Does ZRTP solve the key exchange problem?

In my previous blog I talked about SRTP and the problem to negotiate the SRTP secrets. If TLS can be used and this actually makes sure that the keys are negotiated between the endpoints, life is easy. However in many cases that is not possible and another solution is desirable. ZRTP tries to solve that problem and we put it into the m9, at least in a special build.

ZRTP stands for Zimmermann RTP. Phil Zimmermann is the guy who invented it. He is a kind of celebrity in the crypto scene, because he is the one who wrote PGP (pretty good privacy). ZRTP tries to solve the problem that there is in many cases no trusted entity available, e.g. a trusted root certificate authority like in the case of TLS and the use of certificates. If such a Root CA is available, then there are other options like DTLS, which runs TLS over the media UDP transport layer.

The general idea, in my own short words, is to store the cryptographic secret from the last conversation with someone and use it for the next conversation. Because most of the phone calls today are done by dialing the address book and you don’t trust a first-time caller anyway, this is a way to establish a trust relationship with the communication peer. On the m9, there is a directory called “zrtp” that stores the information, so that also after a reboot cycle this information is still available.

In the special case that you are talking to the PBX, the question is if you are talking to the PBX itself or the remote party. That’s where things get a little tricky. ZRTP needs the information in the SIP headers to figure out where you are talking to, so in theory you would have to have a different key for every remote party. That can be done relatively easy in the case of talking to extensions; but in the case of talking to someone on PSTN (over the PSTN gateway) this is not very practical. So in these cases there is either no ZRTP (which makes sense because the remote party on PSTN does not receive an encrypted audio stream) or the PBX or PSTN gateway has to encrypt the traffic in a B2BUA way, and also keep the keys for each remote party ID. Practically speaking, I would say, as long as there is RTP in the game, ZRTP makes sense; otherwise it is just a feel-good pill with no substance behind it. But at least for internal calls, ZRTP is an improvement; if the service provider lets the ZRTP packets pass through to the other side, it is also a very important improvement against the situation where you don’t encrypt at all. For example in the case of the “nsa.com—we got the cheapest routes to Afghanistan”, if they would pass the ZRTP packets back and forth between wherever you are and Afghanistan, then they would have a hard time to listen to your phone calls.

On the snom m9, the only thing about ZRTP you will notice is that there is a log level for ZRTP messages. If you want to play around, you will be able to see the ZRTP negotiation process. We don’t do things like playing out crypto messages at the beginning of the conversation, but AFAIK we do display the lock on the display of the handset once the call is secure.

So what’s the roadmap for ZRTP? It is for sure right now a chicken egg problem. If there are no ZRTP devices, there is nothing to test against. With the support for ZRTP in the m9 we wanted to help to increase the number of available devices, and even if the display is not perfect yet, it does help to increase the ratio of available devices. As always, feedback from customers is appreciated.