Keys are not uploaded to backup if the backup is not signed

[ajbura]

Spec says https://spec.matrix.org/v1.10/client-server-api/#server-side-key-backups : trust can also be determined

by deriving the public key from a private key that it obtained from a trusted source. Trusted sources for the private key include the user entering the key, retrieving the key stored in secret storage, or obtaining the key via secret sharing from a verified device belonging to the same user.

link to problem area:

matrix-js-sdk/src/rust-crypto/backup.ts

Line 306 in cc238c2

if (!trustInfo.trusted) {

should be (as both are part of BackupTrustInfo)

if (!trustInfo.matchesDecryptionKey && !trustInfo.trusted) {

alternative fix at

matrix-js-sdk/src/rust-crypto/backup.ts

Line 132 in cc238c2

trusted: signatureVerification.trusted(),

trusted: signatureVerification.trusted() || backupMatchesSavedPrivateKey

related debugging:

• matrix-js-sdk/src/rust-crypto/backup.ts

  Lines 123 to 124 in cc238c2

  	public async isKeyBackupTrusted(info: KeyBackupInfo): Promise<BackupTrustInfo> {
  	const signatureVerification: SignatureVerification = await this.olmMachine.verifyBackup(info);

• https://github.com/matrix-org/matrix-rust-sdk-crypto-wasm/blob/1499b237364cf5751c64dfbb0c119ebb676ccc3b/src/machine.rs#L1127
• https://github.com/matrix-org/matrix-rust-sdk/blob/57919f5480baa99474bb16ecef94525d78e23107/crates/matrix-sdk-crypto/src/backups/mod.rs#L273
• https://github.com/matrix-org/matrix-rust-sdk/blob/57919f5480baa99474bb16ecef94525d78e23107/crates/matrix-sdk-crypto/src/backups/mod.rs#L95

more details:
one of my account only has device signatures(from logged out devices) in auth_data and missing master_key signature in that case the backup is stalled for forever. Not sure we can also add master_key signature using https://spec.matrix.org/v1.10/client-server-api/#put_matrixclientv3room_keysversionversion without resetting version?

[richvdh]

I'm struggling to understand what the actual problem you're seeing is. Part of the problem is that there is no one meaning of "trusted": it is very much contextual.

As best I can understand:

• You have a key backup which (for some reason?) has not been signed by your master cross-signing key
• However, you also have the private decryption key for this backup and it has been imported (and can therefore successfully decrypt keys retrieved from the backup?)
• Per the spec, the backup should then be "trusted" for the purpose of uploading received message keys to the backup
• However, this is not working.

Is that correct?

[ajbura]

Yes, you got it right, my keys are not uploading.

[richvdh]

Ok. How did you get into the state where you have a key backup that you have the decryption key for, but which has not been signed by your cross-signing key?

Not saying it shouldn't work, it's just not something we've ever come across before and so haven't tested.

[ajbura]

I am not sure, maybe from the client (Element Android probably) i enabled this feature 3-4 years ago have not signed it with master key? and since i never reset it or lost key it remains the same.

it was uploading keys initially but from last 2 years it has stopped (looking at restored keys in new login).

[richvdh]

ok, thanks

[BillCarsonFr]

A better way to fix that would be to correctly sign the backup with the MSK if you properly enter the decryption key.
That would be fixing the Connect this session to key backup button:

[ajbura]

I feel like it will bump the version number and re-upload all the keys? if so, pressing it on the device which has all keys is required. It also adds confusion and not all client has the button.

Is there any particular reason backup with decryption key match is not consider as trusted?

[richvdh]

I feel like it will bump the version number and re-upload all the keys

It won't, but that button is being removed imminently (element-hq/element-web#26468). There was previously some security concern around trusting backups which aren't signed, but I don't think it matters here.

The concern is specifically: suppose you have another compromised, or buggy client (see, for example, GHSA-hw6g-j8v6-9hcm); that buggy client might (incorrectly) accept the decryption key from an attacker's device. It could then share those keys with other (correctly-functioning) devices, causing them to also trust the key backup.

However, I think that attempting to work around that is a fool's errand: if the other device is that buggy, you've pretty much already lost. In particular, requiring the user to enter the recovery key (as @BillCarsonFr's suggestion implies) doesn't really solve the problem, because the buggy device could just as well upload the malicious decryption key to 4S, or sign it with the MSK, or do 100 other incorrect and insecure things.

[ajbura]

It won't, but that button is being removed imminently (element-hq/element-web#26468). There was previously some security concern around trusting backups which aren't signed, but I don't think it matters here.

On the side not I want to clarify that I am not reporting it as a specific client user but as sdk consumer.

I was working on cinnyapp/cinny#2168 when i find this bug and it is a not good for user to verify themself first and later asking for recovery key to reset the backup. And automating it via secret received by the verification process can further complicate the situation of backup between devices (it won't be good choice to automate such action anyway).

[ajbura]

Since the https://spec.matrix.org/v1.10/client-server-api/#put_matrixclientv3room_keysversionversion allow changing the auth_data can adding just signature considered as an option?