 Hi, I'm Leonard Waters, and together with Jan van den Herderwegen, we will present our work titled, Dismantling DSD-AT-Based Immobiliser Systems. This work was a collaboration between the Centre for Cybersecurity and Privacy at the University of Birmingham in the United Kingdom, and the Coastal Research Group at the Keeleurven University in Belgium. Jan is going to start his presentation by explaining what an immobiliser system is exactly, and how it is used to prevent thieves from stealing your car. So, what exactly is an immobiliser? It is the main anti-theft measure in any modern car. Before they were in place, a criminal could so-called hotwire your car, which is when they touched the ignition wire and the main voltage line, and then that would start the car. Now, with immobilisers in place, when the key fob is inserted in the ignition barrel and turns, the immobiliser cryptographically authenticates the key fob and only when it has been previously paired to the vehicle, then it sends on a signal to other ECUs or control units in the car, which then finally can start the car. Since the immobiliser is the main component of this system, we decided to look more into what exactly it does and how it does this. To achieve this, we've looked at immobiliser ECUs made by Toyota and ECUs made by Kia and Hyundai. This is the Toyota DSTAT immobiliser ECU opened up. So, as you can see, there's the pin headers here, leading on to various components in the car. There's a small e-promptrip containing several bytes of data, and then finally there's the main immobiliser microcontroller here, which we have desoldered on this breakout board. We will explain later why. One issue we encountered with this particular PCB is that the serial number printed on the chip did not match any of our Google searches. That was because it was a serial number of the manufacturer that made the immobiliser ECU and not actually the chip number. So we had to kind of narrow down from all data sheets online based on the pinouts, so the voltage pins and the ground pins, and then finally also the resonator here, which helped narrow it down finally to the ReneSAS 78K0 microcontroller, which is an 8-bit microcontroller. So this ReneSAS chip exposes a bootloader interface, which communicates over simple serial protocol UARTs here, and by pulling this pin high on reset, we can make the chip enter a boot mode, which exposes certain functionalities such as rewriting flash sectors or erasing the chip or separate flash check sectors. However, it also incorporates a protection mechanism to prevent exactly that, and since this protection bytes with each bit indicating a separate level of protection was completely set, we had to resort to voltage glitching, which is a technique where we control the voltage line, and by inserting small glitches or anomalies in this voltage supply, we can, for example, skip the instruction where it checks the protection bytes. So our setup for this is as follows, we're using the giants of which you can find the source here to insert the glitches, and then we use a raspberry byte to interface with the bootloader on the one hand, and on the other hand to control the giants through USB. So through this bootloader interface, we were able to send a command which sets a new security byte, so where we can disable all security bits, and by inserting a glitch when it checks that this byte is allowed, we managed to revert the security bytes. So that gave us right access to the chip, and then finally, we could override the boot sector of it, and with a simple program that just dumps the firmware over UARTs, and then finally, we obtained the immobiliser firmware. Once we had this immobiliser firmware, we were interested in finding out more about DSD80, of which little is publicly known. So it's a successor of DSD40, also manufactured by Texas Instruments, and a immobiliser shifer reverse engineered and attacked by Bono et al in 2005. They showed that with a cluster of FPGAs, they could brute force a 40-bit encryption key. DSD80 is based on the same authentication protocol, namely the immobiliser generates a 40-bit random challenge, and then sends it on to the transponder, which in turn calculates a 24-bit signature and a 16-bit block-checked character based on a shared secret key. This secret key is split into 40-bit chunks, namely key left and key right. So this is the result of our reverse engineering efforts. What you can see here is the standard DSD40. So a 40-bit challenge response register is initialized with the 40-bit random challenge, and then the cipher runs for 200 rounds. In each round, a round key is put along with the challenge response register through a fysal function F, which consists of several lookup tables, F, G and H, and then finally results in two bits, which are subsequently fed back into the challenge response register. The round key is derived from two key registers, which are both 40 bits. So key left and key right are both LFSRs with depth bits on these positions. So every round, these shifts by one bit, and then the round key is just derived by taking 20 bits of the left key and then 20 bits of the right key. Unlike DSD40, where only every three rounds, the round key is added in the ST80 that's done every round. Once we had this DSD80 cipher reverse engineers, we wanted to see whether we could practically attack these DSD80 systems. The result of this is two attacks based on weak secret key generation and several attacks based on transponder configuration issues. First of all, we noticed that Toyota mobilizers read out the serial number and two separate pages from the transponder memory, and then put this through some function, which then finally generated the 80 bits secret key. This was then put along with the 40-bit random challenge in the ST80 and resulted in a response. Since this is quite a strange setup, we decided to look more into how exactly this key diversification works. So we reverse engineered this key diversification procedure from the immobilizer firmware. Every DSD80 transponder has this particular memory layout, namely there's a transponder ID, then there's several pages of user data, which you manufacture and program, and then, of course, there's also the 10 bytes encryption key. We found that the immobilizer initializes a 40-bit state with three bytes of the serial number and then two 1-byte pages of the transponder, which are all publicly readable, so they're not protected, and then puts this through a proprietary cipher, which finally spits out the 80-bit encryption key. The only entropy in this cipher comes from a secret stored in the firmware, which is basically 15 bytes. And, of course, the initial state, but that doesn't add any entropy since it's all publicly readable information. So we realized that the secrets are identical across all firmers we looked at. So actually, once you know the proprietary cipher and these secrets, that means that all you need is the transponder ID and these two pages, and then you can derive the 80-bit encryption key from that, completely breaking the security in Toyota DSTAT immobilizers. The security analysis for Kia Hyundai immobilizers was slightly different. First of all, since the STM8 microcontroller, which controlled the immobilizer ECU, was unlocked, we were able to just connect to the debug interface and read out the flash and eProm memory straight away. Immediately, we realized that the DSTAT keys were stored in eProm, and after dumping them, the immobilizer firmware of several ECUs, we realized that four bytes in the secret keys are always the same. So that reduces the entropy from 80-bits to 48-bits. Then after further investigation, we realized that the three remaining bytes from key rights are just the inverse of the bytes of key left, further reducing the entropy to 24-bits, which is easily brute-forceable offline. So again, all we have to do is wirelessly communicate with the transponder ones, from which we can get two challenge response pairs, and then finally brute-force the 24 remaining bits to obtain the 80-bits encryption key. Now, Leonard is going to explain the transponder configuration issues we found and also several side-channel attacks on DSTAT transponders. After looking at manufacturer-specific vulnerabilities, we also want to cover general issues that can occur with these DST immobilizer systems. As Janus touched upon earlier, each keyfab contains a transponder chip with eProm pages that stores certain information. These pages are used to store configuration of the transponder and the cryptographic key, but they can also be used to store manufacturer-specific application data. For example, some manufacturers will use these pages to store information about your car's maintenance schedule. Each of these transponder pages can be individually and as far as we can tell irreversibly locked. This means that the data stored within these pages can no longer be overwritten. As it turns out, not all manufacturers lock these pages properly, which can lead to some interesting scenarios. For the first scenario, we assume that the manufacturer correctly configured the keyfab to perform DSTAT and that the key has been configured and locked. However, we will assume that the configuration page was left unlocked. In this scenario, an attacker can use these misconfigurations to their advantage by communicating with the keyfab over low frequency. You will first override the configuration of the transponder, such that it performs DST40 instead of DST80. As it turns out, the transponder will now produce a DST40 response to provide a challenge and will use half of the original DST80 key to do so. This means that the adversary can recover the DST40 key in a few seconds using a lookup table, after which he can revert the configuration of the transponder to DST80. He can now obtain some extra challenge response pairs to brute-force the remaining 40 bits of the key. In the second scenario, we will assume that the manufacturer left both the configuration page as well as the page containing the cryptographic key unlocked. The adversary can again modify the transponder's configuration to force it to perform DST40 instead of DST80. As with the first scenario, he can now recover 40 bits of the full 80-bit key using a first lookup table. After doing so, he can also override this 40-bit key to a known value. The ability to override half of the key allows the adversary to use a second lookup table to recover the second half of the key. To that end, he will change the configuration back to DST80, enabling him to recover the second half of the key. Knowing both halves of the key, the adversary can also reprogram the transponder, leaving no trace of his interactions with the keyfob. While some of these scenarios might sound artificial, we found that the second iteration of the Tesla Model S keyfob to be vulnerable to this exact scenario. Finally, we consider the worst-case scenario from an attacker's perspective. The manufacturer locked both the key and configuration pages. As it turns out, certain DST transponder packages contain an SPI interface to which you can still ask your transponder to confirm DST40 operations instead of DST80, even if the transponder is configured to perform DST80. If the adversary has short-term physical access to the keyfob, this scenario can thus be considered equivalent to the first scenario. The adversary can recover the key in two halves. The first 40-bit key can be recovered using a lookup table, and the second half can be brute-forced. Depending on the package type that is used, the adversary requires a few extra steps. A discussion on the exact steps that would be required is provided in the full paper. If all else fails, an adversary might want to apply side-channel analysis to recover the transponder key. In the paper, we cover both the differential power analysis attack, as well as a profiled attack on the key loading procedure. In the interest of time, we will only cover the profiled attack during this presentation. Our goal for this attack is to profile the secret key being loaded from the non-volatile storage to the DST-hardware accelerator. We observe that the key is loaded byte-by-byte on each invocation of the cipher. The strategy is thus to create a profile for each key byte from many side-channel measurements in which the cipher is invoked using different secret keys. During the attack phase, the goal is to recover the secret key using the generated profile and a few side-channel measurements. Most works which target key loads cover artificial scenarios or only consider the worst-case scenario in which the profile device is also the device under attack. In the case of the DST transponders, this worst-case only occurs when the key is left unlocked, a scenario we have previously shown to be vulnerable to a downgrade attack. In this work, we target a real-world device and consider the portability problem in which the profiling device and attack device are different. Difficulties in attacking a different chip during the attack phase stem from variations in the chip production process as well as variations in the measurement conditions. Before building a model, each trace is subjected to a pre-processing methodology. Each trace is aligned to a reference trace on the peak marked by a red diamond. Because all of the measured transponders use an unstable internal clock, it is difficult to perform alignment, especially across multiple target chips. To obtain aligned traces, we extract the marked peaks from each trace and stitch together new artificially aligned traces. While this step might not be strictly necessary when using convolutional neural networks, it is necessary to be able to apply more classical methods to identify the leaking samples. Additionally, it allows to significantly reduce the data complexity. After obtaining artificially aligned traces, we are able to identify regions of interest in the power measurements. In blue, we see the average trace for six different transponders chips. Light blue zones indicate the variation between the means of those six different devices. As can be observed, we identified regions of interest for each of the key byte values, as well as the distance between consecutive key bytes. In orange, we can see that there is at least some information regarding the intra-device difference. These areas were kept as part of the trace in the hope that they would help our model to generalize to unseen devices. Let's first explore the single device scenario in which we train a multi-layer perceptron model on a single device. Afterwards, we evaluate the model's performance when attacking that same device. Finally, we try to use that same model to attack a different transponder chip. The exact details on the used model and the training strategy are provided in the paper. Accuracy and loss are often not the best metric when evaluating a machine learning model in the side channel context. Therefore, we evaluate our models after each epoch by computing the mean rank over 256 attacks, one for each label using 50 traces. Each plot contains three lines. In green, we have the mean rank obtained on the training set. In orange, the mean rank on the validation set. And as you can see, in most cases, both the green and the orange line overlap, indicating that our model generalizes well for the same device. In blue, you can see the mean rank when trying to classify traces from a device that was not part of the training set. From these plots, it is clear that it would be trivial to attack the device that was profiled. However, using the same profile is unlikely to yield good results on a device not used during the profiling phase. In the multiple device scenario, the idea is to create a profile for the family of transponder chips instead of a profile for a single transponder chip. We train the same multi-layer perceptron model on traces from five distinct transponders. And initially, we evaluate this model by attacking traces coming from the same set of five devices. Finally, we try to attack traces from a transponder, which was not part of the training set. This experiment is repeated six times, each time using traces from a different transponder as the attack set. In total, we used six million traces, one million traces with random keys for each of the transponder chips. The details on the used multi-layer perceptron model, as well as the training strategy are provided in the paper. In orange, you can see the mean rank when attacking a transponder chip, which was part of the profiling set. In contrast with the single device scenario, you can see that certain target values are more difficult to attack. Nevertheless, the information gained from these could still be useful when using an optimized key enumeration strategy. In blue, you can see the mean rank when attacking a device, which was not part of the training set. This clearly shows a tremendous improvement over the single device model in at least six out of the nine targets. We provide additional details in the paper, but it turns out that using as little as 10 traces, we could reduce the entropy of the secret key from 80 bits to a brute-forceable 41 bits of entropy. Additionally, we are confident that this attack could be improved upon using several different strategies. From these experiments, we conclude that profiling a family of chips can help to tackle the portability problem, and that this technique allows you to mount a side channel attack on a key transfer in a real-world device. To conclude this presentation, we want to provide you with an overview of all of the vehicles we know are affected by the attacks detailed in this paper. The model names in bold are the vehicles or their ECUs that are evaluated during this research. We contacted all of the affected manufacturers and provided them with a personalized report. Tesla was able to resolve the downgrade attack by pushing an over-the-air update that allowed users to service their own key fob. Finally, we hope you'll enjoy reading the full paper. We believe it contains something for everyone interested in hardware security. We demonstrate a practical fault injection attack that allows to extract the firmware from a commonly used automotive microcontroller. We publish the full details of the proprietary DSD-80 cipher, for which there are currently no public cryptanalytic results. We also reveal that even without a cryptanalytic attack, we can bypass the security provided by many of these systems by exploiting weak key diversification and downgrade attacks. Additionally, we provide a differential power analysis attack, as well as a profile attack on the key being loaded into the hardware accelerator, all of this while taking portability into account. Feel free to contact us should you have any questions or join us for the discussion during the virtual chess 2020 conference. Thank you for taking the time to watch this presentation.