diff --git a/proposals/3270-symmetric-megolm-backup.md b/proposals/3270-symmetric-megolm-backup.md new file mode 100644 index 00000000000..007b28c541b --- /dev/null +++ b/proposals/3270-symmetric-megolm-backup.md @@ -0,0 +1,135 @@ +# MSC3270: Symmetric megolm backup +The current megolm backup uses asymmetric encryption. This was chosen so that +clients without the private key can still add their own megolm sessions to the +backup. This, however, allows a homeserver admin to inject their own malicious +megolm session into someone’s backup and then send an encrypted message as a user +that they wish to impersonate. Due to this, some clients such as Element [warn the +user](https://github.com/vector-im/element-web/issues/14323#issuecomment-740855963) +that a message cannot be authenticated when the megolm session for that +message was obtained from backup. + +Using symmetric encryption for megolm backup would fix this attack vector, +since keys added by untrusted devices would be undecryptable, thus allowing keys +obtained from backup to be trusted. Additionally, many clients cache the +megolm private key anyway, making the original reason for choosing asymmetric +encryption obsolete. + +**Credits:** This proposal was originally written by @sorunome. + +## Proposal +This proposal introduces a new megolm backup algorithm, `m.megolm_backup.v1.aes-hmac-sha2`. +The backup method `m.megolm_backup.v1.curve25519-aes-sha2` +is deprecated. + +### `session_data` +The session data of the megolm backup is an object containing the `iv` property +and the `ciphertext` property. Below is described how to generate these from +the megolm backup key. The data to be encoded is the same JSON-encoded data as +in `m.megolm_backup.v1.curve25519-aes-sha2`. + +As such, a complete `KeyBackupData` object could look as follows: + +```json +{ + "first_message_index": 0, + "forwarded_count": 0, + "is_verified": true, + "session_data": { + "iv": "cL/0MJZaiEd3fNU+I9oJrw", + "ciphertext": "WL73Pzdk5wZdaaSpaeRH0uZYKcxkuV8IS6Qa2FEfA1+vMeRLuHcWlXbMX0w" + } +} +``` + +### Encryption +Room keys are encrypted using AES-GCM using the following process: + +1. Encode the session key to be backed up as a JSON object with the same + properties as with `m.megolm_backup.v1.curve25519-aes-sha2`, with the + addition of an optional property `untrusted`, which is a boolean indicating + whether the Megolm session should be considered as untrusted, for example + because it came from an untrusted source. If the `untrusted` property is + absent, the key should be considered as trusted. +2. Given the megolm backup key, generate 32 bytes by performing an HKDF with + SHA-256 as the hash, a salt of 32 bytes of 0, and with `|` as the info. This is the AES encryption key. +3. Generate 16 random bytes, and use this as the AES initialization + vector. This becomes the `iv` property, encoded using unpadded base64. +4. Stringify the JSON object and encrypt it using AES-GCM-256 using the AES key + and initialization vector generated above. This encrypted data, encoded + using unpadded base64, becomes the `ciphertext` property. + +### `auth_data` +Similar to symmetric SSSS, the `auth_data` object in the `versions` reply +contains information to verify that you indeed have the correct private +key. For that, you generate a random initialization vector and encrypt the +empty string using the method above, and put the `iv` and the `ciphertext` into +the `auth_data` object. For session ID and backup version, an empty string is +used. As such, a reply to the `versions` endpoint could look as follows: + +```json +{ + "algorithm": "m.megolm_backup.v1.aes-hmac-sha2", + "auth_data": { + "iv": "cL/0MJZaiEd3fNU+I9oJrw", + "ciphertext": "+xozp909S6oDX8KRV8D8ZFVRyh7eEYQpPP76f+DOsnw" + }, + "count": 42, + "etag": "meow", + "version": "foxies" +} +``` + +### Secret key storage +The secret key for symmetric megolm is stored in SSSS base64-encoded with the +name `m.megolm_backup.v1.`. + +### Transitioning to symmetric backup + +Clients that implement this backup method should consider older clients, +which will not be able to use backups created using this method. For example, +clients can initially be updated so that they will be able to use backups +created using this method, but not yet create new backups using this method. +Some time later, once the client author deems that a sufficient number of +clients have been updated to use the new backup method, the client can be +modified such that new backups are created using this method. + +## Potential issues +Many users already have an asymmetric megolm backup and rely on it. In order to +not lose any megolm keys, clients would have to implement a migration to +symmetric megolm backup. When doing so, the existing keys should be marked as +untrusted. + +## Alternatives +An earlier version of this MSC used the same encryption as is currently used in +[symmetric +SSSS](https://github.com/matrix-org/matrix-spec-proposals/pull/2472). However, +it was +[later](https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients) +noted that this method is not "IND-CCA2 secure". As a result, it now uses +AES-GCM-256 instead. + +The authenticity of keys could be established in backups using the +`m.megolm_backup.v1.curve25519-aes-sha2` algorithm by adding a signature or a +MAC. However, this would require managing another key for the key backup. It +would be easier for clients to only need to manage one key. + +## Security considerations +The proposed method requires clients to cache the encryption key for the key +backup. This means that an attacker who compromises a client that uses the key +backup will have access to all the key stored in the backup. Since most +clients already cache the decryption key for current backups, this is not a +change from current practice. + +To migrate an existing backup to the new method, clients will need the SSSS key +to read the existing backup and to store the key for the new backup. When the +user enters the SSSS key, the client will have access to all of the other +secrets stored in SSSS. In general, most users already trust their clients +with their secrets, or could select a trusted client to perform the migration. + +## Unstable prefix +While this feature is in development, implementations should use +`org.matrix.msc3270.v2.aes-hmac-sha2` as the backup algorithm. + +`org.matrix.msc3270.v1.aes-hmac-sha2` was used in a previous version that used +AES-CTR-256 for encryption.