So we just presented on the main stage a framework for interfacing with the vehicular ad-hoc network,
rather for, oh, true, I'm sure we get one of these guys.
We just presented a framework built on the mainline Linux kernel for interfacing with connected vehicles.
So this concept of V2V, V2X, using, by making modifications to the drivers for cheap, accessible,
consumer-off-the-shelf hardware such that you can do this now with a $20 Wi-Fi card rather than a $5,000 DSRC radio.
We're going to jump around the slides here a little bit more.
We're going to skip a lot of the sort of high-level theoretical things.
The concept of V2X, just to reiterate a little bit,
for those of you who don't know,
for those of you who weren't at the talk,
the rapid, high-throughput exchange of safety information between participants of this vehicular ad-hoc network
to enable enhanced safety and behavioral optimization functions within a highly dense traffic environment.
So what this means is cars and infrastructure points are exchanging state information constantly
in order to optimize things like traffic flow.
There you go.
Sure.
So some of the critical features or aspects of this stuff is to, you know,
I mean, first and foremost, it's safety, to actually allow the cars to provide information to each other
that they can't get through the normal sensors.
So, you know, you can't see inside the car, you can't see inside the engine and, you know, the ECUs and all that stuff.
So they have to encode that into, you know, over-the-air radio,
video message so that other cars in the vicinity can actually decode it
and get an understanding of where the network status is
and kind of route their traffic around that and, you know, coordinate.
So, you know, it has major impacts on every aspect of the transportation network
and really this reaches out into most every aspect of society as we know it.
The transportation infrastructure and especially the connected transportation infrastructure will touch,
you know, all the other sectors of critical infrastructure systems from energy and power distribution
to financial to medical, et cetera.
So the impact of having these connected vehicle technologies is that you enable unprecedented levels
of safety functions that are simply not possible with the sensor networks on board one specific platform.
It has, let's see, we're going to skip around a little bit.
There are already some deployed technologies using V2X, so these are rolling out already
in commercial automobiles for the last couple of years, like cooperative cruise control.
You see a little picture of here where the members of the network, you know,
exchange state information and do some math in order to, you know, reduce the amount of stress and braking
and to really smooth out the behavioral flow of these vehicles.
We have, you know, collision avoidance.
Advanced driver safety.
Driver assistance.
Automated ticketing and tolling is sort of to be implemented almost unquestionably in the future.
This we might not like so much, but it is unavoidable.
So you want to take this one?
Sure.
So our approach to kind of developing these things is to create an open source software solution
that allows you to use commodity hardware, particularly, you know,
specifically the Atheros 9K.
You know, the 9K chipset on Linux to actually do this 5.8 to 5.9 gigahertz transmission in OCV mode
and, you know, do V2V to allow people, to allow anyone to develop their own systems, to test,
to validate, and to kind of further development of the V2V systems and vehicular ad hoc networks
in general so that the future standards can build upon, you know, the cooperative data collection
that anyone can, you know, build on.
So that's kind of what we're trying to buy into essentially.
So I have a particular taste for this because I spent about two years before I brought him on it.
It was one year digging around the depths, the soulless chasm that is Linux kernel trying
to understand the attempts of integration so far.
And what we come to realize is that pretty much every group that has gone out to develop an open source
framework for doing V2V has failed, has orphaned the project partway through, or gone closed source
and produced an incomplete.
And now obsolete implementation that is being considered for deployment.
It's simply unacceptable.
So what we've done is modify the mainline Linux kernel and, you know, a set of standard Linux
networking drivers that enable you to interface with VANet using a $20 Wi-Fi card and any computer
that runs Linux.
So, right.
Lessons learned.
Everybody sucks, sharing is caring, except for herpes.
Standards committees are, need some serious assistance developing these kinds of, you know,
highly complex safety systems that require the participation of the security community.
Hence, this goes back to motivation for developing this framework, giving every member of the
security community, every person here and worldwide the ability to sit down and start
developing applications and understanding fundamentally,
without, you know, doing an analysis of the protocols and the standards.
What?
I got a question.
Would you answer the question right?
I'm probably, is it a really good question?
Because otherwise, can I wait?
Or if it's a really good question, I mean, yeah, come on up.
I mean, everybody's .
Yes.
Is it easy, open participation?
Well, because the standards committees aren't really being engaged by, by a whole lot of
the security community.
I mean, I know, so I know those that, in fact, were part of the committee for, for the distribution
that's developing the security layer, very much incomplete, very much lacking, in fact,
so right, V to V systems are being deployed without any existence of a functional 16092
layer.
That, to me, says that these people need some help developing them, right?
And that's, and that's a...
Is it an example?
Is it an example because there is a standard out there and there are not any?
Well, the, the standard is, is incomplete and still under revision as it is today.
So, I mean, you know, one, one of the examples, one of the examples in 16092 that raised some
concern for me was the actual generation of certificates, right?
I think that they were supposed to be refreshed every day, right?
I mean, that, that was the current, that was the scheme, I believe.
No?
So, I mean, no.
But, but look, look, let's, let's talk about this after we've got about 20 minutes left.
I'd be happy to have this discussion with you and we, and we can come over some of the
distributions of the, of the committee.
I just want to make a question about all this information and they're just simply not
necessarily true.
So, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I,
I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I, I.
Hey, hey, hey, check your privilege.
So, we're going to do stack overview, right?
We go from the physical layer 802.11p, actually I think we'll go back a couple of, a couple
of years.
So the physical layer is comprised by and, and the MAC layer bySEE-802.11p, the management
plane bySEE-1609, and the application layer bySEE J2735.
So, just to give a quick overview, so after SE, next steps is governments and organizations
go over these quickly, 802.11p, so multicast ad hoc mesh networking mode that specifies no use
of authentication, encryption or association. Over 5.8 to 5.9 gigahertz ITS bands, ITS
intelligent transportation systems. They use 5 and 10 megahertz with subcarriers within these
channels. And this modulation scheme called OFDM, which is a standard, you know, standard
Wi-Fi modulation scheme. Okay. So, all right, moving on to 1609. So we have the definitions
for the security services in 02, or in 0.2, the networking services and the message, you
know, the sort of encoding dictionaries in 0.3. 0.4 is the multi-channel operation. And
0.12, I believe, is the identifier allocations for provider service IDs, which are kind of
unique strings issued by IEEE to identify particular service types. All right. And then
J2735 is the application layer, grammar, message dictionary that specifies the safety messages
that will be used, you know, in interoperable V to V systems. So basic safety message is the one
that has been most developed so far. Messages that will be continuously transmitted at periodic
intervals between all members of the VA net that includes state information, things like the
dimensionality, the heading, location, and the type of information that's being sent. And then, you know, the
configuration of the car such that you can perform, you know, behavioral optimization, dispatch,
reactionary, reactionary actions to the vehicle bus to augment the behavior. So they have been under
development since 2005, 2006. The, you know, NHTSA has been drafting documentation, I think, since
about 2004 on this. There's been a lot of talk. There's been many major overhauls to the standards without really, without a
full deployment of a fully complete and compliant implementation, still today. So the development is
very much still in flux. Some major changes to the standards. The actual message encodings have
encountered some slight modifications. But significant enough that the actual parsers
wouldn't work between, you know, going from, I believe, WSB 1 and 2 to 3, I believe. One is the
And the message dictionaries in J2735 have changed dramatically in the actual entire scheme.
The encoding scheme has changed so they're completely inter...
Originally using this thing called DER and then to BER and then to UPER. So three
completely different, semi-related but incompatible encoding formats that change
sequentially through each major revision of the standard. So you have ASN1 specifications
that are entirely incompatible and in fact the most recent one that was published doesn't
actually compile and also uses type systems that are non-standard in ASN1 processing
utilities. So basically I even went so far as to buy the spec which is something I try to
never do and what do you know it doesn't actually compile and you can't actually use it or
parse it. So what we did is take this cobble work that of a broken standard and
implement some of it in C so it's digestible and functional and we'll show that in a little bit
here. You know there's some question in our heads about the development of the standards so
there's been a lot of ambiguity that's being introduced. There's things like the message CRCs,
the verification codes were removed in the most recent revision of J2735 from the
roadside alerts from the emergency vehicle alerts. The rest were the same but you take out the error
checking code. It's kind of weird, right? After 15 years of reservation for these for the ITS bands for use in
intelligent transportation systems now suddenly they're up for sale to the to the telecom talking
about being used for LTE. And we just described the overhauls of ASN1 and 2 a non-standard format. And then
furthermore there's just a lot of ambiguity that existed previously in the standards.
Shall talk subtly. Oh yeah, sure. So I mean these aren't necessarily design flaws, these are just issues that can
potentially lead to some implementation fuzziness. The way that the information elements are packed,
the variable length and the specification in a couple of places, you know, wastes like a byte encoding the length. But the
other places there's actually a bit of ambiguity as to whether or not there should even be a byte there to
begin with as to whether, you know, indicating whether a certain block would be there or not. And that
just, it leads to some issues that could go further down in the pipeline. Not in the standards, not on the
standards level but on the level of implementation where you could have someone develop buggy
implementations that cause issues and, you know, that's undesirable definitely. So I want to get into the code
here since we're pretty short on time and just went over a lot of this. But this is important real
quick. I mean big attack surfaces, so right, the nature of the VANet is that it's accessible from a single
endpoint. From one compromising, one endpoint you can propagate a message over the entire network in
this distributed mesh networking fashion such that you can say store information on a vehicle that does
not get distributed until it goes, say, across like a certain border. And you can
propagate it further. You know, within the, you know, still being compatible with the
standards. So not only, it's not just malformed DSRC messages, it's compliant, compatible DSRC
messages that you can store, you know, deliverables in and propagate at an arbitrary point throughout
the entire network. You can perform privilege escalation in the public key infrastructure to
hijack, say, something like an emergency vehicles certificate, you know, cause cars to move out of the
road or, you know, execute something like a platooning service to disable vehicles. And, you
know, probably the most obvious one maybe we should have started with is it acts as an entry point
to isolated systems. So the DSRC radio is hooked into the vehicle control bus and, right, so if you
can send reactionary actions based on, you know, proximal network activity, that means that you
can also send malicious actions based on your desires, right. So, you know, it's a little bit of a
game changer. There's, there's active and passive adversaries. Um, can, can you wait ten
minutes, pretty please? Pretty please. So I, I've spent two years, hey, check your privilege buddy.
Alright, please don't interrupt me during a talk. Please don't interrupt me during a talk.
Can you get a goon or something? I mean, just like quiet for a minute please and I'm plenty happy to
argue with you when this is over. Um, so, yeah, the, we're gonna go up to our solution and how you
use it, right. So how to interface. And I mean, so this talk really is about providing interface,
or a framework for interfacing with connected vehicles, um, using Linux. So, right, it's never
been easier, right. Just use Linux. Um, uh, you, we modified the Linux networking subsystems,
MAG 802.11, CFG 802.11, um, to support 802.11p and then, uh, developed, uh, 60, developed a
kernel driver which we're, which is being integrated into the mainline kernel for the, all
the 1609, um, you know, data elements and, and members such that you'll be able to use a J2735
networking utility, much like IW, which we provide to dispatch, um, DSRC messages from the
standard Linux wireless interface. Uh, where we start is, so, bottom of the stack, modify the
regulatory domain, add definitions for the intelligent transportation systems channels to
the, uh, Atheros wireless drivers or, you know, to the, to the arbitrary wireless driver right
now. Um, while it is built into the mainline Linux kernel, uh, manufacturers of hardware, a
specific, specify a specific regulatory domain that hardware can operate in. So you have to make a
few slight modifications to each wireless driver, um, which are rather analogous, uh, and,
and, and pretty much equivalent, we, it, it looks the same in the RTL, um, and will release
support for a wide set of standard drivers. Um, you modify the regulatory domain in the kernel
and in the user space utilities, so in the net wireless interface and also, uh, in the
CRDA and wireless RegDB at the, uh, at the user space layer. Uh, we, uh, created a pretty, uh,
And then modify the regulatory domain of the wireless driver, as shown in the second picture there.
And then you define the filtering mechanisms for the 802.11p frames.
So it is defined that 802.11p frames that are compatible are data, QS, and action,
and specifically the types that are listed here.
And you just enforce the use of multicast addressing.
So all messages that are transmitted from 802.11p need to use this broadcast BSS ID, wildcard BSS ID,
six octets of all Fs.
And then in order to implement this in user space, we made some simple modifications to the IW utility,
which I'm sure everyone here who has used Linux is quite familiar with.
You add a definition to join and leave the OCB channels.
Yes.
You add compatibility for 5 and 10 megahertz with sub-carriers within the channels.
And then you can run this command, which we'll provide an example of in our GitHub repo.
I mean, it's that command right up there.
And the result is that you're able to successfully join a 5 gigahertz channel in OCB mode
using exclusive use of the channel and 10 megahertz sub-carrier.
So this is 802.11p implemented.
Next, we're going to talk about...
So the implementation of WAV is mostly to do with the actual message encoding all the way up from the short message
and, you know, the constituent fields in there.
And that's primarily to do with actually just making really big parsers or really big parser and a really big encoder
and encoder and decoder to actually allow you to turn these structures into a byte stream
that goes and inject it into the wireless interface to go over the air.
And then along with that, there's also the channel switching capabilities
that need to be done to switch between the service and the control channel,
which are handled through IW, just dispatching an IW set chan, right?
And then some user space links that allow you to use stuff like PCAP inject
to just send it off to the wireless interface directly and handle it all in user space
and not worry about any kernel messiness.
Still you.
Let's go to the structs real quick.
Okay.
So here is the WAV short message struct.
I mean, this is a pretty simple definition, right?
So you have subtype, version, TPID.
You know, then we have the nheader information element extension,
which is just a block of extra information regarding, like, things like location and heading
or RF information, like transmission power, data rate, that kind of thing.
Moving on is the actual information element block, which contains these optional fields
for the RF parameters, the routing, you know, external DNSs,
and various services that are provided potentially by the actual peer.
Here are the sort of ancillary structs that are filled in there.
We got the routing advertisements, service advertisements,
and then the channel information and service information.
I mean, these are all just, they encode the, I mean, more particular information
for the advanced functions provided in the higher layer services that are built on top of this.
Yeah.
So then J2735 is analogously easy to implement.
So we pulled some specification from the broken ASN1 files, J2735 provided.
So here's the struct, say, for one of the messages, the basic safety message,
which is the one that most compatibility has been added for.
We fill each of the fields up with data elements that are within the accepted range,
as specified by the standard.
And then we take one of the structs that Nick just described.
We fill it up with data and pack the basic safety message just into the data field,
serialize it using an encoding function that we wrote,
and then dispatch it to the wireless interface using PCAP inject.
And we can see, when we pull it up in Wireshark,
it recognizes that a wave short message was transmitted.
The Wireshark plug-in for 1609 doesn't click.
It's incomplete and doesn't recognize all the types of packets and stuff yet.
But we provide means to do this, to do testing and injection.
What you can see here is that we have successfully, using an Atheros 9K $20 Wi-Fi card,
injected a DSRC message into the VANet spectrum.
And the same thing you can do with other kinds of safety messages,
emergency vehicle alerts, and roadside advertisements.
These are just simple examples of the same thing.
And they're just as easy to transmit and inject.
And then when you examine the capture from Wireshark,
you see all the data is there with all the proper padding.
I mean, it's not really going to be too easy to see here.
So, what can you do with this, right?
What we have described so far is a means to, as we said,
transmit and inject into the...
into the wave spectrum, the intelligent transportation channels to interface with the VANet.
So, you want to be a master, see if you can pwn like these.
These are five sort of levels of increasing complexity.
You can perform denial of service on, say, a single antenna.
Well, you can perform denial of service on the PKI infrastructure.
The example here we give is on single antenna systems
where you can actually cause a collision attack by transmitting out of sync
with the rest of the nearby systems.
So, you can do that with the VAN network.
On top of that, there are...
I mean, so you can enumerate over, so the actual nature of the network
is such that you can enumerate over the actual services provided
just by observing the traffic across,
and that allows you to characterize a great number of the architectures
in the cars that are along the road.
And if you can get information about the architecture-specific stuff,
the implementation-specific stuff in the car,
you can actually fingerprint that and say that,
oh, wow, you know, this car is running something that I know is vulnerable
and I want to inject and mess with it in some particular way.
You can, as we described earlier, hijack or perform privileged escalation
in the public key infrastructure to hijack a certificate for an emergency vehicle
or some other kind of privileged user that's allowed to execute built-in services
like , which drives, which makes the vehicle come to a stop on the street,
on the side of the roadway, or, you know, et cetera.
And if anyone would ever want to do that, right,
you can also become a mobile toll booth.
Sure. I mean, if, you know, the compromise,
it requires, you know, the exploitation of these privileged users
to actually gain access to their certificate.
And if you're able to do that, you can swipe their privileges
and actually start masquerading around along the road
and do things you're not supposed to, right?
I mean, that's the idea in terms of these exploits.
Or, you know, not exploits, but these particular attack vectors.
Yep, yep.
So, and there's, you know, this also introduces other types of
potential for exploitation of vulnerabilities that exist today.
Right, you can easily, you know, the point about having, you know,
network access from one single entry point and being able to probably get a message,
that means you can probably get things like malware across the entire network
from one entry point.
And moreover, if an entry point has a vulnerability that is implementation specific,
not even one that exists at a theoretical basis in the standards,
that provides you the ability to compromise all other systems that are compliant,
that might not harbor the same vulnerability.
You can reverse engineer, wirelessly now, reverse engineer vehicular architectures
the same way that you would reverse engineer,
say, a vehicle control bus by performing enumeration of built-in diagnostic services
in the DSRC protocol.
You can, let's see, you want to talk about that?
I mean, so, I mean, some of the nature, or the nature of this,
of the vehicular ad hoc network, and V2X particularly,
is that these vehicles communicate to each other, right?
But the vehicle also bridges out to external networks,
be it through Wi-Fi access points or LTE.
So if the vehicle is able to be compromised by messages going across DSRC,
then you can actually use that, you know, LTE, the card, you know,
the cell phone chip on the card to actually pipe data up to wherever you want,
and potentially even, you know, get data back down and plug in back doors,
whatever the hell you want.
I mean, that's the idea.
Yup.
And even more than pwning, the whole point of this,
while it is neat to showcase,
right, these kinds of attacks,
it's more about providing a platform that allows everyone homogeneously
to participate in the development of these standards
and of these future architectures.
The state of them today very much reflects the need for participation
by the security community to develop these to a point
where they are resilient and robust and ready for deployment
in safety critical infrastructure systems that are going to involve
more network traffic than we've ever seen before in this kind of system.
So you get to participate.
This code, we've released our framework on GitHub,
and we're going to continue development and contribution to it
to extend support to a wide range of wireless drivers
and to continue developing the J2735 interface
as the standards become developed further
and eventually integrate 1609
when the full framework is ready.
So the whole family is complete and ready.
So unfortunately we don't have more time to do,
we'll be doing some stuff over in the Karakin Village.
You can come and ask us questions and we can show you stuff.
I want to thank these guys,
especially that one there in the middle
for helping us get through this over the last couple of years.
So here's the GitHub link.
Here's some references.
And thank you very much.