Apple Explains How Secure iMessage Is
techcrunch.com
techcrunch.com
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.
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.
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.
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.
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.
You said: 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.
My point is that publishing the source is not enough since you cannot verify that is the source running on your iPhone. Even if we concede that Apple could let you sideload your own compiled binary (which is not the case today), you still couldn't prove it since you couldn't know that the iPhone is running your binary and not a backdoored binary in the OS.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.
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...
For one, if you back up your device with iCloud, then yes, Apple can read your iMessages. This has been verified by experiment.
Second, Apple operates a central directory of iMessage public keys mapped to accounts, and this enables various kinds of MiTM attacks. Contrast this with the way TextSecure / RedPhone does contact discovery using blinded signature queries [2].
Third, iMessage and iOS are closed source. Ultimately, closed source can do whatever the heck it wants. Not just what they're telling you it does.
All the same, we now have some new details on iMessage from Apple [3], and I'm looking forward to hearing the crypto experts pick it apart.
[1] http://blog.cryptographyengineering.com/2013/06/can-apple-re...
[2] https://whispersystems.org/blog/contact-discovery/
[3] http://images.apple.com/iphone/business/docs/iOS_Security_Fe...
This is actually more secure than I expected.
For example if you have 3 devices (iPhone, iPad, MBP) and someone goes to send you a message, they have to re-encrypt the message three times because Apple would have sent them three public keys.
Now if Apple were evil because of a government order, they could send down four public keys, the three ones for the devices you own, and the one public key that Apple has the private key for. At that point once they receive the message they can read it.
Any system that distributes public keys like this can be compromised the same way.
---
The only real way to stop something like this is to make sure that the person you are talking to holds the keys, OTR does this for example by allowing both parties to verify the fingerprint...
With iMessage, if the FBI gives apple a warrant to include their snooping pubkey as an additional encryption endpoint for all messages for a user, by definition it only gives access to messages made from then on, which is in keeping with how I would expect a search warrant to work.
You're correct about iMessage, which is an important point to make. But you're not correct about PRISM; see my article from last summer: http://news.cnet.com/8301-13578_3-57588337-38/
I made no claim that about direct access to servers, but I guess since the rumors of direct server access and "PRISM" are synonymous in popular news articles, it was misleading to use the term. My point still stands if you replace "PRISM" with "NSA's dragnet surveillance", which is surely happening.
This is not a matter of populism or even of principle. US technology can't be trusted any more. How are you going to restore that trust without making the technology verifiable and without providing simple, reliable ways for end users to routinely put their communications and data out of reach of surveillance?
Where is the "populism" in this? This is about many 10s of billions of dollars in revenue lost and even more in lost shareholder value and opportunity.
That is, assuming, that there isn't some code in the app that allows Apple to request that the app send your private key up to the server. It's conceivable that in order to comply with law enforcement, for example, that Apple could just tell the app to send up your private key so that it can decrypt any message they have stored.
There's also no way to verify that your messages have, in fact, been removed from their services.
Not only do I think it's not unlikely, I actually think it's pretty much a certainty that Apple has a backdoor in their code. After the slides detailing how easy it is for NSA to break into Apple phones I'd be simply shocked if they hadn't inserted such a vulnerability.
Sounds to me like the author is applying a nice coat of white wash.
https://plus.google.com/108799184931623330498/posts/SfYy8xbD...
Of course, as there's no way to disprove this hypothesis, and there's no proof of it, you can still err any way you like :)
The slides pertained to physical access to an iOS 6 device, which was publicly known as insecure before the NSA revelations:
http://apple.slashdot.org/story/13/08/01/2024212/iphone-hack...
* Text messages and most other chat protocols require that you trust multiple hardware vendors, multiple software vendors, and multiple telcos. By comparison, iMessage only requires that you trust a single company, Apple.
* As long as the operating system and messaging software is closed source, it would be impossible to eliminate the requirement to trust Apple anyway. If you really need serious security, you shouldn't be relying on any closed source third party systems, period.
* This is about as secure as it could ever get without requiring users to be educated about security principles. Given that iMessage is foremost a seamless alternative to text messages, it's difficult to imagine how they could make it more secure without compromising utility.
* The implementation details mean that any Government snooping must be done with Apple's knowledge, and will require the blessing of Apple's legal department. This might not be a particularly high bar to cross, but it does mean that Governments aren't running rampant, analyzing every message sent.
* The United States government isn't the only bad actor out there. The level of security appears to be extremely good against entities that hold no sway with Apple's legal team. It's also presumably impervious to a hostile network, or hostile foreign governments.
> * Text messages and most other chat protocols require that you trust multiple hardware vendors, multiple software vendors, and multiple telcos. By comparison, iMessage only requires that you trust a single company, Apple.
This is incorrect. It requires you to trust Apple, every company who operates a CA, every government who can compel any CA to mint a certificate (read: you trust the Turkish and Chinese governments), your IT department, and any hacker who has access to any of those. If you didn't install the patch this week, and for the last year and a half, it required you to trust everyone on every network segment you have ever connected to from any Apple device.
> * This is about as secure as it could ever get without requiring users to be educated about security principles. Given that iMessage is foremost a seamless alternative to text messages, it's difficult to imagine how they could make it more secure without compromising utility.
It could very easily be more secure. For example, certificate pinning would be a decent start. It could also allow users to view key fingerprints if they choose to. Many users wouldn't understand the purpose of that exercise, but at least the option exists. More paranoid users could enable warnings if a user's key changes. See also: Whisper Systems
> * The implementation details mean that any Government snooping must be done with Apple's knowledge, and will require the blessing of Apple's legal department. This might not be a particularly high bar to cross, but it does mean that Governments aren't running rampant, analyzing every message sent.
Incorrect, as explained above. There are attacks that do not require governments nor do they require any assistance or blessing from Apple.
> * The United States government isn't the only bad actor out there. The level of security appears to be extremely good against entities that hold no sway with Apple's legal team. It's also presumably impervious to a hostile network, or hostile foreign governments.
It's not impervious to hostile networks if those networks include your corporate IT network or if you have used it in the past year and a half on any network. Even with the latest patches, it is not impervious to hostile foreign governments. Check your browser's CA list and take a look at how many different countries are in there. For a more complete list, take a look at this: https://www.eff.org/files/colour_map_of_CAs.pdf
Citation, please?
http://images.apple.com/iphone/business/docs/iOS_Security_Fe...
> With one finger enrolled, the chance of a random match with someone else is 1 in 50,000. However, Touch ID allows only five unsuccessful fingerprint match attempts [...]
I assumed it was more accurate than 1 in 50,000. Then again I don't know what a normal fingerprint sensor is capable of. Does anyone know the accurate of the sensor in the new S5, or the sensors that IBM/Lenovo/etc. have put on laptops?
Also:
> The 88-by-88-pixel, 500-ppi raster scan is temporarily stored in encrypted memory within the Secure Enclave while being vectorized for analysis, and then it’s discarded after.
I wonder what kind of neat stuff people could come up with if we had raw access to that kind of sensor data.
So, you know, really not secure at all.
Nothing wrong with end-to-end encryption, folks. Why don't we have more of it?
Complacency and laziness. There is no excuse.
Why not?
In reality, it is probably secure enough against most adversaries. State level adversaries is a different story.. That you need OTR and key verification in person.
And the recent fail in their SSL/TLS library means you don't even need the help of a CA to create a certificate Apple software would consider valid.
They may never have your private key, but you are still trusting them to deliver the correct public keys to other users.
Standard SSL even when done right isn't enough to guard against our current privacy-abusing GO's.
If you can't verify and pin keys, then assume there is no encryption.
More precisely, on a user device: list the contact devices and key fingerprints. Adding a contact's device: on first exchange show fingerprint and ask for trust then pin the pubkey. Warn should the key change. What remains is for parties to exchange fingerprints in a peer to peer side channel (possibly even physically via bluetooth/qr-code).
Just wanted to mention that there is a possibility to key verification over sms. An sms can even be used for a temporary key for encrypting the key transfer.
Which is still exactly 0% secure as far as I'm concerned.
All in all though - in general - I'll be more than happy to continue using iMessage and feel at peace. As a general rule, however, never send anything electronically that may screw you over later.
The best encryption we have today is still bound to time and technology. Without a threat model, it's pointless to discuss security. To the NSA, not much of anything is secure on the Internet. There is a lot you can do when you have total visibility into all traffic. But your psychotic girl/boyfriend who barely understands what Wi-Fi is? They probably won't be eavesdropping on your iMessages.