3

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?

Improve this question
4
  • How many devices?
    – miniBill
    Commented Mar 13, 2014 at 7:49
  • Also, looks fine. Only question is: how are you going to track all the counters?
    – miniBill
    Commented Mar 13, 2014 at 7:52
  • In the initial deployment, probably ~10-12, but I don't see a problem with scaling here.
    – David
    Commented Mar 13, 2014 at 7:52
  • I don't see any flaws. I think one minor point is missing in your description. The device must also check the device ID. Otherwise, it would execute commands which are intended for other devices.
    – DanielE
    Commented Mar 13, 2014 at 7:56

1 Answer 1

Reset to default
1

Only suggestion I can give is to always check for acks, and make them include the counter, otherwise an attacker could selectively drop (or delay, but not reorder) packets.

Also, you need to think of a way to keep track of every device counter's value.

Improve this answer
3
  • What would you do if an ACK is missing? Send the command again with an increased counter? Then, if the ACK is droped by an attacker the server would resend the command with an increased counter and the device would do execute the command again.
    – DanielE
    Commented Mar 13, 2014 at 8:20
  • Why do you think is it necessary to keep track of every device's counter?
    – DanielE
    Commented Mar 13, 2014 at 8:25
  • Because otherwise you cannot detect packets dropped by an attacker
    – miniBill
    Commented Jun 12, 2014 at 6:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .