0:00:00.000,0:00:17.287
Herald: The second thing I wanted to[br]announce: there is no scooter sharing.

0:00:17.287,0:00:35.858
Which brings me to the next talk. We tend[br]to need kind of a security concept for not

0:00:35.858,0:00:43.165
scooter sharing. So the easiest way would[br]be to have kind of a scooter lock. But we

0:00:43.165,0:00:50.864
have the lock picking guys. So that won't[br]work. So the next option would be we can

0:00:50.864,0:00:58.358
have a GPS tracker, but we have the GPS[br]spoofing guys. Which isn't also that good.

0:00:58.358,0:01:06.599
A third option would be an immobilization[br]system. We have Wouter Bokslag. Thank you.

0:01:06.599,0:01:10.800
*applause*

0:01:10.800,0:01:15.665
Wouter: Hi. Thank you for the[br]introduction. Thank you guys for the warm

0:01:15.665,0:01:20.636
welcome. I'm really happy to see that[br]still some people have come together here

0:01:20.636,0:01:27.897
at this ungodly hour to watch my talk[br]about vehicle immobilization. Well,

0:01:27.897,0:01:34.402
briefly something about me. I'm a[br]Kerckhoff security master. And the

0:01:34.402,0:01:41.311
research I will be presenting today, I did[br]as my master's thesis. So I spent about

0:01:41.311,0:01:47.199
half a year analyzing various systems and[br]I wrote something about that. And if you

0:01:47.199,0:01:53.755
want to read the full story, you can look[br]at my thesis, which is public since some

0:01:53.755,0:01:58.966
time now. And there's more detail there.[br]I'm currently working as an automotive

0:01:58.966,0:02:05.500
engineer. And if you feel like asking me[br]questions besides the Q&A, you can always

0:02:05.500,0:02:12.545
contact me by mail. So first, responsible[br]disclosure. This kind of stuff is not a

0:02:12.545,0:02:19.522
joke. Automotive manufacturers think it is[br]very important. And, well, they have a

0:02:19.522,0:02:27.555
reason to think so. So naturally we[br]contacted them ahead of publication even

0:02:27.555,0:02:35.229
before my defense and we laid out the[br]findings and I had a couple of conference

0:02:35.229,0:02:42.959
calls with the manufacturers. And I even[br]went to one of them to demonstrate the

0:02:42.959,0:02:50.715
findings on premise. I need to point out[br]that the research that I did was on fairly

0:02:50.715,0:02:57.598
old vehicles like 2009 and around. But for[br]the three cases that I really went in

0:02:57.598,0:03:04.155
depth we have been able to confirm that[br]they are still in currently produced

0:03:04.155,0:03:09.012
models. So this in itself is kind of[br]surprising because you think automotive,

0:03:09.012,0:03:15.702
cars, electronics, security, it's a fast[br]moving industry, but well, no, not really.

0:03:15.702,0:03:22.097
So everything that was in cars in 2009, at[br]least regarding to these three systems,

0:03:22.097,0:03:27.575
can still be found in currently produced[br]models. I will disclose the vehicles that

0:03:27.575,0:03:34.003
I've been working on, because I think that[br]is relevant. I hope you can forgive me

0:03:34.003,0:03:38.786
that I'm not going to disclose the[br]vehicles that I have identified these

0:03:38.786,0:03:43.815
systems in that are still being produced.[br]I'm not really into facilitating theft and

0:03:43.815,0:03:50.775
I don't see what would be the added value.[br]So the talk will be structured as follows:

0:03:50.775,0:03:58.003
I will first introduce some standard stuff[br]about immobilization systems and about

0:03:58.003,0:04:04.801
computer networks inside vehicles. I will[br]tell you something about how I addressed

0:04:04.801,0:04:10.905
the challenge. So for all three models, I[br]kind of followed a similar approach and I

0:04:10.905,0:04:16.119
think it's more practical to lay that out[br]once and then skip the details later on.

0:04:16.119,0:04:21.472
And then I will present the three[br]protocols that I uncovered in a Peugeot, a

0:04:21.472,0:04:27.190
Fiat and an Opel vehicle. I will then[br]summarize the findings in a series of

0:04:27.190,0:04:34.735
takeaways and there will be some time for[br]questions. Right. So modern vehicles are

0:04:34.735,0:04:41.376
full of electronics and full of computer[br]systems. They operate largely independent.

0:04:41.376,0:04:47.348
They are all connected through a variety[br]of different buses that talk to each other

0:04:47.348,0:04:53.473
with different protocols. And there is a[br]plethora of different standards, ISO

0:04:53.473,0:04:59.061
standards, all kinds of standards. And[br]then the manufacturer wants a lot of

0:04:59.061,0:05:05.007
freedom to, well, do it in their own way.[br]So even if you read these hundreds of

0:05:05.007,0:05:11.923
pages of standards, still every vehicle[br]you will look at will be kind of

0:05:11.923,0:05:20.109
different. There are some practical[br]handles that you can use, and one of them

0:05:20.109,0:05:29.591
is that every car has a OBD-II port. Yeah,[br]this is required by law, both in the US

0:05:29.591,0:05:38.185
and in Europe for quite some time now. And[br]it needs to be conveniently located and

0:05:38.185,0:05:44.830
that is very near the driver's seat. So[br]this is a universal connector and all cars

0:05:44.830,0:05:50.176
with a combustion engine need to have one.[br]And cars with electronic engines also need

0:05:50.176,0:05:55.764
to have one. But the functionality that[br]has to be implemented is much more

0:05:55.764,0:06:04.210
limited. So in regular internal combustion[br]engine powered cars, you have to be able

0:06:04.210,0:06:10.654
to read out emissions data and that kind[br]of stuff. So many manufacturers felt this

0:06:10.654,0:06:17.156
was a very convenient thing to also use[br]for garage purposes, for workshops to read

0:06:17.156,0:06:23.753
out error codes, to perform all kinds of[br]routines on vehicles. You might need to

0:06:23.753,0:06:30.367
teach new keys to your car if you lost one[br]or if you just want a third one. If you

0:06:30.367,0:06:35.724
add a towbar to your car, you need to tell[br]a couple of ECUs in the car that it now

0:06:35.724,0:06:42.340
has a towbar. Depends on the vehicle, but[br]telling this to 5 individual ECUs is not

0:06:42.340,0:06:48.671
an exception. And since it is a bus, the[br]CAN bus, it can be directly addressed

0:06:48.671,0:06:53.995
through the OBD connector on many vehicles[br]and you can talk to a lot of different

0:06:53.995,0:06:59.437
components. So the ECM, the Engine Control[br]Module, is one, the body control module is

0:06:59.437,0:07:04.833
another. That one controls, for instance,[br]powered windows and all kinds of interior

0:07:04.833,0:07:13.538
stuff, but also the airbag, infotainment[br]system, fancy interior lighting, stability

0:07:13.538,0:07:21.880
control systems. Another feature of it[br]being a bus is that you can also see the

0:07:21.880,0:07:28.461
inter-component communication. So if the[br]instrument panel cluster, the dashboard,

0:07:28.461,0:07:36.074
needs to talk to, say, the body control[br]module, you can see that packet going over

