a twisted way to use the keyfile repo format

[anarcat]

Hi,

I've been struggling with automating borg backups for a while. For the longest time I've either used unencrypted repositories (for local backups) or repokey with a strong password (for offsites), but I've always had trouble with the latter because it requires me to input a password every time I backup, which means I typically do it by hand, so not frequently enough.

So let's fix this.

I think I found a hack that could work. The basic principle I'm thinking of is to use a remote repository with in keyfile mode (so the key is stored locally) with an empty passphrase, but with an encrypted backup.

I think the following would get me what I want:

export BORG_PASSPHRASE=`pass show backup`  # pass(1) holds the strong password
borg init --encryption=keyfile ssh://example.com/srv/borg/repo
borg key export ssh://example.com/srv/borg/repo | ssh example.com tee /srv/borg/encrypted-key-backup # backup the password-protected key remotely
export BORG_NEW_PASSPHRASE=""
borg key change-passphrase -v ssh://example.com/srv/borg/repo

at this point, the remote server should have a backup of the local keyfile in /srv/borg/encrypted-key-backup but that key should be password protected, while the local server has a passwordless keyfile.

Therefore, now, this should just work without a password:

borg create ssh://example.com/srv/borg/repo::test /

... while still being able to survive a complete server loss.

What am I doing wrong?

[ThomasWaldmann]

Having a unique key passphrase hard-coded in a backup script or easily accessible in an unlocked keyring is a problem if an attacker has access to your machine (like e.g. via a trojan).

Having an unprotected borg key (no passphrase) and a trojan would be an equivalent problem.

[anarcat]

well the weak key is on the backed up server: there, of course, an attacker can read and write all the files so that's not part of my threat model.

my threat model here is that the attacker has full access to the backup server. i wonder if, then, it can start reading files in the backup, by abusing the backed up keyfile there. presumably, the backed up keyfile (/srv/borg/encrypted-key-backup in my scenario above) would be safe if it has a strong passphrase, even though the original keyfile on the server has a weaker passphrase?

of course, if an attacker compromises both servers, we're screwed, but then I can't think of a model where that's not the case: someone can always take both machines and throw them in a volcano.

i do wonder if such a setup would be sufficient to protect a compromised backup client from ransomware attacks; with the "new" append-only stuff, i guess it wouldn't be able to purge backups on its own, right?

one of the key question that's not fully clear to me is what sort of protection a borg key export file has. The manual says:

the exported key stays encrypted

... but not explicitly something like:

the exported file has the same properties as the original encryption key

You know what I mean?