It's generally known email and IM communication can be encrypted when privacy and security are highly necessary. But what about voice? That time when you need to call someone and discuss a sensitive matter. How can you make sure your phone isn't tapped? 10-15 years ago, you would've probably been left with your guard down. Today, not anymore, thanks to ZRTP encryption for voice.What is ZRTP encryption for voice?
ZRTP, short from 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.
In other words, ZRTP provides end-to-end encryption for VoIP calls. Not cellular calls or other types of telephony, only Voice over IP. Remember this important detail.
The protocol was developed by Phil Zimmermann (who also created PGP), with help from Bryce Wilcox-O'Hearn, Colin Plumb, Jon Callas, and Alan Johnston.
It uses Diffie-Hellman (DH) key exchange and the Secure Real-time Transport Protocol (SRTP) for encryption.
In brief, how does ZRTP VoIP encryption work?
The key agreement algorithm can be divided into 4 steps:
- Hash commitment
- Diffie-Hellman exchange and key derivation
In the discovery phase, the initiator and the responder exchange their ZRTP identifiers, as well as information about each other’s supported ZRTP versions, hash functions, ciphers, authorization tag lengths, key agreement types, and SAS algorithms.
The messages exchanged in the first phase are called Hello messages. An acknowledgment, called HelloACK message, is sent upon receipt of a Hello message.
After compatibility is checked, the initiator chooses which hash function, cipher, authorization tag length, key agreement type, and SAS algorithm should be used, basing his choice on the information brought in the Hello messages. This is sent to the responder via a message called Commit.
The initiator needs to generate his ephemeral key pair before sending the Commit, and the responder generates his key pair before sending a message called DHPart1. The Diffie-Hellman public values are exchanged in the DHPart1 and DHPart2 messages. ZRTP requires to generate new Diffie-Helman key pairs for each session.
SRTP cryptographic keys and salts are then calculated.
Finally, the confirmation phase takes place via Confirm1 and Confirm2 messages. They contain the cache expiration interval for the newly generated retained shared secret.
Defense from man-in-the-middle attacks
Although ZRTP uses a public-key algorithm, it doesn't require public-key infrastructure (PKI). It doesn't use persistent public keys at all. Instead, the protocol employs ephemeral Diffie-Hellman with hash commitment and allows the detection of man-in-the-middle (MiTM) attacks by displaying a short authentication string (SAS) that users verbally compare over the phone.
It's important to note that ephemeral Diffie-Hellman differs from static Diffie-Hellman. With the latter, key exchanges always use the same DH private keys. Thus, each time the same users perform a DH key exchange, they end up with the same shared secret. On the contrary, ephemeral Diffie-Hellman means that a temporary DH key is generated for every connection, so no key is ever used twice.
Furthermore, this enables forward secrecy, also known as perfect forward secrecy. It means that even if a key gets leaked, past communication is still secure because it was protected by different keys.
Even if users don't want to bother with short authentication strings, ZRTP still offers protection from MiTM due to key continuity. It does this by caching some key material to use in the next call, to be mixed in with the next call’s DH shared secret. This provides key continuity properties similar to certificate authorities.
Some people might find it hard to wrap their heads around it, but it's not that complicated. Like I said, all this is done without reliance on a PKI, key certification, trust models, or key management complexity.
Moreover, ZRTP also doesn't rely on the Session Initiation Protocol (SIP) for key management. As a matter of fact, it doesn't rely on any servers at all. It performs its key agreements and key management purely peer-to-peer over the RTP packet stream. It also supports opportunistic encryption by auto-sensing if the other VoIP client supports ZRTP.
Tested and proven
In case you're wondering if anyone has ever put ZRTP to tough test, the answer is, of course, yes.
If you're looking for more proof, as well as more detailed information about ZRTP, you might want to check out The ZRTP Protocol - Analysis on the Diffie-Hellman Mode by Riccardo Bresciani from Dublin's Trinity College. Fast forward, here's his conclusion:
"The analysis performed on the protocol has formally proven that ZRTP is a safe key agreement protocol: two endpoints that use it to agree on a key can be sure that their communications are secured against any attack.
For this to happen it is crucial that there are some pre-shared secrets: if this is not the case, ProVerif shows that a Man-in-the-Middle attack is possible.
This is the reason why one needs to use SAS to ensure that this attack has not been performed on the first session between the two agents: in this session a reliable shared secret will be created, and therefore all the subsequent sessions will be secured".
ZRTP encryption for voice as easy as it can be
Finally, you should consider that theory is best learned with practice. This is why I suggest that you download the 7-day free trial of our flagship Secure Voice app for Android that offers ZRTP encryption for voice out of the box. Try it out, see how ZRTP works from first hand, and you'll feel much more comfortable with protecting your private communication through the best tools and knowledge.
The key features of Secure Voice include:
- End-to-end encrypted VoIP calls over 2G, 3G, 4G, or Wi-Fi
- End-to-end encrypted conference calls
- Sophisticated compression technology to deliver the highest voice and video streaming quality
- Flexible contact management
- Compatibility with other ZRTP-protected VoIP apps