Thanks for tuning into my talk. This is Houston, we have a problem.
It's a bit weird doing things this way, but I guess this is going to be the new normal now.
So the title of my talk is Houston, we have a problem. I'm here today to talk to you about
Europe's proposals for future intelligent roadways to support connected and autonomous vehicles.
So overview of what I'm going to talk about in this session.
First up, who am I? And where did this project come from?
Then a large portion of this talk is going to be discussing the proposed CAV ecosystem.
There's a lot of proposed components in these future systems.
So you need to kind of know what all the components are before you can understand
the overarching system. I'm also going to be shit talking them as I go.
From here, I'm going to be discussing some of the threats likely to be faced by the ecosystems.
So who's likely to target them, with what resources and what kind of things they're
going to be going after. I'll talk through some example scenarios of how an attacker
might infiltrate the network and what to expect. Next up, I'll provide considerations for how we
can improve the situation. And finally, the conclusions, which, spoiler alert, is mainly
that everything is nightmare. Then we'll have some acknowledgments and time for questions,
which I believe is going to be all types. So a little about me. My name is Vic Harkness.
I've got a degree in robotics and artificial intelligence and a degree in cyber security.
I also worked as a falconer for a bit. After graduating, I worked for DSTL, which is a bit of
the UK Ministry of Defence, then moved to MWR Info Security. That got purchased by F-Secure,
so now I work at F-Secure. And I was the lead author on the bit of work that this talk is
discussing. If you want to talk to me, you can find me on Twitter at Vic Harkness. Talk to me
about falconry, facial recognition systems, biometrics, and network vehicle security.
So an overview of the project. This package of work was done as part of the ZENZIC Cyber
Feasibility Report Project. So the ZENZIC Cyber Feasibility Report Project aims to inform and
advise the UK government on the security of future CAV and ITS networks. So I know I've said CAV a
few times already. I'm going to expand on it now. CAV means connected and autonomous vehicles. ITS,
they're referring to the same general concept. But some people prefer to say CAV, some prefer to say
ITS. I think they're more commonly called ITS. And within the standards documents, they're called
ITS. But ZENZIC prefers to call them CAV. So throughout this talk, I'll largely be calling
them CAV. So as I'm sure you're aware, automated vehicles are becoming a thing. In the future,
it's envisioned that most people will drive either hyperconnected vehicles or have an
automated vehicle. To support this future, the creation of sensor-rich intelligent roadways has
been proposed. The UK government wants to buy into this future. 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. They want the most robust roadways, and they want them to be the most secure.
And the ZENZIC Cyber Feasibility Report feeds into this goal. So seven companies worked on the
problem space, and ZENZIC created a summary report. This summary report went off to government to help
decide what they should do about future roadways. 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. But to understand the problem, we needed to look at the space as a whole.
So our paper provides an overview of the entire space, as well as making recommendations on
testing at scale. There should be a link to the white paper available by the time you're watching
this. 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. 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. So it's a fairly Europe-centric
presentation, I'm afraid. But there are very similar proposals in the US, and there's kind
of a lot of equivalency between the proposals. So hopefully it's still useful for non-European
people. 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.
So first we're going to talk about the CAV ecosystem components.
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.
Vehicles are no longer expected to be used solely as a means of transportation.
They guide us to our destinations using maps. They advise us on the best route to take using
traffic information. They advise us, they entertain us using audio and video. In the future, they will
ease the burden of driving altogether by being able to autonomously navigate to our destinations.
To facilitate this, vehicles contain complex internal networks. Future vehicles are more
akin to computer networks. Lots of smaller computers all working on smaller parts of the task
network together. 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. These future vehicles will
be handling large amounts of data taken from a range of sources. 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.
There's also internal data sources within the vehicle. So you've got your classic integrated
sensors, like your speed sensors, your tire pressure sensor. 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. And you'll also be taking inputs from the
driver of the car, like steering wheel, pressing brakes, that sort of thing.
Some of the proposals we looked at also expected some more novel sensors to be used.
So one of the proposals actually described a system whereby the car can automatically
monitor the biometrics of the user. 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. But with all this data coming from a wide range of sources,
how can you trust it? It's a given that attackers are going to be targeting the
internal vehicle networks. 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. But in general, I will say, handle the data with care. No component should place absolute
trust in the data it receives. 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. 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. 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. So what was once a stop sign is now a speed limit sign,
the car just drives straight through. Another thing the attackers might target are the entertainment
and infotainment systems. They're another good route for introducing malicious data into or
gaining access into connected vehicles. 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. 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. 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. 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. 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.
And we all know how good that is for device security. There's little information so far on
how these will actually look in terms of security and access permission models. 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. Or if it's going to be a bit more like the Android Store, where you can just kind
of go for it. There's no advice on this at this point. But it does seem like they're going to be
an excellent route to break into a vehicle's internal network. I mean, they might end up
being used as part of a jailbreaking solution for the vehicles. 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. 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. But the Lord Elon giveth,
the Lord Elon taketh away. 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.
Perhaps applications will be used for this sort of functionality in future paths.
Certainly seems like a fun area for future investigation, if nothing else.
So what if someone manages to compromise multiple aspects of a vehicle's internal network at once?
The vehicles ideally should be able to detect this and handle it in some way. Because it's not
really the best solution if it just crashes into a wall because it thinks it's the road,
Wile E. Coyote style. 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.
Or is that just going to be a perfect vector for denial of service attacks?
Going to be really annoying and not answer that. Instead, I'll move on to talking about
personal stations. So the Etsy standards propose the use of personal stations.
These are little handheld devices which are designed to be connected to the overarching
cab networks. The exact purpose of them is unclear, but they seem to basically be mobile
phones, like you can install apps on them. It's suggested they're used by low-speed users of
networks such as pedestrians and cyclists. 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.
They're basically mobile phones. 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. Who knows? As far as
security goes, I'd say treat them like mobile phones. They're likely to be an easy target for
because they're quite small, so you want them to be lockable and remotely trackable.
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. So the envisioned future
intelligent roadways will need lots and lots of supporting infrastructure. Infrastructure to
support the connections between connected vehicles, infrastructure to support the automated
decision-making capabilities of automated vehicles. But not all vehicles will be connected
or automated in the future. You're still going to get the people like me who are scared of new
technology and want something more old-fashioned. Unfortunately, you can't quite ignore us weirdos
who refuse to join the borg. 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.
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.
In addition to tracking vehicles, sensors can be used to provide supplementary data into
decision-making systems. For example, local weather information or information on road
conditions could be useful to augment the data already within the systems. It's also quite useful
for automated systems. 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. Whereas an automated system, it doesn't
work quite like the human does. But if it was receiving data saying the road's wet, slow down,
then it will be able to act on that. 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. But unfortunately,
just covering everything with sensors means you've got more things to secure.
So just go search for CCTV on Showdown if you're bored. You can view the CCTV feeds, which isn't
that bad. You know, you'd just be watching cars go along the road. Not really that worrisome. But some of
these cameras are designed to be remotely administered. You get that traditional admin-admin
credentials combo going and suddenly you have access to a node within the CAV network.
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. So just, if you're going to be making sensors that are likely to
end up in CAV networks, please secure them. Don't have easily guessable default creds. Require admins
to use VPNs to remotely administer them. Just do something, please. It seems like it's going to be a
really easy way for attackers to get into the networks.
Next up, we've got roadside units. So these roadside units, or RSUs, are designed to collect,
collate, and forward data from other bits of the network. They'll be taking the data from pretty
much everything in the network. 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. The RSUs can also take data from vendors and transmit it back down to the
vehicles. RSUs are actually physical units proposed to be positioned every 500 meters along the side
of the intelligent roadway. They'll all be connected up in some manner. Some believe that RSUs should
be able to take more active roles within the network, such as directly controlling autonomous
vehicles. I think that's kind of a bad idea for reasons that, you know, should become even more
clear as this talk goes on. The RSUs are envisioned to contain some heavy-duty networking equipment,
including industrial network switches and ITS station border routers. You want the industrial
network switches to be survivable in the harsh environments of constant outdoor usage.
And they also support standard security features, such as MAC address filtering,
remote management, network access, etc. During this study, we read a report that was investigating
the security at one of these proposed roadside units. 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. 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. There's a few proposals of what form this transport medium
could take. Some suggest using LTE. Others suggest that you could just lease actual physical lines
from local councils. There's lots of different approaches, and with different approaches come
different security concerns. But when you're securing these RSUs, you should take a general
network infrastructure security approach. So consider the physical security. Make the locks
on the physical box secure with a tamper detection system. If the RSU is hidden away behind the trees,
monitor them with CCTV systems. 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.
So you need some kind of monitoring, because two days gives you quite a bit of time to play around
with stuff. Make sure that tamper detections are actually followed up upon. So you could
cross-reference things like timings of tamper detections with maintenance schedules. And if
the tamper is determined to not be a false alarm, you should take action. 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. In addition to physical security, you should also follow good network security
best practices. You know, change default creds, disable unused services, all that good stuff.
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. Tangentially, you should consider the security of device maintenance
systems. 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. The engineers carrying out the legitimate
work upon the RSUs will probably have laptops that they're designed to plug into the system.
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. So again, just don't trust things. Don't trust an engineer's
laptop, even though in theory it should be fine. It might not be. Trust no one, not even yourself.
I know I sound like a broken record, but do not place absolute trust in any single aspect of the
system. So data hubs are where all the data lives. The data collated by the RSUs
will end up here. The scales of the data hubs is kind of unclear right now. 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. It's not really clear. It's also not clear who's going to run the data hubs,
or what exactly they'll be doing with the data. But generally, they're probably going to be used
in traffic management systems, traffic analysis, all that good stuff. There's also proposals for
their usage in test beds. I'll be talking a bit more about the test beds later. But the basic
idea is that there'll be regions of roadways, which are designated for vendors to test their
new kit on. 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. 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. 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.
So it'd be great for corporate espionage. Or I mean, what if you could just get into the data
hub and delete all the data in it? You know, could you force a vendor to have to redo trials and
delay the release of a new product? Security of the data hubs is going to be incredibly important.
And it's likely going to be fairly bespoke. I mean, one could probably learn from security
best practices for any large scale sensitive data holder. 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. You know, don't let little bobby tables ruin your day. Likewise, you need some form
of accountability within the system. 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. So you can actually
address it. 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.
So transmission medium, there's the potential for lots of different data transmission media to be
used within these future networks. I'll be talking about the connection issues within the next
section, when I discuss the bespoke protocols that have been proposed. So LTE is like the most
obvious connectivity choice. It's simple, it's fairly accessible nowadays, it's reasonably cheap.
Some vehicles already make use of LTE. You've got systems such as eCall, which automatically calls
the emergency services if it detects you're in a crash. And LTE can also be used to transmit
over-the-air software to vehicles, software updates, sorry, to vehicles. I mean, in future
cab vehicles, LTE will probably be used by applications, and maybe also by some of the
roadside sensors, who knows. 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. As mentioned earlier, it's been proposed that lease lines could be used to transmit data
from RSCs back to data hubs. 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. 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. Finally, we get to the wireless local area networks.
Small WLANs within vehicles are proposed, which allow users to get onto the internet via their
vehicle. However, it's also been proposed that giant WLANs could be used to handle the majority
of communications between CAV network nodes. To me, this proposed usage of wireless local area
networks for data transmission between CAV nodes is super interesting. 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. So now that you know about the transmission medium,
what about the transmission protocols? Within CAV networks, there's two main types of message
being sent between vehicles and other nodes, CAM and DENIM. CAM standing for cooperative
awareness messages and DENIM being decentralized environmental notification messages. 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. So about CAM, as the name suggests, CAM
are used for cooperative awareness. They're what let the vehicles know where each
other are, so that they can move cooperatively. The CAM acts as a heartbeat for the vehicle, providing
metrics on its current state. This includes things like the current time, the location, heading
direction, speed, if the lights are on or not, all that sort of thing. 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.
They're signed by the pseudonym certificates used within the CAV ecosystem, and I'll talk more about
certificates later. The generation of CAM is controlled by the cooperative awareness basic
service within the vehicle. The CA basic service also receives and processes CAM from other vehicles.
DENIM, on the other hand, are used by vehicles to share an awareness of any events that may have
occurred. 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. Interestingly, the DENIM standards also
contains medical emergency flags. 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.
So once a vehicle's detected an event, it creates a new event DENIM. 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. This DENIM is transmitted out into the world where
it's picked up by the DEN basic service of other vehicle nodes. When a vehicle picks up a DENIM,
the onus is placed upon the receiving vehicle to decide the relevance of the message.
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. If it is, the vehicle
will update its internal records and automatically retransmits the DENIM onwards to other vehicles.
If it's not relevant, it just ignores it. Based on this automatic forwarding, vehicles may be
updated as to the existence of an event as soon as they enter the relevant area. Likewise, if the
initially reporting vehicle leaves the area, the event is not forgotten. Vehicles might also
provide updates to an existing event, even if they were not the first vehicle to report it.
Likewise, vehicles may send a negation DENIM to report that an event has ended.
As I said before, both CAV and DENIM are signed. The proposed certificate system in CAV
is a little bit bonkers in my mind, and I'll describe it later. But the key point here is the
messages are signed. They're not encrypted because CAVs don't join networks in the traditional sense.
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. This could be problematic for a lot of reasons.
It seems like it's going to be really easy to jam a given vehicle by just spamming out messages
near it. 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. 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. There's also no nonce values in CAM and DEN,
so you've got your standard risks of replay attacks there. 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. So say you're an ambulance, the traffic light behavior might
automatically be updated to favor traffic coming from your direction. So why not just continually
replay a packet capture of an ambulance? The closest thing to nonce values that's included
already is timestamps. And these, in my mind, are kind of weirdly done as well. Epochs weren't good
enough for these guys. 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. The remainder is
then untransmitted. 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. But yeah, this slightly weird timeliness metric makes it very hard to discern
the liveliness of messages at a glance. So go ahead with those replay attacks. Another issue
stems from the automatic forwarding of DENIM if the receiving vehicle is within the area of
relevance. Like I mentioned, DENIM describe an event. Vehicles can automatically retransmit
received DENIM. So now something interesting about these cab networks is that a mechanism
is proposed to exist for detecting and punishing malicious behavior. 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. It's unclear how many reports are needed to trigger a ban in the network.
But yeah, after a certain threshold of reports are hit, a vehicle certificate will be temporarily
rescinded. This means that other nodes won't see its messages as valid, and so will disregard them.
So now, when a vehicle automatically forwards on a DENIM, it repackages the message. 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. And I mean, can you see
where I'm going with this? Say the threshold of reports was five. 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. That vehicle would hit the ban threshold quite easily and would be banned
from the network. Suddenly, it's denied access to the CAV network. 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. So how do we transmit these CAM and DENIM?
Ad-hoc networking is required for the CAV networks because of the node's tendency to move around
quite a bit at high speeds. 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.
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. 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. So to create these
ad-hoc networks, the usage of 802.11p standard and OCB mode is proposed. So what's an 802.11p OCB?
802.11 is an IEEE standard for network access control. 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. It's the stuff your home Wi-Fi network probably uses.
So on top of the initial standards, it's 802.11p, which has been specifically designed for vehicle
networks. It's licensed for use in the US's WAVE systems and in Europe's ITS G5 communication
networks. It's been allocated the frequency band of 5.9 gigahertz. It's all fairly standard so far,
but we need to have ad-hoc networks. My home Wi-Fi isn't ad-hoc. I need to connect devices to it.
How does this work with these cars? So in this case, the 802.11p is being used in OCB mode,
which means outside context of BSS or basic service set. Basic service set refers to the
collection of things which can communicate with each other when in 802.11 network.
When you join things to your home Wi-Fi network, they become part of the BSS.
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.
In 802.11p OCB mode, we don't want any of that. We want everything to be able to transmit to
everything else with no need to join the network. 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.
No authentication is required to be able to transmit within these new networks.
So it's up to the receiver to investigate the signing certificate and assess if the
messages are valid or not. But also, because there's no joining to a network, there's no
inbuilt decongestion, apart from some basic polling and automatic rate adjustment.
Can you see where that might lead to some problems?
If you said denial of service, you'd be right. What we've got here is the frequency allocations
for ITSG5. The EU has provided permissions for ITSG5 transmissions within the 5.47 to 5.925
gigahertz range. The nice big, you see that nice big band on the left of the diagram? That's for
broadband radio access networks, radio local area networks, and wireless local area networks.
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, they cannot. So basically,
you've already limited yourself from using a large chunk of the bands you've got available to you.
Next up, you've got your little DSRC band in the middle. Well, that's not for ITSG5,
so we can't use that. On the far right, we've already got a little band 5.905 to 5.925 gigahertz
that's reserved for future use. So basically, the CAV networks are only left with 5.88 to 5.905
gigahertz ranges. 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. So and then there's also there's going to be like a shit ton of sensors on top of
that, too. It doesn't seem like it's going to go well, really. 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. And there's a certificate infrastructure in place, you can still verify the validity and
integrity of received messages, at least. But that's the problem. 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. 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. It doesn't even have to be
junk, really. With the automatic forwarding of denim, you wouldn't need to have many cars in an
area to get a good packet storm going. 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. It just does not seem
like a good idea. Ideally, no vehicle should need to be connected to the CAV networks to operate.
What's being joined would increase the efficiency of operations, each vehicle should be capable of
operating without receiving any data from external sources. So now I'm going to finally talk about
the proposed usage of public key infrastructure and vehicle certificates. The European Commission
has proposed an entire public key infrastructure or PKI for the CAV networks. In their proposals,
they're keen to stress that it's just a proposal, not gospel. But honestly, it's fairly standard
stuff really in the proposal. At the top, you've got your route certificate authority and the
proposals describe in great detail how to physically secure these. There's fairly standard encryption
schemes, you know, they're making use of AES 128. I'm not going to go into too much details on the
PKI since it's all fairly standard from what I could tell. The vendors will have their own
which they'll use to sign vehicle sets before the vehicle is sold. These preloaded sets are
known as enrollment credentials. Once a vehicle is sold now on the road, it uses its
enrollment credentials to request access tokens, which are also known as pseudonyms. And this
request goes via the roadside units and the pseudonyms are returned via the roadside units.
So pseudonyms are where things get really weird in my mind. 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. It's a good idea. They then decided that it would be bad for vehicles to
transmit a unique identifier, because then someone could track them. I think they forgot
that license plates are a thing, but let's put that aside for now. When a vehicle uses its
enrollment credentials to request pseudonyms, it's given a pool of 100 of them. These are valid
for a period of one week. The pseudonyms are used to sign all the cam and denim that the vehicle
sends out, so they can be verified. Pseudonyms are designed to be rapidly changing. On the slides,
I've got the recommendations that come from the European Commission on when you should cycle
pseudonym. And they're kind of weird. So when you start the car, you cycle to a new pseudonym.
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. And it's just so arbitrary. Like, why are we
switching between distance and time? Like, it's weird. But potentially, you could be cycling
through quite a lot of them on one road trip. And you've got a pool of 100 pseudonyms to use, right?
And that's got to last you a week. There's a bit of disparity on what happens when you run out.
According to Etsy, you should request a new pool of 100 once you run out.
The European Commission, however, states that you can just reuse your pool of 100 so long as
they're still within the validity period. But not everyone is always in range of the infrastructure
needed to get more pseudonyms. Because of this, it's possible for vehicles to be preloaded with
up to three months' worth of future dated pseudonyms. I mean, what are the practicalities
of pseudonym cycling? When a vehicle cycles to its next pseudonym, it also needs to update its
IP address. Otherwise, you could trivially track the vehicle for these changes.
The standards documentation recommends the usage of stateless address auto-configuration,
as described in RFC 4862. 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. This allows the nodes to communicate directly between
each other without needing to go through a router, which is appropriate here.
CAVs are intended to use IPv6 addresses. 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. 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. So what's to stop an attacker using this
to track a vehicle's IP address changes? I mean, not much really, so long as you were keeping near
the vehicle. Or just look at the MAC addresses. These are not cycled at the same time as the IP
addresses. Or more interestingly, what if you always claimed that you were already using the
IPv6 address that it's advertising? 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? Again, I think that just denial of service attacks are going to be
a big thing in these future CAV networks. In my mind, pseudonym cycling seems more likely to enable
abuse than to protect privacy. As I mentioned before, there are provisions for vehicles to be
automatically banned from the CAV network via their certificate being revoked. The certificates being
revoked would potentially just be their pseudonym. So the attacker can either reduce the pseudonym
cycle via normal driving or potentially manipulate their system into cycling on demand. It's an ideal
method of ban evasion, really. To combat this, it's been suggested that hardware-trusted
components could be used to provide more robust banning mechanisms. This could be used to wipe the
entire pool being stored on the vehicle. 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. Also, I'm kind of always
wary of placing too much trust in anything that's sold as unhackable. It just seems like a
bull's eye on it. 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.
I mean, Tesla's already had issues with all parts of head units appearing on eBay unwiped.
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. Just pick up a couple
of these and you're good to go with your civil attacks. They might come preloaded with three
months of certs, or maybe they'll still be able to gain new certs from the network. It might not
be the case that the vendor knows the car was written off so its enrollment credentials were
not revoked. 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. 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. Or if you could gain access to multiple pseudonyms at once,
use them to simulate other vehicles. You got someone tailgating you? Start sending out spoofed
CAVs signed with one of your other pseudonyms, simulating a vehicle following behind you.
The tailgater's car might think there's a car in that space already and automatically fall back.
The final major component of the CAV ecosystem that I want to talk about is test beds.
These are regions of roadway which vendors can test their new products on. 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. In current proposals, vendors will be able
to buy access to data from specific regions of test beds at specific times.
It's been suggested this could be facilitated using a web interface which comes with its own
issues really. I mean generally the security of these test beds is going to need to be very high.
Vendors will be testing new products which competition might want to get a sneak peek of.
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. So it's important that these potentially insecure
vehicles cannot be used as vectors into the rest of the CAV network. 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. 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. So here's a rough overview of the threat actors that are likely to target the CAV
networks. At the bottom we've got the most prolific type of hacker, the script kiddie or skiddie.
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. They are low skill, but they are prolific. And they might target the
CAV networks just because, you know, it seems a bit for the lulz, seems fun. Above this tier,
you've got the motivated individuals or hacktivists. These guys actually know what
they're doing. They'll quite often be using free tools, or maybe they found some bespoke tools,
maybe they even wrote some stuff on their own. But they tend to be more disgruntled people who
are ideologically motivated. 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.
Yeah, it's just people trying to rebel against something that they don't like.
Above this tier, you've got the kind of fairly standard criminal groups. They tend to be going
for financial gain. This could be just a small group that's created, say, a piece of ATM malware.
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. They tend to have more cash available
than the tiers below. 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. Above that tier, you've got serious
organized crime groups. These guys have a lot of technical know-how, or at least access to people
and the technical know-how. They've also got access to large amounts of resources, so they can
kind of do what they want, really. 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.
Above this, you've got the nation-state threats. So these guys, their aim is not always financial,
although it can occasionally be. These guys tend to go more for intelligence gathering,
industrial espionage, economic destabilization. They tend to be using advanced tools. You know,
they might even be stealing tools from governments. They'll be using endless zero days.
Generally, there's not too many of them, but when they target you, you're going to have a bad time.
They're very hard to deal with because they have so many resources and technical expertise
at their disposal. And again, we think that people at all these levels are likely to target
the CAV networks. And frankly, there's no way to keep everyone out. 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. But it's important to keep these lower tiers out. You know, you
shouldn't be able to have the skiddy take down your networks. It's not good. The best way to
counter it really is to just have good detection. 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. 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. 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. 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. We've also got the electronic vehicle
charging stations. Those are an interesting target. If you could break those, you could cause quite a
bit of harm, cause a lot of people to be stranded. You've got your public key infrastructure facilities,
like the actual buildings they're stealing them at. If you could get in and steal, you know, the
route certificate, you can have some fun with that. On the digital front, you've got sensor data,
regional events data, so things like weather, you've got your traffic data. 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.
Or if you steal a car, you just tell the GPS to send you home and, you know, you can get in like that.
Within things like testbed results, there's also likely to be financially sensitive information,
or even intellectual property. People could actually get any interesting data off of these
vehicles, perhaps off the infotainment systems. There might be some proprietary systems that
an attacker could gain information about. On top of these assets, you've also got the kind of
intrinsic reputational assets. 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. And, you know, it's causing reputational harm
is a real risk in these areas, you don't want that. So as an example threat,
I'm going to talk about Bob the Grumpy Guy. Bob lives in a small village, which has a section of
smart roadway running through it. He's upset by the speed at which cars travel through the village,
and he wants them to slow down. 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.
He goes online and he spends some time learning about hardware security. One night he takes his
laptop and a crowbar to an RSU, which is hidden behind some trees. The RSU is in a locked cabinet,
but Bob manages to leave it open with his crowbar. The physical tamper detection system on the RSU
detects the unexpected opening of the door and sounds an alarm. An alert is sent to the cab
network requesting investigation. The loud alarm startles Bob and he runs back home. Based on his
experience with the roadside unit, Bob decides he's going to try and use other devices to get
to the RSU. His neighbor, conveniently, has bought a brand new intelligent vehicle, which connects to
these RSUs. 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. Bob reads a web forum and finds unofficial
reports saying the technology used for this hotspot has an abusable authentication vulnerability.
As Bob's house is within the hotspot's range, he exploits the vulnerability to connect to the car
from his bedroom. 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.
After some trial and error, he learns how to send status update messages to the nearby RSU.
Bob uses these to send the RSU many reports that the vehicle is covered,
sorry, that the road is covered in black ice. The RSU collates these reports and does not correctly
identify that they have all come from a single vehicle. 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. The dynamically updated road signs along the village now display half the previous speed
limit. Autonomous vehicles automatically adhere to them, and most manually driven cars do.
Bob is happy once again. His village is nice and quiet and has slow cars going through it.
Next up, we'll talk about an imaginary threat from a malicious nation state.
So the country of Zeron spends a lot of time comparing itself to its neighbor Nerund.
Nerund has a highly developed ITS roadway system with many internationally acclaimed
CAV developers based in the country. 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. Zeron decides corporate espionage would be a much more cost-effective measure
for developing its technical capabilities. Zeron government engages APT32, a Zeron-backed
hacking group. This group is tasked with stealing as much information on CAV as possible from
companies in Nerund. 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. A spearfishing
campaign is launched, and APT77 soon finds itself with footholds within various support functions of
Nerund Auto. APT77 discovers Nerund Auto does not make use of network segregation. The group can
move from an HR employee's computer to one belonging to the tech support team. This tech
support team has access to the research and development team networks. 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. The Zeron government is very happy with their information gathered by
APT77. They ask APT77 to see if their foothold within the Nerund Auto networks can be
leveraged to gain access to a given car. The group quickly discovers that through the remote upgrade
functionality implemented in all Nerund Auto products, they may push malicious code to arbitrary
vehicles. The Zeron government provides APT32 with details of a Nerund Auto brand vehicle
owned by a key Nerund politician. The APT77 group confirms they can push code to this vehicle.
As the code comes from the trusted manufacturer, it is not evaluated. The APT group is able to cause
the politician's car to take arbitrary actions. It's not really what you want.
So, I mean, these are all proposals at this point. They're not things that are existing
in the real world in this state quite yet, thankfully. What can we do at this point?
Generally, I think we need a lot more security research within this area.
There's still plenty of time to address them. I mean, especially with the UK government's
idea of this being the next 10 years. And hopefully the outputs of this project and
the other ZenZip projects will help to inform the future decision-making process.
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.
People really need to stop doing this. 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.
I also think they should take more input from cybersecurity people.
I mean, generally, you, dear watcher of this talk, take a look at these technologies yourselves.
The 802.11p OCB mode seems to be very under-researched. There's not that much information
available on it. But it seems super weird. It seems like there's going to be a lot of potential
for abuse. And it seems like you can do a lot of cool stuff with it. 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. F-Secure is quite keen to get hands on
with it. We want to collaborate. Or, you know, just generally chat about 802.11p. It's interesting
stuff. I think the testing at scale is going to be a really big problem. These networks are going
to be absolutely huge. They're probably going to become part of our critical national infrastructure.
And they're going to get popped, for sure, at some point. But we still need to remove the low
hanging through. We don't want the little script kiddies to be able to take bits of the network
down. We don't want Bob to be able to mess with speed limits just because he's annoyed by the fast
cars. And in the case that something does happen, a breach is detected, we need to be able to address
them. So we were proposing a system whereby we can detect the point at which malicious data has
entered into the network. So this would be by re-signing your data at every point of transmission.
So your vehicle, it signs the data when it sends it on, right? This ends up in the roadside units.
The roadside unit collates all this data, and then it signs the bundle of data before it transmits
it onwards to the data hub. Then the data hub collates all this information. And then you
notice that something's a bit wrong or something's malicious. 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. And then that RSU, you can work backwards and be like, okay, well,
it's been signed by this vehicle. 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. 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.
In general, I think that information sharing is going to be really important.
There seems to be this thing of cybersecurity being a competitive advantage. You know,
it's, it's, it's like considered IP almost that you know how to not get hacked. And I don't think
that should be the case. I think there should be better information sharing between the vendors,
and even between like research groups. 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.
So by sharing information between each other, you can be better prepared for these attacks to come
in. 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. 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. 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. Just don't, just don't, don't do that.
There needs to be more considerations for cybersecurity when designing these systems.
Stop passing the buck on cybersecurity or you'll make baby Jesus cry.
There's a lot of weird shit in these proposals that people should look at more.
AO211 POCB mode is weird shit. Pseudonyms are even weirder shit. And lastly, I'm never getting
a connected autonomous vehicle if you can help, if I can help it. Like I don't even get ones
with lane assist. I don't trust it at all. I appreciate I'm in the wrong industry to be saying
that, but I don't trust it. So before we finish, I just want to give a few acknowledgements.
I'd like to say thanks to my colleagues who contributed to this project. The main contributors
were Joel, Rich and Terry, who all worked heavily on the project. 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. Surrey University also gave us quite a bit of advice on cab networks
while we were doing our research work. 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. I was very upset while they
were shut in the UK due to the lockdown, but they've reopened now. Everything's wonderful again.
So that's the end of my talk. I think we're doing questions in the chat now, or you can tweet me on
Twitter. I mainly shitpost, so yeah, but go for it. Or drop me an email. I've got my email address
there. Thank you for your time. Thanks for watching, and feel free to ask me any questions.