
Attack of the Week: Apple iMessage - ianmiers
http://blog.cryptographyengineering.com/2016/03/attack-of-week-apple-imessage.html
======
dguido
If you're struggling to understand the impact of this iMessage flaw, remember
that it requires either a Root CA or Apple's help to work. If you're
considering an attacker with access to a Root CA, then you have problems far
beyond iMessage crypto.

It is certainly a good defense-in-depth measure to implement the
recommendations from JHU and it's great that Apple has moved aggressively with
them. Those mitigations will protect even from a catastrophic "goto fail"-type
bug in the future where you could strip away TLS.

That leaves Apple cooperating with law enforcement (or an Apple insider,
coerced or otherwise) to launch this attack against one of their users. I
think this scenario is unlikely given their very public reaction to the iOS 9
backdoor the FBI requested.

Finally, I think their development of the gzip oracle is pretty great and that
it has the potential to work against other cryptosystems. This is probably not
the last that you'll hear of it. I suspect the JHU team is running down a list
of other cryptosystems that it could work against right now...

~~~
tptacek
Format oracles against compressed protocols are actually already a thing, so,
yes, this attack is a pretty useful outline of attacks against other
protocols.

The _underlying_ problem here is unauthenticated encryption (or, MAC-then-
encrypt constructions, which, when it comes to adaptive chosen ciphertext
attacks, are often morally the same thing). Unauthenticated encryption is a
game-over flaw, probably no matter what the rest of the protocol does.

~~~
Natanael_L
The problem here was that authentication could be stripped and substituted
(digital signatures).

~~~
tptacek
Different sense of the word "authentication"!

What you (and, no doubt, the Apple engineers) are thinking of as
authentication is really a _signature_. Signatures and authenticators aren't
the same thing.

Here, we're referring to _message_ authentication, which is the mechanism of
using a secret key (usually agreed on at the same time as the secret key for
the cipher itself) to apply a "secure checksum" to the ciphertext, to ensure
it isn't tampered with.

Trying to use a signature in lieu of an authenticator is what got Apple in
trouble here. In addition to ECDSA signatures, those messages also should have
used a MAC, or, better still, an encryption mode with a MAC built in, like OCB
or EAX or NORX.

~~~
sdevlin
If messages come from one known-good source (e.g. firmware updates), a digital
signature is a valid message authenticator. Where this falls down is in multi-
user settings (e.g. iMessage), where secret-key authentication via MAC becomes
a necessity.

I'd still recommend always to use an authenticated cipher, since the above
distinction can be very fine.

------
heavenlyhash
The Cryptographic Doom principle strikes again!
[http://www.thoughtcrime.org/blog/the-cryptographic-doom-
prin...](http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/)

The article refers to it more precisely as "similar to the padding oracle
attack discovered by Vaudenay", but this root problem -- malleability -- keeps
coming up _so often_ even in relatively mature attempts at crypto that the
appeal-to-emotion "Doom" name seems worth using.

~~~
CiPHPerCoder
Some other attempts to raise aware of ciphertext malleability and AEAD modes:

