 Thank you guys for coming out. This is an awful time to be up on a Sunday morning. I look at this as 3,400 hours Saturday. Okay. Good morning. So I'm Matt. This is Sandy. What I'm going to be talking about is actually joint work with a bunch of other people from my lab at the University of Pennsylvania. Travis who is here but God knows where he is, Harry Metzger, Zach Wasserman and Kevin Zoo. So normally I don't like to start anything with a disclaimer but in this case I kind of have to. There's a standard thing when you're doing work that's been supported by the federal government they like to be acknowledged. So I should say the partial support for this work was very generously provided by the National Science Foundation and we are genuinely grateful to them for the support. They also ask as part of their standard disclaimer that I say in any presentations about their work, any opinions, findings and conclusions or recommendations expressed in this material are those of the author and do not necessarily reflect the views of the National Science Foundation or the United States government. Which may sound to be true. In this particular case that is true. So I am not representing the United States government here. Oh I am definitely not. So what we're going to be talking about is some work that we first presented last year although I'm going to talk about stuff that we haven't talked about before. So involving encrypted two way radios and how they fail in practice and my hope is that you can understand what the problems with these particular things are but more importantly you can understand more broadly some of the lessons we can learn from this in designing the next system and maybe in designing secure systems more generally because I think there are some real general interesting problems behind this. Yeah so in particular one way crypto and so on. And by generally interesting we are scientists and what we mean by that is we don't know how to do it yet. So there's some work to be done. So in particular the system that we've studied is called APCO project 25. Which sounds it's a bit obscure. It has become the standard though in the U.S. and a few other countries including Canada and Russia for digital two way radio in narrow band frequency allocations. So it's intended to work with the existing spectrum for two way radios that uses narrow band analog FM and be a digital drop in replacement. So it's not a spread spectrum system. It uses the same channelized narrow slices that land mobile two way radio has always used and it's intended to be incrementally compatible so you can kind of move your system instead of all at once you can do it kind of a channel at a time and some radios at a time. It is intended to be one size fits all in that they aim to have a standard that would be widely adopted for everything from local government police dispatch to the radios used for tactical operations by intelligence and federal law enforcement surveillance operatives to some use by the military in battlefield and near battlefield scenarios. So everything from the two way radio used by your local fire department for fire calls to the things at the other end of those coiled ear pieces that the people in the dark suits have to actual war fighters is intended to use the standard or be able to use the standard. And so it includes security options that are not of interest to the vast majority of users. Local police, local fire and so on don't need, don't actually even want to have their radios in general be encrypted because they have interoperability is a major problem. But there are other users like people doing surveillance, wires, war operations and so on that very much depend on security and the same standard is intended to support both the unencrypted and encrypted users. So this has been under deployment since the 1990s, a product started coming out in earnest around the early 2000s and the federal government has become kind of the dominant user. So here's a typical walkie talkie two way P25 radio, kind of the latest generation of it. Here's the previous generation which has gotten to the point that the goons here can use them for talking with each other. And here's the really cool retro 1980s telephone handset. With a two way radio hidden in it, yeah. So because it's a standard there are multiple vendors. In the United States Motorola is sort of the dominant vendor particularly in the federal law enforcement sector. But there are about a dozen P25 vendors that use the user interfaces, the protocols and even to some extent the code base are pretty much standardized across vendors. This is actually an example where the standardization process has mostly work usually, you know, because standards don't work. But here there's at least on the basic level a fair amount of actual interoperability. I went looking for pictures of things other than local law enforcement that are using this. So I found a couple pictures on the left is a picture from a New York time story about Afghanistan. If you look closely on the warfighter in front's chest is strapped to a Motorola XDS 5000 radio. And if you zoom in on the picture you can see that the crypto switch is in the on position. If you zoomed in really, really closely. And you can figure out what the switch means. On the right is an official White House photo of the back of a Secret Service agent at a formal White House event. And you can see stuffed in the back of her evening gown is one of these radios. This is what's at the end of the coiled earpiece. If you zoom in really, really closely on this picture you can see that the crypto switch is in the off position. Just a little push-to-talk button under her sleeve. And also up in her sleeve is the push-to-talk button. So that's what's at the other end of those little coiled earpieces. So the protocol is intended to send traffic over narrow band voice channel, 12.5 kilohertz channel spacing or 6.25 kilohertz in the second version of it. Essentially it's a 9600 bit per second digital channel with voice being the dominant feature, although not the only feature. Using a vocoder called IMDE and in a later version AMDE which provides actually surprisingly good quality audio at that bit rate. It's comparable to the audio quality that you get from narrow band FM radio, although it has different properties as it starts to fail under weak signals. The speech is basically divided up into 180 millisecond chunks that are encoded with a little bit of redundant metadata and error correcting codes around them. So essentially every 180 milliseconds you get a new voice frame that's sent out and if you lose something within 180 milliseconds you'll catch back up after two of these frames, so within 360. It's a broadcast model. So these are called two-way radios, but in fact they are one way, this is a one-way protocol in that the sender makes all the decisions. They are broadcasting to anybody on the frequency. There are no handshakes, there are no sessions or any of the notions that we normally associate with the communications protocol that we might be building over something like the internet or over a high infrastructure system like the cellular telephone network. Here essentially the sender radio makes all the decisions. It's up to the receivers to stay in receive only mode and figure out what the sender did. And so it relies on forward error correction as it's error correcting mechanism and also relies on the sender's security configuration to decide whether the crypto options are on. You don't negotiate with your receiver. So the security options, again they are options. It is based entirely on symmetric crypto. There's no public key involved here at all. The model is very simple. There are a bunch of standardized ciphers. Most recently AES, originally they standardized on DES and there's still a lot of DES users out there, though not in the federal sector. There are also some vendor proprietary ciphers involved. And we know how well they work. Right. And there's support for classified ciphers that can be kind of dropped in for military use, although not typically for federal law enforcement use, even though they often are doing classified investigations, they don't have the NSA crypto radios typically within the United States. The traffic keys have to be loaded into the radio in advance, either with a key loading device that I'll show you in a second, or through a God awful over-the-air recon protocol. Essentially, here are the important features of how the security model works. If you receive clear text, you always demodulate it. So on the receiving side, if you can receive clear text, you always demodulate and play it. If you receive cipher text, you check and see if you have the key material in your radio. If you do have key material in your radio, you decrypt it and play the cipher text. On the sending side, you have a switch typically configured on your radio, although it can be configured in other ways that will switch between whether you're sending clear or sending encrypted. But that affects your outgoing traffic, not your incoming traffic. So the thing that you will notice about this protocol is it is designed to optimize communication. The thing that it is optimizing is getting the message through, which for local law enforcement, you know, where you're yelling out, I'm being shot at, please come help me, is exactly what you want to optimize. But for other applications, this may not be what you want to optimize. You may want to be able to detect, for example, that an encrypted user and a clear user are, you know, in different configurations and have it not work until they're both in agreement. But this protocol doesn't allow you to do that. It's designed to... Oh, I got a slide for that. It is cooler. Yeah, we have the cooler newer one. Okay. So we wrote a paper, we looked at these protocols, we wrote a paper that examines in detail and I've talked about it before, so I'm not going to repeat it here and you can go read the paper. What the protocol weaknesses that we found in this are. Essentially, what we found is they did not make any of the crazy mistakes that people often make when they design a crypto protocol where, you know, if you X or the first packet with the second packet, you get the key or, you know, anything crazy like that. So, you know, in fact, they seem to do mostly the right things with the actual crypto itself. The key generation is usually based on, the IV generation is usually based on real good random numbers as far as we can tell. They don't reuse IVs in their stream mode in any particularly obvious way, although who's to say if they, you know, maybe somebody smarter than us will come along and discover that actually there is a vulnerability there. But if there are vulnerabilities, they aren't the obvious ones. But the protocols themselves are not using standard designs. This was designed kind of for this and designed by a big committee and as we all know, the larger the committee, the better the protocol you get. And this was designed by a large committee. So, there's no authentication anywhere. It's incredibly susceptible to traffic analysis. The unit IDs are sent in the clear even when you're in encrypted mode. There's all sorts of metadata that's sent out in the clear. And we found denial of service attacks that are frightfully efficient. It is much more efficient from an energy perspective to interfere with this protocol than to use it legitimately by a large factor. And there are some serious crypto usability deficiencies. So again, I'm not going to talk about the details of some of the active attacks that we found in the protocol, even though from a purely technical point of view, they're more clever. Because they require an active attacker. And an active attacker at least raises the bar a little bit. So, for example, there's no authentication. So a trivial active attack is that you can do impersonation very easily. Even when you can impersonate clear, you can use the clear mode to impersonate encrypted traffic and introduce false messages or replay messages. You can do that. It's not even broken. It's just not even in there. Since you can program your radio to display any ID you want, you can just become part of the group. And because it's clear, they will always receive it. So, you're subject to all sorts of active and passive traffic analysis. Every radio has a unique identifier, typically a unique identifier. You don't have to, but in practice, anybody using the Over the Erie King protocol uses a globally unique identifier for every radio. The standard says you're supposed to encrypt that when you're in encrypted mode. The standard code base that all the vendors are using doesn't actually encrypt it. And it's not clear whether we were the first people to discover this, but we were certainly the first people apparently to mention it anywhere. The, there's just like, there's some crypto flag that's on, should be on in the code that just isn't turned on. Who knows? Who knows? So what that means is that when people are in encrypted mode, you can get pretty good traffic analysis of who's talking. But we also found some active attacks, which is that if you send, if a radio is configured to use the Over the Erie King protocol, which pretty much all federal law enforcement radios are, and you send them a malformed packet of a particular, with a particularly formed header, the radio will effectively see that as a ping to which it sends a knack back. It says, oh, you sent me a malformed packet. I am user ID number 3, 4, 1, 6, 5, 1. Please send that packet again. It doesn't work for the voice protocol, but it does work for the data protocol. And you can use that effectively to ping a radio at will. Yeah, and it's impossible if you're the person being pinged, unless you've got your finger in the antenna slot and you're actually feeling a little bit of heat as power goes out of your radio, there's no way to detect that you are responding. So these pings are completely undetectable. Right. So this works for tracking radios that aren't transmitting effectively, as long as they're on and within range. So we, thanks to Margo Seltzer at Harvard, she heard about it and said, oh, you can build the Marauder's map from Harry Potter. So essentially, you can take two base stations, ping people, triangulate their location with phased arrays, which is pretty simple to do. In fact, there's, I understand there's a GNU radio project you can use an edis box to kind of do this with incredibly cheap equipment and get a real-time map of all of the users on a given frequency, even when they're supposedly idle. So is this a threat in the domestic law enforcement environment? Well, maybe, maybe not. Is it a threat in the battlefield environment? Ah, they don't care about that stuff, right? Okay. So denial of service is another interesting active attack here. Typically with radios, jamming is this fairly evenly matched arms race with narrow band radio. Whoever has the most power wins. So jamming requires a little more power as received at the receiver as the legitimate transmitter. Which makes a jammer easy to find. Right. It makes a jammer easy to find and it makes the jammer's job at least a little bit harder or at least as hard as the job of the real communicator and you're vulnerable to being detective. With spread spectrum systems, you can actually put the jammer at a huge disadvantage either by using secrets or some clever protocols that don't require secrets, but that would require the jammer to use significantly more energy than what they're trying to attack because they have to spread it over a wider spectrum. P25 manages to invert that advantage profoundly because of the way they do error correcting codes. They got it so wrong. Yeah. So they use error correcting codes, which is good. It makes you more resistant to dropouts, but they error correct subfields of the transmission separately, which is, it turns out bad. So at the beginning of every 17, 28-bit voice frame, there's a 64-bit frame that contains actually about 12 bits of real information that identifies what, that this is a voice frame. If you synchronize and jam this 12-bit expanded into 64-bit subframe, you can prevent the receiver from knowing what kind of frame it is and they'll ignore the rest of it. Now the effect when you do the math is that you need 14 dB less energy than the legitimate transmitter to prevent a signal from being received because you can turn your jamming transmitter off for the vast, vast majority of the time. So the question is, is it practical to build something like this? And that's why we have Travis. So we mentioned this problem to Travis and he said, oh, I have just the thing. The P25 protocols use C4 FM, which is similar enough to a protocol used by the TI 1110 single-chip radio transceiver, and I can just load firmware in there to recognize the beginnings of the types of frames you want to jam and then turn the transmitter on. So, you know, I said, oh, great, Travis, do you think we could actually do this? And he, you know, said, well, give me an hour. And then he gave us my first jammer. So this chip is used in the, there's a device called the GirlTech IME. It's either purple or pink depending on which model you get. It has this chip in it. It's cheaper to buy these things than to buy the chips themselves. So this is actually the cheapest way to get them. They're two for $30 because you want to buy them in pairs and they have a little battery thing and you get a keyboard and a display and a little unicorns and ponies on the box. So you load this firmware in there and it can do all of the synchronization. So we've talked about that in the past. You'd have to add an external power amplifier if you wanted to do real jamming, which would actually increase the price to, you know, more than $15. So here's a scenario for you. Suppose you know that you're under surveillance and you want to block it in some way. How about building a whole bunch of these and putting a little magnets on them and throwing them on the back of taxes? So, and the other interesting scenario is can you use this to train users that their encryption doesn't work as well as the clear text. And so the interesting scenario is the selective jamming scenario where you don't jam everything. You just jam the ones that you can't understand yourself and force them to switch to the clear mode, which is actually trivial to program because you have to read the transmissions in order to synchronize. So you can just look and see, well, what frame type is this? Is it an encrypted frame and then only jam those? And that effectively trains the users that the thing only works if you turn the crypto switch off. So. And I can give you examples of this. So again, the problem with this is that it's an active attack. And, you know, even though, okay, there's Travis and there are these girl tech IMEs, you know, that's probably not a threat today. I mean, you know, give it a week or two, but it's not an immediate threat and there's still some risk because you are transmitting and as long as you're transmitting, you know, you can be detected. And similarly with the active ping attacks, it requires an adversary with a certain amount of infrastructure to do these attacks who's willing to run the risk of actually being found. And this is going to make them very mad at you when they find you. Right. So. It's actually against the law. Right. Not just against the law, it makes them mad. Right. So one kind of more interesting question, even though they're not as technically interesting, is how often do they go in the clear anyway because of the usability and the keying problems that we found? So we found a number of potential usability problems. There's four feedback about the crypto state. Only transmit crypto is controlled by your switch so you can't tell what state it's in by the behavior of your communication. The switch has no effect on received audio. Clear signals always get accepted when you're in encrypted mode. Encrypted signals are always accepted if you have the key material when you're in clear mode so a clear user can happily interoperate with an encrypted user and they just don't get any feedback about what's going on. Now the second thing is if you look in the manuals for all these systems and what all of the users and system administrators of these systems have been told, which is that for maximum security, change your keys. Yeah. Don't we tell users to change their passwords frequently? Right. So the same idea, well change your crypto keys because if you're an agent of some federal law enforcement agency, let's pick one at random. Let's imagine you work for some bureau of the federal government that conducts investigations. I won't single any of them out. Agents do not get captured over enemy territory very often but their keying practices are designed very much to make captured radios not be useful for very long. But the effect is that the over the arc re keying protocol has these unreliabilities built in where effectively what it does is it erases your current key and then tries to get the new one. So what happens is that every time you re-key people end up without keys for a little while. So I'll tell you a story. One thing we did in the going on three years now that we've been conducting this investigation, we have built a taxonomy of how many times we've heard them say X or Y. And I cannot tell you how many times after a particular day of the month one particular agency says, oh fuck the re-keying didn't work. And the other thing we often hear as the first transmission that we hear in the clear is okay I just re-keyed. Yeah. Or somebody giving somebody else instructions on how to re-key and then us hearing both of them. Right. So if you go back to the academic literature you could take there was a great paper it is required greeting for everybody. Your homework after you leave this is go get Alma Witton Doug Tiger's 1999 music paper Why Johnny Can't Encrypt where they looked at PGP and tried to figure out why people aren't using it. And basically they found a long list of usability problems for crypto protocols that you should avoid. This list was apparently used by the P25 designer as a checklist of how they should design their protocol. They made all of the mistakes in Witton and Tiger's paper are in there. There's no feedback to the user, the usability, getting the crypto working isn't tied to the user experience. There's little chance to notice or help. So let me just give you an example. Here's the Motorola XDS 5000 radio. Here's its configuration in the clear mode. Here it is in encrypted mode. Here it is in clear mode. Here it is in encrypted mode. You can certainly see the difference. The difference is... If we go back to our original picture of... We zoomed in on these pictures. And look where the radios are. How are they going to tell anyway? Yeah. So that's the indication. Now you can also get a beep to be configured if you're in clear mode. There's a crypto beep warning, but it's the same beep as the channel is available beep when it's in the trunk signals and the low battery beep when it's... So often people just change in their batteries constantly to get rid of the beep. They're in the encrypted mode. The trick is there's this little symbol. A zero means one state and a zero with a slash through it means the other state. There is disagreement among the user community about which means which. So... Okay. What does that mean to you? To me, it means no, doesn't it? It means don't touch this. It means bad kitty you're going to get smacked. It means air conditioning vent closed. Right. Fee if you're into group theory. The null set. It means goes to quiet if you're into language stuff. So they have these... Yeah. So it's also... It means either open or closed is apparently the metaphor that you're supposed to understand that symbol with. So we made up hats that we've been giving out to feds and shirts with the... When I put this hat on you can't understand... We have a few of these for swag for good questions. So one of the problems is that keys are set to either expire or be rigorously enforced because changing your keys is good. That causes people to go in the clear though. There's no way to rekey the radios in the field. Even though there's a keypad on the radio, you can't actually use that to enter a key. You have to either use the over the air reking protocol or a key loading device. Here's the latest and greatest version of the load AES keys in it. You're told keep this in your safe. Don't let this out in the field because it has keys in it. And so people who are conducting a surveillance operation and so on don't have any chance of fixing a problem even if they detect it. And they're ridiculously expensive so every group only has one. Yeah, these are government prices. And they require that you punch in about 64 buttons without making a mistake. And if you make a mistake you have to start over. So the active attacks are interesting but they're probably, we found no evidence that the active attacks are actually being conducted by bad guys. We were interested though in the question of how often do these passive problems result in unintended clear attacks? And besides that we're lazy and passive attacks are much easier. Right. So Bob Morris, who was a technical director at the national security agency, gave a public talk at the crypto 95 conference. He repeated a version of that talk here a couple of years later but the first time he gave it was at the crypto 95 conference gathering of cryptographers in Santa Barbara every August. We got him to give the keynote address. And he revealed the NSA's first rule of crypt analysis and we all got out our pens and papers and wrote it down because we thought we were going to be told something about well you use Gauss's formula here and do this. But what he said was NSA rule number one of crypt analysis, look for clear text. So we decided to actually do that. So in our lab, when we started playing with these, we got some of these radios. We inadvertently misconfigured one. We got the frequency that we were trying to enter into it off by like 10 megahertz or something like that by entering the digits wrong. And suddenly we start hearing this really interesting sounding surveillance operation. And they were actually in the neighborhood of the university and they were talking in kind of, you know, a fed speak. And it sounded, it was like having our own private version of the wire. It was really interesting. And they clearly were referring to being in encrypted mode. And that was really surprising. So we decided to collect some statistics about how often this happened. So we wanted to focus on confidential federal law enforcement traffic. So we omitted local agencies, non covert operations. You know, the national park service uses these radios. We didn't care about them. No offense to anyone from the national park service. So we were focusing only on the federal law enforcement that was doing confidential surveillance operations. And we wanted to see, well, how often are they actually going out in the clear? So we wanted to be very systematic about this. So it's easy to pick up unintended clear federal traffic. In fact, scanner hobbyists do this all the time. But we're scientists and we overdo things. And besides it, let's us get all really cool equipment to play with. Well, that's true. But so we wanted to have this government law really systematically. How big a problem is this actually? How often does this happen? Are these usability problems actually, do these actually represent a serious problem? And we wanted to get data rather than anecdotes of, hey, we hear the feds from time to time. So we decided that the best thing to do would be to build our own little SIGINT network. And collect clear P-25 content and the metadata in several cities just like we were if we were a hostile intelligence service trying to find out what's going on and do this soon. So please understand. There was a really good paper at Ruxcon in Australia a year or two ago where they looked at the P-25 radios and decryption. And of course, everyone knows DES is broken and they showed how it's broken on these radios as well. We did not bother to look at the crypto. If AES is broken, we have other problems besides these radios. And we didn't have to. And why should you do any more work than you have to do? We were just looking at clear tests. Right. And even though we have Travis and Tamara, we don't want to use it. Right. Not outside of the lab. Right. We don't want to actually cause them any more harm than they've already got. Because just the pure passive attacks are bad enough or we wanted to find out at least how bad are they. So one problem is we wanted to build our own little NSA on the cheap but we do not actually have the NSA's budget. So how do we do this? So we got off the shelf equipment. First, we started. We wanted to use edis boxes running into new radio because they are cool. Unfortunately, they're not quite able to do real-time IMBE decoding with the current versions of the softwares. They may be now. When we started three years ago, it wasn't mature yet. But a lot of things have been done and we're looking at it for the follow-up paper that we're going to be doing on the over-the-ary keying. So they may be useful for that. So we ended up not getting cool software-defined radios for our second operation. We instead used a purpose-built software-controllable radios. We ended up getting the ICOMR 2500s which are aimed at the hobbyist scanner market. But the interesting thing is there's a P25 option board that does pretty good quality decoding of the P25 audio. So what did we do? Well, there are 2,000 roughly channels in VHF and UHF that are allocated to the federal government. About 24 megahertz of spectrum. Law enforcement is mixed in with unsensitive stuff. And some of the frequencies they're using are well-known. Some of them are not. There's a website called radioreference.com which is mostly nonfiction but contains a lot of fiction. So we decided to just ignore it and used a slightly different approach for identifying which channels have the sensitive traffic on it. How did we identify which channels have sensitive traffic on it? They're the ones with encryption. So we found the frequencies with encrypted traffic on it and we basically identified candidate frequencies for sensitive stuff as what those were. Then we deployed a network of these R2500 receivers running, tethered to computers, running software that we built to collect data in a systematically and analyzable way in a variety of unnamed cities that we cannot tell you the identity of because we don't want to actually... Be rated. Well, we don't want to reveal information about who is sensitive. Who is vulnerable to this. Although everyone is vulnerable, we know that they are vulnerable in certain cities that we are not actually allowed to tell you because of our institutional review board rules about human subject data. So use your imagination about what cities we're seeing. So to recap, the equipment you need is one radio capable of doing P25 and they're fairly inexpensive. About a thousand bucks with the plus, including a network computer. Yeah, one netbook and a little bit of really crappy C code. Yeah. And we're going to release our crappy C code probably over the next few weeks. Right now we can't do it out of fear of embarrassment, but we're working on unembarassed. We'll clean it up and make it look actually. It is research grade software. It's grad wear. Yeah. So research grade, yes. So what do we do? Well, we collected all of the clear text audio and metadata and all of the metadata on these channels. And what we found was that in fact, most traffic is successfully encrypted, but about 30 minutes per day per city of traffic isn't encrypted. Now there's high variance. It turns out this happens much more often during the normal work week than on weekends. It happens much more often on the week after rekey day than it does before. When there's the larger the operation, the higher probability that there's some sensitive clear text going on. So what do we capture? Well, we got occasional sensitive clear content and a lot of metadata because the metadata is in the clear even on the encrypted traffic. Yeah, we never found a case. Never. Yeah. Nobody makes equipment that gets it right where they encrypt the metadata. And then we discovered that actually doing this systematically is incredibly powerful. Traffic analysis when you actually go to the trouble of collecting the data as opposed to just poking around and seeing what you're hearing, it allows you to take the stuff that you've gotten in the clear, which is only a tiny percentage of it, and use that to make really good inferences about what's going on in encrypted mode. And, you know, there have been books written about this. The Zendian problem book is sort of the classic text on this. This was an NSA course in traffic analysis where you get a little encrypted traffic and a lot of traffic you can't decrypt and you're supposed to make inferences about what's going on. That stuff works. So you essentially can find out by looking at all of the metadata you learn well what user IDs are associated with what agencies. We discovered that one agency that we will not identify we found a list of offices of this agency and each office of this agency was numbered. We found out that number was embedded in the user IDs that they have so we can find out which office is actually doing an operation by looking at their IDs. And since they sometimes list the employees of various offices then you find out who. Yeah. So you can use that when they go out in the clear you learn a little bit who are their names what are the some of the operations that are going on. The best phrase to listen for is okay everyone here's the plan. How sensitive is sensitive? So what we found included actually some of the most sensitive investigative data that the government handles. They talk because they believe this is encrypted they are much more direct about what's going on they're not circumspect anymore they don't speak in coded languages it's not agent 25 we're at location B it's you know hey Fred. Well one group actually does use agent and we can tell you which agency it is. We can tell you which agency it is by their banter. Everybody's got their own particular culture and after listening for just a few minutes you know who it is and some of these guys you know are really jokey some are really silly some things that go across the air are downright embarrassing. Can I tell the open mind story? Okay so one time one agent had her microphone open while she was on the telephone arguing with her spouse about who ruined who's sister's wedding. And it went on for a long time. Apparently that agency didn't have the timeout timer configured on their radios. But you know that's sort of funny and embarrassing but we also are getting things like you know the name of the confidential informant. Whether or not there's a helicopter what cars they're in there's tag numbers who they're following what the person's following. We can give you some great tips on how to avoid surveillance. But yeah it's kind of like looking at their cards. Yeah. So you know mostly this is not classified traffic but there are occasional protective details for you know certain high-level executives of the federal government. Some counterterrorism some counter intelligence traffic. You know everybody is vulnerable to this it doesn't matter what you're doing unless you're in one particular agency that we cannot identify that does not ever go in the clear. And anybody does anybody want to take a guess for a hack? Can anybody tell us you get one guess so make it good. Who does not you serve? No. No. No. No. One more guess. Yeah. No. No. No. No. You guessed already. You have to sit down. Somebody else is doing. But you were wrong anyway. What? Nope. Nope. Yeah. What? No. No. No. No. Yeah. All right. One last guess. Okay. Yeah. Oh. Yeah. Sorry. One last guess. Yes. Yes. No. No. Not Secret Service. Not Coast Guard. No. Anyway. Yep. Nobody ever guesses. Not just in the ready remat or in the Q and A afterwards. Energy? No. No. No. Somebody got it. But somebody who said Postal Service. Postal. Come on up. Do not mess with the Postal Inspector. They are everywhere and they're invisible. On the flip side of how funny or boring some of the stuff we've heard is some of it has been scarily sensitive. And one thing that we have learned from listening to these people, whatever your belief about whether or not the laws that they are trying to enforce are good laws or bad laws, the people are doing their jobs and they are very, very good and very professional at doing their jobs. But damn it, they can't use the equipment right. And they can't use it right because it's designed in ways that make it difficult to use. One of our people working on this hadn't been playing with the radios for about three months, came back and couldn't remember which way the crypto switch went. And using these wrong puts these people's lives in danger. And one thing that we caught a lot of was trying to rescue victims of human trafficking. And that's a fairly dangerous position to put in. I'd like them to succeed at that without their radios blowing their cover. So, you know, what did we do? Well, before we published the first of our results, we naturally wanted to kind of mitigate some of the harm. I mean, we had sort of one temptation was to go and become master criminals. But we rejected that option for the record. So we also realized that the passive attacks, although some of them are sort of embedded in the standard, can be mitigated with better configuration and better procedures. So we did reach out to the user community. And the active attacks are long-term problems that require fixing to the standard. So we also reached out to the standards community. So one question is, well, you know, who would react better? So in the short term, we approached the feds. We very politely went to various levels of the different agencies that are having some of these problems, both from their headquarters levels to the local, like, field offices, like, five, yep, got it, to the local field offices. And in fact, you know, one of the things we were worried was that we would leave these meetings in hand cuffs. But in fact, they understood... It would be all his fault. I was led astray. You know, in fact, they were actually receptive and appreciative universally at all levels. But... They really got it. They really got it. And we've had these very satisfying meetings and, you know, with the right phone numbers to call. And every time we would have one of these meetings with an agency, we would see their unintended clear text drop really rapidly and then go up to past where it was before, after about a week. And so there's something where paying attention to the problem causes it to become worse. We don't understand this. Which we do not fully understand. In the longer term, we've got to fix the protocols and the standards, and that's going to require the vendors and the standards body, the P25, to actually take a good, hard look at it. Because it's obvious, for one thing, that they didn't include people like us. People whose research is the security of communications protocols in the design of these. And then when they implemented, it's obvious that they didn't include people like us, people who professional and amateur penetration testers to look at this. So they had no idea whether it works or not, but then they went ahead and implemented it and sold millions of them. So the least pleasant four hours of my life were at the P25 standards body. There's a microphone, by the way, up here. The P25 standards body where they spent the first three hours of the meeting explaining all of the different ways in which I'm an idiot. And then all of the vendors pretty well agreed that all of the protocols and products are just fine and the problem is the users. So you'll argue with them and you'll say not being able to re-key in the field is a problem. What if you have to add a different group and you don't have a key loader? But finally, the only argument we could make is, you know, it doesn't matter whether the problem is the users. You can't fix the users, so fix the usability. Right. So much finger pointing and enjoyment. So I got many more entries for my security excuse bingo as a result of this. I am writing an iPhone app for this. It will be released publicly. So if you want to play this, it will be right now. We have time for, like, you know, .25 questions and then we'll have the Q&A room later. So, sir. Okay. So .25 questions. Would you say that? What? I'm sorry. So what you described where you notified law enforcement and the amount of, basically the amount of clear, unintended clear traffic went down and then went back up. Right. To me, that speaks of they changed the policy and then immediately it became the fact that the new policy got in the way of doing things so people subverted it. Yes. That's possible. I think that's very probable. So what I would ask is how much insight have you been able to gain and I don't know whether this could have been your interaction with law enforcement could have been basically from reading the manuals and knowing how these things have to happen. How much insight did you gain into what sort of the obvious choices for policies and procedures around this would be? And do you have any suggestions? Yeah. So we actually have a mitigation guide that as far as we can tell has not actually been implemented yet within the federal sector. The immediate term problem was telling people, you know, what they did was they told people pay more attention to this, make sure the switch is in this position. And then they remember that after a week what they remember is fiddle with these switches. Right. Right. Yeah. Okay. So I think we're right up at the end. So speak quickly until we get the hook. Yeah. The question is on the jitters radio that's the government standard. How does it compare to the P-25 and is there any other cross-volume versions that you should worry about? Yeah. It's got a completely different set of issues. It does not share any of the problems with this and has its own set of issues. Yeah. Yeah. The last one. Go ahead. Real quick. Yeah. Okay, good. Thank you very much.