0:07:36.074,0:07:42.505
the CAN bus. All my research has been[br]focused on this OBD-II connector and what

0:07:42.505,0:07:49.171
you can do and what you can see from this[br]perspective. Immobilizer systems are

0:07:49.171,0:07:56.406
nowadays required to be implemented in[br]vehicles. Since the late 90s, legislation

0:07:56.406,0:08:02.620
has been adopted in both the States and[br]Europe, mandating the use of an electronic

0:08:02.620,0:08:09.699
immobilization system. And the purpose, of[br]course, was to reduce the risk of theft.

0:08:09.699,0:08:17.003
This is proven to be effective: According[br]to one study, theft rates dropped by

0:08:17.003,0:08:26.010
almost 40% in, I think, a 7 year span they[br]based their data on. This is because car

0:08:26.010,0:08:33.831
theft used to be quite simple. You could[br]just put two wires together and you could

0:08:33.831,0:08:39.123
power the starting circuit and you could[br]actually start the engine. And the

0:08:39.123,0:08:45.232
immobilizer system adds another step to[br]that. The engine control module that

0:08:45.232,0:08:50.956
finally controls the engine wants to have[br]some kind of assurance that the key

0:08:50.956,0:08:55.854
presented in the system is actually valid[br]and does so by validating a security

0:08:55.854,0:09:01.741
transponder. First generations of these[br]security transponders have been widely

0:09:01.741,0:09:08.121
studied and often were found insecure. Of[br]course this is a problem because well, if

0:09:08.121,0:09:13.275
it's insecure, it doesn't add any security[br]and cars can be stolen nonetheless. So

0:09:13.275,0:09:17.715
there has been kind of an arms race in[br]this domain and we see that nowadays

0:09:17.715,0:09:24.086
security transponders have become a lot[br]better. Your car might even use AES to

0:09:24.086,0:09:31.622
validate that the key you're putting in[br]the ignition is an actual key that is

0:09:31.622,0:09:37.710
recognized by your vehicle. And this is[br]really necessary because car thieves have

0:09:37.710,0:09:43.210
shown to be able to wield quite high tech[br]solutions, procure them from shady

0:09:43.210,0:09:51.436
companies or just use official tools that[br]can be used in illegitimate ways. A nice

0:09:51.436,0:09:58.051
example of this is shown here. For certain[br]models of Range Rover, they have a blind

0:09:58.051,0:10:03.930
spot sensor, so you can see if there is a[br]car in your blind spot. And if you pop off

0:10:03.930,0:10:09.498
a cap, then you can connect a 12V battery,[br]power the internal ECUs of the vehicle.

0:10:09.498,0:10:15.293
Then you can access the CAN bus, put the[br]car into key teaching mode and hold a

0:10:15.293,0:10:20.865
blank key to the window and it will[br]program the key and recognize it as a

0:10:20.865,0:10:24.564
valid key. Well, needless to say, this was[br]not intended behavior

0:10:24.564,0:10:27.706
*laughter*

0:10:27.706,0:10:33.252
and this has had consequences for[br]consumers. Because insurance companies saw

0:10:33.252,0:10:38.892
a rise in theft for these models - these[br]are quite expensive cars - and they

0:10:38.892,0:10:45.363
started adding demands before they would[br]allow you to insure your car. So the

0:10:45.363,0:10:51.068
insurance would get more expensive or you[br]would not be able to get the insurance if

0:10:51.068,0:10:57.494
at least at your own home, you couldn't[br]park it in a secured area. There is a

0:10:57.494,0:11:05.350
common misconception about how immobilizer[br]systems work, and it's actually one of the

0:11:05.350,0:11:10.090
reasons I want to give this talk and[br]present this, because I think it's

0:11:10.090,0:11:16.611
important to realize that an immobilizer[br]system is a bit more complicated than the

0:11:16.611,0:11:23.435
single cryptographic step that seems[br]logical. So what you might think is that

0:11:23.435,0:11:28.253
the engine control module sends a[br]challenge to the body control module,

0:11:28.253,0:11:34.276
which communicates with the key. It[br]implements the radio layer and it can then

0:11:34.276,0:11:41.217
relay the challenge to the key. The key[br]can compute the proper response based on a

0:11:41.217,0:11:47.103
secret it shares with ECM, send back the[br]response, which the BCM will in turn

0:11:47.103,0:11:52.998
forward to the ECM. The ECM can verify the[br]validity, and if this seems to be the

0:11:52.998,0:11:58.564
right response, immobilization is[br]deactivated and the car can start. Sounds

0:11:58.564,0:12:05.995
good. Sounds easy, but this is in modern[br]cars no longer the case. 'course. What we

0:12:05.995,0:12:12.960
see is that there is a second step. The[br]ECM does an authentication with the BCM.

0:12:12.960,0:12:20.215
The BCM does an authentication with the[br]key. So if your key uses say AES for its

0:12:20.215,0:12:28.450
authentication, then this will be an AES[br]secured authentication between the BCM and

0:12:28.450,0:12:34.307
the key. The BCM, if it can validate the[br]legitimacy of the key, will then send the

0:12:34.307,0:12:38.916
correct response to the engine control[br]module. But this is a whole different

0:12:38.916,0:12:45.195
protocol, using different cryptographic[br]primitives, using different keys,

0:12:45.195,0:12:52.529
sometimes, often, don't know. And more[br]importantly, it has not yet been covered.

0:12:52.529,0:12:58.335
So in the scientific literature, I have[br]found absolutely zero reference of this

0:12:58.335,0:13:04.188
step being identified. And here and there[br]you find a reference that people know that

0:13:04.188,0:13:10.796
this happens, but no actual analysis of[br]the security or the cryptographic

0:13:10.796,0:13:18.552
primitives involved. Right. So that is an[br]open question then and asks for further

0:13:18.552,0:13:24.811
research. So how do you do that? You can[br]sniff CAN traffic from the OBD connector

0:13:24.811,0:13:31.989
with tooling. And by disconnecting ECUs[br]and placing yourself in the middle you can

0:13:31.989,0:13:38.577
also modify CAN traffic. You can analyze[br]this CAN traffic, see if you can find

0:13:38.577,0:13:44.317
immobilizer-related messages. And of[br]course, by the messages, you cannot deduce

0:13:44.317,0:13:48.816
the algorithm, most of the time. So you[br]will need a firmware image or something

0:13:48.816,0:13:54.063
else you can reverse engineer to actually[br]find the code that does the magic stuff.

0:13:54.063,0:13:59.379
If you have that and if you are able to[br]pinpoint where the algorithm is, then you

0:13:59.379,0:14:04.652
can start looking at if it's actually[br]decent. And once you are all there you

0:14:04.652,0:14:10.697
will want to test if all the assumptions[br]you've made on the way are correct and if

0:14:10.697,0:14:15.299
it's actually working as you think it's[br]working. So the first step, protocol

0:14:15.299,0:14:19.882
identification, is actually quite[br]straightforward because you have some

0:14:19.882,0:14:26.465
knowledge. You know that this is a message[br]exchange that happens when you switch the

0:14:26.465,0:14:32.424
ignition to the on position. And you know[br]that there must be at least two high

