36C3 - Vehicle immobilization revisited

Herald: The second thing I wanted to
announce: there is no scooter sharing.

Which brings me to the next talk. We tend
to need kind of a security concept for not

scooter sharing. So the easiest way would
be to have kind of a scooter lock. But we

have the lock picking guys. So that won't
work. So the next option would be we can

have a GPS tracker, but we have the GPS
spoofing guys. Which isn't also that good.

A third option would be an immobilization
system. We have Wouter Bokslag. Thank you.

*applause*

Wouter: Hi. Thank you for the
introduction. Thank you guys for the warm

welcome. I'm really happy to see that
still some people have come together here

at this ungodly hour to watch my talk
about vehicle immobilization. Well,

briefly something about me. I'm a
Kerckhoff security master. And the

research I will be presenting today, I did
as my master's thesis. So I spent about

half a year analyzing various systems and
I wrote something about that. And if you

want to read the full story, you can look
at my thesis, which is public since some

time now. And there's more detail there.
I'm currently working as an automotive

engineer. And if you feel like asking me
questions besides the Q&A, you can always

contact me by mail. So first, responsible
disclosure. This kind of stuff is not a

joke. Automotive manufacturers think it is
very important. And, well, they have a

reason to think so. So naturally we
contacted them ahead of publication even

before my defense and we laid out the
findings and I had a couple of conference

calls with the manufacturers. And I even
went to one of them to demonstrate the

findings on premise. I need to point out
that the research that I did was on fairly

old vehicles like 2009 and around. But for
the three cases that I really went in

depth we have been able to confirm that
they are still in currently produced

models. So this in itself is kind of
surprising because you think automotive,

cars, electronics, security, it's a fast
moving industry, but well, no, not really.

So everything that was in cars in 2009, at
least regarding to these three systems,

can still be found in currently produced
models. I will disclose the vehicles that

I've been working on, because I think that
is relevant. I hope you can forgive me

that I'm not going to disclose the
vehicles that I have identified these

systems in that are still being produced.
I'm not really into facilitating theft and

I don't see what would be the added value.
So the talk will be structured as follows:

I will first introduce some standard stuff
about immobilization systems and about

computer networks inside vehicles. I will
tell you something about how I addressed

the challenge. So for all three models, I
kind of followed a similar approach and I

think it's more practical to lay that out
once and then skip the details later on.

And then I will present the three
protocols that I uncovered in a Peugeot, a

Fiat and an Opel vehicle. I will then
summarize the findings in a series of

takeaways and there will be some time for
questions. Right. So modern vehicles are

full of electronics and full of computer
systems. They operate largely independent.

They are all connected through a variety
of different buses that talk to each other

with different protocols. And there is a
plethora of different standards, ISO

standards, all kinds of standards. And
then the manufacturer wants a lot of

freedom to, well, do it in their own way.
So even if you read these hundreds of

pages of standards, still every vehicle
you will look at will be kind of

different. There are some practical
handles that you can use, and one of them

is that every car has a OBD-II port. Yeah,
this is required by law, both in the US

and in Europe for quite some time now. And
it needs to be conveniently located and

that is very near the driver's seat. So
this is a universal connector and all cars

with a combustion engine need to have one.
And cars with electronic engines also need

to have one. But the functionality that
has to be implemented is much more

limited. So in regular internal combustion
engine powered cars, you have to be able

to read out emissions data and that kind
of stuff. So many manufacturers felt this

was a very convenient thing to also use
for garage purposes, for workshops to read

out error codes, to perform all kinds of
routines on vehicles. You might need to

teach new keys to your car if you lost one
or if you just want a third one. If you

add a towbar to your car, you need to tell
a couple of ECUs in the car that it now

has a towbar. Depends on the vehicle, but
telling this to 5 individual ECUs is not

an exception. And since it is a bus, the
CAN bus, it can be directly addressed

through the OBD connector on many vehicles
and you can talk to a lot of different

components. So the ECM, the Engine Control
Module, is one, the body control module is

another. That one controls, for instance,
powered windows and all kinds of interior

stuff, but also the airbag, infotainment
system, fancy interior lighting, stability

control systems. Another feature of it
being a bus is that you can also see the

inter-component communication. So if the
instrument panel cluster, the dashboard,

