[00:03.430 --> 00:05.950] Good day, DEF CON and Car Hacking Village. [00:05.950 --> 00:07.630] I am Jonathan Petit, [00:07.630 --> 00:09.490] and I'm here with two of my colleagues, [00:09.490 --> 00:11.550] Rashid Ansari and Kong Chen. [00:11.550 --> 00:14.310] We are the research team for Qualcomm [00:14.310 --> 00:17.430] working on connected and automated vehicle security. [00:18.150 --> 00:21.330] Today, we're going to talk about misbehavior detection [00:21.330 --> 00:26.730] and demonstrating you some attacks on VLAN board unit. [00:27.010 --> 00:29.270] So before we start, I think it is important [00:29.270 --> 00:32.230] that we understand what is V2X communication. [00:32.230 --> 00:37.150] So V2X enable devices like vehicles, [00:37.150 --> 00:39.690] pedestrians or roadside unit to be equipped [00:39.690 --> 00:42.970] with an onboard unit, a device that enables [00:42.970 --> 00:47.050] all of those components to broadcast information [00:47.050 --> 00:50.070] in the surrounding to create an awareness. [00:50.330 --> 00:54.750] So in this example, we have three cars [00:54.750 --> 00:57.850] and are all equipped with V2X technology. [00:58.190 --> 01:00.490] And we'll see that now the white car [01:00.490 --> 01:02.530] is performing an emergency brake. [01:02.890 --> 01:04.370] Therefore, because the onboard unit [01:04.370 --> 01:06.110] is connected to the CAN bus, [01:06.110 --> 01:08.490] it can detect that there is a high deceleration, [01:08.490 --> 01:11.010] for example, and that in the brake pressure, [01:11.010 --> 01:13.490] and therefore we'll be able to generate a message [01:13.490 --> 01:16.390] that he's sending to the surrounding vehicle. [01:17.150 --> 01:19.750] So those messages are called basic safety message [01:19.750 --> 01:21.550] here in the US, so that's the BSM [01:21.550 --> 01:23.750] that we're going to talk about in this talk. [01:24.390 --> 01:27.210] When the vehicle receive a BSM, [01:27.210 --> 01:29.270] they are able to understand that the white car [01:29.270 --> 01:30.910] is performing an emergency brake, [01:30.910 --> 01:33.290] and therefore themselves brake, [01:33.290 --> 01:35.070] avoiding a chain of collision. [01:35.130 --> 01:38.030] So we see the huge benefit, safety benefit, [01:38.030 --> 01:41.890] especially in that V2V use case that we are showing you. [01:41.890 --> 01:45.370] This is an emergency electronic brake light application, [01:45.370 --> 01:48.770] and it's consuming BSM sent by other vehicle [01:48.770 --> 01:51.350] to understand an emergency brake is happening. [01:51.430 --> 01:53.950] So there is many application for safety [01:53.950 --> 01:56.330] 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:03.130] So then, of course, we understand [02:03.130 --> 02:04.650] that from a security standpoint, [02:05.010 --> 02:07.730] we do not want external attacker [02:07.730 --> 02:12.030] to be able to send bad messages to the other vehicles. [02:12.030 --> 02:14.430] So all the messages that are sent [02:14.430 --> 02:16.330] are actually digitally signed. [02:16.330 --> 02:18.870] So in the same example we just showed before, [02:18.870 --> 02:21.890] now we have the white car is actually signing [02:21.890 --> 02:24.890] with this private key, attaching a certificate, [02:25.210 --> 02:27.090] the message before sending it. [02:27.090 --> 02:31.390] The receiver will use the keys in order to verify [02:31.990 --> 02:34.890] that this is sent by an authenticated vehicle. [02:35.210 --> 02:36.350] Good. [02:36.610 --> 02:39.410] But as you might imagine, [02:39.410 --> 02:43.370] 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:50.230] So here in our same example, [02:50.230 --> 02:52.010] we have here the white car is an attacker, [02:52.010 --> 02:55.270] 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:01.530] Therefore, they have to use a content [03:01.530 --> 03:03.990] which says it is an emergency brake. [03:04.310 --> 03:07.490] Here in the animation you just saw here, [03:07.490 --> 03:08.990] the blue car didn't stop. [03:08.990 --> 03:10.010] And you might wonder why. [03:10.010 --> 03:11.410] It's because we can make an assumption [03:11.410 --> 03:15.350] that this vehicle was equipped or is equipped with a camera [03:15.350 --> 03:17.890] and therefore didn't see the white car braking. [03:18.190 --> 03:20.570] But the red car has no line of sight [03:20.570 --> 03:22.970] and therefore has to trust that information. [03:23.550 --> 03:24.870] So we clearly understand [03:24.870 --> 03:27.990] and you need a misbehavior protection system [03:27.990 --> 03:30.310] to defend against such attacks. [03:30.370 --> 03:33.330] And this is one we're going to present today [03:33.330 --> 03:37.090] is really about the attacks and how you perform this [03:37.090 --> 03:39.670] and how you protect against this. [03:40.070 --> 03:42.610] So let me show you a little bit [03:42.610 --> 03:45.770] on our example about misbehavior. [03:46.150 --> 03:48.970] Here on the left-hand side, [03:48.970 --> 03:52.570] this is an application called intelligent signaling. [03:52.830 --> 03:54.870] This is where you have a traffic light [03:54.870 --> 03:56.530] equipped with a roadside unit [03:56.530 --> 03:58.110] with the same kind of equipment [03:58.110 --> 04:00.730] to receive the message sent by the vehicle. [04:01.570 --> 04:03.630] And by reading the BSM, [04:03.630 --> 04:07.590] it adjusts the signal phase and time. [04:07.590 --> 04:09.850] Therefore, it's going to play with the red and green [04:09.850 --> 04:12.710] on this different segment coming at the intersection. [04:13.490 --> 04:16.710] And an attack that was demonstrated by some researcher [04:17.650 --> 04:22.690] showed that if the vehicles are sending wrong BSMs, [04:22.690 --> 04:24.070] I'm going to just run the video here, [04:24.070 --> 04:26.670] if you send that, and after 30 minutes of attack, [04:26.670 --> 04:30.850] you can see this long line at each of two, [04:30.850 --> 04:32.530] or actually three intersections, [04:32.530 --> 04:34.070] three segment of the intersection. [04:34.070 --> 04:37.310] So an application that consumed a BSM that is fake, [04:37.310 --> 04:39.490] even though it's purely authenticated, [04:39.490 --> 04:43.530] if you do not do a misbehavior analysis protection, [04:43.530 --> 04:46.690] you might see issues like this in intelligent signaling. [04:47.890 --> 04:50.650] Now looking on the right-hand side, [04:50.650 --> 04:53.070] we have a position jump attack. [04:53.290 --> 04:56.670] So the position here in that representation, [04:56.670 --> 05:00.110] you are, the ego vehicle is the green dot. [05:00.110 --> 05:04.670] You're driving and an attacker is sending messages [05:05.370 --> 05:08.650] with the same identifier, but he's jumping, [05:08.650 --> 05:09.690] he's changing his position. [05:09.690 --> 05:11.190] That's where you see this blue dot, [05:11.190 --> 05:13.090] this is the BSM received. [05:13.090 --> 05:15.150] And it's flickering because it's actually jumping [05:15.150 --> 05:16.670] back and forth. [05:16.770 --> 05:20.150] And sometimes outside of the frame here that you can see, [05:20.150 --> 05:21.830] 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:26.230] And what is interesting, [05:26.230 --> 05:29.810] as you're going to hear this sound in a few seconds, [05:30.530 --> 05:33.070] is that sometimes this is performing here [05:33.250 --> 05:34.750] a forward collision warning. [05:34.750 --> 05:37.210] So even though this was a position jump, [05:37.210 --> 05:41.090] 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:04.330] And all the other blocks that you see, [06:04.330 --> 06:06.230] the blue and orange one, [06:06.230 --> 06:09.830] are the vehicles also sent by the V2X message. [06:09.830 --> 06:11.890] So you're going to represent this local dynamic map [06:11.890 --> 06:13.390] 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:19.430] Because part of the BESM, [06:19.430 --> 06:20.770] there is the position, [06:20.770 --> 06:22.950] there is your kinematic states, your velocity, [06:22.950 --> 06:24.570] but also you have the headings [06:24.570 --> 06:28.490] that helps pass planning, for example. [06:28.490 --> 06:30.650] To know where is this car going? [06:30.650 --> 06:32.470] Especially when you perform pass prediction [06:32.470 --> 06:33.630] when you're using Kalman filter. [06:33.630 --> 06:35.190] You want to use that heading. [06:35.490 --> 06:38.010] And here, in this specific example, [06:38.010 --> 06:39.810] 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:44.710] So now your system that consumed the BESM [06:44.710 --> 06:45.790] to perform pass planning [06:45.790 --> 06:49.210] 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:54.610] So this is where an attacker [06:54.610 --> 06:58.810] 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:04.490] And for example, you'll be using your 20 or 19, [07:04.490 --> 07:05.830] depends if you want to use yours, [07:05.830 --> 07:06.730] and you send your 19 [07:06.730 --> 07:10.190] 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:16.710] So that is what happens when you map [07:16.710 --> 07:18.370] all the BESM you receive [07:18.370 --> 07:21.850] and put them on this virtual view. [07:22.130 --> 07:25.530] It is really hard for the connected [07:25.530 --> 07:27.230] and even automated vehicle in the future [07:27.230 --> 07:30.710] 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:37.090] This is where an attacker is actually overlapping [07:37.090 --> 07:38.330] 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:45.590] And those are just a couple of example [07:45.590 --> 07:47.270] about what we call misbehavior [07:47.830 --> 07:49.910] that are all authenticated messages, [07:49.910 --> 07:51.310] but the content is wrong. [07:54.330 --> 07:57.650] So when we look at V2X misbehavior, [07:57.650 --> 08:00.050] there's what we call a misbehavior life cycle. [08:00.170 --> 08:02.630] So you receive those V2X messages, [08:02.630 --> 08:05.010] and here we gave example about basic safety message [08:05.010 --> 08:07.370] because they are the one commonly frequently sent [08:07.370 --> 08:11.310] 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:22.570] The goals are to validate the position of the sender, [08:22.570 --> 08:26.550] his motion, its motion, and the presence. [08:27.870 --> 08:30.550] To do that, you can also, [08:30.550 --> 08:33.190] you have to look at the application content. [08:33.190 --> 08:34.650] So the application layer content, [08:34.650 --> 08:37.610] meaning you look at the content of the message itself. [08:37.750 --> 08:39.290] You will look at a different field, [08:39.290 --> 08:42.770] are they plausible, are they actually consistent? [08:43.870 --> 08:46.830] But one important thing is that you need to understand [08:47.510 --> 08:49.890] the effect on the V2X application [08:49.890 --> 08:52.370] that is consuming that ESM. [08:52.570 --> 08:54.930] Because not all messages are actually triggering [08:55.530 --> 08:57.030] an application event. [08:57.030 --> 08:59.990] In our case of the EEBL that we showed earlier, [09:01.830 --> 09:04.650] you will perform an EEBL, [09:04.650 --> 09:07.970] so perform yourself a heart breaking or warning the user [09:07.970 --> 09:10.610] only if the vehicle is ahead of you [09:11.290 --> 09:13.530] with a sudden deceleration, for example, [09:13.530 --> 09:16.310] and a brake status flag at one. [09:16.950 --> 09:19.810] So I could be sending wrong messages, [09:19.810 --> 09:21.350] but I'm not ahead of you, [09:21.350 --> 09:25.510] and therefore it will not trigger the V2X application. [09:25.510 --> 09:27.270] So it is important to understand that [09:27.270 --> 09:28.850] because not all messages are equal [09:28.850 --> 09:30.970] and therefore should be investigated. [09:31.410 --> 09:34.730] As we're going to demonstrate in the demo later, [09:34.730 --> 09:38.190] it is really also important to look at the lower layer [09:38.190 --> 09:39.690] of the IETF stack. [09:39.690 --> 09:41.250] I'm going to give you an example [09:41.250 --> 09:45.050] where you can use signal strengths of the signal [09:45.050 --> 09:47.630] to really identify the position [09:48.230 --> 09:51.150] or the presence of another vehicle. [09:52.050 --> 09:54.310] So, but then really finally, [09:54.310 --> 09:55.970] when you build a detection system, [09:55.970 --> 09:57.930] you need to have a timely detection. [09:58.170 --> 09:59.570] You want a real time detection [09:59.570 --> 10:02.350] because this is a safety of life application. [10:02.350 --> 10:05.050] This is the information is useful to, [10:05.050 --> 10:07.670] 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:13.770] You cannot afford to wait the whole chain [10:14.390 --> 10:16.270] until the global reaction. [10:17.330 --> 10:21.530] And you have to do this, so in real time, if possible, [10:21.530 --> 10:26.090] and with high accuracy, and that's the performance part [10:26.090 --> 10:29.210] where in some cases, our case, for example, [10:29.210 --> 10:31.350] we want to favor recall over precision [10:31.970 --> 10:33.650] because it is important to capture [10:34.450 --> 10:36.090] as much attack as possible [10:36.090 --> 10:38.970] and really precise only on one attack. [10:39.250 --> 10:40.910] So, but that will depend on your system [10:40.910 --> 10:43.690] and your use case and what you will consider. [10:43.690 --> 10:45.430] So this is everything you need to consider [10:45.430 --> 10:48.370] when you want to build a detection system. [10:49.130 --> 10:50.990] As soon as you've detected, [10:50.990 --> 10:52.450] it's not just enough to detect [10:52.450 --> 10:54.350] and give it to the application. [10:54.350 --> 10:56.430] You need to perform a local reaction. [10:57.290 --> 10:59.970] And two example about what could happen locally [10:59.970 --> 11:03.150] on your vehicle is to dismiss the further messages [11:03.150 --> 11:05.050] from the same identifier. [11:06.190 --> 11:08.710] But as we know, there is privacy by design in V2X, [11:08.710 --> 11:13.570] which means that we, each vehicle are using pseudonyms [11:13.570 --> 11:17.050] 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:20.990] If you dismiss that, [11:20.990 --> 11:23.850] the same standard will simply change identifier. [11:24.010 --> 11:25.630] It's still a question here. [11:25.690 --> 11:27.950] Another reaction that we do locally [11:27.950 --> 11:30.130] is to adjust your kinematic state. [11:30.130 --> 11:33.170] So you will perform potentially a graceful degradation. [11:33.450 --> 11:35.530] Let's say that you are in a platoon of vehicle, [11:35.530 --> 11:36.810] of connected vehicle, [11:36.810 --> 11:39.210] where you use those BSTEM to know that the vehicle is ahead [11:39.210 --> 11:42.410] and agree on the inter-vehicle distance. [11:43.190 --> 11:44.830] And now you detect that in that platoon, [11:44.830 --> 11:45.990] there is a misbehavior. [11:46.270 --> 11:47.970] You better actually say, [11:47.970 --> 11:49.950] oh, let me leave the platoon [11:49.950 --> 11:52.250] or degrade and say, [11:52.250 --> 11:55.850] if this was a level four autonomous vehicle, [11:55.850 --> 11:57.630] for example, you want to go a level three, [11:57.630 --> 11:59.370] you want to go back to the driver, [11:59.370 --> 12:00.750] or you want to warn the driver. [12:00.750 --> 12:04.390] So it is important to think in terms of the cyberspace, [12:04.390 --> 12:05.450] dismissing the further message [12:05.450 --> 12:08.130] and also on the physical space, what do you do? [12:09.890 --> 12:12.070] Then also, when you do your detection, [12:12.070 --> 12:15.050] you will perform, you will generate a report. [12:15.050 --> 12:16.490] That's the reporting phase. [12:16.490 --> 12:19.810] So here, depending on the type of misbehavior, [12:19.810 --> 12:22.670] you will have different type of misbehavior report. [12:22.930 --> 12:24.950] And this is currently under standardization [12:24.950 --> 12:28.150] 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:33.610] And this report is important [12:34.190 --> 12:36.210] because it is sent to encrypted [12:36.930 --> 12:39.650] and sent to the MA, the Misbehavior Authority. [12:39.650 --> 12:42.930] It is a component part of the PKI for, [12:42.930 --> 12:44.890] and in our case, the SCMS. [12:45.440 --> 12:47.090] The Misbehavior Authority, [12:47.090 --> 12:50.570] receive all the misbehavior report from different vehicles, [12:50.570 --> 12:52.590] aggregate those misbehavior report. [12:52.670 --> 12:57.150] And it is the only one that can actually link [12:57.850 --> 13:01.190] this different pseudonym to the same device [13:01.190 --> 13:03.290] by actually a process of talking [13:03.290 --> 13:06.330] to the other SCMS component, PKI component. [13:06.630 --> 13:08.590] And this is how, for example, [13:08.590 --> 13:10.650] they could detect a Sybil attack [13:10.650 --> 13:12.990] because they will know that all those devices [13:12.990 --> 13:14.550] are linked to the same pseudonym. [13:15.090 --> 13:16.490] So that is an example [13:16.490 --> 13:18.710] 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:26.070] In cyberspace, this is a revocation, [13:26.070 --> 13:28.290] for example, of the enrollment certificate. [13:28.410 --> 13:30.010] If you cannot revoke, [13:30.010 --> 13:32.410] as it is the case currently in Europe, [13:32.410 --> 13:33.910] you just block the generation [13:33.910 --> 13:37.310] of future pseudonym certificate for that vehicle. [13:37.310 --> 13:38.350] And then you will put that on, [13:38.350 --> 13:39.630] for example, in the US, [13:39.630 --> 13:40.710] we put that on the CRL, [13:40.710 --> 13:42.330] the Certification of Location List, [13:42.330 --> 13:43.810] that is then provided to all vehicles [13:43.810 --> 13:46.810] so that they can dismiss immediately the message. [13:47.870 --> 13:49.330] But something that isn't discussed yet [13:49.330 --> 13:51.710] is really what happened in the physical space. [13:52.010 --> 13:53.430] You could, for example, [13:53.430 --> 13:56.470] inform the owner of the vehicle, of the device, [13:56.470 --> 13:58.870] and to perform an inspection, to repair, [13:58.870 --> 14:00.710] and therefore to perform a re-enrollment [14:00.710 --> 14:03.070] into the system in a secure location. [14:03.530 --> 14:05.290] Or maybe why not performing [14:05.790 --> 14:07.370] a remote vehicle immobilization? [14:07.370 --> 14:09.870] For now, you are stopping the vehicle where it is [14:09.870 --> 14:11.950] because that's been a misbehavior. [14:11.950 --> 14:14.050] Of course, this remote vehicle immobilization [14:14.510 --> 14:15.270] could be problematic [14:15.270 --> 14:16.930] if this is coming from a faulty sensor [14:16.930 --> 14:19.170] and not a real malicious attacks. [14:19.770 --> 14:21.190] But you know what we are saying, [14:21.190 --> 14:22.950] it's like there's a need of cyber reaction [14:22.950 --> 14:25.190] and physical space also reaction. [14:25.370 --> 14:27.630] So this is the whole misbehavior lifecycle. [14:27.990 --> 14:30.650] And as we can definitely see it, [14:30.650 --> 14:34.590] as an attacker, if I fool the detection part, [14:34.590 --> 14:35.930] you will never report me, [14:35.930 --> 14:37.150] you will never react to it, [14:37.150 --> 14:38.350] you will know no investigation [14:38.350 --> 14:40.270] and no verbal reaction. [14:40.270 --> 14:41.890] Therefore for this presentation, [14:41.890 --> 14:43.370] we're going to focus on this part [14:43.370 --> 14:48.290] 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:53.350] So where are we going to start [14:53.350 --> 14:56.170] 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:01.050] I'm going to take over to talk to you [15:01.050 --> 15:02.790] 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:35.060] So as Jonathan talked about the detection portion [15:35.060 --> 15:39.080] of misbehavior detection system. [15:39.220 --> 15:43.500] So this slide shows you all the possible ways [15:43.500 --> 15:49.340] that we look at right now to detect any attack. [15:49.340 --> 15:52.520] So any attack on the application [15:52.520 --> 15:58.100] or on the physical layer, [15:58.120 --> 15:59.620] or anything. [15:59.620 --> 16:04.180] So let's go over what we do about, [16:04.180 --> 16:07.080] how we go about checking all the, [16:09.040 --> 16:12.500] checking everything in the V2X space here. [16:12.500 --> 16:15.880] So first we look at basic plausibility checks, [16:15.880 --> 16:18.500] where we look at if the speed or angle [16:18.500 --> 16:23.560] or acceleration in a BSM or a CAM message is unrealistic. [16:23.560 --> 16:26.460] Is it too high or is the turning angle [16:26.460 --> 16:28.360] too much as the vehicle? [16:28.360 --> 16:31.000] As you saw in the heading change example, [16:31.000 --> 16:33.920] 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:40.860] And that's how, [16:40.860 --> 16:45.020] and you don't need a chain of messages for this. [16:45.840 --> 16:48.000] So an attack can be detected [16:48.000 --> 16:51.100] 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 --> 16:57.980] So we look at whatever messages we are getting, [16:57.980 --> 16:59.760] like whatever speed you're getting, [16:59.760 --> 17:02.220] you compare that with, let's say a radar, [17:02.220 --> 17:04.620] like if a radar is tracking any other vehicle, [17:04.620 --> 17:07.160] whatever speed that radar, [17:07.160 --> 17:10.120] that you can calculate using the radar input, [17:10.120 --> 17:13.640] you compare that with the information you're getting [17:13.640 --> 17:16.100] in the V2X, in the BSM. [17:17.440 --> 17:22.000] So that way this can also be done in a per message basis, [17:22.000 --> 17:25.300] but can only be done on vehicles that are nearby. [17:25.300 --> 17:27.240] And by nearby, I mean in line of sight, [17:27.240 --> 17:30.160] because radars, cameras can only work in line of sight, [17:30.160 --> 17:31.540] but not in non-line of sight. [17:32.120 --> 17:34.180] Similarly, we look at the RF, [17:34.180 --> 17:38.400] we compare the position, the direction, the velocity, [17:38.400 --> 17:40.740] we look at the consistency on the RF side [17:40.740 --> 17:42.320] 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 --> 17:54.060] If a car, for example, has a position that goes [17:54.840 --> 17:58.600] through buildings, that is not really a lane [17:58.600 --> 18:00.500] that we know about. [18:00.540 --> 18:05.920] So we would really like to see, [18:05.920 --> 18:10.140] okay, is the information coming in the V2X message, [18:10.140 --> 18:13.580] does that correlate with what we have in the map data? [18:13.660 --> 18:16.320] And then we look at consistency [18:16.320 --> 18:18.940] between the senders' messages. [18:18.940 --> 18:23.540] So consistency within the message itself from a sender, [18:23.540 --> 18:25.400] like if the brake status, [18:25.400 --> 18:28.220] for example, if the brake status is not consistent [18:28.220 --> 18:30.740] with deceleration between the messages, [18:30.740 --> 18:33.940] like if the brake is applied, [18:33.940 --> 18:36.160] is the acceleration negative? [18:36.160 --> 18:37.920] Is the vehicle really decelerating? [18:37.960 --> 18:39.960] So that is one example we look at, [18:39.960 --> 18:42.080] is the position, speed, and acceleration, [18:42.080 --> 18:43.640] is that consistent with each other? [18:43.640 --> 18:44.960] So that is one more thing. [18:44.960 --> 18:47.280] And there are many more things that we can look at [18:47.280 --> 18:50.540] 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:00.960] So for example, if you have multiple vehicles [19:00.960 --> 19:07.300] going on a highway, and you look at one-way traffic, [19:07.300 --> 19:09.940] all the vehicles are heading towards this one direction, [19:09.940 --> 19:12.580] and one vehicle is coming directly [19:12.580 --> 19:14.000] in the opposite direction. [19:14.000 --> 19:16.620] So that is a possible misbehavior. [19:17.140 --> 19:19.380] It can be that there is some crazy driver [19:19.380 --> 19:20.720] who is coming on this direction, [19:20.720 --> 19:23.080] but it is really highly unlikely, [19:23.080 --> 19:25.240] and we consider that as a misbehavior. [19:25.240 --> 19:27.420] Or we look at, that is one example, [19:27.420 --> 19:30.180] but in general terms, we look at the trajectory [19:30.840 --> 19:33.600] that is implied by one car and match it with others. [19:33.740 --> 19:35.640] Like for speed, for example, [19:35.640 --> 19:39.320] the speed of vehicles should almost be similar [19:39.320 --> 19:41.540] 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:49.640] And now talking about the fun part, [19:49.640 --> 19:51.240] how do you attack all of this? [19:51.700 --> 19:59.440] So what we do is we look at how an attacker will go about [19:59.440 --> 20:04.320] attacking the misbehavior system [20:04.320 --> 20:09.280] or the B2X system as a whole on the receiver. [20:09.280 --> 20:11.540] So the attacker could attack the security layer, [20:11.540 --> 20:14.120] he could attack on the L1, L2 layer, [20:14.120 --> 20:15.280] that physical MAC layer, [20:15.280 --> 20:17.900] that is, he could perform some attacks on the spectrum, [20:17.900 --> 20:20.860] or he could attack on the application layer as well. [20:20.920 --> 20:22.720] So for example, on security layer, [20:22.720 --> 20:25.220] what he can do, he can send outdated messages. [20:25.220 --> 20:27.140] That means the generation time of the message [20:27.140 --> 20:28.800] is too far behind, [20:28.800 --> 20:31.160] but you're still receiving that message now. [20:31.160 --> 20:33.420] So that is kind of an attack, [20:33.420 --> 20:34.480] that is kind of a message [20:34.480 --> 20:36.560] that you shouldn't have really received. [20:37.000 --> 20:39.320] And then the other attack is [20:39.320 --> 20:41.840] that the vehicle could just send unsigned BSMs [20:41.840 --> 20:44.300] and you just receive those messages, [20:44.300 --> 20:46.460] you say, oh, this is not authenticated, [20:46.460 --> 20:47.660] you drop that. [20:47.980 --> 20:54.580] Then to counter an outdated B2X message attack, [20:54.580 --> 20:59.000] the attacker could forward the generation time in the BSMs [20:59.000 --> 21:00.440] and you could keep that current [21:00.440 --> 21:05.020] to actually try to circumvent the old message check [21:06.040 --> 21:08.900] that can be performed on the security layer. [21:08.900 --> 21:10.580] The attacker could also send a message [21:10.580 --> 21:13.280] without a certificate to invoke no certificate check, [21:13.280 --> 21:16.360] he could also send an expired certificate, [21:16.360 --> 21:19.400] he could incorrectly sign a message, [21:19.400 --> 21:22.720] and then he could be inconsistent on the channel [21:23.280 --> 21:25.080] as well during transmission. [21:25.080 --> 21:27.120] Now, all of these attacks on the security layer, [21:27.120 --> 21:30.480] what they could do is they can starve the receiver [21:30.480 --> 21:34.880] of resources, of processing power. [21:34.920 --> 21:38.700] So even though all these messages are false [21:38.700 --> 21:41.280] and they raise all these concerns, [21:42.320 --> 21:46.820] the receiver could already lose processing [21:46.820 --> 21:50.360] any BSM that is from a legitimate vehicle [21:50.360 --> 21:56.020] and possibly not react to any real incident [21:56.020 --> 21:58.040] that might happen in front of it. [21:58.140 --> 22:02.260] So similarly, you look at coming to spectrum misbehavior [22:02.260 --> 22:04.320] on the physical and math layer, [22:04.320 --> 22:07.320] the attacker could, as we see [22:07.320 --> 22:08.820] in any wireless communication, [22:08.820 --> 22:10.600] could just jam the signal with the blast energy [22:10.600 --> 22:13.300] 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:20.080] He can just say, oh, my message length is this much [22:20.080 --> 22:22.100] and does not send the message, [22:22.100 --> 22:25.120] which is a truncate after preamble attack [22:25.120 --> 22:26.820] that we have heard about recently. [22:27.220 --> 22:31.840] And a lot of wireless communication standards [22:31.840 --> 22:34.640] actually ask the receiver to wait [22:34.640 --> 22:36.960] for a certain period of time after the counter [22:37.480 --> 22:39.080] to wait for the message [22:39.580 --> 22:42.080] so that they can read the message during that time. [22:42.080 --> 22:43.820] So the attacker actually... [22:43.820 --> 22:47.380] So the receiver just waits and does not process [22:47.380 --> 22:49.280] 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 --> 22:55.860] And then the attacker could change his MAC address [22:55.860 --> 23:00.140] so that if you filter MAC, according to, [23:00.140 --> 23:03.000] if you recognize an attacker's MAC address, [23:03.000 --> 23:06.160] if I get any message with this MAC address, [23:06.160 --> 23:08.860] 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:14.740] Coming to the application layer, [23:14.740 --> 23:17.540] the attacker could just fuzz all the fields, [23:17.540 --> 23:20.680] like we do in all... [23:25.460 --> 23:28.640] like we do in testing any mechanism. [23:28.640 --> 23:30.120] The attacker could just say, oh, [23:30.120 --> 23:32.840] I'm sending a speed of minus infinity to infinity [23:32.840 --> 23:36.700] and I want to see how does the way, [23:36.700 --> 23:40.020] does the receiver really accept those messages? [23:40.340 --> 23:45.240] Or what kind of behavior does the vehicle show me [23:45.240 --> 23:47.960] if I send such messages? [23:47.960 --> 23:50.340] And as Jonathan showed about civil attack, [23:50.340 --> 23:52.020] the way we could change MAC addresses, [23:52.020 --> 23:54.380] use the same certificate or different certificates [23:55.180 --> 23:57.120] and create those vehicles. [23:57.120 --> 24:01.800] And then lastly, the attacker could formulate [24:01.800 --> 24:05.340] specific messages to fool V2X applications. [24:05.400 --> 24:07.820] And we're going to talk about this in detail now [24:08.640 --> 24:11.600] with an example of the EBL application [24:11.600 --> 24:13.680] in the next couple of slides. [24:18.790 --> 24:24.890] So here you can see that there are two cars here, [24:24.890 --> 24:26.930] the blue one we consider as the victim vehicle, [24:26.930 --> 24:28.010] the benign vehicle, [24:28.010 --> 24:31.810] and the dark gray car is the attacker. [24:31.810 --> 24:34.670] Now the attacker formulates a normal BSM, [24:34.670 --> 24:36.150] which is marked all as green, [24:36.150 --> 24:38.270] where all the fields of the BSM are consistent [24:38.270 --> 24:39.030] with each other. [24:39.030 --> 24:40.110] You have position, you have speed, [24:40.110 --> 24:41.790] you have positive acceleration. [24:41.790 --> 24:42.890] You don't have any braking, [24:42.890 --> 24:45.330] you don't have any EBL flag set. [24:45.330 --> 24:50.130] The EBL flag is the flag that has to be set [24:50.130 --> 24:52.310] for the EBL application to actually react [24:52.310 --> 24:54.950] to a heartbreaking event. [24:54.950 --> 24:57.410] So whenever a vehicle, if it is hit [24:57.410 --> 24:59.950] and it is heartbreaking, the EBL flag is set [24:59.950 --> 25:03.650] and the receiver, whenever it receives the EBL application, [25:03.650 --> 25:06.970] sees that flag first and then checks other things. [25:07.230 --> 25:11.710] So here, the attacker at first just transfers [25:11.850 --> 25:14.550] a normal BSM, our benign vehicle receives that message [25:14.550 --> 25:16.350] and says, oh, it's a normal car, [25:16.350 --> 25:18.010] goes about on its way. [25:18.250 --> 25:20.130] And then now our attacker says, [25:20.130 --> 25:21.830] 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:32.150] So the brake is zero [25:32.150 --> 25:34.270] and the acceleration is also positive. [25:34.270 --> 25:36.030] This should not really be the case. [25:36.030 --> 25:39.390] But if you don't have any misbehavior detection, [25:39.390 --> 25:42.570] the benign vehicle, when it receives this message, [25:42.570 --> 25:43.990] it says, oh, it's a heartbreaking event, [25:43.990 --> 25:45.610] I should brake, it's safety critical to me [25:45.610 --> 25:48.470] or I might crash into the vehicle. [25:48.530 --> 25:52.470] And our attacker goes about his way ahead. [25:53.610 --> 25:58.830] So at this point, our vehicle maybe looks at, [25:58.830 --> 26:03.290] maybe he doesn't see any car in the vehicle space [26:03.290 --> 26:04.810] after a while. [26:04.810 --> 26:10.050] And like, oh, okay, there was no car in the vehicle space, [26:10.050 --> 26:12.070] 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:22.950] And here we assume that the benign vehicle [26:22.950 --> 26:27.070] doesn't use his sensors like camera or radar [26:27.650 --> 26:32.270] 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:38.370] So firstly, as it might be apparent [26:38.370 --> 26:43.050] that you look at the inconsistency within the BSMPs [26:43.050 --> 26:46.590] and you say, oh, okay, so there's an inconsistency, [26:46.590 --> 26:50.250] 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 --> 26:58.170] So if the attacker, after an EBL, [26:58.170 --> 27:02.150] you would expect that the vehicle would stop, [27:02.150 --> 27:05.130] but if the vehicle continues to change its positions [27:05.130 --> 27:09.230] and has a positive speed and the vehicle keeps on moving, [27:09.230 --> 27:12.870] meaning it doesn't have any change between the telemetry [27:12.870 --> 27:15.370] that was before the attack or after the attack, [27:15.370 --> 27:16.530] that is another indication [27:16.530 --> 27:19.150] where how you could detect such kind of an attack. [27:19.750 --> 27:23.330] Now we talk about fake EBL version two attack, [27:23.330 --> 27:24.910] 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:28.750] You check for inconsistency [27:28.750 --> 27:32.550] and you check for my telemetry. [27:32.550 --> 27:34.350] So I'm going to become smarter. [27:34.470 --> 27:36.910] Again, the attacker transmits a normal BSM, [27:36.910 --> 27:39.990] goes about his way, the benign vehicle follows it. [27:39.990 --> 27:52.890] Now he transmits a fake EBL message, [27:52.890 --> 27:56.370] formulated specifically to counter the detection [27:56.370 --> 27:57.850] in the first version. [27:57.870 --> 28:01.090] You can see that the EBL flag is set as one, [28:01.090 --> 28:02.370] the brake is also set as one [28:02.370 --> 28:04.290] and the acceleration is also negative. [28:04.370 --> 28:06.450] So when our benign vehicle receives this, [28:07.530 --> 28:10.190] his detectors don't give him any indication [28:10.590 --> 28:11.930] and this vehicle just sees, [28:11.930 --> 28:14.290] 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:30.410] The victim vehicle brakes in this case [28:30.410 --> 28:32.950] 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:44.650] We have looked at all the application layer side of things [28:44.650 --> 28:46.170] in the previous checks. [28:46.170 --> 28:48.130] Now we look at the physical layer side of things, [28:48.130 --> 28:51.450] where we look at the signal strength versus the distance. [28:51.450 --> 28:55.870] So as you can see on the graph on the bottom right section, [28:55.870 --> 28:57.350] on the X-axis, you have the distance [28:57.350 --> 28:59.530] and on the Y-axis, you have the signal strength. [28:59.950 --> 29:02.970] And what we have seen is that the signal strength [29:02.970 --> 29:06.550] should reduce as the distance increases [29:07.830 --> 29:11.550] between any two vehicles in this kind of a graph. [29:11.990 --> 29:14.830] But in this case, if the attacker [29:14.830 --> 29:18.190] is sending constant positions in front of you, [29:18.190 --> 29:22.550] but is actually physically changing his positions, [29:22.550 --> 29:24.710] his characteristics would look something [29:24.710 --> 29:27.370] like the red line you see. [29:27.370 --> 29:29.070] The distance is the same, [29:29.070 --> 29:30.530] but the signal strength keeps reducing. [29:30.530 --> 29:34.450] So this is how you could actually find out genuine vehicles [29:34.450 --> 29:38.470] versus an attack vehicle in such cases. [29:39.150 --> 29:42.490] Now our attacker thinks, okay, now you remember me [29:42.490 --> 29:45.730] and I'm going to try to circumvent this. [29:45.730 --> 29:47.890] So we have a version three attack [29:47.890 --> 29:51.630] 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 --> 29:59.170] And now he again, you know, [29:59.170 --> 30:01.150] formulates a fake email message [30:01.150 --> 30:02.370] with all the fields consistent [30:03.070 --> 30:08.030] and transmit that message over our way to receive it. [30:08.030 --> 30:10.730] The attacker stops in vehicle space, [30:10.730 --> 30:12.650] transmits constant positions after the attack, [30:12.650 --> 30:14.810] 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:21.790] But now what the attacker does [30:21.790 --> 30:26.550] is that the attacker goes into a silent period. [30:26.550 --> 30:29.770] So the attacker would go into a silent period here [30:29.770 --> 30:35.190] where it would stop transmitting any DSMs. [30:35.190 --> 30:40.130] So to conserve the storage space in the benign vehicle, [30:40.130 --> 30:42.710] the benign vehicle would check its database, [30:42.710 --> 30:44.890] like, oh, I have, how far, [30:44.890 --> 30:48.370] have I received any BSM recently from this vehicle, [30:48.370 --> 30:50.130] from this attack, from this attacker? [30:50.130 --> 30:52.250] And you would say, no, it has been a long time [30:52.250 --> 30:53.490] 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:00.930] And we assume that the benign vehicle [31:00.930 --> 31:02.710] just deletes all the information [31:02.710 --> 31:06.070] 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:15.250] It doesn't see any vehicle, [31:15.250 --> 31:16.790] so it starts continuing its motion [31:16.790 --> 31:18.370] in the physical space as well. [31:18.370 --> 31:20.210] Now the attacker, he says, [31:20.210 --> 31:22.450] okay, now you have forgotten about me. [31:22.450 --> 31:25.010] He waits for this vehicle ahead, [31:25.010 --> 31:26.410] like it slows down or something, [31:26.410 --> 31:28.050] and performs the same attack. [31:28.250 --> 31:29.250] Now, since our benign vehicle [31:29.250 --> 31:31.370] doesn't have any history on this attacker, [31:31.370 --> 31:34.770] since he deleted this earlier, [31:34.770 --> 31:37.950] 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:46.590] You would, of course, again, [31:46.590 --> 31:47.830] look at the physical properties [31:49.330 --> 31:51.250] of this kind of an attack, [31:51.250 --> 31:53.770] and possibly remember these kinds of vehicles [31:53.770 --> 31:55.690] who kind of were not, [31:55.690 --> 31:57.310] that you were not sure about, [31:57.310 --> 31:59.370] that, okay, maybe this vehicle was malicious. [31:59.370 --> 32:02.550] So you try to remember more, [32:03.110 --> 32:05.090] remember such kind of vehicles for a longer time [32:05.090 --> 32:06.990] to detect, to have history on them. [32:06.990 --> 32:09.970] So that if you have a random jump like this [32:10.570 --> 32:13.790] in the V2X space, that this gray vehicle here, [32:13.790 --> 32:15.390] the vehicle in the V2X space, [32:15.390 --> 32:17.650] jumped from back to here, [32:17.650 --> 32:19.890] you can say that this is a random jump, [32:19.890 --> 32:21.810] and this is possibly a mistake. [32:23.690 --> 32:28.450] Yes, so this is how we have formulated [32:29.350 --> 32:30.470] a cat and mouse game, [32:30.470 --> 32:32.270] where you come up with an attacker, [32:32.270 --> 32:35.450] like a red team, blue team kind of thing, [32:35.450 --> 32:39.770] where the attacker becomes smarter, [32:39.770 --> 32:41.810] we make our detector smarter, [32:41.810 --> 32:44.410] and we expand our detectors [32:44.410 --> 32:48.690] from the application layer to the physical layer, [32:48.690 --> 32:51.490] and map layer, and we expand the portfolio [32:51.490 --> 32:52.990] of all the detectors. [32:53.370 --> 32:58.110] And now we have a demo for this, [32:58.110 --> 32:59.950] that we would like to present there, [32:59.950 --> 33:02.650] where we try to simulate these attacks. [33:02.650 --> 33:04.050] And I would like to hand over [33:04.410 --> 33:07.850] 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:17.890] In the following demo, [33:17.890 --> 33:20.610] I will present the three attacking scenario [33:20.610 --> 33:22.630] as presented by Rashid, [33:22.630 --> 33:26.090] 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:39.550] As you can see, there are two Roadrunner boards, [33:39.550 --> 33:43.410] and one HMI device, and one demo control panel. [33:43.850 --> 33:49.110] And a Roadrunner is a Qualcomm CV2x development platform, [33:49.110 --> 33:52.710] 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 --> 33:59.970] Here you can see we have two Roadrunners, [33:59.970 --> 34:04.970] one of which is the genuine host vehicle, [34:04.970 --> 34:08.630] while the other one is the remote attacker vehicle. [34:09.270 --> 34:14.830] Since the Roadrunner can play the pre-recorded BSM files, [34:14.830 --> 34:18.350] so even though they are placed stationary, [34:18.350 --> 34:20.930] they can still transmit BSMs to each other, [34:20.930 --> 34:23.810] as if they are traveling on a real road. [34:23.810 --> 34:29.170] On the other hand, the HMI display is an Android application [34:29.170 --> 34:30.890] that will visualize the interaction [34:30.890 --> 34:32.510] between the two vehicles. [34:32.510 --> 34:34.170] And the control panel is used to control [34:34.170 --> 34:35.890] and configure our demo. [34:41.430 --> 34:45.730] So here is the control panel of our demo. [34:45.730 --> 34:47.550] And on top of the panel, [34:47.550 --> 34:51.010] you can see the option of our attack scenarios [34:51.790 --> 34:54.790] from fake EVL version one to version three. [34:54.790 --> 34:57.350] Actually, we have many more attack scenarios, [34:57.350 --> 34:59.110] but here we only show those three. [35:00.050 --> 35:02.590] And below the attack options [35:02.590 --> 35:07.470] is our misbehavior protection system status display, [35:07.470 --> 35:09.950] which will show the detection results [35:09.950 --> 35:12.990] of our misbehavior protection system. [35:13.530 --> 35:18.130] So now, let's start version one [35:18.130 --> 35:23.310] of the fake EVL explained by Rashid. [35:24.370 --> 35:27.350] In version one, the attacker generates a fake EVL warning, [35:27.350 --> 35:29.630] but keeps moving both physically [35:30.410 --> 35:33.970] as well as in the V2X space, [35:33.970 --> 35:37.170] as shown in this HMI display. [35:38.050 --> 35:41.510] So in this HMI display, as you can see, [35:41.510 --> 35:46.470] the green bubble here is the host vehicle, [35:46.470 --> 35:49.270] while the blue bubble is the remote vehicle. [35:49.270 --> 35:52.310] From the perspective of the host vehicle, [35:52.310 --> 35:55.070] based on the BSM it received. [35:55.070 --> 35:59.310] And the overlay here on the right of the display [35:59.310 --> 36:01.090] is not a vehicle. [36:01.090 --> 36:04.010] Actually, it's a dashboard for the host vehicle, [36:04.010 --> 36:06.390] which will indicate the safety warnings [36:06.910 --> 36:09.570] generated by the safety applications. [36:10.090 --> 36:12.890] Let's resume the demo. [36:12.990 --> 36:14.590] So as you can see, [36:14.590 --> 36:17.050] from the perspective of the host vehicle, [36:17.050 --> 36:19.510] both are moving normally [36:20.050 --> 36:25.550] until the host vehicle received a fake EVL warning. [36:25.610 --> 36:29.390] And this is because, just as Rashid explained, [36:29.390 --> 36:34.030] because of the inconsistency between the position field [36:34.030 --> 36:37.910] and the EVL flag in the BSMs. [36:37.910 --> 36:41.090] So you can see the blue bubble is still moving, [36:41.090 --> 36:43.530] but it transmits a fake EVL warning. [36:44.250 --> 36:46.910] However, our misbehavior protection system [36:46.910 --> 36:49.930] can easily detect this inconsistency [36:49.930 --> 36:52.390] by applying the possibility check [36:52.390 --> 36:54.010] and the consistency check. [36:54.370 --> 36:58.110] So this is a very easy attacking scenario. [36:58.110 --> 37:00.390] Of course, a smart attacker [37:00.390 --> 37:03.610] will come up with smarter attacks. [37:04.530 --> 37:07.970] Now let's look at the second one, [37:07.970 --> 37:12.350] the version two of our fake EVL attack. [37:12.350 --> 37:14.750] So in version two, explained by Rashid, [37:14.750 --> 37:17.570] the attacker will generate a fake EVL warning, [37:18.290 --> 37:23.790] but all the fields in the BSM are consistent, [37:23.790 --> 37:29.010] meaning that the attacker will move physically, [37:29.010 --> 37:32.690] but it will stop in the V2X space. [37:35.150 --> 37:36.830] Now let's switch into the... [37:37.350 --> 37:42.950] So as you can see, in this version, [37:42.950 --> 37:46.590] the blue bubble is moving normally in the beginning, [37:46.590 --> 37:49.550] but then it will stop in the V2X. [37:50.270 --> 37:51.610] As you can see here, [37:51.610 --> 37:56.150] the blue bubble indeed stopped in the V2X space. [37:56.190 --> 37:58.810] So the host vehicle, we believe, [37:58.810 --> 38:01.710] is a normal vehicle in the application layer. [38:01.790 --> 38:06.150] However, if we're applying our physical layer detector, [38:06.150 --> 38:07.790] such as the signal strength, [38:07.790 --> 38:10.070] we can detect such misbehavior. [38:10.930 --> 38:14.550] So our host vehicle can ignore this fake EVL warning [38:14.550 --> 38:16.510] and continue the motion. [38:17.130 --> 38:19.570] You can see here, our host vehicle is still moving, [38:19.570 --> 38:21.550] even though it detects this, [38:21.550 --> 38:24.350] because it detects this misbehavior. [38:26.350 --> 38:30.970] The attacker can keep finding ways to upgrade his attack, [38:30.970 --> 38:32.550] explained by Rashid. [38:32.550 --> 38:34.110] And so in version three, [38:34.110 --> 38:37.470] and the attacker, the host vehicle, [38:37.470 --> 38:40.470] the attacker will enter a silent period [38:40.950 --> 38:44.670] after performing the first fake EVL attack. [38:44.890 --> 38:48.750] And then he will disappear from the V2X space, [38:48.750 --> 38:51.890] hoping that the host vehicle will forget about him [38:52.290 --> 38:54.230] 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:07.230] As you can see, in the V2X space, [39:07.230 --> 39:09.390] but then it disappeared, [39:10.090 --> 39:13.090] hoping the host vehicle will forget about him. [39:13.090 --> 39:15.650] Now, after the silent period, [39:15.650 --> 39:18.990] it shows up again and then perform the attack again. [39:19.910 --> 39:22.810] So again, this attack can also be detected [39:23.270 --> 39:25.210] using the physical layer detectors [39:26.010 --> 39:27.870] just introduced by Rashid. [39:32.990 --> 39:33.890] Okay. [39:34.390 --> 39:37.050] So as the demo shows that a smart attacker [39:37.050 --> 39:41.870] can always find ways to create smarter attacks [39:42.370 --> 39:45.610] as our detection algorithm evolves. [39:45.610 --> 39:49.330] For example, we showed that using the physical layer, [39:49.330 --> 39:53.210] we can detect the fake EVL attack version two [39:53.210 --> 39:54.630] and version three. [39:54.630 --> 39:58.230] However, a smart attacker may circumvent our detector [39:59.270 --> 40:01.590] by, for example, matching the signal strengths [40:02.330 --> 40:04.730] with valid distribution. [40:04.730 --> 40:07.190] Valid signal strength distribution [40:07.430 --> 40:10.130] by adjusting the transmission power. [40:10.270 --> 40:12.090] And other cases, [40:12.090 --> 40:14.350] attacker can use different MAC address [40:14.350 --> 40:16.950] and pseudonym certificates to perform a stable attack [40:16.950 --> 40:19.570] as introduced previously [40:19.810 --> 40:22.970] to fool the majority based detector. [40:22.970 --> 40:24.850] And actually there are many more ways [40:24.850 --> 40:27.870] that attacker can progress [40:27.870 --> 40:31.050] to perform more advanced attacks. [40:31.050 --> 40:35.470] However, by improving our detection system, [40:35.470 --> 40:38.250] we are able to squeeze the attacker to the corner [40:38.250 --> 40:42.730] and raise the bar and the cost of the successful attack. [40:42.730 --> 40:44.150] And on the other hand, [40:44.150 --> 40:46.470] the progression of the attack can push for a stronger [40:46.470 --> 40:49.590] 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:08.720] So what we showed you today is [41:10.360 --> 41:14.000] why, what is misbehavior, first of all, in V2X [41:14.000 --> 41:16.360] and give you many examples. [41:16.540 --> 41:20.040] And then we even went through this misbehavior life cycle, [41:20.040 --> 41:21.780] detection, local reaction, reporting, [41:21.780 --> 41:23.540] 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:34.920] So, and we'll give you a demo of this [41:34.920 --> 41:36.880] working on real onboard unit. [41:37.140 --> 41:41.000] So as a conclusion, really we understand why [41:41.000 --> 41:43.460] misbehavior protection is super important [41:43.460 --> 41:46.080] for more secure V2X deployment. [41:46.080 --> 41:47.060] You need to have it, [41:47.060 --> 41:49.360] 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:55.500] But what's good is that misbehavior detection, [41:55.500 --> 41:57.140] reporting, investigation, reaction [41:57.140 --> 41:59.100] are all being standardized right now. [41:59.100 --> 42:02.700] So we hope that then really we're going to raise that bar [42:02.700 --> 42:04.640] on making it harder for an attacker [42:04.640 --> 42:06.660] and all have at least minimum performance [42:06.660 --> 42:08.140] in terms of detection. [42:08.280 --> 42:10.080] And also what is really positive [42:10.080 --> 42:12.780] is that misbehavior protection solutions exist [42:12.780 --> 42:15.740] and have been deployed in, for example, [42:15.740 --> 42:17.740] one in the connected vehicle part of deployment. [42:17.860 --> 42:19.900] So this is positive, you know, [42:19.900 --> 42:23.140] it's there, we are ahead of the curve, basically. [42:23.380 --> 42:26.420] But as we've seen, the attacker is always smarter [42:26.940 --> 42:29.820] and will try to counter what you do. [42:29.820 --> 42:31.500] So we still have a lot of open challenges [42:31.500 --> 42:34.940] and I really just like to give you three examples here. [42:34.960 --> 42:37.020] The first one is, [42:37.020 --> 42:40.480] if you are using a machine learning based detector, [42:40.480 --> 42:43.360] therefore an attacker will use a visual example, [42:43.440 --> 42:46.800] a visual machine learning to fool your detection algorithm. [42:46.800 --> 42:49.680] So this is a really active field right now [42:49.680 --> 42:51.740] to look at visual machine learning. [42:51.860 --> 42:53.180] And so therefore, if you're based on that, [42:53.180 --> 42:54.500] you need to look at it. [42:55.760 --> 42:58.780] This is still a highly sophisticated level of attack, [42:58.780 --> 43:00.280] but it is a matter of time [43:00.280 --> 43:02.420] before it's making it easier to be there. [43:02.460 --> 43:04.640] The second part is that we've shown today [43:04.640 --> 43:07.660] only the detection, the attacks on the first step. [43:07.660 --> 43:10.100] So you need to investigate the attack on the reporting, [43:10.100 --> 43:12.160] investigation and a global reaction. [43:12.200 --> 43:14.240] What could you do on those different stages? [43:14.840 --> 43:17.340] And finally, don't forget that V2X [43:17.860 --> 43:20.300] will be part of an automated vehicle [43:20.300 --> 43:23.040] and therefore will be fused with other sensors. [43:23.040 --> 43:25.600] So you need to analyze the effect of V2X attack [43:26.220 --> 43:28.340] on the sensor fusion to understand [43:28.780 --> 43:30.760] how much inconsistency and insensitivity [43:30.760 --> 43:33.060] can you create just from the V2X standpoint. [43:33.520 --> 43:35.680] With that, this is the end of our presentation [43:36.340 --> 43:38.140] and we'll be happy to take questions. [43:38.140 --> 43:39.020] Thank you.