0:14:32.424,0:14:37.351
entropy messages because the challenge has[br]to be different every time. And the

0:14:37.351,0:14:40.973
response is the output of some[br]cryptographic function. So it may be

0:14:40.973,0:14:46.370
expected that that looks quite random,[br]too. Also, if you switch the ignition on

0:14:46.370,0:14:52.127
but no valid transponder is present, you[br]should be able to detect some kind of

0:14:52.127,0:14:55.925
difference. And it will probably be the[br]very first moment you observe a

0:14:55.925,0:15:01.041
difference, because before that point, the[br]car didn't know there was no valid

0:15:01.041,0:15:06.567
transponder. So with a bit of fiddling and[br]some patience and going through CAN

0:15:06.567,0:15:12.510
traffic logs, you can probably find this.[br]OK. Next step is to get a firmware image

0:15:12.510,0:15:19.094
in which you hope to be able to find the[br]actual cryptographic protocol. So there

0:15:19.094,0:15:24.785
are several options. Of course you already[br]have the firmware, but it's in the

0:15:24.785,0:15:30.705
microcontroller in an ECU that is either[br]lying on your desk or inside some vehicle.

0:15:30.705,0:15:38.190
So you could try to get it straight out of[br]that device. Debugging headers are a good

0:15:38.190,0:15:44.879
option. You have JTAG, you have BDM, UART[br]occasionally can be used, but sometimes

0:15:44.879,0:15:49.854
these are deactivated. Sometimes it just[br]doesn't seem to work. Sometimes the

0:15:49.854,0:15:55.038
tooling is prohibitively expensive. So if[br]that doesn't work, you can always go to

0:15:55.038,0:16:00.314
the internet. Some manufacturers provide a[br]means to download a set of information

0:16:00.314,0:16:06.900
about the vehicle based on its VIN number.[br]You can find all kinds of configurations,

0:16:06.900,0:16:13.095
you might be able to find actual parts or[br]full firmwares, often encrypted, not

0:16:13.095,0:16:18.510
always. And then there is the tuning[br]scene. And while you might think of neon

0:16:18.510,0:16:23.273
lighting and stuff like that, these guys[br]are actually pretty knowledgeable about

0:16:23.273,0:16:28.485
the internals of engine control modules in[br]particular. And you might just be able to

0:16:28.485,0:16:34.716
find a full firmware image or parts of it[br]or some model that is highly related. And

0:16:34.716,0:16:40.312
this is kind of a viable approach to[br]getting your hands on the firmware. But

0:16:40.312,0:16:45.008
also very practical can be to just[br]leverage the functionality that is

0:16:45.008,0:16:51.555
implemented in the ECU. The ECU allows for[br]diagnostic commands such as read memory by

0:16:51.555,0:16:59.925
address and request upload, which from the[br]perspective of an ECU is sending new data.

0:16:59.925,0:17:07.405
And you might be able to just dump the[br]whole firmware or dump memory or dump at

0:17:07.405,0:17:13.820
least parts of the the internals of the[br]ECU. Then there is some kind of mechanism

0:17:13.820,0:17:19.688
that's called second bootloader. It's a[br]sort of standard. Not every manufacturer

0:17:19.688,0:17:26.495
implements it, but quite some do. That[br]allows you to actually send binary code to

0:17:26.495,0:17:33.621
the ECU. And it then jumps to it. So very[br]convenient functionality. It's maybe very

0:17:33.621,0:17:38.599
painstaking to get it working, but yeah,[br]it's basically free code execution. Except

0:17:38.599,0:17:42.919
for the fact that you often need to[br]authenticate before you're allowed to use

0:17:42.919,0:17:47.018
such functionality. So that might leave[br]you with some kind of chicken and egg

0:17:47.018,0:17:51.225
problem, because you don't know how to[br]authenticate, you don't have the algorithm

0:17:51.225,0:17:56.411
for this authentication. And lastly, there[br]are sometimes firmware updates for ECUs

0:17:56.411,0:18:02.685
and you might be able to use an official[br]dealer tool, you might be able to sniff

0:18:02.685,0:18:08.614
CAN traffic. Multiple ways of trying to[br]update the firmware on your ECU

0:18:08.614,0:18:12.931
reconstructed from the CAN traffic. Once[br]more, you have to go through an ISO

0:18:12.931,0:18:18.116
standard before you understand how it's[br]exactly chunked in 8 byte messages, but

0:18:18.116,0:18:25.160
you'll get there eventually. So once you[br]have this firmware, you have to pinpoint

0:18:25.160,0:18:30.091
the cryptographic algorithm and ECU[br]firmwares are typically between half a

0:18:30.091,0:18:35.058
megabyte and 2 megabytes. And that is a[br]lot, if we're talking assembly. And the

0:18:35.058,0:18:41.184
information density is extremely low. And[br]if you have to go through it line by line,

0:18:41.184,0:18:46.713
it's hardly doable. So you need to have[br]some tricks. I think we're at a conference

0:18:46.713,0:18:51.473
where we've seen a lot of reverse[br]engineering. So this is not going to be my

0:18:51.473,0:18:56.365
focus during this talk, but a couple of[br]pointers. Maybe someone is helped by that.

0:18:56.365,0:19:01.168
Of course, you know the protocol because[br]you have observed CAN traffic. So you can

0:19:01.168,0:19:07.183
search for immediate values, for numerical[br]values that are used in the protocol to

0:19:07.183,0:19:13.815
designate a packet type, for instance. It[br]must be in the firmware somewhere. Also,

0:19:13.815,0:19:18.706
you know that crypto usually uses XOR[br]instructions and you would be surprised

0:19:18.706,0:19:23.549
how little XOR instructions there are in a[br]firmware. Depending on the architecture,

0:19:23.549,0:19:28.341
you might immediately dismiss most of[br]those as a single bit flip or maybe

0:19:28.341,0:19:34.288
inversion of a whole register, and then[br]you will find some XORs with either weird

0:19:34.288,0:19:40.340
constants or variables. So those are[br]points to focus on. Lastly, you can make

0:19:40.340,0:19:46.912
some assumptions on the structure of the[br]cryptographic function, so it certainly

0:19:46.912,0:19:53.033
doesn't do IO, it will not invoke a lot of[br]other external functions, maybe some round

0:19:53.033,0:19:57.909
function once or twice, maybe some[br]initialization. It will probably have some

0:19:57.909,0:20:03.530
loops and you can sometimes recognize the[br]length of the challenge. You can sometimes

0:20:03.530,0:20:09.041
recognize the length of the response. That[br]being said, let's dive in the first case

0:20:09.041,0:20:15.569
study. So I reverse engineered the Peugeot[br]207, which is, as I said, not the most

0:20:15.569,0:20:21.620
recent of vehicles. And this was my test[br]setup. It doesn't look like much, but

0:20:21.620,0:20:27.412
everything that's relevant to me is there.[br]And you can toggle the ignition and lights

0:20:27.412,0:20:32.430
will show and all the ECUs are connected[br]through a CAN bus and an OBD connector

0:20:32.430,0:20:39.220
that you can see on the left side of the[br]instrument panel. And I investigated a

0:20:39.220,0:20:46.445
tool that had a kind of peculiar function[br]and that is that you could obtain the

