ZRTP's Back-Door-Resistant Features
The ZRTP "Disclosure flag"
here
are no back doors defined in the ZRTP protocol specification. The designers of ZRTP would like to discourage back doors in ZRTP-enabled products. However, despite the lack of back doors in the actual ZRTP protocol, it must be recognized that a ZRTP implementor might still deliberately create a rogue ZRTP-enabled product that implements a back door outside the scope of the ZRTP protocol. For example, they could create a product that discloses the ZRTP session key out-of-band to a third party. They may even have a legitimate business reason to do this for some customers.
For example, some environments have a need to monitor or record calls, such as stock brokerage houses who want to discourage insider trading, or special high security environments with special needs to monitor their own phone calls. We've all experienced automated messages telling us that "This call may be monitored for quality assurance". A ZRTP endpoint in such an environment might unilaterally disclose the session key to someone monitoring the call. ZRTP-enabled products that perform such out-of-band disclosures of the session key can undermine public confidence in the ZRTP protocol, unless we do everything we can in the protocol to alert the other user that this is happening.
If one of the parties is using a product that is designed to disclose their session key, ZRTP requires them to confess this fact to the other party through a protocol message to the other party's ZRTP client, which can properly alert that user, perhaps by rendering it in a GUI. The disclosing party does this by sending a "Disclosure flag".
Note that the intention here is to have the Disclosure flag identify products that are designed to disclose their session keys, not to identify which particular calls are compromised on a call-by-call basis. This is an important legal distinction, because CALEA requires a VoIP service provider to not reveal which particular calls are wiretapped. But there is nothing illegal about revealing that a product is designed to be wiretap-friendly. The ZRTP protocol mandates that such a product "out" itself.
You might be using a ZRTP-enabled product with no back doors, but If your own GUI tells you the call is (mostly) secure, except that the other party is using a product that is designed in such a way that it may have disclosed the session key for monitoring purposes, you might ask him what brand of secure telephone he is using, and make a mental note not to purchase that brand yourself. If we create a protocol environment that requires such back-doored phones to confess their nature, word will spread quickly, and the "invisible hand" of the free market will act. The free market has effectively dealt with this in the past.
Of course, a ZRTP implementor can lie about his product having a back door, but the ZRTP standard mandates that ZRTP-compliant products MUST adhere to the requirement that a back door be confessed by sending the Dislosure flag to the other party. A purported implementation which violates this requirement can at the very least be accused of false advertising. But stronger incentives may be available. Perhaps in this case, intellectual property law can be harnessed for a noble purpose. Usage of the ZRTP-Compliant™ trademark and royalty-free licensing of any relevant ZRTP-related patents is contingent on compliance with the ZRTP standard, especially the proper and truthful use of the Disclosure flag. If an implementor wants to have a back door in his product, it's useful to put that implementor in a position where he has to ask his corporate legal counsel to help him choose between coming clean with the public or actively telling a lie and violating intellectual property law. The Disclosure flag, coupled with intellectual property law and market forces, together constitutes an anti-back-door feature of the ZRTP protocol.
There will be inevitable comparisons to Steve Bellovin's 2003 April fool's joke, when he submitted RFC 3514 which defined the "Evil bit" in the IPV4 header, for packets with "evil intent". But we submit that a similar idea can actually have some merit for securing VoIP. Sure, one can always imagine that some implementor will not be fazed by the rules and will lie, but they would have lied anyway even without the Disclosure flag. There are good reasons to believe that it will improve the overall percentage of implementations that at least tell us if they put a back door in their products, and may even get some of them to decide not to put in a back door at all. From a civic hygiene perspective, we are better off with having the Disclosure flag in the protocol.
Guidelines on Proper Implementation of the Disclosure Flag
Some implementers have asked for guidance on implementing the Disclosure Flag. Some people have incorrectly thought that a connection secured with ZRTP cannot be used in a call center, with voluntary voice recording, or even with a voicemail system. Similarly, some potential users of ZRTP have overconsidered the protection that ZRTP can give them. These guidelines clarify both concerns.
The ZRTP Disclosure Flag only governs the ZRTP/SRTP stream itself. It does not govern the underlying RTP media stream, nor the actual media itself. Consequently, a PBX that uses ZRTP may provide conference calls, call monitoring, call recording, voicemail, or other PBX features and still say that it does not disclose the ZRTP key material. A video system may provide DVR features and still say that it does not disclose the ZRTP key material. The ZRTP Disclosure Flag, when not set, means only that the ZRTP cryptographic key material stays within the bounds of the ZRTP subsystem.
If an application has a need to disclose the ZRTP cryptographic key material, the easiest way to comply with the protocol is to set the flag to the proper value. The next easiest way is to overestimate disclosure. For example, a call center that commonly records calls might choose to set the disclosure flag even though all recording is an analog recording of a call (and thus outside the ZRTP scope) because it sets an expectation with clients that their calls might be recorded.
Note also that the ZRTP Disclosure Flag does not require an implementation to preclude hacking or malware. Malware that leaks ZRTP cryptographic key material does not create a liability for the implementor from non-compliance with the ZRTP specification.
A user of ZRTP should note that ZRTP is not a panacea against unauthorized recording. ZRTP does not and cannot protect against an untrustworthy partner who holds a microphone up to the speaker. It does not protect against someone else being in the room. It does not protect against analog wiretaps in the phone or in the room. It does not mean your partner has not been hacked with spyware. It does not mean that the software has no flaws. It means that the ZRTP subsystem is not knowingly leaking ZRTP cryptographic key material.