1
00:00:00,000 --> 00:00:06,080
Speaker here, Trey Fogetti is here to talk about the challenges of user privacy in a location

2
00:00:06,080 --> 00:00:14,520
sensitive system like 911. He's part of the 911 Association. This talk is being recorded to show

3
00:00:14,520 --> 00:00:20,140
it online later on. So if anyone has any questions, please walk down to the microphone at the

4
00:00:20,140 --> 00:00:24,720
center aisle and we can record the questions too. So without further ado, Trey.

5
00:00:25,600 --> 00:00:31,220
Thank you so much and thank all of you for being here this afternoon. I know your time at DEF CON is

6
00:00:31,220 --> 00:00:38,680
precious. And I will say for my part, I very much want to make this talk a lot less formal and a lot

7
00:00:38,680 --> 00:00:45,060
more interactive than some of the talks that you'll see in the other tracks. So if you have at

8
00:00:45,060 --> 00:00:48,860
some point a question about anything that I'm saying, please don't wait until the end. Come up to

9
00:00:48,860 --> 00:00:53,720
the microphone and as soon as I get to like a convenient pausing point, I will take your

10
00:00:53,720 --> 00:00:54,020
question.

11
00:00:54,740 --> 00:01:00,240
This is a really interesting area that I'm very passionate about. I'm being told I can't be

12
00:01:00,240 --> 00:01:05,900
heard. So let me, I'm just going to hold this. How about that? Everybody hear me now? Good. So

13
00:01:08,100 --> 00:01:15,220
where we start is I get a question all the time. So you guys at 911, you're just tracking

14
00:01:15,220 --> 00:01:20,560
everybody all the time, right? That's how you know where I am. And the answer couldn't be further

15
00:01:20,560 --> 00:01:24,700
from the truth. We are not tracking you at any time. And we are not tracking you at any time.

16
00:01:24,720 --> 00:01:30,320
In fact, you would almost be appalled at how little location data we do get when we want to find

17
00:01:30,320 --> 00:01:35,200
you, which is when you call 911. So my talk is going to go over a little bit about what we

18
00:01:35,200 --> 00:01:42,540
do get, when we get it, how we are actually part of the privacy solution by virtue of keeping

19
00:01:43,320 --> 00:01:49,320
people who want access to location data away from it when they shouldn't have it. And how we

20
00:01:50,300 --> 00:01:54,700
acquire and store and use location data when you make it available to them. So let me first talk a

21
00:01:54,700 --> 00:02:00,320
it available by calling 911. So at the outset I think I want to start with just a quick thing

22
00:02:00,320 --> 00:02:09,340
about how location works. Are folks here familiar with how GPS works like generally? Okay. I'm

23
00:02:09,340 --> 00:02:15,640
going to go into it just kind of at a very high level. So basically a few thousand miles up we

24
00:02:15,640 --> 00:02:21,100
have a constellation of 30-odd satellites orbiting the earth roughly every 90 minutes. And

25
00:02:21,100 --> 00:02:27,900
each one of them is singing a unique song, but they're singing it on the same frequency. And by

26
00:02:28,440 --> 00:02:35,680
singing the same song inside a receiver essentially, you can find out how far off in time

27
00:02:35,680 --> 00:02:41,140
your song is from the one being sung by the satellite. And that tells you a time offset. So

28
00:02:41,140 --> 00:02:48,320
you get and we multiply that by the speed of light, correct for things like the diffraction of

29
00:02:48,320 --> 00:02:51,080
the ionosphere that delays these signals. And then we multiply that by the speed of light.

30
00:02:51,080 --> 00:02:56,640
And once we have ranging from multiple satellites, then your device can calculate its

31
00:02:56,640 --> 00:03:04,580
location in 3-D space. Now, it's pretty good horizontally. GPS in the best of cases can give us,

32
00:03:04,580 --> 00:03:09,880
you know, five to ten meter fixes most of the time. If you have a really good device with a

33
00:03:09,880 --> 00:03:14,800
great antenna and, you know, a multiband receiver and you leave it stationary for a very long

34
00:03:14,800 --> 00:03:21,020
time, you can get that down to like a tenth of a meter reliably or better. But for the

35
00:03:21,080 --> 00:03:25,960
typical case of something that's cheap enough to put in a smartphone and for us to carry around

36
00:03:25,960 --> 00:03:30,520
with us every day and, you know, doesn't have a gigantic antenna sticking out the end of it,

37
00:03:30,600 --> 00:03:35,460
that's not really the reality. You're not going to get anything nearly that close. So

38
00:03:36,620 --> 00:03:41,240
historically we've had this problem of we need to find people when they call 911. So how are we

39
00:03:41,240 --> 00:03:44,920
going to do that? Well, in the wireline world it was easy. We knew where the telephone

40
00:03:44,920 --> 00:03:50,500
company's wires went. They kept a billing database that said, you know, here's where our wires go.

41
00:03:51,080 --> 00:03:56,260
And when you established phone service, we could go to them and say, look, for every address that

42
00:03:56,260 --> 00:04:00,020
you put in your database, you have to validate that with somebody. It's something called the

43
00:04:00,020 --> 00:04:05,460
master street address guide for your locality, which is a table that contains all of the valid

44
00:04:05,460 --> 00:04:12,060
street names and all of the valid number ranges within those street names. And so they could

45
00:04:12,060 --> 00:04:15,680
submit that address, make sure that it was valid. If it wasn't, they had to go back to you and

46
00:04:15,680 --> 00:04:20,820
say, hey, it looks like your street doesn't exist or potentially your number's out of the

47
00:04:20,820 --> 00:04:24,000
range. Like what happened? Did somebody build something new? And if that's the case, okay, we

48
00:04:24,000 --> 00:04:27,920
got to go fix the database. But there was a process. We knew where everything was. Smartphones

49
00:04:27,920 --> 00:04:32,840
aren't like that. They move around. Cell phones generally move around. And so we had to come up

50
00:04:32,840 --> 00:04:39,860
with ways to figure out where mobile devices were. In the early days, there were two very

51
00:04:39,860 --> 00:04:44,740
general ways of doing this. There was called the network-based model and the handset-based

52
00:04:44,740 --> 00:04:50,800
model. In the network-based model, devices in the network either transmitted or were

53
00:04:50,820 --> 00:04:58,320
received signals to or from a device and used information like angle of arrival, time

54
00:04:58,320 --> 00:05:04,860
difference of arrival, or absolute timing offsets to calculate ranging and bearing data and

55
00:05:04,860 --> 00:05:09,020
figure out where the device was. And that worked. It's actually very fast. It's one of the

56
00:05:09,020 --> 00:05:14,060
fastest ways to find someone generally. The problem is it's not terribly precise. With those

57
00:05:14,060 --> 00:05:20,080
sorts of methods, you can get within 200 to 300 meters very quickly, but you'll never get down to

58
00:05:20,820 --> 00:05:27,700
some tens of meters. It just doesn't work that way. So that was the typical technology in

59
00:05:28,260 --> 00:05:34,260
CDMA, or excuse me, in GSM networks. Because in GSM networks, that was what was convenient.

60
00:05:34,460 --> 00:05:39,860
They had the right sort of signal structure to do that kind of ranging. CDMA had at the time a

61
00:05:39,860 --> 00:05:44,400
really cool advantage, which is when I talked about the way GPS satellites sing little songs,

62
00:05:44,600 --> 00:05:49,800
they're actually doing that in kind of a version of CDMA. All the satellites transmit on the

63
00:05:49,800 --> 00:05:50,800
same frequency. And that's what they're doing. And that's what they're doing. And that's what

64
00:05:50,820 --> 00:05:53,760
they're doing. They're doing it very frequently. But they do it with different pseudo-random

65
00:05:53,760 --> 00:05:59,460
number sequences imposed over that. And you can pick individual satellites out by knowing which

66
00:05:59,460 --> 00:06:03,320
one of those are. You're looking up in an almanac, okay, what satellites should I be able to

67
00:06:03,320 --> 00:06:08,520
see, getting that from the constellation itself even, and using that data to figure out, okay,

68
00:06:08,560 --> 00:06:13,700
what should I listen for. Since CDMA handsets already had correlators inside that could do that

69
00:06:13,700 --> 00:06:18,140
for the networks they were attached to, someone had the bright idea, well, let's just reuse that as

70
00:06:18,140 --> 00:06:20,800
a GPS receiver. And it worked. It worked brilliantly. Now, CDMA has a lot more tasting

71
00:06:20,800 --> 00:06:25,160
Now the trouble was early on there was only one because they only expected you to be carrying

72
00:06:25,160 --> 00:06:30,920
on one voice conversation at a time. So when in the early days they wanted to figure out where

