I am currently using Aeon on fallback FDE mode. This works well enough, but I am using it with a Thinkpad X1 tablet, so whenever I need to restart/shutdown the device I have to attach some sort of keyboard. GNOME’s login screen does support an OSK so it would be ideal if there was a way I could maintain my FDE whie not having to use the BIOS passphrase.
I have a TPE 2.0 module but it does not seem to support PolicyAuthorizeNV so I cannot use the default method. Is there a way I can still utilise my TPM module and maintain FDE with Aeon so I can get to the login screen instead of the passphrase on restart? I see you can add tokens here here but I’m not sure this is what I want. Any reading/tools to point me in the right direction?
Apparently it does not support anything except the most trivial PolicyAuthorize. Are you sure it is TPM 2.0 and not 1.2?
Well … theoretically grub2 supports unlocking using simple PCR policy, but it happens very early, so you lose almost all protection TPM offers (like measuring kernel command line).
Otherwise you can of course manually enroll using plain PCRs with systemd-cryptenroll --tpm2-pcrs=xxx, but then you will need to recalculate the PCRs (i.e. - remove current enrollment and repeat again) every time something changed, like kernel update or initrd rebuild. But as long as these do not change, it allows automatic unlock.
You can of course chose PCRs that do not normally change, but then you again lose protection TPM offers (anyone with physical access will be able to unlock your root).
@arvidjaar according to the output of cat /sys/class/tpm/tpm0/tpm_version_majorthis is indeed version 2. However I can’t really find any more detail than that on any subversion.
I think I follow, by the looks of it I just need to enroll one of the PCR keys + add tpm2-device=auto to my crypttab? What exactly does doing it through this with PolicyAuthorize not offer that PolicyAuthorizeNV does?
@malcolmlewis sorry the screen I am referring to in this case is the TTY screen you are presented with to enter the pass/code before getting to GDM. Unless I can add an onscreen keyboard in that TTY somehow…?
It decouples TPM policy from the enrollment metadata. With PolicyAuthorzieNV the actual policy is stored inside of TPM and information in LUKS header just describes how to access it. It makes it possible to recompute policy without changing LUKS header. With PolicyAuthorize policy itself is stored in LUKS header and must be replaced every time something has changed.
With PolicyAuthorizeNVsystemd implements policy that matches multiple alternatives (e.g. you may have several kernels that are allowed by it), with PolicyAuthorize the policy computed by systemd will only match precisely one single set of PCR measurements.