Open tscherf opened 6 years ago
I'm interested in this, too. I'd like to have several available factors, one of which I'd like to be a password which can be printed as QR code and put in a safe. The version of clevis from 2+ years ago supported both pwd and http...why'd those go away?
I'm also interested in this. I'll would like very much to be able to have unlock with tpm + password. This would allow to mitigate some weaknesses of both tpm (cold boot attack) and password (brute force).
In addition, it should be possible to update one of the tpm's PCR with a hash computed from the password to ensure the tpm secret remain sealed until the correct password is provided.
would also love to see this
use case: setting up a trustworthy physical machine which contains a semi automated workflow for root ca crl generation
we already use vault and hence SSS with t>=3 to assure that not one person alone can unseal the vault, but to satisyf our paranoia towards untampered helper scripts we'd love the ability to integrate SSS in luks open of the root volume
because then noone with physical access to this machine could do bad things
Yes please. I'm rather uncomfortable with the current scheme where a stolen device would be able to be booted, as that allows things like cold boot attacks or waiting for a privilidge escalaction exploit for the installed kernel version. :+1:
Is cold boot attack even a real possibility? Sounds like a pretty intense threat model I just use TPM with clevis and keep my gnome password on. Pretty much covers all bases.
This would allow to mitigate some weaknesses of both tpm (cold boot attack) and password (brute force).
To add, when using password alone, you might not know your system was compromised by an evil maid until it's too late. However, if you add TPM2 measurements in the mix (Secure Boot, etc.), this is mitigated, as password won't unlock the disk of the compromised system.
People are interested in the password pin support when clevis is used with sss. This ticket is to track the interest.