[wyldfire]

Even if they changed this specific design decision/vulnerability, it seems like there's a big gaping hole (or I'm missing something).

Given that WhatsApp brokers the initial key exchange, lawful interdiction can take place at WhatsApp under subpoena. What we hope is the case is that WhatsApp would fight these orders in court, claiming that the keys are merely forwarded and aren't stored by design. But if they fought and lost, then presumably they'd comply with the orders and the provision not to reveal the order. Do we really think that WhatsApp and/or Facebook have the conviction of Ladar Levison?

It would seem that all new accounts created at WhatsApp after that theoretical warrant is executed are at risk.

[ikeboy]

I'd assume the keys are generated on device.

[tptacek]

They are, so I'm not sure I understand the attack upthread.

[mschuster91]

A plausible attack scenario, outlined in multiple steps:

1) Police arrest a drug dealer, who manages to turn his phone off by smashing it on the floor and the battery pops out, in the same step also locking the data from readout if the device is using FDE

2) Cops now take the SIM card, compel the provider to provide the PUK to unlock the SIM card and insert it into their own smartphone

3) Cops activate WhatsApp and now can read any messages sent after the arrest, thus discovering potential clients. They can also impersonate the drug dealer and arrange sting operations.

[pfg]

That's why WhatsApp allows you to verify your recipient's key out of band. The scenario you describe would cause the identity key to change and trigger a notification if one of the potential clients has that option enabled.

There's really no way to avoid out-of-band key verification in end-to-end encrypted messaging unless you fully trust the service. Other than that, the best you can hope for is after-the-fact detection of MitM attacks through something like Key Transparency, but that still requires that someone's actively looking for that.

[mschuster91]

> The scenario you describe would cause the identity key to change and trigger a notification if one of the potential clients has that option enabled.

But only for messages sent by the sender AFTER the key-change notification. Those still in the send queue get re-encrypted with the new key of the cop phone and then resent without confirmation, and this is the attack window and the bug!

Oh, and most people don't enable the key-change notification anyway so they won't even know that their dealer got arrested.

[pfg]

Sorry, I was thinking under the premise of a hypothetical version of WhatsApp where this behaviour was changed, since that's what OP was referring to. In that scenario, I don't see where the gaping hole is.

[sschueller]

How does Whatsapp re-encrypt a message if they aren't supposed to have a key to decrypt? Is this done on the senders phone? Is it possible to re-encrypt within decrypting?

[FabHK]

> The scenario you describe would cause the identity key to change and trigger a notification if one of the potential clients has that option enabled.

... and that notification would be shown after that potential client's WhatsApp client had re-encrypted the undelivered messages and re-sent them.

[antihero]

So they could effectively leave the phone off for a while, then pop in the SIM and suck up any messages that had been sent in the mean time, and only then would the warning come up?

[pfg]

Yes, but this thread starts with "Even if they changed this specific design decision/vulnerability, it seems like there's a big gaping hole (or I'm missing something)."

I don't see how WhatsApp would be vulnerable in this scenario assuming they change this behaviour, but OP claims there's still a big gaping hole.

[wyldfire]

That doesn't match the scenario I was describing. Though I think it does match the one described in the article.

[wyldfire]

Presumably the device generates a keypair and then needs to exchange with the remote device somehow? I assumed both devices connect to WhatsApp and it delivers what is ostensibly the pub keys from each of the parties to each of them?

[pfg]

This can be detected if the sender and the recipient attempt to verify their keys out of band (i.e. in person or through some other trusted communication channel). WhatsApp allows you to do that.

[dingaling]

Out of band but not out of app. It's the WhatsApp app that generates and presents the 'security code' or key fingerprint for comparison.

It's not like SSH in which separate and discrete components generate the keypair and verify fingerprint on connection.

[pfg]

That's moving the goalposts. A backdoor in the app itself is a whole different matter - both legally (give us these records/change these records in your database vs. build software according to our spec and ship it to your customers, which is similar to Apple vs. FBI and might not be constitutional) and technically.

I also don't see the difference between this and SSH. If your SSH server or client is backdoored/compromised, you have no control over what happens with your plaintext, no matter what the fingerprint verification tells you. The only difference is that one is open source, so the likelihood that a backdoor is detected is probably higher, though I don't think this means a) there is no backdoor and b) a backdoor in a closed-source app cannot be detected.

[arrakeen]

it uses the diffie-hellman key exchange: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...