1
00:00:00,000 --> 00:00:07,900
Everyone welcome. Next up, our next speaker is Brian Knopf. Awesome, okay. And he is giving

2
00:00:07,900 --> 00:00:13,700
his talk on redesigning PKI, you know, because IoT crypto is hard.

3
00:00:21,600 --> 00:00:26,860
Thank you. So I was going to joke and put up the camera because every time I've told

4
00:00:26,860 --> 00:00:32,860
people the topic, I get this look and it's been a running joke all week, like redesigning PKI

5
00:00:33,420 --> 00:00:40,040
because everyone uses it, right? So a little bit about my background so you understand kind of

6
00:00:40,040 --> 00:00:44,800
where I'm coming from in this. A lot of those devices sitting on the table over there are ones

7
00:00:44,800 --> 00:00:50,200
I've designed. So I used to run security for Linksys and Belkin and just because that means

8
00:00:50,860 --> 00:00:54,600
there's vulnerabilities doesn't mean we didn't know about them. And then I left and went to

9
00:00:54,600 --> 00:01:04,140
Wink. So my focus has been IoT for about five or six years. And this really is research based on

10
00:01:04,140 --> 00:01:14,940
my work in defense and attack and getting tired of getting owned when I shouldn't. So I'm going to

11
00:01:14,940 --> 00:01:20,720
take you through kind of what this TDI framework is and then kind of explain the keys and the

12
00:01:20,720 --> 00:01:24,180
terms because trust me, you'll need a roadmap for the keys.

13
00:01:24,600 --> 00:01:28,520
And then I've got a demo at the end and you'll get a real good sense of what we're talking about

14
00:01:28,520 --> 00:01:36,820
here. So what is TDI? So it stands for trusted device identity. This is a framework that I started

15
00:01:36,820 --> 00:01:45,120
designing on my living room floor. And it was acquired by New Star in August. We started as

16
00:01:45,120 --> 00:01:54,480
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

17
00:01:54,600 --> 00:01:59,880
and breaking things and thought we should actually start fixing things and making it harder to break

18
00:01:59,880 --> 00:02:11,480
these devices. So what happened? And I joke, what didn't happen? So some of these headlines look

19
00:02:11,480 --> 00:02:15,900
familiar because some of them are on things that I worked on, some of them are on things that were on

20
00:02:15,900 --> 00:02:24,560
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

21
00:02:24,600 --> 00:02:34,380
hub to generate traffic and send requests to the light bulbs, right? Unauthenticated. Not surprising. One of the things

22
00:02:34,380 --> 00:02:41,800
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

23
00:02:41,800 --> 00:02:54,580
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

24
00:02:54,600 --> 00:03:02,760
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

25
00:03:02,760 --> 00:03:13,480
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.

26
00:03:14,000 --> 00:03:24,360
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

27
00:03:24,360 --> 00:03:24,580
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

28
00:03:24,600 --> 00:03:26,940
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

29
00:03:26,940 --> 00:03:35,480
completely Amplified. So you have this party that's putting keys and someone has access to get root cert on

30
00:03:35,480 --> 00:03:46,100
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

31
00:03:46,100 --> 00:03:54,300
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

32
00:03:54,300 --> 00:04:01,100
the Wemo products at Belkin, one of our developers dropped a private key for some reason on the

33
00:04:01,100 --> 00:04:08,440
device during an update. And a researcher rightfully copied that key and made their own

34
00:04:08,440 --> 00:04:14,680
firmware. So now I have a half a million devices that are sitting in the wild waiting for users to

35
00:04:14,680 --> 00:04:20,100
update those devices. Because my knock and my sock are sitting there going, I'm compromised, we

36
00:04:20,100 --> 00:04:24,880
can't do anything until they update. And it occurred to me, the people who actually understand

37
00:04:24,880 --> 00:04:29,400
the security aren't the ones in control anymore. And they're waiting on these users to do all

38
00:04:29,400 --> 00:04:39,100
these things rather than letting them control it. So this kind of got me thinking, let's

39
00:04:39,100 --> 00:04:44,360
completely think about the way we do PKI and how it doesn't work at all for IoT. Now this really

40
00:04:44,360 --> 00:04:49,920
can be applied to other things, but in the IoT sense, IoT, PKI and IoT does not

41
00:04:49,920 --> 00:04:50,080
support IoT. So we can't do anything until they update. And it occurred to me, the people who

42
00:04:50,100 --> 00:04:57,140
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

43
00:04:57,140 --> 00:05:02,980
before, you know that I sort of live the IoT space. My house has 130 IoT devices in it. Every

44
00:05:02,980 --> 00:05:08,720
single light bulb, door lock, window sensor, my pool, everything in my house is connected. And the

45
00:05:08,720 --> 00:05:14,360
reason is, I don't think you can actually solve a problem unless you live the problem. And so I do

46
00:05:14,360 --> 00:05:19,980
research on a full-time basis in my house on everything that goes across the network. And

47
00:05:19,980 --> 00:05:24,800
yes, that requires some enterprise gear for switching because of the bandwidth, but it also

48
00:05:24,800 --> 00:05:29,880
lets me see things, relationships between devices that I wouldn't otherwise see. So when I

49
00:05:29,880 --> 00:05:34,680
started this, I grabbed a ream of paper and sat on my floor. And I drew out a threat model for

50
00:05:34,680 --> 00:05:40,000
every single device I had ever attacked, defended, or worked on, or anything that I had ever

51
00:05:40,000 --> 00:05:46,540
seen other researchers, some of which I see in the audience, had worked on. And I started to

52
00:05:46,540 --> 00:05:49,960
think is, what would we need to do to design this so that we could be able to do something

53
00:05:49,960 --> 00:05:54,080
like this? And the answer to that is that the minute that attack happens, I can recover,

54
00:05:54,940 --> 00:05:59,480
regardless of what that attack is. If that attack is on the app, the user, the server, any of

55
00:05:59,480 --> 00:06:05,960
those things, I revoke it because I'm in control, and now I'm recovered. Now, of course, that

56
00:06:05,960 --> 00:06:09,520
means you have to patch or fix whatever vulnerability that is, but as fast as you can spin up

57
00:06:09,520 --> 00:06:14,260
that system, you'd be allowed to remove it. And we're going to show you this in the demo. It

58
00:06:14,260 --> 00:06:19,940
literally is a one-second revoke. So what we're going to do is we're going to go ahead and

59
00:06:19,960 --> 00:06:24,380
do this. So we know crypto is hard. We know that developers like anyone else make mistakes,

60
00:06:24,780 --> 00:06:30,100
right? Whether they're trying to, you know, mess around with PKI or not, it becomes very

61
00:06:30,100 --> 00:06:37,600
difficult to get it right. What if we made it easier? Right? And that's kind of the idea.

62
00:06:39,040 --> 00:06:43,780
And I'll give you one more story. I worked at a company called Wink. I was there three

63
00:06:43,780 --> 00:06:49,460
months, and I got a call on a Saturday morning as I was hanging out with my kids that all the

64
00:06:49,960 --> 00:06:55,440
people on the East Coast had just disconnected. And so we had about 50,000 devices and

65
00:06:55,440 --> 00:07:00,320
about 30-something thousand had disconnected already and had three hours to save the West Coast

66
00:07:00,320 --> 00:07:09,720
devices. Now, show of hands in here, who has dealt with an expired cert? So the sad thing is

67
00:07:09,720 --> 00:07:15,860
that everyone has an expired cert story, right? And this should never, ever happen, right? So I

68
00:07:15,860 --> 00:07:19,940
was asked at an early hour in the morning to try and hack back into my computer and see if I could

69
00:07:19,940 --> 00:07:26,780
hack into my device to recover those devices and fix them. Luckily, NTP is awful and so is DNS,

70
00:07:27,080 --> 00:07:33,060
and so we injected a DNS entry for a fake NTP server and set time back to fix some of those

71
00:07:33,060 --> 00:07:38,460
devices. But the ones we didn't fix got even worse because they had completely disconnected

72
00:07:38,460 --> 00:07:45,360
from the network. So we went to Best Buy, Amazon, and Lowe's and everyone else, had them box up

73
00:07:45,360 --> 00:07:49,920
every device, ship it to a warehouse, and had the entire team flashing firmware. So we had a lot of

74
00:07:49,920 --> 00:07:54,140
issues with that, including the users. This is not exactly something you ever want to happen or

75
00:07:54,140 --> 00:08:02,580
see happen again. All these things led me to say, okay, PKI sucks. We get this. So what do we need

76
00:08:02,580 --> 00:08:10,240
it to do? Trust nothing, right? Don't assume that your network is your security model. And I

77
00:08:10,240 --> 00:08:14,800
can't tell you how many times I look at a device and they've just assumed that if it's on your

78
00:08:14,800 --> 00:08:19,900
LAN, it's allowed to be looked at. And not only should you check that, but you should also check

79
00:08:19,920 --> 00:08:24,520
that, but make sure you check it again and again for every single request. And that way you can do

80
00:08:24,520 --> 00:08:31,700
real-time revocation. Key rotation should not be this massive effort. If you've ever done key

81
00:08:31,700 --> 00:08:36,440
rotation on an IT team, they plan for it, they test for it, it's a weekend effort or a night-long

82
00:08:36,440 --> 00:08:42,960
effort. It's not some easy thing. It should be a five-minute effort, right? So how do we make

83
00:08:42,960 --> 00:08:49,900
that? And plan for complete failure. As good as your AppSec team is going to be, at some point, it's

84
00:08:49,920 --> 00:08:54,660
going to be a third-party library that's going to own you. It happened to me, right? We were

85
00:08:54,660 --> 00:09:00,740
fuzzing protocols. We were doing things that other AppSec teams were not doing. But we still got a

86
00:09:00,740 --> 00:09:06,740
private key exposed from a third-party library. So when that happens, not if, how do you recover

87
00:09:06,740 --> 00:09:11,540
and how do you recover fast? Because when it happened to us, we spent six months cleaning it up,

88
00:09:11,640 --> 00:09:16,560
which meant we didn't ship a whole product line. That product line literally went in a dumpster,

89
00:09:17,160 --> 00:09:19,440
because by the time we were able to ship, we were able to get it out of the system. And we were able to

90
00:09:19,440 --> 00:09:19,900
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

