>> Thank you guys very much, uh, we're here to talk about uh, an attack that happened last October. Uhm, we called it the 'Meet Desai' attack after the, uh, the guy who wrote the code that caused the incident. Uhm, but before we get into the details of that. Just a quick little bit about me. Uhm, I'm Cincvolflt otherwise known as Trey Forgety, uhm, a hacker, lawyer, navigator and physicist. Uhm, I work for an association called NENA - the 9 1 1 association, uh, we improve 9 1 1 by doing all of the things in that lengthy statement. Uhm, advocacy is my part of it - as a lawyer I mainly, uh, do stuff in Washington but, uhm, because of that I get to do some cool things like interact with all of you here at Def Con for the past few years. [cough] And so I, I'm pleased to be presenting about this attack and what we're doing to try and help defend against these types of attacks, uh, going forward. So, this past November, a teenager from Arizona launched a telephone denial of service attack - the first distributed denial of service attack against not one, uh, centers across the entire country using eight lines of code and a tweet. [laughter] Now, before I get into the details of all this, this is Def Con 101 and so we're supposed to talk about some more basic type things and one thing that I personally think has become a little bit missing, uhm, in the world of, uh, information theory as we've gone from the telephone network into all IP networks like the internet is some mathematical rigor. [audience noise] Uhm, now, according to Stephen Hawking if you put a formula in something you cut the number of people interested by half. So, if the back half of the room will please stay seated - I don't want everybody leaving at once when I, when I put this up. But I want to talk to you about a, a formula that was invented by this guy. This is Agner Krarup Erlang, and he came up with something called the 'Erlang V formula'. He was a Swedish telephone engineer back in the '20s - brilliant guy. He was the one who first put some rigor around how many things you need to service some number of requests. And the cool thing about it was he did it in the abstract. This can apply to, uh, telephone lines; telephone trunks; servers; uh, the number of threads that you need to do something. But for our purposes, it, it deals with how much carrying capacity a network needs to absorb some amount of traffic that's thrown at it. So, this is his B formula - this is the Erlang B formula - you don't need to remember this, uhm, if you wanna go online and take a look at the Def Con materials once they're posted - I put a much longer version of this slide deck up, so you can actually see a walk through of this equation and learn what all the parts of it, uh, do. But basically this tells us the probability of blocking - that's PB, uhm, the probability that we'll have a resource unavailable if we have M resources available and we have E which is the, uh, normalised ingress load. So, normalised ingress load is fairly simple - it just means the average call time or transaction time if you're doing, like, server type stuff. Uhm, multiplied by the average holding time. So, uh, how often you get calls times how long they are tells you you're normalised ingress load and then if you do this summation over here. Uh, you can come up with, uhm, probability of blocking. Now, in the abstract you say, okay, that's fine but so what? Well, if you, you reorganize this and you actually solve for M - you can start out with a target. You can say 'I want no more than a one percent probability of blocking a call or a transaction or, or whatever it is I'm trying to do'. And that was very important to Erlang and it's still very important to us in the 9 1 1 field because telephone lines or telephone trunks that connect switches with 9 1 1 centers are very finite resource. We have very few of those. Uhm, 9 1 1 and the telephone network in particular - the last sort of thing in the information world where it's physical wires that matter, uhm, all of this stuff - you wanna go make a change to a 9 1 1 network? The only way to do that is you gotta get out this, like, crazy ancient little screw gun and like unscrew some wires from a terminal block and move them and screw them in again and file lots of paperwork to tell everybody what you did. So, last year, uh, we got a call, uh, from the department of homeland security asking us to take a look at a research paper, uh, that was put out by Ben-Gurion University in, uh, Israel. And they did a lot of really cool math - a lot of really great research; they deeply analysed the 9 1 1 system in the state of North Carolina based mostly on open source, uh, information that they were able to develop and so they developed a model of sort of what a typical 9 1 1 system might look like. And what they came up with was this notion that a typical 9 1 1 system probably has about one point seven zero five three trunks for every ten thousand population in the area that it serves. Now, I, I wanna point out this is, all of this stuff was based on the wire line network. 9 1 1 started back in the six, in the late '60s and that is all there was. There were no cell phones back then; there was no VoIP. So, all of this stuff was built on this kind of physical infrastructure basis. Once upon a time that was probably really ripe - like that, there was, I'm sure there was some traffic engineering table somewhere where you can go look that up and just build that. Uh, the bell system was great about that. Uhm, they estimated that 75 percent of those trunks were shared between wire lined and wireless and 9.5 percent were dedicated to wireless only. For reasons that wireless was kind of this built on sort of thing that we did decades after wireline. There some cases where like the wireless trunks are separate from the wireline trunks. The only problem about this is that when we read this in our organisation we deal with this everyday. Our members are the people who have to, you know, build and operate these things. Uhm, we thought that was a really aggressive estimate. We actually believe the number is more like 12 or less trunks per average 9 1 1 center; average PSAP. You'll see me use that term - it stands for 'Public Safety Answering Point'. I use it as a shorthand for 9 1 1 center. I'll try not to be jargony but if I slip into it just know that PSAP is a 9 1 1 center. THere about seven thousand of these across the united states and another couple of hundred across Canada that we represent. Uhm, so about 12 on average, uhm, bigger places, bigger populations, uh, you will see more of that. But we decided to just call around and ask our members 'Hey, do you, do you have a sense of whether is, is accurate or not? Like how many do you actually have?' That's not something that we know on a national basis. And by way of example, uhm, I called up some folks in Denver, uhm, and the Ben-Gurion paper predicts between 79 and 95 wireless trunks for a city with 663 thousand population and that's just the city of Denver. If you're one of the people who lives out there and knows it's growing very quickly, you go 'Oh my g*d, there's way more than that'. This is just the city proper because that's what's served by their PSAP, their 9 1 1 centre. Uhm, the reality when we called them up is they have 32. [laughter] And that's about a two and a half to three times smaller number than what was expected, so, you know, that was kinda one of those moments that were, you know, we said back to the DHS, you know 'Hey, these guys did great; they did all the math correctly. They just fundamentally over estimated the carrying capacity of these systems. It's actually much smaller. We have very few trunks, uh, compared to what you might expect.' And this was actually a problem that we were aware of. This was not something that was new. Back in 2012, uhm, I and a few other people in the public safety field actually work with the department of homeland security to stand up a working group on, uh, telephone denial of service and cyber security issues in 9 1 1. And in, through that process, we, we focused on a few things, We had gotten requests from California and a few other states who wanted to know what do if x happens? And the xs that they were worried about tended to be things like Android malware - what if somebody infects a whole lot of these vulnerable Android devices and they go out and start making 9 1 1 calls. What do we do? Who do we call? What if they geo-target it? So, you know, 9 1 1 centres have defined geographic service areas - you only get to that 9 1 1 center if you're within the service area or maybe even a little bit of a radio margin around it. So, the, the question was, well, okay, what if they start targeting a 9 1 1 centre as a prelude to a kinetic attack? If you wanna bomb something and you wanna make sure you have the most possible casualties one way to do that is shut down the 9 1 1 service; stop the response. And they also were really worried about single PSAP incidents happens. You know, when something happens and one 9 1 1 center is affected - what do they do? Who Do they call? Remember, these are not folks who deal with the feds on a daily basis; they don't have US cert on speed dial. Uhm, the FBI is somebody that comes in and takes over - not somebody that, you know, like, you routinely reach out to call. SO, through this process we came up with a few things. We helped our members to understand how to recognize an attack; uh, how to report an attack; who to call at the FCC, at homeland, at the FBI etcetera to, to let folks know. Hey, something's going on; and also how to recover service - how to get things back running the way they should be. But we never thought it would happen the way that it ultimately did. Again, we were focused on things like mal, you know, android malware, geo-fencing and so on. What we really expected was that the first 9 1 1 distributed TDOS attack would happen as a result of native malicious code that was executable on a device or; and this is the other big one that kind of kept me awake, was we expected an, an enterprise callmanager to get popped. Uhm, I did a quick Shoden search and found 635 unprotected call, uh, enterprise call managers sitting out on the internet just in North America. Any one of these boxes has far more traffic origination capability than even the biggest 9 1 1 centers in the country are capable of absorbing. There's just no way if one, if one of these things get, gets popped we can defend against it. We also knew that there's almost a billion , uh, known vulnerable Android devices that are out there with, you know, legacy operating systems that are no longer patched on devices that the manufacturers are no longer supporting. So, like, that was the thing that we expected. Nobody expected what actually happened. We also expected that attacks would be limited by user location, We thought at worst and attack could hit a region. Because, uh, as the Ben-Gurion folks found, you know, some places they have regional interconnections of 9 1 1 systems; they have one selective router or a few of them that serve, you know, large populations. Like I think North Carolina has either four or seven. And, and you could get some fail over between those if they're wired up just perfectly. So we thought, you know, the worst this could go is a few PSAPs - this is not gonna be lots of 9 1 1 centres because it's really difficult to scale. [cough] And last thing; we never thought that there could be a distributed attack on distributed targets. Like that's not the normal model - you, you normally think of like Mirai going after Brian Krebs - not Mirai going after all of the internet. Like that's just, uh, it's not within your norm. But when you're dealing with scales that are so much different like in the telephone network - well, all of a sudden that becomes true and I'm gonna argue later on that starts to become true very quickly for even the rest of the internet at large as the number of compromisable devices grows. So, let's talk about a practical attack - you guys came to hear what actually happened. [cough] Uhm, what actually hit these 9 1 1 centers. In the end it was one YouTube comment; an obfuscated URL and eight lines of really simple code. So, the, the guy behind the incident, uh, ultimately, and I wanna be very clear here. [laughter] Uhm, when I was this guy's age, I did dumb stuff with scripts that could have landed me in a lot of trouble too and I, I imagine that's a shared experience in this room? Uhm, I, I find it very hard to, to be really harsh about this because like, people do dumb stuff. In this case, it, it, worst possible target. 9 1 1 is not the thing you wanna mess around with because people are gonna freak about it, right? Uhm, but, in fairness to him, uhm, it was a teenager who did a, a very very dumb thing. Uhm, fortunately he didn't have all that many followers. If this had gone out from Kim Kardashian - we would have been in a world of hurt. Uhm, ultimately, he wasn't even the guy who had originally found, uh, the vulnerability in iOS that lead to this. He was actually helping somebody out saying 'Hey, you guys took down this guy's site clicking on his links. Uh, here, let me put that back up for you.' And well, unfortunately, then it got out because the following day, oh, it's still going strong; people are still clicking; large number of hits on the, uh, link. And then the really amazing thing for us about all of this is the attack really wouldn't have been that bad if this had just stayed within the hacker community. In fact, I doubt most 9 1 1 centres would have noticed if this was just 'Hey, I found this cool iOS vuln, everybody go check this out', right? Or 'I'm just gonna go blow up somebody's phone just for fun'. Unfortunately there's this thing out there called the music community. And the music community has like libs on social media - people who are into music; people who make music etcetera. They live their lives on social media and they click links from people they don't know absolutely all the time. [laughter] It, the music community is like this enormous, weaponizable net that you can exploit... [laughter] It's, it's amazing. So, the social media personalities just happen to be in the wrong time zone so that literally everybody in the US is awake when they're, when they're doing these things. Everybody's retweeting with nothing more than a 'LOL' because 'Hey, you made me have to go reset my phone, big whoop, right'? They weren't thinking about are the other possible, you know, other possible consequences. But, you know, like folks, like this guy - Sunday Gavin whose headline says 'Hey, he's gonna be famous one day!' remember that. We're gonna come back to it. [laughter] And this, then this guy, this was, this was the thing that really like made this go pear-shaped. This is Mark Thomas, he is as far as I can tell, this guy doesn't actually do anything other than show up at places and look good. [laughter] That's, uh, and somehow gets paid for it, I, I think, I don't understand that but it's a thing on social media. He has 500-and-32-thousand twitter followers who love to click things. [laughter] And they did - because what they saw when they went to twitter was a, a helpfully shortened URL, something like this, you know the average user doesn't understand that that blob of nothing down below really points to a really shady URL dot com and is going to get them poned. And so they don't expect what is coming next. Because what this linked to was a very simple web page. Now, and I'm gonna show you the code here in just a second but, the, the basis of the vulnerability that these guys were exploiting is once upon a time on iOS - very helpfully - if you clicked on a phone number or a tell URI, in our speak, uhm, you would get an automatic call generation. I can click a phone number for one of my friends and it would automatically call them and that was helpful and useful and quick and low friction. Good thing, right? The problem is user interaction is not the only way to call a tell URI. You can also write a script that calls a tell URl and says 'Oh, click that!'. And if you put that in a for loop you can click that a lot of times very quickly. [laughter] Uhm, and that's what this guy did. So, on this page - here's the actual, uhm, code that caused the incident. [laughter] It, it, it's not the most sophisticated thing in the world but there, there is sort of this internal elegant simplicity to it. [laughter] Like you know, you do it for the 'lolz', first of all. I mean, why do we do anything/. We do it for the 'lolz' right? So uh, that's what the users saw in their browser. They just saw a string of lolz and then within about a second the, uh, the script down at the bottom there. And I'm gonna walk through this in pseudo code for those of you who, who don't read script - in just a minute. But basically you've got at the top, you've got a definition of a couple of links, one of which for a phone number and one of which for an email thing. And this was the other kind of elegant, clever thing about this is like if you want to crash somebody's device make it do lots of stuff, uh, and cover up the fact that it's doing lots of stuff, right? So, uh, in addition to to continually call 9 1 1 something like ten to the sixteenth times. I, I, apparently an earlier version of the code, uh, used it 13 to 37 times but, that, that was deemed to be insufficient. Uhm.... [laughter] So, inside the for loop, it basically says look, call 9 1 1 and look, put up an email thing, you know? Put up this email thing that tells people they have a virus on their phone which would worry most people. And, and, you know, the worrisome thing about this is Safari's a great browser; I love it, I use it all the time. It does very helpful things that are also very exploitable. So, in this particular case if you just power cycled your device - when you reopened it and came back into Safari, Safari hopefully said you were just looking at this page on Meet Desai dot com, why don't I reopen that for you? [laughter] So rinse and repeat, right? THe only way to actually kill this off was to then open, uh, boot your device, open settings, go clear the safari cache so that it didn't reopen this code. Uhm, I, I promised some pseudo code - here's basically what I just walked you guys through. If, if you're not super into code this is a nice kind of little explanation of, of what you can see in the rocket script of the previous page. [laughter] So, this was basically, uh, this was basically the whole thing. This is how you attack 9 1 1, at least on earlier versions of iOS. So, let's talk a bit about, like the prompt effects. WHat happened when this, when this started? Well, we know from looking at the google, uhm, uh, link shortener that there were about a 117 thousand 500 clicks that we know of. Now I also know that this URL and other like it got repackaged and reused roughly in the same timeframe. So, not all of these may have been, uhm, actually a result of this one, uh, youtube comment or these tweets. Uhm, and I would also add, uhm, this, this could wildly overestimate the number of times anything actually went wrong. Because this was an iOS unique vulnerability -this wasn't everywhere, uhm, and so other devices on different operating systems and potentially on different versions may not have reacted in the same way. So, if it had really been 117 thousand devices calling 9 1 1 constantly I would have heard about it in 30 minutes instead of like six hours, right? I, it, my phone would have rung, rung a lot faster. But it did have effects in the real world - it caused overloads at 9 1 1 in 12 states that we know about. And, uhm, and in some places there was peak traffic of about six times their average load. Now, that sounds really big and scary but before everybody starts to freak out again I want to emphasize - the average 9 1 1 centre in the country has maybe three positions and maybe six to 12 trunks - so, like, it's very small. So, six times three is just like, 'Oh, you got 18 calls in an hour instead of three.' Like it, you know, some of them were admittedly bigger than that but the numbers can be made to seem a lot larger than they really are when you start using multipliers like this, Uhm, and I just kinda wanna be clear that, it, it wasn't that gigantic in most cases. The other thing, and this was really fascinating to, to find out, uhm, you can really exploit demographic difference in groups to create a lot of confusion around attacks. The first report, the first three or four reports that I got from 9 1 1 centres and then ultimately from folks in the government was, you know, we think is a, a vulnerability in one carrier's network that is causing this. Everybody was saying 'Oh, all the calls are coming from this particular carrier'. And that seemed really strange. Like why should iOS on one carrier behave differently than it does on another? We didn't even know it was just iOS at that point. Why should any, uh, you know, software respond differently to the carrier network? It turns out it doesn't! There was, the carrier had absolutely nothing to do with it. It's just that all of the people - remember I was talking about weaponizing the mus, the music community? Everybody in the music community uses one particular wireless carrier. I don't understand why... [laughter] But like music fans have this particular bias. They like this particular carrier and so even when this happened, everybody thought 'Oh my g*d, it's this one carrier, somebody shut them down!'. [cough] You know, not a good a position to be in if you're that carrier, right? That's not a good thing. But it was just this, this weird A-symmetry in this one particular sub-population that just happened to confuse the heck out everybody. So, and the big takeaway from all of this is that above some threshold nothing is really safe. Like there is some traffic threshold when it really just doesn't matter anymore what you're doing. There's, there's, you're just not going to be able to defend against it - I'm sorry, that's, that's it. Uhm, we, we happen to find that in the telephone network in the 9 1 1 system, in this, uh, in this instance because we're a softer target. We have this vulnerability that we knew about, uh, we know when we've, when we've got this limited carrying capacity, you know, maybe 23, uhm, trunks in some places. Uhm, we, we, knew about that and, and it's even actually worse than that because behind those 23 thinks there might only be like three or four people actually answering calls. So, funny story, you know, we talked about the Erlang formula, that doesn't just apply to technical things like gets and server transactions and trunks - it also applies to people. You can use the Erlang formula to model how many people; how many agents do I have to have to deal with a particular call load when the, you know, average arrival rate is, uh, lambda and the average holding time is H. You can, you can work that out and figure out okay, how many people do I have to hire. Uhm, the same holds true for things on the internet. I, I think, you know, I mentioned the Mirai attack against Brian Krebs earlier, uhm, one of the articles that, that I read in the mop up from that was, when Google was trying to decide 'Hey, should we take this guy on and defend him?'. They had to have a very adult conversation about 'Well, wait a minute, this thing is so big now, even if we are the 600 pound gorilla on the internet, we could be vulnerable too.' And that's, and if you think about the scale of somebody like Google having to have that very sober conversation, uhm, it really does demonstrate that, you know, especially in the IOT era that we live in where, you know, every little mote of dust is potentially an IP traffic source, uhm, we really have to start thinking about defense in, in very different ways. Because there is a scale at which there's just nothing else you can do and, and, and, and it becomes, uh, essentially indefensible. So, what did we do? Knowing that we have these vulnerabilities, let's get into remediation. The, the first thing obviously was to stop propagation. We had to stop this thing getting bigger and we had to do that very quickly. Uh, and we also had to do everything we could to remove, uh, de-obfuscate the links if we could. So that people would know it was potentially shady and also to just take away that level of abstraction so that it was, you know, not, uh, something easy and, and convenient for users to click on and then ultimately just get the site offline. Like, I, you know, somehow get that code to a point where nobody can get to it. So very quick sort of things - twitter was actually very helpful working with the government to, uh, basically pause the source accounts; filter out the malicious link; uh, stop this from circulating. Uh, Google equally very helpful disabling the shortened URL so that, you know, if, if you go try to click on the shortened URL now, nothing's gonna happen. Uhm, and, uh, also take down, take down the website. I, I, and I don't have this confirmed, I am 99 percent certain this was a, a hosting site behind Cloudflare. I know Cloudflare was in front of it. Uhm, and they were actually very helpful in ultimately, uh, blackholing the domain. Uhm, the guy like knew that something wonky was going on but was like 'No, no, I took this on to like help everybody out. Don't worry, it'll come right back!'. Well, no, that's, that's not coming back. Not ever. [laughter] And, remember this guy? [laughter] He is now Def Con famous! [laughter] So, you know, and I, I, and I love the, just like to be that candid about, you know, lawyers we have a duty of perfect candor. Well, if you tell people, 'Well, I'm about to get arrested', that's, you know, hey... Uh, this guy, he's got some serious candor. There's, there's his mug shot. [laughter] He, he, didn't, didn't have a good time. And here's out, uh, agust original vulnerability researcher. And, and again, like I said, I, I absolutely feel for this guy because I have been the 17-year-old kid doing stuff with things that sometimes goes pear-shaped. Uhm, and I know a lot of the folks in this room have too. I, I don't think this should be like a life-ending or a life-altering sort of thing. Like, and I say that as somebody coming from the 9 1 1 community where I know exactly what's at stake with every call. My members have to deal with people, you know, getting murdered in real-time while they listen. And eventually while they watch. And it, it's very meaningful to us so a lot of folks will be very reaction, reactive, reaction, reactionary, sorry. Uhm, and will just say, you know, burn him at the stake or something like that and it's like, yea, you know. This, this is something that got way out of hand thanks to a bunch of celebrities, like, let's not completely destroy this guy because of that. Uhm, uh, CV, interestingly enough this vulnerability - although it does have a 2017 CV, that we'll talk about in a second was not completely new. Uhm, this guy Colin RM on twitter, uhm, I threw a lot of very deep Googling - I managed to discover he had actually notified Apple, uhm, about this very issue back in 2008 or at least issues that could effect similar results. And those were eventually patched. Uhm, they did eventually patch, uh iOS as well against the particular flaw that was exploited in, in this incident. Uhm, it, but that patch actually didn't come out for another five months. That was May 30th if memory serves that was iOS ten-three-two. Uhm, so five months later it is actually patched and you can see it, these were the write-ups if you wanna go look at CVE 2017, 24 84; and CVE 2017, 24 04. Uhm, and these were the ones that ultimately were exploited to cause, uh, both 9 1 1 denial of service attack and basically the shutdowns on, uh, users' devices or, or basically rendering the devices unusable. So, one of the things that I put in the abstract, because we thought that this was very important was to track, uhm, the extent to which these vulnerabilities are, you know, potentially hanging around. And, uh, part of the way that we did that, uhm, we, we went out there and looked at, uh, Telligent data to see okay, what's the rollover rate? How quickly are people patching? And I, uh, just refreshed this today and 76 percent of active, uh, iOS versions that are being seen on the web now are ten-three. And I don't know how many of those are, doesn't get broken down by subpoint. Uhm, but we're fairly confident that this problem is going away quickly, uhm, but the trouble - and I think this goes to show, you know, a lot of folks, uh, kind of poopoo the notion that like, well, you know iOS is always, like, so much better. Well, there's a, you know, 11 percent that are still on ten-two. That's a lot of devices across the world! It may, it may not be the billion that you have, like, with Android but nothing - none of these types of vulnerabilities are unique to any particular, you know, smartphone ecosystem. Uhm, they're just a consequence of having little computers in our hands that can run code. And that nonetheless connect to a telephone network that doesn't know what code is. So, we know we're vulnerable, the next obvious question is - okay Trey, well, what do we do about it? Like you can't just bring us your problems - you gotta propose some solutions otherwise, you know, you're really not doing anything for us. So, a few things to talk through, uhm, and I, and I wanna take a step back for a second because the 9 1 1 world right now is very fragmented. We have three feet in three different time frames. There's 'Legacy', 'Transitional' and 'Next Generation'. Legacy is the part the is like strictly analog telephone network, uh, I, this ought to be good for a chuckle - most of the nation's 9 1 1 systems still run on CAMA and MF signalling. [audience noise] That's not a joke. We still use all the stuff that Captain Crunch and crew were messing around with with blue boxes and gold boxes and stuff back in the day - that's still how most 9 1 1 calls are signaled and set up in the telephone network today. Uhm, CAMA is handle, you know, handles a lot of the data, uh, when we get your location in 9 1 1 - that comes from something called 'Automatic Location Identification'. And it has an upper bound of 512 non-extended ASCII character set characters. That's it, that's the entire data block; that plus maybe 20 digits that we use for some routing and call back purposes - not caller ID but, uh, uh, automatic number identification. That, that's really it - that's the legacy world. And that's all that analog stuff. In the middle, in the transitional case we've got networks that have started to move to IP. So, maybe you have IP trunking, you're no longer using, uh, those, uh, analog or TDM trunks, uh, to connect the local end office class five switch with the 9 1 1 center. Uhm, but you're doing some VoIP stuff, maybe you have a sort of Quasi cloud-hosted service provider somewhere in like Colorado or California or Washington. And you connect up to them over multiple links and, and that's how you're doing it. Maybe even in some cases you're doing some cool stuff, uh, with, uh location technology - you're adding some data in; bolting some stuff on. So that, uh, you know, you're doing some things out of band so that you can get more data in a 9 1 1 call - that's the transitional case. Where we're headed is next generation 9 1 1. Uhm, that's something that's defined by a thing called the i3 standard that my organisation publishes. It's basically a model for all IP 9 1 1 service where we get deep, good location data, uh, that can be reference to something that's like human-readable, like you know, the Octavius ballroom at Caesars palace, for example. Uhm, it does things like much more intelligent routing and so on. And, and, basically that's sort of the all IP case. There's a very little bit of that in existence today - maybe four or five percent of the country but it's still just doing voice. It's not doing video and text and data the way we really want it to be in the next, you, three or four years. So, I'm gonna talk you through defence in all three of those cases like the options that we have available to us and the problems that we have with those options. So, in the legacy world the, the first defence is you can just over provision. You can go do the Erlang formula again; you can come up with a probability of blocking that's a tenth of one percent, you know? You spend a ton of money - up your bandwidth, up your number of trunks, and it's great, that works but it's expensive - number one - you've got to buy and build all that stuff. And number two, it may be impossible. You just can't get enough people to handle the ingress load at some point, there's there's no way to do it. Uh, you can do contextual white-listing, banks do this. So, most of the time when you call your bank, uhm, they're looking to see with automatic number identification that's the theoretically not spoofable part of, uh, not caller ID, that uhm, that they use to say 'Okay, who is this actually calling? And, and for the most part it's well-trusted because there are so many rules around it for 9 1 1. The trouble is for us, unlike a bank we don't have a customer list. I mean, it's one thing to say, you know, in the wireline world, you can say 'Okay, here's the list of all the numbers that we know exist for telephones in our jurisdiction '. Because somebody went out there and nailed one to the wall, right? Like, you know where those lines go; that's, that would work. Trouble is now they move around, they're on these things and that doesn't work anymore. So, uh, we don't have a customer list that we can use so we can't do contextual white-listing. And we could do blacklisting, this is the other thing - like, okay, you send us a hundred calls and they all turn out to be false. [laughter] Sorry, hat it for you, you're over and done, we're just gonna block your call now. Which, okay fine, you did something nefarious but do you really deserve to potentially die from that? Uhm, you know, when you call 9 1 1 and you're actually having a heart attack, you know, uh, and our members feel very strongly about that. I feel very strongly about that, you know, we, uhm, I talked last year at Def Con, uh, about high availability systems - when you have to carry traffic; you really don't have an option because it's 9 1 1. That complicates matters greatly - when you can't just say 'Sorry, I don't like your traffic, uhm, I'm not gonna handle it'. You, your life gets a lot more complicated. In the transitional case, some things that are being researched heavily right now - homeland's doing a lot of work on this. We're working with some of the, uh, technical folks to connect them with our members and what not. Uhm, you can do number reputation scoring. Uhm, if you've got apps like, uh, you know, uh. I've got Hiya on my phone and it, and it like blocks bad calls for me. Uhm, it's doing that in part on the basis of number reputation scoring and that's a great thing. We know that this particular number is getting misused often - great, let's block or at least flag that call. Uhm, that's dangerous because lawyers... [laughter] And it's also a, a thing that, you know, may be dangerous because of human life. So, we've, we've got, we've got to be careful about that. I think we'll see some of this done soon, with at least flagging, We'll, we'll start seeing like a little asterisk somewhere in that 512 character data block, that says 'This is a little squidgy, may be think twice about it before you go, you know, uhm... [cough] Send the S.W.A.T. team to Brian Krebs house again. Uhm, we can also do real-time threat scoring, so things like should this call be coming from this location? In other words if somebody was recently making calls from a cell-sector in Boca Raton, and now I'm getting a 9 1 1 call from them, that's hitting a cell sector in Kansas city and there hasn't been enough time for them to get between one and the other - like, we need to think about, okay, is that really problem? Like that could be a real threat-score. Uhm, the trouble is for both of these, we haven't tested diverting calls. One way to handle that I to, like, send some, send the call someplace else like an IVR or proof of humanness test - where you gotta like, you know, dial one two three to get access to 9 1 1 or, or whatever. Uhm, those capabilities exist in some transitional systems but nobody's kind of been brave enough to turn them on yet. Uhm, so we've gotta get; we've gotta go through a process of getting comfortable with is this going to work in a way that doesn't endanger human life. That we can, you know, justify turning it on, uhm, all the time and not just when we know we have an incident or an attack. [cough] And then in the next generation 9 1 1 world now, and I, I love to talk about this because in, in the legacy world, uhm, yes, we have lots of vulnerabilities that are... But, but they're like impossible to defend against. In the next gen world - yes, we have lots of vulnerabilities, maybe even more but now we can do things to actually defend against them. And so, the first thing on the list here is the 'stir and shaken' framework. If anybody's a bond fan - yes, this is a bond reference, uhm, stir is an IETF track standard for cryptographically signing ownership of number blocks. So, if I have, you know, 8 6 6, 5 5 5 5, 1 2, 1 2, uhm, the, the North American numbering plan administrator should issue a, a, a signed thing that says that belongs to Verizon or AT&T or Sprint or somebody. They should sign it saying this particular number belongs to, uh, uh, Cincvolflt and oh, by the way the chain is all, you know, it all rolls up to some Root CA and so we can trust that this is a legitimately originated call with that number. It's not being spoofed. Shaken is the same thing just done in the carrier standards body called ATIS. Uhm, trouble with that as, uh, I can't remember if it's Bruce Shaun or Phil Zimmerman said, a couple of Def Cons ago "PKI is really, really hard and if the PKI goes wrong, I want to talk to 9 1 1.' [audience noise] And that is the sanitized version of that line for everybody's, you know, if anybody, for anybody who knows him. Uhm, we can also do bad actor marking - we can start to say 'Look, we know you're a bad guy because we've seen your traffic and it's not good, we're gonna stop that'. Uh, that takes time to tune - could go wrong. Uhm, we could do suspicious call diversion, uhm, we have the ability in the motor control function of next generation 9 1 1 systems to mark traffic as suspicious and then say add a subsequent emergency services routing proxy. If we see that a 9 1 1 center is in load, we can say okay - prioritize the non-suspicious traffic first. Or if it gets in really high load - maybe divert that to an IBR first; proof of humanness etcetera. We, or, you know, fail it over to an investigatory center that's not handling live 9 1 1 calls but is just dealing with, like, the suspicious stuff. That's intelligence that we don't have and can't have in the telephone network but that we can have in the next gen 9 1 1. Also, a big work in progress there's a DHS pilot on threat scores... [cough] Uhm, using those frameworks that I just talked about. Uhm, and we're also working, uh, the i3 standard that I mentioned before and then the other big standard we publish, uh, for this is, uhm, called NG Sec- that's the next generation security standard. And it tells you, uh, adn, and it's actually applicable in today's e- 9 1 1 environment too but it sort of tells you what to do to, uhm, baseline properly configure and secure a big, complex, hairy, nextgen 9 1 1 system. Uhm, and, and on that note I want to encourage everybody because those standards are still under active development if you know things... [cough] About these subjects and you want to help we would love to have you join in at 'dev dot NENA dot org'. [cough] It's an amazing way to contribute... [cough] To the safety and security of not just the community here in the United States but the i3 framework in particular. [cough] Uh, the i3 standard is actually, uh, being used in Canada and uh, all of Europe as well as as the basis for their emergency systems going forward. So, this is going to be a global kinda thing and we, we need the global information security community focused on it to make sure that as we add things like voice, video, text, data, etcetera. Uhm, that we have the capability to, uhm, do that securely. [cough] So, so we, we'd love to have you! Uhm, before I close here, a couple of things I, I will take some questions if we can do that, uhm, but I, I wanna say a special thanks to QueerCon, uhm, we have the coolest badges at all of Def Con! And we do that every year because of some amazing people. Uh, these guys are my family, uhm, I love you all, it's the reason I'm up here. Thank you so much! Uhm, also I Am The Cavalry for those of you who knows something about tech and policy - I absolutely encourage you to get involved with I Am The Cavalry. We're doing amazing things in DC. Uh, translating and being ambassadors for those in the policy community who don't know a lot about what all of you do from day to day. Uhm, and we need help, we need more help. There, we're putting computers in every part of our lives today and that has huge policy implications for the safety of human life and, and literally every part of our economy. So, please, please, uh, you know, come join us. [cough] Uhm, also, check out my other talk in the, uh, Crypt Privacy village, hashtag shameless plug. [laughter] Uhm, I will be, I'll be talking there about, uh, location tracking, uh, so basically in 9 1 1 we don't wanna track you but sometimes other people do and they always blame us when that happens. But I, I wanna assure everybody how that works so please come and see that in the CPV. And, at this point, are there questions? Am I allowed to take questions? >> Yea you're allowed to take questions...[inaudible] seven minute >> Okay...Anyone? Anyone? Beuller? [applause] [cheering] Thank you!