 Thank you very much for standing in line or whatever you had to do to come see me talk. This is awesome. I'm desius. I'm so stoked to be speaking at DEF CON. It's pretty easy to figure out who I really have in real life and what company I work for. And I want to make it clear that I'm here speaking on my own behalf. I'm not here as a representative of my employer. And what I'm going to talk about is surveillance systems in the Internet and how they work and actually some concerns I have about how they're architected. So there's this great debate that's been going on for years now about the nature of surveillance in the Internet infrastructure in the future. Are we going to have an encryption so that surveillance of our communications is essentially impossible? Or are we going to have systems that are built into the Internet that enable the government to surveil our communications when they decide that they need to? So one of the first sort of salvos in this discussion was the clipper chip. The clipper chip was a crypto system that had a back door so the government could access the contents. It also had a flaw which was discovered by some cryptographers and as a consequence didn't become as popular as they thought it was going to. That was in the early 1990s. Around the same period of time the US government passed a law called the communications assistance for law enforcement act. This law requires telecommunications companies to create interfaces that allow law enforcement to perform surveillance. The reason for this law, at least the justification for the law that was presented is that telecommunications networks are getting more and more complicated. So it used to be the case that if you wanted to wire tap somebody you could go out with your alligator clips and hook up to a junction box. As the systems have become more sophisticated it's more complicated to do that. So we need an interface that allows us to collect this data. Originally there was this agreement negotiated within Kaliya such that it only applied to what we consider to be voice telecommunication systems and that data internet networks like that didn't apply to them. And in 2005 the FCC made a ruling that said that broadband internet providers were telecommunications companies and so Kaliya did apply to them. And so now we're beginning to see this technology rolled out into the internet. In fact in Europe various governments required this kind of technology to be rolled out into internet networks before the United States did. So the IETF got involved and they published an RFC in the year 2000 which talks about whether or not the IETF will consider requirements for wiretapping when they're designing the protocols that the internet is based on and they decided that they would not do that. And there's a bunch of different reasons why. One of the reasons that they stated was this sort of dichotomy that a lot of people think exists where they think that wiretapping in the future will either be easy or impossible because we either have end to end encryption or we do not. If we have end to end encryption you can't wiretap. If we don't then you hook up somewhere where things aren't encrypted and you don't need an interface built in for that. So one of the other arguments they made is that the internet should be free from security loopholes. And so if you built interfaces into the internet that enabled wiretapping someone might misuse them. Someone might gain unauthorized access to them. And that's a concern. So perhaps we shouldn't design those weaknesses in. However they did say that if you were going to design a surveillance system into the internet that you should tell everyone how you did it. You should publish the details of your architecture. And there's two reasons for that. The first is that it allows peer review. People can take a look at your architecture and see if there are any security weaknesses in it. And the second thing is really that almost all of the architectural underpinnings of the internet are available for all of us to read in RFCs. And so if you had some surveillance system that was a part of the internet infrastructure that was secret and no one could understand how it worked that would almost be antithetical to the way that we go about designing the internet. So in keeping with that policy Cisco published an RFC that described the interface that they built within Cisco routers for performing wiretaps. It's not an internet standard because the ITF decided they wouldn't have those. But they published Cisco's architecture within the IESG so that it would be freely available within the same documentation set and you can go read about it. Cisco had to build this because their customers demanded it and because the governments of the countries their customers are operating in essentially forced them to. And it's the architecture they decided on was based on some previous technical standards that were defined by the European telecommunication standards institute, Etsy. Some of these Etsy standards are available online. You can find them on cryptome.org. So the way it works is the SNMP V3 interface and by sending an SNMP V3 request you can provision a wiretap and it's available in a bunch of different sort of edge routers that large ISPs would be using. Let's talk about the architecture a little bit. This diagram is from the RFC and some of the entities in this diagram are actual pieces of equipment and some of the entities are organizations of people. The first organization of people is the LEA. That's the law enforcement agency. They get permission to wiretap a suspect and they bring it to the ISP. And the LI administration function is this organization of people in the ISP who handle this interface for law enforcement. So law enforcement comes to them with the warrant. They validate that the warrant is valid and they go ahead and provision the wiretap. You can actually outsource your lawful intercept administration function if you're a large ISP. This is just marketing material from a number of different companies that offer to perform this service for you. So they hire lawyers and they have people who understand the technology. And so when the law enforcement wants to access your network they provide the access. The wiretap is provisioned using this thing called a mediation device. The mediation device is really the heart of the wiretapping system. And what it does is it sends interception requests to various intercept access points, various places where you can collect data. The data is collected and then it's sent back to the mediation device and the mediation device packs it and sends it on to the law enforcement agency. So there's two kinds of, well before I get there I'm going to talk about mediation device vendors. This is just a partial list of vendors who make mediation devices that are compatible with the Cisco architecture for lawful intercepts. So there's a bunch of different companies out there that make this technology. That picture is from one of the companies they're called Verrent. I picked their pictures out because they have really nice looking marketing material. So I want to point something out about this picture. So this sort of describes the process that they're going through. At the top there's a warrant. And the warrant is, you know, enables them to use this technology to find this red individual who's the target amongst all of this other communication that's going on. And we filter the red individual out and now we have actionable intelligence based on our monitoring of that person. That's the technology they're selling. So I just want to point out that there are other products that these companies make. And a number of the different companies in the list including Verrent also have, as opposed to lawful intercept solutions, they also have mass intercept solutions. And they have marketing material about their mass intercept solutions. So this is the marketing picture for their mass intercept solution. There is no warrant at the top. There are a large number of people there. None of them is identified as the individual target. The technology actually filters out a list of a number of different new suspects for them to investigate. So that's a completely different kind of technology. I don't know exactly how it works or in what context it's sold. Perhaps it's only for use in war zones. I don't know. But I thought it was interesting. I thought you would think it was interesting. So let's go back to the subject of hand. This is lawful intercept. The mediation device accesses two different kinds of intercept access points. There is the IRI IAP over on the side there and then there's a content IAP. This is a consequence of this ancient distinction that most western legal systems make regarding what kind of authority law enforcement needs in order to access certain kinds of information. So the most ancient kind of telecommunication system is a letter and usually letters have envelopes and the addresses are on the outside of the envelope. So your postman can tell who you're receiving letters from and who you're sending letters to. And so that's not as private as the contents that are inside the envelope. And most western legal systems acknowledge that distinction. And they say that if law enforcement wants to know who you're sending letters to and who you're receiving them from, they need a certain level of suspicion and a certain amount of documentation. And if they want to actually open the envelopes and view the content inside, they need to establish a greater level of suspicion and they need to have even more documentation and authorization. So this actually ends up impacting this technical architecture in the internet where you have these IRI IAPs that only collect addressing information. They collect two and from addresses and other things like that. And then on the other hand you have content IAPs. And content IAPs can collect the entirety of a communication, not just the headers. So I'm going to forget about IRI IAPs. A number of them are manufactured by the different companies on the list in the previous slide. Cisco routers are content IAPs. They provide the full content. So if we go back to this diagram here, you can see this interception request gets sent from the mediation device to the content IAP. The interception request tells the content IAP what content we want to collect and that content is sent back to the mediation device by the content IAP. The interception request is an SNMP V3 request. It's a single UDP packet that goes from the mediation device to the router. It tells the router everything that the router needs to know about the wiretap. What addresses, what IP source and destination addresses you want to collect, what source and destination port numbers you want to collect, and where to send the content. Where does the output go? And also what transport to send it over. I'll talk more about that in a minute. These are just little pieces of the MIB for the interception request. There's actually a whole bunch of different information that can be specified in this request. And the whole MIB has been published. You can Google it. It's called the TAP MIB. So let's look at, you know, the reason that the ITF said that these things should be published is so that we can look at them from a security perspective and see whether or not we think that they're strong or weak. And that's what I'm trying to do with this work. So let's consider, you know, what security concerns exist for lawful intercept. And I don't evaluate all of these issues in this talk. I'm only focused on the third one, but I wanted to mention all of them so we have like a full framework for how you analyze these things. So the first thing that you need to consider, if you were going to design a system for wiretapping is that you need to make sure that the subject does not, cannot figure out that he's being wiretapped. And if you go read the RFCs for the Cisco interface for lawful intercept, they explain how they go about doing that. They talk about how you don't want to have an additional hop that shows up in the trace route when wiretaps are happening, for example. So there are certain decisions they made to make it invisible to the user. It's possible that when this feature is enabled, it could affect the performance of the router, but it might be difficult to differentiate that from other things that can affect the performance of the router. So that, and I didn't evaluate that, so I'm not absolutely certain. The second thing you need to consider is, and there's a really awesome paper by Matt Blaise called the eavesdroppers dilemma. And if you're interested in this, I highly recommend reading it. He talks about how if you're an eavesdropper, what do you do with data that's malformed? What do you do with a packet that has a bad checksum? You can either include it in the information that you're displaying to the law enforcement agency, or you can throw it out. If you include it, it could confuse the law enforcement agency. The guy who is being tapped could generate a bunch of extra data with bad checksums, knowing that it will never reach its destination, in order to provide a bunch of cover traffic that basically, you know, misdirects the person who's surveilling them. If you choose not to include it, then the guy who's being surveilled can send all of his traffic with bad checksums and just configure the computer on the other end not to do the checks. So it's a difficult and interesting issue. And again, I recommend reading about it, but it's not what I'm covering in this talk. What I'm talking about is unauthorized access. And there are two sort of different kinds of unauthorized access you need to be concerned with. The first is making sure that people who are not authorized to provision a wiretap cannot do so. And the second is to make sure that the people who are authorized to provision a wiretap are only collecting the data that they were actually authorized to collect. They got a warrant to look at Bob's stuff, they only collect Bob's stuff and not Carol's stuff. So let's talk about that. Let's talk about gaining unauthorized access. This is a network map. It's an example network that just kind of shows you how this looks when it's actually deployed in an ISP's environment. There's this IAP edge router down here that's providing service to a bunch of customers. And one of those customers is the surveillance target. Somewhere within the ISP's cloud, there's this service provider management network. This is how ISPs run their networks. They have SNMP monitoring servers and a bunch of other machines in that network that they use for running all of their gear. In that service provider management network is the mediation device. Hopefully behind another firewall. So this is how this is supposed to work. If you look at the red line, traffic flows. The mediation device sends an interception request out to the IAP edge router and the edge router collects data from the surveillance target and sends it back to the mediation device. This is sort of an idealistic attack scenario. The attacker out on the internet sends his interception request to the router and the router sends the intercepted traffic back out to the attacker's server on the internet. So how do we accomplish this? Well, we have to send an unauthorized interception request. Again, it's a single UDP packet. It's an SNMP V3 request. It has to have the correct username and password. You have to know the correct username and password with one caveat, which I'll disguise. You also have to have the SNMP V3 engine ID, engine boots and engine time values. Those are three numbers that SNMP V3 uses to prevent replay of requests. You can get them from the router as long as you can talk SNMP to it. You don't need a username or password to get them. It will hand them out to anybody who asks. And they can be shared between different people. So if you ask for it, you can hand it to Bob and he can use it. So it doesn't matter what source address you're coming from. The attacker would need to be able to interact with the interface, at least to send a packet that the interface will receive. So packet filters could play a role here and I'll talk about that too. Obviously because it's a single UDP packet, it can be spoofed. But there are caveats to that. Also encryption might prove to be an obstacle and I emphasize might. So the first thing you want to do, as I said, is you got to have the right username and password. So it turns out that there was this vulnerability in SNMP V3 implementations which was disclosed in the middle of the summer of 2008. That allowed somebody to access an SNMP V3 interface without knowing the password. It affected a bunch of different implementations. SNMP V3 messages are actually authenticated using an HMAC. The HMAC is calculated with the password. So when a router receives an SNMP V3 request, they're supposed to, the way the RFC is written, it's supposed to take that HMAC out and check to make sure it's 12 bytes long. If it's not 12 bytes long, it throws the HMAC away. It throws the packet away. If it is 12 bytes long, then it goes further and does verification. It turns out that that particular piece of code was not actually implemented by a bunch of different SNMP V3 implementations. So regardless of how long the HMAC was, the software would proceed to the verification step. And that function there is the actual verification function. The software would go calculate its own HMAC and then it would compare it with the HMAC that was in the packet. And it used the link from the packet to do that comparison operation. So if you send one byte as your HMAC, and that one byte happens to be the correct first byte for the real HMAC that you're supposed to send, your packet is accepted as valid. In practice, this means that you send 256 requests, one for each possible byte, and one of them will be accepted. So you don't need the password. As I mentioned, this was disclosed in June of 2008. It impacted a bunch of different vendors. What's interesting is that a lot of the iOS software trains that support lawful intercept were never vulnerable to this vulnerability. And both the vulnerability and lawful intercept have existed in iOS version trains for many years. So it's, obviously Cisco had two source branches here. One of them had the bug and one of them didn't. I did find one version in particular that had both the bug and the feature. There were probably others. I didn't exhaustively search the list. But the Cisco 10,000 series Ryder supports this particular version train of iOS and it had both the vulnerability and the lawful intercept feature. Another thing I want to say is that this particular series of Ryder supports IP VPNs. And IP VPNs are a personal pet peeve of mine so I like grinding this axe. When I think of a VPN, I think of encryption. And there are a bunch of people out there who sell VPN systems that are encryption based. But the service provider industry sells service provider VPNs. They use the word VPN, but these VPNs do not have any encryption in them. And I think it's misleading. I think there's a lot of companies out there that buy these things thinking that they're buying encryption. And if you press the service providers about it, they'll say, it's okay. Our networks are not subject to surveillance. So it turns out that yes they are. And in fact, you can specify a VPN that you would like to listen to within the interception request. So in fact, there is a reason that there's a good reason for making a distinction between encrypted VPNs and other kinds of VPNs that are not encrypted. Anyway, let's say that the router that you want to target has been patched. And that's probably a realistic scenario because the vulnerability was disclosed two years ago. A lot of people don't patch the routers very often because it's complicated. It involves downtime, et cetera. So there may still be some machines out there that are unpatched. But if it's patched, you've got to brute force the username and password. It turns out that SNMPv3 makes this easy. It provides verbose error messages whenever you try a username and password. If you send a bad username, it'll tell you the username is bad. So you can try usernames until you get one that works. And then if you try a password, and it turns out that your password was bad, it'll tell you it was the password that was bad. And you can keep trying passwords until you get that right, too. So it's pretty easy to brute force. And one of the things you might think if you were doing all that brute forcing is that you'd be caught because it would generate a bunch of logging information. It would freak out that someone was trying to break into it. Well, it turns out that it doesn't do that either. The documentation seems to imply... So let me go back. In SNMPv2, they didn't have usernames and passwords. They had community strings, which was sort of like a password without a username. And if you configured your router to send traps, authentication failure traps specifically, then if you send an SNMPv2 request to the router with the wrong community string, the router would generate this authentication failure trap. So people running large networks with SNMP devices could tell if people were trying to crack their community strings on their network. The documentation strongly implies that this is also true for SNMPv3. That if you have these traps configured on your router and someone's trying to crack your username and password, those traps are going to get generated and you'll be able to know that this is going on. But it turns out it actually doesn't work. I tried a bunch of different iOS versions and no traps or informs are generated when bad usernames and passwords are used. So I told Cisco about it because I figured it was an implementation bug. And they decided after deliberating for a while that it was actually a problem with the documentation. And so there's actually this bug number down here in CCO. You can look up. It tells you that the documentation is wrong and in fact they don't generate any traps or informs when authentication failure occurs. So the other thing is that you'd think that once you got in and you started your wiretap up, that would result in some sort of audit trail. But actually that doesn't result in an audit trail. The person, so inside the MIB for the interception request, you can actually turn notification off. You can say, don't tell anyone about this wiretap. Keep it a secret. It's between you and me, router. So this is this is really bizarre in my mind. And I'm going to skip slides a little bit. What kind of technology allows the user to turn the logs off? Unix shells, you get loggy, it's syslogged. Unless you're root. DHCP servers have logs. SMTP servers have logs. All these systems are constantly generating audit trails all the time. This is the only technology that I think I've ever seen where the user can just turn the logging off. We know that this audit trail problem exists in a bunch of different architectures. It's not just the Cisco interface, it's not just Cisco's issue. It's actually something that exists in telecommunications infrastructure which was designed based on completely different technology by totally different people. And it's been attacked in the past. So there's this IEEE Spectrum article called the Athens affair that was published in July of 2007. It's a really good read. There was this and this involved an Ericsson cellular phone switch in Greece. No Cisco equipment was involved in this case. What happened was that the switch started crashing and Ericsson's third level support guys were sent down to Greece to find out what was wrong with the switch. And so they started looking at the core dumps and they discovered that there was assembly code in the core dumps that their engineers didn't write. And it turns out it was spying on people. So that's got to be the technical support escalation nightmare of all time. And what it did is access the lawful intercept feature in the switch and use it to spy on a number of members of the Greek government. And the reason that no one knew that this was going on is because the architecture was very similar. There's a system for provisioning the wiretaps and all the logging is built into that provisioning system which is much like the mediation device. And then the actual switch where the wiretaps actually occurred, it had no audit trail. So there are fundamental requirements, architectural requirements that are going into these lawful intercept systems of different variety that are driving this this design decision. And I'll talk later about why this decision was made. But I want to point out a couple of other things. In addition to the fact that this can be attacked, it's also important to point out that allegations of misuse of the system cannot be investigated. If somebody says, hey, I was wiretapped illegally, I'm sorry there's no logs. So we can't figure out whether or not you're lying. So that's another issue. But if you think about it, in Europe there are these data retention laws that require ISPs to store all of the audit trails from all of these systems that the ISPs are running. They have to store the source and destination of every communication for six months to two years in Europe. So there are laws that require all of your activity on the internet if you're in Europe to be retained so that it can be investigated in the future if there's some allegation that you did something wrong. But the wiretapping system in the exact same networks does not have any audit trail at all and there is no way to go back and investigate an allegation of misuse. So what's up with that? It seems very clear that that's hypocritical. So I'm going to go on to the next issue but once I get further into this talk, I'll explain exactly why they designed it that way and how they can design it differently so that it doesn't have to work that way. So another neat feature of this system is that the output stream is very flexible. Once you've provisioned your wiretap, you can send the output to any destination on the global internet over any port using four different encapsulation schemes, one of which is or two of which are UDP based, one of which is TCP and one of which is STCP based. So you can send this thing anywhere and you make you can make it look like anything. For example, you can send it on port 53 as a bunch of UDP packets. So it looks like DNS traffic and I included a picture of Dan Kaminsky because every time I think about DNS I think of Dan. Now there are a couple of things the ISP can do to protect this interface and in fact if the ISP configures the interface properly, they can in fact prevent these attacks fairly well. I just don't think that most of them are and I'll explain why. One of the key things that ISPs like to do to protect stuff on their network is use access lists and all of the SNMPV3 hardening guides and information from Cisco recommends these infrastructure access control lists that say that will only accept SNMPV3 from our management land and I figure a lot of ISPs have those access lists configured. So in theory you can spoof this interception request but in practice you probably don't want to because if you're cracking usernames and passwords you're going to want those error messages to come back to you so you're not going to want to be spoofing. So I'll just go on. The consequence of this is that I think that this is a more realistic attack scenario. Somebody has owned a machine in the service provider management network and they use that machine to send the interception request to the edge router and then the edge router sends the wiretap to some system out on the internet. You don't have to keep control of that machine for very long. You only have to send one packet to initiate the wiretap but you probably want to do it from within the service provider land. But service lands are impenetrable. You know, no they're not. Some people argue that if you're in the service land you basically have you own the ISP and so you could perform wiretapping if you wanted to regardless of whether or not the system exists. There's a couple of flaws in that logic. The first thing is that there are a lot of people who have access to the service land who are not authorized to be engaged in wiretapping. And another thing is that the existence of the wiretapping system makes it very easy to do this. And so it becomes more attractive to an attacker when it's cheap. There is a frack article from a few, it's almost ten years ago I think, that talks about if you get in a router and you have enable access you can configure IP and IP tunnel from that router to some place out on the internet and have the traffic go all the way out there and then all the way back and then come back out the router. And so that's a way of putting a wiretap in a router if you have control of it. It's kind of an interesting idea in theory but it introduces massive amounts of latency and it's not very practical. This system is extremely practical, it's very easy to use and so it actually makes breaking into the service land more attractive than it otherwise would be. So there's another kind of access list that's actually way more effective than these infrastructure access lists that an ISP could potentially configure but I don't think a lot of people used it because it's not well documented. You can configure an access list for an SNMP user group and you can say this user cannot use this interface unless they come from a specific IP address. And again you can spoof the request so you know and the other thing is you, things like the SNMP 3 engine values again can be shared between sources so you could have collected them from your address because you can interact from that address and then just send the interception request from this IP. So it's not a perfect solution. What it does that's actually kind of interesting is it gives you an audit trail. If you send a packet to the router from the wrong address and you have this access list configured the router will send that authentication failure trap that I couldn't get it to send when you have the bad password. So that's bizarre but it's actually pretty useful if you have to run this on your network. So another thing you could try is encryption. The documentation says although encryption is not necessarily a requirement is highly recommended, you can get this lawful intercept feature on your router even if your router does not have an encryption iOS build and there are certainly places where people are operating this system without encryption. I don't think you can adequately protect this system without encryption. But there are places where they're required to run it even though they don't have encryption. There are two kinds of encryption you could run if you were going to run it. One of them is SNMPv3 encryption and that's a pretty decent idea. It doesn't solve all of your security problems but it it makes things harder for an attacker. You can also implement an IPsec tunnel and that's what people are usually doing for this. That's what the RFCs recommend but an IPsec tunnel doesn't solve all your problems either. So an IPsec tunnel exists at a different layer than SNMPv3 and it says all of the traffic between these two addresses will be encrypted. So you have a tunnel between the mediation device and the IP edge router. Well let's say I'm launching my attack. I launch my attack from this other machine that's not the mediation device and so the router is not expecting that attack to be encrypted and so it accepts it. In the clear and I'm sending my output to another destination address that is not the mediation device and so that destination address is not inside the IPsec tunnel and so the router is going to send it to me in the clear and so your encrypted tunnel doesn't really prevent me from accessing this without authorization. The only way to really lock this down is to is to couple that IPsec tunnel with the with the user group access control list that I mentioned before. So how practical is this attack? Again what I think service providers are doing they're using the SNMPv3 infrastructure IP access control list. Some service providers were vulnerable to that CVE some might still be. There are certainly service providers that are not using encryption. So I think when you add all those things up this attack is practical on some real networks on the internet. I have a bunch of recommendations for how you can deploy this on your network so that such that it's secure. I've pretty much already explained them so I'll skip this. I also have recommendations for how to change the the the architecture of this protocol so that we don't have some of these security issues and I would like to make progress I guess toward changing some of these protocols so that they're more secure but I don't know if I have been making progress in that regard. In terms of SNMPv3 there are certain things that you could do to make it harder to brute force usernames and passwords. However the working group for SNMPv3 is closed. So in order to get this standard changed there has to be this whole process in the ITF to reopen the working group then you have to have this whole standards discussion and it's like a it's like a two-year road to getting this done and it's a lot of work. I also have some recommendations for the lawful intercept system. In particular I think that there needs to be an audit trail. The reason that there isn't an audit trail is that they don't want the people that run the ISP network to know that that wiretaps are taking place. The people who work for the ISP are not necessarily authorized to have that information and if they could configure their own audit trail for themselves in the router configuration then any time a wiretap was being provisioned they would get a notification and they could tell somebody so that's potentially a problem and the way I think you solve that problem is by enforcing agreement between the router configuration and the wiretap. So the router could be configured with a number of different destinations to send the audit trail to and as long as the interception request includes one of those destinations as the place to send notifications the interception is allowed to to proceed that way the guy running the router cannot configure another address that the law enforcement organization doesn't know about and the law enforcement organization cannot do wiretaps without without having some sort of audit trail and attackers cannot do a wiretap without having some sort of audit trail I think that makes a lot of sense but again this is just a I'm a security researcher I don't work for the companies that make this technology I haven't been involved in the standard style so there could be good reasons why this idea doesn't fly but I don't know what they are I'm just trying to be helpful here so so what's going to happen in the future this is really what I think is the interesting part of this discussion it's it's like what's going on with wiretapping in the internet today and and how's it going to evolve over time and what kind of place do we want it to evolve to so it seems to me that illegal wiretapping used to be really easy telco junction boxes used to be pretty easy to access get a couple of alligator clips and open the box up and connect to it frequency scanners many of you have them here can listen to people's cordless phone calls or their cellular phone calls etc over time that's been getting harder cell phones now usually have some encryption in them it's not impervious to attack but it's not as easy as going down a radio shack and buying a scanner it's also it's getting more difficult to actually listen to people's phone calls at the junction box because it's not just a voice call that's going across copper anymore you've got you know voice over IP that's going over ADSL you've got this whole protocol stack and it's it's um you know you have to have equipment that they can parse that protocol stack in order to get back to the voice call I think that that's actually something that's going to get easier so there's this thing that's changed over time where originally it was really easy to listen to voice calls at the junction box and it's gotten more complicated as we've gotten more protocols more digital telephony and now it's expensive you have to go out and buy this protocol analyzer that costs a lot of money if you want to perform that kind of did you say five minutes oh I thought I had an hour all right so what's going to happen in the future is GNU radio and software defined radio will make it easier to have a protocol a protocol analyzer without having to spend tens of thousands of dollars and so that as a consequence it might be easier to do that in the future than it is today I also think we may never see perfect end-to-end encryption on the internet that's something that a lot of people believed a few years back but I don't think it's necessarily going to happen people don't tend to want to deal with public keys people in this room might but people in general don't where encryption really makes a difference is when it's a link layer encryption things like your cell phone that you don't have to think about you don't have to authenticate and it actually does protect your security so one of the things I think is that if you want to cut down on illegal wiretapping anything that you can do to help and put link layer encryption into the infrastructure will make a difference but there's this other question about should we build this wiretapping infrastructure and the consensus view of the computer science research community is that you shouldn't because of the sort of risks that I'm describing in this talk that people can use this stuff without authorization and it introduces a security risk by being there and so they argue that so this is the thing there's going to be a way that law enforcement performs wiretaps I don't think that there's this future where wiretapping doesn't occur because I think the government is always going to want to do that and they're going to find a way to do it and so really the question for us is how are they going to do it and if you consider the consensus view of computer sciences it's that the argument is that they should do it with portable protocol analyzers and I'm going to go out on a limb here and say I'm not sure that's actually the best approach the problem with protocol analyzers is that you know you're say you're a police officer and you're authorized to perform a wiretap you go get the protocol analyzer you plug it into the network you collect some data and then you do your analysis and you go turn it back in there's no audit trail right you have the ability to do whatever you want with that system while you have it checked out so the only way to really have an effective access control system is to have a piece of permanent infrastructure and you get the access control system because you have to have one if you have permanent infrastructure and so potentially there's an opportunity if you build permanent wiretapping infrastructure to build a access control mechanism for it that actually effectively prevents people from wiretapping if they don't have the right lawful authorization and so if we if we see this future where you get more link layer encryption and you get a more effective system for access control you could significantly cut down on all kinds of illegal wiretapping whether it's done by individuals or it's done by people in the government but this access control system has to work effectively and I think that there's a concern that what we've got right now is the worst of both worlds we have a vulnerable system and we also have vulnerable networks so I have two more points I want to make the first is that peer review is important it's a good thing that Cisco published this architecture in the IESG that we have the opportunity to read it that we can understand how it works and that we can question its security properties there's a bunch of other lawful intercept technology that's being made by a number of different vendors that's deployed all over the world and almost none of it has been subjected to this kind of peer review so what we do in the security scene in this conference is we go find vulnerabilities in things and when you do that kind of analysis it's amazing what you find Barnaby Jack tomorrow is going to jackpot a couple ATMs on stage you figure guys who make ATMs are probably pretty serious about their computer security but somebody went and did an analysis and it turns out there are vulnerabilities in order to have a really secure infrastructure we have to do that kind of analysis with everything that we're putting into play and so that sort of analysis is necessary for these systems too and hopefully other people will go on and do further projects like this so what can you do to prevent illegal wiretapping you can try to try to work on projects that involve link layer encryption as well as end to end encryption although I think that they're less likely to be adopted you can help peer review intercept systems that are out on the internet there's a bunch of technology out there that hasn't been hasn't been looked at and you can also insist that your ISP and your government if they're requiring lawful intercept to be built into your network that technology is secure and that's open to peer review and so that you can understand how it was architected and implemented so that's my talk thank you very much