While people discuss about a possible state-actor stronghanding WhatsApp and the semantics of backdoor, the "design feature" of not showing the key changes are making real victims, at least in Brasil:
The attacker first try to duplicate the mobile phone number of the first victim, probably by social engineering their phone company. This part may look difficult to do, but it is not hard if you realize you do not need to target anyone special - everyone uses WhatsApp, so any number gives a high probability of success.
After getting the first victim number, the attacker install WhatsApp, which gladly verifies the user via SMS - WA has no login, no password, so anyone receiving the SMS can impersonate anyone else.
As Whatsapp does not send any alert of key change by default, the attacker is free to impersonate to person - in this case, he simply asks for some borrowed money to be transferred to a bank account, which will be paid soon. The recipient has no reason to distrust the message - it is being sent by his friend in the same chat window as they always talked to, even the logs are there. There is no message to warn about the potential issue, by design!
This is no hypothesis - this is actually happening for some time, now.[1] This design feature surely has some loyal users.
Unfortunately, if WhatsApp did defend against this, it would be such a big hassle that users would disable it. How many people do you know that wouldn't just click "accept" on "this user's keys changed", or wouldn't just ask the attacker "hey did you get a new phone?" "yes" "oh okay"?
People love to blame WhatsApp, but what can anyone realistically do?
It does not need to be a modal form - a notification message, embedded in the the chat log, just before a "Hey, could you send me some money", could make some people think twice before transferring:
"Wow, he is asking me in excess of USD500 just after WhatsApp warned me his cell phone has changed. Weird".
The simple alert shown in moxie's own blog post [1], perhaps less cryptically written, would probably do the job.
Heck, if this happened between me and girlfriend last week, I would most probably fall, as I did not know this was disabled in WhatsApp. Now, at least, I have turned the notification on.
For the overwhelming majority of people, it would just lead to alert fatigue, where users start ignoring the alerts because 99% of the time they're not actually indicative of a problem.
No, this is why I disagree with Moxie, the right UI design wouldn't have to create fatigue. It could just block by default, and then allow you to change the default with an appropriate warning.
At least that way, everyone will become aware at least once and make their choice.
Everyone (talking about non-technical users here) won't understand why they can't message a particular person any more and will blame WhatsApp "It's broken again". Block by default would kill growth and they don't want that.
>As Whatsapp does not send any alert of key change by default
I don't think that's the case. AFAIK WhatsApp does warn people about key changes with this warning message by default: https://cldup.com/QdUQmjJoF9.png
In fact working with software, at least once a month someone will ask me "Hey, what is this 'Security code has changed' message that pops up every so often about? Do I need to worry about it?"
This has nothing to do with Whatsapp and its use of encryption but is cause by its choice of username and validation method.
The attacker needs to know the phone number and be able to read SMS messages from the phone number. Even very weak methods like the typical security questions would make this much more difficult.
I don't believe it could be done by the thousands, it would be way more targeted:
You'll need to be next to the actual phone number user when you request, and the victim will receive the SMS. Also, the victim would be shut out of WhatsApp (it allows only one client to be active), which would probably trigger some reaction.
Yep, this is an analysis by a trusted individual in the security field. His ultimate summary:
> [WhatsApp's representative is] technically correct. This is not a backdoor. This really isn't even a flaw. It's a design decision that put usability ahead of security in this particular instance.
> How serious this is depends on your threat model. If you are worried about the US government -- or any other government that can pressure Facebook -- snooping on your messages, then this is a small vulnerability. If not, then it's nothing to worry about.
Security isn't either a scale or a binary; from one point of view a large number of binary values.
Either your security will or won't be compromised by a given threat model. This is binary, but there's lots of different threat models one could have.
e.g. If you care about the Russian government impersonating you, it's a different threat model than if you care about the US government reading your communication, which is a different threat model than if you care about a private actor encrypting all your data and holding it ransom.
This is then complicated by the fact that we can't see into the future (sufficiently complicated code is likely to have bugs, we need to predict if those bugs will be exploited before they are fixed; large government attackers may or may not know about math that the public crypto community doesn't; which governments will successfully compel a third party to do various things or reveal various secrets &c.) so each binary value for the security becomes probabilistic.
Come on, a collection of binary values for all of the threat models on a product used by millions of people is a scale by any other name. How good is the product at covering each of the threat models?
The question for me is that posed by the hacker who discovered the vulnerability. Here's what he said [1]:
"He (Moxie) said: “The choice to make these notifications ‘blocking’ would in some ways make things worse. That would leak information to the server about who has enabled safety number change notifications and who hasn’t, effectively telling the server who it could man-in-the-middle transparently and who it couldn’t; something that WhatsApp considered very carefully.”
This claim is false. Those “blocking” clients could instead retransmit a message of the same length that just contains garbage and this message would just not be displayed by the receiver’s phone. Encryption guarantees the garbage or real messages are indistinguishable in the encrypted form. Hence, this technique would make identifying users with the additional security enabled on a large scale impossible."
This was raised in the previous WhatsApp vuln thread but as far as I'm aware, Moxie is yet to address this criticism. Would be good to get a response on this.
The blocking would occur when the server changes the identity key of a user. If the server does that with the goal of finding out if the user has enabled safety number change notifications, it could just change the identity key to one under the server's control and see whether it receives any garbage.
I think you're using a different meaning of "blocking" than Moxie is. I believe they mean "blocking" in the sense of waiting for the user to confirm that the message should be re-sent -- i.e. blocking on the user's input. Whereas you're using "blocking" to mean refusing to re-encrypt the message.
Presumably any message which would be detectable enough as garbage to not be displayed on the reader's phone could be treated as them having this feature enabled, allowing the information-leak Moxie mentioned.
(To be clear, I do think there's a argument to be had over which of these leaks is worse. I just don't think this suggested approach actually addresses Moxie's concern.)
Resending and reencrypting the message mean the same thing here, I don't understand the distinction. Once the user okays the key change it can be resent by encrypting with the new key, before that it would be blocked from being resent.
I know nothing of the signal protocol, but whether the server can tell the message is garbage depends on what the receiver client tells the server. An ideal client would acknowledge receipt to the server but show the user an error (or silently drop the garbage message). From the quote it seems like this is the case, in which case the server can't tell a true message receipt from receipt of garbage and the correlation doesn't work.
> I know nothing of the signal protocol, but whether the server can tell the message is garbage depends on what the receiver client tells the server.
You're forgetting that the server is the one telling the sender what the new key is. If the key is under the control of the attacker/server, they can read the message and determine if it's garbage or not.
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.
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.
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.
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?
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.
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.
If your threat model is the government compelling Facebook, then you should be using a different product that's geared specifically towards security, such as Signal. WhatsApp is a mass-market product aimed at the whole world, which means it makes different tradeoffs, providing a less comprehensive threat model in favor of higher usability. And that's a perfectly fine thing for this app to do.
Yes, thank you. So many people in this thread are making the absurd assertion that security is a binary thing — it's either totally secure against all threats, or it's insecure.
What the security community has spent the last 20 or so years coming to grips with is that it's very hard to cover every attack surface, and not wind up with a product that nobody outside of a select few are smart or dedicated enough to use (e.g., GPG), or that people don't just blindly click through endless warnings (e.g., the not-so-distant days of TLS). What we can do is make incremental improvement over the existing tools that people use by covering more in the threat model or improving the usability such that more people use it and/or fewer people ignore important concerns.
As a mass-market anti-surveillance and privacy-enabling chat app, WhatsApp is an incredible success. It's not replacing GPG with a carefully-curated web of trust. It's replacing plaintext SMS.
There are better tools if you know your threat model includes targeted, high-budget attacks the FSB, NSA, or CIA.
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.
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).
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.
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?
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.
conspicuously missing from this discussion is the self-healing capabilities of the signal protocol, which as far as i understand is a major feature. when marlinspike says, "This is called a \"man in the middle\" attack, or MITM, and is endemic to public key cryptography, not just WhatsApp," i find it odd that he wouldn't even address the fact that the signal protocol has protections against this built into the protocol.
The attacker first try to duplicate the mobile phone number of the first victim, probably by social engineering their phone company. This part may look difficult to do, but it is not hard if you realize you do not need to target anyone special - everyone uses WhatsApp, so any number gives a high probability of success.
After getting the first victim number, the attacker install WhatsApp, which gladly verifies the user via SMS - WA has no login, no password, so anyone receiving the SMS can impersonate anyone else.
As Whatsapp does not send any alert of key change by default, the attacker is free to impersonate to person - in this case, he simply asks for some borrowed money to be transferred to a bank account, which will be paid soon. The recipient has no reason to distrust the message - it is being sent by his friend in the same chat window as they always talked to, even the logs are there. There is no message to warn about the potential issue, by design!
This is no hypothesis - this is actually happening for some time, now.[1] This design feature surely has some loyal users.
[1]http://www.correiobraziliense.com.br/app/noticia/cidades/201...