 morning. Welcome to the village talks. I'm speaking about vehicle-to-vehicle and vehicle-to-infrastructure communications and security. If that's the track that you want to go to, you're right here, not over there. I was there in the beginning. Unfortunately, we don't have a projector, so I can't show you my nice slides that I made for you. I tried to publish them afterwards somewhere so you can get them. So I tried to give you the idea of what we're doing, what it's all about. I have to make a small disclaimer at the beginning. I work for an OEM. I'm not speaking on behalf of them today. I have a couple of slides that you don't see today from the US DOT. I'm not speaking on behalf of them over here. I got the permission to show them. You won't see them, so it doesn't matter. But I'm one of the principal investigators for CAMP, which is the crash avoidance metrics partners. I'm working on the topic of the V2X security credential management system. Maybe a question up front, who is familiar with the term V2X? Okay. Who knows how it works? Okay. So V2X is the acronym for vehicle to vehicle and vehicle to infrastructure communications. And actually, it's a messaging, unmanaged messaging, broadcasting messaging from vehicles to other vehicles or from infrastructure to vehicles or the other way around. That's literally the basic technology that's behind it. And on top of that, it's the applications, I guess, what everybody would think about when we speak about V2X. It's applications like, for example, do not pass warnings, so you're behind a car. You want to pass this car, but there's an upcoming car. You can't see the car yet because it's a curve or whatever. And as soon as you hit the indicator, which you show your warning, hey, there's an upcoming car, you shouldn't pass right now. That's something that you can't do with sensors nowadays because sensors always require a direct line of sight. So there are a couple of use cases that you can think of that you can't do with sensors that you can do with V2X. Left turn assist is another one. So if you do it in left turn and there's an approaching car from left side, it's in a situation where you can't look around the corner so you don't know if there's actually somebody. And if you drive too fast towards the intersection and there's actually a car coming on, it will show you again a warning saying, hey, you better break. It's all about warnings right now. And for the foreseeable future, it will not be anything else. We might, or OEMs start thinking about sensor fusion. But what will never happen is I think that any OEM will purely rely on V2X messages to engage brakes or something like that. This is not going to happen. What might be happen is that you use it for existing, um, assistant functions like automatic braking and you use it as an additional input to slow down the car, for example, to de-accurate but not to engage brakes. You will engage brakes as soon as a sensor can verify this information that you got up front. Um, just to set, make the setting clear that we're talking about. Another one when you speak about, um, infrastructure to vehicle, um, you can think about a traffic light that sends the information, uh, I'm red right now. Um, and if you approach too fast, it will show you again a warning that you should break. Or it could send you the information, um, next green face is coming in 20 seconds and you could try to, um, sail towards the traffic light so you don't speed up, you don't break because you know the, um, green face will coming. Um, so there are a couple of use cases that you can think of that you can do with this technology. There are also a couple of use cases around that are trying to mimic existing, um, features like there's a car breaking right in front of you. Um, doesn't make much sense because you already have sensors. I think in most of the cars nowadays, um, even on the lower end, you already have those kind of sensors that you can use for that. Um, how will the devices look like? Um, you will have integrated devices into cars for sure. Um, you will have aftermarket devices that you can put up on your dashboard. Um, and you will have roadside equipment, um, stuff that you see on traffic lights or somewhere on the side of the road. Um, I bought a couple of pictures, unfortunately I can show you them, uh, right now. Um, so there's an idea of how this looks like. Um, there's a fourth class of devices that I didn't show, uh, today. I didn't bring a list. And this might be actually laptops, like your guys' laptops, I don't know, any car hackers here. Um, they tried to mess around with the system. So we need to be prepared for this. Um, why is this relevant? So I think by now it's like 15 years of research in this area. So why it is suddenly so urgent or how is everybody picking up this right now? This is because we started deploying this technology. So, um, in 2014 there were the so-called connected vehicle pilots that got awarded. A couple of cities got money for deploying, um, video-x technology from the, uh, DOT. And they will actually start putting devices in cars and putting devices on the roadside next year. So this will be out there. Be prepared. Get your laptops ready. Um, they are in Wyoming. In Wyoming we have a big corridor, um, on a highway. It will be mostly video applications for trucks, truck management. I think the most interesting one, uh, will be in New York City, uh, where we, uh, where we have 10,000 cabs equipped with V2V equipment. There are a couple of V2I use cases as well, but I think that will be one of the biggest V2V deployments that we see in the near-term future. And then there is in, uh, Temper, Florida, another, uh, one which is, um, a little bit of both worlds, V2V and V2X. Um, I got your list of all the applications that, um, they proposed to implement. It's quite a huge list, like 25 applications maybe. So go check out the slides or ask me afterwards if you want to get them directly. Um, then you can see this list. Um, there's public information on how those applications work. So if you want to look into, um, data formats, um, that are used to send over the air, um, how the receiving end is supposed to react to this, that's all out there. And then there's another project, Smart Cities. Um, it's a quite large project. I think it's $50 million, um, and it will happen, I think, in, um, Columbus, if I'm right. Um, and this is a large, a larger approach towards Smart Cities. So you not only see V2X connected vehicles, but you will also see smart homes, all kinds of use cases that are smart connected. Um, but V2X will be one of them as well. So if we speak about V2X and technology, um, I bought a couple of information about how this actually works, so that it's, it's using the so-called dedicated short range communications. It's a low latency Wi-Fi like medium. Uh, it's sending on 5.9 gigahertz. Um, which is quite a nice. It's an I2P-E, um, 802.11P standard. Um, so, um, it should be quite easy to get on this channel with your laptop. You don't need any, any special hardware for this. Any Wi-Fi chip should be able, uh, to be on this band. Um, it broadcasts messages. So you can receive them in an area of up to 300, um, meters, an range of up to 300 meters. If you have like nothing out there, you're in a plain field. It might go up to 800 meters, um, but it's really, really the best case environment it could even be. And if you go to cities like New York, downtown, Manhattan, um, I think it will be even less than 300, um, because of the, um, buildings that you have in there. Um, there are P2P functions as well. So you, um, not only send broadcast those messages, but there are some applications that forward those messages as well. For example, um, a better version of ACC or the adaptive cruise control, where you can already look ahead a couple of cars and they will forward the messages and verify with their sensors if this car is actually in your lane. So you actually know, okay, if this car is breaking, I can already de-accelerate, uh, the car until I verify with my sensors that the car in front of me is actually breaking and then I break as well. It makes the whole area of CACC much smoother, um, because it also can use the indicator. So the indicator gets sent over the, uh, area as well. So as soon as you see somebody hitting the indicator, the sensors will take some time until they recognize that the car is actually moving in your lane. But with this, you can already prepare the car and slow down. Or if it's leaving, so if you, if you drive with ACC right now, that's, I think the feature that, that bugs me most. If it's leaving your lane and it can actually speed up, it waits and waits and waits and waits and waits right now, and then it speeds up. With V2X, we would be able to say, okay, this is already indicating so I can prepare the car to accelerate and as soon as I see a little bit movement, uh, with my sensors, I can go ahead and start. Um, little bit more about technology. So what we are doing over here. Um, as I said, it's an IEEE 802 family. Um, for lower level of definition, we have a 10 megahertz channel. Or a couple of them actually. Um, one control channel, a couple of service channels. Um, there's an additional network layer, um, defined for this and, um, the payload definitions are most of them SAEs and Zodibans. I think that they got deployed our SAEs and it's already. Um, the, um, yeah, unfortunately I have a nice picture of the whole stack, uh, in here so that you can see, uh, which different technologies, um, you need to implement in order to send those messages. So it starts with IEEE 802 11P, then you have, uh, the IEEE family of 609. Um, it starts with four, three, dot two is security actually. And then on top of that, you have, um, the application layer where we use SAE standards like J2945, uh, dot one, for example, for the so-called basic safety messages. That's the first, um, message that we will, or that will be deployed over there, um, for safety features like warning about breaking events or stuff like that. Um, the University of Prague is actually already created a kernel patch to support, um, IEEE 802 11P and the OCB mode because you don't join a network over there. You just start sending. So we need to use a new color mode, um, for sending those messages. Um, you can download it. It's free on, on gut GitHub. Um, there's still a small issue, I think, um, with the, um, with the 889K driver, the Wi-Fi driver that you need to have because, um, there's a database which implements the regulations that you have in the different countries like which channels you're supposed to use, uh, and stuff like this. And this, I think, um, permitted us to actually go to this, um, channel that we need to use. There are some patches out there already. Um, I don't know if they work. I haven't had the time to test them out, but feel free, take this information if you want to build something like that. Um, I think they are happy to help out. Um, they are very active on, on the mailing list, so shouldn't be an issue to, uh, get in touch with them. Um, basic safety message. So what's, what's in there? What do we send over there? We send speed, we send the position within the heading and the acceleration. Those three data points is what we send with 10 hertz. So 10 times a second, these measures get sent out from each and every vehicle. Um, that is equipped with that. And the information is signed, so there's a digital signature in there. Um, and I think every, um, every fifth message we send a certificate with that as well. So you can verify if this information that you just received is summing from a trusted source. That's the idea. Um, oh, and there's date and time in there as well. For, uh, traffic lights, um, applications, there are a bunch of different messages defined already. Uh, one of them is so-called sped message. Um, there is encoded the movement state, um, which is like the traffic light face that is in there right now. What's the ending time? And based on this, you can think of a couple of, um, applications that can build on top. Like red light violation warning, you get the information, it's still 20 seconds red, but the car is approaching way too fast, this traffic light, so you send a message to the driver, hey, better ingrate your bakes. Um, all those messages, as I said, get signed. Um, we have one, uh, type of certificates for each field. So we have one, um, for V2V messages. Um, they are called pseudom certs, pseudom, um, certificates. And we have application certs for, um, the V2I area. The pseudom certs are actually, um, um, quite new concept, uh, in, in this area because, um, this technology is going to be mandated eventually. And that means that each and every new vehicle sold here in the US needs to be equipped with V2V and need to send those messages. And in order to avoid that somebody is sitting on the sidewalk and just sniffing messages and being able to track cars, um, by just doing so, we need to avoid that there are any, uh, permanent IDs in the messages. And we also need to avoid that they can just use the certificate that we use to sign the messages in order to track the cars. So you have actually a whole bunch of, um, so called pseudom certs that you use, um, and that you exchange frequently. They are good for a week. So the ability period is one week. And after this week you throw them away and get a new bunch of certificates. Um, the architecture for this is quite complicated. So the architecture for the CA or the public infrastructure that we built for this, um, because we only, you don't only want to protect against outside attacks like somebody sitting actually on the sidewalk, but also against inside attacks. So somebody running a part of the PKI should also not be able to tell which pseudom certs belong to which vehicle, because otherwise he already has this information he just needs to start listening out in the field and see where cars are going. Um, this actually will be quite hard to explain if you don't see it over there. So I brought a picture of the architecture. Um, but I, I, I give my best. So you start with an enrollment cert. That's the very first certificate that you get. Um, this is not, uh, this is per device that is out there in the field. And this is only used for communication with the security convention management system. So you never use this certificate for anything else than just authentication against the, um, STMS security convention management system. With this enrollment cert you can go to the registration authority and download or request pseudom certs or application certs based on the permissions that you have within this enrollment cert. If you focus on the pseudom certs for now, um, because they are the ones that need to have this special protection against insider attacks. Um, the registration authority will, um, take your request. It's a single request. Um, we use a technology called butterfly key expansion, um, to expand this one request to initially 3000, um, pseudonym cert requests. And the device not only sends this request, but it also sends a response encryption key. The registration authority takes those individual requests, expands the request and expands this, uh, response encryption key as well. And forwards them to the pseudonym, uh, CA, certification authority. This authority creates the pseudonym certs, encrypts them with the, uh, response encryption key one by one. The requests are shuffled, so they are not sent batch wise, like I get one request, send 3000 up, get another one, next 3000. But I shuffle them on the RA level so that the PCA is not able to tell just by looking at the sequence, okay, there's a high probability that this, uh, set of pseudom certs actually belong to one device. They encrypt them, um, send them back to the RA, so the RA cannot look into, um, the certificate, um, zip them and then get them ready for download of, uh, for the devices. Um, maybe a little bit later about how we do, um, revocation in this case. So why is important that, uh, when we have the system, we would still be able if it's a single organization running the whole, uh, public infrastructure for this, this organization would still be able to tell, right? Because it just needs to look on the different components within the system, get the data from there and then it can make pretty good guesses, um, which certificates belong together. So what we need to have in this public infrastructure is a separation of duties, a separation, um, of the different components. And there are some components that shouldn't be in one single hand because if you combine those information, you can get, again, the information about, um, which certificates actually belong to one, uh, single car. So registration authority that are just introduced and the pseudom search authority, uh, authority, they shouldn't be able, they shouldn't be run by one single, um, organization because if you get the requests and they're, even if they're shuffled, you still can trace back, um, which certs belong to one, um, batch. Um, we have one, um, speciality in this PKI that you don't see in any other PKI's, I guess, um, that's the so-called linkage authority. Linkage authorities are used to generate, um, linkage values and those linkage values are put into the device and in the certificate as well so that once we start doing misbehavior investigation, which is the part that we need to do in order to identify your laptop on the site work sending messages, for example, by using fake certs or actually, uh, using real certs that you extracted from a device that you found somewhere. Um, we need to be able to tell again which certs belong together, right? Because if you have a whole bunch of pseudom certs and we are speaking about 3,000 worth of 3 years, uh, initially that you put in a, uh, vehicle, uh, if one of them get, get blacklisted or revoked, you just take the next one, right? So there need to be some mechanism in there that we can use in order to identify still which belongs to, um, together. But in a way that I don't get the actually pseudom certs out there. So I shouldn't have any single component again in the system which knows the actually certs and which of those certs belong to a single set or a single device. So what we do here is we have, um, so-called linkage seats, um, which is a hash value and we have two separate linkage authorities, both with those seats. They again need to be run by different organizations and they generate so-called pre-linkage values. So they take a hash value, create another hash of it, 20 per week, um, send them back to the RA, uh, actually, or, yeah, via the RA to the PCA, they're encrypted, um, with, um, with a key towards the PCA. So the RA cannot read them and the PCA will x-order them together to get the linkage value. It's a little bit complicated if you don't see the pictures right now. So I apologize for that. Um, if you have any questions towards this, feel free to reach out, um, to me or ask them right after the talk. I give a little bit, hope I have a little bit more time for this. Um, but it works in a way that you only can do, it's a forward hash so you can only take the latest one and if you get the linkage seat again, you can put this on the CLL and everybody can do the same calculations to find out if a, um, linkage value that is in any pseudom assert belong to a group of linkage, uh, pseudom asserts that are revoked. That's the whole idea. So we put out the linkage seats once we identified that there is some kind of misbehavior out there. Um, so those linkage authorities needs to be separated in different organizations and they also need to, uh, need to be separate from the, um, pseudom CA because that's, um, the place where they were, um, X or and if the PCA knows which initial hash values were used, they can just do the calculations and get the information, um, which pseudom asserts belong together. Um, so I'm talking about misbehavior detection. I think if you, um, if you have a system like this, we can almost expect it. You guys will work on this and see what, what you can do. Um, we know that people are able to extract those, um, extract any private keys from devices. Um, there are very sophisticated tags out there. So we need to anticipate in the system already that eventually private keys get extracted, um, certificates will be flying around and we need to have countermeasures for this. So the countermeasure for this is we do some kind of misbehavior detection. Um, that is we try to validate information already on the car. That's the local part to it, local misbehavior detection and see if they make sense. Like for example, if you get two messages from supposedly two different cars signed by different pseudom asserts and the location that is sent in there is so close to the other location that either they crashed right now in front of you or something is wrong. There could be tons of different reasons for this, right? There could be bad GPS reception. There could be an error in the GPS module. Um, there could be actually somebody sitting on the sidewalk and sending messages and getting in the same location as a car in the street. Um, we don't care about what the reason is because the standard says that if you know that you have bad GPS reception and most modern GPS devices are able to tell, um, how good they are because you stop sending. So if you implemented everything correctly on the device and in your car and nobody's spoofing, um, you're not supposed to send. If you still send, we can assume that there is some kind of misbehavior and we don't care if it's wrong software on your car or if it's somebody sitting on a sidewalk. There's something wrong and we shouldn't issue warnings based on your wrong locations to other cars. So if we detect this, um, the vehicle that detected this misbehavior will send up a report and the reports get, um, put into this investigation where we try to, um, see if they belong together. So you get like two different messages from, um, signed with two different pseudom search, but stemming from the same device. And what we do then is we take those pseudom search and send them to the linkage authorities in order to get, um, a trace back to throughout the system to see if they belong to the same linkage seat in the very beginning. The answer that the misbehavior authority, which is doing this process will get is only, um, there's one, um, pseudom search in here and I tell you which one. And there were five others in your request that belong to this, but I don't tell you which ones. So we again try to protect the privacy, um, of the actual device, even when we do misbehavior investigation up to the highest level possible. Um, and once we identified that this is actually misbehavior, so we got enough reports. Again, enough is a question about what the report was about. So for example, if we have this overlapping and we have two different cars reporting the same, um, set of pseudom search doing this, we can assume that there is something going wrong. Um, we then put those information on a certificate of revocation list, put them out to the system and then they need to be distributed to the cars. And that's, that's a weak point in the system right now because we need to get them those information as soon as possible out there. Um, one problem that we have right now is that we can't assume that all conars, cars are connected every time. So we need to find a way to get those, um, CRLs to them even if they are not online. And one of the project that we're, um, starting to implement is, um, a P2P network between cars so that we actually can ask another card that is, um, within your, um, range, do you have a newer CRL and if so please start sending me this CRL. Um, this will go until we have a reasonable amount of numbers of cars that are out there that, that are connected. Um, and then we might start speaking about other, um, technologies than CRLs in order to get those bad certificates out of the system. But up to then, um, I think that's the only solution that we have right now. Um, one problem that I wanted to talk a little bit and I hope I have, um, you know, 10 minutes left. Um, so we have traditional PKI and in any traditional PKI you have a root CA, anchor of trust. And the problem again is, um, there's a validity period so we don't want to have a root CA that is flying or which is valid for, I don't know, 50, 70, 80 years just to match the lifetime of a vehicle of about 20 years, some say 40 years. Um, so we need to get shorter lifetimes in there and we can only do this if we have a roll over, right? That's traditional PKI, um, mechanisms. But if we roll over to a new route, how do we get this route out to the vehicles so that they can start using or start using this new route to verify incoming messages? Um, what you do traditionally is you do a software update, firmware update, browser updates. That's how it works in the internet world. Um, but there's no way of doing this if you're not online or if you're asking somebody on the street like another car, hey, I saw your message links up to a different trust chain and I don't know this route. So what do I do? Um, and the idea that we came up with is the so-called elector concept. So we have some kind of superpower in there. They are not part of the PKI. There are some kind of signatures, um, CAs. So all they do is they sign a message, uh, which says this certificate over here is a new route and we, um, we ensure that this is part of the system. Um, there's always a quorum. So we have like, for example, we start with three electors and as long as at least two of them sign the message that this new route is part of the system from now, uh, you can trust them. Those three elector certificates get pre-installed on all the devices and the good thing is if it's three, we can also remove them and get new ones in there. Like the same operation like as if we add a new route, we have a message to add a route, we have a message to remove a route if it's going bad, like compromise or something like that in the worst case. And the same, uh, with the electors, as long as you have three electors, you can always add a fourth elector by having at least two signing, um, the message and then remove the one that you want to exchange with the new three new ones. So with that, we have some kind of democracy up there, uh, where we always, always you can vote, always can vote new electors in there and add and remove, um, route CAs from all the devices. And then I think about this, um, is that you don't need to have an online connectivity, um, in your car in order to get those messages because again, you can ask just another vehicle as long as you get the message, uh, which is signed by the electors, you can always verify if this is a trusted, um, route or, or an, uh, or not. So you don't rely on any, uh, kind of online connectivity, you only rely on other cars telling you that this is actually part of the system. And you can do this in the moment where a car under this new route is sending you a message. So you get this message, you see the chain up to a different route and you just ask, hey, give me your route certificate and this ad message. And as long as it can verify, I can trust your message. Um, we published a paper about this. So, uh, if anybody wants to discuss about this, I'm more than happy. Um, and we are actually implementing this. So it's not, um, something that we just talk about in, in science, um, or research. Um, we actually demonstrated this, um, whole PKI one week ago, um, where we issued certificates that are, that in, in, in an amount, or we issued certain asserts in an amount that is equivalent to our first year's production within the U.S., um, which is roughly 70 million cars. Uh, so we were able to show that we are capable with this system, uh, to generate enough certificates to get 3,000, um, in there per device. Um, and we showed that we are capable of running these new concepts with the linkage values, with butterfly keys, and with the electros as well. And this system will be used within the upcoming connected vehicle pilots that I, um, started to talk about. Um, to issue certificates to devices. So whenever you are sitting on a site work in the future, getting VDX messages and looking into them, those certificates will be coming from our system. Um, and with that, I close my talk. If there are any questions about this, I don't know how much time we still have. We started a little bit late. We can do it right now or just grab me afterwards while we were hanging around in the car. I can village, I guess most of the time. Um, so first of all, you need to have a, um, uh, certificate for this, um, special certificate for this. Um, and just replaying the attack, um, there's always a time stamp in there. And there's a certain threshold, um, but this threshold is, is pretty small. So, um, it's either you're within the same area and we're playing within microseconds, the same message. But if it's a valid message, we don't care, right? If this message is turning something green, it's in real emergency cars. So the replay attack just will turn it green again. So nothing happens. If you try to take this message and send it afterwards, um, once the emergency car is already through, um, the time stamp will tell the, um, device that, um, it's a replay attack. So it, it's based on synchronized clocks. We need to have synchronized clocks in all devices, which is actually an issue because we need to agree upon one time system. They're different out there and all the discussions. Yeah. Yeah. Um, right now there is not a really good solution to this. Um, the only solution that we have is, it's contained in a certain area, right? You can sit at one intersection and flood the channel over there and it will maybe be around 300 meters, uh, where nobody can talk to each other anymore. So this intersection won't work. Uh, you won't see any messages or you will only see those messages that are coming through and you could use them to issue warnings. But if you're actually able to flood the whole channel in this area, um, the only thing that will happen is, is that devices that see those messages coming in, um, will report this because you're supposed to send 10 times a second if you do it, uh, more often than that. That's clearly a misbehavior that is, uh, that should be or that will be reported. Um, if you're capable of doing this with a whole bunch of different devices because you're prepared to attack very well, um, this is something that we can't detect if you have the right certificates and stuff like this. So if, if you look like a legitimate device and your messages make sense, like they're all on the street, they're all not overlapping, all those kind of techniques that we have, um, implemented for misbehavior detection already, there's not much that we can do right now. There are some works or some research on the physical level, um, physical layer to see if there's anything that we can do there, but that's nothing that we can implement to our production system right now. Any more questions? Yep. Pami? Um, so in the vehicles clocks are synchronized by our GPS. Um, there's a time signal on, on, on a GPS channel. Um, yeah. So you can use a GPS gemmer or fake GPS, try to introduce this in the system. Yeah. Okay. Then do you know more questions? Thanks a lot.