Everyone welcome. Next up, our next speaker is Brian 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 about my background so you 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 shouldn't. 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 New Star in August. We started as
OneID. And it was a team of five of us building this framework for IoT devices. The idea was we were tired of popping shell
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. But let's take the Philips Hue as a great example. One of the things that happened to the Philips Hue was the TAC was using the
hub to generate traffic and send requests to the light bulbs, right? Unauthenticated. Not surprising. One of the things
is as a researcher, as an attacker is cloning the device. It's usually fairly simple. We're being on the same LAN 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 search got taken. DigiNotar, which isn't even on there. Oh, it actually is on there. Sorry. It got
completely taken. DigiNotar, which isn't even on there. Oh, it actually is on there. Sorry. It got completely taken. DigiNotar, which isn't even on there. Oh, it actually is on there. Sorry. It got
completely taken. DigiNotar, which isn't even on there. Sorry. It got completely taken. DigiNotar, which isn't even on there. Sorry. It got completely passed over. So we're
completely Amplified. 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 Wemo 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
support IoT. So we can't do anything until they update. And it occurred to me, the people who
are doing it, they're not going to be able to do it on a 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 we could be able to do something
like this? And the answer to that is 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 what we're going to do is we're going to go ahead and
do this. 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
people 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 of 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 computer and see if I could
hack 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. So we had a lot of
issues with that, 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 on your
LAN, it's allowed to be looked at. And not only should you check that, but you should also 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 on an 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 AppSec team is going to be, at some point, it's
going to be 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 AppSec teams were not doing. But we still got a
private key exposed from a third-party library. 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, we were able to get it out of the system. And we were able to
get it out of the system. And we were able to get it out of the system. And we were able to get it out of the system. And we were able to get it out of the system. And we
prepare tricks on prices, but we were actually snow cr globally, somewhere around $2,000 off of our
competitors had newer products on. So how do you make sure you can work on apopt on be
roadmap? Not sit there maintaining compromised environments. And that's really
compromise environments. And that's really what this is about. I should say as part of this
apologize Ungates added We partnered up with Dell in the
Linux Foundation. There's an the Linux Foundation. And the will be released under the
Let's open aойt- Gemeent in our network lab, do smart searching this code to build security dist пожалуйста
secure IoT framework. So it's going to be released under the Apache 2.0 license. And the idea is to let
secure IT devices or 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 me 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'll get very clear.
Every single device has its own identity.
That identity could be a secure element or TPM or TEE, but it has its own identity.
And because that identity is used to communicate with the servers.
But it also has the public key.
And the public key is the 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, the third key is the reset key.
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 talk 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 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,
TPM, TEE makers to do the same thing.
So if the device already has a provisioned identity, great.
If not, we can generate that.
That'll 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 our real-time verification.
And it 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 and 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 that, 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.
I've been in 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.
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, an API, and a UI.
So most likely people would integrate this 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 search
but it still allows the request.
So this allows us to do the real work.
It's a 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.
When you're using PKI with CRL and shared server keys,
one server is compromised, every single server is compromised.
And any time you add a server, you've had to add that public key to every device
and every server that can communicate with it.
That's a big problem 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
that can't have a constant flow of updates.
They have other things, streams of data that they want to send.
Now when you have individual servers' keys, it gets even worse.
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 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.
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, you start to overload these devices
with every public key that they need to have access.
So if you think of what's happening today with attacks,
CryptoLocker, 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,
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, that need to be rekeyed.
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 1,000 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?
Knock, sock, 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, or 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 remove servers, add or remove devices, right?
This would be your knock, 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 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 it 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 generates 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 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 it has 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 sideload requests of,
you know, sideload 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.
But 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 that 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 if 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 in 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 a 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 when 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.
Or you can click revoke.
The difference here is
if you want to do an 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.
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.
This is 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 lost 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.
We're not only pointing the device to the servers.
We're pointing the device and the server
they're authenticating,
they're telling each other they're authorized,
they're not authenticating each other,
but they're authenticating to the cosigning service.
And the real-time revocation.
It's to get this removed.
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 on 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 a 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?
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
and 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 gateway messages,
I validate the order
and the timestamp 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.
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,
So when we got acquired by NuStar,
the first thing I thought of is,
if you don't know NuStar,
they have recursive DNS services
and they have DDoS scrubbing services.
So this provides really interesting things
for IoT devices.
So let's think about Mirai 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
so you're going to have to put a blacklist
on the device
and stop the attack at the edge.
That's one of the things we're working on 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.
So 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 NuStar,
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 device manufacturers
are never going to pay for 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 sideload attacks,
to stop DNS attacks,
to stop denial of service attacks,
maybe, just maybe,
we can stop some of this 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 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
when I originally designed it.
If you start thinking about cars,
not just other IoT devices,
a car has about 100 ECUs,
different processes that control everything.
And if you look at Charlie's work
when they loaded the Jeep,
they basically took a USB drive
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 affects 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.
So you have to understand
the relationships of what's allowed to talk to what.
Assume that nothing's allowed to talk to anything
until proven otherwise.
Again, that's the basis of this.
Alright, 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.
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 of 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,
right of the top left,
there's two Raspberry Pis there.
Those Raspberry Pis 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 communicate 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.
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've 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.
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.
Remove 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 is 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.
That's server 2.
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
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.
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 1ID.
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 bit.ly 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 going to control that for now
to make sure that 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 going to 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 want to do
to build a secure framework for IoT.
We'd love to hear feedback from you guys.
We come from research backgrounds.
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 want to thank just a couple of people
because when I had this idea
the OneID CEO came to me
and said, hey I want to 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 Callie
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.
It's really cool.
The other thing is that you don't build security in a backroom.
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 in a second.
So if you think of a latency standpoint
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 obviously depends
how big the CRL list is
but you're cutting down the time significantly.
Sorry, go ahead.
So I didn't
thank you, I appreciate it.
I didn't talk about rotation.
I said about rotation being a problem.
You can basically go in here and rekey 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 rekeying? 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 want to focus on
because I wanted the development team to make sure
they were focusing on the authentication and authorization part.
But yeah,
certainly we could do automatic.
As you scale it, it's a lot more important, right?
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 that the hard part
but it's an important feature.
Actually one of our developers is sitting in the back
so I'll have him 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.
So there are other things that we're looking at using it for.
You can sign any protocol with this, right?
We sit 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 doesn't do that.
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, add them, whatever.
So the question was are we just shifting
the area to TDI?
And it's 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 update 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,
with different credentials,
and they're 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?
It's really small, whereas
I'm going to
refer 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...
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.
The people who actually know about security
are the ones who can do something about it.
So put your dock and sock back in control.
Not users, not site managers.
Thanks.