 Alright, uh, we're getting ready to start now. It's an introduction to Autosar. Uh, Jeff cannot be here today, Don speaking on his behalf. Hello and welcome. Uh, can you get the door please? Thanks. Um, so, um, just a quick intro of what we're gonna do here. So, basically, this is to, 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 and electronics, but also, 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. Uh, and doing a brute force hack on it, which will be done before the end of the day. Uh, so, uh, I'm not Jeff, and I did not spend 13 years. Uh, uh, actually, uh, I spent nine years at that same company, which I won't talk about, but then I spent a lot more time after, uh, before that, working in automotive, uh, but in also non-automotive, like defense aerospace stuff. But basically, everything we're talking about today is an open standard. Okay, and 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. Uh, if you'd like to see these slides, or follow along, right, there's your URL. Um, so, uh, hopefully you know what CAN is, or controller area network, hopefully you know what an ECU is, or a module, or, you know, embedded computing, uh, you're gonna need to know about that. Um, so, uh, so basically we're gonna start out with where we're at now and where we're moving towards, uh, trying to secure our onboard communication. Uh, so, so right now, and I would, I would have to say that it's not entirely thought about as everybody still being insecure by default in automotive. All the automotive OEMs are thinking about and making moves to secure the vehicles. Okay. Um, and I'm already starting to see evidence of that. Uh, but, uh, but certainly most, every production vehicle you put your hands on is, has this, you know, insecure by default essentially. Um, 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, anything like that. Um, now the thing is, in the real world for testing validation, we also do these kinds of things for when we want to do simulations, when 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, uh, uh, a network that is really about measuring sensor, you know, outputs and also actuating, sensors and actuators. Okay. So, that's nice because actuating or controlling something, we'd like to do that. Um, so if an attacker can somehow send arbitrary CAN messages, then basically you own it. Okay. So anyone 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 on-star. It can pretend to be whatever you would like it to be at the moment. So, um, one of the things that you'll see, uh, repeated a couple of times in the slides is, is the concept of implicit availability. You know, basically, uh, in essence, this basically means that, uh, many, uh, most everything that's needed by other ECUs inside the vehicle is going to be transmitted periodically, automatically. And everybody, everybody just watches for this, this magic message, an ID, if you will, uh, in CAN, this will be the RBID. Okay. Basically, that RBID gives us a clue as to how to interpret the data bytes. Okay. So once we have that ID, we see that ID coming up every 100 milliseconds. Well, we know there's certain amount of data in there, and now we can, we can sniff that data. Okay. Um, now of course, you don't have calibrated data at that point, you just have data bytes. But, with some, you know, with some, uh, trials and, uh, and, uh, some work, you can create your own calibrations, essentially making your own databases. Okay. 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. Um, some of the things that is actually kind of nice about having this implicit availability is the fact that, uh, because this essentially means these nodes or these ECUs are, 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 it just puts out an extra message or two, and everybody watches that message. Um, 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 got to do is plug in the extra module if I really want to. Okay. So, uh, in this, in this example you'll see that it has, you know, this ID number, the arbitration ID for CAN, for instance, and then there's an RPM or engine speed would be a more correct term. Temperature, this could be, uh, this could be, uh, OAT or outside air temperature, uh, 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, that's all up to each of those ECUs and how you program them. So, uh, 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. Uh-huh. Uh-huh. Yeah. Well, back in the day when we didn't have Bluetooth, didn't have Wi-Fi. Yeah, of course. Um, so the thing is, as customers demand more features, more connectivity, this just gives us more vectors of attack, right? That's a, that's all it means, which is a wonderful world for us, actually. Uh, so, obviously if we're in, 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. Uh, and maybe we care about people watching those can messages. And maybe we care about people, you know, even seeing the transactions that we have going on. Well, we'll talk about all that in a moment, okay? So, we want to come up with a system that prohibits, say, people pretending to be other people, et cetera, but still maintains this advantage of this, this implicit availability, okay? Because that's gonna 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 gonna try to come up with different vectors of attack, et cetera. Um, we have to also come up with assuming that something gets 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 gonna spend much time because they're on YouTube, you guys have heard about them, Miller and Valasek. A lot of, a lot of more specific information in here, but you can hit up their presentation on Defcon, that's out there and you can watch it. But the bottom line here is that you probably 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 of 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, they're able to do, and there's, 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 onage. Okay. So, 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 heard of the progressive, uh, hack as well. Um, so, so the customers helped us out by putting in dongles into the cars that we could of course then hack. Okay. Because progressive wasn't, 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 ear gap vehicle. Okay. As soon as I put something into that OBD connector, obviously not much of an ear gap anymore because nine times out of ten, that thing is transmitting something back to somebody else. In fact, if you look at the white Lincoln Navigator, it's out here. Before we put in a remote hacking module into it, uh, we actually had to pull out the rental car companies tracking device that we found as we're doing it. So they're, 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 firmware is out there in production vehicles. That's always fun for us. So. 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 in 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 OBD connector and the rest of the vehicle and it basically plays a middleman and if you hook up any device to this OBD connector, if it fails, if it does something bad, if it does something that'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, 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, 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 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 it happens, can we detect it? That would be nice to know. Availability. 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 got to get Uber. Okay. Not so bad. Military? That's a little bit more dangerous. You don't want somebody to get bricked while you're in the, you know, at theater. You know, you're out there and you're actually in operation. Corrupted communication? Hmm. Pretending to be somebody else? That seemed like it was pretty dramatic with the G-PAC. A lot of people got, you know, really worried when they started to see that stuff. A lot of politicians, etc. Right. Viewing the contents? Hmm. I don't know. It doesn't seem like it worries us too much. Ultimately, ultimately what you're starting to see is that the number one thing that we're seeing 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 in computers, right, we're doing this like doing public key, right? Okay. There's a couple of issues that happen there. It 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, etc., and then we'll get to the point where we start to implement what we need to do in a can 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 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 or give an 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, a couple of popular ones or we're popular ones. So, MD5, obviously that one's gone. SHA1, 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. SHA2, at this point we consider SHA2 safe because there are only some partial theoretical attacks and because it takes so long to develop these algorithms, SHA3 has already been developed, just essentially is 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. 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. Jeff uses message in his, I would say, more correct to say frame or PDU or protocol data unit. 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. I'm 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, 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 let's get in a little harder now. So at least we could do a private key encryption, if you will. And so, we can do a hash, a hash methods MAC, if you will, or HMAC. Excuse me. So basically I've got the formula here for you, but the idea is that 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. So we're able to put in our secret key and do a hash and boom we have a message authentication code. Okay. So things are looking up. It's maybe possible to make this all work. So another couple of things I'll talk about is it is possible to not use hashes, but we can use stream cipher, so ADS, okay. So that's, that's another option. 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 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 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 was in possession of 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 later time. Not cool. Not cool at all. Okay, so let's move on to the secure onboard communications for AutoZar. Okay. So um, in AutoZar, if you, in fact, I'll jump ahead here because this makes a little bit more sense. AutoZar 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 AutoZar basic software, I can jam it right in there, have many different uh, makers, many different uh, tier one suppliers, actually making the code on an OEM or on a uh, on an ECU that's actually made by some other manufacturer. Because in AutoZar, not only do I pick and choose who makes which ECU, I pick 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 standardize, we have this concept of AutoZar. And that's where we're all really, really moving to. So uh, estimates are by 2020, all those new cars coming off the line will essentially be AutoZar based. So that means this will be some interesting information. Cause if you're pen testing, that means AutoZar 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 onboard communications is essentially another AutoZar module that provides PDU, this would be the message or the signals, integrity and authentication. Basically what we've been doing. Okay. Um, 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. Um, 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 that's 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. Uh, so, um, so basically the idea is that we are going to have, um, 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, uh, 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 those I have to maintain a freshness value. Okay. So we're going to use that freshness value and put it into the mix inside of our encrypted hash or our, uh, 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 different freshness strategies, uh, what I usually see is freshness counters at this point. Or you could use just simply as time stamp. 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, 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, uh, that 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 uh, 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 even there. Okay. So in the spec it talks about secured IPDU and that's basically, uh, 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, um, 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 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, uh, that's gonna give me a little, 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 see in 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 gonna need to do that in standard can, if we do it in standard can. Okay. Uh, one of the things that's not talked about in this presentation at all, that Jeff kind of, he doesn't, he 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 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, 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 roll over 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 or Mac, we can truncate that as well. Because on the other side, when we pull it out, 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 auto czar spec too, if you want to dig it up. Um, so I've already kind of explained this as well about the LSBs, the freshness value that we can actually, uh, uh, we are depending upon it 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 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, cryptographic primitives. Uh, we, it looks like we're going to keep our implicit availability as long as the, uh, the receiver and the transmitter can keep track of these freshness values and, uh, an authentication key. Or it's a, uh, yeah, it's private key. Um, the freshness value is actually independently maintained by both the sender and receiver. So that means I send it out, I increment it on the other side, the other guy is going to expect it to be incremented and I'm main, 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, of the network, for instance, you're cranking the vehicle. Some other thing happens. Um, you know, you have some, uh, 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, it's true. We have it over there. Eventually you'll see the, uh, siren going off and the strobe lights. But, uh, it takes about seven hours, uh, for us to brute force it. So, this is where this fresh, freshness value can also become desynced if we have to replace a node. In other words, I take it in for service. I gotta somehow maintain the key, number one. But number two, the freshness value. What happens? Um, 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, etc. Uh, 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? Um, so, having some way of 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 period, 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. If I, I still have to take some guesses though, that's what the demo is over there in the, uh, car hacking village. Okay. So that could be a, that, 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, how are the ECUs re-synchronizing their freshness counters? That's a good place to look. Okay. And I already talked about how de-syncing 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, 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, nope, let me back up here. So, um, what happens when they get de-synced? 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, uh, we say, we technically would say that we've lost communication with the transmitting ECU. So, uh, U-code or DTC. Um, but the thing is we have to deal with that in our software. Um, so once we get, uh, once we get de-synced, it's not like we can, uh, just jump back in. We're gonna 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 susceptible to brute forcing like this, because we just have the one freshness, another solution would be to require multiple correct Macs before re-syncing. Okay. That would help us out a little bit. Okay. Instead of just one Mac works, boom, I'm done. Now 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're not done right, that's gonna 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 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 different seed number, and so then I can just sit there 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 the 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, uh, ultimately if we gain code as execution on one ECU, essentially at that point, uh, in most every case, that means that whoever, whoever owns that ECU now can send any message they want. Okay. Because it 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. Uh, 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 um, so having so many keys doesn't make too much sense, but maybe a possible compromise to be partial networking. In other words, I have a key for one group of messages. Okay. That kind of fits into the concept of subsystems that you see nowadays inside more complex vehicles, more contemporary vehicles. I have an autonomy subsystem. I have a powertrain subsystem. I have a body control subsystem, 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 about this? Even if we had keys for each message, would the security onboard communication protect against a U-connect 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 gonna just gonna be full compromise, no matter what you do pretty much. Okay. So what do we do design-wise, hopefully in OEMs, we'll do this. 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 bad idea. Um, make sure 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, you connect the G-PAC, 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. Alright. So, if you have any questions, I probably can answer some of them. I'm not 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. I'm sorry, I'm having a hard time hearing you. That's okay. Oh, like, like lightweight ciphers. That's a, now that would be something for Jeff. Cause that's getting out of my pay grade. But, in, in the end, what you're seeing, cause I have 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 on with people hacking cars. And they've ignored it, okay, to the G-PAC. 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 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, the 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 would be a lot, it would be a lot more secure obviously 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 cryptology. So any other questions? I don't, but Jeff does. See, this is so easy for you to answer questions. I used to say, oh, talk to Jeff. 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, what you want? Like, well, whichever one you want because it's open standard. Do what you want. So 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, I'm going to use the network time, but modular 100. So I end up with the integer between 0.99. Okay. Well, I'm not going to say who did that. Okay, so anyway. But yeah, obviously you want to use a, 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. By at least picking and choosing the things they want to use. Just like in key management. I think the next question was over here. Was there a question? Yes. Oh. Oh, so that's a good question. Can you prevent a DOS attack on the vehicle with Sec Ock? Answer is no. You can take, say, a value can. We've got some value cans over there. I can get in the 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 basically go as fast as possible. And nothing will come across that bus. Period. So that's your DOS attack. That's, that's what we taught in, in Black Hat just 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 work. That's the way it works at the physical level. It works like a wired AND gate. So if there's, 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, uh, approximation to Jeff Cannell. So, uh, feel free to send, uh, send him emails or get on his website. Uh, and the presentation once again is at jeffq.com slash def con underscore s e c o c dot p d f. Thank you very much.