> From what I can tell, the iMessage app gives the sender no indication of how many keys have been associated with a given iMessage recipient, nor does it warn them if the recipient suddenly develops new keys.
iMessage does warn you on all devices when a new device gets added to the account. Of course that's during normal operations. Unless somebody reverse-engineers one of the apps, we can't know whether the protocol has a provision for "please add this key but don't warn the user".
That's the thing with crypto in closed source software: it's completely useless because you have to trust the software vendor not to put any backdoors in.
And since two weeks, unfortunately, the only think we can trust is that the vendor actually DID add a backdoor.
I just wanted to highlight the fact that devices DO inform the user when a new key gets added. So if the directory didn't serve fake public keys and if the devices didn't have code to not warn if certain keys were added, then you would have the guarantee to only talk to me.
Sure: I could add more devices, but I have the full control over them, so it doesn't matter to you how many devices your client encrypts the message for because I have the full control over what devices I authorize or not.
That of course would be the perfect world, when in fact, Appke probably adds surveillance keys to the directory server and doesn't warn the user as such keys are added.
Don't use iMessages for anything you would not want Apple or the NSA or any other law enforcement agency to read.
But then again, don't use any of email (envelope in the clear), SMS (your carrier can read it), any other IM service (same issue as iMessage), snail mail (can be read by the post office and anybody opening your letter box when you aren't there).
This is totally false. When you are sending iMessages to someone, you get no UI indication at all when they buy new devices and add them to their Apple ID.
You are confusing it with adding devices to your own account.
We're talking about RECIPIENT keys.
The data's available to them from Apple, though there is no UI for it.
Nobody iMessaging me gets an alert when I buy a new iPad - only my other devices.
BUT: If I can be sure that only my devices can decrypt data sent to them and you know that my account will only announce keys to devices I actually own, then you don't need a notification when I add a new device because however many devices I have, only I will be able to read your messages.
Of course because we can't trust apple to not silently add more keys to an account, all of this is moot anyways.
What about THEIR privacy? End-to-end encryption to device-specific keys means that they have no idea which devices THEIR messages to you are being encrypted to.
Apple could have just gone "fuck it, let's store it in plaintext, since it's never going to be good enough anyway", but adding strong, transparent encryption to one of the most-used messaging services in existence right now is a very good thing, in my book.
Sure, the transparency introduces some flaws, but Apple has protected itself by a whole slew of passive attacks, which, to my knowledge, is the kind of attack that the mass surveillance state uses, and what a large messaging service is most at risk of.
Getting a warrant and saying "hey, we have a warrant for X, can we look at their communications", and then having Apple MITM that person is much, much more preferable to me than having a government say "we need all your data" and then the provider just handing the data over, since it's all in plaintext.
As it stands, Apple has pretty much disabled large-scale surveillance of iMessage accounts, which is what PRISM and all the furore is about, and people still shit on them?
Can we have some perspective please? If we lambaste any provider who takes steps to safeguard our privacy (again, at no benefit to them, since most people who use iMessage don't even know what encryption is), then what do you think the next service to have the choice in a product will say? "Hmm, I could either store everything in plaintext and have governments strong-arm me into sharing it with them (which I couldn't really care less about), I could build really strong encryption into it and make it an unusable mess for no added benefit to me, or I could build as much encryption into it as doesn't impact usability, again for no benefit to me, and get shat on for not providing option #2. Gee, how can I ever decide?"
If you want strong privacy/security, use Silent Circle (disclosure I work for them etc). If you care about your day-to-day privacy and want to talk to people you know, you could do much worse than iMessage.
That's the point of the article: the messages stored on iCloud aren't encrypted. The claim that iMessage uses end-to-end encryption is worthless.
A co-worker and I send encrypted e-mails back and forth occasionally. If he decrypts my attachments and saves them to his hard drive to work with, that doesn't mean that e-mailing them in an encrypted form was worthless.
If you read the article, you'll note that the author was successful with an attack that demonstrates that Apple can access the plain text of at least recently-delivered messages (and possibly all of the backed up messages).
Apple did a great thing by making iMessage secure by default. They should do a similarly great thing by making iCloud backups secure or by making it very obvious to the user that they are not secure (and what that means for your other "secure" data).
This seems likely given they offer to store your key for FileVault under some secret answers. I think this delivers the same level of "secure" in the sense that, provided they don't store the passwords you submit (possible law enforcement request), then they shouldn't be able to decrypt your iCloud backups either.
Apple can still get at them because they can reset your password on you. Certain files in the backup will not be accessible to them if they were encrypted with a key that wraps the Device UID. iMessages don't seem to be one of these files, but Mail backups are clearly inaccessible.
i think the most important takeaway here is that the reactionary press release "Apple’s Commitment to Customer Privacy" was very carefully worded to give the customer a sense of security. it's definitely not telling the full story, but it serves its purpose of reassuring a concerned user base.
Also.. it's important to note that the iMessage client only retains about a day's worth of messages on the device. Earlier messages can be obtained via a "load earlier messages" button. This means that Apple does store the message history on the iMessage servers, and there is a way for the client to retrieve them in batches while the contents are not accessible to Apple.
It seems extremely likely that this 'iCloud Backup' vulnerability is a red herring. The messages are not stored in the regular backup but are fetched encrypted by the client when you sign in.
Therefore, my iMessage history is secure (I fully understand that my message recipients may expose my individual messages, but my copy is safe).
Tools exist to read the database from the phone directly, from backups, etc. Which is great when you accidentally delete them... I wouldn't know that though. :)
"For example, conversations which take place over iMessage and FaceTime are protected by end-to-end encryption so no one but the sender and receiver can see or read them. Apple cannot decrypt that data. "
The author did demonstrate that recently-delivered messages may be accessed without device-specific or user-specific secrets in place. So, even if all the transports on all the hops between all the machines in the message delivery chain are encrypted, Apple is able to access the plain text of at least the recently-sent messages.
However, this is really far into the weeds on a topic that doesn't matter so much, as none of it really relates to Apple's claims about iMessages.
But how much security can you guarrantee with closed source anyway?
Which is actually, as far as we know, true for Skype too. The reason is both systems acquired a reputation (one that Apple's PRISM press release courted) that they were three letter agency proof(at least for most TLA's).
That reputation, we now know, at least for Skype was erroneous long before Microsoft bought them and might be for Apple. Yes, Apple deserves major props for deploying end to end crypto , but IChat security reputation is inaccurate.
It's an interesting meta-question about why Apple's claim was taken at face value. Not just by the public but by Apple's many scoffing critics? The Mat Honan incident should have been a clear sign that Apple's security mindset had a gaping hole:
> Apple tech support confirmed to me twice over the weekend that all you need to access someone's AppleID is the associated email address, a credit card number, the billing address, and the last four digits of a credit card on file. I was very clear about this. During my second tech support call to AppleCare, the representative confirmed this to me. "That's really all you have to have to verify something with us," he said.
That's a pretty grievous oversight. Why should Apple get the benefit of the doubt that they've solved the holy grail of security...that is, having lockbox security without impact to user convenience? In the above-cited case of AppleID access, they hadn't overcome that tradeoff and appear to have erred on the side of user convenience, at the cost of security.
Also, for what its worth, at least one of the IMessage handshake headers mentions Fairplay. Which makes me suspect the system was done by Apple's DRM team. Given that DRM is typically an exercise in obfuscation more than actual crypto, this does not bode well.
I'm much more worried about that happening than an evil-Apple scenario. I doubt many people have strong AppleID passwords, or particularly unique ones either. Heck, I know people that share accounts to avoid paying for apps.
There's even pre-built forensic ramdisks if you'd like to have a play around — https://code.google.com/p/iphone-dataprotection/
I'm willing to bet that there's at least one private bootrom exploit, one of the jailbreak developers has hinted that he has found one.
It's also pretty much considered the most annoying thing about those corporate profiles.
I suspect someone could decap the chip itself and extract the key, at the cost of the phone (and burning a bunch of whatever chip they're using in advance to prep for the attack). That probably would be worthwhile for a conference presentation. I'm confident any decent intelligence service which doesn't have Apple's cooperation can do this now, since extracting keys from hardware is a pretty key capability for anyone doing black bag stuff. A friend of mine just started a consultancy in this space, so maybe will look at this for a presentation in 2014 if there's time.
Bruteforcing 10e3 numerics doesn't take long when your forensic ramdisk doesn't have any rate limiting or auto-wiping.
But a longer pass phrase (admittedly a ux problem) helps. Plus, rumors of biometrics, which may or may not be implemented in a smart way. A biometric which allows a 4 digit pin, or if it fails, a 16 char alphanumeric, would be proper.
There are no public ways to extract from the newest devices on ios 5 or 6, except for a few corner-case bugs (which were limited, and patched).
Plenty once you jailbreak the phone, or compromise a paired device. I believe the best practice among public attacks is to do that. There are probably various exploits in iOS itself which let you root phones remotely. Beyond that, either secret attacks or hardware attacks, or figuring out how to get the phone to boot from one ramdisk while talking to the security element from before (which is trivial if you can sign stuff as Apple, and may actually be possible otherwise.)
In other comment threads I'd heard the opposite: that when new iOS devices were activated, they didn't get access to past iMessage threads, just future ones. Perhaps that's because there's a "new device" activation flow and a special "replacement device" one. But that doesn't matter. Your iMessages are only as secure as the weakest link. OP has found a pretty weak one here.
Perhaps a better experiment would be to see if messages are readable after a restore (with and without password changes) if the device isn't backed up to iCloud.
The long & short of it is that Apple can't get at your iMessage contents or history if you don't use iCloud backups and don't subscribe to Apple's desktop password recovery service (duh).
Apple's iOS Security Whitepaper adds some light: https://www.apple.com/ipad/business/docs/iOS_Security_Oct12....
(a) iMessage is end-to-end encrypted. There is metadata about who is messaging whom because it is distributed through the Apple Push Notification Service. This identifying metadata consists of ephemeral tokens generated by the sending server and the receiving device. And there is a small amount of encrypted message history kept for the PNS to resolve pending messages to all subscribing devices.
(b) Some iOS Backup files are not accessible by anything but the original device because they are encrypted by a combination of the device UID and your key. Mail for example. No one can get at them other than someone with 1. your password and 2. your device.
(c) iMessage files aren't protected like this since you CAN restore them across devices. But this is by design -- only way for iMessage history to be retained is through a backup.
(d) There are two backup approaches: iTunes (on your PC/Mac), which encrypts via a password, or iCloud.
(e) With iCloud, Apple could get at your backups because they could reset your password.
(f) Therefore, make a determination as to what is more secure: your PC/Mac's password, or your iCloud password (and Apple's willpower not to reset it at the request of the NSA). Back up your iOS (and thus iMessages) devices there. Or don't backup at all, and no one will see any history.
(edits: for clarity)
The rest of it though... iMessage is not perfect, but it's better than most alternatives.
* Plaintext logs of iMessages (iOS or OS X) allow you to view past messages. Duh. So do plaintext logs of OTR chats via Adium or Pidgin.
* You don't generate your own key nor verify the keys of others; you rely on a third party to do it. The effect is that the system is actually used by normals unlike, sadly, GPG or OTR. Heck, even many of the technical people I know give up on GPG and OTR because they're just too much work. The point is the messages are encrypted in transit and cannot be read by just anyone ... in contrast to SMS and typical instant messaging.
And said services are explicit about this upfront.
In short, Apple can't read your email backups, and neither can anyone attempting to restore your device from iCloud (they would need your email passwords). iMessage doesn't have the same protection.
Not that I believe every article that I read (I always speculate sources and bias journalism), but here is an article "pre-PRISM," that states the FBI's stance with iMessage: http://news.cnet.com/8301-13578_3-57577887-38/apples-imessag...
Even without iCloud backup, Apple, or anyone they add keys for on your account, can decrypt iMessages.
Your whole chat history is right there, readable in TextEdit.
It's not unthinkable that the NSA could access iCloud backups (with some sort of FISA rubber stamp). Access to everyone's backups is much more conducive to dystopian mass surveillance than the key server's tradeoff of vulnerability to MITM.
The OPs first point is a lot stronger than the second. Distributed backups are probably bad from a privacy/security perspective. That seems like the better point to make, provided we understand that iMessage is not a guarantee of complete safety from any surveillance.
Is there a way to access the messages on iCloud itself (i.e. the web interface)? That would be much stronger evidence that Apple can read it.
"In practice it's not clear if Apple devices encrypt to this key directly or if they engage in an OTR -like key exchange protocol. What is clear is that iMessage does not include a 'key fingerprint' or any means for users to verify key authenticity, which means fundamentally you have to trust Apple to guarantee the authenticity of your keys. Moreover iMessage allows you to send messages to offline users. It's not clear how this would work with OTR."
So I guess the need to send messages to offline users ruled out the use of OTR.