WEBVTT 00:03.430 --> 00:05.950 Good day, DEF CON and Car Hacking Village. 00:05.950 --> 00:11.550 I am Jonathan Petit, and I'm here with two of my colleagues, Rashid Ansari and Kong Chen. 00:11.550 --> 00:17.430 We are the research team for Qualcomm working on connected and automated vehicle security. 00:18.150 --> 00:26.730 Today, we're going to talk about misbehavior detection and demonstrating you some attacks on VLAN board unit. 00:27.010 --> 00:32.230 So before we start, I think it is important that we understand what is V2X communication. 00:32.230 --> 00:50.070 So V2X enable devices like vehicles, pedestrians or roadside unit to be equipped with an onboard unit, a device that enables all of those components to broadcast information in the surrounding to create an awareness. 00:50.330 --> 00:57.850 So in this example, we have three cars and are all equipped with V2X technology. 00:58.190 --> 01:02.530 And we'll see that now the white car is performing an emergency brake. 01:02.890 --> 01:16.390 Therefore, because the onboard unit is connected to the CAN bus, it can detect that there is a high deceleration, for example, and that in the brake pressure, and therefore we'll be able to generate a message that he's sending to the surrounding vehicle. 01:17.150 --> 01:23.750 So those messages are called basic safety message here in the US, so that's the BSM that we're going to talk about in this talk. 01:24.390 --> 01:35.070 When the vehicle receive a BSM, they are able to understand that the white car is performing an emergency brake, and therefore themselves brake, avoiding a chain of collision. 01:35.130 --> 01:41.890 So we see the huge benefit, safety benefit, especially in that V2V use case that we are showing you. 01:41.890 --> 01:51.350 This is an emergency electronic brake light application, and it's consuming BSM sent by other vehicle to understand an emergency brake is happening. 01:51.430 --> 01:56.330 So there is many application for safety and auto efficiency that are designed for V2X. 01:56.330 --> 01:57.710 So this is the context here. 01:57.710 --> 02:00.490 We are looking at those type of application. 02:00.730 --> 02:12.030 So then, of course, we understand that from a security standpoint, we do not want external attacker to be able to send bad messages to the other vehicles. 02:12.030 --> 02:16.330 So all the messages that are sent are actually digitally signed. 02:16.330 --> 02:27.090 So in the same example we just showed before, now we have the white car is actually signing with this private key, attaching a certificate, the message before sending it. 02:27.090 --> 02:34.890 The receiver will use the keys in order to verify that this is sent by an authenticated vehicle. 02:35.210 --> 02:36.350 Good. 02:36.610 --> 02:43.370 But as you might imagine, this doesn't prevent any bad content to be sent. 02:43.370 --> 02:47.670 You could be authenticated, but sending wrong information. 02:48.190 --> 02:55.270 So here in our same example, we have here the white car is an attacker, is sending a fake EBL to the other vehicles. 02:55.610 --> 02:58.310 The other vehicle will verify the signature. 02:58.310 --> 02:59.530 It's all valid. 02:59.570 --> 03:03.990 Therefore, they have to use a content which says it is an emergency brake. 03:04.310 --> 03:08.990 Here in the animation you just saw here, the blue car didn't stop. 03:08.990 --> 03:10.010 And you might wonder why. 03:10.010 --> 03:17.890 It's because we can make an assumption that this vehicle was equipped or is equipped with a camera and therefore didn't see the white car braking. 03:18.190 --> 03:22.970 But the red car has no line of sight and therefore has to trust that information. 03:23.550 --> 03:30.310 So we clearly understand and you need a misbehavior protection system to defend against such attacks. 03:30.370 --> 03:39.670 And this is one we're going to present today is really about the attacks and how you perform this and how you protect against this. 03:40.070 --> 03:45.770 So let me show you a little bit on our example about misbehavior. 03:46.150 --> 03:52.570 Here on the left-hand side, this is an application called intelligent signaling. 03:52.830 --> 04:00.730 This is where you have a traffic light equipped with a roadside unit with the same kind of equipment to receive the message sent by the vehicle. 04:01.570 --> 04:07.590 And by reading the BSM, it adjusts the signal phase and time. 04:07.590 --> 04:12.710 Therefore, it's going to play with the red and green on this different segment coming at the intersection. 04:13.490 --> 04:32.530 And an attack that was demonstrated by some researcher showed that if the vehicles are sending wrong BSMs, I'm going to just run the video here, if you send that, and after 30 minutes of attack, you can see this long line at each of two, or actually three intersections, 04:32.530 --> 04:34.070 three segment of the intersection. 04:34.070 --> 04:46.690 So an application that consumed a BSM that is fake, even though it's purely authenticated, if you do not do a misbehavior analysis protection, you might see issues like this in intelligent signaling. 04:47.890 --> 04:53.070 Now looking on the right-hand side, we have a position jump attack. 04:53.290 --> 05:00.110 So the position here in that representation, you are, the ego vehicle is the green dot. 05:00.110 --> 05:09.690 You're driving and an attacker is sending messages with the same identifier, but he's jumping, he's changing his position. 05:09.690 --> 05:13.090 That's where you see this blue dot, this is the BSM received. 05:13.090 --> 05:16.670 And it's flickering because it's actually jumping back and forth. 05:16.770 --> 05:21.830 And sometimes outside of the frame here that you can see, but it's basically doing it back and forth. 05:21.830 --> 05:23.610 That's the position jump attack. 05:24.350 --> 05:34.750 And what is interesting, as you're going to hear this sound in a few seconds, is that sometimes this is performing here a forward collision warning. 05:34.750 --> 05:41.090 So even though this was a position jump, you might see you need to detect those kinds of behavior. 05:41.090 --> 05:43.390 Same identifier and still jumping back and forth. 05:43.390 --> 05:46.750 That shouldn't be taken in consideration by an application. 05:48.090 --> 05:50.510 I have other example to show you. 05:50.550 --> 05:55.150 Here, this is another representation of the onboard unit. 05:55.150 --> 05:58.150 Here, this is, we use MATLAB actually as a visualization. 05:58.370 --> 06:01.030 And you are the red car. 06:01.110 --> 06:09.830 And all the other blocks that you see, the blue and orange one, are the vehicles also sent by the V2X message. 06:09.830 --> 06:13.390 So you're going to represent this local dynamic map with all the vehicles. 06:13.390 --> 06:15.630 On the left-hand side, you have the first misbehavior. 06:15.630 --> 06:17.110 It's changing headings. 06:17.110 --> 06:28.490 Because part of the BESM, there is the position, there is your kinematic states, your velocity, but also you have the headings that helps pass planning, for example. 06:28.490 --> 06:30.650 To know where is this car going? 06:30.650 --> 06:33.630 Especially when you perform pass prediction when you're using Kalman filter. 06:33.630 --> 06:35.190 You want to use that heading. 06:35.490 --> 06:39.810 And here, in this specific example, you see the car actually spinning. 06:39.810 --> 06:41.950 So we are changing the heading all the time. 06:42.150 --> 06:49.210 So now your system that consumed the BESM to perform pass planning might be really confused by this kind of behavior. 06:50.190 --> 06:52.770 In the middle, we have a single attack. 06:52.870 --> 06:58.810 So this is where an attacker is using multiple certificates that are all valid at once. 06:58.810 --> 07:01.610 So it could be 20 certificates valid per week. 07:01.610 --> 07:10.190 And for example, you'll be using your 20 or 19, depends if you want to use yours, and you send your 19 to create 19 other ghost vehicles on the road. 07:10.190 --> 07:12.790 And you can make them move as you wish. 07:12.790 --> 07:21.850 So that is what happens when you map all the BESM you receive and put them on this virtual view. 07:22.130 --> 07:30.710 It is really hard for the connected and even automated vehicle in the future to behave in this kind of really noisy environment. 07:32.490 --> 07:34.790 On the right hand side, we have a position overlap. 07:34.790 --> 07:38.330 This is where an attacker is actually overlapping two of those vehicles. 07:38.330 --> 07:40.530 So here, that is basically what we see. 07:40.530 --> 07:43.370 And here even overlapping with your own position. 07:43.970 --> 07:51.310 And those are just a couple of example about what we call misbehavior that are all authenticated messages, but the content is wrong. 07:54.330 --> 08:00.050 So when we look at V2X misbehavior, there's what we call a misbehavior life cycle. 08:00.170 --> 08:11.310 So you receive those V2X messages, and here we gave example about basic safety message because they are the one commonly frequently sent every 100 millisecond to other neighboring vehicle. 08:11.310 --> 08:13.730 The first stage is the detection. 08:13.730 --> 08:15.550 You want to do misbehavior detection. 08:15.590 --> 08:17.710 So what do you do in this case? 08:18.270 --> 08:26.550 The goals are to validate the position of the sender, his motion, its motion, and the presence. 08:27.870 --> 08:33.190 To do that, you can also, you have to look at the application content. 08:33.190 --> 08:37.610 So the application layer content, meaning you look at the content of the message itself. 08:37.750 --> 08:42.770 You will look at a different field, are they plausible, are they actually consistent? 08:43.870 --> 08:52.370 But one important thing is that you need to understand the effect on the V2X application that is consuming that ESM. 08:52.570 --> 08:57.030 Because not all messages are actually triggering an application event. 08:57.030 --> 09:16.310 In our case of the EEBL that we showed earlier, you will perform an EEBL, so perform yourself a heart breaking or warning the user only if the vehicle is ahead of you with a sudden deceleration, for example, and a brake status flag at one. 09:16.950 --> 09:25.510 So I could be sending wrong messages, but I'm not ahead of you, and therefore it will not trigger the V2X application. 09:25.510 --> 09:30.970 So it is important to understand that because not all messages are equal and therefore should be investigated. 09:31.410 --> 09:39.690 As we're going to demonstrate in the demo later, it is really also important to look at the lower layer of the IETF stack. 09:39.690 --> 09:51.150 I'm going to give you an example where you can use signal strengths of the signal to really identify the position or the presence of another vehicle. 09:52.050 --> 09:57.930 So, but then really finally, when you build a detection system, you need to have a timely detection. 09:58.170 --> 10:02.350 You want a real time detection because this is a safety of life application. 10:02.350 --> 10:07.670 This is the information is useful to, in our example of an EEBL to perform an emergency brake. 10:07.670 --> 10:12.110 Therefore you need to detect that attack really quickly. 10:12.110 --> 10:16.270 You cannot afford to wait the whole chain until the global reaction. 10:17.330 --> 10:38.970 And you have to do this, so in real time, if possible, and with high accuracy, and that's the performance part where in some cases, our case, for example, we want to favor recall over precision because it is important to capture as much attack as possible and really precise only on one attack. 10:39.250 --> 10:43.690 So, but that will depend on your system and your use case and what you will consider. 10:43.690 --> 10:48.370 So this is everything you need to consider when you want to build a detection system. 10:49.130 --> 10:54.350 As soon as you've detected, it's not just enough to detect and give it to the application. 10:54.350 --> 10:56.430 You need to perform a local reaction. 10:57.290 --> 11:05.050 And two example about what could happen locally on your vehicle is to dismiss the further messages from the same identifier. 11:06.190 --> 11:17.050 But as we know, there is privacy by design in V2X, which means that we, each vehicle are using pseudonyms and can change them according to pseudonym change strategies. 11:17.050 --> 11:19.490 So what about pseudonym change in this case? 11:19.490 --> 11:23.850 If you dismiss that, the same standard will simply change identifier. 11:24.010 --> 11:25.630 It's still a question here. 11:25.690 --> 11:30.130 Another reaction that we do locally is to adjust your kinematic state. 11:30.130 --> 11:33.170 So you will perform potentially a graceful degradation. 11:33.450 --> 11:42.410 Let's say that you are in a platoon of vehicle, of connected vehicle, where you use those BSTEM to know that the vehicle is ahead and agree on the inter-vehicle distance. 11:43.190 --> 11:45.990 And now you detect that in that platoon, there is a misbehavior. 11:46.270 --> 12:00.750 You better actually say, oh, let me leave the platoon or degrade and say, if this was a level four autonomous vehicle, for example, you want to go a level three, you want to go back to the driver, or you want to warn the driver. 12:00.750 --> 12:08.130 So it is important to think in terms of the cyberspace, dismissing the further message and also on the physical space, what do you do? 12:09.890 --> 12:15.050 Then also, when you do your detection, you will perform, you will generate a report. 12:15.050 --> 12:16.490 That's the reporting phase. 12:16.490 --> 12:22.670 So here, depending on the type of misbehavior, you will have different type of misbehavior report. 12:22.930 --> 12:28.150 And this is currently under standardization to actually agree about what should be in that report. 12:28.590 --> 12:30.150 When do you put the evidence? 12:30.150 --> 12:31.750 What evidence do you need? 12:31.750 --> 12:39.650 And this report is important because it is sent to encrypted and sent to the MA, the Misbehavior Authority. 12:39.650 --> 12:44.890 It is a component part of the PKI for, and in our case, the SCMS. 12:45.440 --> 12:52.590 The Misbehavior Authority, receive all the misbehavior report from different vehicles, aggregate those misbehavior report. 12:52.670 --> 13:06.330 And it is the only one that can actually link this different pseudonym to the same device by actually a process of talking to the other SCMS component, PKI component. 13:06.630 --> 13:14.550 And this is how, for example, they could detect a Sybil attack because they will know that all those devices are linked to the same pseudonym. 13:15.090 --> 13:18.710 So that is an example about what is happening in the investigation. 13:18.950 --> 13:23.910 And then the MA will decide what is the global reaction. 13:24.110 --> 13:28.290 In cyberspace, this is a revocation, for example, of the enrollment certificate. 13:28.410 --> 13:37.310 If you cannot revoke, as it is the case currently in Europe, you just block the generation of future pseudonym certificate for that vehicle. 13:37.310 --> 13:46.810 And then you will put that on, for example, in the US, we put that on the CRL, the Certification of Location List, that is then provided to all vehicles so that they can dismiss immediately the message. 13:47.870 --> 13:51.710 But something that isn't discussed yet is really what happened in the physical space. 13:52.010 --> 14:03.070 You could, for example, inform the owner of the vehicle, of the device, and to perform an inspection, to repair, and therefore to perform a re-enrollment into the system in a secure location. 14:03.530 --> 14:07.370 Or maybe why not performing a remote vehicle immobilization? 14:07.370 --> 14:11.950 For now, you are stopping the vehicle where it is because that's been a misbehavior. 14:11.950 --> 14:19.170 Of course, this remote vehicle immobilization could be problematic if this is coming from a faulty sensor and not a real malicious attacks. 14:19.770 --> 14:25.190 But you know what we are saying, it's like there's a need of cyber reaction and physical space also reaction. 14:25.370 --> 14:27.630 So this is the whole misbehavior lifecycle. 14:27.990 --> 14:40.270 And as we can definitely see it, as an attacker, if I fool the detection part, you will never report me, you will never react to it, you will know no investigation and no verbal reaction. 14:40.270 --> 14:48.290 Therefore for this presentation, we're going to focus on this part about how an attacker can defeat the detection system. 14:48.290 --> 14:49.610 And we're going to show you a progression. 14:49.610 --> 14:52.230 How do we usually do the attacks? 14:52.230 --> 14:56.170 So where are we going to start and then slowly make it a smarter and smarter attacker. 14:56.170 --> 14:58.790 For this now, I will have my colleague, Rashid. 14:58.790 --> 15:02.790 I'm going to take over to talk to you about this progression of attacks. 15:17.480 --> 15:18.720 Can you hear me now? 15:25.580 --> 15:26.980 All right, yeah. 15:26.980 --> 15:28.120 Thank you, Jonathan. 15:28.120 --> 15:39.080 So as Jonathan talked about the detection portion of misbehavior detection system. 15:39.220 --> 15:49.340 So this slide shows you all the possible ways that we look at right now to detect any attack. 15:49.340 --> 15:59.620 So any attack on the application or on the physical layer, or anything. 15:59.620 --> 16:12.500 So let's go over what we do about, how we go about checking all the, checking everything in the V2X space here. 16:12.500 --> 16:23.560 So first we look at basic plausibility checks, where we look at if the speed or angle or acceleration in a BSM or a CAM message is unrealistic. 16:23.560 --> 16:28.360 Is it too high or is the turning angle too much as the vehicle? 16:28.360 --> 16:33.920 As you saw in the heading change example, is the vehicle really changing its heading a lot? 16:33.920 --> 16:35.200 Is this really possible? 16:35.200 --> 16:38.200 And we can do this on a per message basis. 16:39.620 --> 16:45.020 And that's how, and you don't need a chain of messages for this. 16:45.840 --> 16:51.100 So an attack can be detected with one message as well in this case. 16:51.380 --> 16:53.880 Then we look at consistency with the sensor. 16:53.880 --> 17:14.780 So we look at whatever messages we are getting, like whatever speed you're getting, you compare that with, let's say a radar, like if a radar is tracking any other vehicle, whatever speed that radar, that you can calculate using the radar input, you compare that with the information you're getting in the V2X, 17:14.780 --> 17:16.100 in the BSM. 17:17.440 --> 17:25.300 So that way this can also be done in a per message basis, but can only be done on vehicles that are nearby. 17:25.300 --> 17:31.540 And by nearby, I mean in line of sight, because radars, cameras can only work in line of sight, but not in non-line of sight. 17:32.120 --> 17:42.320 Similarly, we look at the RF, we compare the position, the direction, the velocity, we look at the consistency on the RF side as well as on the V2X side. 17:42.920 --> 17:46.480 And then we would also look at map data. 17:46.480 --> 17:49.680 So we look at the consistency with the map data we had. 17:50.220 --> 18:00.500 If a car, for example, has a position that goes through buildings, that is not really a lane that we know about. 18:00.540 --> 18:13.580 So we would really like to see, okay, is the information coming in the V2X message, does that correlate with what we have in the map data? 18:13.660 --> 18:18.940 And then we look at consistency between the senders' messages. 18:18.940 --> 18:36.160 So consistency within the message itself from a sender, like if the brake status, for example, if the brake status is not consistent with deceleration between the messages, like if the brake is applied, is the acceleration negative? 18:36.160 --> 18:37.920 Is the vehicle really decelerating? 18:37.960 --> 18:43.640 So that is one example we look at, is the position, speed, and acceleration, is that consistent with each other? 18:43.640 --> 18:44.960 So that is one more thing. 18:44.960 --> 18:50.540 And there are many more things that we can look at in a VSM or a CAM message. 18:51.580 --> 18:55.920 Then we look at consistency with other vehicles' messages. 18:55.920 --> 19:14.000 So for example, if you have multiple vehicles going on a highway, and you look at one-way traffic, all the vehicles are heading towards this one direction, and one vehicle is coming directly in the opposite direction. 19:14.000 --> 19:16.620 So that is a possible misbehavior. 19:17.140 --> 19:25.240 It can be that there is some crazy driver who is coming on this direction, but it is really highly unlikely, and we consider that as a misbehavior. 19:25.240 --> 19:33.600 Or we look at, that is one example, but in general terms, we look at the trajectory that is implied by one car and match it with others. 19:33.740 --> 19:41.540 Like for speed, for example, the speed of vehicles should almost be similar on a highway scenario as well. 19:41.540 --> 19:43.120 So we look at that as well. 19:43.870 --> 19:46.800 Now, this is how we detect. 19:47.060 --> 19:51.240 And now talking about the fun part, how do you attack all of this? 19:51.700 --> 20:09.280 So what we do is we look at how an attacker will go about attacking the misbehavior system or the B2X system as a whole on the receiver. 20:09.280 --> 20:20.860 So the attacker could attack the security layer, he could attack on the L1, L2 layer, that physical MAC layer, that is, he could perform some attacks on the spectrum, or he could attack on the application layer as well. 20:20.920 --> 20:25.220 So for example, on security layer, what he can do, he can send outdated messages. 20:25.220 --> 20:31.160 That means the generation time of the message is too far behind, but you're still receiving that message now. 20:31.160 --> 20:36.560 So that is kind of an attack, that is kind of a message that you shouldn't have really received. 20:37.000 --> 20:47.660 And then the other attack is that the vehicle could just send unsigned BSMs and you just receive those messages, you say, oh, this is not authenticated, you drop that. 20:47.980 --> 21:08.900 Then to counter an outdated B2X message attack, the attacker could forward the generation time in the BSMs and you could keep that current to actually try to circumvent the old message check that can be performed on the security layer. 21:08.900 --> 21:25.080 The attacker could also send a message without a certificate to invoke no certificate check, he could also send an expired certificate, he could incorrectly sign a message, and then he could be inconsistent on the channel as well during transmission. 21:25.080 --> 21:34.880 Now, all of these attacks on the security layer, what they could do is they can starve the receiver of resources, of processing power. 21:34.920 --> 21:58.040 So even though all these messages are false and they raise all these concerns, the receiver could already lose processing any BSM that is from a legitimate vehicle and possibly not react to any real incident that might happen in front of it. 21:58.140 --> 22:13.300 So similarly, you look at coming to spectrum misbehavior on the physical and math layer, the attacker could, as we see in any wireless communication, could just jam the signal with the blast energy of the channel and the receiver cannot hear anything. 22:13.400 --> 22:15.280 Then he could also perform a DOS attack. 22:15.280 --> 22:17.920 For example, he can send only preambles. 22:17.920 --> 22:26.820 He can just say, oh, my message length is this much and does not send the message, which is a truncate after preamble attack that we have heard about recently. 22:27.220 --> 22:42.080 And a lot of wireless communication standards actually ask the receiver to wait for a certain period of time after the counter to wait for the message so that they can read the message during that time. 22:42.080 --> 22:43.820 So the attacker actually... 22:43.820 --> 22:49.280 So the receiver just waits and does not process any other messages coming in. 22:49.280 --> 22:52.520 So that can be a DOS attack that the attacker could perform. 22:53.300 --> 23:08.860 And then the attacker could change his MAC address so that if you filter MAC, according to, if you recognize an attacker's MAC address, if I get any message with this MAC address, I'm going to filter any messages coming from this guy. 23:08.860 --> 23:12.080 He can change that MAC address and still pass your filter. 23:12.240 --> 23:20.680 Coming to the application layer, the attacker could just fuzz all the fields, like we do in all... 23:25.460 --> 23:28.640 like we do in testing any mechanism. 23:28.640 --> 23:40.020 The attacker could just say, oh, I'm sending a speed of minus infinity to infinity and I want to see how does the way, does the receiver really accept those messages? 23:40.340 --> 23:47.960 Or what kind of behavior does the vehicle show me if I send such messages? 23:47.960 --> 23:57.120 And as Jonathan showed about civil attack, the way we could change MAC addresses, use the same certificate or different certificates and create those vehicles. 23:57.120 --> 24:05.340 And then lastly, the attacker could formulate specific messages to fool V2X applications. 24:05.400 --> 24:13.680 And we're going to talk about this in detail now with an example of the EBL application in the next couple of slides. 24:18.790 --> 24:31.810 So here you can see that there are two cars here, the blue one we consider as the victim vehicle, the benign vehicle, and the dark gray car is the attacker. 24:31.810 --> 24:39.030 Now the attacker formulates a normal BSM, which is marked all as green, where all the fields of the BSM are consistent with each other. 24:39.030 --> 24:41.790 You have position, you have speed, you have positive acceleration. 24:41.790 --> 24:45.330 You don't have any braking, you don't have any EBL flag set. 24:45.330 --> 24:54.950 The EBL flag is the flag that has to be set for the EBL application to actually react to a heartbreaking event. 24:54.950 --> 25:06.970 So whenever a vehicle, if it is hit and it is heartbreaking, the EBL flag is set and the receiver, whenever it receives the EBL application, sees that flag first and then checks other things. 25:07.230 --> 25:18.010 So here, the attacker at first just transfers a normal BSM, our benign vehicle receives that message and says, oh, it's a normal car, goes about on its way. 25:18.250 --> 25:21.830 And then now our attacker says, okay, now I'm going to start my attack. 25:21.830 --> 25:26.550 And now the attacker puts the EBL flag as one. 25:26.650 --> 25:30.710 And you can see that he has not changed all of the fields. 25:30.730 --> 25:34.270 So the brake is zero and the acceleration is also positive. 25:34.270 --> 25:36.030 This should not really be the case. 25:36.030 --> 25:48.470 But if you don't have any misbehavior detection, the benign vehicle, when it receives this message, it says, oh, it's a heartbreaking event, I should brake, it's safety critical to me or I might crash into the vehicle. 25:48.530 --> 25:52.470 And our attacker goes about his way ahead. 25:53.610 --> 26:04.810 So at this point, our vehicle maybe looks at, maybe he doesn't see any car in the vehicle space after a while. 26:04.810 --> 26:12.070 And like, oh, okay, there was no car in the vehicle space, neither physically in front of me. 26:12.070 --> 26:14.370 So I should just continue my motion. 26:14.370 --> 26:16.670 Maybe my EBL application was good. 26:16.670 --> 26:19.270 So this is what is the attack that we consider. 26:19.270 --> 26:32.270 And here we assume that the benign vehicle doesn't use his sensors like camera or radar in this example to verify messages. 26:33.330 --> 26:36.050 So how would you detect such kind of an attack? 26:36.050 --> 26:50.250 So firstly, as it might be apparent that you look at the inconsistency within the BSMPs and you say, oh, okay, so there's an inconsistency, it is possible that this message is wrong. 26:50.390 --> 26:53.470 And you can also check the telemetry of the attacker. 26:53.470 --> 27:15.370 So if the attacker, after an EBL, you would expect that the vehicle would stop, but if the vehicle continues to change its positions and has a positive speed and the vehicle keeps on moving, meaning it doesn't have any change between the telemetry that was before the attack or after the attack, 27:15.370 --> 27:19.150 that is another indication where how you could detect such kind of an attack. 27:19.750 --> 27:24.910 Now we talk about fake EBL version two attack, where our attacker has gotten smarter. 27:24.910 --> 27:27.730 He's like, okay, you check for both of those things. 27:27.730 --> 27:32.550 You check for inconsistency and you check for my telemetry. 27:32.550 --> 27:34.350 So I'm going to become smarter. 27:34.470 --> 27:39.990 Again, the attacker transmits a normal BSM, goes about his way, the benign vehicle follows it. 27:39.990 --> 27:42.750 Now he transmits 27:50.010 --> 27:57.850 a fake EBL message, formulated specifically to counter the detection in the first version. 27:57.870 --> 28:04.290 You can see that the EBL flag is set as one, the brake is also set as one and the acceleration is also negative. 28:04.370 --> 28:14.290 So when our benign vehicle receives this, his detectors don't give him any indication and this vehicle just sees, oh, okay, this is a heartbreaking event. 28:14.350 --> 28:18.190 And the attacker also stops in the V2X space. 28:18.190 --> 28:21.350 The attacker moves physically, but stops in the V2X space. 28:21.530 --> 28:24.170 So our benign vehicle sees, oh, there is a vehicle stopped. 28:24.170 --> 28:26.110 So the telemetry has changed as well. 28:26.110 --> 28:27.390 So I should brake. 28:27.650 --> 28:32.950 The victim vehicle brakes in this case and does not continue motion. 28:33.690 --> 28:36.210 So this is an improvement on the attack. 28:36.210 --> 28:38.510 Now, how would you detect this kind of an attack? 28:41.310 --> 28:46.170 We have looked at all the application layer side of things in the previous checks. 28:46.170 --> 28:51.450 Now we look at the physical layer side of things, where we look at the signal strength versus the distance. 28:51.450 --> 28:59.530 So as you can see on the graph on the bottom right section, on the X-axis, you have the distance and on the Y-axis, you have the signal strength. 28:59.950 --> 29:11.550 And what we have seen is that the signal strength should reduce as the distance increases between any two vehicles in this kind of a graph. 29:11.990 --> 29:27.370 But in this case, if the attacker is sending constant positions in front of you, but is actually physically changing his positions, his characteristics would look something like the red line you see. 29:27.370 --> 29:30.530 The distance is the same, but the signal strength keeps reducing. 29:30.530 --> 29:38.470 So this is how you could actually find out genuine vehicles versus an attack vehicle in such cases. 29:39.150 --> 29:45.730 Now our attacker thinks, okay, now you remember me and I'm going to try to circumvent this. 29:45.730 --> 29:51.630 So we have a version three attack that the attacker could perform as well. 29:53.190 --> 29:57.330 So here the attacker again, transmits a normal DSM. 29:57.630 --> 30:08.030 And now he again, you know, formulates a fake email message with all the fields consistent and transmit that message over our way to receive it. 30:08.030 --> 30:14.810 The attacker stops in vehicle space, transmits constant positions after the attack, but continues physically, right? 30:14.810 --> 30:17.910 So our victim vehicle again stops. 30:17.910 --> 30:19.890 It's just like the version two attack. 30:19.890 --> 30:26.550 But now what the attacker does is that the attacker goes into a silent period. 30:26.550 --> 30:35.190 So the attacker would go into a silent period here where it would stop transmitting any DSMs. 30:35.190 --> 30:50.130 So to conserve the storage space in the benign vehicle, the benign vehicle would check its database, like, oh, I have, how far, have I received any BSM recently from this vehicle, from this attack, from this attacker? 30:50.130 --> 30:53.490 And you would say, no, it has been a long time since I have not received it. 30:53.490 --> 30:54.330 Let's say five seconds. 30:54.330 --> 30:57.570 Five seconds is also a long time in a real-time system. 30:57.890 --> 31:06.070 And we assume that the benign vehicle just deletes all the information just to conserve its storage space. 31:06.350 --> 31:10.830 And now he doesn't see any vehicle anyways in front of it. 31:10.830 --> 31:14.150 So it starts continuing its motion in the V2X space. 31:14.150 --> 31:18.370 It doesn't see any vehicle, so it starts continuing its motion in the physical space as well. 31:18.370 --> 31:22.450 Now the attacker, he says, okay, now you have forgotten about me. 31:22.450 --> 31:28.050 He waits for this vehicle ahead, like it slows down or something, and performs the same attack. 31:28.250 --> 31:37.950 Now, since our benign vehicle doesn't have any history on this attacker, since he deleted this earlier, it would fall for the same attack again. 31:37.950 --> 31:44.630 That is what we think an improved attacker would do. 31:44.770 --> 31:45.690 And how would you detect? 31:45.690 --> 31:59.370 You would, of course, again, look at the physical properties of this kind of an attack, and possibly remember these kinds of vehicles who kind of were not, that you were not sure about, that, okay, maybe this vehicle was malicious. 31:59.370 --> 32:06.990 So you try to remember more, remember such kind of vehicles for a longer time to detect, to have history on them. 32:06.990 --> 32:21.810 So that if you have a random jump like this in the V2X space, that this gray vehicle here, the vehicle in the V2X space, jumped from back to here, you can say that this is a random jump, and this is possibly a mistake. 32:23.690 --> 32:48.690 Yes, so this is how we have formulated a cat and mouse game, where you come up with an attacker, like a red team, blue team kind of thing, where the attacker becomes smarter, we make our detector smarter, and we expand our detectors from the application layer to the physical layer, 32:48.690 --> 32:52.990 and map layer, and we expand the portfolio of all the detectors. 32:53.370 --> 33:02.650 And now we have a demo for this, that we would like to present there, where we try to simulate these attacks. 33:02.650 --> 33:07.850 And I would like to hand over the screen to my colleague, Song. 33:08.570 --> 33:09.590 Thank you, Rashid. 33:14.810 --> 33:16.570 Yeah, hello everyone. 33:16.570 --> 33:26.090 In the following demo, I will present the three attacking scenario as presented by Rashid, in order to show the progression of our attacks. 33:26.090 --> 33:30.370 So first, let's take a look at our demo setup. 33:30.370 --> 33:34.690 And this is a demo setup that we show in CES 2020. 33:34.690 --> 33:43.410 As you can see, there are two Roadrunner boards, and one HMI device, and one demo control panel. 33:43.850 --> 33:52.710 And a Roadrunner is a Qualcomm CV2x development platform, and that is equipped with Qualcomm CV2x chipset. 33:52.710 --> 33:57.090 And it is used as an onboard unit in this demo. 33:57.390 --> 34:08.630 Here you can see we have two Roadrunners, one of which is the genuine host vehicle, while the other one is the remote attacker vehicle. 34:09.270 --> 34:23.810 Since the Roadrunner can play the pre-recorded BSM files, so even though they are placed stationary, they can still transmit BSMs to each other, as if they are traveling on a real road. 34:23.810 --> 34:32.510 On the other hand, the HMI display is an Android application that will visualize the interaction between the two vehicles. 34:32.510 --> 34:35.890 And the control panel is used to control and configure our demo. 34:41.430 --> 34:45.730 So here is the control panel of our demo. 34:45.730 --> 34:54.790 And on top of the panel, you can see the option of our attack scenarios from fake EVL version one to version three. 34:54.790 --> 34:59.110 Actually, we have many more attack scenarios, but here we only show those three. 35:00.050 --> 35:12.990 And below the attack options is our misbehavior protection system status display, which will show the detection results of our misbehavior protection system. 35:13.530 --> 35:23.310 So now, let's start version one of the fake EVL explained by Rashid. 35:24.370 --> 35:37.170 In version one, the attacker generates a fake EVL warning, but keeps moving both physically as well as in the V2X space, as shown in this HMI display. 35:38.050 --> 35:49.270 So in this HMI display, as you can see, the green bubble here is the host vehicle, while the blue bubble is the remote vehicle. 35:49.270 --> 35:55.070 From the perspective of the host vehicle, based on the BSM it received. 35:55.070 --> 36:01.090 And the overlay here on the right of the display is not a vehicle. 36:01.090 --> 36:09.570 Actually, it's a dashboard for the host vehicle, which will indicate the safety warnings generated by the safety applications. 36:10.090 --> 36:12.890 Let's resume the demo. 36:12.990 --> 36:25.550 So as you can see, from the perspective of the host vehicle, both are moving normally until the host vehicle received a fake EVL warning. 36:25.610 --> 36:37.910 And this is because, just as Rashid explained, because of the inconsistency between the position field and the EVL flag in the BSMs. 36:37.910 --> 36:43.530 So you can see the blue bubble is still moving, but it transmits a fake EVL warning. 36:44.250 --> 36:54.010 However, our misbehavior protection system can easily detect this inconsistency by applying the possibility check and the consistency check. 36:54.370 --> 36:58.110 So this is a very easy attacking scenario. 36:58.110 --> 37:03.610 Of course, a smart attacker will come up with smarter attacks. 37:04.530 --> 37:12.350 Now let's look at the second one, the version two of our fake EVL attack. 37:12.350 --> 37:32.690 So in version two, explained by Rashid, the attacker will generate a fake EVL warning, but all the fields in the BSM are consistent, meaning that the attacker will move physically, but it will stop in the V2X space. 37:35.150 --> 37:36.830 Now let's switch into the... 37:37.350 --> 37:49.550 So as you can see, in this version, the blue bubble is moving normally in the beginning, but then it will stop in the V2X. 37:50.270 --> 37:56.150 As you can see here, the blue bubble indeed stopped in the V2X space. 37:56.190 --> 38:01.710 So the host vehicle, we believe, is a normal vehicle in the application layer. 38:01.790 --> 38:10.070 However, if we're applying our physical layer detector, such as the signal strength, we can detect such misbehavior. 38:10.930 --> 38:16.510 So our host vehicle can ignore this fake EVL warning and continue the motion. 38:17.130 --> 38:24.350 You can see here, our host vehicle is still moving, even though it detects this, because it detects this misbehavior. 38:26.350 --> 38:32.550 The attacker can keep finding ways to upgrade his attack, explained by Rashid. 38:32.550 --> 38:44.670 And so in version three, and the attacker, the host vehicle, the attacker will enter a silent period after performing the first fake EVL attack. 38:44.890 --> 38:54.230 And then he will disappear from the V2X space, hoping that the host vehicle will forget about him and then he will show up again. 38:54.350 --> 38:56.650 Now let's take a look at this scenario. 38:56.650 --> 39:01.150 So in the beginning, the blue bubble behaves normally. 39:02.010 --> 39:04.650 Then he will perform the fake EVL version two. 39:04.650 --> 39:13.090 As you can see, in the V2X space, but then it disappeared, hoping the host vehicle will forget about him. 39:13.090 --> 39:18.990 Now, after the silent period, it shows up again and then perform the attack again. 39:19.910 --> 39:27.870 So again, this attack can also be detected using the physical layer detectors just introduced by Rashid. 39:32.990 --> 39:33.890 Okay. 39:34.390 --> 39:45.610 So as the demo shows that a smart attacker can always find ways to create smarter attacks as our detection algorithm evolves. 39:45.610 --> 39:54.630 For example, we showed that using the physical layer, we can detect the fake EVL attack version two and version three. 39:54.630 --> 40:04.730 However, a smart attacker may circumvent our detector by, for example, matching the signal strengths with valid distribution. 40:04.730 --> 40:10.130 Valid signal strength distribution by adjusting the transmission power. 40:10.270 --> 40:22.970 And other cases, attacker can use different MAC address and pseudonym certificates to perform a stable attack as introduced previously to fool the majority based detector. 40:22.970 --> 40:31.050 And actually there are many more ways that attacker can progress to perform more advanced attacks. 40:31.050 --> 40:42.730 However, by improving our detection system, we are able to squeeze the attacker to the corner and raise the bar and the cost of the successful attack. 40:42.730 --> 40:49.590 And on the other hand, the progression of the attack can push for a stronger and more robust detection system. 40:50.390 --> 40:51.730 Thank you. 40:59.800 --> 41:01.020 Thank you, Rashid. 41:01.020 --> 41:05.680 So we are coming to the conclusion of this talk. 41:05.680 --> 41:16.360 So what we showed you today is why, what is misbehavior, first of all, in V2X and give you many examples. 41:16.540 --> 41:23.540 And then we even went through this misbehavior life cycle, detection, local reaction, reporting, investigation, global reaction. 41:23.820 --> 41:27.500 And then we demonstrated the progression of an attack. 41:27.500 --> 41:30.220 What does the attacker do to be smarter and smarter? 41:30.220 --> 41:32.840 What would you test when you want to attack the system? 41:33.300 --> 41:36.880 So, and we'll give you a demo of this working on real onboard unit. 41:37.140 --> 41:46.080 So as a conclusion, really we understand why misbehavior protection is super important for more secure V2X deployment. 41:46.080 --> 41:49.360 You need to have it, otherwise authentication isn't sufficient. 41:49.360 --> 41:50.440 You will see this big data. 41:50.440 --> 41:52.980 You need to be able to analyze it and detect it. 41:52.980 --> 41:59.100 But what's good is that misbehavior detection, reporting, investigation, reaction are all being standardized right now. 41:59.100 --> 42:08.140 So we hope that then really we're going to raise that bar on making it harder for an attacker and all have at least minimum performance in terms of detection. 42:08.280 --> 42:17.740 And also what is really positive is that misbehavior protection solutions exist and have been deployed in, for example, one in the connected vehicle part of deployment. 42:17.860 --> 42:23.140 So this is positive, you know, it's there, we are ahead of the curve, basically. 42:23.380 --> 42:29.820 But as we've seen, the attacker is always smarter and will try to counter what you do. 42:29.820 --> 42:34.940 So we still have a lot of open challenges and I really just like to give you three examples here. 42:34.960 --> 42:46.800 The first one is, if you are using a machine learning based detector, therefore an attacker will use a visual example, a visual machine learning to fool your detection algorithm. 42:46.800 --> 42:51.740 So this is a really active field right now to look at visual machine learning. 42:51.860 --> 42:54.500 And so therefore, if you're based on that, you need to look at it. 42:55.760 --> 43:02.420 This is still a highly sophisticated level of attack, but it is a matter of time before it's making it easier to be there. 43:02.460 --> 43:07.660 The second part is that we've shown today only the detection, the attacks on the first step. 43:07.660 --> 43:12.160 So you need to investigate the attack on the reporting, investigation and a global reaction. 43:12.200 --> 43:14.240 What could you do on those different stages? 43:14.840 --> 43:23.040 And finally, don't forget that V2X will be part of an automated vehicle and therefore will be fused with other sensors. 43:23.040 --> 43:33.060 So you need to analyze the effect of V2X attack on the sensor fusion to understand how much inconsistency and insensitivity can you create just from the V2X standpoint. 43:33.520 --> 43:38.140 With that, this is the end of our presentation and we'll be happy to take questions. 43:38.140 --> 43:39.020 Thank you.