protecting data at rest : encrypt data before writing them to disk.
e2e encryption : block should be encrypted by the sender ( in our case : the host) . Not applicable for now.
key rotation : use a new key to encrypt new data without losing the ability to decrypt old data. Should be used periodically, or at least after an attacker got the keys.
Veeam : https://helpcenter.veeam.com/archive/backup/95/vsphere/encryption_standards.html
- To encrypt data blocks in backup files and files archived to tape, Veeam Backup & Replication uses the 256-bit AES with a 256-bit key length in the CBC-mode. For more information, see http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf.
- To generate a key based on a password, Veeam Backup & Replication uses the Password-Based Key Derivation Function, PKCS #5 version 2.0. Veeam Backup & Replication uses 10,000 HMAC-SHA1 iterations and a 512-bit salt. For more information, see http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf.
key exchange https://signal.org/docs/specifications/doubleratchet/#symmetric-key-ratchet
easy to develop, quite easy to manage , but weak : an attacker with access to the host files will be able to obtain the key
easy to develop, easier to manage, but even weaker : an attacker will only need a xo account to decrypt data. Since the data are store unencrypted in redis, an attacker with access to the host will also be able to read this without an xo account.
will need a user intervention when restarting xo-server
need a manual intervention on service restart (to enter the master key/connection key). This step should be done after asking for our communtiy which provider to support ( hashicorp vault, amazon , google, keycloack for example)
if the key is compromised we should be able to update the key
slow, costly but easy and ensure that the attacker won't be able to recover any fragment of data after
store in the block metdata the hash / reference of the key used. When encrypting : use the most recent key. When decrypting : use the key referenced in the block metadata. That way an attacker with the knowledge of a key won't be able to get the new data, making the disk image unreadable.
- a file on the host with the keys algorithm + hash + value . File may be store on an encrypted partition
- a parameter on the remote to activate encryption only for vhd directory
- saving the key hash in the
filtersfie during backup - add an option to export the key files during a XO configuration export
- changing a key will means that the merge will fall back to download/decrypt/crypt/upload until the next full backup
- deleting the keys file on the xo host will means all data are irrecoverable
Step 2:
- encryption of the key file, maybe linked with the TPM feature