> Compare this to Apple's iMessage or FaceTime - Apple
> cannot decrypt the contents of the messages, and
> therefore cannot give the contents to the government.
This is not correct.First, when you buy a new iPhone, the way you authenticate yourself is by entering your Apple ID and password. Once entered, your new device will begin receiving iMessage data. This means that Apple is capable of provisioning a virtual device with your credentials, which will receive your messages. From there, they can be either stored or forwarded to third parties. Second, your iPhone runs binaries distributed by Apple. There is no technical reason why these binaries could not contain code to forward historical messages to Apple or to a third party. Even if they don't now, a future update to iOS (which you won't be able to audit) could introduce such code. The only way to have private communication is for all parties to run open-source clients. Each party must have the technical skill to audit the source code, or there must be at least one (preferably multiple) trusted third-party auditor. They must distribute encryption keys through a separate channel which does not depend on the communication host. In other words, the standard Thunderbird+GPG+keyparty system that is popular among nerds but has seen no uptake among the general population. |
Wrong. As others who have examined the protocol have noted, your password is used to unlock a keybag on the device itself. Apple doesn't have your password (only a secure hash) and therefore can't unlock the keybag. The security depends on the strength of your password, which is a weakness, but it is in your control, not Apples.
Yes, the binaries of any system can contain arbitrary spyware or be infected with such at any stage from development through to decommissioning. Open source is no absolute protection against that.
At the moment we are trusting that companies are not baldly lying to us, even Google.