Skip to main content
Information Security

Return to Question

Clarified that device ID would be checked.
Source Link
David
David
  • 16.1k
  • 3
  • 52
  • 74

I'm in the process of building a network of small devices (ARM microcontrollers with something like nRF24L01 connectivity). The controllers will be receiving commands from a central system over these wireless links, and I'm in the process of designing the protocol. Confidentiality is a non-goal, but integrity & authenticity are. Accordingly, we need to validate both the source and avoid replay attacks of the packets. I'd like to avoid any challenge/response protocols to minimize traffic and battery drain, so what I have in mind is something like this:

  • Key and device ID are burned in to device in the firmware.
  • A counter is initialized to 0.
  • Each command sent to the device contains the device ID, counter++, and the command itself. Then an HMAC-SHA1 is calculated over all of these fields and attached.
  • Upon receiving a command, the device verifies the HMAC-SHA1, device ID and ensures that the counter value is strictly larger than the counter stored in NVRAM. If so, it sets the NVRAM counter to the value in the received packet and carries out the command.
  • (Possibly an ack of some sort here.)

Is this protocol similar to anything that exists (I couldn't find anything) or is there anything suitable that already exists? Am I missing a major flaw?

I'm in the process of building a network of small devices (ARM microcontrollers with something like nRF24L01 connectivity). The controllers will be receiving commands from a central system over these wireless links, and I'm in the process of designing the protocol. Confidentiality is a non-goal, but integrity & authenticity are. Accordingly, we need to validate both the source and avoid replay attacks of the packets. I'd like to avoid any challenge/response protocols to minimize traffic and battery drain, so what I have in mind is something like this:

  • Key and device ID are burned in to device in the firmware.
  • A counter is initialized to 0.
  • Each command sent to the device contains the device ID, counter++, and the command itself. Then an HMAC-SHA1 is calculated over all of these fields and attached.
  • Upon receiving a command, the device verifies the HMAC-SHA1 and ensures that the counter value is strictly larger than the counter stored in NVRAM. If so, it sets the NVRAM counter to the value in the received packet and carries out the command.
  • (Possibly an ack of some sort here.)

Is this protocol similar to anything that exists (I couldn't find anything) or is there anything suitable that already exists? Am I missing a major flaw?

I'm in the process of building a network of small devices (ARM microcontrollers with something like nRF24L01 connectivity). The controllers will be receiving commands from a central system over these wireless links, and I'm in the process of designing the protocol. Confidentiality is a non-goal, but integrity & authenticity are. Accordingly, we need to validate both the source and avoid replay attacks of the packets. I'd like to avoid any challenge/response protocols to minimize traffic and battery drain, so what I have in mind is something like this:

  • Key and device ID are burned in to device in the firmware.
  • A counter is initialized to 0.
  • Each command sent to the device contains the device ID, counter++, and the command itself. Then an HMAC-SHA1 is calculated over all of these fields and attached.
  • Upon receiving a command, the device verifies the HMAC-SHA1, device ID and ensures that the counter value is strictly larger than the counter stored in NVRAM. If so, it sets the NVRAM counter to the value in the received packet and carries out the command.
  • (Possibly an ack of some sort here.)

Is this protocol similar to anything that exists (I couldn't find anything) or is there anything suitable that already exists? Am I missing a major flaw?

Tweeted twitter.com/#!/StackSecurity/status/444060580505473024
Source Link
David
David
  • 16.1k
  • 3
  • 52
  • 74

Avoiding Replay Attacks on Lightweight Channel

I'm in the process of building a network of small devices (ARM microcontrollers with something like nRF24L01 connectivity). The controllers will be receiving commands from a central system over these wireless links, and I'm in the process of designing the protocol. Confidentiality is a non-goal, but integrity & authenticity are. Accordingly, we need to validate both the source and avoid replay attacks of the packets. I'd like to avoid any challenge/response protocols to minimize traffic and battery drain, so what I have in mind is something like this:

  • Key and device ID are burned in to device in the firmware.
  • A counter is initialized to 0.
  • Each command sent to the device contains the device ID, counter++, and the command itself. Then an HMAC-SHA1 is calculated over all of these fields and attached.
  • Upon receiving a command, the device verifies the HMAC-SHA1 and ensures that the counter value is strictly larger than the counter stored in NVRAM. If so, it sets the NVRAM counter to the value in the received packet and carries out the command.
  • (Possibly an ack of some sort here.)

Is this protocol similar to anything that exists (I couldn't find anything) or is there anything suitable that already exists? Am I missing a major flaw?