The attack known as Rolling-PWN (CVE-2021-46145) [1] is the latest of a recent series of security issues affecting the car’s immobilizers and RKEs (Remote Keyless Entry, also known as the keyfob 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 [2], Hyundai-Kia [3], VAG (Volkswagen, Audi, Seat, Porsche, Skoda) [4], and others. This time, the targets of Rolling-PWN 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, keyfobs have an internal counter which is incremented, encrypted, and transmitted when a button (i.e., LOCK or UNLOCK door) is pressed. When the car receives the radio packet sent by the keyfob, 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 little resources, compromising their security. Common algorithms like Keeloq, Hitag, DST40, Megamos, or AUT64 were designed in the 80’s and 90’s, 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. [5], [6], [7], [8], [9]
Insecure key management
Even when a secure algorithm – like AES – is used, the keys are often incorrectly managed. Unfortunately, insecure key derivation, provisioning, and storing are the norm.
Unprotected hardware and software
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 and side channel analysis are rarely present.
These vulnerabilities typically result in the attack path like this:
- Firmware extraction
The ECU (Electronic Controller Unit) 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 [4]. More advanced attacks involve fault injection to re-enable the JTAG [3] of the microcontrollers or bypass the UDS authentication. Unified Diagnostic Services [10] 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 implemented, vulnerabilities are found that allow the attacker to clone the original keyfob 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 keyfob is possible because a certain sequence of keypresses forces the counters to be resynchronized. In 2019, a similar vulnerability (CVE-2019-20626) [11] 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 [12]. The security of the automotive industry has improved significantly since then. Still, the average age of the EU vehicle fleet is 12 years [13]. 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 the 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 being posed by not securing its products properly. Proof of that is the good reception that the recently published ISO21434 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 life-cycle 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 OTA, secure domain / 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, pentesting, and SCA/FI testing, will undoubtedly result in stronger security.
Bibliography
[1] R. P. Attack. [Online]. Available: https://rollingpwn.github.io/rolling-pwn/.
[2] L. Wouters, E. Marin, T. Ashur, B. Gierlichs and B. Preneel, “Fast, Furious and Insecure: Passive Keyless Entry and Start Systems in Modern Supercars,” IACR Transactions on Cryptographic Hardware and Embedded Systems, 2019.
[3] W. Lennert , V. d. H. Jan , G. Flavio and O. David, “Dismantling DST80-based Immobiliser Systems,” IACR Transactions on Cryptographic Hardware and Embedded System, p. 99–127, 2020.
[4] F. Garcia, D. Oswald, T. Kasper and P. Pavlides, “Lock It and Still Lose It-on the (In) Security of Automotive Remote Keyless Entry Systems.,” 25th USENIX security symposium, 2016.
[5] C. Hicks, F. Garcia and D. Oswald, ” Dismantling the AUT64 Automotive Cipher,” IACR Transactions on Cryptographic Hardware and Embedded Systems, pp. 46-49, 2018.
[6] R. Verdult, F. Garcia and B. Ege, “Dismantling Megamos Crypto: Wirelessly Lockpicking a Vehicle Inmobilizer,” Supplement to the Proceedings of 22nd USENIX Security Symposium (Supplement to USENIX Security 15), pp. 703-718, 2015.
[7] R. Verdult, F. Garcia and J. Balasch, “Gone in 360 Seconds: Hijacking with Hitag2,” 21st USENIX Security Symposium (USENIX Security 2012), pp. 237-252, 2012.
[8] S. Indesteege, N. Keller, O. Dunkelman, E. Biham and B. Preneel, “A Practical Attack on KeeLoq,” Advances in Cryptology – EUROCRYPT 2008, 2008.
[9] B. Stephen , G. Matthew , S. Adam and J. Ari , “Security Analysis of a Cryptographically-Enabled,” Proceedings of the USENIX14 Security Symposium, 2005.
[10] M. Alyssa, A. Milburn and S. Cordoba, “There Will Be Glitches: Extracting and Analyzing Automotive Firmware Efficiently”.
[11] “PoC for vulnerability in Honda’s Remote Keyless System(CVE-2022-27254),” https://github.com/nonamecoder/CVE-2022-27254. [Online].
[12] “Hackers Remotely Kill a Jeep on the Highway—With Me in It,” [Online]. Available: https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/.
[13] “Average age of the EU vehicle fleet, by country,” [Online]. Available: https://www.acea.auto/figure/average-age-of-eu-vehicle-fleet-by-country/.