WEBVTT 00:00:00.000 --> 00:00:17.287 Herald: The second thing I wanted to announce: there is no scooter sharing. 00:00:17.287 --> 00:00:35.858 Which brings me to the next talk. We tend to need kind of a security concept for not 00:00:35.858 --> 00:00:43.165 scooter sharing. So the easiest way would be to have kind of a scooter lock. But we 00:00:43.165 --> 00:00:50.864 have the lock picking guys. So that won't work. So the next option would be we can 00:00:50.864 --> 00:00:58.358 have a GPS tracker, but we have the GPS spoofing guys. Which isn't also that good. 00:00:58.358 --> 00:01:06.599 A third option would be an immobilization system. We have Wouter Bokslag. Thank you. 00:01:06.599 --> 00:01:10.800 *applause* 00:01:10.800 --> 00:01:15.665 Wouter: Hi. Thank you for the introduction. Thank you guys for the warm 00:01:15.665 --> 00:01:20.636 welcome. I'm really happy to see that still some people have come together here 00:01:20.636 --> 00:01:27.897 at this ungodly hour to watch my talk about vehicle immobilization. Well, 00:01:27.897 --> 00:01:34.402 briefly something about me. I'm a Kerckhoff security master. And the 00:01:34.402 --> 00:01:41.311 research I will be presenting today, I did as my master's thesis. So I spent about 00:01:41.311 --> 00:01:47.199 half a year analyzing various systems and I wrote something about that. And if you 00:01:47.199 --> 00:01:53.755 want to read the full story, you can look at my thesis, which is public since some 00:01:53.755 --> 00:01:58.966 time now. And there's more detail there. I'm currently working as an automotive 00:01:58.966 --> 00:02:05.500 engineer. And if you feel like asking me questions besides the Q&A, you can always 00:02:05.500 --> 00:02:12.545 contact me by mail. So first, responsible disclosure. This kind of stuff is not a 00:02:12.545 --> 00:02:19.522 joke. Automotive manufacturers think it is very important. And, well, they have a 00:02:19.522 --> 00:02:27.555 reason to think so. So naturally we contacted them ahead of publication even 00:02:27.555 --> 00:02:35.229 before my defense and we laid out the findings and I had a couple of conference 00:02:35.229 --> 00:02:42.959 calls with the manufacturers. And I even went to one of them to demonstrate the 00:02:42.959 --> 00:02:50.715 findings on premise. I need to point out that the research that I did was on fairly 00:02:50.715 --> 00:02:57.598 old vehicles like 2009 and around. But for the three cases that I really went in 00:02:57.598 --> 00:03:04.155 depth we have been able to confirm that they are still in currently produced 00:03:04.155 --> 00:03:09.012 models. So this in itself is kind of surprising because you think automotive, 00:03:09.012 --> 00:03:15.702 cars, electronics, security, it's a fast moving industry, but well, no, not really. 00:03:15.702 --> 00:03:22.097 So everything that was in cars in 2009, at least regarding to these three systems, 00:03:22.097 --> 00:03:27.575 can still be found in currently produced models. I will disclose the vehicles that 00:03:27.575 --> 00:03:34.003 I've been working on, because I think that is relevant. I hope you can forgive me 00:03:34.003 --> 00:03:38.786 that I'm not going to disclose the vehicles that I have identified these 00:03:38.786 --> 00:03:43.815 systems in that are still being produced. I'm not really into facilitating theft and 00:03:43.815 --> 00:03:50.775 I don't see what would be the added value. So the talk will be structured as follows: 00:03:50.775 --> 00:03:58.003 I will first introduce some standard stuff about immobilization systems and about 00:03:58.003 --> 00:04:04.801 computer networks inside vehicles. I will tell you something about how I addressed 00:04:04.801 --> 00:04:10.905 the challenge. So for all three models, I kind of followed a similar approach and I 00:04:10.905 --> 00:04:16.119 think it's more practical to lay that out once and then skip the details later on. 00:04:16.119 --> 00:04:21.472 And then I will present the three protocols that I uncovered in a Peugeot, a 00:04:21.472 --> 00:04:27.190 Fiat and an Opel vehicle. I will then summarize the findings in a series of 00:04:27.190 --> 00:04:34.735 takeaways and there will be some time for questions. Right. So modern vehicles are 00:04:34.735 --> 00:04:41.376 full of electronics and full of computer systems. They operate largely independent. 00:04:41.376 --> 00:04:47.348 They are all connected through a variety of different buses that talk to each other 00:04:47.348 --> 00:04:53.473 with different protocols. And there is a plethora of different standards, ISO 00:04:53.473 --> 00:04:59.061 standards, all kinds of standards. And then the manufacturer wants a lot of 00:04:59.061 --> 00:05:05.007 freedom to, well, do it in their own way. So even if you read these hundreds of 00:05:05.007 --> 00:05:11.923 pages of standards, still every vehicle you will look at will be kind of 00:05:11.923 --> 00:05:20.109 different. There are some practical handles that you can use, and one of them 00:05:20.109 --> 00:05:29.591 is that every car has a OBD-II port. Yeah, this is required by law, both in the US 00:05:29.591 --> 00:05:38.185 and in Europe for quite some time now. And it needs to be conveniently located and 00:05:38.185 --> 00:05:44.830 that is very near the driver's seat. So this is a universal connector and all cars 00:05:44.830 --> 00:05:50.176 with a combustion engine need to have one. And cars with electronic engines also need 00:05:50.176 --> 00:05:55.764 to have one. But the functionality that has to be implemented is much more 00:05:55.764 --> 00:06:04.210 limited. So in regular internal combustion engine powered cars, you have to be able 00:06:04.210 --> 00:06:10.654 to read out emissions data and that kind of stuff. So many manufacturers felt this 00:06:10.654 --> 00:06:17.156 was a very convenient thing to also use for garage purposes, for workshops to read 00:06:17.156 --> 00:06:23.753 out error codes, to perform all kinds of routines on vehicles. You might need to 00:06:23.753 --> 00:06:30.367 teach new keys to your car if you lost one or if you just want a third one. If you 00:06:30.367 --> 00:06:35.724 add a towbar to your car, you need to tell a couple of ECUs in the car that it now 00:06:35.724 --> 00:06:42.340 has a towbar. Depends on the vehicle, but telling this to 5 individual ECUs is not 00:06:42.340 --> 00:06:48.671 an exception. And since it is a bus, the CAN bus, it can be directly addressed 00:06:48.671 --> 00:06:53.995 through the OBD connector on many vehicles and you can talk to a lot of different 00:06:53.995 --> 00:06:59.437 components. So the ECM, the Engine Control Module, is one, the body control module is 00:06:59.437 --> 00:07:04.833 another. That one controls, for instance, powered windows and all kinds of interior 00:07:04.833 --> 00:07:13.538 stuff, but also the airbag, infotainment system, fancy interior lighting, stability 00:07:13.538 --> 00:07:21.880 control systems. Another feature of it being a bus is that you can also see the 00:07:21.880 --> 00:07:28.461 inter-component communication. So if the instrument panel cluster, the dashboard, 00:07:28.461 --> 00:07:36.074 needs to talk to, say, the body control module, you can see that packet going over 00:07:36.074 --> 00:07:42.505 the CAN bus. All my research has been focused on this OBD-II connector and what 00:07:42.505 --> 00:07:49.171 you can do and what you can see from this perspective. Immobilizer systems are 00:07:49.171 --> 00:07:56.406 nowadays required to be implemented in vehicles. Since the late 90s, legislation 00:07:56.406 --> 00:08:02.620 has been adopted in both the States and Europe, mandating the use of an electronic 00:08:02.620 --> 00:08:09.699 immobilization system. And the purpose, of course, was to reduce the risk of theft. 00:08:09.699 --> 00:08:17.003 This is proven to be effective: According to one study, theft rates dropped by 00:08:17.003 --> 00:08:26.010 almost 40% in, I think, a 7 year span they based their data on. This is because car 00:08:26.010 --> 00:08:33.831 theft used to be quite simple. You could just put two wires together and you could 00:08:33.831 --> 00:08:39.123 power the starting circuit and you could actually start the engine. And the 00:08:39.123 --> 00:08:45.232 immobilizer system adds another step to that. The engine control module that 00:08:45.232 --> 00:08:50.956 finally controls the engine wants to have some kind of assurance that the key 00:08:50.956 --> 00:08:55.854 presented in the system is actually valid and does so by validating a security 00:08:55.854 --> 00:09:01.741 transponder. First generations of these security transponders have been widely 00:09:01.741 --> 00:09:08.121 studied and often were found insecure. Of course this is a problem because well, if 00:09:08.121 --> 00:09:13.275 it's insecure, it doesn't add any security and cars can be stolen nonetheless. So 00:09:13.275 --> 00:09:17.715 there has been kind of an arms race in this domain and we see that nowadays 00:09:17.715 --> 00:09:24.086 security transponders have become a lot better. Your car might even use AES to 00:09:24.086 --> 00:09:31.622 validate that the key you're putting in the ignition is an actual key that is 00:09:31.622 --> 00:09:37.710 recognized by your vehicle. And this is really necessary because car thieves have 00:09:37.710 --> 00:09:43.210 shown to be able to wield quite high tech solutions, procure them from shady 00:09:43.210 --> 00:09:51.436 companies or just use official tools that can be used in illegitimate ways. A nice 00:09:51.436 --> 00:09:58.051 example of this is shown here. For certain models of Range Rover, they have a blind 00:09:58.051 --> 00:10:03.930 spot sensor, so you can see if there is a car in your blind spot. And if you pop off 00:10:03.930 --> 00:10:09.498 a cap, then you can connect a 12V battery, power the internal ECUs of the vehicle. 00:10:09.498 --> 00:10:15.293 Then you can access the CAN bus, put the car into key teaching mode and hold a 00:10:15.293 --> 00:10:20.865 blank key to the window and it will program the key and recognize it as a 00:10:20.865 --> 00:10:24.564 valid key. Well, needless to say, this was not intended behavior 00:10:24.564 --> 00:10:27.706 *laughter* 00:10:27.706 --> 00:10:33.252 and this has had consequences for consumers. Because insurance companies saw 00:10:33.252 --> 00:10:38.892 a rise in theft for these models - these are quite expensive cars - and they 00:10:38.892 --> 00:10:45.363 started adding demands before they would allow you to insure your car. So the 00:10:45.363 --> 00:10:51.068 insurance would get more expensive or you would not be able to get the insurance if 00:10:51.068 --> 00:10:57.494 at least at your own home, you couldn't park it in a secured area. There is a 00:10:57.494 --> 00:11:05.350 common misconception about how immobilizer systems work, and it's actually one of the 00:11:05.350 --> 00:11:10.090 reasons I want to give this talk and present this, because I think it's 00:11:10.090 --> 00:11:16.611 important to realize that an immobilizer system is a bit more complicated than the 00:11:16.611 --> 00:11:23.435 single cryptographic step that seems logical. So what you might think is that 00:11:23.435 --> 00:11:28.253 the engine control module sends a challenge to the body control module, 00:11:28.253 --> 00:11:34.276 which communicates with the key. It implements the radio layer and it can then 00:11:34.276 --> 00:11:41.217 relay the challenge to the key. The key can compute the proper response based on a 00:11:41.217 --> 00:11:47.103 secret it shares with ECM, send back the response, which the BCM will in turn 00:11:47.103 --> 00:11:52.998 forward to the ECM. The ECM can verify the validity, and if this seems to be the 00:11:52.998 --> 00:11:58.564 right response, immobilization is deactivated and the car can start. Sounds 00:11:58.564 --> 00:12:05.995 good. Sounds easy, but this is in modern cars no longer the case. 'course. What we 00:12:05.995 --> 00:12:12.960 see is that there is a second step. The ECM does an authentication with the BCM. 00:12:12.960 --> 00:12:20.215 The BCM does an authentication with the key. So if your key uses say AES for its 00:12:20.215 --> 00:12:28.450 authentication, then this will be an AES secured authentication between the BCM and 00:12:28.450 --> 00:12:34.307 the key. The BCM, if it can validate the legitimacy of the key, will then send the 00:12:34.307 --> 00:12:38.916 correct response to the engine control module. But this is a whole different 00:12:38.916 --> 00:12:45.195 protocol, using different cryptographic primitives, using different keys, 00:12:45.195 --> 00:12:52.529 sometimes, often, don't know. And more importantly, it has not yet been covered. 00:12:52.529 --> 00:12:58.335 So in the scientific literature, I have found absolutely zero reference of this 00:12:58.335 --> 00:13:04.188 step being identified. And here and there you find a reference that people know that 00:13:04.188 --> 00:13:10.796 this happens, but no actual analysis of the security or the cryptographic 00:13:10.796 --> 00:13:18.552 primitives involved. Right. So that is an open question then and asks for further 00:13:18.552 --> 00:13:24.811 research. So how do you do that? You can sniff CAN traffic from the OBD connector 00:13:24.811 --> 00:13:31.989 with tooling. And by disconnecting ECUs and placing yourself in the middle you can 00:13:31.989 --> 00:13:38.577 also modify CAN traffic. You can analyze this CAN traffic, see if you can find 00:13:38.577 --> 00:13:44.317 immobilizer-related messages. And of course, by the messages, you cannot deduce 00:13:44.317 --> 00:13:48.816 the algorithm, most of the time. So you will need a firmware image or something 00:13:48.816 --> 00:13:54.063 else you can reverse engineer to actually find the code that does the magic stuff. 00:13:54.063 --> 00:13:59.379 If you have that and if you are able to pinpoint where the algorithm is, then you 00:13:59.379 --> 00:14:04.652 can start looking at if it's actually decent. And once you are all there you 00:14:04.652 --> 00:14:10.697 will want to test if all the assumptions you've made on the way are correct and if 00:14:10.697 --> 00:14:15.299 it's actually working as you think it's working. So the first step, protocol 00:14:15.299 --> 00:14:19.882 identification, is actually quite straightforward because you have some 00:14:19.882 --> 00:14:26.465 knowledge. You know that this is a message exchange that happens when you switch the 00:14:26.465 --> 00:14:32.424 ignition to the on position. And you know that there must be at least two high 00:14:32.424 --> 00:14:37.351 entropy messages because the challenge has to be different every time. And the 00:14:37.351 --> 00:14:40.973 response is the output of some cryptographic function. So it may be 00:14:40.973 --> 00:14:46.370 expected that that looks quite random, too. Also, if you switch the ignition on 00:14:46.370 --> 00:14:52.127 but no valid transponder is present, you should be able to detect some kind of 00:14:52.127 --> 00:14:55.925 difference. And it will probably be the very first moment you observe a 00:14:55.925 --> 00:15:01.041 difference, because before that point, the car didn't know there was no valid 00:15:01.041 --> 00:15:06.567 transponder. So with a bit of fiddling and some patience and going through CAN 00:15:06.567 --> 00:15:12.510 traffic logs, you can probably find this. OK. Next step is to get a firmware image 00:15:12.510 --> 00:15:19.094 in which you hope to be able to find the actual cryptographic protocol. So there 00:15:19.094 --> 00:15:24.785 are several options. Of course you already have the firmware, but it's in the 00:15:24.785 --> 00:15:30.705 microcontroller in an ECU that is either lying on your desk or inside some vehicle. 00:15:30.705 --> 00:15:38.190 So you could try to get it straight out of that device. Debugging headers are a good 00:15:38.190 --> 00:15:44.879 option. You have JTAG, you have BDM, UART occasionally can be used, but sometimes 00:15:44.879 --> 00:15:49.854 these are deactivated. Sometimes it just doesn't seem to work. Sometimes the 00:15:49.854 --> 00:15:55.038 tooling is prohibitively expensive. So if that doesn't work, you can always go to 00:15:55.038 --> 00:16:00.314 the internet. Some manufacturers provide a means to download a set of information 00:16:00.314 --> 00:16:06.900 about the vehicle based on its VIN number. You can find all kinds of configurations, 00:16:06.900 --> 00:16:13.095 you might be able to find actual parts or full firmwares, often encrypted, not 00:16:13.095 --> 00:16:18.510 always. And then there is the tuning scene. And while you might think of neon 00:16:18.510 --> 00:16:23.273 lighting and stuff like that, these guys are actually pretty knowledgeable about 00:16:23.273 --> 00:16:28.485 the internals of engine control modules in particular. And you might just be able to 00:16:28.485 --> 00:16:34.716 find a full firmware image or parts of it or some model that is highly related. And 00:16:34.716 --> 00:16:40.312 this is kind of a viable approach to getting your hands on the firmware. But 00:16:40.312 --> 00:16:45.008 also very practical can be to just leverage the functionality that is 00:16:45.008 --> 00:16:51.555 implemented in the ECU. The ECU allows for diagnostic commands such as read memory by 00:16:51.555 --> 00:16:59.925 address and request upload, which from the perspective of an ECU is sending new data. 00:16:59.925 --> 00:17:07.405 And you might be able to just dump the whole firmware or dump memory or dump at 00:17:07.405 --> 00:17:13.820 least parts of the the internals of the ECU. Then there is some kind of mechanism 00:17:13.820 --> 00:17:19.688 that's called second bootloader. It's a sort of standard. Not every manufacturer 00:17:19.688 --> 00:17:26.495 implements it, but quite some do. That allows you to actually send binary code to 00:17:26.495 --> 00:17:33.621 the ECU. And it then jumps to it. So very convenient functionality. It's maybe very 00:17:33.621 --> 00:17:38.599 painstaking to get it working, but yeah, it's basically free code execution. Except 00:17:38.599 --> 00:17:42.919 for the fact that you often need to authenticate before you're allowed to use 00:17:42.919 --> 00:17:47.018 such functionality. So that might leave you with some kind of chicken and egg 00:17:47.018 --> 00:17:51.225 problem, because you don't know how to authenticate, you don't have the algorithm 00:17:51.225 --> 00:17:56.411 for this authentication. And lastly, there are sometimes firmware updates for ECUs 00:17:56.411 --> 00:18:02.685 and you might be able to use an official dealer tool, you might be able to sniff 00:18:02.685 --> 00:18:08.614 CAN traffic. Multiple ways of trying to update the firmware on your ECU 00:18:08.614 --> 00:18:12.931 reconstructed from the CAN traffic. Once more, you have to go through an ISO 00:18:12.931 --> 00:18:18.116 standard before you understand how it's exactly chunked in 8 byte messages, but 00:18:18.116 --> 00:18:25.160 you'll get there eventually. So once you have this firmware, you have to pinpoint 00:18:25.160 --> 00:18:30.091 the cryptographic algorithm and ECU firmwares are typically between half a 00:18:30.091 --> 00:18:35.058 megabyte and 2 megabytes. And that is a lot, if we're talking assembly. And the 00:18:35.058 --> 00:18:41.184 information density is extremely low. And if you have to go through it line by line, 00:18:41.184 --> 00:18:46.713 it's hardly doable. So you need to have some tricks. I think we're at a conference 00:18:46.713 --> 00:18:51.473 where we've seen a lot of reverse engineering. So this is not going to be my 00:18:51.473 --> 00:18:56.365 focus during this talk, but a couple of pointers. Maybe someone is helped by that. 00:18:56.365 --> 00:19:01.168 Of course, you know the protocol because you have observed CAN traffic. So you can 00:19:01.168 --> 00:19:07.183 search for immediate values, for numerical values that are used in the protocol to 00:19:07.183 --> 00:19:13.815 designate a packet type, for instance. It must be in the firmware somewhere. Also, 00:19:13.815 --> 00:19:18.706 you know that crypto usually uses XOR instructions and you would be surprised 00:19:18.706 --> 00:19:23.549 how little XOR instructions there are in a firmware. Depending on the architecture, 00:19:23.549 --> 00:19:28.341 you might immediately dismiss most of those as a single bit flip or maybe 00:19:28.341 --> 00:19:34.288 inversion of a whole register, and then you will find some XORs with either weird 00:19:34.288 --> 00:19:40.340 constants or variables. So those are points to focus on. Lastly, you can make 00:19:40.340 --> 00:19:46.912 some assumptions on the structure of the cryptographic function, so it certainly 00:19:46.912 --> 00:19:53.033 doesn't do IO, it will not invoke a lot of other external functions, maybe some round 00:19:53.033 --> 00:19:57.909 function once or twice, maybe some initialization. It will probably have some 00:19:57.909 --> 00:20:03.530 loops and you can sometimes recognize the length of the challenge. You can sometimes 00:20:03.530 --> 00:20:09.041 recognize the length of the response. That being said, let's dive in the first case 00:20:09.041 --> 00:20:15.569 study. So I reverse engineered the Peugeot 207, which is, as I said, not the most 00:20:15.569 --> 00:20:21.620 recent of vehicles. And this was my test setup. It doesn't look like much, but 00:20:21.620 --> 00:20:27.412 everything that's relevant to me is there. And you can toggle the ignition and lights 00:20:27.412 --> 00:20:32.430 will show and all the ECUs are connected through a CAN bus and an OBD connector 00:20:32.430 --> 00:20:39.220 that you can see on the left side of the instrument panel. And I investigated a 00:20:39.220 --> 00:20:46.445 tool that had a kind of peculiar function and that is that you could obtain the 00:20:46.445 --> 00:20:51.065 vehicle PIN - some kind of secret you needed to authenticate for diagnostics - 00:20:51.065 --> 00:20:56.499 by connecting this tool and toggling the ignition a couple of times. So that kind 00:20:56.499 --> 00:21:00.860 of gives you a hunch that the immobilization system might be involved, 00:21:00.860 --> 00:21:07.215 because it's triggered upon toggling the ignition, and that you can derive in some 00:21:07.215 --> 00:21:14.560 way the vehicle pin from this. So for this Peugeot and for most BSA vehicles in 00:21:14.560 --> 00:21:21.222 general, the PIN is a four digit uppercase and numeric code excluding the O and I, 00:21:21.222 --> 00:21:27.190 because that would be confusing. So that leaves us with roughly one point three 00:21:27.190 --> 00:21:33.826 million keys, which is nothing in terms of crypto. I finally reversed the algorithm. 00:21:33.826 --> 00:21:40.557 It is obviously in the engine control module and the body control module. And 00:21:40.557 --> 00:21:46.025 the main part looked like, oh wait, wait for it. And the protocol looks like this. 00:21:46.025 --> 00:21:51.935 So if you observe CAN traffic, you will see that some CAN ID 72. On that ID is 00:21:51.935 --> 00:21:58.675 sent a message that starts with 00 and then followed by a 4 byte challenge. And 00:21:58.675 --> 00:22:04.827 if the BCM is able to verify that a valid key is present, it will respond with 04 00:22:04.827 --> 00:22:11.880 and a four byte response. So this is a very small, straightforward protocol, 00:22:11.880 --> 00:22:19.520 which, well, does the bare necessary. And one of the first things I did was 00:22:19.520 --> 00:22:25.129 injecting challenges. Just inject a challenge, send it to the BCM with a valid 00:22:25.129 --> 00:22:30.362 key and see what the response is going to be. And if I replace the zeros by dots, 00:22:30.362 --> 00:22:37.858 you see that there's an extremely apparent pattern is visible. So the ideal case that 00:22:37.858 --> 00:22:45.602 a single bit flip in a challenge leads to a 50/50 chance of a bit flip in every 00:22:45.602 --> 00:22:51.992 response bit is not exactly respected. You see that the effect of changing the 00:22:51.992 --> 00:22:58.310 challenge has a very localized effect on the response. Another weird feature, which 00:22:58.310 --> 00:23:04.359 is not very clearly visible here, but it's visible in the last one, is that on 00:23:04.359 --> 00:23:10.389 average, when you give average just random challenges, 75% of the bits of the 00:23:10.389 --> 00:23:16.385 response will be set. So that is a very, very heavy bias. And it was quite puzzling 00:23:16.385 --> 00:23:23.430 to me what kind of cryptographic primitive would exhibit such behavior. And then it 00:23:23.430 --> 00:23:30.576 became clear. this is the main function of the algorithm and there is a transform 00:23:30.576 --> 00:23:36.950 function that I left out, but it basically does some multiplication, some division, 00:23:36.950 --> 00:23:43.265 some modulo, mathematical operations, It splits the challenge in two parts and it 00:23:43.265 --> 00:23:49.742 splits the vehicle PIN, so the secret in two parts. And the total of four parts are 00:23:49.742 --> 00:23:55.523 all used as inputs for this transform function and we obtain a challenge 00:23:55.523 --> 00:24:02.135 transformed left challenge transformed right and similarly for the PIN a left and 00:24:02.135 --> 00:24:08.456 right transformed part. And then something interesting happens because the left 00:24:08.456 --> 00:24:14.692 transformed part of the challenge is ORed with a part of the PIN. And an OR 00:24:14.692 --> 00:24:24.713 operation will lead to a, well, on average 75% set result. So that kind of explains 00:24:24.713 --> 00:24:34.005 the weird behavior we saw before. Strange and maybe not so smart, because an 00:24:34.005 --> 00:24:41.900 adversary will be able to either control or observe the challenge that is used as 00:24:41.900 --> 00:24:47.755 input for this algorithm. So if you know the challenge, you know the transform 00:24:47.755 --> 00:24:52.263 challenge, and if you know to transform challenge, you know something about the 00:24:52.263 --> 00:24:59.672 output. Because if the transform challenge has a one bit, then the response will have 00:24:59.672 --> 00:25:05.755 a one bit in that same position. There is another property for the transform 00:25:05.755 --> 00:25:10.285 function, and that is that if the input is a zero, the further parameters of 00:25:10.285 --> 00:25:16.105 transform vary a bit, but it doesn't affect this property: if the input is a 00:25:16.105 --> 00:25:22.132 zero, the output is a zero. So that gives us that if you have a challenge of all 00:25:22.132 --> 00:25:27.872 zeros, you will obtain a transform challenge of all zeros. And that means 00:25:27.872 --> 00:25:33.808 that when you're doing the OR you're ORing with nothing and the response will be 00:25:33.808 --> 00:25:41.104 entirely determined by the transformed PIN. Then another property is that the 00:25:41.104 --> 00:25:47.883 PIN, which is an alphanumeric PIN, is invertable once. Let me restart. 00:25:47.883 --> 00:25:58.365 Transform: If it takes a PIN as input, then the output can be inverted. There is 00:25:58.365 --> 00:26:04.608 only one PIN part input that maps to one output of the transform function. So if 00:26:04.608 --> 00:26:09.906 you are able to supply the vehicle with a challenge of zeros, you will get one 00:26:09.906 --> 00:26:14.730 response and you can uniquely identify the secret of the car, the PIN. And this PIN 00:26:14.730 --> 00:26:19.224 can later be used to, for instance, authenticate for diagnostics or key 00:26:19.224 --> 00:26:24.013 teaching or whatever you want. If you're not able to control the challenge, you can 00:26:24.013 --> 00:26:28.945 just collect a couple of random challenge responses and you will still have the PIN. 00:26:28.945 --> 00:26:34.842 So that's bad. What's worse is that there are a lot of collisions because the bits 00:26:34.842 --> 00:26:42.360 that are set in the challenge transformed will hide the bits that are set in the PIN 00:26:42.360 --> 00:26:49.886 transformed. So a challenge transformed with a lot of ones set will accept a lot 00:26:49.886 --> 00:26:56.020 of different PINs as proper input and result in the same response. So there is a 00:26:56.020 --> 00:27:02.431 quite simple attack we can mount here and that is that we get a challenge from the 00:27:02.431 --> 00:27:08.450 car without a valid key present and we then compute for that challenge for all 00:27:08.450 --> 00:27:14.036 PINs what response it would yield. And you will see that some PINs, sorry, some 00:27:14.036 --> 00:27:18.787 responses are generated by a lot of different PINs. It could easily be two-, 00:27:18.787 --> 00:27:23.664 three thousand PINs resulting in the same challenge. So you choose the most probable 00:27:23.664 --> 00:27:29.231 response and you send it and either the ECU accepts it and disables immobilization 00:27:29.231 --> 00:27:35.037 or it doesn't. And if it doesn't accept it, then you know for three thousand pins 00:27:35.037 --> 00:27:40.892 that it was not that. In general this takes far less than 4000 attempts and and 00:27:40.892 --> 00:27:47.546 far less than 15 minutes. I don't know exactly. I've tried it a couple of times 00:27:47.546 --> 00:27:53.813 and I've been able to deactivate immobilization, I'd say, 3 minutes once, 00:27:53.813 --> 00:28:00.410 maybe 10 minutes once. And after that, if you toggle the ignition switch, the car 00:28:00.410 --> 00:28:07.776 will actually start without transponder present. So. That was not so good. Next 00:28:07.776 --> 00:28:15.864 case is the Fiat I investigated, the Grande Punto and I reverse engineered the 00:28:15.864 --> 00:28:22.281 BCM. It's based on the NEC V850 architecture, which is a nice 32 bit RISC 00:28:22.281 --> 00:28:29.600 architecture, pretty readable, pretty fair information density. But still, I couldn't 00:28:29.600 --> 00:28:35.450 really figure out what the actual crypto part was. So I also investigated an engine 00:28:35.450 --> 00:28:41.570 control module. Surprisingly, I was able to find it there. And then I immediately 00:28:41.570 --> 00:28:48.260 went back to the V850 because that at least is readable code. Protocol is as 00:28:48.260 --> 00:29:00.350 follows: It has a 32 bit challenge, then a 4 bit - sorry - 4 byte challenge, then a 2 00:29:00.350 --> 00:29:06.470 byte proof of knowledge. And that's an interesting feature, because that way the 00:29:06.470 --> 00:29:10.820 engine control module proves to the body control module that it actually has 00:29:10.820 --> 00:29:17.030 knowledge of the key. So you can not just spam a challenge and get a get a response 00:29:17.030 --> 00:29:23.300 for that. You have to prove that you know the secret. And then you get back a 2 byte 00:29:23.300 --> 00:29:30.320 response. And if that is correct, the ECM accepts it and the car can start. And this 00:29:30.320 --> 00:29:37.640 very well, seemingly nice security feature that there is a proof of knowledge of the 00:29:37.640 --> 00:29:44.720 key is actually the flaw in this system, as it turns out. The cipher is a linear 00:29:44.720 --> 00:29:50.360 feedback shift register based cipher. It initializes the states with the key, XORed 00:29:50.360 --> 00:29:55.730 with the challenge, XORed with some constant. And then it does 38 rounds. If 00:29:55.730 --> 00:30:00.410 you don't know what an LFSR is I'll tell you in the next slide. Then it generates 00:30:00.410 --> 00:30:06.020 the proof. That is 12 rounds, actually 12 bits output. And if you look back in the 00:30:06.020 --> 00:30:11.510 protocol, you actually see that the first nibble is indeed a zero. So it's not 16 00:30:11.510 --> 00:30:17.000 bits, but it's only 12 bits. After generating the proof, it loads an 00:30:17.000 --> 00:30:22.940 additional 16 bit constant and then generates the 14 bit response. This is a 00:30:22.940 --> 00:30:28.850 very standard construction in crypto and there is a fairly standard attack to it. 00:30:28.850 --> 00:30:40.460 So what you see here is an LFSR, it's a 32 bit register and it operates in ticks. So 00:30:40.460 --> 00:30:45.170 it is loaded with this initial secret state at the beginning of the algorithm 00:30:45.170 --> 00:30:55.610 and each tick it takes 4 bits and they are XORed together. Then the whole register 00:30:55.610 --> 00:31:02.030 shifts one position to the left. So bit 0 goes to bit 1, 1 to 2, etc. Bit 31 shifts 00:31:02.030 --> 00:31:10.310 out and the previously computed XOred bit is shifted in in the 0 position. So that 00:31:10.310 --> 00:31:16.340 way it cycles and continuously updates its internal state. And then there is an 00:31:16.340 --> 00:31:22.910 output function that takes 8 bits of input and each tick it computes one bit from an 00:31:22.910 --> 00:31:29.690 8 bit input, and on the lower left you can see the output generation table. So it 00:31:29.690 --> 00:31:36.890 kind of just counts through this. And if the eight bits together add up to say A2, 00:31:36.890 --> 00:31:44.030 then you pick bit position A2 in this table and that is then the bit that is 00:31:44.030 --> 00:31:53.000 being generated as proof or response bit during that round. Now what we see here is 00:31:53.000 --> 00:32:00.560 that there is actually 8 bits of the LFSR that determine the output bit. And of 00:32:00.560 --> 00:32:12.820 these 8 bits they generate 256 different values. Now there are 256 different 00:32:12.820 --> 00:32:18.730 combinations and only half will generate the observed output bit. So that means 00:32:18.730 --> 00:32:24.790 that 128 different options may be valid options for these 8 bits to generate a 00:32:24.790 --> 00:32:30.340 response or a proof that we have observed earlier. And that is pretty interesting. 00:32:30.340 --> 00:32:37.510 And you can use that to construct a guess and determine attack. Which means that you 00:32:37.510 --> 00:32:44.500 make an assumption on the internal state. We have 128 candidate internal states. And 00:32:44.500 --> 00:32:50.170 then we do a round. So we shift the guessed bits one position to the left. We 00:32:50.170 --> 00:32:56.170 do the feedback function and then we are going to evaluate the second bit that was 00:32:56.170 --> 00:33:01.120 generated. For the second bit we already have some knowledge, because we made 00:33:01.120 --> 00:33:09.040 assumptions earlier. So the green squares designate the bits that we already know. 00:33:09.040 --> 00:33:17.260 And you see that throughout the rounds, each round you can eliminate half the 00:33:17.260 --> 00:33:21.430 candidates, because they generate the wrong output bit. And you need to guess 00:33:21.430 --> 00:33:28.630 less and less bits in order to to fill in the state. And this continuous elimination 00:33:28.630 --> 00:33:35.500 of half the candidate states makes this far more efficient than just a brute force 00:33:35.500 --> 00:33:42.490 attack. The total complexity of this attack is 2^21, which is orders of 00:33:42.490 --> 00:33:51.640 magnitude less than mounting a brute force attack. Right. So that's OK. That is 00:33:51.640 --> 00:33:58.210 fairly standard stuff in crypto. Now, there is a big problem in the way they 00:33:58.210 --> 00:34:03.690 implemented this, because they did some secret reuse. And the secret that is being 00:34:03.690 --> 00:34:12.330 used to generate the proof is in some mangled way the vehicle PIN. If you take 00:34:12.330 --> 00:34:18.510 this 32 bit secret input value and you take the 5 rightmost nibbles and then 00:34:18.510 --> 00:34:23.850 transform the letters into numbers and then replace the zeros by sevens, then you 00:34:23.850 --> 00:34:31.620 get a 5 digit number and that number is the PIN. So what we have now is an attack 00:34:31.620 --> 00:34:37.770 that observes a couple of challenges together with their proof of knowledge, 00:34:37.770 --> 00:34:44.640 which is always there, and you get it for free when you just power the ECU, and you 00:34:44.640 --> 00:34:50.670 run an attack on that. That takes, well, my not so optimized implementation takes 6 00:34:50.670 --> 00:34:57.570 seconds on a single core. You can probably do better. Runs in seconds. And what you 00:34:57.570 --> 00:35:05.400 get is the PIN. So you can still not authenticate towards the ECM, but you do 00:35:05.400 --> 00:35:09.180 get the pin which you can then use to authenticate for diagnostic services, you 00:35:09.180 --> 00:35:12.840 can, maybe, read memory, you can, maybe, reprogram stuff, you can, maybe,enter key 00:35:12.840 --> 00:35:23.160 teaching mode. There is absolutely ways to leverage this and, well, get the car to 00:35:23.160 --> 00:35:33.870 start. The 3rd case I investigated was an Opel Astra H. And I've decided to skip the 00:35:33.870 --> 00:35:38.190 crypto parts in this one because I couldn't break it and I wouldn't want to 00:35:38.190 --> 00:35:43.710 bore you with a fairly complicated algorithm and then not present an attack. 00:35:43.710 --> 00:35:48.420 If you're interested, it's in my thesis so you can look it up. But there is still 00:35:48.420 --> 00:35:56.100 some funny things to point out here. I reverse engineered an ECM that was based 00:35:56.100 --> 00:36:04.320 on a PowerPC architecture microcontroller. And that is very nice because there is a 00:36:04.320 --> 00:36:10.860 decompiler for that. And IDA Pro will nicely transform the assembly into 00:36:10.860 --> 00:36:18.270 somewhat accurate, somewhat readable C code. That was good, but it was not 00:36:18.270 --> 00:36:26.790 enough. So I purchased some tool to use the BDM interface of this ECU which was 00:36:26.790 --> 00:36:32.640 active and usable. And it took me a lot of time to get the tools working, because 00:36:32.640 --> 00:36:37.020 virtual machines were not okay, etc etc. I installed Windows and did crazy stuff. And 00:36:38.580 --> 00:36:43.920 then I was able to read memory, modify registers on the actual ECU, and that 00:36:43.920 --> 00:36:52.170 helped a great deal in debugging and finding the actual functions. So this is 00:36:52.170 --> 00:36:58.950 the protocol that I found. It has a 2 byte opcode, then 2 bytes status data, then a 4 00:36:58.950 --> 00:37:03.480 byte challenge. And similarly 2 byte opcode for the response, 2 byte status 00:37:03.480 --> 00:37:13.590 data, 4 byte response. No proof of knowledge here. Just a 32 bit to 32 bit 00:37:13.590 --> 00:37:20.400 challenge-response authentication. And what was funny when I finally uncovered 00:37:20.400 --> 00:37:26.760 the algorithm is that this is not an algorithm that was designed by Opel. It is 00:37:26.760 --> 00:37:34.440 an algorithm that is used by a security transponder. It is used by the PCF7935 00:37:34.440 --> 00:37:39.630 security transponder, which is the predecessor of high tech II, which you may 00:37:39.630 --> 00:37:47.760 be familiar with it. It uses a 128 bit secret. So that is really, really big 00:37:47.760 --> 00:37:53.790 secret, and a 32 bit internal state. When I saw that 32 bit internal state, I was 00:37:53.790 --> 00:38:01.260 like, OK, this is going to be doable. It wasn't. Because it does a lot of rounds 00:38:01.260 --> 00:38:05.910 between output moments. Not as in the FIAT case, one round, one bit output. It does 00:38:05.910 --> 00:38:11.580 34 rounds and then it outputs two bits and then it does another 34 rounds and two 00:38:11.580 --> 00:38:19.950 more bits. And during these 34 rounds, it mixes the whole 128 bit secret key into 00:38:19.950 --> 00:38:23.580 the state. There is so much distance between these moments that it is very, 00:38:23.580 --> 00:38:31.380 very hard to relate any of this information or any usable assumption that 00:38:31.380 --> 00:38:39.780 survives so much new mixing of information. I did my best. I found some 00:38:39.780 --> 00:38:44.400 stuff. Nothing that is usable to mount an attack. You can read my thesis if you're 00:38:44.400 --> 00:38:53.190 interested in the details. I found it funny to find an implementation of a 00:38:53.190 --> 00:38:57.990 security transponder in an engine. While I, In the beginning of this talk pointed 00:38:57.990 --> 00:39:03.150 out that the engine doesn't talk with the transponder. So I went back in time and I 00:39:03.150 --> 00:39:10.530 analyzed another vehicle, a Corsa Model C and found that this was different. This 00:39:10.530 --> 00:39:17.370 car had indeed an engine that talks with the key. And what probably happened is 00:39:17.370 --> 00:39:22.920 that they wanted to decouple development of engines and development of cars so they 00:39:22.920 --> 00:39:27.180 could upgrade security transponders without replacing their engines or 00:39:27.180 --> 00:39:33.210 replacing their engine firmwares. So I think that is how this happened and why 00:39:33.210 --> 00:39:39.090 they just decided to well, then implement the security transponder and emulate it in 00:39:39.090 --> 00:39:43.860 the body control module towards the engine. It seemed like a convenient 00:39:43.860 --> 00:39:49.650 solution, I guess. It is by far the strongest algorithm I have encountered in 00:39:49.650 --> 00:39:54.660 these three case studies. And while it is out of scope because I limited myself to 00:39:54.660 --> 00:39:59.700 the actual cryptographic primitives, I felt the need to point out that the random 00:39:59.700 --> 00:40:08.820 number generator is really not very good. They use the tick counter of the CPU as 00:40:08.820 --> 00:40:13.440 source of randomness and then they use a couple of constants that, if you google 00:40:13.440 --> 00:40:23.520 them, direct you to the Netscape random number generator. So summing it up: We 00:40:23.520 --> 00:40:30.870 found that Peugeot used a tiny key space with only 1.3 million different possible 00:40:30.870 --> 00:40:39.510 PIN codes. They leak a lot of information in the response. If you can inject a zero 00:40:39.510 --> 00:40:44.670 challenge, you immediately get the full secret. It has a lot of collisions, which 00:40:45.180 --> 00:40:54.210 makes it really not very robust against an adversary. Fiat has a schoolbook algorithm 00:40:54.210 --> 00:41:01.050 and it's vulnerable to schoolbook attack. It's a nice idea to implement neutral 00:41:01.050 --> 00:41:07.650 authentication, but it doesn't really work in this context. And worse, they reuse 00:41:07.650 --> 00:41:14.700 that part of the secret as the vehicle PIN as opposed to using the other part of the 00:41:14.700 --> 00:41:21.120 secret that is used to generate a response. If that would have been the 00:41:21.120 --> 00:41:28.350 vehicle PIN I would not have been able to mount this attack. And lastly, Opel 00:41:28.350 --> 00:41:34.470 decided to clone an obsolete security transponder. The successor, high tech II, 00:41:34.470 --> 00:41:41.640 was desperately broken. This one wasn't. Not by me. I have a master's degree, not 00:41:41.640 --> 00:41:46.740 in cryptanalysis. I'm not convinced that it's a secure transponder, but it is 00:41:46.740 --> 00:41:52.230 certainly better than the other two I analyzed. And also interesting is that all 00:41:52.230 --> 00:41:58.650 these three systems are still around in new vehicles. Maybe not all models, but 00:41:58.650 --> 00:42:05.400 they're still being manufactured. So I am curious to see how this relates to other 00:42:05.400 --> 00:42:12.630 manufacturers, other models. And I think it would be interesting to, well, do some 00:42:12.630 --> 00:42:19.290 further research in this domain and see what else is out there. So to finish with 00:42:19.290 --> 00:42:25.920 a few takeaways. Don't do your own crypto. It's often said and repeated. You are 00:42:25.920 --> 00:42:32.200 going to mess it up. Just use standardized cryptographic components and maybe try to 00:42:32.200 --> 00:42:38.230 get people that are actually security experts to implement it instead of hoping 00:42:38.230 --> 00:42:44.710 for the best. Don't reuse secrets. These two case studies revealed that reuse of 00:42:44.710 --> 00:42:50.710 secret made the attack much more powerful than it needed to be. Minimize the number 00:42:50.710 --> 00:42:53.980 of cryptographic protocols and cryptographic primitives that you're 00:42:53.980 --> 00:43:01.420 using. The more different primitives, the more attack surface you create for an 00:43:01.420 --> 00:43:07.240 adversary. And lastly, as I mentioned before, there has been an arms race in 00:43:07.240 --> 00:43:12.400 transponder security. How is it possible that a modern car key may be equipped with 00:43:12.400 --> 00:43:19.870 AES or other fairly secure cryptographic features, and these protocols that date 00:43:19.870 --> 00:43:26.680 from 1995 and such are still there, not replaced. Apparently no one either figured 00:43:26.680 --> 00:43:34.870 it out or there are other very important reasons to just leave them there. So I 00:43:34.870 --> 00:43:39.880 hope that was interesting. Maybe entertaining and I'll happily take any 00:43:39.880 --> 00:43:46.599 questions you have for me. 00:43:46.599 --> 00:43:47.865 *applause* 00:43:47.865 --> 00:43:51.747 Herald: Bedankt Wouter Bokslag. Thank you. You know the game if you have questions - 00:43:51.747 --> 00:43:59.308 oh, we already have questions. There are microphones, microphones number 1 to 7 and 00:43:59.308 --> 00:44:05.265 2 to 8. And the Internet has questions already. So we start with the Internet. 00:44:05.265 --> 00:44:09.019 Internet, please. Signal Angel: Why don't make cars more use 00:44:09.019 --> 00:44:13.622 of rings of security or layers or permissons system? 00:44:13.622 --> 00:44:21.453 Wouter: Oh, well, this is embedded security. This is not a PC or smartphone 00:44:21.453 --> 00:44:26.873 security. It's embedded security. And I think automotive manufacturers do their 00:44:26.873 --> 00:44:33.629 best, but this is just not their game. And yeah, there is plenty of ways you could do 00:44:33.629 --> 00:44:40.987 this in a more secure manner. But they didn't. I cannot really say, why not do it 00:44:40.987 --> 00:44:46.950 better? Of course they should do it better. But I think it's understandable 00:44:46.950 --> 00:44:53.169 that they may be a bit behind on this game that is relatively new to them. 00:44:53.169 --> 00:44:57.474 Herald: Thank you. And microphone number one. 00:44:57.474 --> 00:45:03.445 Q: Hi. Amazing work, but I have a question. Did you find any simpler, more 00:45:03.445 --> 00:45:08.725 entertaining mistakes like storing the PIN in the open, in other components in the 00:45:08.725 --> 00:45:12.870 car? Wouter: Well yeah, I did do some other 00:45:12.870 --> 00:45:18.365 stuff besides the 3 cases I presented here. I also investigated some 00:45:18.365 --> 00:45:24.066 authentication mechanisms for diagnostic functionality and I didn't put them in my 00:45:24.066 --> 00:45:30.310 thesis because it's nice to have a clear message and a clear line of research. But 00:45:30.310 --> 00:45:37.283 I've seen authentications that are really pretty hilarious, such as challenge - 00:45:37.283 --> 00:45:48.400 secrets - subtract - response. Herald: Answered? I think this is a yes. 00:45:48.400 --> 00:45:53.950 Microphone number 2, please. Q: Hey, thank you for the talk. Two short 00:45:53.950 --> 00:45:58.300 questions. How did you specifically choose those two cars, those three cars, and 00:45:58.300 --> 00:46:05.320 which parts or are parts of these flaws fixable in later firmware, bootloader, 00:46:05.320 --> 00:46:10.420 software, coding, update, whatever? Wouter: Yeah, Okay. I chose these cars 00:46:10.420 --> 00:46:16.720 mainly by availability. I didn't really cherry pick models. It was just that at 00:46:16.720 --> 00:46:23.020 the place where I was doing my internship then, I was, I had some platforms to play 00:46:23.020 --> 00:46:27.340 around with. You have seen my very professional PSA setup, that was the most 00:46:27.340 --> 00:46:35.350 professional I had. So yeah, this is what I had. And since I in the end found that 00:46:35.350 --> 00:46:43.300 they are still relevant right now, I think that wasn't really harmful in any way. It 00:46:43.300 --> 00:46:47.680 turns out to be a good choice. Your second question was? 00:46:47.680 --> 00:46:52.930 Q: Can those flaws be fixed in an update? Wouter: Oh yes. Well, in some sense, 00:46:52.930 --> 00:46:59.890 except that there is no real infrastructure to roll out updates. So all 00:46:59.890 --> 00:47:03.040 the cars that are out there, I don't think they are going to recall them to update 00:47:03.040 --> 00:47:04.165 firmwares. Q: But normal servicing... 00:47:04.165 --> 00:47:13.000 Wouter: Yeah, yeah, you can do that. It takes time. So it doesn't incur costs for 00:47:13.000 --> 00:47:18.130 the manufacturer. But what you could do, for instance, is just use timeouts in the 00:47:18.130 --> 00:47:26.860 PSA case and make sure it's not too easy to try lots of authentication attempts. 00:47:27.700 --> 00:47:32.695 It's not a fix because it doesn't really fix it. But well, it's certainly a 00:47:32.695 --> 00:47:39.460 mitigation. It somewhat limits the impact. In the Fiat case, it's a bit harder 00:47:39.460 --> 00:47:45.160 because you cannot really change an entire algorithm because there's different 00:47:45.160 --> 00:47:49.060 engines. And yeah, I think that would be quite a hassle. You really have to change 00:47:49.060 --> 00:47:51.880 your protocol there. Q: Thank you. 00:47:52.650 --> 00:47:54.900 Herald: Thank you. Microphone number five, please. 00:47:54.900 --> 00:48:01.200 Q: Are the secrets unique per car? And if so, how do you handle the case when one of 00:48:01.200 --> 00:48:06.330 the units has to get replaced? Wouter: Yeah. The secrets are unique for 00:48:06.330 --> 00:48:16.290 car and replacement frequently involves a procedure to couple the new ECU in the 00:48:16.290 --> 00:48:21.000 current system. And you just have to put the ECU there, connect to the ECU and 00:48:21.000 --> 00:48:25.350 enter the vehicle pin. So that is quite probably also the reason that they reused 00:48:25.350 --> 00:48:29.640 a secret, because if you use a different secret, you have to have some kind of 00:48:29.640 --> 00:48:37.050 complicated secret sharing protocol that well, brings the new ECU up to speed with 00:48:37.050 --> 00:48:39.720 the key material that's being used inside the vehicle. 00:48:39.720 --> 00:48:45.090 Herald: Thank you. Microphone number one, please. 00:48:45.090 --> 00:48:53.070 Q: Hello. So what I'm struggling to understand here is why there was the need 00:48:53.070 --> 00:48:58.890 to decouple the communication in the first place and just split it in two. I can 00:48:58.890 --> 00:49:03.450 guess that is so that the ECU can be trained on new keys. But then isn't it 00:49:03.450 --> 00:49:08.310 easier to just, you know, instead of training like the ECU and telling it: Hey, 00:49:08.310 --> 00:49:15.360 this is the new key's key. Just load the ECU's key on the new transponder. 00:49:15.360 --> 00:49:19.320 Wouter: So if I understand your question correctly is that you wonder why we need 00:49:19.320 --> 00:49:25.320 two different authentication systems, one for the key to BCM and one for the engine 00:49:25.320 --> 00:49:29.280 to BCM and not use the simple model of having the key talk to the engine control 00:49:29.280 --> 00:49:30.120 module. Q: That's correct. 00:49:30.120 --> 00:49:33.810 Wouter: All right. You have to understand that engine development is done by 00:49:33.810 --> 00:49:40.650 different companies and the same engine may be used in various different vehicles, 00:49:40.650 --> 00:49:49.140 maybe even from completely different ranges. And it is complicated to give 00:49:49.140 --> 00:49:55.980 these cars a different firmware. So it's definitely possible. But they just want to 00:49:55.980 --> 00:50:00.060 build an engine and build a car and have it work together. And another car with the 00:50:00.060 --> 00:50:06.660 same engine should also work. So it's, ... it has to do with their process of 00:50:06.660 --> 00:50:13.620 developing vehicles. Q: But then shouldn't also, I mean, I'm 00:50:13.620 --> 00:50:20.460 assuming that the part that talks to the transponder and talks to the engine still 00:50:20.460 --> 00:50:27.032 has to match the engine communication protocol anyway. So, I mean, doesn't the 00:50:27.032 --> 00:50:32.026 car producers still have to match the engine protocol anyway at some points 00:50:32.026 --> 00:50:35.004 anyway, so why just not implement it on the key in the first place? 00:50:35.004 --> 00:50:38.520 Wouter: Yeah. Well, this is all speculation from my side as well. I have 00:50:38.520 --> 00:50:45.620 no inside information as to why they did this. But yeah, I can imagine ways that 00:50:45.620 --> 00:50:53.598 they could fix this and they don't do it. And my experience is that generally this 00:50:53.598 --> 00:50:59.842 has to do with legacy and compatibility issues. They could also just embed five 00:50:59.842 --> 00:51:05.549 algorithms in the BCM or the engine control module and just by configuration 00:51:05.549 --> 00:51:10.852 choose the one that fits for that vehicle. I have no idea why they don't do that. But 00:51:10.852 --> 00:51:15.496 once again, these are not software companies. These are automotive companies. 00:51:15.496 --> 00:51:18.901 Q: Awesome. Thanks. Herald: Thank you. Microphone number 00:51:18.901 --> 00:51:23.151 three, please. Q: Thank you for the great talk. Once we 00:51:23.151 --> 00:51:29.570 have the OBD connected to the Internet and do you see any other complication that 00:51:29.570 --> 00:51:33.910 could prevent me to park the car remotely from there? 00:51:33.910 --> 00:51:43.391 Wouter: OBD connected to the Internet... Now well, no. Why? Once you have OBD 00:51:43.391 --> 00:51:53.079 access so you can use the OBD port you can do a lot. There are cars that use a 00:51:53.079 --> 00:51:59.203 gateway that is some kind of filter or you have to authenticate towards it before you 00:51:59.203 --> 00:52:02.975 can access the internals of the vehicle. So it really depends on the model. It 00:52:02.975 --> 00:52:07.995 depends on the manufacturer to which extent you have room to maneuver there. 00:52:07.995 --> 00:52:12.777 For some, it would be super easy, for some it would be a lot of work. For some, it 00:52:12.777 --> 00:52:17.288 might be impossible. But you certainly have a very, very good starting point. 00:52:17.288 --> 00:52:21.300 Q: Thank you. Herald: Microphone number one, please. 00:52:21.300 --> 00:52:26.676 Q: Hello. Did you spot any kind of anti- brute force measures during your analyses? 00:52:26.676 --> 00:52:30.678 That's the question number one. And question number two is: Obviously you had 00:52:30.678 --> 00:52:35.960 access to the internal communication between the BCM and ECM, but were those 00:52:35.960 --> 00:52:42.332 attacks successful on Fiat and Peugeot, are they doable using just the OBD-II 00:52:42.332 --> 00:52:47.127 port? Or do you actually need to see the internal communications? 00:52:47.127 --> 00:52:52.589 Wouter: I tried to point out in the beginning of my talk that I carry out all 00:52:52.589 --> 00:52:59.361 the attacks presented and I focused only on functionality that is exposed through 00:52:59.361 --> 00:53:05.307 OBD. So, yes, I did some stuff on the hardware of the ECUs, but that was just 00:53:05.307 --> 00:53:10.424 for research. So the attacks are absolutely doable over OBD. 00:53:10.424 --> 00:53:16.738 Q: OK, and the previous question there, which was already partially answered. 00:53:16.738 --> 00:53:21.049 Wouter: Yes. Q: So no, like, locking out after five 00:53:21.049 --> 00:53:26.615 failed trials? Wouter: I did find something that was 00:53:26.615 --> 00:53:36.668 peculiar in the PSA case, and that is that if you... let me think. There is rate 00:53:36.668 --> 00:53:45.562 limiting implemented in the PSA on the engine control module. Is that right? No, 00:53:45.562 --> 00:53:51.957 on the body control module. And that means that if you spam challenges, it will at 00:53:51.957 --> 00:53:57.440 some point no longer give you the response, which sounds like a good idea, 00:53:57.440 --> 00:54:01.803 right? Rate limiting. But they did it on the wrong side. 00:54:01.803 --> 00:54:06.136 Q: Okay, great. Thank you. Herald: Thank you. Microphone number two, 00:54:06.136 --> 00:54:08.610 please. Q: Have you spotted some kinds of 00:54:08.610 --> 00:54:13.478 relationship between this, like public identifier of the car and the secret used 00:54:13.478 --> 00:54:20.555 to authenticate in the service? Wouter: Yeah, so if the VIN in some ways 00:54:20.555 --> 00:54:28.609 could be converted in the secret, the PIN code of the car. No, I see where you're 00:54:28.609 --> 00:54:31.991 headed, but I haven't spotted anything like that. 00:54:31.991 --> 00:54:35.253 Q: Okay. Thanks. Herald: Questions from the Internet? 00:54:35.253 --> 00:54:40.545 Signal Angel: No more. Herald: No more. In this case, ladies and 00:54:40.545 --> 00:54:58.635 gentlemen, bedankt Wouter Bokslag. Thank you very much. 00:54:58.635 --> 00:55:13.200 *applause* 00:55:13.200 --> 00:55:17.815 *postroll music*