Also known as: rolling code, hopping code, code-hopping
A rolling code (or hopping code) is the scheme that stops a captured remote keyless entry transmission from being replayed, by making every button press send a different, non-repeating value.1 Instead of a fixed secret that anyone who records one press could re-transmit, the fob encrypts an internal counter that increments on each use, so the code visibly “rolls” forward and a receiver rejects any value it has already seen. It is the security core of the vast majority of car and garage-door remotes.
How it works
The fob and the receiver share a secret key and each keep a synchronization counter. On every button press the fob increments its counter, encrypts that counter (plus a fixed identifier and button bits) under the shared key, and transmits the result — a value that looks random and differs from the last. The receiver decrypts the incoming code, checks that the recovered counter is greater than the last counter it accepted, and if so opens and advances its own stored counter to match. A replayed old capture carries a stale counter the receiver has already passed, so it is rejected.
Because a user may press the fob out of range of the receiver, the counter can drift ahead of what the receiver has seen. Systems therefore accept any counter within a forward window (typically a few hundred codes ahead) and resynchronize to it, with a larger tolerance requiring two consecutive in-sequence presses. This window is what makes the scheme usable in the real world — and, as attacks show, is also a weak point.
Variants
The dominant implementation is KeeLoq, a lightweight proprietary block cipher with a 32-bit block and 64-bit key, built around a nonlinear-feedback shift register run for 528 rounds; it encrypts the counter to produce the hopping value.2 Simpler and older remotes used a linear-feedback shift register to sequence codes, but a bare LFSR is linear and its sequence can be predicted from a few observed codes, so it offers replay resistance without real cryptographic strength. Higher-end automotive systems have since moved to AES-based rolling codes and to two-way challenge–response, which resist the counter-window attacks below.
In practice — known weaknesses
Rolling codes defeat naive replay but not more active attacks. The well-known RollJam attack jams the receiver while recording a valid press, so the code is never consumed by the car; the attacker replays the captured-but-unused code later. Because KeeLoq’s cipher was reverse-engineered, researchers also demonstrated key-recovery and cloning attacks against fobs whose manufacturer key was weakly derived. These are the reasons the field is migrating toward authenticated, challenge–response, and AES-based designs. None of this is decryption of content — an RKE frame carries no message, only an authenticator — so the attacks target the protocol’s freshness guarantee rather than confidentiality.
Relevance to SDR
Rolling-code remotes are a classic short-range RF signal a software-defined radio can observe: they transmit brief OOK/FSK bursts in the 315 MHz and 433 MHz ISM bands, and their structure (preamble, fixed serial number, hopping code field) is easy to demodulate and log. What an SDR cannot do without the fob’s key is predict or forge the next valid code, and replaying a recorded one fails by design against the counter check. GopherTrunk is a trunked-radio scanner and does not target RKE devices, so this entry is background on how the wider RF world uses lightweight cryptography: it illustrates authentication-by-counter rather than the keystream-based voice encryption GopherTrunk actually encounters on P25 and DMR.
Sources
-
Rolling code — Wikipedia, for the incrementing-counter model, the resynchronization window, and the RollJam replay-with-jamming attack. ↩
-
KeeLoq — Wikipedia, for the KeeLoq block cipher’s 32-bit block, 64-bit key, NLFSR round structure, and reverse-engineering/cloning attacks. ↩