Desynchronized Secret Storage

[BillCarsonFr]

4S (secure secret storages and sharing) contains a set of secrets securely encrypted and stored server side. This meta issue is created to record the different cases when the secrets contained in 4S are outdated/missing.

The consequence of this problem is that even if you enter the correct 4S passphrase/passkey you won't be able to get a properly working session.

This issue is specifically for when the secrets in 4S do not match the published cross-signing keys or the current backup key. If it's just the client that is out-of-date and that just need to ask for the passphrase then it's another kind of problem.

Technical Inputs

How could the 4S end up with wrong secrets?

The 4S contains the msk/usk/ssk/megolm_backup, and they are stored encrypted in account_data.

But changing the cross-signing keys or the backup are independent APIs that can be called and that will not update the 4S.

Some examples:

• A client resets the cross-signing key, but does not update the 4S just after (the 4S will have the old private keys)
• A client creates a new key backup, but doesn't update the 4S after.
• If a client deletes a backup without updating the 4S, then if there was a previous backup version it will become the current one; in this case, 4S will still have have a key, but not the correct one.

Well-behaved clients are expected to maintain the 4S in sync, but it's still possible that some clients do not behave correctly.

So there should be a way for a client to "Fix the recovery".

Clients should ensure that they can update the 4S before making changes to cross-signing or backup. The operation should also be atomic: in case of forgotten passphrase/password, it should be possible to revert back to a working setup.

It is also possible that the account_data has been modified manually (eg, via dev tools or direct API calls). Clients should be careful when trying to fix 4S, when some account_data are missing/malformed, as this is controlled by the server.

List of related issues:

• Desynchronized 4S | Megolm backup causing Unusable backup element-android#5906
• Restore from backup failure after backup has been re-created from another session element-web#22036
• Element-R: aborting cross-signing reset leaves the account in a broken state element-web#26322
• "Reset Backup" creates 4S without cross-signing keys element-web#27806
• Room key backup is not enabled when you already have 4S without key backup element-web#27952

[richvdh]

So there should be a way for a client to "Fix the recovery".

Is this correct? Is it even possible to fix recovery once things have broken? Or is it better that we change the design of the protocol to minimise the chances of the problem arising, eg with a transactional API where nothing changes until it is "committed"?

[BillCarsonFr]

So there should be a way for a client to "Fix the recovery".

Is this correct? Is it even possible to fix recovery once things have broken? Or is it better that we change the design of the protocol to minimise the chances of the problem arising, eg with a transactional API where nothing changes until it is "committed"?

It could be possible, maybe another session has the correct key cached locally. Maybe you could extract it?
If not the fix could be to reset what is out-of-sync, but would need some thinking.
All in all I think it should be possible.

Or is it better that we change the design of the protocol to minimise the chances of the problem arising

That would be nice if possible

[richvdh]

It could be possible, maybe another session has the correct key cached locally. Maybe you could extract it?
If not the fix could be to reset what is out-of-sync, but would need some thinking.
All in all I think it should be possible.

Hrm. Doesn't sound very reliable. And having to reset is pretty bad. I'd vote in favour of expending effort on avoiding the problem in the first place.