Contrary to public claims, Apple can read your iMessages
arstechnica.com
arstechnica.com
> Since Apple controls the entire infrastructure, there's nothing preventing company employees from swapping out the proper keys with ones controlled by Apple or other parties.
What is misleading here is that (if I understand it correctly) the cryptography is solid, it is the implementation being owned by Apple that raises the doubt. But this is NOT a statement about the cryptography used on the iMessages, it is a statement about the fact that Apple effectively has "root access" to their phones.
Imagine that you had a PERFECT and UNBREAKABLE code system. Perhaps it interfaces with angles who alter the laws of the universe to prevent anyone but the intended recipient from reading the messages. Such a system would still have the same vulnerability. All Apple needs to do is to alter the phone so that when you click on the icon to launch this perfectly secure messaging app it instead launches one that has the same UI but which actually sends a duplicate to the NSA (or whoever it is you don't want listening in).
ANY system where code can be deployed at will and the owner of the device is not in full control of the device will have this same level of vulnerability. Saying that a system is insecure because you could change the system doesn't tell you anything interesting about the system.
The issue is that iMessage outright ignores a long understood challenge in the APPLICATION of cryptography, namely knowing when to trust that someone is REALLY giving you their public key rather than being man-in-the-middled.
While this is a thorny challenge there are well understood, if imperfect, ways of addressing it that have been around for decades. At minimum it works like ssh, where you get a warning when an unfamiliar new key is presented and decide whether to trust it or not. More sophisticated is the certificate infrastructure around TLS/SSL where some effort is made to bring semi-trusted third parties into play.
These are all flawed solutions, the problem remains essentially unsolved. But any truly secure system based around public keys has some mechanism that addresses this challenge.
The issue with iMessage is that 1. Apple did not attempt to address the key exchange problem, which would maybe be fair enough on an "easy" consumer product with weak security claims but then 2. Apple made strong security claims very publicly and 3. even said a counterfactual, that it had no capability to intercept messages.
THAT is what is disingenuous: Apple implements public key cryptography, which since its inception and at its very heart raises difficult challenges around key exchange; Apple chooses to ignore these challenges; Apple then claims strong public key security. Either attempt to address the challenges like everyone else, or don't make the security claim, you can't do both.
The flawed systems are SMS and predecessor systems like alphanumeric pagers, where your messages are archived indefinitely in a database by the carrier. Remember the Wikileaks release of all of the pager traffic in lower Manhattan on 9/11?
In my mind, the NSA/PRISM stuff is a meta-problem that is just something that is hanging out in the background. I work in enterprise IT, I'm not a dissident, drug dealer or whistleblower, so I'm more worried about incompetent carriers and other hostile parties than the NSA.
So iMessage gives me encrypted message content that may be readable retrospectively by the NSA, and is almost certainly "tappable" by normal law enforcement.
The reality is, that's about as good as you are going to get outside of a defined community of interest. My employer has highly secure voice and text solutions available for key personnel, for instance. Perfectly secure communications won't be available to the masses, because the operators of those systems face liability.
Apple did not say, "Here's iMessage, it is much more secure than SMS."
Apple said (in essence), "Here's iMessage, we couldn't tap it if we tried."
THAT is false, and all of the nice things you point out about iMessage aren't in dispute and don't have anything to do with the glaring inaccuracy of Apple's claim.
They key message is: Apple cannot decrypt or read your data. That's all they said.
They didn't say "Apple will not lawfully provide iMessage encryption keys to the government" nor "Apple will not provide the secret key for the iPhone CA to the government upon request/demand" nor "Apple will not provide iMessage data to the police."
When a secret court compels you to remain silent, what isn't said is critical.
Strong crypto is, and should be, available to everyone.
Common carriers are required to to have "tappable" systems if the system is deemed to replace phone conversations.
ANY system where code can be deployed at will and the owner of the device is not in full control of the device will have this same level of vulnerability. Saying that a system is insecure because you could change the system doesn't tell you anything interesting about the system.
1. The NSA vacuums up network traffic. Meaning they use man-in-the-middle attacks. Sometimes they do force businesses to deploy a malicious program, as you describe, to gather a user's password. This is called a Pen Register, or Trap Trace Device: https://ssd.eff.org/wire/govt/pen-registers However, this is the exception, not the norm.
Defending against man-in-the-middle attacks is a bare minimum requirement for any system that purports to be "secure". Defending against Pen Registers is an unsolved problem, but it's unrelated to the attack presented here.
If I understand it correctly, they are saying that the messages are encrypted using an RSA key unique to the sender, and that this is not secure because Apple could, if they wanted to or were ordered to, replace the certificates with ones that were not secret. [...] What is misleading here is that (if I understand it correctly) the cryptography is solid, it is the implementation being owned by Apple that raises the doubt. But this is NOT a statement about the cryptography used on the iMessages, it is a statement about the fact that Apple effectively has "root access" to their phones.
2. From http://blog.quarkslab.com/static/resources/2013-10-17_imessa... page 36:
- All iMessages are encrypted and signed using asymmetric cryptography
- Thus, there has to be a key directory
- iMessage client retrieves recipient’s public keys by querying Apple’s ESS server
It's that last point which is the most important. When someone sends you an iMessage, their device queries an Apple-controlled server for the recipient's public key. The server returns a "Public Keys Buffer". The buffer contains an RSA public key (1280-bit) to encrypt messages for the remote device.
Apple controls that server. They can send you whatever public key they want.
In other words, while I wouldn't say it's "trivial," it's at least "realistic" for the government to be able to order Apple to serve up an MITM'd public key. Combined with a copy of the network traffic, they can then decrypt all iMessages. And the government isn't the only adversary to worry about, either.
The point of cryptography is that you should be able to trust who you choose to trust. Apple is saying we can trust their claim of not being able to decrypt iMessages. But that claim rests on Apple to serving up the proper public keys through Apple-controlled servers. This is called the key exchange problem, and it's why their iMessage claim can be accurately described as "completely bogus." They don't even attempt to address key exchange security.
The takeaway is: iMessage shouldn't be trusted.
Isn't that also true (minus Apple) for the PGP keyservers?
And if you want to make it extra nice, you could add an automatic/half-automatic back channel through bluetooth. could create interesting design options.
In a sense, you are an instant target for suspicion, you have created a "reasonable and probably cause for suspicion" by using such a device or software system.
I remember driving through my neighborhood in suburban Philadelphia and seeing a young man walking down the side of the road and being shocked by this act. Nobody walks in that neighborhood or along that road. Nobody bikes there. Frankly, it's ill advised because of the winding nature of the road and the absence of sidewalks or even a shoulder. I could feel myself become immediately suspicious of his presence and his actions.
All he was doing was going out for a walk. Frankly, I was the weird one.
At some point, as technology becomes embedded in our culture we expect people to use it and we look at those who do not as odd balls and are suspicious of them (think the Amish).
So if you are avoiding using the "latest and greatest" and opting to use a "secure system", people are going to look at you like you are crazy and be suspicious of your activities. This will probably drive you to keep it secret, which will only make it look more incriminating.
My point is: how do make these things mainstream in such a way that ordinary people who aren't interested in the security aspects can and will use them, but those who want or need the added security can use them without garnering suspicion for doing so?
1. Say i care about privacy. I decide that all the help i give people over the internet, would be composed of a plain text teaser ,and an encrypted content. That's easy to imagine doing so in private messages , and even in small groups. Maybe even using some technical trick this could work on publicly posted information(or at least slow the rate/chance of wiretapping). And in those cases i only reply to messages sent securely.
If enough people do this , soon enough , there will be plenty of encryption.
2. Make it a habit to embed an encrypted background channel in many apps that always transmits, that need comes be , can be used to transmit info. "Hey it's just a cool app man". If enough such apps spread, suddenly everyone encrypts.
' 3. Same applies regarding to anonymity.
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. [1]
I didn't read the article as asserting that the encryption is broken or poorly designed, simply that if compelled, Apple could indeed eavesdrop on iMessages, which contradicts the above statement. The author explains this explicitly:
In fairness to Apple, most other commercial messaging systems are also vulnerable to man-in-the-middle or similar attacks mounted by insiders. The difference is that few if any of those other providers have issued public statements claiming the messages sent over their services can be read only by the sender and receiver.
[1] https://www.apple.com/apples-commitment-to-customer-privacy/
As anti-Apple as I am, I think we have to give them this one, especially when the alternative (i.e. making iMessage completely unencrypted) would have been much, much easier.
I would be prepared to give them this one, were it not for the fact that they claimed the opposite. Make all the security vs usability trade offs you want, just don't lie about them!
Bbm is only secure if you run your own bes.
There is no access to BES - it's a private key owned by the companies.
Nobody has access to BBM over BES except each company running BES.
EDIT: I found the flaw: You have to wait until you have a full block before you can encrypt. If you send that, it's immediately decryptable. You can't send half a block, because you don't know the rest. Besides, the MITM can just pretend you haven't been typing until they receive the full message, and then start sending it.
http://en.wikipedia.org/wiki/ZRTP#Authentication
Cross-check of code words is essentially a humanization of RSA keys fingerprint cross-check. Only true geeks will speak hex digits over the phone, but normal people won't hesitate to tell a few words or small quizes/stories/whatever (if they need added security for this call).
By the way, if anyone knows how a birthday attack is possible on the verification without hash commitment? It seems to me that the attacker has to generate a key whose fingerprint matches the fingerprint of the key they agreed on with the second recipient. However, this means that they have to generate a key to match a specific one, rather than multiple keys, hence no birthday attack is possible. What am I missing?
You are correct that the MITM could wait until it's seen the whole block and pretend your partner hasn't started typing, but that results in big pauses with no typing after every question, which is detectable.
Also, what does the salt have to do with the encryption?
As a recipient of my message you receive my message encrypted one character at a time. When I press enter you receive the key to decrypt all of these individual characters and can string them together into my message. I pick a new key and start sending the next message one character at a time. I'm thinking that any MITM attack will introduce noticeable latency into this scheme.
Next you have a message key for each message that is used to encrypt and send each character and is sent at the end of each message (encrypted with the session key). A key detail I forgot to mention is that message keys should be tied to session keys so that the MITM can't just forward on the characters encrypted as they arrive.
Yes, it would be something you'd have to know to look for. The good thing is that under suitable conditions it would let you know that you weren't being MITMed.
A more practical system would probably be to just display a session ID in each chat window that is tied to the session key and is supposed to match between chat partners -- a fact that can be checked later in person. That would prevent MITM attacks from being commonplace without everyone knowing about it.
This seems about as vulnerable as the certificate authority/public key infrastructure system used for SSL, code signing, etc... We're always delegating to another party the responsibility of authenticating the person on the other side of our messages/web browser/signed software that we run. In the case of iMessage, Apple is responsible for authenticating your friend. In the SSL or signed code case, the certificate authorities are responsible. Seems that both Apple and CA companies might be subject to the same legal pressures to eavesdrop on people.
stellar678 is basically correct - Apple, like a CA, is vouching for the authenticity of users' public keys. The only difference is superficial: a SSL CA signs a certificate and the validation is done without needing to contact the CA, whereas with iChat the public key is validated by virtue of coming from Apple. Just as a CA can sign a malicious certificate, Apple can send you a malicious public key.
Well internal controls could prevent that but since we don't know we'll assume they don't exist, print the headline:
Tim Cook is reading your iMessages right now!
/shrug, when Gabriel W. says no one at Duck Duck Go can read your search history he's making a claim based entirely on internal controls that DDG has established that make this impossible. Similarly, Apple didn't claim it would be impossible for them to ever <rewrite everything> and one day be able to read your iMessages.
Since Apple controls the entire infrastructure, there's nothing preventing company employees from swapping out the proper keys with ones controlled by Apple or other parties.
We have evidence of a secret court order for Verizon to hand over the meta-data associated with phone calls. IANAL, but this seems quite different from ordering Apple to perform a MITM attack against a user.
Under what kind of court order would Apple have to remove or compromise end-to-end encryption from a target's device?
http://www.volokh.com/2013/10/11/lavabit-challenges-contempt-order/
A NSL can force Apple to not disclose it, but they can't force them to publically lie about it. And lying about that would be ridiculously stupid.
There wasn't a "case" here, Lavabit was compelled and risked fines, jail time, or both if they did not comply. You get a legal court order you can challenge it in court, but when the court upholds the legality of the order (as it did here) you either comply or go to jail. Apple will comply with any legal court order (although they may object to it first, as Google has done according to court records).
[1] Presumed to be Snowden.
[2] Printed out in 4pt font (which I thought was brilliant btw)
I'm not sure they'd be put in a position to lie. It would have to be a very direct, specific question to _require_ a lie. Otherwise, dodgy language would suffice.
1. https://www.apple.com/apples-commitment-to-customer-privacy/
"Apple can intercept the creation of new conversations between users on iMessage or FaceTime if compelled to do so by a valid court order."
English being as fungible as it is, leads to this sort of mess.
I'm not aware of the protocol, but it may be that Apple could only do this the first time someone sent a message, when keys were established. It might not, I'm just speculating, but it sounds reasonable.
If Apple wanted the protocol to be insecure, they'd have just sent messages in plaintext over TLS and be done with it. The fact that Apple actively designed a reasonably secure, encrypted protocol is evidence that they wanted to protect users against themselves too (to the point where it didn't impact usability).
1. Compel a witness to testify;
2. Compel someone to produce a document or "tangible thing";
3. Require someone to allow the inspection of premises.
Fed. R. Civ. Proc. Rule 45(a)(1)(A)(iii).
I can't imagine the Government would attempt to use subpoena power to force a business to take any other action, and if they tried to do so, as an attorney I would definitely appeal it (and probably prevail).
That's not to say there aren't other means at the Government's disposal, but subpoena is definitely not one of them.
Whenever a new technology comes out without lawful intercept, it gets embraced by criminals. Remember Nextel/Boost phones with direct connect? You might recall that there were 3 resellers on a block in the hood selling these things in the early 2000's. DirectConnect wasn't tappable for a few years, and the addressing scheme was tied to a phone, not a user. Those users later moved to BlackBerry.
I've wondered the same thing about Dropbox. If I were to open my dropbox at work, could my employer view private things in the dropbox? Even if I don't open the file, an icon will still load in the browser view.
If your employer has physical access or the admin password to your work computer (very likely) then anything you store or do on it is potentially compromised. (including passwords, keys, etc.) Same for work-issued phones etc. The security of the protocol is irrelevant in this case as you're trusting a compromised client.
if both of you rely on some intermediate authority for authentication (as HTTPS works), it's by definition not 100% because the intermediary can, in theory, be compromised.
if the two parties know each other and can authenticate via some basic questions, that may work. or you can just exchange symmetric AES keys in person or public certs through another channel.
> A 3rd-party iMessage app was just released on Android; I believe all data sent from/to Apple is resent to/from China for processing: beware.