WEBVTT 00:00.000 --> 00:02.100 Thanks for tuning into my talk. 00:02.100 --> 00:04.500 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:12.520 So the title of my talk is Houston, we have a problem. 00:12.580 --> 00:19.260 I'm here today to talk to you about 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:29.620 First up, who am I? 00:29.640 --> 00:32.360 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:45.780 So you need to kind of know what all the components are before you can understand the overarching system. 00:45.880 --> 00:48.660 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:58.640 So who's likely to target them, with what resources and what kind of things they're going to be going after. 00:59.040 --> 01:04.200 I'll talk through some example scenarios of how an attacker might infiltrate the network and what to expect. 01:04.380 --> 01:08.240 Next up, I'll provide considerations for how we can improve the situation. 01:08.460 --> 01:14.000 And finally, the conclusions, which, spoiler alert, is mainly that everything is nightmare. 01:14.280 --> 01:19.020 Then we'll have some acknowledgments and time for questions, which I believe is going to be all types. 01:20.780 --> 01:22.180 So a little about me. 01:22.180 --> 01:23.680 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:31.380 I also worked as a falconer for a bit. 01:31.920 --> 01:38.940 After graduating, I worked for DSTL, which is a bit of the UK Ministry of Defence, then moved to MWR Info Security. 01:38.940 --> 01:42.460 That got purchased by F-Secure, so now I work at F-Secure. 01:42.600 --> 01:46.460 And I was the lead author on the bit of work that this talk is discussing. 01:46.820 --> 01:50.280 If you want to talk to me, you can find me on Twitter at Vic Harkness. 01:50.280 --> 01:56.120 Talk to me about falconry, facial recognition systems, biometrics, and network vehicle security. 01:58.300 --> 02:00.760 So an overview of the project. 02:00.760 --> 02:05.840 This package of work was done as part of the ZENZIC Cyber Feasibility Report Project. 02:05.840 --> 02:14.340 So the ZENZIC Cyber Feasibility Report Project aims to inform and advise the UK government on the security of future CAV and ITS networks. 02:14.340 --> 02:16.560 So I know I've said CAV a few times already. 02:16.560 --> 02:18.080 I'm going to expand on it now. 02:18.080 --> 02:21.320 CAV means connected and autonomous vehicles. 02:21.580 --> 02:29.540 ITS, they're referring to the same general concept. 02:29.540 --> 02:33.000 But some people prefer to say CAV, some prefer to say ITS. 02:33.020 --> 02:35.000 I think they're more commonly called ITS. 02:35.000 --> 02:37.700 And within the standards documents, they're called ITS. 02:37.780 --> 02:40.540 But ZENZIC prefers to call them CAV. 02:40.540 --> 02:43.260 So throughout this talk, I'll largely be calling them CAV. 02:44.380 --> 02:48.420 So as I'm sure you're aware, automated vehicles are becoming a thing. 02:48.620 --> 02:54.400 In the future, it's envisioned that most people will drive either hyperconnected vehicles or have an automated vehicle. 02:54.540 --> 02:59.040 To support this future, the creation of sensor-rich intelligent roadways has been proposed. 02:59.240 --> 03:01.820 The UK government wants to buy into this future. 03:01.920 --> 03:07.520 They don't necessarily want to be the first people to create these intelligent roadway systems, but they want to be the best to do it. 03:07.520 --> 03:11.000 They want the most robust roadways, and they want them to be the most secure. 03:11.220 --> 03:14.540 And the ZENZIC Cyber Feasibility Report feeds into this goal. 03:14.820 --> 03:19.220 So seven companies worked on the problem space, and ZENZIC created a summary report. 03:19.220 --> 03:24.020 This summary report went off to government to help decide what they should do about future roadways. 03:24.540 --> 03:33.280 So my team at F-Secure looked at the V2X, or vehicle-to-everything aspect of the problem, as well as considering how you might test these future networks at scale. 03:33.460 --> 03:36.860 But to understand the problem, we needed to look at the space as a whole. 03:36.920 --> 03:42.540 So our paper provides an overview of the entire space, as well as making recommendations on testing at scale. 03:42.960 --> 03:46.280 There should be a link to the white paper available by the time you're watching this. 03:46.280 --> 03:51.560 At the time of recording, it's not gone live yet, but I'm sure I can share it in the chat or something like that. 03:51.840 --> 04:07.300 As a quick note, the proposals we looked at for future cap infrastructure have been provided by the European Telecommunications Standards Institute, the International Organization for Standardization, and the European Commission. 04:07.300 --> 04:11.140 So it's a fairly Europe-centric presentation, I'm afraid. 04:11.140 --> 04:17.240 But there are very similar proposals in the US, and there's kind of a lot of equivalency between the proposals. 04:17.240 --> 04:20.700 So hopefully it's still useful for non-European people. 04:21.260 --> 04:28.700 But hopefully this talk and our white paper provide sufficient information for someone 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:45.460 Whilst our area of the project was dealing with the vehicles-to-everywhere communications, 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:52.480 They guide us to our destinations using maps. 04:52.480 --> 04:55.720 They advise us on the best route to take using traffic information. 04:55.940 --> 04:59.120 They advise us, they entertain us using audio and video. 04:59.260 --> 05:05.200 In the future, they will ease the burden of driving altogether by being able to autonomously navigate to our destinations. 05:05.380 --> 05:09.240 To facilitate this, vehicles contain complex internal networks. 05:09.500 --> 05:12.160 Future vehicles are more akin to computer networks. 05:12.200 --> 05:16.380 Lots of smaller computers all working on smaller parts of the task network together. 05:16.500 --> 05:26.920 So for instance, you could have one computer that's driving the infotainment system, another one that's driving the lights, but they all need to be connected so that the infotainment system can be used to control the lights, for instance. 05:27.380 --> 05:31.760 These future vehicles will be handling large amounts of data taken from a range of sources. 05:31.780 --> 05:39.340 Some of those are going to be external, like GPS data, traffic data, data coming in from the vendor, whoever you bought the car off. 05:39.340 --> 05:42.260 There's also internal data sources within the vehicle. 05:42.400 --> 05:48.940 So you've got your classic integrated sensors, like your speed sensors, your tire pressure sensor. 05:48.940 --> 05:58.320 But the more futuristic systems are going to have cameras, range sensors, like sonars to detect where there's nearby vehicles or detect if someone's walked in front of the car. 05:58.820 --> 06:05.560 And you'll also be taking inputs from the 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:17.540 So one of the proposals actually described a system whereby the car can automatically monitor the biometrics of the user. 06:17.840 --> 06:27.440 And so if the driver of the car was to, for instance, have a heart attack, the system would be able to automatically detect and communicate this and assumedly call an ambulance. 06:28.100 --> 06:32.320 But with all this data coming from a wide range of sources, how can you trust it? 06:33.100 --> 06:37.040 It's a given that attackers are going to be targeting the internal vehicle networks. 06:37.260 --> 06:48.820 I'm not going to talk specifically about data hygiene within internal vehicle networks, because I'm sure there'll be someone else at the car hacking village who knows a lot more about it than me and will be able to do a much better job than me of explaining it. 06:49.100 --> 06:52.000 But in general, I will say, handle the data with care. 06:52.160 --> 06:55.480 No component should place absolute trust in the data it receives. 06:55.660 --> 07:02.340 But really, it's up to you guys making these systems to decide how trustworthy components are and design your models based around that trust. 07:03.060 --> 07:12.700 Some of the sort of things that an attacker is likely to target are the vehicle sensors, they make a good potential entry point for introducing false or malicious data into the vehicle network. 07:13.040 --> 07:24.920 I mean, people are already playing around with the future systems, like people have been using adversarial examples to generate stickers they can put on road signs, which will cause the car to no longer classify the road sign correctly. 07:25.140 --> 07:30.220 So what was once a stop sign is now a speed limit sign, the car just drives straight through. 07:32.120 --> 07:37.280 Another thing the attackers might target are the entertainment and infotainment systems. 07:38.360 --> 07:43.820 They're another good route for introducing malicious data into or gaining access into connected vehicles. 07:43.920 --> 07:52.780 I mean, we're already getting familiar with the advanced infotainment systems, we're used to them having a touchscreen now to display maps to play with our music, all that sort of thing. 07:53.180 --> 08:05.260 In some of the CAV proposed documents, these systems are also going to be doing tourist information for you, you're going to drive past a mountain, and the car's going to start telling you what the mountain is, the history of it, all about it, for better or worse. 08:06.880 --> 08:22.000 Potentially, they're kind of similar to sensors in the attackers might try and manipulate data by and manipulate behavior, sorry, by inserting malicious data, such as incorrect traffic data, or try and use them as a point from which they could pivot to elsewhere within the car's internal network. 08:22.760 --> 08:28.740 The first thing I want to mention is applications, because you've got to have apps if you want to be futuristic with your system. 08:30.020 --> 08:36.460 So in the Envisioned Future Connected and Autonomous Vehicles, you'll be able to download apps from an app store, like how you would on your phone. 08:36.460 --> 08:39.060 And we all know how good that is for device security. 08:39.420 --> 08:44.800 There's little information so far on how these will actually look in terms of security and access permission models. 08:44.880 --> 08:49.940 Don't know if it's going to be like the Apple Store, where you've got to like have your app pre-approved before it can be uploaded. 08:50.120 --> 08:53.860 Or if it's going to be a bit more like the Android Store, where you can just kind of go for it. 08:54.020 --> 08:56.160 There's no advice on this at this point. 08:56.440 --> 09:01.360 But it does seem like they're going to be an excellent route to break into a vehicle's internal network. 09:01.620 --> 09:05.400 I mean, they might end up being used as part of a jailbreaking solution for the vehicles. 09:06.020 --> 09:15.960 So with Teslas, it turns out that when you buy an upgrade for a Tesla, it can be remotely enabled, you don't actually need to go to the garage to get it upgraded. 09:17.160 --> 09:29.400 So when they had the massive fires in California a few years back, Tesla remotely pushed free battery updates to cars within the area of effect, so that they could escape easier, or the drivers could escape easier. 09:29.400 --> 09:32.820 But the Lord Elon giveth, the Lord Elon taketh away. 09:32.840 --> 09:40.780 There's been lots of cases of people buying secondhand Tesla models 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 --> 09:59.540 The vehicles ideally should be able to detect this and handle it in some way. 09:59.640 --> 10:04.200 Because it's not really the best solution if it just crashes into a wall because it thinks it's the road, Wile E. 10:04.200 --> 10:05.260 Coyote style. 10:05.680 --> 10:13.060 Perhaps it'd be more appropriate for a vehicle that detects anything 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:18.860 Going to be really annoying and not answer that. 10:18.860 --> 10:22.080 Instead, I'll move on to talking about personal stations. 10:27.500 --> 10:31.420 So the Etsy standards propose the use of personal stations. 10:32.460 --> 10:37.380 These are little handheld devices which are designed to be connected to the overarching cab networks. 10:37.420 --> 10:43.780 The exact purpose of them is unclear, but they seem to basically be mobile phones, like you can install apps on them. 10:43.940 --> 10:48.740 It's suggested they're used by low-speed users of networks such as pedestrians and cyclists. 10:48.940 --> 10:56.160 I've got a few of the suggestions on the slides, like using them to check bus times, use them to update bus times, use them to look at maps. 10:56.160 --> 10:57.820 They're basically mobile phones. 10:58.140 --> 11:03.100 Maybe this will just morph into an app that you can put on your own mobile phone so you don't have to carry something extra around. 11:03.100 --> 11:03.940 Who knows? 11:04.440 --> 11:07.820 As far as security goes, I'd say treat them like mobile phones. 11:07.900 --> 11:13.580 They're likely to be an easy target for because they're quite small, so you want them to be lockable and remotely trackable. 11:13.940 --> 11:20.780 You also, again, don't want to be completely trusting of data coming from them because there's a high risk of compromise if they are akin to mobile phones. 11:23.310 --> 11:28.270 So the envisioned future intelligent roadways will need lots and lots of supporting infrastructure. 11:28.590 --> 11:36.330 Infrastructure to support the connections between connected vehicles, infrastructure to support the automated decision-making capabilities of automated vehicles. 11:36.730 --> 11:40.250 But not all vehicles will be connected or automated in the future. 11:40.330 --> 11:44.890 You're still going to get the people like me who are scared of new technology and want something more old-fashioned. 11:45.170 --> 11:49.110 Unfortunately, you can't quite ignore us weirdos who refuse to join the borg. 11:49.110 --> 11:55.950 You still need to know where the old-fashioned vehicles are so that they can be incorporated into your traffic models or avoided by your automated systems. 12:00.330 --> 12:10.730 Extensions of current CCTV and radar system capabilities, when augmented by additional sensors, could be sufficient to track old-fashioned vehicles as though they were connected vehicles. 12:10.890 --> 12:16.970 In addition to tracking vehicles, sensors can be used to provide supplementary data into decision-making systems. 12:17.010 --> 12:24.070 For example, local weather information or information on road conditions could be useful to augment the data already within the systems. 12:24.490 --> 12:27.350 It's also quite useful for automated systems. 12:27.350 --> 12:33.410 So if you've got a human driver, they might, you know, notice that it's raining and the road is wet and so automatically slow down. 12:33.490 --> 12:37.150 Whereas an automated system, it doesn't work quite like the human does. 12:37.150 --> 12:42.610 But if it was receiving data saying the road's wet, slow down, then it will be able to act on that. 12:43.690 --> 12:51.390 So thanks to these prolific sensors, it might be the case that these automated systems would be able to behave in a more human-like manner. 12:51.610 --> 12:56.170 But unfortunately, just covering everything with sensors means you've got more things to secure. 12:57.410 --> 13:00.870 So just go search for CCTV on Showdown if you're bored. 13:00.950 --> 13:03.610 You can view the CCTV feeds, which isn't that bad. 13:03.610 --> 13:05.430 You know, you'd just be watching cars go along the road. 13:05.430 --> 13:07.050 Not really that worrisome. 13:07.410 --> 13:10.050 But some of these cameras are designed to be remotely administered. 13:10.290 --> 13:16.150 You get that traditional admin-admin credentials combo going and suddenly you have access to a node within the CAV network. 13:16.450 --> 13:23.210 If the network trusts data coming from that CCTV system to a high degree, then the whole network's going to be having a bad time. 13:23.570 --> 13:29.350 So just, if you're going to be making sensors that are likely to end up in CAV networks, please secure them. 13:29.490 --> 13:31.810 Don't have easily guessable default creds. 13:31.810 --> 13:34.990 Require admins to use VPNs to remotely administer them. 13:35.110 --> 13:36.570 Just do something, please. 13:36.570 --> 13:40.870 It seems like it's going to be a really easy way for attackers to get into the networks. 13:43.150 --> 13:45.350 Next up, we've got roadside units. 13:45.690 --> 13:51.610 So these roadside units, or RSUs, are designed to collect, collate , and forward data from other bits of the network. 13:51.650 --> 13:54.830 They'll be taking the data from pretty much everything in the network. 13:55.050 --> 14:05.630 They can collect data from roadside sensors and vehicles, and they'll send this data onwards to data hubs, which are processing centers designed to inform traffic control decisions. 14:06.030 --> 14:10.670 The RSUs can also take data from vendors and transmit it back down to the vehicles. 14:10.950 --> 14:17.290 RSUs are actually physical units proposed to be positioned every 500 meters along the side of the intelligent roadway. 14:17.370 --> 14:19.630 They'll all be connected up in some manner. 14:19.930 --> 14:26.110 Some believe that RSUs should be able to take more active roles within the network, such as directly controlling autonomous vehicles. 14:26.170 --> 14:31.830 I think that's kind of a bad idea for reasons that, you know, should become even more clear as this talk goes on. 14:32.170 --> 14:41.850 The RSUs are envisioned to contain some heavy-duty networking equipment, including industrial network switches and ITS station border routers. 14:41.970 --> 14:50.370 You want the industrial network switches to be survivable in the harsh environments of constant outdoor usage. 14:50.550 --> 14:57.710 And they also support standard security features, such as MAC address filtering, remote management, network access, etc. 14:58.210 --> 15:04.770 During this study, we read a report that was investigating the security at one of these proposed roadside units. 15:05.330 --> 15:17.710 And they found that, yeah, the switch in it had MAC address filtering in place, but the MAC address of the computer driving the RSU was written on the side of the box, so not really the best security maybe. 15:19.390 --> 15:28.650 The ITS station border routers within the RSUs are designed as the point through which data from the intelligent roadways is sent off to the data hubs. 15:28.930 --> 15:32.430 There's a few proposals of what form this transport medium could take. 15:32.430 --> 15:34.310 Some suggest using LTE. 15:34.310 --> 15:38.750 Others suggest that you could just lease actual physical lines from local councils. 15:39.430 --> 15:44.450 There's lots of different approaches, and with different approaches come different security concerns. 15:44.710 --> 15:49.650 But when you're securing these RSUs, you should take a general network infrastructure security approach. 15:49.950 --> 15:51.770 So consider the physical security. 15:51.810 --> 15:55.950 Make the locks on the physical box secure with a tamper detection system. 15:56.110 --> 16:01.770 If the RSU is hidden away behind the trees, monitor them with CCTV systems. 16:01.990 --> 16:14.090 So in the report where they noticed the MAC address was written on the side of the box, the guy who did that study, he actually set up a tent next to the RSU, and he camped out there for like two days, and no one noticed him messing around with the thing. 16:14.090 --> 16:19.130 So you need some kind of monitoring, because two days gives you quite a bit of time to play around with stuff. 16:19.910 --> 16:23.130 Make sure that tamper detections are actually followed up upon. 16:23.130 --> 16:28.770 So you could cross-reference things like timings of tamper detections with maintenance schedules. 16:28.850 --> 16:32.870 And if the tamper is determined to not be a false alarm, you should take action. 16:33.070 --> 16:39.830 For instance, you could consider that all data from that node is now unsafe, and so do not make any important decisions based upon it. 16:40.110 --> 16:45.250 In addition to physical security, you should also follow good network security best practices. 16:45.290 --> 16:49.330 You know, change default creds, disable unused services, all that good stuff. 16:49.570 --> 17:00.510 Make sure that a procedure for patching devices is in place, encrypt the data being held locally, and when it's being transmitted onwards, especially if you're making use of third-party transmission mediums. 17:00.930 --> 17:04.910 Tangentially, you should consider the security of device maintenance systems. 17:05.030 --> 17:11.730 It's likely that there'll be engineers coming to, you know, do upgrades on these systems, or do general maintenance tasks, or whatever, really. 17:12.190 --> 17:18.950 The engineers carrying out the legitimate work upon the RSUs will probably have laptops that they're designed to plug into the system. 17:19.090 --> 17:24.650 They might also have been on a dodgy porn website in the hotel the night before, and be bringing all sorts of nasties with them. 17:24.810 --> 17:26.430 So again, just don't trust things. 17:26.430 --> 17:30.150 Don't trust an engineer's laptop, even though in theory it should be fine. 17:30.150 --> 17:31.650 It might not be. 17:33.590 --> 17:35.790 Trust no one, not even yourself. 17:35.790 --> 17:41.450 I know I sound like a broken record, but do not place absolute trust in any single aspect of the system. 17:47.400 --> 17:50.000 So data hubs are where all the data lives. 17:50.380 --> 17:54.480 The data collated by the RSUs will end up here. 17:54.700 --> 17:57.780 The scales of the data hubs is kind of unclear right now. 17:57.820 --> 18:03.620 I mean, maybe they're going to be regional, maybe they'll be countrywide, maybe they'll be just for a town or a specific section of road. 18:03.620 --> 18:05.200 It's not really clear. 18:05.380 --> 18:11.240 It's also not clear who's going to run the data hubs, or what exactly they'll be doing with the data. 18:11.520 --> 18:16.860 But generally, they're probably going to be used in traffic management systems, traffic analysis, all that good stuff. 18:17.180 --> 18:19.900 There's also proposals for their usage in test beds. 18:19.980 --> 18:22.500 I'll be talking a bit more about the test beds later. 18:22.500 --> 18:28.980 But the basic idea is that there'll be regions of roadways, which are designated for vendors to test their new kit on. 18:29.240 --> 18:39.700 Because of this, there's going to be large amounts of data being collected on the test bed roadways, which vendors can then evaluate like post trial to work out the performance of their systems. 18:39.960 --> 18:46.400 And that will make test bed data hubs a really high value target for attackers, because there's going to be lots and lots of data. 18:46.400 --> 18:52.020 And because people are going to be testing new models of vehicles, it's likely to be about things that aren't actually available yet. 18:52.020 --> 18:54.500 So it'd be great for corporate espionage. 18:54.860 --> 18:58.460 Or I mean, what if you could just get into the data hub and delete all the data in it? 18:58.460 --> 19:03.040 You know, could you force a vendor to have to redo trials and delay the release of a new product? 19:04.160 --> 19:07.140 Security of the data hubs is going to be incredibly important. 19:07.180 --> 19:09.400 And it's likely going to be fairly bespoke. 19:09.520 --> 19:14.580 I mean, one could probably learn from security best practices for any large scale sensitive data holder. 19:14.660 --> 19:21.960 But I mean, just once again, you don't want to trust all the data you're receiving into these data hubs, just in general. 19:22.560 --> 19:25.480 You know, don't let little bobby tables ruin your day. 19:25.820 --> 19:29.300 Likewise, you need some form of accountability within the system. 19:29.340 --> 19:39.940 If you find that you're all you're frequently getting malicious data from a certain node, like you're frequently getting bobby tables popping up, you might you want to be able to identify what node this malicious data is coming from. 19:39.940 --> 19:41.660 So you can actually address it. 19:41.660 --> 19:50.500 Or just if you're getting like, I don't know, like invalid data coming from a node, you want to be able to work out where it's coming from, and address whatever the issue is. 19:57.220 --> 20:04.180 So transmission medium, there's the potential for lots of different data transmission media to be used within these future networks. 20:04.460 --> 20:10.520 I'll be talking about the connection issues within the next section, when I discuss the bespoke protocols that have been proposed. 20:11.140 --> 20:14.500 So LTE is like the most obvious connectivity choice. 20:14.500 --> 20:18.040 It's simple, it's fairly accessible nowadays, it's reasonably cheap. 20:18.100 --> 20:20.400 Some vehicles already make use of LTE. 20:20.400 --> 20:26.100 You've got systems such as eCall, which automatically calls the emergency services if it detects you're in a crash. 20:26.480 --> 20:32.300 And LTE can also be used to transmit over-the-air software to vehicles, software updates, sorry, to vehicles. 20:32.620 --> 20:39.780 I mean, in future cab vehicles, LTE will probably be used by applications, and maybe also by some of the roadside sensors, who knows. 20:40.060 --> 20:49.720 Standard LTE security best practices should be followed, just to make sure it's not too obvious that your tech is using 5G LTE, so it doesn't get blamed for international pandemics. 20:50.520 --> 20:56.560 As mentioned earlier, it's been proposed that lease lines could be used to transmit data from RSCs back to data hubs. 20:56.740 --> 21:05.640 If you're sending potentially sensitive data over third-party lines, you probably want to try and encrypt it and sign it so that it cannot be read or tampered whilst it's in transit. 21:06.180 --> 21:16.320 From what I can tell, lease lines will be used only for data hub communications, though they're not going to be used for like sending data from one car to another, because that just wouldn't make sense. 21:16.960 --> 21:20.240 Finally, we get to the wireless local area networks. 21:20.880 --> 21:26.200 Small WLANs within vehicles are proposed, which allow users to get onto the internet via their vehicle. 21:26.440 --> 21:33.340 However, it's also been proposed that giant WLANs could be used to handle the majority of communications between CAV network nodes. 21:33.500 --> 21:40.840 To me, this proposed usage of wireless local area networks for data transmission between CAV nodes is super interesting. 21:41.040 --> 21:51.160 It's proposed that it will be enabled through the usage of a relatively new 802.11p standard OCB mode, and as always with this talk, I'll be talking more about that later. 21:52.360 --> 21:56.780 So now that you know about the transmission medium, what about the transmission protocols? 21:56.900 --> 22:03.020 Within CAV networks, there's two main types of message being sent between vehicles and other nodes, CAM and DENIM. 22:03.020 --> 22:10.200 CAM standing for cooperative awareness messages and DENIM being decentralized environmental notification messages. 22:10.200 --> 22:22.000 For those of you in the US, these are equivalent to DSRC basic safety messages, where BSM part one is about equivalent to CAM and part two is about equivalent to DENIM. 22:22.660 --> 22:27.280 So about CAM, as the name suggests, CAM are used for cooperative awareness. 22:27.400 --> 22:32.300 They're what let the vehicles know where each other are, so that they can move cooperatively. 22:32.600 --> 22:37.200 The CAM acts as a heartbeat for the vehicle, providing metrics on its current state. 22:37.200 --> 22:44.320 This includes things like the current time, the location, heading direction, speed, if the lights are on or not, all that sort of thing. 22:44.800 --> 22:50.420 The vehicles don't send these to anyone in particular, they just transmit it out into the world for anyone or anything to pick up. 22:50.580 --> 22:56.740 They're signed by the pseudonym certificates used within the CAV ecosystem, and I'll talk more about certificates later. 22:57.180 --> 23:01.880 The generation of CAM is controlled by the cooperative awareness basic service within the vehicle. 23:02.080 --> 23:06.300 The CA basic service also receives and processes CAM from other vehicles. 23:06.660 --> 23:11.440 DENIM, on the other hand, are used by vehicles to share an awareness of any events that may have occurred. 23:11.580 --> 23:18.540 An event could be that an accident has occurred ahead, or that the vehicle has detected the presence of ice on the road, that sort of thing. 23:18.820 --> 23:23.140 Interestingly, the DENIM standards also contains medical emergency flags. 23:23.140 --> 23:36.100 These are the things I spoke about earlier, whereby if the vehicle detects that the driver's had a heart attack or they're in a diabetic coma, it's got a specific DENIM message type to let the other cars around that driver know that that's what happened. 23:36.980 --> 23:41.400 So once a vehicle's detected an event, it creates a new event DENIM. 23:41.400 --> 23:50.360 This contains info on what the event type is, the geographic area of relevance for the event, and that includes details of what roads will lead up to encountering the event. 23:50.400 --> 23:55.720 This DENIM is transmitted out into the world where it's picked up by the DEN basic service of other vehicle nodes. 23:55.980 --> 24:02.140 When a vehicle picks up a DENIM, the onus is placed upon the receiving vehicle to decide the relevance of the message. 24:02.260 --> 24:10.560 So the vehicle will determine if it's within the geographic area of relevance for the event, or if it's even heading in the correct direction to encounter the event. 24:10.960 --> 24:17.640 If it is, the vehicle will update its internal records and automatically retransmits the DENIM onwards to other vehicles. 24:17.680 --> 24:19.940 If it's not relevant, it just ignores it. 24:20.200 --> 24:27.180 Based on this automatic forwarding, vehicles may be updated as to the existence of an event as soon as they enter the relevant area. 24:27.340 --> 24:31.680 Likewise, if the initially reporting vehicle leaves the area, the event is not forgotten. 24:32.660 --> 24:38.000 Vehicles might also 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:49.400 As I said before, both CAV and DENIM are signed. 24:49.520 --> 24:55.860 The proposed certificate system in CAV is a little bit bonkers in my mind, and I'll describe it later. 24:55.940 --> 24:58.440 But the key point here is the messages are signed. 24:58.440 --> 25:02.680 They're not encrypted because CAVs don't join networks in the traditional sense. 25:02.780 --> 25:10.040 Because there's no network joining, it's all up to the CA and DEN basic services to verify the validity of all received messages. 25:10.300 --> 25:13.020 This could be problematic for a lot of reasons. 25:13.280 --> 25:18.100 It seems like it's going to be really easy to jam a given vehicle by just spamming out messages near it. 25:18.100 --> 25:27.040 Likewise, if an attacker could fuzz the basic service and find a message that would crash it, then there's little resiliency against potentially harmful messages within this environment. 25:27.200 --> 25:38.960 It wouldn't even matter if the vehicle was part of the network because it's up to the receiver to determine if the message is valid or not, if it's from an actual member of the network or from an actual vehicle, sorry. 25:40.160 --> 25:46.400 There's also no nonce values in CAM and DEN, so you've got your standard risks of replay attacks there. 25:46.680 --> 25:54.340 In these future networks, some of the information contained within CAM will be used within the intelligent roadway systems for deciding things like traffic flow. 25:54.440 --> 26:00.800 So say you're an ambulance, the traffic light behavior might automatically be updated to favor traffic coming from your direction. 26:00.800 --> 26:04.760 So why not just continually replay a packet capture of an ambulance? 26:04.960 --> 26:09.480 The closest thing to nonce values that's included already is timestamps. 26:09.600 --> 26:13.040 And these, in my mind, are kind of weirdly done as well. 26:13.180 --> 26:15.220 Epochs weren't good enough for these guys. 26:15.220 --> 26:30.660 What they've gone for is a system whereby the time from the start of 2004 is taken in milliseconds, and then it's divided by two to the power of 16, or 65,536, which is coincidentally a touch over the number of milliseconds in a minute. 26:30.980 --> 26:33.500 The remainder is then untransmitted. 26:33.780 --> 26:42.300 So whilst you could kind of use this in your application as a nonce value, you'd have something that could be replayed roughly every minute or so, depending on your tolerances. 26:42.680 --> 26:48.280 But yeah, this slightly weird timeliness metric makes it very hard to discern the liveliness of messages at a glance. 26:48.280 --> 26:50.440 So go ahead with those replay attacks. 26:51.000 --> 26:56.700 Another issue stems from the automatic forwarding of DENIM if the receiving vehicle is within the area of relevance. 26:56.700 --> 26:59.420 Like I mentioned, DENIM describe an event. 27:00.680 --> 27:04.280 Vehicles can automatically retransmit received DENIM. 27:04.440 --> 27:11.840 So now something interesting about these cab networks is that a mechanism is proposed to exist for detecting and punishing malicious behavior. 27:12.100 --> 27:24.340 The details of it aren't really specified in any great detail, but the general gist of it is that nodes can automatically report that certain vehicle sending out malicious data with the vehicle being identified by its signing certificate. 27:24.340 --> 27:28.360 It's unclear how many reports are needed to trigger a ban in the network. 27:28.400 --> 27:34.260 But yeah, after a certain threshold of reports are hit, a vehicle certificate will be temporarily rescinded. 27:34.260 --> 27:43.180 This means that other nodes won't see its messages as valid, and so will disregard them. 27:43.820 --> 27:50.300 So now, when a vehicle automatically forwards on a DENIM, it repackages the message. 27:50.300 --> 28:02.780 The sender ID that you received of the initial message is then replaced with the sender ID of the vehicle that's forwarding on the message, and it's re-signed using the re-sender certificate. 28:02.780 --> 28:04.700 And I mean, can you see where I'm going with this? 28:04.700 --> 28:06.840 Say the threshold of reports was five. 28:06.840 --> 28:14.680 If you could have five vehicle nodes that you control send out DENIM-containing malicious data near a target, it in theory would just repeat them all on. 28:14.680 --> 28:19.100 That vehicle would hit the ban threshold quite easily and would be banned from the network. 28:19.140 --> 28:21.580 Suddenly, it's denied access to the CAV network. 28:21.960 --> 28:29.000 Generally, I think that mechanisms such as automatic bans need to be carefully considered because there's, you know, there's a real potential for abuse in there. 28:34.160 --> 28:36.760 So how do we transmit these CAM and DENIM? 28:37.980 --> 28:43.900 Ad-hoc networking is required for the CAV networks because of the node's tendency to move around quite a bit at high speeds. 28:44.440 --> 28:53.360 The idea of having passing vehicles connect to RSUs as they go past has been floated, but it was written off because there wouldn't be sufficient time, apparently. 28:53.360 --> 29:02.480 I'm not sure how fast people think future cars are going to go, but... So I must apologize, it's now time for acronym o'clock. 29:02.620 --> 29:09.280 I'll try and make this as clear as possible, but if you're confused at all, just ask me questions afterwards and hopefully I can explain it a bit better. 29:09.740 --> 29:15.560 So to create these ad-hoc networks, the usage of 802.11p standard and OCB mode is proposed. 29:15.740 --> 29:17.960 So what's an 802.11p OCB? 29:18.520 --> 29:23.040 802.11 is an IEEE standard for network access control. 29:23.040 --> 29:32.540 It provides the authentication mechanisms for devices wishing to join a LAN or WLAN, as well as allowing for things like network decongestion to automatically take place. 29:32.540 --> 29:35.400 It's the stuff your home Wi-Fi network probably uses. 29:35.620 --> 29:41.380 So on top of the initial standards, it's 802.11p, which has been specifically designed for vehicle networks. 29:41.380 --> 29:47.900 It's licensed for use in the US's WAVE systems and in Europe's ITS G5 communication networks. 29:47.900 --> 29:51.080 It's been allocated the frequency band of 5.9 gigahertz. 29:51.080 --> 29:55.380 It's all fairly standard so far, but we need to have ad-hoc networks. 29:55.500 --> 29:56.900 My home Wi-Fi isn't ad-hoc. 29:56.900 --> 29:58.400 I need to connect devices to it. 29:58.400 --> 30:00.780 How does this work with these cars? 30:01.100 --> 30:09.460 So in this case, the 802.11p is being used in OCB mode, which means outside context of BSS or basic service set. 30:09.660 --> 30:16.420 Basic service set refers to the 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:35.500 And then messages sent within the network are tagged with a BSS ID or basic service set ID, which marks them as belonging to the WLAN, so that all the nodes know if they're actually coming from something within the network and should be, you know, something they should bother with or not. 30:36.600 --> 30:40.420 In 802.11p OCB mode, we don't want any of that. 30:40.420 --> 30:45.020 We want everything to be able to transmit to everything else with no need to join the network. 30:45.160 --> 30:52.480 This allows for the truly ad hoc networking, 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:02.100 So it's up to the receiver to investigate the signing certificate and assess if the messages are valid or not. 31:02.200 --> 31:10.120 But also, because there's no joining to a network, there's no 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:17.280 If you said denial of service, you'd be right. 31:17.440 --> 31:21.240 What we've got here is the frequency allocations for ITSG5. 31:21.280 --> 31:29.120 The EU has provided permissions for ITSG5 transmissions within the 5.47 to 5.925 gigahertz range. 31:29.160 --> 31:33.040 The nice big, you see that nice big band on the left of the diagram? 31:33.120 --> 31:39.420 That's for broadband radio access networks, radio local area networks, and wireless local area networks. 31:40.340 --> 31:54.300 The key point for this is that you need to make use of dynamic frequency selection to avoid co-channel interference if you want to transmit in that range, which, since our CAVs networks aren't going to be connecting to the WLAN in the traditional sense, 31:54.300 --> 31:55.280 they cannot. 31:55.660 --> 32:00.680 So basically, you've already limited yourself from using a large chunk of the bands you've got available to you. 32:00.840 --> 32:04.140 Next up, you've got your little DSRC band in the middle. 32:04.140 --> 32:07.500 Well, that's not for ITSG5, so we can't use that. 32:07.580 --> 32:14.580 On the far right, we've already got a little band 5.905 to 5.925 gigahertz that's reserved for future use. 32:14.640 --> 32:20.200 So basically, the CAV networks are only left with 5.88 to 5.905 gigahertz ranges. 32:20.600 --> 32:30.440 And I hear there's a lot of cars in general, like there's a lot of them, they tend to all get together on these big stretches, and there's just a lot of them all talking at once. 32:31.280 --> 32:35.620 So and then there's also there's going to be like a shit ton of sensors on top of that, too. 32:35.620 --> 32:38.680 It doesn't seem like it's going to go well, really. 32:41.450 --> 32:49.170 So the proposed ad hoc networks in CAV networks are pretty unique, because it removes the issues from everything having to be joined to the network. 32:49.190 --> 32:55.170 And there's a certificate infrastructure in place, you can still verify the validity and integrity of received messages, at least. 32:55.370 --> 32:56.910 But that's the problem. 32:56.910 --> 33:05.350 When people aren't having to join a network, it means anyone can transmit, you got to process every single message you receive to work out if it's valid or not. 33:05.390 --> 33:15.970 I think that in these future CAV networks, denial of service attacks are going to be a real big issue, both on the frequency jamming front, but also from inducing the vehicles to process large quantities of junk messages. 33:16.970 --> 33:18.830 It doesn't even have to be junk, really. 33:18.890 --> 33:24.250 With the automatic forwarding of denim, you wouldn't need to have many cars in an area to get a good packet storm going. 33:24.550 --> 33:31.850 If we decide to go with the scenario whereby roadside units can be used to teleoperate autonomous vehicles, it's going to go kind of badly. 33:31.850 --> 33:34.250 It just does not seem like a good idea. 33:34.870 --> 33:39.510 Ideally, no vehicle should need to be connected to the CAV networks to operate. 33:39.510 --> 33:47.010 What's being joined would increase the efficiency of operations, each vehicle should be capable of operating without receiving any data from external sources. 33:51.870 --> 33:57.630 So now I'm going to finally talk about the proposed usage of public key infrastructure and vehicle certificates. 33:57.870 --> 34:04.070 The European Commission has proposed an entire public key infrastructure or PKI for the CAV networks. 34:04.130 --> 34:08.830 In their proposals, they're keen to stress that it's just a proposal, not gospel. 34:09.090 --> 34:12.310 But honestly, it's fairly standard stuff really in the proposal. 34:12.470 --> 34:18.750 At the top, you've got your route certificate authority and the proposals describe in great detail how to physically secure these. 34:18.930 --> 34:22.930 There's fairly standard encryption schemes, you know, they're making use of AES 128. 34:23.270 --> 34:28.790 I'm not going to go into too much details on the PKI since it's all fairly standard from what I could tell. 34:30.310 --> 34:37.010 The vendors will have their own which they'll use to sign vehicle sets before the vehicle is sold. 34:37.010 --> 34:41.710 These preloaded sets are known as enrollment credentials. 34:43.230 --> 34:50.570 Once a vehicle is sold now on the road, it uses its enrollment credentials to request access tokens, which are also known as pseudonyms. 34:50.670 --> 34:57.330 And this request goes via the roadside units and the pseudonyms are returned via the roadside units. 34:57.330 --> 35:01.970 So pseudonyms are where things get really weird in my mind. 35:02.290 --> 35:10.430 The creator of the cab networks heard that privacy is a good thing, and they want to maintain it within these networks, which you know, so far so good. 35:10.430 --> 35:11.470 It's a good idea. 35:11.730 --> 35:18.230 They then decided that it would be bad for vehicles to transmit a unique identifier, because then someone could track them. 35:18.550 --> 35:23.850 I think they forgot that license plates are a thing, but let's put that aside for now. 35:25.610 --> 35:30.810 When a vehicle uses its enrollment credentials to request pseudonyms, it's given a pool of 100 of them. 35:31.030 --> 35:33.830 These are valid for a period of one week. 35:34.010 --> 35:38.990 The pseudonyms are used to sign all the cam and denim that the vehicle sends out, so they can be verified. 35:39.470 --> 35:41.430 Pseudonyms are designed to be rapidly changing. 35:41.430 --> 35:46.990 On the slides, I've got the recommendations that come from the European Commission on when you should cycle pseudonym. 35:47.230 --> 35:48.950 And they're kind of weird. 35:49.410 --> 35:52.570 So when you start the car, you cycle to a new pseudonym. 35:52.570 --> 36:01.890 You change again after driving in the region of 800 to 1500 meters, then again somewhere after two to six meters, then again after 15 kilometers. 36:01.890 --> 36:03.290 And it's just so arbitrary. 36:03.290 --> 36:05.370 Like, why are we switching between distance and time? 36:05.370 --> 36:06.550 Like, it's weird. 36:07.070 --> 36:11.470 But potentially, you could be cycling through quite a lot of them on one road trip. 36:11.470 --> 36:13.710 And you've got a pool of 100 pseudonyms to use, right? 36:13.710 --> 36:15.610 And that's got to last you a week. 36:15.970 --> 36:18.610 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:28.670 The European Commission, however, states that you can just reuse your pool of 100 so long as they're still within the validity period. 36:29.030 --> 36:33.390 But not everyone is always in range of the infrastructure needed to get more pseudonyms. 36:33.470 --> 36:39.130 Because of this, it's possible for vehicles to be preloaded with up to three months' worth of future dated pseudonyms. 36:40.870 --> 36:43.610 I mean, what are the practicalities of pseudonym cycling? 36:43.850 --> 36:48.470 When a vehicle cycles to its next pseudonym, it also needs to update its IP address. 36:48.470 --> 36:52.590 Otherwise, you could trivially track the vehicle for these changes. 36:52.630 --> 37:00.310 The standards documentation recommends the usage of stateless address auto-configuration, as described in RFC 4862. 37:00.550 --> 37:13.750 So RFC 4862 provides a framework for devices in a network to automatically configure themselves using a mixture of information being advertised by a router and from locally available information. 37:13.770 --> 37:20.350 This allows the nodes to communicate directly between each other without needing to go through a router, which is appropriate here. 37:20.930 --> 37:23.930 CAVs are intended to use IPv6 addresses. 37:24.050 --> 37:32.270 As this address space is quite large, there's a low risk of collision in the pseudo-randomly generated IPv6 addresses created using RFC 4862. 37:32.390 --> 37:43.010 But to avoid collision, RFC 4862 nodes do advertise their proposed new IPv6 addresses and give neighbors the chance to respond if they've already claimed them. 37:43.010 --> 37:47.050 So what's to stop an attacker using this to track a vehicle's IP address changes? 37:47.210 --> 37:49.770 I mean, not much really, so long as you were keeping near the vehicle. 37:50.090 --> 37:51.570 Or just look at the MAC addresses. 37:51.570 --> 37:54.270 These are not cycled at the same time as the IP addresses. 37:54.590 --> 38:00.590 Or more interestingly, what if you always claimed that you were already using the IPv6 address that it's advertising? 38:00.950 --> 38:11.510 Like, could you just make a little box that you can tape onto the vehicle, a little address denial box, which automatically lays claim to any address being advertised by the vehicle? 38:12.050 --> 38:17.030 Again, I think that just denial of service attacks are going to be a big thing in these future CAV networks. 38:18.590 --> 38:23.950 In my mind, pseudonym cycling seems more likely to enable abuse than to protect privacy. 38:24.150 --> 38:30.770 As I mentioned before, there are provisions for vehicles to be automatically banned from the CAV network via their certificate being revoked. 38:30.810 --> 38:34.230 The certificates being revoked would potentially just be their pseudonym. 38:34.290 --> 38:41.350 So the attacker can either reduce the pseudonym cycle via normal driving or potentially manipulate their system into cycling on demand. 38:41.430 --> 38:44.230 It's an ideal method of ban evasion, really. 38:44.750 --> 38:50.430 To combat this, it's been suggested that hardware-trusted components could be used to provide more robust banning mechanisms. 38:50.590 --> 38:53.910 This could be used to wipe the entire pool being stored on the vehicle. 38:53.970 --> 39:00.170 But then you still got the problems I talked about earlier, whereby you can just cause a vehicle to be unjustly banned from the network. 39:00.370 --> 39:05.850 Also, I'm kind of always wary of placing too much trust in anything that's sold as unhackable. 39:05.870 --> 39:10.350 It just seems like a bull's eye on it. 39:10.950 --> 39:18.550 And there's nothing to say that an attacker would need to control multiple 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:33.470 It's likely that whatever contains the CAV, the CA slash then basic service will appear soon enough, harvested from written off cars by unscrupulous garages. 39:33.610 --> 39:37.030 Just pick up a couple of these and you're good to go with your civil attacks. 39:37.430 --> 39:42.390 They might come preloaded with three months of certs, or maybe they'll still be able to gain new certs from the network. 39:42.530 --> 39:47.410 It might not be the case that the vendor knows the car was written off so its enrollment credentials were not revoked. 39:47.730 --> 39:54.010 You know, use these to your heart's content to avoid bans and juice bans and others, flood networks and malicious data, whatever you feel like really. 39:54.390 --> 40:02.950 Or you could use these to send out your CA slash then basic service crashing messages that you know you've developed previously by fuzzing the basic services. 40:03.110 --> 40:07.870 Or if you could gain access to multiple pseudonyms at once, use them to simulate other vehicles. 40:07.870 --> 40:09.610 You got someone tailgating you? 40:09.610 --> 40:14.830 Start sending out spoofed 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:30.900 These are regions of roadway which vendors can test their new products on. 40:30.900 --> 40:39.840 They can include a mixture of private roads and public roads, and they will be absolutely covered in sensors so vendors can receive their high quality trials data. 40:40.020 --> 40:51.880 In current proposals, vendors will be able to buy access to data from specific regions of test beds at specific times. 40:51.940 --> 40:58.360 It's been suggested this could be facilitated using a web interface which comes with its own issues really. 40:58.620 --> 41:02.280 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:13.220 There's also the very real possibility that the vehicles being tested on these test beds might not yet have the most robust security in place. 41:13.540 --> 41:19.480 So it's important that these potentially insecure vehicles cannot be used as vectors into the rest of the CAV network. 41:21.140 --> 41:29.320 I'm now going to move on to talk about some of the threats that F-Secure thinks CAV networks will face and talk you through a couple examples of how these could be actualized. 41:29.460 --> 41:43.900 If this is an area of interest to you, I'd recommend reading our full white paper as it goes into much more detail about the type of assets which will be considered within CAV networks, as well as talking about specific threat actor groups including APT32. 41:49.610 --> 41:54.970 So here's a rough overview of the threat actors that are likely to target the CAV networks. 41:55.590 --> 42:01.890 At the bottom we've got the most prolific type of hacker, the script kiddie or skiddie. 42:02.190 --> 42:11.510 These are just people sat at home, they're just playing around, they downloaded something off the internet, they've got their low orbit iron cannon, they want to have a play with it, they're trying to impress their mates. 42:11.810 --> 42:15.150 They are low skill, but they are prolific. 42:15.190 --> 42:20.650 And they might target the CAV networks just because, you know, it seems a bit for the lulz, seems fun. 42:21.170 --> 42:25.830 Above this tier, you've got the motivated individuals or hacktivists. 42:25.930 --> 42:28.350 These guys actually know what they're doing. 42:28.550 --> 42:34.630 They'll quite often be using free tools, or maybe they found some bespoke tools, maybe they even wrote some stuff on their own. 42:34.630 --> 42:38.810 But they tend to be more disgruntled people who are ideologically motivated. 42:39.090 --> 42:47.330 So like you get the people who are hacking SeaWorld, Sealand, 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.050 Above this tier, you've got the kind of fairly standard criminal groups. 42:55.050 --> 42:57.410 They tend to be going for financial gain. 42:57.410 --> 43:01.470 This could be just a small group that's created, say, a piece of ATM malware. 43:01.470 --> 43:08.090 Like they often they might just have one techie who creates stuff and then the rest of the money mules that go around picking up the cash, that sort of thing. 43:08.150 --> 43:12.110 They tend to have more cash available than the tiers below. 43:12.110 --> 43:19.430 So they can actually buy bespoke tools on the dark market, or, you know, fund someone to create tools that are a bit more interesting. 43:19.710 --> 43:22.690 Above that tier, you've got serious organized crime groups. 43:22.690 --> 43:27.770 These guys have a lot of technical know-how, or at least access to people and the technical know-how. 43:27.770 --> 43:33.770 They've also got access to large amounts of resources, so they can kind of do what they want, really. 43:33.810 --> 43:40.610 You know, they're going to be able to fund people to research zero days that are targeting certain technology that they're interested in, all that sort of thing. 43:41.130 --> 43:43.630 Above this, you've got the nation-state threats. 43:43.630 --> 43:47.950 So these guys, their aim is not always financial, although it can occasionally be. 43:47.950 --> 43:54.470 These guys tend to go more for intelligence gathering, industrial espionage, economic destabilization. 43:54.510 --> 43:56.950 They tend to be using advanced tools. 43:57.110 --> 43:59.450 You know, they might even be stealing tools from governments. 43:59.450 --> 44:01.910 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:12.930 They're very hard to deal with because they have so many resources and technical expertise at their disposal. 44:13.790 --> 44:17.830 And again, we think that people at all these levels are likely to target the CAV networks. 44:18.210 --> 44:20.910 And frankly, there's no way to keep everyone out. 44:21.130 --> 44:28.710 People who have the absolute dedicated skills and resources, they probably will try and figure a way, they probably will be able to find a way in. 44:28.910 --> 44:30.950 But it's important to keep these lower tiers out. 44:30.950 --> 44:34.190 You know, you shouldn't be able to have the skiddy take down your networks. 44:34.190 --> 44:35.450 It's not good. 44:36.770 --> 44:39.830 The best way to counter it really is to just have good detection. 44:39.970 --> 44:52.250 So even if a nation-state was able to do something to your network, by being able to detect it immediately, you can start to go into damage control mode, you can start to ignore data coming from that node because you know it's malicious, that sort of thing. 44:54.270 --> 45:01.690 There's a whole variety of assets that these threat actors are likely to be targeting within the networks for various different, you know, end goals. 45:01.770 --> 45:15.690 So you've got the physical ones, which are the obvious things like you've got vehicles, you've got the roadside units and sensors, but you could also target, say, a garage so that you could perhaps automatically lift data of everything that comes into the garage. 45:15.690 --> 45:28.010 Or the backend servers, if the car is still connected to the vendor servers in some way, could you pivot from the vehicle into the vendor servers and, you know, do your cyber crimes through there. 45:28.170 --> 45:30.730 We've also got the electronic vehicle charging stations. 45:30.730 --> 45:32.410 Those are an interesting target. 45:32.590 --> 45:36.390 If you could break those, you could cause quite a bit of harm, cause a lot of people to be stranded. 45:36.710 --> 45:42.550 You've got your public key infrastructure facilities, like the actual buildings they're stealing them at. 45:42.550 --> 45:47.530 If you could get in and steal, you know, the route certificate, you can have some fun with that. 45:47.790 --> 45:55.530 On the digital front, you've got sensor data, regional events data, so things like weather, you've got your traffic data. 45:55.550 --> 46:05.670 You've also got personal information probably carried upon these vehicles, like there's the classic of buying old GPS units 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:17.950 Within things like testbed results, there's also likely to be financially sensitive information, or even intellectual property. 46:17.950 --> 46:23.510 People could actually get any interesting data off of these vehicles, perhaps off the infotainment systems. 46:23.510 --> 46:28.250 There might be some proprietary systems that an attacker could gain information about. 46:28.750 --> 46:34.190 On top of these assets, you've also got the kind of intrinsic reputational assets. 46:34.410 --> 46:51.350 So things like Tesla's been getting hammered a bit in the US news recently, because of stuff like people putting autopilot on and the car driving into a barrier, or I can't remember which company it was, was trialing a couple years back, one of their self-driving vehicles that killed a pedestrian. 46:51.890 --> 46:57.750 And, you know, it's causing reputational harm is a real risk in these areas, you don't want that. 47:03.300 --> 47:08.280 So as an example threat, I'm going to talk about Bob the Grumpy Guy. 47:08.820 --> 47:13.460 Bob lives in a small village, which has a section of smart roadway running through it. 47:13.460 --> 47:17.820 He's upset by the speed at which cars travel through the village, and he wants them to slow down. 47:17.840 --> 47:25.160 He's read online that the roadside units placed every 500 meters along the roadside control the speed of which cars drive, so he decides he's going to target them. 47:25.400 --> 47:28.880 He goes online and he spends some time learning about hardware security. 47:29.060 --> 47:33.620 One night he takes his laptop and a crowbar to an RSU, which is hidden behind some trees. 47:33.760 --> 47:38.240 The RSU is in a locked cabinet, but Bob manages to leave it open with his crowbar. 47:38.240 --> 47:43.940 The physical tamper detection system on the RSU detects the unexpected opening of the door and sounds an alarm. 47:44.160 --> 47:47.260 An alert is sent to the cab network requesting investigation. 47:47.380 --> 47:50.500 The loud alarm startles Bob and he runs back home. 47:50.980 --> 47:56.600 Based on his experience with the roadside unit, Bob decides he's going to try and use other devices to get to the RSU. 47:56.620 --> 48:02.360 His neighbor, conveniently, has bought a brand new intelligent vehicle, which connects to these RSUs. 48:02.400 --> 48:09.060 Bob does some research on his neighbor's new car and he discovers that the car broadcasts a hotspot which drivers can connect their phones to. 48:09.060 --> 48:16.360 Bob reads a web forum and finds unofficial reports saying the technology used for this hotspot has an abusable authentication vulnerability. 48:17.420 --> 48:23.780 As Bob's house is within the hotspot's range, he exploits the vulnerability to connect to the car from his bedroom. 48:23.940 --> 48:31.720 Using his knowledge of network security, he's able to pivot through the car's 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:43.060 Bob uses these to send the RSU many reports that the vehicle is covered, sorry, that the road is covered in black ice. 48:43.200 --> 48:49.260 The RSU collates these reports and does not correctly identify that they have all come from a single vehicle. 48:49.460 --> 48:55.740 The RSU updates its models for that area with the presence of black ice and decides that the speed limit in that area should be lowered . 48:55.980 --> 49:00.700 The dynamically updated road signs along the village now display half the previous speed limit. 49:00.700 --> 49:05.480 Autonomous vehicles automatically adhere to them, and most manually driven cars do. 49:05.620 --> 49:07.100 Bob is happy once again. 49:07.100 --> 49:10.840 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:31.380 Nerund has a highly developed ITS roadway system with many internationally acclaimed CAV developers based in the country. 49:31.380 --> 49:40.020 Zeron decides it would like to have more developed ITS roadways too, but it doesn't have the resources to fund the extensive CAV development work Nerund has done. 49:40.020 --> 49:46.340 Zeron decides corporate espionage would be a much more cost-effective measure for developing its technical capabilities. 49:47.160 --> 49:52.920 Zeron government engages APT32, a Zeron-backed hacking group. 49:52.920 --> 49:57.620 This group is tasked with stealing as much information on CAV as possible from companies in Nerund. 49:57.720 --> 50:06.480 The APT77 team decides their first move should be to gain access to the internal networks of Nerund Auto, the country's leading vehicle manufacturer. 50:06.540 --> 50:14.000 A spearfishing campaign is launched, and APT77 soon finds itself with footholds within various support functions of Nerund Auto. 50:14.920 --> 50:19.440 APT77 discovers Nerund Auto does not make use of network segregation. 50:19.600 --> 50:24.380 The group can move from an HR employee's computer to one belonging to the tech support team. 50:24.380 --> 50:29.380 This tech support team has access to the research and development team networks. 50:29.440 --> 50:37.980 Once APT77 gains access to Nerund Auto's R&D network, they're able to steal large amounts of research work, including plans for unreleased vehicles. 50:38.320 --> 50:42.780 The Zeron government is very happy with their information gathered by APT77. 50:42.900 --> 50:49.860 They ask APT77 to see if their foothold within the Nerund Auto networks can be leveraged to gain access to a given car. 50:49.880 --> 50:58.720 The group quickly discovers that through the remote upgrade functionality implemented in all Nerund Auto products, they may push malicious code to arbitrary vehicles. 50:58.980 --> 51:06.760 The Zeron government provides APT32 with details of a Nerund Auto brand vehicle owned by a key Nerund politician. 51:06.940 --> 51:10.740 The APT77 group confirms they can push code to this vehicle. 51:10.740 --> 51:14.720 As the code comes from the trusted manufacturer, it is not evaluated. 51:15.080 --> 51:19.660 The APT group is able to cause the politician's car to take arbitrary actions. 51:20.000 --> 51:22.060 It's not really what you want. 51:24.120 --> 51:27.300 So, I mean, these are all proposals at this point. 51:27.300 --> 51:31.580 They're not things that are existing in the real world in this state quite yet, thankfully. 51:31.740 --> 51:33.380 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:43.380 There's still plenty of time to address them. 51:43.380 --> 51:47.440 I mean, especially with the UK government's idea of this being the next 10 years. 51:47.800 --> 51:54.200 And hopefully the outputs of this project and the other ZenZip projects will help to inform the future decision-making process. 51:56.180 --> 52:06.960 So, while we were going over all these standard documents, I'll just count the amount of times that I read security is out of scope for this document or security will occur at another level. 52:07.700 --> 52:09.320 People really need to stop doing this. 52:09.320 --> 52:16.160 You need to consider the security at every level, 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:28.940 The 802.11p OCB mode seems to be very under-researched. 52:28.940 --> 52:31.260 There's not that much information available on it. 52:31.260 --> 52:33.040 But it seems super weird. 52:33.040 --> 52:35.220 It seems like there's going to be a lot of potential for abuse. 52:35.220 --> 52:37.600 And it seems like you can do a lot of cool stuff with it. 52:38.600 --> 52:49.960 Incidentally, if you happen to have access to any tech that actually can use it, is already set up to communicate over 802.11p OCB mode, please do reach out to me on Twitter or email. 52:49.960 --> 52:51.940 F-Secure is quite keen to get hands on with it. 52:51.940 --> 52:53.120 We want to collaborate. 52:53.280 --> 52:57.140 Or, you know, just generally chat about 802.11p. 52:57.140 --> 52:58.260 It's interesting stuff. 53:00.760 --> 53:03.600 I think the testing at scale is going to be a really big problem. 53:03.600 --> 53:05.740 These networks are going to be absolutely huge. 53:05.740 --> 53:08.960 They're probably going to become part of our critical national infrastructure. 53:08.960 --> 53:12.360 And they're going to get popped, for sure, at some point. 53:12.460 --> 53:14.520 But we still need to remove the low hanging through. 53:14.520 --> 53:18.760 We don't want the little script kiddies to be able to take bits of the network down. 53:18.760 --> 53:23.860 We don't want Bob to be able to mess with speed limits just because he's annoyed by the fast cars. 53:24.880 --> 53:30.860 And in the case that something does happen, a breach is detected, we need to be able to address them. 53:30.980 --> 53:37.020 So we were proposing a system whereby we can detect the point at which malicious data has entered into the network. 53:37.020 --> 53:42.540 So this would be by re-signing your data at every point of transmission. 53:42.880 --> 53:46.180 So your vehicle, it signs the data when it sends it on, right? 53:46.180 --> 53:48.000 This ends up in the roadside units. 53:48.000 --> 53:55.480 The roadside unit collates all this data, and then it signs the bundle of data before it transmits it onwards to the data hub. 53:55.620 --> 53:58.380 Then the data hub collates all this information. 53:58.520 --> 54:01.600 And then you notice that something's a bit wrong or something's malicious. 54:01.760 --> 54:09.580 You can then look at the initial data and say, okay, well, the malicious data include this signed bundle come from the RSUs, that RSU, so it's come from that RSU. 54:09.820 --> 54:14.600 And then that RSU, you can work backwards and be like, okay, well, it's been signed by this vehicle. 54:14.760 --> 54:23.500 And it's just important to be able to backtrace the point at which the incident has occurred, so that you can try and prevent better things, these things from happening again in the future. 54:23.640 --> 54:30.840 Like if you notice it's a specific RSU, go investigate that RSU, 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.300 There seems to be this thing of cybersecurity being a competitive advantage. 54:41.300 --> 54:45.740 You know, it's, it's, it's like considered IP almost that you know how to not get hacked. 54:45.740 --> 54:47.860 And I don't think that should be the case. 54:47.860 --> 54:53.180 I think there should be better information sharing between the vendors, and even between like research groups. 54:53.640 --> 55:02.220 Because if, say you had a phishing campaign targeting your organization as a vendor, it's likely that the attackers will also target similar vendors. 55:02.220 --> 55:06.500 So by sharing information between each other, you can be better prepared for these attacks to come in. 55:06.880 --> 55:14.020 And you know, if someone does manage to get into your network, you can share that information with other companies so that it doesn't happen to them either. 55:14.180 --> 55:20.440 I think you need to get, we need to get over seeing it as like a competitive advantage and just work more collaboratively in general together. 55:22.180 --> 55:30.820 So my conclusions for this are current proposals are not fit for purpose, they're going to be a nightmare of just denial of service and all sorts. 55:30.820 --> 55:33.080 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:48.100 AO211 POCB mode is weird shit. 55:48.100 --> 55:50.040 Pseudonyms are even weirder shit. 55:50.660 --> 55:56.080 And lastly, I'm never getting a connected autonomous vehicle if you can help, if I can help it. 55:56.080 --> 55:58.200 Like I don't even get ones with lane assist. 55:58.200 --> 55:59.980 I don't trust it at all. 55:59.980 --> 56:04.820 I appreciate I'm in the wrong industry to be saying that, but I don't trust it. 56:06.720 --> 56:10.500 So before we finish, I just want to give a few acknowledgements. 56:10.500 --> 56:13.620 I'd like to say thanks to my colleagues who contributed to this project. 56:13.620 --> 56:18.560 The main contributors were Joel, Rich and Terry, who all worked heavily on the project. 56:18.860 --> 56:27.160 I'd also just like to thank my colleague Kytan, who, although he's no longer with us, he provided a lot of support to me while I was working on this project. 56:28.040 --> 56:34.200 Surrey University also gave us quite a bit of advice on cab networks while we were doing our research work. 56:34.260 --> 56:42.580 I'd also like to thank Zenzik for funding this work and F-Secure for letting me work on it, and KFC for fueling my existence. 56:42.580 --> 56:46.920 I was very upset while they were shut in the UK due to the lockdown, but they've reopened now. 56:47.060 --> 56:48.440 Everything's wonderful again. 56:50.060 --> 56:51.940 So that's the end of my talk. 56:51.940 --> 56:56.820 I think we're doing questions in the chat now, or you can tweet me on Twitter. 56:56.820 --> 57:00.800 I mainly shitpost, so yeah, but go for it. 57:00.800 --> 57:01.880 Or drop me an email. 57:01.880 --> 57:03.460 I've got my email address there. 57:03.760 --> 57:05.060 Thank you for your time. 57:05.060 --> 57:08.460 Thanks for watching, and feel free to ask me any questions.