[tpm2] Re: Made an ZFS root pool auto-unlock, please give review of method

[Garrett Fields <ghfields at gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2530 bytes --]

I've played around with this for quite some time and wanted to get some
more eyes on this code.  I've created a draft PR with "ZFS on Linux",
asking for a discussion of methodology.  Likely, the people on this list
can speak to the utilization of TPM2-tools and help with the security
aspects more than the filesystems focused developers there.

Please have a look and submit comments here or the PR itself.
https://github.com/zfsonlinux/zfs/pull/9852

Many thanks,
Garrett Fields

On Mon, Dec 9, 2019 at 11:15 PM Garrett Fields <ghfields(a)gmail.com> wrote:

> 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:
> https://github.com/ghfields/zfs/compare/master...ghfields:tpm2-autounlock
>
> 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.
>
> Thanks,
> Garrett Fields
>
>
>

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 3260 bytes --]