start	end	text
0	4500	Thanks for tuning into my talk. This is Houston, we have a problem.
4740	9060	It's a bit weird doing things this way, but I guess this is going to be the new normal now.
9480	14000	So the title of my talk is Houston, we have a problem. I'm here today to talk to you about
14000	19260	Europe's proposals for future intelligent roadways to support connected and autonomous vehicles.
25160	28040	So overview of what I'm going to talk about in this session.
28160	32360	First up, who am I? And where did this project come from?
32360	36640	Then a large portion of this talk is going to be discussing the proposed CAV ecosystem.
37160	40880	There's a lot of proposed components in these future systems.
40900	44280	So you need to kind of know what all the components are before you can understand
44280	48660	the overarching system. I'm also going to be shit talking them as I go.
48820	53340	From here, I'm going to be discussing some of the threats likely to be faced by the ecosystems.
53340	57420	So who's likely to target them, with what resources and what kind of things they're
57420	61480	going to be going after. I'll talk through some example scenarios of how an attacker
61480	66660	might infiltrate the network and what to expect. Next up, I'll provide considerations for how we
66660	72560	can improve the situation. And finally, the conclusions, which, spoiler alert, is mainly
72560	76940	that everything is nightmare. Then we'll have some acknowledgments and time for questions,
76940	83680	which I believe is going to be all types. So a little about me. My name is Vic Harkness.
83800	88960	I've got a degree in robotics and artificial intelligence and a degree in cyber security.
88960	94920	I also worked as a falconer for a bit. After graduating, I worked for DSTL, which is a bit of
94920	100720	the UK Ministry of Defence, then moved to MWR Info Security. That got purchased by F-Secure,
100720	105600	so now I work at F-Secure. And I was the lead author on the bit of work that this talk is
105600	110620	discussing. If you want to talk to me, you can find me on Twitter at Vic Harkness. Talk to me
110620	116120	about falconry, facial recognition systems, biometrics, and network vehicle security.
118300	123960	So an overview of the project. This package of work was done as part of the ZENZIC Cyber
123960	129860	Feasibility Report Project. So the ZENZIC Cyber Feasibility Report Project aims to inform and
129860	135480	advise the UK government on the security of future CAV and ITS networks. So I know I've said CAV a
135480	146100	few times already. I'm going to expand on it now. CAV means connected and autonomous vehicles. ITS,
147060	151940	they're referring to the same general concept. But some people prefer to say CAV, some prefer to say
151940	156720	ITS. I think they're more commonly called ITS. And within the standards documents, they're called
156720	162360	ITS. But ZENZIC prefers to call them CAV. So throughout this talk, I'll largely be calling
162360	169380	them CAV. So as I'm sure you're aware, automated vehicles are becoming a thing. In the future,
169380	173100	it's envisioned that most people will drive either hyperconnected vehicles or have an
173100	178000	automated vehicle. To support this future, the creation of sensor-rich intelligent roadways has
178000	182960	been proposed. The UK government wants to buy into this future. They don't necessarily want
182960	186920	to be the first people to create these intelligent roadway systems, but they want to be the best to
186920	191000	do it. They want the most robust roadways, and they want them to be the most secure.
191220	196280	And the ZENZIC Cyber Feasibility Report feeds into this goal. So seven companies worked on the
196280	201340	problem space, and ZENZIC created a summary report. This summary report went off to government to help
201340	207300	decide what they should do about future roadways. So my team at F-Secure looked at the V2X, or
207300	212040	vehicle-to-everything aspect of the problem, as well as considering how you might test these future
212040	216860	networks at scale. But to understand the problem, we needed to look at the space as a whole.
216920	221340	So our paper provides an overview of the entire space, as well as making recommendations on
221340	225920	testing at scale. There should be a link to the white paper available by the time you're watching
225920	230060	this. At the time of recording, it's not gone live yet, but I'm sure I can share it in the chat or
230060	236980	something like that. As a quick note, the proposals we looked at for future cap infrastructure have
236980	242420	been provided by the European Telecommunications Standards Institute, the International
243440	249160	Organization for Standardization, and the European Commission. So it's a fairly Europe-centric
249160	254580	presentation, I'm afraid. But there are very similar proposals in the US, and there's kind
254580	259940	of a lot of equivalency between the proposals. So hopefully it's still useful for non-European
259940	264800	people. But hopefully this talk and our white paper provide sufficient information for someone
264800	268700	wishing to enter the problem space to get up to speed on the future proposals.
272340	275960	So first we're going to talk about the CAV ecosystem components.
276700	280900	Whilst our area of the project was dealing with the vehicles-to-everywhere communications,
280900	285460	I still consider the internal systems of a vehicle as an important part of the CAV ecosystem.
285900	289740	Vehicles are no longer expected to be used solely as a means of transportation.
289740	294320	They guide us to our destinations using maps. They advise us on the best route to take using
294320	300340	traffic information. They advise us, they entertain us using audio and video. In the future, they will
300340	305200	ease the burden of driving altogether by being able to autonomously navigate to our destinations.
305380	310480	To facilitate this, vehicles contain complex internal networks. Future vehicles are more
310480	315040	akin to computer networks. Lots of smaller computers all working on smaller parts of the task
315040	319340	network together. So for instance, you could have one computer that's driving the infotainment
319340	323640	system, another one that's driving the lights, but they all need to be connected so that the
323640	328260	infotainment system can be used to control the lights, for instance. These future vehicles will
328260	332680	be handling large amounts of data taken from a range of sources. Some of those are going to be
332680	339340	external, like GPS data, traffic data, data coming in from the vendor, whoever you bought the car off.
339340	343640	There's also internal data sources within the vehicle. So you've got your classic integrated
343640	349720	sensors, like your speed sensors, your tire pressure sensor. But the more futuristic
349720	355380	systems are going to have cameras, range sensors, like sonars to detect where there's nearby
355380	360940	vehicles or detect if someone's walked in front of the car. And you'll also be taking inputs from the
360940	365560	driver of the car, like steering wheel, pressing brakes, that sort of thing.
366080	370240	Some of the proposals we looked at also expected some more novel sensors to be used.
370240	375520	So one of the proposals actually described a system whereby the car can automatically
375520	380840	monitor the biometrics of the user. And so if the driver of the car was to, for instance,
380840	385160	have a heart attack, the system would be able to automatically detect and communicate this and
385160	390820	assumedly call an ambulance. But with all this data coming from a wide range of sources,
390820	395400	how can you trust it? It's a given that attackers are going to be targeting the
395400	400140	internal vehicle networks. I'm not going to talk specifically about data hygiene within
400140	403900	internal vehicle networks, because I'm sure there'll be someone else at the car hacking village
403900	408100	who knows a lot more about it than me and will be able to do a much better job than me of explaining
408100	413600	it. But in general, I will say, handle the data with care. No component should place absolute
413600	418540	trust in the data it receives. But really, it's up to you guys making these systems to decide how
418540	423800	trustworthy components are and design your models based around that trust. Some of the sort of
423800	428700	things that an attacker is likely to target are the vehicle sensors, they make a good potential
428700	433580	entry point for introducing false or malicious data into the vehicle network. I mean, people
433580	438000	are already playing around with the future systems, like people have been using adversarial
438000	443100	examples to generate stickers they can put on road signs, which will cause the car to no longer
443100	448380	classify the road sign correctly. So what was once a stop sign is now a speed limit sign,
448380	455040	the car just drives straight through. Another thing the attackers might target are the entertainment
455040	461520	and infotainment systems. They're another good route for introducing malicious data into or
461520	465880	gaining access into connected vehicles. I mean, we're already getting familiar with the advanced
465880	471040	infotainment systems, we're used to them having a touchscreen now to display maps to play with
471040	476080	our music, all that sort of thing. In some of the CAV proposed documents, these systems are also
476080	480020	going to be doing tourist information for you, you're going to drive past a mountain, and the
480020	484520	car's going to start telling you what the mountain is, the history of it, all about it, for better or
484520	491440	worse. Potentially, they're kind of similar to sensors in the attackers might try and manipulate
491440	497400	data by and manipulate behavior, sorry, by inserting malicious data, such as incorrect traffic data,
497400	501220	or try and use them as a point from which they could pivot to elsewhere within the car's internal
501220	506900	network. The first thing I want to mention is applications, because you've got to have apps if
506900	512040	you want to be futuristic with your system. So in the Envisioned Future Connected and Autonomous
512040	516460	Vehicles, you'll be able to download apps from an app store, like how you would on your phone.
516460	521240	And we all know how good that is for device security. There's little information so far on
521240	525520	how these will actually look in terms of security and access permission models. Don't know if it's
525520	529120	going to be like the Apple Store, where you've got to like have your app pre-approved before it can
529120	532620	be uploaded. Or if it's going to be a bit more like the Android Store, where you can just kind
532620	537880	of go for it. There's no advice on this at this point. But it does seem like they're going to be
537880	542460	an excellent route to break into a vehicle's internal network. I mean, they might end up
542460	549100	being used as part of a jailbreaking solution for the vehicles. So with Teslas, it turns out
549100	553820	that when you buy an upgrade for a Tesla, it can be remotely enabled, you don't actually need
553820	559760	to go to the garage to get it upgraded. So when they had the massive fires in California a few
559760	565600	years back, Tesla remotely pushed free battery updates to cars within the area of effect,
565600	571060	so that they could escape easier, or the drivers could escape easier. But the Lord Elon giveth,
571060	575600	the Lord Elon taketh away. There's been lots of cases of people buying secondhand Tesla models
575600	580780	with certain upgrades enabled, only to have them be remotely disabled again after purchase.
580780	584800	Perhaps applications will be used for this sort of functionality in future paths.
584900	588940	Certainly seems like a fun area for future investigation, if nothing else.
590280	595260	So what if someone manages to compromise multiple aspects of a vehicle's internal network at once?
595420	600460	The vehicles ideally should be able to detect this and handle it in some way. Because it's not
600460	603820	really the best solution if it just crashes into a wall because it thinks it's the road,
603820	608440	Wile E. Coyote style. Perhaps it'd be more appropriate for a vehicle that detects anything
608440	613060	funky going on to drive to the side of the road and refuse to move again until it gets assistance.
613260	616480	Or is that just going to be a perfect vector for denial of service attacks?
616540	620600	Going to be really annoying and not answer that. Instead, I'll move on to talking about
620600	631420	personal stations. So the Etsy standards propose the use of personal stations.
632460	636140	These are little handheld devices which are designed to be connected to the overarching
636140	641060	cab networks. The exact purpose of them is unclear, but they seem to basically be mobile
641060	646160	phones, like you can install apps on them. It's suggested they're used by low-speed users of
646160	651060	networks such as pedestrians and cyclists. I've got a few of the suggestions on the slides, like
651060	656160	using them to check bus times, use them to update bus times, use them to look at maps.
656160	660540	They're basically mobile phones. Maybe this will just morph into an app that you can put on your
660540	664940	own mobile phone so you don't have to carry something extra around. Who knows? As far as
664940	669360	security goes, I'd say treat them like mobile phones. They're likely to be an easy target for
669360	673580	because they're quite small, so you want them to be lockable and remotely trackable.
673940	677520	You also, again, don't want to be completely trusting of data coming from them because
677520	684870	there's a high risk of compromise if they are akin to mobile phones. So the envisioned future
684870	689270	intelligent roadways will need lots and lots of supporting infrastructure. Infrastructure to
689270	693310	support the connections between connected vehicles, infrastructure to support the automated
693310	698550	decision-making capabilities of automated vehicles. But not all vehicles will be connected
698550	702590	or automated in the future. You're still going to get the people like me who are scared of new
702590	707470	technology and want something more old-fashioned. Unfortunately, you can't quite ignore us weirdos
707470	711630	who refuse to join the borg. You still need to know where the old-fashioned vehicles are so that
711630	715950	they can be incorporated into your traffic models or avoided by your automated systems.
720330	725690	Extensions of current CCTV and radar system capabilities, when augmented by additional
725690	730730	sensors, could be sufficient to track old-fashioned vehicles as though they were connected vehicles.
730890	735350	In addition to tracking vehicles, sensors can be used to provide supplementary data into
735350	740030	decision-making systems. For example, local weather information or information on road
740030	745710	conditions could be useful to augment the data already within the systems. It's also quite useful
745710	750310	for automated systems. So if you've got a human driver, they might, you know, notice that it's
750310	755430	raining and the road is wet and so automatically slow down. Whereas an automated system, it doesn't
755430	760450	work quite like the human does. But if it was receiving data saying the road's wet, slow down,
760450	767190	then it will be able to act on that. So thanks to these prolific sensors, it might be the case that
767190	772990	these automated systems would be able to behave in a more human-like manner. But unfortunately,
772990	776170	just covering everything with sensors means you've got more things to secure.
777410	782890	So just go search for CCTV on Showdown if you're bored. You can view the CCTV feeds, which isn't
782890	787750	that bad. You know, you'd just be watching cars go along the road. Not really that worrisome. But some of
787750	792210	these cameras are designed to be remotely administered. You get that traditional admin-admin
792210	796150	credentials combo going and suddenly you have access to a node within the CAV network.
796450	801690	If the network trusts data coming from that CCTV system to a high degree, then the whole network's
801690	806750	going to be having a bad time. So just, if you're going to be making sensors that are likely to
806750	812550	end up in CAV networks, please secure them. Don't have easily guessable default creds. Require admins
812550	818570	to use VPNs to remotely administer them. Just do something, please. It seems like it's going to be a
818570	823570	really easy way for attackers to get into the networks.
823570	829370	Next up, we've got roadside units. So these roadside units, or RSUs, are designed to collect,
829370	833690	collate, and forward data from other bits of the network. They'll be taking the data from pretty
833690	838270	much everything in the network. They can collect data from roadside sensors and vehicles, and
838270	843530	they'll send this data onwards to data hubs, which are processing centers designed to inform
843530	849770	traffic control decisions. The RSUs can also take data from vendors and transmit it back down to the
849770	855670	vehicles. RSUs are actually physical units proposed to be positioned every 500 meters along the side
855670	861250	of the intelligent roadway. They'll all be connected up in some manner. Some believe that RSUs should
861250	865050	be able to take more active roles within the network, such as directly controlling autonomous
865050	870030	vehicles. I think that's kind of a bad idea for reasons that, you know, should become even more
870030	877110	clear as this talk goes on. The RSUs are envisioned to contain some heavy-duty networking equipment,
877110	882830	including industrial network switches and ITS station border routers. You want the industrial
882830	890370	network switches to be survivable in the harsh environments of constant outdoor usage.
890550	894650	And they also support standard security features, such as MAC address filtering,
894650	901310	remote management, network access, etc. During this study, we read a report that was investigating
901310	907650	the security at one of these proposed roadside units. And they found that, yeah, the switch in it
907650	912950	had MAC address filtering in place, but the MAC address of the computer driving the RSU was written
912950	922110	on the side of the box, so not really the best security maybe. The ITS station border routers
922110	926490	within the RSUs are designed as the point through which data from the intelligent roadways
926490	931450	is sent off to the data hubs. There's a few proposals of what form this transport medium
931450	937130	could take. Some suggest using LTE. Others suggest that you could just lease actual physical lines
937130	942570	from local councils. There's lots of different approaches, and with different approaches come
942570	947230	different security concerns. But when you're securing these RSUs, you should take a general
947230	952350	network infrastructure security approach. So consider the physical security. Make the locks
952350	958430	on the physical box secure with a tamper detection system. If the RSU is hidden away behind the trees,
958430	964230	monitor them with CCTV systems. So in the report where they noticed the MAC address was written
964230	969670	on the side of the box, the guy who did that study, he actually set up a tent next to the RSU,
969670	974090	and he camped out there for like two days, and no one noticed him messing around with the thing.
974090	978230	So you need some kind of monitoring, because two days gives you quite a bit of time to play around
978230	983730	with stuff. Make sure that tamper detections are actually followed up upon. So you could
983730	989150	cross-reference things like timings of tamper detections with maintenance schedules. And if
989150	993930	the tamper is determined to not be a false alarm, you should take action. For instance, you could
993930	998670	consider that all data from that node is now unsafe, and so do not make any important decisions
998670	1003990	based upon it. In addition to physical security, you should also follow good network security
1003990	1009330	best practices. You know, change default creds, disable unused services, all that good stuff.
1009570	1014690	Make sure that a procedure for patching devices is in place, encrypt the data being held locally,
1014690	1018050	and when it's being transmitted onwards, especially if you're making use of third-party
1019010	1023830	transmission mediums. Tangentially, you should consider the security of device maintenance
1023830	1029090	systems. It's likely that there'll be engineers coming to, you know, do upgrades on these systems,
1029090	1033990	or do general maintenance tasks, or whatever, really. The engineers carrying out the legitimate
1033990	1038950	work upon the RSUs will probably have laptops that they're designed to plug into the system.
1039090	1042810	They might also have been on a dodgy porn website in the hotel the night before, and be bringing
1042810	1047810	all sorts of nasties with them. So again, just don't trust things. Don't trust an engineer's
1047810	1055790	laptop, even though in theory it should be fine. It might not be. Trust no one, not even yourself.
1055790	1060690	I know I sound like a broken record, but do not place absolute trust in any single aspect of the
1060690	1073440	system. So data hubs are where all the data lives. The data collated by the RSUs
1073440	1078460	will end up here. The scales of the data hubs is kind of unclear right now. I mean, maybe they're
1078460	1082680	going to be regional, maybe they'll be countrywide, maybe they'll be just for a town or a specific
1082680	1088640	section of road. It's not really clear. It's also not clear who's going to run the data hubs,
1088640	1093140	or what exactly they'll be doing with the data. But generally, they're probably going to be used
1093140	1098300	in traffic management systems, traffic analysis, all that good stuff. There's also proposals for
1098300	1103260	their usage in test beds. I'll be talking a bit more about the test beds later. But the basic
1103260	1107960	idea is that there'll be regions of roadways, which are designated for vendors to test their
1107960	1113180	new kit on. Because of this, there's going to be large amounts of data being collected on the test
1113180	1118900	bed roadways, which vendors can then evaluate like post trial to work out the performance of
1118900	1123980	their systems. And that will make test bed data hubs a really high value target for attackers,
1123980	1128240	because there's going to be lots and lots of data. And because people are going to be testing new
1128240	1132020	models of vehicles, it's likely to be about things that aren't actually available yet.
1132020	1136800	So it'd be great for corporate espionage. Or I mean, what if you could just get into the data
1136800	1140800	hub and delete all the data in it? You know, could you force a vendor to have to redo trials and
1140800	1147140	delay the release of a new product? Security of the data hubs is going to be incredibly important.
1147180	1151220	And it's likely going to be fairly bespoke. I mean, one could probably learn from security
1151220	1156540	best practices for any large scale sensitive data holder. But I mean, just once again,
1156540	1160340	you don't want to trust all the data you're receiving into these data hubs,
1160340	1167140	just in general. You know, don't let little bobby tables ruin your day. Likewise, you need some form
1167140	1171940	of accountability within the system. If you find that you're all you're frequently getting malicious
1171940	1176680	data from a certain node, like you're frequently getting bobby tables popping up, you might you
1176680	1180960	want to be able to identify what node this malicious data is coming from. So you can actually
1180960	1185820	address it. Or just if you're getting like, I don't know, like invalid data coming from a node,
1185820	1190500	you want to be able to work out where it's coming from, and address whatever the issue is.
1197220	1202500	So transmission medium, there's the potential for lots of different data transmission media to be
1202500	1206800	used within these future networks. I'll be talking about the connection issues within the next
1206800	1212600	section, when I discuss the bespoke protocols that have been proposed. So LTE is like the most
1212600	1218040	obvious connectivity choice. It's simple, it's fairly accessible nowadays, it's reasonably cheap.
1218100	1223020	Some vehicles already make use of LTE. You've got systems such as eCall, which automatically calls
1223020	1228260	the emergency services if it detects you're in a crash. And LTE can also be used to transmit
1228260	1233120	over-the-air software to vehicles, software updates, sorry, to vehicles. I mean, in future
1233120	1237940	cab vehicles, LTE will probably be used by applications, and maybe also by some of the
1237940	1243800	roadside sensors, who knows. Standard LTE security best practices should be followed, just to make
1243800	1248640	sure it's not too obvious that your tech is using 5G LTE, so it doesn't get blamed for international
1248640	1254540	pandemics. As mentioned earlier, it's been proposed that lease lines could be used to transmit data
1254540	1259960	from RSCs back to data hubs. If you're sending potentially sensitive data over third-party lines,
1259960	1264480	you probably want to try and encrypt it and sign it so that it cannot be read or tampered whilst
1264480	1270220	it's in transit. From what I can tell, lease lines will be used only for data hub communications,
1270220	1274280	though they're not going to be used for like sending data from one car to another, because
1274280	1280240	that just wouldn't make sense. Finally, we get to the wireless local area networks.
1280880	1285240	Small WLANs within vehicles are proposed, which allow users to get onto the internet via their
1285240	1290280	vehicle. However, it's also been proposed that giant WLANs could be used to handle the majority
1290280	1296200	of communications between CAV network nodes. To me, this proposed usage of wireless local area
1296780	1302160	networks for data transmission between CAV nodes is super interesting. It's proposed that it will
1302160	1308720	be enabled through the usage of a relatively new 802.11p standard OCB mode, and as always with this
1308720	1314760	talk, I'll be talking more about that later. So now that you know about the transmission medium,
1314760	1319280	what about the transmission protocols? Within CAV networks, there's two main types of message
1319280	1324600	being sent between vehicles and other nodes, CAM and DENIM. CAM standing for cooperative
1324600	1330840	awareness messages and DENIM being decentralized environmental notification messages. For those
1330840	1338140	of you in the US, these are equivalent to DSRC basic safety messages, where BSM part one is about
1338140	1345500	equivalent to CAM and part two is about equivalent to DENIM. So about CAM, as the name suggests, CAM
1345500	1349800	are used for cooperative awareness. They're what let the vehicles know where each
1349800	1354920	other are, so that they can move cooperatively. The CAM acts as a heartbeat for the vehicle, providing
1354920	1360400	metrics on its current state. This includes things like the current time, the location, heading
1360400	1365980	direction, speed, if the lights are on or not, all that sort of thing. The vehicles don't send these to
1365980	1370420	anyone in particular, they just transmit it out into the world for anyone or anything to pick up.
1370580	1375440	They're signed by the pseudonym certificates used within the CAV ecosystem, and I'll talk more about
1375440	1380300	certificates later. The generation of CAM is controlled by the cooperative awareness basic
1380300	1386300	service within the vehicle. The CA basic service also receives and processes CAM from other vehicles.
1386660	1390680	DENIM, on the other hand, are used by vehicles to share an awareness of any events that may have
1390680	1395620	occurred. An event could be that an accident has occurred ahead, or that the vehicle has detected
1395620	1401000	the presence of ice on the road, that sort of thing. Interestingly, the DENIM standards also
1401000	1405540	contains medical emergency flags. These are the things I spoke about earlier, whereby if the
1405540	1411080	vehicle detects that the driver's had a heart attack or they're in a diabetic coma, it's got a
1411080	1417520	specific DENIM message type to let the other cars around that driver know that that's what happened.
1417520	1423020	So once a vehicle's detected an event, it creates a new event DENIM. This contains info on what the
1423020	1427940	event type is, the geographic area of relevance for the event, and that includes details of what
1427940	1432520	roads will lead up to encountering the event. This DENIM is transmitted out into the world where
1432520	1437780	it's picked up by the DEN basic service of other vehicle nodes. When a vehicle picks up a DENIM,
1437780	1442140	the onus is placed upon the receiving vehicle to decide the relevance of the message.
1442260	1446720	So the vehicle will determine if it's within the geographic area of relevance for the event, or
1446720	1452540	if it's even heading in the correct direction to encounter the event. If it is, the vehicle
1452540	1457640	will update its internal records and automatically retransmits the DENIM onwards to other vehicles.
1457680	1462800	If it's not relevant, it just ignores it. Based on this automatic forwarding, vehicles may be
1462800	1468140	updated as to the existence of an event as soon as they enter the relevant area. Likewise, if the
1468140	1473640	initially reporting vehicle leaves the area, the event is not forgotten. Vehicles might also
1473640	1478000	provide updates to an existing event, even if they were not the first vehicle to report it.
1478000	1482940	Likewise, vehicles may send a negation DENIM to report that an event has ended.
1486360	1491720	As I said before, both CAV and DENIM are signed. The proposed certificate system in CAV
1491720	1497120	is a little bit bonkers in my mind, and I'll describe it later. But the key point here is the
1497120	1502680	messages are signed. They're not encrypted because CAVs don't join networks in the traditional sense.
1502780	1507700	Because there's no network joining, it's all up to the CA and DEN basic services to verify
1507700	1513020	the validity of all received messages. This could be problematic for a lot of reasons.
1513280	1517160	It seems like it's going to be really easy to jam a given vehicle by just spamming out messages
1517160	1521960	near it. Likewise, if an attacker could fuzz the basic service and find a message that would crash
1521960	1526200	it, then there's little resiliency against potentially harmful messages within this
1526200	1531100	environment. It wouldn't even matter if the vehicle was part of the network because it's
1531100	1535940	up to the receiver to determine if the message is valid or not, if it's from an actual member
1535940	1542860	of the network or from an actual vehicle, sorry. There's also no nonce values in CAM and DEN,
1542860	1548140	so you've got your standard risks of replay attacks there. In these future networks, some
1548140	1552220	of the information contained within CAM will be used within the intelligent roadway systems for
1552220	1557020	deciding things like traffic flow. So say you're an ambulance, the traffic light behavior might
1557020	1562240	automatically be updated to favor traffic coming from your direction. So why not just continually
1562240	1567520	replay a packet capture of an ambulance? The closest thing to nonce values that's included
1567520	1573880	already is timestamps. And these, in my mind, are kind of weirdly done as well. Epochs weren't good
1573880	1580320	enough for these guys. What they've gone for is a system whereby the time from the start of 2004
1580320	1587820	is taken in milliseconds, and then it's divided by two to the power of 16, or 65,536, which is
1587820	1592100	coincidentally a touch over the number of milliseconds in a minute. The remainder is
1592100	1597440	then untransmitted. So whilst you could kind of use this in your application as a nonce value,
1597440	1601060	you'd have something that could be replayed roughly every minute or so, depending on your
1601060	1606280	tolerances. But yeah, this slightly weird timeliness metric makes it very hard to discern
1606280	1611760	the liveliness of messages at a glance. So go ahead with those replay attacks. Another issue
1611760	1615840	stems from the automatic forwarding of DENIM if the receiving vehicle is within the area of
1615840	1622980	relevance. Like I mentioned, DENIM describe an event. Vehicles can automatically retransmit
1622980	1627660	received DENIM. So now something interesting about these cab networks is that a mechanism
1627660	1633220	is proposed to exist for detecting and punishing malicious behavior. The details of it aren't
1633220	1637820	really specified in any great detail, but the general gist of it is that nodes can automatically
1637820	1642980	report that certain vehicle sending out malicious data with the vehicle being identified by its
1642980	1648360	signing certificate. It's unclear how many reports are needed to trigger a ban in the network.
1648400	1653240	But yeah, after a certain threshold of reports are hit, a vehicle certificate will be temporarily
1653240	1663180	rescinded. This means that other nodes won't see its messages as valid, and so will disregard them.
1663820	1671300	So now, when a vehicle automatically forwards on a DENIM, it repackages the message. The sender ID
1671940	1677620	that you received of the initial message is then replaced with the sender ID of the vehicle that's
1677620	1683420	forwarding on the message, and it's re-signed using the re-sender certificate. And I mean, can you see
1683420	1687960	where I'm going with this? Say the threshold of reports was five. If you could have five vehicle
1687960	1693220	nodes that you control send out DENIM-containing malicious data near a target, it in theory would
1693220	1697960	just repeat them all on. That vehicle would hit the ban threshold quite easily and would be banned
1697960	1703140	from the network. Suddenly, it's denied access to the CAV network. Generally, I think that
1703140	1706960	mechanisms such as automatic bans need to be carefully considered because there's, you know,
1706960	1716760	there's a real potential for abuse in there. So how do we transmit these CAM and DENIM?
1717980	1722180	Ad-hoc networking is required for the CAV networks because of the node's tendency to move around
1722180	1728520	quite a bit at high speeds. The idea of having passing vehicles connect to RSUs as they go past
1728520	1733360	has been floated, but it was written off because there wouldn't be sufficient time, apparently.
1733360	1740680	I'm not sure how fast people think future cars are going to go, but... So I must apologize, it's now
1740680	1745700	time for acronym o'clock. I'll try and make this as clear as possible, but if you're confused at all,
1745700	1750460	just ask me questions afterwards and hopefully I can explain it a bit better. So to create these
1750460	1757960	ad-hoc networks, the usage of 802.11p standard and OCB mode is proposed. So what's an 802.11p OCB?
1758520	1764940	802.11 is an IEEE standard for network access control. It provides the authentication mechanisms
1764940	1770000	for devices wishing to join a LAN or WLAN, as well as allowing for things like network
1770000	1775400	decongestion to automatically take place. It's the stuff your home Wi-Fi network probably uses.
1775620	1780660	So on top of the initial standards, it's 802.11p, which has been specifically designed for vehicle
1780660	1786960	networks. It's licensed for use in the US's WAVE systems and in Europe's ITS G5 communication
1786960	1792900	networks. It's been allocated the frequency band of 5.9 gigahertz. It's all fairly standard so far,
1792900	1798400	but we need to have ad-hoc networks. My home Wi-Fi isn't ad-hoc. I need to connect devices to it.
1798400	1805180	How does this work with these cars? So in this case, the 802.11p is being used in OCB mode,
1805180	1811280	which means outside context of BSS or basic service set. Basic service set refers to the
1811280	1816420	collection of things which can communicate with each other when in 802.11 network.
1816420	1820360	When you join things to your home Wi-Fi network, they become part of the BSS.
1820560	1825740	And then messages sent within the network are tagged with a BSS ID or basic service set ID,
1825740	1830340	which marks them as belonging to the WLAN, so that all the nodes know if they're actually coming
1830340	1835500	from something within the network and should be, you know, something they should bother with or not.
1836600	1842440	In 802.11p OCB mode, we don't want any of that. We want everything to be able to transmit to
1842440	1847500	everything else with no need to join the network. This allows for the truly ad hoc networking,
1847500	1852480	which is required for CAM and DENIM to just be spat out and have everyone listen to them.
1852760	1856740	No authentication is required to be able to transmit within these new networks.
1856740	1860620	So it's up to the receiver to investigate the signing certificate and assess if the
1860620	1865600	messages are valid or not. But also, because there's no joining to a network, there's no
1865600	1870120	inbuilt decongestion, apart from some basic polling and automatic rate adjustment.
1870120	1873160	Can you see where that might lead to some problems?
1874640	1879580	If you said denial of service, you'd be right. What we've got here is the frequency allocations
1879580	1887580	for ITSG5. The EU has provided permissions for ITSG5 transmissions within the 5.47 to 5.925
1887580	1893680	gigahertz range. The nice big, you see that nice big band on the left of the diagram? That's for
1893680	1899420	broadband radio access networks, radio local area networks, and wireless local area networks.
1900340	1905640	The key point for this is that you need to make use of dynamic frequency selection to avoid
1905640	1911220	co-channel interference if you want to transmit in that range, which, since our CAVs networks
1911220	1916360	aren't going to be connecting to the WLAN in the traditional sense, they cannot. So basically,
1916360	1920680	you've already limited yourself from using a large chunk of the bands you've got available to you.
1920840	1926080	Next up, you've got your little DSRC band in the middle. Well, that's not for ITSG5,
1926080	1932760	so we can't use that. On the far right, we've already got a little band 5.905 to 5.925 gigahertz
1932760	1938920	that's reserved for future use. So basically, the CAV networks are only left with 5.88 to 5.905
1938920	1944840	gigahertz ranges. And I hear there's a lot of cars in general, like there's a lot of them,
1944840	1949020	they tend to all get together on these big stretches, and there's just a lot of them all
1949020	1954940	talking at once. So and then there's also there's going to be like a shit ton of sensors on top of
1954940	1963590	that, too. It doesn't seem like it's going to go well, really. So the proposed ad hoc networks in
1963590	1968270	CAV networks are pretty unique, because it removes the issues from everything having to be joined to
1968270	1972830	the network. And there's a certificate infrastructure in place, you can still verify the validity and
1972830	1978210	integrity of received messages, at least. But that's the problem. When people aren't having
1978210	1983190	to join a network, it means anyone can transmit, you got to process every single message you
1983190	1987570	receive to work out if it's valid or not. I think that in these future CAV networks, denial of
1987570	1992610	service attacks are going to be a real big issue, both on the frequency jamming front, but also from
1992610	1997870	inducing the vehicles to process large quantities of junk messages. It doesn't even have to be
1997870	2002270	junk, really. With the automatic forwarding of denim, you wouldn't need to have many cars in an
2002270	2007710	area to get a good packet storm going. If we decide to go with the scenario whereby roadside units can
2007710	2012930	be used to teleoperate autonomous vehicles, it's going to go kind of badly. It just does not seem
2012930	2019510	like a good idea. Ideally, no vehicle should need to be connected to the CAV networks to operate.
2019510	2023770	What's being joined would increase the efficiency of operations, each vehicle should be capable of
2023770	2033790	operating without receiving any data from external sources. So now I'm going to finally talk about
2033790	2038930	the proposed usage of public key infrastructure and vehicle certificates. The European Commission
2038930	2045050	has proposed an entire public key infrastructure or PKI for the CAV networks. In their proposals,
2045050	2050630	they're keen to stress that it's just a proposal, not gospel. But honestly, it's fairly standard
2050630	2055010	stuff really in the proposal. At the top, you've got your route certificate authority and the
2055010	2060150	proposals describe in great detail how to physically secure these. There's fairly standard encryption
2060150	2065070	schemes, you know, they're making use of AES 128. I'm not going to go into too much details on the
2065070	2073230	PKI since it's all fairly standard from what I could tell. The vendors will have their own
2073230	2079010	which they'll use to sign vehicle sets before the vehicle is sold. These preloaded sets are
2079010	2086010	known as enrollment credentials. Once a vehicle is sold now on the road, it uses its
2086010	2091150	enrollment credentials to request access tokens, which are also known as pseudonyms. And this
2091150	2097330	request goes via the roadside units and the pseudonyms are returned via the roadside units.
2097330	2104410	So pseudonyms are where things get really weird in my mind. The creator of the cab networks heard
2104410	2108730	that privacy is a good thing, and they want to maintain it within these networks, which you know,
2108730	2114610	so far so good. It's a good idea. They then decided that it would be bad for vehicles to
2114610	2119910	transmit a unique identifier, because then someone could track them. I think they forgot
2119910	2126750	that license plates are a thing, but let's put that aside for now. When a vehicle uses its
2126750	2132030	enrollment credentials to request pseudonyms, it's given a pool of 100 of them. These are valid
2132030	2136930	for a period of one week. The pseudonyms are used to sign all the cam and denim that the vehicle
2136930	2142170	sends out, so they can be verified. Pseudonyms are designed to be rapidly changing. On the slides,
2142170	2146210	I've got the recommendations that come from the European Commission on when you should cycle
2146210	2152570	pseudonym. And they're kind of weird. So when you start the car, you cycle to a new pseudonym.
2152570	2158330	You change again after driving in the region of 800 to 1500 meters, then again somewhere after
2158330	2163810	two to six meters, then again after 15 kilometers. And it's just so arbitrary. Like, why are we
2163810	2168930	switching between distance and time? Like, it's weird. But potentially, you could be cycling
2168930	2173710	through quite a lot of them on one road trip. And you've got a pool of 100 pseudonyms to use, right?
2173710	2178610	And that's got to last you a week. There's a bit of disparity on what happens when you run out.
2178870	2182470	According to Etsy, you should request a new pool of 100 once you run out.
2182570	2186610	The European Commission, however, states that you can just reuse your pool of 100 so long as
2186610	2191590	they're still within the validity period. But not everyone is always in range of the infrastructure
2191590	2196190	needed to get more pseudonyms. Because of this, it's possible for vehicles to be preloaded with
2196190	2202110	up to three months' worth of future dated pseudonyms. I mean, what are the practicalities
2202110	2207430	of pseudonym cycling? When a vehicle cycles to its next pseudonym, it also needs to update its
2207430	2212590	IP address. Otherwise, you could trivially track the vehicle for these changes.
2212630	2217570	The standards documentation recommends the usage of stateless address auto-configuration,
2217570	2225910	as described in RFC 4862. So RFC 4862 provides a framework for devices in a network to automatically
2225910	2230650	configure themselves using a mixture of information being advertised by a router
2231190	2236350	and from locally available information. This allows the nodes to communicate directly between
2236350	2240350	each other without needing to go through a router, which is appropriate here.
2240930	2246450	CAVs are intended to use IPv6 addresses. As this address space is quite large, there's a low risk
2246450	2253370	of collision in the pseudo-randomly generated IPv6 addresses created using RFC 4862. But to avoid
2253370	2260450	collision, RFC 4862 nodes do advertise their proposed new IPv6 addresses and give neighbors
2260450	2264870	the chance to respond if they've already claimed them. So what's to stop an attacker using this
2264870	2268910	to track a vehicle's IP address changes? I mean, not much really, so long as you were keeping near
2268910	2273430	the vehicle. Or just look at the MAC addresses. These are not cycled at the same time as the IP
2273430	2277930	addresses. Or more interestingly, what if you always claimed that you were already using the
2277930	2283350	IPv6 address that it's advertising? Like, could you just make a little box that you can tape onto
2283350	2290010	the vehicle, a little address denial box, which automatically lays claim to any address being
2290010	2294690	advertised by the vehicle? Again, I think that just denial of service attacks are going to be
2294770	2301930	a big thing in these future CAV networks. In my mind, pseudonym cycling seems more likely to enable
2301930	2306890	abuse than to protect privacy. As I mentioned before, there are provisions for vehicles to be
2306890	2311610	automatically banned from the CAV network via their certificate being revoked. The certificates being
2311610	2316150	revoked would potentially just be their pseudonym. So the attacker can either reduce the pseudonym
2316150	2321990	cycle via normal driving or potentially manipulate their system into cycling on demand. It's an ideal
2321990	2327090	method of ban evasion, really. To combat this, it's been suggested that hardware-trusted
2327090	2331770	components could be used to provide more robust banning mechanisms. This could be used to wipe the
2331770	2336390	entire pool being stored on the vehicle. But then you still got the problems I talked about earlier,
2336390	2341290	whereby you can just cause a vehicle to be unjustly banned from the network. Also, I'm kind of always
2341290	2349130	wary of placing too much trust in anything that's sold as unhackable. It just seems like a
2349130	2354090	bull's eye on it. And there's nothing to say that an attacker would need to control multiple
2354090	2358550	vehicles even to be able to gain malicious levels of influence within the CAV networks.
2358950	2363750	I mean, Tesla's already had issues with all parts of head units appearing on eBay unwiped.
2363810	2369250	It's likely that whatever contains the CAV, the CA slash then basic service will appear soon
2369250	2374410	enough, harvested from written off cars by unscrupulous garages. Just pick up a couple
2374410	2378750	of these and you're good to go with your civil attacks. They might come preloaded with three
2378750	2382990	months of certs, or maybe they'll still be able to gain new certs from the network. It might not
2382990	2386490	be the case that the vendor knows the car was written off so its enrollment credentials were
2386490	2391050	not revoked. You know, use these to your heart's content to avoid bans and juice bans and others,
2391050	2395630	flood networks and malicious data, whatever you feel like really. Or you could use these to send
2395630	2400790	out your CA slash then basic service crashing messages that you know you've developed previously
2400790	2405990	by fuzzing the basic services. Or if you could gain access to multiple pseudonyms at once,
2405990	2410690	use them to simulate other vehicles. You got someone tailgating you? Start sending out spoofed
2410690	2414830	CAVs signed with one of your other pseudonyms, simulating a vehicle following behind you.
2414830	2419370	The tailgater's car might think there's a car in that space already and automatically fall back.
2421760	2426660	The final major component of the CAV ecosystem that I want to talk about is test beds.
2426820	2431960	These are regions of roadway which vendors can test their new products on. They can include a
2431960	2436560	mixture of private roads and public roads, and they will be absolutely covered in sensors so
2436560	2442080	vendors can receive their high quality trials data. In current proposals, vendors will be able
2442080	2451880	to buy access to data from specific regions of test beds at specific times.
2451940	2457140	It's been suggested this could be facilitated using a web interface which comes with its own
2457140	2462280	issues really. I mean generally the security of these test beds is going to need to be very high.
2462280	2466220	Vendors will be testing new products which competition might want to get a sneak peek of.
2466220	2470520	There's also the very real possibility that the vehicles being tested on these test beds might not
2470520	2475660	yet have the most robust security in place. So it's important that these potentially insecure
2475660	2482500	vehicles cannot be used as vectors into the rest of the CAV network. I'm now going to move on to
2482500	2486740	talk about some of the threats that F-Secure thinks CAV networks will face and talk you through a
2486740	2491760	couple examples of how these could be actualized. If this is an area of interest to you, I'd recommend
2491760	2496040	reading our full white paper as it goes into much more detail about the type of assets which
2496040	2501580	will be considered within CAV networks, as well as talking about specific threat actor groups
2501580	2513930	including APT32. So here's a rough overview of the threat actors that are likely to target the CAV
2513930	2521890	networks. At the bottom we've got the most prolific type of hacker, the script kiddie or skiddie.
2522190	2526570	These are just people sat at home, they're just playing around, they downloaded something off
2526570	2530090	the internet, they've got their low orbit iron cannon, they want to have a play with it, they're
2530090	2536710	trying to impress their mates. They are low skill, but they are prolific. And they might target the
2536710	2542230	CAV networks just because, you know, it seems a bit for the lulz, seems fun. Above this tier,
2542230	2547370	you've got the motivated individuals or hacktivists. These guys actually know what
2547370	2552670	they're doing. They'll quite often be using free tools, or maybe they found some bespoke tools,
2552670	2556750	maybe they even wrote some stuff on their own. But they tend to be more disgruntled people who
2556750	2563890	are ideologically motivated. So like you get the people who are hacking SeaWorld, Sealand,
2563890	2567330	they won in the US because they were pissed off about the treatment of orcas.
2567470	2570810	Yeah, it's just people trying to rebel against something that they don't like.
2571550	2575870	Above this tier, you've got the kind of fairly standard criminal groups. They tend to be going
2575870	2581470	for financial gain. This could be just a small group that's created, say, a piece of ATM malware.
2581470	2585310	Like they often they might just have one techie who creates stuff and then the rest of the money
2585310	2590370	mules that go around picking up the cash, that sort of thing. They tend to have more cash available
2590370	2596630	than the tiers below. So they can actually buy bespoke tools on the dark market, or, you know,
2596630	2601110	fund someone to create tools that are a bit more interesting. Above that tier, you've got serious
2601110	2606230	organized crime groups. These guys have a lot of technical know-how, or at least access to people
2606230	2611450	and the technical know-how. They've also got access to large amounts of resources, so they can
2611450	2616070	kind of do what they want, really. You know, they're going to be able to fund people to research
2616070	2620610	zero days that are targeting certain technology that they're interested in, all that sort of thing.
2621130	2626270	Above this, you've got the nation-state threats. So these guys, their aim is not always financial,
2626270	2631010	although it can occasionally be. These guys tend to go more for intelligence gathering,
2631010	2637250	industrial espionage, economic destabilization. They tend to be using advanced tools. You know,
2637250	2641910	they might even be stealing tools from governments. They'll be using endless zero days.
2642050	2647110	Generally, there's not too many of them, but when they target you, you're going to have a bad time.
2647110	2651570	They're very hard to deal with because they have so many resources and technical expertise
2651570	2656570	at their disposal. And again, we think that people at all these levels are likely to target
2656570	2662630	the CAV networks. And frankly, there's no way to keep everyone out. People who have the absolute
2662630	2667250	dedicated skills and resources, they probably will try and figure a way, they probably will
2667250	2671630	be able to find a way in. But it's important to keep these lower tiers out. You know, you
2671630	2677610	shouldn't be able to have the skiddy take down your networks. It's not good. The best way to
2677610	2682450	counter it really is to just have good detection. So even if a nation-state was able to do something
2682450	2686590	to your network, by being able to detect it immediately, you can start to go into damage
2686590	2690910	control mode, you can start to ignore data coming from that node because you know it's malicious,
2690910	2697370	that sort of thing. There's a whole variety of assets that these threat actors are likely to
2697370	2702270	be targeting within the networks for various different, you know, end goals. So you've got the
2702270	2706650	physical ones, which are the obvious things like you've got vehicles, you've got the roadside units
2706650	2713050	and sensors, but you could also target, say, a garage so that you could perhaps automatically
2713050	2718390	lift data of everything that comes into the garage. Or the backend servers, if the car is still
2718390	2724270	connected to the vendor servers in some way, could you pivot from the vehicle into the vendor
2724270	2729670	servers and, you know, do your cyber crimes through there. We've also got the electronic vehicle
2729670	2734330	charging stations. Those are an interesting target. If you could break those, you could cause quite a
2734330	2740790	bit of harm, cause a lot of people to be stranded. You've got your public key infrastructure facilities,
2740790	2744470	like the actual buildings they're stealing them at. If you could get in and steal, you know, the
2744470	2750490	route certificate, you can have some fun with that. On the digital front, you've got sensor data,
2750490	2756370	regional events data, so things like weather, you've got your traffic data. You've also got personal
2756370	2761390	information probably carried upon these vehicles, like there's the classic of buying old GPS units
2761390	2765670	and, you know, pressing the home button because, you know, people have programmed home into them.
2765670	2770350	Or if you steal a car, you just tell the GPS to send you home and, you know, you can get in like that.
2771670	2776290	Within things like testbed results, there's also likely to be financially sensitive information,
2776290	2780690	or even intellectual property. People could actually get any interesting data off of these
2780690	2785690	vehicles, perhaps off the infotainment systems. There might be some proprietary systems that
2785690	2791130	an attacker could gain information about. On top of these assets, you've also got the kind of
2791130	2798330	intrinsic reputational assets. So things like Tesla's been getting hammered a bit in the US
2798330	2803770	news recently, because of stuff like people putting autopilot on and the car driving into a barrier,
2803770	2808770	or I can't remember which company it was, was trialing a couple years back, one of their
2808770	2814810	self-driving vehicles that killed a pedestrian. And, you know, it's causing reputational harm
2814810	2825240	is a real risk in these areas, you don't want that. So as an example threat,
2825960	2831480	I'm going to talk about Bob the Grumpy Guy. Bob lives in a small village, which has a section of
2831480	2836140	smart roadway running through it. He's upset by the speed at which cars travel through the village,
2836140	2841080	and he wants them to slow down. He's read online that the roadside units placed every 500 meters
2841080	2845160	along the roadside control the speed of which cars drive, so he decides he's going to target them.
2845400	2849980	He goes online and he spends some time learning about hardware security. One night he takes his
2849980	2855460	laptop and a crowbar to an RSU, which is hidden behind some trees. The RSU is in a locked cabinet,
2855460	2860520	but Bob manages to leave it open with his crowbar. The physical tamper detection system on the RSU
2860520	2865220	detects the unexpected opening of the door and sounds an alarm. An alert is sent to the cab
2865220	2871440	network requesting investigation. The loud alarm startles Bob and he runs back home. Based on his
2871440	2875480	experience with the roadside unit, Bob decides he's going to try and use other devices to get
2875480	2881080	to the RSU. His neighbor, conveniently, has bought a brand new intelligent vehicle, which connects to
2881080	2886500	these RSUs. Bob does some research on his neighbor's new car and he discovers that the car broadcasts
2886580	2891180	a hotspot which drivers can connect their phones to. Bob reads a web forum and finds unofficial
2891180	2896360	reports saying the technology used for this hotspot has an abusable authentication vulnerability.
2897420	2902600	As Bob's house is within the hotspot's range, he exploits the vulnerability to connect to the car
2902600	2906920	from his bedroom. Using his knowledge of network security, he's able to pivot through the car's
2906920	2911720	internal networks until he finds the service which allows it to connect interface with the RSU.
2911820	2916400	After some trial and error, he learns how to send status update messages to the nearby RSU.
2916580	2920640	Bob uses these to send the RSU many reports that the vehicle is covered,
2920640	2925640	sorry, that the road is covered in black ice. The RSU collates these reports and does not correctly
2925640	2931080	identify that they have all come from a single vehicle. The RSU updates its models for that
2931080	2935180	area with the presence of black ice and decides that the speed limit in that area should be
2935180	2939880	lowered. The dynamically updated road signs along the village now display half the previous speed
2939880	2945480	limit. Autonomous vehicles automatically adhere to them, and most manually driven cars do.
2945620	2950840	Bob is happy once again. His village is nice and quiet and has slow cars going through it.
2952880	2958480	Next up, we'll talk about an imaginary threat from a malicious nation state.
2958680	2963600	So the country of Zeron spends a lot of time comparing itself to its neighbor Nerund.
2963600	2969060	Nerund has a highly developed ITS roadway system with many internationally acclaimed
2969060	2973560	CAV developers based in the country. Zeron decides it would like to have more developed
2973560	2978860	ITS roadways too, but it doesn't have the resources to fund the extensive CAV development work Nerund
2978860	2983780	has done. Zeron decides corporate espionage would be a much more cost-effective measure
2983780	2991700	for developing its technical capabilities. Zeron government engages APT32, a Zeron-backed
2991700	2996160	hacking group. This group is tasked with stealing as much information on CAV as possible from
2996160	3001780	companies in Nerund. The APT77 team decides their first move should be to gain access to
3001780	3007140	the internal networks of Nerund Auto, the country's leading vehicle manufacturer. A spearfishing
3007140	3012720	campaign is launched, and APT77 soon finds itself with footholds within various support functions of
3012720	3020140	Nerund Auto. APT77 discovers Nerund Auto does not make use of network segregation. The group can
3020140	3024940	move from an HR employee's computer to one belonging to the tech support team. This tech
3025490	3031000	support team has access to the research and development team networks. Once APT77 gains
3031000	3036060	access to Nerund Auto's R&D network, they're able to steal large amounts of research work, including
3036060	3041320	plans for unreleased vehicles. The Zeron government is very happy with their information gathered by
3041320	3047500	APT77. They ask APT77 to see if their foothold within the Nerund Auto networks can be
3047500	3052540	leveraged to gain access to a given car. The group quickly discovers that through the remote upgrade
3052540	3057640	functionality implemented in all Nerund Auto products, they may push malicious code to arbitrary
3057640	3064380	vehicles. The Zeron government provides APT32 with details of a Nerund Auto brand vehicle
3064380	3070740	owned by a key Nerund politician. The APT77 group confirms they can push code to this vehicle.
3070740	3076720	As the code comes from the trusted manufacturer, it is not evaluated. The APT group is able to cause
3076720	3082060	the politician's car to take arbitrary actions. It's not really what you want.
3084120	3088780	So, I mean, these are all proposals at this point. They're not things that are existing
3088780	3093380	in the real world in this state quite yet, thankfully. What can we do at this point?
3095680	3099780	Generally, I think we need a lot more security research within this area.
3100700	3105140	There's still plenty of time to address them. I mean, especially with the UK government's
3105140	3109580	idea of this being the next 10 years. And hopefully the outputs of this project and
3109580	3114200	the other ZenZip projects will help to inform the future decision-making process.
3116180	3121220	So, while we were going over all these standard documents, I'll just count the amount of times
3121220	3126960	that I read security is out of scope for this document or security will occur at another level.
3127700	3131460	People really need to stop doing this. You need to consider the security at every level,
3131460	3136160	in my mind, to make sure that the systems are kind of holistically as secure as possible.
3136840	3140080	I also think they should take more input from cybersecurity people.
3140320	3144940	I mean, generally, you, dear watcher of this talk, take a look at these technologies yourselves.
3145160	3150140	The 802.11p OCB mode seems to be very under-researched. There's not that much information
3150140	3154260	available on it. But it seems super weird. It seems like there's going to be a lot of potential
3154260	3159840	for abuse. And it seems like you can do a lot of cool stuff with it. Incidentally, if you happen
3159840	3165980	to have access to any tech that actually can use it, is already set up to communicate over 802.11p
3165980	3171560	OCB mode, please do reach out to me on Twitter or email. F-Secure is quite keen to get hands on
3171560	3177500	with it. We want to collaborate. Or, you know, just generally chat about 802.11p. It's interesting
3177500	3184500	stuff. I think the testing at scale is going to be a really big problem. These networks are going
3184500	3188960	to be absolutely huge. They're probably going to become part of our critical national infrastructure.
3188960	3193800	And they're going to get popped, for sure, at some point. But we still need to remove the low
3193800	3197980	hanging through. We don't want the little script kiddies to be able to take bits of the network
3197980	3203000	down. We don't want Bob to be able to mess with speed limits just because he's annoyed by the fast
3203000	3210120	cars. And in the case that something does happen, a breach is detected, we need to be able to address
3210120	3215560	them. So we were proposing a system whereby we can detect the point at which malicious data has
3215560	3222540	entered into the network. So this would be by re-signing your data at every point of transmission.
3222880	3228000	So your vehicle, it signs the data when it sends it on, right? This ends up in the roadside units.
3228000	3233460	The roadside unit collates all this data, and then it signs the bundle of data before it transmits
3233460	3239020	it onwards to the data hub. Then the data hub collates all this information. And then you
3239020	3243260	notice that something's a bit wrong or something's malicious. You can then look at the initial data
3243260	3248120	and say, okay, well, the malicious data include this signed bundle come from the RSUs, that RSU,
3248120	3252700	so it's come from that RSU. And then that RSU, you can work backwards and be like, okay, well,
3252700	3257260	it's been signed by this vehicle. And it's just important to be able to backtrace the point at
3257260	3262120	which the incident has occurred, so that you can try and prevent better things, these things from
3262120	3267020	happening again in the future. Like if you notice it's a specific RSU, go investigate that RSU,
3267020	3270840	work out how it got popped so that you can better protect the other nodes within the network.
3273500	3277080	In general, I think that information sharing is going to be really important.
3277120	3281580	There seems to be this thing of cybersecurity being a competitive advantage. You know,
3281580	3286600	it's, it's, it's like considered IP almost that you know how to not get hacked. And I don't think
3286600	3290920	that should be the case. I think there should be better information sharing between the vendors,
3290920	3297140	and even between like research groups. Because if, say you had a phishing campaign targeting your
3297140	3302220	organization as a vendor, it's likely that the attackers will also target similar vendors.
3302220	3306220	So by sharing information between each other, you can be better prepared for these attacks to come
3306220	3310800	in. And you know, if someone does manage to get into your network, you can share that information
3310800	3315360	with other companies so that it doesn't happen to them either. I think you need to get, we need to
3315360	3319640	get over seeing it as like a competitive advantage and just work more collaboratively in general
3319640	3326980	together. So my conclusions for this are current proposals are not fit for purpose, they're going
3326980	3333080	to be a nightmare of just denial of service and all sorts. Just don't, just don't, don't do that.
3333660	3337300	There needs to be more considerations for cybersecurity when designing these systems.
3337300	3341140	Stop passing the buck on cybersecurity or you'll make baby Jesus cry.
3342020	3345400	There's a lot of weird shit in these proposals that people should look at more.
3345760	3352360	AO211 POCB mode is weird shit. Pseudonyms are even weirder shit. And lastly, I'm never getting
3352480	3357340	a connected autonomous vehicle if you can help, if I can help it. Like I don't even get ones
3357340	3362060	with lane assist. I don't trust it at all. I appreciate I'm in the wrong industry to be saying
3362060	3370500	that, but I don't trust it. So before we finish, I just want to give a few acknowledgements.
3370500	3374320	I'd like to say thanks to my colleagues who contributed to this project. The main contributors
3374320	3380660	were Joel, Rich and Terry, who all worked heavily on the project. I'd also just like to thank
3380660	3385520	my colleague Kytan, who, although he's no longer with us, he provided a lot of support to me while
3385520	3392140	I was working on this project. Surrey University also gave us quite a bit of advice on cab networks
3392140	3397880	while we were doing our research work. I'd also like to thank Zenzik for funding this work and
3397880	3403820	F-Secure for letting me work on it, and KFC for fueling my existence. I was very upset while they
3403820	3408440	were shut in the UK due to the lockdown, but they've reopened now. Everything's wonderful again.
3410060	3416080	So that's the end of my talk. I think we're doing questions in the chat now, or you can tweet me on
3416080	3422740	Twitter. I mainly shitpost, so yeah, but go for it. Or drop me an email. I've got my email address
3422740	3428460	there. Thank you for your time. Thanks for watching, and feel free to ask me any questions.