Newly created Secure Backup Key refused by Element iOS

[NicolasBuquet]

Steps to reproduce

1. Element iOS launched on device, Element web launched in browser on same account as Element iOS
2. Regenerate a Secure Backup key on Element web
3. Eventually disconnect Element iOS from internet during 1 minute during step 2
4. on Element iOS, try to recover message from secure backup using the newly generated Secure Backup key from web session

Outcome

What did you expect?

I expected the Element iOS app to accept the new Secure backup key and restore the messages.

What happened instead?

The Secure Backup key is refused by Element iOS although it is the active Secure Backup code on the account.

Video showing the bug

20240111d_element_secure_backup_bug.mp4

Your phone model

iPhone 15 Pro simulator

Operating system version

iOS 17.0

Application version

Element iOS 1.11.5

Homeserver

matrix.org

Will you send logs?

No

[NicolasBuquet]

The Secure backup key verification fails here in the matrix-ios-sdk :

func validPrivateKey(forRecoveryKey recoveryKey: String, for keyBackupVersion: MXKeyBackupVersion) throws -> Data {
        let key = try BackupRecoveryKey.fromBase58(key: recoveryKey)
        guard key.megolmV1PublicKey().publicKey == publicKey(for: keyBackupVersion) else {
            throw Error.invalidPrivateKey
        }
        
        let privateKey = try MXRecoveryKey.decode(recoveryKey)
        log.debug("Created valid private key from recovery key")
        return privateKey
    }

Account data sample :

Printing description of JSONDictionary:
{
    algorithm = "m.megolm_backup.v1.curve25519-aes-sha2";
    "auth_data" =     {
        "public_key" = qUqwkb21yIJbeconn6wPivnpydHMBhnbHNV8QWyxrwY;
        signatures =         {
            "@xxxxx.yyyyyyy-beta.gouv.fr:agent.dinum.tchap.gouv.fr" =             {
                "ed25519:YPJAZRHKVW" = "xexoRSskmVDb4HT0did...G1wXsOzas6R7LfNzLA/eU44UdxgNQZHah9w2sborqf/+GBw";
                "ed25519:r5lpLNTV+66IGMBbJFKk2uJGmmmkHP7Zo1oedzyBzfM" = "Mx6SdshgOm+zlYn0RITvXjR1ku...T0r4B0VoSG33Ut5sF7lDFRKaATTS1XNBmWPUNiErlICg";
            };
        };
    };
    count = 8934;
    etag = 45;
    version = 30;
}

Result of publicKey evaluation inside Xcode session :

recoveryKey.megolmV1PublicKey().publicKey
    [MXCryptoSDK] DEBUG matrix_sdk_crypto_ffi::backup_recovery_key: megolm_v1_public_key
    "yE6IkfNFJT8wltlLtn/w7zXPSLSGLVFl/wFEgHi2KXQ"

key.megolmV1PublicKey().publicKey
    [MXCryptoSDK] DEBUG matrix_sdk_crypto_ffi::backup_recovery_key: megolm_v1_public_key
    "5IvnKhpDt4e/diKoGSU7Vc2rAiNmZHtFXJvX0wh1iFU"

@pixlwave can you evaluate the severity of this issue?

[giomfo]

When you create a new secure backup on the Element Web client, the potential existing backup are not deleted. So here your iOS session stayed connected to the previous backup. This is on purpose to not lose an existing backup when the user creates a new one from the wrong device. Indeed here the user should take back the control of the backup from the iOS session not the web.

When you click on "Restore from Backup", the iOS session is prompting you for the security key of the previous backup. The key of the new backup doesn't match here. When you logout/login on iOS, the new session is ready to restore from the most recent backup.
(Instead of logging out the iOS session, you may have to Delete backup on the iOS session. Then the iOS session would be ready to restore from the new backup)

An enhancement here would be to let the end user select the right backup in the iOS session (Help the user to know about these 2 backups, and how to deal with them):

• Restore from the previous backup (which may be the most relevant backup), and then eventually be able to switch on the new backup to upload all the key in this new one.
• Directly switch on the new backup (with the risk of lose some keys, indeed some remotely stored keys may not be available locally (so a restore from the previous backup is recommended)))

I will highlight internally this feedback, at least to take it into account in EX

[NicolasBuquet]

@giomfo Thank you for this explanation.

I understand technically, but this is a nightmare for the user because essentially nothing inform him of the existence of the multiple versions backup.

The different backups should at least be listed user side.