Hacker News Reader

Comment by StavrosK | Hacker News Reader

This says that, yes, Apple can read your iMessages, but it seems to me that the protocol is pretty much designed to be as secure as one can make it while still being usable. Would you really expect people who used iMessage to call their friends and have them read hex fingerprints over the phone?

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.

View on HN

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!

They may very well not be able to read your messages after the initial key exchange.

This is known to be false; Apple will restore your iMessages if e.g. you replace your phone.

These come from your iDevices encrypted backup in iCloud, not from iMessage servers. I guess if you dont use iCloud and back upp to your local iTunes on your Mac/PC, your messages are a bit more "private".

this seems to only be true if you are using iCloud backup. it is easy to not back up to iCloud if you choose.

The backups stored on iCloud are encrypted with your Apple ID password.

Your password can be reset and you don't lose your backups so either Apple has your password in cleartext (so the encrypted backups can be viewed freely) or they have full access.

Well - to be fair, BBM over BES is as secure as it gets. The only people who can read those messages are sender and recipient, and the owner of the org keys. Neither cell provider nor blackberry can decrypt them.

I think it's established that there are backdoors in BBM. E.g., http://www.zdnet.com/in/indias-blackberry-monitoring-system-...

How does it exchange the keys? If you don't verify fingerprints, there's always the possibility of a MITM.

You can arrange a chat protocol, I think, where MITM isn't possible without being easily detectable in a low latency environment. The idea would be that when you see the "..." of the other person typing, you're receiving an encrypted copy of the letters of their message. When the message comes through it contains information needed to decrypt the message that was received over many seconds. You could always be chatting with an imposter, but a middle man would have to wait for the decrypted message before sending out the re-encrypted keys, which would add a big awkward pause before every response even started being typed.

Hmm, interesting idea, thanks.

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.

Another interesting idea against MitM attacks on key exchange is implemented in ZRTP: verbal cross-check of two code words displayed on both terminals (during the first call) and key continuity (during subsequent calls).

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).

The brilliant part of ZRTP isn't the cross check, it's using hash commitment to shorten the SAS to only 16 bits, from 160+.

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?

I don't understand the first flaw you found. You can encrypt single characters + salt.

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.

If you encrypt a single character, you can also decrypt that single character. What would that gain you?

Also, what does the salt have to do with the encryption?

Forget the salt. I thought you were possibly concerned with encrypting one character being a weakness.

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.

How are you going to send the key over the wire without anyone intercepting it?

You have a session key that encrypts the entire channel. A MITM attack would require negotiating two session keys: one for you and one for your human chat parter.

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.

Ah, I see what you mean now. Then a MITM attack would basically double your typing time. Given that messing around/thinking about what you want to say/etc takes a variable (and pretty large) amount of time, I'm not sure that just doubling your typing time would be detectable.

FYI it's not just increased typing time. It's increased pauses with no typing.

I meant that the added pause will be equal to your typing time, so if you wait 10 seconds and type for 1, the other person will see an 11-second pause and 1 second of typing.

(Replying to your new message)

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.

That's what every system currently does, you're supposed to verify the fingerprints before talking to the other person. Phone systems are easier because you can verify that they're who they say from their voice (when it's reading you the fingerprint).

Does iMessage do this?

I'm not sure, I've never used it. I was referring to OTR, Silent Circle, etc.

How does the key exchange happen between the two parties? With a party in the middle that has an already existing relationship with both parties, no? That is where you sit and exchange fake data with both endpoints.

With enterprise server (BES) presumably the company which owns the phone acts as the certificate authority. So your employer could pull off a MITM attack, but then they already own the hardware anyway.

Yeah like Apple makes your iPhone hardware anyway.

Except that this would have to be done at each individual company...

Leaders from Saudi Arabia, India, and probably the UAE, Lebanon, Algeria and others all disagree with you on this one.

No contradiction. The telcos are the owners of the org keys.

Bbm is only secure if you run your own bes.

Incorrect. They have access to consumer level, same as any other nation that permits BBM.

There is no access to BES - it's a private key owned by the companies.

As far as I know, the Indian govenrment gave an ultimatum to BlackBerry to place servers in India and provide a mechanism to read messages or to leave the country. BlackBerry caved in and was forced to do so. So even BBM isn't as secure. Anytime you trust a third party with your data, there is always that element of risk involved.

That was for BIS - consumer-level BBM, essentially, and the same access is given (if not advertise) to governments anywhere.

Nobody has access to BBM over BES except each company running BES.

Note that BES communications are only secure within a community of interest. (Assuming whomever is running your BES isn't logging and transmitting your texts) Once you talk to someone outside of your BES, RIM controls the key.

Reply on news.ycombinator.com