73
00:06:30,920 --> 00:06:36,400
you were for 911 purposes, they actually had to say hold on a second, you're going to hear

74
00:06:36,400 --> 00:06:41,800
silence while I determine your location. And then they would trigger, the 911 center would

75
00:06:41,800 --> 00:06:46,600
trigger something in the carrier network to actually start that process with your device. The

76
00:06:46,600 --> 00:06:50,660
device would listen for the satellites, collect the data, correlate it, ship it off to the

77
00:06:50,660 --> 00:06:55,120
network, the network would calculate your position and relay it via a database to the 911

78
00:06:55,120 --> 00:06:59,480
center. Really kludgy and you don't want to tell somebody in the midst of an emergency, please

79
00:06:59,480 --> 00:07:05,580
hold, right? That's not a great thing to tell someone when they're like screaming to death. So

80
00:07:05,580 --> 00:07:10,200
over time we got better, we got better chips with more correlators, we got to the point that we

81
00:07:10,200 --> 00:07:14,480
could actually put GPS chips in almost every phone and these days that's what everybody does.

82
00:07:14,600 --> 00:07:19,180
We have GPS chips. Most of the network technologies have sort of gone away. We still have

83
00:07:19,180 --> 00:07:20,640
two out there called GPS chips. We have GPS chips. We have GPS chips. We have GPS chips. We have

84
00:07:20,640 --> 00:07:26,760
advanced forward link trilateration which is a ranging technology used mostly in CDMA networks

85
00:07:26,760 --> 00:07:33,780
and then OTDOA which stands for observed time difference of arrival. How many navigation nerds

86
00:07:33,780 --> 00:07:40,200
are there in the room who have heard of Loran? Okay, we got a few people. Good. So this is the

87
00:07:40,200 --> 00:07:46,400
really cool thing. OTDOA is just Loran with cell towers instead of Loran chains. You just listen

88
00:07:46,400 --> 00:07:50,560
for the time differences between transmissions of synchronized towers and then you can

89
00:07:50,640 --> 00:07:55,260
use that to do hyperbolic ranging which is really fun. It's kind of a cool sort of thing. Again,

90
00:07:55,320 --> 00:08:02,340
it's one of these network technologies that are fast but not necessarily super precise. All

91
00:08:02,340 --> 00:08:08,520
well and good, okay, fine, you've got a measurement system. What do we do with that now? In

92
00:08:08,520 --> 00:08:13,900
the 911 case, and I said this before, we're not tracking you. We don't want that stuff running all

93
00:08:13,900 --> 00:08:17,380
the time because frankly we don't have anything to do with the data and it's really not of any

94
00:08:17,380 --> 00:08:20,620
interest to us. We need to know where you are, when you have it and we need to know where you are

95
00:08:20,640 --> 00:08:25,100
in an emergency. You don't want that going on obviously for privacy reasons otherwise you

96
00:08:25,100 --> 00:08:29,420
wouldn't be in the crypto privacy village and you also don't want it going on because it's a very

97
00:08:29,420 --> 00:08:34,600
battery intensive activity to keep track of yourself precisely all the time. In fact, most of

98
00:08:34,600 --> 00:08:40,080
the things that you see, you know, this question why is it that Uber can find me but 911 can't

99
00:08:40,080 --> 00:08:45,400
that we hear so often, I really hate this question because like most of the time Uber is not,

100
00:08:45,620 --> 00:08:50,480
Uber doesn't, hasn't measured where you are to any degree of certainty. They have soft

101
00:08:50,640 --> 00:08:57,560
ware in your device platform and in their platform that's making a very educated guess. People

102
00:08:57,560 --> 00:09:02,360
tend to focus on the little blue dot that tells you where the thing thinks you are. What they

103
00:09:02,360 --> 00:09:06,700
often don't realize is that there's also a blue circle around that. There's some uncertainty

104
00:09:07,360 --> 00:09:14,020
associated with that location fix and often in the case of commercial apps on smart phones that

105
00:09:14,020 --> 00:09:19,140
uncertainty is actually relatively large. It can be on the order of hundreds or even thousands of

106
00:09:19,140 --> 00:09:26,360
meters. That's calculated at about a 90% confidence level most of the time, which we want. We want

107
00:09:26,360 --> 00:09:31,060
about a, only about a 10% margin that will find you outside the circle. But if you think about a

108
00:09:31,060 --> 00:09:37,840
place like Caesar's Palace, an uncertainty of a hundred meters or 200 meters makes it really

109
00:09:37,840 --> 00:09:43,000
difficult to find someone. It makes it really difficult to go search for them. 200 meters might

110
00:09:43,000 --> 00:09:48,900
put me in any one of three different hotel towers, the casino, the conference center and a bunch of

111
00:09:48,900 --> 00:09:49,120
restaurants. I don't want to be in any of those. I don't want to be in any of those. I don't want to

112
00:09:49,120 --> 00:09:52,920
be in any other restaurants. So you really have to deal with constraining that uncertainty

113
00:09:52,920 --> 00:09:58,540
somehow before you can use that for emergency response. Uber can make those guesses because it

114
00:09:58,540 --> 00:10:03,860
has that ability then ask you, okay where are you in fact? Does this match up and if not drag the

115
00:10:03,860 --> 00:10:09,120
map and pick the little dot. We don't have that luxury in 911. So I've said that we're not

116
00:10:09,120 --> 00:10:14,700
tracking you. Well what are we doing? When you call 911 a few things happen. I've talked about

117
00:10:14,700 --> 00:10:19,100
some of the different methods that we've used. We're starting to add things. We're still

118
00:10:19,100 --> 00:10:24,500
from the handset now. Historically only stuff that was baked into the baseband or the

119
00:10:24,500 --> 00:10:29,320
network was really available for 911. But these days we're actually doing a lot more than

120
00:10:29,320 --> 00:10:34,120
that. This is bleeding edge stuff that's just starting to come into the devices but we're

121
00:10:34,120 --> 00:10:39,880
starting to be able to use Wi-Fi and Bluetooth both to do sort of associative location to

122
00:10:39,880 --> 00:10:45,480
say look we know that Trey's Wi-Fi access point is at this particular address in this town

123
00:10:45,480 --> 00:10:51,380
because he's there all the time and he's associated with that and so on. So if the phone can

124
00:10:51,380 --> 00:10:58,640
see Trey's Wi-Fi access point that's probably a location of association that we can use as a

125
00:10:58,640 --> 00:11:02,720
starting point for a search. It's kind of a probabilistic sort of thing. That's a very

126
00:11:02,720 --> 00:11:07,420
uncomfortable proposition for 911. We want things to be deterministic. We want to be able to

127
00:11:07,420 --> 00:11:10,680
say to the cops and firefighters in the field who really couldn't find their way out of the

128
00:11:10,680 --> 00:11:15,400
building without our help that you know this is how you this is exactly where

129
00:11:15,400 --> 00:11:19,920
to go. But that's not realistic. That's just not the way the physics of measurement work.

130
00:11:21,240 --> 00:11:26,480
And that's why you know the other thing that we're looking at Bluetooth beacons. You put

131
00:11:26,480 --> 00:11:31,500
Bluetooth low energy in a light bulb for lots of really great reasons. One of the things you

132
00:11:31,500 --> 00:11:39,040
can do with that is associate that UUID that Bluetooth beacon ID with that location in a

133
00:11:39,040 --> 00:11:43,440
database. We're working on something called the National Emergency Address Database which

134
00:11:43,440 --> 00:11:45,380
will actually associate Wi-Fi maps with the location of that location in a database. We're

135
00:11:45,400 --> 00:11:47,560
working on that. So we're going to be able to associate Wi-Fi maps and Bluetooth UUIDs with

136
00:11:47,560 --> 00:11:53,660
physical locations in the world. So that if for example there's a beacon in this particular

137
00:11:53,660 --> 00:11:58,960
ballroom I can be localized if I'm within you know 10 to 30 meters of that I can be localized

138
00:11:58,960 --> 00:12:04,620
very, very precisely with that. But of course that takes getting a lot of beacons out in the

139
00:12:04,620 --> 00:12:09,480
world. Thank you Internet of Things that's going to be easy. But then it also it means we've got

140
00:12:09,480 --> 00:12:13,420
to track those things and make sure that if they move we find out about it. That you know

141
00:12:13,420 --> 00:12:15,380
there's some aging in the database to make sure that we're able to track those things. So

142
00:12:15,400 --> 00:12:22,280
as things get older we trust them less to provide location and so on. So at call time when you

143
00:12:22,280 --> 00:12:29,240
make a 911 call a couple of things happen. First off the your platform your phone platform

