CAR HACKING VILLAGE - V2X Misbehavior Detection
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
Titel |
| |
Alternativer Titel |
| |
Serientitel | ||
Anzahl der Teile | 322 | |
Autor | ||
Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
Identifikatoren | 10.5446/39846 (DOI) | |
Herausgeber | ||
Erscheinungsjahr | ||
Sprache |
Inhaltliche Metadaten
Fachgebiet | ||
Genre | ||
Abstract |
|
00:00
ComputersicherheitPrimzahlzwillingeDatenanalyseComputeranimation
00:46
Message-PassingICC-GruppeSichtenkonzeptSpannungsmessung <Mechanik>Rechter WinkelAbstimmung <Frequenz>SkalarproduktEinfach zusammenhängender RaumRechenwerkRichtungMessage-PassingMobiles InternetKartesische KoordinatenZellularer AutomatStandardabweichungInteraktives FernsehenTurm <Mathematik>Front-End <Software>ComputeranimationVorlesung/Konferenz
02:25
QuellcodeICC-GruppeKartesische KoordinatenMessage-PassingKlassische PhysikStandardabweichungTelekommunikationMultiplikationsoperatorNotepad-Computer
03:15
Physikalisches SystemTouchscreenInformationTreiber <Programm>Lesen <Datenverarbeitung>MultiplikationsoperatorPhasenumwandlungGreen-FunktionOrdnung <Mathematik>VerkehrsinformationKonditionszahlStrömungsrichtungMessage-PassingRechter WinkelDatenflussGlobale OptimierungVorlesung/Konferenz
04:12
KonditionszahlVerkehrsinformationPhysikalisches SystemKonditionszahlDatenverwaltungSystemzusammenbruchStrömungsrichtungCASE <Informatik>Message-PassingÜberlastkontrolleZentralisatorOrdnung <Mathematik>Richtung
05:02
ZeitstempelOrtsoperatorPhasenumwandlungMultiplikationsoperatorÄhnlichkeitsgeometrieDigitales ZertifikatMessage-PassingOrtsoperatorKartesische KoordinatenComputersicherheitInhalt <Mathematik>Elektronische UnterschriftSystemzusammenbruchTermZeitstempel
05:48
HardwareSoftwarePlastikkarteKernel <Informatik>Message-PassingPunktFlächeninhaltKernel <Informatik>ComputersicherheitRechenschieberMessage-PassingBitModallogikProdukt <Mathematik>HardwareSchreib-Lese-KopfStandardabweichungPlastikkarteProjektive EbeneValiditätOpen Source
06:51
ComputersicherheitComputersicherheitBitDigitales ZertifikatPunktBasis <Mathematik>AnonymisierungMessage-PassingPhysikalisches SystemSystemidentifikationHyperbelverfahrenDatenmissbrauchIdentifizierbarkeitOrdnung <Mathematik>YouTubeKeller <Informatik>BildschirmmaskeElektronische UnterschriftTelekommunikationIdentitätsverwaltungComputeranimation
08:34
Digital Object IdentifierMenütechnikDigitales ZertifikatElektronische UnterschriftArithmetisches MittelGebäude <Mathematik>PunktStandardabweichungSichtenkonzeptSeitenkanalattackeProfil <Aerodynamik>Regulator <Mathematik>ComputersicherheitPublic-Key-KryptosystemVorlesung/Konferenz
09:55
ComputersicherheitNachlauf <Strömungsmechanik>Message-PassingKartesische KoordinatenSeitenkanalattackeRichtungOrtsoperatorRechenschieberHardwareWeb Site
10:39
Ultraviolett-PhotoelektronenspektroskopieTabelleRippen <Informatik>OrtsoperatorEin-AusgabeSoftwareMessage-PassingVektorpotenzialHardwareRoutingOrdnung <Mathematik>Physikalisches SystemPublic-Key-KryptosystemDifferenteUnrundheit
12:12
DatentransferRechnernetzCASE <Informatik>SoftwareDatentransferProzess <Informatik>Message-PassingSchreib-Lese-KopfOrtsoperatorComputeranimation
13:05
ProgrammverifikationDigitales ZertifikatZeitstempelOrtsoperatorTermTeilbarkeitRechenwerkZeichenketteDienst <Informatik>Physikalisches SystemGreen-FunktionCybersexMultiplikationsoperatorProtokoll <Datenverarbeitungssystem>ValiditätRechter WinkelPublic-Key-KryptosystemVariableGruppenoperationBaumechanikMessage-PassingVerschlingungVorlesung/Konferenz
15:43
EinsOrdnung <Mathematik>RichtungPhysikalisches SystemPunktInformationHilfesystemQuick-SortKartesische KoordinatenAnonymisierungDatenmissbrauchKontrollstrukturRechter Winkel
17:21
AnalysisDigital Object IdentifierNummernsystemTriangulierungDifferenteNummernsystemLeistung <Physik>SoundverarbeitungMathematikSoftwareTypentheorieProtokoll <Datenverarbeitungssystem>Mooresches GesetzHardwareMessage-PassingAbstimmung <Frequenz>TelekommunikationOrtsoperatorAnonymisierungExpertensystemVorlesung/Konferenz
18:48
NummernsystemQuellcodeMultiplikationsoperatorDatenmissbrauchIdentifizierbarkeitÄhnlichkeitsgeometrieAnonymisierungPhysikalisches SystemOrdnung <Mathematik>ZahlenbereichMessage-PassingPunkt
19:36
HalbleiterspeicherMooresches GesetzKontrollstrukturHardwareÜbergangMultiplikationSpannweite <Stochastik>QuellcodeWeb SiteDifferente
21:08
StellenringProzess <Informatik>TermSoftwaretestImplementierungStellenringComputersicherheitSprachsyntheseRechenschieberVerkehrsinformationBitPunktSoftwareProzess <Informatik>Computeranimation
22:13
Prozess <Informatik>AbstandTUNIS <Programm>Front-End <Software>VerkehrsinformationEntscheidungstheorieSystemaufrufMAPWeb SiteMessage-PassingVorzeichen <Mathematik>Elektronische PublikationMultiplikationsoperatorVorlesung/Konferenz
23:27
Rechter WinkelWeb SiteInelastischer StoßTreiber <Programm>Message-PassingSystemzusammenbruchEntscheidungstheorieComputeranimation
24:27
Web SiteProzess <Informatik>AlgorithmusDigitales ZertifikatEreignishorizontVerkehrsinformationAnonymisierungMultiplikationsoperatorSoftwaretestSchwellwertverfahrenBildschirmmaskeMessage-PassingComputeranimation
25:22
Physikalisches SystemAnonymisierungURLFlächeninhaltDigitales ZertifikatVerkehrsinformationAutorisierungUmwandlungsenthalpieInformationSchwellwertverfahrenBit
26:20
Prozess <Informatik>AbstandDigitales ZertifikatBildschirmmaskeOrdnung <Mathematik>SoftwareBitDickeOrtsoperatorCASE <Informatik>Ein-AusgabePlastikkarteFehlermeldungMessage-PassingRechter WinkelVorlesung/Konferenz
27:36
Digital Object IdentifierAbstandProzess <Informatik>Message-PassingSchwellwertverfahrenVerkehrsinformationStellenringMultiplikationsoperator
28:31
AbstandProzess <Informatik>BeweistheorieMAPSoftwareEndliche ModelltheorieMessage-PassingCASE <Informatik>TypentheorieDifferenteHoaxPublic-Key-KryptosystemComputeranimation
29:48
Prozess <Informatik>AbstandDigital Object IdentifierMultiplikationsoperatorMessage-PassingPhysikalisches SystemAnonymisierungDifferenteAutorisierungSystemzusammenbruch
30:52
Prozess <Informatik>AbstandProdukt <Mathematik>SeitenkanalattackeDateiformatSystemprogrammierungICC-GruppeBildschirmmaskeVerkehrsinformationInformationBitLokales MinimumProjektive EbeneNichtlinearer OperatorComputersicherheitZentrische StreckungAutonome DifferentialgleichungKette <Mathematik>Einfach zusammenhängender RaumSoftwaretestOrtsoperatorStellenringProdukt <Mathematik>Physikalisches SystemRechter WinkelMailing-Liste
33:19
Kartesische KoordinatenPunktAdditionData MiningComputeranimation
34:05
Statistische HypotheseDigital Object IdentifierPunktInformationEindringerkennungBeweistheorieAdressraumElektronischer FingerabdruckDatenmissbrauchMultiplikationsoperatorNichtlinearer OperatorAxiomApp <Programm>Kette <Mathematik>Konfiguration <Informatik>ComputersicherheitFlächeninhaltPhysikalisches SystemRPCMAPHypermediaRegulator <Mathematik>URLNP-hartes ProblemRechenwerkGesetz <Physik>AnalysisCASE <Informatik>HardwareExpertensystemStatistische HypotheseRückkopplungSichtenkonzeptIdentifizierbarkeitKonfigurationsraumRankingCAN-BusRelativitätstheoriePublic-Key-KryptosystemSchreib-Lese-KopfInfotainmentRechter Winkel
40:57
Ordnung <Mathematik>Kartesische KoordinatenUmsetzung <Informatik>Güte der AnpassungQuick-SortBefehl <Informatik>Selbst organisierendes SystemStapeldateiComputersicherheitSichtenkonzeptBeweistheorieBildgebendes VerfahrenGruppenoperationBimodulPunktSoftwaretestMaschinenschreibenSoftwareentwicklerTeilmengeOrtsoperatorKonditionszahlMultiplikationsoperatorExpertensystemSpieltheorieProgrammierumgebungMathematikTermQuellcodeZentrische Streckung
45:04
MereologieEreignishorizontDatenflussMehrwertnetzQuellcodeRuhmasseATMPhysikalisches SystemHackerElektronischer DatenaustauschSystemprogrammierungLokales MinimumWeitverkehrsnetzGruppoidMultiplikationsoperatorQuellcodeMessage-PassingServerBasis <Mathematik>PunktDifferenteEinfach zusammenhängender RaumStandardabweichungSchwellwertverfahrenPhysikalisches SystemKartesische KoordinatenOrdnung <Mathematik>KonditionszahlRechter WinkelFehlermeldungRegulator <Mathematik>ModemComputersicherheitGemeinsamer SpeicherSimulationExogene VariableVerkehrsinformationInformationRandverteilungTermOrtsoperatorSichtenkonzeptRechenwerkEinflussgrößeZellularer AutomatAdditionZentrische StreckungFront-End <Software>Computeranimation
49:25
Große VereinheitlichungMessage-PassingTreiber <Programm>SystemzusammenbruchStellenringEntscheidungstheorieInformationCASE <Informatik>MultiplikationUmsetzung <Informatik>Front-End <Software>Rechter WinkelIndexberechnungMultiplikationsoperatorHilfesystemTwitter <Softwareplattform>Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:00
First of all, I'd like to thank you, my incredible wife, who just gave birth three months ago to two incredible twins. Without her and her support, I wouldn't be here, so I wouldn't be able to listen to my talk. She made it possible that I can have my, or do
00:23
my daddy duties while I'm also doing this talk over here, so catch up after the talk. Talk to her, don't only talk about baby stuff to her because she is in the industry as well, so you can definitely ask her questions about cars and security and data analysis actually. Yeah, a little disclaimer up front, I have
00:48
to do this because I have several votes. Right now, I don't represent anybody else than me, so I'm not representing my home company, I'm not representing any of the consortia that I'm working for, this is just me. I use
01:06
some material which was published before or not has been published yet by the US DOT or CAMP. I got permission for that, but that's all. I'm not representing them, I'm not speaking on their behalf, it's me purely and my
01:22
views, my opinions. What is We2X? Anybody here in the room that hasn't or let's do it the other way around. Who has heard about We2X and knows what it is? Okay, there are a few that haven't heard about it, so maybe a quick introduction to that. It's about vehicles and infrastructure exchanging
01:42
messages in an unmanaged way. So, there is a direct connection between those devices, there are several standards out there to do this, there's one Wi-Fi based, there's another one cellular We2X or cellular internet based and the idea is that without any infrastructure like cell towers or roadside units, they
02:05
can exchange messages directly. There are some applications that go over infrastructure for sure, like especially when there's a back end involved, but they don't have to for all the applications. So, there are applications that actually require direct interaction because, for
02:22
example, of latency reasons. And I think the easiest way to kind of introduce it to this is just to go quickly through a couple of applications so they get a picture of what's done there. The first one I wanted to show here is forward collision warning. So, there's a car in front of you which suddenly hits the brakes pretty hard and it's
02:42
sending at the same time a message telling you where it is, where it's heading, what speed it has and that it is braking right now. And then regardless if the car is right in front of you so that other car sensors like LIDAR or radar could see this car, you still get this message and could react to that. Even if there are a couple of cars in
03:02
between, you would still get this message and you would be able to react to that. So, there are a couple of advantages to We2X communication over standard or classical car sensors that we have in cars nowadays. Another one is traffic light assistance. So, there's a traffic light which sends out the information when the
03:23
based on that you could give a recommendation to the driver to slow down because it wouldn't make the green light or to start up your automatic stop system in time for the next green phase. Another one is intelligent traffic signal. So, traffic signals that
03:45
are looking at the current traffic situation because there are cars sending messages all the time. And based on that they could just count how many cars are there and especially at intersections they could decide to change the green light or the red light accordingly in order to optimize traffic
04:01
flow. And now you think, awesome, civil attack, I can get a green light, right? And you're probably right if you're capable to do that. Another one, road condition reporting. So, snowplows running around and they're reporting back to
04:20
some central traffic management system, what the current road condition is. And if that's too bad or the weather is pretty bad on the road and it's icy, based on that the traffic management system could decide to reroute traffic in order to avoid traffic congestions or in worst case crashes based on the ice out there. And now you think,
04:43
awesome, traffic rerouting. If I'm able to just manipulate those messages and tell everybody, hey, you can't go through this street here because it's totally ice, it's blocked, whatever, suddenly all the traffic goes through other directions. How does this work? So just two
05:05
examples that I brought in terms of message content. BSM is the basic safety message, what's in there, speed, position, heading, acceleration, time stamp, signature and a certificate. Based on that you can implement a whole bunch of VtoV safety applications, crash
05:24
avoidance applications. And another one is the spat, that's about traffic light faces, the time stamp and the signature and certificate. Why I'm showing this here is there are two similarities, here are two items here in both of those messages and that is the signature and the certificate. So that's
05:43
security. So much for a quick introduction to VtoX, if you want to know more, Craig is here, you can buy his book in the vendor area, there is a pretty good introduction to VtoX in there, which I think is a pretty good starting point if you want to
06:01
learn more about that. If you're already a little bit more advanced and you want to implement stuff, just a quick highlight to a project that was just published at Blackhead by Onboard Security, it's the last point on the slide, Onboard Security published a open source DSRC validation tool which generates messages that are compliant to the
06:22
necessary standards. You could do this with the first hardware that are listed there in GNU radio. There are also, there's also a Linux kernel that I think already is in the upstream, Linux kernel patched, which is already in the upstream, which implements the necessary radio
06:42
capabilities for HD9K based Wi-Fi cards. So if you want to play around with that, that might be good starting points for you. So now let's look a little bit into security. I did a talk here at the Karging Village two years ago. If you want to deep dive into how the system is
07:03
built, how it works, just look up this talk, it's on YouTube I think. The important point that I want to highlight here is pseudonym certificates. So those certificates that we saw in the messages before are so-called pseudonym certificates that are used to create signatures and enable the other side, the
07:22
receiving end, to verify those signatures. They're called pseudonym because Kars have a whole bunch of them, so they kind of can hide their identity behind them. They exchange them on a frequent basis so that nobody could use the certificate in order to track a car. If they would always use the same
07:41
one, you just need to listen to one message at a starting point and then listen to another message at the end point of the traffic and if the same certificate shows up on both sides, you know that this car was traveling from A to B. With plutonium certs, there is some form of protection against that because they're changing those certificates, so you can't use the
08:01
certificate for that. And the idea goes through the whole communication stack. So all identifiers are exchanged on a regular basis at the same time so that there is no identification in there. I just wanted to highlight this because this pseudonymity concept is an important concept for privacy protections in the system and later on, if
08:21
you look at misbehavior detection, what this talk is about, we kind of need to break this pseudonymity to a certain point because otherwise we're not able to identify bad actors. So the first line of defense for V2X security for sure is,
08:40
if you talk about signatures and certificates, the private key. If you just look at what was proposed or is proposed in upcoming or proposed regulations, especially in the US, there are certain standards that are required that you have to implement or certify for your devices. Over here in the US,
09:00
it's FIPS 140-2. In Europe, there is the idea of a commons criteria-based certification and a protection profile for that is about to be published within the next weeks. The point that I want to make here is this first line of defense might not be enough
09:21
because if you look at, for example, FIPS 140-2, there are no protections against side channel attacks required in there and we all know that this is kind of daily business for you guys. So that might not be enough. That doesn't mean that OEMs or other device
09:41
manufacturers that are implementing V2X right now don't add to that, that they don't add side channel protections, but if you look at this from a regulation point of view, this is not enough. So we need to go beyond that. And then if you're building walls, like the security casters that we oftentimes see on slides, don't forget
10:03
that there might be miners that try to go around your walls, under your walls, over your walls. So side channel and direct hardware, security hardware, is not the only asset that you need to protect. In fact, if the device is
10:21
generating a message and the applications built on that are depending on the position, for example, within this message. The question is how does the vehicle that sends the message generates this position? And then you come to GPS as one of
10:42
the inputs. And you don't need to necessarily get access to the private keys in order to get a message into the system which doesn't reflect reality, which doesn't reflect an actual position of a car. You just need to kind of fake the GPS position or the input to the car and then the car itself generates the message for you,
11:02
which is not reflecting reality because you just spoofed the GPS position for that car. And this is actually a recent publication where we demonstrated with a device which is, I think, around about 225 bucks in hardware and some
11:21
clever software where they were able to fake or where they were able to spoof the GPS position in a way that Google Maps actually rerouted the car to a different endpoint. So what it took into consideration with their software is the actually street network. They were able to spoof to a position in a way
11:42
that Google Maps recalculated the route and then ended up in a different endpoint, which is C over here, instead of D where the original or where the user originally wanted to go to. If you take this and would apply this to V2X, you see how easily, or not how easily
12:02
because no one demonstrated yet, but a potential pitfall for V2X messages as well. This whole introduction is just about highlighting the importance of misbehavior detection and especially
12:20
research on that. A quick definition, what is misbehavior? When I say misbehavior, I mean the willful or inadvertent, in this case there was somebody spoofing the message, so the original device doesn't do anything willfully here, transmission of incorrect data within the Card2X network. And incorrect means it doesn't reflect
12:41
reality. It doesn't reflect your position, it doesn't reflect your speed, it doesn't reflect your heading. Misbehavior detection on the other side is the process of identifying this misbehavior. So actually figuring out there was somebody who sent a message
13:00
that was not reflecting reality, so it included incorrect data. A couple of selected research approaches on this, and this work is heavily based on work from colleagues in Europe. One idea that came up in research was a verifiable path history. If there would
13:24
be a way that you could figure out where a car was in the past, you could extrapolate to the current position and then figure out if this car is actually faking its position. This would be especially helpful for against cyber attacks, because if a car
13:44
has a whole bunch of certificates and an attacker is able to get access to certificates, they could simulate a whole bunch of cars. They wouldn't need to use those certificates for just one car. For example, in the US there were talks about having 20 certificates valid per week. In Europe we are
14:01
talking about 100 certificates per week, so in Europe you could, if you get access to that, so that's always a big if, but if you are able to get around the first line of defense, you would be able to simulate 100 cars at the same time, and then you get a green light, right? So, verify your path history. The idea was that there are
14:22
roadside units that send you a time stamp beacon, assigned time stamp actually beacon, that you would then incorporate into your messages, and therefore there is a very small chance that a couple of cars get actually the very same time stamp from a couple of
14:40
those roadside units, and would be able to kind of show you a string that looks exactly the same. If that happens, if you see a whole bunch of cars that have exactly the same verifiable path, you actually have a high chance of seeing a civil attack going on right now. The issue with that is we need
15:03
new protocols, so an issue not necessarily in terms of this won't work, but nobody took it further than that so far. It's a, I think, pretty good idea, but we don't have a protocol yet which reflects that. We would need a new
15:21
roadside unit service for that that somebody has to develop, and actually we would require a high coverage of roadside units that we don't have nowadays. So there's a huge cost factor to that, and actually in this research that's not reflected, nobody is actually calculating what would it cost to deploy a system like that just for misbehavior detection. So the question is, where do
15:42
we go from there? Next one is Plutum linkability. So if you get all those Plutum swords from those cars at a traffic light, same situation, right, intelligent traffic light, you're trying to decide if you change the green face for a certain direction. If you could just take all the Plutum swords and get to know which ones
16:01
belong to a single car and which ones belong to different cars, you would be able again to figure out if there's a civil attack going on. But this would break the privacy point. If there's a single entity in this whole system, and actually this would be a whole bunch of points, all the traffic lights that
16:23
implement this intelligent traffic light application, they would be able to break the plutum entity in order to figure out which Plutum swords belong to the same car. Then an attacker just needs to break into an RSU and get this capability and then could start
16:42
tracking vehicles with that. That's one point. The other point is again that right now we haven't really figured out how you could do this quickly because it doesn't help you if you get this information like 30 minutes later. Not to speak about days where the system is currently with this capability. So you would need to get
17:02
this kind of immediately. And nobody actually calculated so far how much traffic we would see with that, what the performance requirements are for that, and how we would implement that. So again, there's something to this idea, but nobody took it any step
17:20
further so far. Then a couple more radio signal based, you could kind of do triangulation, you could look into power differences. Again, nobody really took this any further so far. There are other schemes that are building
17:41
on the swarm type of this kind of network itself where you kind of vote if a situation that somebody is reporting on the v2x network right now is actually happening. So if there are a couple of devices that are having other capabilities like radar to
18:01
verify if there's an obstacle or if there's actually somebody breaking, you could kind of vote on that and then let everybody know, okay, you can trust this message or you can't. Again, there is something to this idea, but we need a new protocol for that. There is, again, an issue with platinum cert change. What if the attacker just
18:21
changed the platinum cert in between? So you need to do this again and again and again with age change. And the question is, what is the effect on automotive hardware for that? How much more computational power do you need for that? How much more communication will you have on the restricted channels that are available
18:40
for v2x? Again, who's working on that? Reputation based is kind of similar if over time other devices figured out that the messages that you send are actually trustworthy, you get a kind of
19:02
higher reputation point or score and could use that in order to inform newly added devices to the system that you are actually trustworthy source. But then again, this could be used for as an identifier, actually you need to have an identifier to do this over time because otherwise you wouldn't know
19:21
where to add those numbers to or the score to. So this is again implications on the synonymity, on the privacy aspect of the system and nobody really looked into this so far. Then there's another interesting approach which I think was presented just
19:43
recently where you kind of do multi source fusion within the car itself, the receiving end. I think it's a logical step if you have radar, if you have LIDAR, if you have other sensors and v2x is just another sensor, you could kind of fuse all of those
20:00
information and see what the probabilities are that there actually is somebody breaking or that there actually is an obstacle somewhere. I think this is worthwhile looking into but again the question is what are the requirements on the automotive side for that and
20:21
maybe I have to highlight this for people that are not working on the OEM side on the automotive industry but computational power is restricted, energy levels are restricted, memory is restricted because we're trying to do things cheaply and we are having special requirements on hardware because we need to accommodate way
20:42
higher temperature ranges than consumer hardware does. So there are a couple of special specialties to automotive hardware that you need to keep in mind when you design a system like that that OEMs are sometimes fighting about sense. Couple of sense added to a car and you look at one of the big car
21:01
companies 5 million cars per year ascent might make a difference there. So all of this is research. The question is where are we with actually implementations? Do we have anything implemented and tested out and have the data to see if this
21:20
actually works performance wise in terms of detecting quickly misbehavior but also in terms of automotive restrictions. And the only thing that I know of so far is actually work done by camp and by the USDOT. And I just want to dip into this a little bit in the next couple of slides. They have
21:42
a concept where they differentiate between local misbehavior detection and global misbehavior detection. Local misbehavior detection is the process that identifies locally in a device misbehavior or at least creates a suspicion that there is something wrong and then collects data. It's like
22:01
a monitoring classical IT security speech. Some data points, some node in the network that kind of reports back to you whenever there's anything kind of fishy. And then the global side is the backend that collects all of this data, all of these reports and then tries to figure out if there was actually something going on. Because on the device level
22:22
you might not be able to actually make a hard binary decision. Yes, this was misbehavioral. No, this wasn't. So there's, the idea here is that you have a backend which collects from a whole bunch of devices those reports and then somehow or hopefully makes a decision call that or a call to
22:42
identify that this was misbehavioral or not. How does this work? The two, I think two methods that were implemented so far on actual devices are proximity plausibility. So if you see a couple of cars driving around and their messages, they might start
23:01
overlapping because of bad GPS reception or because there's an attack going on. And if this happens a couple of times, then you on the receiving end start being suspicious and saying, huh, there's something going on so I better file a report, collect all those messages that I got that looked like
23:21
they were overlapping, sign them and send them off to the global site. Another one is false warnings. So I got messages that caused me to issue a warning to my driver, for example, for a forward collision warning. Like
23:43
there's a car braking right in front of you and therefore you should engage your brakes. So I already made this decision in my device that there's something going on. I warn my driver or engage the brakes if I have an autonomous car in this way. But then nothing happens, especially when I just
24:01
put it out to the driver, there's no driver reaction. He's not engaging the brakes, he's not steering away and there wasn't a crash. So something with this data was wrong. I got clearly data that there's somebody in my lane braking pretty hard and I'm only that far away, so there had to be a driver
24:21
reaction to that, but there wasn't. So again, I collect this data and send it off to the global site. This kind of process is called misbehavior reporting, collecting the evidence and then sending it off to the global site. The only two algorithms that are implemented so far and got some form
24:44
of testing are device-based and device-based is a pure counter. How often do I see the same synonym search sending messages that led to the receiving end to actually create a
25:00
misbehavior report? It's just a counter. Whenever I see the same synonym search, I count up and when there's a threshold reach like five times for example, I decide okay, this device is misbehaving so I just put it on the CIL or put its certificates on the CIL and let everybody know to not trust this device anymore. The other one is
25:23
a little bit more sophisticated. This one is location specific, so I have a predefined area. I put all the misbehavior reports that are coming from this area together. I look under the synonym search and actually I use
25:41
the capabilities that are built into the system and here I'm referencing again to my talk before or to Craig's book how this actually works, but there is some way that the misbehavior authority within the system is able to check if those reports are actually about the same device or about different devices. It doesn't get the
26:00
synonym search for that so it can't start tracking, it just gets this binary information. They belong together or they didn't. And if they belong together to the same device, and again if there's a threshold reached, the misbehavior detection authority puts the device or its certificates on the CRL.
26:20
And this is the last step which is called device revocation or sometimes blacklisting because in Europe we don't do revocation, we just blacklist the device so it doesn't get new certificates. But there's some form of penalty to the device in order to exclude it from the network. So how
26:41
does this work? An example, we have a misconfigured device or an actual attacker, doesn't matter in this case. There are three cars, A, C and D that are just regular V2X equipped cars and a suspicious device B. And B's position
27:04
is slightly off. Could be programming error, could be that we are in New York City, downtown and we get bad GPS reception or we could beat it as actually an attacker spoofing the GPS inputs to this car. And therefore the
27:22
device or the messages of this device look like that there is a B slash car in my lane, in the lane of A, C and D. This is this kind of ghost car on the bottom right. So we go further and then we see a first overlap. All the cars are recognizing
27:42
this and seeing okay those messages overlap and therefore those cars had to overlap. And they're starting collecting the evidence. They see one overlap, another overlap and a third overlap. And in this example the threshold is three for the local misspave detection. So after three overlaps I decide okay this looks
28:03
suspicious so I send off a report. And as this happened pretty quickly the chances that the sending device was changing its serum certs is pretty low. So it looks like three times overlap with the serum, same serum cert. If the
28:20
global misspave detection looks like those reports it can decide B is misbehaving and therefore it should be revoked. How could you trick this? And again this is conceptual level already. We didn't do a proof of concept for that. But on the
28:41
conceptual level already you could say I have three cars hacked. The chances are if you're capable of hacking one of the cars that you can hack the same model, same model year, same brand and a different car is pretty high because of the reuse in the
29:00
automotive industry. So let's assume they were able as an attacker to gain access to the private keys of three different cars, same model type and so on. Those cars are labeled here A, B and C. And what you do now is you pick a victim which is V in this case, the yellow car. Attackers
29:21
are red. And you create a couple of fake cars A1, B1 and C1 with your messages. So you're sending messages that look like you were in this lane were actually not in this lane, you're just one lane to the left in this case. If you send out those messages
29:43
over the V2X network, everybody will see them. And the other cars, the green cars around there will be noticing those overlaps of your cars with the victim. As you've hacked this system or the cars, you can exchange pseudonym certs for those cars. We
30:00
have either 20 or 100 in Europe. So you could use for each message that shows an overlap, a different pseudonym cert. But you actually don't need to because once you overlapped three times with it, it looks like V is always overlapping whereas the others are not. They're just overlapping with V. So with the currently
30:22
implemented methods on the global side, the misbehavior authority would actually revoke the victim's car. As an attacker, you would have reached your goal in kind of getting this car out of the system because now it can't use or nobody's trusting their messages
30:42
anymore and therefore in crash situations for example, nobody will actually believe that a car is where it is reporting it, that it is. So what do we do? And that's a big question mark because if you look at ongoing work
31:01
right now, what different stakeholders are doing nowadays, I only found so far two stakeholders doing anything. First of all, the USDOT, they took the work that they created together with CAMP and decided that the connected
31:21
vehicle pilots that are being deployed here in the US right now in New York City, in Wyoming and in Tampa should implement some form of minimum viable misbehavior product in their devices. So the capability of doing local misbehavior detection in some form should be implemented so that we get a little bit of a larger scale test out
31:41
in the real world, which is good. And the other one is a sensor-based approach to misbehavior detection. This is kind of the step where we go and start doing sensor fusion. We take lighter and later information and add V2X information on top and see if there are anything, any devices that report a position which doesn't reflect
32:02
physical reality. And if so, report again back up there. I think those are the necessary steps and I can only appreciate the work that the USDOT is doing there. But what else do we see right now? In France there is a project
32:21
called Secure Cooperative Autonomous Systems and they are actually looking into viable misbehavior detection approaches right now and the idea is they implement the full chain. They are following the same approach, local and misbehavior detection, creating reports and then finally revoking or
32:41
blacklisting. But that's it. And the question is if you look into the news as of lately, there are industries deploying the systems. We have OEMs that are putting this into their cars. We have roadside operators that are
33:00
putting devices out there. So this is looks like nobody is really solving this issue that whenever there was somebody able to get around the first line of defense, what happens next? So this is
33:22
a big concern of mine. I don't know if you share this concern. The question I'm asking myself and trying to ask you is why is that? Why is nobody taking this seriously enough? If you look at the applications and I just showed five out of I think fifty or seventy applications that are defined by now for
33:42
v2x, I think this is critical infrastructure. And for critical infrastructure we need to look onto the additional lines of defense beyond the first line. Especially with systems like that that will operate for thirty, forty, fifty years into the future. We have to anticipate that at some point somebody is able to get around
34:01
this. So what do we do? Why is it that nobody actually takes this seriously? So any ideas in the audience? Nope. I have a couple of stomach feelings here. So this is kind of a hypothesis that
34:21
I want to try out here. Maybe there is some misconception about the status of v2x security. Maybe, especially in the higher up ranks, people think that we have it covered. We are already working on this. We are already spending so much money on secure hardware and figuring things out for
34:42
protecting the private keys. So that's enough. That's all we can do. Is that the case? Or is it just that somebody did a risk analysis and said, yeah, we don't have that many cars yet on the road and that many roadside units yet on the road. So this is an issue which
35:02
we need to handle and figure out down the road somewhere. Could be. What adds to this is in the last two years I oftentimes saw a couple of papers published in the car hacking area
35:22
where respectful researchers and heads off to them were able to get, for example, into an infotainment system. And when you read their papers and you're pretty excited about it, especially when you work on automotive, you see, hey, there was somebody able to go around my first line of defense. So what did they do with that? And then in the end, they
35:40
kind of claim we would have been easily been able to control the car by that. And then nothing. And I oftentimes think, okay, so you kind of made me excited about your research. I read the news because the media might get just
36:00
this last line saying, oh, they were able to kind of remote steer the car or brake or whatever. And then it's just we might have been able or we were able, but no proof of concept. From a researcher's point of view, I think, yeah, I don't know. And the feedback that I oftentimes get from the industry is then, yeah, you know,
36:20
those researchers, they were able to get in there, but we have it covered. So there were no chance that they would get ever to the steering wheels or the brakes because we have separated cans and whatnot out there. So this is just for highlighting their research in the press. I don't know.
36:41
Maybe we need to get to the point where research takes this additional step. And I know it's hard work. I know it can be costly. I know it takes time. I know it doesn't make immediate news, especially if you are not able to create a proof of concept, but maybe we should go there and say proof of concept or GTFO. Would that
37:04
help? Because I think on the researcher area and in the security experts area, we all kind of have more or less knowledge on what they would be able to do. But just one or two steps up the chain, it's, oh, no, we
37:21
don't need to work on anything there because we have it covered. There was no proof of concept. Nobody demonstrated that. They're just claiming. So they don't do anything. They don't get the budgets in place. They don't get the time in place, the people in place to work on that stuff. Maybe this adds to that. I don't know.
37:41
Any other ideas? Yep. Yeah. So the
38:24
question was, why do we emphasize privacy so much, or actually with two questions, so much because everybody is carrying around a cell phone already and locations get sent wherever and on the other hand, isn't there anything else in the stack that you could use as a fingerprint and
38:41
therefore ID to track devices? Last question, my answer to this is the idea is there's none of this in there. So MAC addresses get changed and we all, all of the IDs get changed and actually there's already work and I think there are chips available, radio chips that make it hard if not impossible to do a RF fingerprinting to
39:00
use that as an identifier. Why do we do this? Already has that. Yeah. Right.
39:32
Because first of all, we were expecting a regulation and there are laws in place as I do understand in market over here that they have to protect privacy or at least give the
39:40
option for that. And second, I think the OEM industry has to cater not only like the general public but also critical security and privacy concerned citizens. So there is an interest in the industry to protect your privacy especially because we are broadcasting this information. So it's not just Google or some app operator
40:01
that collects your location information and maybe you have even a chance to kind of configure a device in a way that it doesn't send those location information. No, we are broadcasting this. Everybody can collect those information. You just need to set up a passive listening device somewhere and nobody actually would know that you're tracking. So everybody could do
40:21
this and that's the idea why we need to protect it because you don't want to have your spouse looking for where you're going or maybe our higher level target that needs to be protected. So we want to protect as best as we can the privacy of our
40:41
customers. Yeah. If you turn off
41:08
V2V especially you lose all the safety applications and that might be something that you don't want to. Okay, so where do we go from here? We certainly don't want to go back to those times I hope. Um, so just
41:23
rip all the online connectivity out of the cars because it doesn't work. Um, maybe for the last point I made about the proof of concept, maybe we in the industry should critically comment on publications that are coming out. Making statements about the
41:41
probability that this actually works, um, how good the research was, maybe this helps in order to get a public image on the work that is going on and a more realistic view in our organizations higher up. Maybe we have to kind of get in touch with the V2X application developers because they're way more than the security folks
42:02
um, and tell them you have to define for each of your application what misbehavior is and where it could lead to and how you can detect it within your application. Because right now it's a very small group of security experts doing this and as I said there are 70, 80 whatever applications out there. There's no way
42:21
that we can ever catch up. So we need to get applications developers to get at least a basic understanding of what the security issues are and what they could add to prevent that. Have a conversation within your company about V2X and raise the issue and tell them um, what the issues are
42:40
and that we need to work on that. There's another idea. Yeah, that would be pretty awesome. I think the Car Hacking Village actually um, discussed this uh, two years ago to add a V2X um, module to their batch in order to start working on this.
43:01
Unfortunately never managed to do it or I don't know what the issues were but there were only discussions so far. But maybe that's actually a good idea. Maybe we should have V2X CTF challenges next year in the Car Hacking Village. Anything else? Yep. That's a pretty hard problem.
43:48
I don't have an answer right now on this and that's actually my point. We don't have the answers yet. We need more research or we need more um, kind of industry led applicable large scale testing of what research
44:02
already did in order to figure out if this works. Because there are already all kinds of good ideas out there. The selected research approaches that I show today is just a small subset of the ideas that are out there but nobody took them further and actually tested them out to see how do they perform in terms of how quickly and how often do they
44:22
actually identify real misbehavior with the all, all the environment conditions that we have in automotive. Um, how much does it cost? There's always a question if it's too costly nobody will implement it. Um, so all those, there are tons of good ideas. My point is we need to work on that in order to get them implemented.
44:43
Yep. Yeah. So there's an application if, if you're in a distress situation it's called, you don't change your personum sorts.
45:04
Okay, couple of sources. Um, for this, there, I don't know how much time I still have. Um, but as long as nobody kicks me out today I'm happy to take more questions. Yeah.
45:31
That's a pretty good idea. So, um, what is implemented so far in the US is that there is a CL server which provides it in the car or the devices
45:40
it's in their responsibility to connect on a regular basis to get them. Um, with DSRC there's an issue because you don't necessarily can anticipate that they have cellular based on that. So you need to have other approaches like roadside unit that provide connection to the CL server. Or there was another research, um, approach where you have collaborative sharing
46:01
of this information. So cars that already have refreshed CL could share it with other cars that don't have it. Um, but this as far as I know was never really implemented. There might be some simulation work going on right now in this. Um, but this is an issue. When you look at CV2X, um, the new technology
46:21
which is different from this Wi-Fi, uh, this IC standard, you already have a cellular modem in there. So the um, assumption is that you have way more regular connectivity to some backend and therefore could download this information.
46:45
There's a margin of error which is built into the applications. Um, actually you are not supposed to send your you're not supposed to send BSM messages if you're out of a certain threshold which is I think 1.4 meters or something like that. But there's
47:00
some threshold built into that. But it's it depends on the device being able to tell that it's out of accuracy for GPS. So if you spoof there's a higher chance that the device is not able to tell. Especially if it doesn't have additional measures, um, like deck reckoning, um, for its
47:20
positioning. Um, and then it wouldn't know and still would send these messages. And in terms of overlap, again, this is the reason why we don't send immediately any overlap that we see on a local basis but we wait until we saw like three overlaps or five overlaps. Nobody figured out the real threshold for this yet. Again, large scale
47:41
deployments missing this so far in order to test this out. But the idea is you don't report immediately each and every overlap because there could be some weird GPS condition going on right now.
48:04
Yeah. So those are the hard, tough questions for the overall system. Uh, I can only answer them as good as I can because that's not necessarily security, it's more governance and politics and whatsoever. Um,
48:21
I my personal view is we will see many CAs that are operated by the OEMs for example. And they are independent of the country that the vehicle is operated in. They might be still restricted to a certain market like there's a very small chance that a car that
48:42
is produced for the North American market which is Canada, USA and Mexico at least um, gets ever shipped to Europe or China and operated there. So there could be different CAs for North American region, for European region. Um, but there are also discussions there that for example the USDOT
49:02
stands up, puts up ACA for that. And then the Canadian government has to do one and the Mexican has to do one. So there are a couple of different concepts out there. The point is as long as we don't have a regulation we don't know and it's up for industry to figure out and decide on that.
49:22
Yeah. That's especially
49:45
a question of latency I think. Um, I think that the overlap um, that we might see is an indication that like you create a suspicion locally that there is something going on because especially on the receiving end for overlap
50:01
you don't know which one is wrong. Right? You get two messages they are from different cars and they seem to overlap you don't know if car A or car B is wrong. This is the reason why those, this data is then sent off to a global misbehavior detection backend and the global
50:21
backend will collect a couple of reports and if the same device shows up in different reports over and over again then there is a high probability that this device is somehow misbehaving whatever that means. But in between, between the first detected overlap and the decision
50:40
of, on the backend side to actually revoke this device and then getting the information out to all the other cars that this device is now revoked there could be actually crashes happening. Yeah. Does anybody know if I'm running out of time? No? Okay. Yeah.
51:19
So that's, um
51:20
that's another good example or a good question for an example. If you have multiple local misbehavior detection approaches implemented, overlap and warning based then you have a higher probability to make a local decision which one not to trust. But again, especially with the warning based, it might be
51:41
too late for the driver. Because when you figured out, oh there wasn't a crash then there's a suspicion that there was somebody doing it wrongly but in case there is a crash, it's too late. You know everybody was right or the messages were right but it doesn't help you anymore. Okay.
52:01
I get a signal that we're over. So if you'd like to continue the conversation just hit me up after the talk talk to my wife or just send me a message on Twitter. Thanks.