Analysis of an attack on automotive keyless entry systems

The attacker uses a preprepared 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.

1. 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.
2. 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).
3. 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.
4. 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.
5. 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.
6. 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).
7. 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. 
8. 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.

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.

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 emphasize the approaches and security activities that automotive organizations should engage in to help improve security and reduce the risks of vulnerabilities and weaknesses in the final product before release.