144
00:12:29,240 --> 00:12:33,620
whether it's Android, iOS, Blackberry whatever completely overrides your location privacy

145
00:12:33,620 --> 00:12:39,100
settings. It says look you've made a 911 call this is really important turn everything on we

146
00:12:39,100 --> 00:12:45,060
need to find you. Historically that's only meant like the GPS chip and you know not some of the

147
00:12:45,060 --> 00:12:48,400
other cool things that you have in there like the accelerometers, gyroscopes, magnetometers,

148
00:12:48,540 --> 00:12:53,000
barometers, Wi-Fi, Bluetooth, etc. But we're working to change that. We're actually working to

149
00:12:53,000 --> 00:12:58,820
get to the point where we can ingest data from all of those different things to create something

150
00:12:58,820 --> 00:13:05,340
called device based hybrid. And this is where we you know use those use things opportunistically

151
00:13:05,340 --> 00:13:13,640
where they make sense. So GNSS, GPS, Galileo, GLONASS, Compass Baidu all of those things work

152
00:13:13,640 --> 00:13:21,640
phenomenally well outdoors in urban and suburban environments and even to some extent in sort of

153
00:13:21,640 --> 00:13:27,880
urban clusters. Not necessarily in Manhattan and San Francisco and downtown Atlanta and Chicago in

154
00:13:27,880 --> 00:13:34,200
those places GPS is really really awful. But Wi-Fi and Bluetooth things have much higher

155
00:13:34,200 --> 00:13:38,440
densities in those environments and consequently they are of more use. And so this is the

156
00:13:38,440 --> 00:13:43,580
concept behind device based hybrid is we're going to opportunistically use what is best in

157
00:13:43,640 --> 00:13:48,260
the environment that it's in. So if you're in Manhattan and the best thing we have to like figure

158
00:13:48,260 --> 00:13:52,520
out where you are is Wi-Fi and Bluetooth we'll use that. And if not if you're out some place

159
00:13:52,520 --> 00:14:00,160
where GPS is working great we'll use that. All of this is just just sort of starting to happen.

160
00:14:01,080 --> 00:14:07,100
We've had one company called Rapid SOS that built some really cool stuff to kind of get location

161
00:14:07,100 --> 00:14:13,620
data around the database limitations of the legacy 911 network. And in doing so we're going to be

162
00:14:13,640 --> 00:14:18,960
doing that they've kind of proven out that you can you can get a lot more calls clustered down in

163
00:14:18,960 --> 00:14:25,520
that you know zero to 20 meter range with device based hybrid. And I don't mean to like endorse

164
00:14:25,520 --> 00:14:30,740
Rapid or something like that. There are tons of folks working on this. Google just announced a few

165
00:14:30,740 --> 00:14:35,140
months back that they're going to be doing a lot more in their fused location provider for

166
00:14:35,140 --> 00:14:40,040
emergency services purposes over the next three or four years. Including and this I thought this

167
00:14:40,040 --> 00:14:43,620
was really cool. They're putting dual frequency GPS receivers in their devices. They're putting dual

168
00:14:43,620 --> 00:14:46,700
frequency GPS receivers in their devices. Which allows you to directly measure and cancel the

169
00:14:46,700 --> 00:14:53,380
ionospheric diffraction delay. And that is the primary source of error in a GPS fix. So in three

170
00:14:53,380 --> 00:14:59,040
to four years your handset GPS locations indoors and out are going to be phenomenally better.

171
00:14:59,180 --> 00:15:05,780
They really will just get meaningfully better. We're also seeing barometers go into devices which

172
00:15:05,780 --> 00:15:13,600
is really cool. These allow us to implicitly pull out a vertical location. So if you have a device

173
00:15:13,620 --> 00:15:29,700
location. If you have. I've gone dead. If you happen to have. I think so. There we go. We're

174
00:15:29,700 --> 00:15:36,140
back. If you happen to have a barometer and you have a good external reference for what sea level

175
00:15:36,140 --> 00:15:41,380
pressure is, you can use those measurements. You can compare them and say, okay, I must be this

176
00:15:41,380 --> 00:15:43,600
much up or down from that reference data. If you happen to have a barometer and you have a good

177
00:15:43,620 --> 00:15:47,860
system. Now in order to do this, you've got to have measurements that are fairly localized. And

178
00:15:47,860 --> 00:15:53,720
so, you know, another example, this company, Nexnav, their idea is to put sort of pseudo lights

179
00:15:53,720 --> 00:15:59,700
or fake GPS satellites on cell towers and buildings. And broadcast basically their own GPS

180
00:15:59,700 --> 00:16:06,500
signal down at 900 megahertz where it penetrates deep into buildings. And to broadcast as part of

181
00:16:06,500 --> 00:16:13,600
that hyper local barometric pressure corrections that let them pull up exactly the height of the

182
00:16:13,620 --> 00:16:17,340
barometer. And so you can see the distance that you are at with a great deal of reliability. Now,

183
00:16:17,400 --> 00:16:21,400
what do we know about 900? 900 is the junk band. Right? Everything awful is in there. It's

184
00:16:21,400 --> 00:16:25,800
completely useless other than wireless meter readers who just sit on top of everything. Except

185
00:16:25,800 --> 00:16:32,800
that the one thing that is actually privileged in 900 megahertz is multilateration and location

186
00:16:32,800 --> 00:16:38,720
monitoring services. And there are licenses. And these guys happen to have a lot of them. There

187
00:16:38,720 --> 00:16:43,100
are other folks who have them for other markets, but this is like a cool thing that you can do in the

188
00:16:43,100 --> 00:16:48,240
the 900 megahertz band and you get, you actually get interference protection if you do this.

189
00:16:49,100 --> 00:16:54,800
So another cool thing. When you make that 911 call, all of this stuff kicks on and starts

190
00:16:54,800 --> 00:17:02,860
saying, okay, now where are you? Initially when your 911 call arrives at a 911 center, most

191
00:17:02,860 --> 00:17:09,520
likely we will not have good location data at the start of the call. What typically happens,

192
00:17:09,520 --> 00:17:14,840
and this was something called phase one and phase two. Phase one location is what we get at the

193
00:17:14,840 --> 00:17:21,840
beginning of basically every wireless call. And it just tells us the street address of the cell

194
00:17:21,840 --> 00:17:28,180
tower that you're attached to. And it's the GPS coordinates of the tower. Again, this is not you,

195
00:17:28,240 --> 00:17:35,500
this is the tower. And it tells us the central bearing of the cell sector that's serving you. So

196
00:17:35,500 --> 00:17:39,120
if you look up at a cell tower, it's usually kind of triangular. It's got antennas on the

197
00:17:39,120 --> 00:17:39,500
vertical. It's got a little bit of a curve. It's got a little bit of a curve. It's got a little

198
00:17:39,500 --> 00:17:44,680
vertices of the triangle. Each of those has a particular central bearing. It's serving about 60

199
00:17:44,680 --> 00:17:50,740
to 120 degrees. And so by knowing that kind of general bearing and then asking you questions,

200
00:17:50,920 --> 00:17:57,440
hopefully we can figure out, if you don't know, where you are. The way all of that works is

201
00:17:57,440 --> 00:18:02,620
super kludgy. It actually happens because of a database process that got started in the 1980s

202
00:18:02,620 --> 00:18:09,280
built for the wireline world. And that's why before we can get your more precise location, we have

203
00:18:09,280 --> 00:18:14,580
to wait a period of time for a couple of processes to happen. So first of all, the device has to

204
00:18:14,580 --> 00:18:21,360
actually calculate a fix that is better than whatever it had from, you know, the tower and so

205
00:18:21,360 --> 00:18:27,480
forth. And then it has to communicate that back to the carrier network. The carrier network has to

206
00:18:27,480 --> 00:18:33,720
pass that to a database management system provider. They have to further process it and

207
00:18:33,720 --> 00:18:39,260
implant it into the database that ultimately your local telephone company will use to

208
00:18:39,260 --> 00:18:45,360
maintain it because it was the one that they maintained for that wireline process oh, so long

209
00:18:45,360 --> 00:18:52,960
ago. Then at that point, the 911 center system either automatically or manually can re-query the

210
00:18:52,960 --> 00:19:00,600
database and say, okay, is there anything better? And typically by the 15 to 25 second mark is

211
00:19:00,600 --> 00:19:07,560
when we'll start to see an improvement. Something like a GPS fix that's within the allowable error

212
00:19:07,560 --> 00:19:09,240
range. The carriers have, you know, they've got a lot of data. They've got a lot of data that

213
00:19:09,260 --> 00:19:15,360
they have to hit. Ultimately those are going to get down to 50 meters horizontally and some