needs to talk to, say, the body control
module, you can see that packet going over

the CAN bus. All my research has been
focused on this OBD-II connector and what

you can do and what you can see from this
perspective. Immobilizer systems are

nowadays required to be implemented in
vehicles. Since the late 90s, legislation

has been adopted in both the States and
Europe, mandating the use of an electronic

immobilization system. And the purpose, of
course, was to reduce the risk of theft.

This is proven to be effective: According
to one study, theft rates dropped by

almost 40% in, I think, a 7 year span they
based their data on. This is because car

theft used to be quite simple. You could
just put two wires together and you could

power the starting circuit and you could
actually start the engine. And the

immobilizer system adds another step to
that. The engine control module that

finally controls the engine wants to have
some kind of assurance that the key

presented in the system is actually valid
and does so by validating a security

transponder. First generations of these
security transponders have been widely

studied and often were found insecure. Of
course this is a problem because well, if

it's insecure, it doesn't add any security
and cars can be stolen nonetheless. So

there has been kind of an arms race in
this domain and we see that nowadays

security transponders have become a lot
better. Your car might even use AES to

validate that the key you're putting in
the ignition is an actual key that is

recognized by your vehicle. And this is
really necessary because car thieves have

shown to be able to wield quite high tech
solutions, procure them from shady

companies or just use official tools that
can be used in illegitimate ways. A nice

example of this is shown here. For certain
models of Range Rover, they have a blind

spot sensor, so you can see if there is a
car in your blind spot. And if you pop off

a cap, then you can connect a 12V battery,
power the internal ECUs of the vehicle.

Then you can access the CAN bus, put the
car into key teaching mode and hold a

blank key to the window and it will
program the key and recognize it as a

valid key. Well, needless to say, this was
not intended behavior

*laughter*

and this has had consequences for
consumers. Because insurance companies saw

a rise in theft for these models - these
are quite expensive cars - and they

started adding demands before they would
allow you to insure your car. So the

insurance would get more expensive or you
would not be able to get the insurance if

at least at your own home, you couldn't
park it in a secured area. There is a

common misconception about how immobilizer
systems work, and it's actually one of the

reasons I want to give this talk and
present this, because I think it's

important to realize that an immobilizer
system is a bit more complicated than the

single cryptographic step that seems
logical. So what you might think is that

the engine control module sends a
challenge to the body control module,

which communicates with the key. It
implements the radio layer and it can then

relay the challenge to the key. The key
can compute the proper response based on a

secret it shares with ECM, send back the
response, which the BCM will in turn

forward to the ECM. The ECM can verify the
validity, and if this seems to be the

right response, immobilization is
deactivated and the car can start. Sounds

good. Sounds easy, but this is in modern
cars no longer the case. 'course. What we

see is that there is a second step. The
ECM does an authentication with the BCM.

The BCM does an authentication with the
key. So if your key uses say AES for its

authentication, then this will be an AES
secured authentication between the BCM and

the key. The BCM, if it can validate the
legitimacy of the key, will then send the

correct response to the engine control
module. But this is a whole different

protocol, using different cryptographic
primitives, using different keys,

sometimes, often, don't know. And more
importantly, it has not yet been covered.

So in the scientific literature, I have
found absolutely zero reference of this

step being identified. And here and there
you find a reference that people know that

this happens, but no actual analysis of
the security or the cryptographic

primitives involved. Right. So that is an
open question then and asks for further

research. So how do you do that? You can
sniff CAN traffic from the OBD connector

with tooling. And by disconnecting ECUs
and placing yourself in the middle you can

also modify CAN traffic. You can analyze
this CAN traffic, see if you can find

immobilizer-related messages. And of
course, by the messages, you cannot deduce

the algorithm, most of the time. So you
will need a firmware image or something

else you can reverse engineer to actually
find the code that does the magic stuff.

If you have that and if you are able to
pinpoint where the algorithm is, then you

can start looking at if it's actually
decent. And once you are all there you

will want to test if all the assumptions
you've made on the way are correct and if

it's actually working as you think it's
working. So the first step, protocol

identification, is actually quite
straightforward because you have some

knowledge. You know that this is a message
exchange that happens when you switch the

ignition to the on position. And you know
that there must be at least two high

entropy messages because the challenge has
to be different every time. And the

