Hacker News Reader

Comment by folex | Hacker News Reader

I didn't quite grasp why attacking entity (e.g. government) has the ability to read messages. What does "WhatsApp has the ability to force the generation of new encryption keys for offline users" mean? Does it mean that WhatsApp backend has the ability to force sender to use pregenerated compromised key provided by attacker? In terms of WhatsApp security whitepaper, does that mean that attacker can force sender to use newly generated (by attacker) S_recipient, O_recipient and the main one, I_recipient? I'm asking because "force the generation of new _encryption_ keys" doesn't really specify who would generate keys, or what about identity key that signs everything.

View on HN

WhatsApp has the ability to change the identity key associated with a user. That's the key they give anyone who wishes to send a message to that user. This is necessary in case the device is lost, wiped or replaced. Changing the identity key triggers a notification for other parties in a conversation if they have enabled that option. However, WhatsApp also automatically re-encrypts any messages that have not been marked as delivered using the new identity key. An attacker that could force WhatsApp to change the identity key to one under their control could then read those re-encrypted messages, but not any messages that were already marked as delivered (or any future messages, assuming the notification causes the chat parties to re-verify the keys out of band before continuing their conversation).

> to one under their control

I wasn't able to find proof for attacker's ability to provide pregenerated key, can you please provide link with/or quote? I also wasn't able to find description of WhatsApp key changing procedure, and intuitively it would be more than strange not to require new identity key be signed with previous one.

The key is generated on device. WhatsApp acts as a kind of key server (if we want to compare it to GPG) where a sender can look up the public (identity) key of the recipient, which is then used to encrypt the message for the recipient. I'm simplifying a bit here, but the details are not important in this context.

The scenario is that someone changes the public key associated with the recipient on WhatsApp's server, which then causes the re-transmission "vulnerability" I described. This could be done either because the government forces them to, or because the server is compromised.

> it would be more than strange not to require new identity key be signed with previous one.

This would not work in practice. Phones can be lost, stolen and/or broken. There would be no way to sign the new key with the old one in any of these scenarios, since the key is only stored on the (lost) device. Forcing the users to back up the keys is not practical either for an app that wants to be an easy replacement for SMS, and depending on how users store those keys, might be less secure.

So the main problem is that the only way to make something secure is to introduce authentication factors, e.g. passphrase or biometrics

Let's say WhatsApp wants to read the next message sent to user X:

1) WhatsApp makes user X appear offline

2) User Y sends user X a message

3) WhatsApp sends user Y an indication that user X's key has changed, along with the public key for which they have the corresponding private key

With these steps, user Y's message will be resent with the new key that WhatsApp knows, and so they can read the message. There is a configuration setting that will display a notification that the key changed, but no way to prevent an undelivered message from automatically being resent with the new key.

So the main problem is that on _identity_ key change, the new one isn't required to be signed with previous identity key? If so, that's plain stupid, isn't it?

It's a natural consequence of "My phone got run-over/lost/stolen"

They don't have the ability to flat out read messages. If they were to impersonate a contact, you would see that the key had changed (assuming you had this on) and you could choose not to talk to that contact until you verified.

That's what I understood too. AFAIK, they only could 'break' contact, and not control the actual public identity key, so no way to read user messages.

Reply on news.ycombinator.com