214
00:19:15,360 --> 00:19:20,540
number vertically that we don't know exactly what it will be yet, but we're working on that. Or a

215
00:19:20,540 --> 00:19:24,480
dispatchable address. And dispatchable address is the process I talked about before with the

216
00:19:24,480 --> 00:19:33,000
database piece of it. Now, the one sort of worrisome part about this is those values, those

217
00:19:33,000 --> 00:19:38,000
location values, we know they're very sensitive. Those are actually transmitted in the clear. But

218
00:19:38,000 --> 00:19:39,240
they're transmitted in the clear. They're transmitted in the clear. They're transmitted in the clear.

219
00:19:39,260 --> 00:19:45,520
Only within sort of trusted carrier networks and then only on the network's control plane. So the

220
00:19:45,520 --> 00:19:51,220
location information never touches the user data plane until it actually gets down to the 911

221
00:19:51,220 --> 00:19:58,580
center and it is received at the start or, you know, some number of seconds into your call. And

222
00:19:58,580 --> 00:20:05,100
then at that point, we kind of, we look at this as like a hot potato. We'll keep that, store it as

223
00:20:05,100 --> 00:20:09,240
long as we have to, to provide you with service. And then at that point, we kind of, we look at

224
00:20:09,240 --> 00:20:09,420
this as like a hot potato. We'll keep that, store it as long as we have to, to provide you with service. And

225
00:20:09,420 --> 00:20:14,980
to keep the sort of records that 911 centers are legally obliged to keep for whether it's for

226
00:20:14,980 --> 00:20:19,460
investigatory purposes or just because the legislature said we want everything to be kept for

227
00:20:19,460 --> 00:20:24,000
90 days or 120 days. Some things may get archived if they look like they're going to be

228
00:20:24,000 --> 00:20:30,380
important down the line. But not necessarily everything. I mean, we typically want to get rid

229
00:20:30,380 --> 00:20:35,960
of non-critical 911 data that's not subject to a litigation hold as quickly as possible. We

230
00:20:35,960 --> 00:20:37,620
really just want to get that out of the system.

231
00:20:39,280 --> 00:20:45,680
This is where it gets a little interesting because obviously being in public safety, 911 is

232
00:20:45,680 --> 00:20:52,740
part of a lot of law enforcement responses. A lot of law enforcement responses start as a result of

233
00:20:52,740 --> 00:21:01,120
a 911 call. In fact, almost all of them do. And 911 is known for having location data. People in

234
00:21:01,120 --> 00:21:05,900
the law enforcement and fire and EMS communities know that when you call 911, we get your

235
00:21:05,900 --> 00:21:09,220
location data. And so people not, unfortunately, don't have a lot of information about 911.

236
00:21:09,240 --> 00:21:13,640
So we reasonably often make the assumption that, well, if I need that for some other purpose, the

237
00:21:13,640 --> 00:21:18,660
way I should be able to get that is by just going to my friendly neighborhood 911 outfit and

238
00:21:18,660 --> 00:21:23,720
saying, hey, help me out with some of that good, good location data. Right? And we get those

239
00:21:23,720 --> 00:21:29,160
requests all the time. Our members actually get location data requests from law enforcement and

240
00:21:29,160 --> 00:21:35,180
fire and EMS often when there's no actual 911 call going. So I said earlier, 911 really is on

241
00:21:35,180 --> 00:21:39,220
the front line of protecting user privacy because often, the people that I'm talking to are the

242
00:21:39,220 --> 00:21:44,300
The thing we have to do is tell sometimes even the boss, no. Because we get 911 data for a

243
00:21:44,300 --> 00:21:49,340
purpose. We use it for a purpose. And that's part of user trust in the 911 system is that we're not

244
00:21:49,340 --> 00:21:56,180
going to misuse that 911 location data. The other reason that these things happen from time to time

245
00:21:56,180 --> 00:22:03,240
is we also have access to a process for exigent circumstances. So if you've ever seen the movie

246
00:22:03,240 --> 00:22:09,200
The Call with Halle Berry, so small aside, I got to meet Halle Berry. She is amazing in person.

247
00:22:09,340 --> 00:22:14,540
She is even more beautiful and even more friendly and awesome and wonderful. And she really took a

248
00:22:14,540 --> 00:22:19,460
lot of time and effort to get in the trenches with real 911 call takers and learn how they do what

249
00:22:19,460 --> 00:22:24,760
they do, which was really awesome and cool. Hopefully there will be a sequel. But in that movie

250
00:22:24,760 --> 00:22:32,140
there was this occasion where a young woman was kidnapped and thrown in a trunk. And she made a

251
00:22:32,140 --> 00:22:33,220
very, she was only able to get out of the car and she was able to get out of the car and she

252
00:22:33,220 --> 00:22:38,900
was able to make a quick discreet 911 call to say, you know, help, I'm in the trunk, right? When

253
00:22:38,900 --> 00:22:45,340
that happens, we've got to have some process to get some location data when you're not on a 911

254
00:22:45,340 --> 00:22:50,120
call. Now the challenge for us is, as I talked about before, all of the location privacy

255
00:22:50,120 --> 00:22:57,060
settings and all of those sensors and measurement systems are not on unless you're in a 911

256
00:22:57,060 --> 00:23:03,200
call. So the moment you hang up, we lose the ability to query for updated location data. And

257
00:23:03,200 --> 00:23:12,740
at that point, the best we can do, and I realize this sounds insane in 2017, is fax, yes, fax a

258
00:23:12,740 --> 00:23:20,340
form to the carrier that was serving that 911 call to say, we need the best location data you've

259
00:23:20,340 --> 00:23:27,620
got for this particular phone number. The turnaround time for that can be 15 to 45 minutes.

260
00:23:27,920 --> 00:23:32,520
They generally, they do take it very seriously. They try to get the exigent circumstances request

261
00:23:32,520 --> 00:23:38,200
processed as quickly as possible. But it is still a process. It's not an automated kind of thing.

262
00:23:38,280 --> 00:23:44,180
It is a very manual process. And then what happens once the carriers, lawyers and engineers have

263
00:23:44,180 --> 00:23:49,340
looked at the form and said, okay, yes, this is a valid exigent circumstances request. There

264
00:23:49,340 --> 00:23:56,620
really is an ongoing emergency with a threat to life or property. Then and only then can they

265
00:23:56,620 --> 00:24:02,420
start to do a little bit to help us. But again, you're not in a 911 call. They can't turn on all the

266
00:24:02,420 --> 00:24:02,500
sensors. They can't do any of the things that we're doing. So we're going to do a little bit of a

267
00:24:02,500 --> 00:24:04,700
look at that. So we're going to do a little bit of a look at the sensors. Typically the best we can

268
00:24:04,700 --> 00:24:10,680
do is we fall back to that sort of phase one information. We can typically get, okay, what

269
00:24:10,680 --> 00:24:17,580
tower and sector is serving the device. So we get, you know, kind of a point and a bearing. And

270
00:24:17,580 --> 00:24:24,120
if we're really, really lucky, in some cases, they will also be able to give us a range estimate.

271
00:24:24,420 --> 00:24:29,220
So I talked before about, you know, GPS and the way the ranges kind of cross over and you can get a

272
00:24:29,220 --> 00:24:32,480
location out of that. Another way you can develop a location fix is you can get a location fix

273
00:24:32,500 --> 00:24:38,740
is with a bearing and a range. So that's a line and an arc and wherever they cross, that's sort of

274
00:24:38,740 --> 00:24:43,180
generally where you are because, again, our measurements are kind of fuzzy. That arc can be

275
00:24:43,180 --> 00:24:49,260
really wide. That line can be really thick. You get kind of an annular sector. But, hey, that's

276
00:24:49,260 --> 00:24:55,380
still useful data. But again, it's not data that we're getting easily. It's something that's very,

277
00:24:55,460 --> 00:25:00,980
very protected. And in the 911 case, when we do get that, again, that's a manual process. So

278
00:25:00,980 --> 00:25:02,480
there's no database to put that in. That's a manual process. So there's no database to put that

279
00:25:02,500 --> 00:25:08,180
in. That's actually something that's done on a, you know, we're on the phone with AT&T, Verizon,

280
00:25:08,400 --> 00:25:12,920
Sprint, T-Mobile, somebody, saying, okay, where are they now? Okay, has the location changed?

281
00:25:13,040 --> 00:25:17,080
Where are they now? And it's this very sort of iterative manual thing. And eventually,

282
00:25:17,220 --> 00:25:22,340
hopefully, you can work out, okay, it's a car that's going down, you know, I-40 or something