response is the output of some
cryptographic function. So it may be

expected that that looks quite random,
too. Also, if you switch the ignition on

but no valid transponder is present, you
should be able to detect some kind of

difference. And it will probably be the
very first moment you observe a

difference, because before that point, the
car didn't know there was no valid

transponder. So with a bit of fiddling and
some patience and going through CAN

traffic logs, you can probably find this.
OK. Next step is to get a firmware image

in which you hope to be able to find the
actual cryptographic protocol. So there

are several options. Of course you already
have the firmware, but it's in the

microcontroller in an ECU that is either
lying on your desk or inside some vehicle.

So you could try to get it straight out of
that device. Debugging headers are a good

option. You have JTAG, you have BDM, UART
occasionally can be used, but sometimes

these are deactivated. Sometimes it just
doesn't seem to work. Sometimes the

tooling is prohibitively expensive. So if
that doesn't work, you can always go to

the internet. Some manufacturers provide a
means to download a set of information

about the vehicle based on its VIN number.
You can find all kinds of configurations,

you might be able to find actual parts or
full firmwares, often encrypted, not

always. And then there is the tuning
scene. And while you might think of neon

lighting and stuff like that, these guys
are actually pretty knowledgeable about

the internals of engine control modules in
particular. And you might just be able to

find a full firmware image or parts of it
or some model that is highly related. And

this is kind of a viable approach to
getting your hands on the firmware. But

also very practical can be to just
leverage the functionality that is

implemented in the ECU. The ECU allows for
diagnostic commands such as read memory by

address and request upload, which from the
perspective of an ECU is sending new data.

And you might be able to just dump the
whole firmware or dump memory or dump at

least parts of the the internals of the
ECU. Then there is some kind of mechanism

that's called second bootloader. It's a
sort of standard. Not every manufacturer

implements it, but quite some do. That
allows you to actually send binary code to

the ECU. And it then jumps to it. So very
convenient functionality. It's maybe very

painstaking to get it working, but yeah,
it's basically free code execution. Except

for the fact that you often need to
authenticate before you're allowed to use

such functionality. So that might leave
you with some kind of chicken and egg

problem, because you don't know how to
authenticate, you don't have the algorithm

for this authentication. And lastly, there
are sometimes firmware updates for ECUs

and you might be able to use an official
dealer tool, you might be able to sniff

CAN traffic. Multiple ways of trying to
update the firmware on your ECU

reconstructed from the CAN traffic. Once
more, you have to go through an ISO

standard before you understand how it's
exactly chunked in 8 byte messages, but

you'll get there eventually. So once you
have this firmware, you have to pinpoint

the cryptographic algorithm and ECU
firmwares are typically between half a

megabyte and 2 megabytes. And that is a
lot, if we're talking assembly. And the

information density is extremely low. And
if you have to go through it line by line,

it's hardly doable. So you need to have
some tricks. I think we're at a conference

where we've seen a lot of reverse
engineering. So this is not going to be my

focus during this talk, but a couple of
pointers. Maybe someone is helped by that.

Of course, you know the protocol because
you have observed CAN traffic. So you can

search for immediate values, for numerical
values that are used in the protocol to

designate a packet type, for instance. It
must be in the firmware somewhere. Also,

you know that crypto usually uses XOR
instructions and you would be surprised

how little XOR instructions there are in a
firmware. Depending on the architecture,

you might immediately dismiss most of
those as a single bit flip or maybe

inversion of a whole register, and then
you will find some XORs with either weird

constants or variables. So those are
points to focus on. Lastly, you can make

some assumptions on the structure of the
cryptographic function, so it certainly

doesn't do IO, it will not invoke a lot of
other external functions, maybe some round

function once or twice, maybe some
initialization. It will probably have some

loops and you can sometimes recognize the
length of the challenge. You can sometimes

recognize the length of the response. That
being said, let's dive in the first case

study. So I reverse engineered the Peugeot
207, which is, as I said, not the most

recent of vehicles. And this was my test
setup. It doesn't look like much, but

everything that's relevant to me is there.
And you can toggle the ignition and lights

will show and all the ECUs are connected
through a CAN bus and an OBD connector

that you can see on the left side of the
instrument panel. And I investigated a

tool that had a kind of peculiar function
and that is that you could obtain the

