The gritsforbreakfast blog post making the rounds on the Liberation Tech mailing list about security of Apple’s iMessaging service is gaining quite some attention. The post refers to a CNET article on how the iMessage service “stymied attempts by federal drug enforcement agents to eavesdrop” conversations due its end-to-end encryption and commends Apple for protecting the user’s privacy while pointing out that Gmail and Facebook Messaging don’t. However, I disagree on some points of the blog post and therefore want to discuss them here.
Before we get to the iMessage service I want to comment on the criticism on Gmail. It’s like comparing apples and oranges. iMessage is a proprietary technology and corresponding servers are in control of one company. In contrast Gmail is just a generic e-mail service. Well known encryption methods like PGP are freely available for content encryption of e-mails. Blaming Google for not securing network transmission is just questionable due to well-known technical limitations of “e-mail”.
Coming back to iMessage, I would like to start the discussion on storage encryption. One big issue, besides eavesdropping, is that devices get easily lost, stolen or even can be confiscated by law enforcement agencies. Apple iOS implements two mechanisms for local storage security. One is hardware supported data at rest encryption which is often misunderstood. Its main purpose is to allow for fast and reliable remote wipes of storage cleaning the encryption keys instead of overwriting all data. The encryption key is embedded in hardware and as soon you turn on your iDevice the whole storage is decrypted using this key – no matter how long/strong your unlock PIN is.
The other one is Data Protection[pdf] which is only activated when you set a PIN or password . It only secures your data while the device is locked (which also depends on the protection class developers choose).
It is an additional layer of encryption which uses a key derived from your PIN/PW and the hardware embedded key. Bruteforcing the PIN must be performed on the actual device due to the fact that the hardware encryption key can’t be extracted from the device. In addition, access frequency to the hardware key is artificially slowed down which obviously slows down the whole bruteforce process significantly. As a consequence it will take you up to 20 minutes for a 4 digits PIN on an iPhone4. For an alphanumeric password with a length of 6 it already takes up to 196 years for a successful attack. The downside of Data Protection is that particular Apps have to use it for data they store. On a stock iOS device only the Mail App and Keychain make use of DP. In addition only a couple of Apps in the AppStore implement DP.
Assuming your device has set a secure alphanumeric password which doesn’t allow bruteforcing it in a reasonable amount of time, there still is an easy way on getting the rest of your data (including your SMS and iMessages). iPhones older than the 4S model as well as the first generation iPad have a bootloader vulnerability which allows to boot unsigned firmware. Elcomsoft sells a password recovery tool to law enforcement agencies which makes use of this vulnerability. Meanwhile there is a publicly available bruteforce and recovery tool for 4 digits PINs as proof of concept. It’s achieved through booting the device with a custom RAM disk without touching the actual iPhone Operating System.
While there’re only rumors on Apple supporting law enforcement agencies in decryption of confiscated iDevices, Dmitry Sklyarov (former employee at Elcomsoft) confirmed during his last talk at TROOPERS , that Apple sings the Firmware of particular 3-Letter-Agencies. This enables them to run custom RAM disks not only on older vulnerable devices but on all iDevices available on the market as well as on those developed and manufactured in the future. DP is rarely used either due to usability reasons or – what I see as the more significant reason – because it’s just little known among developers. When you’re sure a particular App carrying your sensitive data uses DP, the security of data heavily relies on the quality of the password you set. So let’s look at iMessage security.
“Apple didn’t have to build iMessage with end-to-end encryption”
This is basic protection against eavesdropping in local area networks, on the way to Apple servers and to your communication partner. While there are no criticisms at that it should be pointed out that this is rudimentary protection, even when many consumer cloud services do not implement transmission encryption (sadly).
iMessage is a proprietary protocol. The service as well as the corresponding infrastructure is owned by Apple. It’s based on the APNS (Apple Push Notification Server). Having a look at Apple’s documentation gives an idea on how the transmission encryption is implemented and brings up the second point you should keep in mind when using iDevices with particular cloud services. As Mathew Green already pointed out in the original article, Apple might take advantage of its position as cloud service provider and decrypt the transmitted traffic as well as forward your messages to law enforcement agencies.
Last but not least you should be aware of the fact that your backups made with iCloud are stored on servers in the USA. Therefore Apple, like all the other cloud service providers, has to provide law enforcement agencies with a warranty of accessing all your data they store (including your Messages (-; ).
I still don’t see why the DEA complains about a service whose introduction is two years past and why they don’t use the same procedure like other agencies do, sometimes even without a warrant.
Remember, as soon as you are using a proprietary platform and its backend services, its owner is in control of all data you provide. Apple improved their security a lot during the last years. But that doesn’t matter too much. As soon as a 3-Letter-Agency knocks the door and calls for their warrant the service provider will deliver your data, simply because he has to. This is not about Apple being evil (or not), it’s about US law. Hopefully I could give you enough technical reasons to not have a false sense of security.
cheers
Sergej