KryptoPhone uses ZRTP to provide real-time end-to-end encryption for VoIP calls.
ZRTP, an acronym for Zimmermann Real-time Transport Protocol, is a cryptographic key-agreement protocol meant to negotiate the keys for encryption between two end points in Voice-over-Internet-Protocol (VoIP) telephony call based on Real-time Transport Protocol.
ZRTP uses Diffie-Hellman (DH) key exchange and the Secure Real-time Transport Protocol (SRTP) for encryption.
The protocol was developed by Phil Zimmermann with help from Bryce Wilcox-O'Hearn, Colin Plumb, Jon Callas and Alan Johnston. ZRTP is published in RFC 6189.
The introduction page of RFC 6189 explains ZRTP as below:
“ZRTP is a key agreement protocol that performs a Diffie-Hellman key exchange during call setup in the media path and is transported over the same port as the Real-time Transport Protocol (RTP) media stream which has been established using a signaling protocol such as Session Initiation Protocol (SIP). This generates a shared secret, which is then used to generate keys and salt for a Secure RTP (SRTP) session.”
The protocol can be broken down into 4 phases:
Discovery and Protocol Negotiation
Diffie-Hellman Key Establishment
Session Key Confirmation
Secure Communication Session
Discovery and Protocol Negotiation:
In the Discovery and Protocol Negotiation phase, the initiator and the responder exchange ZRTP identifiers, supported ZRTP versions, and other details like hash functions, ciphers, authorization tag length, key agreement types and SAS algorithms. The messages exchanged in this phase (F1 – F4) are called Hello messages.
After the Hello messages (F1 – F4) are exchanged, the initiator sends a Commit message (F5) to the responder, and drives the key agreement exchange. The Commit message includes the protocol details that would be used, details like hash function, cipher, authorization tag length, key agreement type, and SAS algorithm.
Diffie-Hellman Key Establishment:
The initiator needs to generate its ephemeral key pair before sending the Commit, and the responder generates its key pair before sending a message called DHPart1.
The Diffie-Hellman public values are exchanged in the DHPart1 and DHPart2 messages.
Session Key Confirmation:
ZRTP requires to generate new Diffie-Helman key pairs for each session. Initiator and Responder generate SRTP keys. SRTP keys and salts are then calculated. Both parties confirm that have agreed on the same key which is done via confirmation messages.
Confirmation messages Confirm1 (F8), Confirm2 (F9) and Conf2ACK (F10) are exchanged between the initiator and the responder.
Secure Communication Session:
A secure communication session (SRTP begins) is established after the session confirmation. The two parties, the initiator and the responder, can now communicate securely.