91
00:09:19,900 --> 00:09:20,360
prepare tricks on prices, but we were actually snow cr globally, somewhere around $2,000 off of our

92
00:09:20,360 --> 00:09:25,600
competitors had newer products on. So how do you make sure you can work on apopt on be

93
00:09:25,600 --> 00:09:30,160
roadmap? Not sit there maintaining compromised environments. And that's really

94
00:09:30,160 --> 00:09:33,260
compromise environments. And that's really what this is about. I should say as part of this

95
00:09:33,260 --> 00:09:35,560
apologize Ungates added We partnered up with Dell in the

96
00:09:35,560 --> 00:09:40,040
Linux Foundation. There's an the Linux Foundation. And the will be released under the

97
00:09:40,040 --> 00:09:41,720
Let's open aойt- Gemeent in our network lab, do smart searching this code to build security dist пожалуйста

98
00:09:41,720 --> 00:09:47,480
secure IoT framework. So it's going to be released under the Apache 2.0 license. And the idea is to let

99
00:09:49,900 --> 00:09:57,080
secure IT devices or anyone who wants to work on those. So let's talk about some key terms

100
00:09:57,080 --> 00:10:02,140
really quick because this will help you understand it. So a fleet, think of a fleet as any SKU.

101
00:10:02,360 --> 00:10:07,000
So just pick a device back there, right? You consider that a fleet. And the idea of the fleet

102
00:10:07,000 --> 00:10:11,640
is just it's a rubber band around things that are allowed to communicate on behalf of the fleet.

103
00:10:12,340 --> 00:10:17,900
So each fleet server is just anything, whether it's a connection server, a content server,

104
00:10:17,900 --> 00:10:22,120
a firmware update server, that you want to be able to sign on behalf of that fleet.

105
00:10:24,220 --> 00:10:29,340
The co-signing service is the heart of what TDI is. And the idea is that in real time,

106
00:10:29,600 --> 00:10:33,180
those servers are validated to make sure they're still valid for the fleet.

107
00:10:33,780 --> 00:10:39,780
This means when you revoke one, it's gone. Not in a little while, not the public key being removed

108
00:10:39,780 --> 00:10:44,860
from the device, it is gone instantly. And it's a one second thing, which means you can remove

109
00:10:44,860 --> 00:10:47,560
all your servers, every single server.

110
00:10:47,900 --> 00:10:53,620
From your pool, put new servers back, and the next request goes through. And the reason is

111
00:10:53,620 --> 00:10:57,800
because we separate out authentication and authorization. And think of how this works

112
00:10:57,800 --> 00:11:03,700
with IoT devices. You've got a smart car and it's in front of me driving. You stop your car

113
00:11:03,700 --> 00:11:09,000
really fast. And my smart car needs to slow down and know that your smart car stopped.

114
00:11:09,560 --> 00:11:14,820
I don't need to know anything about you. I just need to know that you're authorized to talk to me.

115
00:11:15,320 --> 00:11:17,760
Not that I authenticate directly to you.

116
00:11:18,560 --> 00:11:21,680
And the devices, of course, are just the IoT devices that are connecting.

117
00:11:23,560 --> 00:11:26,920
So there's a lot of keys here. And let me explain what's going on.

118
00:11:27,560 --> 00:11:30,500
I know it looks confusing, but I promise it'll get very clear.

119
00:11:31,020 --> 00:11:34,200
Every single device has its own identity.

120
00:11:34,900 --> 00:11:40,660
That identity could be a secure element or TPM or TEE, but it has its own identity.

121
00:11:41,360 --> 00:11:44,320
And because that identity is used to communicate with the servers.

122
00:11:45,140 --> 00:11:47,440
But it also has the public key.

123
00:11:47,900 --> 00:11:48,680
And the public key is the key for two things.

124
00:11:48,960 --> 00:11:51,680
The fleet and the co-signing service.

125
00:11:52,200 --> 00:11:56,980
And the reason it doesn't need to know a server is because all it needs to know is those two public keys.

126
00:11:57,960 --> 00:12:01,000
And that allows it to know that it's authorized to speak to that server.

127
00:12:03,240 --> 00:12:06,280
We also create these reset keys. And I'll go into them a little bit.

128
00:12:06,480 --> 00:12:09,340
But remember when I said everything will be compromised?

129
00:12:09,900 --> 00:12:12,520
Well, we have a way of recovering when everything is compromised.

130
00:12:12,940 --> 00:12:15,180
It's not probable, but it is possible.

131
00:12:17,040 --> 00:12:17,880
And finally, the third key is the reset key.

132
00:12:17,880 --> 00:12:18,860
And finally, we have the co-signing service.

133
00:12:19,240 --> 00:12:23,180
So for every fleet, we create a new private-public key pair.

134
00:12:23,500 --> 00:12:26,900
So that if one fleet is compromised, other fleets are not compromised.

135
00:12:30,440 --> 00:12:33,220
So as I said, when we're talking about identities for the device,

136
00:12:33,680 --> 00:12:37,860
one of the things we're doing is tying the actual hardware to the firmware.

137
00:12:38,320 --> 00:12:41,880
And if you ever talk to a researcher who works on IoT, one of the first things they do,

138
00:12:42,040 --> 00:12:44,840
they look for the OAuth tokens, they're looking for the identity,

139
00:12:45,080 --> 00:12:47,440
so they can put it into Burp Suite and start

140
00:12:47,880 --> 00:12:48,700
pretending to be that device.

141
00:12:49,360 --> 00:12:51,180
What if you pulled the hardware identity?

142
00:12:51,500 --> 00:12:56,040
What if you did a firmware checksum to make sure that the digital identity you assigned to it

143
00:12:56,040 --> 00:12:58,580
was actually tied to the hardware identity?

144
00:12:59,040 --> 00:13:03,160
Now you actually know that the device you're talking to is the device you're talking to,

145
00:13:03,280 --> 00:13:04,220
and not a researcher.

146
00:13:05,600 --> 00:13:08,620
So we've partnered with Intel on their EPID identities,

147
00:13:08,900 --> 00:13:11,860
and we can use that EPID identity and pick up the public key,

148
00:13:12,000 --> 00:13:14,140
and now that becomes the identity of the device.

149
00:13:15,040 --> 00:13:17,200
We've also talked to other secure element,

150
00:13:17,200 --> 00:13:19,460
TPM, TEE makers to do the same thing.

151
00:13:19,740 --> 00:13:22,500
So if the device already has a provisioned identity, great.

152
00:13:22,620 --> 00:13:24,140
If not, we can generate that.

153
00:13:24,820 --> 00:13:25,840
That'll be in the firmware.

154
00:13:26,060 --> 00:13:28,780
Obviously it would be more secure to be in a hardware root of trust.

155
00:13:31,400 --> 00:13:34,860
And again, these fleet servers are verifying anything within there.

156
00:13:35,020 --> 00:13:39,420
So the fleet server is given the authorization to speak on behalf of the fleet.

157
00:13:39,680 --> 00:13:41,760
And I'll show you the workflow and how that works,

158
00:13:41,840 --> 00:13:43,860
and it'll make sense once I do that.

159
00:13:44,480 --> 00:13:47,020
So here's what we're talking about as far as components.

160
00:13:48,260 --> 00:13:49,620
We've got the co-signing engine.

161
00:13:49,780 --> 00:13:51,180
This is our real-time verification.

162
00:13:51,820 --> 00:13:53,960
And it has some additional things that I'll get into,

163
00:13:54,120 --> 00:13:56,700
but the heart of it is verifying in real-time.

164
00:13:57,620 --> 00:13:59,000
And revoking in real-time.

165
00:13:59,580 --> 00:14:02,120
The client app has a lightweight piece of code,

166
00:14:02,220 --> 00:14:05,200
and that code is used to verify and generate signatures.

167
00:14:05,920 --> 00:14:09,460
So any message and every single message has a signature on it.

168
00:14:10,220 --> 00:14:11,840
The fleet server gets the same thing.

169
00:14:11,940 --> 00:14:13,840
It gets a lightweight piece of code that goes on it,

170
00:14:13,900 --> 00:14:16,980
so it can generate messages when it wants to send firmware,

171
00:14:17,200 --> 00:14:18,800
or content, or anything down to the device.

172
00:14:19,620 --> 00:14:22,500
And then that same thing would go on any client app,

173
00:14:22,660 --> 00:14:24,740
any gateway, or any device.

174
00:14:25,140 --> 00:14:27,580
And I'll show you why I said gateway, not just app.

175
00:14:30,740 --> 00:14:31,820
Everyone wants to know the tech.

176
00:14:31,980 --> 00:14:33,520
So this is the P256 curve.

177
00:14:33,800 --> 00:14:36,300
Now I really wanted to use ED25519,

178
00:14:36,740 --> 00:14:39,620
but what you find out is that some of the low-power IoT devices

179
00:14:39,620 --> 00:14:40,740
don't actually support it.

180
00:14:40,960 --> 00:14:43,480
So when I sat down with NXP and other chip manufacturers

181
00:14:43,480 --> 00:14:45,280
to find out what chip supported this,

182
00:14:45,280 --> 00:14:48,620
we ended up going a little lower in the encryption than we wanted.

183
00:14:49,580 --> 00:14:52,400
But if you look at it, it's not the encryption that's usually broken.

184
00:14:52,600 --> 00:14:55,020
So this isn't going to be something that's a big problem for us.

185
00:14:56,020 --> 00:14:58,580
The other part of that, and one of our developers is back there,

186
00:14:58,700 --> 00:15:01,440
is asking developers to rewrite their stack

187
00:15:01,440 --> 00:15:04,120
is something that's usually not easy to do.

188
00:15:04,400 --> 00:15:07,520
So we wanted to do code implementations in every language

189
00:15:07,520 --> 00:15:08,880
that developers were working in,

190
00:15:08,920 --> 00:15:11,520
so that whatever they were using, they could use our library.

191
00:15:13,040 --> 00:15:14,700
So we have a bunch.

192
00:15:14,700 --> 00:15:16,800
Python, C, Node, Java.

193
00:15:17,160 --> 00:15:19,940
We have a Docker container that we just made two days before,

194
00:15:20,100 --> 00:15:21,640
so I didn't get a chance to put it in there.

195
00:15:21,940 --> 00:15:24,220
And we've got some other implementations on the way.

196
00:15:25,300 --> 00:15:28,900
The other thing is IoT devices don't have a whole lot of space.

