Hacker News new | ask | show | jobs
by mschuster91 3440 days ago
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.

2 comments

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.

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

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.
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?
No, the WA server sends the changed public key of the recipient to the client, which has the unencrypted messages. Then the client reencrypts all pending messages and resends them.
> 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.

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?
yup
That's pretty savage. This really is a massive issue.
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.

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