 This is Lars Lidesen of the Silicon Laboratories in Norway, and he is the head of the security office and they are making chips for smart devices in homes, and his talk is about how you commission them on network and all the risks that go with that and all that. That can go wrong with that and how you should solve it, so he'll have a talk on that. So, enjoy. Thank you. Thank you very much for coming. It's quite an interesting time of day to have such a technical topic, but I'm also proud to be able to give this presentation at two different dates. This is the first time I give a presentation that actually lasts formally for two days. I'm using methods for IoT. Who am I? So, I used to be a quantum hacker. Quantum cryptography are these beautiful systems that deliver perfect security, but there are hundreds of them in the world, and they are used in real applications. And there will be a bit of talk tomorrow by Vadim who's here taking pictures at the moment at 1.30, so you can go into depth on that. But since then, I changed hats, and now I'm working for silicon laboratories that make connectivity chips. So, instead of securing some hundreds of very expensive systems, I'm securing billions of very cheap systems. And what's going on? What's happening with the world? Well, in the classical cybersecurity space, our house used to look like this, and soon it looks like this, with all kinds of wireless protocols in all of these devices. And there are a few big issues with that. And the attack surface for a hacker has increased, it has exploded, since all of these are now connected and many of them talk several different protocols. And accessibility to hardware is becoming a big problem, because suddenly the hackers can now have the device in their hands. And from being used to having secure IP connection, you actually have to be concerned about something cracking open the device, and starting to look inside the chip. And people are doing that, looking inside our chips. And the limited processing power in end nodes. So basically, I usually say, I don't want my live builds to have to run antivirus. So it's this issue. So we're actually, I'm working in Norway, but the headquarters is in Texas. So I like to kind of talk about things that resonate with Texans. And guns really resonate with Texans. So this is actually a female hacker in the region. This was on Black Hat two years ago. Who have heard about this rifle hack before? The bear guys in the back. So basically, this is a rifle, a smart rifle, where you aim and then you push a button when you have what you want to hit inside. And then when you push the trigger, it will fire automatically when it's perfectly positioned. And then they could hack it over the Wi-Fi connection. So when you aim that this person here, you actually shot this person here by changing the calibration. So that's from one female Norwegian hacker. And this is to another one. This says network in the heart. So basically, a lot of people ask me, why do anyone hack a medical device? My answer is typically because it's a security expert that gets a medical device inside of them. And they say, hey, does this thing have connectivity? So this was on the region hacker that got a pacemaker and actually figured out there was insecure wireless interfaces to it. And this is why Dick Cheney got a special pacemaker without wireless interfaces. And typically, I encourage to take the debate afterwards, if you have a pacemaker, would you want open or closed source? To me, that's the ultimate question of open versus closed source because it's a life or death question. And of course, the Mirai botnet attack has really put IoT security on the agenda at the authorities. And two days ago, there was a legislation proposal in the US that any federal building when they buy IoT devices, they have to have a minimum security level. So this is moving into regulation at this point. It's going slower than it should, but it's actually happening. So when we talk about commissioning, we have to talk about attackers. So what's the commissioning problem? The commissioning problem is when you have a device and you want to put it on your network and you need to exchange credentials. So somehow, once you have a password that you can use to secure the link, securing the link is trivial. That's not where most of the hacks happen. Most of the hacks in this space happen when the keys are exchanged. So we have passive attackers that only listen. And then we have the active attackers that do man-in-the-middle attacks. So basically, when the communicating part is typically Alice and Bob, try to communicate, someone is sitting in the middle and intercept and resend and modify all the information that's sent. And we look at IoT wireless protocols. What is that? I mentioned Wi-Fi, Bluetooth, SIGB and Thread. Who here has heard about SIGB? Okay, this is very impressive. And who here has heard about Thread? Okay, yeah, that's... Thread is kind of the next-generation SIGB with IP connectivity. It's also mesh protocol, but it's IP-connectable. And typically, what we talk about when we see a lot of the big news stories, some of them used to be vulnerable to passive attackers. But then we talk about, yeah, they're pretty secure against active attackers. Disregarding man-in-the-middle during commissioning. So we're kind of all the time, we're just putting the real problem under the rug. So the commissioning problem, how do you secure the link? How Alice and Bob, they need somehow to get the secret key, the link key or the network key. And that's typically happening when you put a device on the network. We all know it's when we take our laptop home and we type in the password to the router. This is one way of distributing the key. And this is actually a real problem, not only a theoretical problem at this point. So there was this story, this spring, and now it's resurfaced again, where someone could make a worm that spread from light bulb to light bulb over these Philips Hue smart bulbs. These were SIGBI bulbs. And to steal other bulbs, so what the worm wants to do, he wants to replicate itself into new bulbs, it exploited our issue in the commissioning protocol. And why could this happen? Well, it's because security and privacy is a balancing act. So security and ease of use and functionality is at conflict. To me, the Philips Hue guys actually do an amazing job of securing the product. But the problem is that my mother needs to be able to buy a light bulb and get it on the network. And if that's really hard, she won't buy that light bulb. So what do you do? Okay, so I'm going to kind of give you an overview of the commissioning schemes that exist and kind of a little bit the traits of each of them so you know which one to pick. And the first one is what we call permissive schemes. And basically, you just send the key over the link. It's easier as that. You say, okay, I accept a reduced security when the commissioning happens or when my mother brought the light bulb home. Perhaps there is a window that's risky, but okay, we accept that. So we do it in the clear or we can send it encrypted, authenticated with a well-known key, which kind of to a security researcher sounds silly, but this is actually what's going on in a lot of protocols. I feel like I have to mention it. And you can use public key cryptography to secure it. So at least then you're secure against passive attackers but not against active attackers. It can also be improved by temporal filtering. So this is like you can only do the commissioning at a certain time when you push a button. There is a window commission within one net or spatial filtering, which is what a lot of these do, where the devices need to be physically close to each other to be able to commission. So that can be an okay solution. Like NFC and airfield communication is using that and also saying, okay, if I'm at home and I'm commissioning two devices and I know they're in my living room, perhaps that's acceptable. Perhaps it's acceptable that I think that the hacker is not outside with a powerful antenna at that time. I won't go through public key exchange because I assume you know that already. So to summarize, permissive is very easy to use. There is no UI requirements. So it's not like my IoT device needs a button or a screen or anything because it just accepts any connection and there are minimal operational requirements. Like when I produce the device, I don't have to insert any secrets into it. So it's very easy to produce. And it works offline, which is increasingly a requirement. But the level of security is really low. And in many cases, this is a trade-off that the companies are willing to do. Then we have shared key, where from somewhere this key is coming to both Alice and Bob. And this is the scheme in the Wi-Fi router. You type the password in the router and you type the password on the computer. So you're kind of manually carrying the key around. And there are many ways of doing this. You can have the key printed on the note, you can have QR codes to make it more efficient. One of the big issues with this is that it kind of encourages short keys. Like most people I know, they have a super short, easy to remember key on their Wi-Fi just because of convenience. So there are ways to make long keys efficient if you want to use this scheme. Like QR codes, or you can use something called JPEC, which is a fancy protocol where you can have very short keys at both ends, but still make it very resistant against brute force. And of course, again, temporal filtering and spatial filtering. So shared key can provide good security and it works offline. But it requires user interaction, typically, and it requires a user interface. And it can motivate insufficient killings and there is operational complexity. And that's something that sounds simple, but we hear again and again about router producers that make a default password via some algorithm and the algorithm comes out and then suddenly it turns out that all the passwords leaked simultaneously. So the operational, my advice is always don't underestimate how operationally hard it is to inject secrets into every device. It sounds like this is well-known, it's just engineering, but it's still non-trivial to do. The last way of doing this is certificate-based, where the parties pre-share, hold on, pre-share public keys. And this way they can actually properly authenticate each other via public key cryptography. And there is a lot of flexibility here. Once you have the public keys, you can grant rights, you can do certificate chains, you can do a lot of very sophisticated things. And so it's the perfect flexible security, there is no user interaction, but there is a significant operational complexity, much more complicated than the other skills. It may not work offline, and it requires more resources on the devices. So on a small device, you might not have the computational power to do public key cryptography. And so on here, ask me how are, if you look at many of the big vendors, you are now getting in a position where, like if I order something from Amazon, it already connects with my home, and that's because they have the operational proficiency to do this. Okay, so this is just a spray permissive, it's bad security and super on everything else. Certificate is great on everything, but operational requirements, because it's just hard to do, to distribute all these certificates, and shared key is somewhere in the middle. So in protocols, Wi-Fi, this is the well-known that we all use, it's a shared key method, and then of course that was very hard, so they made this VPS, which is a permissive scheme where you push this button on each device, and then suddenly magically they work together. The problem with that is, it must support an eight pin, or eight digit pin entry mode, which has turned out to be insecure. So VPS is simply not recommended, it's insecure, but simple. And then VPA Enterprise is a certificate-based method. The biggest challenge with this is that it's often not supported by Internet of Things devices, simply. So the problem is, if I set up my gateway to support VPA Enterprise, most of my IoT devices will not be able to connect with it. Today, Bluetooth, it has had, so I'm only referring to Bluetooth after version 4.2. And then it has been public key-based. And what the Bluetooth committee did was they put a few standard methods based on the UI on each side. So you have something called JustWorks, that's a permissive method. That just works. And then there is a numeric comparison. Basically, if you have the ability to compare digits on each screen. And this is what happens in your car. When you connect your phone, it will say, your phone will say a six digit number, and then your screen on your car will say a six digit number, and you're asked to compare them. So this is a shared key scheme. And then there is a pass key entry, where you actually enter the six digit number, and then all of these protocols, superpowers called autoband, where it means you just roll your own, figure a way to get the key to each device. And then based on what you have, you can have this different scheme. So if you have a keyboard on each end, then you can do a pass key. If you have no input and no output on any device, well, then it's only JustWorks because you can't interact with the device at all. If you have display only at the keyboard, you can do pass key, et cetera. So this is like a matrix that can give you the highest level of security based on what UI elements you have on each end. Zigbee has a lot of different variants here. One of the issues is that it's permissive and it's using a fixed key. So basically there is a secret or should be secret Zigbee key that is used to encrypt the other keys. The problem is that that key has, of course, leaked. So basically you should think of it as sending your keys in the clear. Now Zigbee 3.0 has come and it has extra options. It has something called install codes where you pre-share unique keys per node in the mesh network. I think that proximity window. So you have to be close. It uses RSSI. It's not perfect, but it works. And then Zigbee smart energy, which is used in smart grid, uses public key-based schemes. Thread is IP enabled. So this allows end-to-end connections with IP connected devices. It uses secret keys, but it uses this JPEG to make significantly longer or increase security levels. So even if the keys are short, you get a high security level. And then DTLS is used to secure the link during commissioning. It leans on DTLS as well. And then out-of-band. Out-of-band is just this magic way that the key comes from somewhere. So you can roll your own, basically. And two typical schemes we see is one standard to commission another. So someone will use Bluetooth to commission a light bulb and then it jumps to a mesh protocol afterwards. And NFC is something where physical proximity is supposed to be working well. The challenge with NFC is that like in a light bulb setting, it might not be easy to kind of get physical proximity. So that's like, it's both a pro and a con in this setting. Let's see. Okay, hold on. So final remarks. So commissioning is really a challenging trade-off between security, usability, and operational complexity. It's really where the rubber hits the road in terms of IoT security. And there are several schemes, permissive, shared keys, certificate-based, and almost all the wireless standards support different methods. And in general, this also provides interoperability. So all the standards support out-of-band. So every standard can be made secure if you want to. And then, don't roll your own scheme unless you have to, and especially for a protocol, because it's hard to do this right. Thank you very much. Okay, thank you very much. Are there any questions? Wait a minute. What I would like to ask is what... So in your chips, what kind of protocol do you use? So we support all of these protocols. We have both Bluetooth, Zigbee, Thread, and Wi-Fi chips. Okay, and is there any you prefer? Or...? I think it depends on what you're trying to do. So in a home automation, I would prefer Thread. If I was building a house, I would want Thread devices, but they are not on the market yet, so then it's Zigbee. If it's connecting to my phone, Bluetooth is the natural choice. And if it's at home or you require a lot of data, high data rate, then Zigbee. No, sorry, Wi-Fi would be the natural choice. Okay, I see someone over there. Please ask your question. So Lars, are you kind of happy with the situation with the available options and protocols? Or is there anything significant that could be improved, or maybe further research done to improve the available methods? It's a very good question. Are you repeat the question? Yes, so are there any ways to improve this? What's the situation? Are there any ways, any research that could be done? It's a good question. I think the most important aspect is to get good security in the standards itself, which sounds trivial, but actually it's not. So that's on one hand. We have public key cryptography, so we have the fundamental building blocks. Yeah, I don't know, perhaps, regulation or some major entity could do something in this space. Kind of like we have the domain name or the names, the DNS companies. And I'm not saying that it's a good solution, but at least some central authority might be able to provide a route of trust into this. I believe with Wi-Fi you were explaining that you could use certificates, and with that you would share to exchange a shared key. But wouldn't it be more logical that once you have certificates, you just use them to establish a session? Ah, yes, sorry. So the Wi-Fi can have several modes, and when you use certificates, you can use that to establish a session if you have that. Okay, so the question is, is there additionally also the mode where you do use the certificates only to exchange a shared key, or that is not officially a mode? It should be possible via the out-of-band scheme in DPS. So also Wi-Fi allows you to supply the key from somewhere, and then you could have your own, roll your own certificate-based scheme. Okay, are there any more questions? No? Okay, then I would like another applause for the speaker.