* [https://tonyarcieri.com/all-the-crypto-code-youve-ever-writt...](https://tonyarcieri.com/all-the-crypto-code-youve-ever-written-is-probably-broken)

* [https://paragonie.com/blog/2015/05/using-encryption-and-auth...](https://paragonie.com/blog/2015/05/using-encryption-and-authentication-correctly)

* Many articles on [http://www.cryptofails.com](http://www.cryptofails.com)

------
runesoerensen
Direct link to the paper (since it's a bit hidden in the blog post):
[https://isi.jhu.edu/~mgreen/imessage.pdf](https://isi.jhu.edu/~mgreen/imessage.pdf)

------
zaroth
So the setup is... All iMessage has to start with is some unspecified sender
who has your public key and wants to send you a message. Sender will RSA-OAEP
a random key to the receiver's public key, but then for some reason they are
doing encrypt-then-sign, which doesn't really accomplish much because an
attacker can just substitute their own signature.

The receiver can't know where the ciphertext they are being sent actually
originated.... Just strip the signature from the original sender, add back
your own, keep the RSA-OAEP blob which is holding the encryption key as-is,
and then start tampering with the AES-CTR ciphertext. Having found an oracle
(a way to know if decryption succeeded or not) in the attachment download
code, it was just a matter of the hard work of making the bits dance just
right to use the oracle to deduce the key.

In this attack the RSA-OAEP encrypted nonce is left alone. The fix they
propose at the end is to cache this part of the message for a while to not
allow replay. But I don't understand... why not instead derive authentication
and encryption keys from the random 'k' and use it to append a MAC to the AES-
CTR ciphertext, like an IES?

Given RSA-OAEP is "IND-CCA2", it is not vulnerable to chosen cipertext. That
means it's "safe" to touch the RSA and decrypt before authenticating anything.
At that point you then have enough to generate an authentication key to run an
HMAC on the "hot" AES-CTR ciphertext before proceeding any further. I guess
the obvious appeal of just caching the RSA'd 'k' to prevent replay instead of
something like this is that neither the crypto nor even the message format
have to change.

Alternatively, what you see in X25519, is the sender generates an ephemeral
keypair and does ECDH with their private key and the receiver's public key to
get a shared secret. Sender can then use the shared secret to do any standard
authenticated symmetric encryption they want. Receiver will need the sender's
ephemeral public key on their end to ECDH the same shared secret. In this
case, again, as long as the asymmetric crypto is IND-CCA2 the receiver can
safely figure out the shared secret and an authentication key before they have
to touch any hot sauce.

Actually pulling of a working exploit with 2^18 messages while having to
mangle ciphertext and keep gzip happy is really impressive! But at the same
time, encrypt-then-sign with no MAC obviously will fail given an oracle, and
oracles will always exist. So.... why did Apple do it this way, and why not
just fix the underlying crypto and instead hack around with anti-replay?

------
junto
> ...attacks on a key server seem fundamentally challenging to implement --
> since they require the ability to actively manipulate Apple infrastructure
> without getting caught.

Tell that to Belgacom [1]! If the NSA can tap the inner networks of Google's
fibre connections as they traverse the Atlantic, then they can infiltrate
Apple whilst juggling chainsaws.

Apple are probably the market leader in branding. Their hardware is top notch
but their services are flaky and feel hacked together.

That doesn't bode well when it comes to securing message protocols and
networks. In addition, much of Apple's services run in the cloud on Microsoft
Azure and Amazon AWS. I doubt we can consider then safe havens from the
snooping, driving, hacking five eyes.

[1] [https://theintercept.com/2014/12/13/belgacom-hack-gchq-
insid...](https://theintercept.com/2014/12/13/belgacom-hack-gchq-inside-
story/)

------
newman314
I'd be over the moon if iMessage turns cross platform and adopts
Signal/Axolotl under the hood. iMessage UX is much better than Signal's and it
just works.

~~~
praseodym
It's too bad Signal isn't used more widely. I even deleted it from my iPhone
because of its very high data usage for contact discovery: about ~5MB for
every(!) change in my iPhone contacts. And after over six months, a fix has
not been released yet [1] (and a new release doesn't seem planned for anytime
soon).

[1] [https://github.com/WhisperSystems/Signal-
iOS/issues/866](https://github.com/WhisperSystems/Signal-iOS/issues/866)

~~~
Matt3o12_
The reason why I don't use signal is because it uploads all my contacts to
their server, something which I don't want. I don't mind adding a contact by
hand.

I currently use Threema, which seems to be pretty secure. Unfortunately, it is
not open source. A killer feature in Threema ist that you can exchange (and
verify I believe) the certificates physicly. You just scan the other party's
qr code (it think it is either the fingerprint or the public key) and it saves
it to the contact (it will not save it to your phone it will just remember
that user with the id ABC uses that certificate. But until it is open sourced,
we can only use the good ole PGP.

~~~
praseodym
Signal tried to avoid uploading contacts by downloading an encrypted bloom
filter to match contacts on the device instead. Unfortunately this doesn't
work out with many users (causing large downloads), so they ditched the
feature.

Reference and more details: [https://whispersystems.org/blog/contact-
discovery/](https://whispersystems.org/blog/contact-discovery/)

Commit that removes bloom filters (unreleased, will be in version 2.4):
[https://github.com/WhisperSystems/Signal-
iOS/commit/26f9207c...](https://github.com/WhisperSystems/Signal-
iOS/commit/26f9207cab06e4df4af3dc9c02deca3d250eb4ae)

~~~
newman314
Wait, are you saying that encrypted contact discovery has been removed because
it's "hard to do"??

I would think that's a pretty big change to be announced other than a blog
post. I reread the post and the only mention is "For TextSecure, however,
we’ve grown beyond the size where that remains practical, so the only thing we
can do is write the server such that it doesn’t store the transmitted contact
information, inform the user, and give them the choice of opting out".

That's pretty WTF to me. Disabling access to contacts now and back to wishing
for my unicorn messaging app.

~~~
StavrosK
No, it was removed because it "used 5MB for every change". I also wish for an
app that would defy reality, but, until then, telling a server who your
friends are so it can check, without telling it who your friends are, is a
hard problem to solve.

~~~
tveita
There is nothing reality defying about meeting up and exchanging keys in
person. Unfortunately, that's a use case the Signal UI goes out of its way to
discourage.

It's not like they don't know how, copying Threema's UI would be a massive
improvement. Hell, even Snapchat lets you add a friend by scanning their
screen, it's not like it's some user hostile ivory tower feature.

~~~
StavrosK
Signal does too. We're talking about contact discovery, not key verification.
Contact discovery is the problem of, given a list of contacts, returning the
ones that are on the service.

Contact discovery without the server seeing the list of contacts is hard.

~~~
newman314
Given that the way Signal presents contacts is suboptimal too (contacts
showing up irregardless if they have Signal installed only someone else
uploaded said contact), I'd rather have a mode where I have to manually
exchange contact info until such time secure contact exchange is solved.

~~~
StavrosK
Isn't that easily achieved by not giving Signal access to your contacts?

~~~
newman314
Try it with the current version.

If you disable access to contacts, all it does is complain about access with
no way to bypass.

------
durkie
a little bit tangential, but is it known how received imessages are able to be
decrypted on multiple devices?

if the sender's message encryption key is encrypted with my iphone's public
key, then my iphone's private key is the only key that can recover the the key
used for the message.

so then how can desktop imessage also recover the key and decrypt the message?
it seems like either: * private keys are shared between devices (doesn't seem
good) * imessages are encrypted multiple times based on the number of
registered devices the recipient has (plausible?)

~~~
TACIXAT
Schemes using multiple keys exist. [1]

1\. [http://laurent.bachelier.name/2013/03/gpg-encryption-to-
mult...](http://laurent.bachelier.name/2013/03/gpg-encryption-to-multiple-
recipients/)

~~~
JackuB
Should I feel bad for opening that link on iPad? (Got redirected here:
[http://no-hipsters-allowed.t28.net](http://no-hipsters-allowed.t28.net))

~~~
dfc
It looks like it works based on the referer. Anyone from HN is tagged as a
hipster. Copy the link and paste into a new tab.

~~~
briandear
Why even bother with that link if he's going to be so ridiculous with the
redirect?

~~~
dfc
Who knows. I imagine that the original linker had no idea of the functionality
when he linked to the site.

------
rplnt
Attack of the week on Monday, huh...

------
lovedj
i think this was put in there on purpose

