Frequently Asked Questions regarding 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). These protocols 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 considered insecure today. During the last years several activities started to enhance the security of RTP.
- The Secure Real-time Transfer Protocol (SRTP) enhances security for RTP and provides integrity and confidentiality for RTP media connections. To use SRTP in an efficient way VoIP applications should be able to negotiate keys and other parameters in an automatic fashion.
- ZRTP is a protocol that negotiates the keys and other information required to setup a SRTP audio and video session
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.
Generic FAQ regarding ZRTP, GNU ZRTP:
ZRTP - what’s the fuss about it?
ZRTP features and non-features
ZRTP and communication programs
How does it work?
RTP, SRTP, and ZRTP - what is their relationship?
What happens if the other party’s program does not support ZRTP?
GNU ZRTP - what is it, where to find, what to expect
Which cryptographic algoritms are available for secure RTP (SRTP) in GNU ZRTP?
Which key agreement algoritms are available in GNU ZRTP?
Which SRTP authentication algorithms does GNU ZRTP implementations support?
Does ZRTP require SIP, XMPP or other signaling protocols?
Does ZRTP store data about me, does it store used keys?
Can ZRTP work without any data storage?
What is the ZRTP identifier?
What is the Retained shared Secret (RS)?
Does ZRTP support key continuity?
Can ZRTP detect and report Man-in-the-Middle attacks?
What is the SAS and how to use it?
Can I or somebody else recover a key?
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
- setup of secure audio and video session without additional infrastructure, server programs, registration, and alike.
- inform the user of the communication program if a session is secure or not, inform about problems and thier severity
- provide an easy-to-use method to detect if bad guys tamper with the session
What ZRTP does not provide:
- ZRTP cannot automatically authenticate the end-users, this is task of the users once they can talk to each other
- and last but not least ‘’‘ZRTP is no replacement for common sense: check that you talk to the right person and then check the SAS
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 setup audio/video calls and to provide interworking with ZRTP.
How does it work?
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 symmetric cryptographic algorithms, key agreement algorithms, and authentications modes they support.
During the next phase the peers generate their Diffie-Helman values and exchange the public part of the Diffie-Helman key pair. ZRTP requires to generate new Diffie-Helman 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 exhange 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 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 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 (RFC 3350) and the accompaning 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 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 and encrypt a RTP packet. SRTP (RFC 3711) 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.
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 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 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 setup 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 support ZRTP it automatically starts its key negotiation and sets up secure RTP channels.
GNU ZRTP - what is it, where to find, 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 specific module that links the GNU ZRTP core to the underlying RTP stack and the operating system.
The following GNU ZRTP implementations are available
- a C++ implementation as extension for GNU ccRTP. This implementations 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. Check this place to download GNU ZRTP C++. The SVN repository is on GNU savannah.
- A C wrapper that provides pure C programms to use the GNU ZRTP C++ implmentation. This wrapper is available at github.
- a Java implementation that already has the glue code to link into Java JMF or the free alternative FMJ. ZRTP4J is also available at GNU savannah.
Currently the GNU ZRTP supports the following symmetric cryptographic algorithms:
- AES Counter Mode with 128 bit key length
- AES Counter Mode with 256 bit key length
- Twofish Counter Mode with 128 bit key length
- Twofish Counter Mode with 256 bit key length
Which key agreement algoritms are available in GNU ZRTP?
To exchange the key material ZRTP uses well known Diffie-Helman key agreement algorithms. For these algorithms GNU ZRTP implements several modes that are compliant with the ZRTP specification:
- 2048 bit Diffie-Helman values
- 3072 bit Diffie-Helman values
- 256 bit Diffie-Helman elliptic curve
- 384 bit Diffie-Helman elliptic curve
Elliptic curve algorithms requires less CPU cycles and are more secure than a finite field (normal) Diffie-Helman key exchange algorithm.
Does ZRTP support key continuity?
Yes. After a first sucessful 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 verifications fails ZRTP reports this and the users shall compare their Short Authentication String - refer to this answer.
Such a behaviour may happen if the user deleted the ZRTP cache file or the the device was broken. Thus it is not a real security problem - just a little incovenience.
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. Ensuring that there is no attack is a simple procedure: just compare the Short Authentication String with your peer - 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 implementations do 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:
- HMAC-SHA1 which supports authentication lengths of 32 and 80 bit
- Skein MAC which supports authentication lengths of 32 and 64 bit
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 setup the RTP session communication programs may use any mechansism, including SIP or XMPP, to exchange the parties RTP session addresses and other necessary informartion.
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 spcification defines features that require data storage. This data does not contain keys, it 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
- ZRTP generates a new [[#faqId|ZRTP identfier for each new session. Thus the calling or called party cannot associate any status information on the RTP session.
- No Retained shared Secrets (RS) are available, thus automatic detection of Man-in-the-middle (MitM) attacks is not possible.
- The users have to positively identity each other and compare the SAS on each call to guarantee the integrity of ZRTP’s key negotiation phase.
If ZRTP runs in cacheless mode the commincation program usually display a warning message on every call to remain the user to check the SAS. The warning is usually something simliar 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 identifes the combination of the device and the communication program instance. ZRTP uses this identifier to identify sessions between 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 is able to compute and store Retained Shared Secrets (RS) that enables 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/commuincation 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 display 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 enables 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 availabe but no matches found - must verify SAS
Background Info
ZRTP uses Diffie-Helman key agreement to exchange key data between the two communication programs. 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 problem ZRTP defines counter measures to enable the users to detect a MitM and to make sure nobody tampered with the ZRTP negotiation. ZRTP defines simple, yet powerfull 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 happend 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 the 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 with 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 real 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 verfiy the SAS and to identify your communication partner.
GNU ZRTP reports this error if the ZRTP cache file are out of synchronization:
Valid retained shared secrets availabe but no matches found - must verify SAS
test: Werner Dittmann