0:20:46.445,0:20:51.065
vehicle PIN - some kind of secret you[br]needed to authenticate for diagnostics -

0:20:51.065,0:20:56.499
by connecting this tool and toggling the[br]ignition a couple of times. So that kind

0:20:56.499,0:21:00.860
of gives you a hunch that the[br]immobilization system might be involved,

0:21:00.860,0:21:07.215
because it's triggered upon toggling the[br]ignition, and that you can derive in some

0:21:07.215,0:21:14.560
way the vehicle pin from this. So for this[br]Peugeot and for most BSA vehicles in

0:21:14.560,0:21:21.222
general, the PIN is a four digit uppercase[br]and numeric code excluding the O and I,

0:21:21.222,0:21:27.190
because that would be confusing. So that[br]leaves us with roughly one point three

0:21:27.190,0:21:33.826
million keys, which is nothing in terms of[br]crypto. I finally reversed the algorithm.

0:21:33.826,0:21:40.557
It is obviously in the engine control[br]module and the body control module. And

0:21:40.557,0:21:46.025
the main part looked like, oh wait, wait[br]for it. And the protocol looks like this.

0:21:46.025,0:21:51.935
So if you observe CAN traffic, you will[br]see that some CAN ID 72. On that ID is

0:21:51.935,0:21:58.675
sent a message that starts with 00 and[br]then followed by a 4 byte challenge. And

0:21:58.675,0:22:04.827
if the BCM is able to verify that a valid[br]key is present, it will respond with 04

0:22:04.827,0:22:11.880
and a four byte response. So this is a[br]very small, straightforward protocol,

0:22:11.880,0:22:19.520
which, well, does the bare necessary. And[br]one of the first things I did was

0:22:19.520,0:22:25.129
injecting challenges. Just inject a[br]challenge, send it to the BCM with a valid

0:22:25.129,0:22:30.362
key and see what the response is going to[br]be. And if I replace the zeros by dots,

0:22:30.362,0:22:37.858
you see that there's an extremely apparent[br]pattern is visible. So the ideal case that

0:22:37.858,0:22:45.602
a single bit flip in a challenge leads to[br]a 50/50 chance of a bit flip in every

0:22:45.602,0:22:51.992
response bit is not exactly respected. You[br]see that the effect of changing the

0:22:51.992,0:22:58.310
challenge has a very localized effect on[br]the response. Another weird feature, which

0:22:58.310,0:23:04.359
is not very clearly visible here, but it's[br]visible in the last one, is that on

0:23:04.359,0:23:10.389
average, when you give average just random[br]challenges, 75% of the bits of the

0:23:10.389,0:23:16.385
response will be set. So that is a very,[br]very heavy bias. And it was quite puzzling

0:23:16.385,0:23:23.430
to me what kind of cryptographic primitive[br]would exhibit such behavior. And then it

0:23:23.430,0:23:30.576
became clear. this is the main function of[br]the algorithm and there is a transform

0:23:30.576,0:23:36.950
function that I left out, but it basically[br]does some multiplication, some division,

0:23:36.950,0:23:43.265
some modulo, mathematical operations, It[br]splits the challenge in two parts and it

0:23:43.265,0:23:49.742
splits the vehicle PIN, so the secret in[br]two parts. And the total of four parts are

0:23:49.742,0:23:55.523
all used as inputs for this transform[br]function and we obtain a challenge

0:23:55.523,0:24:02.135
transformed left challenge transformed[br]right and similarly for the PIN a left and

0:24:02.135,0:24:08.456
right transformed part. And then something[br]interesting happens because the left

0:24:08.456,0:24:14.692
transformed part of the challenge is ORed[br]with a part of the PIN. And an OR

0:24:14.692,0:24:24.713
operation will lead to a, well, on average[br]75% set result. So that kind of explains

0:24:24.713,0:24:34.005
the weird behavior we saw before. Strange[br]and maybe not so smart, because an

0:24:34.005,0:24:41.900
adversary will be able to either control[br]or observe the challenge that is used as

0:24:41.900,0:24:47.755
input for this algorithm. So if you know[br]the challenge, you know the transform

0:24:47.755,0:24:52.263
challenge, and if you know to transform[br]challenge, you know something about the

0:24:52.263,0:24:59.672
output. Because if the transform challenge[br]has a one bit, then the response will have

0:24:59.672,0:25:05.755
a one bit in that same position. There is[br]another property for the transform

0:25:05.755,0:25:10.285
function, and that is that if the input is[br]a zero, the further parameters of

0:25:10.285,0:25:16.105
transform vary a bit, but it doesn't[br]affect this property: if the input is a

0:25:16.105,0:25:22.132
zero, the output is a zero. So that gives[br]us that if you have a challenge of all

0:25:22.132,0:25:27.872
zeros, you will obtain a transform[br]challenge of all zeros. And that means

0:25:27.872,0:25:33.808
that when you're doing the OR you're ORing[br]with nothing and the response will be

0:25:33.808,0:25:41.104
entirely determined by the transformed[br]PIN. Then another property is that the

0:25:41.104,0:25:47.883
PIN, which is an alphanumeric PIN, is[br]invertable once. Let me restart.

0:25:47.883,0:25:58.365
Transform: If it takes a PIN as input,[br]then the output can be inverted. There is

0:25:58.365,0:26:04.608
only one PIN part input that maps to one[br]output of the transform function. So if

0:26:04.608,0:26:09.906
you are able to supply the vehicle with a[br]challenge of zeros, you will get one

0:26:09.906,0:26:14.730
response and you can uniquely identify the[br]secret of the car, the PIN. And this PIN

0:26:14.730,0:26:19.224
can later be used to, for instance,[br]authenticate for diagnostics or key

0:26:19.224,0:26:24.013
teaching or whatever you want. If you're[br]not able to control the challenge, you can

0:26:24.013,0:26:28.945
just collect a couple of random challenge[br]responses and you will still have the PIN.

0:26:28.945,0:26:34.842
So that's bad. What's worse is that there[br]are a lot of collisions because the bits

0:26:34.842,0:26:42.360
that are set in the challenge transformed[br]will hide the bits that are set in the PIN

0:26:42.360,0:26:49.886
transformed. So a challenge transformed[br]with a lot of ones set will accept a lot

0:26:49.886,0:26:56.020
of different PINs as proper input and[br]result in the same response. So there is a

0:26:56.020,0:27:02.431
quite simple attack we can mount here and[br]that is that we get a challenge from the

0:27:02.431,0:27:08.450
car without a valid key present and we[br]then compute for that challenge for all

0:27:08.450,0:27:14.036
PINs what response it would yield. And you[br]will see that some PINs, sorry, some

0:27:14.036,0:27:18.787
responses are generated by a lot of[br]different PINs. It could easily be two-,

0:27:18.787,0:27:23.664
three thousand PINs resulting in the same[br]challenge. So you choose the most probable

0:27:23.664,0:27:29.231
response and you send it and either the[br]ECU accepts it and disables immobilization

0:27:29.231,0:27:35.037
or it doesn't. And if it doesn't accept[br]it, then you know for three thousand pins

0:27:35.037,0:27:40.892
that it was not that. In general this[br]takes far less than 4000 attempts and and

