 I'm sorry I'm late. You know, yesterday a lot of people told me I was supposed to speak at 11 o'clock. And so I didn't actually look on the DEF CON website to see if that was actually true. So here I am at 11 o'clock. I'm sorry for the inconvenience. By the way, I don't mind if anyone takes my photos. Yeah, either John Callis, John Callis is CTO of PGP, or me doesn't matter. We get photos all the time. I figure I've already gotten in enough trouble with the feds so it can't get any worse, right? Yep. Wow, that's a little bit lower resolution than usual, but that's all right. I'm going to demo my new project today. My new project is Secure Voip. I think it's about time we had Secure Voip. How many people here use Voip? Oh, you guys are so geeky. The early adopters. Well, you know, for years we've enjoyed the relative safety of the public switch telephone network. I say relative safety. We're speaking relative to the internet. Of course, we all know that phone calls on the public switch telephone network can be intercepted. But it's a lot harder to do. You have to be like the government or somebody who's willing to physically go to a place and clip on some alligator clips. Or you have to have access to the phone company or the cooperation of the phone company. But with Voip, it's possible for somebody in Malaysia to hack into a machine somewhere and install a piece of software that will intercept all the Voip calls on your network and organize them like a Tivo player. And so, to move our precious phone calls from the sort of well manicured neighborhood of the public switch telephone network to the sort of crime-ridden slum that is now the internet, I think would be unwise without protecting it with encryption. So, first I'm going to do a little demo here and then I'm going to explain how it works. Somewhere in a soundproof booth is an accomplice who will now call me on my Voip phone. Steve, call me. He said he's watching this so he'll be able to tell. Yep, here it is. It's ringing. So now I'm going to answer. This is a regular SIP phone, by the way. It can call any other SIP phone. Great. Okay. I was afraid this would happen. Let me just say, I'm going to exit and relaunch. I'm using an open source Voip client and then I added crypto to it. And so, there are some issues with the open source Voip client that I'm using. And sometimes it has difficulty with NAT firewall traversal. Okay, I'm ready again. Steve, I hope you've exited and relaunched. Call me again. What I did was, you know, many of you are aware of PTP phone, a project that I did about nine years ago. At that time, the internet wasn't ready. No one had broadband. There were no protocols that were standardized for voiceover IP. SIP wasn't invented yet. Steve, you're supposed to call me now. Maybe if I try calling him. Come on, Steve. Anyway, oh, he's calling me on my cell phone. He's telling me, yes, you had to reboot your machine? Oh, man. That would explain a lot. Okay. Okay, I'll leave this open here. I'm going to put you on the little speakerphone. So you just yell into your speakerphone or into your phone when you want to talk to me. Or you could just call me. Okay, well, anyway, so what I did was, back in the days of PTP phone, I had to improvise my own protocols. There was no SIP. There was no RTP. It was the beginnings of RTP at that time. They were starting to design it. And so I had to just sort of improvise my own. And it wasn't so bad for the time, but the internet just wasn't ready. The bandwidth wasn't anywhere near as what it had to be. So it was a neglected product for many years. What? Are you ready to call? Okay. What? Okay. Just call when you're ready. So fast forward nine years, and now the internet is ready for this. Maybe this is not ready, but... So there's still some net firewall traversal things in the open-source VoIP plant. I'm using an open-source VoIP plant called STOOM, which is written oddly enough in Python. And so we had to write our crypto in Python. It's kind of a new experience to do that, to do a secure phone in Python. Or any kind of SIP phone in Python. And so there are some problems with that. So this is why... See, I didn't feel I was ready for this, but Nico Cell persuaded me to unveil this at the Black Hat conference. And I said, no, no, I'm not ready. And so she kind of, you know, kept pushing me to do it until finally I had to do it because the press started... What? Yeah, well, it's not. I would notice if it was. Oh, there it is. By the way, we don't have any audio. Oh, I didn't plug in the audio. Oh, it's just a minute. We're going to exit now. This is terribly embarrassing. This is the... You don't work the first time at Black Hat when we were on an outside IP address. We couldn't get it to work inside the firewall. But we got an outside IP address and it worked. Okay, now I'm ready, so call me. Oh, there we go. Oh, man, this is not working. Okay, you know, the crypto is in pretty good shape. It's a good thing they gave me an hour to talk, right? So I can try this several times. I actually got here a little while ago and I wanted to test and test and test, but the Ethernet cable for this was right here at the podium and so I couldn't... Did you exit and relaunch? This is why I... This is why I never use... Why I never bring a laptop to a talk. All right, I'm going to abort this. I'm just going to explain how it works. Goodbye. Okay, I'm humiliating. You have to believe me that it worked at Black Hat yesterday. I might try it again. It's tempting. If you want to bring it up here, maybe we can try it again. But do you have broadband? Okay, that's pretty impressive. I looked at various other protocols that are currently being considered for secure void. There is some IETF-RFCs that define various ways of doing it. Most of them rely on external sources of essentially controlled public key infrastructure to certificate authority. I think that two people who want to talk to each other should not need permission from someone else to do it. And so I just do like I did with PGP Phone. I do a Diffie-Helman Key Exchange. I do a Diffie-Helman Key Exchange with hash commitment so that this means that I can read an authentication digest aloud that gets displayed and the two people read it to each other and if it matches, that means there's no band in the middle attack. This eliminates the need for a certificate authority, a public key infrastructure. There's a lot of feedback here. The other way. Turn it the other way. Yes, I'm using a Macintosh for security reasons. That's just not going to work. Coaches that don't use a public key infrastructure necessarily, but they send SIP packets that use TLS connections and they put the key for the session key right there in the SIP packet, not encrypted. They'll just send that, but they'll send it through a TLS connection. The problem is it's going through multiple TLS connections from server to server to server and each one of them, it's decrypted, and then re-encrypted into another TLS connection. So that means that each of those servers has access to the session key and is in a position to compromise the call. There's another scheme that actually takes the session key and crips it as an S-mime email message and sticks that into the SIP packet and sends that to set up the call. And the other side receives it, decrypts it like it was a piece of email, extracts the session key and then uses that. To use an email encryption standard, I mean it's bad enough they're not using PGP for that, right? But even if it was PGP, I would still be complaining because it's just the wrong approach. You don't send an encrypted email to somebody to set up a phone call. It just doesn't, you know, it just feels wrong. And not only that, but it means that at the end of the call you have persistent key material around that you could use to retroactively reconstruct the call. If somebody intercepted the call and recorded all the packets, they would be able to decrypt them after the fact if they could somehow later obtain the key that was sent through the SIP packet. In other words, it doesn't have perfect forward secrecy. Well, you know, I just can't imagine designing a secure phone that doesn't have perfect forward secrecy. Let's see, there's another one that has self-signed certificates but you have to use a trusted server to get them or you don't know who they are and it could be a man in the middle. So all of the other schemes that I looked at have problems. And almost all the problems come from trying to get somebody else involved in setting up a secure call between Alice and Bob. And it just seemed the wrong approach. So with my approach, just the two people are involved. It doesn't use anything involving another external server. It doesn't send anything in the SIP packet that relates to the crypto. Of course, it uses SIP to set up the call like any SIP phone but not to set up the encryption, not to set up the key agreement. Instead, you get the SIP call started and then the RTP packets start flowing and then it inserts a Diffie-Helman exchange in the stream. Gets the key agreement and then starts encrypting it using SRTP, Secure Real-Time Protocol. When I first started working on this, I thought I was going to have to encrypt my own packets with my own protocol like I did with PGP phone but I discovered something called Secure RTP or SRTP and I read the spec for it and it looks a lot like PGP phone. It encrypts the packets in a manner that is nearly identical to the way it was done in PGP phone nine years ago and I thought, this saves me a lot of trouble. I was going to do it this way already. So I'm going to use SRTP. So this is actually one part of the protocol that is predefined in an RFC. But I do one more thing that I did not do in PGP phone. At the end of the call, I erase all the keys but I keep a hash of the shared secret that we used. I keep a hash of it around for the next phone call. And then when the next phone call happens, I do a fresh Diffie-Hellman P exchange like I do with every call but I also take one more step and mix in the retained shared secret from the last phone call. This means that there is sort of a key continuity model which Peter Gutman I see in the audience right here as he has called this the baby duck security model. He was referring to SSH. With SSH, you have an exchange of key material at the first session and that's locally cashed and you assume that the man in the middle is not present in the first session and if he's not present in the first session it's too late for him to get involved in later sessions. Well, that's the same thing I'm using here. So remember when I said about reading the hash aloud? Unfortunately, I can't show it to you. But for those of you who have seen secure phones like Eric Blossom's secure phone from back in the mid-90s and the AT&T 3600 developed in the early 90s they all involved displaying a short hash code that you read aloud to the other person to verify there's no man in the middle. Well, if you forget to do that it's probably okay because the attacker is afraid that you will do that and so he won't attack. But if he knows that you're lazy he might be tempted to attack knowing that you might not check it. But suppose you made 100 phone calls to your friend and you didn't check. You just kept making phone calls and you just forgot to check or you were too lazy to check by reading aloud the authentication digest. Well, if on the 50th call you suddenly remember that I really ought to check this and you read it aloud and the other person reads it there is allowed and it checks and it compares and everything is good it means that not only is this call secure but every other call all the way back in the previous 50 calls to the first call you ever made to them it proves that all of them were secure. It retroactively proves there was no man in the middle. That's really good for peace of mind. It means that you can be lazy most of the time and then finally one day when you're diligent about it your diligence assures you that all the other times you were lazy it was okay. Of course if it doesn't match it means that there was a man in the middle all the way back to the beginning of time that's a real oh shit moment, you know. But that's something that other secure phones don't do and that my protocol does and so I'm feeling pretty good about that feature. Now if somebody were to kick the door in and come in with guns and pin you against the wall and take your computer and suck all the bits out of the computer they're not going to be able to retroactively reconstruct the call not even with the retained shared secrets I just described because what doesn't actually retain the shared secret that was used in the call, it hashes it. So you can't go backwards in the hash. I'll be publishing a document describing this protocol. I think this is a better way to do secure void. This is a much better way than the other protocols currently being considered in various IETF RFCs. You know designs tend to resemble the institutions that give birth to them and I think that centrally managed approaches that we're seeing right now sort of reflect the sort of institutional thinking that went into making them and I tend to be more libertarian in my approach. I'm not a big L libertarian but I'm a civil libertarian but it's not only my political instincts it's also from a design perspective simpler to add a certificate authority to a SIP server adds immense complexity. We've seen many companies go bankrupt in the 1990s trying to build public infrastructure. There are companies that try to create the technology for building certificate authorities. Those companies are now bankrupt and sure you can explain some of that by saying the internet bubble burst I don't think it's always from that. Some of them went bankrupt just because of the difficulty of building public key infrastructure. Not only the companies that were providing that technology but the companies that were trying to use the technology they didn't go bankrupt necessarily but their IT departments almost went under trying to deploy public key infrastructure. So I think that if we were to learn from our mistakes we should stop trying to do it that way and when we have a new opportunity to deploy something with a new technology like VoIP the last thing we should do is go back and take a proven technology and I say proven I don't mean proven successful I mean proven a proven failure of public key infrastructure and try to apply it to VoIP and so my design doesn't do that. So for those of you that would like to see this prototype work better than what we just witnessed this thing is built around an open source VoIP client called STOOM written in Python and if you Google for STOOM you can find the homepage for it and for those of you who are Python weanies if you go out and try to fix the open source VoIP client and make it work on all platforms it's supposed to work on PC's Windows platforms too and get it a little bit more stable then this thing will benefit from that all the problems that we just saw relate to the state machine in the VoIP plant and how they interact with a firewall so I'd like to open it up for questions you're asking me to elaborate on my remark that PKI is a failure well you know I don't think PKI is a completely a failure I think it's actually worked pretty well for web browsers and web servers I think SSL connections between your browser and the server seems to work pretty well but it doesn't work that well for email well the PGP PKI works a lot better for email but you know take S-MIME S-MIME is widely deployed and is in fact invented in a lot of Microsoft products I mean bundled I should say with Microsoft products and yet no one uses it, why? because to make S-MIME work you have to have a PKI up and running already so the activation energy is too high with PGP you can run right out of the box you don't need a PKI to be running first and I think that it would be crazy to try to burden VoIP with that same high activation energy that's what I mean by PKI as a failure well let's talk about how a man in the middle attack would work imagine that you had let's imagine that this was actually in a hardware phone you had a phone on your desk that did this protocol and you bought that phone at Walmart for 100 bucks so imagine that your friend also has a phone like that and you want to call and it sets up a Diffie home and exchange and now you're talking right but imagine that an eavesdropper went down to Walmart and bought two of these phones okay and brought them home and set up the two phones side by side and had one of the phones interposed between you and the other person and the other phone too so that when you're calling your friend you're not actually calling your friend you're calling this eavesdropper's phone right here the one on the left and the eavesdropper knows you're going to do this and has your friend's phone number on the speed dial on this phone here on the right and so when he sees the phone ring and sees that you're calling and you're calling your friend hits the speed dial, waits for your friend to answer and as soon as your friend answers he answers you and now he's got these two phones and he holds the two phones together like this so that the earpiece and the mouthpiece are connected in this kind of sort of lewd and lascivious kind of connection there and now you think you're talking to your friend but in fact you're talking to the man in the middle and the man in the middle can listen in the air gap between the two mouthpieces, whatever and now notice that that the eavesdropper didn't have to have any special knowledge of mathematics didn't have to know anything about how Diffie Hellman works the only important thing is that you know there's these two identical these two phones that they bought at Walmart right and now there's a random session key between you and one of the phones a different random session key between the other phone and your friend well if you could figure out a way of discovering the fact that the two session keys aren't the same you would know there was a man in the middle well what if the two phones could hash the session key and display that on the little display and you read it aloud to your friend well they better match because if they don't match that means there's a man in the middle and that's what we do here only I couldn't show it to you it did work yesterday I swear it worked yesterday it's worked in a lot of places but in some places there's some firewall problems and I can't get it to work you know a lot of the SIP phones out there have difficulty with firewall nat traversal but there's better protocols coming out all the time you know Skype does overcome these firewall problems and I think we can overcome them in the SIP world too back there could you yell really loud now unfortunately it's written in Python so it would have to be sort of refactored into C the question was can this code be ported to other open source clients but it has to be rewritten in C in fact I'm looking for volunteers to do that I've actually got a series of products on the roadmap you know this is starting out just like PGP you remember PGP was started out as a private project without any money I paid for all this myself actually I did get some help Jeff pover who is a well known in the VoIP world put in some of his own money too but most of it came from me paying I hired an engineer full time to work on it for a few months but I was paying him really very low wages and eventually he had to take a job with a real company that paid him good money so the development has slowed down there is some development still going on with it but it's at the slower pace and I am going to try to start a company for this and I'm actually talking to some investors to get some funding for this and I got funding now from two sources so far I put some of his own money in and I got a little bit of money from Dick Clark I don't mean the guy from American Bandstand the other Dick Clark cyber security he left the Bush White House and wrote a book on they called Against All Enemies it's a really good book but anyway it's too late now so I'm going to start a new company and commercialize this but I will publish the source code with PGP that's what I believe is necessary to get people to trust it so more questions yeah could you yell really loud could you get up and just absolutely yell you mean the retained shared secrets you just need a little bit of memory for that yeah okay yes you want to be able to take sort of an identity with you from one machine to another well I thought about doing that you could put your configuration files and carry that around and copy it but I don't know I think we'd have to do something more elaborate to do what you're talking about because do you really want to copy that onto a computer in a cyber cafe well it's okay because the first time you call somebody there isn't any retained shared secrets so you just read the hash aloud and it just works the retained shared secrets feature it kind of makes it nicer but it isn't necessary yes right yes that's right I'm using SHA-256 SHA-256 yes and for the Diffie-Helman exchange I'm using a 4,000 bit Diffie-Helman and for the block cipher I'm using AES-256 running in counter mode for you know it is defined by the SRTP protocol so I think I'm doing that I you know I picked the right algorithms for this and actually you know even the collision problems that we've seen in some of the hash functions I think are not likely to be exploitable in the particular scenario that we're using them here even if I were using one of the weaker hash functions John do you want to say anything yeah we've been working with Phil on this too and supporting him and getting him contact with these and I've been controlling him into demoing at places like this as well okay I've been saying that you know we at PGP have been helping Phil with this that we've been getting him with VCs controlling him to demo the thing because I believe that getting some exposure to this is going to be important to get it properly funded and out there the really important thing in what he's doing is that this will go nearly anywhere I mean it can go in a handset it can go in a handheld computer it can go on a laptop the protocols are also directly layerable on top of what's going on sorry that we don't have a good network here to do the demo but the system that he's running is an ordinary VoIP phone you can call any other VoIP phone in the world with it and it just so happens that if somebody else has one that has the security in there poof now all of a sudden you've got a secure phone call and that's a really important aspect of what this does because it means that the network effect of getting people to get secure phones is lower that if you build a infrastructure that is a secure phone infrastructure that doesn't interoperate with regular phones it makes it increasingly hard for people to go on because they have to make a decision do I want secure do I want easy well this gives you both easy and secure and other things like you know that you only really need to do the hash once or maybe even not do that I make phone calls all the time and I can tell from the person's voice whom I'm talking to and you know from the Rhetarian shared secret that you are talking to the end point that you were talking to last time so you know if you have anything that tells you that that was a good phone call you know that you are in the same state you were before so again this makes it be very easy and understandable for people who are not crypto savvy who are not security savvy it can be put into all sorts of devices that's right the question is what about a non-technical person using this phone if your mother wants to use this phone she doesn't have to read aloud the little hash digits that are displayed she could just talk on the phone the protocol would work the same way the packets going back and forth are still you know the same packets it's just that final check that you do to verify to yourself to assure yourself that there's no man in the middle you would skip it and presumably the man in the middle doesn't know that you're going to be lazy and you're going to skip it so he's afraid to to do his attack it's an active attack he has to actually sit in there and generate packets and inject them he's going to be afraid to do that because he's afraid he'll be discovered because maybe your mom isn't as lazy as he thinks one of the other advantages of this is that you know that if there's anybody listening to a phone call they've always been there so this also makes it very difficult for the attacker because there is no way for them to get in and get out they have to be in at the beginning and stay in because the minute they drop out they are also detected this is a non-cryptographic security property that is very nice because it serves as a real deterrent to the attacker it makes their life really difficult yeah well you could the question is what happens if you try to call somebody who's using a regular POTS phone on the public switch telephone network in that case you would have to go through a gateway that connects the VoIP world to the PSTN world and that means that you're not going to be able to make it a secure call end to end now theoretically at least you could make it a secure call between your phone and the gateway where it touches the PSTN and then that last mile hopefully it's only a mile would be in the clear but that gets you across the Atlantic or across national borders yeah in the worst case it's no less secure than a regular PSTN call so that means that the vulnerabilities the new vulnerabilities that come from being in a VoIP world have been largely solved by this yeah the question is the US government is requiring people to put back doors in their VoIP software I believe you're probably referring to Kalia well you know they may change the way Kalia works but my I'm not a lawyer and I don't have the most perfect understanding of this but my limited understanding of Kalia is that it largely applies to the service providers it largely applies to the people who have gateways to the PSTN or the servers I don't I don't think it applies to end users so if you're running some software on your laptop computer you know and it sets up an encrypted link between you and the other party without the involvement of the service provider and you're not going through a gateway to the PSTN then I'm going to go out on a limb here and suggest that Kalia doesn't apply to that case now it's possible that they could change the laws you know make it more aggressive but we'll have to worry about that when that happens yeah I haven't worked out the protocol to make this an anonymous system it you know it's pure to pure you know unless you have to go through a proxy because of some firewall problems yeah probably if you do the anonymous part you're probably going to sacrifice your man in the middle protection yeah there's not that much overhead for the encryption the SRTP adds a little bit of extra to each packet for an HMAC an authentication code that gets stuck on to each packet it's long but it can be short to 32 bits and that's not you know it's not that much of a bandwidth and the only reason why that's there is actually not to encrypt it but to authenticate to prevent someone from sending in packets in a denial of service attack so that the packets can be rejected because they don't they don't authenticate it's not actually necessary for the encryption it's necessary it's part of the extra protection you get from SRTP against a hacker coming in and injecting packets that aren't part of your phone call I don't know if that's very clear we can talk about it later if you want more details or go and read the spec for SRTP there's an RFC for it it'll explain why you want to have that extra stuff you know it isn't only political reasons why I'm doing this it's also business reasons I think that if we're going to successfully migrate our phone calls to VoIP to the internet we're going to need this kind of protection and and in order to make a simpler design I'm doing it this way and so it isn't just my instincts for civil liberties it's also my instincts for simple design and the need for having secure calls you know we need to protect critical infrastructure and this is a good way to do it that wasn't in response to any question but I just wanted to add that I don't want everybody to just think I do everything for political reasons yeah well you know the question is what's the timing on the release of the source code first there has to be some source code what you just didn't see is a demo of my prototype it's a prototype it's written in python you know it's not the product and it does work I swear it works just doesn't work here but what I'd want is I want a product written C and there isn't one to get one I'm going to need funding so I don't have a timetable for that but what I might do a lot of people have been asking me I've gotten tremendous number of requests to just release the prototype for people to play with and for that I'm looking at I've got a whole lot of travel in August and so I'm going to really try to get it out by the end of August I actually considered trying to get it out yesterday for Black Hat but I called a law office there's a lawyer I'm talking to about the export controls well I had to file documents with the commerce department to tell them about it because you know there's still a little tiny bit of export controls left I mean we fought to get rid of the export controls in the 1990s and we won they got rid of the export controls but there's just a little bit left the only thing that you're required to do is that you just have to tell them about a product like this you don't have to ask their permission you just have to inform them telling them about the product but there's one other last vestigial remnant of the export controls you're not allowed to export it to about six or seven countries like North Korea and Iran and Sudan and you know those countries they're at the embargoed countries and so to put it on a web server I have to put in special checks to make sure that it's not being downloaded by someone in one of those countries and I don't know how to do that and so I couldn't figure out how to do it in time for Black Hat yesterday if I could have done it in time for Black Hat you would have been able to download it today if anybody wants to give me a hand on that contact me and I'll put you to work there's a lot of Unix weenies in here and I'm sure that somebody in here can help me set up a server to do the reverse DNS lookups and all that kind of stuff there's even some commercial packages that will do it for you but I don't want to have to pay for them yes got a yell really loud we got this loud air conditioner and we got a lawn mower and whatever else is going on so I can't really hear you conference calls what about conference calls well in order to do a conference call you would have to do one of these calls here just take this exact protocol and you'd have to do it between you and a server and every other person who participates would all have to do it to the same server server would mix the audio together and you got to trust the server also which isn't so bad no each person would have a different encrypted Diffie Homan exchange there would be a different session key and the server would just treat them like they were all separate phone calls and then mix the audio together and distribute it back out at least that's one way to do it alright now let's not always see the same hands ok well maybe I finished early you got any other questions you can ask me later so what do you think is it going to work I'd like to get your opinion about one thing is this going to do you think that this is a better architecture than the other architectures for those of you that have been reading the encrypted VoIP approaches what do you think my phone is ringing I think it's the guy in the back oh you want to try it once more why do you have a reason to believe it will work this time oh hey they opened up something in the firewall we're going to try one more time to do the demo just a minute if you want to wait one more time and to see another spectacular failure just wait a second ok let's see if this works I did you know I hit the call button we're not getting any evidence that ok I'm going to hang up well incoming call hey it's secure look at that going secure but we have no audio is there any audio can you give me some audio ok just a minute wait let's try no audio we're not getting any audio ok what we're going to do is hold the microphone up to the little tiny speaker on here where's the yell it yell say something I don't hear anything now yeah ok yes there's sound coming out here alright now listen to this you see this secure button the secure light here watch this I'm going to press this and this is what a wiretapper hears this is the first reg in the program ok watch that's taking the encrypted packets and playing them without decrypting them first so it sounds like white noise I'm going to do that again wiretapper hears this and that little that little staccato you know there's a lot of gaps there it's because of jitter and bandwidth problems but anyway so encrypted text sounds like white noise so let the meat cipher text and we have a go clear button here for the weenies here now it's just like making a normal plain text call and if we hit go secure it goes back to secure mode alright but I'm sorry we have no audio oh can you give us audio say something please say something say something audio sorry say something please listen to this call actually these buttons here go clear and go secure are not necessary in the real product but we put them in so because we're engineers and we like to fool around so I'm going to say go secure here and it does a little calculation for diffie and now that little bong that you just heard is the bong that says you're now secure oh the hashes let's see is there a man in the middle I say 5sz 3ua 3ua that's right there's no man in the middle so it's great no one knows what we're talking about we have a secure call here you have anything secret you want to tell me so we're done I'm going to hang up and that's it see you later thanks Steve alright finally we got it to work we got it to work I told you it worked I wasn't just making this up oh yeah you had one more question what the open source voice