Remote Keyless Entry and Immobilisers

Vehicle entry and engine authorisation rely on three overlapping mechanisms. Remote Keyless Entry (RKE) responds to a button press: the fob transmits a rolling code over UHF (315 or 433 MHz), accepted if the code falls within a valid counter window. Passive Keyless Entry and Start (PKES) requires no button press; the car polls nearby fobs over short-range LF, commonly 125 or 134 kHz, and unlocks automatically on a valid challenge-response. Immobilisers form a separate last line of defence: an RFID transponder in the key must authenticate cryptographically before the engine control module will enable fuel and ignition. Most dismantling work in this chapter targets immobiliser ciphers, because breaking them allows engine start independent of relay or code-capture attacks.

PKES Relay Attacks

Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars

Francillon, Danev, Capkun, NDSS 2011 ^[1]

Francillon, Danev and Capkun at ETH Zurich built two low-cost relays and tested them against 10 car models from 8 manufacturers. The attack exploits a structural assumption: PKES relies on the LF polling signal reaching only nearby fobs (1 to 2 metres). A relay that forwards LF from near the car to near the key defeats this without touching the cryptographic exchange.

The wired relay used coaxially connected loop antennas; the wireless relay up-converted the 130 kHz LF carrier to 2.5 GHz and down-converted at the key end. The key's UHF reply naturally carries 10 to 100 metres without assistance. Component cost was $100 to $1,000. All 10 models were successfully unlocked and started. Any PKES system using LF polling plus UHF response is structurally vulnerable regardless of cryptographic strength. Proposed mitigations include motion-sleeping fobs, UWB distance bounding (later adopted by some manufacturers), and Faraday pouches.

Wireless relay architecture showing the LF signal forwarded through an amplifier to the key, with the UHF reply returning directly to the car. Figure from Francillon et al., 2011 (Relay Attacks on PKES).

Megamos Crypto

Dismantling Megamos Crypto: Wirelessly Lockpicking a Vehicle Immobiliser

Verdult, Garcia, Ege, USENIX Security 2013 (slides); USENIX Security Supplement 2015 (full paper) ^[2][3]

Megamos Crypto was at the time the most widely deployed immobiliser transponder family, used in Audi, Fiat, Honda, Volkswagen, Volvo, and many other makes. The transponder authenticates using a 96-bit secret key and a proprietary stream cipher whose internal state is only 56 bits wide. The invertibility of the state successor function and a 15-bit known-plaintext leak in the final authentication step create the cryptographic footholds the authors exploit.

Three practical attacks are presented. The first eavesdrops two authentication traces and recovers the 96-bit key with a computational complexity of 2^49 cipher evaluations, using a 12 TB precomputed table. The second exploits a key-update flaw: because many transponders ship with no PIN or a default PIN, an attacker with 30 minutes of wireless access can recover the key with negligible computation and then emulate the transponder. The third targets low-entropy keys, common in OEM configurations where the first 32 bits are all zero, enabling a time-memory trade-off from just two eavesdropped traces.

The legal episode is itself significant: Volkswagen obtained a UK court injunction suppressing publication for two years. The full paper appeared in the 2015 USENIX supplement after the injunction was not renewed.

Megamos Authentication Protocol: the ignition lock and key fob exchange a 32-bit tag identifier, a 56-bit car nonce, a 28-bit car authenticator, and a 20-bit tag authenticator (keystream values). Slide from Verdult, Garcia, Ege, 2013/2015 (Dismantling Megamos Crypto, USENIX Security).

VAG RKE Ciphers (VW1-4 Schemes)

Lock It and Still Lose It (VW1-4 Schemes)

Garcia, Oswald, Kasper, Pavlides, USENIX Security 2016 ^[4]

By extracting and reverse-engineering the firmware of rolling-code receiver ECUs, the authors found that virtually all VW Group vehicles manufactured from roughly 1995 through 2016 rely on a small number of global master cryptographic keys. The paper identifies four distinct scheme generations across the fleet. VW1, the oldest, uses a 433.92 MHz OOK-modulated packet and carries security through LFSR-based obfuscation alone, with no cryptographic key at all; the counter state itself is the only secret. VW2 and VW3 encrypt an 8-byte payload (UID, counter, button byte) with the AUT64 block cipher, a proprietary 12-round construction with key-dependent byte permutations and S-box layers. VW4, found in vehicles from approximately 2009 through 2016, swaps AUT64 for XTEA, a 64-round ARX Feistel cipher with a 128-bit key.

