Back in the end of July, I wrote a message on this discussion list titled
"PCR Policy enforcement when using nvram". In that, I asked for a way to
have both a PCR check AND a password lock an nvram range (not an OR). I
really appreciated everyone's help, especially William Roberts, who gave
some sample code of using a session to accomplish this goal.
Now that Ubuntu has updated its repositories for the upcoming 20.04 LTS
release and included TPM-tools v4.x, I figured it was time to take another
My goal is to provide a method to auto-unlock a ZFS encrypted root
filesystem. Currently, ZFS allows for unlocking via a prompt or file
containing a raw, hex, or passphrase values. The mechanisms are already
inplace to prompt on startup.
So far I have just done a proof of concept. It probably loads of bad code
and tons of polish needed:
I forked the zfs project, expanded the its initramfs hooks to include the
required tpm2-tools binaries, and added another stanza to init script's
decrypting section. I also created a pair of scripts that configures the
system and tests readback.
The nvram index and the PCRs used are stored/read from the zfs filesystem
properties. I used the filesytem's GUID as the required password as
another check to verify the NVRAM range was intended for that filesystem.
I also intend to issue an nvreadlock to prevent snooping once the key is
I'd be interested in a critique of the method overall I expect there ways
to make this more secure. With enough effort, one could issue a
break=premount on the kernel line and manually extract the password from
the TPM. Any way to tighten that up?
I'm a total novice at TPM in general, but am completely open to advise and