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 look.

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 used.

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 guidance.

Garrett Fields