Cross signing: implement signing our own devices

[bwindels]

Depends on #953

Once we can trust our MSK with #953, we can now also trust the USK (User Signing Key) and SSK (Self Signing Key). The private keys for these are again stored in 4S, but verification should rather rely on the signatures from the MSK. We should only require to have the private keys when we actually want to sign something.

• derive USK and SSK trust from parent key signature (MSK). This will not contain the hierarchical caching system for signature validation we eventually want, see #957 for that.
• sign own device with SSK
• publish signature
• sign other users with USK and publish signature

[bwindels]

One note on the above, when we have the private MSK, we'll also have the private SSK and USK as they are all unlocked with the 4S key. So verification ... probably still good to check the signatures are ok, but we can rely on the private as well...

[bwindels]

This is just adding support in code without exposing it in the UI, this happens in the next issue #955

[bwindels]

Steps for own device signing

• fetch SSK + signature
• verify SSK signatures from MSK
• get device key for our own device (already supported), the ed25519 one?
• calculate signature with SSK
• upload signature

[bwindels]

For signing other users and other devices apart from the current one:

• rework way device keys are stored
  • so we can:
    • also store cross-signing keys in same store
    • store signatures
    • store in format as returned by server as that is what we have to calculate signatures on
  • for this, we'll:
    • rename deviceIdentities store to userKeys store
    • rename userIdentities store to userKeyTracking store
    • store device/msk keys in device format as returned by server
    • keep signatures in there, so we can later verify them if needed

[bwindels]

Ah but we have an index on the curve25519 sender key for device keys which we don't have for cross-signing keys 🤔

[bwindels]

For signing other users and other devices apart from the current one:

• add crossSigningKeys store, key by userId|key, we also need to look up by userId|usage (which can contain multiple usages), have an multi index on here? How about IE support?
• store signatures in deviceIdentites
• remove crossSigningKeys from userIdentities
• rename userIdentities to userKeyTracking?

[bwindels]

From uhoreg:

The usage field gets included when calculating the signature, so an attacker can't get you to sign something and try to use the signature for something else, since the key indicates what the signatures can be used for. It is an array because we thought it might be useful to allow some key types in the future to have multiple usages, but you shouldn't have multiple usages with cross-signing.

So, in the end, we will:

• create new crossSigningKeys store with the key being the userId and the usage of the key (we don't need to look up by public key, we'll usually verify from the MSK down to device keys, so we already have the parent key in memory)
• store keys there not in response format but our own, smaller, format
• store signatures in deviceIdentities