283
00:25:22,340 --> 00:25:28,840
like that, and say, let's go try to intercept whatever that is and find somebody. And then, of

284
00:25:28,840 --> 00:25:32,480
course, immediately after that exigent circumstance passes, you can get a location fix that

285
00:25:32,500 --> 00:25:38,020
passes, that location data that was used for that purpose basically has to go away. Because it

286
00:25:38,020 --> 00:25:44,180
wasn't necessarily obtained with an investigative purpose for law enforcement purposes. So then,

287
00:25:44,300 --> 00:25:48,820
you've got to start thinking about, okay, do we get a subpoena? Do we get a warrant? How do we

288
00:25:48,820 --> 00:25:56,540
actually acquire that location data in a way that can be used for some criminal prosecutorial

289
00:25:56,540 --> 00:26:02,400
purpose that's not, you know, related to an immediate emergency response? So that's

290
00:26:02,500 --> 00:26:07,680
kind of the multiple phasic approach that you have within the 911 center. We have the sort of

291
00:26:07,680 --> 00:26:15,260
baseline case. Weirdly, I often hear people say 112, which is the European emergency number, is

292
00:26:15,260 --> 00:26:21,240
really part of the global emergency calling standard, and you should use that. And in a lot of

293
00:26:21,240 --> 00:26:27,700
places, using 112 might actually get you to a 911 center. Like, it might. It won't always, but

294
00:26:27,700 --> 00:26:32,320
it might. And if it does, the challenge, though, is it won't turn on, usually, any of that

295
00:26:32,320 --> 00:26:39,660
cool location stuff. So don't dial 112 unless you're in Europe. Once that location process is

296
00:26:40,360 --> 00:26:46,200
over with, there is sort of a residual question of what do we do with the data? And I don't think

297
00:26:46,200 --> 00:26:52,620
we have a good answer right now, because your average 911 center is not technically

298
00:26:52,620 --> 00:26:58,920
sophisticated enough to be encrypting or hashing or doing things like that with those sorts of

299
00:26:58,920 --> 00:27:02,300
data. They kind of have to rely on whatever their system vendor might be. And that's kind of the

300
00:27:09,100 --> 00:27:15,080
thing we're working on. So the next piece of this that I want to talk about is how we will acquire

301
00:27:15,080 --> 00:27:22,680
and use location information in a next generation 911 environment. And basically, the process

302
00:27:22,680 --> 00:27:28,240
still stays heavily dependent on what the device and the network knows. But now, instead of

303
00:27:28,240 --> 00:27:32,300
dealing with legacy wireline databases from the late 70s, early 80s, we're going to be dealing with

304
00:27:32,320 --> 00:27:39,640
these. We're going to take this into a more IP-based realm. So in next generation 911, when you

305
00:27:39,640 --> 00:27:45,380
dial 911 from a phone, whether that's a voice call to 911 or a video call or even a text session,

306
00:27:45,520 --> 00:27:49,540
we're going to have realtime text very soon. Or total conversation. If you have, you know,

307
00:27:49,560 --> 00:27:53,860
different accessibility needs, you'll have the ability to communicate in all of those different

308
00:27:53,860 --> 00:27:59,400
ways simultaneously, which is really awesome if you have a hearing or speech disability. At that

309
00:27:59,400 --> 00:28:04,200
point you've got a couple of things that have to happen. First, the device needs to figure out

310
00:28:04,200 --> 00:28:11,540
what 911 system its call should go to. So it's going to query something in the access network

311
00:28:11,540 --> 00:28:16,560
provider's network. And here I want to stop and define a couple of terms because historically

312
00:28:16,560 --> 00:28:21,240
when you bought phone service from the phone company you were really buying two very

313
00:28:21,240 --> 00:28:26,020
different things but it looked like the same thing because it was all you knew. When you bought

314
00:28:26,020 --> 00:28:32,200
voice service from the phone company you were buying first off a transport network. So that's an

315
00:28:32,200 --> 00:28:37,480
access network that is capable of moving things around. But you were also buying an originating

316
00:28:37,480 --> 00:28:43,100
service. The ability to connect from one endpoint to another endpoint using some particular

317
00:28:43,100 --> 00:28:49,980
address. Today networks don't have to do all of those things in an integrated way. I can buy my

318
00:28:49,980 --> 00:28:55,940
access network service from for example AT&T and I can buy my voice originating service

319
00:28:55,940 --> 00:29:03,100
from Vonage for example. We have to accommodate that in the 911 system. We have to be able to deal

320
00:29:03,100 --> 00:29:09,000
with the fact that your carrier is no longer just the phone company. It may be somebody else.

321
00:29:09,480 --> 00:29:14,160
Historically we have not done a good job of that because we've just bolted stuff on to the 911

322
00:29:14,160 --> 00:29:19,440
systems over the years and we haven't really integrated a lot of these new technologies into

323
00:29:19,440 --> 00:29:25,560
the way the system works. So your device goes to the access network provider. Well okay why?

324
00:29:25,940 --> 00:29:31,220
Well the infrastructure provider they know where their wires go. They know where their cell

325
00:29:31,220 --> 00:29:36,600
towers are. They're the ones who have the sort of intimate real world physical connection with

326
00:29:36,600 --> 00:29:43,220
you that can be used to start that process of localizing the call. So your device goes and

327
00:29:43,220 --> 00:29:50,700
queries their location information server. It gets back currently actually location by value. It

328
00:29:50,700 --> 00:29:55,580
gets sort of your here generally. Although we're trying to be very careful about giving that to

329
00:29:55,580 --> 00:30:00,680
devices because you know we can see a state where you might have malware on the device and you

330
00:30:00,680 --> 00:30:04,340
don't necessarily want to disclose location to that. So we're working on some cryptographic stuff

331
00:30:04,340 --> 00:30:09,220
to try and keep that private as well to basically tokenize it so that then the device can pass

332
00:30:09,220 --> 00:30:13,740
either that location value or that token to something called an emergency services routing

333
00:30:13,740 --> 00:30:20,820
proxy. And the purpose there is for the proxy to say to a big thing called a forest guide which

334
00:30:20,820 --> 00:30:25,560
is basically a hierarchical database structure that tells you here are all the data that you

335
00:30:25,560 --> 00:30:29,240
have. Where are all the countries in the world. What are their boundaries. Within those what are

336
00:30:29,240 --> 00:30:34,120
the states. Within those what are the counties. Within those what are the 911 center service

337
00:30:34,120 --> 00:30:39,680
areas. And oh by the way you're there. Great you go to this 911 center. That's where your call

338
00:30:39,680 --> 00:30:47,720
should go. So this involves a lot of GIS processing. That's geospatial information system. I

339
00:30:47,720 --> 00:30:52,460
think I have a slide here that actually shows some of that. So we actually have a standard for

340
00:30:52,460 --> 00:30:55,540
geospatial information systems. Remember I said we have a standard for geospatial information systems.

341
00:30:55,560 --> 00:31:00,740
I talked about that old school way of doing the database of addresses where you have a list of

342
00:31:00,740 --> 00:31:05,980
street names. A table of street names. And a table of valid number ranges. That's all well and

343
00:31:05,980 --> 00:31:10,900
good if you only need to locate people in like row houses. But what if you have an apartment

344
00:31:10,900 --> 00:31:15,420
building. How do we know that a floor number is valid. How do we know that a room number is

345
00:31:15,420 --> 00:31:22,740
valid. And moreover how do we decide where do all of those 911 calls within that thing go. For

346
00:31:22,740 --> 00:31:25,540
example if I'm Caesars Palace I'm not going to be able to locate people within that thing. If I'm a

347
00:31:25,540 --> 00:31:30,120
might have my own. I might be a limited municipality. I might have my own response center

348
00:31:30,120 --> 00:31:34,820
that can get you help faster. We might want to route all of the calls within Caesars Palace to

349
00:31:34,820 --> 00:31:39,600
them instead. Disney World is a great example of that. They actually have the Reedy Creek

350
00:31:39,600 --> 00:31:44,000
Improvement District. There are like six Disney executives that have houses like on the

351
00:31:44,000 --> 00:31:48,700
property. They're the entire voting block for the whole city of Reedy Creek. And they actually

352
00:31:48,700 --> 00:31:52,580
have their own 911 center. It's like a best practice place. Everybody loves to hold it up. It's

353
00:31:52,580 --> 00:31:55,520
like shiny and new and a good place to go. But you know it's a good place to go. But you know the

354
00:31:55,540 --> 00:32:01,000
you have to be able to track those things so that you can do change management. So that you can

355
00:32:01,620 --> 00:32:08,380
know when somebody puts up a new building. How do we add that to our addressing system. And then