197
00:15:29,500 --> 00:15:31,220
If you've ever built an IoT device,

198
00:15:31,380 --> 00:15:32,800
rather than just playing around with them,

199
00:15:32,980 --> 00:15:37,060
what you'll find is sometimes we didn't have even room to put SSL libraries in.

200
00:15:37,240 --> 00:15:39,320
And I know that sounds really strange, but it's true.

201
00:15:40,680 --> 00:15:43,280
I've been in places where we were stripping text off pages

202
00:15:43,280 --> 00:15:46,640
to try and make enough room to put the SSL libraries in.

203
00:15:46,960 --> 00:15:48,600
As ridiculous as that sounds.

204
00:15:49,840 --> 00:15:52,000
So we've got it down to 100 kilobit.

205
00:15:53,360 --> 00:15:55,340
It's about 32K of RAM.

206
00:15:55,620 --> 00:15:58,860
It's a very lightweight thing that runs on the device in the gateway.

207
00:15:59,260 --> 00:16:02,840
And we also have a CLI, an API, and a UI.

208
00:16:03,180 --> 00:16:08,220
So most likely people would integrate this with their sim,

209
00:16:08,480 --> 00:16:09,980
with their other dashboards.

210
00:16:10,120 --> 00:16:11,680
We have a dashboard to evaluate it.

211
00:16:11,680 --> 00:16:13,720
So if you're going to build your own implementation.

212
00:16:14,060 --> 00:16:16,940
But the idea is give you data however you need to take that data.

213
00:16:19,080 --> 00:16:22,000
So let's explain the difference between PKI and TDI.

214
00:16:22,840 --> 00:16:23,980
And it's really simple.

215
00:16:24,700 --> 00:16:29,100
In PKI model, you want to send a firmware update down to a device.

216
00:16:29,560 --> 00:16:32,200
The server generates a request, sends it down to the device,

217
00:16:32,400 --> 00:16:35,860
and now you're asking that device to do a lookup on a CRL.

218
00:16:36,160 --> 00:16:38,060
Now those CRLs can get really long.

219
00:16:38,660 --> 00:16:39,960
They take a long time.

220
00:16:39,960 --> 00:16:43,360
And you're asking the lower power device to do that.

221
00:16:43,960 --> 00:16:50,620
With TDI, we turn that around and say the server actually requests to TDI

222
00:16:51,720 --> 00:16:53,500
to make a request to the device.

223
00:16:53,840 --> 00:16:57,400
And TDI validates that server to make sure it's still part of the fleet.

224
00:16:57,820 --> 00:17:00,140
If it's not part of the fleet, we kill it.

225
00:17:00,900 --> 00:17:04,460
And this prevents an Apple fail condition where you have invalid search

226
00:17:04,460 --> 00:17:05,740
but it still allows the request.

227
00:17:07,300 --> 00:17:09,940
So this allows us to do the real work.

228
00:17:09,940 --> 00:17:13,320
It's a real-time revocation, adding all the servers back, removing servers.

229
00:17:13,620 --> 00:17:15,680
And again, I'll show you this in the demo how we do this.

230
00:17:17,960 --> 00:17:19,260
Now think about this for a minute.

231
00:17:19,380 --> 00:17:23,120
When you're using PKI with CRL and shared server keys,

232
00:17:23,800 --> 00:17:26,960
one server is compromised, every single server is compromised.

233
00:17:27,420 --> 00:17:31,720
And any time you add a server, you've had to add that public key to every device

234
00:17:31,720 --> 00:17:33,820
and every server that can communicate with it.

235
00:17:34,700 --> 00:17:38,420
That's a big problem because it's one thing when you're on a PC with a lot of power.

236
00:17:38,420 --> 00:17:42,920
When you're talking about an IoT device and you're talking about thousands of servers

237
00:17:42,920 --> 00:17:46,600
that can serve content to it, now you're talking about a lot of overhead

238
00:17:46,600 --> 00:17:48,480
that that device really can't handle.

239
00:17:48,840 --> 00:17:51,860
You're talking about lower power networks, lower bandwidth networks

240
00:17:51,860 --> 00:17:54,280
that can't have a constant flow of updates.

241
00:17:55,720 --> 00:17:58,360
They have other things, streams of data that they want to send.

242
00:17:59,040 --> 00:18:01,780
Now when you have individual servers' keys, it gets even worse.

243
00:18:03,660 --> 00:18:06,240
Now everything is getting a copy of everything.

244
00:18:06,440 --> 00:18:08,400
Every device gets a copy of every server's public key.

245
00:18:08,420 --> 00:18:11,840
Every server gets a copy of every other server's public key.

246
00:18:12,080 --> 00:18:15,220
And the problem here is, one, you don't have the room,

247
00:18:15,360 --> 00:18:17,680
and two, it's a massive overload of communication.

248
00:18:18,800 --> 00:18:21,660
The last thing is, again, every time you have a breach,

249
00:18:21,840 --> 00:18:24,000
you have to pull that public key off an IoT device.

250
00:18:24,480 --> 00:18:26,880
And IoT is like Android. It's not like a PC.

251
00:18:27,480 --> 00:18:30,500
You have to do a firmware update in order to pull that public key.

252
00:18:30,620 --> 00:18:31,580
It's not just sitting out there.

253
00:18:31,940 --> 00:18:34,660
And that requires a lot of testing, it requires time,

254
00:18:34,840 --> 00:18:37,020
but it also requires users to do something.

255
00:18:37,280 --> 00:18:38,240
And let's be honest.

256
00:18:38,420 --> 00:18:40,060
Users don't patch, right?

257
00:18:40,140 --> 00:18:41,880
So instead of telling users to learn security,

258
00:18:42,340 --> 00:18:43,680
why don't we turn that around and say,

259
00:18:43,820 --> 00:18:45,880
we're going to change security to work for users.

260
00:18:46,560 --> 00:18:48,480
And that's really what we're doing here.

261
00:18:49,740 --> 00:18:52,300
So, all right, OCSP tried to fix this, right?

262
00:18:52,960 --> 00:18:53,360
Great.

263
00:18:53,500 --> 00:18:56,220
You send the verification down with the actual request.

264
00:18:56,600 --> 00:18:58,920
The problem is, the public key is still on the device.

265
00:18:59,540 --> 00:19:02,240
So when you revoke, you still have to go and remove that.

266
00:19:08,540 --> 00:19:10,460
So the difference really here is,

267
00:19:10,560 --> 00:19:13,640
servers can be revoked instantly with TDI.

268
00:19:13,860 --> 00:19:16,140
With PKI, you have to pull the public key off of them.

269
00:19:17,020 --> 00:19:19,940
Devices only store two keys, right?

270
00:19:20,040 --> 00:19:22,960
The TDI service and the fleet.

271
00:19:23,140 --> 00:19:25,460
They don't store every public key for every server.

272
00:19:25,720 --> 00:19:29,060
And again, this is that authorization and authentication separating out.

273
00:19:30,660 --> 00:19:33,620
And again, with PKI, you start to overload these devices

274
00:19:33,620 --> 00:19:36,640
with every public key that they need to have access.

275
00:19:38,420 --> 00:19:40,660
So if you think of what's happening today with attacks,

276
00:19:41,240 --> 00:19:42,060
CryptoLocker, right?

277
00:19:42,140 --> 00:19:44,540
Sony being attacked and losing access to all their servers.

278
00:19:45,060 --> 00:19:49,020
The power here is that if you've lost access to your entire environment,

279
00:19:49,520 --> 00:19:50,480
I don't mean a couple servers,

280
00:19:50,720 --> 00:19:52,640
I mean everything is completely compromised,

281
00:19:53,340 --> 00:19:54,640
TDI allows you to recover.

282
00:19:55,740 --> 00:19:58,740
And I wasn't kidding when I said I expect everything to be compromised,

283
00:19:58,860 --> 00:20:00,500
so make sure you can recover from anything.

284
00:20:02,600 --> 00:20:04,820
In PKI, you're talking about potentially hundreds,

285
00:20:05,060 --> 00:20:07,520
thousands of devices, right, that need to be rekeyed.

286
00:20:08,420 --> 00:20:09,780
You generate those keys, you push them out,

287
00:20:09,820 --> 00:20:10,880
you do a lot of firmware updates.

288
00:20:11,080 --> 00:20:12,400
Again, and then you're waiting.

289
00:20:13,560 --> 00:20:14,920
So when I was at Belkin,

290
00:20:15,080 --> 00:20:17,240
we had those 500,000 devices that were compromised.

291
00:20:17,860 --> 00:20:21,760
When we got down to the last couple, almost 1,000 users,

292
00:20:22,080 --> 00:20:23,560
we just sent them new devices

293
00:20:23,560 --> 00:20:26,520
and told them that they had four days to switch over to those devices

294
00:20:26,520 --> 00:20:28,740
because they wouldn't update them, right?

295
00:20:28,760 --> 00:20:32,780
Because we were maintaining this environment that was completely compromised, right?

296
00:20:32,880 --> 00:20:35,100
Knock, sock, basically just sitting there, twiddling their thumbs,

297
00:20:35,140 --> 00:20:35,760
going, what do I do?

298
00:20:35,760 --> 00:20:39,520
I wanted them to be in control of what they needed to do.

299
00:20:40,560 --> 00:20:42,520
So let me go through the workflow really quick.

300
00:20:42,640 --> 00:20:44,240
It's fairly simple.

301
00:20:45,620 --> 00:20:48,240
So when you want to create a fleet,

302
00:20:49,140 --> 00:20:51,540
if you have an HSM, you just grab the public key

303
00:20:51,540 --> 00:20:53,080
and upload it into the TDI interface.

304
00:20:53,800 --> 00:20:57,020
Otherwise, you use the API, or the SDK,

305
00:20:57,140 --> 00:20:58,960
to generate a public-private key pair.

306
00:21:00,780 --> 00:21:01,880
Then you have a fleet.

307
00:21:02,000 --> 00:21:03,860
Now you can assign an owner to that fleet.

308
00:21:03,860 --> 00:21:06,080
And so the owner in this case is an administrator,

309
00:21:06,420 --> 00:21:09,380
someone who can add or remove servers, add or remove devices, right?

310
00:21:09,700 --> 00:21:11,980
This would be your knock, your sock members.

