WEBVTT 00:01.100 --> 00:02.460 Hey, hello world. 00:02.460 --> 00:05.080 It's your boy Brent, back with another talk on hacking cars. 00:05.500 --> 00:07.720 Last time we talked about how we automate the hack. 00:07.720 --> 00:11.520 This time we're going to talk about how to stop the hack automatically. 00:11.760 --> 00:21.860 So without further ado, this does not reflect any opinions of the government, the military, and any photos or cited papers that are shown in the talk. 00:21.860 --> 00:24.700 Those, of course, belong to their original copyright holder. 00:25.180 --> 00:27.020 And so let's talk about the threat. 00:27.020 --> 00:39.200 All right, so if we spoof the acceleration brakes and the parking assist to control the steering, we can get into a pretty dramatic situation where, let's say, a cyber criminal starts a three-way call with a mother. 00:39.600 --> 00:41.420 Their teenager is in the car. 00:41.500 --> 00:44.100 They say, Mom, the car won't slow down. 00:44.340 --> 00:54.100 And all of a sudden there's a new strange voice, maybe a computer-automated voice, that says you have three minutes to send me $10,000 using the link in the text message I just sent you. 00:54.100 --> 00:58.140 If you don't comply, I will crash this car at 110 miles per hour. 00:58.460 --> 01:07.420 The attacker disconnects, leaving the scared mother on the line with their teenager, who's about to possibly die from this exploit. 01:07.760 --> 01:10.220 This is not necessarily a fictional scenario. 01:10.780 --> 01:14.640 Surely you've probably heard of Chris Miller and Balasek's hack of the Jeep. 01:14.800 --> 01:16.700 So this is already something that's happened. 01:16.700 --> 01:22.600 And as cars get more and more automated, more and more connected to the Internet, this is a threat that will continue to happen. 01:22.600 --> 01:24.040 So how do we stop it? 01:24.040 --> 01:25.060 Let's use offense. 01:25.060 --> 01:26.940 Offense is the best defense. 01:26.980 --> 01:31.000 We can specifically do bit smashing to stop the attacker in their tracks. 01:31.020 --> 01:42.580 What it turns out is actually if you look at it, these control protocols that are in cars, while they may seem super insecure, with a very small and inexpensive change, we can achieve almost perfect security. 01:42.580 --> 01:43.560 I'll get into that. 01:43.560 --> 01:51.560 I understand it's a very bold claim to make, but it's pretty surprising how elegant and well this defense method would work. 01:51.560 --> 01:55.800 So it will stop your denial of service, which is typically thought to be unstoppable. 01:55.800 --> 01:59.160 In these control network situations, it will stop spoofing. 01:59.440 --> 02:10.500 And this will work for a lot of the control networks that are multicast, which means one sender sends a message and nearly all or all of the other devices on the network will receive that message. 02:10.680 --> 02:14.820 And the ones that it's not intended for will simply ignore it while it's on the wire. 02:15.200 --> 02:20.540 One other nice benefit of this, particularly for cars, is you no longer need an intrusion detection. 02:20.540 --> 02:30.940 It works out that the way that this defense is implemented, you achieve effectively perfect intrusion detection without any sort of complicated machine learning or AI. 02:30.940 --> 02:32.400 It just works. 02:32.640 --> 02:35.060 All right, so what is bit smashing, first of all? 02:35.060 --> 02:42.020 Let's say agency on the network wants to send a payload of hex A, and they're the fraud. 02:42.020 --> 02:46.240 They're the attacker trying to send some malicious data on the network. 02:46.240 --> 02:53.500 Now they're sharing a physical wire with all of the other nodes in the vehicle or in the multicast control network. 02:53.700 --> 02:57.060 So B is our valiant hero who wants to stop this attack. 02:57.080 --> 02:59.260 So B wants to stop C in their tracks. 02:59.260 --> 03:15.340 What B will do is while the voltage is still going up and down on the wire, as C tries to transmit their message, B in real time can stop that transmission while it's in progress by putting extra voltage on the wire that C is not expecting. 03:15.340 --> 03:22.660 And what this will do is essentially smash the logic that C is trying to send, and B will take over the communication on the bus. 03:22.700 --> 03:26.280 C will stop talking, and then the attack is stopped. 03:26.360 --> 03:38.580 So as you can see here on the left, C is sending 01010, and by B sending that extra logical one, that extra amount of voltage at a certain time segment, they effectively stop C in their tracks. 03:38.820 --> 03:40.060 So that's bit smashing. 03:40.420 --> 03:42.420 Now, I'm not the chef here, okay? 03:42.420 --> 03:47.760 Last time we talked, the previous talk called Reverse Engineering, 17 Cars in Under 10 Minutes. 03:48.220 --> 03:50.680 In that, I was a chef and your waiter. 03:50.720 --> 03:52.360 In here, I'm not the chef. 03:52.460 --> 03:56.100 This, I did not come up with the solution, and it's actually pretty well documented. 03:56.260 --> 04:05.660 In particular, this article you see in the green on the top right, that 2017 academic proof of concept, which was in the IEEE Vehicle Magazine. 04:05.800 --> 04:08.420 I encourage you to grab a copy if you get a chance. 04:08.440 --> 04:09.440 Check it out. 04:09.440 --> 04:14.880 It's a very clear explanation of how the process works beyond what I'm talking about here. 04:14.880 --> 04:19.320 And then also, they show you the hardware they used to actually implement this proof of concept. 04:19.320 --> 04:26.220 That way, you can try this out yourself and tinker around without having to burn any sort of custom hardware. 04:28.340 --> 04:33.240 One part of this security that is not perfect is we're not getting confidentiality. 04:33.240 --> 04:34.900 Okay, this is still a control network. 04:34.900 --> 04:39.480 We're still basically talking in an open room where each person is a member of that room. 04:39.480 --> 04:45.660 And when they project their voice, no matter how loud you want to talk, you're not going to stop the fact that that other person is talking. 04:45.660 --> 04:47.260 Everyone else will still hear them. 04:47.920 --> 04:52.580 So you're not going to get confidentiality in an open room talking to other folks. 04:52.580 --> 04:55.680 But what we do get is integrity and availability. 04:56.120 --> 04:58.980 So integrity, am I sure who sent this message? 04:59.000 --> 05:00.640 Is the person I think it is? 05:00.640 --> 05:03.320 And then, is this the message that they originally intended to send me? 05:03.320 --> 05:04.480 Has it been modified? 05:04.600 --> 05:06.660 There's no man-in-the-middle business going on. 05:06.880 --> 05:09.600 And then for availability, that's your denial of service. 05:09.600 --> 05:12.000 Can I talk in the network when I want to talk on it? 05:12.000 --> 05:14.660 And is it behaving how it's designed? 05:16.040 --> 05:20.360 All right, so to give a little bit more context, we are not talking about general use networks. 05:20.360 --> 05:31.940 And here, I mean like the internet, Wi-Fi, anything where you can add or remove endpoints and adjust the structure and the number of participants in the network dynamically. 05:31.940 --> 05:33.440 And you don't need to make any adjustments. 05:33.440 --> 05:35.360 It just naturally works out. 05:35.440 --> 05:37.440 That's not what we're talking about here. 05:38.860 --> 05:47.380 We actually gain a lot of benefit by not having this because here in the general use network, there's no way of necessarily knowing how many participants are on the network. 05:47.380 --> 05:54.200 So when you see new data go on the network, it's unclear whether they are a legitimate user and member of the network or not. 05:54.200 --> 06:07.260 Additionally, there's tons of metadata for keeping track of which messages are where, who owns what, and spoofing that metadata is just one more attack vector to make it even more confusing to know the origin of a message. 06:07.680 --> 06:09.400 Here, we're talking about control networks. 06:09.400 --> 06:17.600 Okay, so medical electronics, vehicles, obviously in this case, CarHack Village, but planes, trains, automobiles, factory floors, you name it. 06:17.600 --> 06:21.300 So control networks, you're not trying to add or remove hosts very often. 06:21.300 --> 06:26.860 You pretty much know the machines and components that you want to communicate, and that's a fairly fixed number. 06:27.000 --> 06:31.060 Maybe you might add one or two every couple years, and you can document that. 06:31.060 --> 06:32.720 It's a very deliberate process. 06:32.960 --> 06:34.660 And you also lose metadata. 06:34.920 --> 06:39.460 And so in this case, it actually goes for a benefit here because now there's even less information. 06:39.720 --> 06:41.260 The attacker has a spoof. 06:41.260 --> 06:47.080 They basically have to talk in the wide open, and there's not a lot of extra information that they can lie about. 06:47.080 --> 06:50.500 They simply say, I'm this person, and send their information. 06:50.960 --> 06:56.600 And if there's already someone that says, hey, that's my name, so who are you? 06:56.600 --> 07:00.620 It becomes very clear and evident that that person is not who they say they are. 07:00.620 --> 07:02.920 That node is not legitimate. 07:03.920 --> 07:05.880 So what does this look like in practice? 07:05.880 --> 07:10.000 If A wants to send some information, they send it over the bus. 07:10.100 --> 07:12.900 Again, this is multicast, so everyone gets a copy. 07:12.900 --> 07:21.520 And if you look at this wiring harness from a vehicle, it might look something like this, where it originates at one point of that wire, and then it gets sent out to multiple other endpoints. 07:22.080 --> 07:33.120 Now, granted, in vehicles, there's a lot of things like gateways, which effectively create collision domains, or if this term is more familiar to you, subnets, even though it's not strictly subnetting. 07:33.480 --> 07:37.820 So sometimes these gateways, you don't necessarily see the entire bus on the vehicle. 07:37.860 --> 07:39.660 We'll get to that, but that's not a problem. 07:39.660 --> 07:42.460 As a matter of fact, it actually goes for a benefit even more. 07:43.180 --> 07:45.040 So what is the problem? 07:45.240 --> 07:53.800 So because I have this multicast nature, and let's say I've got my instrument cluster talking to some other piece of information, I may also have a telemedics unit. 07:53.840 --> 08:01.280 I may have an entertainment system that has a SIM card in it, where I pay for Wi-Fi connection to my vehicle. 08:01.280 --> 08:03.200 That way, I have in-vehicle Wi-Fi. 08:03.200 --> 08:06.220 I can update my maps, whatever reason you want to be connected. 08:06.220 --> 08:22.720 Or for example, the Tesla business model, which is instead of having to recall vehicles, and it's a very expensive and time-consuming process, I can do a lot of things, over-the-air software updates to change the behavior of the car, in which case a data connection is mandatory to do that. 08:23.280 --> 08:26.780 So again, we've got some sort of internet connectivity to the vehicle. 08:26.960 --> 08:38.500 Now these systems, which were designed to be pretty insecure, there's no cryptology, there's nothing, really no authentication, but it used to be air-gapped, so it was okay, now it's no longer air-gapped. 08:38.500 --> 08:41.000 Now we've got attackers that can reach these networks. 08:41.060 --> 08:43.540 So let's assume the attacker has done so. 08:43.560 --> 08:56.260 One way or another, they've gotten onto our control network, and they can modify our brakes, they can turn off our accelerator, they can turn off whatever, possibly even take control if we have that power steering module, and we're in a lot of trouble. 08:56.260 --> 08:58.160 So we want to stop that from happening. 08:58.160 --> 09:09.920 One thing the attacker can choose to do with a pretty dangerous attack, simply pick a high-priority message identifier that no one else is using, and just spam that as quickly as they possibly can. 09:09.920 --> 09:17.060 Essentially, you turn off all communications, and now you've got no steering, no acceleration, no brakes, you're just dead in the water. 09:17.340 --> 09:24.780 So if you look at the Wired article, for when Miller and Balasek did the GPAC, they probably did something similar to this. 09:24.780 --> 09:28.960 The other situation is a little bit more nuanced. 09:29.100 --> 09:38.760 You've got a specific packet you want to send to a specific location to fool that part of the network, and you simply just say, I'm this person. 09:39.060 --> 09:45.440 And right now, the way it goes, even if B can see this happening, Module B here, there's really nothing they can do about it. 09:45.440 --> 09:54.320 They just have to grin and bear it that someone else is using their ID that they know should not be used by anyone else, and the attack simply happens. 09:54.320 --> 10:04.940 B can try to send messages all they want, but now you just get into basically dossing the network all over again when you get into a fight of the legitimate B versus the attacker acting like their B. 10:05.120 --> 10:08.520 So we want to stop denial of service, and we want to stop spoofing. 10:08.980 --> 10:10.640 So here's the solution. 10:10.880 --> 10:13.240 We're going to bit smash those communications. 10:13.420 --> 10:20.640 So again, bit smashing is adding that extra voltage on the wire, physical layer, in order to stop that communication or take it over. 10:22.060 --> 10:25.880 We're going to focus on cars here, obviously, because it's CarHack Village. 10:26.060 --> 10:31.300 But again, this is a fairly generic process, but here we've got the machine and its logic. 10:31.300 --> 10:33.940 So in this case, the actual physical brake caliper. 10:34.000 --> 10:41.820 There's going to be some internal wiring and control there to actually squeeze onto the disc brake and slow the car down. 10:41.820 --> 10:43.880 That's part of the machine logic. 10:44.660 --> 10:48.860 The vast majority of the cost of that component is that machine and the logic. 10:49.420 --> 10:51.940 Touching that is what's called a CAN controller. 10:51.940 --> 11:01.660 That's a piece of little chip and or software within the bigger logical board that actually implements the controller area network protocol. 11:01.700 --> 11:07.800 So what order do I send things, how do I interpret messages, how do I synchronize with the network clock, etc. 11:08.080 --> 11:11.940 And then separate and distinct from that, once more, is the CAN transceiver. 11:11.940 --> 11:20.280 And that's the piece that actually implements the layer one electrical engineering to talk on the wire. 11:20.280 --> 11:24.940 So how do I actually make a waveform and create voltage on the wire to communicate. 11:25.220 --> 11:38.360 So in either case, I can leave alone all the design that I'm doing for my main machine, and I could just modify that commercial off-the-shelf product, that CAN controller, or the CAN transceiver, or both. 11:38.360 --> 11:43.800 If I modify one of those to implement bit smashing, then the manufacturer really doesn't have to care. 11:43.800 --> 11:47.740 They can just buy that product off the shelf, attach it to their existing product. 11:47.740 --> 11:51.600 There's really nothing else that they have to do, and you get the security. 11:51.720 --> 11:53.600 So it's extremely low cost. 11:53.760 --> 12:00.480 These CAN controllers and transceivers, we're talking less than a dollar most of the time, if not pennies, to do this. 12:00.480 --> 12:12.160 And if we assume that that costs quadruples, to add the bit smashing capability, we're talking about $0.20 versus $0.80 to get a completely secure solution. 12:12.660 --> 12:22.180 One way of thinking of this, if you have any background in security, is this is doing intrusion detection and prevention using a decentralized access control list. 12:22.180 --> 12:35.240 So if every endpoint knows what their name is, and they'll bit smash anyone else that tries to use that name, essentially you get an access control list, that way stopping any sort of traffic does not pass that check. 12:36.060 --> 12:42.160 Alright, so here I am, B, our hero, once more, good boy, and he's watching the bus. 12:42.160 --> 12:58.100 And I'm watching the attacker send some information, and the way I know he's an attacker is I'm watching him send bits on the bus over time, and I'm processing this in real time, I see that, hey, you just used my ID, that's not okay, I'm the only one that gets to use that ID on this bus. 12:58.260 --> 13:04.840 So now I've got a long time, relatively speaking, to react and actually bit smash. 13:04.840 --> 13:19.540 There's about up to 80 or so, possibly even more, clock cycles, or bus cycles, should I say, of the clock going, clock increments, to have an opportunity to bit smash. 13:19.540 --> 13:28.760 So even if it takes a little bit of processing to actually decide, okay, yep, they used my ID, I'm going to use this clock cycle to figure out, yep, I definitely want to bit smash. 13:28.760 --> 13:46.720 And then in here, either the CRC or the data, I can just start holding the voltage high, I will bit smash that transmission, all of the members of the network will throw out that message, and they will even store it in memory, they won't even transmit it up to that higher component that they're supporting. 13:46.720 --> 13:49.040 It will stop at that CAN controller. 13:49.140 --> 14:07.920 So one time I just want to emphasize, if we're trying to, say, spoof or attack that brake, the brake won't even realize an attack is happening, because it will stop at that controller chip, or logic, and it won't even make it to the part of the control unit that's actually working the brake. 14:07.920 --> 14:09.620 It won't even realize it's happening. 14:11.280 --> 14:23.420 Alright, so the way that would look, the telematics unit, if we say that's the source of the attack, tries to send a message, before it even makes it to A, control module B, our hero, says, two B's? 14:23.460 --> 14:27.800 No way, not two B's, there can only be one, okay, I'm the only B. 14:28.780 --> 14:48.480 We get this out of benefit, okay, with CAN in particular, anytime that an error occurs while you're trying to transmit, by the way controllers are supposed to be implemented to meet the CAN standard, if a fault happens while I'm trying to talk, I essentially get a hit against an internal counter that I have. 14:48.480 --> 14:57.820 We'll call that a fail state counter, saying something went wrong, possibly me, maybe I'm defective, and I'm going to keep track, or I'm going to try again. 14:58.020 --> 15:12.940 Well, as B continues to bit smash me when I use its ID, eventually I'm going to exceed that threshold, and I'm going to go into what's called a fail silent state, which essentially means that I will continue to listen to the network, but I will not send messages. 15:12.940 --> 15:27.020 And so if you're the attacker, and you're trying to communicate with this car through the internet, and you've got some traffic, and you're seeing the traffic go, even better is not only do I stop that attacker from physically being able to transmit on the bus, 15:27.020 --> 15:42.260 but the attacker may not even realize that they're stopped, because they're still seeing the traffic come in, and they cannot necessarily get acknowledgments that their transmission was successful or not, depending on the logic between the machine and the controller that it's attached to. 15:42.500 --> 15:49.960 So the controller may or may not actually communicate that it's gone into a fail safe state, because it's failed, it's just not doing anything. 15:50.360 --> 16:00.600 So not only do we stop the attacks, whether that's denial of service or spoofing, but we've essentially done a DOS attack against the attacker's node, and turned them off for some period of time. 16:01.380 --> 16:04.600 A couple assumptions to actually make this happen. 16:04.700 --> 16:08.420 So each endpoint needs to have a unique ID on this multicast network. 16:08.420 --> 16:13.180 So if you have multiple possible people using the same ID, then that's a problem. 16:13.220 --> 16:18.720 Because now it's unclear, if I see that ID on the network, should I bit smash it or not? 16:18.720 --> 16:21.940 So every endpoint needs to have a unique ID. 16:22.860 --> 16:40.260 Gateways, okay, so if I have everything in my engine compartment, for example, going into a single gateway, and then that gateway talks to other parts of the vehicle, like brakes or something like that, or your tachometer, that essentially creates two different parts of the CAN bus, 16:40.260 --> 16:45.320 and nodes on either section may or may not be able to see traffic from each other. 16:45.380 --> 16:47.740 So now you've got back into the same situation. 16:47.740 --> 17:04.760 Well, if this node over on this section of the network is supposed to bit smash these IDs being generated on another section, but the gateway isn't forwarding that, it's not being a transparent, basically a bus, instead of a switch, then how do I stop that? 17:04.760 --> 17:06.980 Well, you just reverse the logic. 17:06.980 --> 17:16.740 So if endpoint logic is, I'm going to allow all traffic except my ID, if I see my ID, I'm going to bit smash it, you flip-flop that logic for gateways. 17:16.740 --> 17:22.220 I'm only going to allow this set of IDs, and I'm going to bit smash anything that doesn't make sense. 17:22.220 --> 17:30.520 And that access control list, if you want to call it that, can be specific for each section of the network that it's physically connected to. 17:30.940 --> 17:49.200 What that allows you to do is, going back to the denial-of-service attack example, with CAN, I could just pick the highest priority arbitration ID possible, according to the protocol, and more than likely there's not going to be a device on the network that's using that arbID, 17:49.200 --> 17:53.620 so if the gateways weren't implementing this, then they would just be able to DOS the network. 17:53.780 --> 18:06.880 But by having these gateways, looking to say, I know what arbID should exist, and you're using something that's outside of that list, I'm going to bit smash you, and then again we go into, alright, now we've turned off the attacker's CAN controller, they can no longer talk, 18:06.880 --> 18:15.700 it's not a problem, and the message is never finished anyways, so the overhead imposed on the bus is really not that bad. 18:16.360 --> 18:34.420 And then finally, one talk, if you watch a lot of the talks that Miller and Balasek gave a couple years ago, is a lot of these ECUs, the nodes on a vehicle, will accept reprogramming commands while driving at freeway speeds. 18:34.420 --> 18:39.580 There's really no logic to check, should I be allowing a reprogram to happen or not? 18:39.580 --> 18:41.320 They just simply accept it. 18:41.320 --> 18:58.220 So one small tweak that would need to happen, either in the CAN controller or possibly that more expensive component piece, is to add just a little bit of extra on that state machine to say, hey, I'm getting the signal, or I'm seeing that we're not in park, 18:58.220 --> 19:03.500 so I'm not going to allow a reprogram to happen, you need to put the vehicle in park before that happens. 19:04.180 --> 19:11.860 And then finally, we've got to make sure that the controllers are just not rewritable chips. 19:11.860 --> 19:16.660 So that imposes some recall issues if one of these transceivers starts bugging out. 19:16.660 --> 19:18.640 You will need to go back to the shop. 19:18.640 --> 19:35.220 But this basically makes it impossible, just like we wouldn't want to reprogram the logic for the larger component, if we have these very powerful bit-smashing controllers or transceivers, we do not want to open up the opportunity for those to get reprogrammed and then used to just hold the bus high, 19:35.220 --> 19:37.620 and then there's really nothing anyone can do about it. 19:37.620 --> 19:42.800 You're just putting voltage on the wire, and there's no workaround for that. 19:42.800 --> 19:48.700 So we don't want it to be rewritable, but we do want them to continue to comply with that fail silent state. 19:48.740 --> 19:52.960 All CAN controllers should comply with that, if they're compliant with the CAN protocol. 19:52.960 --> 19:59.540 And then again, other multicast protocols typically have similar fail states. 19:59.980 --> 20:06.940 But I'm not going to speak that I know for sure for every possible multicast ICS protocol. 20:08.400 --> 20:09.880 Thanks so much. 20:09.880 --> 20:18.800 Just again, references, if you want to look into this deeper, please check out the IEEE Vehicle Technology Magazine from 2017. 20:18.800 --> 20:21.460 Go ahead and grab a copy off of IEEE Explorer. 20:21.460 --> 20:33.080 And these guys did a pretty good job of really breaking it down and showing photos of how they created a working version of this without any sort of special hardware or production manufacturing capability. 20:37.360 --> 20:39.560 All right, with that, I'll open it up to questions. 20:39.560 --> 20:40.360 Thank you.