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