311
00:21:12,440 --> 00:21:14,700
So you can have multiple people that have access to this.

312
00:21:15,320 --> 00:21:17,600
And again, when you create that fleet,

313
00:21:17,780 --> 00:21:20,560
TDI creates a separate instance of it, right?

314
00:21:20,640 --> 00:21:25,160
So the fleet keys for that are completely separate than any other fleet.

315
00:21:27,000 --> 00:21:28,320
Now you want to provision servers

316
00:21:28,320 --> 00:21:30,540
so that they can go ahead and take care of communication.

317
00:21:31,300 --> 00:21:33,760
So you generate either through an HSM

318
00:21:33,860 --> 00:21:35,200
you can pull public keys again,

319
00:21:35,840 --> 00:21:39,060
or you generate new server keys through the API.

320
00:21:40,420 --> 00:21:42,600
And the server gets the private key for that.

321
00:21:42,960 --> 00:21:44,760
The public key goes to TDI.

322
00:21:45,080 --> 00:21:47,380
Because again, TDI is verifying in real time

323
00:21:47,380 --> 00:21:48,520
that that server is valid.

324
00:21:48,940 --> 00:21:51,340
And it literally is just a copy-paste of the public key

325
00:21:51,340 --> 00:21:52,080
into the dashboard.

326
00:21:55,980 --> 00:21:57,980
Provisioning devices is just as easy.

327
00:21:58,360 --> 00:22:00,140
You generate a private-public key pair.

328
00:22:00,360 --> 00:22:02,580
If it's got a TPM, TE, secure element,

329
00:22:02,580 --> 00:22:04,020
you literally just grab the public key,

330
00:22:04,140 --> 00:22:05,300
paste it in the dashboard.

331
00:22:05,500 --> 00:22:06,300
It's now authorized.

332
00:22:09,380 --> 00:22:12,540
And then the public key goes to TDI through that dashboard.

333
00:22:14,440 --> 00:22:16,180
So this is the main workflow.

334
00:22:16,520 --> 00:22:18,940
So I'm going to take you through it one more time.

335
00:22:19,020 --> 00:22:19,760
I talked about it,

336
00:22:19,800 --> 00:22:22,280
but seeing it visually makes it a little easier to understand.

337
00:22:23,000 --> 00:22:25,460
So here in step one, that server generates a request.

338
00:22:25,940 --> 00:22:29,460
It signs with its identity that is only used by it.

339
00:22:30,560 --> 00:22:32,340
It sends the message to TDI.

340
00:22:32,580 --> 00:22:36,240
And TDI will validate if that server is valid for the fleet.

341
00:22:36,660 --> 00:22:37,880
And again, if it's not,

342
00:22:38,060 --> 00:22:39,280
it will kill that request immediately.

343
00:22:40,220 --> 00:22:42,140
If the request is valid,

344
00:22:42,440 --> 00:22:44,640
it signs with its private key

345
00:22:44,640 --> 00:22:46,160
and now sends it back to the server.

346
00:22:46,400 --> 00:22:49,220
The server now can grab the private key from the HSM.

347
00:22:49,440 --> 00:22:51,400
And now you've got three signatures on it.

348
00:22:51,580 --> 00:22:53,160
The private key for the fleet,

349
00:22:53,300 --> 00:22:55,120
the private key for TDI,

350
00:22:55,360 --> 00:22:56,840
and the private key for the server.

351
00:22:57,360 --> 00:22:59,160
And when that request goes down to the device,

352
00:22:59,260 --> 00:23:00,420
the device only looks at two.

353
00:23:00,420 --> 00:23:02,260
It could care less about the server.

354
00:23:02,380 --> 00:23:03,440
It ignores it completely

355
00:23:03,440 --> 00:23:05,780
because it just knows that the server is authorized.

356
00:23:06,260 --> 00:23:08,080
It has the public key for TDI

357
00:23:08,080 --> 00:23:09,920
and it has the public key for the fleet,

358
00:23:10,040 --> 00:23:11,160
and that's all it cares about.

359
00:23:11,400 --> 00:23:13,840
The code on the device verifies those two signatures

360
00:23:14,340 --> 00:23:16,060
and it accepts the message, whatever it says.

361
00:23:16,720 --> 00:23:19,380
This means that you can't sideload requests of,

362
00:23:19,460 --> 00:23:20,920
you know, sideload firmware and devices

363
00:23:21,480 --> 00:23:23,040
using medical device programmers,

364
00:23:23,240 --> 00:23:24,140
if you put that on there.

365
00:23:24,400 --> 00:23:25,640
And when they want to communicate,

366
00:23:25,840 --> 00:23:27,720
they have to go and get authorization first.

367
00:23:28,320 --> 00:23:30,280
So this stops a lot of the attacks.

368
00:23:30,420 --> 00:23:31,660
But let's be realistic.

369
00:23:31,800 --> 00:23:32,900
This is not a silver bullet.

370
00:23:32,980 --> 00:23:34,120
This is not going to stop everything.

371
00:23:34,420 --> 00:23:36,300
There's nothing in security that stops everything.

372
00:23:36,800 --> 00:23:38,260
But that's not what this is about.

373
00:23:38,420 --> 00:23:39,580
This is about recovery

374
00:23:39,580 --> 00:23:43,100
because all that we're talking about now

375
00:23:43,100 --> 00:23:44,700
is we have devices that are compromised

376
00:23:44,700 --> 00:23:47,380
that we can't do anything with, right?

377
00:23:47,460 --> 00:23:48,560
And we've got people compromising

378
00:23:48,960 --> 00:23:50,000
all these devices back here.

379
00:23:50,680 --> 00:23:52,320
How many times have we seen someone

380
00:23:52,320 --> 00:23:54,320
put a, you know, a card in a device,

381
00:23:54,480 --> 00:23:57,520
upload the firmware with no authorization, right?

382
00:23:57,580 --> 00:23:58,640
We saw it earlier yesterday.

383
00:24:00,640 --> 00:24:02,840
Device-to-server works a little differently.

384
00:24:03,060 --> 00:24:04,600
It actually passes through the server.

385
00:24:04,760 --> 00:24:06,940
And the reason we do this is we don't want anyone

386
00:24:06,940 --> 00:24:08,540
to hijack that traffic.

387
00:24:09,140 --> 00:24:10,540
So it goes through the server,

388
00:24:10,640 --> 00:24:11,840
it passes it to TDI,

389
00:24:12,080 --> 00:24:13,640
we verify the signature,

390
00:24:13,800 --> 00:24:15,160
and then we pass it back.

391
00:24:15,920 --> 00:24:18,320
If that signature, if that device is invalid

392
00:24:18,320 --> 00:24:19,500
or if something looks wrong,

393
00:24:19,680 --> 00:24:20,640
we kill that request.

394
00:24:21,240 --> 00:24:23,320
And again, this means we can revoke a device

395
00:24:23,320 --> 00:24:24,520
that's been compromised immediately.

396
00:24:27,340 --> 00:24:28,620
Now, when we throw in an application

397
00:24:28,640 --> 00:24:31,060
into the mix, it's a very similar workflow.

398
00:24:31,500 --> 00:24:33,440
All this adds is when you have the app,

399
00:24:33,580 --> 00:24:35,340
the app actually has its own identity as well.

400
00:24:35,460 --> 00:24:37,000
Because here, everything gets an identity.

401
00:24:37,260 --> 00:24:39,180
The application can actually sign

402
00:24:39,180 --> 00:24:41,160
with its identity from the device.

403
00:24:41,540 --> 00:24:43,040
So the device has a request.

404
00:24:43,600 --> 00:24:45,600
It also gets signed with the app.

405
00:24:45,780 --> 00:24:46,800
And now you start knowing

406
00:24:46,800 --> 00:24:47,900
everything that's interacted.

407
00:24:48,220 --> 00:24:49,920
So if someone is using a different app

408
00:24:49,920 --> 00:24:51,520
or an app that doesn't look right,

409
00:24:51,720 --> 00:24:53,400
you can actually stop that request.

410
00:24:54,120 --> 00:24:55,800
Again, it's all about making sure

411
00:24:55,800 --> 00:24:57,480
everything that you know in this chain

412
00:25:00,840 --> 00:25:01,240
is valid.

413
00:25:03,160 --> 00:25:04,760
Sending a message down to a device,

414
00:25:04,940 --> 00:25:05,200
right?

415
00:25:06,040 --> 00:25:07,640
Again, we kind of went through this,

416
00:25:07,780 --> 00:25:09,980
but when there's an application involved,

417
00:25:10,260 --> 00:25:12,240
now you have the application signing as well

418
00:25:12,940 --> 00:25:14,200
before it gets down to the device.

419
00:25:14,380 --> 00:25:15,400
So that step gets added.

420
00:25:18,200 --> 00:25:19,820
So breach recovery, right?

421
00:25:19,900 --> 00:25:20,880
It's not if, it's when.

422
00:25:21,600 --> 00:25:23,100
Breach recovery is really simple.

423
00:25:23,220 --> 00:25:24,020
You go into our dashboard,

424
00:25:24,220 --> 00:25:25,640
there's a list of all your servers and devices.

425
00:25:28,640 --> 00:25:29,700
Or you can click revoke.

426
00:25:30,900 --> 00:25:32,320
The difference here is

427
00:25:32,320 --> 00:25:33,880
if you want to do an investigation

428
00:25:33,880 --> 00:25:35,860
and actually see if this is really an attack,

429
00:25:36,120 --> 00:25:38,260
you pause this device or server.

430
00:25:38,520 --> 00:25:40,360
And now it can no longer communicate

431
00:25:40,360 --> 00:25:42,300
but you can still see the messages come through.

432
00:25:42,700 --> 00:25:44,620
If you know that that device is in fact

433
00:25:44,620 --> 00:25:46,800
or that server is in fact really compromised,

434
00:25:47,120 --> 00:25:48,980
you archive it and it's gone.

435
00:25:49,160 --> 00:25:50,480
It can no longer communicate.

436
00:25:51,100 --> 00:25:52,460
This is really interesting

437
00:25:52,460 --> 00:25:54,440
because we're going to show this in the demo.

438
00:25:54,680 --> 00:25:55,720
We generate an attack.

439
00:25:56,020 --> 00:25:57,600
I'm never going to stop the attack.

440
00:25:58,640 --> 00:25:59,340
I'm going to remove the attack

