Rolling Code Technology and Key Encryption Explained

Early key fobs (late 1980s through mid-1990s) used a fixed code transmitted in the clear -- no encryption, no variation. The same 40-bit or 64-bit code was transmitted every time you pressed the lock button. An attacker with a simple RF receiver could capture this code and replay it at will, unlocking your vehicle without any key. This attack was called a 'replay attack' and was documented in academic literature as early as 1992. The auto industry's solution was the rolling code, independently developed by several companies and most successfully commercialized by Microchip Technology under the KeeLoq trademark in 1996. KeeLoq became the dominant rolling code algorithm used by Chrysler, GM, Volkswagen, and others through the early 2000s. It has since been supplemented and partially replaced by AES-based protocols, but KeeLoq remains widely deployed.

A rolling code system uses two synchronized counters: one in the transmitter (your key fob) and one in the receiver (your vehicle's BCM or remote receiver). When you press a button, the fob increments its counter and encrypts the counter value using a secret key shared between the fob and the vehicle at programming time. This encrypted counter value is the 'code' transmitted on 315 MHz or 433 MHz. The vehicle's receiver has the same secret key. When it receives a transmission, it decrypts the code and reads the counter value. If the counter value falls within an acceptable window (typically the next 256 increments beyond the last valid received value), the command is accepted and acted upon (lock, unlock, etc.). The counter is then advanced to just beyond the received value. Because the code changes every transmission, a captured code is only valid for one transaction. A replay attack fails because the captured code's counter value is already in the vehicle's 'used' history. An attacker who captures a code while out of range and attempts to replay it later will find that the code was already used (or is now outside the acceptable window).

The look-ahead window (typically 256 counter increments) exists to accommodate accidental button presses: if you press the fob's buttons in your pocket 50 times while the vehicle is out of range, the fob counter advances 50 steps. When you return to range, the vehicle's counter is 50 steps behind the fob's current value -- still within the look-ahead window, so the next valid press succeeds and the vehicle advances its counter to match. But if the button is pressed thousands of times (left at the bottom of a bag pressing against other items, or the spring fails to release and holds the button), the fob counter can advance far beyond the vehicle's look-ahead window. The next valid press the vehicle receives has a counter value so far ahead of what it expects that it rejects it as potentially fraudulent. The fob appears dead to the vehicle even though battery and hardware are fine. Re-synchronization procedures exist for this scenario: most vehicles accept resynchronization by pressing a specific button sequence while very close to the receiver, or by entering a resync mode through the vehicle's settings. Programming via OBD-II is the most reliable method to reset the rolling code counter baseline.

Modern smart key and transponder systems have moved beyond simple rolling codes to AES (Advanced Encryption Standard) challenge-response protocols. Instead of the fob unilaterally deciding the code to send, the vehicle issues a random challenge to the key, and the key computes the correct response using AES-128 encryption with its stored secret key. The vehicle independently computes the expected response and validates the match. This bidirectional challenge-response architecture is significantly more secure than one-way rolling codes. Even if an attacker captured the complete radio exchange, they could not derive the secret key from the visible challenge and response (due to the one-way nature of the AES function). And since the challenge is generated fresh every time, a captured exchange cannot be replayed. AES-128 is currently considered computationally infeasible to brute-force with any available technology. The key space is 2^128 -- approximately 340 undecillion possible keys. Even the world's fastest supercomputers would require billions of years to test every possible key. This is why Hitag AES and equivalent chips cannot be cloned: there is no way to extract the secret key from the chip's protected memory or infer it from observed transmissions.