 Cool, I think I'll get started. My name is Leonard Waters. I'm here to present to you an attack we did on a Tesla Model S. And the goal of our research was to figure out how the passive keels entry system in the Tesla Model S works and to see if there's any vulnerabilities we could exploit. So in the way a passive keels entry and start system works is you approach the vehicle with the keyfob in your pocket and it automatically unlocks and starts. So what's actually going on in the back is the car sends a challenge to the keyfob. The keyfob computes a cryptographic response and sends it back to the car. If the cryptographic response is correct, the car will unlock and start. Now if we take one of these keyfobs and we open it up, this is what it looks like. So this is the PCB from the backside. There's not much going on here. You can see a UHF antenna, a low frequency antenna and an RF transmitter chip. The front side is a bit more interesting. So you can see that there's one interesting chip here. This is the Texas Instruments TMS37F128. Now if you take an X-ray of this chip, you can see that there's actually two dies or two distinct chips inside of this one package. So there's an MSP430 microcontroller. This is a general purpose microcontroller which can communicate with a transponder. So this is a TMS37126 and this transponder is actually the part that stores all of the cryptographic material and it performs all of the cryptographic operations. The microcontroller can talk to the transponder using an SPI interface. Now usually you would look up the datasheet for one of these chips to figure out what is going on. In this case to get a full datasheet, you have to sign NDAs, which is of course something we don't like to do. Now the things you can find online are like some basics. So this chip supports an 80 bit DSD80 security authentication co-processor, whatever that may be. And then it uses a five byte challenge and three byte response algorithm. And it also supports mutual authentication. So let's get started and let's buy some of these ICs. So I went to Digikey or Farnel, but couldn't find any of them. So again, you have to sign NDAs even to buy these chips. Luckily at my research group, there's a lot of international colleagues. I also have some Chinese colleagues and that makes it easier to get this stuff. So we went in Taobao, ordered some of these chips and once we got them, we noticed that they use a very uncommon package type. So we designed our own breakout ward to get started. Now the chip we acquired is the TMS37126. So it's only the transponder without the included microcontroller. So as I mentioned, you need to sign NDAs to get the datasheets. There is some public information, but the public information that is out there is very inconsistent. So for this one chip, you can easily find two distinct pinouts, which makes it quite annoying when you want to connect to them. My initial goal was to connect an Arduino to this chip so I could talk SPI with it and try to figure out what was going on. So in this case, the Arduino is the SPI master and the transponder is the SPI slave. When you connect all of this up on a breadboard, it looks somewhat like this. So SPI usually has three data lines. We have a clock line, a data line for data going from the slave to the master and the other way around. In this case, Texas Instruments decided to add a fourth line, which is called the busy line. As you can imagine, this line is used by the slave, so in this case, the transponder to indicate to the master when it is ready to receive the next byte of data. You can also see in this diagram that an SPI packet, in this case, usually starts with a length byte and this byte indicates how many bytes will follow in this packet. The second byte is the command you want to execute and then there might be one or more data bytes. You can also get a reply back from the transponder, including some data. Now, as we didn't have the data sheets, we had to figure out ourselves what available SPI commands there are. And it turns out that this extra SPI busy line is very convenient for this because it will throw an error when there's something wrong. So if you provide it with a command that does not exist, it will throw an error by holding this line low or high for an extended period of time. Now we made two observations. When the command value is incorrect, it throws an error, but if you set the length byte to FF, it will throw an error after the correct number of bytes was received. So you can simply fix the length byte to FF and then enumerate all of the command bytes to figure out what all of the correct lengths and commands are. So in that way, we uncovered some commands that we thought were interesting. So as you can see, we found two commands that perform the dsd40 cipher. I will give some more information on that cipher later on. And two commands that perform another unknown cipher. Now, this unknown cipher also works on 40-bit keys and we were expecting to find an 80-bit cipher. So I made the assumption that maybe the 80-bit cipher is a combination of two of these 40-bit ciphers. Usually combining two 40-bit ciphers into an 80-bit cipher results in interesting problems. So I set out to reverse engineer the unknown cipher and we did this by providing an input and observing the output and then making assumptions based on dsd40, which we knew how it worked. So this means that I spent about a month trying to black box reverse engineer a cipher which in the end wasn't used. We also found two commands that allow you to set a 40-bit key. So no 80-bit keys, only 40-bit keys. At this point, I finally got my hands on an actual test level as key fob. And as you can see, there are some easily available debug pads and I was able to connect a JTEC programmer and figured out that the JTEC fuse wasn't blown. So this means we can dump the program memory on the microcontroller, throw it into this assembler and start looking at the assembly code. So for the MSP430, the two things to do are first look at the interrupt vector table. This is stored at the end of flash and it basically teaches you what code will be run after an interrupt occurs. So in the case of a key fob, for example, which code is run when you press a button on it? And this helps you narrow down where to look in the assembly. Secondly, references to special function registers are interesting and especially in this case because we're trying to figure out which SPI commands the Tesla model S key fob is using. So I searched for the function which is doing the SPI communication basically. Now we went on to dynamic analysis. So setting breakpoints in the microcontroller at the address where the SPI function starts basically. Then you would try to unlock the car. When the breakpoint is triggered, you dump the memory to see which data was sent and received over SPI. And by doing this a few times, well, just in the normal way as you would unlock the car normally, we figured out that the only comment that you're using was 86, which you earlier figured out was DST 40. Now what is DST 40? DST 40 is a Cypher introduced back in 2000 by Texas Instruments. It uses a 40 bit key, which I guess everyone knows is too short by today's standards. The Cypher itself was first reverse engineered back in 2005. And back then it was used mainly in the mobilizers and the Exxon mobile speed pass payment system. This is a schematic overview of how the Cypher works. So at the bottom you have a 40 bit key register. At the top you have a 40 bit challenge register. And then there are some lookup tables in the middle. These lookup tables produce two bits of output. This round is executed 200 times. And the two output bits are shifted into the challenge register every round. After running the Cypher for 200 rounds, the 24 least significant bits of the challenge register are returned as the response. So the important thing to remember here is that we have a 40 bit key, a 40 bit challenge, and the response is actually shorter than the challenge. And this is important for the summer and next in the presentation. Okay, so we know that the key fob is using an old outdated Cypher, but we still have to figure out how to talk to the vehicle and how to receive messages from the key fob. Now if you look at one of these key fobs, you can observe two distinct systems. So there's a remote keyless entry system. And this is a system where you press a button on the key fob and then the car unlocks. And this is one way communication going from the key fob to the vehicle. Secondly, there's passive keyless entry and start. So this is two way communication where you approach the vehicle and it automatically unlocks. We will start by looking at the one way communication. So the remote keyless entry because these packets are easier to receive and it's easier to understand how everything works. So in order to receive messages from such a key fob, you need to have a few physical layer parameters like the operating frequency, the modulation, and the symbol rate. These are relatively easy to determine. Then what you do is once you can receive one message, you just receive a few. So you press the button a few times and you look at which parts of the message change. And in that way, you can understand what is going on. So in this case, there's one byte for the command and the command is basically do you want to lock or unlock the vehicle? Then there's a three byte response which is a dst40 response and there's a two byte counter. So the way it works is the key fob stores a 40 bit counter. Every time you press the button, the counter gets incremented and this counter is fed as a challenge to dst40 and then the response is computed. The reason they send the long part of the counter is to prevent desynchronization between key fob and car. So if your kid presses the button too many times, you still want to be able to unlock your vehicle. So I actually made a challenge for the capture the flag in the car hacking village which is based on a real Tesla Model S key fob. So what I did is I took one of the key fobs, I removed one of the buttons and I connected an Arduino to it. And the Arduino will simulate the button press every 15 seconds. Now to have a challenge, it's nice if you can have a flag which is fixed. So what I did is I reset the key fob right after it transmits so that the counter is not updated. So in this way, the packet is fixed and you can have a fixed flag. If you're having troubles with the challenge and you want some tips, you can come and find me after the talk or you can look at the talk rapid radio reversing by Michael Osborne. Now there should be short video of a small proof concept and we can show that you can unlock the doors. We can open the trunk and we can also open the trunk but the video is not working. Opening a vehicle is cool but it's even cooler if you can drive off with it. And to do that, you have to understand the passive keyless entry part. As I said before, there's two way communication. So low frequency going from the vehicle to the key fob and high frequency for data going from the key fob to the car. And this, the high frequency part is almost the same as the remote keyless entry scenario. For the low frequency part, I used the Poxmark 3 because it supports the operating frequency. But it turns out that the modulation is not supported in the Poxmark. So I had to modify the heart of the Poxmark. I had to write my own verilog code for the FPGA and I had to write my own microcontroller code. So the signals look kind of like this. So on top, you have the signal received by the antenna of the Poxmark. Then it's routed to an amplification stage. Then there's an analog P-detect circuit and then after the analog P-detect circuit, the FPGA will output a digital signal which can then be interpreted by the microcontroller. Now receiving these LF signals was kind of a hassle. So I had to spend a few of my weekends like this in the car and around the car. So basically what I did was I taped the receiving antenna of the Poxmark very close to the transmitting antennas of the car and that made it easier. So in a Tesla Model S, there's antennas at the rearview mirrors. There's one in the center cup holder. There's one at the trunk and there's one in the middle of the windshield. So at this point, we can receive ultra high-frequency signals, we can receive low-frequency signals, so we can build a protocol analyzer. So I have a simple Python script that controls both the Arctic One and the Poxmark and it basically gives me a trace of all of the communication between the keyfob and the car. So again, what you do is you do the same. You unlock the car a few times while you have your script running and you look at the output. And then by seeing which parts change, you can kind of guess what the protocol looks like. So I figured out that the car sends a message twice a second and it's just pulling to see if a keyfob is close. And this wake message contains a car identifier which the keyfob is looking for. Now, if the keyfob is close, it will reply. And this reply is basically the same message as the wake command, but it's an obfuscated version. I'm not sure why the obfuscation is there because if you receive messages from two vehicles, you can easily figure it out. It's basically a combination of some byte swaps and bit shifts. So when the keyfob replies, the car will send a random challenge. The keyfob computes the response and if the response was correct, the car unlocks. Now, as you can see here, you need to send the car identifier along with your challenge to the keyfob because otherwise it won't reply. Now, one scenario we're thinking about is could we steal a car without ever seeing the keyfob? Like, could we just stand next to it, unlock it and drive off? And it turns out it is possible, but it will take you about 97 days. So it's not really a practical attack. So we wanted to also have a practical attack, of course. And to get a practical attack, the thing you need to do is to recover the 40-bit key as fast as possible. So to recapulate, DSD40 uses a 40-bit challenge, a 40-bit key, but the output is only 24 bits. So it's kind of like a compression function. And this means that you need at least two challenge response pairs in order to recover the 40-bit key. What we did was to make a time memory trade-off table and the general idea is that we fixed one challenge, so we chose one. And then for every possible key, we recorded which response it produced. So because the response is shorter than a challenge, there will be multiple keys that produce the same response. We grouped all of the keys that produce the same response into one file. So we have a 5.4-terabyte lookup table, which has two to the 24 files, so one file for each response, and each of these files contains about two to the 16 keys. So once you have this table, recovering the key from a key fob is quite easy. You first have to get the two-byte car identifier, which you can do by brute force or sniffing it from the vehicle. Then you send the challenge that you use to make your table. You record the response and use the value of this response to recover, to take the file from your lookup table. And at that point, the key space is only two to the 16. So then you send a second random challenge to the key fob, record the response, and you test the remaining two to the 16 keys. Testing these two to the 16 keys takes two seconds on a Raspberry Pi. So we built this device. I have it here with me. If anyone wants to take a look at it later, just come and find me. No. So it basically contains the Proxima 3 and your stick one. Then a Raspberry Pi, which is basically the brains of the operation, and a USB power bank. So the way I use this is I make a hotspot on my phone. The Raspberry Pi automatically connects to it. I SSH into the Raspberry Pi, and I can control everything I want. And using this connection, the Raspberry Pi can also fetch files from a lookup table. Now, after we built this proof of concept attack, we've caused also notified Tesla. And then after notifying them, we realized that Tesla didn't build the system themselves, so they bought it. And they bought it from a company called Petron, which is based in the UK. And then looking at FCC documentation, we figured out that they built similar systems using the same Texas Instruments chip from McLaren, Karma, and Triumph. I don't have a McLaren. This is Vegas, so if anyone has one, let me know. So we contacted Tesla, and then they worked on fixing the key fob, so they made a new version of this key fob. And all vehicles produced from June 2018 onwards are using this newer version of the key fob. Existing customers can also request a new version of the key fob. They also did some over-the-air software objects that make the attack harder to execute. So they have a pin-to-drive feature, which is basically a second factor of authentication, so you have to enter a pin each time you try and start the vehicle. And the second option is to disable passive keyless entry. None of these features are enabled by default, so if you have one of these vehicles, you should enable them. I do want to point out that these features make it more difficult for me to steal your car, but they don't prevent me from doing it. So if you disable passive keyless entry, this is actually a nice feature, and I think you should enable it because it will stop the more common relay attack. But in order to start the vehicle, they still have to use passive keyless entry. There's no other way. Also, you might disable passive keyless entry on the car side, but the key fob will still reply to messages sent to it. The pin-to-drive feature is also nice, but again, once I'm inside your vehicle, there's other ways to start it and drive off. So another mitigation I came up with, and I did on one of the key fobs we have is, I basically added another button that allows me to disable passive entry on the key fob side. So this makes it impossible to clone the key fob. Now, Tesla was pretty cool about working with us to fix the issues, and at some point they even drove over at Tesla to our university, and we had to show that the attack actually worked. We also tried contacting some of the other probably affected companies. Karma and Triumph didn't really engage with us, they didn't really reply. McLaren did eventually reply, but when we said that we wouldn't remove their name from our paper, they weren't very interested in talking to us anymore. They did release a public statement online, which is quite funny. So the statement was on that URL, they removed it from their website, but I indexed it on the way back machine so you can still find it. I'll point out some interesting facts from the statement. So it starts by, we have been alerted, which is nice because they acknowledge that we contacted them, so we're off the hook. And then they continue by saying the relay attack, and we didn't do any relay attack, so I'm not sure what they're talking about. And then they try to explain what a relay attack is, and they say, if you leave your key close to the vehicle, it could be scammed. Now, relay attack doesn't work that way at all. If you leave your key fob close to your car, I'm gonna get in, I'm gonna drive off. I don't care about the relay part. So they continue, and they say the second attack includes, it takes about 100 days, and it requires a skilled attacker and skilled assembly and use. So it's kind of fluttered because it means that they read the paper we sent them. And then they continue reading, and they again explain how this attack work. And they say that for this attack, you have to be close to the key fob. Now, the attack is called a car-only attack. So I never have to be close to the key fob. This is a little section from the paper. So the car-only attack is a little subsection in the paper because it's not really a practical attack. And the second sentence basically says, without ever being in proximity of the key fob. Now, if you own a McLaren, there's no need to worry. McLaren takes the security of all their vehicles very seriously. So after this research, we can, of course, draw some conclusions. I think everyone here knows, but don't use proprietary cryptography. And if you ship manufacturer, the secrecy of data sheets is simply annoying and it doesn't really stop any attacker. It just makes it more difficult for legitimate researchers to find vulnerabilities and fix them. And if you're a car manufacturer, just buying stuff from a tier one or tier two supplier, it's maybe not the best idea. Maybe you should work with them and try to figure out what you're actually buying from them. And if you're making a product that has a microcontroller with firmware in it, don't rely on the secrecy of the firmware for security. There is always a way to get the firmware out, but that also doesn't mean that it should make it easy to get the firmware out. Now, there's a few other issues we've seen with similar systems. So Flavio Garcia, for example, he showed that Volkswagen was using only seven keys for all of their remote-less entry systems. So this includes Audi, Skoda, I think, and all of the other Volkswagen brands. And then of course, if you're one of the designers of such systems, maybe read the papers that people have published about this kind of stuff so that you know what kind of attacks are out there. But then most importantly, this is a tweet from one of my colleagues and Tesla got a lot of heat for using only 40-bit keys, but at least they did the effort of fixing it and they replied to us when we emailed them. And this cannot be said for the other manufacturers. Okay, so then I have a video we made to show how the attack works, if I can. So I will just talk to the video to explain again how the attack works, just to recapitulate. So it's actually quite easy to find these cars if you want to steal them. They all have to charge and they all do it in the same location. So what you do is you go to a supercharger, you hide there and you wait for someone to charge their car. Now, what most people do is it takes like 30 or 45 minutes to charge their vehicle. So they'll take a walk or they'll go to a nearby coffee shop so it's also easy to find your target. Now as an attacker, we need the car identifier and the easiest way to get it is to just sniff it from the vehicle. So you walk up to the vehicle and you just receive it basically. So the output on top, the terminal output is recorded from my phone. Then you walk to your target, you send your chosen challenge and your random challenge. You record the responses, you download the candidate key file, you boot force the remaining keys and in about five seconds, you have a perfect copy of the key fob. You walk back to the car, you unlock it, don't forget to unplug it. The protocol is the same for unlocking and starting so once you can unlock it, you can also start the vehicle. You start it and you drive off.