441
00:25:59,340 --> 00:26:01,900
because I'm going to remove the server's ability to communicate.

442
00:26:03,020 --> 00:26:04,120
And think about this

443
00:26:04,120 --> 00:26:05,440
from an administrative standpoint.

444
00:26:05,800 --> 00:26:07,460
You've lost access to your server.

445
00:26:07,580 --> 00:26:09,200
It's sending a request it shouldn't be sending

446
00:26:09,200 --> 00:26:10,840
or someone's compromised that identity.

447
00:26:11,180 --> 00:26:13,020
The minute I revoke it from the dashboard,

448
00:26:13,680 --> 00:26:16,160
whoever has access to that server can't do anything.

449
00:26:16,440 --> 00:26:18,060
They can send out requests all day long.

450
00:26:18,480 --> 00:26:19,820
Each one of them is going to fail

451
00:26:19,820 --> 00:26:20,980
and you'll see them fail immediately.

452
00:26:23,300 --> 00:26:24,420
Alright, so I said

453
00:26:24,420 --> 00:26:25,940
we started with the idea that

454
00:26:25,940 --> 00:26:27,140
everything will be compromised.

455
00:26:28,680 --> 00:26:30,240
When I drew this out, I said

456
00:26:30,240 --> 00:26:32,520
alright, what happens if someone hacks

457
00:26:32,520 --> 00:26:34,560
into all the servers, hacks into the

458
00:26:34,560 --> 00:26:36,600
co-signing service, hacks into the devices?

459
00:26:37,040 --> 00:26:38,120
Everything is compromised.

460
00:26:38,840 --> 00:26:40,240
So when we generate a fleet,

461
00:26:40,360 --> 00:26:41,560
we generate these reset keys.

462
00:26:41,980 --> 00:26:43,260
There are three private keys.

463
00:26:43,420 --> 00:26:45,120
We recommend storing them on a USB drive.

464
00:26:45,440 --> 00:26:46,580
They are not stored online.

465
00:26:47,900 --> 00:26:50,100
The public keys for those three private keys

466
00:26:50,100 --> 00:26:51,720
are on every single device.

467
00:26:52,940 --> 00:26:54,380
When you generate a request,

468
00:26:55,320 --> 00:26:56,600
you also have

469
00:26:56,600 --> 00:26:58,520
two new public keys.

470
00:26:58,640 --> 00:27:00,840
A new public key for a fleet

471
00:27:00,840 --> 00:27:02,340
and a new public key

472
00:27:02,340 --> 00:27:03,260
for the co-signing service.

473
00:27:03,680 --> 00:27:05,700
This means if you've completely lost

474
00:27:05,700 --> 00:27:06,820
access to your environment,

475
00:27:07,000 --> 00:27:08,880
you can spin up a brand new environment,

476
00:27:09,200 --> 00:27:10,620
send a request down to your device

477
00:27:10,620 --> 00:27:12,480
and your device will now point to that environment.

478
00:27:13,600 --> 00:27:15,240
This means disaster recovery

479
00:27:15,240 --> 00:27:16,940
if you've completely lost access.

480
00:27:17,900 --> 00:27:19,380
There's also another thing here.

481
00:27:19,560 --> 00:27:21,020
People use HSMs,

482
00:27:21,600 --> 00:27:23,240
but they don't think about what happens

483
00:27:23,240 --> 00:27:24,120
if the HSM dies.

484
00:27:24,520 --> 00:27:26,960
You can't get the private key out of an HSM.

485
00:27:28,640 --> 00:27:28,980
This is a great idea.

486
00:27:29,460 --> 00:27:31,060
This is a really secure piece of hardware,

487
00:27:31,620 --> 00:27:33,040
but they didn't think about the part

488
00:27:33,040 --> 00:27:35,180
about what happens if that piece of hardware dies.

489
00:27:35,760 --> 00:27:37,060
So you need to generate a new,

490
00:27:37,500 --> 00:27:39,980
you have a new private key and a new HSM

491
00:27:39,980 --> 00:27:41,440
and now you need to figure out

492
00:27:41,440 --> 00:27:42,300
how to recover your environment.

493
00:27:43,340 --> 00:27:45,300
So with this, all you have to do

494
00:27:45,300 --> 00:27:46,640
is send this request down,

495
00:27:46,860 --> 00:27:48,820
you grab the public key for the new HSM,

496
00:27:49,080 --> 00:27:50,100
you send it down to the device,

497
00:27:50,220 --> 00:27:51,320
the device now points to it.

498
00:27:51,640 --> 00:27:52,800
It becomes very simple.

499
00:27:52,800 --> 00:27:54,480
And again, it doesn't matter

500
00:27:54,480 --> 00:27:56,200
if you've lost access to the network,

501
00:27:56,360 --> 00:27:58,400
unless they're blocking everything from coming through,

502
00:27:58,540 --> 00:28:00,200
that message is still going to get to the device.

503
00:28:03,460 --> 00:28:03,900
So,

504
00:28:04,600 --> 00:28:05,860
we're doing something different here.

505
00:28:05,900 --> 00:28:06,980
We're not pinning certs.

506
00:28:07,260 --> 00:28:09,300
We're not only pointing the device to the servers.

507
00:28:10,060 --> 00:28:11,740
We're pointing the device and the server

508
00:28:11,740 --> 00:28:12,600
they're authenticating,

509
00:28:12,720 --> 00:28:14,420
they're telling each other they're authorized,

510
00:28:14,720 --> 00:28:15,920
they're not authenticating each other,

511
00:28:16,080 --> 00:28:18,380
but they're authenticating to the cosigning service.

512
00:28:19,480 --> 00:28:21,040
And the real-time revocation.

513
00:28:22,800 --> 00:28:23,560
It's to get this removed.

514
00:28:24,760 --> 00:28:26,680
Whether it's a server, whether it's a device,

515
00:28:26,800 --> 00:28:27,500
whether it's an app,

516
00:28:27,640 --> 00:28:29,040
you can yank it immediately.

517
00:28:29,980 --> 00:28:31,920
And this becomes really fast and easy

518
00:28:31,920 --> 00:28:33,200
for the knock on the sock to handle.

519
00:28:34,940 --> 00:28:36,100
So we call this the gravy

520
00:28:36,100 --> 00:28:38,020
because I didn't want to stop there.

521
00:28:38,160 --> 00:28:39,840
I wanted to make your life's living a hell

522
00:28:39,840 --> 00:28:40,600
if you're a researcher.

523
00:28:42,420 --> 00:28:43,920
If you clone the devices,

524
00:28:44,760 --> 00:28:46,160
you know, this is something

525
00:28:46,160 --> 00:28:47,140
if you do red teaming,

526
00:28:47,140 --> 00:28:48,320
you drop devices in a network,

527
00:28:48,460 --> 00:28:49,340
it's really fun, right?

528
00:28:54,280 --> 00:28:56,040
So I came up with this idea

529
00:28:56,540 --> 00:28:58,860
that what if you actually put the code

530
00:28:58,860 --> 00:28:59,820
on the gateways as well

531
00:28:59,820 --> 00:29:01,680
and the gateway validates anything

532
00:29:01,680 --> 00:29:02,760
that's on that LAN segment.

533
00:29:03,880 --> 00:29:06,260
So if I sign a message with a device,

534
00:29:06,500 --> 00:29:07,940
I pass it to the gateway,

535
00:29:08,160 --> 00:29:10,100
the gateway validates that device

536
00:29:10,540 --> 00:29:11,280
and the message

537
00:29:11,280 --> 00:29:13,300
and now signs with its own identity.

538
00:29:13,740 --> 00:29:15,720
And now I do that again for the next gateway

539
00:29:15,720 --> 00:29:16,680
it goes through that I control.

540
00:29:16,920 --> 00:29:18,640
And now I do it again for the next gateway.

541
00:29:18,640 --> 00:29:20,820
And when that message gets to my server,

542
00:29:21,020 --> 00:29:23,900
now do I not only verify the device message

543
00:29:23,900 --> 00:29:25,420
and the gateway messages,

544
00:29:25,640 --> 00:29:26,960
I validate the order

545
00:29:26,960 --> 00:29:27,960
and the timestamp of them.

546
00:29:28,300 --> 00:29:29,820
So if you've hijacked a request,

547
00:29:30,040 --> 00:29:30,900
if you've cloned a device

548
00:29:30,900 --> 00:29:32,080
and you're not in that LAN segment,

549
00:29:32,300 --> 00:29:33,080
I'm going to notice.

550
00:29:33,700 --> 00:29:35,100
Is this going to stop every attack?

551
00:29:35,280 --> 00:29:35,400
No.

552
00:29:35,540 --> 00:29:36,700
Is it going to make it harder?

553
00:29:37,100 --> 00:29:37,500
Absolutely.

554
00:29:38,900 --> 00:29:40,340
So we can do this with apps,

555
00:29:40,500 --> 00:29:41,360
we can do it with gateways,

556
00:29:48,640 --> 00:29:49,600
So when we got acquired by NuStar,

557
00:29:49,820 --> 00:29:50,980
the first thing I thought of is,

558
00:29:51,100 --> 00:29:52,320
if you don't know NuStar,

559
00:29:52,500 --> 00:29:54,440
they have recursive DNS services

560
00:29:54,440 --> 00:29:56,060
and they have DDoS scrubbing services.

561
00:29:56,860 --> 00:29:59,080
So this provides really interesting things

562
00:29:59,080 --> 00:30:01,180
for IoT devices.

563
00:30:01,820 --> 00:30:03,740
So let's think about Mirai for a minute.

564
00:30:03,940 --> 00:30:05,300
You've got a bunch of devices

565
00:30:05,300 --> 00:30:06,700
with unauthenticated DNS

566
00:30:07,340 --> 00:30:09,220
that were pointed to a site

567
00:30:09,220 --> 00:30:11,220
and sending tremendous amounts of traffic.

568
00:30:11,620 --> 00:30:13,180
Well at some point that traffic

569
00:30:13,180 --> 00:30:14,680
is going to get too much to push off

570
00:30:18,640 --> 00:30:18,860
so you're going to have to put a blacklist

571
00:30:18,860 --> 00:30:20,100
on the device

572
00:30:20,100 --> 00:30:21,860
and stop the attack at the edge.

573
00:30:23,800 --> 00:30:25,740
That's one of the things we're working on for this.

