 Hi, my name is Leonard Wouters and in this recorded talk I will present our paper titled My other car is your car, compromising the Tesla Model X keyless entry system. I want to start this presentation by quickly recapping what a keyless entry system is exactly. In many modern vehicles there are two related but separate ways of unlocking the car using the key fob. Specifically in the Model X the car can be unlocked by the press of a button. This is often referred to as remote keyless entry. In this scenario the key fob transmits a rolling or hoping code to the vehicle, the vehicle verifies it and then unlocks the door if the code was valid. Noted in this scenario there is no communication from the car to the key fob. In contrast in the passive keyless entry scenario the car will transmit a challenge to the key fob and in turn the key fob computes a cryptographic response and sends it back to the car. The car verifies the response and unlocks the doors if the response was valid. During our initial exploration of the system we disassembled a Model X key fob to understand what components are being used. To our surprise we found the Texas Instruments CC2541 Bluetooth Low Energy Microcontroller which is paired with a Texas Instruments 2.4Ghz range extender. On the other side of the board we find the maximum integrated 22kHz transponder chip. This chip allows the key fob to receive low frequency messages coming from the car. On the left side of the board we find an analog devices accelerometer. This is likely being used to try and prevent relay attacks or to increase the battery life of the key fob. Finally there is an Infinion SLM97 common criteria certified secure element. This secure element is responsible for all of the critical cryptographic operations performed in this key fob. It also stores all of the cryptographic keys. As you can imagine compromising the secure element itself will be challenging. Nevertheless in this talk we will cover a practical attack that allows us to unlock and start a model X without having to compromise the secure element. Instead we are simply going to ask it to unlock the car for us. Interestingly the small battery powered device contains three hardware AES accelerators. For the remainder of the talk it is important to keep in mind that there are two radio frequency interfaces and that the secure element is responsible for storing cryptographic keys and performing cryptographic operations. This is our homemade Tesla Model X key fob development kit in which we soldered wires to most of the exposed test points and some of the exposed wires. We also added a CCD bugger that allows us to read and write the firmware stored in the Bluetooth Low Energy Microcontroller. By recording the signals present on these test points using a logic analyzer we can get a better understanding of how all of the different components interact with each other. So with the logic analyzer attached we can then press a button and figure out how the button press is handled by the device. Using this information we can then make a more detailed version of our first slide. In the remote keyless entry scenario the user will first press one of the buttons on the key fob. This button press is handled by the CC2541. This microcontroller will then send a request unlocked token APDU command to the secure element. The secure element will in turn compute a token and send it back to the CC2541. Finally, the token is transmitted to the car using a Bluetooth Low Energy Broadcast message. In the passive keyless entry scenario the car will send a challenge over the 22kHz Low Frequency Channel. This challenge is received and demodulated by the maximum integrated transpondership. The challenge is then forwarded to the CC2541 microcontroller over a serial peripheral interface bus. From there the challenge is sent to the secure element which will compute a response to the provider challenge. This response is then sent back to the car over Bluetooth Low Energy. Now that we have a basic understanding of how the device operates we can take a closer look at the Bluetooth Low Energy side of things. Like many other BLE devices the key fob behaves like a BLE peripheral. By power cycling the key fob we notice that the key fob advertises itself as a connectable BLE peripheral. At this point we can connect to the key fob using a variety of tools. On the right you can see a screenshot from the Light Blue smartphone app connected to the key fob. The key fob hosts a variety of services each including multiple characteristics. The Overair Download service is provided by Texas Instruments and allows to update the firmware on the key fob over the BLE interface. A second interesting service is related to application protocol data units or APD use. This service allows to send APDU commands to the secure element over Bluetooth Low Energy. Next we will have a look at these two services in more detail. As stated earlier the APDU service allows us to interact with the secure element through the Bluetooth Low Energy microcontroller. This functionality is used when a key fob is being paired to a car. One issue with such an interface is that someone could potentially request an unlocked token from the secure element. To prevent such an attack a block list is implemented on the BLE microcontroller. This block list prevents us from using among others the Get Unlocked Token APDU command. The Overair Download service allows us to update the CC2541 firmware over the BLE interface. As part of a master thesis at our university we recently investigated the example OAD implementation provided by Texas Instruments. The secure variant of this implementation uses AES encounter mode to encrypt the firmware and a CBC MAC tag to protect its authenticity. On the left you can see a grayscale plot of a plain text firmware image and on the right you can see the encrypted firmware image when encrypted using the example implementation. We found that the counter mode implementation had a bug resulting in the counter resetting every 4 AES blocks. As the firmware is padded to a fixed length it is straightforward to recover the key stream and decrypt the entire firmware image. We also found that message authentication tag was being verified using the standard Variable Time Mem Compare function. This could allow an attacker to craft a valid tag using a timing side channel. Both of these issues have been fixed in later versions of the Texas Instruments software development kit. Tesla modified the example implementation. We found that Tesla distributes the firmware in plain text and adds a SHA-1 hash and RSA signature to the firmware. During an overwrite download update the secure element will then compute a SHA-256 hash over the provided SHA-1 hash and verifies the RSA signature. However, we noticed that the firmware of the CC2541 would simply ignore the secure element's response. So even an unsigned firmware image would be accepted. Having established that the OAD service is vulnerable, we can try to build our own malicious update firmware. The goal of this malicious firmware is to remove the APDU block list, enabling us to send arbitrary APDU commands to the secure element. To achieve this, we have a few options. We can write a custom firmware image from scratch. However, this would require us to become familiar with the Texas Instruments Tooling and Software Development Kit. Unless we implement all of the keyfob's features, it would be rather evident when a keyfob has been updated. A second option would be to statically reverse engineer the existing firmware. While popular reverse engineering tools support the AT51 instruction set, they do not contain support for the customizations present in this particular chip. So finally, we decided that reverse engineering the firmware would be a time-consuming and tedious endeavor. The solution we came up with is a brute force-based firmware modification process that can be easily automated. The idea behind this approach is that a simple block list implementation will likely use conditional instructions, such as the jump if accumulator is not zero, or jump if accumulator is zero instructions. So to automatically modify the firmware, we simply replace an occurrence of jump if accumulator not zero with jump if accumulator is zero. We then flashed this modified firmware to the keyfob using the CCD burger on our homemade development kit. Afterwards, we connected the keyfob over Bluetooth Low Energy and tried to send a blocked APDU. If we receive a response, we know that we successfully modified the block list. Having identified the offset, at which an instruction had to be patched, we could then easily disassemble the surrounding instructions and remove the entire block list. So at this point, we have a malicious firmware image that can be used in an attack. So far, our plan of attack is to first reseat the keyfob battery. Then we can connect to the keyfob and perform an over-the-air download using our malicious firmware image. This firmware has been modified to allow all of the APDUs. We can now use the APDU service to request a valid rolling code or unlock token from the secure element. This rolling code can then be used to unlock the car. It is important to note here that this code can only be used to unlock the car and we cannot use it to start the car. Of course, we want to get rid of this first step in the attack plan. If we have physical access to the keyfob, we might as well just use it to unlock the car. Next we will have a look at the car side of the system to identify a way of waking up the keyfob remotely. This picture shows the Tesla Model X body control module. This is one of the ECUs located in the car. Among other things, the body control module is responsible for unlocking the doors and starting the vehicle. We can identify a few regions on this printed circuit board. We have a power distribution network, but we also have a region with components related to IO and bus interfaces. Some of these interfaces, such as the controller area network or CANBUS, allow this BCM to communicate with other parts in the vehicle. Next, we have a low frequency transceiver chip that is connected to five antennas located in different locations throughout the vehicle. Using this interface, the BCM can send commands or messages to the keyfob over the low frequency channel. There are also three Bluetooth low energy microcontrollers on this BCM, one for each antenna. Finally, marked in red, we have the main processor on this board, a free scale SPC56. This microcontroller is connected to an Infinion SLM97 secure element. As it turns out, the body control module can send a wake-up command over low frequency to the keyfob. This wake-up command then causes the keyfob to advertise itself as connectable over Bluetooth low energy. However, BCM is only capable of waking up a keyfob that has been paired to do the same car. As a keyfob will only act on a wake-up command if the wake-up command contains the correct car identifier. This car identifier is derived from the vehicle identification number or VIN, which is readable from the car's windshield. The VIN itself is stored in a secure element and read by the microcontroller. As the main microcontroller trusts the information coming from the secure element, we can also trick it into believing it belongs to a different car or VIN number. To do so, we removed the secure element from a BCM and replaced it with a USB to serial converter, allowing us to emulate the secure element behavior. Using this modified BCM, we can now force a target keyfob to wake up and advertise itself as connectable. In our new plan of attack, we can now first request a target keyfob to advertise itself as connectable using a modified BCM. As before, we can then connect to the keyfob and push our malicious firmware image to the keyfob. Afterwards, we can request the valid unlock token from the secure element through the BLE APDU service. This token, a rolling code, can then be used to unlock the car. Now, there is still one final missing piece. Unlocking the car is fun, but we want to be able to drive away with it. To achieve this, we had a look at how a new keyfob can be paired to the car. In normal circumstances, a Tesla service technician will use the Tesla toolbox to pair a new keyfob to the car. The toolbox is a tool developed by Tesla that is used to service Model S and Model X vehicles. The tool is not publicly available, but leaked versions do circulate on the internet. The tool was recently also unintentionally released by Tesla themselves. The toolbox consists out of modules that are stored encrypted on disk, but as you can imagine, the software itself has to decrypt these modules before they can be used. In a normal scenario, the Tesla toolbox software will run on a laptop. The toolbox software is able to reach out to a backend HSM if the user has valid service credentials. Using a leaked copy of the software does not give access to the HSM. Additionally, the laptop is connected to a USB-2-CAN interface, allowing the software to send commands to the body control module. This allows the toolbox software to send APDU commands to the secure element in the body control module. This interface was reverse engineered by enumerating the unified diagnostic service or UDS interface, and we will cover this in the next slide. The laptop is also connected to a USB-2-BLE adapter, allowing the toolbox software to send APDU commands to the secure element inside the keyfob. So in a way, the toolbox software and all of its interfaces allows the secure elements to communicate with each other. We enumerated the functionality of the body control module's unified diagnostics interface to figure out how to send APDU commands to the secure element. As the UDS interface is defined in an ISO standard, we use the information from that standard to our advantage. We first started by enumerating all of the routines offered by the service by sending a routine start command for each routine identifier and observing the response code. For each of the existing routines, we could then enumerate how many input bytes they expect. Afterwards, we would start the routine with the correct number of input bytes and use a logic analyzer to check if our data arrived at the secure element. In this way, we could determine how to send APDU commands to the secure element over UDS on CAN. Now that we can send APDU commands to both the keyfob and body control module, we still need to figure out how the actual pairing protocol works. The toolbox code reveals the overall structure of the protocol, but does not contain the details of what a secure element itself is doing exactly. To reverse-engineer the full protocol, we combined the information from the toolbox code with a gasoline-determined style reverse engineering approach. The pairing procedure is carried out in two steps. A new keyfob is first provisioned. Each of these secure elements can store five RSA key pairs. In this case, sold zero and one are reserved for Tesla-specific certificates. The secure element itself will generate RSA key pairs for the remaining slots. Finally, the HSM will sign the certificates for these slots, and these certificates are then stored in the secure element. Presumably, the idea here is that these certificates can be verified by the car. That way the car can verify that a legitimate keyfob is being paired. After a keyfob has been provisioned, it can be paired to the car. The full pairing protocol is provided on the slide and is explained in more detail in the paper. The main issue with this protocol, however, is that the certificates generated during the provisioning step are never sent to the car. The car can not distinguish between legitimate or fake keyfob. To abuse this vulnerability in the pairing protocol, we had to create a malicious keyfob. This keyfob needs to be able to skip the provisioning steps while also being able to perform the pairing protocol and the rest of the secure elements features. To achieve this, we could search for a matching footprint component and program it with all of the functionality. As we are building a simple proof concept, we decided to simply remove the secure element from a keyfob and replace it with a USB to serial converter, which shows the CP2102N USB to serial converter because it supports arbitrary bar traits and comes with a few extra GPIO pins. We now have a complete plan of attack. As before, we first wake up the target keyfob and push a malicious firmware update to this keyfob. We then request an unlock token from the secure element and use that to unlock the car. Now that we have physical access to the interior of the vehicle, we can also connect to the diagnostic port and pair our malicious keyfob to the car. This malicious keyfob now allows us to drive off. To demonstrate that this attack could be performed in the real world, we created a proof of concept device. The device is battery powered and easily fits in a backpack. A Raspberry Pi is used to control all of the components and allows us to control the device from a smartphone. A dual interface scan shield allows us to connect one interface to the body control module at the back of this device and one to the diagnostic connector in the vehicle. The malicious keyfob is controlled by the Raspberry Pi. This is the backside of the device showing the modified body control module in which a secure element was replaced by a USB to serial converter. The functionality of a secure element is implemented in Python and controlled by the Raspberry Pi. We created a short video to demonstrate how we would conduct such an attack in practice. So in this case, we have someone parking their Tesla Model X in front of our university building. Probably not their best decision ever. Now we can use our compact tool to approach the vehicle. From the vehicle's windshield, we can read off the VIN number and enter it into our script. At this point, we have a body control module that believes it belongs to that vehicle. And this body control module can now be used to wake up the target's keyfob. Once the keyfob has been woken up, we can connect to it and then start pushing our new malicious firmware over Bluetooth Low Energy. As this is done over Bluetooth Low Energy, we can also do this part of the attack over a longer distance. Once the update has been completed, we can request one-time valid unlock commands from the secure element. It's important here that these are one-time valid and our rolling codes, so they have to be used in the same order as we receive them from the secure element. Having acquired these one-time valid codes, we can go back to the car and unlock it. And as this is a Model X, of course, we also have to open the Falcon wing doors. So at this point, we have gained physical access to the vehicle, which means we can get inside. And inside of the vehicle, we can connect our device to the diagnostic connector. This connector is available underneath the center display in the car. So we connect our device to this connector and can then use our tool to pair the malicious keyfob to this car. This takes only a few seconds. And at this point, we have a keyfob that the car thinks is legitimate. And now we can use that keyfob to drive off. So we emulate the normal keyfob, the car will send us a challenge, we compute a valid response, and then we can drive off with the car. And it's important to note here that this is not a relay attack, so we can keep on using this malicious keyfob to start the car and drive off with it. Back in August of 2020, we reported these findings to Tesla. Tesla released a patch a few months later that fixed the keyfob firmware update vulnerability. Tesla also wireless with a $5,000 bounty as part of their bug bounty program. Even though Tesla fixed the initial vector of our attack, there is still some remaining attack surface. Getting a code execution on the CC2541 is sufficient to recreate our attack. This can potentially be achieved using a chosen prefix SHA-1 collision or by finding a logical or memory corruption type vulnerability. Furthermore, brief physical access to the vehicle allows to pair malicious keyfob to the car. This can occur in multiple scenarios. Another potential avenue for attack is the CC2541 in the body control module. If an attacker can get code execution on these chips, they may be able to achieve arbitrary vehicle unlock. The biggest challenge for such an attack would likely be compromising the main processor from the CC2541 over SPI. Over-the-air updates can be a blessing and a curse. In this case, Tesla was able to resolve an issue in the over-air download service using over-air download. Unsigned and other maliciously formed updates should definitely be part of the test cases before pushing out a new firmware image. Remember that cryptography is typically bypassed and not penetrated. A secure element can be secure, but maybe the device interfacing with it is not. This fundamental weakness in this system's design is also present in other devices. Even though everything is better with Bluetooth, it is also important to remember that everything has more attack surface with Bluetooth. With that, I want to end this talk. You can find all of the details in our paper and you can watch the Proof Concept video again. Or you can reach out to me if you have any questions.