WebR: Sometimes after migrating to rust crypto the existing session reverts back to untrusted

[BillCarsonFr]

A session in legacy crypto, which appears verified, is suddenly showing previously trusted users with red-shields. The current session is not trusted anymore, as shown in the settings

What's happening

It's a case of partially known secrets. The legacy session is missing the MSK private key (not in cache). In legacy, after verification when the cross-signing keys are trusted the public part of the keys are persisted locally, thus making them locally trusted.

Later in the process, the private keys would be requested to other sessions. In some cases the m.request.secret can fail (network issue, the original session was missing them), so you could end up with a trusted session that only has some of the private cross-signing keys.

It is also possible that you have a quite old session, and at some point on web the MSK was not cached locally. Notice that any session verified from a session with partial secrets, will also have partial secrets (verification will be succesfull marking the cross signing keys as trusted, but secret gossiping will only get you what the original session has)

When we migrate the account over to rust crypto, the local trust flag of cross-signing keys is lost. Rust crypto will only consider the current session as trusted if we import the private cross-signing keys correctly.

Solution

WebR should prompt users when the current device is not trusted, and ask them to verify. It appears that this is done only after login? Currently if the cross signing keys are reset from another session web (including legacy) is not prompting the user to verify again?

This flow should be customised after migration, to display a specific copy: Title: "Security upgraded" Message: "Secure messaging has been improved with the latest update. Please re-verify your device."

Similar issues on EAR and EIR https://github.com/element-hq/crypto-internal/issues/58

[BillCarsonFr]

Found some RS showing the existence of legacy sessions with partial secrets. Can be seen from the RS details:

cross_signing_master_privkey_cached: false
cross_signing_self_signing_privkey_cached: true
cross_signing_user_signing_privkey_cached: true

https://github.com/matrix-org/element-web-rageshakes/issues/25123 https://github.com/matrix-org/element-web-rageshakes/issues/25078 https://github.com/matrix-org/element-web-rageshakes/issues/24832 ...

[BillCarsonFr]

Web started caching the MSK mid 2020 https://github.com/matrix-org/matrix-js-sdk/commit/9d1c7136cc67a067de46d928bd13cee608231772

[richvdh]

A couple of points:

• We might not have any other devices to verify against, so forcing the user to verify is not an option in that case. (Entering the 4S passphrase is also an option if 4S is set up; otherwise the user has to reset cross-signing)
• Even if we successfully verify, we still might not end up with the private MSK. That doesn't matter here, because the device we verify against will tell us if we can trust the public key. That said, it seems very odd to me that we are prepared to take the word of another device about whether we can trust the public MSK, whereas we are apparently not prepared to take the word of the legacy crypto stack.

[BillCarsonFr]

Additional details, the root cause for WebR not prompting users when the current device is not trusted has been found and fixed here https://github.com/matrix-org/matrix-js-sdk/pull/4156

The bug was preventing the DeviceListener to ask for re-verification https://github.com/matrix-org/matrix-react-sdk/blob/bd7ce7cda9c0dcb0cc150d1bd76fbe72da609306/src/DeviceListener.ts#L303C15-L303C30 Thus not triggering https://github.com/matrix-org/matrix-react-sdk/blob/bd7ce7cda9c0dcb0cc150d1bd76fbe72da609306/src/DeviceListener.ts#L317

Now that the fix has landed, session that reverted to untrusted after migration (before the migrate local trust patch), and went unnoticed by their user, will be prompted to verify.