vehicle PIN - some kind of secret you
needed to authenticate for diagnostics -

by connecting this tool and toggling the
ignition a couple of times. So that kind

of gives you a hunch that the
immobilization system might be involved,

because it's triggered upon toggling the
ignition, and that you can derive in some

way the vehicle pin from this. So for this
Peugeot and for most BSA vehicles in

general, the PIN is a four digit uppercase
and numeric code excluding the O and I,

because that would be confusing. So that
leaves us with roughly one point three

million keys, which is nothing in terms of
crypto. I finally reversed the algorithm.

It is obviously in the engine control
module and the body control module. And

the main part looked like, oh wait, wait
for it. And the protocol looks like this.

So if you observe CAN traffic, you will
see that some CAN ID 72. On that ID is

sent a message that starts with 00 and
then followed by a 4 byte challenge. And

if the BCM is able to verify that a valid
key is present, it will respond with 04

and a four byte response. So this is a
very small, straightforward protocol,

which, well, does the bare necessary. And
one of the first things I did was

injecting challenges. Just inject a
challenge, send it to the BCM with a valid

key and see what the response is going to
be. And if I replace the zeros by dots,

you see that there's an extremely apparent
pattern is visible. So the ideal case that

a single bit flip in a challenge leads to
a 50/50 chance of a bit flip in every

response bit is not exactly respected. You
see that the effect of changing the

challenge has a very localized effect on
the response. Another weird feature, which

is not very clearly visible here, but it's
visible in the last one, is that on

average, when you give average just random
challenges, 75% of the bits of the

response will be set. So that is a very,
very heavy bias. And it was quite puzzling

to me what kind of cryptographic primitive
would exhibit such behavior. And then it

became clear. this is the main function of
the algorithm and there is a transform

function that I left out, but it basically
does some multiplication, some division,

some modulo, mathematical operations, It
splits the challenge in two parts and it

splits the vehicle PIN, so the secret in
two parts. And the total of four parts are

all used as inputs for this transform
function and we obtain a challenge

transformed left challenge transformed
right and similarly for the PIN a left and

right transformed part. And then something
interesting happens because the left

transformed part of the challenge is ORed
with a part of the PIN. And an OR

operation will lead to a, well, on average
75% set result. So that kind of explains

the weird behavior we saw before. Strange
and maybe not so smart, because an

adversary will be able to either control
or observe the challenge that is used as

input for this algorithm. So if you know
the challenge, you know the transform

challenge, and if you know to transform
challenge, you know something about the

output. Because if the transform challenge
has a one bit, then the response will have

a one bit in that same position. There is
another property for the transform

function, and that is that if the input is
a zero, the further parameters of

transform vary a bit, but it doesn't
affect this property: if the input is a

zero, the output is a zero. So that gives
us that if you have a challenge of all

zeros, you will obtain a transform
challenge of all zeros. And that means

that when you're doing the OR you're ORing
with nothing and the response will be

entirely determined by the transformed
PIN. Then another property is that the

PIN, which is an alphanumeric PIN, is
invertable once. Let me restart.

Transform: If it takes a PIN as input,
then the output can be inverted. There is

only one PIN part input that maps to one
output of the transform function. So if

you are able to supply the vehicle with a
challenge of zeros, you will get one

response and you can uniquely identify the
secret of the car, the PIN. And this PIN

can later be used to, for instance,
authenticate for diagnostics or key

teaching or whatever you want. If you're
not able to control the challenge, you can

just collect a couple of random challenge
responses and you will still have the PIN.

So that's bad. What's worse is that there
are a lot of collisions because the bits

that are set in the challenge transformed
will hide the bits that are set in the PIN

transformed. So a challenge transformed
with a lot of ones set will accept a lot

of different PINs as proper input and
result in the same response. So there is a

quite simple attack we can mount here and
that is that we get a challenge from the

car without a valid key present and we
then compute for that challenge for all

PINs what response it would yield. And you
will see that some PINs, sorry, some

responses are generated by a lot of
different PINs. It could easily be two-,

three thousand PINs resulting in the same
challenge. So you choose the most probable

response and you send it and either the
ECU accepts it and disables immobilization

or it doesn't. And if it doesn't accept
it, then you know for three thousand pins

that it was not that. In general this
takes far less than 4000 attempts and and

