ZRTP FAQ
FAQ about ZRTP, SRTP, and the GNU ZRTP implementations
FAQ about ZRTP, SRTP, and the GNU ZRTP implementations
The ever growing use of Voice over IP (VoIP) and other media applications triggered a more widespread use of the Real-time Transfer Protocol (RTP). This protocol is the workhorse for VoIP applications. Many VoIP applications send RTP data over the public Internet in clear, thus the data is not protected from eavesdropping or modification. Therefore, most VoIP applications are regarded insecure today. During the last years, several activities started to enhance the security of RTP.
While it is important to look at the technology, the protocols and alike, it is also important to look at the implications a specific technology may have on its implementation, deployment, and usability. Usability is of major importance for VoIP peer-to-peer applications: these applications are mainly used by non-IT persons. Therefore, the handling must be simple, easy to use, and shall not require special infrastructure or registration.
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.
ZRTP and the GNU ZRTP implementation provide features to communication programs to
What ZRTP does not provide:
ZRTP cannot work standalone and provide secure communication. Communication programs use the ZRTP implementation together with their RTP stack; the programs offer the user interface, and other features required to set up audio/video calls and to provide interworking with ZRTP.
In principle, ZRTP uses three phases to negotiate and set up the SRTP master keys, and to switch to SRTP mode:
During the first phase, both ZRTP peers exchange information about symmetric cryptographic algorithms, key agreement algorithms, and authentications modes they support.
During the next phase, the peers generate their Diffie-Hellman values and exchange the public part of the Diffie-Hellman key pair. ZRTP requires to generate new Diffie-Hellman key-pairs for each session. ZRTP does not use long living keys. Refer to key continuity and key recovery answers for more information regarding these topics.
Together with these values, the peers may also exchange additional secrets, such as Retained Secrets (RS), or a secret like an additional password (depends on the implementation of the communication program). 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 has computed the SRTP key data, ZRTP exchanges some confirmation data to check if the key negotiation was successful. In the last step, ZRTP sets up the SRTP cryptographic context, and switches from standard RTP to SRTP mode.
RTP is the basic protocol to exchange media data such as audio or video streams between two peers. RTP data packets 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 (RFC 3350) and the accompanying RTP profile specifications describe how to populate the header and data parts.
A basic RTP session is unidirectional, thus if two peers like to exchange data in both directions they must set up two RTP sessions. This is an important fact when it comes to security (see below).
SRTP is, strictly speaking, not a protocol on its own but a specification on how to protect and encrypt an RTP packet. SRTP (RFC 3711) defines
The SRTP specification also defines how to set up 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 an RTP session, has its own context. Thus a bidirectional SRTP communication requires two different SRTP cryptographic contexts.
ZRTP is a protocol in its own right that uses the RTP sessions to exchange its data. The sole purpose of ZRTP is to negotiate keys and cryptographic algorithms between peers, and use these keys and algorithms to generate data to set up the SRTP cryptographic context. Thus
ZRTP is not a replacement of SRTP but an enabler to use SRTP in an easy way.
Once the SRTP cryptographic context is set up, ZRTP steps out of the way and does not require any bandwidth or CPU cycles.
ZRTP will detect this during its discovery phase, and can inform the user about this fact. Obviously, ZRTP cannot set up secure RTP session in this case.
Therefore, it is safe to have ZRTP enabled all the time. As soon as ZRTP detects that the other party's communication program also supports ZRTP, it automatically starts its key negotiation and sets up secure RTP channels.
GNU ZRTP implements most features 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 specific module that links the GNU ZRTP core to the underlying RTP stack and to the operating system.
The following GNU ZRTP implementations are available:
Currently, the GNU ZRTP implementation supports the following symmetric cryptographic algorithms:
To exchange the key material, ZRTP uses the well known Diffie-Hellman key agreement algorithms. For these algorithms, GNU ZRTP implements several modes that are compliant with the ZRTP specification:
Elliptic curve algorithms require less CPU cycles and are more secure than a finite field (normal) Diffie-Hellman key exchange algorithm.
Yes. After a first successful key negotiation between two users (and devices), ZRTP computes some data (Retained Shared Secrets – RS), and stores this data in a cache file on the users' devices. Despite the name, this data is not really secret but is used to implement key continuity, and to simplify validation of further key exchanges. If the users call again and use the same device, then ZRTP detects this and will use the cached RS data to verify the key exchange. If this verification fails, ZRTP reports this and the users shall compare their Short Authentication String – refer to this answer.
Such a behavior may happen if the user deleted the ZRTP cache file or the device was broken. Thus it is not a real security problem – just a little inconvenience.
There is a simple answer to this: No if both users made sure that no Man-in-the-Middle (MitM) attack took place during the ZRTP negotiation phase. It's a simple procedure: just compare the Short Authentication String – refer to SAS.
Because ZRTP generates and negotiates the keys on its own, nobody knows the keys. Thus, even the users are not able to tell the keys because they do not know them. The GNU ZRTP implementation does not store generated keys outside its own internal memory, and clears the memory as soon as possible if a specific datum is not longer in use.
GNU ZRTP supports two authentication algorithms:
The Skein MAC is faster and requires much less CPU power, and is claimed to be more secure than HMAC-SHA1. Skein is a candiate for the new NIST SHA-3 hash algorithm.
No. ZRTP uses the RTP session to exchange its data. To set up the RTP session communication, programs may use any mechanism, including SIP or XMPP, to exchange the parties' RTP session addresses and other necessary information.
You may even use a small ZRTP-enabled communication program that uses simple point-to-point RTP sessions. Of course, in this case you need all the necessary adress data of the called party.
The ZRTP protocol specification defines features that require data storage. This data does not contain keys; it does not identify a person nor can one use this data to recover keys. The ZRTP data is usually called the ZRTP cache file.
ZRTP stores status information that consists of the ZRTP identifier, the SAS verification status, retained shared secret (RS), and some more.
The location of this file depends on the implementataion of the communication program.
Yes. This may be advantageous for devices that cannot store the ZRTP cache file or in situations that may require plausible deniability about ZRTP usage. If ZRTP is not able to store data, then
If ZRTP runs in cacheless mode, the communication program usually displays a
warning message on every call to remind the user to check the SAS. The warning
is usually something similar to: No retained shared secrets available -
must verify SAS.
Currently, no implementation supports this mode (cacheless mode) but it is on the roadmap for the GNU ZRTP implementations.
The ZRTP identifier (ZID) is a random number that identifies the combination of the device and the communication program instance. ZRTP uses this identifier to identify sessions involving the same device/communication program, and stores status information for these sessions.
At the end of the first ZRTP key negotiation, GNU ZRTP computes and stores Retained shared Secrets (RS) that enable it to detect a MitM attack and other problems (network problems for example) during further sessions. ZRTP uses hash algorithms to compute the RS, thus it is not possible to recover keys or other relevant key material by analysing the RS.
ZRTP computes and updates the RS after every key negotiation, to enable key continuity and recover from possible errors during key negotiation.
At the very first session to a device/communication program, no status data
is available (see also here), and ZRTP is not able to
detect a Man-in-the-Middle (MitM) attack. Therefore users should always
check the SAS, and verify that the key negotiation was
indeed correct. The communication program displays a warning message similar to
this one: No retained shared secrets available - must verify
SAS.
At the end of the first ZRTP key negotiation, GNU ZRTP computes and stores
Retained shared Secrets (RS) that enable it to
detect and warn about a possible MitM attack on further sessions to the same
device/communication program. If ZRTP detects a possible MitM, it reports this
and the communication program usually gives a warning message similar to this
one: Valid retained shared secrets available but no matches found - must
verify SAS.
ZRTP uses Diffie-Hellman key agreement to exchange key data between the two communication programs. The Diffie-Hellman 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 problem, ZRTP defines countermeasures to enable the users to detect a MitM and to make sure nobody tampered with the ZRTP negotiation. ZRTP defines simple, yet powerful mechanisms:
ZRTP uses a Short Authentication String (SAS) as an easy-to-use mechanism to detect if something happened during key negotiation, and to enable users to check the integrity of the session.
The ZRTP implementations compute the SAS and the communication programs must present it as short textual information to the user (ZRTP defines the length of the mandatory SAS to 4 characters).
Both users can now read the SAS data and shall compare it over the audio connection.
A good way to check the SAS is that the caller reads the first two characters of the SAS, the callee the second two characters. If the values match, then nobody tampered with the ZRTP key negotiation session. Comparing the values should be done at the beginning of the call and during normal conversation.
After verifying the SAS data, both users may set the SAS status to verified. If both users set SAS to verified, the ZRTP implementations store this information and use it in further ZRTP sessions.
Actually, this is not a big problem. GNU ZRTP creates a new empty cache file and a new ZRTP identification (ZID) for this device/communication combination. Then place calls as usual. Of course, all information about verified SAS is not longer available and should be re-established (see SAS).
If you start with a new ZRTP cache file or call a partner for the first
time, then GNU ZRTP reports the following warning: No retained shared
secrets available - must verify SAS.
Well, this may be a bigger issue, but it is not really dangerous. GNU ZRTP generates different retained shared secrets even if two callers use the same ZRTP cache file – in this case you and the bad guy who copied the file. This is possible because ZRTP uses the random key data to compute the retained shared secrets.
Therefore, the two ZRTP cache files go out of synchronization, and this causes warning messages at the called parties because ZRTP sees different retained secrets from the same ZRTP identification. If you see such a message, then make sure to verify the SAS and to identify your communication partner.
GNU ZRTP reports this error if the ZRTP cache files are out of
synchronization: Valid retained shared secrets availabe but no matches
found - must verify SAS.