 We are here at the ARM TechCon and who are you? Goff Lindemann, Knock Knock Labs. Knock Knock Labs and who are you? I'm Milos Meryak, ARM. And so do you both work in the security of IoT? Yes, in some sense. So we are mostly focused on authentication and in cloud space and IoT space now. So how is authentication important for the IoT? So you might have heard about recent attacks on video cameras where they have been misused for distributed denial of service attacks and with our technology you can make sure that there is no blank password, no default password, it's just more secure and more convenient authentication for users. How does it work? There's no password. How do you authenticate? So there's essentially two parts of that. The first thing, the user interacts with what we call an authenticator and then the authenticator runs a challenge response protocol, a cryptographic challenge response protocol with the IoT device itself. So is this going to work with what he's doing? Yes, so just to put some name tags on the password. Authenticator would be, for example, your smartphone. So instead of entering a password, you have your smartphone as smartphone is basically an envoy of you and basically you can basically, it's like a passport to your IoT devices. And I think that makes IoT way more user friendly. Yeah, and you have seen different modalities supported by authenticators. So there's a lot of smartphones supporting fingerprint sensors now. There are newer smartphones that support Iris recognition. And there might be authenticators built into smartphones with use speaker recognition in the future. So there's a lot of different choices you can make. And the good thing is that will not impact the size of the stack you have to implement in IoT devices. They can still support arbitrary modalities. So what you're doing, is this compatible with what you're doing in ARM? Yes, so I think I'll stuff like nicely, like compliment each other. So like in order to have this device identities and the security model, you need basically to store cryptographic secrets and whatever the attacker does to the device, they should not get hold of the secrets. And we, without technology, make sure that these secrets are compartmentalized and let's say even after device is hacked, that you can still like talk to the device remotely and reset it to a known state. So last week, was it, is it correct? There was a million ARM devices in the US shut down the whole like part of the internet. It was ARM devices, right? Yes. So it's really important for you to make ARM, all ARM super secure. And are you gonna succeed with this? So yes, so like the problem that happened is that these devices had default username passwords. So by having like this advanced authentication methods, you would not need a username password and that situation could not exist in the first place. So I think a large part of that story is about educating manufacturers. For example, not to ship devices with default passwords, but for example, to seek alternate solutions for authenticating to these devices. Who were the hackers last week? Do you know who it was? I think it's not known who the hackers were. But you have access to the IRC group or something? You checked? No, but the point is like, I'm not so interested about hackers because the attack itself is incredibly trivial, right? So you scan for devices of a certain manufacturer, you get a known string as response. So the point is like, internet is actually not as big as people think. So internet basically, in IPv4, four space are four billion addresses. It turns out with a 10 gigabit uplink, you can scan literally the whole internet within five minutes. And that's basically like, simply the internet is now fast enough that like everybody's dog can scan the whole of the internet within five minutes, find all these cameras and by having all the same user and password, every idiot in his dog can execute this attack. Have you scanned the whole internet as part of your job? Do you do that every week or something? I have plausible deniability. Okay. So Knock Knock Labs is a company, do you have business already doing this? Yes, we have already business and we are currently mostly focused on user-to-cloud authentication, right? And we have customers like NDDDocomo in Japan, which have ruled out our technology to their customer base already. And now we are bringing the same technology to internet of things use cases. So scale it down from big cloud services to small internet of things devices. It doesn't make things more complicated to install and buy and stuff. Is it as easy to set up? Yes, it's as easy as set up and the good thing is the user verification or authentication gets much easier for the user, right? You don't have to remember all the different passwords for different devices connected to cloud service anymore to just authenticate using your preferred user verification method, which might be a fingerprint or speaker recognition or face recognition or whatever. So if you get an IP camera, on-part IP camera, and you get an on-part IP camera DVR machine, how would you authenticate it? So you typically, those cameras do not have a direct user interface, right? There's no keyboard with a camera, there's no display directly. So you have to use your tablet or your smartphone to connect to those devices. Just any smartphone, you have 10 IP cameras and start authenticating. And sure you have to register first and that needs some kind of initial pairing or registration process. And typically what we have learned in devices case is that physical access to the device when the device has not been used yet, right? Is the right thing to do. But once you have registered, it's implicitly assumed to be, for example, an admin registration and then it automatically blocks further registrations without explicit permission from that initial admin. Unless you'd reset the devices or in the real estate. So is this in the hardware or is it just a software solution? So for example, the hardware can help a lot with discoverability. So for example, by using technologies like Bluetooth Low Energy, you can literally detect devices in front of you. So you can control the transmission power of Bluetooth Low Energy devices and the smartphone then can figure out this is the device apparently standing in front of. So the hardware can facilitate this discovery process a lot and. So this arm trust zone, we've seen that for a while. Are people using that? Or is it they're just shipping and not really using it? And this could be more security, right? Arm trust zone I think is on pretty much probably most of the Android phones since many, many years. It was predominantly used for DRM, for example, for digital content. So let's say, even let's say, five, eight years in the past when you were playing an HD video, streaming on the smartphone, most likely arm trust zone was involved. But I think the new cases of, for example, malware detection and so on are pretty exciting. So for these, we still need to convince, for example, like large operating system vendors or like Google, for example, to use basically this additional capabilities of trust zone to do more than just digital rights management. I think the second, let's say, largest use case for trust zone actually is implementation of authenticators. And we have seen large companies like Samsung and Sony and so on, all implementing phyto authenticators, putting them on the devices and using trust zone technology to protect those authenticators from the rich operating system. So you work with trust zone? We work with a lot of authenticator vendors and we have done a lot of proof of concept implementations which then have been used for real deployments. So the way trust zone works, like a lot of people are using trust zone without being aware of it. So for example, in Android, you have like generic APIs for a key storage and it just happens that some of these key storages are backed by trust zone. So you can ask basically interface if you care about trust zone, whether something is trust zone. But I think most cases, you would use trust zone without realizing. So let's say, if you stop, let's say passwords in your browser, that storage might be protected by a trust zone backed secret. Because I really wanna see passwords disappear. Is that your business? That's our business. Oh, it's only IoT for consumers also. Yes, so we already use that for consumers to cloud authentication and now we are moving towards a space for consumers to IoT device authentication. So that's- Because what's the point in having all these passwords for all these websites, for all these IoT devices? That's not secure, right? It's first not secure and second it's not convenient, right? So you can't remember that as a user. You typically forget the password. Then you come up with all these workarounds, right? You have it written down or stored in password managers or even worse stored in some other cloud storage systems which are vulnerable and some of them already have been attacked. So that's things you want to want. So you log into a registered system on the web, something on the cloud and that's how you authenticate all your devices. And if you lose your phone, you can log in again with another phone or? So there are different kinds of IoT devices. There are standalone devices, for example, light bulbs, right? Or Wi-Fi routers, typically do not depend on external cloud services to work. So you can authenticate directly to those devices but they are also connected. IoT devices, for example, cars, right? It could be connected to a cloud service as could be doors, right? For example, in hotel rooms and if they are connected to cloud services, you register to the cloud service, right? To my rental car.com, for example, or to my hotel.com. You register as a user, you book your room, then you show up in the hotel, you want to skip the check-in line, you just go straight to your room and then authenticate to that door with the authentication capability. So there's authentication, is there a lot of other things you're doing for security? Yeah, so firmware update I think is also a big topic. So if basically you have problems in IoT devices then you need to make it as simple as possible to manufacture, recover from them. So in that sense, we need to establish this common way for doing firmware updates. So you don't necessarily depend on a manufacturer cooking up their own firmware update and introducing, for example, security problems with that in the first place. Is that embed OS? Is that part of what it does? Provides updates? Yes, so we provide firmware update which is portable across a large set of devices and it's basically a common way where you can have the same security assurances across devices from different manufacturers. So if you have a firmware updates, you have secure authentication, does that mean you have 100% security? No, you never have 100% security. Still not? No, you haven't fixed it since last year? No. No? And I will never fix it. Never? Never. Not possible. No, it's not possible. That's not possible, but what you can do, you can work hard to make sure that the attack is so expensive for an attacker to run that it's not worth doing it. And this is what we think is a way to go forward to protect against scalable attacks to make sure that attackers cannot simply steal, let's say, hundreds of millions of passwords from servers just by avoid storing secrets on the servers or devices. So that was a story where they wouldn't really want to spend $10,000 hacking one light bulb. There's no point. Exactly. So that's the main case you have right here. That's still the story. Exactly. It's still the story. But how many other things do you have in security? You have so firmware, you have authentication. So the device identity, which is an extent of authenticating the device, because, of course, devices have also a relation between each other. So I need to trust, for example, that the device that initiates an action is basically that device. It's not some attacker that pretends to be the device. So I think a strong part of authentication also like identity. Because it's too expensive to put a unique ID in every CPU, right? That's not something they do. That's very common right now. So every modern microcontroller has a unique serial number. But a unique serial number is not sufficient for device identity. Because a serial number, once you see it, you can pretend to have the same serial number. And it does not help. So you need, essentially, a method where you have some secret, which is not shared by the other side. And traditionally, public key cryptography is very useful for that, where you share your public key, which is your identity. But you prove to be in the possession of the private key whenever someone asks you which one. Also provides other advantages, because this public key does not need to be the same for the device, for the lifetime of the device. So if that user gives the device to another person, you can avoid this global correlation and this traceability across the device owners, right? If you just replace all these key material, which you can't typically do with a CPU serial number. So what we generally recommend is per device edge. So basically, if you have multiple nodes, you have relationship between these devices. So each relationship is an edge. And for each edge, you can have a different identity. So that would be the ideal case. So let's say if you have a smartphone, then, for example, identity towards a vending machine A would be a different one than to vending machine B. So basically, the vending company could not track you between these two machines. And the new Cortex-M2232, they add the trust zone and other things that add security to Cortex-M. Yeah, so I think all modern products will contain the security features when we are constantly extending the security features. But then it's also important to have a cloud, like machine learning or something. Is it what you do also to kind of like find out if that device supposed to be there or not to identify it or... So that's a different thing, right? So there is machine learning typically involved in the risk-based authentication, especially when you authenticate to cloud services. There's the explicit signal that the user claims, I'm the right user, and you do the cryptography to verify that it's indeed that user. But then there is some backend calculation you do on top of that, which is the risk analytics thing. And there's typically machine learning involved there. How that translates to small devices, that's a different question, right? If those devices are connected to cloud service, you can still offload that to the cloud services at machine learning, but I'm not sure that you really can scale down the machine learning into those small devices always. All right, so one interesting aspect of machine learning, I think in combination with cloud networks is, can I trust the data which are used as a basis of the machine learning? Because if an attacker, I can shift the data by pretending to provide measurements, I can influence the machine learning to my benefit. And being able to trust the data, created by these very small sensors, I think it's of vital importance for having reliable machine learning. And how about having some kind of secure OS subsystem thing? Is this something happening? Before there was a stress zone, there was a whole second OS kind of idea, where you would be secure OS, you type your passport in there or something. But is that something you were doing? Yeah, so like the security needs to be integrated with other system components. So whatever the OS is, it needs to be tightly integrated with the security functions. So for example, with respect to recoverability, with respect to firmware update, so every OS needs to perform this integration. So yes, like the OS would need to be integrated with the security functions. All right, cool. So looking forward to 100%, I want 100%. I hope you will find a way. No, it's asymptotically approaching 100%, but technically we never reach 100%. Cool, and all these IP cameras that have issues right now, what do you recommend them to do? Just return them up. Yeah, throw them into a dump. All right. Let's see if they can keep doing DDoS every two weeks with those, but there's no way to stop it, right? Let's shut them off. So I think the easiest approach is that the providers behind these cameras block that traffic. So the users won't even notice that their cameras are now safe with respect to internet. But the providers essentially need to remove that threat. They need to do a recall. No, you see, let's say you have a thousand users, let's say here in Santa Clara with these cameras. So you don't have to approach these customers, but let's say the cable provider that gives them internet access can detect that specific traffic and block that traffic before it hits the internet. So that would be, I think, the immediate resolution to block all this bad traffic. At the provider level, and then the users don't even need to know that these devices are affecting the first place. I think that's a pragmatic solution here. And then midterm, you have to update the firmware to make sure those things do not happen that easily. But I think that is impractical because you would need to communicate to the user who reads the mail they get from the provider, who reads any paper, mail. Maybe ARM should send a few engineers over to the company in Shenzhen in China and help them update their firmware. Maybe that's something you could think about doing now. And that ARM is a little bit different than the company. After a fact, it's very hard to fix these kinds of problems. So the millionaire device is already out there. So whatever is now fixed at this company in Shenzhen, which probably is now aware that that is a problem and they are now aware of it, they won't make that mistake again, most likely. But still, it doesn't change that there's million devices out there and they are technically vulnerable unless the provider starts blocking the inbound access, which is the other aspect. So you stop reinfection, but also block outgoing malicious traffic. And they can use embed for the next product, right? Embed OS. Yes, so we would have integration, for example, with sophisticated authenticators and that would remove the need for these passports. And this is hopefully something you are preparing, right? Embed OS customized for that market, the IP camera market, it just works. So the way that works is that partners do this customizations themselves. And so it's not our business to create IP cameras. Okay, okay, cool. This is a hot topic right here at ArmTechCon. What you're talking about right now is like the important thing, right? So you have a lot of discussions here with the industry, right? Yeah, looking forward to that. Cool.