 This talk is a little pun-vatican, obviously. I don't refer to the state with the lowest birth rate in the world, but to vetted authenticated canvas. The motivation, I think, we heard from the previous talk is quite clear, but usually, as an easy start, it's nice to see a little video of what actually happens if a faulty ECU, a vulnerability ECU, has been compromised and issues packets that it shouldn't do. In this demonstration car, this video is actually two years old, so it was actually before this G-PAC. We sent some packets on the bus that turn on the windscreen wipers or the headlights and stuff like that, and obviously there's no driver in the car currently using any switch or knobs. So it's basically by overwriting what's on the bus, and here you can see even the instrument cluster, of course, shows wrong information. So the canvas, as we heard before, wasn't designed, of course, to be able to cope with these attacks, because security wasn't in the mind when it was designed in 1983 by Bosch, because you had physical, you would need physical access to the car, and usually that is locked away. So I think no wonder that we now have these security problems, because, of course, it wasn't designed to do this. The canvas itself comes in a variety of topologies from very, very simple ones, like in this Jeep Cherokee that you probably have all seen one year ago when they drove it into a ditch, which has only one bus, which is, if you will, the most insecure one, obviously, because you can't really have separate buses that have a separate purpose, and if one fails or if one is compromised, you don't actually compromise the other one. So in this case, you can clearly see that from the tire pressure monitoring system, even worse, ABS, so your brakes up to the infotainment system all is connected to one bus. And so if the infotainment system, which in this case has a SIM card embedded, has a vulnerability and gets compromised, so it can just send packets that would usually only come from the ABS and, for example, a brake. But it's not limited to, let's say, modern cars which have an embedded SIM card, but also arbitrarily old cars which have a diagnostic pod can be vulnerable to this. So if you got a little dongle from your insurance that you're supposed to plug into your car that measures how you drive, don't ask me why you would do that, but many people are doing that, and if this has a vulnerability like we demonstrated here, then, of course, you can turn on the windscreen wipers or whatever, make an emergency brake, deploy the airbags while you're driving on the motorway, something you would not like to experience usually. Even if the buses are separated, this is an example, a real-world example from a BMW 3-series, the latest F30 series, it has a variety of buses, as you can see. One is called K-CAN2, and this is just internal naming from the people in Munich. But the physically interesting parts, the power steering, for example, is connected over yet another bus, the Flex-ray bus. So you would think at first sight, maybe that's more secure because it's separate, and it can only be controlled from the front electronics module, FEM in short, to issue commands, if you, for example, press the park button so it can maneuver into a parking lot automatically. And the ECU that's actually measuring the distance to all the other cars and then sending out the commands to the steering wheel, to the throttle and to the brakes is the PMA, the Park Maneuvering Assistant. However, this one is connected over CAN bus to the front electronics module. So the signals are supposed to come from the PMA only, but suppose there's a vulnerability in the infotainment system that BMW calls the COM box, the communication box, and so over the internet connection, somebody else can, in theory, probably in practice, issue commands, and so you would suddenly turn right on the motorway, which is probably a very dangerous thing. So this talk is a very practical approach to solve this problem because in theory, we could agree it's probably the best way to throw away CAN bus and to use something that's more secure to begin with. But the problem is, and why this is a very practical view, that the auto industry doesn't work like this. We cannot just start over. And to give you an example of why that is, I want to have a look at the manufacturing depth. That's how much do the OEMs actually produce themselves and how much is outsourced to others? Because, I mean, nowadays, nobody builds their own cars. They basically share all the components that are made by suppliers. And the self-proclaimed lowest manufacturing depth is by Porsche. They say that they only produce 20% of the cars they sell and 80% comes from contracted suppliers. And if you would now think that the 20% that remains is something that is unique to Porsche, that's also wrong because the 20% of the whole cost of the car are sale and quality control and also the assembly of the car. But the rest is basically taken from the VW parts, even including the engine. So my point is really difficult to say, okay, we now change all the protocols that exist there and we come up with a new one that is more secure. So our approach here was to go back to the drawing board and say, how can we modify Canvas in such a way that it is more secure yet backward compatible? So all the ECUs that are still in that car that we want to make more secure and that have contracts with suppliers do not need to be updated. So a software-only solution would be the best way. And then we face a couple of challenges. The most obvious one is probably that real-time is important. Canvas was designed by electrical engineers that wanted to replace the heavy copper wires with something digital. And so real-time is a big issue because Canvas basically only replaces the copper wire going from A to B. We cannot introduce a high latency here. But also the CPU and memory resources we have available are very constrained because we're still talking about embedded systems here. So we probably cannot use symmetric cryptography here. But I'll come to that later. Most importantly, though, if we want to stick to the Canvas protocol, we're limited with 64 bits of payload, which is not a whole lot. And the number four here, individual keys, is an interesting thing because, as you might have read, I think it was one and a half years ago, BMW made the mistake of incorporating the same cryptographic key into every car because they said, well, who would go through the effort of extracting that key by desoldering the chips while somebody did? It cost him around, I think, 40,000 euros, which is well below the price of that BMW. And he now got the key and can control all of the cars. So you don't want that to happen. So of course, we also need individual keys then. And as you see, so in the previous talk, that would be one option to have individual keys in each car and individual keys even shared between the ECUs of car. So to address the first challenge in real time, the question is, how much can we delay an authentication of a message? It would obviously introduce some sort of delay, but what is acceptable so that it is not significantly increased in latency? So by significantly increased, there are basically two things we can look at here. The first, how many messages can we send, for example, in one millisecond? Suppose we delay the authentication by one millisecond. The equivalent at typically 500 kilobits per second canvas would be that roughly five messages could be sent at the same time. But we're talking about cars. We're talking about cyber-physical devices here. And if we're driving at motorway speed, delaying an important message by one millisecond means that we have basically traveled 3.3 centimeters. So we should keep that in mind when we design this. The adversary we're talking about here was already alluded to in the earlier talk. So to refresh your memory, one ECU that is supposed to send a critical command, let's say, this is the Park Maneuvering Assistant here, simply called abstract ECU three. And ECU four could be something like the power steering that accepts that command. But the attacker, on the other hand, has compromised any other ECU and wants to impersonate ECU three to send some critical command. So that it seems it's coming from ECU three, but in fact it isn't. So that means the attacker can send arbitrary payloads, can replay them, can also passively listen to the canvas. So the goal and the backward compatibility is that we neither want to change the original sender, so the ID of the canvas, nor its payload, because then all the ECUs that we don't want to upgrade, the uncritical ones would need to be upgraded as well. And by uncritical ECUs, I mean something like, for example, your central locking. It listens to the speed of the car because it locks your doors when you drive above 15, but it's not critical if it doesn't work anymore. So we don't want to update those to be backward compatible. And one naive solution could be to translate from the critical ECUs that talks some new protocol and the old ones. But the problem is that given again the same problem that we have the suppliers and the contracts that already exist, we can't simply update all the wiring harnesses as well. It's the same as coming up with a new protocol because then you would have to rewire everything to different groups because that's the benefit of Canvas that everything is basically on the same physical wires. So to show you how we solve this is typically the different ECUs that are in that car listen to different IDs because they have a very specific purpose. And they do that by applying filters and masks. It's a very Canvas-specific thing. The mask is simply an and, a logical and, that is applied to all the IDs that are received on the bus. And if it matches, it goes through the next step. And then the filter is applied. And the filter is simply an and again. But all the ones that are set are checked. So for example, you can do something like the first example, 3FFS the mask. And then you want to filter everything that has a 4 in the second digit. So if all these messages that are currently on the bus are filtered like this, the first ECU only sees the 1, 4, 1, and 2, 4, 1, whereas the other ones see 7A and 5A, for example. And the ones that both don't have a filter for, they just ignore. So to be backward compatible, the idea would be to just leave that as is as a first step and then introduce new IDs in the middle. But the question is, when do we send these packets and with a higher or with a lower priority? So a higher priority means a lower number in that case. It could change the priority that has been designed by the manufacturer. That could be a problem. And the question also is, do we want to send an additional authenticated packet after or before? The second question is more easy to answer because the timing of the original is not affected if we send it after the original one. For the priority, both is actually possible. If there is no priority in between the ECU we want to protect and another one, then we basically don't change the list of absolute priorities. So this is both possible. To get a little bit more concrete, so suppose 7A is just a randomly chosen ID with a specific payload of an ECU that we want to authenticate. So we leave that as is, but we introduce a second sender ID, which is just a virtual ID. It's not a second physical ECU. It's just one ECU sending two packets. The original one is unmodified and the second one contains an HMAC of the payload together with a sender ID because we want to prohibit an attacker from taking a coincidentally identical payload from another ECU and its HMAC. And then, of course, a nonce to provide protection against a replay attack. Problem here with a nonce I'll come to in a second is that we can't incorporate that in the 64 bits. The 64 bits themselves are quite small already for an HMAC. But when we use something like a catch-check construction with the rate and capacity set to 128, which will produce these 64 bits, then as you see in the evaluation, it still suffices to protect for a long enough period with these nonces. So in this case, 64 bits as payload incorporated and an 11-bit sender ID that's both fixed because of the Canvas characteristics would give space to up to 53 bits of a nonce. As I said before, the nonce, however, cannot be sent as plain text in the original message because we can't modify that. So the idea here, because ECUs might be offline or ECUs might just drop a packet and didn't listen to it, we don't have a synchronized state. So the simple solution to that would be to introduce a global nonce generator, something like a global clock in this sense, which will broadcast, let's say, 7.6.1 as the currently valid global nonce, and then every ECU has its local nonce that it increases when sending a packet. So in this case, the ABS module will send 56, let's say that's the rotation, the speed of the car. It has received the global nonce before. So the ESP, which is the receiver of this packet, the electronic stability program, can then use this to calculate the HMAC based on the payload and the sender ID and this known nonce that it also has to increase after that, which can be done in parallel to the sender so you don't actually have to do it twice in terms of timing because while the sender is calculating the HMAC, of course, the receiver has already received the packet and can do the same. So when the sender then sends the H, calculated HMAC as a packet, the only thing that has to be done for the receiver is to compare it to see if that matches or not. The results on a very typical V85, a V850 microcontroller is that it usually introduces 1.3 milliseconds of delay. So that was the, let's say, 4.3 centimeters at 120 kilometers per hour, that you would lose in terms of your reaction time. The more interesting thing here is the 64-bit HMAC suffice. On this very popular processor, just like the lower end you would find in a car, 58 days are needed on average to brute-force that. So that's well below a typical to 124-bit output for a char-3, but on the other hand, the nonce is updated, let's say, every 50 milliseconds, and so that's invalidated. So what we can achieve in the end with this setup is that we have an already existing architecture, for example, a rotation sensor that measures the speed, and other ECUs that are listening to that, most importantly, the stability control, suppose we want to secure that as well, but also ECUs that we deem to be non-important or non-critical in that sense. The instrument cluster might show a wrong speed, we don't care if it's a tech, and the navigation system also uses the speeds that you can navigate if you have a lost GPS connection, and also, as I said, the central locking, but we don't care about the three on the right. So if the left ones are protected, that means they send the packets as usual, everybody is receiving them, nothing has changed, and the additional packet, which contains the HMAC, is pretended to be coming from another ECU, ABS prime, in this sense. Another solution that does, however, require hardware tricks is that we can also change the way the packet is transmitted on the bus. If you look at the timing, then usually the ID is the first transmitted, and while it is being transmitted, other ECUs could also listen to that, and as we heard in the talk earlier, it's of course possible for an ECU that knows I am ID 100. If I hear ID 100 on the bus, and it didn't come from me, it must be wrong, but the question is what to do then? Can we raise an error? That would mean we have to send another packet, but there's also another option, and that is if we look at the CSC, we can also use the same trick that the zero is dominant, and we can destroy the CSC, and so all the other ECUs would simply not listen to that packet, which in the concrete case of this park maneuvering existence means it could potentially detect the spoof message, and then simply destroy the CSC, and nobody would notice. The key management is the same problem as alluded to in the talk before, would be exponential, of course, if we do it in a classical way, so either we can use a protocol that is similar to the one that has already been presented, or a very practical approach would be to just insert randomly generated keys during the production, and then have a solution for the case of repair. So the first is easy. Usually during the production, they can be inserted into the memory of the ECU with a random number generator, and all the pairs that are needed in the groups that Canvas uses already hardwired into the flash memory, and then when a repair is needed, so if an ECU is malfunctioning, it has to be replaced by a mechanic. We can use asymmetric cryptography, in this case just signed keys, which is already commonplace over the OBD diagnosis pod, which is usually only used to software update, but here we can also update the keys. The results we have found in a PASART, this is the typical communication you would see on the powertrain. These are all the CAN IDs, and a little bit of explanation what they mean, and these three green ones are the ones that we deemed are very important to protect, the brakes of course, and also the electronic throttle control, ETC, and the speed, and when only protecting those out of the 560 total messages that make up 34 kilobits, we end up with an increased overhead of course. The usual overhead is 34, as I said, plus the overhead that comes from the Canvas communication itself. When adding the Vatican protocol, we have roughly 12 kilobits more out of the 500 that would theoretically be possible, but when we flooded the bus, we only achieved about 448. And to conclude that with the video as well, even though you can't usually see security, this is just a bench setup of the extracted instrument cluster that uses the authenticated messages for speed control. So if the electronic throttle control reads a value, this is then interpreted by the instrument cluster, which has not been modified, and the other ECUs, for example, can display the speed 76, 74, and is authenticated. As a last remark, you can download the library for that on automotivesecurity.net, and this is available as an Arduino sketch to start with. So you can add secure senders and then have a received message call back, and it would tell you if it's authenticated or not. And at this point, I'd like to thank you very much for attending and listening and hope you have any questions.