 Hello everyone, my name is Leonard Waters and this talk is called My Other Car is Your Car and it's about compromising the Tesla Model X keyless entry system. Now in a modern day vehicle like the Tesla Model X, you usually have two ways of entering or opening the vehicle. The first method is remote keyless entry, so you press a button on the key fob. The key fob generates a rolling code or hoping code, the car verifies this code and then unlocks the doors. Massive entry is if you have the key fob in your pocket, you approach the car, the car sends a challenge to the key fob, the key fob computes a cryptographic response, sends it back to the vehicle and then the vehicle verifies the response. So the second scenario is used to passively open the car but also to start the car. Now if we take one of these key fobs and open it up, then we find the following printed circuit board inside of it. You can see it's quite complicated and it's quite a few components. So let's look at all of them individually. So the first thing we see is a Texas Instruments CC2541. It's a Bluetooth Low Energy Microcontroller. This microcontroller is paired with a Bluetooth Low Energy Range Extender. And then at the other side of the PCB, we have a maximum integrated low frequency transponder chip. So this transponder chip allows the key fob to receive signals on a 22 kHz frequency. Then on the left of the PCB, we have an accelerometer, which is likely being used to try and prevent relay attacks or to try and increase the battery life of the key fob. And then finally, we have an Infineon SLM97 Common Criteria Certified Secure Element. So the secure element underwent certification by Common Criteria, which means that the secure element has been certified to be secure against certain attacks. Now, as you can imagine, the secure element will be quite difficult for us to attack. But as it turns out, in the way the system is designed, we actually only have to attack the Bluetooth Low Energy Chip. Because once we compromise this chip, we can send arbitrary commands to the secure element. Now, to figure out how all of these components communicate with each other, I built a small breakout bar, basically, that allows me to connect the logic analyzer and see all of the communication between the different chips. So you could even use this key fob to actually open or unlock a car if the key fob is paired to it, and then see, basically, by connecting a logic analyzer, what all of the communication between these chips is. And in doing so, we can then learn how the device works. And then we can make a more detailed view of the first energy we had. So basically, in a remote keyless entry scenario, a user will first press a button. This button press is handled by the Bluetooth Low Energy Microcontroller that then sends a request token command to the secure element. The secure element computes a cryptographic token that is sent back to the microcontroller. And then it is transmitted over Bluetooth Low Energy as a broadcast packet to the car. The car verifies the token and then unlocks. In the passive keyless entry scenario, the car will first send a challenge over low frequency to this maximum integrated transponder chip that takes the challenge and sends it to the microcontroller over SPI. The microcontroller then again sends it to the secure element. The secure element performs some cryptographic operations, computes a response, and then the Bluetooth Low Energy Microcontroller sends it back to the car. Now here it's important to note that the only way to compute a valid response or a valid token and thus to unlock the car is to have the key that is stored in the secure element. And getting that key out will be quite difficult. But what's interesting here compared to other keyless entry systems is that we have this Bluetooth Low Energy Microcontroller. And with having this microcontroller and Bluetooth Low Energy, there is more attack service. As it turns out, if you take the battery out of this key fob and then put it back in or basically power cycle the key fob, then it will start advertising itself as a connectable Bluetooth Low Energy peripheral. And so you can connect to it with an app on your phone, for example. And then you can see all of the services and characteristics that are exposed on the device. So there's two of these services that are interesting for us. The first one being over air download, and that basically allows us to update the firmware on the key fob, wirelessly over Bluetooth. Secondly, there is an APDU interface, APDU stands for application protocol data unit. And those of you familiar with smart cards and secure elements know that these are basically commands that you can send to the secure elements. So presumably to this service, we can send commands to the secure elements. Now let's first take a look at how you communicate with a secure element. And in this case, actually, the secure element interface is quite similar to that of a smart card. So you may recognize this pinout, which is an example from a chip. For example, the kind that you would find in your banking card. And this chip is a secure element in the key fob. And it basically has the same sort of interface just in a different package. So what we did here is we basically built a PCB, took a secure element from the key fob, put it on the PCB, and then this PCB we can put in a smart card reader, and then basically communicate with a secure element from Python. Now to send commands or APDU commands to the secure elements, these commands usually exist out of at least five bytes. So we first have the command class byte, which basically indicates if this is a proprietary or standard command, then we have the command byte itself. Then there's two parameter bytes. And then finally, there's a byte that indicates the number of additional input bytes for this command. So for example, if you press a button on the key fob, then what will happen is the microcontroller will send this APDU command to the secure element. And as you can see, this command indicates that there's three additional input bytes. The secure element confirms that we can send these input bytes, and then we send these three input bytes. Now these input bytes in this case indicate the kind of action we want to perform. So do we want to unlock the doors? Do we want to lock them? Maybe you want to unlock the Falcon windows and so on. After seeing these three bytes, the secure element will compute the cryptographic response and then indicates to us that it is ready. We can then read the response back, which is 16 bytes, and then the secure element also indicates that everything was successful. Now if we go back to the Bluetooth Low Energy microcontroller and this Bluetooth Low Energy to APDU interface, then it is clear that basically this interface can be used to send these sorts of APDU commands to the secure element over Bluetooth. And this functionality is normally used during pairing. And of course, the engineers at Tesla realize that this can be a security issue. So certain commands such as the getUnlockToken that we discussed earlier are blocked from being used to this Bluetooth Low Energy interface. Otherwise, you could simply ask the keyfob for an UnlockToken and then unlock the car. Then the second interface that we discussed earlier is the OverAirDownloadService. And OverAirDownload is basically Texas Instruments implementation over the AirSoftware updates. And it basically allows you to update the firmware on the CC2541 microcontroller. Now the example implementation provided by Texas Instruments actually contained a few vulnerabilities. So one of our students at the university actually looked at this example implementation and identified two major issues. So the first one being that they use AS encounter mode to encrypt the firmware. But they had a bug that basically resulted in the counter being reset after four AS blocks. And you can see the results here on the bottom of the slide. So on the left, you can see basically the plain text firmware image. And then on the right, you can see the encrypted firmware image. And you can clearly see here at the bottom that there's too much structure for this to be properly encrypted. And as a result, you can actually decrypt this firmware image without knowledge of the key. And the second bug was that they used CBC Mac to provide authentication of the firmware image. But they used the non-constant time implementation of memcompare. So this implementation would also be vulnerable to a timing attack. Now Tesla didn't actually use any of these security features provided in the example implementation by TI. But they decided to use RSA signatures to verify the authenticity of the firmware. And this signature would then be verified by the secure element. This is, of course, a good choice. But as it turns out, the result provided by the secure element was simply being ignored. So the microcontroller would ask the secure element, is this a valid firmware image? Secure element would say, no, this firmware image is not valid. And then the microcontroller would still accept the firmware. We are not sure how this issue ended up in the production build of the Model X keyfob firmware. But we believe that maybe it was a leftover from development. So now what we want to do is we want to build a malicious firmware image that allows us to send arbitrary APDU commands to the secure element inside of the keyfob. So what we can do is we can build a custom firmware. And this would require us to become familiar with the TI tooling and software development kit, which would require some time. And we'd likely end up with a firmware image that doesn't have all the functionality that the original keyfob has. We could also take the original firmware and then statically reverse engineer it, try to find the block list, and then basically patch the firmware. However, for this specific platform, there isn't any good support. For example, Qidra supports the 8051 instruction set, but not the custom additions that were done to this platform. So in the end, what we decided to do was basically brute force the firmware modification process because this could be easily automated and then we could just leave it run for a few hours and not have to do any of these tedious tasks. So the idea is really quite simple. We assume that a block list is implemented using if statements or a case and that this will likely be compiled to conditional instructions, such as jump if not 0 or jump if 0. So then the idea is to basically replace an occurrence of the jump if not 0 instruction with a jump if 0 instruction. Then we flash this modified firmware image to the keyfob. We connect over Bluetooth and we try to send the request unlock token APDU command. If we receive a response, then we know that our command was successful and that we successfully patched the firmware. If not, then we simply continue the loop, patch the next instruction and try again. And eventually in a few hours of time, you have a modified firmware image that no longer has a block list. So now our plan of attack current looks something like this. We take the keyfob, we take out the battery, put it back in. We then connect to the keyfob and push our own malicious firmware image and this then allows us to send arbitrary APDU commands to the secure element. We can request a valid rolling code to this APDU interface and then use that rolling code to unlock the car. Now I think we all agree that step one in this plan of attack is not really that nice or cool because we would have to have physical access to the keyfob. So let's see if we can get rid of step one. And to do this, we will look at the body control module. So this is one of the ECUs that is located inside of the Model X and I noted some of the more interesting regions here. So most importantly for us is that there's the same secure element as in the keyfob is also in the body control module. And then we have this main processor, which is a free scale SPC 5.6 series that can communicate with other ECUs in the car through these IO and bus interfaces. It can also send low frequency commands to the keyfob using these LFT and SEVER ICs and then there's also, of course, antennas connected to these connectors. And then, of course, this BCM also needs to be able to communicate over Bluetooth low energy. Now what we figured out is that this body control module can actually send a wake up command over low frequency to the keyfob. And basically this allows a car to wake up keyfob so they have been paired with. And the low frequency command basically contains an identifier that is derived from the VIN number of the vehicle. And of course, it's important to realize that the VIN number is publicly readable and it's basically just readable from the windshield of the car. So what we can do is we can remove this secure element from the BCM because the secure element is actually the component that stores the VIN number. And then we emulate the VIN or the secure element better using this USB to serial converter and we basically trick this BCM into believing that it belongs to a different VIN number. So now if you go back to our plan of attack, we can first use our modified BCM to force our target keyfob to wake up. We then connect to the keyfob and push our malicious firmware. We can now request a valid unlock token from the secure element over Bluetooth low energy. And we can then use this rolling code to unlock the car. So now we have a fully remote attack that allows us to get inside of the car. But of course, it's more fun if we can also drive off with the car. And to see how we can achieve that, we looked at how Tesla pairs a new keyfob to the car. And in practice, if you go to the service center, they do this using the Tesla toolbox, which is basically a software tool that's used for servicing Model S and Model X vehicles. The tool is not publicly available, but as with many other items, they are available on the internet. And Tesla even unintentionally released a version of this tool recently. Basically, if you registered for a Chinese service account, you could download the software for free. Now, all of the interesting components of this tool are actually stored encrypted on disk. But as you can imagine, the tool itself has to decrypt these modules before it can use them. I'm not going to go into the details of how you decrypt these modules because other people have already done this before me. And I'm also not the first to use the toolbox software for security research. So in a normal scenario, we have a service technician with a laptop that's running the Tesla toolbox software. And as their service technician, we assume that they have valid toolbox credentials, which also allows the software to communicate with a backend hardware security module that is hosted by Tesla. Then there's a USB to con interface that connects to the diagnostic connector inside of the vehicle. And that basically allows the toolbox software to send APDU commands to the secure element in the body control module. On the other side, we have a USB to Bluetooth adapter that allows the toolbox software to send APDU commands to the secure element in the key fob. Now, to figure out how we can send commands to the secure element in the body control module, we actually enumerated UDS routines, basically. I don't have time to go into all of the details of this, but the idea is relatively straightforward. So we can look at the specifications of UDS and then try to find ways in which we can enumerate existing routines. So that's step one. And then step two is to enumerate the option record length. So this is basically additional data that you can provide to a routine start method. And then we start the routine with optional record data. So we assume here basically that to send an APDU command, you would have to start a routine and provide extra input data to the routine. So then basically what we did here is we have the ECU on a bench. And we have the logic analyzer connected to the secure element interface. Then through this USB to Khan adapter, we send these routine start commands. And then we look in the data of the logic analyzer, if our data sent over can actually is received at the input of the secure element. And if that's the case, then we know which routine can be used to communicate with the secure element. Then to actually reverse engineer the pairing protocol between the key fob and the car. We used not only the toolbox software, the toolbox software allowed us to basically understand the message format or the type of data exchanged between the two secure elements. But it didn't allow us to reverse engineer what the secure element itself was doing. And to do that, we basically interacted with two secure elements and made a guess for what the secure element was doing and verified it. And in this way, we were able to reverse engineer the entire pairing protocol. Which can be divided into two parts. So we first have a provisioning step, which is basically a set of steps that every brand new key fob would go through. As you can see in this protocol, only the back end HSM, the toolbox and the key fob are involved. So the car is not yet involved during these steps. Every key fob can store five RSA key pairs. And in this case, slot zero and slot one are reserved for Tesla specific certificates and public keys. Then basically the key fob will generate RSA key pairs for the three remaining slots. And now the idea is that these public keys will be sent to the back end HSM. The HSM will generate certificates for these public keys and these certificates are then stored back into the secure element of the key fob. So presumably here, the idea is that once we pair this key fob to the car, that the car would be able to verify these certificates and to verify that it's pairing to a legitimate key fob. However, if we then look at the actual pairing protocol where the car is now involved with the toolbox and the key fob, then we can see that these certificates are never being used. So the key fob is never sending the certificates to the secure element. And this basically allows us to skip all of these provisioning steps and make a fake Tesla key fob. I'm not going to go into all of the details of the pairing protocol itself, but you can always look at the diagram later in the slides. So I said that we would use a modified key fob to do this, and this is what our modified key fob looks like. So basically we have to replace the standard secure element so that we can skip all of these provisioning steps. So we could either try to find a matching component with a matching footprint and then program that to do all of these actions, but instead we replace the secure element using a USB to UART converter and we can then basically implement all of the secure element functionality in Python. So I chose to use the CP2102 USB to sale converter because it allows us to set an arbitrary ball trade and it has some extra GPI opens, which are useful in this case. So with that we have a complete plan of attack. We again use a modified BCM to wake up the target key fob. This can be done wirelessly. Then we connect to the key fob and push our malicious firmware again wirelessly. And this malicious firmware allows us to remove the block list on the APDU interface. We can now connect to the key fob and request a valid unlock token from the secure element. We use that token to unlock the car and gain physical access to the interior. We can then connect our tool to the diagnostic connector inside of the vehicle and pair our modified key fob to the car. And now we can use that key fob to drive off. We actually built a tool that allows us to carry out this for attack and it's battery powered and fits in the backpack. So basically we have a LiPo battery here that powers this Raspberry Pi. Raspberry Pi is basically the brains of the operation and controls all of the other components. Raspberry Pi has a can shield on top of it that has two interfaces. One interface is connected to the BCM on the back of our tool. And then the second interface will be connected to the diagnostic connector inside of the vehicle. Here you can again see the modified key fob which is being controlled from a Python script that's running on the Raspberry Pi. On the backside of our tool we have the modified body control module. Where again we have modified or removed the secure element and replaced it with a USB to sail converter. And in this way we can make this body control module believe that it belongs to a different car. Now after identifying these issues we also reported the issues to Tesla. So we reported the issues in August of 2020. They released a patch in November of 2020 in which they fixed the signature check issue in the firmware update of the key fob. And they awarded us with a 5000 dollar bounty. If you want to read more about this there's a wired article that has some nice information in it. And the full scientific paper will also be published in a few weeks. Now to end this presentation I want to show you a demonstration video of how we would actually conduct this attack in practice. So in this scenario we have someone parking their car in front of our university building. And maybe they're going to charge it and then go for a walk or have a bite to eat somewhere. And the idea here now is that we can using our tool approach the parked car and we can read the VIN number from the windshield. We enter this VIN number in our Python tool that then basically allows us to emulate the BCM. So we now have a BCM that believes it belongs to that same car. We can then use that BCM to wake up the key fob in the owner's pocket. And once it starts advertising as a connectable BLE peripheral, we connect to it and we start pushing our malicious firmware. The firmware update itself is performed over Bluetooth low energy and can thus be performed over a longer range. Once the device has been updated we can connect to it and request some valid one time, one time valid unlock commands. As these are rolling codes we also have to use them in the same way or in the same order as we receive them. So with these unlock commands we can then walk back to the car and send them to the car to unlock the doors. So we unlock the doors and then of course this is a Model X so we also have to open the Falcon wing doors. So in doing so we've now gained physical access to the interior of the vehicle. But with these one time valid unlock tokens we wouldn't be able to drive off. So to drive off we are now going to pair our modified key fob to the car. So we plug in our tool to the diagnostic connector which is located underneath the center display in the car. Then we can start the pairing process from our phone basically and within a few seconds our malicious key fob is now paired to the car. The car will send us a challenge and our key fob will compute the valid response to then start the vehicle. And of course once that is done we can simply drive off with the car. As we now have a key fob that's paired to the car we would also be able to restart the car as many times as we want. So it's not like a relay attack. Now to conclude this presentation I have some basically yearly reminders. Over the air updates can be both a blessing and a curse. So in this case it's the functionality basically that allowed us to compromise the key fob. But it's also the functionality that allowed Tesla to fix the issue. A secure element does not guarantee a secure system. And it's important to remember here that usually the attacker will try to bypass the cryptography and not penetrate it. Sheldon Cooper once said that everything is better with Bluetooth but I think it's important to remember that everything has more attack surface with Bluetooth. And then finally you have to remember that all embedded devices live in a hostile environment. So if you're going to rely on a general purpose microcontroller for security critical operations you're likely going to have bad time. So with that I want to end this presentation. You can watch the video again on this YouTube link or you can always contact me if you have questions. The full paper will soon be released online.