At the moment encrypted backups are performed as follows:
- a symmetric key is acquired from the crypto manager, generating one if needed
- a cipher output stream is created using the symmetric key
- a ZIP stream is created, wrapping the cipher stream
- the files to be backed up are added to the ZIP stream
Backups with HMAC signature are performed as follows:
- A mac key is acquired from the crypto manager, generating one and adding it to admin data if needed
- Backup data is hashed with the mac key
- The mac key ID is stored in the .info file, it is used to retrieve the mac key from crypto manager at the time of restoring
There are a couple of issues with these approaches:
- the same symmetric key is used for all backups, as well as for other purposes such as DB and changelog encryption, although typically DB and backup encryption are not used simultaneously.
- the keys are stored separately from the data, which may provide a bit more security, but makes the backups less portable since they are effectively "locked" to their deployment
- the symmetric key encrypts the entire DB content which could be very large and potentially exceed the usage limitations of the key if a transformation like AES/GCM is used for which there is a 64GB limit. (This problem will be fixed with
This issue may be closed once:
- the backup mechanism generates new keys for each backup file using a key derivation algorithm that takes a nonce and the master private key and then stores the nonce in the backup file. The HMAC key and encryption key should be different. To restore the backup the restore tool simply needs access to the master private key to obtain the key.
- we ensure that backups do not use AES/GCM and instead use AES/CBC, which is what we were using in 6.5 and earlier, because this cipher mode has a recommended 2^48 messages usage limit (~ 4 PiB). If users want integrity protection then they can hash/sign the backup. (This is optional because backup files will be small after