Across all four schemes, the cipher algorithms vary but the deployment flaw is identical: a single worldwide master key is shared across every ECU and every remote built to that scheme. Recovering the master key from any ECU firmware (extracted via documented automotive debug interfaces) is sufficient to clone any remote for any vehicle in the fleet. The practical attack requires eavesdropping exactly one button-press transmission to learn the UID and current counter, then generating valid rolling codes at will. Vulnerable vehicles include essentially all of VW, Audi, SEAT, and Skoda production from ~1995 to 2016, representing well over 100 million vehicles. According to the paper, VW Group acknowledged the flaw and stated that the most recent platform generation (e.g., Golf 7) uses per-vehicle key diversification.

VW1 RKE frame layout showing UID (bits 0-32), obfuscated LFSR counter state (32-56), and button nibble (56-59). Figure from Garcia et al., 2016 (Lock It and Still Lose It).

VW2-4 RKE frame layout showing fixed start pattern, 4-byte UID, 3-byte encrypted counter, and button bytes. VW3 and VW4 share this format while differing in cipher algorithm and start pattern. Figure from Garcia et al., 2016 (Lock It and Still Lose It).

PCB of a newer-generation VW Group remote control carrying the unidentified microcontroller used across the VW3 and VW4 schemes; firmware extraction was complicated by the obscure markings and undocumented programming interface. Figure from Garcia et al., 2016 (Lock It and Still Lose It).

HiTag2

Lock It and Still Lose It (Hitag2 RKE)

Garcia, Oswald, Kasper, Pavlides, USENIX Security 2016 ^[4]

The Hitag2 rolling-code scheme, implemented on NXP PCF7946 and PCF7947 ICs, is used for door-locking RKE across multiple manufacturers independently of any VW Group relationship. The underlying cipher is a 48-bit LFSR combined with a non-linear filter function built from three sub-circuits (fa, fb, fc), drawing 20 of the 48 state bits as inputs and producing one keystream bit per clock cycle. There are no S-boxes in the traditional sense; the filter tables are small Boolean lookup tables. Each button press transmits a 102-bit packet: a fixed preamble, 32-bit UID, 4-bit button code, 10 low-order counter bits, 32 bits of cipher keystream, a padding bit, and an 8-bit XOR checksum.

The paper presents a novel correlation attack exploiting the fact that only 20 LFSR bits influence each keystream output bit. Guessing a partial internal state allows immediate consistency checking against observed keystream. The attack iterates over the reduced search space while accumulating correlation scores across four to eight captured button-press frames, and recovers the 48-bit key in a few minutes on a laptop. Unlike the earlier Hitag2 immobiliser attacks, this approach requires no controlled interaction with the target; eavesdropping from up to 100 metres is sufficient. Vehicles confirmed as affected include models from Abarth, Alfa Romeo, Chevrolet, Citroen, Fiat, Mitsubishi, Nissan, Opel, Peugeot, and Renault, among others.

Hitag2 RKE frame layout showing the 102-bit packet structure: preamble, UID, button code, low-order counter bits (lctr), keystream (ks), padding, and checksum. Figure from Garcia et al., 2016 (Lock It and Still Lose It).

Structure of the Hitag2 stream cipher (Figure 10), showing the 48-bit LFSR taps feeding two-stage nonlinear filter functions. Figure from Garcia et al., 2016 (Lock It and Still Lose It).

Hitag 2 Hell: Brutally Optimizing Guess-and-Determine Attacks

Verstegen, Verdult, Bokslag, USENIX WOOT 2018 ^[5]

The guess-and-determine (GD) attack on Hitag2 works because each keystream bit depends on only 20 of the 48 state bits; guessing a partial state allows immediate consistency checking against observed keystream. Verstegen et al. extend this with memoization of nonlinear sub-functions, precomputed tables to skip impossible states, and GPU bit-slicing. The entire 48-bit state space is searched in approximately 75 seconds on a consumer GPU using two captured RF frames, versus 18 hours for the prior best. The authors verified the attack on 2017-model-year vehicles and released the source under the GPL.

