 Hi, I'm Phil Zimmerman, and I'm here to talk about my Secure Void project. I've talked at DEF CON before about it, but I thought I'd bring in an update. This was a substitute talk for a time slot that opened up, so this is not well prepared in advance, but perhaps I can just show you what I've been up to lately, especially since last year. The project is called Z-Phone, and what I have is three things. I have a protocol specification that describes how to negotiate cryptographic keys for an encrypted voice over IP call. There's also a software development kit that implements the protocol that can be used in the creation of other Void products, so that if you are making a Void phone and you want to put my SDK into your Void firmware, or if you're making a soft Void client, you can put it in that, or you can put it in a PBX. We have it running on asterisk. I'm going to be demonstrating that today. Then your Void product becomes capable of running my protocol. The protocol is called ZRTP. The third thing that we have is an application called Z-Phone that makes use of this protocol. Z-Phone is not a Void client, but rather is an IP filter that runs in your IP stack that filters the Void traffic as it goes in and out of your computer. It's sort of like a bump in the wire, except there's no wire, so it's like a bump in the IP stack. You can run any Void client you'd like to run, except for Skype, and Skype doesn't tell you what their protocol is, or they're pretty secretive about it. If you're running one of the other Void clients, like I like to run Apple iChat, or Gizmo, or a couple of other ones that I like to run, and I'll be showing three of them here. I'm going to take down this web page. This is the Z-Phone project website. Our sort of thing that we like to say is that Z-Phone lets you whisper in someone's ear from a thousand miles away, and that's the kind of sort of breakthrough experience that this brings you. We're going to get rid of that there. First thing I'm going to do is run Apple iChat. This is the Z-Phone GUI. It's put there by the demon that's sitting in there running the IP filter. It's going to watch for a Void call, like the iChat Void client is going to do a connection. Z-Phone will intervene and do a key exchange at the beginning using Diffie Helman, and then it will start encrypting it. I hope we've got some sound coming out of the loudspeaker. Ah, there we go. It's kind of loud. Hi, Steve. Don't turn it too loud. I've got it really turned up here. Turn the gain down a bit here. This is my friend Steve, who we demoed with last year. Okay, so Steve, it looks like we've made a secure connection, and we've got secure audio and secure video, and just to make sure there's no man in the middle attack, let's see if we're using the same cryptographic keys on both sides. So the short authentication string is Puppy Atmosphere. Is that what you have? Puppy Atmosphere, yes. Yeah, so your GUI is saying the same thing as mine. These words are derived from the cryptographic key negotiation that both sides have done. If they match, it means there's no man in the middle attack, so it would be quite a surprise if there was a man in the middle attack, although considering how many kinds of attacks there have been at DEF CON, I wouldn't be totally surprised by that. Okay, so I'm going to press clear, so we're going to go to clear mode. Okay. Okay, so Steve is now not encrypted. Okay, can you hear me, Steve? I can hear you fine, I'm just protecting my identity. Yeah, that's right. We certainly wouldn't want anyone to intercept this and figure out who you are. Okay, Steve, well, either you or I could go back to secure mode again by pressing this button. You want to do it or should I? I guess I'll do it. I'll do it. Okay. Uh-oh, now you've told me to go clear. Sorry, I... Oh, you thought I... Yeah, okay. I pressed the button too. Yeah, you did, okay. Well, all right, so go back to secure mode. Okay, we're secure again. All right, so next time we'll just have to make sure we understand who's going to press the button. That's right. So we have a little bit of... What is that called? That's a race condition. Race condition. All right, so now we're going to switch off the video chat with iChat and we're going to switch over to Gizmo. Okay. And now, remember I told you that Z-Phone works with just about any VoIP client. Here's another one here called Gizmo, a popular VoIP client that runs on a lot of platforms. And there we are. Can you hear me, Steve? I can hear you fine? Okay, and again, we're secure. Yes, we are. Zulu opulent. Zulu opulent. This list of words is the same list of words used by PGP when you compare PGP fingerprints. How many people here have used PGP? Yeah, I can see that this is a completely random audience that... This is a completely random sample of the general population, right? I wish the ratio were that high in the general population. So you know that a PGP fingerprint uses a list of words and that same list is what we use here. In fact, we actually developed that list in 1995 for PGP Phone, which was kind of a predecessor to this. That's when I first did a secure VoIP application, but at that time the internet wasn't ready. There was no broadband anywhere, really, and also there were no VoIP standards. So it wasn't the right time, but now it is the right time. And so here we are with Z-Phone. Okay, so we're going to hang up this and we're going to switch now to using SJ Phone. And we're going to go through a PBX this time. Okay, now this is another VoIP client called SJ Phone, which actually isn't supported anymore, unfortunately. But SJ Phone, I've configured to talk to my asterisk PBX at home. And my PBX at home, I have integrated the ZRTP protocol into the PBX. So what I'm going to do here is I'm going to call Steve and we're both going to be connected through this PBX. And the PBX is actually going to act as a man in the middle, in this case. But we have the protocol arranged so that it can handle that. Let's see. Honey, is it working again? Yes. Now I'm going to show you what happens when a wiretapper listens to this call. Okay. This is what ciphertext sounds like to the wiretapper. Okay. So it sounds like white noise. That's real ciphertext. We're actually taking the ciphertext as it comes in and just sending it through the codec. And you're just listening to what the ciphertext would really sound like from a wiretapper's perspective. So I'll do that again. Okay. Steve, say something. Yes, I have to push my speaker down a little bit. Yeah. So we can hear you and that's, you know, but the wiretapper would hear white noise. All right. So we're going to hang this up and I think that's all for the demo. Oh wait. You know what I'm going to do is I'm going to call. I need to volunteer from the audience that has a mobile phone in their pocket that I can call a mobile phone. Now here you see a PBX, you can use VoIP to talk through a PBX to call a normal telephone and that's what we're going to do right now. So suppose I'm traveling in Europe. Suppose I'm in Moscow in a hotel room and I want to call somebody here, right, on your regular phone, maybe a cell phone. And I don't want Vladimir Putin to listen to the call. So I want to make it encrypted from the Moscow hotel room to my PBX in California and there it goes through a PSTN gateway to, you know, a local telephone. So could I get a volunteer who's willing to give me your phone number to dial in so that I can't mask the number. Well, wait a minute. Maybe I can. I'll just put this on top of it. No, I got to type it. Unplug the video. For some reason people are reluctant to give out their phone numbers into this audience. What is it about this audience? Okay, is this, this has to be a real mobile phone in the room. Okay. Okay. Yeah. 415 what? 200. 656. Oh. 200. 7656. Okay. So I want to dial that. It's making a connection to the PBX and is dialing out through the PSTN to your phone. Your phone is turned on, right? All right. Turn up the gain so we can hear. Oh, we'll answer it. Can you hear me? Yeah, we can hear you. Yeah, I can hear you. Okay. So, again, we'll do the same trick again. I'll, this is what Vladimir Putin would hear from my, if he's intercepting the call. Okay. But you can hear me fine, right? Go hear me. All right. So, now, but what if we want to check for the man in the middle attack? You see, I want to see if this is, these words here match right here. It says billboard retraction. Dial 77 on your phone and listen. Is there a robot talking to you? What? Oh, what happened? No, not 977. All right, never mind. It's too complicated. The point is, actually, every connection that we make to the PBX from this VoIPLiant is going to already be authenticated because we've done it before. Because we use something similar to what SSH does. We use key continuity. You know that, how many people here have used SSH? Gosh, almost the same number. It's almost as if you all had experience with security issues, right? Again, a normal, randomly selected audience. Well, you know that when you use SSH, the first time you make a connection, it caches some key material so that the next time you make a connection, if there can't be a man in the middle attack because if there wasn't a man in the middle attack in the first connection, there isn't going to be one in the second connection. And I'm using the same thing. What happened here? Are we still on? I should hang up. There we go. Yeah. We were connected all that time through your mobile phone. Okay. That means you could hear my talk through your mobile phone, right? Okay. Yeah. All right. So, here, let's just get rid of that so that no one could write it down, right? I guess his phone number must be in the buffer for this VoIPLiant here, but I don't think I'm going to be calling it anymore, so don't worry. Oh, he has my phone? Well, actually, no, because my PSTN gateway at home has the caller ID blocked, so he can't see it. That's because I got my phone years ago back. I'm sort of a Luddite about that. I have my caller ID blocked for my outgoing calls, which means that I can't call a lot of people because they block incoming calls that have the caller ID blocked. So, oh, well. Right. So, where was I? Oh, yeah. So, I cached some key material in the first call and then keep it around for subsequent calls. So, every call it does a fresh Diffie-Hellman calculation, but it hashes the session key and stores that in a cache. So, the next time there's a call to the same person, it does a new Diffie-Hellman calculation, but it detects whether there was still some cached key material from the earlier call and mixes it in by hashing it together with the new key so that if there was no man in the middle attack in the first call, there won't be one in the second or the third or any of the later ones that does this every time. Now, this is an interesting security property because it means that you don't really have to compare the short authentication string. Now, I did compare it because I wanted to show how it works, but you don't really have to compare the short authentication string. You could just rely on the key continuity properties that work pretty much the way SSH works, except instead of a signature key, you're not caching a signature key. You're caching a hash of the session key. And this means that you could call someone 100 times and never check the short authentication string. Call them 100 times, spread out over perhaps a year, and talk about harmless things, talk about the weather, talk about nothing important, but after a year of talking about nothing important, one day you want to talk about secret stuff. So you decide today we're going to compare the short authentication string. So you compare it and it matches, which means there's no man in the middle. But it also means retroactively that there never was a man in the middle in all the previous 100 phone calls that went back for the past year. Now, that's a really nice security property. So you can be lazy most of the time. All you got to do is check the authentication string just once. It could be at the beginning or it could be later on. And it retroactively covers it in the past and going forward. It doesn't actually prevent the attacks in the past. It just lets you know that there weren't any. Of course, the corollary of that is that if it doesn't match after 100 calls, then that means there is a man in the middle in this call. And it also means there always was a man in the middle for all 100 calls. So it's a real oh shit moment. So maybe you ought to do it earlier than 100 calls. So this protocol doesn't rely on a public key infrastructure. It doesn't rely on servers. It does the entire protocol in the media layer, not in the signaling, the SIP signaling. It doesn't rely on the SIP signaling. It doesn't involve the phone company at all. In fact, if the media goes through a different path than the signaling, which it typically does, then the phone company doesn't even have to know you're using the protocol. There's nothing in the SIP packets that tell them you're using this protocol. So it's just between you and the other person. You and the other person are the only two parties that are involved in the negotiation of the cryptographic keys that will be used to encrypt the media. Remember in the old days there used to be these devices you could buy for a couple thousand bucks that you would plug your phone into and they would do a modem connection and negotiate keys that way. There was one in the early 90s that had a clipper chip in it. And that was also something that didn't involve the phone company. However, it had a clipper chip in it. So there was built-in wiretap friendly stuff. This protocol doesn't have any wiretap friendly stuff and it doesn't involve the phone company in the key negotiation. Now as many of you know, there have been some things that have happened that make us question whether the phone company has our best interest in mind. So I'd rather not ask their permission. If I want to speak Navajo to my friend on the phone, I don't want to have to get permission from the phone company to speak Navajo. So I think that's the way encryption should work. There's another protocol that does involve a public key infrastructure that does involve certificate authorities and sort of a top-down thing. It's called DTLS, DTLS SRTP, and that's another way to do it. But if you do it that way, you're relying on a central authority, you're relying on a public key infrastructure. So I think that public key infrastructures can be made to work in some environments like web servers and web browsers. There you have one server talking to a lot of web browsers. But when you want to have a many-to-many architecture like email, during the 1990s a lot of companies attempted to build public key infrastructures for email encryption and failed. In fact, a lot of them went out of business. It's very difficult to do. It involves building a bureaucracy. You have to have somebody run the public key infrastructure, set it up, check people's credentials, and so on. It's hard to do. So that's why PGP succeeded where SMIME failed. And other predecessors to SMIME, like Privacy Enhanced Mail in 1991, Moss in the mid-90s, and later SMIME. And SMIME had a lot of deployment advantages because it was bundled with Microsoft software, and yet it never really got used a lot. And the reason why is because it required too much activation energy because you had to create a public key infrastructure to use it. PGP didn't require building a centralized public key infrastructure, so it was able to, so it was more widely used. Well, I think that those, the things that made public key infrastructure difficult to do for email become even more important for phone calls. Phone calls are more ephemeral. There's no reason to keep around keys because at the end of the call, you're done with the call. You don't need to decrypt it next week, like you do with a piece of email. So why should you keep the keys around? So you don't need a public key infrastructure. So this is a more lightweight approach, and it can also be used in, like for government agencies that want to use it. If you're going to try to build a monolithic organization like a military organization, you can make a PKI work, but if you want to have an interagency thing, maybe first responders, you know, Hurricane Katrina, decentralized mesh networks, that sort of thing, you're going to have not everyone marching to the same drummer. You're not going to have everybody under the same command. And so to try to get them all to work with the same PKI is not easy to do, but with this approach, it'll always work. So I think it's a better architecture. So anyway, let's see. Yeah, okay, so we're done with that. So anyway, visit the Z-Phone Project website. It's got a great FAQ page. And, you know, there's lots of Wikipedia links in here, and take a look at it. Download it. You can download it for free to try it out, and you can get the SDK and play with it in your product, and you can also download the asterisk patch. If you have an asterisk PBX, you can play with that too. Yeah. Can you send encrypted audio over the PSTN? Well, you know, you heard what encrypted audio sounds like. It sounds like white noise. No, you can't really do that, but what you could do is you could send it through a modem, you know, and send UDP through a modem. But I don't think that's the question you were asking. I think that for the PSTN, you would have to take a different approach. And, you know, a famous hockey player said, I always try to skate to where I think the puck will be, and I think the future of telephony is more likely to be in VoIP, so that's more interesting to me than encrypting the PSTN. Yeah. Louder, please. Before it gets into one? No, I encrypt the data after it's been compressed. Yeah, the question is, what about these variable bitrate codecs that leak information about the speech? Well, I think it's a good idea to not use variable bitrate encoders for secure telephones. I think if you're building a secure telephone, it's better to use constant bitrate codecs. Well, you know, you can configure your VoIP client to just exclude the variable bitrate codecs. There's only a couple of them, and most of them are constant bitrate. So, you know, use GSM, you know? Use, um, sure. Well, I'm probably going to add something to my FAQ page about that. If I didn't already, maybe I did. I wonder if I did. Well, I knew I was thinking of adding something. Okay, let's see. What else? Yeah. With conference calling, how do you encrypt conference calls? Well, you remember the way conference calls work is that everybody calls a conference mixer. In fact, a lot of times, a conference mixer is a PBX. So, you would encrypt each link to the conference mixer, and the audio mixing is done at the mixer. So, you're doing individual encrypted links, and they're all ZRTP connections. So, it's not like you have to work out the keys between every party. You're just doing the key negotiation only between each party and the mixer. Yeah. We have done conference calls with the Z-Phone. Uh, well, what we've done is we've done a protocol extension to have a shared secret between your VoIP phone and the PBX. And so, once that shared secret is established, it's there all the time. And so, it's pre-authenticated. Yeah. Yeah, yeah, the PBX, let's assume that the PBX is acting as a conference bridge, and it's a conference mixer. It's doing mixing of the audio. And so, it has to have the plain text there. I mean, that's just what audio mixing, if you're going to do audio mixing, you have to do the plain text, you know? There's no way to avoid that. You're going to have to trust the conference mixer. Typically, you own the conference mixer, so it's yours. Yeah. Yeah, it's a patch to the source code. You can download the patch. You rebuild asterisk. And we actually have a patch for like three different versions of asterisk. You have to recompile asterisk. Now, later on, we could put it into the asterisk code base, and I think at some point, they will, but that hasn't quite been worked out yet. Yeah. Well, I think a number of people that build these asterisk systems could put it in, and then ship the systems with that already put in. Yeah. Say that again. Well, you know, BlackBerry software, the question is can we put this on a BlackBerry? BlackBerry is not a very open architecture, and to the extent that they let you do anything, you have to write it in Java. So I think it would require a special relationship with BlackBerry, with RIM, to make something that's written in C for them to insert it on their product. Now, that would be kind of up to them. What? Windows Mobile does have a VoIP client that has this integrated. There's three companies in Europe that are working on VoIP clients that use this on mobile phones. There's a company in Latvia called TV that has a VoIP client that they've integrated this into. There's another company in Italy that's working on a VoIP client for mobile phones that will have this integrated in. And there's a company in France called Atelier that has, they're not doing a VoIP client, they're doing something actually quite unusual. Instead of taking our SDK and putting in a VoIP client like we usually do, they're taking Z-Phone, the Z-Phone application that I just showed you. And they're importing that to Symbian and then you're running the Nokia VoIP client or maybe other VoIP clients and having it intercept the packets the way Z-Phone does. And I've seen that work. I was just in Paris a few weeks ago and saw it work and it works pretty good. So there's different ways of getting this on a mobile phone. In Europe, it's more popular in Europe than it is here. And mobile phones are more popular there too, I guess. So you will be able to get this for your mobile phone. And also, I know of someone working on an iPhone implementation. So I just bought an iPhone. I just got my iPhone yesterday so I'm looking forward to that. I want to be the first user. Pardon me? Yeah, I'm going to push the iPhone version as soon as possible because I use an iPhone now and I want it now. Yeah. Louder, please? Yeah, I know. The question is, will Apple distribute the VoIP client with ZRTP embedded in it? Well, I don't know exactly but I know that they do have a way of accepting applications to put on their online store and certainly we'll be trying to arrange for that to happen. Well, actually there is a VoIP application for the iPhone. What's it called? Fring or something like that? Yeah, there is a couple of I think there's a couple of VoIP clients for the iPhone. So one more is not going to be a big departure from what they already have. I think they're running it over Wi-Fi and not the 3G network. I think that any efforts by Apple to stop it are probably going to be focused on stopping it on the 3G network. But they're going to allow it for the Wi-Fi. At least they do for the other one or two VoIP clients that you can download right now for the iPhone. So I think there's a good chance they'll allow this. And if they don't well then there's always other ways to make it available. In fact, maybe I'll ask some of you guys to help with that. Yeah. Are any government agencies using Z-Phone? Well you know, government agencies have used PGP quite a bit. There's thousands of seats of PGP in government agencies for many governments around the world. I imagine that at some point they'll be using either Z-Phone or they'll be using phones that have my SDK embedded in them. But do they use it now? No, they don't use it now. At least not that I'm aware of. Although maybe some unofficial use. Yeah. Say that again. Connections between asterisk boxes I think most often use another protocol called IAX. And this doesn't work with that protocol. Because IAX is a protocol that mixes many calls together in the same connection. This is a protocol that's designed between two people, you know, a single connection. Yeah. If you can get a RTP connection to PBXs then this will work with that. Now for those of you who want to download the asterisk patch and try it I'm going to give you the URL for that here. You can get it here. I don't know if it's visible on the screen but you can copy that down. See we've got patches for three different versions of asterisk. Or just send me an email and I'll make sure you get the latest one. You can try it out. I'd like you to try it out and tell me how it works for you. In fact if you want to look at the online documentation just go to that asterisk page and look here we've got a user's guide and it'll show you how we set it up and how to configure it on your asterisk box. So anyway yeah. Well do you mean do you think that they will oppose encryption for VoIP? Is that what you're asking? Well let me take the first question first which is will they oppose encryption for VoIP? And I think that they're going to have to accept encryption for VoIP and not just in a few cases but they're going to have to have it everywhere. The reason why is because while there's a large asymmetry in the difficulty of wiretapping between governments the government can easily wiretap the PSTN but everyone else has to they have to go to the phone company and ask for a wiretap and the phone company is not going to give it to you but they will if you're the government. Now that's true for the US and a lot of the western democracies it's not always true in every country in some countries there are corrupt governments corrupt phone companies you can bribe someone and get a wiretap. I understand that in Brazil you can get a wiretap you can get recordings of your business competitors phone calls for a whole month for about $5,000 so that's like a published rate you know but here in the US you pretty much have to be the government to get easy wiretaps but that asymmetry in the difficulty of wiretapping maps as we move to VoIP because with VoIP it becomes equally easy for anyone to wiretap and when I say anyone that means organized crime that means organized crime can wiretap the cops they'll be able to wiretap judges and prosecutors and that means they'll be able to listen to details of ongoing criminal investigations the names of witnesses the names of informants and listening to them calling their wives at home to pick up their kids at school so even if the local criminals are too stupid to do that they'll outsource it to the Russian mafia and the Russians will do it from Russia without ever setting foot in the US so you know you can be wiretapped from the other side of the world by people that never had to get a visa to come into your country it's not like they got to get close with alligator clips and clip them on the copper wires outside your office they could do it from afar so we have no choice we must encrypt VoIP the law enforcement community needs it as much as we do all of society needs it all of society can't migrate to VoIP without it so will they have a backdoor well you know I think if you try to put a backdoor in somebody's going to figure out a way to exploit it somebody other than law enforcement and it just makes it weaker it'll be an attractive nuisance let's see what else we got any other questions here I guess huh oh I still got plenty of time well let's see what else can I talk about hmm yeah say that again well with source code available can they keep you from using encryption you know I think that we fought the battle in the 1990s to be able to use encryption and I think we won that battle so I don't think they're going to be able to turn back the clock on that and I do publish the source code um you know and I've done something else that's kind of a strange thing to do I've I've done some things in the protocol that try to discourage people from putting backdoors in their products um I I put in a protocol element that says that if you are disclosing the cryptographic keys out of band I mean there's nothing in the protocol that has any backdoors there's nothing that's part of the ZRTP protocol that has the clipper chip, the law enforcement access field there's nothing in the protocol like that but there's what could I can build my own products with no backdoor but what about other people's products that implement the same standard they could conceivably leak the key material out of band you know they could send it somewhere that's not part of this protocol they could just send it somewhere else you know maybe through an encrypted tunnel to you know to and so if they do that I would like them to identify which products are wiretap friendly like that because remember back in the 90s the clipper chip how many people here know about the clipper chip okay not as many as have used PGP and used SSH well the clipper chip was a wiretap friendly chip that encrypted voice and during the 1990s there was an effort by the government to require that this chip be put into phones you know that do voice over IP and it didn't succeed in the market because nobody wanted to buy a chip that had a backdoor for the government so Adam Smith's unseen hand and the invisible hand of the market does not favor wiretap friendly chips or wiretap friendly protocols so I'd like to try to use that I'd like to try to encourage people that are going to make wiretap friendly implementations of my protocol to reveal that their products are wiretap friendly well that's not so easy to do how do I do it so what I did was I put in the protocol a requirement in the specification that you have to set a special flag in one of the packets that says this product is wiretap friendly this product is designed to leak key material out of band or whatever method they want to use to leak key material but how do I get them to do it well I filed a patent application for certain aspects of this protocol now I don't like patents anyone who knows me knows that I'm sort of a anti software patent guy but I'm giving away a free patent license you can just use it for free if you implement this specification you can use the patent for free in certain aspects of the protocol so I'm not charging money for using the patent but I'm saying that you only get this patent license if you meet the specification if you actually comply with the specification and the specification says that if you make a product that's wiretap friendly you have to set this special flag in this packet which the other party would see on his phone and would know that your is a wiretap friendly phone so what I'm doing is I'm combining the invisible hand of the market and standards and intellectual property law together to discourage backdoor products so it's kind of a radical experiment so as long as the patent if I get the patent yeah I've just applied for it but if I get the patent as long as that patent runs which is about 20 years then people that implement this protocol are probably not going to be putting backdoors in their products when the patent expires you know can't help you there so any other questions well maybe we're done so go download Z-Phone and try it out by the way if you can attack it do some fuzzing attacks or something like that and find some weaknesses I'll give you credit on the website if you find a real weakness that way maybe a buffer overflow attack or something like that I could even put you in the about box so try to do that alright that's it thanks