0:27:40.892,0:27:47.546
far less than 15 minutes. I don't know[br]exactly. I've tried it a couple of times

0:27:47.546,0:27:53.813
and I've been able to deactivate[br]immobilization, I'd say, 3 minutes once,

0:27:53.813,0:28:00.410
maybe 10 minutes once. And after that, if[br]you toggle the ignition switch, the car

0:28:00.410,0:28:07.776
will actually start without transponder[br]present. So. That was not so good. Next

0:28:07.776,0:28:15.864
case is the Fiat I investigated, the[br]Grande Punto and I reverse engineered the

0:28:15.864,0:28:22.281
BCM. It's based on the NEC V850[br]architecture, which is a nice 32 bit RISC

0:28:22.281,0:28:29.600
architecture, pretty readable, pretty fair[br]information density. But still, I couldn't

0:28:29.600,0:28:35.450
really figure out what the actual crypto[br]part was. So I also investigated an engine

0:28:35.450,0:28:41.570
control module. Surprisingly, I was able[br]to find it there. And then I immediately

0:28:41.570,0:28:48.260
went back to the V850 because that at[br]least is readable code. Protocol is as

0:28:48.260,0:29:00.350
follows: It has a 32 bit challenge, then a[br]4 bit - sorry - 4 byte challenge, then a 2

0:29:00.350,0:29:06.470
byte proof of knowledge. And that's an[br]interesting feature, because that way the

0:29:06.470,0:29:10.820
engine control module proves to the body[br]control module that it actually has

0:29:10.820,0:29:17.030
knowledge of the key. So you can not just[br]spam a challenge and get a get a response

0:29:17.030,0:29:23.300
for that. You have to prove that you know[br]the secret. And then you get back a 2 byte

0:29:23.300,0:29:30.320
response. And if that is correct, the ECM[br]accepts it and the car can start. And this

0:29:30.320,0:29:37.640
very well, seemingly nice security feature[br]that there is a proof of knowledge of the

0:29:37.640,0:29:44.720
key is actually the flaw in this system,[br]as it turns out. The cipher is a linear

0:29:44.720,0:29:50.360
feedback shift register based cipher. It[br]initializes the states with the key, XORed

0:29:50.360,0:29:55.730
with the challenge, XORed with some[br]constant. And then it does 38 rounds. If

0:29:55.730,0:30:00.410
you don't know what an LFSR is I'll tell[br]you in the next slide. Then it generates

0:30:00.410,0:30:06.020
the proof. That is 12 rounds, actually 12[br]bits output. And if you look back in the

0:30:06.020,0:30:11.510
protocol, you actually see that the first[br]nibble is indeed a zero. So it's not 16

0:30:11.510,0:30:17.000
bits, but it's only 12 bits. After[br]generating the proof, it loads an

0:30:17.000,0:30:22.940
additional 16 bit constant and then[br]generates the 14 bit response. This is a

0:30:22.940,0:30:28.850
very standard construction in crypto and[br]there is a fairly standard attack to it.

0:30:28.850,0:30:40.460
So what you see here is an LFSR, it's a 32[br]bit register and it operates in ticks. So

0:30:40.460,0:30:45.170
it is loaded with this initial secret[br]state at the beginning of the algorithm

0:30:45.170,0:30:55.610
and each tick it takes 4 bits and they are[br]XORed together. Then the whole register

0:30:55.610,0:31:02.030
shifts one position to the left. So bit 0[br]goes to bit 1, 1 to 2, etc. Bit 31 shifts

0:31:02.030,0:31:10.310
out and the previously computed XOred bit[br]is shifted in in the 0 position. So that

0:31:10.310,0:31:16.340
way it cycles and continuously updates its[br]internal state. And then there is an

0:31:16.340,0:31:22.910
output function that takes 8 bits of input[br]and each tick it computes one bit from an

0:31:22.910,0:31:29.690
8 bit input, and on the lower left you can[br]see the output generation table. So it

0:31:29.690,0:31:36.890
kind of just counts through this. And if[br]the eight bits together add up to say A2,

0:31:36.890,0:31:44.030
then you pick bit position A2 in this[br]table and that is then the bit that is

0:31:44.030,0:31:53.000
being generated as proof or response bit[br]during that round. Now what we see here is

0:31:53.000,0:32:00.560
that there is actually 8 bits of the LFSR[br]that determine the output bit. And of

0:32:00.560,0:32:12.820
these 8 bits they generate 256 different[br]values. Now there are 256 different

0:32:12.820,0:32:18.730
combinations and only half will generate[br]the observed output bit. So that means

0:32:18.730,0:32:24.790
that 128 different options may be valid[br]options for these 8 bits to generate a

0:32:24.790,0:32:30.340
response or a proof that we have observed[br]earlier. And that is pretty interesting.

0:32:30.340,0:32:37.510
And you can use that to construct a guess[br]and determine attack. Which means that you

0:32:37.510,0:32:44.500
make an assumption on the internal state.[br]We have 128 candidate internal states. And

0:32:44.500,0:32:50.170
then we do a round. So we shift the[br]guessed bits one position to the left. We

0:32:50.170,0:32:56.170
do the feedback function and then we are[br]going to evaluate the second bit that was

0:32:56.170,0:33:01.120
generated. For the second bit we already[br]have some knowledge, because we made

0:33:01.120,0:33:09.040
assumptions earlier. So the green squares[br]designate the bits that we already know.

0:33:09.040,0:33:17.260
And you see that throughout the rounds,[br]each round you can eliminate half the

0:33:17.260,0:33:21.430
candidates, because they generate the[br]wrong output bit. And you need to guess

0:33:21.430,0:33:28.630
less and less bits in order to to fill in[br]the state. And this continuous elimination

0:33:28.630,0:33:35.500
of half the candidate states makes this[br]far more efficient than just a brute force

0:33:35.500,0:33:42.490
attack. The total complexity of this[br]attack is 2^21, which is orders of

0:33:42.490,0:33:51.640
magnitude less than mounting a brute force[br]attack. Right. So that's OK. That is

0:33:51.640,0:33:58.210
fairly standard stuff in crypto. Now,[br]there is a big problem in the way they

0:33:58.210,0:34:03.690
implemented this, because they did some[br]secret reuse. And the secret that is being

0:34:03.690,0:34:12.330
used to generate the proof is in some[br]mangled way the vehicle PIN. If you take

0:34:12.330,0:34:18.510
this 32 bit secret input value and you[br]take the 5 rightmost nibbles and then

0:34:18.510,0:34:23.850
transform the letters into numbers and[br]then replace the zeros by sevens, then you

0:34:23.850,0:34:31.620
get a 5 digit number and that number is[br]the PIN. So what we have now is an attack

0:34:31.620,0:34:37.770
that observes a couple of challenges[br]together with their proof of knowledge,

0:34:37.770,0:34:44.640
which is always there, and you get it for[br]free when you just power the ECU, and you

0:34:44.640,0:34:50.670
run an attack on that. That takes, well,[br]my not so optimized implementation takes 6

0:34:50.670,0:34:57.570
seconds on a single core. You can probably[br]do better. Runs in seconds. And what you

