Silent Phone FAQ’s
Frequently Asked Questions
Do both parties on a phone call (calling and receiving) need to be using the App for the conversation to be protected?
No. Extend the reach of private communication, even when you’re calling someone who is not using the Silent Phone App. Calls have enhanced security over conventional calls, since they’re routed through our secure servers before reaching the public switched telephone network. The leg of the call between your device and our servers will be encrypted, keeping you safe from local eavesdropping threats.
Yes. Unfortunately there is no way to secure your SMS text when the receiving party is unsecured and not using the App.
As VoIP grows into a replacement for the PSTN (public switched telephone network), we will absolutely need to protect it, or organized crime will be attacking it as intensively as they attack the rest of the Internet today. VoIP is far more vulnerable to interception than the PSTN. A PC on your office network can unknowingly host spyware that can intercept your corporate VoIP calls and store and organize them on a hard disk for convenient browsing by criminals half a world away, giving them trade secrets and insider trading opportunities. The Internet is not a safe medium to carry our phone calls. But Secure Phone solves these problems. This technology has social benefits. It has the power to change our lives, enabling us to have a private conversation any time we want with anyone, anywhere – without buying a plane ticket.
No. The Secure Phone application is not available under the GPL, the AGPL, or any other open source license. We are firm believers in publishing the source code for cryptographic software for peer review, to build public confidence that it contains no back doors. Publishing the source code for peer review is not the same as making it available under an open source license. Secure Phone has several major components, and not all of them are published under the same licensing terms. The entire body of source code for the complete Secure Phone client software is published for peer review purposes.
No. A good rule of thumb about how you can tell if there is no back door in a product: Do they publish their source code? We do. We publish the source code for Secure Phone. We also publish the source code for Silent Text, which also has no back doors. You can inspect it yourself, and build the executables from the source code yourself. We don’t feel comfortable trusting a crypto product if they don’t publish their source code. It’s easy to keep back doors out of your own product, as we do with Secure Phone.
It’s a fair question to ask in a post-9/11 world. Just how likely would it be for the government to restrict the end user’s use of secure VoIP? The question of whether strong cryptography should be restricted by the government was debated all through the 1990s. This debate had the participation of the White House, the NSA, the FBI, the courts, the Congress, the computer industry, civilian academia, and the press. This debate fully took into account the question of terrorists using strong crypto, and in fact that was one of the core issues of the debate. Nonetheless, society’s collective decision (over the FBI’s objections) was that on the whole, we would be better off with strong crypto, unencumbered with government back doors. The export controls were lifted and no domestic controls were imposed. This was a good decision, because we took the time and had such broad expert participation. The 9/11 attacks did not change the wisdom of that collective decision, and although civil liberties on the whole have eroded since then, we haven’t lost our right to use strong crypto. In the early 1990s, the government tried to control the end user’s use of crypto by introducing the Clipper chip. That didn’t go over too well politically, and had to be abandoned. The government will find it difficult to try again to stop end users from encrypting their traffic, regardless of whether that traffic is email, e-commerce web transactions, or VoIP calls. Further, the government would have to force everyone to abandon peer-to-peer communication protocols in favor of centralized, old Eastern-Bloc-style, panoptic ways of doing things. That’s not the direction technology has been heading. Rather than a “war on terrorism”, the government would have to conduct a war on technology. Does ZRTP slow down the VoIP call? No, not during the conversation. At the start of the call it takes a second or two to negotiate the cryptographic keys, but after that, it’s smooth sailing. The AES encryption is much faster than the speech compression that your VoIP client already performs. You won’t notice any additional delay.
ZRTP is a cryptographic key-agreement protocol to negotiate the keys for encryption between two end points in a Voice over Internet Protocol (VoIP) phone telephony call based on the Real-time Transport Protocol. It uses Diffie-Hellman key exchange and the Secure Real-Time Transport Protocol (SRTP) for encryption. ZRTP stands for “Zimmermann Real-time Transport Protocol.”
The ZRTP protocol has some nice cryptographic features lacking in many other approaches to VoIP encryption. Although it uses a public key algorithm, it avoids the complexity of a public key infrastructure. In fact, it does not use persistent public keys at all. It uses ephemeral Diffie-Hellman with hash commitment, and allows the detection of man-in-the-middle (MiTM) attacks by displaying a short authentication string for the users to verbally compare over the phone. It has perfect forward secrecy, meaning the keys are destroyed at the end of the call, which precludes retroactively compromising the call by future disclosures of key material. But even if the users are too lazy to bother with short authentication strings, we still get fairly decent authentication against a MiTM attack, based on a form of 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, giving it key continuity properties analogous to certificate authorities, All this is done without reliance on a PKI, key certification, trust models, or key management complexity that bedevils the email encryption world. It also does not rely on SIP signaling for the key management, and in fact does not rely on any servers at all. It performs its key agreements and key management in a purely peer-to-peer manner over the RTP packet stream. And it supports opportunistic encryption by auto-sensing if the other VoIP client supports ZRTP. ZRTP doesn’t need a PKI, and there are good reasons why it’s a mistake to require a PKI for secure VoIP. Plus, there have been a growing number of spectacular security failures of traditional PKIs. Nonetheless, ZRTP can use a PKI if you already have one up and running.
Only Secure Phone’s end users are involved in the key negotiation, and CALEA does not apply to end users. Our architecture likely renders that question moot. The Communications Assistance for Law Enforcement Act applies in the US to the PSTN phone companies and VoIP service providers, such as Vonage. CALEA imposes requirements on VoIP service providers to give law enforcement access to whatever they have at the service provider, which would be only encrypted voice packets. ZRTP does all its key management in a peer-to-peer manner, so the service provider does not have access to any of the keys. Only the end users are involved in the key negotiation, and CALEA does not apply to end users. Here is the operative language from CALEA itself: 47 U.S.C. 1002(b)(3): ENCRYPTION – A telecommunications carrier shall not be responsible for decrypting, or ensuring the government’s ability to decrypt, any communication encrypted by a subscriber or customer, unless the encryption was provided by the carrier and the carrier possesses the information necessary to decrypt the communication.
Two human beings verbally compare the Short Authentication String, drawing the human brain directly into the protocol. And this is a Good Thing. The Diffie-Hellman key exchange by itself does not provide protection against man-in-the-middle (MiTM) attacks. To authenticate the key exchange, ZRTP uses a Short Authentication String (SAS), which is essentially a cryptographic hash of the two Diffie-Hellman values. The SAS value is rendered to both ZRTP endpoints. To carry out authentication, this SAS value is read aloud to the communication partner over the voice connection. If the values on both ends do not match, it indicates the presence of a man-in-middle attack. If they do match, there is a high probability that no man-in-the-middle is present. The use of hash commitment in the DH exchange constrains the attacker to only one guess to generate the correct SAS in his attack, which means the SAS can be quite short. A 16-bit SAS, for example, provides the attacker only one chance out of 65536 of not being detected. ZRTP provides a second layer of authentication against a MiTM attack, based on a form of key continuity. It does this by caching some hashed shared key material to use in the next call, to be mixed in with the next call’s DH shared secret, giving it key continuity properties analogous to SSH. If the MiTM is not present in the first call, he is locked out of subsequent calls. Thus, even if the SAS is never used, most MiTM attacks are stopped, because they weren’t present in the first call. ZRTP’s key continuity features have some self-healing properties that are better than the SSH approach. ZRTP provides yet a third layer of protection against a MiTM attack. The IETF plans to add integrity protection to the delivery of SIP information, and that integrity protection will rely on a PKI. When this eventually deploys, ZRTP can take advantage of this. See RFC 6189 on how ZRTP can leverage an integrity-protected SIP layer to provide integrity protection for ZRTP’s Diffie-Hellman exchange in the media layer. This protects against a MiTM attack, without requiring the users to verbally compare the SAS. However, no VoIP clients yet offer a fully implemented SIP stack that provides end-to-end integrity protection for the delivery of SIP information. Thus, real-world implementations of ZRTP endpoints will continue to depend on SAS authentication for quite some time. Even after there is widespread availability of SIP products that offer integrity protection, many users will still be faced with the fact that the signaling path may be controlled by institutions that do not have the best interests of the end user in mind. In those cases, ZRTP’s built-in SAS authentication will remain the gold standard for the prudent user. That, plus the key continuity features.
Isn’t SRTP good enough? This is the wrong question to ask. Despite the similarity in the two names, it is not a choice between SRTP and ZRTP. SRTP is the protocol we use to encrypt the low level voice packets. But you cannot use SRTP until both parties have agreed on what key to use for the SRTP encryption. The SRTP protocol (RFC 3711) says nothing about how session keys are negotiated. That’s where ZRTP (RFC 6189) comes in. ZRTP is the protocol that the two parties use to negotiate the SRTP session key. Silent Phone uses SRTP, but it uses ZRTP first to negotiate the SRTP session key. There are several different protocols that may be used to negotiate SRTP session keys, including ZRTP, SDES, or DTLS. Of course, we think ZRTP is the best one.
Yes. ZRTP encrypts all RTP traffic, including Touch-Tone keypad DTMF tones. DTMF tones are carried in the RTP media stream using methods defined by RFC 2833, embedded as special RTP payload types. We encrypt these along with the rest of the RTP media stream, which is important because people use DTMF tones to enter their credit card numbers when they call their bank, for example.