574
00:30:25,820 --> 00:30:28,160
It's essentially to use TDI to sign those requests

575
00:30:28,160 --> 00:30:30,040
so that if you get a device

576
00:30:30,040 --> 00:30:31,900
or a bunch of devices that tell you,

577
00:30:31,940 --> 00:30:32,620
hey by the way,

578
00:30:33,060 --> 00:30:34,620
we're being directed to this site,

579
00:30:35,200 --> 00:30:37,280
you can actually take that information in,

580
00:30:37,380 --> 00:30:39,580
push that back down to all the rest of the devices

581
00:30:39,580 --> 00:30:41,360
and depending on if it's server relay

582
00:30:41,360 --> 00:30:42,180
or point to point,

583
00:30:42,340 --> 00:30:45,120
block that site or allow different sites

584
00:30:45,120 --> 00:30:46,080
to be accessed.

585
00:30:48,640 --> 00:30:49,760
So anything that was a command and control server

586
00:30:49,760 --> 00:30:51,240
that you had access to before

587
00:30:51,240 --> 00:30:53,300
can be blocked very quickly.

588
00:30:53,980 --> 00:30:55,600
And because we have

589
00:30:55,600 --> 00:30:57,440
some additional features

590
00:30:57,440 --> 00:30:58,360
that NuStar,

591
00:30:58,500 --> 00:31:00,940
we own 400 TLDs

592
00:31:00,940 --> 00:31:02,020
and we do that recursive DNS,

593
00:31:02,340 --> 00:31:04,400
we see things that we can push down to these lists.

594
00:31:05,040 --> 00:31:07,020
So that means we can protect these devices

595
00:31:07,020 --> 00:31:08,800
which protects customers

596
00:31:08,800 --> 00:31:10,680
but it also protects the average user.

597
00:31:11,000 --> 00:31:13,440
And that's the reason we're putting this out there.

598
00:31:13,680 --> 00:31:15,100
Because device manufacturers

599
00:31:15,100 --> 00:31:17,220
are never going to pay for security.

600
00:31:18,640 --> 00:31:19,920
I've been on both sides of it

601
00:31:19,920 --> 00:31:21,080
and convincing them to pay a nickel

602
00:31:21,080 --> 00:31:21,920
is not happening.

603
00:31:22,460 --> 00:31:23,920
But if we give them a framework

604
00:31:23,920 --> 00:31:25,900
that they can use to stop sideload attacks,

605
00:31:26,220 --> 00:31:28,020
to stop DNS attacks,

606
00:31:28,360 --> 00:31:30,380
to stop denial of service attacks,

607
00:31:31,460 --> 00:31:32,520
maybe, just maybe,

608
00:31:32,640 --> 00:31:34,040
we can stop some of this stuff

609
00:31:34,040 --> 00:31:35,700
and get things to recover quickly.

610
00:31:38,320 --> 00:31:39,520
There's a couple other scenarios

611
00:31:39,520 --> 00:31:40,280
that we're working on.

612
00:31:41,180 --> 00:31:42,340
There was an auto manufacturer

613
00:31:42,340 --> 00:31:43,260
that came to us and said,

614
00:31:43,260 --> 00:31:44,020
hey, by the way,

615
00:31:44,140 --> 00:31:47,160
if we put that digital identity in our key fob

616
00:31:47,160 --> 00:31:48,620
and that car is underground,

617
00:31:49,260 --> 00:31:51,100
how do we make sure I can unlock my car?

618
00:31:51,620 --> 00:31:53,560
And I went, shit, that's probably a good idea.

619
00:31:54,000 --> 00:31:55,100
I don't want to be locked out

620
00:31:55,100 --> 00:31:56,080
of my $80,000 car

621
00:31:56,080 --> 00:31:59,900
when I can't do that.

622
00:32:00,160 --> 00:32:01,800
So there are scenarios

623
00:32:01,800 --> 00:32:02,560
where we would say

624
00:32:02,560 --> 00:32:04,240
you can actually allow

625
00:32:04,240 --> 00:32:05,320
a certain number of requests

626
00:32:05,320 --> 00:32:07,920
so that key fob, even without access.

627
00:32:08,320 --> 00:32:10,140
But there's actually a more powerful option

628
00:32:10,140 --> 00:32:12,660
which is that car now has a gateway

629
00:32:13,260 --> 00:32:14,660
so if we locally replicate

630
00:32:14,660 --> 00:32:16,600
all the devices that are in that car,

631
00:32:17,540 --> 00:32:19,540
we can allow you to authenticate there

632
00:32:19,540 --> 00:32:21,100
rather than going out to the cloud.

633
00:32:22,000 --> 00:32:23,200
And there's another thing

634
00:32:23,200 --> 00:32:24,660
that goes along with this

635
00:32:24,660 --> 00:32:25,640
that was part of this

636
00:32:25,640 --> 00:32:27,080
when I originally designed it.

637
00:32:27,180 --> 00:32:28,740
If you start thinking about cars,

638
00:32:28,780 --> 00:32:30,240
not just other IoT devices,

639
00:32:30,620 --> 00:32:32,780
a car has about 100 ECUs,

640
00:32:32,920 --> 00:32:34,560
different processes that control everything.

641
00:32:34,880 --> 00:32:36,400
And if you look at Charlie's work

642
00:32:36,400 --> 00:32:37,700
when they loaded the Jeep,

643
00:32:37,880 --> 00:32:39,560
they basically took a USB drive

644
00:32:44,180 --> 00:32:46,620
What if you gave every single ECU

645
00:32:46,620 --> 00:32:48,120
its own identity within a car

646
00:32:48,120 --> 00:32:50,160
and had the gateway authorizing

647
00:32:50,160 --> 00:32:52,500
what ECUs were allowed to talk to other ECUs?

648
00:32:53,320 --> 00:32:55,320
Regardless if the car was offline or not,

649
00:32:55,440 --> 00:32:56,540
now you can stop attacks

650
00:32:57,060 --> 00:32:59,020
from a radio that affects my brakes.

651
00:32:59,820 --> 00:33:01,560
And if you want to set it up,

652
00:33:01,580 --> 00:33:02,940
we can have fleets within fleets

653
00:33:02,940 --> 00:33:05,220
so you can actually say your Toyota,

654
00:33:05,420 --> 00:33:07,480
you can say to all your component manufacturers

655
00:33:07,480 --> 00:33:09,040
that they control the firmware

656
00:33:09,040 --> 00:33:10,120
to that component

657
00:33:10,120 --> 00:33:11,720
but not to anything else.

658
00:33:13,320 --> 00:33:13,720
So you have to understand

659
00:33:13,720 --> 00:33:15,600
the relationships of what's allowed to talk to what.

660
00:33:16,260 --> 00:33:18,280
Assume that nothing's allowed to talk to anything

661
00:33:18,720 --> 00:33:19,740
until proven otherwise.

662
00:33:20,260 --> 00:33:21,820
Again, that's the basis of this.

663
00:33:24,400 --> 00:33:25,440
Alright, so the demo.

664
00:33:27,480 --> 00:33:28,500
I will say that

665
00:33:28,500 --> 00:33:29,800
before I start this,

666
00:33:29,980 --> 00:33:31,460
I recorded this beforehand

667
00:33:31,460 --> 00:33:34,280
and the reason is this takes five monitors to run

668
00:33:34,280 --> 00:33:36,360
and I didn't think they'd have five projectors

669
00:33:36,360 --> 00:33:37,020
to get me to run it.

670
00:33:37,380 --> 00:33:38,680
But let me set this up for you

671
00:33:38,680 --> 00:33:39,900
so you understand what's going on here.

672
00:33:43,260 --> 00:33:45,040
So we built a Lego parking lot.

673
00:33:45,840 --> 00:33:47,280
We didn't automate the car

674
00:33:47,280 --> 00:33:49,020
so there's some dental floss that you'll see

675
00:33:49,020 --> 00:33:52,060
but essentially we have three IoT sensors

676
00:33:52,060 --> 00:33:53,720
that are in the parking spaces.

677
00:33:54,160 --> 00:33:55,860
And when a car is in that space

678
00:33:55,860 --> 00:33:58,420
it changes the color from green to red.

679
00:33:58,580 --> 00:33:59,580
So that way we know

680
00:33:59,580 --> 00:34:01,160
when there's a space open.

681
00:34:01,640 --> 00:34:03,180
In the bottom left hand corner

682
00:34:03,180 --> 00:34:04,820
is a little mobile app that we built

683
00:34:04,820 --> 00:34:07,020
that just tells you what the status

684
00:34:07,020 --> 00:34:08,020
of those parking spots are.

685
00:34:08,240 --> 00:34:09,520
So if it's green it's open,

686
00:34:09,520 --> 00:34:10,380
if it's red it's closed.

687
00:34:11,120 --> 00:34:12,360
In the top right corner,

688
00:34:12,540 --> 00:34:14,580
and I know this projector is hard to see on it,

689
00:34:14,680 --> 00:34:15,580
is our dashboard.

690
00:34:15,880 --> 00:34:17,240
This is where you add devices,

691
00:34:17,480 --> 00:34:19,700
add servers, remove devices, remove servers.

692
00:34:20,000 --> 00:34:21,060
It's very simple.

693
00:34:21,260 --> 00:34:22,560
You'll see during this demo

694
00:34:24,020 --> 00:34:25,820
messages come through on the bottom

695
00:34:25,820 --> 00:34:27,820
and then we revoke and it immediately

696
00:34:27,820 --> 00:34:28,800
goes from green to red.

697
00:34:29,120 --> 00:34:30,960
And so that brings up this bottom right corner.

698
00:34:31,160 --> 00:34:32,800
This is the logs that are being tailed.

699
00:34:33,160 --> 00:34:35,000
Right now you see a valid result here.

700
00:34:35,000 --> 00:34:36,440
This is the parking lot

701
00:34:36,440 --> 00:34:37,720
sending a message just saying

702
00:34:37,720 --> 00:34:39,040
this is the status.

703
00:34:40,320 --> 00:34:42,460
We're going to see those keep on going green.

704
00:34:42,560 --> 00:34:44,020
Every couple of seconds

705
00:34:44,020 --> 00:34:45,660
they're going to keep on sending requests through.

706
00:34:46,220 --> 00:34:47,920
And at some point on the top

707
00:34:47,920 --> 00:34:49,580
you're going to see us revoke a server

