 Thank you guys very much. We're here to talk about an attack that happened last October. We call it the meat decide attack after the guy who wrote the code that caused the incident. But before we get into the details of that, just a quick little bit about me. I'm Sync Valfleet, otherwise known as Trey Forgity. I'm a hacker, lawyer, navigator and physicist. I work for an association called Nina, the 9-1-1 association. We improve 9-1-1 by doing all of the things in that lengthy statement. Advocacy is my part of it. As a lawyer, I mainly do stuff in Washington. But 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. And so I'm pleased to be presenting about this attack and what we're doing to try and help defend against these types of attacks going forward. So this past November, a teenager from Arizona launched a telephone denial of service attack. The first distributed telephone denial of service attack against 9-1-1 centers across the entire country using eight lines of code and a tweet. Now, before I get into the details of all of 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 in the world of information theory, as we've gone from the telephone network into all IP networks like the internet, is some mathematical rigor. Now, according to Stephen Hawking, if you put a formula in something, you cut the number of people interested in it by half. So if the back half of the room will please stay seated, I don't want everybody leaving at once when I put this up. But I want to talk to you about a formula that was invented by this guy. This is Agner Crerop Erlang. And he came up with something called the Erlang B 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 telephone lines, telephone trunks, servers, the number of threads that you need to do something. But for our purposes, 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. If you want to 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 that you can actually see a walk through of the equation and learn what all the parts of it do. But basically this tells us the probability of blocking. That's PB. The probability that we'll have a resource unavailable if we have M resources available. And we have E, which is the normalized ingress load. So normalized ingress load is fairly simple. It just means the average call time or transaction time if you're doing like server type stuff, multiplied by the average holding time. So how often you get calls times how long they are tells you you're normalized. Ingress load. And then if you do this summation over here, you can come up with a probability of blocking. Now in the abstract you say okay that's fine but so what? Well if 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 1% probability of blocking a call or a transaction 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. 9-1-1 and the telephone network in particular are the last sort of thing in the information world where it's physical wires that matter. All of this stuff you want to go make a change to a 9-1-1 network. The only way to do that is you got to get out this like crazy ancient little screw gun and 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 we got a call from the Department of Homeland Security asking us to take a look at a research paper that was put out by Ben-Gurion University in Israel. And they did a lot of really cool math, a lot of great research. They deeply analyzed the 9-1-1 system in the state of North Carolina based mostly on open source 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 1.7053 trunks for every 10,000 population in the area that it serves. Now I want to point out this is, all of this stuff was based on the wire line network. 9-1-1 started back in the late 60s and that was 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 right. Like that, I'm sure there's some traffic engineering table somewhere where you can go look that up and just build that. The bell system was great about that. They estimated that 75% of those trunks were shared between wire line and wireless and 9.5% were dedicated for wireless only. For reasons that wireless was kind of this bolt on sort of thing that we did decades after wire line. There are some places where like the wireless trunks are separate from the wire line trunks. The only problem about this is when we read this in our organization, we deal with this stuff every day. Our members are the people who have to, you know, build and operate these things. We thought that was a really aggressive estimate. We actually believe that the number is more like 12 or less trunks per average 9-1-1 center, average PSAP. You'll see me use that term that 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 are about 7,000 of these across the United States and another couple of hundred across Canada that we represent. So about 12 on average. Bigger places, bigger populations, you will see more of that. But we decided to like just call around and ask our members, you know, hey, do you, do you have a sense of whether this estimate is accurate or not? Like how many do you actually have? That's not something that we knew on a national basis. And by way of example, I called up some folks in Denver and the Hungarian paper predicts between 79 and 95 wireless trunks for a city with 663,000 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 God, there's way more than that. This is just the city proper because that's what's served by their peace app, their 9-1-1 center. The reality when we call them up is they have 32. And that's about a 2.5 to 3 times smaller number than what was expected. So, you know, that was kind of one of those moments that were, you know, we said back to DHS, you know, hey, these guys did great research, they did all the math correctly. They just fundamentally overestimated the carrying capacity of these systems. It's actually much smaller. We have very few trunks 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, I and a few other people in the public safety field actually worked with the Department of Homeland Security to stand up a working group on telephone denial of service and cybersecurity issues in 9-1-1. And through that process, we focused on a few things. We had gotten requests from California and a few other states who wanted to know what do we do if X happens? And the X's that they were worried about tended to be things like Android malware. What if somebody infects a whole bunch 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 centers have defined geographic service areas. You only get to that 9-1-1 center if you're within the service area or maybe a little bit of a radio margin around it. So, the question was, well, okay, what if they start targeting a 9-1-1 center as a prelude to a kinetic attack? If you want to bomb something and you want to make sure you have the most possible casualties, one way to do that, shut down the 9-1-1 service, stop the response. And they also were really worried about single PSAP incidents. 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 U.S. cert on speed dial. 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, how to report an attack, who to call at the FCC, at homeland, at the FBI, et cetera, 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 that it would happen the way it ultimately did. Again, we were focused on things like, you know, Android malware, geofencing, and so on. What we really expected was that the first 9-1-1 distributed T-DOS 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 enterprise call manager to get popped. I did a quick show to end search and found 675 unprotected call, 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 of these things gets popped we can defend against it. We also knew that there's almost a billion 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. This is, nobody expected what actually happened. We also expected that attacks would be limited by user location. We thought at worst an attack could hit a region. Because, you know, as the Bengurian 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 4 or 7. And, and you could get some failover between those if they're wired up just perfectly. So we thought, you know, the worst this could go is like a few PSAPs. This is not going to be lots of 9-1-1 centers because it's really difficult to scale. And last, we never thought that there could be a distributed attack on distributed targets. Like that's not the normal model. You normally think of like Mariah going after Brian Krebs, not Mariah going after all of the internet. Like that's just, 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 going to 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, what, 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 guy behind the incident ultimately, and I want to be very clear here, 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 imagine that's a shared experience in this room. I find it very hard to be really harsh about this because like people do dumb stuff. In this case, it works possible target. 9-1-1 is not the thing you want to mess around with because people are going to freak out about it, right? But in fairness to him, he was a teenager who did a very, very dumb thing. 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. Ultimately, he wasn't even the guy who originally found the vulnerability in iOS that led to this. He was actually helping somebody out saying, hey, you guys took down this guy's site clicking on his links. 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 numbers of hits on the 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. Like, in fact, I doubt most 9-1-1 centers would have noticed if this was just, hey, I found this cool iOS phone, everybody go check it out, right? Or I'm just going to 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, lives on social media. People who are into music, people who make music, et cetera, they live their lives on social media and they click links from people they don't know absolutely all the time. The music community is an enormous, like, weaponizable net that you can exploit. It's amazing. So the social media personalities just happen to be in the wrong time zone so that literally everybody in the U.S. is awake when they're doing these things. Everybody's retweeting with nothing more than a lull because, hey, you made me have to go reset my phone big whoop, right? They weren't thinking about what are the other possible consequences. But, you know, like folks like this guy, Sunday Gavin, whose headline says, hey, he's going to be famous one day. Remember that. We'll come back to it. And then this guy, 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. That's, and somehow he gets paid for it, I think. I don't understand that, but it's a thing on social media. He has 532,000 Twitter followers who love to click things. And they did. Because what they saw when they went to Twitter was 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.com and is going to get them pwned. And so they don't expect what's coming next. Because what this linked to was a very simple web page, and I'm going to show you the code here in just a second, but 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, you would get an automatic call generation. I could 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 URI and says, oh, click that. And if you put that in a for loop, you can click that a lot of times very quickly. And that's what this guy did. So on this page, here's the actual code that caused the incident. It's not the most sophisticated thing in the world, but there is sort of this internal elegant simplicity to it. Like, you do it for the laws, first of all. I mean, that's like, why do we do anything? We do it for the laws, right? So that's what the user saw in their browser. They just saw a string of laws. And then within about a second, the script down at the bottom there started. So, and I'm going to walk through this in pseudo code for those of you 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 and cover up the fact that it's doing lots of stuff, right? So in addition to continuously calling 911 something like 10 to 16 times, apparently an earlier version of the code used it 1337 times, but that was deemed to be insufficient. So inside the for loop, it basically says look call 911 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 you know, the worrisome thing about this is, Safari is 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 decide.com. Why don't I reopen that for you? So rinse and repeat, right? The only way to actually kill this off was to then open, boot your device, open settings, go clear the Safari cache so that it didn't reopen this code. I promise some pseudo code. Here's basically what I just walked you guys through. If you're not super into code, this is a nice kind of little explanation of what you can see in the rocket script on the previous page. So this was basically the whole thing. This is how you attack 911, at least on earlier versions of iOS. So let's talk a bit about like the prompt effects. What happened when this started? Well, we know from looking at the Google link shortener that there were about 117,500 clicks that we know of. Now, I also know that this URL and others like it got repackaged and reused roughly in the same time frame. So not all of these may have been actually a result of this one YouTube comment or these tweets. And I would also add this could wildly overestimate the number of times anything actually went wrong because this was, remember, an iOS unique vulnerability. This wasn't everywhere. 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,000 devices calling 911 constantly, I would have heard about it in 30 minutes instead of like six hours, right? My phone would have rung a lot faster. But it did have effects in the real world. It actually caused overloads at 911 centers in 12 states that we know about. 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 911 center in the country has maybe three positions and maybe six to 12 trunks. Like it's very small. So it's 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. And I just kind of want to be clear that it wasn't that gigantic in most cases. The other thing, and this was really fascinating to find out, you can really exploit demographic differences in groups to create a lot of confusion around attacks. The first reports, the first three or four reports that I got from 911 centers and then ultimately from folks in the government was, you know, we think this is 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, 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 talked about weaponizing the music community? Everybody in the music community uses one particular wireless carrier. I don't understand why, but like music fans have this particular bias. They like this particular carrier. And so when this happened, everybody thought, oh my God, it's this one carrier, somebody shut them down. You know, not a good position to be in if you're that carrier, right? That's not a good thing. But it was just this weird asymmetry in this one particular subpopulation that just happened to confuse the heck out of 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. Um, we happen to find that in the telephone network in the 911 system, um, in this, uh, you know, in this instance because we're a softer target. We have this vulnerability that we knew about. Uh, you know, we know when we've only got, you know, this limited carrying capacity, you know, maybe 23, uh, trunks in some places. Um, we knew about that. And it's even actually worse than that because behind those 23 trunks 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 work that out and figure out, okay, how many people do I have to hire? Um, the same holds true for things on the internet. I, I think, you know, I mentioned the Mariah attack against Brian Krebs earlier. Um, one of the articles that I read in the, 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 that even if we are the 600 pound gorilla on the internet, we could be vulnerable too. And that's, if you think about the scale of somebody like Google having to have that very sober conversation, um, it really does demonstrate that, you know, especially in the IOT era that we live in where every little, you know, moat of dust is potentially an IP traffic source, um, 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 it becomes 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, 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, 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. Uh, 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 you go try to click on that shortened URL now, nothing's going to happen. Um, and, uh, also to take, take down the website. I, I, and I don't have this confirmed. I am 99% certain this was a, a hosting site behind Cloudflare. I know Cloudflare was in front of it. Um, and they were actually very helpful in ultimately, uh, black hole in the domain. Um, 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, that's not coming back. Not ever. And remember this guy? He is now DEF CON famous. So, you know, and, and I love that, you know, just like to, to be that candid about it, you know, lawyers, we have a duty of perfect candor. Well, if you're telling people, well, I'm about to get arrested. That's, you know, hey, uh, this guy's, he's got some serious candor. Uh, there's his mugshot. He, he, he didn't, didn't have a good time. And here's our August, uh, original vulnerability researcher. And, and again, I, like I said, I, 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. Um, 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 life altering sort of thing. Like, and I say that as somebody coming from the 911 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 reactive, reactive, reactionary, sorry. Um, and we'll just say, you know, burn them at the stake or something. It's like, 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 just because of that. Um, uh, CVE. So interestingly enough, this vulnerability, although it does have a 2017 CVE that we'll talk about in a second, was not completely new. Um, this guy, Colin RM on Twitter, um, I threw a lot of very deep Googling. I managed to discover he had actually notified Apple, um, about this very issue back in 2008 or at least issues that could affect similar results and those were eventually patched. Um, they did eventually patch, uh, iOS as well against the particular flaw that was exploited in, in this incident. Um, but that patch actually didn't come out for another five months. That was May 30th. If memory serves, that was iOS 1032. Um, so five months later, it is actually patched. And you can see it, these are the, the write ups. If you want to go look at CVE 2017, 2484 and CVE 2017, 2404. Um, and these were the ones that ultimately were exploited to cause, uh, both the 911 denial of service attack and basically the shutdowns on, uh, user's devices or, or basically rendering the devices unusable. So one of the things that I put in the abstract, because we, we thought this was very important was to track, um, the extent to which these vulnerabilities are, you know, potentially hanging around. And, uh, part of the way that we did that, um, we, we went out there and looked at, uh, app-telegent data to see, okay, what's the, the rollover rate? How quickly are people patching? And, uh, I actually, uh, just refreshed this today. And 76% of active, uh, iOS versions that are being seen on the web now are 10-3. And I don't know how many of those are, it doesn't get broken down by sub-point. Um, but we're fairly confident that this problem is going away quickly. Um, but the trouble, and, and I think this goes to show, you know, a lot of folks, uh, kind of poo-poo the notion that, like, well, you know, iOS is always, like, so much better. Well, there's, you know, 11% that are on, still on 10-2. That's a lot of devices across the world. It may, 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. Um, 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've got to propose some solutions. Otherwise, you know, you're really not doing anything for us. So, a few things to talk through. Um, and I, and I want to take a step back for a second because the 911 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 that is, like, strictly analog telephone network. Um, I, this ought to be good for a chuckle. Most of the nation's 911 systems still run on Cama and MF signaling. 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 911 calls are signaled and set up in the telephone network today. Um, Cama is handy, you know, handles a lot of the data. When we get your location in 911, 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 callback purposes. Not caller ID, but automatic number identification. 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 those analog or TDM trunks to connect the local end office class 5 switch with the 911 center. Um, but you're doing some voice stuff. Maybe you have a sort of quasi cloud hosted service provider somewhere in like Colorado, California, or Washington, and you connect up to them over multiple links. And that's how you're doing it. Maybe even in some cases you're doing some cool stuff with location technology. You're adding some data in, bolting some stuff on so that, you know, you're doing some things out of bands so that you can get more data in on the 911 call. That's the transitional case. Where we're headed is next generation 911. Um, that's something that's defined by a thing called the i3 standard that my organization publishes. It's basically a model for all IP 911 service where we get deep, good location data that can be referenced to something that's like human readable like, you know, the Octavius ballroom at Caesars Palace for example. Um, it does things like much more intelligent routing and so on. 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 know, three or four years. So I'm going to talk you through defense 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 first defense 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 no way to do it. You can do contextual whitelisting. Banks do this. So most of the time when you call your bank, they're looking to see with automatic number identification, that's the theoretically not spoofable part of a not caller ID that they use to say, okay, who is this actually calling? And for the most part, it's well trusted because there are so many rules around it for number one. 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 wire line world, you could 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 we don't have a customer list that we can use so we can't do contextual whitelisting. 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. Sorry, I hate it for you. You're over and done. We're just going to block your call now. Which, okay, fine, you did something nefarious, but do you really deserve to potentially die from that, you know, when you call 911 and you're actually having a heart attack? You know, and our members feel very strongly about that. I feel very strongly about that. You know, we, I talked last year at DEF CON about high availability systems when you have to carry traffic. You really don't have an option because it's 911. That complicates matters greatly. When you can't just say, sorry, I don't like your traffic, I'm not going to handle it, 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 technical folks to connect them with our members and whatnot. You can do number reputation scoring. If you've got apps like, you know, I've got HIA on my phone and it like blocks, you know, bad calls for me. 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. That's dangerous because lawyers and it's also a thing that, you know, may be dangerous because of human life. So we've got to be careful about that. I think we'll see some of this done soon with at least flagging. We'll start seeing like a little asterisk somewhere in that 512 character data block that says, this is a little squidgy. Maybe think twice about it before you go, you know, send the SWAT team to Brian Krebs house again. 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 and I'm on one 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 a problem? Like that could be a real threat score. The trouble is for both of these, we haven't tested diverting calls. One way to handle that is to like send the call someplace else like an IVR or proof of humanness test or you got to like dial one, two, three to get access to number one or whatever. Those capabilities exist in some transitional systems but nobody's kind of been brave enough to turn them on yet. So we've got to get, we've got to 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 all the time and not just when we know we have an incident or an attack. And then in the next generation 911 world now, and I love to talk about this because in the legacy world, yes we have lots of vulnerabilities that are, 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. Stir is an IETF track standard for cryptographically signing ownership of number blocks. So if I have, you know, 865-555-1212, the North American numbering plan administrator should issue a signed thing that says that belongs to Verizon or AT&T or TMO or Sprinter somebody. They should sign it saying this particular number belongs to Sinkvallfleet 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 Addis. Trouble with that, as I can't remember if it was Bruce Shiner 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 911. And that is the sanitized version of that line for everybody's, you know, anybody who knows them. 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 going to stop that. That takes time to tune, could go wrong. We can do suspicious call diversion. We have the ability in the border control function of next generation 911 systems to mark traffic as suspicious and then say at a subsequent emergency services routing proxy if we see that 911 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 IVR first, proof of humanist, etc. We get or you know fail it over to an investigatory center that's not handling live 911 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 next generation 911. Also a big work in progress there's a DHS pilot on threat scores using those frameworks that I just talked about and we're also working the I3 standard that I mentioned before and then the other big standard we publish for this is called NGSEC that's the next generation security standard it tells you and it's actually applicable in today's 911 environment too but it sort of tells you what to do to baseline properly configure and secure a big complex Harry next gen 911 system. And on that note I want to encourage everybody because those standards are still underactive development if you know things about these subjects and you want to help we would love to have you join in at dev.nina.org it's an amazing way to contribute to the safety and security of not just the community here in the United States but the I3 framework in particular I3 standard is actually being used in Canada and all of Europe as well as the basis for their emergency systems going forward so this is going to be a global kind of thing and we need the global information security community focused on it to make sure that as we add things like voice video text data etc that we have the capability to to do that securely so we'd love to have you. Before I close here a couple of things I will take some questions if we can do that but I want to say a special thanks to QueerCon we have the coolest badges at all of DEF CON and we do that every year because of some amazing people these guys are my family I love you all it's the reason I'm up here thank you so much also I am the cavalry for those of you who know something about tech and policy I absolutely encourage you to get involved with I am the cavalry we're doing amazing things in DC 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 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 literally every part of our economy so please please you know come join us also check out my other talk in the crypto privacy village hash tag shameless plug I will be I'll be talking there about location tracking so basically in 911 we don't want to track you but sometimes other people do and they always blame us when that happens but I want to 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 anyone anyone