1 00:00:00,620 --> 00:00:05,960 We're getting ready to start now. This is an introduction to AUTOSAR. Jeff cannot be here 2 00:00:05,960 --> 00:00:14,080 today. Don is speaking on his behalf. Hello and welcome. Can you get the door, 3 00:00:14,140 --> 00:00:21,660 please? Thanks. So just a quick intro of what we're going to do here. So basically this is 4 00:00:21,660 --> 00:00:27,840 talking about not just AUTOSAR which is automotive open systems architecture which is where 5 00:00:27,840 --> 00:00:33,080 the whole automotive industry is going to for their development in electronics but specifically 6 00:00:33,540 --> 00:00:38,900 towards secure onboard communication, talk about what that is, how it's done and also discuss 7 00:00:38,900 --> 00:00:43,880 some of the weaknesses, one of which we are exploiting in the room right across the way right 8 00:00:43,880 --> 00:00:50,000 now and doing a brute force hack on it which will be done before the end of the day. So I'm not 9 00:00:50,000 --> 00:00:57,820 Jeff and I did not spend 13 years. Actually, I spent nine years at that same company and 10 00:00:57,840 --> 00:01:04,960 I spent a lot more time before that working in automotive and also non-automotive like 11 00:01:04,960 --> 00:01:09,400 defense aerospace stuff. But basically everything we're talking about today is an open standard. 12 00:01:09,900 --> 00:01:14,520 That's part of what the automotive industry is trying to go to because open standards, we hope 13 00:01:14,520 --> 00:01:21,260 we save money, we hope we don't have to have our suppliers remake that wheel again. If you'd 14 00:01:21,260 --> 00:01:27,820 like to see these slides or follow along, right there is your URL. So we're going to talk about 15 00:01:27,840 --> 00:01:32,160 that. Hopefully you know what CAN is or controller area network. Hopefully you know what an ECU is 16 00:01:32,160 --> 00:01:39,300 or module or embedded computing. You're going to need to know about that. So basically we're 17 00:01:39,300 --> 00:01:45,380 going to start out with where we're at now and where we're moving towards trying to secure our 18 00:01:45,380 --> 00:01:52,740 onboard communication. So right now, and I would have to say that it's not entirely thought 19 00:01:52,740 --> 00:01:57,820 about as everybody still being insecure by default in automotive. There are a lot of people who 20 00:01:57,840 --> 00:02:06,520 all the automotive OEMs are thinking about and making moves to secure the vehicles. And I'm 21 00:02:06,520 --> 00:02:12,400 already starting to see evidence of that. But certainly most, every production vehicle you put 22 00:02:12,400 --> 00:02:20,380 your hands on has this insecure by default essentially. Essentially if you can pretend to be 23 00:02:20,380 --> 00:02:25,260 somebody else, pretend to send a message, then it's just accepted. You don't have to worry 24 00:02:25,260 --> 00:02:27,820 about any kind of authentication or anything like that. So I'm going to talk a little bit about that. 25 00:02:27,840 --> 00:02:35,040 Now the thing is, in the real world for testing validation we also do these kinds of things. When we 26 00:02:35,040 --> 00:02:39,700 want to do simulations, we want to do test validation, we're actually doing these same things. 27 00:02:39,740 --> 00:02:45,440 Pretending to be another ECU doing different things to see what happens. Or making certain 28 00:02:45,440 --> 00:02:54,200 commands. CAN was originally made to be a network that is really about measuring sensors, outputs, 29 00:02:54,200 --> 00:03:00,140 outputs and also actuating. Sensors and actuators. So that's 30 00:03:00,140 --> 00:03:03,040 nice because actuating or controlling something, we'd like 31 00:03:03,040 --> 00:03:07,820 to do that. So if an attacker can somehow send arbitrary CAN 32 00:03:07,820 --> 00:03:13,320 messages then basically you own it. So any one ECU that you 33 00:03:13,320 --> 00:03:17,100 could happen to make transmit any arbitrary CAN message 34 00:03:17,100 --> 00:03:20,080 basically it can pretend to be the test tool, it can pretend to 35 00:03:20,080 --> 00:03:23,200 be OnStar, it can pretend to be whatever you would like it to 36 00:03:23,200 --> 00:03:29,440 be at the moment. So one of the things that you'll see repeated 37 00:03:29,440 --> 00:03:32,140 a couple times in the slides is the concept of implicit 38 00:03:32,140 --> 00:03:36,600 availability. Basically, in essence, this basically means 39 00:03:36,600 --> 00:03:41,020 that many, most everything that's needed by other ECUs 40 00:03:41,020 --> 00:03:44,040 inside the vehicle is going to be transmitted periodically. 41 00:03:44,980 --> 00:03:48,480 Automatically. And everybody just watches for this magic 42 00:03:48,480 --> 00:03:53,020 message. An ID, if you will, in CAN this would be the 43 00:03:53,020 --> 00:03:53,180 arbitrary CAN message. So if you're sending a message to an 44 00:03:53,200 --> 00:03:57,780 ARB ID, basically that ARB ID gives us a clue as to how to 45 00:03:57,780 --> 00:04:02,220 interpret the data bytes. So once we have that ID, we see that ID 46 00:04:02,220 --> 00:04:05,240 coming up every 100 milliseconds, well we know there's a certain 47 00:04:05,240 --> 00:04:10,860 amount of data in there and now we can sniff that data. Now of 48 00:04:10,860 --> 00:04:13,340 course you don't have calibrated data at that point, you just have 49 00:04:13,340 --> 00:04:20,460 data bytes. But with some trials and some work, you can create 50 00:04:20,460 --> 00:04:22,940 your own calibrations, essentially making your own data 51 00:04:22,940 --> 00:04:26,200 bases. And that's usually the spot, when I'm teaching reverse 52 00:04:26,200 --> 00:04:29,360 engineering, I'm teaching people how to reverse CAN messages and 53 00:04:29,360 --> 00:04:33,640 that's like the very first thing we go after. Some of the 54 00:04:33,640 --> 00:04:36,180 things that is actually kind of nice about having this implicit 55 00:04:36,180 --> 00:04:40,320 availability is the fact that because this essentially means 56 00:04:40,320 --> 00:04:43,720 these nodes or these ECUs, they're very much decoupled from 57 00:04:43,720 --> 00:04:47,320 each other, say that we need to put a new feature in a car. Well 58 00:04:47,320 --> 00:04:51,640 we just add in the extra ECU and it gives us say this backup 59 00:04:51,640 --> 00:04:52,920 camera. And then we have a new feature in the car that we can 60 00:04:52,920 --> 00:04:55,600 use. And then it just puts out an extra message or two and 61 00:04:55,600 --> 00:04:59,240 everybody watches that message. If we don't want to, just take it 62 00:04:59,240 --> 00:05:02,740 away, okay, there's no backup camera messages. That's a nice 63 00:05:02,740 --> 00:05:06,860 easy plug and play world for all the automotive OEMs. They love 64 00:05:06,860 --> 00:05:09,580 it and they are not going to get rid of that. Because it makes 65 00:05:09,580 --> 00:05:13,420 it a lot easier for them to upsell the options, et cetera, 66 00:05:13,500 --> 00:05:16,060 without doing very much work. All I've got to do is plug in the 67 00:05:16,060 --> 00:05:21,280 extra module if I really want to. Okay. So in this example you'll 68 00:05:21,280 --> 00:05:22,900 see that it has, you know, it's got a lot of data in there. It's 69 00:05:22,920 --> 00:05:25,740 got this ID number, the arbitration ID for CAN, for 70 00:05:25,740 --> 00:05:28,380 instance. And then there's an RPM or engine speed would be the 71 00:05:28,380 --> 00:05:33,640 more correct term. Temperature, this could be OAT or outside 72 00:05:33,640 --> 00:05:37,960 air temperature, et cetera, et cetera. And this would be 73 00:05:37,960 --> 00:05:41,700 broadcast from an ECU and maybe this particular one is broadcast 74 00:05:41,700 --> 00:05:44,760 every 50 milliseconds. All the other ECUs are hooked up to the 75 00:05:44,760 --> 00:05:47,840 same exact bus. They all see that same exact information all 76 00:05:47,840 --> 00:05:51,060 the time. Whether they act upon that information, whether they 77 00:05:51,060 --> 00:05:52,900 even measure that information, they're going to be able to see 78 00:05:52,920 --> 00:05:55,260 it. That's all up to each of those ECUs and how you program 79 00:05:55,260 --> 00:06:00,540 them. So up until now, this has all been okay. Okay. Because 80 00:06:00,540 --> 00:06:03,420 we've thought about the vehicle being the ultimate air gap 81 00:06:03,420 --> 00:06:10,260 network. That's really funny. Yeah. Well, back in the day when 82 00:06:10,260 --> 00:06:13,640 we didn't have Bluetooth, didn't have Wi-Fi, yeah, of 83 00:06:13,640 --> 00:06:19,400 course. So the thing is, as customers demand more features, 84 00:06:19,480 --> 00:06:22,540 more connectivity, this just gives us more vectors of attack, 85 00:06:22,920 --> 00:06:26,200 right? That's all it means, which is a wonderful world for 86 00:06:26,200 --> 00:06:31,160 us, actually. So obviously if we're in the automotive industry, 87 00:06:31,340 --> 00:06:33,520 we're trying to figure out some system that's going to prohibit 88 00:06:33,520 --> 00:06:36,160 this kind of stuff. People pretending to be who they are 89 00:06:36,160 --> 00:06:41,200 not. Okay. And maybe we care about people watching those canned 90 00:06:41,200 --> 00:06:44,640 messages. And maybe we care about people, you know, even 91 00:06:44,640 --> 00:06:47,500 seeing the transactions that we have going on. We'll talk about 92 00:06:47,500 --> 00:06:51,300 all that in a moment. Okay. So we want to come up with a system 93 00:06:51,300 --> 00:06:52,900 that prohibits, say, people from using the internet. We want to 94 00:06:52,920 --> 00:06:55,120 keep people pretending to be other people, et cetera, but 95 00:06:55,120 --> 00:06:59,060 still maintains this advantage of this, this implicit 96 00:06:59,060 --> 00:07:02,580 availability. Okay. Because that's going to still help us 97 00:07:02,580 --> 00:07:06,300 keep doing the things we've been doing in automotive. Okay. So 98 00:07:06,300 --> 00:07:09,420 before we go on, let's talk about what are we really trying 99 00:07:09,420 --> 00:07:14,660 to prevent here? Okay. Um, so, of course, just like anybody 100 00:07:14,660 --> 00:07:16,820 that's doing some pen testing, we're going to try to come up 101 00:07:16,820 --> 00:07:20,240 with different vectors of attack, et cetera. Um, we have 102 00:07:20,240 --> 00:07:22,900 to also come up with assuming that something gets, you know, 103 00:07:22,920 --> 00:07:25,580 stuck inside. Somebody does some stuff. What are the 104 00:07:25,580 --> 00:07:29,820 consequences? If we have some level of compromise, can we even 105 00:07:29,820 --> 00:07:33,120 mitigate that compromise to whatever level? So let's take a 106 00:07:33,120 --> 00:07:35,400 look at a couple of recent attacks. I'm not going to spend 107 00:07:35,400 --> 00:07:38,880 much time because they're on YouTube. You guys have heard 108 00:07:38,880 --> 00:07:42,660 about them. Miller and Valasek. Lot of, lot of more specific 109 00:07:42,660 --> 00:07:45,880 information in here, but you can hit up their presentation on 110 00:07:45,880 --> 00:07:49,320 DEF CON, um, on, that's out there and, uh, and you can watch 111 00:07:49,320 --> 00:07:52,900 it. Uh, but the bottom line here is that you probably don't 112 00:07:52,920 --> 00:07:56,100 remember that with the, quote, Jeep hack, they could take 113 00:07:56,100 --> 00:07:59,100 control of the vehicle, actually could steer it off the road and 114 00:07:59,100 --> 00:08:01,700 do stuff to the brakes, all that kind of stuff because they could 115 00:08:01,700 --> 00:08:05,920 essentially become a test tool. Okay. Because they took over 116 00:08:06,360 --> 00:08:08,560 what's called the head unit. The head unit being that 117 00:08:08,560 --> 00:08:11,200 infotainment system that we all like to, you know, pair our 118 00:08:11,200 --> 00:08:14,220 phones to, et cetera. They took that over and because it could 119 00:08:14,220 --> 00:08:17,540 transmit arbitrary CAN commands, it could pretend to be anything. 120 00:08:17,800 --> 00:08:22,740 It could pretend to be the test tool. Okay. So, ultimately, there 121 00:08:22,920 --> 00:08:25,880 is, there's really a lot of details in here. This only 122 00:08:25,880 --> 00:08:29,700 touches on just certain facets. But the bottom line is they got, 123 00:08:29,980 --> 00:08:34,380 they basically totally own the vehicle. Total ownage. Okay. So, 124 00:08:34,460 --> 00:08:37,480 um, and that right there is really the scary thing that 125 00:08:37,480 --> 00:08:40,920 really got everybody worried. Somebody can take control of a 126 00:08:40,920 --> 00:08:44,300 vehicle remotely. I can find out that particular VIN number and I 127 00:08:44,300 --> 00:08:48,120 can figure out where it's located and I can do stuff to 128 00:08:48,120 --> 00:08:51,680 it. And then, uh, you've probably, you've heard of the 129 00:08:51,680 --> 00:08:52,900 Progressive, uh, Hackers. We've got, uh, we've got, uh, we've 130 00:08:52,920 --> 00:08:56,560 got a bunch of them as well. Um, so, so the customers helped us 131 00:08:56,560 --> 00:08:59,320 out by putting in dongles into the cars that we can, of course, 132 00:08:59,360 --> 00:09:02,240 then hack. Okay. Because Progressive wasn't, not, not 133 00:09:02,240 --> 00:09:04,840 necessarily thinking about the fact that they're transmitting 134 00:09:04,840 --> 00:09:07,920 data back but they're also providing a new vector of attack. 135 00:09:08,360 --> 00:09:13,000 Um, that concept of the ultimate air gap vehicle, okay, as soon 136 00:09:13,000 --> 00:09:16,320 as I put something into that OBD connector, obviously not much of 137 00:09:16,320 --> 00:09:19,880 an air gap anymore because nine times out of ten, that thing is 138 00:09:19,880 --> 00:09:22,860 transmitting something back to somebody else. In fact, it 139 00:09:22,920 --> 00:09:24,640 actually, if you look at the white Lincoln Navigator that's 140 00:09:24,640 --> 00:09:28,100 out here, before we put in a remote hacking module into it, uh, 141 00:09:28,280 --> 00:09:31,100 we actually had to pull out the rental car company's tracking 142 00:09:31,100 --> 00:09:34,240 device that we found as we were doing it. So there, you know, 143 00:09:34,240 --> 00:09:37,400 who knows what you could hide. Uh, I've also been on military 144 00:09:37,400 --> 00:09:41,420 vehicles where, um, you think, oh, well, I'll never be able to 145 00:09:41,420 --> 00:09:44,420 get to the CAN bus and so I just reach up behind the armor 146 00:09:44,420 --> 00:09:48,840 plating and there's a twisted pair right there. Bam. So, if I 147 00:09:48,840 --> 00:09:52,520 were in some, say, some doing, some doing some, um, special 148 00:09:52,520 --> 00:09:56,200 operations, I could come up with a tool, somebody could come in 149 00:09:56,200 --> 00:09:58,900 the middle of the night, click it on, boom. I could be doing some 150 00:09:58,900 --> 00:10:01,120 remote stuff and they would never even know because I've 151 00:10:01,120 --> 00:10:05,320 attached something from the outside. Okay. Interesting. So, 152 00:10:05,480 --> 00:10:09,840 um, yeah, and again, one thing I did not bring up because 153 00:10:09,840 --> 00:10:13,100 that's really not part of this, but it's, it blows me away how 154 00:10:13,100 --> 00:10:16,160 much, uh, lack of authentication of firmware is out 155 00:10:16,160 --> 00:10:20,540 there in production vehicles. That's always fun for us. So, 156 00:10:22,580 --> 00:10:28,200 thinking about these hacks, the, the Uconnect or the Jeep 157 00:10:28,200 --> 00:10:32,360 hack, okay, this one right here is actually hacking right into 158 00:10:32,360 --> 00:10:35,380 the vehicle. Didn't have to put anything in at all. Okay. 159 00:10:35,940 --> 00:10:40,640 Whereas the progressive hack actually can be mitigated and 160 00:10:40,640 --> 00:10:44,120 you're already starting to see examples of this right now. Uh, 161 00:10:44,200 --> 00:10:47,520 the concept of having, uh, a common gateway module or central 162 00:10:47,520 --> 00:10:51,440 gateway module, basically a gateway that fits between your, 163 00:10:51,500 --> 00:10:52,460 uh, OBD connection. 164 00:10:52,520 --> 00:10:52,920 Okay. And you're starting to see more and more and more gateway 165 00:10:52,920 --> 00:10:54,460 UBD connector, the UBD connector, and the rest of the vehicle. And 166 00:10:54,460 --> 00:10:57,660 it basically plays the middle man and if you hook up any device 167 00:10:57,660 --> 00:11:00,680 to this OBD connector, if it fails, if it does something bad, 168 00:11:00,900 --> 00:11:03,540 if it does something it's not supposed to do, it doesn't even 169 00:11:03,540 --> 00:11:06,140 pass it to the other side. So then we would have the dirty 170 00:11:06,140 --> 00:11:08,720 side, if you will, which is everything outside of the OBD 171 00:11:08,720 --> 00:11:11,720 connector. Within that, within the vehicle, that would be the 172 00:11:11,720 --> 00:11:14,720 clean side and the, that central gateway module protect, would 173 00:11:14,720 --> 00:11:18,440 protect everything. Okay. And you're starting to see more and 174 00:11:18,440 --> 00:11:22,380 more and more gateway modules. Okay. You're gonna, you've already 175 00:11:22,520 --> 00:11:25,120 seen a lot of them if you've been into any vehicles, like any 176 00:11:25,120 --> 00:11:28,860 German vehicles. Those things have had gateways for years. Okay. 177 00:11:28,960 --> 00:11:32,940 But most everybody is going to a gateway module because of the 178 00:11:32,940 --> 00:11:36,400 progressive hack and other things. Not to mention, users 179 00:11:36,400 --> 00:11:39,440 putting their own stuff in there and their aftermarket stuff 180 00:11:39,440 --> 00:11:42,380 fails, causing warranty issues. They don't like to hear about 181 00:11:42,380 --> 00:11:49,680 that. Okay. So, the goal, the goal is that we want to have 182 00:11:49,680 --> 00:11:52,360 something that we of course maintain those advantages that I 183 00:11:52,520 --> 00:11:55,940 talked about, but at the same time that the messages or the 184 00:11:55,940 --> 00:11:59,000 signals or PDUs, a lot of different names for those things, 185 00:11:59,240 --> 00:12:05,100 uh, are only produced and only consumed by the intended nodes. 186 00:12:05,660 --> 00:12:10,260 Okay. So I can't pretend to be anybody else basically. Okay. So 187 00:12:10,260 --> 00:12:14,420 let's, uh, let's take a little segue though into cryptography and 188 00:12:14,420 --> 00:12:19,300 talk about our three main pillars here. Okay. Which one do we really 189 00:12:19,300 --> 00:12:22,500 care about the most? Confidentiality? Do we care about 190 00:12:22,520 --> 00:12:24,580 the content? Do we really care if somebody can actually see the 191 00:12:24,580 --> 00:12:27,480 contents of the communication on the CAN bus, for instance? 192 00:12:28,260 --> 00:12:32,340 Maybe. If it's got a GPS location. I don't want to really 193 00:12:32,340 --> 00:12:35,740 reveal that, right? A lot of times maybe it doesn't matter. 194 00:12:36,600 --> 00:12:39,300 But, you never know. Let's think, we'll think about that a 195 00:12:39,300 --> 00:12:43,320 little bit. Integrity. Can somebody, some third party get in 196 00:12:43,320 --> 00:12:46,840 there and modify information, corrupt the communication? Okay. 197 00:12:47,380 --> 00:12:49,900 And if that happens, can we detect it? That would be nice to 198 00:12:49,900 --> 00:12:52,500 know. Availability. Can we detect it? Can we detect it? Can we 199 00:12:52,520 --> 00:12:55,400 even use our car in the first place? That would be nice to 200 00:12:55,400 --> 00:12:59,700 know. I don't want to get it disabled. Okay. So, can somebody 201 00:12:59,700 --> 00:13:03,300 get in there and actually basically just totally brick our 202 00:13:03,300 --> 00:13:07,140 vehicle, essentially. Remotely brick it. Okay. Pretty 203 00:13:07,140 --> 00:13:10,440 interesting concept. Well, if you think about these things, 204 00:13:10,880 --> 00:13:13,900 well, with availability, the worst case is, if we're talking 205 00:13:13,900 --> 00:13:17,560 about a passenger car, okay, the guy's gotta get Uber. Okay. 206 00:13:17,600 --> 00:13:21,060 Not so bad. Military? Uh, it's a little bit more dangerous. You 207 00:13:21,060 --> 00:13:22,100 don't want somebody to get bricked. 208 00:13:22,520 --> 00:13:25,440 Well, you're in the, you know, theater, you know. You're out 209 00:13:25,440 --> 00:13:29,460 there and you're actually in operation. Um, corrupting the 210 00:13:29,460 --> 00:13:32,280 communication? Hmm. Pretending to be somebody else? That seemed 211 00:13:32,280 --> 00:13:35,120 like it was pretty dramatic with the Jeep hack. A lot of people 212 00:13:35,120 --> 00:13:37,660 got, you know, really worried when they started to see that 213 00:13:37,660 --> 00:13:41,640 stuff. A lot of politicians, et cetera. Right? Viewing the 214 00:13:41,640 --> 00:13:45,940 contents? Hmm. I don't know. Doesn't seem like it worries us 215 00:13:45,940 --> 00:13:49,940 too much. Ultimately, ultimately what you're starting 216 00:13:49,940 --> 00:13:52,500 to see is that the number one thing that you're going to see 217 00:13:52,520 --> 00:13:56,960 improvements in is integrity. We don't necessarily care if 218 00:13:56,960 --> 00:13:59,820 people can read those messages and sniff the bus, but we 219 00:13:59,820 --> 00:14:04,760 certainly want to make sure that only those who are allowed to 220 00:14:04,760 --> 00:14:08,360 send that certain message are sending them. That we can tell. 221 00:14:08,600 --> 00:14:11,880 Okay. More specifically, authenticity. We need to 222 00:14:11,880 --> 00:14:16,220 authenticate. Okay. So we need to be able to say, okay, you 223 00:14:16,220 --> 00:14:22,420 sent this. I need to know that you are, in fact, you. So, now 224 00:14:22,520 --> 00:14:26,140 normally, traditionally, you know, computers, right? We're 225 00:14:26,140 --> 00:14:29,000 doing this like doing public key, right? Okay. There's a couple 226 00:14:29,000 --> 00:14:32,680 of issues that, that happen there. It can, we can be done 227 00:14:32,680 --> 00:14:35,920 with symmetric cryptography, of course, if we somehow pre-share 228 00:14:35,920 --> 00:14:38,520 keys. But key management is always the Achilles heel, 229 00:14:38,620 --> 00:14:42,780 right? It's always a big deal. So, I'm going to do a really 230 00:14:42,780 --> 00:14:46,080 quick overview. You know, what is a hash, et cetera. And then 231 00:14:46,080 --> 00:14:49,520 we'll get to the point where we start to implement what we need 232 00:14:49,520 --> 00:14:51,760 to do in a canned frame to make this all happen. 233 00:14:52,520 --> 00:14:55,700 So, many of you already know what a hash function is. Any 234 00:14:55,700 --> 00:14:58,900 arbitrary link string you put into it out, comes out a fixed 235 00:14:58,900 --> 00:15:03,900 length. Okay. But a cryptographic hash is a little 236 00:15:03,900 --> 00:15:07,900 bit more specialized. Okay. Obviously, we want to have 237 00:15:07,900 --> 00:15:10,520 something that if we have a hash function, it would be nice 238 00:15:10,520 --> 00:15:14,180 if we can just get right down to the bottom line and say, we 239 00:15:14,180 --> 00:15:17,680 really wanted to act like a black box. It's very, very, very 240 00:15:17,680 --> 00:15:22,420 difficult, very, very difficult to find out what the input was, 241 00:15:22,520 --> 00:15:27,500 you know, to match a given output. Okay. So, that's really 242 00:15:27,500 --> 00:15:30,480 the key thing. We're trying, of course, I never said it's 243 00:15:30,480 --> 00:15:33,600 impossible because we really don't know. That's one of the 244 00:15:33,600 --> 00:15:35,520 hard things. When you start to get to this level of 245 00:15:35,520 --> 00:15:39,700 cryptography, you start to find out that it's really the layer of 246 00:15:39,700 --> 00:15:43,000 the mathematicians who, they basically will work on a 247 00:15:43,000 --> 00:15:45,260 certain algorithm that they think works, work on it for 248 00:15:45,260 --> 00:15:47,920 several years, and once they believe that they've got 249 00:15:47,920 --> 00:15:51,640 something pretty secure, then they'll say, okay, we're going 250 00:15:51,640 --> 00:15:52,500 to make that a standard. Okay. So, that's really the key thing. 251 00:15:52,520 --> 00:15:59,180 Okay. So, a couple of popular ones, or were popular ones. So, 252 00:15:59,300 --> 00:16:07,920 MD5, obviously, that one's gone. SHA-1, theoretically, we could 253 00:16:07,920 --> 00:16:12,020 attack it, brute force attack it. Really, no practical attacks 254 00:16:12,020 --> 00:16:16,220 yet, though. But because there's theoretical attacks, basically, 255 00:16:16,800 --> 00:16:18,840 it's essentially getting deprecated. If you're smart, 256 00:16:18,940 --> 00:16:22,500 you're going to deprecate it. SHA-2, at this point, it's 257 00:16:22,500 --> 00:16:26,680 considered SHA-2 safe, because there are only some partial 258 00:16:26,680 --> 00:16:29,980 theoretical attacks. And because it takes so long to develop 259 00:16:30,660 --> 00:16:35,740 these algorithms, SHA-3 has already been developed, just 260 00:16:36,440 --> 00:16:39,240 essentially as a safeguard. Because as soon as somebody owns 261 00:16:39,240 --> 00:16:41,080 one of these things, you've got to have something to go to 262 00:16:41,080 --> 00:16:44,300 immediately. And it literally takes several years to come up 263 00:16:44,300 --> 00:16:48,420 with enough proof to get people to believe that this will 264 00:16:48,420 --> 00:16:52,440 actually work. Okay. Obviously, a problem is, 265 00:16:52,500 --> 00:16:55,860 if an adversary can change your message, they can certainly 266 00:16:55,860 --> 00:17:02,740 change a hash. Okay. So, that's obviously a big problem. Okay. So, 267 00:17:02,780 --> 00:17:06,320 now, message authentication code. This is where we start to get to 268 00:17:06,320 --> 00:17:10,920 a little bit more of the meat and potatoes of this. Um, so, we 269 00:17:10,920 --> 00:17:14,980 could make some kind of a code that, if you will, a piece of 270 00:17:14,980 --> 00:17:17,760 information that is going to be the authentication. It will 271 00:17:17,760 --> 00:17:22,340 authenticate that message, or that frame of data, or PDU. Okay. 272 00:17:22,500 --> 00:17:25,300 All of those are essentially kind of the same thing. Uh, Jeff 273 00:17:25,300 --> 00:17:28,220 uses message in his, I would say, more, more correct to say 274 00:17:28,220 --> 00:17:33,940 frame or PDU. Um, or protocol data unit. So, um, so we could 275 00:17:33,940 --> 00:17:37,940 just do a hash of the message, of the signals or the data, if 276 00:17:37,940 --> 00:17:42,340 you will. Use it as a MAC. Okay. But, of course, if we can see 277 00:17:42,840 --> 00:17:45,920 the actual signals, the signal, the data, of course, we can 278 00:17:45,920 --> 00:17:48,100 recalculate that hash. A big deal. That doesn't mean 279 00:17:48,100 --> 00:17:50,540 anything. So, we need to put some kind of secret information 280 00:17:50,540 --> 00:17:51,800 into this as well. 281 00:17:52,500 --> 00:17:57,080 So, that we can somehow, some way, um, if we have the secret 282 00:17:57,080 --> 00:18:02,400 key, if you will, we can combine that with the signals and then we 283 00:18:02,400 --> 00:18:05,040 can create our message authentication code. So, that 284 00:18:05,040 --> 00:18:07,220 means the adversary now has to know that secret piece of 285 00:18:07,220 --> 00:18:10,740 information. Okay. So, that's getting a little harder now. So, 286 00:18:10,780 --> 00:18:14,940 at least we could do a private key encryption, if you will. And 287 00:18:14,940 --> 00:18:20,320 so, um, we can do a hash, a hash methods MAC, if you will, 288 00:18:20,380 --> 00:18:22,400 HMAC. Excuse me. 289 00:18:23,300 --> 00:18:25,640 So, basically, I've got the formula here for you, but the 290 00:18:25,640 --> 00:18:28,860 idea is that the HMAC formula is going to turn any hash function 291 00:18:29,440 --> 00:18:32,500 into a keyed hash function, because we are adding the key in 292 00:18:32,500 --> 00:18:36,680 here. So, that's where we got the K prime there. Uh, so, we're 293 00:18:36,680 --> 00:18:41,960 able to put in our secret key and do a hash and boom, we have a 294 00:18:41,960 --> 00:18:45,920 message, message authentication code. Okay. So, things are 295 00:18:45,920 --> 00:18:50,120 looking up. It may be possible to make this all work. So, um, 296 00:18:50,760 --> 00:18:52,480 another couple things I'll talk about. Um, I'm going to talk a 297 00:18:52,500 --> 00:18:55,980 little bit about is it is possible, uh, to not use hashes, 298 00:18:56,020 --> 00:18:59,240 but we can use stream cipher, so ADS. Okay. So, that's, uh, 299 00:18:59,320 --> 00:19:02,480 that's another option. Uh, they're in the specification for 300 00:19:02,480 --> 00:19:06,320 Auto Czar, they don't tie you to using secret key or public key 301 00:19:06,320 --> 00:19:09,180 encryption. They don't tie you to that. And in fact, they don't 302 00:19:09,180 --> 00:19:11,560 even talk about key management. It's not even covered in that 303 00:19:11,560 --> 00:19:16,520 standard. Okay. So, one thing that you find out really quick, 304 00:19:16,580 --> 00:19:19,460 if you're trying to do something like AES, eventually we're going 305 00:19:19,460 --> 00:19:22,360 to have to get some hardware to do that. Because, you know, when it 306 00:19:22,500 --> 00:19:24,980 comes to public key encryption, you're looking at something 307 00:19:24,980 --> 00:19:28,820 that's many, many, many, many, many times slower. And therefore, 308 00:19:29,060 --> 00:19:36,940 I'd have to have hardware to even speed it up. Okay. So, it 309 00:19:36,940 --> 00:19:39,860 sounds like at the, at the beginning there, I was talking 310 00:19:39,860 --> 00:19:43,000 about things are looking up. Okay. But the problem here is 311 00:19:43,000 --> 00:19:49,000 that if I have a secret key, and if I have the data, and if I have 312 00:19:49,000 --> 00:19:51,580 this cryptographic hash function, and I create my message 313 00:19:51,580 --> 00:19:55,220 authentication, it sounds like I should be able to know, oh, 314 00:19:55,320 --> 00:19:59,320 you've got the right thing. I can decrypt, figure it out. You 315 00:19:59,320 --> 00:20:02,700 know, the, the MAC matches on my side when I decrypt it with my 316 00:20:02,700 --> 00:20:07,740 private key. Everything should be okay. However, this is still a 317 00:20:07,740 --> 00:20:15,200 problem. So, think of this. If you see a proper message come 318 00:20:15,200 --> 00:20:20,780 across that only tells you that the message creator wasn't in 319 00:20:20,780 --> 00:20:21,560 possession of the secret key, then you're going to be able to 320 00:20:21,580 --> 00:20:26,060 decrypt the secret key. It does not mean that the sender didn't 321 00:20:26,060 --> 00:20:30,240 just copy that. So, I could still replay attack this. I can 322 00:20:30,240 --> 00:20:33,960 literally just take, oh, well, it worked this particular time. I 323 00:20:33,960 --> 00:20:38,360 can just replay that and see if I can get away with it. And so, we 324 00:20:38,360 --> 00:20:42,560 could do something crazy. Like, if I was able to deploy airbags 325 00:20:43,160 --> 00:20:46,520 through a message on the bus in one, in some way, shape, or form, 326 00:20:46,600 --> 00:20:50,940 then I could record that, and then I could just simply resend that 327 00:20:50,940 --> 00:20:51,560 again at some point. So, I could just, you know, I could just, you 328 00:20:51,580 --> 00:20:54,080 know, I could just resend that again at some later time. Not cool. Not 329 00:20:54,080 --> 00:20:59,100 cool at all. Okay. So, let's move on to the secure onboard 330 00:20:59,100 --> 00:21:06,400 communications for AUTOSAR. Okay. So, in AUTOSAR, if you, in 331 00:21:06,400 --> 00:21:08,500 fact, I'll jump ahead here because this makes a little bit 332 00:21:08,500 --> 00:21:11,580 more sense. AUTOSAR is essentially like an operating 333 00:21:11,580 --> 00:21:15,380 system that runs on the ECU itself. So, there's lots of 334 00:21:15,380 --> 00:21:18,040 stuff that you'll see here, all these different components. And 335 00:21:18,040 --> 00:21:21,520 way up here are the actual different software components. 336 00:21:21,580 --> 00:21:27,060 And the way that the OEMs are thinking is, I can buy even 337 00:21:27,060 --> 00:21:30,400 certain functions from different manufacturers. And if they're 338 00:21:30,400 --> 00:21:33,900 all AUTOSAR basic software, I can jam it right in there, have 339 00:21:33,900 --> 00:21:38,580 many different makers, many different tier one suppliers, 340 00:21:38,780 --> 00:21:43,880 actually making the code on an OEA, or on an ECU that's 341 00:21:43,880 --> 00:21:46,100 actually made by some other manufacturer. Because in 342 00:21:46,100 --> 00:21:50,700 AUTOSAR, not only do I pick and choose who makes which ECU, I 343 00:21:50,700 --> 00:21:51,560 pick and choose who makes which ECU. So, I can actually make a 344 00:21:51,560 --> 00:21:54,020 code and choose the software for each component and I can put 345 00:21:54,020 --> 00:21:58,080 them all in there. Okay. So, it's a kind of interesting idea. 346 00:21:58,300 --> 00:22:01,440 So, of course, in order to be open system, make everything 347 00:22:01,440 --> 00:22:05,180 standardized, we have this concept of AUTOSAR. And that's 348 00:22:05,180 --> 00:22:09,400 where we're all really, really moving to. So, estimates are by 349 00:22:09,400 --> 00:22:13,520 2020 all those new cards coming off the line will essentially be 350 00:22:13,520 --> 00:22:18,760 AUTOSAR based. So that means, this will be some interesting 351 00:22:18,760 --> 00:22:21,540 information. Because if you're pen testing, that means you're 352 00:22:21,540 --> 00:22:25,340 auto czar is probably involved which pretty much means that what we're about to talk about is 353 00:22:25,340 --> 00:22:34,320 going to be there. Okay. So SECOC or secure on board communications is essentially another auto 354 00:22:34,320 --> 00:22:40,220 czar module that provides PDU this would be the message or the signals and integrity and 355 00:22:40,220 --> 00:22:45,840 authentication. Basically what we've been doing. Okay. The key thing is it ensures this 356 00:22:45,840 --> 00:22:49,600 freshness. We're going to talk about a freshness value coming into play and it makes it a 357 00:22:49,600 --> 00:22:56,320 little bit harder for us to crack it. Okay. It is a generically defined system so if you 358 00:22:56,320 --> 00:23:02,220 want to use symmetric or asymmetric cryptography you can of course. Okay. One of the key 359 00:23:02,220 --> 00:23:08,240 things here is that key distribution is not even specified. So that leaves everybody to 360 00:23:08,240 --> 00:23:13,620 basically roll their own. Whatever they're going to do to distribute their keys. Which is 361 00:23:13,620 --> 00:23:19,580 awesome. Because they'll probably mess up. So basically the idea is that we're going to 362 00:23:19,600 --> 00:23:29,760 have a unique ID. The SECOC data ID. Okay. That's right from the spec. Or every PDU protocol 363 00:23:29,760 --> 00:23:38,240 data unit is basically a signal or collection of signals. Okay. And so basically each one of 364 00:23:38,240 --> 00:23:46,440 these senders or receivers has to maintain a freshness state for this particular PDU. So that 365 00:23:46,440 --> 00:23:49,580 means I have, I'm sending out a group of signals and along with that I'm sending out a group of 366 00:23:49,580 --> 00:23:56,920 signals. Along with those I have to maintain a freshness value. Okay. So, we're going to use 367 00:23:56,920 --> 00:24:02,020 that freshness value and put it into the mix, in, inside of our encrypted hash or our our 368 00:24:02,720 --> 00:24:07,400 cryptographic hash and we're going to be able to make it even harder so you can't just do a 369 00:24:07,400 --> 00:24:13,200 replay attack anymore. Because I'm going to have this extra freshness value. Okay. So, to a 370 00:24:13,200 --> 00:24:19,560 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 371 00:24:19,580 --> 00:24:29,000 simply a timestamp, okay? So the idea is the PDU or the group of signals, we're going to take 372 00:24:29,000 --> 00:24:36,820 that input, the data itself, and we're going to put it into, excuse me, into the Mac generation. 373 00:24:37,180 --> 00:24:42,780 So it's going to be part of the game. We already know that. We also have a secret key. That's 374 00:24:42,780 --> 00:24:46,640 something we're going to share separately. That probably was done by the OEM during servicing or 375 00:24:46,640 --> 00:24:51,560 manufacturing. And then there will be a counter, for instance. This will be like using a 376 00:24:51,560 --> 00:24:56,880 freshness counter. So this counter is going to generate our freshness counter and then it's 377 00:24:56,880 --> 00:25:02,860 going to feed that into the Mac generation. And what comes out is going to be our Mac value, 378 00:25:03,100 --> 00:25:08,460 okay? Now it says truncation down here. I'll explain that in a second. But essentially think 379 00:25:08,460 --> 00:25:15,460 of this now. We now have this PDU and a freshness value and we have the authentication 380 00:25:17,540 --> 00:25:23,460 value, if you will, the Mac value. And then that gets transmitted on the bus. And over here, what 381 00:25:23,460 --> 00:25:29,540 do we do? We take our secret key, run it through our verification, and we're able to find out what 382 00:25:29,540 --> 00:25:37,100 was the count. Did it actually match up with our last received count? Okay. Did the Mac value 383 00:25:37,660 --> 00:25:45,180 actually match up as well? And if it is, great, okay. If not, we just reject the message. Pretend 384 00:25:46,640 --> 00:25:54,200 it's not. Okay. So in the spec, it talks about secured IPDU and that's basically what contains 385 00:25:54,640 --> 00:26:00,200 that original message or the data within the frame, okay? As well as the freshness value in 386 00:26:00,200 --> 00:26:04,280 the Mac. So that's basically all three of those components I just talked about. That is the 387 00:26:04,280 --> 00:26:12,280 secured IPDU. So basically, we're able to use that freshness value because that's something that 388 00:26:12,280 --> 00:26:16,620 is yet another thing in the mix so that I can't just rebroadcast it because I'm not going to be 389 00:26:16,640 --> 00:26:19,860 able to see what's on the other side. What am I looking for? I'm looking for the right freshness 390 00:26:19,860 --> 00:26:25,220 value. So if I just rebroadcast it, then how would I even know? I have to figure out something 391 00:26:25,220 --> 00:26:30,400 there, right? So that's going to give me another little roadblock. Didn't stop us, by the way, 392 00:26:30,420 --> 00:26:38,900 over in the car hacking village. I'll show you that in a little bit. Okay. So one thing is that 393 00:26:38,900 --> 00:26:44,600 you'll see in here, and actually I believe you've seen the demo as well, is that in the symmetric 394 00:26:44,600 --> 00:26:49,340 mode, we can actually chop off some of the Mac if it's too long. And we're going to need to do that 395 00:26:49,340 --> 00:26:54,440 in standard CAN, if we do it in standard CAN. Okay. One of the things that's not talked about in 396 00:26:54,440 --> 00:26:58,800 this presentation at all that Jeff kind of doesn't even implies it but doesn't talk about it, 397 00:26:58,860 --> 00:27:04,960 and that's this thing called CAN FD. CAN flexible data is basically a way that we can get more data 398 00:27:04,960 --> 00:27:10,920 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 399 00:27:10,920 --> 00:27:14,580 more data in the same amount of time. That gives us so much more room to be able to do this kind of 400 00:27:14,580 --> 00:27:18,060 thing. We don't even have to do a full implementation, we don't even have to truncate anything, 401 00:27:18,240 --> 00:27:27,480 okay, if we really didn't want to. Okay. So maybe we do chop off some of the Mac. And in fact, we 402 00:27:27,480 --> 00:27:31,960 can chop off some of the freshness value too. Because if you think about it, this authentic 403 00:27:31,960 --> 00:27:40,280 IPDU, this is the actual signal, or the signal data. Okay. And maybe we calculate a freshness 404 00:27:40,280 --> 00:27:44,560 value. That's not our misspelling, sorry. That's from the graphic. Uh, and then we calculate the 405 00:27:44,580 --> 00:27:48,520 truncated freshness value. Uh, but we maybe take a fraction of that, and we put that, the lowest 406 00:27:48,520 --> 00:27:53,560 significant bits in here for the truncated freshness value. Why can we do this? Because we can 407 00:27:53,560 --> 00:27:58,300 figure out this upper part on the other side. Okay. If we started out at zero, we already know 408 00:27:58,300 --> 00:28:02,400 this is going to be zero. If we see a rollover over here, we're just going to increment over 409 00:28:02,400 --> 00:28:06,580 here. And so we can keep track of it on the other side just by seeing the truncation, if you 410 00:28:06,580 --> 00:28:12,060 really want to. And then the authenticator, our Mac, we can trans, we can actually truncate that as 411 00:28:12,060 --> 00:28:14,560 well. Because on the other side, when we pull it out, we're going to see the truncated freshness value. 412 00:28:14,580 --> 00:28:21,340 We can see how far it matches up. It should still match up on the other side. Okay. So this 413 00:28:21,340 --> 00:28:27,160 way, we can actually fit in everything into even, into standard CAN. We don't have very many 414 00:28:27,160 --> 00:28:33,800 bits. I think we end up with 27 bits, roughly. Okay. Again, this is all in the AUTOSAR spec, too, 415 00:28:33,860 --> 00:28:39,600 if you want to dig it up. But, um, so I've already kind of explained this as well, about the 416 00:28:39,600 --> 00:28:44,560 LSBs and the freshness value that we can actually, uh, uh, we are, depending on the 417 00:28:44,580 --> 00:28:52,520 component, to always be increasing by one. Um, and also about the authenticator that we can 418 00:28:52,520 --> 00:28:59,240 truncate that as well. Okay. So let's take a look at this whole method. If I have the freshness 419 00:28:59,240 --> 00:29:07,760 value, I can avoid the replay attack and I have authentic, authenticity. Okay. So in secure 420 00:29:07,760 --> 00:29:13,880 onboard communication, let's take a look at what's really going on and where we might have some 421 00:29:13,880 --> 00:29:21,360 possible, uh, some possible exploits. Uh, so, of course, we already know we're using cryptographic 422 00:29:22,300 --> 00:29:27,520 primitives. Uh, we, looks like we're going to keep our implicit availability as long as the, uh, 423 00:29:27,580 --> 00:29:31,900 receiver and the transmitter can keep track of these freshness values and authentications key. 424 00:29:32,760 --> 00:29:39,920 Yeah, its private key. Um, the freshness value is actually independently maintained by both the 425 00:29:39,920 --> 00:29:43,860 sender and receiver. So that means I send it out to the receiver, the receiver has to send it out to the 426 00:29:43,880 --> 00:29:48,320 I increment it on the other side, the other guy is going to expect it to be incremented and 427 00:29:48,320 --> 00:29:54,920 I'm maintaining it. Which actually, by the way, becomes a problem. Because what happens when the 428 00:29:54,920 --> 00:30:00,960 freshness counters get out of sync? Well, in a real world, they would never do that, right? But 429 00:30:00,960 --> 00:30:06,480 the reality is, even in normal operation of the network, for instance, you're cranking the 430 00:30:06,480 --> 00:30:13,300 vehicle, some other thing happens. You know, you have something that jumps on the bus and 431 00:30:13,300 --> 00:30:18,560 takes priority. You may end up with somehow getting out of sync. And that means we have to 432 00:30:18,560 --> 00:30:26,460 take care of that and that's actually going to be one of our exploits. Okay. So, for regular CAN, 433 00:30:26,580 --> 00:30:32,420 only 27 bits can be used for the MAC. Can this be brute force? Don't stay tuned. It's true. We 434 00:30:32,420 --> 00:30:38,360 have it over there. Eventually you'll see the siren going off and the strobe lights. But it 435 00:30:38,360 --> 00:30:41,720 takes about seven hours for us to brute force it. 436 00:30:44,540 --> 00:30:49,180 So, this is where this freshness value can also become desynced if we have to replace a 437 00:30:49,180 --> 00:30:55,200 node. In other words, I take it in for service. I got to somehow maintain the key, number one. But 438 00:30:55,200 --> 00:30:59,620 number two, the freshness value. What happens? Because I'm going to try to make this 439 00:30:59,620 --> 00:31:04,320 persistent so that I do a key cycle and it's going to keep track of what it was last time, 440 00:31:04,340 --> 00:31:08,100 et cetera. I don't want to make it easy where everything starts at zero at the beginning 441 00:31:08,100 --> 00:31:13,280 because that would just make it easier for us, right? So, having some way that we can do this, 442 00:31:13,280 --> 00:31:19,320 synchronizing the freshness values has to be done. And that is actually not covered in that 443 00:31:19,320 --> 00:31:24,820 secure onboard communication spec. It's actually up to what you would like to do as an OEM, 444 00:31:25,820 --> 00:31:30,160 which is very interesting because if they're doing it, they must be communicating that full 445 00:31:30,160 --> 00:31:34,260 freshness value periodically. And if they're communicating the full freshness periodically, 446 00:31:35,360 --> 00:31:40,580 that means you can see it. And if you can see it, that means you know it. And then guess what? I 447 00:31:40,580 --> 00:31:42,580 can replay it because I know the freshness value. 448 00:31:43,500 --> 00:31:48,320 I still have to take some guesses, though. That's what the demo is over there in the car hacking 449 00:31:48,320 --> 00:31:55,060 village. Okay. So that can be, that actually turns out to be a pretty fair way for us to 450 00:31:55,060 --> 00:31:59,560 actually try to get in there. So the secret sauce, when you're doing your pen testing, trying 451 00:31:59,560 --> 00:32:06,880 to find the secret sauce, how are the ECUs resynchronizing their freshness counters? That's a 452 00:32:06,880 --> 00:32:12,400 good place to look, okay? And I already talked about how desyncing can possibly happen even when 453 00:32:12,400 --> 00:32:16,860 you're cranking a vehicle. Certain things happen on the bus and things get out of sync. It just 454 00:32:16,860 --> 00:32:23,180 happens. So, this right here about periodically transmitting that full freshness value, if you're 455 00:32:23,180 --> 00:32:27,920 pen testing, I suggest you start looking at that. That's a good place to look. You just think, 456 00:32:27,940 --> 00:32:35,300 hmm, if I were them, the easiest thing for me to be would be periodically transmit it, okay? So, 457 00:32:36,260 --> 00:32:42,380 oop, let me back up here. So, um, what happens when they get to the OEM? Well, they get to the 458 00:32:42,400 --> 00:32:47,160 OEM and they get desynced. Well, the receiver is supposed to ignore, okay? It ignores that 459 00:32:47,160 --> 00:32:52,120 message. But that eventually causes some level of failure, okay? Whether that's a U code, 460 00:32:52,320 --> 00:32:57,980 possibly, because we say, we technically would say that we've lost communication with the 461 00:32:57,980 --> 00:33:04,660 transmitting ECU. So, U code or DTC. But the thing is, we have to deal with that in our 462 00:33:04,660 --> 00:33:12,380 software. So, once we get, once we get desynced, it's not like we can just jump in and say, oh, 463 00:33:12,400 --> 00:33:17,000 I'm back in. We're going to have to figure out, you know, uh, basically how we're going to get 464 00:33:17,000 --> 00:33:21,600 that full freshness value in this case. So, basically, that's where the, this demo, we, we can 465 00:33:21,600 --> 00:33:29,700 show you that over on the other side. Um, but, uh, another thing is instead of, say, being, uh, 466 00:33:29,720 --> 00:33:34,640 susceptible to brute forcing like this because we just have the one freshness, another solution 467 00:33:34,640 --> 00:33:41,720 would be to require multiple correct MACs before resyncing, okay? That would help us out a little 468 00:33:42,400 --> 00:33:50,140 bit. Instead of just one MAC works, boom, I'm done. No, make sure it's multiple MACs. So, key 469 00:33:50,140 --> 00:33:57,000 management, okay? So, uh, apart from all of this, uh, most everybody in this room already knows 470 00:33:57,000 --> 00:34:02,920 that key management is really the key. Um, if they are not done right, that's going to be a 471 00:34:02,920 --> 00:34:09,300 problem. So, how do they generate and store those keys? Well, that's up to the OEM, okay? Uh, 472 00:34:09,320 --> 00:34:12,380 so, could we just do one global key? Well, that would be really, really, really, really hard. 473 00:34:12,400 --> 00:34:16,000 That would be real simple but real stupid because, of course, the key gets out once and it's 474 00:34:16,000 --> 00:34:23,980 over, okay? Uh, so, not cool. So, maybe we have one key per vehicle, which, in a way, I've 475 00:34:23,980 --> 00:34:29,160 actually seen this kind of thing used out in the field where, uh, I'm unlocking an ECU for one 476 00:34:29,160 --> 00:34:34,540 particular ECU and that one particular vehicle, it unlocks with one, you know, basically you ask 477 00:34:34,540 --> 00:34:39,240 it for a seed and you get that same seed number every single time. And so, that way you'd have to 478 00:34:39,240 --> 00:34:42,380 know the solution versus, say, every time you ask, you get a new key. So, that would be really, really, 479 00:34:42,380 --> 00:34:44,980 really hard. I have to get a different seed number and so then I can just sit there and ask and 480 00:34:44,980 --> 00:34:49,960 ask and ask and ask and pretty soon I can watch a service tool, ask and ask and get answers and 481 00:34:49,960 --> 00:34:57,580 answers back and pretty soon I can create a table or I can unlock that ECU. So, um, so 482 00:34:57,580 --> 00:35:04,300 ultimately, if we have one global key or one key for the vehicle, as soon as we get on that 483 00:35:04,300 --> 00:35:12,180 vehicle with that key, obviously, ultimately, if we gain code execution on one ECU, essentially at 484 00:35:12,180 --> 00:35:20,400 that point, in most every case, that means that whoever owns that ECU now can send any message 485 00:35:20,400 --> 00:35:26,900 they want. Okay. Because in CAN, every ECU has to be able to transmit. And that means if I can 486 00:35:26,900 --> 00:35:31,600 make it transmit, then I can make it transmit whatever I want and I own the whole system. Okay. 487 00:35:35,480 --> 00:35:42,020 So another solution would be one key per message. Well, man, that's a lot of keys. If you've 488 00:35:42,020 --> 00:35:46,760 looked at any of the latest vehicles and counted the number of unique IDs that you see coming out 489 00:35:46,760 --> 00:35:54,520 on one bus, that's a lot of keys. Sounds bad. Sounds real complicated for anybody, even if they 490 00:35:54,520 --> 00:36:01,840 want to try. Okay. So having so many keys doesn't make too much sense, but maybe a possible 491 00:36:01,840 --> 00:36:07,900 compromise would be partial networking. In other words, I have a key for one group of 492 00:36:07,900 --> 00:36:12,000 messages. Okay. That kind of fits into the concept of a key for one group of messages. Okay. 493 00:36:12,020 --> 00:36:15,740 So let's look at the sub-systems that you see nowadays inside of more complex vehicles, more 494 00:36:15,740 --> 00:36:22,300 contemporary vehicles. I have an autonomy sub-system. I have a powertrain sub-system. I have a 495 00:36:22,300 --> 00:36:28,900 body control sub-system, et cetera, et cetera. And each one of those is, um, it could have its own 496 00:36:29,540 --> 00:36:35,300 key, if you will, so that we can compromise between having a key for every message and having 497 00:36:35,300 --> 00:36:42,000 one key. Okay. So, how do you get to the key for every message? Well, you can get to the key for 498 00:36:42,020 --> 00:36:46,020 every message. How about this? Even if we had keys for each message, would the security onboard 499 00:36:46,020 --> 00:36:52,800 communication protect against a Uconnect hack? Hmm. Interesting. Well, the thing is, you have to 500 00:36:52,800 --> 00:36:58,380 remember, they own that head unit. 100%. They own it. So if they own it, well, the thing is, it's 501 00:36:58,380 --> 00:37:03,160 already got everything already there. So that means you can still send stuff out. Uh, it will make 502 00:37:03,160 --> 00:37:07,120 it a little more difficult for you, but you have to remember, if you already have the code in 503 00:37:07,120 --> 00:37:11,900 there to deal with everything, and you just need to take a little extra advantage of it, I mean, 504 00:37:12,020 --> 00:37:17,620 you basically have it owned, you know, in the end. Okay. In other words, if you get remote code 505 00:37:17,620 --> 00:37:21,900 execution, you're going to, it's going to be a full compromise, no matter what you do, pretty 506 00:37:21,900 --> 00:37:30,200 much. Okay. So, what do we do design-wise, hopefully in OEMs, we'll do this. Uh, don't do crazy 507 00:37:30,200 --> 00:37:36,220 things like, you have code for playing MP3s, and it also somehow has the ability to send 508 00:37:36,220 --> 00:37:42,000 CAN frames. Shouldn't do that. Probably a bad idea. Um, make sure you, I mean, if you're 509 00:37:42,020 --> 00:37:45,620 using a G-Pack, you isolate processes and give them the right permissions, control that stuff, 510 00:37:46,100 --> 00:37:51,620 uh, using maybe a secondary processor for sending messages that has its own defined interface. By 511 00:37:51,620 --> 00:37:57,120 the way, Uconnect, the G-Pack, they did do that, but because they had authenticated, 512 00:37:57,620 --> 00:38:02,220 unauthenticated firmware, they were able to download it and reverse it. So, didn't matter 513 00:38:02,220 --> 00:38:10,480 anyway. So, protect your firmware. All right. So, if you have any questions, I probably can 514 00:38:10,480 --> 00:38:12,000 answer some of them. I'm not jacking off. So, if you have any questions, I'm not jacking off. So, 515 00:38:12,000 --> 00:38:17,560 Jeff. But I'd like everybody to get Jeff's information. Um, feel free to ask him questions. I 516 00:38:17,560 --> 00:38:22,080 actually know some of this stuff, too, and you can ask me questions as well. Um, unfortunately, 517 00:38:22,180 --> 00:38:26,880 Jeff couldn't be here, so hopefully everything's okay back home. Um, he really wanted to be 518 00:38:26,880 --> 00:38:31,980 here. He was here just long enough to turn around and come back. So, any questions about secure 519 00:38:31,980 --> 00:38:41,260 onboard communication that I might be able to answer? I did that a lot quicker than usual. Go 520 00:38:41,260 --> 00:38:41,400 ahead. 521 00:38:45,940 --> 00:38:48,820 Oh, I'm sorry. I'm having a hard time hearing you. That's okay. 522 00:38:53,060 --> 00:39:04,980 Oh, like, like, lighter weight ciphers. Now, that would be something for Jeff. Because that's 523 00:39:04,980 --> 00:39:11,980 getting out of my pay grade. But, in the end, what you're seeing, let me, because I'm 524 00:39:12,000 --> 00:39:17,740 a partial answer for you. So, uh, so the question was, um, if you think about, like, AES, maybe 525 00:39:17,740 --> 00:39:22,740 there should be some thought put to some of the lighter weight ciphers, that kind of thing. So, so 526 00:39:22,740 --> 00:39:28,660 you have to remember that in automotive, we've come from basically no encryption, no 527 00:39:28,660 --> 00:39:36,780 authentication. And then, um, they basically have heard rumors. I'll just say they've heard 528 00:39:36,780 --> 00:39:41,980 rumors that maybe it's probably time for us to pay some attention to, you know, maybe what's going to 529 00:39:41,980 --> 00:39:48,220 be going on with people hacking cars. And they've ignored it, okay, to the Jeep hack. It's like 530 00:39:48,220 --> 00:39:52,400 really the momentous occasion that people are like, oh, crap, we actually have to do something 531 00:39:52,400 --> 00:39:57,680 now. And so that means they're in the middle of a design cycle where they have no hardware that 532 00:39:57,680 --> 00:40:01,960 they're going to be able to put in because they have to pump it out. And usually in automotive, 533 00:40:02,200 --> 00:40:07,680 we're, we're reacting rather slowly, rather slowly. So that means they're going to try to do 534 00:40:07,680 --> 00:40:11,520 the stuff they can just do entirely in software first. And then they're going to get the hardware 535 00:40:11,520 --> 00:40:15,600 encryption in there where they can actually do something that's, even though it may not be AES, 536 00:40:15,660 --> 00:40:19,960 but I'm sure they would want to do lighter weight stuff just because of the, you know, fact that 537 00:40:19,960 --> 00:40:24,820 anything that takes too long, it's obviously going to be a problem. They're going to immediately 538 00:40:24,820 --> 00:40:29,500 go away from it. But it'll be a lot, it'll be a lot more secure, obviously, to, uh, to go to some 539 00:40:29,500 --> 00:40:33,740 of the heavier duty stuff than just this kind of authentication. But this is kind of like their 540 00:40:33,740 --> 00:40:37,660 stop gap if you think about it. It's like, okay, at least nobody can take control of the vehicle. 541 00:40:38,280 --> 00:40:40,940 We hope. Right? So. 542 00:40:41,520 --> 00:40:47,440 I know a very long non-answer to your question, but Jeff would love to talk about that 543 00:40:47,440 --> 00:40:53,360 because his master's is in mathematics. Then for fun, he's doing automotive, automotive, uh, 544 00:40:54,120 --> 00:40:57,360 cryptology. So, um, any other questions? 545 00:41:05,900 --> 00:41:10,620 I don't, but Jeff does. See, I'm, I, this is so easy for me to answer questions. I just say, oh, 546 00:41:10,660 --> 00:41:11,420 well, talk to Jeff. 547 00:41:11,520 --> 00:41:17,200 Um, the thing is, what I'm talking about here is actually what's in the standard. And the 548 00:41:17,200 --> 00:41:22,600 standard is, and this is part of, it's almost a frustration with open standard. Open standard 549 00:41:22,600 --> 00:41:29,300 says, okay, use a freshness value. And you're like, well, which one? Like, well, whichever one 550 00:41:29,300 --> 00:41:34,340 you want because it's open standard. Do what you want. So, uh, the thing is, if you're an OEM, 551 00:41:34,340 --> 00:41:38,940 you certainly should put some thought into those types of things. Okay? Certainly don't do 552 00:41:38,940 --> 00:41:41,500 something stupid like, uh, I'm going to use, uh, I'm going to use, uh, I'm going to use, uh, 553 00:41:41,500 --> 00:41:48,540 the network time, but modulo 100, so I end up with an integer between 0 and 99. Okay? Well, I'm 554 00:41:48,540 --> 00:41:54,220 not going to say who did that. Uh, okay, so anyway, um, but yeah, obviously you want to use, 555 00:41:54,260 --> 00:42:00,080 uh, you know, a proper freshness counter. So, but yes, open, open system architecture means 556 00:42:00,080 --> 00:42:04,540 OEMs get to decide. So they get to do some of their role of your own, if you will, almost, uh, 557 00:42:04,560 --> 00:42:08,560 by at least picking and choosing the things they want to use. Just like in key management. Uh, 558 00:42:08,580 --> 00:42:10,860 I think the next question was over here. Was there a question? 559 00:42:11,500 --> 00:42:18,200 Yes. Can you prevent, uh, DOS attack by, uh, using, uh, SEC? 560 00:42:19,520 --> 00:42:25,000 Oh. Oh, so that's a good question. Can you prevent a DOS attack on the vehicle with SEC 561 00:42:25,000 --> 00:42:30,700 OCH. Answer is no. You can take, uh, say, a value can. We've got some value cans over 562 00:42:30,700 --> 00:42:37,560 there. I can get into vehicle spy, use a free version, transmit R by D zero and then for the 563 00:42:37,560 --> 00:42:41,480 transmit rate put in minus one. And then that is a hint to the hardware to go and use that, uh, 564 00:42:41,500 --> 00:42:47,780 basically go as fast as possible and nothing will come across that bus, period. So that's your 565 00:42:47,780 --> 00:42:54,080 DOS attack. That's what we taught in Black Hat just this last week. So that's a good question 566 00:42:54,080 --> 00:42:59,660 though. Unfortunately when it comes to DOS attack, your options are pretty limited, okay, 567 00:43:00,240 --> 00:43:04,860 because of the way that CAN works. That's the way it works at the physical level. Works like a 568 00:43:04,860 --> 00:43:10,480 wired AND gate. So if you've got a zero on there, it's going to override everything. Any 569 00:43:10,480 --> 00:43:17,760 other questions? You had a question? Oh, you're good? Okay. If you're good, I'm good. Any 570 00:43:17,760 --> 00:43:27,680 other questions? Well, thank you very much for this bad approximation to Jeff Connell. So feel 571 00:43:27,680 --> 00:43:33,740 free to send him e-mails or get on his website. And the presentation once again is at 572 00:43:33,740 --> 00:43:40,320 jeffq.com slash defcon underscore secoc dot pdf. Thank you very much. 573 00:43:40,480 --> 00:43:41,480 Thank you.