 Hey everyone, welcome. Next up, our next speaker is Brian Knopf. Knopf? Awesome. Okay. And he is giving his talk on redesigning PKI, you know, because IoT crypto is hard. Thank you. So I was going to joke and put up the camera because every time I've told people the topic, I get this look. And it's been a running joke all week, like redesigning PKI because everyone uses it, right? So a little bit of my background to understand kind of where I'm coming from in this. A lot of those devices sitting on the table over there are ones I've designed. So I used to run security for Linksys and Belkin. And just because that means there's vulnerabilities doesn't mean we didn't know about them. And then I left and went to Wink. So my focus has been IoT for about five or six years. And this really is research based on my work in defense and attack and getting tired of getting owned when I shown. So I'm going to take you through kind of what this TDI framework is and then kind of explain the keys and the terms because trust me, you'll need a roadmap for the keys. And then I've got a demo at the end and you'll get a real good sense of what we're talking about here. So what is TDI? So it stands for Trusted Device Identity. This is a framework that I started designing on my living room floor. And it was acquired by a new star in August. We started as one ID. And it was a team of five of us building this framework for IoT devices. The idea was we were tired of popping shells and breaking things and thought we should actually start fixing things and making it harder to break these devices. So what happened? And I joke what didn't happen. So some of these headlines look familiar because some of them are on things that I worked on. Some of them are on things that were on my devices. Well let's take the Philips hue as a great example. One of the things that happened to the Philips hue is the attack was using the hub to generate traffic and send requests to the light bulbs, right? Unauthenticated. Not surprising. One of the things as a researcher, as an attacker, is cloning the device. It's usually fairly simple. We're being on the same land segment and being able to send attacks to the device. So what if we change that idea and say everything will be compromised? So don't trust anything until proven otherwise. And that's kind of what we started with this idea. That the network, the service, the user, the device, the app, everything is going to be compromised at some point. So assume they're compromised and start from there. So you had all these devices being hacked. And then these things happened. Right? Our root CAs were getting owned. Right? Komodo got completely owned. Google's intermediate certs got taken. Diginotar, which is even on there, oh it actually is on there, sorry, got their root certs. So you have this party that's putting keys and someone has access to get root cert on things you're using. So what if we made it so that the only person that can generate a root cert or get root access is you, rather than the person who controls the CA. And then these are the ones that kind of get personal for me. These are the products I worked on because as I was running the WiIMO products at Belkin, one of our developers dropped a private key for some reason on the device during an update. And a researcher rightfully copied that key and made their own firmware. So now I have a half a million devices that are sitting in the wild waiting for users to update those devices because my knock and my sock are sitting there going I'm compromised, we can't do anything until they update. And it occurred to me, the people who actually understand the security aren't the ones in control anymore. And they're waiting on these users to do all these things rather than letting them control it. So this kind of got me thinking, let's completely think about the way we do PKI and how it doesn't work at all for IoT. Now this really can be applied to other things, but in the IoT sense IoT, PKI and IoT does not scale at all. So if you've ever heard me talk before, you know that I sort of live the IoT space. My house has 130 IoT devices in it. Every single light bulb, door lock, window sensor, my pool, everything in my house is connected. And the reason is I don't think you can actually solve a problem unless you live the problem. And so I do research on a full-time basis in my house on everything that goes across the network. And yes that requires some enterprise gear for switching because of the bandwidth, but it also lets me see things, relationships between devices that I wouldn't otherwise see. So when I started this, I grabbed a ream of paper and sat on my floor. And I drew out a threat model for every single device I had ever attacked, defended or worked on, or anything that I had ever seen other researchers, some of which I see in the audience had worked on. And I started to think is what would we need to do to design this so that the minute that attack happens, I can recover regardless of what that attack is. If that attack is on the app, the user, the server, any of those things, I revoke it because I'm in control and now I'm recovered. Now of course that means you have to patch or fix whatever vulnerability that is, but as fast as you can spin up that system, you'd be allowed to remove it. And we're going to show you this in the demo, it literally is a one-second revoke. So we know crypto is hard. We know that developers like anyone else make mistakes, right? Whether they're trying to, you know, mess around with PKI or not, it becomes very difficult to get it right. What if we made it easier, right? And that's kind of the idea. And I'll give you one more story. I worked at a company called Wink. I was there three months and I got a call on a Saturday morning as I was hanging out with my kids that all the devices on the East Coast had just disconnected. And so we had about 50,000 devices and about 30-something thousand had disconnected already and had three hours to save the West Coast devices. Now show hands in here who has dealt with an expired cert. So the sad thing is that everyone has an expired cert story, right? And this should never, ever happen, right? So I was asked at an early hour in the morning to try and hack back into my device to recover those devices and fix them. Luckily NTP is awful and so is DNS. And so we injected a DNS entry for a fake NTP server and set time back to fix some of those devices. But the ones we didn't fix got even worse because they had completely disconnected from the network. So we went to Best Buy, Amazon and Lowe's and everyone else had them box up every device, ship it to a warehouse and had the entire team flashing firmware including the users. This is not exactly something you ever want to happen or see happen again. All these things led me to say okay, PKI sucks, we get this. So what do we need it to do? Trust nothing, right? Don't assume that your network is your security model. And I can't tell you how many times I look at a device and they've just assumed that if it's all under land it's allowed to be looked at. And not only should you check that but make sure you check it again and again for every single request. And that way you can do real-time revocation. Key rotation should not be this massive effort. If you've ever done key rotation in IT team they plan for it, they test for it, it's a weekend effort or a night long effort. It's not some easy thing. It should be a five-minute effort, right? So how do we make that? And plan for complete failure. As good as your APSEC team is going to be, at some point you're going to get a third-party library that's going to own you. It happened to me, right? We were fuzzing protocols. We were doing things that other APSEC teams were not doing. But we still got a private key exposed from a third-party library of all. So when that happens, not if, how do you recover and how do you recover fast? Because when it happened to us we spent six months cleaning it up, which meant we didn't ship a whole product line. That product line literally went in a dumpster. Because by the time we were able to ship, our competitors had newer products on. So how do you make sure you can work on product on the roadmap? Not sit there maintaining compromised environments. And that's really what this is about. I should say as part of this, we've partnered up with Dell and the Linux Foundation. There's an Edge Foundry product. All this code is being contributed to that project to make a secure IoT framework. So it's going to be released under the Apache 2.0 license. And the idea is to let manufacturers take this code and build secure IoT devices for anyone who wants to work on those. So let's talk about some key terms really quick, because this will help you understand it. So a fleet, think of a fleet as any SKU. So just pick a device back there, right? You consider that a fleet. And the idea of the fleet is just, it's a rubber band around things that are allowed to communicate on behalf of the fleet. So each fleet server is just anything, whether it's a connection server, a content server, a firmware update server, that you want to be able to sign on behalf of that fleet. The co-signing service is the heart of what TDI is. And the idea is that in real time, those servers are validated to make sure they're still valid for the fleet. This means when you revoke one, it's gone. Not in a little while, not the public key being removed from the device, it is gone instantly. And it's a one second thing, which means you can remove all your servers, every single server from your pool, put new servers back, and the next request goes through. And the reason is because we separate out authentication and authorization. And think of how this works with IoT devices. You've got a smart car and it's in front of you driving. You stop your car really fast. And my smart car needs to slow down and know that your smart car stopped. I don't need to know anything about you. I just need to know that you're authorized to talk to me. Not that I authenticate directly to you. And the devices, of course, are just the IoT devices that are connecting. So there's a lot of keys here. And let me explain what's going on. I know it looks confusing, but I promise it will get very clear. Every single device has its own identity. That identity could be a secure element or TPM or TE, but it has its own identity. And because that identity is used to communicate with the servers. But it also has the public key for two things, the fleet and the co-signing service. And the reason it doesn't need to know a server is because all it needs to know is those two public keys. And that allows it to know that it's authorized to speak to that server. We also create these reset keys and I'll go into them a little bit. But remember when I said everything will be compromised? Well, we have a way of recovering when everything is compromised. It's not probable, but it is possible. And finally, we have the co-signing service. So for every fleet, we create a new private public key pair so that if one fleet is compromised, other fleets are not compromised. So as I said, when we're talking about identities for the device, one of the things we're doing is tying the actual hardware to the firmware. And if you ever talked to a researcher who works on IoT, one of the first things they do, they look for the OAuth tokens, they're looking for the identity so they can put it into Burp Suite and start pretending to be that device. What if you pulled the hardware identity? What if you did a firmware checksum to make sure that the digital identity you assigned to it was actually tied to the hardware identity? Now you actually know that the device you're talking to is the device you're talking to and not a researcher. So we've partnered with an Intel on their EPID identities and we can use that EPID identity and pick up the public key and now that becomes the identity of the device. We've also talked to other secure element TPMTE makers to do the same thing. So if the device already has a provisioned identity, great. If not, we can generate that. That would be in the firmware. Obviously, it would be more secure to be in a hardware root of trust. And again, these fleet servers are verifying anything within there. So the fleet server is given the authorization to speak on behalf of the fleet. And I'll show you the workflow and how that works and it'll make sense once I do that. So here's what we're talking about as far as components. We've got the co-signing engine. This is a real-time verification and has some additional things that I'll get into, but the heart of it is verifying in real-time and revoking in real-time. The client app has a lightweight piece of code and that code is used to verify and generate signatures. So any message in every single message has a signature on it. The fleet server gets the same thing. It gets a lightweight piece of code that goes on it so it can generate messages when it wants to send firmware or content or anything down to the device. And then that same thing would go on any client app, any gateway or any device. And I'll show you why I said gateway, not just app. Everyone wants to know the tech. So this is the P256 curve. Now, I really wanted to use ED25519, but what you find out is that some of the low-power IoT devices don't actually support it. So when I sat down with NXP and other chip manufacturers to find out what chip supported this, we ended up going a little lower in the encryption than we wanted. But if you look at it, it's not the encryption that's usually broken. So this isn't going to be something that's a big problem for us. The other part of it, and one of our developers is back there, is asking developers to rewrite their stack is something that's usually not easy to do. So we wanted to do code implementations in every language that developers were working in so that whatever they were using, they could use our library. So we have a bunch, Python, C, Node, Java. We have a Docker container that we just made two days before, so I didn't get a chance to put it in there. And we've got some other implementations on the way. The other thing is, IoT devices don't have a whole lot of space. If you've ever built an IoT device rather than just playing around with them, what you'll find is sometimes we didn't have even room to put SSL libraries in. And I know that sounds really strange, but it's true, right? We've, I've been at places where we were stripping text off pages to try and make enough room to put the SSL libraries in. As ridiculous as that sounds. So we've got it down to 100 kilobit. We also, it's about 32K of RAM. It's a very lightweight thing that runs on the device in the gateway. And we also have a CLI and API and a UI. So most likely people would integrate this with their, you know, with their SIM, with their other dashboards. We have a dashboard to evaluate it, so if you're going to build your own implementation. But the idea is give you data however you need to take that data. So let's explain the difference between PKI and TDI. And it's really simple. In PKI model, you want to send a firmware update down to a device. The server generates a request, sends it down to the device. And now you're asking that device to do a lookup on a CRL. Now those CRLs can get really long. They take a long time. And you're asking the lower power device to do that. With TDI, we turn that around and say the server actually requests to TDI to make a request to the device. And TDI validates that server to make sure it's still part of the fleet. If it's not part of the fleet, we kill it. And this prevents an Apple fail condition where you have invalid certs, but it still allows the request. So this allows us to do the real-time revocation, adding all the servers back, removing servers. And again, I'll show you this in the demo how we do this. Now think about this for a minute, right? When you're using PKI with CRL and shared server keys, one server is compromised, every single server is compromised. And anytime you add a server, right, you've had to add that public key to every device and every server that can communicate with it. That's a big problem, right? Because it's one thing when you're on a PC with a lot of power. When you're talking about an IoT device and you're talking about thousands of servers that can serve content to it, now you're talking about a lot of overhead that that device really can't handle. You're talking about lower power networks, lower bandwidth networks. They can't have a constant flow of updates, right? They have other things, streams of data that they want to send. Now when you have individual server keys, it gets even worse, right? Now everything is getting a copy of everything. Every device gets a copy of every server's public key. Every server gets a copy of every other server's public key. And the problem here is, one, you don't have the room and two, it's a massive overload of communication. The last thing is, again, every time you have a breach, you have to pull that public key off an IoT device. And IoT is like Android. It's not like a PC. You're not, you have to do a firmware update in order to pull that public key. It's not just sitting out there. And that requires a lot of testing. It requires time. But it also requires users to do something. And let's be honest, users don't patch, right? So instead of telling users to learn security, why don't we turn that around and say, we're going to change security to work for users? And that's really what we're doing here. So, all right, OCSP tried to fix this, right? Great. You send the verification down with the actual request. The problem is the public key is still on the device. So when you revoke, you still have to go and remove that. So the difference really here is servers can be revoked instantly with TDI. With PKI, you have to pull the public key off of them, right? Devices only store two keys, right? The TDI service and the fleet. They don't store every public key for every server. And again, this is that authorization and authentication separating out. And again, with PKI, right, you start to overload these devices with every public key that they have access. If you think of what's happening today with attacks, Crypto Locker, right? Sony being attacked and losing access to all their servers. The power here is that if you've lost access to your entire environment, and I don't mean a couple servers, I mean everything is completely compromised, TDI allows you to recover. And I wasn't kidding when I said I expect everything to be compromised, so make sure you can recover from anything. In PKI, you're talking about potentially hundreds, thousands of devices, right? They need to be rekeyed. So you generate those keys, you push them out, you do a lot of firmware updates. Again, and then you're waiting. So when I was at Belkin, we had those 500,000 devices that were compromised. When we got down to the last couple, almost a thousand users, we just sent them new devices and told them that they had four days to switch over to those devices because they wouldn't update them, right? Because we were maintaining this environment that was completely compromised, right? Noxock basically just sitting there twiddling their thumbs going, what do I do? I wanted them to be in control of what they needed to do. So let me go through the workflow really quick. It's fairly simple. So when you want to create a fleet, if you have an HSM, you just grab the public key and upload it into the TDI interface. Otherwise, you use the API, the SDK, to generate a public-private key pair. Then you have a fleet, now you can assign an owner to that fleet. And so the owner in this case is an administrator, someone who can add or move servers, add or move devices, right? This would be your Nox, your Sock members. So you can have multiple people that have access to this. And again, when you create that fleet, TDI creates a separate instance of it, right? So that fleet is, the fleet keys for that are completely separate than any other fleet. Now you want to provision servers so that they can go ahead and take care of communication. So you generate either through an HSM, you can pull public keys again, or you generate new server keys through the API. And the server gets the private key for that. The public key goes to TDI because again, TDI is verifying in real time that that server is valid. And it literally is just a copy, paste of the public key into the dashboard. Provisioning devices is just as easy. You generate a private public key pair, if it's got a TPM, TE, secure element, you literally just grab the public key, paste in the dashboard, it's now authorized. And then the public key goes to TDI through that dashboard. So this is the main workflow. So I'm going to take you through it one more time. I talked about it, but seeing it visually makes it a little easier to understand. So here in step one, that server generated a request. It signs with its identity that is only used by it. It sends the message to TDI. And TDI will validate if that fleet, that server is valid for the fleet. And again, if it's not, it will kill that request immediately. If the request is valid, it signs with its private key and now sends it back to the server. The server now can grab the private key from the HSM. And now you've got three signatures on it. The private key for the fleet, the private key for TDI, and the private key for the server. And when that request goes down to the device, the device only looks at two. It could care less about the server. It ignores it completely because it just knows that the server is authorized. It has the public key for TDI and is the public key for the fleet and that's all it cares about. The code on the device verifies those two signatures and it accepts the message whatever it says. This means that you can't side load requests of, you know, side load firmware and devices using medical device programmers. If you put that on there and when they want to communicate, they have to go and get authorization first. So this stops a lot of the attacks. Well, let's be realistic. This is not a silver bullet. This is not going to stop everything. There's nothing in security that stops everything. But that's not what this is about. This is about recovery. Because all we're talking about now is we have devices that are compromised that we can't do anything with, right? And we've got people compromising all these devices back here. How many times have we seen someone put a, you know, a card in a device, upload the firmware with no authorization, right? We saw it earlier yesterday. Device to server works a little differently. It actually passes through the server and the reason we do this is we don't want anyone to hijack that traffic. So it goes through the server, it passes it to TDI, we verify the signature, and then we pass it back. If that signature, if that device is invalid or something looks wrong, we kill that request. And again, this means we can revoke a device that's been compromised immediately. Now when we throw an application into the mix, it's a very similar workflow. All this adds is when you have the app, the app actually has its own identity as well. Because here everything gets an identity, the application can actually sign with its identity from the device. So the device has another request, it also gets signed with the app, and now you start knowing everything that's interacted. So if someone is using a different app or an app that doesn't look right, you can actually stop that request. Again it's all about making sure everything that you know in this chain is valid. Sending a message down to a device, right? Again we kind of went through this, but within there's an application involved, now you have the application signing as well before it gets down to the device. So that step gets added. So breach recovery, right? It's not if it's when. Breach recovery is really simple. You go into our dashboard, there's a list of all your servers and devices. You click on the device, you click pause, or you can click revoke. The difference here is if you want to do investigation and actually see if this is really an attack, you pause this device or server, and now it can no longer communicate but you can still see the messages come through. If you know that that device is in fact, or that server is in fact really compromised, you archive it and it's gone. It can no longer communicate. This is really interesting because we're going to show this in the demo. We generate an attack, I'm never going to stop the attack. I'm going to remove the attack because I'm going to remove the server's ability to communicate. And think about this from an administrative standpoint. You've lost access to your server. It's sending a request it shouldn't be sending, or someone's compromised that identity. The minute I revoke it from the dashboard, whoever has access to that server can't do anything. They can send out requests all day long. Each one of them is going to fail and you'll see them fail immediately. Alright, so I said we started with the idea that everything will be compromised. And I wasn't kidding. When I drew this out, I said, alright, what happens if someone hacks into all the servers, hacks into the co-signing service, hacks into the devices, everything is compromised. So when we generate a fleet, we generate these reset keys. There are three private keys. We recommend storing them on a USB drive. They are not stored online. The public keys for those three private keys are on every single device. When you generate a request, you also have two new public keys. A new public key for a fleet and a new public key for the co-signing service. This means if you've completely lost access to your environment, you can spin up a brand new environment, send a request down to your device, and your device will now point to that environment. This means disaster recovery if you've completely lost access. There's also another thing here. People use HSMs, but they don't think about what happens if the HSM dies. You can't get the private key out of an HSM, right? So it's a great idea. This is a really secure piece of hardware, but they didn't think about the part about what happens if that piece of hardware dies. So you need to generate a new, you have a new private key and a new HSM, and now you need to figure out how to recover your environment. So with this, all you have to do is send this request down, you grab the public key for the new HSM, you send it down to the device, the device now points to it. It becomes very simple. And again, it doesn't matter if you've locked access to the network, unless they're blocking everything from coming through, that message is still going to get to the device. So we're doing something different here. We're not pinning certs, right? We're not only pointing the device to the servers, right? We're pointing the device and the server they're authenticating, they're telling each other to authorize, they're not authenticating each other, but they're authenticating to the co-signing service, right? And the real-time revocation, there's no firmware updates to get this removed, right? Whether it's a server, whether it's a device, whether it's an app, you can yank it immediately. And this becomes really fast and easy for the knock of the sock to handle. So we call this the gravy because I didn't want to stop there. I wanted to make your life's living hell if you're a researcher. If you clone the devices, you know, this is something if you do red teaming, you drop devices in a network, it's really fun, right? But you usually don't drop a device on every segment of the LAN. So I came up with this idea that what if you actually put the code on the gateways as well and the gateway validates anything that's on that LAN segment? So if I sign a message with a device, I pass it to the gateway, the gateway validates that device in the message and now signs with its own identity. And now I do that again for the next gateway it goes through that I control. And now I do it again for the next gateway. And when that message gets to my server, now, do I not only verify the device message and the server or the gateway messages, I validate the order and the time stamp of them. So if you've hijacked a request, if you've cloned a device and you're not in that LAN segment, I'm going to notice, right? Is this going to stop every attack? No. Is it going to make it harder? Absolutely. So we can do this with apps, we can do it with gateways, we can do it with any of the things that are in your environment that you control. So when we get acquired by Neustar, the first thing I thought of is if you don't know Neustar, they have recursive DNS services and they have DDS scrubbing services. So this provides really interesting things for IoT devices. So let's think about Merai for a minute. You've got a bunch of devices with unauthenticated DNS that were pointed to a site and sending tremendous amounts of traffic. Well, at some point that traffic is going to get too much to push off and scrub elsewhere. What if you could actually do authenticated whitelist and blacklist on the device and stop the attack at the edge? That's one of the things working out for this. It's essentially to use TDI to sign those requests so that if you get a device or a bunch of devices that tell you, hey, by the way, we're being directed to this site, you can actually take that information in, push that back down to all the rest of the devices and depending on if it's server relay or point to point, block that site or allow different sites to be accessed. That means anything that was a command and control server that you had access to before can be blocked very quickly. And because we have some additional features that Newstar, we own 400 TLDs and we do that recursive DNS, we see things that we can push down to these lists. So that means we can protect these devices, which protects customers, but it also protects the average user. And that's the reason we're putting this out there because the device manufacturers are never going to pay for first security. I've been on both sides of it and convincing them to pay a nickel is not happening. But if we give them a framework that they can use to stop side load attacks, to stop DNS attacks, to stop denial of service attacks, maybe just maybe we can stop some of the stuff and get things to recover quickly. There's a couple other scenarios that we're working on. There was an auto manufacturer that came to us and said, hey, by the way, if we put that digital identity in our key fob and that car is underground, how do we make sure I can unlock my car? And I went, shit, that's probably a good idea. I don't want to be locked out of my $80,000 car when I can't do that. So there are scenarios where we would say you can actually allow a certain number of requests so that that key fob, even without access, but there's actually a more powerful option, which is that car now has a gateway. So if we locally replicate all the devices that are in that car, we can allow you to authenticate there rather than going out to the cloud. And there's another thing that goes along with this that was part of this one I originally designed it. If you start thinking about cars, not just other IoT devices, a car has about 100 ECUs, different processors that control everything. And if you look at Charlie's work when they loaded the Jeep, they basically took a USB drive and loaded malware into it, right, loaded an invalid image. What if you gave every single ECU its own identity within a car and had the gateway authorizing what ECUs were allowed to talk to other ECUs? Regardless if the car was offline or not, now you can stop attacks from a radio that affect my brakes. And if you want to set it up, we can have fleets within fleets. So you can actually say your Toyota, you can say to all your component manufacturers that they control the firmware to that component, but not to anything else. And then you can set up your relationships of what's allowed to talk to what. Assume that nothing is allowed to talk to anything until proven otherwise. Again, that's the basis of this. All right, so the demo. I will say that before I start this, I recorded this beforehand. And the reason is this takes five monitors to run. And I didn't think they'd have five projectors to get me to run it. But let me set this up for you so you understand what's going on here. In the top left corner, we like Legos around our office. So we built a Lego parking lot. We didn't automate the car, so there's some dental floss that you'll see. But essentially, we have three IoT sensors that are in the parking spaces. And when a car is in that space, it changes the color from green to red. So that way we know when there's a space open. In the bottom left-hand corner is a little mobile app that we built that just tells you what the status of those parking spots are. So if it's green, it's open. If it's red, it's closed. In the top right corner, and I know this projector is hard to see on it, is our dashboard. This is where you add devices, add servers, remove devices, remove servers. It's very simple. You'll see during this demo messages come through on the bottom. And then we revoke, and it immediately goes from green to red. And so that brings up this bottom right corner. This is the logs that are being tailed. Right now you see a valid result here. This is the parking lot sending a message just saying, this is the status. We're going to see those keep on going green. Every couple seconds, they're going to keep on sending requests through. And at some point on the top, you're going to see us revoke a server and you'll watch the next request turns red. But before we do that, in the bottom right corner, you're going to see another window pop up. It's an injection attack that we're running. We're spoofing the identity of server number one. So in the top left, if you look at the top right of the top left, there's two Raspberry Pi's there. Those Raspberry Pi's are acting as servers for the parking lot. And remember what I told you, you can remove all your servers. So server two isn't really set up right now. It's only server one. So what you're going to see us do is we're going to remove server one so it has no access to communicating anymore. And we're never going to stop that attack. And then you'll see everything go red. We'll add server two in and now you'll see everything turn back to green. It's a very quick demo. I try and draw it out because it's a lightweight piece of code and it works really fast. But let me take you through it. So you got valid results here. We're going to use our magic to pull this string and pull that car in. And now you see the status of it change. So they're all red. You'll see the bottom right. There's another window that's going to come up in a second, which is when we generate the attack. But I wanted to draw it out so I let it go valid. Here's our attack executing right now. And on the left hand side on the bottom, watch those colors. They're going to start flashing as it's changing the status request. The cars aren't moving at all, but yet all those cars, their status is changing for the parking lot. And in a second in the top right, you're going to see me revoke the server. I said it's a very quick thing. You click on it and you remove it. So we find the server in the list, click on it, remove its access, verify it and the next message is red. That server no longer has access, but we have not stopped the attack. The attack's still running because that attacker still has access to that server. And it will fail as long as that server is trying to send messages and is not validated to be in the fleet. Now we're going to add a new server back, server two, and you'll watch that request immediately go green. And that's TDI. See, we're of the belief that if you build things to fail, right? Assume that everything is failing. You can actually start putting security people back in control so that they can make the decisions that they know are true, right? Don't rely on users to make these decisions. So let's talk about the code. Some of the code has already been released. It's on our GitHub repo. We have a Python library up there. We are actually in the process of being acquired right now. So there was a little bit of delay in the rest of the code being audited. As soon as that's audited, it will be up here. You'll notice that the documentation says one ID. That was the name of the company before we got acquired. So we just hadn't changed that URL. But our documentation is up there and we are constantly updating it. If you want some more information on our site, there's a Bitly link. It's new star TDI. It's case sensitive. It's got some information on my white paper. And we also have an email address if you have questions about it. We are going to be allowing other people to contribute to this. We are gonna control that for now to make sure that things, a bad code isn't being put in there and people aren't breaking things. But as I said, the Edge Foundry Dell Project, we're gonna be contributing our code as part of that. So this is our phase two. I have six phases of this. The team doesn't even know the rest of them yet. There's a lot of things that we wanna do to build a secure framework for IoT. We'd love to hear feedback from you guys. We come from research backgrounds, right? We've attacked these devices. We're trying to make something to defend it to make it harder for us to do our job as attackers and easier for the people to do defense. I just wanna thank, there's a couple of people because when I had this idea, the one ID CEO came to me and said, hey, I wanna build this thing. And I'm like, actually, I'd like to build this thing. And Steve Kirsch, the founder and our CEO said, go build that thing. That sounds really cool. And then Kali put all these videos together for me so I didn't have to get five projectors running for you guys, which makes my job up here a little easier. The other thing is that I literally put this out to any researcher that I knew on Twitter and went through the model. We want more eyes on it because you don't build security in a vacuum. The whole point of this is to help all of us get things more secure rather than just breaking things. So if you'd like to contribute, if you'd like to help look at threat models, we'd love to have your help. Questions? So that's a good question. Here's the thing, on a small instance Amazon server, we can do 100,000 requests, like verify signatures a second. So if you think of a latency standpoint, either from a device, the device is a lot slower than a cloud-to-cloud communication. So we can put this wherever your devices are. Obviously we want it in a different rack so that it's locked off from a threat model perspective. We want different credentials to it, but we can deploy it anywhere. So the whole idea is that request coming down from the server, it's validated through our server. It's a very quick turnaround. It's much faster than a CRL lookup. And it's gonna obviously depends how big the CRL list is and you know, but you're cutting down the time significantly. And sorry, go ahead. So I didn't, you know what, thank you. I appreciate you. So I didn't talk about rotation, right? I said about a rotation meeting or problem. You can basically go in here and re-key very easily. So you would just generate new keys, you'd pop them in there and you'd just put them on the server. Could you do automated re-keying? Yes. At the time when we started building the framework, I just had to choose what was important to build at the time. That's why I said there's six phases total. There were certain things that we just didn't wanna focus on because I wanted the development team to make sure they were focusing on the authentication authorization part. But yeah, certainly we could, you know, do automatic. Absolutely, yeah. But it also, even with this, it's really easy because you generate a set of keys. You can write a script to push those out to the server and put the public key up there. I don't necessarily consider it the hard part, but it's an important feature. Actually one of our developers is sitting in the back, so I'll have them put that in. Very good question. Yeah, so that's a good question. The question was about would it work for EMS, right? Oh, TLS, oh, I'm sorry, I thought you said EMS. But that works also. Here's the thing, it's protocol agnostic. So there are other things that we're looking at using it for. You can sign any protocol with this. We sent on top of it. The reason was I didn't want to have someone, if they had transport encryption, to have to use whatever we had. So you could actually use this for NTP. You could use it for DNS. You could use it for TLS. There's no reason why we couldn't write the signatures on top. Well, you'd provision a server, yeah. But the server would then be in the TDI. So you would just authorize it there. So you could do it the same way. And again, this allows you to remove them at them, whatever. Well, that's, so the question was, are we just shifting the area to TDI? And no, because you need both keys. So if TDI is compromised, you can replace it instantly. Whereas in a root cert, in a CA, you have to revoke it, which means you have to firmware up the device. In our case, we can generate a request and push the public key that points to TDI instantaneously. It has to check both sigs or it can't do anything. And that's the power of it. So you could hack the server. You could hack TDI. Are you going to hack them both at the same time when they have different credentials and they are run by different people? Again, it's possible. It's just not probable. And if you do, then you can revoke and replace. So the whole thing is recovery. How fast can you recover? How can you make sure you're working on your roadmap? Any other questions? Yeah, it's really small. Whereas I'm going to defer to Ian for a second. If you, Ian's back here. He's one of our developers. It's pretty, yeah, go for it. Yeah, so it's pretty lightweight. Questions? Cool, thank you guys very much. I'll just say one more thing. So we designed this. This isn't the be all and end all. The whole idea here is sort of a mentality shift. Don't rely on the router if you're building these devices. Make sure your security is self-contained for the device you're building. Trust nothing until proven otherwise all the time. And make sure the people who actually know about security are the ones who can do something about it. So put your knock and sock back control, not users, not site managers. Thanks.