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...
I think it would only work with Apple's help (via court order or a breach) because Apple implemented certificate pinning as of iOS 9.0 according to the article.
Yes, the obvious first mitigation was to ensure that all iMessage clients used pinned certificates. This prevents an attacker who can forge their own certificates from obtaining encrypted iMessages and launching the JHU attack.
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.
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.
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.
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.
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).
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.
Actually, Signal uses bloom filters to do "offline", private contact discovery[1]. That's why their contact discovery is rather bandwidth-intensive, as @praseodym mentioned.
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.
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.
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.
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.
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.
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.
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.
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?)
Yes, the latter. They call it a "keybag." When you sign into iMessage on a new device, a new public key is added to your "keybag" and all messages addressed to your account are also encrypted with that key.
You get a notification when a new device is signed into your iMessage account. However, Apple could presumably suppress this notification when adding a law enforcement key to your keybag. In principle, devices sending messages to you are aware of this key (they must handle it) but because iMessage is proprietary, the user has know way of knowing.
In principle, iMessage's design but with open-source clients would be ideal.
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?
> ...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.
39 comments
[ 2.8 ms ] story [ 103 ms ] threadIt 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...
Or a compromise of Apple's push notification infrastructure.
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.
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.
I'd still recommend always to use an authenticated cipher, since the above distinction can be very fine.
[1] https://github.com/WhisperSystems/Signal-iOS/issues/866
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.
[1]: https://whispersystems.org/blog/contact-discovery/
Reference and more details: 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...
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.
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.
Contact discovery without the server seeing the list of contacts is hard.
If you disable access to contacts, all it does is complain about access with no way to bypass.
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.
* https://tonyarcieri.com/all-the-crypto-code-youve-ever-writt...
* https://paragonie.com/blog/2015/05/using-encryption-and-auth...
* Many articles on http://www.cryptofails.com
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?)
You get a notification when a new device is signed into your iMessage account. However, Apple could presumably suppress this notification when adding a law enforcement key to your keybag. In principle, devices sending messages to you are aware of this key (they must handle it) but because iMessage is proprietary, the user has know way of knowing.
In principle, iMessage's design but with open-source clients would be ideal.
1. http://laurent.bachelier.name/2013/03/gpg-encryption-to-mult...
Which is weird, Chrome is far more mainstream than Firefox these days.
Hipster neutral link: http://stackoverflow.com/a/597200/1176872
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?
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...