 So, I'll be presenting our work on physical-layer group key agreement for Automotive CAN. And the hope is that we can take that 95 Mercedes from the previous talk of running Windows 95, put some of this technology and salvage some of that lost value, so it's not as insecure anymore. So, you know, I mean, I know that the Automotive bus is sort of new to this community, so just to give you an overview. The control area network inside the car is basically the one of the primary communication networks inside the car. And you have several electronic control units, ECUs connected to it in a ring topology. So you essentially have a broadcast medium connected via a two-wire bus, and then you do differential signaling over this to transmit a zero or a one. So the structure, as you can see here, is very simple. You have different ECUs connected with terminating resistors with two wires. So what exactly happens here? So if I was to imagine what my car, you know, a 2001 Accord looks like inside, if I open up the bus, it would probably look like this. Now, this is a bit of a drawing of my imagination that it has a very simple structure. And if I open my lab mates car, which is a 2014 Accord, so this structure is well documented and, you know, this is what it looks like. So you can see that the complexity of this network has grown. And that's basically, you know, while that makes your car easier to use, that's also one of the big problems. So you have more ECUs attached to the network, and several of these ECUs now are connected to public network. So, you know, there's cellular, there's Bluetooth, there's USB. And because these ECUs are very sensitive to cost, the manufacturers are very sensitive to cost, there's not much over provisioning. And the design of this network was with respect to old cars, with respect to my car. So it doesn't really, cannot accommodate these new interfaces securely. And of course, the time, operations inside a car are very timing critical. You don't want to apply a break and have your car stop 10 seconds later. And the, the security here, I mean, we're just starting to see attacks and, you know, early stages of adoption. So of course, I mean, not to go into depth in this, but a lot of attacks have been demonstrated starting early in 2010. And but this was mostly in the academic community. And I think what really changed the landscape is, you know, this cheap attack last year with sort of had everyone scrambling, right? And again, so from a follow up, there are attacks presented this year by the same group. And also, there's, you know, using the same techniques to attack big trucks, right? So if I was to break down the anatomy of this attack, the key components that were used was first the reverse engineered, the can messages, because there was no encryption. Everything is an open. And then they compromised a single ECU, which is your head unit. And they were able to inject arbitrary messages. So you can see how dangerous this can be. So, you know, just as a naive security guy, if you want to put some security in this, I mean, I can do two things. I can encrypt all traffic, minimize information leakage, and introduce basic notions of authentication so that there is no malicious injection possible. But that's, so people have tried to do that, but this is what the trend has been. So people add new interfaces. So they add the wireless, they add cellular interface, they take security from IT security and they add it as a fence outside, so they add the firewalls. So this is obviously quick to do because you take existing methods and you add it and you have well-known solutions for this. But what happens when this fence is breached, that's in the Jeep attack? So, you know, you have the entire car compromised. So our goal is what additional security can you add inside this fence and how efficiently can you do it, right? And that's why, so one of the things, so the things that we are proposing is plug-in secure modules, which can be added, so it's as simple as plugging them in and they start working securely. And for this, we're using device properties to make this solution more efficient. So just from a high-level view, what exactly would we need, you know, for a security solution for the automotive? So obviously, you need a symmetric key. You need the ability to fast, re-key quickly and efficiently, and you need group keys. So one of the key design criteria for Canvas was broadcast communication, group communication, so you essentially need the notion of group keys, right? And we believe that plug-in secure actually provides these properties very efficiently. So in a nutshell, essentially what you have is very simple ability to generate pair-wise keys between two parties and very simple mechanism to update this. We have negligible software and hardware overhead and negligible software storage requirements, and we actually have methods to extend this to group keys and to include authentication. So how does it work? So the notion is that the idea itself is pretty simple. So if two nodes or two ECUs write simultaneously on the CAN bus, the physical structure makes the bus behave as a logical and operator, okay? So if node one and node two writing, this is basically a truth table of what somebody will see on the bus, okay? So this was used by one of our colleagues, Andreas Müller, to exchange keys between two parties. So the way it works is node one chooses a random value, node two chooses a random value, they transmit that simultaneously, and then they transmit complement of that random value, okay? And if you have an eavesdropper in the middle, what happens is so whenever there's a one-one, he knows it was a one, and whenever there's a zero-zero, so in the complement there will be a one-one, so he knows it was a zero-zero. So these bits leak. So you remove these, you discard these leak bits from your original random value, and what you're left with is a shared secret, okay? And so this scheme actually from properties point of view, it can actually be considered to a basic unauthenticated Diffie-Hellman scheme. In fact, it provides a slightly stronger guarantee because it provides you guarantee against unbounded adversary, so it's information theoretically secure. And the reasoning, I mean, the details are in the paper, but the reasoning is simple, so successive leak bits don't reveal anything about each other if your random numbers are uniformly chosen. And bits which are not leaked to the adversary, so the zero-one and the one-zero, the adversary just sees zero, so he does not really get any information of what one of the ECUs has. So this is actually, I mean, this basic scheme is actually information theoretically secure. So then the question becomes, how do we extend this to a group of ECU and how do you add authentication to this, right? So the extension to the group protocol is actually very straightforward. So node one, and so we want to generate a 128-bit key. So node one, node two, node three, so node A selects 512 bits, B selects 512 bits, C selects 256 bits, node one and node two do this plug-and-secure two-party scheme. On an average, they're left with 256 residual secret bits. Then node two and node three do the same and they're left with average 128 bits. And because this is a broadcast medium, so node one can actually see whatever node two is transmitting and it knows because of the shared secret beforehand. Node one will essentially have the output of this interaction as well. So you get a group key. And of course, this is an extension of the basic scheme. It provides information theoretic security. But we can see the problem here that as you scale, as you increase the number of nodes, it's not very efficient. Because you need exponential number of bits as your group size grows. So and why exactly this happens? So it's because successive stages leak more and more bits. So if we can provide an efficient method to isolate these stages, then we would do away with this leakage. And we can get an efficient scheme. So and that can be done very simply. So if you just replace wherever we're choosing random values, if you use pseudo random values, so we lose something in terms of security. So we would now just be secure against computationally bounded adversaries. But replacing it by pseudo random functions, we get the desired isolation that we need, right? So it's just, I mean, if we use f here as a pseudo random function. So here's how the scheme would work with that, right? So this is the old scheme. So now each of them would choose random values, which are 128 bits. So instead of doing the plug and secure with the random values, it uses the chosen random value as a key of the pseudo random function. And it uses an index. And it uses the output of this to do plug and secure. So you're doing plug and secure using pseudo random values. And every time you don't get sufficient bits, you can just update this index and do it. The second stage would use the output of the first stage as the key to the pseudo random function and do the same operation. So essentially now, so you don't, so you do away with that problem of needing more and more bits. And you can get a group key protocol, which does not really need any expensive operations. And it's simple to implement, right? And it has very nice properties, like key independence. And it can be shown to be secure against passive adversaries. So this can actually be further extended. So this is a linear protocol. You can actually make a tree out of this. So if you organize all your ECUs in a tree structure, you can actually have the first two ECUs doing the protocol, then the next pair. And then at the next stage where this subtree is doing the protocol, so essentially you choose, so this can be arbitrarily chosen, you choose two nodes. Here we have chosen the first two nodes of the subtree to do protocol. So they use the output of the first interaction and the second interaction to do plug and secure to get the next level of hierarchy. And the same thing is repeated on this side. And you can continue this to get your key. So the advantage of this, of course, the initial key exchange has linear complexity, which is good. So if you have to add node, we get logarithmic complexity, as expected, from traditional key-based, I mean tree-based group key agreements that we have in literature. And if you actually have to re-key, you can actually get constant complexity. Because if you assume that your ECUs maintain certain state, all they need to do is just repeat the last step of plug and secure with updated indices, and you can get a new key. So you can actually re-key with constant complexity in case the key leaks because of a side-channel attack. So this structure basically gives you all the good properties that you need. But again, this was secure against passive adversaries. So what do we do against active adversaries, right? So the goal, again, of course, if an adversary can arbitrarily inject packets or modify messages, so you want to ensure that the communication is happening only between the correct parties and the group key can only be derived by the correct parties. So we assume that the adversary is powerful in the sense it can inject arbitrary messages. It can modify messages. It can replay messages. It can record messages. But what we do assume here is that the adversarial access is restricted through a traditional ECU. And this is important because we are focusing on remote attacks. So an adversary compromises an ECU, and he can do anything. We are not considering physical probing. But I have to say that there are enhancements that we have done to the scheme to protect against physical probing since this paper was submitted. And we are working on publishing those results as well. So yeah, but the basic idea is that there's two approaches how you can provide authentication. So you can use the inherent robustness that the scheme has and that the Canvas provides. Or you can provide authentication using cryptographic guarantees, using a pre-existing trust relation. So what exactly is this robustness that PluginSecure and Canvas provides in a network? So if you think about it, the Canvas, because it's a broadcast medium, it has a natural immunity to node impersonation because if somebody's impersonating somebody else, the genuine node can always raise a flag. So if you built a bit of robustness in nodes to identify this behavior, you can prevent this. If you remember, so in the PluginSecure protocol, there were some nodes which are active, some which were passive. You can only, now, if you were trying to insert messages for active nodes, you can only do that by actively engaging in the PluginSecure protocol. And there, basically, what you're doing is you're constrained to using the AND operation. So it's like if you want to inject a random value R, the other node will select which bits it takes. So you cannot do arbitrary injections. So the power is very limited. If you want to insert messages for observer nodes, we can actually show that this is the probability that you can successfully do this, that you can successfully craft a message which would be accepted is negligible. So this cannot be done. And one of the advantages of the Canvas is you only have transitions possible from 0 to 1. So you cannot flip a 0 to 1. So it's a very restricted environment. And these are all properties that the Canvas provides. So we think that this might be sufficient to prevent active adversaries. We don't have a formal argument for this, but it seems sufficient. But on top of this, so this does not need any modification. If we have to provide cryptographic guarantees, so what we can do is essentially we can overlay an authentication architecture on the existing scheme. And the idea behind that is so all cars have a powerful ECU, which is called the Gateway node, which does a lot of routing functionality. So it's a much more powerful ECU. We can use that as a root of trust. And what we assume is that when the car is being manufactured or a mechanic is installing a new ECU, the new ECU, so we somehow put a pre-shared key or a pre-shared trust relation, we establish that while installing this new ECU with the Gateway ECU. And then our Gateway becomes the root of trust for all our future operations. And the way that the scheme will work is that the Gateway will be used as a monitor. So the Gateway just monitors all the transmissions on the bus. It's not doing active participation. And that's actually sufficient to ensure that there's authentication. So if we take the tree-based scheme, how this would work is the Gateway would broadcast a nonce. These ECUs, instead of choosing random values, they actually generate a tag on that nonce using the pre-shared key. And they use that as input of the plug and secure. And nothing else changes. But what this gives is it gives the Gateway the ability to verify every transmission that happens on the bus. And because it's a broadcast medium, so we're not changing anything. So we get this for free. And at each stage, you can just transmit a OK message. And we get verified messages. The problem with this is that this does not have forward secrecy. And in the automotive domain, that is important because you can remove ECUs. You can extract the keys. There are some ECUs, like your door ECU, which is just easy to access. So it's possible to remove that. And here, of course, if your keys are your K1, the long-term keys are compromised. And if somebody has access to the medium, then they know everything. So that can actually be fixed. So instead of the Gateway broadcasting a nonce, it sort of transfers a nonce to just one of the nodes secretly. So it transfers a nonce to the first node secretly using the basic plug and secure. And then the protocol proceeds using the linear structure. So we cannot have a tree structure here. We would have to go back to a linear structure. So essentially, where the nodes were using pseudo random values first, instead of pseudo random values, they will use true random values and then a tag on these two random values to do plug and secure. And that would actually give you a shared authenticated key. And this would actually have perfect forward secrecy. And because of adding these authentication tags, we're not actually losing anything in terms of bandwidth because we lose half the bits anyway. So for a 128-bit key, we have to transmit 256 bits anyway. So now we use 128-bit randomness and then 128-bit tag. So yeah, so that's the basic authenticated scheme. So just to sort of summarize, we have the scheme provides security against active and passive adversaries. You get nice properties. So perfect forward secrecy is difficult to achieve. And it's good with almost no computation overhead. So we get that key independence. If you really want, you can get information theoretic secrecy. Of course, there's some trade-off in terms of bandwidth. The operations are very efficient. So you're just using the natural and structure and discarding bits. And in the authenticated case, you're computing tags, which are, again, very efficient. And it's based on very simple cryptographic primitives. And the number of rounds is very comparable to the best-known schemes in literature. So the scaling of computation with key lengths is linear in this case, which I think becomes a big advantage even if you're using going in the elliptic curve domain. As you scale the key length, your computation increases square with the key length at least. But here you have linear increase. And what we haven't presented here is so you can actually the gateway verification functionality can actually be distributed over several gateways. And we have structures for that already. Of course, one of the things that's not been covered in this talk in particular, as I mentioned, is probing attacks or adversaries with low-level physical access. There are actually very interesting attacks which exist there. And we've actually considered them. And we have a whole bunch of countermeasures that can be easily implemented on this scheme. And that's actually in preparation for publication. And with that, I will take any questions.