[SOLVED] Encrypting a passphrase make any sense?

[vcmota]

I don't know for sure that this question even make sense, since asymmetric encryption implies in a public key, a private key and a passphrase, which the owner of the key should hold. If it is encrypted, my guess is that the owner would also have to hold another passphrase for the second encryption and so on. But here it goes the question anyway: Is it possible to store a passphrase in an encrypted file to help automate file signing with duplicity or gpg?

Let me elaborate a little more. I am using duplicity for a while now to handle my offsite backups. However, the whole process is mainly manual, since I want both encryption and signing. Since I use asymmetric encryption, the encryption part could easily be automated, but what about the signing part? As far as I know either gpg and duplicity would always ask for my passphrase for signing a file in the moment of signing. One way out would be to write my passphrase in some file that duplicity reads, but that would expose my passphrase in the case that I do something stupid and somehow the content of this specific file became disclosed. Is there anyway around this or the question don't even make sense?

Thank you all.

[Hu]

There is no perfect solution. Either the system can operate without your intervention, in which case it can be operated without your consent; or it cannot be operated without your assistance, in which case it only operates when you consent. If you want automated signing, you could have a signing-specific key with no passphrase on it, or with the passphrase loaded into an agent and given a long lifetime. In the former case, the passphrase is only secured by other access controls on the system (limitations of who can login, whether they can read the file, etc.). If the system can be rebooted into an attacker-controlled environment, then a passphrase-free key is completely vulnerable to that attacker.

Loading the key into an agent is a little bit better. It requires you to intervene once per boot to load the key, but then the system runs unattended from there. That key is not vulnerable to an offline attack, but again depends on system security to protect the agent from unauthorized use.

[javeree]

Hu is right,

using an agent you can limit the amount of times you need to give the passphrase that protects your encryption key. In the end, as you realised yourself, whatever scheme you come up with, it is passphrases all the way down. The only thing you can do is create a scheme that in the end hinges on some kind of 'super-grandmaster phrase' that starts the unlocking of all the other ones.

I have been struggling with the same thing, as I have an unattended backup server, and I wanted it to be able to reboot and backup into an encrypted disk without me having to ssh in to give the passphrase. Since this is on a LAN, my solution was to store the encrypted passphrase on a different PC (which I'll call vault), and the private and public key for that encrypted passphrase on the backup server.

before backup, the backup script requests the encrypted passphrase from vault using ssh with public authentication (therefore only the backup pc can ask for the encrypted passphrase). It then decrypts he passphrase and unlocks the disk before starting the backup. At the end of the backup, it closes the disk (and has forgotten the passphrase.
with this scheme, someone stealing the backup PC cannot decrypt the disk, as the passphrase is on vault, while someone stealing vault, cannot decrypt the passphrase because the private key for that is on backup.
The resulting scheme basically says 'as long as the backup PC and the vault PC can communicate, it is possible to open the backup drive.

So what if someone steals/accesses both backup and vault ?
Well, vault happens to be a PC that I actively use, so I logon on a regular base, and it too has an encrypted drive that opens when I logon. The encrypted passphrase is on that encrypted drive. So in the end, it IS passphrases all the way down...

[Ant P.]

Not much you can do about signing (maybe a TPM module?), but you can encrypt to a key that isn't stored on the same system.

[John R. Graham]

We use these (Safenet / Gemalto eToken 51xx series) to provide tamper resistance and anti-cloning protection for important asymmetric key credentials. It still leaves you with a decision on what to do with the passphrase but ensures that no one can walk off with a copy of your private key. No TPM required.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[Ant P.]

Oh right, forgot those were a thing for a second. Come to think of it, USB hardware tokens are probably the best you can do here as most of them integrate directly with gpg with no hacks necessary.

[vcmota]

Thank you all guys for your replies.

My threat model today consistis mostly of

1) someone stoles my hardware (PC or/and external HDs) and try to access my files. I have full disk encryption in place with a long dice wise passphrase but I am no expert, not sure that I did the full disk encryption without any flaws;

2) someone hack its way into my system via internet. Although I am basically nobody, specially in the internet, I guess that is always a possibility;

So in this case I suspect the current manual signing is probably the best option for me, even if it makes the off site backup forcefully manual.

As always happens in this forum I learned o lot from your replies, so thank you all again.