Last week, the U. With the encryption key in hand, authorities could listen to conversations made over VOIP calls. For now, Zfone can only be used with software VOIP clients, like those used on computers, but developers can license it to integrate it into their hardware.
Customers of service providers like Vonage Holdings, for example, who use adapters that allow the use of existing analog telephones, won't be able to use Zfone because the software isn't yet built into the adapter hardware. The U. Nancy is a freelance journalist who started writing about mobile phones just in time to cover the transition to digital. Here are the latest Insider stories.
More Insider Sign Out. The question of whether strong cryptography should be restricted by the government was debated all through the 's. 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 law enforcement community will be understandably concerned about the effects encrypted VoIP will have on their ability to perform lawful intercepts. But what will be the overall effects on the criminal justice system if we fail to encrypt VoIP?
Historically, law enforcement has benefited from a strong asymmetry in the feasibility of government or criminals wiretapping the PSTN. As we migrate to VoIP, that asymmetry collapses. VoIP interception is so easy , organized crime will be able to wiretap prosecutors and judges, revealing details of ongoing investigations, names of witnesses and informants, and conversations with their wives about what time to pick up their kids at school.
The law enforcement community will come to recognize that VoIP encryption actually serves their vital interests. In the early s, 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. A: Yes. There are major problems and complexities with building, maintaining, and relying on PKI. That's why in the s, a number of companies died trying to build and market PKI technology.
PGP became the dominant email encryption standard because it did not depend on a centrally managed PKI. Plus, there have been a growing number of spectacular security failures of traditional PKIs , notably, the Comodo and DigiNotar debacles , and the stolen certificate-signing keys that enabled the Stuxnet worm attack.
Organizations that feel comfortable with PKIs can still get what they want. Which thus confers protection against a man-in-the-middle MiTM attack, without requiring the users to verbally compare the SAS.
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 bit SAS, for example, provides the attacker only one chance out of of not being detected. 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.
When this eventually deploys, ZRTP can take advantage of this. 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. That, plus the key continuity features. A client-server protocol like TLS can work well in a client-server environment, but a phone call between two human beings is an ad-hoc peer-to-peer relationship, and the cryptographic key negotiations should reflect that.
All these cryptographic protocols have a goal of negotiating keys in a way that stops man-in-the-middle MiTM attacks. Human beings can readily see if there is a MiTM by direct evidence and common sense. ZRTP harnesses the immense resources at both endpoints, which each have a brain with a hundred trillion synapses and the unique power of human intuition. How does the callee know that this phone number is actually originating from example.
Many years of experience in the crypto industry leads us to believe that PKI is an inappropriate approach to achieving media security in VoIP. But a self-signed certificate offers no protection against a MiTM attack. If they don't use a PKI, and have no other MiTM attack countermeasure, such as key continuity or a short authentication string, it just won't be a secure phone. Although far less important than the aforementioned pachyderm, here's another strike against this protocol: DTLS-SRTP must bear the additional cost of a signature calculation of its own, in addition to the signature calculation the SIP layer uses to achieve its integrity protection.
This may be relevant in low-power mobile platforms, or in highly loaded servers. Isn't SRTP good enough? A: This is the wrong question to ask. SRTP is the protocol we use to encrypt the low level voice packets. Of course, we think ZRTP is the best one. But wait. When you say you are already using SRTP, what do you mean, exactly? Which brings us to the next question. Is that safe?
A: Good heavens, no! Here's how it works. Suppose Alice wants to talk to Bob, who lives in China. Alice's phone generates a random session key to encrypt the conversation, but somehow Alice has to get this key into Bob's hands so they can both use it. Her phone company, who now has full knowledge of this session key, transmits it to Bob's phone company in China.
Bob's phone company, owned by the Chinese government who now has full knowledge of the session key, transmits it to Bob's phone. Now Alice and Bob's phones are ready to start an encrypted voice conversation. What's wrong with this picture? If Alice wants to talk with Bob about human rights issues, or how they might overcome trade barriers, the Chinese government can easily monitor the call.
To stay competitive in a global economy, it's important that a company use end-to-end encryption to protect its business communications from foreign governments. And some of us have doubts about whether our domestic phone company will always act with our best interests in mind. If PGP Corp had implemented such an embarrassingly bad protocol, it would be met with shocked disbelief in the crypto community. But VoIP product vendors seem to get away with it, probably because crypto is not part of the VoIP industry's core competency.
I've talked to VoIP vendors who just shrug and candidly admit they implemented SDES so they can simply check the "supports encryption" checkbox on their product feature checklist. Their excuse is that their customers have not demanded anything better. A: Well, you can, but it would be a bad idea in most cases.
IPsec encryption is done down in the IP layer of the Internet protocol suite's protocol stack, which is too low a layer to let the user know if it is running. Some routers support IPsec, and some don't. You don't know if the other party supports IPsec, so some connections will be not encrypted, and you would never know it. If you don't know for sure whether the call is encrypted, what good is it?
It's better to do the encryption at the application layer, so that the user can be told if the call is encrypted. Q: I'm a VoIP developer.
The software is implemented in C. Zfone is ready to run for end users, not just VoIP developers. Zfone is not itself a VoIP client-- it is an "adapter" that lets you make secure phone calls using your favorite VoIP client. If you just want to make secure VoIP phone calls as an end user, get Zfone. A: No. The SDK is also available under a commercial license, in a dual-licensing model. See our Licensing Policy page for details.
I'm a firm believer in publishing the source code for cryptographic software for peer review, to build public confidence that it contains no back doors , a tradition I started in with PGP. PGP is a proprietary product, even though the source code is available for peer review.
Publishing the source code for peer review is not the same as making it availble under an open source license. Zfone 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 Zfone client software is published for peer review purposes. However, the rest of the Zfone application remains proprietary. A: Yes, but don't worry-- we offer a royalty-free patent license to anyone who doesn't sue us.
I think software patents stifle innovation and have done a great deal of harm to the software industry, especially in the crypto world. I don't ever want to experience this problem again, so our patent is purely defensive. Having the patent also allows us to better serve the user community's interests by providing leverage to get other ZRTP implementors to abide by ZRTP's back-door-resistant features.
A: Yes, we do. Elliptic curve algorithms are the next generation of public key cryptography, offering a level of security that better matches the full key strength of AES Q: Does Zfone work with Skype? Skype uses a closed proprietary protocol, which they do not publish. That makes it difficult to design Zfone to work with it. Skype intentionally does not interoperate with the rest of the VoIP industry, which is built on open standards.
I decided to follow the industry standards. There is one other problem with Skype. It uses a Variable-Bit Rate codec, which introduces significant vulnerabilities, regardless of the quality of encryption.
A: Nope. VoIP is the wave of the future, so I'm not motivated to try to retrofit this to work with the old public switched telephone network. A famous hockey player said "I try to skate to where I think the puck will be. It just depends your VoIP service. What kind of VoIP service do you have? If the latter, then yes, you can make such a call.
But the call will not be secure. The whole point of Zfone is to make secure calls. Will Zfone work with that? A: Well, not with that exact setup, no. To make a secure call with that kind of setup, you would have to have an ATA with the ZRTP protocol integrated inside, which will happen someday, we hope. You can use the software VoIP client to connect to your VoIP service provider from your computer, not from a normal telephone.
What about IAX? Most conference calls are connected via a conference call mixer or a PBX , connected in a star topology.
Think of the conference call mixer as the hub of a spoked wheel, with each spoke connected to a party in the conference call. Each spoke is a separate ZRTP connection, with its own separate session key. The conference call mixer acts as a trusted man-in-the-middle MiTM between ZRTP-equipped phones, and performs the audio mixing for the conference call.
ZRTP is independent of the signaling layer, because it does all its key negotiations in the media stream. Zfone will encrypt audio and video for Apple iChat calls on Mac OS X Leopard , but not file transfers, text chat, or remote desktop control.
It does not work with Skype. Our SDK is written in C. We don't have a Java version at this time. Zfone is a new secure VoIP phone software product which lets you make secure encrypted phone calls over the Internet. It lets you whisper in someone's ear from a thousand miles away. The Zfone software detects when the call starts, and initiates a cryptographic key agreement between the two parties, and then proceeds to encrypt and decrypt the voice packets on the fly.
It has its own little separate GUI, telling the user if the call is secure. Think of it as a software bump-on-the-wire, or a bump in the protocol stack. Although it uses a public key algorithm, it avoids the complexity of a public key infrastructure PKI. In fact, it does not use persistent public keys at all.
0コメント