0:34:57.570,0:35:05.400
get is the PIN. So you can still not[br]authenticate towards the ECM, but you do

0:35:05.400,0:35:09.180
get the pin which you can then use to[br]authenticate for diagnostic services, you

0:35:09.180,0:35:12.840
can, maybe, read memory, you can, maybe,[br]reprogram stuff, you can, maybe,enter key

0:35:12.840,0:35:23.160
teaching mode. There is absolutely ways to[br]leverage this and, well, get the car to

0:35:23.160,0:35:33.870
start. The 3rd case I investigated was an[br]Opel Astra H. And I've decided to skip the

0:35:33.870,0:35:38.190
crypto parts in this one because I[br]couldn't break it and I wouldn't want to

0:35:38.190,0:35:43.710
bore you with a fairly complicated[br]algorithm and then not present an attack.

0:35:43.710,0:35:48.420
If you're interested, it's in my thesis so[br]you can look it up. But there is still

0:35:48.420,0:35:56.100
some funny things to point out here. I[br]reverse engineered an ECM that was based

0:35:56.100,0:36:04.320
on a PowerPC architecture microcontroller.[br]And that is very nice because there is a

0:36:04.320,0:36:10.860
decompiler for that. And IDA Pro will[br]nicely transform the assembly into

0:36:10.860,0:36:18.270
somewhat accurate, somewhat readable C[br]code. That was good, but it was not

0:36:18.270,0:36:26.790
enough. So I purchased some tool to use[br]the BDM interface of this ECU which was

0:36:26.790,0:36:32.640
active and usable. And it took me a lot of[br]time to get the tools working, because

0:36:32.640,0:36:37.020
virtual machines were not okay, etc etc. I[br]installed Windows and did crazy stuff. And

0:36:38.580,0:36:43.920
then I was able to read memory, modify[br]registers on the actual ECU, and that

0:36:43.920,0:36:52.170
helped a great deal in debugging and[br]finding the actual functions. So this is

0:36:52.170,0:36:58.950
the protocol that I found. It has a 2 byte[br]opcode, then 2 bytes status data, then a 4

0:36:58.950,0:37:03.480
byte challenge. And similarly 2 byte[br]opcode for the response, 2 byte status

0:37:03.480,0:37:13.590
data, 4 byte response. No proof of[br]knowledge here. Just a 32 bit to 32 bit

0:37:13.590,0:37:20.400
challenge-response authentication. And[br]what was funny when I finally uncovered

0:37:20.400,0:37:26.760
the algorithm is that this is not an[br]algorithm that was designed by Opel. It is

0:37:26.760,0:37:34.440
an algorithm that is used by a security[br]transponder. It is used by the PCF7935

0:37:34.440,0:37:39.630
security transponder, which is the[br]predecessor of high tech II, which you may

0:37:39.630,0:37:47.760
be familiar with it. It uses a 128 bit[br]secret. So that is really, really big

0:37:47.760,0:37:53.790
secret, and a 32 bit internal state. When[br]I saw that 32 bit internal state, I was

0:37:53.790,0:38:01.260
like, OK, this is going to be doable. It[br]wasn't. Because it does a lot of rounds

0:38:01.260,0:38:05.910
between output moments. Not as in the FIAT[br]case, one round, one bit output. It does

0:38:05.910,0:38:11.580
34 rounds and then it outputs two bits and[br]then it does another 34 rounds and two

0:38:11.580,0:38:19.950
more bits. And during these 34 rounds, it[br]mixes the whole 128 bit secret key into

0:38:19.950,0:38:23.580
the state. There is so much distance[br]between these moments that it is very,

0:38:23.580,0:38:31.380
very hard to relate any of this[br]information or any usable assumption that

0:38:31.380,0:38:39.780
survives so much new mixing of[br]information. I did my best. I found some

0:38:39.780,0:38:44.400
stuff. Nothing that is usable to mount an[br]attack. You can read my thesis if you're

0:38:44.400,0:38:53.190
interested in the details. I found it[br]funny to find an implementation of a

0:38:53.190,0:38:57.990
security transponder in an engine. While[br]I, In the beginning of this talk pointed

0:38:57.990,0:39:03.150
out that the engine doesn't talk with the[br]transponder. So I went back in time and I

0:39:03.150,0:39:10.530
analyzed another vehicle, a Corsa Model C[br]and found that this was different. This

0:39:10.530,0:39:17.370
car had indeed an engine that talks with[br]the key. And what probably happened is

0:39:17.370,0:39:22.920
that they wanted to decouple development[br]of engines and development of cars so they

0:39:22.920,0:39:27.180
could upgrade security transponders[br]without replacing their engines or

0:39:27.180,0:39:33.210
replacing their engine firmwares. So I[br]think that is how this happened and why

0:39:33.210,0:39:39.090
they just decided to well, then implement[br]the security transponder and emulate it in

0:39:39.090,0:39:43.860
the body control module towards the[br]engine. It seemed like a convenient

0:39:43.860,0:39:49.650
solution, I guess. It is by far the[br]strongest algorithm I have encountered in

0:39:49.650,0:39:54.660
these three case studies. And while it is[br]out of scope because I limited myself to

0:39:54.660,0:39:59.700
the actual cryptographic primitives, I[br]felt the need to point out that the random

0:39:59.700,0:40:08.820
number generator is really not very good.[br]They use the tick counter of the CPU as

0:40:08.820,0:40:13.440
source of randomness and then they use a[br]couple of constants that, if you google

0:40:13.440,0:40:23.520
them, direct you to the Netscape random[br]number generator. So summing it up: We

0:40:23.520,0:40:30.870
found that Peugeot used a tiny key space[br]with only 1.3 million different possible

0:40:30.870,0:40:39.510
PIN codes. They leak a lot of information[br]in the response. If you can inject a zero

0:40:39.510,0:40:44.670
challenge, you immediately get the full[br]secret. It has a lot of collisions, which

0:40:45.180,0:40:54.210
makes it really not very robust against an[br]adversary. Fiat has a schoolbook algorithm

0:40:54.210,0:41:01.050
and it's vulnerable to schoolbook attack.[br]It's a nice idea to implement neutral

0:41:01.050,0:41:07.650
authentication, but it doesn't really work[br]in this context. And worse, they reuse

0:41:07.650,0:41:14.700
that part of the secret as the vehicle PIN[br]as opposed to using the other part of the

0:41:14.700,0:41:21.120
secret that is used to generate a[br]response. If that would have been the

0:41:21.120,0:41:28.350
vehicle PIN I would not have been able to[br]mount this attack. And lastly, Opel

0:41:28.350,0:41:34.470
decided to clone an obsolete security[br]transponder. The successor, high tech II,

0:41:34.470,0:41:41.640
was desperately broken. This one wasn't.[br]Not by me. I have a master's degree, not

0:41:41.640,0:41:46.740
in cryptanalysis. I'm not convinced that[br]it's a secure transponder, but it is

0:41:46.740,0:41:52.230
certainly better than the other two I[br]analyzed. And also interesting is that all

0:41:52.230,0:41:58.650
these three systems are still around in[br]new vehicles. Maybe not all models, but

0:41:58.650,0:42:05.400
they're still being manufactured. So I am[br]curious to see how this relates to other

