We're getting ready to start now. This is an introduction to AUTOSAR. Jeff cannot be here
today. Don is speaking on his behalf. Hello and welcome. Can you get the door,
please? Thanks. So just a quick intro of what we're going to do here. So basically this is
talking about not just AUTOSAR which is automotive open systems architecture which is where
the whole automotive industry is going to for their development in electronics but specifically
towards secure onboard communication, talk about what that is, how it's done and also discuss
some of the weaknesses, one of which we are exploiting in the room right across the way right
now and doing a brute force hack on it which will be done before the end of the day. So I'm not
Jeff and I did not spend 13 years. Actually, I spent nine years at that same company and
I spent a lot more time before that working in automotive and also non-automotive like
defense aerospace stuff. But basically everything we're talking about today is an open standard.
That's part of what the automotive industry is trying to go to because open standards, we hope
we save money, we hope we don't have to have our suppliers remake that wheel again. If you'd
like to see these slides or follow along, right there is your URL. So we're going to talk about
that. Hopefully you know what CAN is or controller area network. Hopefully you know what an ECU is
or module or embedded computing. You're going to need to know about that. So basically we're
going to start out with where we're at now and where we're moving towards trying to secure our
onboard communication. So right now, and I would have to say that it's not entirely thought
about as everybody still being insecure by default in automotive. There are a lot of people who
all the automotive OEMs are thinking about and making moves to secure the vehicles. And I'm
already starting to see evidence of that. But certainly most, every production vehicle you put
your hands on has this insecure by default essentially. Essentially if you can pretend to be
somebody else, pretend to send a message, then it's just accepted. You don't have to worry
about any kind of authentication or anything like that. So I'm going to talk a little bit about that.
Now the thing is, in the real world for testing validation we also do these kinds of things. When we
want to do simulations, we want to do test validation, we're actually doing these same things.
Pretending to be another ECU doing different things to see what happens. Or making certain
commands. CAN was originally made to be a network that is really about measuring sensors, outputs,
outputs and also actuating. Sensors and actuators. So that's
nice because actuating or controlling something, we'd like
to do that. So if an attacker can somehow send arbitrary CAN
messages then basically you own it. So any one ECU that you
could happen to make transmit any arbitrary CAN message
basically it can pretend to be the test tool, it can pretend to
be OnStar, it can pretend to be whatever you would like it to
be at the moment. So one of the things that you'll see repeated
a couple times in the slides is the concept of implicit
availability. Basically, in essence, this basically means
that many, most everything that's needed by other ECUs
inside the vehicle is going to be transmitted periodically.
Automatically. And everybody just watches for this magic
message. An ID, if you will, in CAN this would be the
arbitrary CAN message. So if you're sending a message to an
ARB ID, basically that ARB ID gives us a clue as to how to
interpret the data bytes. So once we have that ID, we see that ID
coming up every 100 milliseconds, well we know there's a certain
amount of data in there and now we can sniff that data. Now of
course you don't have calibrated data at that point, you just have
data bytes. But with some trials and some work, you can create
your own calibrations, essentially making your own data
bases. And that's usually the spot, when I'm teaching reverse
engineering, I'm teaching people how to reverse CAN messages and
that's like the very first thing we go after. Some of the
things that is actually kind of nice about having this implicit
availability is the fact that because this essentially means
these nodes or these ECUs, they're very much decoupled from
each other, say that we need to put a new feature in a car. Well
we just add in the extra ECU and it gives us say this backup
camera. And then we have a new feature in the car that we can
use. And then it just puts out an extra message or two and
everybody watches that message. If we don't want to, just take it
away, okay, there's no backup camera messages. That's a nice
easy plug and play world for all the automotive OEMs. They love
it and they are not going to get rid of that. Because it makes
it a lot easier for them to upsell the options, et cetera,
without doing very much work. All I've got to do is plug in the
extra module if I really want to. Okay. So in this example you'll
see that it has, you know, it's got a lot of data in there. It's
got this ID number, the arbitration ID for CAN, for
instance. And then there's an RPM or engine speed would be the
more correct term. Temperature, this could be OAT or outside
air temperature, et cetera, et cetera. And this would be
broadcast from an ECU and maybe this particular one is broadcast
every 50 milliseconds. All the other ECUs are hooked up to the
same exact bus. They all see that same exact information all
the time. Whether they act upon that information, whether they
even measure that information, they're going to be able to see
it. That's all up to each of those ECUs and how you program
them. So up until now, this has all been okay. Okay. Because
we've thought about the vehicle being the ultimate air gap
network. That's really funny. Yeah. Well, back in the day when
we didn't have Bluetooth, didn't have Wi-Fi, yeah, of
course. So the thing is, as customers demand more features,
more connectivity, this just gives us more vectors of attack,
right? That's all it means, which is a wonderful world for
us, actually. So obviously if we're in the automotive industry,
we're trying to figure out some system that's going to prohibit
this kind of stuff. People pretending to be who they are
not. Okay. And maybe we care about people watching those canned
messages. And maybe we care about people, you know, even
seeing the transactions that we have going on. We'll talk about
all that in a moment. Okay. So we want to come up with a system
that prohibits, say, people from using the internet. We want to
keep people pretending to be other people, et cetera, but
still maintains this advantage of this, this implicit
availability. Okay. Because that's going to still help us
keep doing the things we've been doing in automotive. Okay. So
before we go on, let's talk about what are we really trying
to prevent here? Okay. Um, so, of course, just like anybody
that's doing some pen testing, we're going to try to come up
with different vectors of attack, et cetera. Um, we have
to also come up with assuming that something gets, you know,
stuck inside. Somebody does some stuff. What are the
consequences? If we have some level of compromise, can we even
mitigate that compromise to whatever level? So let's take a
look at a couple of recent attacks. I'm not going to spend
much time because they're on YouTube. You guys have heard
about them. Miller and Valasek. Lot of, lot of more specific
information in here, but you can hit up their presentation on
DEF CON, um, on, that's out there and, uh, and you can watch
it. Uh, but the bottom line here is that you probably don't
remember that with the, quote, Jeep hack, they could take
control of the vehicle, actually could steer it off the road and
do stuff to the brakes, all that kind of stuff because they could
essentially become a test tool. Okay. Because they took over
what's called the head unit. The head unit being that
infotainment system that we all like to, you know, pair our
phones to, et cetera. They took that over and because it could
transmit arbitrary CAN commands, it could pretend to be anything.
It could pretend to be the test tool. Okay. So, ultimately, there
is, there's really a lot of details in here. This only
touches on just certain facets. But the bottom line is they got,
they basically totally own the vehicle. Total ownage. Okay. So,
um, and that right there is really the scary thing that
really got everybody worried. Somebody can take control of a
vehicle remotely. I can find out that particular VIN number and I
can figure out where it's located and I can do stuff to
it. And then, uh, you've probably, you've heard of the
Progressive, uh, Hackers. We've got, uh, we've got, uh, we've
got a bunch of them as well. Um, so, so the customers helped us
out by putting in dongles into the cars that we can, of course,
then hack. Okay. Because Progressive wasn't, not, not
necessarily thinking about the fact that they're transmitting
data back but they're also providing a new vector of attack.
Um, that concept of the ultimate air gap vehicle, okay, as soon
as I put something into that OBD connector, obviously not much of
an air gap anymore because nine times out of ten, that thing is
transmitting something back to somebody else. In fact, it
actually, if you look at the white Lincoln Navigator that's
out here, before we put in a remote hacking module into it, uh,
we actually had to pull out the rental car company's tracking
device that we found as we were doing it. So there, you know,
who knows what you could hide. Uh, I've also been on military
vehicles where, um, you think, oh, well, I'll never be able to
get to the CAN bus and so I just reach up behind the armor
plating and there's a twisted pair right there. Bam. So, if I
were in some, say, some doing, some doing some, um, special
operations, I could come up with a tool, somebody could come in
the middle of the night, click it on, boom. I could be doing some
remote stuff and they would never even know because I've
attached something from the outside. Okay. Interesting. So,
um, yeah, and again, one thing I did not bring up because
that's really not part of this, but it's, it blows me away how
much, uh, lack of authentication of firmware is out
there in production vehicles. That's always fun for us. So,
thinking about these hacks, the, the Uconnect or the Jeep
hack, okay, this one right here is actually hacking right into
the vehicle. Didn't have to put anything in at all. Okay.
Whereas the progressive hack actually can be mitigated and
you're already starting to see examples of this right now. Uh,
the concept of having, uh, a common gateway module or central
gateway module, basically a gateway that fits between your,
uh, OBD connection.
Okay. And you're starting to see more and more and more gateway
UBD connector, the UBD connector, and the rest of the vehicle. And
it basically plays the middle man and if you hook up any device
to this OBD connector, if it fails, if it does something bad,
if it does something it's not supposed to do, it doesn't even
pass it to the other side. So then we would have the dirty
side, if you will, which is everything outside of the OBD
connector. Within that, within the vehicle, that would be the
clean side and the, that central gateway module protect, would
protect everything. Okay. And you're starting to see more and
more and more gateway modules. Okay. You're gonna, you've already
seen a lot of them if you've been into any vehicles, like any
German vehicles. Those things have had gateways for years. Okay.
But most everybody is going to a gateway module because of the
progressive hack and other things. Not to mention, users
putting their own stuff in there and their aftermarket stuff
fails, causing warranty issues. They don't like to hear about
that. Okay. So, the goal, the goal is that we want to have
something that we of course maintain those advantages that I
talked about, but at the same time that the messages or the
signals or PDUs, a lot of different names for those things,
uh, are only produced and only consumed by the intended nodes.
Okay. So I can't pretend to be anybody else basically. Okay. So
let's, uh, let's take a little segue though into cryptography and
talk about our three main pillars here. Okay. Which one do we really
care about the most? Confidentiality? Do we care about
the content? Do we really care if somebody can actually see the
contents of the communication on the CAN bus, for instance?
Maybe. If it's got a GPS location. I don't want to really
reveal that, right? A lot of times maybe it doesn't matter.
But, you never know. Let's think, we'll think about that a
little bit. Integrity. Can somebody, some third party get in
there and modify information, corrupt the communication? Okay.
And if that happens, can we detect it? That would be nice to
know. Availability. Can we detect it? Can we detect it? Can we
even use our car in the first place? That would be nice to
know. I don't want to get it disabled. Okay. So, can somebody
get in there and actually basically just totally brick our
vehicle, essentially. Remotely brick it. Okay. Pretty
interesting concept. Well, if you think about these things,
well, with availability, the worst case is, if we're talking
about a passenger car, okay, the guy's gotta get Uber. Okay.
Not so bad. Military? Uh, it's a little bit more dangerous. You
don't want somebody to get bricked.
Well, you're in the, you know, theater, you know. You're out
there and you're actually in operation. Um, corrupting the
communication? Hmm. Pretending to be somebody else? That seemed
like it was pretty dramatic with the Jeep hack. A lot of people
got, you know, really worried when they started to see that
stuff. A lot of politicians, et cetera. Right? Viewing the
contents? Hmm. I don't know. Doesn't seem like it worries us
too much. Ultimately, ultimately what you're starting
to see is that the number one thing that you're going to see
improvements in is integrity. We don't necessarily care if
people can read those messages and sniff the bus, but we
certainly want to make sure that only those who are allowed to
send that certain message are sending them. That we can tell.
Okay. More specifically, authenticity. We need to
authenticate. Okay. So we need to be able to say, okay, you
sent this. I need to know that you are, in fact, you. So, now
normally, traditionally, you know, computers, right? We're
doing this like doing public key, right? Okay. There's a couple
of issues that, that happen there. It can, we can be done
with symmetric cryptography, of course, if we somehow pre-share
keys. But key management is always the Achilles heel,
right? It's always a big deal. So, I'm going to do a really
quick overview. You know, what is a hash, et cetera. And then
we'll get to the point where we start to implement what we need
to do in a canned frame to make this all happen.
So, many of you already know what a hash function is. Any
arbitrary link string you put into it out, comes out a fixed
length. Okay. But a cryptographic hash is a little
bit more specialized. Okay. Obviously, we want to have
something that if we have a hash function, it would be nice
if we can just get right down to the bottom line and say, we
really wanted to act like a black box. It's very, very, very
difficult, very, very difficult to find out what the input was,
you know, to match a given output. Okay. So, that's really
the key thing. We're trying, of course, I never said it's
impossible because we really don't know. That's one of the
hard things. When you start to get to this level of
cryptography, you start to find out that it's really the layer of
the mathematicians who, they basically will work on a
certain algorithm that they think works, work on it for
several years, and once they believe that they've got
something pretty secure, then they'll say, okay, we're going
to make that a standard. Okay. So, that's really the key thing.
Okay. So, a couple of popular ones, or were popular ones. So,
MD5, obviously, that one's gone. SHA-1, theoretically, we could
attack it, brute force attack it. Really, no practical attacks
yet, though. But because there's theoretical attacks, basically,
it's essentially getting deprecated. If you're smart,
you're going to deprecate it. SHA-2, at this point, it's
considered SHA-2 safe, because there are only some partial
theoretical attacks. And because it takes so long to develop
these algorithms, SHA-3 has already been developed, just
essentially as a safeguard. Because as soon as somebody owns
one of these things, you've got to have something to go to
immediately. And it literally takes several years to come up
with enough proof to get people to believe that this will
actually work. Okay. Obviously, a problem is,
if an adversary can change your message, they can certainly
change a hash. Okay. So, that's obviously a big problem. Okay. So,
now, message authentication code. This is where we start to get to
a little bit more of the meat and potatoes of this. Um, so, we
could make some kind of a code that, if you will, a piece of
information that is going to be the authentication. It will
authenticate that message, or that frame of data, or PDU. Okay.
All of those are essentially kind of the same thing. Uh, Jeff
uses message in his, I would say, more, more correct to say
frame or PDU. Um, or protocol data unit. So, um, so we could
just do a hash of the message, of the signals or the data, if
you will. Use it as a MAC. Okay. But, of course, if we can see
the actual signals, the signal, the data, of course, we can
recalculate that hash. A big deal. That doesn't mean
anything. So, we need to put some kind of secret information
into this as well.
So, that we can somehow, some way, um, if we have the secret
key, if you will, we can combine that with the signals and then we
can create our message authentication code. So, that
means the adversary now has to know that secret piece of
information. Okay. So, that's getting a little harder now. So,
at least we could do a private key encryption, if you will. And
so, um, we can do a hash, a hash methods MAC, if you will,
HMAC. Excuse me.
So, basically, I've got the formula here for you, but the
idea is that the HMAC formula is going to turn any hash function
into a keyed hash function, because we are adding the key in
here. So, that's where we got the K prime there. Uh, so, we're
able to put in our secret key and do a hash and boom, we have a
message, message authentication code. Okay. So, things are
looking up. It may be possible to make this all work. So, um,
another couple things I'll talk about. Um, I'm going to talk a
little bit about is it is possible, uh, to not use hashes,
but we can use stream cipher, so ADS. Okay. So, that's, uh,
that's another option. Uh, they're in the specification for
Auto Czar, they don't tie you to using secret key or public key
encryption. They don't tie you to that. And in fact, they don't
even talk about key management. It's not even covered in that
standard. Okay. So, one thing that you find out really quick,
if you're trying to do something like AES, eventually we're going
to have to get some hardware to do that. Because, you know, when it
comes to public key encryption, you're looking at something
that's many, many, many, many, many times slower. And therefore,
I'd have to have hardware to even speed it up. Okay. So, it
sounds like at the, at the beginning there, I was talking
about things are looking up. Okay. But the problem here is
that if I have a secret key, and if I have the data, and if I have
this cryptographic hash function, and I create my message
authentication, it sounds like I should be able to know, oh,
you've got the right thing. I can decrypt, figure it out. You
know, the, the MAC matches on my side when I decrypt it with my
private key. Everything should be okay. However, this is still a
problem. So, think of this. If you see a proper message come
across that only tells you that the message creator wasn't in
possession of the secret key, then you're going to be able to
decrypt the secret key. It does not mean that the sender didn't
just copy that. So, I could still replay attack this. I can
literally just take, oh, well, it worked this particular time. I
can just replay that and see if I can get away with it. And so, we
could do something crazy. Like, if I was able to deploy airbags
through a message on the bus in one, in some way, shape, or form,
then I could record that, and then I could just simply resend that
again at some point. So, I could just, you know, I could just, you
know, I could just resend that again at some later time. Not cool. Not
cool at all. Okay. So, let's move on to the secure onboard
communications for AUTOSAR. Okay. So, in AUTOSAR, if you, in
fact, I'll jump ahead here because this makes a little bit
more sense. AUTOSAR is essentially like an operating
system that runs on the ECU itself. So, there's lots of
stuff that you'll see here, all these different components. And
way up here are the actual different software components.
And the way that the OEMs are thinking is, I can buy even
certain functions from different manufacturers. And if they're
all AUTOSAR basic software, I can jam it right in there, have
many different makers, many different tier one suppliers,
actually making the code on an OEA, or on an ECU that's
actually made by some other manufacturer. Because in
AUTOSAR, not only do I pick and choose who makes which ECU, I
pick and choose who makes which ECU. So, I can actually make a
code and choose the software for each component and I can put
them all in there. Okay. So, it's a kind of interesting idea.
So, of course, in order to be open system, make everything
standardized, we have this concept of AUTOSAR. And that's
where we're all really, really moving to. So, estimates are by
2020 all those new cards coming off the line will essentially be
AUTOSAR based. So that means, this will be some interesting
information. Because if you're pen testing, that means you're
auto czar is probably involved which pretty much means that what we're about to talk about is
going to be there. Okay. So SECOC or secure on board communications is essentially another auto
czar module that provides PDU this would be the message or the signals and integrity and
authentication. Basically what we've been doing. Okay. The key thing is it ensures this
freshness. We're going to talk about a freshness value coming into play and it makes it a
little bit harder for us to crack it. Okay. It is a generically defined system so if you
want to use symmetric or asymmetric cryptography you can of course. Okay. One of the key
things here is that key distribution is not even specified. So that leaves everybody to
basically roll their own. Whatever they're going to do to distribute their keys. Which is
awesome. Because they'll probably mess up. So basically the idea is that we're going to
have a unique ID. The SECOC data ID. Okay. That's right from the spec. Or every PDU protocol
data unit is basically a signal or collection of signals. Okay. And so basically each one of
these senders or receivers has to maintain a freshness state for this particular PDU. So that
means I have, I'm sending out a group of signals and along with that I'm sending out a group of
signals. Along with those I have to maintain a freshness value. Okay. So, we're going to use
that freshness value and put it into the mix, in, inside of our encrypted hash or our our
cryptographic hash and we're going to be able to make it even harder so you can't just do a
replay attack anymore. Because I'm going to have this extra freshness value. Okay. So, to a
couple of different freshness strategies. Uhh what I usually see is freshness counters at this point. Uh or you could use just a few of these. So if I'm
simply a timestamp, okay? So the idea is the PDU or the group of signals, we're going to take
that input, the data itself, and we're going to put it into, excuse me, into the Mac generation.
So it's going to be part of the game. We already know that. We also have a secret key. That's
something we're going to share separately. That probably was done by the OEM during servicing or
manufacturing. And then there will be a counter, for instance. This will be like using a
freshness counter. So this counter is going to generate our freshness counter and then it's
going to feed that into the Mac generation. And what comes out is going to be our Mac value,
okay? Now it says truncation down here. I'll explain that in a second. But essentially think
of this now. We now have this PDU and a freshness value and we have the authentication
value, if you will, the Mac value. And then that gets transmitted on the bus. And over here, what
do we do? We take our secret key, run it through our verification, and we're able to find out what
was the count. Did it actually match up with our last received count? Okay. Did the Mac value
actually match up as well? And if it is, great, okay. If not, we just reject the message. Pretend
it's not. Okay. So in the spec, it talks about secured IPDU and that's basically what contains
that original message or the data within the frame, okay? As well as the freshness value in
the Mac. So that's basically all three of those components I just talked about. That is the
secured IPDU. So basically, we're able to use that freshness value because that's something that
is yet another thing in the mix so that I can't just rebroadcast it because I'm not going to be
able to see what's on the other side. What am I looking for? I'm looking for the right freshness
value. So if I just rebroadcast it, then how would I even know? I have to figure out something
there, right? So that's going to give me another little roadblock. Didn't stop us, by the way,
over in the car hacking village. I'll show you that in a little bit. Okay. So one thing is that
you'll see in here, and actually I believe you've seen the demo as well, is that in the symmetric
mode, we can actually chop off some of the Mac if it's too long. And we're going to need to do that
in standard CAN, if we do it in standard CAN. Okay. One of the things that's not talked about in
this presentation at all that Jeff kind of doesn't even implies it but doesn't talk about it,
and that's this thing called CAN FD. CAN flexible data is basically a way that we can get more data
in, so up to 64 bytes, and we can clock it as up to eight times the speed. So I can fit in a lot
more data in the same amount of time. That gives us so much more room to be able to do this kind of
thing. We don't even have to do a full implementation, we don't even have to truncate anything,
okay, if we really didn't want to. Okay. So maybe we do chop off some of the Mac. And in fact, we
can chop off some of the freshness value too. Because if you think about it, this authentic
IPDU, this is the actual signal, or the signal data. Okay. And maybe we calculate a freshness
value. That's not our misspelling, sorry. That's from the graphic. Uh, and then we calculate the
truncated freshness value. Uh, but we maybe take a fraction of that, and we put that, the lowest
significant bits in here for the truncated freshness value. Why can we do this? Because we can
figure out this upper part on the other side. Okay. If we started out at zero, we already know
this is going to be zero. If we see a rollover over here, we're just going to increment over
here. And so we can keep track of it on the other side just by seeing the truncation, if you
really want to. And then the authenticator, our Mac, we can trans, we can actually truncate that as
well. Because on the other side, when we pull it out, we're going to see the truncated freshness value.
We can see how far it matches up. It should still match up on the other side. Okay. So this
way, we can actually fit in everything into even, into standard CAN. We don't have very many
bits. I think we end up with 27 bits, roughly. Okay. Again, this is all in the AUTOSAR spec, too,
if you want to dig it up. But, um, so I've already kind of explained this as well, about the
LSBs and the freshness value that we can actually, uh, uh, we are, depending on the
component, to always be increasing by one. Um, and also about the authenticator that we can
truncate that as well. Okay. So let's take a look at this whole method. If I have the freshness
value, I can avoid the replay attack and I have authentic, authenticity. Okay. So in secure
onboard communication, let's take a look at what's really going on and where we might have some
possible, uh, some possible exploits. Uh, so, of course, we already know we're using cryptographic
primitives. Uh, we, looks like we're going to keep our implicit availability as long as the, uh,
receiver and the transmitter can keep track of these freshness values and authentications key.
Yeah, its private key. Um, the freshness value is actually independently maintained by both the
sender and receiver. So that means I send it out to the receiver, the receiver has to send it out to the
I increment it on the other side, the other guy is going to expect it to be incremented and
I'm maintaining it. Which actually, by the way, becomes a problem. Because what happens when the
freshness counters get out of sync? Well, in a real world, they would never do that, right? But
the reality is, even in normal operation of the network, for instance, you're cranking the
vehicle, some other thing happens. You know, you have something that jumps on the bus and
takes priority. You may end up with somehow getting out of sync. And that means we have to
take care of that and that's actually going to be one of our exploits. Okay. So, for regular CAN,
only 27 bits can be used for the MAC. Can this be brute force? Don't stay tuned. It's true. We
have it over there. Eventually you'll see the siren going off and the strobe lights. But it
takes about seven hours for us to brute force it.
So, this is where this freshness value can also become desynced if we have to replace a
node. In other words, I take it in for service. I got to somehow maintain the key, number one. But
number two, the freshness value. What happens? Because I'm going to try to make this
persistent so that I do a key cycle and it's going to keep track of what it was last time,
et cetera. I don't want to make it easy where everything starts at zero at the beginning
because that would just make it easier for us, right? So, having some way that we can do this,
synchronizing the freshness values has to be done. And that is actually not covered in that
secure onboard communication spec. It's actually up to what you would like to do as an OEM,
which is very interesting because if they're doing it, they must be communicating that full
freshness value periodically. And if they're communicating the full freshness periodically,
that means you can see it. And if you can see it, that means you know it. And then guess what? I
can replay it because I know the freshness value.
I still have to take some guesses, though. That's what the demo is over there in the car hacking
village. Okay. So that can be, that actually turns out to be a pretty fair way for us to
actually try to get in there. So the secret sauce, when you're doing your pen testing, trying
to find the secret sauce, how are the ECUs resynchronizing their freshness counters? That's a
good place to look, okay? And I already talked about how desyncing can possibly happen even when
you're cranking a vehicle. Certain things happen on the bus and things get out of sync. It just
happens. So, this right here about periodically transmitting that full freshness value, if you're
pen testing, I suggest you start looking at that. That's a good place to look. You just think,
hmm, if I were them, the easiest thing for me to be would be periodically transmit it, okay? So,
oop, let me back up here. So, um, what happens when they get to the OEM? Well, they get to the
OEM and they get desynced. Well, the receiver is supposed to ignore, okay? It ignores that
message. But that eventually causes some level of failure, okay? Whether that's a U code,
possibly, because we say, we technically would say that we've lost communication with the
transmitting ECU. So, U code or DTC. But the thing is, we have to deal with that in our
software. So, once we get, once we get desynced, it's not like we can just jump in and say, oh,
I'm back in. We're going to have to figure out, you know, uh, basically how we're going to get
that full freshness value in this case. So, basically, that's where the, this demo, we, we can
show you that over on the other side. Um, but, uh, another thing is instead of, say, being, uh,
susceptible to brute forcing like this because we just have the one freshness, another solution
would be to require multiple correct MACs before resyncing, okay? That would help us out a little
bit. Instead of just one MAC works, boom, I'm done. No, make sure it's multiple MACs. So, key
management, okay? So, uh, apart from all of this, uh, most everybody in this room already knows
that key management is really the key. Um, if they are not done right, that's going to be a
problem. So, how do they generate and store those keys? Well, that's up to the OEM, okay? Uh,
so, could we just do one global key? Well, that would be really, really, really, really hard.
That would be real simple but real stupid because, of course, the key gets out once and it's
over, okay? Uh, so, not cool. So, maybe we have one key per vehicle, which, in a way, I've
actually seen this kind of thing used out in the field where, uh, I'm unlocking an ECU for one
particular ECU and that one particular vehicle, it unlocks with one, you know, basically you ask
it for a seed and you get that same seed number every single time. And so, that way you'd have to
know the solution versus, say, every time you ask, you get a new key. So, that would be really, really,
really hard. I have to get a different seed number and so then I can just sit there and ask and
ask and ask and ask and pretty soon I can watch a service tool, ask and ask and get answers and
answers back and pretty soon I can create a table or I can unlock that ECU. So, um, so
ultimately, if we have one global key or one key for the vehicle, as soon as we get on that
vehicle with that key, obviously, ultimately, if we gain code execution on one ECU, essentially at
that point, in most every case, that means that whoever owns that ECU now can send any message
they want. Okay. Because in CAN, every ECU has to be able to transmit. And that means if I can
make it transmit, then I can make it transmit whatever I want and I own the whole system. Okay.
So another solution would be one key per message. Well, man, that's a lot of keys. If you've
looked at any of the latest vehicles and counted the number of unique IDs that you see coming out
on one bus, that's a lot of keys. Sounds bad. Sounds real complicated for anybody, even if they
want to try. Okay. So having so many keys doesn't make too much sense, but maybe a possible
compromise would be partial networking. In other words, I have a key for one group of
messages. Okay. That kind of fits into the concept of a key for one group of messages. Okay.
So let's look at the sub-systems that you see nowadays inside of more complex vehicles, more
contemporary vehicles. I have an autonomy sub-system. I have a powertrain sub-system. I have a
body control sub-system, et cetera, et cetera. And each one of those is, um, it could have its own
key, if you will, so that we can compromise between having a key for every message and having
one key. Okay. So, how do you get to the key for every message? Well, you can get to the key for
every message. How about this? Even if we had keys for each message, would the security onboard
communication protect against a Uconnect hack? Hmm. Interesting. Well, the thing is, you have to
remember, they own that head unit. 100%. They own it. So if they own it, well, the thing is, it's
already got everything already there. So that means you can still send stuff out. Uh, it will make
it a little more difficult for you, but you have to remember, if you already have the code in
there to deal with everything, and you just need to take a little extra advantage of it, I mean,
you basically have it owned, you know, in the end. Okay. In other words, if you get remote code
execution, you're going to, it's going to be a full compromise, no matter what you do, pretty
much. Okay. So, what do we do design-wise, hopefully in OEMs, we'll do this. Uh, don't do crazy
things like, you have code for playing MP3s, and it also somehow has the ability to send
CAN frames. Shouldn't do that. Probably a bad idea. Um, make sure you, I mean, if you're
using a G-Pack, you isolate processes and give them the right permissions, control that stuff,
uh, using maybe a secondary processor for sending messages that has its own defined interface. By
the way, Uconnect, the G-Pack, they did do that, but because they had authenticated,
unauthenticated firmware, they were able to download it and reverse it. So, didn't matter
anyway. So, protect your firmware. All right. So, if you have any questions, I probably can
answer some of them. I'm not jacking off. So, if you have any questions, I'm not jacking off. So,
Jeff. But I'd like everybody to get Jeff's information. Um, feel free to ask him questions. I
actually know some of this stuff, too, and you can ask me questions as well. Um, unfortunately,
Jeff couldn't be here, so hopefully everything's okay back home. Um, he really wanted to be
here. He was here just long enough to turn around and come back. So, any questions about secure
onboard communication that I might be able to answer? I did that a lot quicker than usual. Go
ahead.
Oh, I'm sorry. I'm having a hard time hearing you. That's okay.
Oh, like, like, lighter weight ciphers. Now, that would be something for Jeff. Because that's
getting out of my pay grade. But, in the end, what you're seeing, let me, because I'm
a partial answer for you. So, uh, so the question was, um, if you think about, like, AES, maybe
there should be some thought put to some of the lighter weight ciphers, that kind of thing. So, so
you have to remember that in automotive, we've come from basically no encryption, no
authentication. And then, um, they basically have heard rumors. I'll just say they've heard
rumors that maybe it's probably time for us to pay some attention to, you know, maybe what's going to
be going on with people hacking cars. And they've ignored it, okay, to the Jeep hack. It's like
really the momentous occasion that people are like, oh, crap, we actually have to do something
now. And so that means they're in the middle of a design cycle where they have no hardware that
they're going to be able to put in because they have to pump it out. And usually in automotive,
we're, we're reacting rather slowly, rather slowly. So that means they're going to try to do
the stuff they can just do entirely in software first. And then they're going to get the hardware
encryption in there where they can actually do something that's, even though it may not be AES,
but I'm sure they would want to do lighter weight stuff just because of the, you know, fact that
anything that takes too long, it's obviously going to be a problem. They're going to immediately
go away from it. But it'll be a lot, it'll be a lot more secure, obviously, to, uh, to go to some
of the heavier duty stuff than just this kind of authentication. But this is kind of like their
stop gap if you think about it. It's like, okay, at least nobody can take control of the vehicle.
We hope. Right? So.
I know a very long non-answer to your question, but Jeff would love to talk about that
because his master's is in mathematics. Then for fun, he's doing automotive, automotive, uh,
cryptology. So, um, any other questions?
I don't, but Jeff does. See, I'm, I, this is so easy for me to answer questions. I just say, oh,
well, talk to Jeff.
Um, the thing is, what I'm talking about here is actually what's in the standard. And the
standard is, and this is part of, it's almost a frustration with open standard. Open standard
says, okay, use a freshness value. And you're like, well, which one? Like, well, whichever one
you want because it's open standard. Do what you want. So, uh, the thing is, if you're an OEM,
you certainly should put some thought into those types of things. Okay? Certainly don't do
something stupid like, uh, I'm going to use, uh, I'm going to use, uh, I'm going to use, uh,
the network time, but modulo 100, so I end up with an integer between 0 and 99. Okay? Well, I'm
not going to say who did that. Uh, okay, so anyway, um, but yeah, obviously you want to use,
uh, you know, a proper freshness counter. So, but yes, open, open system architecture means
OEMs get to decide. So they get to do some of their role of your own, if you will, almost, uh,
by at least picking and choosing the things they want to use. Just like in key management. Uh,
I think the next question was over here. Was there a question?
Yes. Can you prevent, uh, DOS attack by, uh, using, uh, SEC?
Oh. Oh, so that's a good question. Can you prevent a DOS attack on the vehicle with SEC
OCH. Answer is no. You can take, uh, say, a value can. We've got some value cans over
there. I can get into vehicle spy, use a free version, transmit R by D zero and then for the
transmit rate put in minus one. And then that is a hint to the hardware to go and use that, uh,
basically go as fast as possible and nothing will come across that bus, period. So that's your
DOS attack. That's what we taught in Black Hat just this last week. So that's a good question
though. Unfortunately when it comes to DOS attack, your options are pretty limited, okay,
because of the way that CAN works. That's the way it works at the physical level. Works like a
wired AND gate. So if you've got a zero on there, it's going to override everything. Any
other questions? You had a question? Oh, you're good? Okay. If you're good, I'm good. Any
other questions? Well, thank you very much for this bad approximation to Jeff Connell. So feel
free to send him e-mails or get on his website. And the presentation once again is at
jeffq.com slash defcon underscore secoc dot pdf. Thank you very much.
Thank you.