The Hitag2 LFSR state and two-stage filter function (f), showing how 20 of the 48 state bits feed the nonlinear output. Figure from Verstegen et al., 2018 (Hitag 2 Hell).

DST40 and DST80 (Tesla, Toyota, Hyundai/Kia)

Fast, Furious and Insecure: PKES in Modern Supercars

Wouters, Marin, Ashur, Gierlichs, Preneel, IACR TCHES 2019 ^[6]

The Texas Instruments DST40 cipher was publicly broken in 2005 at its 40-bit key size, yet was still in active use more than a decade later. Wouters et al. at KU Leuven found that the Tesla Model S (pre-2018 key fob), McLaren, Karma, and Triumph motorcycles all share a Pektron PKES system built on DST40. The 40-bit key space allows exhaustive search in seconds on modern hardware.

The PKES protocol conducts a three-phase challenge-response over LF (134 kHz) and UHF (433 MHz): the car sends a 40-bit challenge, the fob responds with a 24-bit DST40 output, and a valid response unlocks doors and starts the engine using the same key. No read-out protection was present on the MSP430 in the key fob, enabling straightforward firmware extraction. The practical attack uses a Proxmark III to collect challenge-response pairs from the target fob over a few seconds; exhaustive key search completes in seconds. A backpack-sized device can then impersonate the fob indefinitely.

PKES protocol during nominal operation, showing the two challenge-response exchanges for door unlock and engine start. Figure from Wouters et al., 2019 (PKES in Modern Supercars).

Dismantling DST80-based Immobiliser Systems

Wouters, Van den Herrewegen, Garcia, Oswald, Gierlichs, Preneel, IACR TCHES 2020 ^[7]

The same group turned to DST80, Texas Instruments' 80-bit successor cipher, previously undisclosed. They extracted the cipher from immobiliser ECU firmware by voltage-glitching the Renesas 78K0 microcontroller used in Toyota immobilisers, reducing the glitch count from 15,000 (prior best) to two pulses.

Beyond the cipher, the paper exposes key-diversification failures. Toyota derives the transponder key from the serial number and three manufacturer constants readable by any reader, so the cryptographic key can be computed from a wireless serial read with no authenticated interaction. Kia and Hyundai use a marginally better scheme but achieve only three bytes of effective entropy, reducing the key search from 2^80 to 2^24. A downgrade attack on the second-generation Tesla Model S fob reduces the effective key space to 2^41. A portable profiled side-channel attack on the DST80 key-loading procedure reduces the key space to 2^40 using just 10 power traces.

Typical DST80 immobiliser system: the DST80 transponder communicates at 125 kHz through the ignition coil to an RFID reader inside the immobiliser ECU, which then authorises the Engine Control Unit via a serial link. Figure from Wouters et al., 2020 (Dismantling DST80).

My Other Car Is Your Car: Compromising the Tesla Model X Keyless Entry System

Wouters, Gierlichs, Preneel, IACR TCHES 2021 ^[8]

The Model X was designed with relay and cloning attacks in mind: its fob uses BLE for key-fob communication, a separate 22 kHz low-frequency transponder for wake-up signalling, an accelerometer to suppress the fob when stationary, and an Infineon SLM97 Secure Element rated Common Criteria EAL5+. All cryptographic operations use standard AES and public-key primitives.

Two implementation weaknesses combined into a full compromise. First, the BLE firmware update mechanism accepted modified firmware because the old fob firmware ignored the Secure Element's signature-verification failure. This let an attacker within BLE range disable the APDU block list and request an unlock token from the Secure Element. Second, the pairing protocol could skip the provisioning step that normally depends on Tesla service tooling. The proof of concept wakes a target fob using an LF packet derived from the public VIN, updates the fob firmware over BLE, obtains an unlock token, unlocks the car, then uses the diagnostic connector to pair a modified fob that can start the vehicle. Tesla patched via OTA update; the paper confirms the fix is sound.

