Cross signing

[fkwp]

Highlevel description

Prevent man-in-the-middle attacks on e2ee by adding the ability to a) verify a user (rather than a device) and automatically trust any devices they have verified themselves, and b) publish the verification of our own devices to the network. In the context of Hydrogen, this will also require a framework to establish trust of other devices, which is lacking currently.

This is an epic issue. List of individual issues is below:

### Linked Tasks
- [ ] See linked tasks in the comments
- [ ] Implement Emoji verification (only for verifying MSKs, not device keys, although don't design out the latter entirely)
- [ ] Implement uploading cross-signing signatures for other users
- [ ] Implement signing with our USK for other users' MSK
- [ ] Implement signing with our SSK for own devices identity keys
- [ ] Implement transitive (cross-signing) trust architecture
- [ ] Secure Secret Storage and Sharing (SSSS) write support
- [ ] Bootstrapping cross-signing (creating keys etc.)
- [ ] Implement QR code verification

[genofire]

related : https://github.com/vector-im/hydrogen-web/issues/518

[bwindels]

Some notes how to make bootstrapping more reliable from eleweb: https://github.com/vector-im/element-web/issues/13581#issuecomment-1154420509

[bwindels]

We are starting to groom this epic in more depth.

To remain fast, we would like to cache and persist the signature validations of:

• user device with their SSK (self-signing key), can store validation in deviceIdentities store?
• their SSK with their MSK (master signing key), can store validation in userIdentities store?
• their MSK with our USK (user-signing key), can store validation in userIdentities store?
• our USK with our MSK, can store validation in account store?
• aggregate and cache whether or not we trust all the users and devices in an e2ee room, can store validation in roomSummary store?

We were discussing whether there are cases whether we won't be told if any of these keys change, and therefore we could see a different trust than clients that would fetch the signatures everytime trust is calculated (not sure anyone does that?) but the spec seems to mentions that key changes are communicated in sync in the device_lists field.

https://spec.matrix.org/latest/client-server-api/#cross-signing

Would still be good to ask other clients if there is any good reason not to implement this cache.

[bwindels]

A change in any device or any users trust needs to purge the cache and recalculate trust from device to the user to all the room that user is in (which we already store in the userIdentities store).

[bwindels]

Need to split out detailed tickets for all tasks:

• [ ] verify other user
• [ ] verify device signature using x-sign key chain
• [ ] ...

[bwindels]

After having checked with other app teams about the caching strategy, valere said this:

It's cached on current implementation too. We store a trusted boolean attached to user identities (like for devices actually). We are probably recomputing too much, mainly because we prefer to be up to date on shields rather then out of sync. We only recently started optimize that a bit on android. The real problem we have in EA now is that at some point a shield (person or room) is dirty and need to be validated again, but we don't have that reflected in the model. In the model it's a boolean, but it should be 3 states (trusted, untrusted, checking/loading). The lack of this state leads to several races and unwanted popups, like you just verified, and you see a popup to verify your existing devices. Actually they are fine but it's still checking (trusted=false still though).. If you are fast enough, it maybe not needed, but I'd recommand to have a 3 state flag for trust? Also android modelize user trust by using the 3 keys MSK/USK/SSK (own user) - or 2 MSK/SSK(other user) each of them having a trusted flag, It's probably better to have a single UserIdentity object and hides the key details(edited)

[bwindels]

Order of implementation:

• assume Element does the bootstrapping initially
• implement verifying our own MSK based on the private MSK key stored in 4S upon entering your passphrase
• implement signing our own devices and other users
• sign our own device if not signed yet after entering passphrase and MSK checks out
• implement verification (e.g. emoji and QR)
  • could split up here in verifying our own devices (with to_device transport) and verifying other users (with timeline event transport).
• implementing the shields (doing the signature verification but not signing yet), the signature is included in the section for the signed key in the /keys/query response for that user. We can't do this as the first point because we can't yet trust our own MSK, as we don't have a means of verifying either another client or verifying that the private key in 4S checks out with the published MSK.
• implement cross-signing boostrapping
• implement write support 4S

[bwindels]

Implement shields:

• we need the keys of all members in a room to be able to show the room shield. we probably at least want to show the shield in the room header when you open the room. Element does not show the shield in the left panel, probably precisely for this reason. Showing the shield implies tracking the room (downloading members, downloading their keys and tracking and member device changes) so does that render the optimizations to not track the room until we send our first message obsolete?

[genofire]

There is already crosssinging in features. what is done of this issue?

[MidhunSureshR]

@genofire You can only sign your own device now