ZRTP

ZRTP is a cryptographic key-agreement protocol to negotiate encryption keys required to establish an end-to-end secured VoIP (Voice over IP) phone call.

The first release of ZRTP protocols has been invented and published in 2006 by a group of well-known cryptography experts:

• Philip Zimmermann, original inventor of PGP

• Jon Callas, Chief Scientist at PGP Inc, previously co-worker of Bruce Schneier
• Zooko Wilcox O’Hearn, peer to peer hacker and cypherpunk
• Colin Plumb, famous old school cryptography expert
• Alan Johnston, famous VoIP telecommunication expert

The protocol, subject to public security review for more than 4 years, improved with continuous enhancements and security analyses by scientific and security communities from all around the world.

Latest updated protocol specification is available for download from IETF website in ZRTP page.

Basically ZRTP makes an automatic key exchange between peers that support such encryption protocol and secure the voice communication channel. This way it provides the users the ability to verify that there is no man in the middle, by verbally comparing two strings. The two strings will be displayed on the caller phone and the called phone, and they have to be exactly the same.

The strings, that the caller and the called must compare to verify that the communication line is secure, are called Short Authentication Strings (SAS) and derive from the PGP Word List (a list of words for conveying data bytes in a clear unambiguous way via a voice channel).

For usability purpose, the SAS can be verified only once, and then each party can mark the other as “trusted”. This way the parties do not have to verify the SAS at their every call. This great feature is provided by the key continuity feature of ZRTP.

Due to its expansion, ZRTP became a very complete protocol for voice encryption, covering also particular usage scenario that we don’t use or support.

PrivateGSM uses a reduced subset of the ZRTP feature in order strip down all the unneeded functionalities - keeps it lightweight, easy to understand, analyze and audit:

• Key agreement method: Ecliptic Curve Diffie-Hellman 384bit (ECDH-384 mode)
• Symmetric encryption: AES-256 in Counter Mode
• Self-Healing Key Continuity: Addressbook integration with Cache operations
• NO Diffie-Hellmann mode (only based on Ecliptic Curve cryptography)
• NO PBX Enrollment
• NO Multistream mode
• NO Pre-shared mode
• NO SAS signing with OpenPGP or X.509v3
• NO GoClear support (only encrypted calls)

Thus, ZRTP is used to assist just what it was designed for: Make secure phone calls.

Technically speaking, ZRTP has a great advantage over SRTP. It does not require any kind of SIP specific protocol extension in order to work properly, because all its operations are “in-band”, performed in the same communication channel through which the voice is transported.

After the SIP telephony handshake is completed successfully (the called peer answers the phone), ZRTP key handshake is started, followed by the exchange of encrypted audio:

Additionally, note that ZRTP increases the strength of entropy generation system by feeding the raw entropy pool with some audio voice sample. The audio voice sample is not sent during key exchange, but recorded from microphone. This way ZRTP implementation always has a fresh and strong entropy collected from a physical source of entropy such as the microphone. We follow strictly all Random Number Generation recommendations of ZRTP RFC.

ZRTP protocol, by itself, does not work across a certain PBX (for example, Asterisk block it). PrivateWave technology extended the protocol with some light modifications, called ZRTP Masquerading. It allows the protocol to function with a non-ZRTP supported PBX as well.

If you would like to inspect and analyze a ZRTP key exchange, please visit Wireshark ZRTP dissector web page.

N.B.: ZRTP should not be used for end-to-site encryption because it creates too much overhead and security management tasks for the end-user and for the security staff. It makes the overall system less secure because more complex to be maintained. For end-to-site encryption security scheme, SRTP/SDES is available since 2004. It is widely diffused and implemented by most enterprise PBXs. In order to achieve security, it requires proper implementation of a server-side certificate (like HTTPS banking website) and strict client-side verification of such certificate. ZRTP enrollment for end-to-site encryption is not supported, as it adds too much complexity and bureaucracy compared to the simplicity of security management of SRTP/SDES.