0:42:05.400,0:42:12.630
manufacturers, other models. And I think[br]it would be interesting to, well, do some

0:42:12.630,0:42:19.290
further research in this domain and see[br]what else is out there. So to finish with

0:42:19.290,0:42:25.920
a few takeaways. Don't do your own crypto.[br]It's often said and repeated. You are

0:42:25.920,0:42:32.200
going to mess it up. Just use standardized[br]cryptographic components and maybe try to

0:42:32.200,0:42:38.230
get people that are actually security[br]experts to implement it instead of hoping

0:42:38.230,0:42:44.710
for the best. Don't reuse secrets. These[br]two case studies revealed that reuse of

0:42:44.710,0:42:50.710
secret made the attack much more powerful[br]than it needed to be. Minimize the number

0:42:50.710,0:42:53.980
of cryptographic protocols and[br]cryptographic primitives that you're

0:42:53.980,0:43:01.420
using. The more different primitives, the[br]more attack surface you create for an

0:43:01.420,0:43:07.240
adversary. And lastly, as I mentioned[br]before, there has been an arms race in

0:43:07.240,0:43:12.400
transponder security. How is it possible[br]that a modern car key may be equipped with

0:43:12.400,0:43:19.870
AES or other fairly secure cryptographic[br]features, and these protocols that date

0:43:19.870,0:43:26.680
from 1995 and such are still there, not[br]replaced. Apparently no one either figured

0:43:26.680,0:43:34.870
it out or there are other very important[br]reasons to just leave them there. So I

0:43:34.870,0:43:39.880
hope that was interesting. Maybe[br]entertaining and I'll happily take any

0:43:39.880,0:43:46.599
questions you have for me.

0:43:46.599,0:43:47.865
*applause*

0:43:47.865,0:43:51.747
Herald: Bedankt Wouter Bokslag. Thank you.[br]You know the game if you have questions -

0:43:51.747,0:43:59.308
oh, we already have questions. There are[br]microphones, microphones number 1 to 7 and

0:43:59.308,0:44:05.265
2 to 8. And the Internet has questions[br]already. So we start with the Internet.

0:44:05.265,0:44:09.019
Internet, please.[br]Signal Angel: Why don't make cars more use

0:44:09.019,0:44:13.622
of rings of security or layers or[br]permissons system?

0:44:13.622,0:44:21.453
Wouter: Oh, well, this is embedded[br]security. This is not a PC or smartphone

0:44:21.453,0:44:26.873
security. It's embedded security. And I[br]think automotive manufacturers do their

0:44:26.873,0:44:33.629
best, but this is just not their game. And[br]yeah, there is plenty of ways you could do

0:44:33.629,0:44:40.987
this in a more secure manner. But they[br]didn't. I cannot really say, why not do it

0:44:40.987,0:44:46.950
better? Of course they should do it[br]better. But I think it's understandable

0:44:46.950,0:44:53.169
that they may be a bit behind on this game[br]that is relatively new to them.

0:44:53.169,0:44:57.474
Herald: Thank you. And microphone number[br]one.

0:44:57.474,0:45:03.445
Q: Hi. Amazing work, but I have a[br]question. Did you find any simpler, more

0:45:03.445,0:45:08.725
entertaining mistakes like storing the PIN[br]in the open, in other components in the

0:45:08.725,0:45:12.870
car?[br]Wouter: Well yeah, I did do some other

0:45:12.870,0:45:18.365
stuff besides the 3 cases I presented[br]here. I also investigated some

0:45:18.365,0:45:24.066
authentication mechanisms for diagnostic[br]functionality and I didn't put them in my

0:45:24.066,0:45:30.310
thesis because it's nice to have a clear[br]message and a clear line of research. But

0:45:30.310,0:45:37.283
I've seen authentications that are really[br]pretty hilarious, such as challenge -

0:45:37.283,0:45:48.400
secrets - subtract - response.[br]Herald: Answered? I think this is a yes.

0:45:48.400,0:45:53.950
Microphone number 2, please.[br]Q: Hey, thank you for the talk. Two short

0:45:53.950,0:45:58.300
questions. How did you specifically choose[br]those two cars, those three cars, and

0:45:58.300,0:46:05.320
which parts or are parts of these flaws[br]fixable in later firmware, bootloader,

0:46:05.320,0:46:10.420
software, coding, update, whatever?[br]Wouter: Yeah, Okay. I chose these cars

0:46:10.420,0:46:16.720
mainly by availability. I didn't really[br]cherry pick models. It was just that at

0:46:16.720,0:46:23.020
the place where I was doing my internship[br]then, I was, I had some platforms to play

0:46:23.020,0:46:27.340
around with. You have seen my very[br]professional PSA setup, that was the most

0:46:27.340,0:46:35.350
professional I had. So yeah, this is what[br]I had. And since I in the end found that

0:46:35.350,0:46:43.300
they are still relevant right now, I think[br]that wasn't really harmful in any way. It

0:46:43.300,0:46:47.680
turns out to be a good choice. Your second[br]question was?

0:46:47.680,0:46:52.930
Q: Can those flaws be fixed in an update?[br]Wouter: Oh yes. Well, in some sense,

0:46:52.930,0:46:59.890
except that there is no real[br]infrastructure to roll out updates. So all

0:46:59.890,0:47:03.040
the cars that are out there, I don't think[br]they are going to recall them to update

0:47:03.040,0:47:04.165
firmwares.[br]Q: But normal servicing...

0:47:04.165,0:47:13.000
Wouter: Yeah, yeah, you can do that. It[br]takes time. So it doesn't incur costs for

0:47:13.000,0:47:18.130
the manufacturer. But what you could do,[br]for instance, is just use timeouts in the

0:47:18.130,0:47:26.860
PSA case and make sure it's not too easy[br]to try lots of authentication attempts.

0:47:27.700,0:47:32.695
It's not a fix because it doesn't really[br]fix it. But well, it's certainly a

0:47:32.695,0:47:39.460
mitigation. It somewhat limits the impact.[br]In the Fiat case, it's a bit harder

0:47:39.460,0:47:45.160
because you cannot really change an entire[br]algorithm because there's different

0:47:45.160,0:47:49.060
engines. And yeah, I think that would be[br]quite a hassle. You really have to change

0:47:49.060,0:47:51.880
your protocol there.[br]Q: Thank you.

0:47:52.650,0:47:54.900
Herald: Thank you. Microphone number five,[br]please.

0:47:54.900,0:48:01.200
Q: Are the secrets unique per car? And if[br]so, how do you handle the case when one of

0:48:01.200,0:48:06.330
the units has to get replaced?[br]Wouter: Yeah. The secrets are unique for

0:48:06.330,0:48:16.290
car and replacement frequently involves a[br]procedure to couple the new ECU in the

0:48:16.290,0:48:21.000
current system. And you just have to put[br]the ECU there, connect to the ECU and

0:48:21.000,0:48:25.350
enter the vehicle pin. So that is quite[br]probably also the reason that they reused

0:48:25.350,0:48:29.640
a secret, because if you use a different[br]secret, you have to have some kind of

0:48:29.640,0:48:37.050
complicated secret sharing protocol that[br]well, brings the new ECU up to speed with

