1 00:00:00,000 --> 00:00:17,287 Herald: The second thing I wanted to announce: there is no scooter sharing. 2 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 3 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 4 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 5 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. 6 00:00:58,358 --> 00:01:06,599 A third option would be an immobilization system. We have Wouter Bokslag. Thank you. 7 00:01:06,599 --> 00:01:10,800 *applause* 8 00:01:10,800 --> 00:01:15,665 Wouter: Hi. Thank you for the introduction. Thank you guys for the warm 9 00:01:15,665 --> 00:01:20,636 welcome. I'm really happy to see that still some people have come together here 10 00:01:20,636 --> 00:01:27,897 at this ungodly hour to watch my talk about vehicle immobilization. Well, 11 00:01:27,897 --> 00:01:34,402 briefly something about me. I'm a Kerckhoff security master. And the 12 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 13 00:01:41,311 --> 00:01:47,199 half a year analyzing various systems and I wrote something about that. And if you 14 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 15 00:01:53,755 --> 00:01:58,966 time now. And there's more detail there. I'm currently working as an automotive 16 00:01:58,966 --> 00:02:05,500 engineer. And if you feel like asking me questions besides the Q&A, you can always 17 00:02:05,500 --> 00:02:12,545 contact me by mail. So first, responsible disclosure. This kind of stuff is not a 18 00:02:12,545 --> 00:02:19,522 joke. Automotive manufacturers think it is very important. And, well, they have a 19 00:02:19,522 --> 00:02:27,555 reason to think so. So naturally we contacted them ahead of publication even 20 00:02:27,555 --> 00:02:35,229 before my defense and we laid out the findings and I had a couple of conference 21 00:02:35,229 --> 00:02:42,959 calls with the manufacturers. And I even went to one of them to demonstrate the 22 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 23 00:02:50,715 --> 00:02:57,598 old vehicles like 2009 and around. But for the three cases that I really went in 24 00:02:57,598 --> 00:03:04,155 depth we have been able to confirm that they are still in currently produced 25 00:03:04,155 --> 00:03:09,012 models. So this in itself is kind of surprising because you think automotive, 26 00:03:09,012 --> 00:03:15,702 cars, electronics, security, it's a fast moving industry, but well, no, not really. 27 00:03:15,702 --> 00:03:22,097 So everything that was in cars in 2009, at least regarding to these three systems, 28 00:03:22,097 --> 00:03:27,575 can still be found in currently produced models. I will disclose the vehicles that 29 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 30 00:03:34,003 --> 00:03:38,786 that I'm not going to disclose the vehicles that I have identified these 31 00:03:38,786 --> 00:03:43,815 systems in that are still being produced. I'm not really into facilitating theft and 32 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: 33 00:03:50,775 --> 00:03:58,003 I will first introduce some standard stuff about immobilization systems and about 34 00:03:58,003 --> 00:04:04,801 computer networks inside vehicles. I will tell you something about how I addressed 35 00:04:04,801 --> 00:04:10,905 the challenge. So for all three models, I kind of followed a similar approach and I 36 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. 37 00:04:16,119 --> 00:04:21,472 And then I will present the three protocols that I uncovered in a Peugeot, a 38 00:04:21,472 --> 00:04:27,190 Fiat and an Opel vehicle. I will then summarize the findings in a series of 39 00:04:27,190 --> 00:04:34,735 takeaways and there will be some time for questions. Right. So modern vehicles are 40 00:04:34,735 --> 00:04:41,376 full of electronics and full of computer systems. They operate largely independent. 41 00:04:41,376 --> 00:04:47,348 They are all connected through a variety of different buses that talk to each other 42 00:04:47,348 --> 00:04:53,473 with different protocols. And there is a plethora of different standards, ISO 43 00:04:53,473 --> 00:04:59,061 standards, all kinds of standards. And then the manufacturer wants a lot of 44 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 45 00:05:05,007 --> 00:05:11,923 pages of standards, still every vehicle you will look at will be kind of 46 00:05:11,923 --> 00:05:20,109 different. There are some practical handles that you can use, and one of them 47 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 48 00:05:29,591 --> 00:05:38,185 and in Europe for quite some time now. And it needs to be conveniently located and 49 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 50 00:05:44,830 --> 00:05:50,176 with a combustion engine need to have one. And cars with electronic engines also need 51 00:05:50,176 --> 00:05:55,764 to have one. But the functionality that has to be implemented is much more 52 00:05:55,764 --> 00:06:04,210 limited. So in regular internal combustion engine powered cars, you have to be able 53 00:06:04,210 --> 00:06:10,654 to read out emissions data and that kind of stuff. So many manufacturers felt this 54 00:06:10,654 --> 00:06:17,156 was a very convenient thing to also use for garage purposes, for workshops to read 55 00:06:17,156 --> 00:06:23,753 out error codes, to perform all kinds of routines on vehicles. You might need to 56 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 57 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 58 00:06:35,724 --> 00:06:42,340 has a towbar. Depends on the vehicle, but telling this to 5 individual ECUs is not 59 00:06:42,340 --> 00:06:48,671 an exception. And since it is a bus, the CAN bus, it can be directly addressed 60 00:06:48,671 --> 00:06:53,995 through the OBD connector on many vehicles and you can talk to a lot of different 61 00:06:53,995 --> 00:06:59,437 components. So the ECM, the Engine Control Module, is one, the body control module is 62 00:06:59,437 --> 00:07:04,833 another. That one controls, for instance, powered windows and all kinds of interior 63 00:07:04,833 --> 00:07:13,538 stuff, but also the airbag, infotainment system, fancy interior lighting, stability 64 00:07:13,538 --> 00:07:21,880 control systems. Another feature of it being a bus is that you can also see the 65 00:07:21,880 --> 00:07:28,461 inter-component communication. So if the instrument panel cluster, the dashboard, 66 00:07:28,461 --> 00:07:36,074 needs to talk to, say, the body control module, you can see that packet going over 67 00:07:36,074 --> 00:07:42,505 the CAN bus. All my research has been focused on this OBD-II connector and what 68 00:07:42,505 --> 00:07:49,171 you can do and what you can see from this perspective. Immobilizer systems are 69 00:07:49,171 --> 00:07:56,406 nowadays required to be implemented in vehicles. Since the late 90s, legislation 70 00:07:56,406 --> 00:08:02,620 has been adopted in both the States and Europe, mandating the use of an electronic 71 00:08:02,620 --> 00:08:09,699 immobilization system. And the purpose, of course, was to reduce the risk of theft. 72 00:08:09,699 --> 00:08:17,003 This is proven to be effective: According to one study, theft rates dropped by 73 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 74 00:08:26,010 --> 00:08:33,831 theft used to be quite simple. You could just put two wires together and you could 75 00:08:33,831 --> 00:08:39,123 power the starting circuit and you could actually start the engine. And the 76 00:08:39,123 --> 00:08:45,232 immobilizer system adds another step to that. The engine control module that 77 00:08:45,232 --> 00:08:50,956 finally controls the engine wants to have some kind of assurance that the key 78 00:08:50,956 --> 00:08:55,854 presented in the system is actually valid and does so by validating a security 79 00:08:55,854 --> 00:09:01,741 transponder. First generations of these security transponders have been widely 80 00:09:01,741 --> 00:09:08,121 studied and often were found insecure. Of course this is a problem because well, if 81 00:09:08,121 --> 00:09:13,275 it's insecure, it doesn't add any security and cars can be stolen nonetheless. So 82 00:09:13,275 --> 00:09:17,715 there has been kind of an arms race in this domain and we see that nowadays 83 00:09:17,715 --> 00:09:24,086 security transponders have become a lot better. Your car might even use AES to 84 00:09:24,086 --> 00:09:31,622 validate that the key you're putting in the ignition is an actual key that is 85 00:09:31,622 --> 00:09:37,710 recognized by your vehicle. And this is really necessary because car thieves have 86 00:09:37,710 --> 00:09:43,210 shown to be able to wield quite high tech solutions, procure them from shady 87 00:09:43,210 --> 00:09:51,436 companies or just use official tools that can be used in illegitimate ways. A nice 88 00:09:51,436 --> 00:09:58,051 example of this is shown here. For certain models of Range Rover, they have a blind 89 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 90 00:10:03,930 --> 00:10:09,498 a cap, then you can connect a 12V battery, power the internal ECUs of the vehicle. 91 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 92 00:10:15,293 --> 00:10:20,865 blank key to the window and it will program the key and recognize it as a 93 00:10:20,865 --> 00:10:24,564 valid key. Well, needless to say, this was not intended behavior 94 00:10:24,564 --> 00:10:27,706 *laughter* 95 00:10:27,706 --> 00:10:33,252 and this has had consequences for consumers. Because insurance companies saw 96 00:10:33,252 --> 00:10:38,892 a rise in theft for these models - these are quite expensive cars - and they 97 00:10:38,892 --> 00:10:45,363 started adding demands before they would allow you to insure your car. So the 98 00:10:45,363 --> 00:10:51,068 insurance would get more expensive or you would not be able to get the insurance if 99 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 100 00:10:57,494 --> 00:11:05,350 common misconception about how immobilizer systems work, and it's actually one of the 101 00:11:05,350 --> 00:11:10,090 reasons I want to give this talk and present this, because I think it's 102 00:11:10,090 --> 00:11:16,611 important to realize that an immobilizer system is a bit more complicated than the 103 00:11:16,611 --> 00:11:23,435 single cryptographic step that seems logical. So what you might think is that 104 00:11:23,435 --> 00:11:28,253 the engine control module sends a challenge to the body control module, 105 00:11:28,253 --> 00:11:34,276 which communicates with the key. It implements the radio layer and it can then 106 00:11:34,276 --> 00:11:41,217 relay the challenge to the key. The key can compute the proper response based on a 107 00:11:41,217 --> 00:11:47,103 secret it shares with ECM, send back the response, which the BCM will in turn 108 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 109 00:11:52,998 --> 00:11:58,564 right response, immobilization is deactivated and the car can start. Sounds 110 00:11:58,564 --> 00:12:05,995 good. Sounds easy, but this is in modern cars no longer the case. 'course. What we 111 00:12:05,995 --> 00:12:12,960 see is that there is a second step. The ECM does an authentication with the BCM. 112 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 113 00:12:20,215 --> 00:12:28,450 authentication, then this will be an AES secured authentication between the BCM and 114 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 115 00:12:34,307 --> 00:12:38,916 correct response to the engine control module. But this is a whole different 116 00:12:38,916 --> 00:12:45,195 protocol, using different cryptographic primitives, using different keys, 117 00:12:45,195 --> 00:12:52,529 sometimes, often, don't know. And more importantly, it has not yet been covered. 118 00:12:52,529 --> 00:12:58,335 So in the scientific literature, I have found absolutely zero reference of this 119 00:12:58,335 --> 00:13:04,188 step being identified. And here and there you find a reference that people know that 120 00:13:04,188 --> 00:13:10,796 this happens, but no actual analysis of the security or the cryptographic 121 00:13:10,796 --> 00:13:18,552 primitives involved. Right. So that is an open question then and asks for further 122 00:13:18,552 --> 00:13:24,811 research. So how do you do that? You can sniff CAN traffic from the OBD connector 123 00:13:24,811 --> 00:13:31,989 with tooling. And by disconnecting ECUs and placing yourself in the middle you can 124 00:13:31,989 --> 00:13:38,577 also modify CAN traffic. You can analyze this CAN traffic, see if you can find 125 00:13:38,577 --> 00:13:44,317 immobilizer-related messages. And of course, by the messages, you cannot deduce 126 00:13:44,317 --> 00:13:48,816 the algorithm, most of the time. So you will need a firmware image or something 127 00:13:48,816 --> 00:13:54,063 else you can reverse engineer to actually find the code that does the magic stuff. 128 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 129 00:13:59,379 --> 00:14:04,652 can start looking at if it's actually decent. And once you are all there you 130 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 131 00:14:10,697 --> 00:14:15,299 it's actually working as you think it's working. So the first step, protocol 132 00:14:15,299 --> 00:14:19,882 identification, is actually quite straightforward because you have some 133 00:14:19,882 --> 00:14:26,465 knowledge. You know that this is a message exchange that happens when you switch the 134 00:14:26,465 --> 00:14:32,424 ignition to the on position. And you know that there must be at least two high 135 00:14:32,424 --> 00:14:37,351 entropy messages because the challenge has to be different every time. And the 136 00:14:37,351 --> 00:14:40,973 response is the output of some cryptographic function. So it may be 137 00:14:40,973 --> 00:14:46,370 expected that that looks quite random, too. Also, if you switch the ignition on 138 00:14:46,370 --> 00:14:52,127 but no valid transponder is present, you should be able to detect some kind of 139 00:14:52,127 --> 00:14:55,925 difference. And it will probably be the very first moment you observe a 140 00:14:55,925 --> 00:15:01,041 difference, because before that point, the car didn't know there was no valid 141 00:15:01,041 --> 00:15:06,567 transponder. So with a bit of fiddling and some patience and going through CAN 142 00:15:06,567 --> 00:15:12,510 traffic logs, you can probably find this. OK. Next step is to get a firmware image 143 00:15:12,510 --> 00:15:19,094 in which you hope to be able to find the actual cryptographic protocol. So there 144 00:15:19,094 --> 00:15:24,785 are several options. Of course you already have the firmware, but it's in the 145 00:15:24,785 --> 00:15:30,705 microcontroller in an ECU that is either lying on your desk or inside some vehicle. 146 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 147 00:15:38,190 --> 00:15:44,879 option. You have JTAG, you have BDM, UART occasionally can be used, but sometimes 148 00:15:44,879 --> 00:15:49,854 these are deactivated. Sometimes it just doesn't seem to work. Sometimes the 149 00:15:49,854 --> 00:15:55,038 tooling is prohibitively expensive. So if that doesn't work, you can always go to 150 00:15:55,038 --> 00:16:00,314 the internet. Some manufacturers provide a means to download a set of information 151 00:16:00,314 --> 00:16:06,900 about the vehicle based on its VIN number. You can find all kinds of configurations, 152 00:16:06,900 --> 00:16:13,095 you might be able to find actual parts or full firmwares, often encrypted, not 153 00:16:13,095 --> 00:16:18,510 always. And then there is the tuning scene. And while you might think of neon 154 00:16:18,510 --> 00:16:23,273 lighting and stuff like that, these guys are actually pretty knowledgeable about 155 00:16:23,273 --> 00:16:28,485 the internals of engine control modules in particular. And you might just be able to 156 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 157 00:16:34,716 --> 00:16:40,312 this is kind of a viable approach to getting your hands on the firmware. But 158 00:16:40,312 --> 00:16:45,008 also very practical can be to just leverage the functionality that is 159 00:16:45,008 --> 00:16:51,555 implemented in the ECU. The ECU allows for diagnostic commands such as read memory by 160 00:16:51,555 --> 00:16:59,925 address and request upload, which from the perspective of an ECU is sending new data. 161 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 162 00:17:07,405 --> 00:17:13,820 least parts of the the internals of the ECU. Then there is some kind of mechanism 163 00:17:13,820 --> 00:17:19,688 that's called second bootloader. It's a sort of standard. Not every manufacturer 164 00:17:19,688 --> 00:17:26,495 implements it, but quite some do. That allows you to actually send binary code to 165 00:17:26,495 --> 00:17:33,621 the ECU. And it then jumps to it. So very convenient functionality. It's maybe very 166 00:17:33,621 --> 00:17:38,599 painstaking to get it working, but yeah, it's basically free code execution. Except 167 00:17:38,599 --> 00:17:42,919 for the fact that you often need to authenticate before you're allowed to use 168 00:17:42,919 --> 00:17:47,018 such functionality. So that might leave you with some kind of chicken and egg 169 00:17:47,018 --> 00:17:51,225 problem, because you don't know how to authenticate, you don't have the algorithm 170 00:17:51,225 --> 00:17:56,411 for this authentication. And lastly, there are sometimes firmware updates for ECUs 171 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 172 00:18:02,685 --> 00:18:08,614 CAN traffic. Multiple ways of trying to update the firmware on your ECU 173 00:18:08,614 --> 00:18:12,931 reconstructed from the CAN traffic. Once more, you have to go through an ISO 174 00:18:12,931 --> 00:18:18,116 standard before you understand how it's exactly chunked in 8 byte messages, but 175 00:18:18,116 --> 00:18:25,160 you'll get there eventually. So once you have this firmware, you have to pinpoint 176 00:18:25,160 --> 00:18:30,091 the cryptographic algorithm and ECU firmwares are typically between half a 177 00:18:30,091 --> 00:18:35,058 megabyte and 2 megabytes. And that is a lot, if we're talking assembly. And the 178 00:18:35,058 --> 00:18:41,184 information density is extremely low. And if you have to go through it line by line, 179 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 180 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 181 00:18:51,473 --> 00:18:56,365 focus during this talk, but a couple of pointers. Maybe someone is helped by that. 182 00:18:56,365 --> 00:19:01,168 Of course, you know the protocol because you have observed CAN traffic. So you can 183 00:19:01,168 --> 00:19:07,183 search for immediate values, for numerical values that are used in the protocol to 184 00:19:07,183 --> 00:19:13,815 designate a packet type, for instance. It must be in the firmware somewhere. Also, 185 00:19:13,815 --> 00:19:18,706 you know that crypto usually uses XOR instructions and you would be surprised 186 00:19:18,706 --> 00:19:23,549 how little XOR instructions there are in a firmware. Depending on the architecture, 187 00:19:23,549 --> 00:19:28,341 you might immediately dismiss most of those as a single bit flip or maybe 188 00:19:28,341 --> 00:19:34,288 inversion of a whole register, and then you will find some XORs with either weird 189 00:19:34,288 --> 00:19:40,340 constants or variables. So those are points to focus on. Lastly, you can make 190 00:19:40,340 --> 00:19:46,912 some assumptions on the structure of the cryptographic function, so it certainly 191 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 192 00:19:53,033 --> 00:19:57,909 function once or twice, maybe some initialization. It will probably have some 193 00:19:57,909 --> 00:20:03,530 loops and you can sometimes recognize the length of the challenge. You can sometimes 194 00:20:03,530 --> 00:20:09,041 recognize the length of the response. That being said, let's dive in the first case 195 00:20:09,041 --> 00:20:15,569 study. So I reverse engineered the Peugeot 207, which is, as I said, not the most 196 00:20:15,569 --> 00:20:21,620 recent of vehicles. And this was my test setup. It doesn't look like much, but 197 00:20:21,620 --> 00:20:27,412 everything that's relevant to me is there. And you can toggle the ignition and lights 198 00:20:27,412 --> 00:20:32,430 will show and all the ECUs are connected through a CAN bus and an OBD connector 199 00:20:32,430 --> 00:20:39,220 that you can see on the left side of the instrument panel. And I investigated a 200 00:20:39,220 --> 00:20:46,445 tool that had a kind of peculiar function and that is that you could obtain the 201 00:20:46,445 --> 00:20:51,065 vehicle PIN - some kind of secret you needed to authenticate for diagnostics - 202 00:20:51,065 --> 00:20:56,499 by connecting this tool and toggling the ignition a couple of times. So that kind 203 00:20:56,499 --> 00:21:00,860 of gives you a hunch that the immobilization system might be involved, 204 00:21:00,860 --> 00:21:07,215 because it's triggered upon toggling the ignition, and that you can derive in some 205 00:21:07,215 --> 00:21:14,560 way the vehicle pin from this. So for this Peugeot and for most BSA vehicles in 206 00:21:14,560 --> 00:21:21,222 general, the PIN is a four digit uppercase and numeric code excluding the O and I, 207 00:21:21,222 --> 00:21:27,190 because that would be confusing. So that leaves us with roughly one point three 208 00:21:27,190 --> 00:21:33,826 million keys, which is nothing in terms of crypto. I finally reversed the algorithm. 209 00:21:33,826 --> 00:21:40,557 It is obviously in the engine control module and the body control module. And 210 00:21:40,557 --> 00:21:46,025 the main part looked like, oh wait, wait for it. And the protocol looks like this. 211 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 212 00:21:51,935 --> 00:21:58,675 sent a message that starts with 00 and then followed by a 4 byte challenge. And 213 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 214 00:22:04,827 --> 00:22:11,880 and a four byte response. So this is a very small, straightforward protocol, 215 00:22:11,880 --> 00:22:19,520 which, well, does the bare necessary. And one of the first things I did was 216 00:22:19,520 --> 00:22:25,129 injecting challenges. Just inject a challenge, send it to the BCM with a valid 217 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, 218 00:22:30,362 --> 00:22:37,858 you see that there's an extremely apparent pattern is visible. So the ideal case that 219 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 220 00:22:45,602 --> 00:22:51,992 response bit is not exactly respected. You see that the effect of changing the 221 00:22:51,992 --> 00:22:58,310 challenge has a very localized effect on the response. Another weird feature, which 222 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 223 00:23:04,359 --> 00:23:10,389 average, when you give average just random challenges, 75% of the bits of the 224 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 225 00:23:16,385 --> 00:23:23,430 to me what kind of cryptographic primitive would exhibit such behavior. And then it 226 00:23:23,430 --> 00:23:30,576 became clear. this is the main function of the algorithm and there is a transform 227 00:23:30,576 --> 00:23:36,950 function that I left out, but it basically does some multiplication, some division, 228 00:23:36,950 --> 00:23:43,265 some modulo, mathematical operations, It splits the challenge in two parts and it 229 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 230 00:23:49,742 --> 00:23:55,523 all used as inputs for this transform function and we obtain a challenge 231 00:23:55,523 --> 00:24:02,135 transformed left challenge transformed right and similarly for the PIN a left and 232 00:24:02,135 --> 00:24:08,456 right transformed part. And then something interesting happens because the left 233 00:24:08,456 --> 00:24:14,692 transformed part of the challenge is ORed with a part of the PIN. And an OR 234 00:24:14,692 --> 00:24:24,713 operation will lead to a, well, on average 75% set result. So that kind of explains 235 00:24:24,713 --> 00:24:34,005 the weird behavior we saw before. Strange and maybe not so smart, because an 236 00:24:34,005 --> 00:24:41,900 adversary will be able to either control or observe the challenge that is used as 237 00:24:41,900 --> 00:24:47,755 input for this algorithm. So if you know the challenge, you know the transform 238 00:24:47,755 --> 00:24:52,263 challenge, and if you know to transform challenge, you know something about the 239 00:24:52,263 --> 00:24:59,672 output. Because if the transform challenge has a one bit, then the response will have 240 00:24:59,672 --> 00:25:05,755 a one bit in that same position. There is another property for the transform 241 00:25:05,755 --> 00:25:10,285 function, and that is that if the input is a zero, the further parameters of 242 00:25:10,285 --> 00:25:16,105 transform vary a bit, but it doesn't affect this property: if the input is a 243 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 244 00:25:22,132 --> 00:25:27,872 zeros, you will obtain a transform challenge of all zeros. And that means 245 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 246 00:25:33,808 --> 00:25:41,104 entirely determined by the transformed PIN. Then another property is that the 247 00:25:41,104 --> 00:25:47,883 PIN, which is an alphanumeric PIN, is invertable once. Let me restart. 248 00:25:47,883 --> 00:25:58,365 Transform: If it takes a PIN as input, then the output can be inverted. There is 249 00:25:58,365 --> 00:26:04,608 only one PIN part input that maps to one output of the transform function. So if 250 00:26:04,608 --> 00:26:09,906 you are able to supply the vehicle with a challenge of zeros, you will get one 251 00:26:09,906 --> 00:26:14,730 response and you can uniquely identify the secret of the car, the PIN. And this PIN 252 00:26:14,730 --> 00:26:19,224 can later be used to, for instance, authenticate for diagnostics or key 253 00:26:19,224 --> 00:26:24,013 teaching or whatever you want. If you're not able to control the challenge, you can 254 00:26:24,013 --> 00:26:28,945 just collect a couple of random challenge responses and you will still have the PIN. 255 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 256 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 257 00:26:42,360 --> 00:26:49,886 transformed. So a challenge transformed with a lot of ones set will accept a lot 258 00:26:49,886 --> 00:26:56,020 of different PINs as proper input and result in the same response. So there is a 259 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 260 00:27:02,431 --> 00:27:08,450 car without a valid key present and we then compute for that challenge for all 261 00:27:08,450 --> 00:27:14,036 PINs what response it would yield. And you will see that some PINs, sorry, some 262 00:27:14,036 --> 00:27:18,787 responses are generated by a lot of different PINs. It could easily be two-, 263 00:27:18,787 --> 00:27:23,664 three thousand PINs resulting in the same challenge. So you choose the most probable 264 00:27:23,664 --> 00:27:29,231 response and you send it and either the ECU accepts it and disables immobilization 265 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 266 00:27:35,037 --> 00:27:40,892 that it was not that. In general this takes far less than 4000 attempts and and 267 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 268 00:27:47,546 --> 00:27:53,813 and I've been able to deactivate immobilization, I'd say, 3 minutes once, 269 00:27:53,813 --> 00:28:00,410 maybe 10 minutes once. And after that, if you toggle the ignition switch, the car 270 00:28:00,410 --> 00:28:07,776 will actually start without transponder present. So. That was not so good. Next 271 00:28:07,776 --> 00:28:15,864 case is the Fiat I investigated, the Grande Punto and I reverse engineered the 272 00:28:15,864 --> 00:28:22,281 BCM. It's based on the NEC V850 architecture, which is a nice 32 bit RISC 273 00:28:22,281 --> 00:28:29,600 architecture, pretty readable, pretty fair information density. But still, I couldn't 274 00:28:29,600 --> 00:28:35,450 really figure out what the actual crypto part was. So I also investigated an engine 275 00:28:35,450 --> 00:28:41,570 control module. Surprisingly, I was able to find it there. And then I immediately 276 00:28:41,570 --> 00:28:48,260 went back to the V850 because that at least is readable code. Protocol is as 277 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 278 00:29:00,350 --> 00:29:06,470 byte proof of knowledge. And that's an interesting feature, because that way the 279 00:29:06,470 --> 00:29:10,820 engine control module proves to the body control module that it actually has 280 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 281 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 282 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 283 00:29:30,320 --> 00:29:37,640 very well, seemingly nice security feature that there is a proof of knowledge of the 284 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 285 00:29:44,720 --> 00:29:50,360 feedback shift register based cipher. It initializes the states with the key, XORed 286 00:29:50,360 --> 00:29:55,730 with the challenge, XORed with some constant. And then it does 38 rounds. If 287 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 288 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 289 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 290 00:30:11,510 --> 00:30:17,000 bits, but it's only 12 bits. After generating the proof, it loads an 291 00:30:17,000 --> 00:30:22,940 additional 16 bit constant and then generates the 14 bit response. This is a 292 00:30:22,940 --> 00:30:28,850 very standard construction in crypto and there is a fairly standard attack to it. 293 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 294 00:30:40,460 --> 00:30:45,170 it is loaded with this initial secret state at the beginning of the algorithm 295 00:30:45,170 --> 00:30:55,610 and each tick it takes 4 bits and they are XORed together. Then the whole register 296 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 297 00:31:02,030 --> 00:31:10,310 out and the previously computed XOred bit is shifted in in the 0 position. So that 298 00:31:10,310 --> 00:31:16,340 way it cycles and continuously updates its internal state. And then there is an 299 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 300 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 301 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, 302 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 303 00:31:44,030 --> 00:31:53,000 being generated as proof or response bit during that round. Now what we see here is 304 00:31:53,000 --> 00:32:00,560 that there is actually 8 bits of the LFSR that determine the output bit. And of 305 00:32:00,560 --> 00:32:12,820 these 8 bits they generate 256 different values. Now there are 256 different 306 00:32:12,820 --> 00:32:18,730 combinations and only half will generate the observed output bit. So that means 307 00:32:18,730 --> 00:32:24,790 that 128 different options may be valid options for these 8 bits to generate a 308 00:32:24,790 --> 00:32:30,340 response or a proof that we have observed earlier. And that is pretty interesting. 309 00:32:30,340 --> 00:32:37,510 And you can use that to construct a guess and determine attack. Which means that you 310 00:32:37,510 --> 00:32:44,500 make an assumption on the internal state. We have 128 candidate internal states. And 311 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 312 00:32:50,170 --> 00:32:56,170 do the feedback function and then we are going to evaluate the second bit that was 313 00:32:56,170 --> 00:33:01,120 generated. For the second bit we already have some knowledge, because we made 314 00:33:01,120 --> 00:33:09,040 assumptions earlier. So the green squares designate the bits that we already know. 315 00:33:09,040 --> 00:33:17,260 And you see that throughout the rounds, each round you can eliminate half the 316 00:33:17,260 --> 00:33:21,430 candidates, because they generate the wrong output bit. And you need to guess 317 00:33:21,430 --> 00:33:28,630 less and less bits in order to to fill in the state. And this continuous elimination 318 00:33:28,630 --> 00:33:35,500 of half the candidate states makes this far more efficient than just a brute force 319 00:33:35,500 --> 00:33:42,490 attack. The total complexity of this attack is 2^21, which is orders of 320 00:33:42,490 --> 00:33:51,640 magnitude less than mounting a brute force attack. Right. So that's OK. That is 321 00:33:51,640 --> 00:33:58,210 fairly standard stuff in crypto. Now, there is a big problem in the way they 322 00:33:58,210 --> 00:34:03,690 implemented this, because they did some secret reuse. And the secret that is being 323 00:34:03,690 --> 00:34:12,330 used to generate the proof is in some mangled way the vehicle PIN. If you take 324 00:34:12,330 --> 00:34:18,510 this 32 bit secret input value and you take the 5 rightmost nibbles and then 325 00:34:18,510 --> 00:34:23,850 transform the letters into numbers and then replace the zeros by sevens, then you 326 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 327 00:34:31,620 --> 00:34:37,770 that observes a couple of challenges together with their proof of knowledge, 328 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 329 00:34:44,640 --> 00:34:50,670 run an attack on that. That takes, well, my not so optimized implementation takes 6 330 00:34:50,670 --> 00:34:57,570 seconds on a single core. You can probably do better. Runs in seconds. And what you 331 00:34:57,570 --> 00:35:05,400 get is the PIN. So you can still not authenticate towards the ECM, but you do 332 00:35:05,400 --> 00:35:09,180 get the pin which you can then use to authenticate for diagnostic services, you 333 00:35:09,180 --> 00:35:12,840 can, maybe, read memory, you can, maybe, reprogram stuff, you can, maybe,enter key 334 00:35:12,840 --> 00:35:23,160 teaching mode. There is absolutely ways to leverage this and, well, get the car to 335 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 336 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 337 00:35:38,190 --> 00:35:43,710 bore you with a fairly complicated algorithm and then not present an attack. 338 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 339 00:35:48,420 --> 00:35:56,100 some funny things to point out here. I reverse engineered an ECM that was based 340 00:35:56,100 --> 00:36:04,320 on a PowerPC architecture microcontroller. And that is very nice because there is a 341 00:36:04,320 --> 00:36:10,860 decompiler for that. And IDA Pro will nicely transform the assembly into 342 00:36:10,860 --> 00:36:18,270 somewhat accurate, somewhat readable C code. That was good, but it was not 343 00:36:18,270 --> 00:36:26,790 enough. So I purchased some tool to use the BDM interface of this ECU which was 344 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 345 00:36:32,640 --> 00:36:37,020 virtual machines were not okay, etc etc. I installed Windows and did crazy stuff. And 346 00:36:38,580 --> 00:36:43,920 then I was able to read memory, modify registers on the actual ECU, and that 347 00:36:43,920 --> 00:36:52,170 helped a great deal in debugging and finding the actual functions. So this is 348 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 349 00:36:58,950 --> 00:37:03,480 byte challenge. And similarly 2 byte opcode for the response, 2 byte status 350 00:37:03,480 --> 00:37:13,590 data, 4 byte response. No proof of knowledge here. Just a 32 bit to 32 bit 351 00:37:13,590 --> 00:37:20,400 challenge-response authentication. And what was funny when I finally uncovered 352 00:37:20,400 --> 00:37:26,760 the algorithm is that this is not an algorithm that was designed by Opel. It is 353 00:37:26,760 --> 00:37:34,440 an algorithm that is used by a security transponder. It is used by the PCF7935 354 00:37:34,440 --> 00:37:39,630 security transponder, which is the predecessor of high tech II, which you may 355 00:37:39,630 --> 00:37:47,760 be familiar with it. It uses a 128 bit secret. So that is really, really big 356 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 357 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 358 00:38:01,260 --> 00:38:05,910 between output moments. Not as in the FIAT case, one round, one bit output. It does 359 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 360 00:38:11,580 --> 00:38:19,950 more bits. And during these 34 rounds, it mixes the whole 128 bit secret key into 361 00:38:19,950 --> 00:38:23,580 the state. There is so much distance between these moments that it is very, 362 00:38:23,580 --> 00:38:31,380 very hard to relate any of this information or any usable assumption that 363 00:38:31,380 --> 00:38:39,780 survives so much new mixing of information. I did my best. I found some 364 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 365 00:38:44,400 --> 00:38:53,190 interested in the details. I found it funny to find an implementation of a 366 00:38:53,190 --> 00:38:57,990 security transponder in an engine. While I, In the beginning of this talk pointed 367 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 368 00:39:03,150 --> 00:39:10,530 analyzed another vehicle, a Corsa Model C and found that this was different. This 369 00:39:10,530 --> 00:39:17,370 car had indeed an engine that talks with the key. And what probably happened is 370 00:39:17,370 --> 00:39:22,920 that they wanted to decouple development of engines and development of cars so they 371 00:39:22,920 --> 00:39:27,180 could upgrade security transponders without replacing their engines or 372 00:39:27,180 --> 00:39:33,210 replacing their engine firmwares. So I think that is how this happened and why 373 00:39:33,210 --> 00:39:39,090 they just decided to well, then implement the security transponder and emulate it in 374 00:39:39,090 --> 00:39:43,860 the body control module towards the engine. It seemed like a convenient 375 00:39:43,860 --> 00:39:49,650 solution, I guess. It is by far the strongest algorithm I have encountered in 376 00:39:49,650 --> 00:39:54,660 these three case studies. And while it is out of scope because I limited myself to 377 00:39:54,660 --> 00:39:59,700 the actual cryptographic primitives, I felt the need to point out that the random 378 00:39:59,700 --> 00:40:08,820 number generator is really not very good. They use the tick counter of the CPU as 379 00:40:08,820 --> 00:40:13,440 source of randomness and then they use a couple of constants that, if you google 380 00:40:13,440 --> 00:40:23,520 them, direct you to the Netscape random number generator. So summing it up: We 381 00:40:23,520 --> 00:40:30,870 found that Peugeot used a tiny key space with only 1.3 million different possible 382 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 383 00:40:39,510 --> 00:40:44,670 challenge, you immediately get the full secret. It has a lot of collisions, which 384 00:40:45,180 --> 00:40:54,210 makes it really not very robust against an adversary. Fiat has a schoolbook algorithm 385 00:40:54,210 --> 00:41:01,050 and it's vulnerable to schoolbook attack. It's a nice idea to implement neutral 386 00:41:01,050 --> 00:41:07,650 authentication, but it doesn't really work in this context. And worse, they reuse 387 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 388 00:41:14,700 --> 00:41:21,120 secret that is used to generate a response. If that would have been the 389 00:41:21,120 --> 00:41:28,350 vehicle PIN I would not have been able to mount this attack. And lastly, Opel 390 00:41:28,350 --> 00:41:34,470 decided to clone an obsolete security transponder. The successor, high tech II, 391 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 392 00:41:41,640 --> 00:41:46,740 in cryptanalysis. I'm not convinced that it's a secure transponder, but it is 393 00:41:46,740 --> 00:41:52,230 certainly better than the other two I analyzed. And also interesting is that all 394 00:41:52,230 --> 00:41:58,650 these three systems are still around in new vehicles. Maybe not all models, but 395 00:41:58,650 --> 00:42:05,400 they're still being manufactured. So I am curious to see how this relates to other 396 00:42:05,400 --> 00:42:12,630 manufacturers, other models. And I think it would be interesting to, well, do some 397 00:42:12,630 --> 00:42:19,290 further research in this domain and see what else is out there. So to finish with 398 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 399 00:42:25,920 --> 00:42:32,200 going to mess it up. Just use standardized cryptographic components and maybe try to 400 00:42:32,200 --> 00:42:38,230 get people that are actually security experts to implement it instead of hoping 401 00:42:38,230 --> 00:42:44,710 for the best. Don't reuse secrets. These two case studies revealed that reuse of 402 00:42:44,710 --> 00:42:50,710 secret made the attack much more powerful than it needed to be. Minimize the number 403 00:42:50,710 --> 00:42:53,980 of cryptographic protocols and cryptographic primitives that you're 404 00:42:53,980 --> 00:43:01,420 using. The more different primitives, the more attack surface you create for an 405 00:43:01,420 --> 00:43:07,240 adversary. And lastly, as I mentioned before, there has been an arms race in 406 00:43:07,240 --> 00:43:12,400 transponder security. How is it possible that a modern car key may be equipped with 407 00:43:12,400 --> 00:43:19,870 AES or other fairly secure cryptographic features, and these protocols that date 408 00:43:19,870 --> 00:43:26,680 from 1995 and such are still there, not replaced. Apparently no one either figured 409 00:43:26,680 --> 00:43:34,870 it out or there are other very important reasons to just leave them there. So I 410 00:43:34,870 --> 00:43:39,880 hope that was interesting. Maybe entertaining and I'll happily take any 411 00:43:39,880 --> 00:43:46,599 questions you have for me. 412 00:43:46,599 --> 00:43:47,865 *applause* 413 00:43:47,865 --> 00:43:51,747 Herald: Bedankt Wouter Bokslag. Thank you. You know the game if you have questions - 414 00:43:51,747 --> 00:43:59,308 oh, we already have questions. There are microphones, microphones number 1 to 7 and 415 00:43:59,308 --> 00:44:05,265 2 to 8. And the Internet has questions already. So we start with the Internet. 416 00:44:05,265 --> 00:44:09,019 Internet, please. Signal Angel: Why don't make cars more use 417 00:44:09,019 --> 00:44:13,622 of rings of security or layers or permissons system? 418 00:44:13,622 --> 00:44:21,453 Wouter: Oh, well, this is embedded security. This is not a PC or smartphone 419 00:44:21,453 --> 00:44:26,873 security. It's embedded security. And I think automotive manufacturers do their 420 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 421 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 422 00:44:40,987 --> 00:44:46,950 better? Of course they should do it better. But I think it's understandable 423 00:44:46,950 --> 00:44:53,169 that they may be a bit behind on this game that is relatively new to them. 424 00:44:53,169 --> 00:44:57,474 Herald: Thank you. And microphone number one. 425 00:44:57,474 --> 00:45:03,445 Q: Hi. Amazing work, but I have a question. Did you find any simpler, more 426 00:45:03,445 --> 00:45:08,725 entertaining mistakes like storing the PIN in the open, in other components in the 427 00:45:08,725 --> 00:45:12,870 car? Wouter: Well yeah, I did do some other 428 00:45:12,870 --> 00:45:18,365 stuff besides the 3 cases I presented here. I also investigated some 429 00:45:18,365 --> 00:45:24,066 authentication mechanisms for diagnostic functionality and I didn't put them in my 430 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 431 00:45:30,310 --> 00:45:37,283 I've seen authentications that are really pretty hilarious, such as challenge - 432 00:45:37,283 --> 00:45:48,400 secrets - subtract - response. Herald: Answered? I think this is a yes. 433 00:45:48,400 --> 00:45:53,950 Microphone number 2, please. Q: Hey, thank you for the talk. Two short 434 00:45:53,950 --> 00:45:58,300 questions. How did you specifically choose those two cars, those three cars, and 435 00:45:58,300 --> 00:46:05,320 which parts or are parts of these flaws fixable in later firmware, bootloader, 436 00:46:05,320 --> 00:46:10,420 software, coding, update, whatever? Wouter: Yeah, Okay. I chose these cars 437 00:46:10,420 --> 00:46:16,720 mainly by availability. I didn't really cherry pick models. It was just that at 438 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 439 00:46:23,020 --> 00:46:27,340 around with. You have seen my very professional PSA setup, that was the most 440 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 441 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 442 00:46:43,300 --> 00:46:47,680 turns out to be a good choice. Your second question was? 443 00:46:47,680 --> 00:46:52,930 Q: Can those flaws be fixed in an update? Wouter: Oh yes. Well, in some sense, 444 00:46:52,930 --> 00:46:59,890 except that there is no real infrastructure to roll out updates. So all 445 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 446 00:47:03,040 --> 00:47:04,165 firmwares. Q: But normal servicing... 447 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 448 00:47:13,000 --> 00:47:18,130 the manufacturer. But what you could do, for instance, is just use timeouts in the 449 00:47:18,130 --> 00:47:26,860 PSA case and make sure it's not too easy to try lots of authentication attempts. 450 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 451 00:47:32,695 --> 00:47:39,460 mitigation. It somewhat limits the impact. In the Fiat case, it's a bit harder 452 00:47:39,460 --> 00:47:45,160 because you cannot really change an entire algorithm because there's different 453 00:47:45,160 --> 00:47:49,060 engines. And yeah, I think that would be quite a hassle. You really have to change 454 00:47:49,060 --> 00:47:51,880 your protocol there. Q: Thank you. 455 00:47:52,650 --> 00:47:54,900 Herald: Thank you. Microphone number five, please. 456 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 457 00:48:01,200 --> 00:48:06,330 the units has to get replaced? Wouter: Yeah. The secrets are unique for 458 00:48:06,330 --> 00:48:16,290 car and replacement frequently involves a procedure to couple the new ECU in the 459 00:48:16,290 --> 00:48:21,000 current system. And you just have to put the ECU there, connect to the ECU and 460 00:48:21,000 --> 00:48:25,350 enter the vehicle pin. So that is quite probably also the reason that they reused 461 00:48:25,350 --> 00:48:29,640 a secret, because if you use a different secret, you have to have some kind of 462 00:48:29,640 --> 00:48:37,050 complicated secret sharing protocol that well, brings the new ECU up to speed with 463 00:48:37,050 --> 00:48:39,720 the key material that's being used inside the vehicle. 464 00:48:39,720 --> 00:48:45,090 Herald: Thank you. Microphone number one, please. 465 00:48:45,090 --> 00:48:53,070 Q: Hello. So what I'm struggling to understand here is why there was the need 466 00:48:53,070 --> 00:48:58,890 to decouple the communication in the first place and just split it in two. I can 467 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 468 00:49:03,450 --> 00:49:08,310 easier to just, you know, instead of training like the ECU and telling it: Hey, 469 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. 470 00:49:15,360 --> 00:49:19,320 Wouter: So if I understand your question correctly is that you wonder why we need 471 00:49:19,320 --> 00:49:25,320 two different authentication systems, one for the key to BCM and one for the engine 472 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 473 00:49:29,280 --> 00:49:30,120 module. Q: That's correct. 474 00:49:30,120 --> 00:49:33,810 Wouter: All right. You have to understand that engine development is done by 475 00:49:33,810 --> 00:49:40,650 different companies and the same engine may be used in various different vehicles, 476 00:49:40,650 --> 00:49:49,140 maybe even from completely different ranges. And it is complicated to give 477 00:49:49,140 --> 00:49:55,980 these cars a different firmware. So it's definitely possible. But they just want to 478 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 479 00:50:00,060 --> 00:50:06,660 same engine should also work. So it's, ... it has to do with their process of 480 00:50:06,660 --> 00:50:13,620 developing vehicles. Q: But then shouldn't also, I mean, I'm 481 00:50:13,620 --> 00:50:20,460 assuming that the part that talks to the transponder and talks to the engine still 482 00:50:20,460 --> 00:50:27,032 has to match the engine communication protocol anyway. So, I mean, doesn't the 483 00:50:27,032 --> 00:50:32,026 car producers still have to match the engine protocol anyway at some points 484 00:50:32,026 --> 00:50:35,004 anyway, so why just not implement it on the key in the first place? 485 00:50:35,004 --> 00:50:38,520 Wouter: Yeah. Well, this is all speculation from my side as well. I have 486 00:50:38,520 --> 00:50:45,620 no inside information as to why they did this. But yeah, I can imagine ways that 487 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 488 00:50:53,598 --> 00:50:59,842 has to do with legacy and compatibility issues. They could also just embed five 489 00:50:59,842 --> 00:51:05,549 algorithms in the BCM or the engine control module and just by configuration 490 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 491 00:51:10,852 --> 00:51:15,496 once again, these are not software companies. These are automotive companies. 492 00:51:15,496 --> 00:51:18,901 Q: Awesome. Thanks. Herald: Thank you. Microphone number 493 00:51:18,901 --> 00:51:23,151 three, please. Q: Thank you for the great talk. Once we 494 00:51:23,151 --> 00:51:29,570 have the OBD connected to the Internet and do you see any other complication that 495 00:51:29,570 --> 00:51:33,910 could prevent me to park the car remotely from there? 496 00:51:33,910 --> 00:51:43,391 Wouter: OBD connected to the Internet... Now well, no. Why? Once you have OBD 497 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 498 00:51:53,079 --> 00:51:59,203 gateway that is some kind of filter or you have to authenticate towards it before you 499 00:51:59,203 --> 00:52:02,975 can access the internals of the vehicle. So it really depends on the model. It 500 00:52:02,975 --> 00:52:07,995 depends on the manufacturer to which extent you have room to maneuver there. 501 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 502 00:52:12,777 --> 00:52:17,288 might be impossible. But you certainly have a very, very good starting point. 503 00:52:17,288 --> 00:52:21,300 Q: Thank you. Herald: Microphone number one, please. 504 00:52:21,300 --> 00:52:26,676 Q: Hello. Did you spot any kind of anti- brute force measures during your analyses? 505 00:52:26,676 --> 00:52:30,678 That's the question number one. And question number two is: Obviously you had 506 00:52:30,678 --> 00:52:35,960 access to the internal communication between the BCM and ECM, but were those 507 00:52:35,960 --> 00:52:42,332 attacks successful on Fiat and Peugeot, are they doable using just the OBD-II 508 00:52:42,332 --> 00:52:47,127 port? Or do you actually need to see the internal communications? 509 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 510 00:52:52,589 --> 00:52:59,361 the attacks presented and I focused only on functionality that is exposed through 511 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 512 00:53:05,307 --> 00:53:10,424 for research. So the attacks are absolutely doable over OBD. 513 00:53:10,424 --> 00:53:16,738 Q: OK, and the previous question there, which was already partially answered. 514 00:53:16,738 --> 00:53:21,049 Wouter: Yes. Q: So no, like, locking out after five 515 00:53:21,049 --> 00:53:26,615 failed trials? Wouter: I did find something that was 516 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 517 00:53:36,668 --> 00:53:45,562 limiting implemented in the PSA on the engine control module. Is that right? No, 518 00:53:45,562 --> 00:53:51,957 on the body control module. And that means that if you spam challenges, it will at 519 00:53:51,957 --> 00:53:57,440 some point no longer give you the response, which sounds like a good idea, 520 00:53:57,440 --> 00:54:01,803 right? Rate limiting. But they did it on the wrong side. 521 00:54:01,803 --> 00:54:06,136 Q: Okay, great. Thank you. Herald: Thank you. Microphone number two, 522 00:54:06,136 --> 00:54:08,610 please. Q: Have you spotted some kinds of 523 00:54:08,610 --> 00:54:13,478 relationship between this, like public identifier of the car and the secret used 524 00:54:13,478 --> 00:54:20,555 to authenticate in the service? Wouter: Yeah, so if the VIN in some ways 525 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 526 00:54:28,609 --> 00:54:31,991 headed, but I haven't spotted anything like that. 527 00:54:31,991 --> 00:54:35,253 Q: Okay. Thanks. Herald: Questions from the Internet? 528 00:54:35,253 --> 00:54:40,545 Signal Angel: No more. Herald: No more. In this case, ladies and 529 00:54:40,545 --> 00:54:58,635 gentlemen, bedankt Wouter Bokslag. Thank you very much. 530 00:54:58,635 --> 00:55:13,200 *applause* 531 00:55:13,200 --> 00:55:17,815 *postroll music*