From d90aeda65836590b42e5f455ddfc22dccb8140fb Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Fri, 14 Dec 2018 00:14:03 -0500 Subject: [PATCH] draft of alternate proposal for cross-signing --- proposals/xxxx-cross-signing.md | 135 ++++++++++++++++++++++++++++++++ 1 file changed, 135 insertions(+) create mode 100644 proposals/xxxx-cross-signing.md diff --git a/proposals/xxxx-cross-signing.md b/proposals/xxxx-cross-signing.md new file mode 100644 index 00000000..a1b3cf55 --- /dev/null +++ b/proposals/xxxx-cross-signing.md @@ -0,0 +1,135 @@ +Each user has a "master identity key" that is used to sign their devices, and +is signed by all of their devices. When one user (Alice) verifies another +user's (Bob's) identity, Alice will sign Bob's master identity key with her +master identity key. (This will mean that verification methods will need to be +modified to pass along the master identity key.) Alice's device will trust +Bob's device if: + +- Alice's device has signed her master identity key, +- her master identity key has signed Bob's master identity key, +- Bob's master identity key has signed Bob's device, and +- none of those signatures have been revoked. + +If Alice believes that her master identity key has been compromised, she can +revoke it and create a new one. This means that all trust involving Alice +(i.e. Alice trusting other people and other people trusting Alice) needs to +start from scratch. + +The master identity key's private key can be stored encrypted on the server +(possibly along with the megolm key backup). Clients may or may not want to +store a copy of the private key locally. Doing so would mean that an attacker +who steals a device has access to the private key, and so can forge trusted +devices until the user notices and resets their master key. However, not doing +so means that when the user verifies another user, they will need to re-fetch +the private key, which means that they will need to re-enter their recovery +key to decrypt it. + +When a user logs in with a new device, they will fetch and decrypt the private +master key, sign the new device's key with the master key, and sign the master +key with the device's key. + +Users will only be allowed to see signatures made by their own master identity +key, or signatures made by other users' master identity keys on their own +devices. + +# API description + +## Possible API 1 + +Use the same API as MSC1680, but with additions. + +API to create new virtual device: + +`POST /devices/create` + +returns + +``` javascript +{ + "device_id": "ABCDEFG" +} +``` + +Send public key using `/keys/upload` as a normal device, but with a special +"algorithms" list: + +`POST /keys/upload` + +``` javascript +{ + "device_keys": { + "user_id": "@alice:example.com", + "device_id": "ABCDEFG", + "algorithms": ["m.master"], + "keys": { + "ed25519:ABCDEFG": "base64+public+key" + }, + "signatures": { + "@alice:example.com": { + "ed25519:ABCDEFG": "base64+self+signature" + } + } + } +} +``` + +(This may require changes in what `device_id`s are accepted by `/keys/upload`.) + +Attestations/revocations will be uploaded and retrieved as described in +MSC1680. Creating a new master key would involve revoking the old master key +by sending a signed revocation and deleting the device using `DELETE +/devices/{deviceId}`, and then creating a new master key. + +Private master key could be stored as part of the key backup (MSC1219), maybe +as a special room ID + session ID, or possibly in the `auth_data` for the +backup version (the latter would mean that changing the master key would +require creating a new backup version, which may be what users need to do +anyways). Or the private master key could be stored in account data, +e.g. `/user/{userId}/account_data/m.master.{deviceId}`. + +## Possible API 2 + +Treat master key separately from normal devices and adding special handling for +them. This might result in a nicer API, but make the implementation more +complicated. For example, the server could automatically add master key +signatures into a device's `signatures` field, rather than shipping the +attestations separately. + +TODO: write this option out + +# Comparison with MSC1680 + +MSC1680 suffers from the fact that the attestation graph may be arbitrarily +complex and may become ambiguous how the graph should be interpreted. In +particular, it is not obvious exactly how revocations should be interpreted -- +should they be interpreted as only revoking the signature created previously by +the device making the revocation, or should it be interpreted as a statement +that the device should not be trusted at all? As well, a revocation may split +the attestation graph, causing devices that were previously trusted to possibly +become untrusted. Logging out a device may also split the attestation graph. +Moreover, it may not be clear to a user what device verifications would be +needed to reattach the parts of the graph. + +One way to solve this is by registering a "virtual device", which is used to +sign other devices. This solution would be similar to this proposal. However, +real devices would still form an integral part of the attestation graph. For +example, if Alice's phone verifies Bob's tablet, the attestation graph might +look like Alice's laptop <-> Alice's virtual device <-> Alice's phone <-> Bob's +tablet <-> Bob's virtual device <-> Bob's desktop. So if Bob replaces his +tablet without re-verifying with Alice, this will split the graph and Alice +will not be able to verify Bob's other devices. In contrast, in this proposal, +Alice and Bob's master keys directly sign each other, and the attestation graph +would look like Alice's phone <-> Alice's master device <-> Bob's master device +<-> Bob's tablet. In this case, Bob's tablet can be replaced without breaking +the graph. FIXME: graphviz-ify the attestation graphs + +With normal cross-signing, it is not clear how to recover from a stolen device. +For example, if Mallory steals one of Alice's devices and revokes Alice's other +devices, it is unclear how Alice can rebuild the attestation graph with her +devices, as there may be stale attestations and revocations lingering around. +(This also relates to the question of whether a revocation should only revoke +the signature created previously by the device making the attestation, or +whether it should be a statement that the device should not be trusted at all.) +In contrast, with this proposal, there is a clear way to rebuild the +attestation graph: create a new master identity key, and re-verify all devices +with it.