Sunday 25th July 2021

Analysing an attack on automotive keyless entry systems

Published on June 16th, 2021

Modern vehicles are becoming increasingly susceptible to cybersecurity attacks with increased connectivity capabilities and larger, more complex software in automotive systems.

Security researchers have identified numerous automotive systems vulnerabilities over the years that have raised awareness around the need for cybersecurity.

A recent example, says Dr. Dennis Kengo Oka, principal automotive security strategist, Synopsys Software Integrity Group, involves a set of vulnerabilities in the Tesla Model X keyless entry system that was discovered by Lennert Wouters at the University of Leuven and made public in November of 2020.

The steps of the Tesla hack are illustrated below with numbers indicating individual steps.

It’s important to note that the target vehicle is locked, and the target key fob is away from the vehicle. An attacker uses a pre-prepared attack device consisting of a modified body control module (BCM), a modified key fob, and a Raspberry Pi. Modifications include replacing the Secure Element (SE) chip with Python scripts running on the Raspberry Pi, emulating the SE. Let’s examine each step that an attacker would conduct to carry out the attack:

  • Approach the target vehicle, read the VIN through the windshield, and configure the emulated SE for the modified BCM in the attack device to use the target VIN.
  • Locate the target key fob and bring the attack device close to it. Connect over low frequency (LF) at a distance up to about 5 metres by pretending to be the target vehicle. The attacker uses an identifier derived from the VIN to force the previously paired target key fob to advertise as connectable over Bluetooth Low Energy (BLE).
  • Push a malicious firmware update over BLE from the Raspberry Pi to the target key fob to gain full control of the key fob. This update can be performed by using the over-the-air download service on the target key fob from up to 30 metres.
  • After the target key fob has been updated, the attack device reconnects over BLE. Since the key fob is running the malicious attacker-controlled firmware, which allows sending arbitrary application protocol data unit (APDU) commands to the SE in the target key fob, the attacker can extract a number of valid one-time unlock commands (e.g., unlock door) for the target vehicle from the SE in the key fob.
  • Approach the target vehicle and use the valid unlock commands to unlock the target vehicle. The unlock commands are sent over BLE from the Raspberry Pi to the target BCM.
  • Now the attacker has gained physical access to the interior of the vehicle and can physically connect the attack device to the in-vehicle network over the diagnostics port located below the central display. The attack device connects to the target BCM over controller area network (CAN).
  • The attack device instructs the target BCM to pair with the modified key fob. After passing a challenge-response authentication with the BCM to add the modified key fob, necessary credentials are stored in the emulated SE for the key fob.
  • Start the vehicle using the newly paired key fob on the attack device to successfully perform a challenge-response authentication using the previously stored credentials in the emulated key fob SE, and now the attacker is able to drive away with the target vehicle.

There are two main vulnerabilities/weaknesses permitting this attack.

Although signature verification is implemented on the key fob, a vulnerability allows the attacker to update the key fob over BLE with malicious firmware. While valid key fobs typically store signed certificates received from the back-end acquired during provision, these certificates aren’t verified by the vehicle BCM while pairing with the key fob.

The issues were responsibly disclosed to Tesla in August 2020 by security researchers, and Tesla released an over-the-air (OTA) patch to address them in November 2020. Note also that some assumptions have been made about the target system and type of weaknesses and vulnerabilities to facilitate discussion around security solutions since there is limited information publicly available.

The first issue of note is improper signature verification in the implementation on the key fob. Such implementation issues can often be found using static code analysis and software composition analysis (to identify known vulnerabilities), and fuzz testing (to detect unknown vulnerabilities).

Dr. Dennis Kengo Oka

The second issue is a missing certificate verification in the design of the pairing protocol between the BCM and key fob. Such design issues can often be identified through security design reviews. For this reason, it’s imperative to perform a proper threat analysis and risk assessment of the target system to identify high-risk areas, which helps define appropriate security requirements and assists in designing suitable security controls.

Developing 100% secure automotive systems isn’t realistic. There are ongoing activities to help automotive organisations improve cybersecurity, such as the development of ISO SAE 21434 and regulations such as UN regulation 155 cyber security. Automotive organisations need to consider and deploy appropriate security measures including capabilities for OTA updates to allow for timely patches of newly detected vulnerabilities.

The author is Dr. Dennis Kengo Oka, principal automotive security strategist at Synopsys Software Integrity Group.

Comment on this article below or via Twitter: @IoTNow_OR @jcIoTnow