"Set up Secure Backup", "Verify with Recovery Key or Phrase", etc, do nothing if 4S secrets are encrypted with the wrong 4S key

[richvdh]

Given an account with:

• m.megolm_backup.v1, m.cross_signing.master encrypted with one 4S (recovery) key
• m.secret_storage.default_key set to another 4S key

Then, there are several flows that just fail silently, or with an unhelpful error message:

Case 1:

• Sign in
• In verification modal, click "Verify with Recovery Key or Phrase"
• Nothing happens

Case 2:

• Sign in, and skip verification modal; alternatively, reload with an existing unverified session.
• Observe "Set up Secure Backup" toast
• Click "Continue"
• Nothing happens

Case 3 (possibly the same as case 1):

• Sign in, and skip "Verify" modal; alternatively, reload with an existing unverified session.
• "Settings" -> "Encryption". Observe "Device not verified".
• Click "Verify this device"
• Click "Verify with Recovery Key or Phrase"
• Nothing happens

Case 4 (will be removed by https://github.com/element-hq/element-web/pull/29088):

• Sign in, and skip "Verify" modal; alternatively, reload with an existing unverified session.
• "Settings" -> "Security & Privacy" -> "Secure Backup" -> "Connect this session to Key Backup"
• Observe:

Case 5 (will be removed by https://github.com/element-hq/element-web/pull/29088):

• Sign in, and skip "Verify" modal; alternatively, reload with an existing unverified session.
• "Settings" -> "Security & Privacy" -> "Cross-signing" -> "Set up Secure Backup"
• Nothing happens

In all cases, the following error appears on the console:

Error: Request for non-default 4S key
    at Object.getSecretStorageKey (SecurityManager.ts:122:15)
    at async ServerSideSecretStorageImpl.getSecretStorageKey (secret-storage.ts:645:26)
    at async ServerSideSecretStorageImpl.get (secret-storage.ts:598:37)
    at async CrossSigningIdentity.bootstrapCrossSigning (CrossSigningIdentity.ts:53:44)
    at async RustCrypto.bootstrapCrossSigning (rust-crypto.ts:738:9)
    at async doAccessSecretStorage (SecurityManager.ts:279:13)
    at async withSecretStorageKeyCache (SecurityManager.ts:191:16)
    at async accessSecretStorage (SecurityManager.ts:233:5)

Workaround

Unless you have another device with working cross-signing and key storage, the only workaround is to perform a reset:

This will reset your message key history and replace your cryptographic identity, but there isn't much choice: the keys to that data have been lost.

Root cause

There is a reasonable question to be asked about how the data got corrupted in this way.

The short answer is: a buggy implementation (probably a Matrix client) did it. With access to the homeserver logs from the time the corruption occurred, it's probably possible to figure out which client was responsible. The problem is, homeservers typically don't store logs for very long, and it's likely the corruption happened weeks, months, or even years ago.

[richvdh]

Fundamentally, the problem in all of these situations is that matrix-js-sdk's ServerSideSecretStorageImpl expects the application to support non-default 4S keys, and EW just doesn't.

We should either strip out the support for non-default 4S keys from matrix-js-sdk (I'm not aware of any applications that make use of there being multiple active 4S keys), or update the API contract to allow applications to indicate that they can't help with non-default keys.

[richvdh]

It would be good to re-test this and see if the symptoms have changed in the light of recent changes such as https://github.com/element-hq/element-web/pull/30230 and https://github.com/element-hq/element-web/issues/30137.

[uhoreg]

Re-tested with recent changes:

Case 1: same result as before

Case 2: get "Verify this session" toast instead of "Set up Secure Backup". Clicking "Verify" pops up a dialog to verify, which basically brings you to the same as Case 1.

Case 3: same result as before

Case 4: removed by https://github.com/element-hq/element-web/pull/29088

Case 5: removed by https://github.com/element-hq/element-web/pull/29088

I think that Cases 1, 2, and 3 are essentially the same now.

[richvdh]

Thanks @uhoreg. I have updated the description accordingly.

[XEVMERSHALL]

I got this issue right after a reset, and now I have to reset again? I never had this issue before the reset.

[XEVMERSHALL]

I can't import room keys on the desktop-client either, that I have saved on my desktop with the filename element-keys, this is before these issues started. There is no visual option to import those keys