Cue web of trust PSA.
Blockchain based key distribution may let you anchor trust to a decentralized process.
--------------------
A Blockchain makes a good backed for a web of trust because it lets us use the above to link an identifier with a public key and server. One of the primary scaling issues with a web of trust based authentication is that names get long fast: PersonA.PersonB.PersonC.Otherguy. A blockchain allows for a universal naming scheme and a central place to store high confidence links that is faster then querying the peers I trust and asking if they have a link to an arbitrary node.
I have issues with their implementation, but in general the message is right.
If they were doing this, it would come out real quick. You'd just send a message to a different account you control then see how many keys you're getting/encrypted messages you're sending. Someone like Applebaum, who knows he's under surveillance and has the crypto/networking chops to dig into it, could verify it quite quickly.
Any crypto system whose security is predicated on a trusted server might as well be compromised. It's way too easy for servers to be subverted, either technologically or (il)legally.
It's not a good system, but it's also not one that is impervious to detection of malicious activity.
In his comment, he says: "OS X 10.9 (and probably also iOS 7) does certificate pinning for the push connection, I don't know about the directory lookup."
[1] http://blog.cryptographyengineering.com/2013/06/can-apple-re...
[2] https://github.com/meeee/pushproxy/blob/master/doc/apple-pus...
If you're spoofing the keyserver, it's invisible to Apple. If you're the FBI and serving a warrant on Apple, Apple does not send the message telling you that "FBI's MacBook Pro has logged in to your iCloud Account."
It's a simple matter of redirecting traffic using something like iptables.
Think of an SSH client that never verifies host keys and never warns you when they change. That's basically what iMessage is.
At least with iMessage, the entire ecosystem is managed by one company, so you only have to trust one company.
It does eliminate the requirement to trust Apple actually. That's the point of (real) end to end encryption. With a custom client, you could use them as a conduit to deliver your message without using any Apple software on either client if you wanted to. As long as the users can verify the keys.
> At least with iMessage, the entire ecosystem is managed by one company, so you only have to trust one company.
I just explained at least 3 different reasons why that is not true. You can fully "trust" Apple and still compromise an iMessage conversation.
> It does eliminate the requirement to trust Apple actually.
As the parent comment indicated (emphasis added), in an extreme hypothetical scenario, Apple could (be compelled to) write a backdoor specifically for your device that captures all text and touch input events, or periodically takes screenshots and sends them somewhere.
This is like sending a PGP message over gmail using mutt on linux via IMAP. Google owns gmail, but they can't backdoor you or read your message in this scenario. Any non-broken secure messaging protocol should have this property, regardless of if people use it that way. This is what end-to-end encryption means.
Okay then, tell me how you could build a system that
* Guarantees secure transmission of public keys
* Can be installed safely on a closed-source operating system
* Is impervious to the whims of the hardware vendor or the operating system vendor
* Is sufficiently straightforward that mums everywhere will happily use it
* Doesn't require users to become security experts
Given the practical realities Apple has to contend with, I think they've done a pretty good job -- certainly a lot better than what anyone could have expected, arguably a lot better than anything comparable that has come before it.
This discussion about backdooring applications isn't even interesting or relevant here. The protocol itself is not secure.
Sure they could. They could change the protocol and UI so that the users could verify and pin keys, and they could publish the iMessage source[1] to allow people to check it and compile it themselves.
Whether they should be expected to do these things is a different issue, but they could.
[1] not necessarily under a liberal license - for example, PGP was proprietary but allowed people to download its sources
Apple cannot prove they aren't reading your iMessages.
Sure they could. They could change the protocol and UI so that the users could verify and pin keys, and they could publish the iMessage source[1] to allow people to check it and compile it themselves.
None of which is to say that Apple should have to prove any of this. If you cannot trust your phone vendor, then you cannot use any function of that phone, be it purportedly-secure messaging or location services or even the web browser.
Sending device grabs all of the recipients public keys (as well as all of their own keys for other devices, which allows the conversation to be replicated on all of their own devices as well) hosted by Apple. Sending device has no way to verify those keys belong to the intended recipient. User has no way to verify which, or how many devices they are sending to. User doesn't even know if the recipient is mysteriously using a different key that has never been seen before. Sending device does not display any information about how many keys it grabs.
Apple wants to read your messages? They drop one of their public keys in the list. Apple gets a warrant? They drop the FBI's key in the list. You'll never know that you're CCing the FBI device keys on all of your messages.
What's more, is these keys are provided by Apple over TLS without certificate pinning. So now anyone who can mint certificates from a CA trusted by the device can just assume Apple's position. You don't need to hack or legally compel Apple in order to eavesdrop.
If your iDevice is managed by your company IT department, it can be silently fed a certificate without compromising a CA.[1]
Finally, if you did not apply the goto fail update a few days ago, it's trivial to break that TLS channel and also "misconfigure" those keys. That hole has been there since September 19, 2012, by the way.
Basically, iMessage has been securing you against someone who knows how to run wireshark or tcpdump, but not much else.
[1] http://blog.quarkslab.com/imessage-privacy.html