708
00:34:49,580 --> 00:34:52,460
and you'll watch the next request turns red.

709
00:34:52,840 --> 00:34:54,080
But before we do that,

710
00:34:54,120 --> 00:34:55,320
in the bottom right corner you're going to see

711
00:34:55,320 --> 00:34:56,280
another window pop up.

712
00:34:56,460 --> 00:34:58,280
It's an injection attack that we're running.

713
00:34:58,440 --> 00:35:01,080
We're spoofing the identity of server number one.

714
00:35:01,600 --> 00:35:03,460
So in the top left,

715
00:35:05,000 --> 00:35:05,900
right of the top left,

716
00:35:06,060 --> 00:35:07,340
there's two Raspberry Pis there.

717
00:35:08,780 --> 00:35:10,540
Those Raspberry Pis are acting as

718
00:35:10,540 --> 00:35:11,780
servers for the parking lot.

719
00:35:12,360 --> 00:35:13,440
And remember what I told you,

720
00:35:13,460 --> 00:35:14,720
you can remove all your servers?

721
00:35:14,940 --> 00:35:18,300
So server two isn't really set up right now.

722
00:35:18,460 --> 00:35:19,520
It's only server one.

723
00:35:19,920 --> 00:35:21,320
So what you're going to see us do is

724
00:35:21,320 --> 00:35:22,520
we're going to remove server one

725
00:35:22,520 --> 00:35:24,300
so it has no access to communicate anymore

726
00:35:24,300 --> 00:35:26,240
and we're never going to stop that attack.

727
00:35:26,700 --> 00:35:28,500
And then you'll see everything go red.

728
00:35:28,940 --> 00:35:30,380
We'll add server two in

729
00:35:30,380 --> 00:35:32,760
and now you'll see everything turn back to green.

730
00:35:35,000 --> 00:35:36,320
I try and draw it out because

731
00:35:36,320 --> 00:35:37,740
it's a lightweight piece of code

732
00:35:37,740 --> 00:35:38,720
and it works really fast.

733
00:35:39,420 --> 00:35:40,500
But let me take you through it.

734
00:35:41,520 --> 00:35:43,040
So you've got valid results here.

735
00:35:43,200 --> 00:35:45,540
We're going to use our magic to pull this string

736
00:35:45,540 --> 00:35:46,820
and pull that car in.

737
00:35:47,480 --> 00:35:50,180
And now you see the status of it change

738
00:35:50,180 --> 00:35:51,280
so they're all red.

739
00:35:53,660 --> 00:35:54,740
You'll see the bottom right,

740
00:35:54,820 --> 00:35:56,520
there's another window that's going to come up in a second

741
00:35:56,520 --> 00:35:57,880
which is when we generate the attack.

742
00:36:00,220 --> 00:36:01,480
But I wanted to draw it out

743
00:36:01,480 --> 00:36:02,400
so I let it go valid.

744
00:36:02,580 --> 00:36:04,220
Here's our attack executing right now.

745
00:36:05,000 --> 00:36:06,680
And on the left hand side on the bottom

746
00:36:06,680 --> 00:36:07,760
watch those colors.

747
00:36:07,900 --> 00:36:08,860
They're going to start flashing

748
00:36:08,860 --> 00:36:10,880
as it's changing the status request.

749
00:36:11,860 --> 00:36:13,400
The cars aren't moving at all

750
00:36:13,400 --> 00:36:15,720
but yet all those cars

751
00:36:15,720 --> 00:36:17,840
their status is changing for the parking lot.

752
00:36:19,180 --> 00:36:20,660
In a second in the top right

753
00:36:20,660 --> 00:36:22,040
you're going to see me revoke the server.

754
00:36:22,340 --> 00:36:23,940
I said it's a very quick thing.

755
00:36:24,100 --> 00:36:25,920
You click on it and you remove it.

756
00:36:32,320 --> 00:36:33,980
So we find the server in the list.

757
00:36:35,000 --> 00:36:35,080
Remove it.

758
00:36:36,000 --> 00:36:37,140
Remove its access.

759
00:36:41,760 --> 00:36:42,480
Verify it.

760
00:36:44,520 --> 00:36:46,360
And the next message is red.

761
00:36:46,740 --> 00:36:48,520
That server no longer has access

762
00:36:48,520 --> 00:36:50,100
but we have not stopped the attack.

763
00:36:50,300 --> 00:36:51,500
The attack is still running

764
00:36:52,160 --> 00:36:54,660
because that attacker still has access to that server.

765
00:36:55,500 --> 00:36:56,660
And it will fail

766
00:36:56,660 --> 00:36:58,500
as long as that server

767
00:36:58,500 --> 00:36:59,500
is trying to send messages

768
00:36:59,500 --> 00:37:01,740
and is not validated to be in the fleet.

769
00:37:02,360 --> 00:37:04,100
Now we're going to add a new server back.

770
00:37:05,000 --> 00:37:05,220
That's server 2.

771
00:37:05,500 --> 00:37:07,740
And you'll watch that request immediately go green.

772
00:37:08,620 --> 00:37:09,660
And that's TDI.

773
00:37:18,780 --> 00:37:20,540
See, we're of the belief that

774
00:37:20,540 --> 00:37:21,960
if you build things to fail

775
00:37:21,960 --> 00:37:24,460
assume that everything is failing

776
00:37:24,940 --> 00:37:26,600
you can actually start putting security people

777
00:37:26,600 --> 00:37:27,780
back in control

778
00:37:27,780 --> 00:37:30,460
so that they can make the decisions that they know are true.

779
00:37:31,420 --> 00:37:32,640
Don't rely on users

780
00:37:32,640 --> 00:37:33,480
to make these decisions.

781
00:37:35,000 --> 00:37:35,060
So let's talk about the code.

782
00:37:35,700 --> 00:37:37,260
Some of the code has already been released.

783
00:37:37,500 --> 00:37:38,680
It's on our GitHub repo.

784
00:37:38,900 --> 00:37:40,140
We have a Python library up there.

785
00:37:40,440 --> 00:37:43,720
We are actually in the process of being acquired right now

786
00:37:43,720 --> 00:37:44,800
so there was a little bit of delay

787
00:37:44,800 --> 00:37:46,600
in the rest of the code being audited.

788
00:37:47,260 --> 00:37:49,120
As soon as that's audited it will be up here.

789
00:37:49,940 --> 00:37:52,260
You'll notice that the documentation says 1ID.

790
00:37:52,600 --> 00:37:53,780
That was the name of the company

791
00:37:53,780 --> 00:37:54,680
before we got acquired

792
00:37:54,680 --> 00:37:56,340
so we just hadn't changed that URL.

793
00:37:56,720 --> 00:37:58,340
But our documentation is up there

794
00:37:58,340 --> 00:38:00,380
and we are constantly updating it.

795
00:38:01,120 --> 00:38:02,980
If you want some more information

796
00:38:02,980 --> 00:38:04,340
on our site

797
00:38:04,340 --> 00:38:05,240
there's a bit.ly link.

798
00:38:05,400 --> 00:38:07,320
It's New Star TDI. It's case sensitive.

799
00:38:07,640 --> 00:38:09,740
It's got some information on my white paper

800
00:38:11,040 --> 00:38:12,800
and we also have an email address

801
00:38:12,800 --> 00:38:14,040
if you have questions about it.

802
00:38:14,280 --> 00:38:16,100
We are going to be allowing other people

803
00:38:16,100 --> 00:38:17,040
to contribute to this.

804
00:38:17,360 --> 00:38:18,880
We are going to control that for now

805
00:38:18,880 --> 00:38:22,000
to make sure that bad code isn't being put in there

806
00:38:22,000 --> 00:38:23,260
and people aren't breaking things.

807
00:38:23,640 --> 00:38:26,380
But as I said, the Edge Foundry

808
00:38:27,540 --> 00:38:28,340
Dell project

809
00:38:28,340 --> 00:38:30,280
we're going to be contributing our code as part of that.

810
00:38:30,380 --> 00:38:32,300
So this is our phase two.

811
00:38:33,080 --> 00:38:34,820
I have six phases of this.

812
00:38:34,960 --> 00:38:36,580
The team doesn't even know the rest of them yet.

813
00:38:36,780 --> 00:38:38,380
There's a lot of things that we want to do

814
00:38:38,380 --> 00:38:39,740
to build a secure framework for IoT.

815
00:38:40,480 --> 00:38:42,320
We'd love to hear feedback from you guys.

816
00:38:42,720 --> 00:38:44,300
We come from research backgrounds.

817
00:38:44,680 --> 00:38:45,840
We've attacked these devices.

818
00:38:46,160 --> 00:38:47,980
We're trying to make something to defend it

819
00:38:47,980 --> 00:38:49,760
to make it harder for us to do our job

820
00:38:49,760 --> 00:38:52,240
as attackers and easier for the people

821
00:38:52,240 --> 00:38:52,740
to do defense.

822
00:38:56,240 --> 00:38:58,100
I just want to thank just a couple of people

823
00:38:58,100 --> 00:39:00,360
because when I had this idea

824
00:39:00,380 --> 00:39:02,520
the OneID CEO came to me

825
00:39:02,520 --> 00:39:03,780
and said, hey I want to build this thing

826
00:39:03,780 --> 00:39:05,960
and I'm like, actually I'd like to build this thing.

827
00:39:06,780 --> 00:39:08,040
And Steve Kirsch

828
00:39:08,980 --> 00:39:09,860
the founder

829
00:39:09,860 --> 00:39:10,980
and our CEO said

830
00:39:11,820 --> 00:39:14,200
go build that thing. That sounds really cool.

831
00:39:14,760 --> 00:39:15,820
And then Callie

832
00:39:16,380 --> 00:39:17,840
put all these videos together for me

833
00:39:17,840 --> 00:39:20,320
so I didn't have to get five projectors running for you guys

834
00:39:20,320 --> 00:39:22,380
which makes my job up here

835
00:39:22,380 --> 00:39:22,880
a little easier.

836
00:39:23,180 --> 00:39:25,480
The other thing is that I literally put this out

837
00:39:25,480 --> 00:39:27,180
to any researcher that I knew on Twitter

838
00:39:27,180 --> 00:39:28,480
and went through the model.

839
00:39:30,380 --> 00:39:30,700
It's really cool.

