3 ms·

> To decrypt the backup, the key K is needed Thus, to safeguard K in the HSM-based Backup Key Vault, the client performs a registration of K with WhatsApp. > T

by prirun 5y ago

> To decrypt the backup, the key K is needed Thus, to safeguard K in the HSM-based Backup Key Vault, the client performs a registration of K with WhatsApp. > 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.

habibur 5y ago
Best comment so far.
kevincox 5y ago
> it seems the strength of that password is really the strength of the whole system 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)
dannyw 5y ago
I think WhatsApp's proposed solution here is sensible and achieves both objectives of protecting user privacy whilst also preventing users from accidentally shooting themselves in the foot with "password123". 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.
- prirun 5y ago
  > I think WhatsApp's proposed solution here is sensible and achieves both objectives of protecting user privacy whilst also preventing users from accidentally shooting themselves in the foot with "password123". 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?'"

by prirun 5y ago

habibur 5y ago

Best comment so far.

kevincox 5y ago

> it seems the strength of that password is really the strength of the whole system 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)

dannyw 5y ago

I think WhatsApp's proposed solution here is sensible and achieves both objectives of protecting user privacy whilst also preventing users from accidentally shooting themselves in the foot with "password123". 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.

prirun 5y ago
> I think WhatsApp's proposed solution here is sensible and achieves both objectives of protecting user privacy whilst also preventing users from accidentally shooting themselves in the foot with "password123". 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?'"