search

element-hq / element-meta

Shared/meta documentation and project artefacts for Element clients
72 stars 12 forks source link

Desynchronized Secret Storage #2322

Open BillCarsonFr opened 7 months ago

BillCarsonFr commented 7 months ago

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:

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:

richvdh commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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.

BillCarsonFr commented 6 months ago

I hope this is the right issue for this

Doesn't look like it. This issue is for case when you correctly enter you recovery key and then you can't import from backup or your session is still unverified.

Maybe it's more that https://github.com/element-hq/element-meta/issues/2327? Some keys are not in the backup?

Anyhow maybe you should open an issue in the web repo describing your problem with some logs.