840
00:39:30,700 --> 00:39:31,940
The other thing is that you don't build security in a backroom.

841
00:39:32,040 --> 00:39:34,040
The whole point of this is to help all of us

842
00:39:34,040 --> 00:39:34,980
get things more secure

843
00:39:34,980 --> 00:39:36,440
rather than just breaking things.

844
00:39:36,720 --> 00:39:38,800
So if you'd like to contribute

845
00:39:38,800 --> 00:39:41,000
if you'd like to help look at threat models

846
00:39:41,000 --> 00:39:42,300
we'd love to have your help.

847
00:39:43,840 --> 00:39:44,280
Questions?

848
00:39:48,840 --> 00:39:49,900
So that's a good question.

849
00:39:49,960 --> 00:39:50,500
Here's the thing.

850
00:39:51,000 --> 00:39:52,780
On a small instance Amazon server

851
00:39:52,780 --> 00:39:54,120
we can do 100,000 requests

852
00:39:54,120 --> 00:39:55,880
like verify signatures in a second.

853
00:39:56,280 --> 00:39:58,720
So if you think of a latency standpoint

854
00:40:00,380 --> 00:40:01,800
the device is a lot slower

855
00:40:01,800 --> 00:40:02,980
than a cloud-to-cloud communication.

856
00:40:03,600 --> 00:40:06,680
So we can put this wherever your devices are.

857
00:40:07,160 --> 00:40:08,720
Obviously we want it in a different rack

858
00:40:08,720 --> 00:40:09,980
so that it's locked off

859
00:40:09,980 --> 00:40:11,260
from a threat model perspective.

860
00:40:11,600 --> 00:40:13,080
We want different credentials to it

861
00:40:13,080 --> 00:40:14,300
but we can deploy it anywhere.

862
00:40:15,180 --> 00:40:16,820
So the whole idea is

863
00:40:16,820 --> 00:40:19,000
that request coming down from the server

864
00:40:19,000 --> 00:40:20,960
it's validated through our server

865
00:40:20,960 --> 00:40:22,480
it's a very quick turnaround.

866
00:40:23,100 --> 00:40:25,160
It's much faster than a CRL lookup.

867
00:40:26,400 --> 00:40:27,800
And it obviously depends

868
00:40:27,800 --> 00:40:29,420
how big the CRL list is

869
00:40:30,760 --> 00:40:32,780
but you're cutting down the time significantly.

870
00:40:34,480 --> 00:40:35,420
Sorry, go ahead.

871
00:40:40,820 --> 00:40:41,920
So I didn't

872
00:40:41,920 --> 00:40:43,420
thank you, I appreciate it.

873
00:40:43,680 --> 00:40:45,160
I didn't talk about rotation.

874
00:40:46,040 --> 00:40:48,080
I said about rotation being a problem.

875
00:40:48,400 --> 00:40:50,540
You can basically go in here and rekey very easily.

876
00:40:50,780 --> 00:40:52,180
So you would just generate new keys

877
00:40:52,180 --> 00:40:54,120
you'd pop them in there and you'd just put them on the server.

878
00:40:54,460 --> 00:40:56,140
Could you do automated rekeying? Yes.

879
00:40:56,940 --> 00:40:58,220
At the time when we started

880
00:40:58,220 --> 00:41:00,200
building the framework I just had to choose

881
00:41:00,380 --> 00:41:01,980
what was important to build at the time.

882
00:41:02,240 --> 00:41:04,080
That's why I said there's six phases total.

883
00:41:04,380 --> 00:41:06,680
There were certain things that we just didn't want to focus on

884
00:41:06,680 --> 00:41:08,500
because I wanted the development team to make sure

885
00:41:08,500 --> 00:41:10,840
they were focusing on the authentication and authorization part.

886
00:41:11,720 --> 00:41:12,240
But yeah,

887
00:41:12,280 --> 00:41:14,520
certainly we could do automatic.

888
00:41:14,820 --> 00:41:16,920
As you scale it, it's a lot more important, right?

889
00:41:17,140 --> 00:41:17,760
Absolutely, yeah.

890
00:41:17,860 --> 00:41:19,620
But it also, even with this it's really easy

891
00:41:19,620 --> 00:41:21,580
because you generate a set of keys

892
00:41:21,580 --> 00:41:23,700
you can write a script to push those out to the server

893
00:41:23,700 --> 00:41:24,720
and put the public key up there.

894
00:41:25,080 --> 00:41:27,480
I don't necessarily consider that the hard part

895
00:41:27,480 --> 00:41:29,460
but it's an important feature.

896
00:41:30,380 --> 00:41:31,820
Actually one of our developers is sitting in the back

897
00:41:31,820 --> 00:41:33,580
so I'll have him put that in.

898
00:41:42,740 --> 00:41:43,760
Very good question.

899
00:41:49,520 --> 00:41:50,660
Yeah, so that's a good question.

900
00:41:50,700 --> 00:41:53,160
The question was about would it work for EMS, right?

901
00:41:53,860 --> 00:41:55,700
Oh, TLS. Oh, I'm sorry. I thought you said EMS.

902
00:41:56,100 --> 00:41:56,920
But that works also.

903
00:41:58,160 --> 00:41:58,800
Here's the thing.

904
00:42:00,380 --> 00:42:02,900
So there are other things that we're looking at using it for.

905
00:42:03,060 --> 00:42:05,540
You can sign any protocol with this, right?

906
00:42:05,600 --> 00:42:06,600
We sit on top of it.

907
00:42:06,680 --> 00:42:08,880
The reason was I didn't want to have someone

908
00:42:08,880 --> 00:42:09,920
if they had transport encryption

909
00:42:10,500 --> 00:42:12,620
to have to use whatever we had.

910
00:42:12,960 --> 00:42:15,060
So you could actually use this for NTP.

911
00:42:15,300 --> 00:42:16,360
You could use it for DNS.

912
00:42:16,680 --> 00:42:18,080
You could use it for TLS.

913
00:42:18,280 --> 00:42:20,600
There's no reason why we couldn't write the signatures on top.

914
00:42:27,320 --> 00:42:29,400
Well, you'd provision a server, yeah.

915
00:42:29,500 --> 00:42:30,360
But the server doesn't do that.

916
00:42:30,380 --> 00:42:32,880
The server would then be in the TDI.

917
00:42:33,560 --> 00:42:34,980
So you would just authorize it there.

918
00:42:35,760 --> 00:42:36,900
So you could do it the same way.

919
00:42:37,360 --> 00:42:39,480
And again, this allows you to remove them, add them, whatever.

920
00:42:55,780 --> 00:42:57,980
So the question was are we just shifting

921
00:42:57,980 --> 00:43:00,940
the area to TDI?

922
00:43:01,120 --> 00:43:02,700
And it's no, because you need both keys.

923
00:43:03,200 --> 00:43:04,420
So if TDI is compromised,

924
00:43:04,560 --> 00:43:05,540
you can replace it instantly.

925
00:43:05,980 --> 00:43:07,800
Whereas in a root cert, in a CA,

926
00:43:08,040 --> 00:43:09,000
you have to revoke it,

927
00:43:09,040 --> 00:43:10,400
which means you have to firmware update the device.

928
00:43:11,140 --> 00:43:12,740
In our case, we can generate a request

929
00:43:12,740 --> 00:43:16,380
and push the public key that points to TDI instantaneously.

930
00:43:19,240 --> 00:43:21,440
It has to check both SIGs or it can't do anything.

931
00:43:21,780 --> 00:43:22,900
And that's the power of it.

932
00:43:23,020 --> 00:43:24,580
So you could hack the server.

933
00:43:24,760 --> 00:43:27,280
You could hack TDI. Are you going to hack them both at the same time,

934
00:43:27,980 --> 00:43:28,240
with different credentials,

935
00:43:28,480 --> 00:43:30,140
and they're run by different people?

936
00:43:31,140 --> 00:43:32,980
Again, it's possible, it's just not probable.

937
00:43:33,520 --> 00:43:34,640
And if you do,

938
00:43:34,820 --> 00:43:36,200
then you can revoke and replace.

939
00:43:37,940 --> 00:43:39,380
So the whole thing is recovery.

940
00:43:39,920 --> 00:43:41,140
How fast can you recover?

941
00:43:41,260 --> 00:43:42,700
How can you make sure you're working on your roadmap?

942
00:43:43,880 --> 00:43:44,620
Any other questions?

943
00:43:54,160 --> 00:43:55,380
It's really small, whereas

944
00:43:56,900 --> 00:43:57,760
I'm going to

945
00:43:57,980 --> 00:44:00,040
refer to Ian for a second.

946
00:44:00,280 --> 00:44:00,620
If you...

947
00:44:01,240 --> 00:44:02,860
Ian's back here, he's one of our developers.

948
00:44:05,360 --> 00:44:06,240
It's pretty...

949
00:44:07,420 --> 00:44:08,620
Yeah, go for it.

950
00:44:26,820 --> 00:44:27,960
Yeah, so it's pretty...

951
00:44:27,980 --> 00:44:28,520
It's pretty lightweight.

952
00:44:30,520 --> 00:44:31,000
Questions?

953
00:44:31,740 --> 00:44:33,160
Cool. Thank you guys very much.

954
00:44:37,360 --> 00:44:38,640
I'll just say one more thing.

955
00:44:38,860 --> 00:44:40,160
So we designed this.

956
00:44:40,340 --> 00:44:41,860
This isn't the be all and end all.

957
00:44:42,540 --> 00:44:45,140
The whole idea here is sort of a mentality shift.

958
00:44:46,760 --> 00:44:47,880
Don't rely on the router

959
00:44:47,880 --> 00:44:49,180
if you're building these devices.

960
00:44:49,820 --> 00:44:51,780
Make sure your security is self-contained

961
00:44:51,780 --> 00:44:52,680
for the device you're building.

962
00:44:53,260 --> 00:44:55,000
Trust nothing until proven otherwise

963
00:44:55,000 --> 00:44:56,280
all the time.

964
00:44:57,980 --> 00:44:59,620
The people who actually know about security

965
00:44:59,620 --> 00:45:01,240
are the ones who can do something about it.

966
00:45:01,460 --> 00:45:03,080
So put your dock and sock back in control.

967
00:45:03,240 --> 00:45:04,740
Not users, not site managers.

968
00:45:06,060 --> 00:45:06,440
Thanks.