0:48:37.050,0:48:39.720
the key material that's being used inside[br]the vehicle.

0:48:39.720,0:48:45.090
Herald: Thank you. Microphone number one,[br]please.

0:48:45.090,0:48:53.070
Q: Hello. So what I'm struggling to[br]understand here is why there was the need

0:48:53.070,0:48:58.890
to decouple the communication in the first[br]place and just split it in two. I can

0:48:58.890,0:49:03.450
guess that is so that the ECU can be[br]trained on new keys. But then isn't it

0:49:03.450,0:49:08.310
easier to just, you know, instead of[br]training like the ECU and telling it: Hey,

0:49:08.310,0:49:15.360
this is the new key's key. Just load the[br]ECU's key on the new transponder.

0:49:15.360,0:49:19.320
Wouter: So if I understand your question[br]correctly is that you wonder why we need

0:49:19.320,0:49:25.320
two different authentication systems, one[br]for the key to BCM and one for the engine

0:49:25.320,0:49:29.280
to BCM and not use the simple model of[br]having the key talk to the engine control

0:49:29.280,0:49:30.120
module.[br]Q: That's correct.

0:49:30.120,0:49:33.810
Wouter: All right. You have to understand[br]that engine development is done by

0:49:33.810,0:49:40.650
different companies and the same engine[br]may be used in various different vehicles,

0:49:40.650,0:49:49.140
maybe even from completely different[br]ranges. And it is complicated to give

0:49:49.140,0:49:55.980
these cars a different firmware. So it's[br]definitely possible. But they just want to

0:49:55.980,0:50:00.060
build an engine and build a car and have[br]it work together. And another car with the

0:50:00.060,0:50:06.660
same engine should also work. So it's, ...[br]it has to do with their process of

0:50:06.660,0:50:13.620
developing vehicles.[br]Q: But then shouldn't also, I mean, I'm

0:50:13.620,0:50:20.460
assuming that the part that talks to the[br]transponder and talks to the engine still

0:50:20.460,0:50:27.032
has to match the engine communication[br]protocol anyway. So, I mean, doesn't the

0:50:27.032,0:50:32.026
car producers still have to match the[br]engine protocol anyway at some points

0:50:32.026,0:50:35.004
anyway, so why just not implement it on[br]the key in the first place?

0:50:35.004,0:50:38.520
Wouter: Yeah. Well, this is all[br]speculation from my side as well. I have

0:50:38.520,0:50:45.620
no inside information as to why they did[br]this. But yeah, I can imagine ways that

0:50:45.620,0:50:53.598
they could fix this and they don't do it.[br]And my experience is that generally this

0:50:53.598,0:50:59.842
has to do with legacy and compatibility[br]issues. They could also just embed five

0:50:59.842,0:51:05.549
algorithms in the BCM or the engine[br]control module and just by configuration

0:51:05.549,0:51:10.852
choose the one that fits for that vehicle.[br]I have no idea why they don't do that. But

0:51:10.852,0:51:15.496
once again, these are not software[br]companies. These are automotive companies.

0:51:15.496,0:51:18.901
Q: Awesome. Thanks.[br]Herald: Thank you. Microphone number

0:51:18.901,0:51:23.151
three, please.[br]Q: Thank you for the great talk. Once we

0:51:23.151,0:51:29.570
have the OBD connected to the Internet and[br]do you see any other complication that

0:51:29.570,0:51:33.910
could prevent me to park the car remotely[br]from there?

0:51:33.910,0:51:43.391
Wouter: OBD connected to the Internet...[br]Now well, no. Why? Once you have OBD

0:51:43.391,0:51:53.079
access so you can use the OBD port you can[br]do a lot. There are cars that use a

0:51:53.079,0:51:59.203
gateway that is some kind of filter or you[br]have to authenticate towards it before you

0:51:59.203,0:52:02.975
can access the internals of the vehicle.[br]So it really depends on the model. It

0:52:02.975,0:52:07.995
depends on the manufacturer to which[br]extent you have room to maneuver there.

0:52:07.995,0:52:12.777
For some, it would be super easy, for some[br]it would be a lot of work. For some, it

0:52:12.777,0:52:17.288
might be impossible. But you certainly[br]have a very, very good starting point.

0:52:17.288,0:52:21.300
Q: Thank you.[br]Herald: Microphone number one, please.

0:52:21.300,0:52:26.676
Q: Hello. Did you spot any kind of anti-[br]brute force measures during your analyses?

0:52:26.676,0:52:30.678
That's the question number one. And[br]question number two is: Obviously you had

0:52:30.678,0:52:35.960
access to the internal communication[br]between the BCM and ECM, but were those

0:52:35.960,0:52:42.332
attacks successful on Fiat and Peugeot,[br]are they doable using just the OBD-II

0:52:42.332,0:52:47.127
port? Or do you actually need to see the[br]internal communications?

0:52:47.127,0:52:52.589
Wouter: I tried to point out in the[br]beginning of my talk that I carry out all

0:52:52.589,0:52:59.361
the attacks presented and I focused only[br]on functionality that is exposed through

0:52:59.361,0:53:05.307
OBD. So, yes, I did some stuff on the[br]hardware of the ECUs, but that was just

0:53:05.307,0:53:10.424
for research. So the attacks are[br]absolutely doable over OBD.

0:53:10.424,0:53:16.738
Q: OK, and the previous question there,[br]which was already partially answered.

0:53:16.738,0:53:21.049
Wouter: Yes.[br]Q: So no, like, locking out after five

0:53:21.049,0:53:26.615
failed trials?[br]Wouter: I did find something that was

0:53:26.615,0:53:36.668
peculiar in the PSA case, and that is that[br]if you... let me think. There is rate

0:53:36.668,0:53:45.562
limiting implemented in the PSA on the[br]engine control module. Is that right? No,

0:53:45.562,0:53:51.957
on the body control module. And that means[br]that if you spam challenges, it will at

0:53:51.957,0:53:57.440
some point no longer give you the[br]response, which sounds like a good idea,

0:53:57.440,0:54:01.803
right? Rate limiting. But they did it on[br]the wrong side.

0:54:01.803,0:54:06.136
Q: Okay, great. Thank you.[br]Herald: Thank you. Microphone number two,

0:54:06.136,0:54:08.610
please.[br]Q: Have you spotted some kinds of

0:54:08.610,0:54:13.478
relationship between this, like public[br]identifier of the car and the secret used

0:54:13.478,0:54:20.555
to authenticate in the service?[br]Wouter: Yeah, so if the VIN in some ways

0:54:20.555,0:54:28.609
could be converted in the secret, the PIN[br]code of the car. No, I see where you're

0:54:28.609,0:54:31.991
headed, but I haven't spotted anything[br]like that.

0:54:31.991,0:54:35.253
Q: Okay. Thanks.[br]Herald: Questions from the Internet?

0:54:35.253,0:54:40.545
Signal Angel: No more.[br]Herald: No more. In this case, ladies and

0:54:40.545,0:54:58.635
gentlemen, bedankt Wouter Bokslag. Thank[br]you very much.

0:54:58.635,0:55:13.200
*applause*

0:55:13.200,0:55:17.815
*postroll music*