Hi,
First thanks for this very nice piece of software. The general setup of restic is quite easy and the software is very speedy.
In restic (0.18) when copying snapshots from one repository to another, it is necessary to provide the repository encryption key (of both sides), which is understandable as it’s necessary to be able to know the relationships between files and packs.
However, this means that in order to implement restic copies for a typical 3-2-1 backup approach to an offsite location, you need to disclose the key of the data to the system that makes the copy.
This is introducing a risk as if a hacker get access to the software where the copy is made, it will have both access to the key and the data.
By introducing a differentiated key for the repository and for the data encryption, it could be possible to manipulate the backup data using repository keys, while not being able in anyway to get access to the data without the data decryption key. The data key can then be kept on the initial server and in a secure location only available to persons allowed to decrypt the data.
I was wondering if this has been thought off ?
Thanks
Ludovic
If you are implementing a 3-2-1 scheme, you can just use tools like rclone copy to pull over new data without being able to decrypt it. Is there some reason this approach would not work in your case?
This approach consumes significant more space as it does not allow to delete any snapshots individually and/or use different retention periods on each side.
During the copy operation, restic requires the key to not only unlock the repository but also decrypt the data and then re-encrypt the data to the new repository location. It will be a significant CPU and I/O intensive operation.
In terms of your question the data key is required for the copy operation. So the location where the copy operation is running definitely requires the key to decrypt and then use the new repositories encryption keys to re-encrypt the data. You can also refer restic’s threat model; where some of the key assumptions and threats are identified. The host system where you run the copy operation must be trusted.
@ldubost what do you mean by a differentiated key? (not familiar with this encryption terminology)
Hi,
Thanks for the answer.
What I mean is currently to run a backup you do
restic -r –password-file backup …
If you were running:
restic -r –password-file –data-password-file backup …
And file names and content were encrypted using this specific encryption key (or the key stored in a key file unlocked by that specific password), then the restic copy operation, which would not need access to this key, because it does not really need to know what it’s processing, would not need the same trust level than it currently needs.
While it could be a point were data can be destroyed, it would not be a place where data can be stolen.
When needing access to the data, you would need to also provide this key to decrypt the file names and the data.
These passwords can be secured differently in order to allow retrieving the backups whenever needed. This is an approach that we are using on our backup system, which are stored on off site platforms but never requiring the key to decrypt the data, in order to manage which backups we have.
The keys are secured using a master key which are stored separately.
Ludovic
If I understood it correctly, you are proposing one encryption key which will be used for management and another key that encrypts the data.
The restic copy doesn’t lift and shift blobs; it decrypts, re-encrypts and writes. To decrypt, it must read the data. The copy operation unavoidably needs the data key as well.
To provide the functionality you are asking for would require re-architecting the key management and encryption IMO.
Indeed this might require some modified key management and encryption.
It would however add a extra level of protection on the backup data while allowing efficient storage management.
Thanks for the input.
1 Like