far less than 15 minutes. I don't know
exactly. I've tried it a couple of times

and I've been able to deactivate
immobilization, I'd say, 3 minutes once,

maybe 10 minutes once. And after that, if
you toggle the ignition switch, the car

will actually start without transponder
present. So. That was not so good. Next

case is the Fiat I investigated, the
Grande Punto and I reverse engineered the

BCM. It's based on the NEC V850
architecture, which is a nice 32 bit RISC

architecture, pretty readable, pretty fair
information density. But still, I couldn't

really figure out what the actual crypto
part was. So I also investigated an engine

control module. Surprisingly, I was able
to find it there. And then I immediately

went back to the V850 because that at
least is readable code. Protocol is as

follows: It has a 32 bit challenge, then a
4 bit - sorry - 4 byte challenge, then a 2

byte proof of knowledge. And that's an
interesting feature, because that way the

engine control module proves to the body
control module that it actually has

knowledge of the key. So you can not just
spam a challenge and get a get a response

for that. You have to prove that you know
the secret. And then you get back a 2 byte

response. And if that is correct, the ECM
accepts it and the car can start. And this

very well, seemingly nice security feature
that there is a proof of knowledge of the

key is actually the flaw in this system,
as it turns out. The cipher is a linear

feedback shift register based cipher. It
initializes the states with the key, XORed

with the challenge, XORed with some
constant. And then it does 38 rounds. If

you don't know what an LFSR is I'll tell
you in the next slide. Then it generates

the proof. That is 12 rounds, actually 12
bits output. And if you look back in the

protocol, you actually see that the first
nibble is indeed a zero. So it's not 16

bits, but it's only 12 bits. After
generating the proof, it loads an

additional 16 bit constant and then
generates the 14 bit response. This is a

very standard construction in crypto and
there is a fairly standard attack to it.

So what you see here is an LFSR, it's a 32
bit register and it operates in ticks. So

it is loaded with this initial secret
state at the beginning of the algorithm

and each tick it takes 4 bits and they are
XORed together. Then the whole register

shifts one position to the left. So bit 0
goes to bit 1, 1 to 2, etc. Bit 31 shifts

out and the previously computed XOred bit
is shifted in in the 0 position. So that

way it cycles and continuously updates its
internal state. And then there is an

output function that takes 8 bits of input
and each tick it computes one bit from an

8 bit input, and on the lower left you can
see the output generation table. So it

kind of just counts through this. And if
the eight bits together add up to say A2,

then you pick bit position A2 in this
table and that is then the bit that is

being generated as proof or response bit
during that round. Now what we see here is

that there is actually 8 bits of the LFSR
that determine the output bit. And of

these 8 bits they generate 256 different
values. Now there are 256 different

combinations and only half will generate
the observed output bit. So that means

that 128 different options may be valid
options for these 8 bits to generate a

response or a proof that we have observed
earlier. And that is pretty interesting.

And you can use that to construct a guess
and determine attack. Which means that you

make an assumption on the internal state.
We have 128 candidate internal states. And

then we do a round. So we shift the
guessed bits one position to the left. We

do the feedback function and then we are
going to evaluate the second bit that was

generated. For the second bit we already
have some knowledge, because we made

assumptions earlier. So the green squares
designate the bits that we already know.

And you see that throughout the rounds,
each round you can eliminate half the

candidates, because they generate the
wrong output bit. And you need to guess

less and less bits in order to to fill in
the state. And this continuous elimination

of half the candidate states makes this
far more efficient than just a brute force

attack. The total complexity of this
attack is 2^21, which is orders of

magnitude less than mounting a brute force
attack. Right. So that's OK. That is

fairly standard stuff in crypto. Now,
there is a big problem in the way they

implemented this, because they did some
secret reuse. And the secret that is being

used to generate the proof is in some
mangled way the vehicle PIN. If you take

this 32 bit secret input value and you
take the 5 rightmost nibbles and then

transform the letters into numbers and
then replace the zeros by sevens, then you

get a 5 digit number and that number is
the PIN. So what we have now is an attack

that observes a couple of challenges
together with their proof of knowledge,

which is always there, and you get it for
free when you just power the ECU, and you

run an attack on that. That takes, well,
my not so optimized implementation takes 6

