You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The TPM2 policy can validate an RSA signature on a set of PCRs and unseal the disk encryption secret if the PCRs match the signed values. This potentially means that the disk recovery key is not necessary for updating the kernel, since the UEFI platform key (stored in a yubikey) can both sign the new kernel as well as the future PCR measurements for when that kernel is booted.
However, this now requires somewhere for the PCR signature to live. The sealed secret can be persistent in the TPM, but the signature is a separate file. It can't go into the (signed) initrd or command line since that would change the PCRs. It could live in the ESP somewhere, but then the initrd would need to mount that and walk it to find the file.
Maybe that is ok?
The text was updated successfully, but these errors were encountered:
The TPM2 counters could also be used to prevent rollback. They are different than the TPM v1.2 counters in that arbitrary NV data may be used as a counter object. However, I don't see a way to use them in a fleet-wide way. There is no way to assign a specific value to a counter (which is good), so the policies would have to include the machine specific values. This unfortunately means that signatures would have to be machine specific, rather than across all machines.
The safeboot luks-seal work flow needs an overhaul to separate sealing the disk key (which requires the recovery key and setting an optional PIN), from the safeboot linux-sign, which will sign both the kernel/initrd as well as the new PCR values. However, where to store the signature and PCRs is still an open question.
As mentioned in this comment: #10 (comment)
The TPM2 policy can validate an RSA signature on a set of PCRs and unseal the disk encryption secret if the PCRs match the signed values. This potentially means that the disk recovery key is not necessary for updating the kernel, since the UEFI platform key (stored in a yubikey) can both sign the new kernel as well as the future PCR measurements for when that kernel is booted.
Intel describes how to configure the policy: https://software.intel.com/content/www/us/en/develop/articles/code-sample-protecting-secret-data-and-keys-using-intel-platform-trust-technology.html#inpage-nav-2-4
OpenSSL engine can do the operations with the yubikey:
However, this now requires somewhere for the PCR signature to live. The sealed secret can be persistent in the TPM, but the signature is a separate file. It can't go into the (signed) initrd or command line since that would change the PCRs. It could live in the ESP somewhere, but then the initrd would need to mount that and walk it to find the file.
Maybe that is ok?
The text was updated successfully, but these errors were encountered: