WhatsApp – Security of End-to-End Encrypted Backups [pdf]
whatsapp.com
whatsapp.com
> Since 2016, all personal messages, calls, video chats and media sent on WhatsApp have been end-to-end encrypted. […]
> WhatsApp’s backup management relies on mobile device cloud partners, such as Apple and Google, to store backups of the WhatsApp data (chat messages, photos, etc ) in Apple iCloud or Google Drive. Prior to the introduction of end-to-end encrypted backups, backups stored on Apple iCloud and Google Drive were not protected by WhatsApp’s end-to-end encryption. Now we are offering the ability to secure your backups with end-to-end encryption before they are uploaded to these cloud services.
I would be surprised, given everything happening in the world today, if the new system does not somehow allow law enforcement to get access (possibly indirectly, through the app giving the key in some weird back channel)
Definitely was not E2EE before.
Whereas ... after that change, Google can read your messages, hackers/law-enforcement only need to talk to Google, and yet -- you yourself can't get that backup without impersonating the WhatsApp app to Google Drive; The local backup is still encrypted with a key that only Facebook knows (and would give you, but only if you impersonate the WhatsApp app when talking to Facebook).
I've looked for the logic and failed. Only reasons I can find is that FB wants to let Google index your messages behind your back (unlikely) or some plausibly deniable legal backdoor.
https://www.theverge.com/2020/12/17/22180258/google-whatsapp...
https://www.theverge.com/2020/12/17/22180258/google-whatsapp...
I am only reachable via email and Signal. I got my contacts to switch to Signal.
This is possible now (in one direction, so far).
However,
> Unfortunately, it’s still not possible to migrate your chat history [from iOS] to a different Android phone, but WhatsApp is planning this in the future. It’s also not possible to migrate your chat history from Android to iOS right now.
You're right that "E2E" is slightly ambiguous. But "encryption at rest" is even worse in my opinion, since it could just mean that Apple/Google's datacenters have disk encryption with a key they can access.
I was referring to the prior backup scheme where Facebook wasn't encrypting. It could accurately be described as encrypted at rest I think, but yet Google and Apple could read the contents I think.
>no ends and it is just a loop.
The terminology is getting pretty confusing at this point. I usually think of the ends as the intended parties to look at the data. If there are no ends, then no one will look at the data, meaning the data is useless. Actually if there's no beginning end, there's no one to create the data, so thus the data doesn't even exist.
But from my understanding, "encryption at rest" is not disk encryption.
If you have a database with disk encryption, once the disk crypto key is entered an attacker could try to "do hacker stuff" and exfiltrate the WAL files.
If you have "encryption at rest", the WAL files are written encrypted and are decrypted on read. An attacker may get your WAL files, but they are still encrypted.
>Encryption at rest is designed to prevent the attacker from accessing the unencrypted data by ensuring the data is encrypted when on disk. If an attacker obtains a hard drive with encrypted data but not the encryption keys, the attacker must defeat the encryption to read the data.
https://docs.microsoft.com/en-us/azure/security/fundamentals...
So with this definition encryption at rest has the threat model of an attacker who can physically steal a hard drive but not the hard drive's encryption key.
Many non-tech people I know that are not aware of this have just come to terms with the fact that phone storage just runs out quicker than it did before, and old phones just lag at 2am for mysterious reasons.
> To avoid excessive data charges, connect your phone to Wi-Fi or disable cellular data for iCloud. iPhone Settings > Cellular > iCloud Drive > OFF.
Like I have to be inconvenienced when I simply want to grab a pdf from iCloud, just to avoid having a few GB of my data cap used if I happen to be out at 2am.
> Many non-tech people I know that are not aware of this have just come to terms with the fact that phone storage just runs out quicker than it did before, and old phones just lag at 2am for mysterious reasons.
Non-tech people get pissed when one smiley message is lost. So for all non-hn people automatic backups are a boon. I know this as we run a free repair-cafe - and help people migrate data from old phones.
The old saying "Actions speak louder than words" has never been more apt. It was just two days ago that Ars & others ran "WhatsApp "end-to-end encrypted" messages aren't that private after all" [1]. Yet, here we are.
It's a strong "No thanks" from me.
[1] https://arstechnica.com/gadgets/2021/09/whatsapp-end-to-end-...
The ProPublica article that the ones you saw are based on was flawed, and has been updated. https://twitter.com/propublica/status/1436054877663375372
>An "end-to-end" encrypted messaging platform could choose to, for example, perform automated AI-based content scanning of all messages on a device, then forward automatically flagged messages to the platform's cloud for further action. Ultimately, privacy-focused users must rely on policies and platform trust as heavily as they do on technological bullet points.
Which doesn't break E2EE technically, but it certainly breaks it in spirit. And yes, I understand that really any application could feasibly implement something like this, it's not in many peoples threat models, etc. However, if I had to bet on which company would implement such a feature, it would be FB.
It just felt sort of funny, seeing this only a few days after all of those articles were written. Of course there is no way FB weaved the whole system and documentation together in two days, but I can't help but roll my eyes slightly at the timing of their release.
I would tell you why, but you're not allowed to according to site rules (it rhymes with 'billing')
E2E is only as secure as the other end.
looks like WhatsApp is appealing, so not a case close.
> noting that WhatsApp did not properly inform EU citizens how it handles their personal data, including how it shares that information with its parent company.
I'm not sure I understand these kind of claims to begin with. WhatsApp is facebook, why would they have to warn users that the data is shared?
How they handle private data, especially if they lie about what they're doing, does really matter. End-to-end encryption doesn't mean anything if they secretly keep the a key able to decrypt it, which is basically what they were getting fined for.
Facebook doesn't think twice about doing highly unethical stuff, covering it up and then lying when it surfaces.
Fish rots from its head and the head is fundamentally rotten.
When Whatsapp wouldnt let me create a group chat without uploading my contacts I was like "yeah.....".
> The key to encrypt the backup is secured with a user-provided password. The password is unknown to WhatsApp, the user’s mobile device cloud partners, or any third party. The key is stored in the HSM Backup Key Vault to allow the user to recover the key in the event the device is lost or stolen. The HSM Backup Key Vault is responsible for enforcing password verification attempts and rendering the key permanently inaccessible after a certain number of unsuccessful attempts to access it. These security measures provide protection against brute force attempts to retrieve the key.
> Additionally, the users have a choice to use a 64-digit encryption key instead of a password, which would require them to remember the encryption key themselves or store it manually as in this case the key is not sent to the HSM Backup Key Vault
So they do allow not storing the key on their servers, which is the only way I know to ensure encrypted backups can't be decrypted, but they make it inconvenient by forcing the key to be 64 digits, for a strength of 10^64.
They could make "no store" keys much easier by allowing the key to be characters, so that people could use a sentence or other sequence of words as a key and not have to write down or remember 64 digits. Using just letters (ignoring case), you'd need at least 46 to get equivalent (12x actually) strength. With uppercase, lowercase, and digits, you'd only need 36 to get 3x the strength of 64 digits.
If users already need to create a password to secure the random key stored on WhatsApp servers, it seems the strength of that password is really the strength of the whole system. In that case, they could just derive a key from the password and use that directly as the encryption key. Assuming they actually want to protect the backup that is.
Disclaimer: I have never used WhatsApp, but am author of HashBackup which does not store your key on any servers.
Not quite. If you trust the HSM that WhatsApp is using the HSMs provide a defense against brute-force attacks that is infeasible with a mathematical key derivation function. For example even with a weak password you could limit an attacker to 10 attempts after which the key is wiped. This isn't something that you can do if your key is only protected my math. With a random 4 digit pin and 10 attempts you can only guess it 1% of the time. With a password you can brute force it until you get it (of course a password with sufficient entropy is probably still out of reach).
Of course trusting their HSMs is a huge if. There are also concerns about refreshing the attempt count (you don't want a brute force attack to wipe your key!) and synchronizing the attempt count across the distributed HSMs. (just enforcing the limit on each is likely to be sufficient though)
Introduction of friction can add security. For example, bitcoin wallets that are self-custody will often involve elaborate, un-skippable "write these 24 words down, repeat it one by one" processes to ensure users properly back up the seed words.
My understanding is they create a random encryption key K and store it in their vault protected by a user-selected password. Knowing the password gets you the encryption key K. I don't see any restriction on a user picking "password123" as their password to the HSM vault, so how does this HSM setup prevent them from "accidentally shooting themselves in the foot with 'password123?'"
I'm not really a cryptographer, but from what I've gathered from a whitepaper, it's just an encrypted backup with a fancy system that allows users to safely store encryption keys on WhatsApp servers. But of course they have to call it end-to-end because users know it is safe
In this case one device makes a backup while another might not be even made yet.
(Edit: Rephrased for better clarity)
If you do not know what end is going to decrypt it, is is just an encryption with a key/password. Anybody who has the credentials can access the data.
These WhatsApp backups could be restored by 50 different 'ends', so using e2e in this context is incorrect.
It’s like equating Fort Knox and a locked car. Fort Knox might not be impenetrable, but they really don’t provide similar levels of protection.
Are you talking about the WhatsApp backup scheme? I think the HSM should theoretically make even a weak password mostly uncrackable.
That’s not what the HSM provides it’s based on this.
OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Computation Attacks: https://eprint.iacr.org/2018/163.pdf
The point of end to end encryption is you don’t need to trust anyone else as long as you verified each parties public keys it’s safe.
This fails that test, The threat model of government surveillance is both up front sniffing of the passwords provided to the server and copying the HSM and doing an offline check of every possible password. Both vulnerabilities are significant issues which allow hackers and state actors to read users backups and thus their messages.
I haven't read either pdfs fully, but it seems to me no password is provided to the server (though I'm actually not sure what you mean by password or server). The OPAQUE protocol means the HSM can verify the user has the password without ever seeing the password. So the password is never provided to the HSM or any other server. It's asymmetric. And for the encryption key, it's stored in the HSM yes, but when sending it to the HSM, it's unsniffable because it's encrypted with the HSM's public key.
>doing an offline check of every possible
The HSM should prevent that by limiting the number of attempts. From the WhatsApp pdf:
>The HSM Backup Key Vault is responsible for enforcing password verification attempts
Of course, if there's a hardware vuln in the HSM, then the verification attempts can be bypassed, and the backup is only secure if the password is quite high entropy. It comes down to how likely there is to be a hardware vuln in the HSM. I think in practice HSMs tend to have hardware vulns somewhat frequently, which is why I said "theoretically" in my previous comment. If we theorize the HSM has no hardware vuln, then it's safe with a weak password. We also have to assume there's no backdoor built into the HSM, or the HSM keypair computation or distribution process.
This means that even if you stop using it today, there is a huge wealth of information about your habits, travel, personal identifiers, social graph, location history, and personal thoughts and opinions that will be permanently stored associated with your name.
Enabling e2e on backups won't purge this information, especially if it has already been downloaded by USG from Apple/Google.
If you want to mitigate this, you basically have to move, replace all your friends/contacts, never go back to the same venues/restaurants/cities, et c, because your existing pattern of life is already archived.
Too little, too late.
People that expected full at rest encryption (which is what a backup system would include) despite the app never being advertised that way would have always needed a large kick to realise that isn't the case. Encryption is complicated and you can't expect everybody to fully understand what e2ee/at rest/etc really means. This whole situation is a learning experience for everyone and I wouldn't blame WhatsApp for it either. They now know that advertising encryption needs a little more explanation.
I recently had the issue for the second time of losing over a year of messages due to dysfunctional WhatsApp backups, about which I wrote a blog post of complaints/rants [1]. The user, as far as I can tell at least on Android, currently has no viable option besides uploading their messages, unencrypted, to Google.
What's the point? I've never felt the need to go back and read any messages I've previously sent. I have no idea why you'd keep them. And also can you imagine if someone got hold of your life's worth of messages?
https://jknewsline.com/parras-email-whatsapp-data-to-be-acce...
Here is how political vendetta is taken against people. This news is just a few months old.
I am not on WhatsApp for a couple of idealogocal reasons, this being one of them
"See? We're not like them"