356
00:32:08,380 --> 00:32:12,560
once you've consulted the forest guide it will give you an IP address for something called the

357
00:32:12,560 --> 00:32:18,780
border control function of the NG 911 system. Next generation 911 system that actually serves

358
00:32:19,140 --> 00:32:25,280
that particular location. At that point the routing proxy whether it's in your access network

359
00:32:25,280 --> 00:32:30,020
provider's network or if it's disaggregated in the originating service provider's network will

360
00:32:30,020 --> 00:32:35,380
actually send signaling and media to that border control function. And then to me the coolest

361
00:32:35,380 --> 00:32:43,260
part of all this is if at some point during the call things change and there's some reason your

362
00:32:43,260 --> 00:32:48,000
location changes or what not and there's some reason to redirect the call either before the

363
00:32:48,000 --> 00:32:54,100
setup is complete or during the call. There's actually an intelligent mechanism to say hey

364
00:32:54,100 --> 00:32:58,740
there's this other 911 center that might need to be involved in this response. Do you

365
00:32:59,300 --> 00:33:03,760
telecommunicator handling the call want to loop them in? Even if it's on like a listen only basis.

366
00:33:04,200 --> 00:33:10,640
And you can do that. And you also get another kind of cool capability is you can have now

367
00:33:10,640 --> 00:33:16,500
specialized 911 centers that deal just with particular populations that have very specific

368
00:33:16,500 --> 00:33:22,800
needs. So for example in Washington D.C. we have one of the largest universities for the deaf and

369
00:33:22,800 --> 00:33:26,880
hard of hearing, Gallaudet. Great school. They actually do a lot of cool engineering work

370
00:33:26,880 --> 00:33:32,900
related to 911 stuff. But if you have a 911 call that's coming from just the area of the Gallaudet

371
00:33:32,900 --> 00:33:38,600
campus you might want to put that into a different queue for someone who has a hot connection with

372
00:33:38,600 --> 00:33:43,780
an ASL interpreter or knows ASL themselves and can handle that video call that way or who's

373
00:33:43,780 --> 00:33:49,220
trained specially to handle real time text calls. And that's something in today's environment we

374
00:33:49,220 --> 00:33:52,780
absolutely can't do because remember back we're routing everything and we're not able to do it

375
00:33:52,800 --> 00:33:58,500
based on that cell tower and the sector. At the beginning of the call that's all we know. In the

376
00:33:58,500 --> 00:34:04,380
future the idea is we're going to route based on the actual XY and hopefully Z someday from the

377
00:34:04,380 --> 00:34:09,580
device and that makes it a lot easier to do much more granular things like that that can really

378
00:34:09,580 --> 00:34:14,700
help. It has a huge impact. If you're in a population that has a specific need like that it's

379
00:34:14,700 --> 00:34:22,380
a really big deal to be able to get to something like that on the first try. Because today one of the

380
00:34:22,800 --> 00:34:28,400
terrible things that happens is if you need to connect with somebody like a video interpreter that

381
00:34:28,400 --> 00:34:34,560
can delay your 911 call on the order of 15 to 30 minutes. And that is not an amount of time you

382
00:34:34,560 --> 00:34:39,420
want to be waiting in an emergency. I've used about 40 minutes here. I haven't had anybody

383
00:34:39,420 --> 00:34:44,380
volunteer questions so I just want to level set. Are there things that I've covered in insufficient

384
00:34:44,380 --> 00:34:50,140
depth or not covered or other things you want to hear about so that I can kind of tune the rest of

385
00:34:50,140 --> 00:34:51,200
the talk? Yep.

386
00:34:54,020 --> 00:34:59,880
So the location data is transmitted in the clear. Is that like from the local device to the base

387
00:34:59,880 --> 00:35:06,640
station or is that afterwards whenever it's going through the actual IP switch stuff? Oh it's

388
00:35:06,640 --> 00:35:11,620
funny you think there's IP switching involved in this. That's very quaint. Yeah. No. So the

389
00:35:11,620 --> 00:35:18,660
question was when I said that location data is transmitted in the clear what part of the sort of

390
00:35:18,660 --> 00:35:22,780
transactional structure was I talking about? So from the device to the network the data is

391
00:35:22,800 --> 00:35:30,480
encrypted at the level of whatever the bearer established. So in LTE it would be encrypted. In

392
00:35:30,480 --> 00:35:37,600
GSM it would be encrypted probably weekly. Same thing in CDMA. Within the carrier network it will be

393
00:35:37,600 --> 00:35:44,280
segregated but not necessarily encrypted. And then the way it's and I know this is why I laughed

394
00:35:44,280 --> 00:35:50,100
about the whole IP switching thing. The way it's actually transmitted within the telephone company

395
00:35:50,100 --> 00:35:52,780
networks is as a series of IP switches. So the way it's actually transmitted within the telephone company networks is as a series

396
00:35:52,780 --> 00:36:00,740
of either medium frequency tones or maybe DTMF in some cases. It's really kind of hilarious how some of

397
00:36:00,740 --> 00:36:06,420
this stuff still actually works. The data block we get with a 911 call I think I said this in

398
00:36:06,420 --> 00:36:14,880
my talk the other day but it bears repeating is 512 maximum. 512 non extended ASCII character set

399
00:36:15,820 --> 00:36:22,240
letters and digits. And that's all. So when you want to represent something like a physical

400
00:36:22,240 --> 00:36:28,040
location, that's all you've got to work with. And so we've really had to figure out how do we

401
00:36:28,040 --> 00:36:31,940
dumb this stuff down. One of the big things we're looking forward to is once we have these next

402
00:36:31,940 --> 00:36:37,380
gen systems where we can protect it properly, encrypt it, and it is an IP system, is actually

403
00:36:37,380 --> 00:36:42,740
starting to be able to represent things graphically. I think I showed, here's an example

404
00:36:42,740 --> 00:36:48,560
of like an uncertainty around a floor, for example. Today we couldn't do that. We couldn't

405
00:36:48,560 --> 00:36:54,520
pull up a visualization of a building and put circles or ellipsoids or spheres or other things

406
00:36:54,520 --> 00:36:59,980
in there and say, look in this general area, because we have no way of representing that in

407
00:36:59,980 --> 00:37:06,280
the 911 systems that we have. Now, the cool thing is the carrier standard that makes all of this

408
00:37:06,280 --> 00:37:10,640
work at kind of the numerical level is something called J standard 036. I think it's an ATIS

409
00:37:10,640 --> 00:37:18,080
slash TIA standard. It actually defines the ability to send different geometric shapes. So I

410
00:37:18,080 --> 00:37:18,540
can see, I can see, I can see, I can see, I can see, I can see, I can see, I can see, I can

411
00:37:18,540 --> 00:37:21,720
see, I can see. I can see. I can send an ellipsoid point with uncertainty, I can send

412
00:37:21,720 --> 00:37:27,640
a point with spherical uncertainty, I can start to do you know, annular segment, things like

413
00:37:27,640 --> 00:37:31,140
that, nobody does that, because again we don't have any way to represent it today.

414
00:37:32,800 --> 00:37:40,580
So the question was, what percentage when it comes to dispatch is sent in the clear as

415
00:37:40,580 --> 00:37:46,220
opposed to bridぁal, encrypted. So the question was, what percentage when

416
00:37:46,220 --> 00:37:48,520
it comes to dispatch is sent in the clear. I don't know what percentage. I think the

417
00:37:48,520 --> 00:37:54,820
versus encrypted or perhaps digital. I assume you mean and I

418
00:37:54,820 --> 00:37:58,980
assume you mean the radio part. Okay. So the radio part of

419
00:37:58,980 --> 00:38:01,160
dispatch, how much of it is encrypted, how much of it is in

420
00:38:01,160 --> 00:38:05,100
the clear. Overwhelmingly it's in the clear. There are places

421
00:38:05,100 --> 00:38:11,740
that are starting to do more encrypted communications. Badly

422
00:38:11,740 --> 00:38:15,660
in most cases. If you look Matt Blaze, Travis Goodspeed and some

423
00:38:15,660 --> 00:38:18,780
folks did an analysis a few years back of one like the

424
00:38:18,780 --> 00:38:22,400
dominant public safety radio standard in the U.S. and found

425
00:38:22,400 --> 00:38:26,360
that it was basically hopelessly insecure. They used a really

426
00:38:26,360 --> 00:38:31,580
weak kind of even more broken version of RC4 as the stream

427
00:38:31,580 --> 00:38:34,780
cipher in some commercial implementations that were very

428
00:38:34,780 --> 00:38:38,680
cheap. And so everybody used those even though they weren't

429
00:38:38,680 --> 00:38:41,220
terribly interoperable and they're not at all secure. So

