[00:00.000 --> 00:04.500] Thanks for tuning into my talk. This is Houston, we have a problem. [00:04.740 --> 00:09.060] It's a bit weird doing things this way, but I guess this is going to be the new normal now. [00:09.480 --> 00:14.000] So the title of my talk is Houston, we have a problem. I'm here today to talk to you about [00:14.000 --> 00:19.260] Europe's proposals for future intelligent roadways to support connected and autonomous vehicles. [00:25.160 --> 00:28.040] So overview of what I'm going to talk about in this session. [00:28.160 --> 00:32.360] First up, who am I? And where did this project come from? [00:32.360 --> 00:36.640] Then a large portion of this talk is going to be discussing the proposed CAV ecosystem. [00:37.160 --> 00:40.880] There's a lot of proposed components in these future systems. [00:40.900 --> 00:44.280] So you need to kind of know what all the components are before you can understand [00:44.280 --> 00:48.660] the overarching system. I'm also going to be shit talking them as I go. [00:48.820 --> 00:53.340] From here, I'm going to be discussing some of the threats likely to be faced by the ecosystems. [00:53.340 --> 00:57.420] So who's likely to target them, with what resources and what kind of things they're [00:57.420 --> 01:01.480] going to be going after. I'll talk through some example scenarios of how an attacker [01:01.480 --> 01:06.660] might infiltrate the network and what to expect. Next up, I'll provide considerations for how we [01:06.660 --> 01:12.560] can improve the situation. And finally, the conclusions, which, spoiler alert, is mainly [01:12.560 --> 01:16.940] that everything is nightmare. Then we'll have some acknowledgments and time for questions, [01:16.940 --> 01:23.680] which I believe is going to be all types. So a little about me. My name is Vic Harkness. [01:23.800 --> 01:28.960] I've got a degree in robotics and artificial intelligence and a degree in cyber security. [01:28.960 --> 01:34.920] I also worked as a falconer for a bit. After graduating, I worked for DSTL, which is a bit of [01:34.920 --> 01:40.720] the UK Ministry of Defence, then moved to MWR Info Security. That got purchased by F-Secure, [01:40.720 --> 01:45.600] so now I work at F-Secure. And I was the lead author on the bit of work that this talk is [01:45.600 --> 01:50.620] discussing. If you want to talk to me, you can find me on Twitter at Vic Harkness. Talk to me [01:50.620 --> 01:56.120] about falconry, facial recognition systems, biometrics, and network vehicle security. [01:58.300 --> 02:03.960] So an overview of the project. This package of work was done as part of the ZENZIC Cyber [02:03.960 --> 02:09.860] Feasibility Report Project. So the ZENZIC Cyber Feasibility Report Project aims to inform and [02:09.860 --> 02:15.480] advise the UK government on the security of future CAV and ITS networks. So I know I've said CAV a [02:15.480 --> 02:26.100] few times already. I'm going to expand on it now. CAV means connected and autonomous vehicles. ITS, [02:27.060 --> 02:31.940] they're referring to the same general concept. But some people prefer to say CAV, some prefer to say [02:31.940 --> 02:36.720] ITS. I think they're more commonly called ITS. And within the standards documents, they're called [02:36.720 --> 02:42.360] ITS. But ZENZIC prefers to call them CAV. So throughout this talk, I'll largely be calling [02:42.360 --> 02:49.380] them CAV. So as I'm sure you're aware, automated vehicles are becoming a thing. In the future, [02:49.380 --> 02:53.100] it's envisioned that most people will drive either hyperconnected vehicles or have an [02:53.100 --> 02:58.000] automated vehicle. To support this future, the creation of sensor-rich intelligent roadways has [02:58.000 --> 03:02.960] been proposed. The UK government wants to buy into this future. They don't necessarily want [03:02.960 --> 03:06.920] to be the first people to create these intelligent roadway systems, but they want to be the best to [03:06.920 --> 03:11.000] do it. They want the most robust roadways, and they want them to be the most secure. [03:11.220 --> 03:16.280] And the ZENZIC Cyber Feasibility Report feeds into this goal. So seven companies worked on the [03:16.280 --> 03:21.340] problem space, and ZENZIC created a summary report. This summary report went off to government to help [03:21.340 --> 03:27.300] decide what they should do about future roadways. So my team at F-Secure looked at the V2X, or [03:27.300 --> 03:32.040] vehicle-to-everything aspect of the problem, as well as considering how you might test these future [03:32.040 --> 03:36.860] networks at scale. But to understand the problem, we needed to look at the space as a whole. [03:36.920 --> 03:41.340] So our paper provides an overview of the entire space, as well as making recommendations on [03:41.340 --> 03:45.920] testing at scale. There should be a link to the white paper available by the time you're watching [03:45.920 --> 03:50.060] this. At the time of recording, it's not gone live yet, but I'm sure I can share it in the chat or [03:50.060 --> 03:56.980] something like that. As a quick note, the proposals we looked at for future cap infrastructure have [03:56.980 --> 04:02.420] been provided by the European Telecommunications Standards Institute, the International [04:03.440 --> 04:09.160] Organization for Standardization, and the European Commission. So it's a fairly Europe-centric [04:09.160 --> 04:14.580] presentation, I'm afraid. But there are very similar proposals in the US, and there's kind [04:14.580 --> 04:19.940] of a lot of equivalency between the proposals. So hopefully it's still useful for non-European [04:19.940 --> 04:24.800] people. But hopefully this talk and our white paper provide sufficient information for someone [04:24.800 --> 04:28.700] wishing to enter the problem space to get up to speed on the future proposals. [04:32.340 --> 04:35.960] So first we're going to talk about the CAV ecosystem components. [04:36.700 --> 04:40.900] Whilst our area of the project was dealing with the vehicles-to-everywhere communications, [04:40.900 --> 04:45.460] I still consider the internal systems of a vehicle as an important part of the CAV ecosystem. [04:45.900 --> 04:49.740] Vehicles are no longer expected to be used solely as a means of transportation. [04:49.740 --> 04:54.320] They guide us to our destinations using maps. They advise us on the best route to take using [04:54.320 --> 05:00.340] traffic information. They advise us, they entertain us using audio and video. In the future, they will [05:00.340 --> 05:05.200] ease the burden of driving altogether by being able to autonomously navigate to our destinations. [05:05.380 --> 05:10.480] To facilitate this, vehicles contain complex internal networks. Future vehicles are more [05:10.480 --> 05:15.040] akin to computer networks. Lots of smaller computers all working on smaller parts of the task [05:15.040 --> 05:19.340] network together. So for instance, you could have one computer that's driving the infotainment [05:19.340 --> 05:23.640] system, another one that's driving the lights, but they all need to be connected so that the [05:23.640 --> 05:28.260] infotainment system can be used to control the lights, for instance. These future vehicles will [05:28.260 --> 05:32.680] be handling large amounts of data taken from a range of sources. Some of those are going to be [05:32.680 --> 05:39.340] external, like GPS data, traffic data, data coming in from the vendor, whoever you bought the car off. [05:39.340 --> 05:43.640] There's also internal data sources within the vehicle. So you've got your classic integrated [05:43.640 --> 05:49.720] sensors, like your speed sensors, your tire pressure sensor. But the more futuristic [05:49.720 --> 05:55.380] systems are going to have cameras, range sensors, like sonars to detect where there's nearby [05:55.380 --> 06:00.940] vehicles or detect if someone's walked in front of the car. And you'll also be taking inputs from the [06:00.940 --> 06:05.560] driver of the car, like steering wheel, pressing brakes, that sort of thing. [06:06.080 --> 06:10.240] Some of the proposals we looked at also expected some more novel sensors to be used. [06:10.240 --> 06:15.520] So one of the proposals actually described a system whereby the car can automatically [06:15.520 --> 06:20.840] monitor the biometrics of the user. And so if the driver of the car was to, for instance, [06:20.840 --> 06:25.160] have a heart attack, the system would be able to automatically detect and communicate this and [06:25.160 --> 06:30.820] assumedly call an ambulance. But with all this data coming from a wide range of sources, [06:30.820 --> 06:35.400] how can you trust it? It's a given that attackers are going to be targeting the [06:35.400 --> 06:40.140] internal vehicle networks. I'm not going to talk specifically about data hygiene within [06:40.140 --> 06:43.900] internal vehicle networks, because I'm sure there'll be someone else at the car hacking village [06:43.900 --> 06:48.100] who knows a lot more about it than me and will be able to do a much better job than me of explaining [06:48.100 --> 06:53.600] it. But in general, I will say, handle the data with care. No component should place absolute [06:53.600 --> 06:58.540] trust in the data it receives. But really, it's up to you guys making these systems to decide how [06:58.540 --> 07:03.800] trustworthy components are and design your models based around that trust. Some of the sort of [07:03.800 --> 07:08.700] things that an attacker is likely to target are the vehicle sensors, they make a good potential [07:08.700 --> 07:13.580] entry point for introducing false or malicious data into the vehicle network. I mean, people [07:13.580 --> 07:18.000] are already playing around with the future systems, like people have been using adversarial [07:18.000 --> 07:23.100] examples to generate stickers they can put on road signs, which will cause the car to no longer [07:23.100 --> 07:28.380] classify the road sign correctly. So what was once a stop sign is now a speed limit sign, [07:28.380 --> 07:35.040] the car just drives straight through. Another thing the attackers might target are the entertainment [07:35.040 --> 07:41.520] and infotainment systems. They're another good route for introducing malicious data into or [07:41.520 --> 07:45.880] gaining access into connected vehicles. I mean, we're already getting familiar with the advanced [07:45.880 --> 07:51.040] infotainment systems, we're used to them having a touchscreen now to display maps to play with [07:51.040 --> 07:56.080] our music, all that sort of thing. In some of the CAV proposed documents, these systems are also [07:56.080 --> 08:00.020] going to be doing tourist information for you, you're going to drive past a mountain, and the [08:00.020 --> 08:04.520] car's going to start telling you what the mountain is, the history of it, all about it, for better or [08:04.520 --> 08:11.440] worse. Potentially, they're kind of similar to sensors in the attackers might try and manipulate [08:11.440 --> 08:17.400] data by and manipulate behavior, sorry, by inserting malicious data, such as incorrect traffic data, [08:17.400 --> 08:21.220] or try and use them as a point from which they could pivot to elsewhere within the car's internal [08:21.220 --> 08:26.900] network. The first thing I want to mention is applications, because you've got to have apps if [08:26.900 --> 08:32.040] you want to be futuristic with your system. So in the Envisioned Future Connected and Autonomous [08:32.040 --> 08:36.460] Vehicles, you'll be able to download apps from an app store, like how you would on your phone. [08:36.460 --> 08:41.240] And we all know how good that is for device security. There's little information so far on [08:41.240 --> 08:45.520] how these will actually look in terms of security and access permission models. Don't know if it's [08:45.520 --> 08:49.120] going to be like the Apple Store, where you've got to like have your app pre-approved before it can [08:49.120 --> 08:52.620] be uploaded. Or if it's going to be a bit more like the Android Store, where you can just kind [08:52.620 --> 08:57.880] of go for it. There's no advice on this at this point. But it does seem like they're going to be [08:57.880 --> 09:02.460] an excellent route to break into a vehicle's internal network. I mean, they might end up [09:02.460 --> 09:09.100] being used as part of a jailbreaking solution for the vehicles. So with Teslas, it turns out [09:09.100 --> 09:13.820] that when you buy an upgrade for a Tesla, it can be remotely enabled, you don't actually need [09:13.820 --> 09:19.760] to go to the garage to get it upgraded. So when they had the massive fires in California a few [09:19.760 --> 09:25.600] years back, Tesla remotely pushed free battery updates to cars within the area of effect, [09:25.600 --> 09:31.060] so that they could escape easier, or the drivers could escape easier. But the Lord Elon giveth, [09:31.060 --> 09:35.600] the Lord Elon taketh away. There's been lots of cases of people buying secondhand Tesla models [09:35.600 --> 09:40.780] with certain upgrades enabled, only to have them be remotely disabled again after purchase. [09:40.780 --> 09:44.800] Perhaps applications will be used for this sort of functionality in future paths. [09:44.900 --> 09:48.940] Certainly seems like a fun area for future investigation, if nothing else. [09:50.280 --> 09:55.260] So what if someone manages to compromise multiple aspects of a vehicle's internal network at once? [09:55.420 --> 10:00.460] The vehicles ideally should be able to detect this and handle it in some way. Because it's not [10:00.460 --> 10:03.820] really the best solution if it just crashes into a wall because it thinks it's the road, [10:03.820 --> 10:08.440] Wile E. Coyote style. Perhaps it'd be more appropriate for a vehicle that detects anything [10:08.440 --> 10:13.060] funky going on to drive to the side of the road and refuse to move again until it gets assistance. [10:13.260 --> 10:16.480] Or is that just going to be a perfect vector for denial of service attacks? [10:16.540 --> 10:20.600] Going to be really annoying and not answer that. Instead, I'll move on to talking about [10:20.600 --> 10:31.420] personal stations. So the Etsy standards propose the use of personal stations. [10:32.460 --> 10:36.140] These are little handheld devices which are designed to be connected to the overarching [10:36.140 --> 10:41.060] cab networks. The exact purpose of them is unclear, but they seem to basically be mobile [10:41.060 --> 10:46.160] phones, like you can install apps on them. It's suggested they're used by low-speed users of [10:46.160 --> 10:51.060] networks such as pedestrians and cyclists. I've got a few of the suggestions on the slides, like [10:51.060 --> 10:56.160] using them to check bus times, use them to update bus times, use them to look at maps. [10:56.160 --> 11:00.540] They're basically mobile phones. Maybe this will just morph into an app that you can put on your [11:00.540 --> 11:04.940] own mobile phone so you don't have to carry something extra around. Who knows? As far as [11:04.940 --> 11:09.360] security goes, I'd say treat them like mobile phones. They're likely to be an easy target for [11:09.360 --> 11:13.580] because they're quite small, so you want them to be lockable and remotely trackable. [11:13.940 --> 11:17.520] You also, again, don't want to be completely trusting of data coming from them because [11:17.520 --> 11:24.870] there's a high risk of compromise if they are akin to mobile phones. So the envisioned future [11:24.870 --> 11:29.270] intelligent roadways will need lots and lots of supporting infrastructure. Infrastructure to [11:29.270 --> 11:33.310] support the connections between connected vehicles, infrastructure to support the automated [11:33.310 --> 11:38.550] decision-making capabilities of automated vehicles. But not all vehicles will be connected [11:38.550 --> 11:42.590] or automated in the future. You're still going to get the people like me who are scared of new [11:42.590 --> 11:47.470] technology and want something more old-fashioned. Unfortunately, you can't quite ignore us weirdos [11:47.470 --> 11:51.630] who refuse to join the borg. You still need to know where the old-fashioned vehicles are so that [11:51.630 --> 11:55.950] they can be incorporated into your traffic models or avoided by your automated systems. [12:00.330 --> 12:05.690] Extensions of current CCTV and radar system capabilities, when augmented by additional [12:05.690 --> 12:10.730] sensors, could be sufficient to track old-fashioned vehicles as though they were connected vehicles. [12:10.890 --> 12:15.350] In addition to tracking vehicles, sensors can be used to provide supplementary data into [12:15.350 --> 12:20.030] decision-making systems. For example, local weather information or information on road [12:20.030 --> 12:25.710] conditions could be useful to augment the data already within the systems. It's also quite useful [12:25.710 --> 12:30.310] for automated systems. So if you've got a human driver, they might, you know, notice that it's [12:30.310 --> 12:35.430] raining and the road is wet and so automatically slow down. Whereas an automated system, it doesn't [12:35.430 --> 12:40.450] work quite like the human does. But if it was receiving data saying the road's wet, slow down, [12:40.450 --> 12:47.190] then it will be able to act on that. So thanks to these prolific sensors, it might be the case that [12:47.190 --> 12:52.990] these automated systems would be able to behave in a more human-like manner. But unfortunately, [12:52.990 --> 12:56.170] just covering everything with sensors means you've got more things to secure. [12:57.410 --> 13:02.890] So just go search for CCTV on Showdown if you're bored. You can view the CCTV feeds, which isn't [13:02.890 --> 13:07.750] that bad. You know, you'd just be watching cars go along the road. Not really that worrisome. But some of [13:07.750 --> 13:12.210] these cameras are designed to be remotely administered. You get that traditional admin-admin [13:12.210 --> 13:16.150] credentials combo going and suddenly you have access to a node within the CAV network. [13:16.450 --> 13:21.690] If the network trusts data coming from that CCTV system to a high degree, then the whole network's [13:21.690 --> 13:26.750] going to be having a bad time. So just, if you're going to be making sensors that are likely to [13:26.750 --> 13:32.550] end up in CAV networks, please secure them. Don't have easily guessable default creds. Require admins [13:32.550 --> 13:38.570] to use VPNs to remotely administer them. Just do something, please. It seems like it's going to be a [13:38.570 --> 13:43.570] really easy way for attackers to get into the networks. [13:43.570 --> 13:49.370] Next up, we've got roadside units. So these roadside units, or RSUs, are designed to collect, [13:49.370 --> 13:53.690] collate, and forward data from other bits of the network. They'll be taking the data from pretty [13:53.690 --> 13:58.270] much everything in the network. They can collect data from roadside sensors and vehicles, and [13:58.270 --> 14:03.530] they'll send this data onwards to data hubs, which are processing centers designed to inform [14:03.530 --> 14:09.770] traffic control decisions. The RSUs can also take data from vendors and transmit it back down to the [14:09.770 --> 14:15.670] vehicles. RSUs are actually physical units proposed to be positioned every 500 meters along the side [14:15.670 --> 14:21.250] of the intelligent roadway. They'll all be connected up in some manner. Some believe that RSUs should [14:21.250 --> 14:25.050] be able to take more active roles within the network, such as directly controlling autonomous [14:25.050 --> 14:30.030] vehicles. I think that's kind of a bad idea for reasons that, you know, should become even more [14:30.030 --> 14:37.110] clear as this talk goes on. The RSUs are envisioned to contain some heavy-duty networking equipment, [14:37.110 --> 14:42.830] including industrial network switches and ITS station border routers. You want the industrial [14:42.830 --> 14:50.370] network switches to be survivable in the harsh environments of constant outdoor usage. [14:50.550 --> 14:54.650] And they also support standard security features, such as MAC address filtering, [14:54.650 --> 15:01.310] remote management, network access, etc. During this study, we read a report that was investigating [15:01.310 --> 15:07.650] the security at one of these proposed roadside units. And they found that, yeah, the switch in it [15:07.650 --> 15:12.950] had MAC address filtering in place, but the MAC address of the computer driving the RSU was written [15:12.950 --> 15:22.110] on the side of the box, so not really the best security maybe. The ITS station border routers [15:22.110 --> 15:26.490] within the RSUs are designed as the point through which data from the intelligent roadways [15:26.490 --> 15:31.450] is sent off to the data hubs. There's a few proposals of what form this transport medium [15:31.450 --> 15:37.130] could take. Some suggest using LTE. Others suggest that you could just lease actual physical lines [15:37.130 --> 15:42.570] from local councils. There's lots of different approaches, and with different approaches come [15:42.570 --> 15:47.230] different security concerns. But when you're securing these RSUs, you should take a general [15:47.230 --> 15:52.350] network infrastructure security approach. So consider the physical security. Make the locks [15:52.350 --> 15:58.430] on the physical box secure with a tamper detection system. If the RSU is hidden away behind the trees, [15:58.430 --> 16:04.230] monitor them with CCTV systems. So in the report where they noticed the MAC address was written [16:04.230 --> 16:09.670] on the side of the box, the guy who did that study, he actually set up a tent next to the RSU, [16:09.670 --> 16:14.090] and he camped out there for like two days, and no one noticed him messing around with the thing. [16:14.090 --> 16:18.230] So you need some kind of monitoring, because two days gives you quite a bit of time to play around [16:18.230 --> 16:23.730] with stuff. Make sure that tamper detections are actually followed up upon. So you could [16:23.730 --> 16:29.150] cross-reference things like timings of tamper detections with maintenance schedules. And if [16:29.150 --> 16:33.930] the tamper is determined to not be a false alarm, you should take action. For instance, you could [16:33.930 --> 16:38.670] consider that all data from that node is now unsafe, and so do not make any important decisions [16:38.670 --> 16:43.990] based upon it. In addition to physical security, you should also follow good network security [16:43.990 --> 16:49.330] best practices. You know, change default creds, disable unused services, all that good stuff. [16:49.570 --> 16:54.690] Make sure that a procedure for patching devices is in place, encrypt the data being held locally, [16:54.690 --> 16:58.050] and when it's being transmitted onwards, especially if you're making use of third-party [16:59.010 --> 17:03.830] transmission mediums. Tangentially, you should consider the security of device maintenance [17:03.830 --> 17:09.090] systems. It's likely that there'll be engineers coming to, you know, do upgrades on these systems, [17:09.090 --> 17:13.990] or do general maintenance tasks, or whatever, really. The engineers carrying out the legitimate [17:13.990 --> 17:18.950] work upon the RSUs will probably have laptops that they're designed to plug into the system. [17:19.090 --> 17:22.810] They might also have been on a dodgy porn website in the hotel the night before, and be bringing [17:22.810 --> 17:27.810] all sorts of nasties with them. So again, just don't trust things. Don't trust an engineer's [17:27.810 --> 17:35.790] laptop, even though in theory it should be fine. It might not be. Trust no one, not even yourself. [17:35.790 --> 17:40.690] I know I sound like a broken record, but do not place absolute trust in any single aspect of the [17:40.690 --> 17:53.440] system. So data hubs are where all the data lives. The data collated by the RSUs [17:53.440 --> 17:58.460] will end up here. The scales of the data hubs is kind of unclear right now. I mean, maybe they're [17:58.460 --> 18:02.680] going to be regional, maybe they'll be countrywide, maybe they'll be just for a town or a specific [18:02.680 --> 18:08.640] section of road. It's not really clear. It's also not clear who's going to run the data hubs, [18:08.640 --> 18:13.140] or what exactly they'll be doing with the data. But generally, they're probably going to be used [18:13.140 --> 18:18.300] in traffic management systems, traffic analysis, all that good stuff. There's also proposals for [18:18.300 --> 18:23.260] their usage in test beds. I'll be talking a bit more about the test beds later. But the basic [18:23.260 --> 18:27.960] idea is that there'll be regions of roadways, which are designated for vendors to test their [18:27.960 --> 18:33.180] new kit on. Because of this, there's going to be large amounts of data being collected on the test [18:33.180 --> 18:38.900] bed roadways, which vendors can then evaluate like post trial to work out the performance of [18:38.900 --> 18:43.980] their systems. And that will make test bed data hubs a really high value target for attackers, [18:43.980 --> 18:48.240] because there's going to be lots and lots of data. And because people are going to be testing new [18:48.240 --> 18:52.020] models of vehicles, it's likely to be about things that aren't actually available yet. [18:52.020 --> 18:56.800] So it'd be great for corporate espionage. Or I mean, what if you could just get into the data [18:56.800 --> 19:00.800] hub and delete all the data in it? You know, could you force a vendor to have to redo trials and [19:00.800 --> 19:07.140] delay the release of a new product? Security of the data hubs is going to be incredibly important. [19:07.180 --> 19:11.220] And it's likely going to be fairly bespoke. I mean, one could probably learn from security [19:11.220 --> 19:16.540] best practices for any large scale sensitive data holder. But I mean, just once again, [19:16.540 --> 19:20.340] you don't want to trust all the data you're receiving into these data hubs, [19:20.340 --> 19:27.140] just in general. You know, don't let little bobby tables ruin your day. Likewise, you need some form [19:27.140 --> 19:31.940] of accountability within the system. If you find that you're all you're frequently getting malicious [19:31.940 --> 19:36.680] data from a certain node, like you're frequently getting bobby tables popping up, you might you [19:36.680 --> 19:40.960] want to be able to identify what node this malicious data is coming from. So you can actually [19:40.960 --> 19:45.820] address it. Or just if you're getting like, I don't know, like invalid data coming from a node, [19:45.820 --> 19:50.500] you want to be able to work out where it's coming from, and address whatever the issue is. [19:57.220 --> 20:02.500] So transmission medium, there's the potential for lots of different data transmission media to be [20:02.500 --> 20:06.800] used within these future networks. I'll be talking about the connection issues within the next [20:06.800 --> 20:12.600] section, when I discuss the bespoke protocols that have been proposed. So LTE is like the most [20:12.600 --> 20:18.040] obvious connectivity choice. It's simple, it's fairly accessible nowadays, it's reasonably cheap. [20:18.100 --> 20:23.020] Some vehicles already make use of LTE. You've got systems such as eCall, which automatically calls [20:23.020 --> 20:28.260] the emergency services if it detects you're in a crash. And LTE can also be used to transmit [20:28.260 --> 20:33.120] over-the-air software to vehicles, software updates, sorry, to vehicles. I mean, in future [20:33.120 --> 20:37.940] cab vehicles, LTE will probably be used by applications, and maybe also by some of the [20:37.940 --> 20:43.800] roadside sensors, who knows. Standard LTE security best practices should be followed, just to make [20:43.800 --> 20:48.640] sure it's not too obvious that your tech is using 5G LTE, so it doesn't get blamed for international [20:48.640 --> 20:54.540] pandemics. As mentioned earlier, it's been proposed that lease lines could be used to transmit data [20:54.540 --> 20:59.960] from RSCs back to data hubs. If you're sending potentially sensitive data over third-party lines, [20:59.960 --> 21:04.480] you probably want to try and encrypt it and sign it so that it cannot be read or tampered whilst [21:04.480 --> 21:10.220] it's in transit. From what I can tell, lease lines will be used only for data hub communications, [21:10.220 --> 21:14.280] though they're not going to be used for like sending data from one car to another, because [21:14.280 --> 21:20.240] that just wouldn't make sense. Finally, we get to the wireless local area networks. [21:20.880 --> 21:25.240] Small WLANs within vehicles are proposed, which allow users to get onto the internet via their [21:25.240 --> 21:30.280] vehicle. However, it's also been proposed that giant WLANs could be used to handle the majority [21:30.280 --> 21:36.200] of communications between CAV network nodes. To me, this proposed usage of wireless local area [21:36.780 --> 21:42.160] networks for data transmission between CAV nodes is super interesting. It's proposed that it will [21:42.160 --> 21:48.720] be enabled through the usage of a relatively new 802.11p standard OCB mode, and as always with this [21:48.720 --> 21:54.760] talk, I'll be talking more about that later. So now that you know about the transmission medium, [21:54.760 --> 21:59.280] what about the transmission protocols? Within CAV networks, there's two main types of message [21:59.280 --> 22:04.600] being sent between vehicles and other nodes, CAM and DENIM. CAM standing for cooperative [22:04.600 --> 22:10.840] awareness messages and DENIM being decentralized environmental notification messages. For those [22:10.840 --> 22:18.140] of you in the US, these are equivalent to DSRC basic safety messages, where BSM part one is about [22:18.140 --> 22:25.500] equivalent to CAM and part two is about equivalent to DENIM. So about CAM, as the name suggests, CAM [22:25.500 --> 22:29.800] are used for cooperative awareness. They're what let the vehicles know where each [22:29.800 --> 22:34.920] other are, so that they can move cooperatively. The CAM acts as a heartbeat for the vehicle, providing [22:34.920 --> 22:40.400] metrics on its current state. This includes things like the current time, the location, heading [22:40.400 --> 22:45.980] direction, speed, if the lights are on or not, all that sort of thing. The vehicles don't send these to [22:45.980 --> 22:50.420] anyone in particular, they just transmit it out into the world for anyone or anything to pick up. [22:50.580 --> 22:55.440] They're signed by the pseudonym certificates used within the CAV ecosystem, and I'll talk more about [22:55.440 --> 23:00.300] certificates later. The generation of CAM is controlled by the cooperative awareness basic [23:00.300 --> 23:06.300] service within the vehicle. The CA basic service also receives and processes CAM from other vehicles. [23:06.660 --> 23:10.680] DENIM, on the other hand, are used by vehicles to share an awareness of any events that may have [23:10.680 --> 23:15.620] occurred. An event could be that an accident has occurred ahead, or that the vehicle has detected [23:15.620 --> 23:21.000] the presence of ice on the road, that sort of thing. Interestingly, the DENIM standards also [23:21.000 --> 23:25.540] contains medical emergency flags. These are the things I spoke about earlier, whereby if the [23:25.540 --> 23:31.080] vehicle detects that the driver's had a heart attack or they're in a diabetic coma, it's got a [23:31.080 --> 23:37.520] specific DENIM message type to let the other cars around that driver know that that's what happened. [23:37.520 --> 23:43.020] So once a vehicle's detected an event, it creates a new event DENIM. This contains info on what the [23:43.020 --> 23:47.940] event type is, the geographic area of relevance for the event, and that includes details of what [23:47.940 --> 23:52.520] roads will lead up to encountering the event. This DENIM is transmitted out into the world where [23:52.520 --> 23:57.780] it's picked up by the DEN basic service of other vehicle nodes. When a vehicle picks up a DENIM, [23:57.780 --> 24:02.140] the onus is placed upon the receiving vehicle to decide the relevance of the message. [24:02.260 --> 24:06.720] So the vehicle will determine if it's within the geographic area of relevance for the event, or [24:06.720 --> 24:12.540] if it's even heading in the correct direction to encounter the event. If it is, the vehicle [24:12.540 --> 24:17.640] will update its internal records and automatically retransmits the DENIM onwards to other vehicles. [24:17.680 --> 24:22.800] If it's not relevant, it just ignores it. Based on this automatic forwarding, vehicles may be [24:22.800 --> 24:28.140] updated as to the existence of an event as soon as they enter the relevant area. Likewise, if the [24:28.140 --> 24:33.640] initially reporting vehicle leaves the area, the event is not forgotten. Vehicles might also [24:33.640 --> 24:38.000] provide updates to an existing event, even if they were not the first vehicle to report it. [24:38.000 --> 24:42.940] Likewise, vehicles may send a negation DENIM to report that an event has ended. [24:46.360 --> 24:51.720] As I said before, both CAV and DENIM are signed. The proposed certificate system in CAV [24:51.720 --> 24:57.120] is a little bit bonkers in my mind, and I'll describe it later. But the key point here is the [24:57.120 --> 25:02.680] messages are signed. They're not encrypted because CAVs don't join networks in the traditional sense. [25:02.780 --> 25:07.700] Because there's no network joining, it's all up to the CA and DEN basic services to verify [25:07.700 --> 25:13.020] the validity of all received messages. This could be problematic for a lot of reasons. [25:13.280 --> 25:17.160] It seems like it's going to be really easy to jam a given vehicle by just spamming out messages [25:17.160 --> 25:21.960] near it. Likewise, if an attacker could fuzz the basic service and find a message that would crash [25:21.960 --> 25:26.200] it, then there's little resiliency against potentially harmful messages within this [25:26.200 --> 25:31.100] environment. It wouldn't even matter if the vehicle was part of the network because it's [25:31.100 --> 25:35.940] up to the receiver to determine if the message is valid or not, if it's from an actual member [25:35.940 --> 25:42.860] of the network or from an actual vehicle, sorry. There's also no nonce values in CAM and DEN, [25:42.860 --> 25:48.140] so you've got your standard risks of replay attacks there. In these future networks, some [25:48.140 --> 25:52.220] of the information contained within CAM will be used within the intelligent roadway systems for [25:52.220 --> 25:57.020] deciding things like traffic flow. So say you're an ambulance, the traffic light behavior might [25:57.020 --> 26:02.240] automatically be updated to favor traffic coming from your direction. So why not just continually [26:02.240 --> 26:07.520] replay a packet capture of an ambulance? The closest thing to nonce values that's included [26:07.520 --> 26:13.880] already is timestamps. And these, in my mind, are kind of weirdly done as well. Epochs weren't good [26:13.880 --> 26:20.320] enough for these guys. What they've gone for is a system whereby the time from the start of 2004 [26:20.320 --> 26:27.820] is taken in milliseconds, and then it's divided by two to the power of 16, or 65,536, which is [26:27.820 --> 26:32.100] coincidentally a touch over the number of milliseconds in a minute. The remainder is [26:32.100 --> 26:37.440] then untransmitted. So whilst you could kind of use this in your application as a nonce value, [26:37.440 --> 26:41.060] you'd have something that could be replayed roughly every minute or so, depending on your [26:41.060 --> 26:46.280] tolerances. But yeah, this slightly weird timeliness metric makes it very hard to discern [26:46.280 --> 26:51.760] the liveliness of messages at a glance. So go ahead with those replay attacks. Another issue [26:51.760 --> 26:55.840] stems from the automatic forwarding of DENIM if the receiving vehicle is within the area of [26:55.840 --> 27:02.980] relevance. Like I mentioned, DENIM describe an event. Vehicles can automatically retransmit [27:02.980 --> 27:07.660] received DENIM. So now something interesting about these cab networks is that a mechanism [27:07.660 --> 27:13.220] is proposed to exist for detecting and punishing malicious behavior. The details of it aren't [27:13.220 --> 27:17.820] really specified in any great detail, but the general gist of it is that nodes can automatically [27:17.820 --> 27:22.980] report that certain vehicle sending out malicious data with the vehicle being identified by its [27:22.980 --> 27:28.360] signing certificate. It's unclear how many reports are needed to trigger a ban in the network. [27:28.400 --> 27:33.240] But yeah, after a certain threshold of reports are hit, a vehicle certificate will be temporarily [27:33.240 --> 27:43.180] rescinded. This means that other nodes won't see its messages as valid, and so will disregard them. [27:43.820 --> 27:51.300] So now, when a vehicle automatically forwards on a DENIM, it repackages the message. The sender ID [27:51.940 --> 27:57.620] that you received of the initial message is then replaced with the sender ID of the vehicle that's [27:57.620 --> 28:03.420] forwarding on the message, and it's re-signed using the re-sender certificate. And I mean, can you see [28:03.420 --> 28:07.960] where I'm going with this? Say the threshold of reports was five. If you could have five vehicle [28:07.960 --> 28:13.220] nodes that you control send out DENIM-containing malicious data near a target, it in theory would [28:13.220 --> 28:17.960] just repeat them all on. That vehicle would hit the ban threshold quite easily and would be banned [28:17.960 --> 28:23.140] from the network. Suddenly, it's denied access to the CAV network. Generally, I think that [28:23.140 --> 28:26.960] mechanisms such as automatic bans need to be carefully considered because there's, you know, [28:26.960 --> 28:36.760] there's a real potential for abuse in there. So how do we transmit these CAM and DENIM? [28:37.980 --> 28:42.180] Ad-hoc networking is required for the CAV networks because of the node's tendency to move around [28:42.180 --> 28:48.520] quite a bit at high speeds. The idea of having passing vehicles connect to RSUs as they go past [28:48.520 --> 28:53.360] has been floated, but it was written off because there wouldn't be sufficient time, apparently. [28:53.360 --> 29:00.680] I'm not sure how fast people think future cars are going to go, but... So I must apologize, it's now [29:00.680 --> 29:05.700] time for acronym o'clock. I'll try and make this as clear as possible, but if you're confused at all, [29:05.700 --> 29:10.460] just ask me questions afterwards and hopefully I can explain it a bit better. So to create these [29:10.460 --> 29:17.960] ad-hoc networks, the usage of 802.11p standard and OCB mode is proposed. So what's an 802.11p OCB? [29:18.520 --> 29:24.940] 802.11 is an IEEE standard for network access control. It provides the authentication mechanisms [29:24.940 --> 29:30.000] for devices wishing to join a LAN or WLAN, as well as allowing for things like network [29:30.000 --> 29:35.400] decongestion to automatically take place. It's the stuff your home Wi-Fi network probably uses. [29:35.620 --> 29:40.660] So on top of the initial standards, it's 802.11p, which has been specifically designed for vehicle [29:40.660 --> 29:46.960] networks. It's licensed for use in the US's WAVE systems and in Europe's ITS G5 communication [29:46.960 --> 29:52.900] networks. It's been allocated the frequency band of 5.9 gigahertz. It's all fairly standard so far, [29:52.900 --> 29:58.400] but we need to have ad-hoc networks. My home Wi-Fi isn't ad-hoc. I need to connect devices to it. [29:58.400 --> 30:05.180] How does this work with these cars? So in this case, the 802.11p is being used in OCB mode, [30:05.180 --> 30:11.280] which means outside context of BSS or basic service set. Basic service set refers to the [30:11.280 --> 30:16.420] collection of things which can communicate with each other when in 802.11 network. [30:16.420 --> 30:20.360] When you join things to your home Wi-Fi network, they become part of the BSS. [30:20.560 --> 30:25.740] And then messages sent within the network are tagged with a BSS ID or basic service set ID, [30:25.740 --> 30:30.340] which marks them as belonging to the WLAN, so that all the nodes know if they're actually coming [30:30.340 --> 30:35.500] from something within the network and should be, you know, something they should bother with or not. [30:36.600 --> 30:42.440] In 802.11p OCB mode, we don't want any of that. We want everything to be able to transmit to [30:42.440 --> 30:47.500] everything else with no need to join the network. This allows for the truly ad hoc networking, [30:47.500 --> 30:52.480] which is required for CAM and DENIM to just be spat out and have everyone listen to them. [30:52.760 --> 30:56.740] No authentication is required to be able to transmit within these new networks. [30:56.740 --> 31:00.620] So it's up to the receiver to investigate the signing certificate and assess if the [31:00.620 --> 31:05.600] messages are valid or not. But also, because there's no joining to a network, there's no [31:05.600 --> 31:10.120] inbuilt decongestion, apart from some basic polling and automatic rate adjustment. [31:10.120 --> 31:13.160] Can you see where that might lead to some problems? [31:14.640 --> 31:19.580] If you said denial of service, you'd be right. What we've got here is the frequency allocations [31:19.580 --> 31:27.580] for ITSG5. The EU has provided permissions for ITSG5 transmissions within the 5.47 to 5.925 [31:27.580 --> 31:33.680] gigahertz range. The nice big, you see that nice big band on the left of the diagram? That's for [31:33.680 --> 31:39.420] broadband radio access networks, radio local area networks, and wireless local area networks. [31:40.340 --> 31:45.640] The key point for this is that you need to make use of dynamic frequency selection to avoid [31:45.640 --> 31:51.220] co-channel interference if you want to transmit in that range, which, since our CAVs networks [31:51.220 --> 31:56.360] aren't going to be connecting to the WLAN in the traditional sense, they cannot. So basically, [31:56.360 --> 32:00.680] you've already limited yourself from using a large chunk of the bands you've got available to you. [32:00.840 --> 32:06.080] Next up, you've got your little DSRC band in the middle. Well, that's not for ITSG5, [32:06.080 --> 32:12.760] so we can't use that. On the far right, we've already got a little band 5.905 to 5.925 gigahertz [32:12.760 --> 32:18.920] that's reserved for future use. So basically, the CAV networks are only left with 5.88 to 5.905 [32:18.920 --> 32:24.840] gigahertz ranges. And I hear there's a lot of cars in general, like there's a lot of them, [32:24.840 --> 32:29.020] they tend to all get together on these big stretches, and there's just a lot of them all [32:29.020 --> 32:34.940] talking at once. So and then there's also there's going to be like a shit ton of sensors on top of [32:34.940 --> 32:43.590] that, too. It doesn't seem like it's going to go well, really. So the proposed ad hoc networks in [32:43.590 --> 32:48.270] CAV networks are pretty unique, because it removes the issues from everything having to be joined to [32:48.270 --> 32:52.830] the network. And there's a certificate infrastructure in place, you can still verify the validity and [32:52.830 --> 32:58.210] integrity of received messages, at least. But that's the problem. When people aren't having [32:58.210 --> 33:03.190] to join a network, it means anyone can transmit, you got to process every single message you [33:03.190 --> 33:07.570] receive to work out if it's valid or not. I think that in these future CAV networks, denial of [33:07.570 --> 33:12.610] service attacks are going to be a real big issue, both on the frequency jamming front, but also from [33:12.610 --> 33:17.870] inducing the vehicles to process large quantities of junk messages. It doesn't even have to be [33:17.870 --> 33:22.270] junk, really. With the automatic forwarding of denim, you wouldn't need to have many cars in an [33:22.270 --> 33:27.710] area to get a good packet storm going. If we decide to go with the scenario whereby roadside units can [33:27.710 --> 33:32.930] be used to teleoperate autonomous vehicles, it's going to go kind of badly. It just does not seem [33:32.930 --> 33:39.510] like a good idea. Ideally, no vehicle should need to be connected to the CAV networks to operate. [33:39.510 --> 33:43.770] What's being joined would increase the efficiency of operations, each vehicle should be capable of [33:43.770 --> 33:53.790] operating without receiving any data from external sources. So now I'm going to finally talk about [33:53.790 --> 33:58.930] the proposed usage of public key infrastructure and vehicle certificates. The European Commission [33:58.930 --> 34:05.050] has proposed an entire public key infrastructure or PKI for the CAV networks. In their proposals, [34:05.050 --> 34:10.630] they're keen to stress that it's just a proposal, not gospel. But honestly, it's fairly standard [34:10.630 --> 34:15.010] stuff really in the proposal. At the top, you've got your route certificate authority and the [34:15.010 --> 34:20.150] proposals describe in great detail how to physically secure these. There's fairly standard encryption [34:20.150 --> 34:25.070] schemes, you know, they're making use of AES 128. I'm not going to go into too much details on the [34:25.070 --> 34:33.230] PKI since it's all fairly standard from what I could tell. The vendors will have their own [34:33.230 --> 34:39.010] which they'll use to sign vehicle sets before the vehicle is sold. These preloaded sets are [34:39.010 --> 34:46.010] known as enrollment credentials. Once a vehicle is sold now on the road, it uses its [34:46.010 --> 34:51.150] enrollment credentials to request access tokens, which are also known as pseudonyms. And this [34:51.150 --> 34:57.330] request goes via the roadside units and the pseudonyms are returned via the roadside units. [34:57.330 --> 35:04.410] So pseudonyms are where things get really weird in my mind. The creator of the cab networks heard [35:04.410 --> 35:08.730] that privacy is a good thing, and they want to maintain it within these networks, which you know, [35:08.730 --> 35:14.610] so far so good. It's a good idea. They then decided that it would be bad for vehicles to [35:14.610 --> 35:19.910] transmit a unique identifier, because then someone could track them. I think they forgot [35:19.910 --> 35:26.750] that license plates are a thing, but let's put that aside for now. When a vehicle uses its [35:26.750 --> 35:32.030] enrollment credentials to request pseudonyms, it's given a pool of 100 of them. These are valid [35:32.030 --> 35:36.930] for a period of one week. The pseudonyms are used to sign all the cam and denim that the vehicle [35:36.930 --> 35:42.170] sends out, so they can be verified. Pseudonyms are designed to be rapidly changing. On the slides, [35:42.170 --> 35:46.210] I've got the recommendations that come from the European Commission on when you should cycle [35:46.210 --> 35:52.570] pseudonym. And they're kind of weird. So when you start the car, you cycle to a new pseudonym. [35:52.570 --> 35:58.330] You change again after driving in the region of 800 to 1500 meters, then again somewhere after [35:58.330 --> 36:03.810] two to six meters, then again after 15 kilometers. And it's just so arbitrary. Like, why are we [36:03.810 --> 36:08.930] switching between distance and time? Like, it's weird. But potentially, you could be cycling [36:08.930 --> 36:13.710] through quite a lot of them on one road trip. And you've got a pool of 100 pseudonyms to use, right? [36:13.710 --> 36:18.610] And that's got to last you a week. There's a bit of disparity on what happens when you run out. [36:18.870 --> 36:22.470] According to Etsy, you should request a new pool of 100 once you run out. [36:22.570 --> 36:26.610] The European Commission, however, states that you can just reuse your pool of 100 so long as [36:26.610 --> 36:31.590] they're still within the validity period. But not everyone is always in range of the infrastructure [36:31.590 --> 36:36.190] needed to get more pseudonyms. Because of this, it's possible for vehicles to be preloaded with [36:36.190 --> 36:42.110] up to three months' worth of future dated pseudonyms. I mean, what are the practicalities [36:42.110 --> 36:47.430] of pseudonym cycling? When a vehicle cycles to its next pseudonym, it also needs to update its [36:47.430 --> 36:52.590] IP address. Otherwise, you could trivially track the vehicle for these changes. [36:52.630 --> 36:57.570] The standards documentation recommends the usage of stateless address auto-configuration, [36:57.570 --> 37:05.910] as described in RFC 4862. So RFC 4862 provides a framework for devices in a network to automatically [37:05.910 --> 37:10.650] configure themselves using a mixture of information being advertised by a router [37:11.190 --> 37:16.350] and from locally available information. This allows the nodes to communicate directly between [37:16.350 --> 37:20.350] each other without needing to go through a router, which is appropriate here. [37:20.930 --> 37:26.450] CAVs are intended to use IPv6 addresses. As this address space is quite large, there's a low risk [37:26.450 --> 37:33.370] of collision in the pseudo-randomly generated IPv6 addresses created using RFC 4862. But to avoid [37:33.370 --> 37:40.450] collision, RFC 4862 nodes do advertise their proposed new IPv6 addresses and give neighbors [37:40.450 --> 37:44.870] the chance to respond if they've already claimed them. So what's to stop an attacker using this [37:44.870 --> 37:48.910] to track a vehicle's IP address changes? I mean, not much really, so long as you were keeping near [37:48.910 --> 37:53.430] the vehicle. Or just look at the MAC addresses. These are not cycled at the same time as the IP [37:53.430 --> 37:57.930] addresses. Or more interestingly, what if you always claimed that you were already using the [37:57.930 --> 38:03.350] IPv6 address that it's advertising? Like, could you just make a little box that you can tape onto [38:03.350 --> 38:10.010] the vehicle, a little address denial box, which automatically lays claim to any address being [38:10.010 --> 38:14.690] advertised by the vehicle? Again, I think that just denial of service attacks are going to be [38:14.770 --> 38:21.930] a big thing in these future CAV networks. In my mind, pseudonym cycling seems more likely to enable [38:21.930 --> 38:26.890] abuse than to protect privacy. As I mentioned before, there are provisions for vehicles to be [38:26.890 --> 38:31.610] automatically banned from the CAV network via their certificate being revoked. The certificates being [38:31.610 --> 38:36.150] revoked would potentially just be their pseudonym. So the attacker can either reduce the pseudonym [38:36.150 --> 38:41.990] cycle via normal driving or potentially manipulate their system into cycling on demand. It's an ideal [38:41.990 --> 38:47.090] method of ban evasion, really. To combat this, it's been suggested that hardware-trusted [38:47.090 --> 38:51.770] components could be used to provide more robust banning mechanisms. This could be used to wipe the [38:51.770 --> 38:56.390] entire pool being stored on the vehicle. But then you still got the problems I talked about earlier, [38:56.390 --> 39:01.290] whereby you can just cause a vehicle to be unjustly banned from the network. Also, I'm kind of always [39:01.290 --> 39:09.130] wary of placing too much trust in anything that's sold as unhackable. It just seems like a [39:09.130 --> 39:14.090] bull's eye on it. And there's nothing to say that an attacker would need to control multiple [39:14.090 --> 39:18.550] vehicles even to be able to gain malicious levels of influence within the CAV networks. [39:18.950 --> 39:23.750] I mean, Tesla's already had issues with all parts of head units appearing on eBay unwiped. [39:23.810 --> 39:29.250] It's likely that whatever contains the CAV, the CA slash then basic service will appear soon [39:29.250 --> 39:34.410] enough, harvested from written off cars by unscrupulous garages. Just pick up a couple [39:34.410 --> 39:38.750] of these and you're good to go with your civil attacks. They might come preloaded with three [39:38.750 --> 39:42.990] months of certs, or maybe they'll still be able to gain new certs from the network. It might not [39:42.990 --> 39:46.490] be the case that the vendor knows the car was written off so its enrollment credentials were [39:46.490 --> 39:51.050] not revoked. You know, use these to your heart's content to avoid bans and juice bans and others, [39:51.050 --> 39:55.630] flood networks and malicious data, whatever you feel like really. Or you could use these to send [39:55.630 --> 40:00.790] out your CA slash then basic service crashing messages that you know you've developed previously [40:00.790 --> 40:05.990] by fuzzing the basic services. Or if you could gain access to multiple pseudonyms at once, [40:05.990 --> 40:10.690] use them to simulate other vehicles. You got someone tailgating you? Start sending out spoofed [40:10.690 --> 40:14.830] CAVs signed with one of your other pseudonyms, simulating a vehicle following behind you. [40:14.830 --> 40:19.370] The tailgater's car might think there's a car in that space already and automatically fall back. [40:21.760 --> 40:26.660] The final major component of the CAV ecosystem that I want to talk about is test beds. [40:26.820 --> 40:31.960] These are regions of roadway which vendors can test their new products on. They can include a [40:31.960 --> 40:36.560] mixture of private roads and public roads, and they will be absolutely covered in sensors so [40:36.560 --> 40:42.080] vendors can receive their high quality trials data. In current proposals, vendors will be able [40:42.080 --> 40:51.880] to buy access to data from specific regions of test beds at specific times. [40:51.940 --> 40:57.140] It's been suggested this could be facilitated using a web interface which comes with its own [40:57.140 --> 41:02.280] issues really. I mean generally the security of these test beds is going to need to be very high. [41:02.280 --> 41:06.220] Vendors will be testing new products which competition might want to get a sneak peek of. [41:06.220 --> 41:10.520] There's also the very real possibility that the vehicles being tested on these test beds might not [41:10.520 --> 41:15.660] yet have the most robust security in place. So it's important that these potentially insecure [41:15.660 --> 41:22.500] vehicles cannot be used as vectors into the rest of the CAV network. I'm now going to move on to [41:22.500 --> 41:26.740] talk about some of the threats that F-Secure thinks CAV networks will face and talk you through a [41:26.740 --> 41:31.760] couple examples of how these could be actualized. If this is an area of interest to you, I'd recommend [41:31.760 --> 41:36.040] reading our full white paper as it goes into much more detail about the type of assets which [41:36.040 --> 41:41.580] will be considered within CAV networks, as well as talking about specific threat actor groups [41:41.580 --> 41:53.930] including APT32. So here's a rough overview of the threat actors that are likely to target the CAV [41:53.930 --> 42:01.890] networks. At the bottom we've got the most prolific type of hacker, the script kiddie or skiddie. [42:02.190 --> 42:06.570] These are just people sat at home, they're just playing around, they downloaded something off [42:06.570 --> 42:10.090] the internet, they've got their low orbit iron cannon, they want to have a play with it, they're [42:10.090 --> 42:16.710] trying to impress their mates. They are low skill, but they are prolific. And they might target the [42:16.710 --> 42:22.230] CAV networks just because, you know, it seems a bit for the lulz, seems fun. Above this tier, [42:22.230 --> 42:27.370] you've got the motivated individuals or hacktivists. These guys actually know what [42:27.370 --> 42:32.670] they're doing. They'll quite often be using free tools, or maybe they found some bespoke tools, [42:32.670 --> 42:36.750] maybe they even wrote some stuff on their own. But they tend to be more disgruntled people who [42:36.750 --> 42:43.890] are ideologically motivated. So like you get the people who are hacking SeaWorld, Sealand, [42:43.890 --> 42:47.330] they won in the US because they were pissed off about the treatment of orcas. [42:47.470 --> 42:50.810] Yeah, it's just people trying to rebel against something that they don't like. [42:51.550 --> 42:55.870] Above this tier, you've got the kind of fairly standard criminal groups. They tend to be going [42:55.870 --> 43:01.470] for financial gain. This could be just a small group that's created, say, a piece of ATM malware. [43:01.470 --> 43:05.310] Like they often they might just have one techie who creates stuff and then the rest of the money [43:05.310 --> 43:10.370] mules that go around picking up the cash, that sort of thing. They tend to have more cash available [43:10.370 --> 43:16.630] than the tiers below. So they can actually buy bespoke tools on the dark market, or, you know, [43:16.630 --> 43:21.110] fund someone to create tools that are a bit more interesting. Above that tier, you've got serious [43:21.110 --> 43:26.230] organized crime groups. These guys have a lot of technical know-how, or at least access to people [43:26.230 --> 43:31.450] and the technical know-how. They've also got access to large amounts of resources, so they can [43:31.450 --> 43:36.070] kind of do what they want, really. You know, they're going to be able to fund people to research [43:36.070 --> 43:40.610] zero days that are targeting certain technology that they're interested in, all that sort of thing. [43:41.130 --> 43:46.270] Above this, you've got the nation-state threats. So these guys, their aim is not always financial, [43:46.270 --> 43:51.010] although it can occasionally be. These guys tend to go more for intelligence gathering, [43:51.010 --> 43:57.250] industrial espionage, economic destabilization. They tend to be using advanced tools. You know, [43:57.250 --> 44:01.910] they might even be stealing tools from governments. They'll be using endless zero days. [44:02.050 --> 44:07.110] Generally, there's not too many of them, but when they target you, you're going to have a bad time. [44:07.110 --> 44:11.570] They're very hard to deal with because they have so many resources and technical expertise [44:11.570 --> 44:16.570] at their disposal. And again, we think that people at all these levels are likely to target [44:16.570 --> 44:22.630] the CAV networks. And frankly, there's no way to keep everyone out. People who have the absolute [44:22.630 --> 44:27.250] dedicated skills and resources, they probably will try and figure a way, they probably will [44:27.250 --> 44:31.630] be able to find a way in. But it's important to keep these lower tiers out. You know, you [44:31.630 --> 44:37.610] shouldn't be able to have the skiddy take down your networks. It's not good. The best way to [44:37.610 --> 44:42.450] counter it really is to just have good detection. So even if a nation-state was able to do something [44:42.450 --> 44:46.590] to your network, by being able to detect it immediately, you can start to go into damage [44:46.590 --> 44:50.910] control mode, you can start to ignore data coming from that node because you know it's malicious, [44:50.910 --> 44:57.370] that sort of thing. There's a whole variety of assets that these threat actors are likely to [44:57.370 --> 45:02.270] be targeting within the networks for various different, you know, end goals. So you've got the [45:02.270 --> 45:06.650] physical ones, which are the obvious things like you've got vehicles, you've got the roadside units [45:06.650 --> 45:13.050] and sensors, but you could also target, say, a garage so that you could perhaps automatically [45:13.050 --> 45:18.390] lift data of everything that comes into the garage. Or the backend servers, if the car is still [45:18.390 --> 45:24.270] connected to the vendor servers in some way, could you pivot from the vehicle into the vendor [45:24.270 --> 45:29.670] servers and, you know, do your cyber crimes through there. We've also got the electronic vehicle [45:29.670 --> 45:34.330] charging stations. Those are an interesting target. If you could break those, you could cause quite a [45:34.330 --> 45:40.790] bit of harm, cause a lot of people to be stranded. You've got your public key infrastructure facilities, [45:40.790 --> 45:44.470] like the actual buildings they're stealing them at. If you could get in and steal, you know, the [45:44.470 --> 45:50.490] route certificate, you can have some fun with that. On the digital front, you've got sensor data, [45:50.490 --> 45:56.370] regional events data, so things like weather, you've got your traffic data. You've also got personal [45:56.370 --> 46:01.390] information probably carried upon these vehicles, like there's the classic of buying old GPS units [46:01.390 --> 46:05.670] and, you know, pressing the home button because, you know, people have programmed home into them. [46:05.670 --> 46:10.350] Or if you steal a car, you just tell the GPS to send you home and, you know, you can get in like that. [46:11.670 --> 46:16.290] Within things like testbed results, there's also likely to be financially sensitive information, [46:16.290 --> 46:20.690] or even intellectual property. People could actually get any interesting data off of these [46:20.690 --> 46:25.690] vehicles, perhaps off the infotainment systems. There might be some proprietary systems that [46:25.690 --> 46:31.130] an attacker could gain information about. On top of these assets, you've also got the kind of [46:31.130 --> 46:38.330] intrinsic reputational assets. So things like Tesla's been getting hammered a bit in the US [46:38.330 --> 46:43.770] news recently, because of stuff like people putting autopilot on and the car driving into a barrier, [46:43.770 --> 46:48.770] or I can't remember which company it was, was trialing a couple years back, one of their [46:48.770 --> 46:54.810] self-driving vehicles that killed a pedestrian. And, you know, it's causing reputational harm [46:54.810 --> 47:05.240] is a real risk in these areas, you don't want that. So as an example threat, [47:05.960 --> 47:11.480] I'm going to talk about Bob the Grumpy Guy. Bob lives in a small village, which has a section of [47:11.480 --> 47:16.140] smart roadway running through it. He's upset by the speed at which cars travel through the village, [47:16.140 --> 47:21.080] and he wants them to slow down. He's read online that the roadside units placed every 500 meters [47:21.080 --> 47:25.160] along the roadside control the speed of which cars drive, so he decides he's going to target them. [47:25.400 --> 47:29.980] He goes online and he spends some time learning about hardware security. One night he takes his [47:29.980 --> 47:35.460] laptop and a crowbar to an RSU, which is hidden behind some trees. The RSU is in a locked cabinet, [47:35.460 --> 47:40.520] but Bob manages to leave it open with his crowbar. The physical tamper detection system on the RSU [47:40.520 --> 47:45.220] detects the unexpected opening of the door and sounds an alarm. An alert is sent to the cab [47:45.220 --> 47:51.440] network requesting investigation. The loud alarm startles Bob and he runs back home. Based on his [47:51.440 --> 47:55.480] experience with the roadside unit, Bob decides he's going to try and use other devices to get [47:55.480 --> 48:01.080] to the RSU. His neighbor, conveniently, has bought a brand new intelligent vehicle, which connects to [48:01.080 --> 48:06.500] these RSUs. Bob does some research on his neighbor's new car and he discovers that the car broadcasts [48:06.580 --> 48:11.180] a hotspot which drivers can connect their phones to. Bob reads a web forum and finds unofficial [48:11.180 --> 48:16.360] reports saying the technology used for this hotspot has an abusable authentication vulnerability. [48:17.420 --> 48:22.600] As Bob's house is within the hotspot's range, he exploits the vulnerability to connect to the car [48:22.600 --> 48:26.920] from his bedroom. Using his knowledge of network security, he's able to pivot through the car's [48:26.920 --> 48:31.720] internal networks until he finds the service which allows it to connect interface with the RSU. [48:31.820 --> 48:36.400] After some trial and error, he learns how to send status update messages to the nearby RSU. [48:36.580 --> 48:40.640] Bob uses these to send the RSU many reports that the vehicle is covered, [48:40.640 --> 48:45.640] sorry, that the road is covered in black ice. The RSU collates these reports and does not correctly [48:45.640 --> 48:51.080] identify that they have all come from a single vehicle. The RSU updates its models for that [48:51.080 --> 48:55.180] area with the presence of black ice and decides that the speed limit in that area should be [48:55.180 --> 48:59.880] lowered. The dynamically updated road signs along the village now display half the previous speed [48:59.880 --> 49:05.480] limit. Autonomous vehicles automatically adhere to them, and most manually driven cars do. [49:05.620 --> 49:10.840] Bob is happy once again. His village is nice and quiet and has slow cars going through it. [49:12.880 --> 49:18.480] Next up, we'll talk about an imaginary threat from a malicious nation state. [49:18.680 --> 49:23.600] So the country of Zeron spends a lot of time comparing itself to its neighbor Nerund. [49:23.600 --> 49:29.060] Nerund has a highly developed ITS roadway system with many internationally acclaimed [49:29.060 --> 49:33.560] CAV developers based in the country. Zeron decides it would like to have more developed [49:33.560 --> 49:38.860] ITS roadways too, but it doesn't have the resources to fund the extensive CAV development work Nerund [49:38.860 --> 49:43.780] has done. Zeron decides corporate espionage would be a much more cost-effective measure [49:43.780 --> 49:51.700] for developing its technical capabilities. Zeron government engages APT32, a Zeron-backed [49:51.700 --> 49:56.160] hacking group. This group is tasked with stealing as much information on CAV as possible from [49:56.160 --> 50:01.780] companies in Nerund. The APT77 team decides their first move should be to gain access to [50:01.780 --> 50:07.140] the internal networks of Nerund Auto, the country's leading vehicle manufacturer. A spearfishing [50:07.140 --> 50:12.720] campaign is launched, and APT77 soon finds itself with footholds within various support functions of [50:12.720 --> 50:20.140] Nerund Auto. APT77 discovers Nerund Auto does not make use of network segregation. The group can [50:20.140 --> 50:24.940] move from an HR employee's computer to one belonging to the tech support team. This tech [50:25.490 --> 50:31.000] support team has access to the research and development team networks. Once APT77 gains [50:31.000 --> 50:36.060] access to Nerund Auto's R&D network, they're able to steal large amounts of research work, including [50:36.060 --> 50:41.320] plans for unreleased vehicles. The Zeron government is very happy with their information gathered by [50:41.320 --> 50:47.500] APT77. They ask APT77 to see if their foothold within the Nerund Auto networks can be [50:47.500 --> 50:52.540] leveraged to gain access to a given car. The group quickly discovers that through the remote upgrade [50:52.540 --> 50:57.640] functionality implemented in all Nerund Auto products, they may push malicious code to arbitrary [50:57.640 --> 51:04.380] vehicles. The Zeron government provides APT32 with details of a Nerund Auto brand vehicle [51:04.380 --> 51:10.740] owned by a key Nerund politician. The APT77 group confirms they can push code to this vehicle. [51:10.740 --> 51:16.720] As the code comes from the trusted manufacturer, it is not evaluated. The APT group is able to cause [51:16.720 --> 51:22.060] the politician's car to take arbitrary actions. It's not really what you want. [51:24.120 --> 51:28.780] So, I mean, these are all proposals at this point. They're not things that are existing [51:28.780 --> 51:33.380] in the real world in this state quite yet, thankfully. What can we do at this point? [51:35.680 --> 51:39.780] Generally, I think we need a lot more security research within this area. [51:40.700 --> 51:45.140] There's still plenty of time to address them. I mean, especially with the UK government's [51:45.140 --> 51:49.580] idea of this being the next 10 years. And hopefully the outputs of this project and [51:49.580 --> 51:54.200] the other ZenZip projects will help to inform the future decision-making process. [51:56.180 --> 52:01.220] So, while we were going over all these standard documents, I'll just count the amount of times [52:01.220 --> 52:06.960] that I read security is out of scope for this document or security will occur at another level. [52:07.700 --> 52:11.460] People really need to stop doing this. You need to consider the security at every level, [52:11.460 --> 52:16.160] in my mind, to make sure that the systems are kind of holistically as secure as possible. [52:16.840 --> 52:20.080] I also think they should take more input from cybersecurity people. [52:20.320 --> 52:24.940] I mean, generally, you, dear watcher of this talk, take a look at these technologies yourselves. [52:25.160 --> 52:30.140] The 802.11p OCB mode seems to be very under-researched. There's not that much information [52:30.140 --> 52:34.260] available on it. But it seems super weird. It seems like there's going to be a lot of potential [52:34.260 --> 52:39.840] for abuse. And it seems like you can do a lot of cool stuff with it. Incidentally, if you happen [52:39.840 --> 52:45.980] to have access to any tech that actually can use it, is already set up to communicate over 802.11p [52:45.980 --> 52:51.560] OCB mode, please do reach out to me on Twitter or email. F-Secure is quite keen to get hands on [52:51.560 --> 52:57.500] with it. We want to collaborate. Or, you know, just generally chat about 802.11p. It's interesting [52:57.500 --> 53:04.500] stuff. I think the testing at scale is going to be a really big problem. These networks are going [53:04.500 --> 53:08.960] to be absolutely huge. They're probably going to become part of our critical national infrastructure. [53:08.960 --> 53:13.800] And they're going to get popped, for sure, at some point. But we still need to remove the low [53:13.800 --> 53:17.980] hanging through. We don't want the little script kiddies to be able to take bits of the network [53:17.980 --> 53:23.000] down. We don't want Bob to be able to mess with speed limits just because he's annoyed by the fast [53:23.000 --> 53:30.120] cars. And in the case that something does happen, a breach is detected, we need to be able to address [53:30.120 --> 53:35.560] them. So we were proposing a system whereby we can detect the point at which malicious data has [53:35.560 --> 53:42.540] entered into the network. So this would be by re-signing your data at every point of transmission. [53:42.880 --> 53:48.000] So your vehicle, it signs the data when it sends it on, right? This ends up in the roadside units. [53:48.000 --> 53:53.460] The roadside unit collates all this data, and then it signs the bundle of data before it transmits [53:53.460 --> 53:59.020] it onwards to the data hub. Then the data hub collates all this information. And then you [53:59.020 --> 54:03.260] notice that something's a bit wrong or something's malicious. You can then look at the initial data [54:03.260 --> 54:08.120] and say, okay, well, the malicious data include this signed bundle come from the RSUs, that RSU, [54:08.120 --> 54:12.700] so it's come from that RSU. And then that RSU, you can work backwards and be like, okay, well, [54:12.700 --> 54:17.260] it's been signed by this vehicle. And it's just important to be able to backtrace the point at [54:17.260 --> 54:22.120] which the incident has occurred, so that you can try and prevent better things, these things from [54:22.120 --> 54:27.020] happening again in the future. Like if you notice it's a specific RSU, go investigate that RSU, [54:27.020 --> 54:30.840] work out how it got popped so that you can better protect the other nodes within the network. [54:33.500 --> 54:37.080] In general, I think that information sharing is going to be really important. [54:37.120 --> 54:41.580] There seems to be this thing of cybersecurity being a competitive advantage. You know, [54:41.580 --> 54:46.600] it's, it's, it's like considered IP almost that you know how to not get hacked. And I don't think [54:46.600 --> 54:50.920] that should be the case. I think there should be better information sharing between the vendors, [54:50.920 --> 54:57.140] and even between like research groups. Because if, say you had a phishing campaign targeting your [54:57.140 --> 55:02.220] organization as a vendor, it's likely that the attackers will also target similar vendors. [55:02.220 --> 55:06.220] So by sharing information between each other, you can be better prepared for these attacks to come [55:06.220 --> 55:10.800] in. And you know, if someone does manage to get into your network, you can share that information [55:10.800 --> 55:15.360] with other companies so that it doesn't happen to them either. I think you need to get, we need to [55:15.360 --> 55:19.640] get over seeing it as like a competitive advantage and just work more collaboratively in general [55:19.640 --> 55:26.980] together. So my conclusions for this are current proposals are not fit for purpose, they're going [55:26.980 --> 55:33.080] to be a nightmare of just denial of service and all sorts. Just don't, just don't, don't do that. [55:33.660 --> 55:37.300] There needs to be more considerations for cybersecurity when designing these systems. [55:37.300 --> 55:41.140] Stop passing the buck on cybersecurity or you'll make baby Jesus cry. [55:42.020 --> 55:45.400] There's a lot of weird shit in these proposals that people should look at more. [55:45.760 --> 55:52.360] AO211 POCB mode is weird shit. Pseudonyms are even weirder shit. And lastly, I'm never getting [55:52.480 --> 55:57.340] a connected autonomous vehicle if you can help, if I can help it. Like I don't even get ones [55:57.340 --> 56:02.060] with lane assist. I don't trust it at all. I appreciate I'm in the wrong industry to be saying [56:02.060 --> 56:10.500] that, but I don't trust it. So before we finish, I just want to give a few acknowledgements. [56:10.500 --> 56:14.320] I'd like to say thanks to my colleagues who contributed to this project. The main contributors [56:14.320 --> 56:20.660] were Joel, Rich and Terry, who all worked heavily on the project. I'd also just like to thank [56:20.660 --> 56:25.520] my colleague Kytan, who, although he's no longer with us, he provided a lot of support to me while [56:25.520 --> 56:32.140] I was working on this project. Surrey University also gave us quite a bit of advice on cab networks [56:32.140 --> 56:37.880] while we were doing our research work. I'd also like to thank Zenzik for funding this work and [56:37.880 --> 56:43.820] F-Secure for letting me work on it, and KFC for fueling my existence. I was very upset while they [56:43.820 --> 56:48.440] were shut in the UK due to the lockdown, but they've reopened now. Everything's wonderful again. [56:50.060 --> 56:56.080] So that's the end of my talk. I think we're doing questions in the chat now, or you can tweet me on [56:56.080 --> 57:02.740] Twitter. I mainly shitpost, so yeah, but go for it. Or drop me an email. I've got my email address [57:02.740 --> 57:08.460] there. Thank you for your time. Thanks for watching, and feel free to ask me any questions.