TPM/TXT auto-unseal

[DemiMarie]

Is your feature request related to a problem? Please describe. HSMs are expensive and require Vault Enterprise. KMS solutions only work in the cloud. TPM-based auto-unseal would allow for auto-unseal based on measured boot.

Describe the solution you'd like Vault should support unsealing via a TPM.

Describe alternatives you've considered None

Explain any additional use-cases This would be useful for those who want to run Vault on a bare-metal server, especially individuals for whom the cost of an HSM and/or Vault Enterprise would be difficult to justify. In home lab situations, automatic unseal after power outages is important.

Additional context It would also be nice if the TPM could be used for the server certificate or (more likely) for decrypting its secret key.

[drewhemm]

Auto-unseal can be done on a bare-metal server using cloud encryption services such as AWS KMS - the server itself does not need to be hosted in the cloud. All it needs is outbound Internet access, credentials to authenticate to the cloud and permissions to use a key. KMS pricing is $1 per month so inexpensive too.

TPM would be nice, but at least there is an easy and cheap alternative in the meantime.

[DemiMarie]

Auto-unseal can be done on a bare-metal server using cloud encryption services such as AWS KMS - the server itself does not need to be hosted in the cloud. All it needs is outbound Internet access, credentials to authenticate to the cloud and permissions to use a key. KMS pricing is $1 per month so inexpensive too.

TPM would be nice, but at least there is an easy and cheap alternative in the meantime.

The purpose of the TPM is measured boot: if the system is tampered with, it will not be able to unlock its keys. Nevertheless, there is likely a better solution: store the unseal key in an ordinary file, but use full disk encryption with TPM-sealed keys. That covers all of the use-cases I mentioned above, and more.

[DemiMarie]

On further thought, this is not actually true, especially if Linux’s Integrity Measurement Architecture (or similar) is employed or if the root filesystem is on a read-only dm-verity volume. Also, TPM auto-unseal could be much easier to setup than TPM-based encryption, especially on older distributions.

[joshenders]

Interested in this as well but afaict there's a lot of work here and I'd be surprised if this made it into any OSS offering.

[DemiMarie]

Interested in this as well but afaict there's a lot of work here and I'd be surprised if this made it into any OSS offering.

I hope it does. HSM-based auto-unseal only makes sense for enterprises, but auto-unseal based on Dynamic Root of Trust for Measurement (DRTM) makes a lot of sense for individuals.

[jbielick]

I find this very interesting. To confirm some of the assumptions or tradeoffs here, I think it's worth mentioning that TPM auto-unseal could only function in a cluster size of 1 (non-HA) unless the unseal key was migrated to the TPMs of the other cluster members (shared).

For the join process to work, all nodes in a single Raft cluster must share the same seal configuration.

https://developer.hashicorp.com/vault/docs/internals/integrated-storage#raft-leadership-in-vault

I take the documentation's meaning as "must share the same key material" due to the "encrypted challenge/answer workflow".

[heatherezell]

Thank you for your interest in this! If you are interested in seeing this feature in Community Edition, please upvote the issue and we will take it under consideration for future planning. Please also feel free to add additional use cases. Please avoid “+1”, “me too”, and “any updates” comments. Thanks very much!