Model X key fob PCB (top side) with the CC2541 BLE SoC, Infineon Secure Element, and MEMS accelerometer. Figure from Wouters et al., 2021 (My Other Car Is Your Car).

Key fob prepared for inter-chip communication analysis using a logic analyser and CC-Debugger interface. Figure from Wouters et al., 2021 (My Other Car Is Your Car).

KeeLoq

KeeLoq is a 64-bit block cipher used in rolling-code RKE and IFF authentication, designed in the 1980s and commercialised by Microchip Technology. Its structure is a 32-bit NLFSR with a five-variable nonlinear feedback function iterated for 528 cycles and a rotating 64-bit key register. The self-similar key schedule creates slide-attack opportunities. Users included Chrysler, Fiat, GM, Honda, Toyota, Volvo, VW, Jaguar, and HomeLink, among others. The four papers below collectively dismantle it.

Attacks on the KeeLoq Block Cipher and Authentication Systems

Bogdanov, RFIDsec 2007 ^[9]

Bogdanov's 2007 paper is the first public cryptanalysis of KeeLoq. The self-similar key schedule allows a slide pair to collapse the effective key search; combined with a linear approximation of the nonlinear filter function, the attack recovers the key in 2^50.6 evaluations from 2^32 known plaintext-ciphertext pairs. A cycle-structure variant reduces this further to 2^37. The two standardised key derivation schemes compound the problem: knowing one device key lets an attacker derive adjacent device keys at negligible cost, eroding protection for an entire product series.

The i-th KeeLoq encryption cycle, showing the 32-bit NLFSR (Y), five-tap nonlinear function (NLF), and rotating key register (K). Figure from Bogdanov, 2007 (Attacks on the KeeLoq Block Cipher).

A Practical Attack on KeeLoq

Indesteege, Keller, Dunkelman, Biham, Preneel, EUROCRYPT 2008 ^[10]

Indesteege et al. combine the slide technique with a meet-in-the-middle approach, requiring 2^16 chosen plaintexts and 2^44.5 KeeLoq evaluations with approximately 3 MB of storage. Chosen plaintexts are obtainable by presenting arbitrary challenges over the unauthenticated KeeLoq IFF protocol, needing 65 to 98 minutes of physical access. A measured implementation recovered keys in roughly 7.8 days on 64 CPU cores. The paper also confirms that one of the two standardised key derivation schemes allows recovering the manufacturer key from a single exposed device key.

On the Power of Power Analysis in the Real World: A Complete Break of the KeeLoq Code Hopping Scheme

Eisenbarth, Kasper, Moradi, Paar, Salmasizadeh, Shalmani, CRYPTO 2008 ^[11]

While the previous two papers require extended IFF access, this paper shows that differential power analysis is far more efficient in practice. Three attacks are described against commercial Microchip HCSXXX encoder chips and PIC microcontrollers. The first recovers the device key from ten power traces in minutes. The second recovers the manufacturer key by DPA on a receiver. The third, most impactful attack is fully remote: by eavesdropping two rolling-code transmissions over the air and applying DPA to a receiver the attacker already possesses (sharing the manufacturer key), any target remote's secret key can be recovered without physical contact. The paper refuted industry claims that a practical gap between laboratory DPA and real-world deployments protected commercial products.

KeeLoq key derivation schemes: the device key is derived from the serial number via one or two KeeLoq decryptions using the manufacturer key. Figure from Eisenbarth et al., 2008 (Power Analysis KeeLoq).

Breaking KeeLoq in a Flash: On Extracting Keys at Lightning Speed

Kasper, Kasper, Moradi, Paar, AFRICACRYPT 2009 ^[12]

This companion paper addresses extracting the manufacturer key from KeeLoq software implementations in receivers. DPA is noisier here, so the authors use a simple power analysis (SPA) approach: the Microchip reference implementation has data-dependent timing in its key schedule, and a single decryption trace is sufficient to read off the 64-bit master key. The attack completes in seconds and requires no plaintext or ciphertext knowledge. Once the manufacturer key is obtained, the remote eavesdropping chain from the CRYPTO 2008 paper enables cloning of every device in the series.

