ZRTP FAQ
From GNU Telephony
This is an FAQ about ZRTP, SRTP and the GNU ZRTP
Contents |
[edit] ZRTP - what's the fuss about it
The inventor of ZRTP, Phil Zimmermann, is a well known person in computer security. He is best known for his famous Pretty Good Privacy (PGP) program that brought strong encryption, data security, and privacy to the masses. ZRTP, Phil's newest coup, enhances security and privacy when we use the Internet to talk to each other using audio or video, commonly known as Voice-over-IP (VoIP). From an user's point of view ZRTP is very easy to use and it does not require a specific infrastructure once it is implemented in the VoIP programs. You can get the ZRTP specification at Phil's Zfone page.
GNU ZRTP implements the basic mechanisms of the ZRTP specification. GNU ZRTP consists of two main parts: the GNU ZRTP core which is independent of the RTP/SRTP implementation and a GNU ccRTP specific extension that links the GNU ZRTP core to the RTP/SRTP stack of GNU ccRTP.
The GNU ZRTP extension for GNU ccRTP extends the standard ccRTP classes and adds specific methods to provide ZRTP support. Applications may use the GNU ZRTP extension in the same way they use the standard ccRTP classes. Only a very few modifications are necessary to secure all RTP sessions. Refer the the GNU ZRTP How To.
[edit] RTP, SRTP, and ZRTP - and their relationship
RTP is the basis protocol to exchange media data such as audio or video streams between two peers. RTP data packtes consist of a fixed header part, an optional variable header part, an optional variable extension header part, and a variable length data part. The RTP specification and the accompaning RTP profile specifications describe how to populate the header parts and the data parts.
A basic RTP session is unidirectional, thus if two peers like to exchange data in both directions they must setup two RTP sessions. This is an important fact when it comes to security (see below).
SRTP is, strictly spoken, not a protocol on its own but a specification how to protect a RTP packet. SRTP defines
- which parts of a RTP packet must be encrypted to protect against eavesdropping
- which parts shall be authenticated to detect data manipulation
- which encryption algorithms and encryption modes to use
- how to generate keys, how to refresh keys, and so on
The SRTP specification also defines how to setup and maintain a cryptographic context. This context holds all necessary data to perform the security operations, for example the SRTP encryption keys, the packet sequence counters, authentication keys, and so on. Each SRTP session, which is the same as a RTP session, has its own context. Thus a bidirectional SRTP communication requires two different SRTP cryptographic contexts.
The SRTP specification is a fairly complex specification and you need some understanding of the overall security topics if you like to read and understand it.
ZRTP is a protocol in its own right that uses the basic RTP to exchange its data. The sole purpose of ZRTP is to negotiate keys between peers and use these keys to compute cryptographic data to setup the SRTP cryptographic context. Thus
ZRTP is not a replacment of SRTP but an enabler to use SRTP in an easy way.
Once the SRTP cryptographic context is setup ZRTP steps out of the way and does not require any bandwidth or a large amount of CPU cycles.
[edit] How does ZRTP setup the SRTP keys?
In principle ZRTP uses three phases to negotiate and setup the SRTP master keys and to switch to SRTP mode.
- Discovery phase - detecting if the peers supports ZRTP
- Key agreement phase - exchanging the key material
- Secure phase - confirm the cryptographic data and switch to SRTP mode
During the first phase both ZRTP peers exchange information about the encryption, key agreement, and authentications modes they support. Currently the ZRTP specification defines the following encryption modes:
- AES Counter Mode with 128 bit key length
- AES Counter Mode with 256 bit key length
To exchange the key material ZRTP uses the Diffie-Helman key agreement algorithm. For this algorithm ZRTP can use different modes:
- 3072 bit Diffie-Helman values
- Diffie-Helman based on elliptic curves (no commonly used yet)
The SRTP authentication modes can be set to either 32 bit authentication or 80 bit authentication.
During the next phase the peers generate their Diffie-Helman values and exchange the public part of the Diffie-Helman key pair. Together with these values the peers may also exhange additional secrets, such as Retained Secrets (RS), SIPS secrets, or a secret like a password. ZRTP uses all available secrets and combines them in a clever way to generate and derive the SRTP master keys. The combination of several key data makes it very hard for an attacker to guess the values.
After ZRTP computed the SRTP key data ZRTP exchanges some confirmation data to check if the key negotiation was successful. I the last step ZRTP sets up the SRTP cryptographic context and switches from standard RTP to SRTP mode.
[edit] How does ZRTP detect Man-in-the-Middle attacks?
The Diffie-Helman key agreement protocol is vulnerable to a so called Man-in-the-Middle (MitM) attack where a bad guy sits between the good guys and has control of their communication path. To overcome this weakness ZRTP defines counter measures:
- A Short Authentication String (SAS)
- Retained Secrets (RS) - ZRTP implementations compute the RS from the previously negotiated data and uses the RS for the next session
After the key negotiation phase the ZRTP implementations on both peers compute the SAS and present it as short textual information to the user. Both users should read the SAS string and compare the values over the audio connection. If the values on both peers are the same no MitM happened. After verifying the SAS data the user may set the SAS status to verified. If both users set SAS to verified the ZRTP implementations can save this status and are able to use this information during further negotiation sessions. This relieves the user from always verifying the SAS.
Once a successful ZRTP negotiation was performed between two peers ZRTP can detect any MitM or other attack that may happen during further ZRTP sessions.
