Sunday, September 11, 2011

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 “—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.


  1. Hi,

    i am Fabio Pietrosanti, CTO of PrivateWave, we do Mobile Voice Encryption Software (also with ZRTP encryption).
    We released our C++/Java ZRTP implementation, ZORG Project, under .

    We would be happy to try to find some cooperation on ZRTP, does interoperability testing and evaluate possible marketing opportunity.

    We already use SNOM equipment for end-to-site (SIP+TLS/SDES) systems, but several customers use end-to-end encryption (SIP+TLS/ZRTP) we would like to be able to provide VoIP Landline also on end-to-end encryption.

    Waiting for yours

    Fabio Pietrosanti
    Founder, CTO
    PrivateWave Italia SpA
    Skype: fpietrosanti

  2. The regular builds dont include ZRTP. If you want to have a build, please contact snom and we'll send you a link.

  3. Hi, can you contact me privately at ?

    I don't have direct SNOM contacts other than contact forms on the public website.

    We would be happy to make some interoperability testing and discuss about possible "certification" of the interoperability :-)

  4. So, is there a roadmap for ZRTP? When will it be released in the standard firmware build for the M9/M9R?

  5. The snom m9r has more memory, so there we can include it in the standard builds. As for the m9, we were getting a little tight with space, so we decided not to include it in the standard builds. It would be good to get more feedback on the ZRTP stuff; every technology takes it time and we would love to see ZRTP taking off.

  6. Thanks for the replay. Is there a possibility to take part in the tests for enduser? I´d know many guys who´d like to "play" with this... (

  7. Hi
    Could you please clarify the ZRTP status at least for M9r? Is it included by default?

    We are thinking to buy quite a lot of SIP devices but encryption (not openvpn) is vital

  8. So, I asked the SNOM support about ZRTP and M9R. Well, guess what? They do not know anything about it...?

  9. Does anybody know more about ZRTP and Snoms ? I'm very interested in trying it out even if it's unsupported or in beta condition.

  10. It was a try three years ago. The sales impact was as far as I can tell practically zero. Unless something major happens in the market I don't think that there will be another approach to integrate ZRTP into the mainstream build.

  11. Any advance on zrtp?
    there are companies like that offers standalone crypto servers. When snom will add zrtp? any ideas??

  12. @snom m9: Does Snowden count as a major impact in the market?

  13. I remember Snowden said that buggy implementations are a big problem, not the algorithms. Looking at heartbleed, this makes sense today. If you implement ZRTP the wrong way, the agencies of the world will find their way to listen to your calls, just like with TLS and SDES. Anyway, the biggest impact will have DTLS for WebRTC, especially because Chrome is moving away from SDES.