Hi, I want to backup encrypted data (file-based with cryptfs) locally on a harddisk. Therefore I take the decrypted files out of a virtual cryptfs-drive and encrypt them again in the backup. Is Kopia suitable for that?
Does Kopia store any unencrypted data (e.g. in a database), file-/foldernames or passwords locally on disk?
Thanks in advance
Kopia stores a lot of data (cache etc) locally. Content and metadata in the cache is encrypted. I don’t know if other locally stored information could leak data.
You could try to keep kopia data in one “safe” location with environment variables.
KOPIA_CONFIG_PATH
KOPIA_LOG_DIR
KOPIA_CACHE_DIRECTORY
You can provide the repository password via the KOPIA_PASSWORD environment variable.
(But swap space and other general security concerns still apply of course).
As far as I am aware, Kopia does not store any unencrypted data in the repository, so the contents and layout of your backup files are not available unless you decrypt the repository and mount snapshots.
When you snapshot a directory, everything is transparently encrypted for you. You should backup the decrypted contents of your drive into the Kopia repository since you otherwise you won’t be able to take advantage of Kopia’s deduplication and compression effectively. And since the contents are encrypted, you don’t need to do any other forms of encryption.
Kopia does leak metadata to logs and also caches the passwords locally by default, which allows you to make snapshots in the future without having to first enter a password. Depending on your threat model, these may or may not be an issue for you. If your computer is encrypted and you are the only one who can access it, then it may not be an issue. If not, then you can take the appropriate steps to mitigate the information leak (e.g. by disconnecting the repository after every snapshot, and setting up to log into a volatile location).
Thank you, I avoided encryption methods of operating systems, it’s unsafe. An option would be container based Veracrypt. But one encryption method should be enough.
So I have two possibilities:
-
Backup of the already encrypted gocryptfs files. Nevertheless deduplication and splitting should work, compression not. Problematic when something goes wrong with gocryptfs encryption, then the error will be backuped too without being recognized.
-
Try to put all sensitive data of Kopia in the gocryptfs drive and backup the rest of the decrypted drive. The same uncertainty as above, because the kopia files cannot be saved by itself, when the backup runs.
Wouldn’t it be an idea to combine both programs? There are encryption programs like cryptomator, cryfs, gocryptfs, but a backup program could do the same if it would be able to mount a virtual drive and work directly with files out of the backup?
There are 3 places where sensitive data can be found:
-
config dir - today kopia does not encrypt the config file, so credentials to the underlying storage (e.g. s3 access tokens) can be found there. This will be fixed in future release by encrypting the entire config file with user-provided password or encrypting sensitive portions/keys/passwords.
-
cache directory - it’s all encrypted today with the exception of index files (sndx), which are decrypted after fetching from the repository for quick access. The index files contain mapping of content hashes to blob names (basically random >=128-bit numbers on both sides), and thus they are not terribly sensitive, but they reveal some statistics about number of files, etc. and possibly they can be used to determine if a particular file or portion of the file (known only by the hash of its contents) is in the repository and when it was added.
There are some ideas in this space for keeping index files encrypted, but the security of this is not really understood yet.
- logs - they will contain filenames, usernames, etc.
If the OS keychain is not available and the user chooses to persist the repo password, kopia will also store the repository password in base-64 encoded file next to the config file (this is on Linux, as mac and Windows generally have the keychain available)
If you are concerned about this, then you probably shouldn’t be using Kopia (as main backup tool). It is much more likely that there is a problem with Kopia than gocryptfs. Kopia is still alpha quality and had a major “format” change recently.
Thank you all. With the 4 environment variables it should be possible to make it fairly safe. As long as anything else is performed in RAM (disabling swap) there should be no traces any more. OS encryption and key-wallets can be replaced by open source solutions (standard keepassxc).
Best solution for safety is a complete encrypted Linux in a container. But windows will will haunt me for a while yet.