[triumphantomato]

Wrong.

1. Backups are opt-in - just as they have always been.

2. The E2EE backups do not rely on HSM's - they rely on a client-side only key derived by the WhatsApp client, on the user's phone.

3. The client-side key backup does not rely solely on HSM's - naturally, the client-side key must be backed up in case the user loses their phone. This key is itself encrypted and stored remotely (whether this is on third-party cloud or on WA servers is unclear from the report). However, decrypting it requires a user passphrase, known only to the user.

4. The design uses HSM's additively, not as the only support - via an OPAQUE exchange the user can combine their passphrase with a per-user secret stored in the HSM to derive, client-side, the key that unwraps the backup key. OPAQUE ensures WA cannot learn the user key material required to derive the key that unwraps the backup key.

This is all on page 6 of the published NCC report.

[GekkePrutser]

Additionally, you can also elect to store the raw key yourself (in the form of a 64-digit number). In which case the HSM thing doesn't apply. The caveat is that they can't help you recover it, but in my opinion that's a feature, not a bug. Consider the mud puddle test.

Of course we still have to take their word from it that the app doesn't secretly store this key somewhere. But I suppose this audit will validate that. I have to do a deep dive into it. The problem remains of course that this app can be modified at any time through the update mechanism.

[alerighi]

Last time I looked at it, WhatsApp backup key was simply stored server side. Also, backup encryption key never changes, basically. I tell you this because I needed to extract an old backup that I did on Android years ago to recover some messages: well it was as simple as extracting the key from another phone where I was signed into (need root privileges, but of course you can just access the account from an emulator, insert the SMS code, recover the key and sign in again on the main phone), then the backup is easily decrypted. And no passphrase needed (and even if it is, how it would be difficult to brute force? Considering that users use the same password everywhere...)

This for local backups, but I assume that the encryption schema is the same for a backup on Google Drive (just the file that would be stored locally is uploaded into Google Drive in a non user accessible location).

By the way I don't care that much of backup secrecy, in fact I use mainly Telegram even if everything is on the server clear text. WhatsApp tries to give users a false sense of security in my opinion.

[reissbaker]

I believe you are mistaken, and the NCC group analysis makes it quite clear that the locally-stored backup key is not the same as the "export key": the export key is the encrypted version of the local backup key. WhatsApp servers only have access to the export key, not the local backup key. The fact that you could extract the local backup key with physical access to your device and root privileges does not mean that the key is stored remotely in plaintext.

[ComodoHacker]

How and where did you have a chance to "look at" server side, may I ask?

[savant_penguin]

It may be my fault, but I have always set it to no backups, but 2am it'll more or less freeze with a "backing up..." message

[nitrogen]

I've seen the same thing, and I've never enabled backups. I'd really like to know what it's doing.

[bsaul]

what's the threat this hsm is adding protection against ?

i don't mean to be ironic, i genuinely couldn't understand after reading the paper.

[reissbaker]

The HSM is a server-side HSM. I believe it helps prevent brute-forcing weak passwords/PINs by non-WhatsApp attackers, in case non-WhatsApp attackers gain access to the encrypted backup keys.

[motohagiography]

I was surprised to read that OPAQUE. uses/generates deterministic asymmetric keypairs based on a secret seed. I'd posit the HSM stores this seed so that it can use various derivations to verify whether a given key asserted by a client was generated by that seed. (https://www.ietf.org/id/draft-irtf-cfrg-opaque-07.html)

I have only used key derivation in symmetric protocols, so tbh I don't know how you do deterministic asymmetric key generation, or even which primitive uses it.

[cassonmars]

It can effectively be the same. Consider ECDH as key agreement, passed into a KDF such as a hashing algorithm, potentially with additional input, then using that value as the private key — the security assumptions then become the Square Computational Diffie-Hellman and whatever assumption(s) are in the hashing algorithm, the former is proven to be equivalent difficulty to the general CDH assumption.