From 6d0d9e27cf2a8bced350e2c0a786fcdabac6d986 Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Wed, 23 Aug 2023 15:53:07 -0400 Subject: [PATCH] initial version of signed key backup proposal --- proposals/xxxx-signed-key-backup.md | 108 ++++++++++++++++++++++++++++ 1 file changed, 108 insertions(+) create mode 100644 proposals/xxxx-signed-key-backup.md diff --git a/proposals/xxxx-signed-key-backup.md b/proposals/xxxx-signed-key-backup.md new file mode 100644 index 00000000..9d7001eb --- /dev/null +++ b/proposals/xxxx-signed-key-backup.md @@ -0,0 +1,108 @@ +# MSCxxxx: Signed key backup + +The [server-side key +backups](https://spec.matrix.org/unstable/client-server-api/#server-side-key-backups) +allows clients to store event decryption keys so that when the user logs in to +a new device, they can decrypt old messages. The current algorithm encrypts +the event keys using a symmetric algorithm, allowing clients to upload keys to +the backup without necessarily giving them the ability to read from the +backup. For example, this allows for a partially-trusted client to be able to +read (and save the keys for) current messages, but not read old messages. + +However, since the event decryption keys are encrypted using a symmetric +algorithm, this allows anyone who knows the public key to write to the backup. +As a result, keys loaded from the backup must be marked as unauthenticated, +leading to [usability +issues](https://github.com/vector-im/element-web/issues/14323). + +[MSC3270](https://github.com/matrix-org/matrix-spec-proposals/pull/3270) tries +to fix this issue by using a symmetric, authenticated encryption algorithm, +which ensures that only someone who knows the secret key can write to the +backup. However this removes the ability for a client to be able to write to +the backup without being able to read from it. + +We propose to continue using a symmetric encryption algorithm in the backup, +but to ensure authenticity by signing the backup data. + +## Proposal + +A user has a new signing key, referred to as the "backup signing key", used to +sign key backups using the ed25519 signature algorithm. The private key can be +shared/stored using [the Secrets +module](https://spec.matrix.org/unstable/client-server-api/#secrets) using the +name `m.key_backup.signing`. + +The `AuthData` object for the [`m.megolm_backup.v1.curve25519-aes-sha2` key +backup +algorithm](https://spec.matrix.org/unstable/client-server-api/#backup-algorithm-mmegolm_backupv1curve25519-aes-sha2) +has a new optional property called `signing_public_key`, contains the public +key of the backup signing key, encoded in unpadded base64. If the `AuthData` +is not signed by the user's master signing key or by a verified device +belonging to the same user, the backup signing key must be ignored, and all +keys in the backup must be treated as being unsigned. + +The `SessionData` object for the `m.megolm_backup.v1.curve25519-aes-sha2` key +backup algorithm has two new optional properties: + +- a `signatures` property: the `SessionData` is a [signed JSON + object](https://spec.matrix.org/unstable/appendices/#signing-json), signed + using the backup signing key, using the public key (encoded in unpadded + base64) as the key ID +- a boolean `authenticated` property, defaulting to `false`: indicates whether + the device that uploaded the key to the backup believes that the key belongs + to the given `sender_key`. This is true if: a) the key was received via an + Olm-encrypted `m.room_key` event from the `sender_key`, b) the key was + received via a trusted key forward + ([MSC3879](https://github.com/matrix-org/matrix-spec-proposals/pull/3879)), + or c) the key was downloaded from the key backup, with the `authenticated` + property set to `true` and signed by a trusted key. If the `SessionData` is + not signed by the backup signing key, then this flag must be treated as being + `false`. + +The `mac` property in the cleartext `session_data` property of the +`KeyBackupData` is deprecated. Clients should continue to produce it for +compatibility with older clients, but should no longer use it to verify the +contents of the backup if the `SessionData` object is signed. + +## Potential issues + +As the `AuthData` is changed, a new backup version will need to be created. A +client will need to download all existing keys and re-upload them. + +In order to store a new secret in the Secret Storage, clients may need to +prompt the user for the Secret Storage key. Clients may need to do so already +to download all the current keys from the backup. + +## Alternatives + +As mentioned above, we could switch to using a symmetric encryption algorithm +for the key backup. However, this is not backwards-compatible, and does not +allow for clients that can write to the backup without reading. + +## Security considerations + +Being able to prove authenticity of keys may affect the deniability of +messages: if a user has a Megolm session in their key backup that is signed by their +backup signing key, and the session data indicates that it originated from one +of their devices, this could be used as evidence that the Megolm session did in +fact come from them. + +This is somewhat mitigated by the fact that obtaining the Megolm session +requires the decryption key for the backup. In addition, the deniability +property is mainly refers to the fact that a recipient cannot prove the +authenticity of the message to a third party, and usually is not concerned with +preventing self-incrimination. And in fact, a confiscated device may already +have enough information to sufficiently prove that the device's owner sent a +message. + +## Unstable prefix + +Until this MSC is accepted, the property name +`org.matrix.mscxxxx.signing_public_key` should be used in place of +`signing_public_key`, and `org.matrix.mscxxxx.authenticated` should be used in +place of `authenticated`. No unstable prefix is used for the `signatures` +property since it uses the existing definition of JSON signing. + +## Dependencies + +None