seconds on a single core. You can probably
do better. Runs in seconds. And what you

get is the PIN. So you can still not
authenticate towards the ECM, but you do

get the pin which you can then use to
authenticate for diagnostic services, you

can, maybe, read memory, you can, maybe,
reprogram stuff, you can, maybe,enter key

teaching mode. There is absolutely ways to
leverage this and, well, get the car to

start. The 3rd case I investigated was an
Opel Astra H. And I've decided to skip the

crypto parts in this one because I
couldn't break it and I wouldn't want to

bore you with a fairly complicated
algorithm and then not present an attack.

If you're interested, it's in my thesis so
you can look it up. But there is still

some funny things to point out here. I
reverse engineered an ECM that was based

on a PowerPC architecture microcontroller.
And that is very nice because there is a

decompiler for that. And IDA Pro will
nicely transform the assembly into

somewhat accurate, somewhat readable C
code. That was good, but it was not

enough. So I purchased some tool to use
the BDM interface of this ECU which was

active and usable. And it took me a lot of
time to get the tools working, because

virtual machines were not okay, etc etc. I
installed Windows and did crazy stuff. And

then I was able to read memory, modify
registers on the actual ECU, and that

helped a great deal in debugging and
finding the actual functions. So this is

the protocol that I found. It has a 2 byte
opcode, then 2 bytes status data, then a 4

byte challenge. And similarly 2 byte
opcode for the response, 2 byte status

data, 4 byte response. No proof of
knowledge here. Just a 32 bit to 32 bit

challenge-response authentication. And
what was funny when I finally uncovered

the algorithm is that this is not an
algorithm that was designed by Opel. It is

an algorithm that is used by a security
transponder. It is used by the PCF7935

security transponder, which is the
predecessor of high tech II, which you may

be familiar with it. It uses a 128 bit
secret. So that is really, really big

secret, and a 32 bit internal state. When
I saw that 32 bit internal state, I was

like, OK, this is going to be doable. It
wasn't. Because it does a lot of rounds

between output moments. Not as in the FIAT
case, one round, one bit output. It does

34 rounds and then it outputs two bits and
then it does another 34 rounds and two

more bits. And during these 34 rounds, it
mixes the whole 128 bit secret key into

the state. There is so much distance
between these moments that it is very,

very hard to relate any of this
information or any usable assumption that

survives so much new mixing of
information. I did my best. I found some

stuff. Nothing that is usable to mount an
attack. You can read my thesis if you're

interested in the details. I found it
funny to find an implementation of a

security transponder in an engine. While
I, In the beginning of this talk pointed

out that the engine doesn't talk with the
transponder. So I went back in time and I

analyzed another vehicle, a Corsa Model C
and found that this was different. This

car had indeed an engine that talks with
the key. And what probably happened is

that they wanted to decouple development
of engines and development of cars so they

could upgrade security transponders
without replacing their engines or

replacing their engine firmwares. So I
think that is how this happened and why

they just decided to well, then implement
the security transponder and emulate it in

the body control module towards the
engine. It seemed like a convenient

solution, I guess. It is by far the
strongest algorithm I have encountered in

these three case studies. And while it is
out of scope because I limited myself to

the actual cryptographic primitives, I
felt the need to point out that the random

number generator is really not very good.
They use the tick counter of the CPU as

source of randomness and then they use a
couple of constants that, if you google

them, direct you to the Netscape random
number generator. So summing it up: We

found that Peugeot used a tiny key space
with only 1.3 million different possible

PIN codes. They leak a lot of information
in the response. If you can inject a zero

challenge, you immediately get the full
secret. It has a lot of collisions, which

makes it really not very robust against an
adversary. Fiat has a schoolbook algorithm

and it's vulnerable to schoolbook attack.
It's a nice idea to implement neutral

authentication, but it doesn't really work
in this context. And worse, they reuse

that part of the secret as the vehicle PIN
as opposed to using the other part of the

secret that is used to generate a
response. If that would have been the

vehicle PIN I would not have been able to
mount this attack. And lastly, Opel

decided to clone an obsolete security
transponder. The successor, high tech II,

was desperately broken. This one wasn't.
Not by me. I have a master's degree, not

in cryptanalysis. I'm not convinced that
it's a secure transponder, but it is

