 is called Fast, Here's an insecure passive keyless entry and start systems in modern supercars and it will be presented by Leonard Wouter's and it's joint work with Edward Marin, Tomer Ashur, Benedikt Geerleys and Bart Preneu. Okay, thank you for the introduction. Some of you might have seen this talk before but still pay attention because at the end there's a small surprise. So the goal of this research was to figure out how secure a modern-day passive keyless entry and start system is. Now the way you would use one of these systems is you have the key fob in your pocket, you approach the car and it automatically unlocks. So when you're close to the vehicle it sends a challenge to your key fob, the key fob computes a cryptographic response and sends it back to the car. If the response is correct the car unlocks and the same procedure is repeated to start the vehicle. Now if we take a model S key fob and we open it up, this is the backside of the PCB. There's not that many interesting parts so there's a low frequency antenna, a UHF antenna and a transmitter chip. The front is a bit more interesting because you can see that there's this one black package that's staring at you and in this case that is a Texas Instruments TMS37F128. Now if you take an X-ray of this package you can actually see that there's two dies inside or two distinct chips. So one of them is the TMS37126 transponder which in this case will perform all of the cryptographic operations and it stores the cryptographic key. Secondly there's an MSP430 microcontroller which is a simple general purpose microcontroller that runs all of the application level code. The general purpose microcontroller can interact with the transponder over a SPI interface. Now usually when you do a project like this you want to get access to some of these chips but in this case that's the first hurdle you have to overcome because Texas Instruments doesn't sell these chips to you unless you want to get a large quantity and unless you sign NDAs. Now luckily Cosmic is a very international research group and I have a lot of international colleagues so in this case my Chinese colleagues help me to get these chips from Taobao. Once you get the chips you notice that they use a very uncommon package type so we started off by designing our own breakout board which makes it easier to connect to it. In this case the chip is only the transponder so without the integrated microcontroller. Again the same issue applies for the datasheets you can't get them without signing NDAs and as researchers we of course don't like signing NDAs. There is some public information but the information that is out there is very inconsistent so you can easily find multiple pinouts for the same chip which makes it very annoying if you're trying to connect to it. My initial goal was to connect it to an Arduino so I could send SPI commands to it and see what the functionality of the chip is basically. So once you figure out how to connect it on a breadboard it looks somewhat like this and as you can see we have an Arduino on the left and it communicates with SPI to the transponder. Usually SPI looks like this so you have a clock line, you have a data line for data going from the master to the slave and a data line for data going from the slave to the master. In this case the Arduino will be the master and the transponder is a slave. Texas instruments decided to add a fourth line which is which they call the busy line and as you can imagine it's used by the transponder to indicate to the master when it is ready to receive the next byte of data. Now as we don't have a datasheet we have to figure out ourselves which SPI commands exist but in this slide you can also see the general structure of what one of these packets looks like so they always start with a length byte which basically indicates how many bytes will follow this byte. Then there's a command byte and one or more data bytes. The transponder can also respond with some more data. So we figured out that this busy line is also being used to throw errors so the transponder will hold this line high or low for an extended period of time if an error occurs. So for example if the command value is incorrect or if the length value is incorrect. And as it turns out you can use these two observations to automatically recover all of the available commands and the number of bytes of input you have to provide for this command. So in this way we figured out that these commands are available on a chip and these are the ones we thought were interesting. So there's two commands that perform DST 40 which is an old 40-bit cipher. I'll talk more about that one a bit later on. Then there's also an unknown DST function which also uses a 40-bit key but produces a different output to a given input. Now when I started this project I was expecting to find an 80-bit cipher so I made the assumption that maybe they combine two 40-bit ciphers in the hope of getting an 80-bit secure one. So I reverse engineered this cipher by writing inputs to it and observing the output making assumptions on what the internal structure is doing because we know how DST 40 works and verifying these assumptions and until we reverse engineered the cipher. Now later on I figured out they weren't actually using this so I spent one month of my time for no reason. So this is again what the keyfob looks like and they have some easily accessible debug pads. And as it turns out the JTAG views of the MSP430 microcontroller is not blown so you can dim the program memory and open it in a disassembler. In this case we used binary ninja with an MSP430 plugin and we start off by doing what is called static analysis so we try to identify pieces of code that we think are interesting. And in the case of an MSP430 and also for most other microcontrollers what you want to do first is look at the interrupt vector table and in this case it starts at the end of the flash and it basically tells you which pieces of code are being run when an interrupt occurs. So in the case of a keyfob which code is run when you press a button on the keyfob. Secondly special function registers are very interesting and in this case the SPI transmit and receive buffers because we're interested to learn which SPI commands are being used in this keyfob. So what we basically do is we identify the interesting code and we know down the addresses and then we can go over to dynamic analysis in which we set breakpoints on the microcontroller and then use the keyfob as you do otherwise. So we set a breakpoint at the start of the SPI routine. We then try to unlock the vehicle and when the breakpoint triggers we can dump the memory. In this way we can see which data is being sent and received over the SPI interface. Now after doing this a few times with a real car we figured out that we're only using command 86 which we had earlier discovered is DST 40. So what is DST 40? DST 40 was introduced back in 2000 by Texas Instruments. It uses a 40 bit key and it was reverse engineered for the first time in 2005. Back then it was mainly used for immobilization systems in vehicles. It was also used in a payment system. This is what the cipher looks like. So we have a 40 bit key register at the bottom in Alphazard configuration. At the top there is a 40 bit challenge register and every round two bits of output get produced that get clocked back into the challenge register. The entire cipher is run for 200 rounds. Then after these 200 rounds the 24 least significant bits which are marked in red on the slide are returned as the response. The only thing you have to remember from this slide is that there's a 40 bit key, a 40 bit challenge and then a 24 bit response. So the response is shorter than the input. So we know that the key fob is using an old cipher which we can probably break but we still have to figure out how the key fob and the car are communicating with each other. Now most modern day key fobs there's actually two distinct systems that you can distinguish. There's a remote keyless entry system which you use when you press a button on the key fob and in this case there's one way communication from the key fob to the car. We also reverse the remote keyless entry part which is described in the paper but in the interest of time I'm going to skip that part. Because the passive keyless entry and start system is more interesting because it also allows you to drive off with the vehicle. In this case there's two way communication. So there will be ultra high frequency communication from the key fob to the vehicle. These signals are rather easy to receive because there's a lot of nice tools out there that you can use. In this case I use the yardstick one. For low frequency the story is a bit different as the tooling is not as well developed. But in this case we decided to use a poxmark tree. And because the modulation used by the vehicle is not actually implemented in the poxmark tree we had to write our own Vagaloc code in the FPGA, C code on the micro controller and I modified the hardware to boost the receiver range. This is what the signals look like. So the top signal is what the antenna of the poxmark actually receives. Then the signal is routed to an amplification stage. Then there's an analog peak detect circuit and then the FPGA will output the bottom signal. Implementing this was a bit of a hassle so I had to spend a few of my weekends like this in and around the vehicle. And basically the idea here is to have the antenna as close to the transmitting antennas of the car. So there's a transmitting antenna in the center cup holder but there's also some antennas at the rear view mirrors. Now once you can receive ultra high frequency and low frequency signals you can build a protocol analyzer. So I have a simple Python script that interacts with both radios and we can then use the car in a legitimate way. So unlock it with the keyfob. And by doing that with the real keyfob and the real car and doing it a few times you can look at which messages stay constant, which change and which parts change. And by doing it a few times and staring at the binary outputs you can then figure out what the protocol looks like. So in this case the car will send periodically, twice a second in this case, a message to the keyfob. If the keyfob is nearby it will reply. And the reply is actually an obfuscated version of the previous packet. I'm not really sure why the obfuscation is here. And if you receive the message from two or three vehicles you can easily figure out what the obfuscation is because it's simple bits, shifts and bytes swaps. When the car receives this reply it will send the challenge to the keyfob. The keyfob computes a cryptographic response and the car verifies it. If it's correct the car unlocks. It's important to note here that the keyfob will only reply if the car identifier in the packet is correct. So as an attacker if you want to impersonate the car you need to know the car identifier. But it's only two bytes. So we were first thinking of stealing the car with ever seeing the keyfob. And the idea here was to send a random response so the car sends you a challenge. You reply with a random response and you hope to get lucky. As it turns out after 97 days and about one guess a second you will get lucky once and you will be able to unlock the vehicle. Afterwards doing computations you can get the second challenge response pair required to recover the key in about nine additional hours. But the nice thing about this attack is that it can be automated. Now 97 days to steal a car is not really a practical attack and we want to show that using 40 bit keys today is maybe not the best decision. So we wanted to build an efficient attack and as a reminder we have a 40 bit challenge, a 40 bit key and only a 24 bit response. So this means that for each other 40 bit challenges there's going to be multiple keys that produce the same response. And this also means that you will need at least two challenge response pairs to recover the real key. In this case there is no mutual authentication in the challenge response protocol so we can build a time memory trade-off table. And the idea here is that we fix one challenge so we fix it once and then for each possible value of the key we compute the response. Afterwards we group all of the keys that produce the same response to this fixed challenge. So we end up with a 5.4 terabyte lookup table which has two to the 24 files, one for each response and each of these files contains about two to the 16 keys. Now how do we use this table? In a real attack you first have to get the car identifier. You then send your challenge to the keyfob, you record the response and you use this response to select a file from your lookup table. At that point there's only two to the 16 keys left so you send the second challenge to the keyfob and brute force remaining keys. So this takes about two seconds on a Raspberry Pi. Then we built this device so at the top there's a simple USB power bank then there's a Raspberry Pi Model 3 which is the brains of the operation and it's controlling the Proxima 3 and your stick 1 radios. The way I use this in practice is I make a hotspot on my phone. The Raspberry Pi connects to the hotspot. I can SSH into the Raspberry Pi and start the tools and the Raspberry Pi can use the same connection to reach out to the time memory tradeoff table. After figuring out these issues we of course contacted the manufacturers. We started off by contacting Tesla and we then quickly figured out that they actually bought the system from a company called Pectrum and as it turns out they built similar systems using the same Texas Instruments chip for McLaren, Karma and Triumph. Does anyone have a McLaren? So the initial report is almost two years ago already and after one year Tesla had a new key fob which they put in new vehicles being produced and they also released some over-the-air software updates that people can enable so they're not enabled by default but you can enable them in the settings. One of them is basically two factor authentication so every time you start your vehicle you have to enter a pin code. The second is the ability to disable passive entry and this is actually a nice feature because it will stop relay attacks which are very common in practice. Now from doing this research we can draw some conclusions and most of the conclusions are pretty sad maybe to show in 2019 because I figured that everyone would have known this by now but there's still manufacturers relying on proprietary cryptography and there's manufacturers that rely on NDAs to make sure that their ships are secure their car manufacturers a lot of them that rely on tier one or tier two suppliers to make secure products for them and they might not know what they're buying and there's also a lot of people that rely on secrecy of their firmware to make a secure product but in most cases and especially in general purpose microcontrollers there's always a way to get the firmware out but maybe the most important conclusion is that Tesla got a lot of heat for using 40 bit keys but the other karma manufacturers such as McLaren, Karma and Triumph they didn't respond at all and Tesla fixed the issues. I have a few funny stories about McLaren specifically but in the interest of time I'm going to skip them but you can always come up to me after the talk and I'll be happy to elaborate. This is a video we made to show how the attack would work in practice so I'll again explain how the attack works. Now if you want to steal Tesla Model S it's not that difficult to find one they all have to charge at some point and they all do it in the same location so I think the car has to charge for about 40 minutes and most people will go to a nearby coffee shop or go for a walk while they wait for the car to charge. Now as I mentioned before as an attacker what we need to communicate with the key fob is the car identifier you can either brute force it but walking up to the vehicle and sniffing it is a lot faster and easier. The output on top, the terminal output is recorded from my phone in this case. Then you have to send your challenge to the key fob, record the response, get the correct file from the lookup table, brute force the remaining keys and in a few seconds you have a perfect copy of the key fob and at this point you can easily unlock the vehicle and you have to remember to unplug it before you drive off and because the same cryptographic key is being used to unlock the vehicle and start the vehicle you can also drive off with it. So this is usually the point where I would end this talk but it's chess and I promised you something new. So I also had a look at the new key fob that Tesla made. So as it turns out a log shatek in this case and the key fob is actually using dst80 so a new 80-bit cipher but we found a way to trick it into doing dst40 with half of the 80-bit key and we can actually make it do that on both half of the 80-bit key. So we could generate a second lookup table and use four seconds instead of two to make a copy of the key fob. Now there is a small downside to this attack because you have to be shorter to the key fob because you're only using low frequency communication for this attack. So the cars being produced today are already using a new new key fob and Tesla is releasing a software update and it's being rolled out since today that allows people to update the key fob from their car. So this is what the update looks like and as you can see I guess Tesla knew I was going to present it today so they even updated their chess game but the idea is that you will put the key fob close to the transmitting antennas and the car will issue a fix to the key fob. I think this is a pretty cool way of solving the issue. There will also be an article about the attack on wires in a few minutes. So that's it for my talk and if there's any questions I'll be happy to answer them. Thank you Leonard. Are there any questions from the audience? Thank you. You mentioned that you are using the memory trade of tables but with damage is a problem that you never get a hundred percent coverage so my question is what is the coverage of your tables? So you could repeat the last one. What is the coverage of your time memory trade of tables because normally you never get a hundred percent coverage if it is. So no using the table we reduce the key space to two to the sixteen and then we need a second challenge response pair to get the actual value of the key. So you are a hundred percent successful? On the five or six cars I tried to unlock this work. So there might be some education where you're not successful but nothing prevents you from sending a third or fourth challenge to the key fork. Okay thank you. Okay let's thank the speaker again.