Bayonne logo

ZRTP FAQ

FAQ about ZRTP, SRTP, and the GNU ZRTP implementations

Rationale

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.

Contents

Generic FAQ regarding ZRTP, GNU ZRTP

What happens or what to do if


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.

ZRTP features and non-features

ZRTP and the GNU ZRTP implementation provide features to communication programs to

What ZRTP does not provide:

ZRTP and communication programs

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.

How does it work?

In principle, ZRTP uses three phases to negotiate and set up the SRTP master keys, and to switch to SRTP mode:

  1. discovery phase – detect if the peers supports ZRTP;
  2. key agreement phase – exchange the key material;
  3. secure phase – confirm the cryptographic data and 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, SRTP, and ZRTP – and their relationship

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.

What happens if the other party's program does not support ZRTP?

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 – what is it, where to find it, what to expect?

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:

Which cryptographic algorithms are available for secure RTP (SRTP) in GNU ZRTP?

Currently, the GNU ZRTP implementation supports the following symmetric cryptographic algorithms:

Which key agreement algorithms are available in GNU ZRTP?

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.

Does ZRTP support key continuity?

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.

Can I or somebody else recover a key?

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.

Which SRTP authentication algorithms does GNU ZRTP implementation support?

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.

Does ZRTP require SIP, XMPP or other signaling protocols?

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.

Does ZRTP store data about me, does it store used keys?

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.

Can ZRTP work without any data storage?

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.

What is the ZRTP identifier?

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.

What is the Retained shared Secret (RS)?

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.

Can ZRTP detect and report Man-in-the-Middle attacks?

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.

Background Info

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:

What is the SAS and how to use it?

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.

The ZRTP cache file was deleted or is corrupt?

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.

The ZRTP cache file was copied by a bad guy?

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.