📝Backups should be using asymmetric encryption
Most backup solutions today () seem to be based on symmetric cryptography—the key to create a backup is the same key used to restore it and for maintenance work.
This seems unfortunate as it increases the risks:
- You want backups automated, which means that either the key shall be stored without a password, or the password is stored somewhere nearby. This increases the risk of key compromise.
- Multiple backup client are likely using the same encryption key (it’s usually the same key per repository). This means that one client may access the backup created by another one. This is bad if one of your devices is less trusted (e.g. mobile phone or something that can be stolen or compromised more easily).
- There’s also no authentication, so one compromised device may create a backup in the name of another one. If the attacker is able to trigger a restore, they may put/modify files on the target machine (e.g. adding their own key to authorized_keys)
Backups should be using asymmetric encryption and signcryption. A backup agent should create a backup that gets encrypted to the restore’s public key. The private part of the restore key can be stored offline or protected with a password that is not written down.
Furthermore, the backup agent shouldn’t need a read access on the backup repository—append-only access should be enough. This reduces the risk of data exposure or backup getting destroyed in case device gets compromised. For example, ransomware is known to try destroying backups.
The hard parts:
- Making the deduplication work across backup agents. The agent needs to know what chunks already exist in the repository. Simultaneously, exposing chunk hashes from one agent to another allows fingerprinting attacks.
- Maintenance. Pruning old backups that are no longer necessary requires read-write access.