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 photoed all the time.
I figure I've already gotten in enough trouble with the Fed so it can't get any worse, right?
Let's see if this comes up. Yep.
Wow, that's a little bit lower resolution than usual, but that's alright.
I'm going to...
Okay.
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.
Um...
Well...
You know...
For years we've enjoyed the relative safety of the public switch telephone network.
I say relative safety.
I'm only 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. You 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 PGP 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 VoIP.
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.
To tell me...
Yes?
You had to reboot your machine?
Oh, man.
That would explain a lot. Okay.
Alright.
Okay, I'll leave this open here.
I'm going to put you on the little speakerphone.
Okay, so you just yell into your speakerphone or into your phone whenever 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 PGP Phone, I had to improvise my own protocols.
There was no SIP, there was no RTP.
It was just the beginnings of RTP at that time.
They were just 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 what it had to be.
So, it was a neglected product for many years.
What?
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 NAT firewall traversal things in the open source VoIP plan.
I'm using an open source VoIP plan 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 Sell 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.
I'm gonna... We're gonna exit now.
This is terribly embarrassing.
This is the... You know, it worked 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...
But we got some...
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...
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 gonna abort this.
I'm just gonna explain how it works.
Goodbye.
Okay.
Now I can get away from the...
I'll just use this one.
Okay.
How humiliating.
You have to believe me that it worked at Black Hat yesterday.
I might try it again.
Oh, yeah?
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.
All right.
I looked at various other protocols that are currently being considered for secure VoIP.
There is some IETF RFCs that define various ways of doing it.
Most of them rely on external sources of a centrally controlled public key infrastructure with a 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-Hellman key exchange.
Yeah, okay.
I do a Diffie-Hellman 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 man-in-the-middle attack.
This eliminates the need for a certificate authority, a public key infrastructure.
Boy, there's a lot of feedback here.
The other way. Turn it the other way.
Yes, I'm using a Macintosh.
For security reasons.
Yep.
Alright, that's just not going to work.
There are other approaches that don't use a public key infrastructure necessarily.
They send SIP packets that use TLS connections and they put 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 in 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, encrypts it as an SMIME 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 feels wrong.
And not only that, but it means that at the end of the call, you have persistent key material around that you can 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-Hellman 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. 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 key 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,
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 cached.
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 involve 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, you know, I really ought to check this,
and you read it aloud, and the other person reads it theirs aloud, 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 him, 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 the 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 key 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, but 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.
When I say proven, I don't mean proven successful. I mean 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 weenies, if you go out and try to fix the open source VoIP client and make it work on all platforms,
PC, 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 client and how they interact with a firewall.
So, I'd like to open it up for questions.
Yeah.
You're asking me to elaborate on my remark that PKI is a failure.
Well, you know, I don't think PKI is 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 embedded 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 is a failure.
Well, let's talk about how a man-in-the-middle attack would work.
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.
So imagine that your friend also has a phone like that.
And you want to call and it sets up a Diffie-Hellman exchange and now you're talking, right?
But imagine that an eavesdropper went down to Walmart and bought two of these phones.
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 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 there's these two phones that they bought at Walmart, right?
And now there's a random session key between you and one of the phones,
and there's a different random session key between the other phone and your friend, right?
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?
No, unfortunately, it's written in Python, so it would have to be, you know, sort of refactored into C.
The question was, can this code be ported to other open source clients?
Yeah, 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.
Remember, PGP was started out as a private project without any money, you know.
I paid for all this myself.
Actually, I did get some help.
Jeff Culver, who is 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, you know, 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 a 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.
Jeff Culver 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 czar, you know.
He left the Bush White House and wrote a book 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, because that's what I did with PGP.
And I believe it's 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 retain 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've thought about doing that.
You could put your configuration files in a USB drive 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, you know?
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 secret feature is an extra 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-Hellman exchange, I'm using a 4000-bit Diffie-Hellman.
And, for the block cipher, I'm using AES-256 running in counter mode, as defined by the SRTP protocol.
So, I think I'm doing... 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 VCs, and I've been cajoling 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, cajoling 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 this 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 or 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.
It's like 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 sharing 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 very 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 kind of 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 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 is 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, 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.
In the worst case, it's no less secure than a regular PSTN call.
So that means that the new vulnerabilities that come from being in a VoIP world have been largely solved by this.
The question is, the U.S. government is requiring people to put back doors in their VoIP software.
I believe you're probably referring to CALEA.
Well, they may change the way CALEA works, but I'm not a lawyer, and I don't have the most perfect understanding of this.
But my limited understanding of CALEA 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 think it applies to end users.
So if you're running some software on your laptop computer, 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 CALEA doesn't apply to that case.
Now it's possible that they could change the laws, make it more aggressive.
But we'll have to worry about that when that happens.
I haven't worked out the protocol to make this an anonymous system.
It's peer-to-peer, 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.
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 onto each packet.
It's 80 bits long, but it can be shortened to 32 bits.
And it's not that much of a bandwidth hit.
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 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 ahead 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 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.
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.
It just doesn't work here.
But what I want is a product where you can see.
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 a 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 for... 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.
Well, I've done that. I've filed documents with 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 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'll do it for you.
But I don't want to have to pay for them.
Yes?
I've got to yell really loud.
We've got this loud air conditioner and we've got a lawnmower 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.
The server would mix the audio together.
And you've got to trust the server also.
Which isn't so bad, you know.
Now, each person would have a different encrypted Diffie-Hellman 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.
Okay, well maybe I finished early.
If you've 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 about the encrypted VoIP approaches.
What do you think?
Oh hey, they opened up something in the firewall.
We're going to try one more time to do the demo.
Okay, alright.
Just a minute. If you want to wait one more time and see another spectacular failure, just wait a second.
What?
Okay, I'm going to try calling them.
Okay, you ready? You ready?
Okay, let's see if this works.
I did.
You know, I hit the call button.
We're not getting any evidence that...
Okay, I'm going to hang up.
Oh, incoming call.
Unsecured call.
Hey, it's secure. Hey!
Look at that, going secure.
But we have no audio.
No audio. We're not getting any audio.
Okay, what we're going to do is we're going to hold the microphone up to the little tiny speaker on here.
Where's the... okay, yell it.
Yell.
Say something.
I don't hear anything now.
Yeah, okay, yes, there's sound coming out here.
Alright, now listen to this.
You see this secure button, this secure light here?
Watch this. I'm going to press this.
And this is what a wiretapper hears.
This is a little Easter egg in the program.
Okay, watch.
That's taking the encrypted packets and playing them without decrypting them first.
It sounds like white noise.
I'm going to do that again.
Wiretapper hears this.
And that little staccato, you know, there's a lot of gaps there.
It's because of jitter and bandwidth problems.
Anyway, so encrypted text, encrypted voice sounds like white noise.
So let them eat cipher text.
And we have a go clear button here for the weenies here.
And 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.
Say something, Steve, say something.
No, no audio, sorry.
No audio.
Okay, so this is a secure call. Nobody can listen to this call.
Say something.
Hey, Phil, how you doing? You look great on TV.
Alright, now I'm going to click that little indicator light that says secure.
Alright, now we're going to actually...
These buttons here, go clear and go secure, are not necessary in the real product,
but we put them in 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-Hellman.
And now that little bong that you just heard is the bong that says you're now secure.
Anyway.
3U8.
Oh, the hashes. Let's see, is there a man in the middle?
I say 5SZ.
3U8.
3U8. That's right. There's no man in the middle.
Alright.
So it's great. No one knows what we're talking about.
We have a secure call here.
Do you have anything secret you want to tell me?
Alright. 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 VoIP we're using...