Security Highlight: Rolling-PWN Automotive Attack
The attack known as Rolling-PWN is the latest of a recent series of security issues affecting the car’s immobilizers and remote keyless entry (RKE, also known as the key fob or remote control). Over the past years, we have seen how security researchers identified attacks that could open and even start cars from vendors like Tesla, Hyundai-Kia, VAG (Volkswagen, Audi, Seat, Porsche, Skoda), and others. This time, the targets are Honda vehicles from 2012 to 2022.
Car manufacturers rely heavily on cryptography to protect their vehicles against thieves. For example, to prevent capture-replay attacks on the RF signal transmitted, key fobs have an internal counter which is incremented, encrypted, and transmitted when a button such as the door lock button is pressed. When the car receives the radio packet sent by the key fob, the counter is decrypted by the vehicle and compared with the expected value. Packets with counters behind the expected value are discarded to prevent reusing old, captured packets. This mechanism is commonly known as “rolling code,” and it is used in almost every car manufactured after 2000.
When analyzing the public attacks for RKE and immobilizers, we find the same vulnerabilities unfortunately repeated over and over again.
Weak cryptography
The car vendors often rely on old algorithms designed to run in 8-bit microcontrollers with few resources, compromising their security. Common algorithms like Keeloq, Hitag, DST40, Megamos, or AUT64 were designed in the eighties and nineties, and their design principles are considered insecure by modern standards. Moreover, none of these algorithms were open to public scrutiny. As a result, when the algorithm was leaked by hackers, researchers found multiple weaknesses.
Insecure key management
Even when a secure algorithm — like Advanced Encryption Standard (AES) — is used, the keys are often incorrectly managed. Unfortunately, insecure key derivation, provisioning, and storing are the norm.
Unprotected hardware and software
In many cases, no special protection mechanisms are implemented in the software or hardware to prevent firmware extraction or reverse engineering. Countermeasures against well-known attacks like fault injection (FI) and side channel analysis (SCA) are rarely present.
These vulnerabilities typically result in an attack path like this:
- Firmware extraction
The Electronic Controller Unit (ECU) firmware responsible for the RKE is extracted. This is usually done with the help of standard tools used in the car workshops for maintaining the vehicles. More advanced attacks involve fault injection to re-enable the Joint Test Action Group (JTAG) standard of the microcontrollers or bypass the United Diagnostic Services (UDS) authentication, which is a debug protocol present in every modern car.
- Firmware reversing
The extracted firmware is analyzed to identify the cryptographic algorithm used and to retrieve cryptographic keys.
- Cryptanalysis
Due to the poor cryptography, the attacker finds vulnerabilities that allow them to clone the original key fob and unlock the vehicle.
In the specific case of the Rolling-PWN attack, no technical information has been released yet. So far, we know that reusing pre-captured traces from the key fob is possible because a certain sequence of key presses forces the counters to be resynchronized. In 2019, a similar vulnerability was found. On that occasion, the security researcher identified that many Honda vehicles sold in the American market use no Rolling Code, making them vulnerable to trivial capture-replay attacks.
For most car vendors, cybersecurity was not really a priority until 2015, when two researchers demonstrated that they could remotely kill a Jeep Cherokee. The security of the automotive industry has improved significantly since then. Still, the average age of the EU vehicle fleet is 12 years. This means that there are still millions of vehicles vulnerable to already known and yet-to-be-discovered vulnerabilities. It is reasonable to think that we will see more attacks like Rolling-PWN in the coming years.
While more attacks like Rolling-PWN can be expected in the future, the automotive industry is already aware of the risks posed by not securing its products properly. Proof of that is the good reception that the recently published ISO 21434 had. Although this standard does not give technical answers to the current challenges, it provides a framework for implementing good security practices and policies during the whole lifecycle of an automotive product.
On the technical side, we observe how automotive vendors have been improving their security in the last couple of years by adopting security practices and technologies well established in other industries. Secure boot, secure over-the-air (OTA), secure domain/hardware security module (HSM), secure cryptography, SCA and FI countermeasures, and others are nowadays adopted by most vendors. These practices, together with periodical security tests that include activities like code review, pen testing, and SCA/FI testing, will undoubtedly result in stronger security.