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