This subtitle is not finished yet. If you are able to, please support us and watch the talk in amara for the last changes: https://c3subtitles.de/talk/1273 Thanks!
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*
Subtitles created by many many volunteers and the c3subtitles.de team. Join us, and help us!