430
00:38:41,220 --> 00:38:43,680
we're in the process of trying to fix that. Earlier this year

431
00:38:44,330 --> 00:38:45,640
the Department of Homeland Security and the Department of

432
00:38:45,660 --> 00:38:49,100
Security and NIST worked together to get a requirement

433
00:38:49,100 --> 00:38:52,720
into the standard so that I think starting in 2018 going

434
00:38:52,720 --> 00:38:57,120
forward all radios built to that standard will now have to have

435
00:38:57,120 --> 00:39:01,980
AES 256 as a mandatory part of their cipher suite. They can

436
00:39:01,980 --> 00:39:06,360
still have broken versions of RC4 but AES 256 has to be in

437
00:39:06,360 --> 00:39:08,580
there as well. And part of the reason for that is in the public

438
00:39:08,580 --> 00:39:11,260
safety community interoperability is a huge deal.

439
00:39:12,100 --> 00:39:15,120
Disasters may start local but they usually don't stay local.

440
00:39:15,660 --> 00:39:19,740
And when they go beyond the, you know, disasters don't obey

441
00:39:19,740 --> 00:39:23,440
jurisdictional lines no matter how much we admonish them. And so

442
00:39:23,440 --> 00:39:25,640
eventually you've got to have help from your neighbor and when

443
00:39:25,640 --> 00:39:29,360
that happens being able to talk with them is a big deal. The

444
00:39:29,360 --> 00:39:32,800
other thing, I appreciate that question about encryption. The

445
00:39:32,800 --> 00:39:35,800
other thing that I want to raise a serious point about though is

446
00:39:36,820 --> 00:39:40,400
authentication and integrity checking. Because even though we

447
00:39:40,400 --> 00:39:44,560
are fixing the encryption problem, sort of, we're getting to a

448
00:39:44,560 --> 00:39:45,640
standard. We're getting to a standard. We're getting to a

449
00:39:45,660 --> 00:39:47,820
standard. We are still not doing anything about protecting

450
00:39:47,820 --> 00:39:53,520
networks from, radio networks from bad devices. So devices that

451
00:39:53,520 --> 00:39:56,500
aren't, that don't belong there. So most of the radio networks

452
00:39:56,500 --> 00:40:00,840
today, if you know like an eight-digit code that is really

453
00:40:00,840 --> 00:40:04,440
easy to pull off the air, you can get a radio attached to that

454
00:40:04,440 --> 00:40:07,220
network and start receiving traffic from it. It's not

455
00:40:07,220 --> 00:40:09,540
authenticated in any way. And then there are also

456
00:40:09,540 --> 00:40:12,480
vulnerabilities to replay attacks in these networks. So you

457
00:40:12,480 --> 00:40:15,640
don't have good integrity mechanisms either. So that's a

458
00:40:16,560 --> 00:40:21,260
problem. It's something we're working on. The trouble is these

459
00:40:21,260 --> 00:40:25,240
are tens of million dollar networks that turn over once

460
00:40:25,240 --> 00:40:29,780
every 15 to 20 years. And the next iteration may just not

461
00:40:29,780 --> 00:40:32,680
happen because they're actually building an LTE network right

462
00:40:32,680 --> 00:40:35,860
now for first responders that's going to be nationwide. So

463
00:40:35,860 --> 00:40:39,220
there's a big debate about well, do we even like keep working on

464
00:40:39,220 --> 00:40:41,900
these standards because at some point we're just going to use

465
00:40:41,900 --> 00:40:45,600
that because it will be better. Not necessarily soon, but it's

466
00:40:45,660 --> 00:40:51,380
going to happen someday. Other questions? Yep.

467
00:40:52,420 --> 00:40:57,500
Do you know, all the location data that gets turned on when you

468
00:40:57,500 --> 00:41:00,340
start a call, does that typically, do you know, get

469
00:41:00,340 --> 00:41:06,080
stored on the device itself also? And is it in such a way that,

470
00:41:06,120 --> 00:41:08,360
you know, law enforcement or something like that could

471
00:41:08,820 --> 00:41:12,160
extract from the phone? So the question was, when you make a

472
00:41:12,160 --> 00:41:15,640
911 call, location stuff turns on. Does the data that you're

473
00:41:15,660 --> 00:41:16,920
talking about, the data that's developed as a result of that

474
00:41:16,920 --> 00:41:19,220
gets stored on the phone in a way that it could be recovered by

475
00:41:19,220 --> 00:41:23,000
forensic analysis, the cops down the line or something. I

476
00:41:23,000 --> 00:41:27,440
don't know a really good answer to that question. The challenge

477
00:41:27,440 --> 00:41:32,580
is there are so many parties involved because there are legal

478
00:41:32,580 --> 00:41:35,440
obligations and interests that the carriers have. There are

479
00:41:35,440 --> 00:41:39,100
very different legal obligations and interests that the handset

480
00:41:39,720 --> 00:41:44,660
manufacturer has. And even the chipset manufacturer, the folks

481
00:41:44,660 --> 00:41:45,640
who are putting those measures on the phone, they're not going

482
00:41:50,060 --> 00:41:52,020
to be able to do that. So I don't know the answer to that,

483
00:41:52,100 --> 00:41:55,720
unfortunately. My hope would be that once the 911 call goes away

484
00:41:55,720 --> 00:41:59,200
that that location data goes away as well. In part because in

485
00:41:59,200 --> 00:42:02,980
the 911 business one of our big concerns is always, well, can we

486
00:42:02,980 --> 00:42:07,440
adequately protect the safety of someone who calls 911 but doesn't

487
00:42:07,440 --> 00:42:11,600
want a third party to know that they have. One tactic that we see

488
00:42:11,600 --> 00:42:15,420
particularly like in an abused spouse situation all the time is

489
00:42:15,660 --> 00:42:20,420
somebody calling 911 and pretending to order pizza. And

490
00:42:20,420 --> 00:42:23,880
when they do that, most clever telecommunicators and

491
00:42:23,880 --> 00:42:27,520
dispatchers will say, you're telling me that you need to order

492
00:42:27,520 --> 00:42:30,240
a pizza because you wanted to call 911 and you don't want

493
00:42:30,240 --> 00:42:34,380
someone else to know. Is that right? Yes, pepperoni. Which is,

494
00:42:34,420 --> 00:42:36,740
you know, so and that's the kind of thing where we don't want

495
00:42:36,740 --> 00:42:39,620
somebody to be able to look at the device and say, oh, you

496
00:42:39,620 --> 00:42:42,500
called 911 from the house where you know you're not supposed to

497
00:42:42,500 --> 00:42:45,280
call anybody. Like that, that would be a potential information

498
00:42:45,660 --> 00:42:50,500
disclosure that would not be good. There's a question right

499
00:42:50,500 --> 00:42:54,020
there? Yep. Could you come up to the mic so that we can get this on

500
00:42:54,020 --> 00:42:58,740
the recording? Yeah. Hello? I don't know if this mic is

501
00:42:58,740 --> 00:43:02,640
actually on. Okay. But can this location data that's collected

502
00:43:02,640 --> 00:43:07,800
also be used to kind of prevent swatting or something like that?

503
00:43:07,980 --> 00:43:13,260
. Okay. The question was can the location

504
00:43:13,260 --> 00:43:15,460
information that is collected be used to prevent

505
00:43:15,660 --> 00:43:19,360
things like, for example, swatting? I promise I did not pay

506
00:43:19,360 --> 00:43:22,120
him to ask that question, but that is like the best possible

507
00:43:22,120 --> 00:43:26,660
question you could ask. It is something that we have been

508
00:43:26,660 --> 00:43:29,720
looking at for a very long time. The answer is yes,

509
00:43:29,880 --> 00:43:35,180
absolutely. It should be used that way every time. I go through

510
00:43:35,180 --> 00:43:40,760
no end of amazement that people don't always check mismatches

511
00:43:40,760 --> 00:43:45,220
like that when there is a call. I do think one of the benefits of

512
00:43:45,660 --> 00:43:48,560
frankly having humans in the loop for 911 calls is that rather

513
00:43:48,560 --> 00:43:52,120
cleverly a lot of the time they do say that and they'll say to

514
00:43:52,120 --> 00:43:55,740
somebody, look, before you go full swat on Brian Krebs again,

515
00:43:57,000 --> 00:43:59,740
maybe let's make sure that this call is actually coming from

516
00:43:59,740 --> 00:44:02,120
there. And the other thing that we've been able to train on is

517
00:44:02,120 --> 00:44:05,180
when you get a call from a non-service initialized device,

518
00:44:05,320 --> 00:44:08,240
so a cell phone that doesn't have service, which is required

