A method for cheap hardware-based unseal with open source vault

Caveat: this method is not for very high value secrets, where you want to protect the secrets even against somebody breaking into a machine running vault. It does however, I think, protect against anybody discovering the secrets from backup copies.

I recently learned that gpg can store its keys on cheap smartcards, including Yubikeys:

I’m not using this in production, but I did a proof of concept where I could create a vault store that I can scriptably unseal while storing the base encryption key in a yubikey 4 where it can’t be read back. I initialized the key and store with these steps:

  1. gpg --expert --full-gen-key, select 4096-bit encrypt-only key with name “vault seal”, email vault@seal, and no passphrase.
  2. Move the key to the yubikey with gpg --edit-key and keytocard.
  3. gpg -a --export vault >vaultseal.pub
  4. vault operator init -key-shares=1 -key-threshold=1 -pgp-keys=vaultseal.pub
  5. copy/paste the given unseal key into vaultseal.gpg.b64
  6. vault operator unseal $(echo 123456|gpg --passphrase-fd=0 --pinentry-mode=loopback --decrypt <(base64 --decode </etc/vault/vaultseal.gpg.b64))

The reason why it doesn’t protect against breakins into the machine is that an attacker could run the command in backquotes and get the unencrypted unseal key, but a backup will be fully encrypted. On the other hand if you have a mechanism to exclude certain files from backup, you could store the unseal key unencrypted and just keep that file from getting backed up.

What I think would be ideal would be an unseal mechanism builtin to vault that was integrated with opensc the way gpg is.



I would love to see official support for something like this. I have been looking at using a TPM to store unseal keys for isolated systems that might lose WAN connectivity but still need to automatically unseal.