ZRTP

My bud Hans and I tonight tested out encrypted VoIP with ZRTP. I noticed a while back that Twinkle supports it and have wanted to test it out, but none of my desk phones support ZRTP.

It was fun. When the call terminated, Twinkle displayed a cute message about verifying the SAS (short authentication string). It was 4 character (hprj, if you're curious) that represented our encryption key. It's the way ZRTP verifies that a man-in-the-middle attack is not underway. There was a padlock icon which we both clicked to verify that the SAS was correct. I'm not sure what if anything happened because of that, except that we both verified that our SIP phones have not been tapped by the feds.

In the SDP, ZRTP is advertised with "a=zrtp". It's not a separate protocol per se. The actual codec was selected through the normal means (we used speex/16000). Looking at the RTP data, I see a whole bunch of "AES256", "SHA256" and "DH4096". Presumably that's part of the ZRTP negotiation. I didn't delve further. What I see though is that the encrypted data is simply represented as Speex RTP, but the actual data has been scrambled so it would be meaningless to a passerby.

Based on this testing, I predict good things for ZRTP. It was quite painless to use as a caller. As long as it's enabled by default in the phone, there's really nothing else that a user has to do to use it. The SAS is short and you only have to verify it if you care. Phil Zimmerman says that you don't even have to verify the SAS every time. Just once in a while is good enough. And obviously anytime you're conducting private business (which is not the same thing as illegal business). The simple fact that ZRTP is used every time means that you can't tell whether a call is valuable or not just based on it being encrypted.

The one possible failure of ZRTP is that it doesn't hide any of the signalling data, so a spy would be able to see who you were calling. That problem would be quite hard to solve. I'm not sure of the benefit either as the cost to mask that information is much higher. You pretty much have to know all the routing information ahead of time. Even then, an eavesdropper could still see the two IP addresses involved, which will give away some amount of information. So for now, ZRTP is a good solution.

tags: 

2 Comments

zrtp in the real world

tensai, it was great that you tried zrtp. It's really easy to use, a lot easier than PGP for filesharing. A couple of notes: the version I use displays the SAS after handshake at the head of the call to confirm security, that wasn't clear from your review. Some new devices are coming that embody zrtp with plug and play capability. You literally plug in a little box as a bump in the line, and voila, make your calls to another zrtp user and you have high security. Best of all, zrtp has very low overhead, typically a couple ms of delay, and doesn't screw up your call quality.

I'm writing to clarify what zrtp was NEVER designed to do - spoof a call or hide the callers.

ZRTP was designed for privacy, not spying. Let's say I'm in France calling back to my US office for a business negotiation. ZRTP assures me that NOBODY can eavesdrop on our call. Sure, they can tell where I'm calling, and where I'm calling from from our IP addresses.

This gets past the CALEA issues, and it also reduces the likelihood of those three letter agencies from giving me a free trip to the land without habeas corpus.

Who needs ZRTP? If you'd doing business domestically or internationally over VoIP, you need zrtp. If you're a lawyer calling a client, you need zrtp. If you're in a country where there's a potential for kidnapping or blackmail, you need zrtp. If you want to talk to your mistress or paramour, you would be advised to use zrtp. If you are tempted to say unkind political words about Dick Cheney zrtp can assure you the NSA doesn't know what you're saying. If you're running for political office, zrtp is your assurance of privacy.

I can envision that every VoIP device will offer zrtp because it's so easy to deploy and has such low demands.

re: zrtp in the real world

Thanks for the comments. I agree with every point you make. I would clarify that when I said that "the one possible failure of ZRTP is that it doesn't hide any of the signalling data", what I mean is that by design it chooses not to hide any of the signaling data. To do so would be a monumental task and not worth the effort. Certainly not worth polluting such a simple system which as you say, is so darn simply to deploy and use.

I hope that it becomes commonplace for all calls. The more common encryption becomes, the less you can infer about a call based on whether it's encrypted. It becomes impossible to tell the "important" ones just based on their encryption status.

Subscribe to Comments for "ZRTP" Subscribe to zmonkey.org - All comments