By: Dr Dennis Kengo Oka, Principal Automotive Security Strategist, Synopsys Software Integrity Group
With increased connectivity capabilities and larger and more complex software in automotive systems, modern vehicles are becoming more susceptible to cyber security attacks. Over the years, security researchers identified a number of vulnerabilities in automotive systems that have raised awareness about the need for automotive cyber security. One example that was made public in November 2020 was a set of vulnerabilities in the Tesla Model X keyless entry system discovered by Lennert Wouters at the University of Leuven in Belgium.
Attack steps in the key fob hack
The steps of the Tesla Model X keyless entry system hack are illustrated in Figure 1. The numbers in the figure indicate the individual steps. Please note that the target vehicle is locked and the target key fob is away from the vehicle.
“Figure 1. The attack steps involving the attack device, target key fob, and target vehicle.”
The 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 that emulate the SE.
- The attacker approaches the target vehicle, reads the VIN through the windshield, and configures the emulated SE for the modified BCM in the attack device to use the target VIN.
- The attacker locates the target key fob and brings the attack device close to it and connects over low frequency (LF) at a distance up to about 5 meters 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).
- The attacker pushes a malicious firmware update over BLE from the Raspberry Pi to the target key fob in order 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 a distance of up to 30 meters.
- 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 is able to extract a number of valid one-time unlock commands (e.g., unlock door, trunk, etc.) for the target vehicle from the SE in the key fob.
- The attacker approaches the target vehicle and uses the valid unlock commands to unlock the target vehicle. The unlock commands are sent over BLE from the Raspberry Pi to the target BCM.
- The attacker gains 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, the necessary credentials are stored in the emulated SE for the key fob.
- The attacker starts 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 is able to drive away with the target vehicle.
Vulnerabilities/weaknesses that lead to the key fob hack
There are two main vulnerabilities/ weaknesses that allow this attack. These issues are summarised in Table 1.
“Table 1. Summary of vulnerabilities/weaknesses”
Although signature verification is implemented on the key fob, a vulnerability allows the attacker to update the key fob over BLE with malicious firmware. Moreover, although valid key fobs typically store signed certificates received from the back end and acquired during provision, these certificates are not verified by the vehicle BCM while pairing with the key fob.
It’s important to note that 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.
Since there is limited information publicly available, please note also that some assumptions have been made about the target systems and type of weaknesses/vulnerabilities in order to facilitate this discussion on security solutions.
Embrace security measures in the automotive industry
There are already multiple ongoing activities in the automotive industry to help improve cyber security, such as the development of a new cyber security engineering standard called ISO SAE 214342 and regulations such as UN regulation 155 cyber security. There are several potential approaches for discovering and addressing the type of issues just described. Our focus here is not on describing a specific technical security solution to address a particular vulnerability, but rather on providing a broader discussion to emphasise the approaches and security activities that automotive organisations should engage in to help improve security and reduce the risks of vulnerabilities and weaknesses in the final product before release.
Address implementation and design issues with application security testing
The first issue is the improper signature verification in the implementation on the key fob. These types of implementation issues can often be found using static code analysis, software composition analysis (to identify known vulnerabilities), and fuzz testing (to detect unknown vulnerabilities). Additionally, it may be possible to detect these types of issues during penetration testing, focusing on high-risk areas such as security-related functions and firmware updates.
The second issue is a missing certificate verification in the design of the pairing protocol between the BCM and the key fob. These type of design issues can often be identified through security design reviews. Moreover, 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. Additionally, it may be possible to detect these types of issues during penetration testing, focusing on high-risk areas such as security-related functions and pairing functions.
The importance of proactive patch management
Developing 100% secure automotive systems is not realistic, so automotive organisations need to consider and deploy appropriate measures for enabling OTA updates to allow for timely patches of newly detected vulnerabilities. Moreover, this example also highlights the need for automotive organisations to establish internal processes and workflows to monitor, gather, and process vulnerability information, such as what is provided by security researchers, in order to respond accordingly.
