[tpm2] using TPM2 NVRAM for storing LUKS password

[Patrick Ohly <patrick.ohly at intel.com>]

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

Hello!

I am trying to port the refkit support for whole-disk encryption from
TPM 1.2 to TPM 2.0. In refkit, an installer image sets up the internal
disk with the root partition encrypted with LUKS. The initramfs then
unlocks that partition before mounting it and transferring control to
/bin/init. TPM NVRAM is used to store a per-machine LUKS password.

The automated tests uses QEMU + swtpm. More precisely, I am using QEMU
2.10.0 with backported chardev patches plus a custom patch that makes
it possible to have QEMU start swtpm.  swtpm and libtpms are from the
current tpm2-preview branches (5c70e401824e4f3f0900bddb50e7ea5fb7bbd84f
resp. e0331c6d71b273ef7f71ce6fa17306f6773f543e).

I'm using tpm2.0-tools v2.1.0. Kernel is 4.9.

In this setup, I get a TPM2.0 /dev/tpm0 in the virtual machine when I
start QEMU with:

-chardev 'socket,id=chrtpm0,cmd=exec swtpm_oe.sh socket --terminate --ctrl type=unixio,,clientfd=0 --tpmstate dir=... --log level=10,,file=.../swtpm.log --tpm2' \
-tpmdev emulator,id=tpm0,chardev=chrtpm0 \
-device tpm-tis,tpmdev=tpm0 

The whole thing is built with Yocto/OE-Core, hence the swtpm_oe.sh
wrapper script. It just sets some paths, then calls swtpm.

There are automated tests, too. All of this was working with TPM1.2.
With TPM2.0, I have everything set up and installing to internal disk
works without issues. But after rebooting the virtual machine, the
NVRAM no longer contains the password. tpm2_nvlist shows nothing.

I'm unsure whether this is an issue in tpm2.0-tools, in swtpm2, or my
usage of both. Let me describe in more details what commands are used. 

The virtual TPM gets initialized with:
    swtpm_setup_oe.sh --tpm2 --tpm-state ... --createe

The commands that run as part of installation are:
    tpm2_takeownership -o ownerpass -e endorsepass -l lockpass
    tpm2_nvdefine -x 0x1500001 -s 40 -a 0x40000001 -t 0x80020002 -P ownerpass
    tpm2_nvwrite -x 0x1500001 -a 0x40000001 -f /dev/shm/keydir.sVrmLQ/keyfile -P ownerpass
    52 45 46 4b 49 54 5f 30 70 e6 2b b9 ca 0c 1c 00 1d 6d eb 58 a1 7a cf 0d 1d 71 46 bc fd 7a 80 a0 8f 8b 0a 30 fc 89 9b db 

    tpm2_nvlist
    1 NV indexes defined.

      0. NV Index: 0x1500001
      {
    	    Hash algorithm(nameAlg):11
         	    The Index attributes(attributes):0xa0020002
         	    The size of the data area(dataSize):40
       }

    tpm2_nvreadlock -x 0x1500001 -a 0x40000001 -P ownerpass


Then the initramfs does:
    tpm2_nvlist
    0 NV indexes defined.

    tpm2_nvread -x 0x1500001 -a 0x40000001 -s 40 -o 0 -P ownerpass
    ERROR: Failed to read NVRAM area at index 0x1500001 (22020097). Error:0x28b

I tried also without tpm2_nvreadlock and without tpm2_takeownership,
but neither of that made a difference.

Conceptually this is similar to the commands used with TPM 1.2. The
simplifying assumption is that only a single OS is getting installed to
virgin hardware and then Secure Boot ensures that no other code ever
gets access to the active TPM. Therefore a fixed index and no real
access protection for the slot are okay. A read-lock is set to ensure
that the key is protected from potentially malicious applications which
 might have access to /dev/tpm0. Does that sound alright?

The index was chosen as in the tpm2.0-tools Wiki (https://github.com/in
tel/tpm2-tools/wiki/How-to-use-tpm2-tools). Is there anything special
about that index?

I checked the swtpm.log (log level 10). Somehow it only contains
SWTPM_IO_Read/Write entries. I'll check whether logging perhaps also
needs to be enabled during compilation.

Any other suggestions for how I could debug this?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.