I'd like to implement something like a write-once public/private encrypted shared secret (no better quick description for the lack of terminology knowledge). I guess, I'm trying to implement HSM.
The scheme goes as follows:
- given a secret (e.g. 512 characters long string)
- generate a public & private key pair
- encrypt the secret with the public key, for private key to decrypt
- encrypt private key, to a hardware token key (OpenPGP smartcard, yubikey, FIDO secure key, TPM etc.) such that only the hardware token can decrypt it.
- destroy public key, destroy plain copy of the secret key
The following properties are achieved:
- given that public key does not exist, no other encrypted secret can be created for that private key.
- both encrypted secret & encrypted private key can be stored externally and transmitted via insecure channels
- to unlock the secret, both encrypted secret & encrypted private key must be presented to the hardware module that does on-chip decryption of the private key & decrypts the original secret which is presented back
- a single hardware token can unlock unlimited amount of secrets (as they are stored externally)
- it's not possible to tell which hardware token can unlock which secrets
Are there fallacies in above argumentation and is it a reasonable scheme? Can a public key be derived from ciphertext & encrypted secret key? Can a public key be derived from ciphertext & decrypted private key? (assuming hardware token is flawed and exposed it externally)
Essentially, I'm trying to create a multi-factor scheme to store shared secret which is used for full-disk encryption (LUKS / cryptsetup). With above to access unlocked encrypted disk I'll need to have:
- encrypted private key
- hardware token to unlock the first two (e.g. smart card)
- smart card pin
But I can reuse the smart card for multiple secret/ciphertext/private-key combinations. Or am I unnecessary complicating things, and should simply encrypt the shared secret with a smart card?