Skip to content
werner edited this page Mar 5, 2020 · 2 revisions

How to use ZRTP

Applications, such as VoIP clients or applications that require ad-hoc, session based end-to-end encryption, may use this library to negotiate encryption keys using an existing transport connection, for example RTP. Once the keys are available ZRTP does not use the connection anymore, thus does not require any bandwidth. The application uses the keys to setup encryption/decryption functions, for example SRTP, which perform the end-to-end encryption of the data.

Because ZRTP uses an established transport connection, it does not require and is not bound to a signaling protocol, for example SIP. ZRTP may use data transmitted by the signaling protocol to inform the other client that ZRTP is available.

Actually ZRTP is not even bound to RTP as its name may imply. An application can use any transport protocol that provides appropriate data exchange capabilities to send and receive ZRTP data packets. It's the task of the Transport packet filter/router (see below) to connect to the data transport. The ZRTP library does not depend on any specific transport protocol.

ZRTP as part of a client application

The following figure depicts how ZRTP connects to an application and how it uses the transport to send and receive its packets.

ZRTP Overview

ZRTP Overview

The blue boxes implement the ZRTP and encryption/decryption functions which connect to some transport protocol on one side and the application specific code on the other side. The upper layer application code never receives or sends any ZRTP specific data.

To reduce implementation efforts only the Transport packet filter/router needs to be implemented and adapted to the transport protocol and the application specific API. All other parts of ZRTP are self-contained. The ZRTP library includes an SRTP implementation as an example to encrypt and de-crypt data (RTP packets). However an application may use its own encryption and decryption functions.

Data flow, packet filtering and routing

The main tasks of the Transport packet filter/router are:

  • connect to the transport protocol
  • implement the API to the UI, audio/video handling, etc
  • implement the ZRTP callback functions to get ZRTP packets, negotiated keys, information about the encryption, the short authentication string (SAS), etc
  • filter incoming data and route ZRTP specific packets to the ZRTP implementation, send ZRTP packets
  • enable encryption/decryption functions after ZRTP negotiated the keys
  • get data from the application, route to encryption function (if encryption is active) and send it to the receiver
  • receive packets from transport and route them to decryption function (if decryption is active) and forward the plain data to the application

The ZRTP project repository contains some examples of Transport packet filter/router implementations. A more generic example will be available soon and application developers may use it as a starting point to setup their Transport packet filter/router and connect ZRTP to their application and transport protocol.

The application should implement some UI elements to inform the user about the security state, the SAS and if the the key negotiation was successful or not.