After key storage remove/add on another client, Web fails to detect that key storage is out of sync
Steps to reproduce
- Have 2 active devices. Web and EX, all verified with all secrets cached locally
- On EX go to encryption settings then turn off key storage and follow the indications
- From EX: Turn back key storage On
- From EX: Then click on setup recovery, and follow instructions
- Go to web
Outcome
What did you expect?
Expect that Web tells me that the Recovery is out of sync
What happened instead?
But Web is just offering me the option to change recovery key.
(At this point web do not have the correct secret for the backup. But it has the correct cross-signing private key.) It is possible to continue the flow
and change the recovery key (even though web do not have the correct backup key).
This can be seen if you try import from backup
As a consequence if I now try to login with that new recovery key, I loose access to backup:
rageshake.ts:69 SecurityManager: accessSecretStorage: error during operation Error: loadSessionBackupPrivateKeyFromSecretStorage: decryption key does not match backup info
at RustCrypto.loadSessionBackupPrivateKeyFromSecretStorage (rust-crypto.ts:1281:19)
at async SetupEncryptionStore.ts:155:25
at async doAccessSecretStorage (SecurityManager.ts:299:9)
at async withSecretStorageKeyCache (SecurityManager.ts:189:16)
at async accessSecretStorage (SecurityManager.ts:231:5)
Operating system
macos
Browser information
Chrone
URL for webapp
app.element.io
Application version
Element version: 1.11.91 Crypto version: Rust SDK 0.8.0 (21f7cc7), Vodozemac 0.8.1
Homeserver
matrix.org
Will you send logs?
Yes
@BillCarsonFr Editorial note, for the sake of clarity & consistency, please use "key storage out of sync" not "recovery is out of sync".
@poljar thinks this info might not come over sync, so we will need to poll for new backups to detect this. Further, it almost certainly needs fixing on EX as well as Web.
@poljar thinks this info might not come over sync, so we will need to poll for new backups to detect this. Further, it almost certainly needs fixing on EX as well as Web.
If the user resets recovery, then we can see that the account data changes. If the user only sets up key backup, then we don't get anything over sync, so we'd need to poll (or else wait for a key upload to fail). At the very least, when the user opens the Encryption settings page, it should check the backup, and see if we have the matching private key. And if not, inform the user and offer a way to fix the situation (either get the key from 4S if it's there, or else create a new backup).
Suggested solutions:
- fix https://github.com/element-hq/element-meta/issues/2865 so that we get the new backup key when it is changed, which should reduce the chances of this issue being triggered
- if the secret storage account data changes, check if we have the right key for the latest backup version. If not (after waiting a little bit for the secret to be shared from the device that changed the backup), prompt the user to enter the Recovery key
- when the user opens the Encryption settings tab, check the backup and see if we have the correct key. If we don't, and Recovery is set up, indicate that there is a problem, and prompt the user to enter the Recovery key or to create a new backup. If we don't have the correct key, and Recovery is not set up, indicate there is a problem, and prompt the user to create a new backup.