Following the revelation of government data gathering program PRISM in June, Apple released a statement on customer privacy that suggested the company was unable to access or decrypt iMessage and FaceTime conversations.
According to researchers who presented at the Hack the Box conference in Kuala Lumpur (via Macworld), it is actually possible for someone inside Apple to intercept messages because the company has access to public iMessage keys.
The company's claim that iMessage is protected by unbreakable encryption is "just basically lies," said Cyril Cattiaux, who has developed iOS jailbreak software and works for Quarkslab, a penetration testing and reverse engineering company in Paris.
The researchers emphasized they have no indication that Apple or the government is reading iMessages, only that it would be possible to do so.
To encrypt iMessages, Apple utilizes public key cryptography, which means that every Apple device is assigned both a private key and a public key. When an iMessage is sent, it requests the public key of the recipient's device to encrypt the message, which is then decrypted by a private key upon receipt.
Because Apple manages public keys and does not divulge them to users, it is not possible to verify that a sent iMessage is going to the intended recipient. Apple could, for example, substitute or add a public key to intercept an outgoing message without the sender being aware of the change, as end users do not have access to public keys.
With a public server, such as MIT’s PGP Public Key Server, the sender can at least see more information, such as whether a key has changed. At that point, the sender can decide whether they want to trust it or not if they suspect a man in the middle attack. Apple’s key server is not public, the researchers say.
"The biggest problem here is you just cannot control that the public key you are using when you are ciphering the message is really the key of your recipient and not, for example, the public key of some guy in Apple," Cattiaux said.
According to the researchers, there would be no way for an end user to detect an intercepted or rerouted message from their iOS device, as it is impossible to see whether or not a key has been switched or where a message has been routed. The solution to the issue, to introduce true end-to-end encryption, would require Apple to store public keys on each iOS device to allow users to compare keys to verify that messages are going to the intended recipient.
Earlier this year, a Drug Enforcement Agency document noted that it was impossible for law enforcement agencies to eavesdrop directly on iMessage conversations due to Apple's encryption, but it appears that Apple itself could potentially intercept those messages using public keys.
Update: Apple spokeswoman Trudy Muller said in a statement to AllThingsD that "iMessage is not architected to allow Apple to read messages," adding that "The research discussed theoretical vulnerabilities that would require Apple to re-engineer the iMessage system to exploit it, and Apple has no plans or intentions to do so."
Top Rated Comments
If Apple wanted to, or intended to, read your iMessages, why wouldn't they design a protocol that specifically allows for this in the first place?
Finding flaws in a protocol which was obviously designed to be secure and then pointing the finger and saying "See? It's all on purpose" is just crazy.
But the masses will disregard the line right at the top of this article:
I certainly trust iMessage way, way more than I trust, for example, Skype, or even plain old SMS.
A much bigger problem is that iCloud backups are not stored encrypted. If you backup your messages to iCloud, Apple has no need to go to the trouble of intercepting your messages in transit.
Because they probably know more about iOS security than you.
(at a high level, various optimizations exist to avoid overhead after initial key exchange, etc)...
Bob wants to send an message to Sue.
Bob generates a private key and stores securely on his device.
Bob derives a public key from his private key.
Bob gives his public key to Apple stating he wants to message Sue.
Apple informs Sue of an message request and is handed Bob's public key.
Sue generates a private key and stores it securely on her device.
Sue derives a public key from her private key.
Sue gives her public key to Apple.
Apple informs Bob of Sue's public key.
Bob encrypts his message to Sue using Sue's public key.
Bob gives his encrypted message to Apple asking for it to be delivered to Sue.
Apple informs Sue of Bob's message.
Sue decrypts the message from Bob using her private key.
Under this model only Bob and Sue have their private keys and hence only they can decrypt messages originating from their devices
...HOWEVER, since Apple is the mediator of the public keys between Bob and Sue Apple could give Bob a public key of their own claiming it was from Sue. This would then allow Apple to decrypt messages from Bob heading to Sue. Apple can do the same thing with Sue. Then Apple would be able to get messages from Bob, decrypt them, look at the message, then re-encrypt it before passing it along to Sue. The man in the middle model...
Bob wants to send an message to Sue.
Bob generates a private key and stores securely on his device.
Bob derives a public key from his private key.
Bob gives his public key to Apple stating he wants to message Sue.
Apple generates a private key and a FakeBob public key of their own.
Apple informs Sue of an message request and is handed FakeBob's public key.
Sue generates a private key and stores it securely on her device.
Sue derives a public key from her private key.
Sue gives her public key to Apple.
Apple generates a private key and a FakeSue public key of their own.
Apple informs Bob of FakeSue's public key.
Bob encrypts his message to Sue using FakeSue's public key.
Bob gives his encrypted message to Apple asking for it to be delivered to Sue.
Apple decrypts message, looks at it, and then re-encrypts message using Sue's public key.
Apple informs Sue of Bob's message.
Sue decrypts the message from Bob using her private key.
Personally I trust Apple to NOT do this and favor the simplicity of their method despite a man in the middle weakness internally in their system. They could prevent this but at the cost of trust being established between Bob and Sue in a more complex and cumbersome way... not ideal for typical users of iMessage.
...personally not sure how this is news or a surprise, with the intentional simplicity and ease of use of the iMessage solution you have to assume Apple will be a good actor on your behalf...
Put the tin foil hat back down. :D