certainly better than the other two I
analyzed. And also interesting is that all

these three systems are still around in
new vehicles. Maybe not all models, but

they're still being manufactured. So I am
curious to see how this relates to other

manufacturers, other models. And I think
it would be interesting to, well, do some

further research in this domain and see
what else is out there. So to finish with

a few takeaways. Don't do your own crypto.
It's often said and repeated. You are

going to mess it up. Just use standardized
cryptographic components and maybe try to

get people that are actually security
experts to implement it instead of hoping

for the best. Don't reuse secrets. These
two case studies revealed that reuse of

secret made the attack much more powerful
than it needed to be. Minimize the number

of cryptographic protocols and
cryptographic primitives that you're

using. The more different primitives, the
more attack surface you create for an

adversary. And lastly, as I mentioned
before, there has been an arms race in

transponder security. How is it possible
that a modern car key may be equipped with

AES or other fairly secure cryptographic
features, and these protocols that date

from 1995 and such are still there, not
replaced. Apparently no one either figured

it out or there are other very important
reasons to just leave them there. So I

hope that was interesting. Maybe
entertaining and I'll happily take any

questions you have for me.

*applause*

Herald: Bedankt Wouter Bokslag. Thank you.
You know the game if you have questions -

oh, we already have questions. There are
microphones, microphones number 1 to 7 and

2 to 8. And the Internet has questions
already. So we start with the Internet.

Internet, please.
Signal Angel: Why don't make cars more use

of rings of security or layers or
permissons system?

Wouter: Oh, well, this is embedded
security. This is not a PC or smartphone

security. It's embedded security. And I
think automotive manufacturers do their

best, but this is just not their game. And
yeah, there is plenty of ways you could do

this in a more secure manner. But they
didn't. I cannot really say, why not do it

better? Of course they should do it
better. But I think it's understandable

that they may be a bit behind on this game
that is relatively new to them.

Herald: Thank you. And microphone number
one.

Q: Hi. Amazing work, but I have a
question. Did you find any simpler, more

entertaining mistakes like storing the PIN
in the open, in other components in the

car?
Wouter: Well yeah, I did do some other

stuff besides the 3 cases I presented
here. I also investigated some

authentication mechanisms for diagnostic
functionality and I didn't put them in my

thesis because it's nice to have a clear
message and a clear line of research. But

I've seen authentications that are really
pretty hilarious, such as challenge -

secrets - subtract - response.
Herald: Answered? I think this is a yes.

Microphone number 2, please.
Q: Hey, thank you for the talk. Two short

questions. How did you specifically choose
those two cars, those three cars, and

which parts or are parts of these flaws
fixable in later firmware, bootloader,

software, coding, update, whatever?
Wouter: Yeah, Okay. I chose these cars

mainly by availability. I didn't really
cherry pick models. It was just that at

the place where I was doing my internship
then, I was, I had some platforms to play

around with. You have seen my very
professional PSA setup, that was the most

professional I had. So yeah, this is what
I had. And since I in the end found that

they are still relevant right now, I think
that wasn't really harmful in any way. It

turns out to be a good choice. Your second
question was?

Q: Can those flaws be fixed in an update?
Wouter: Oh yes. Well, in some sense,

except that there is no real
infrastructure to roll out updates. So all

the cars that are out there, I don't think
they are going to recall them to update

firmwares.
Q: But normal servicing...

Wouter: Yeah, yeah, you can do that. It
takes time. So it doesn't incur costs for

the manufacturer. But what you could do,
for instance, is just use timeouts in the

PSA case and make sure it's not too easy
to try lots of authentication attempts.

It's not a fix because it doesn't really
fix it. But well, it's certainly a

mitigation. It somewhat limits the impact.
In the Fiat case, it's a bit harder

because you cannot really change an entire
algorithm because there's different

engines. And yeah, I think that would be
quite a hassle. You really have to change

your protocol there.
Q: Thank you.

Herald: Thank you. Microphone number five,
please.

Q: Are the secrets unique per car? And if
so, how do you handle the case when one of

the units has to get replaced?
Wouter: Yeah. The secrets are unique for

car and replacement frequently involves a
procedure to couple the new ECU in the

current system. And you just have to put
the ECU there, connect to the ECU and

enter the vehicle pin. So that is quite
probably also the reason that they reused

