0

Let's say we have a hub called H and a door lock controller called D1

Now, we have a malicious electronic which imitates H called M

H sends D1 a command to open the door, D1 unlocks the door.

M captures the message (command), now I assume M can repeat an identical message at a later time and cause D1 to unlock.

How could I stop this?


My idea is to include a timestamp, which is validated by D1 and encrypt the message. If the timestamp is older than 30s then D1 will ignore the command. This still seems unsecure however.


Clarifications:

None so far

Read more

Replay Attacks

1

You are on the right path, but you would need 3 things:

  • Unlock Message
  • Timestamp
  • Unique Message ID

This way the Unlock Message couldn't be captured and replayed in the 30 second window. You would just need to keep a log of used Unique IDs in D1 that have been used in the last 30s

As long as the private key in H is kept secure, and the public key in D1 is not tampered with ... this method should be secure.

It should also be noted that D1 should have a method of securely syncing its internal time system with H periodically to prevent time drift which could otherwise render D1 completely inoperative.


Another option would be to keep a public / private key on both H and D1 ... this would allow you to create a shared secret which could be used as a Secret Key for something like AES256 communication between H and D1. I am noting this because you put TLS as a tag in your question ... and this is in essence how TLS works.

TLS Handshake

enter image description here

  • Time synchronization seems like another big problem here – mateos Jan 23 '17 at 6:12
  • @Albert see update – CaffeineAddiction Jan 23 '17 at 6:15
  • Thanks, Makes more sense. If I don't find another method for Replay Attacks I'll accept this – mateos Jan 23 '17 at 6:30
  • trivial way to sync the date: you send it encrypted like the open message. (something like every 30 min ~ 1 hour) @Albert – satibel Jan 23 '17 at 8:59
1

One typical way to address the replay problem is to use a rolling code or one time passwords (OTP). The main idea of these approaches is that each message is different from the previous one and the recipient knows which message to expect next from the sender. This way replay attacks are impossible, but there is a need for synchronization between sender and recipient. But note that problems with this synchronization can be used to attack rolling code systems.

Another way is to use a challenge-response mechanism where the door lock controller creates a random challenge and the hub replies to this challenge with a response created from the challenge and some secret shared between the hub and the door lock. Since the door lock issues a new random challenge all the time and expects only the response to exactly this challenge replay attacks are impossible. Compared to rolling code or OTP no synchronization is needed but the hub needs the ability to receive the challenge instead of only transmitting data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.