Visual inspection of power traces of the KeeLoq cipher: traces (a) and (b) show distinguishable conditional branch patterns used to recover key bits; trace (c) lacks this structure. Figure from Kasper, Kasper, Moradi, Paar, 2009 (Breaking KeeLoq in a Flash).

ECM Authentication (Peugeot, Fiat, Opel)

An Assessment of ECM Authentication in Modern Vehicles

Bokslag, Master Thesis, Eindhoven University of Technology, 2017 ^[13]

Most immobiliser research targets the transponder-to-BCM link. Bokslag's thesis examines the next link: the BCM-to-ECM challenge-response that must complete before the ECM enables the engine, running over the internal CAN bus and unexamined in academic literature at the time.

Three vehicles (Peugeot, Fiat, and Opel, identified by reverse engineering) are analysed using CAN traffic captured at OBD-II and BCM firmware extracted via the diagnostic interface. The Peugeot cipher has an invertible transformation leaking key bits through output bias. The Fiat scheme uses LFSR-like feedback invertible from observed output, enabling state reconstruction. The Opel variant does not yield to the same techniques. Two of the three manufacturers deployed ECM authentication bypassable from OBD access and a laptop.

Rolling-Code Replay

Drive It Like You Hacked It: New Attacks and Tools to Wirelessly Steal Cars (RollJam)

Kamkar, DEF CON 23, 2015 ^[14]

Kamkar's RollJam device jams the 315/433 MHz channel while capturing the transmitted code. When the car does not respond, the owner presses again; the device captures both codes but delivers only the first. The attacker holds the second, valid and unused, for later replay. The attack subverts the rolling window rather than breaking any cipher. The held code remains useful only until the fob successfully advances the vehicle past it; a later unjammed press can invalidate it.

RollBack: A New Time-Agnostic Replay Attack Against RKE

Csikor, Lim, Wong, Ramesh, Parameswarath, Chan, arXiv 2022 ^[15]

RollBack exploits the resynchronisation feature included in all rolling-code systems: when a fob's counter drifts ahead after out-of-range presses, the car resynchronises to a code within a broad lookahead window. Csikor et al. show that most implementations also accept backward resynchronisation; replaying several consecutive old codes tricks the car into rolling its counter back, making all intervening codes valid. Unlike RollJam, the attack requires no jamming and no continuous presence. An attacker captures a short sequence of consecutive transmissions once and replays them weeks or months later. Approximately 70% of Asian vehicles tested were vulnerable. The time-agnostic property is particularly relevant in car-sharing contexts.

RollJam versus RollBack comparison showing how RollBack eliminates the continuous-presence requirement and the timing sensitivity that limit RollJam. Figure from Csikor et al., 2022 (RollBack).

Direct CAN Attacks

CAN Injection: Keyless Car Theft

Tindell, Canis Automotive Labs blog, 2023 ^[16]

Ken Tindell and Ian Tabor investigated Toyota RAV4 thefts where the only visible sign was a damaged headlight harness. Telematics DTCs recorded at the time of theft showed multiple ECUs on the body CAN bus going silent simultaneously, not from failure but from bus disruption: the thieves were injecting fake messages. CVE-2023-29389 was assigned to this issue.

PKES relay attacks had become less effective as owners adopted Faraday pouches and manufacturers deployed motion-sleeping fobs. A criminal market emerged for CAN injection devices built into everyday enclosures (a JBL Bluetooth speaker case in the documented cases), sold for up to €5,000 per unit targeting specific models. The device contains approximately $10 of components: a PIC18F microcontroller with CAN hardware and a transceiver modified for dominant-override mode.

Connected through the headlight connector, the device wakes sleeping ECUs, then enables its dominant-override circuit to silence all other transmitters. It floods the bus with spoofed "smart key validated" messages at approximately 20 frames per second; the gateway forwards these to the powertrain bus; the ECM deactivates the immobiliser. A button press on the speaker case unlocks the doors.

RAV4 CAN bus wiring diagram showing the three buses (control, powertrain, autonomy) and the headlight ECU entry point used by the CAN injector. Figure from Tindell, 2023 (CAN Injection: Keyless Car Theft).

The CAN injection device disassembled from its JBL Bluetooth speaker housing. Figure from Tindell, 2023 (CAN Injection: Keyless Car Theft).

References