519
00:44:08,240 --> 00:44:12,420
to still be able to make a 911 call, treat that as suspect

520
00:44:12,900 --> 00:44:15,640
until you have really, really good information that you can

521
00:44:16,340 --> 00:44:21,040
link it to that person's thing. Now part of the challenge is if

522
00:44:21,040 --> 00:44:23,900
you're too far away from the target of like a swatting attack

523
00:44:23,900 --> 00:44:27,340
in the first place, your call is not going to go to the right 911

524
00:44:27,340 --> 00:44:30,900
center anyway. And then you're going to raise a whole host of

525
00:44:30,900 --> 00:44:34,580
other questions. Like, well, if your call ended up in Boca Raton

526
00:44:35,200 --> 00:44:41,080
but you're calling from Denver, then there's something, clearly

527
00:44:41,080 --> 00:44:44,800
something has happened that we don't expect and that we ought

528
00:44:44,800 --> 00:44:45,620
to be asking more than that. So I think it's really important to

529
00:44:45,640 --> 00:44:48,820
have more questions about. So great, great question. Really

530
00:44:48,820 --> 00:44:51,220
appreciate that. And in NG 911, one of the things we're going to

531
00:44:51,220 --> 00:44:54,740
do is a lot more data analytics capabilities to make sure we're

532
00:44:54,740 --> 00:44:57,720
authenticating things like that. In fact, as I talked about, like

533
00:44:57,720 --> 00:44:59,840
the device-based hybrid and the national emergency address

534
00:44:59,840 --> 00:45:04,320
database and all that, when we were negotiating those new rules

535
00:45:04,320 --> 00:45:07,820
with the wireless carriers and the FCC, that was one of our key

536
00:45:07,820 --> 00:45:12,800
concerns was if they get a Wi-Fi hotspot, for example, out of the

537
00:45:12,800 --> 00:45:15,620
database, and it says this hotspot is here, and then they

538
00:45:15,620 --> 00:45:19,980
get a Wi-Fi hotspot, let's say Caesars Palace in Las Vegas, but the

539
00:45:19,980 --> 00:45:23,580
call came in from a cell tower that was in Knoxville, Tennessee,

540
00:45:24,660 --> 00:45:28,320
okay, you know, Houston, we have a problem, don't use that

541
00:45:28,320 --> 00:45:31,460
location data, fall back, use the tower, use the GPS, whatever

542
00:45:31,460 --> 00:45:35,660
else you've got. So location data that comes from the database

543
00:45:35,660 --> 00:45:39,200
process has to be corroborated going forward. That was a big

544
00:45:39,200 --> 00:45:42,060
deal for us from an integrity standpoint to make sure that we

545
00:45:42,060 --> 00:45:45,060
had corroboration. Yep, in the back.

546
00:45:50,440 --> 00:45:54,760
The question was, is there a 911 app? Let me be really clear. No,

547
00:45:54,980 --> 00:46:01,220
there is not a 911 app. If I could get Apple and Google to do one

548
00:46:01,220 --> 00:46:04,780
thing, it would be to just grep the entire app store, the entire

549
00:46:04,780 --> 00:46:09,160
play store, and delete anything that involves the words 911. They

550
00:46:09,160 --> 00:46:13,820
don't work. They're totally bogus. There's all kinds of things, and I

551
00:46:13,820 --> 00:46:15,600
hate to be this, like, I hate to be this, like, I hate to be this

552
00:46:15,620 --> 00:46:18,420
passionate and upset about it because I love that there are

553
00:46:18,420 --> 00:46:21,920
developers out there trying to do helpful things for people in an

554
00:46:21,920 --> 00:46:25,420
emergency, but the thing that, like, none of the developers,

555
00:46:25,560 --> 00:46:29,060
with maybe one exception, who have ever attacked this problem

556
00:46:29,060 --> 00:46:34,200
have understood is just how much legacy cruft there is that

557
00:46:34,200 --> 00:46:37,180
stands between anything you can do with an app and the 911

558
00:46:37,180 --> 00:46:42,520
system. It just doesn't work. The only, there's been one

559
00:46:42,520 --> 00:46:45,600
startup that's sort of, kind of, halfway cracked, and it's not a

560
00:46:45,620 --> 00:46:50,160
problem, and they literally had to go and build millions of dollars of

561
00:46:50,160 --> 00:46:54,620
infrastructure. They built their own NG 911 system to just do an end run

562
00:46:54,620 --> 00:46:57,800
around the whole thing and then ultimately find some carrier partner

563
00:46:57,800 --> 00:47:04,380
to trunk the calls out to PSAPs. It, no, there is no app that works with 911, and

564
00:47:04,380 --> 00:47:08,720
there won't be. There are very good reasons that you should not do that.

565
00:47:09,260 --> 00:47:15,300
Again, I appreciate people's passion, but, like, it just, it doesn't work. Don't. As, as,

566
00:47:15,800 --> 00:47:21,060
unfortunately, there are dozens of apps on both, of, both of the major platforms that

567
00:47:21,060 --> 00:47:27,440
purport to do something like connect you directly to the nearest police officer. Well, okay, A,

568
00:47:27,600 --> 00:47:32,460
the app provider doesn't know where the nearest police officer is, and B, the only way to

569
00:47:32,460 --> 00:47:36,700
connect to that nearest police officer is over a radio platform that I guarantee you that app

570
00:47:36,700 --> 00:47:42,400
developer knows nothing about. And, moreover, that police officer does not want your 911 call.

571
00:47:42,520 --> 00:47:45,280
Like, that's not the process. You know, they've got, I don't know, they've got a lot of

572
00:47:45,300 --> 00:47:50,380
other stuff going on. You know, for the third of 911 calls that are, like, cat up a tree, or

573
00:47:50,380 --> 00:47:55,920
McDonald's got my order wrong, or, or, you know, whatever the thing was that went wrong, the

574
00:47:55,920 --> 00:48:00,380
nearest cop, the nearest firefighter doesn't want that. We have these things centralized for a

575
00:48:00,380 --> 00:48:04,000
very good reason. The people that take these calls are an important part of the process, and you

576
00:48:04,000 --> 00:48:08,600
can't circumvent that. So, sorry to be passionate about it, but, yeah, no, no app and won't

577
00:48:08,600 --> 00:48:15,280
be. Down front. Just off along those same lines, um, so it's a large legacy system, so,

578
00:48:15,820 --> 00:48:20,220
let's say someone released an Android malware that switched everyone's phone and downloaded the

579
00:48:20,220 --> 00:48:25,680
malware into 911 mode. Would the system be able to handle that kind of, like, extreme random

580
00:48:25,680 --> 00:48:32,000
traffic that all came at the same time? Clearly you missed my talk yesterday. So that

581
00:48:32,000 --> 00:48:36,140
actually happened. It was, so the question was, uh, if we have all this legacy stuff that's very

582
00:48:36,140 --> 00:48:40,600
susceptible and, you know, minimum traffic carrying capacity, what if somebody, uh, has some

583
00:48:40,600 --> 00:48:45,280
malware that gets on a major platform and then starts calling 911 repeatedly? And, uh, you know,

584
00:48:45,300 --> 00:48:49,380
what I will do is point you to the DEF CON media server, because once, once that talk goes up, you

585
00:48:49,380 --> 00:48:53,820
can get, uh, 45 minutes of a great answer to that question. Yep. In the back.

586
00:48:58,000 --> 00:49:08,360
The question is, what about the integration with SS7? Um, the regrettable reality is SS7 is

587
00:49:08,360 --> 00:49:15,280
going to be with us for some period of time. For most 911 systems, SS7 would be an upgrade. And, uh,

588
00:49:18,980 --> 00:49:23,840
that is exactly the look you should have when I say they're still using MF and CAMA, but they are.

589
00:49:23,980 --> 00:49:29,920
That's, that's how they're signaling things. They're not using SS7. Um, the ultimate goal is to

590
00:49:29,920 --> 00:49:35,420
bypass that completely. We'll still have to have SS7 interfaces for carrier networks that hang

591
00:49:35,420 --> 00:49:40,960
around, um, because signaling system 7 is going to be with us for some period of time. But next

592
00:49:40,960 --> 00:49:44,680
generation 911 is designed to start getting rid of that, get it out of the system as quickly as we

593
00:49:44,680 --> 00:49:54,300
can. I think we've got time for maybe one or two more questions. Anyone? Okay. I'll be hanging

594
00:49:54,300 --> 00:49:58,320
around in the hallway then. Thank you all very much for coming to the talk and great, uh, great

595
00:49:58,320 --> 00:49:59,760
getting to chat with you. Take care.