27
$\begingroup$

I have general questions regarding rolling codes. Basically there is a sender and a receiver. Both have a sequence generator. The receiver checks if the received sequence matches the newly generated. An example used is KeeLoq.

Assuming a car opener (sender) and a car (receiver):

  • What happens if the sender is at another point in the sequence? Think of that the key is pressed while out of range to the car.
  • How does they sync the point of the sequence?
  • Is there any prevention to detect replay attacks? How are they implemented?
Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ The whole point is to prevent replay attacks. Otherwise you wouldn't bother with rolling the code and you wouldn't need to deal with the issues introduced by mismatch between sender and receiver. $\endgroup$
    – qris
    Jul 24, 2014 at 12:56
  • $\begingroup$ related: "How do rolling code fobs and receivers synchronise?" $\endgroup$
    – David Cary
    Feb 7, 2019 at 17:38

3 Answers 3

Reset to default
30
$\begingroup$

What happens if the sender is at another point in the sequence? ... the key is pressed while out of range to the car.

In a rolling code (code hopping) system, the keyfob transmitter maintains a synchronization counter C, incremented every time a button is pushed. The car receiver stores the most recent validated synchronization counter it has received N.

When a rolling code receiver gets a message with a keyfob serial number that seems to match one of the authorized keyfobs in its internal memory, it extracts the keyfob's synchronization number C from the message and compares it to the most recent validated synchronization number N.

In the normal case:

  • C in the rolling window of acceptance -- C is more than but within "a few" codes K of the last validated transmission ( 0 < C-N < K+1 ).

When the counter C in the message is in the window of acceptance, then the car accepts that message as an authentic message, the car overwrites N with the latest value C, and the car unlocks the doors or does whatever else the message says to do.

(As long as you hold down the button, the keyfob will repeatedly transmit bit-for-bit the same message over and over several times a second. It isn't until you let up the button and press it down again that it transmits a message with the next sequential counter number).

So it is possible that the sender will get out of range of the k accepteded codes?

Yes. The AVR411 receiver defaults to WINDOW_SIZE = 100. So with a typical AVR411 system, if the car doesn't hear 100 consecutive button-presses, then the car will ignore the keyfob when it finally gets back in range.

With a typical KeeLoq system, if the car doesn't hear 16 consecutive button-presses, then the car will not unlock the doors on the first button-press of the keyfob when it finally gets back in range. However, if the car then hears 2 consecutive button-presses within the resynchronization window ( K < C-N < Resynchonization_Window ), typically over a thousand button-presses, the car will resynchronize and unlock the doors. With a typical HCS301 system, if the car doesn't hear a few thousand consecutive button-presses, then the car will ignore the keyfob when it finally gets back in range.

How does they sync the point of the sequence? ... How are they implemented?

Before the keyfob can be used, the car must "learn" the keyfob. Typically holding down the "learn button" ("learn switch") for 10 seconds erases the receiver's memory of every keyfob; then letting up on that button makes the receiver go into "learn mode". Typically, pressing both the lock and the unlock button simultaneously on the keyfob makes the keyfob transmit its unique secret key to the receiver. The receiver -- in learn mode -- memorizes the keyfob serial number(s) it hears as authorized keyfobs, and also memorizes the secret key and the current synchronization counter N. After everything is quiet for 10 consecutive seconds with no button presses, the receiver times-out of learn mode and goes into normal mode.

After that, that receiver -- in normal mode -- is now synchronized to the keyfobs.

The tiny amount of battery power available to the keyfob, and the fact that the keyfob only transmits -- never receives -- makes it difficult or impossible to use many cryptographic algorithms.

For details on two popular rolling code implementations, see:

Improve this answer
$\endgroup$
1
  • 3
    $\begingroup$ It's really worth reading the application note for the AVR411 cited above. It includes design objectives, threat model, design rationale, weaknesses, and a reference implementation. Here's a more current (2019) link: microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591226 $\endgroup$
    – MZB
    Jan 28, 2019 at 15:07
14
$\begingroup$

It is worth pointing out that Samy Kamkar realized and implemented (in 2015) what is now forehead-slappingly obvious in retrospect - it's perfectly practical to have a radio TX+RX unit that snoops a legitimate code and then turns on a momentary jammer transmitter to slightly corrupt the end of it (so it's not recognized as valid by the receiver). The keyfob owner then thinks "oh" and presses the button again, transmitting a second code. You do the same thing again (snoop it and corrupt it slightly), and then you re-transmit the first code; causing the car/garage to open. The owner simply sees that it worked the second time and goes about their day; leaving you with the second - still valid - rolling code to replay at your leisure. This is known as the "Rolljam" attack and pretty much destroys all rolling code security.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Why not a time-based, cryptographic rolling code transmission? Put a receiver and clock in the keyfob, then put pairing buttons on both the car and the keyfob. Car and keyfob negotiate a cryptographic key used to send timestamped messages from keyfob to car, ex: "UNLOCK20221228T0730" (indicating an UNLOCK message was generated by the keyfob on 2022-12-28 at 7:30AM UTC) Car rejects any messages sent, say, less than 10 seconds before current time. $\endgroup$
    – Montana Burr
    Dec 28, 2022 at 20:33
6
$\begingroup$

In a rolling code both the sender and the receiver always move forward in the sequence. If the sender has sent the $n$th code, then it will send the $(n+1)$th next. Contrarily, if the receiver has seen the $n$th code it will only accept the $(n+1)$th code or some later code.

What happens if the sender is at another point in the sequence? Think of that the key is pressed while out of range to the car. How does they sync the point of the sequence?

The receiver will have to skip those intermediate points. One strategy is to scan the next $k$ possible codes and compare. If the received code is in the range $[n+1, n+k]$, then it is accepted.

Is there any prevention to detect replay attacks? How are they implemented?

A replay attack will not work, because the captured codes are no longer within accepted range – and never will be if the sequence period is long enough.

Improve this answer
$\endgroup$
4
  • $\begingroup$ So it is possible that the sender will get out of range of the $k$ accepteded codes? And therefor the car would not open anymore...A denial of service attack against environmental pollution ;-) But is there a method on how to prevent those attacks? $\endgroup$
    – matcauthon
    Jul 25, 2014 at 4:46
  • $\begingroup$ @matcauthon, assuming it uses that method of synchronization, then yes, and I think most do. It would be possible to have a different algorithm that sends a sequence counter in addition to the code – then you need cryptographically strong primitives and not just obfuscation. $\endgroup$
    – otus
    Jul 25, 2014 at 8:04
  • $\begingroup$ If a scanner or something received the signal instead of the intended recipient, could it not then replay it? For example, if the transmitter sent code n in the sequence and it was received by a receiver other than the intended recipient, the intended recipient would still be waiting, expecting a code between n and n+k. The scanner could then play the captured code n back to the recipient and it would unlock. This would only work if the scanner received the signal instead of the intended recipient, rather than as well as. Or am I missing some further security feature? $\endgroup$
    – Simon Elms
    Dec 13, 2015 at 1:23
  • $\begingroup$ @SimonTewsi, that's right. However, as soon as the intended recipient received a later signal the captured one would no longer be valid. So in normal use, where the signal is only sent when the e.g. car needs to be opened, there would not really be an occasion to make use of such an attack. $\endgroup$
    – otus
    Dec 13, 2015 at 7:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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