a secret, because if you use a different
secret, you have to have some kind of

complicated secret sharing protocol that
well, brings the new ECU up to speed with

the key material that's being used inside
the vehicle.

Herald: Thank you. Microphone number one,
please.

Q: Hello. So what I'm struggling to
understand here is why there was the need

to decouple the communication in the first
place and just split it in two. I can

guess that is so that the ECU can be
trained on new keys. But then isn't it

easier to just, you know, instead of
training like the ECU and telling it: Hey,

this is the new key's key. Just load the
ECU's key on the new transponder.

Wouter: So if I understand your question
correctly is that you wonder why we need

two different authentication systems, one
for the key to BCM and one for the engine

to BCM and not use the simple model of
having the key talk to the engine control

module.
Q: That's correct.

Wouter: All right. You have to understand
that engine development is done by

different companies and the same engine
may be used in various different vehicles,

maybe even from completely different
ranges. And it is complicated to give

these cars a different firmware. So it's
definitely possible. But they just want to

build an engine and build a car and have
it work together. And another car with the

same engine should also work. So it's, ...
it has to do with their process of

developing vehicles.
Q: But then shouldn't also, I mean, I'm

assuming that the part that talks to the
transponder and talks to the engine still

has to match the engine communication
protocol anyway. So, I mean, doesn't the

car producers still have to match the
engine protocol anyway at some points

anyway, so why just not implement it on
the key in the first place?

Wouter: Yeah. Well, this is all
speculation from my side as well. I have

no inside information as to why they did
this. But yeah, I can imagine ways that

they could fix this and they don't do it.
And my experience is that generally this

has to do with legacy and compatibility
issues. They could also just embed five

algorithms in the BCM or the engine
control module and just by configuration

choose the one that fits for that vehicle.
I have no idea why they don't do that. But

once again, these are not software
companies. These are automotive companies.

Q: Awesome. Thanks.
Herald: Thank you. Microphone number

three, please.
Q: Thank you for the great talk. Once we

have the OBD connected to the Internet and
do you see any other complication that

could prevent me to park the car remotely
from there?

Wouter: OBD connected to the Internet...
Now well, no. Why? Once you have OBD

access so you can use the OBD port you can
do a lot. There are cars that use a

gateway that is some kind of filter or you
have to authenticate towards it before you

can access the internals of the vehicle.
So it really depends on the model. It

depends on the manufacturer to which
extent you have room to maneuver there.

For some, it would be super easy, for some
it would be a lot of work. For some, it

might be impossible. But you certainly
have a very, very good starting point.

Q: Thank you.
Herald: Microphone number one, please.

Q: Hello. Did you spot any kind of anti-
brute force measures during your analyses?

That's the question number one. And
question number two is: Obviously you had

access to the internal communication
between the BCM and ECM, but were those

attacks successful on Fiat and Peugeot,
are they doable using just the OBD-II

port? Or do you actually need to see the
internal communications?

Wouter: I tried to point out in the
beginning of my talk that I carry out all

the attacks presented and I focused only
on functionality that is exposed through

OBD. So, yes, I did some stuff on the
hardware of the ECUs, but that was just

for research. So the attacks are
absolutely doable over OBD.

Q: OK, and the previous question there,
which was already partially answered.

Wouter: Yes.
Q: So no, like, locking out after five

failed trials?
Wouter: I did find something that was

peculiar in the PSA case, and that is that
if you... let me think. There is rate

limiting implemented in the PSA on the
engine control module. Is that right? No,

on the body control module. And that means
that if you spam challenges, it will at

some point no longer give you the
response, which sounds like a good idea,

right? Rate limiting. But they did it on
the wrong side.

Q: Okay, great. Thank you.
Herald: Thank you. Microphone number two,

please.
Q: Have you spotted some kinds of

relationship between this, like public
identifier of the car and the secret used

to authenticate in the service?
Wouter: Yeah, so if the VIN in some ways

could be converted in the secret, the PIN
code of the car. No, I see where you're

headed, but I haven't spotted anything
like that.

Q: Okay. Thanks.
Herald: Questions from the Internet?

Signal Angel: No more.
Herald: No more. In this case, ladies and

gentlemen, bedankt Wouter Bokslag. Thank
you very much.

*applause*

*postroll music*