Background
Say it with me folks, “Security is a system”. In case it is not obvious what that means, I will articulate. Security is made up of a collection of parts, and the system security of this collection is not based on the average security of those parts, or the sum security of these parts – it is based on the weakest security of those parts and how they are integrated. And – sometimes that weakness is not even a part, but a gap in the integration of those parts.
I know, in the abstract we have all heard it before. However we have a new example that highlights this principle.
Before we get into the example I want to share a few of Tom’s Rules of Security:
- Know your Threat – Security can only be understood / judged in the context of a given threat type. Good security against one class of threat may be worthless against another class of threat.
- Follow the Keys – Key management is about how and where the encryption / access control keys are kept. Whoever holds the keys controls the access. If it isn’t you, you don’t control access.
Note – These are not really my rules, just my personal versions of well known principles.
In the Spotlight: Apple iMessage
Recently there was a presentation in Kuala Lumpar (by pod2g) addressing the security of Apple iMessage. More specifically the presentation highlighted a few weaknesses that illustrate the two rules identified above, and went into great detail as to how it could be compromised. For our purposes, we need to first look at how iMessage works and then we will look at how it can fail – or at least be insecure.
From any given iMessage client a secure message can be sent to any other iMessage client. This message is based on public-private key encryption keys. With public-private encryption keys, every user has two keys – a private key (which is the secret key) and the public key (which can be shared with anybody). These are special keys in that any message encrypted with the public key can only be decrypted with the cooresponding private key, and conversely any message encrypted with a private key can only be decrypted with the corresponding public key. In the first case, it allows somebody to send a secure message to a given person without needing to exchange secret keys. In the second case – also known as digital signing, it identifies the source of the message since only the holder of that given private key could create that message. When these methods both used, a message can be sent from Ted to Alice (using their respective public keys) and:
- Ted knows Alice and only Alice can decrypt the message if it was encrypted with her public key.
- Alice knows that Ted and only Ted could have sent the message if it was signed with his private key.
To a certain degree, that is what Apple iMessage does. However, messages are not sent directly between Alice and Ted, they are sent through Apple services and retained under both of the AppleID accounts of the message participants. This alone is not a security exposure by itself, but as a user I would like the option to purge my historical data. It may be securely encrypted today, but who is to say how secure that may be in the future?
In any case, the next part of the story is that all the public keys used by iMessage are stored on Apple ESS servers and are delivered to iMessage clients automatically. Which puts Apple in a perfect position to compromise any encrypted iMessage with a Man in the Middle attack (MiTM). Specifically pages 75&77 (of the presentation) show that Apple has full control of the public key directory, public keys are retrieved by clients “as needed” (with a 30 minute cache window), and users have no visibility into the public keys being used. At any point Apple has the technical capability to insert themselves as the endpoint to a message and then recreate / encrypt the message and send to the intended recipient. Since the keys are exchanged in the background – the users will not be aware than it was not an end to end encryption.
Most of the other 88 pages in this presentation illustrates how iMessage works under the covers, and the challenges of a third party compromise. I will give you a clue – it would be very difficult for anybody who is not Apple to compromise iMessage, but technically very easy for Apple to do.
Bottom line
Apple controls the Keys :There is nothing to imply that Apple is spying on iMessages. However there are no technical limitations that would prevent them from doing so if they were so inclined or directed to, since indirectly they control the keys.
Know your threat: If the threat you concerned about is Joe Internet Hacker, iMessage is very secure, with a very low risk of interception/decryption. However if the threat you are concerned about has a National Security Letter in their pocket, iMessage probably does not provide much security.
Update [2013 Nov 5] : A very well written analysis of Lavabit at thoughtcrime.org shows that Lavabit had a similar approach to key management – and same weakness of co-mingling the keys with the “secured” accounts on the server.