Re: [tpm2] using TPM2 NVRAM for storing LUKS password

[Javier Martinez Canillas <javierm at redhat.com>]

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

Hello Patrick,

On 11/09/2017 01:53 PM, Patrick Ohly wrote:
> 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.
>

Are you sure that the TPM2 state is maintained between VM reboots? I mean, did
you try for example making a transient object (i.e: a key) persistent using the
TPM2_EvictControl command and then check if is still listed after a VM reboot?

I wonder if the problem is only with the objects written with tpm2_nvwrite or
anything that ends being persisted in the NVRAM.

For example, you can try something like the following commands:

$ tpm2_createprimary -A o -g 0x4 -G 0x25 -C primary.context          
nameAlg = 0x0004            
type = 0x0025               
contextFile = primary.context                           

CreatePrimary Succeed ! Handle: 0x80ffffff

$ tpm2_evictcontrol -A o -c primary.context -S 0x81000000            
persistentHandle: 0x8100000

And then after a reboot:

$ tpm2_listpersistent 
1 persistent objects defined.

  0. Persistent handle: 0x81000000
  {
        Type: 0x25
        Hash algorithm(nameAlg): 0x4
        Attributes: 0x30072
  }

> 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?
>

That sounds reasonable. There are other attack vectors like someone replacing
your initramfs (that's not signed in a Secure Boot) and reading the LUKS pass
before the tpm2_nvreadlock.

> 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?
> 

The index seems correct, the NV Index Areas start at the 0x01000000 address.

> 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?
>

Unfortunately I'm not familiar with swtpm and QEMU but I would test the commands
I mentioned above.

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat