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

[BillCarsonFr]

A session which was previously using legacy crypto (and was verified), is now showing previously trusted users with red shields after migration to rust-crypto.

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

Alternative
We could also migrate local trust?.
Given that anyhow if we had performed a verification with the "legacy account" for a new rust session, at the end the new rust session would trust the identity

[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 matrix-org/matrix-js-sdk@9d1c713

[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 matrix-org/matrix-js-sdk#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.