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

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

[Patrick Ohly]

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

On Thu, 2017-11-09 at 13:53 +0100, 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 found that I was accidentally building with a different swtpm2 recipe
in a local workspace, which used an older revision. I also noticed that
the libtpms tpm2-preview branch doesn't actually have the latest
revision: tpm2-preview.rev146 is more recent.

To cut a long story short, with swtpm =
2dfd15d22b425c1ca92c9bc9f03c84634e6e344a and libtpms =
14cb73d6658a9baa41a5e2ff542168463b7becf0 it now works :-)

Stefan, I know you said that you still want to continue rebasing your
tpm2 branches because they aren't ready for use. Do you have an
estimate when the code might become released officially?

I'm also still curious about taking ownership of the TPM.

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

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

[Stefan Berger]

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

On 11/27/2017 05:03 AM, Patrick Ohly wrote:
> On Fri, 2017-11-10 at 10:27 -0500, Stefan Berger wrote:
>> On 11/10/2017 07:53 AM, Patrick Ohly wrote:
>>> Perhaps it would help to advertise some versions of the tpm2-
>>> preview
>>> code as "ready for testing", for example by tagging them?
>> I'll do that next week, after some changes/fixes, and post here and
>> on the QEMU devel mailing list.
> How is it going with that?

Soon :-)

>
> FWIW, I updated my build recipes to your latest snapshots
> (adf9b3fe5d4df6708e9f801b8c9dcfdf7274d457 for swtpm,
> 42a5d1ca4680b1caba67c06fe2011fdc5b253785 for libswtpm) and it continued
> to work for me.
>

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

[Patrick Ohly]

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

On Fri, 2017-11-10 at 10:27 -0500, Stefan Berger wrote:
> On 11/10/2017 07:53 AM, Patrick Ohly wrote:
> > Perhaps it would help to advertise some versions of the tpm2-
> > preview
> > code as "ready for testing", for example by tagging them?
> 
> I'll do that next week, after some changes/fixes, and post here and
> on the QEMU devel mailing list.

How is it going with that?

FWIW, I updated my build recipes to your latest snapshots
(adf9b3fe5d4df6708e9f801b8c9dcfdf7274d457 for swtpm,
42a5d1ca4680b1caba67c06fe2011fdc5b253785 for libswtpm) and it continued
to work for me.

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

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

[Stefan Berger]

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

On 11/10/2017 07:53 AM, Patrick Ohly wrote:
> On Fri, 2017-11-10 at 07:04 -0500, Stefan Berger wrote:
>> On 11/10/2017 04:07 AM, Patrick Ohly wrote:
>>> Stefan, I know you said that you still want to continue rebasing
>>> your
>>> tpm2 branches because they aren't ready for use. Do you have an
>>> estimate when the code might become released officially?
>> QEMU will create version 2.11 in mid December. I would like to have
>> an
>> official version for 2.12, so that would probably be March 2018. I
>> hope
>> we can have some more people testing it or looking at the code until
>> then... I want to be able to support TPM migration in QEMU once it
>> opens
>> up for new code in mid December. And migration needs testers.
>>
>> The proportion between lines of code and eyes looking at it isn't
>> quite
>> right when it comes to TPM and especially swtpm and libtpms.
> Perhaps it would help to advertise some versions of the tpm2-preview
> code as "ready for testing", for example by tagging them?

I'll do that next week, after some changes/fixes, and post here and on 
the QEMU devel mailing list.

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

[Patrick Ohly]

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

On Fri, 2017-11-10 at 07:04 -0500, Stefan Berger wrote:
> On 11/10/2017 04:07 AM, Patrick Ohly wrote:
> > Stefan, I know you said that you still want to continue rebasing
> > your
> > tpm2 branches because they aren't ready for use. Do you have an
> > estimate when the code might become released officially?
> 
> QEMU will create version 2.11 in mid December. I would like to have
> an 
> official version for 2.12, so that would probably be March 2018. I
> hope 
> we can have some more people testing it or looking at the code until 
> then... I want to be able to support TPM migration in QEMU once it
> opens 
> up for new code in mid December. And migration needs testers.
> 
> The proportion between lines of code and eyes looking at it isn't
> quite 
> right when it comes to TPM and especially swtpm and libtpms.

Perhaps it would help to advertise some versions of the tpm2-preview
code as "ready for testing", for example by tagging them?

I've mentioned it to you before, but let me repeat it here because
others might also have an opinion. Providing ready-to-use recipes for
the preview code is tricky because build recipes (at least in Yocto)
don't include source directly and instead fetch from the upstream git.
That has the effect that such recipes can become unbuildable anytime
you rebase and the old revisions get garbage-collected in the GitHub
repo.

I want to merge my TPM2 code into refkit, but I can't risk making the
master branch unbuildable. So what I'll do is tag and mirror the code
that is needed by the recipes under github.com/pohly.

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

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

[Patrick Ohly]

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

On Fri, 2017-11-10 at 06:53 -0500, Stefan Berger wrote:
> Other possibilities, you have an old libtpms library that's being
> picked up that may have had a bug?

I indeed didn't have the latest code, but for other reasons - see my
other email. It's working now :-)

> > BTW, should the swtpm instance above really terminate when qemu
> > disconnects? It currently does, although -terminate is not given.
> 
> It is terminated by QEMU issuing a shutdown on it. I think it's
> better than leaving stale swtpm processes running.

That it explains it. I was just wondering.

Having swtpm spawned by QEMU avoids exactly this issue with lingering
processes, even when QEMU itself gets killed and doesn't get around to
shut down the TPM properly. Unfortunately the QEMU developers didn't
buy that argument :-/

> > How can I enable more debug logging inside swtpm? Increasing the
> > level
> > does not really provide much useful information.
> > 
> 
> There's not much debugging output inside the TPM 2 code. Some fatal 
> errors, such as not swtpm not being able to write the TPM2 state
> file should show up, though.

Just to close on this, --enable-debug also enables additional output,
doesn't it? I haven't actually used it, though, because it leads to an
assertion in swtpm when using TPM2 (https://github.com/stefanberger/swt
pm/issues/54).

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

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

[Stefan Berger]

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

On 11/10/2017 04:07 AM, Patrick Ohly wrote:
> On Thu, 2017-11-09 at 13:53 +0100, 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 found that I was accidentally building with a different swtpm2 recipe
> in a local workspace, which used an older revision. I also noticed that
> the libtpms tpm2-preview branch doesn't actually have the latest
> revision: tpm2-preview.rev146 is more recent.
>
> To cut a long story short, with swtpm =
> 2dfd15d22b425c1ca92c9bc9f03c84634e6e344a and libtpms =
> 14cb73d6658a9baa41a5e2ff542168463b7becf0 it now works :-)

Should have read the most recent message first :-)
>
> Stefan, I know you said that you still want to continue rebasing your
> tpm2 branches because they aren't ready for use. Do you have an
> estimate when the code might become released officially?

QEMU will create version 2.11 in mid December. I would like to have an 
official version for 2.12, so that would probably be March 2018. I hope 
we can have some more people testing it or looking at the code until 
then... I want to be able to support TPM migration in QEMU once it opens 
up for new code in mid December. And migration needs testers.

The proportion between lines of code and eyes looking at it isn't quite 
right when it comes to TPM and especially swtpm and libtpms.


>
> I'm also still curious about taking ownership of the TPM.
>

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

[Stefan Berger]

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

On 11/09/2017 03:40 PM, Patrick Ohly wrote:
> On Thu, 2017-11-09 at 10:17 -0500, Stefan Berger wrote:
>> On 11/09/2017 10:10 AM, Patrick Ohly wrote:
>>> On Thu, 2017-11-09 at 09:55 -0500, Stefan Berger wrote:
>>>> I did all of this with the latest versions of libtpms and swtpm
>>>> and
>>>> it works fine for me.
>>> Which TPM tools (project and revision?) did you use?
>>>
>> I used the tpm2-tools and tpm2-tss available from Fedora 26.
> That's 2.1.1, which is a bit more recent than the 2.1.0 that I am
> currently building with meta-measured. But that difference is minor.
>
> How did you connect to swtpm from inside QEMU? Did your test involve
> restarting swtpm?

Yes.

My swtpm command line looks like this:

#> ls -l /tmp/mytpm1
total 16
-rw-rw-r--. 1 stefanb stefanb 16384 Nov 10 06:26 tpm2-00.permall
#> swtpm socket --tpmstate dir=/tmp/mytpm1 --ctrl 
type=unixio,path=/tmp/mytpm1/ctrl.sock --tpm2


The QEMU command line looks like this:

# sudo ./x86_64-softmmu/qemu-system-x86_64 -vnc :10 -enable-kvm -m 1024 
-boot d -L /usr/share/seabios -bios bios-256k.bin -boot menu=on 
--chardev socket,id=chrtpm,path=/tmp/mytpm1/ctrl.sock -tpmdev 
emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0 -monitor 
stdio -chardev file,id=pts2,path=/tmp/seabios.log -device 
isa-serial,chardev=pts2 /var/lib/libvirt/images/FC26


>
> When I reboot the virtual machine without restarting QEMU and swtpm,
> then NVRAM survives the reboot.

A possibility could be that the TPM 2's state file was not written. If I 
was to try to use a tpm2-00.permall file that swtpm doesn't have access 
to, because it's being owned by another user, then that could happen. 
But I see errors being logged that the file cannot be written to. There 
isn't anything that would issue a TPM2_Clear(), right?

Other possibilities, you have an old libtpms library that's being picked 
up that may have had a bug? 'ldconfig -v' only shows one libtpms, 
right?And it's the one you compiled from recent code...

I have test cases in the swtpm test suite that create NVRAM areas (with 
counters) and shut the TPM 2 down and resume it and also resume from 
previously stored state. So, there is coverage for NVRAM to a certain 
extent. 'make check' on swtpm succeeds for you, right?

>
> But when I stop QEMU and swtpm and then boot up again, swtpm modifies
> the tpm2-00.permall data file when QEMU connects and the previously
> defined NVRAM entry is gone. This can already be reproduced with just
> "tpm2_nvdefine".
>
> Here's roughly what I ran:
>
>      swtpm socket --ctrl type=unixio,path=/tmp/swtpm.sock --tpmstate dir=tpm --log file=swtpm.log --tpm2 &
>
>      qemu ... -chardev 'socket,id=chrtpm0,path=/tmp/swtpm.sock' -tpmdev emulator,id=tpm0,chardev=chrtpm0 -device tpm-tis,tpmdev=tpm0 ...
>
>      # export TPM2TOOLS_TCTI_NAME=device
>      # tpm2_nvdefine -x 0x1500001 -s 40 -a 0x40000001 -t 0x80020002
>      ^ac
>      (qemu) q
>
> swtpm terminates now and one can take a copy of the current state:
>
>      cp tpm/tpm2-00.permall /tmp
>
> Then start both swtpm and qemu again as above, without any TPM
> operations from userspace, and check:
>
>      cmp tpm/tpm2-00.permall /tmp/tpm2-00.permall
>      tpm/tpm2-00.permall /tmp/tpm2-00.permall differ: byte 313, line 1
>
> BTW, should the swtpm instance above really terminate when qemu
> disconnects? It currently does, although -terminate is not given.

It is terminated by QEMU issuing a shutdown on it. I think it's better 
than leaving stale swtpm processes running.

>
> How can I enable more debug logging inside swtpm? Increasing the level
> does not really provide much useful information.
>

There's not much debugging output inside the TPM 2 code. Some fatal 
errors, such as not swtpm not being able to write the TPM2 state file 
should show up, though.

    Stefan

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

[Patrick Ohly]

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

On Thu, 2017-11-09 at 15:12 +0100, Javier Martinez Canillas wrote:
> Hello Patrick,
> 
> On 11/09/2017 01:53 PM, Patrick Ohly wrote:
> > 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?

It should be.

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

That works if I keep swtpm running across the reboot. But as with
tpm2_nvdefine (see my other mail to Stefan), the persistent object is
gone after restarting swtpm.

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

True. In refkit, the UEFI firmware directly loads a signed UEFI
combined app which contains initramfs, kernel and boot parameters, so
there shouldn't be a way for an attacker to intercept booting before
the initramfs runs.

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

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

[Patrick Ohly]

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

On Thu, 2017-11-09 at 10:17 -0500, Stefan Berger wrote:
> On 11/09/2017 10:10 AM, Patrick Ohly wrote:
> > On Thu, 2017-11-09 at 09:55 -0500, Stefan Berger wrote:
> > > I did all of this with the latest versions of libtpms and swtpm
> > > and
> > > it works fine for me.
> > 
> > Which TPM tools (project and revision?) did you use?
> > 
> 
> I used the tpm2-tools and tpm2-tss available from Fedora 26.

That's 2.1.1, which is a bit more recent than the 2.1.0 that I am
currently building with meta-measured. But that difference is minor.

How did you connect to swtpm from inside QEMU? Did your test involve
restarting swtpm?

When I reboot the virtual machine without restarting QEMU and swtpm,
then NVRAM survives the reboot.

But when I stop QEMU and swtpm and then boot up again, swtpm modifies
the tpm2-00.permall data file when QEMU connects and the previously
defined NVRAM entry is gone. This can already be reproduced with just
"tpm2_nvdefine".

Here's roughly what I ran:

    swtpm socket --ctrl type=unixio,path=/tmp/swtpm.sock --tpmstate dir=tpm --log file=swtpm.log --tpm2 &

    qemu ... -chardev 'socket,id=chrtpm0,path=/tmp/swtpm.sock' -tpmdev emulator,id=tpm0,chardev=chrtpm0 -device tpm-tis,tpmdev=tpm0 ...

    # export TPM2TOOLS_TCTI_NAME=device
    # tpm2_nvdefine -x 0x1500001 -s 40 -a 0x40000001 -t 0x80020002
    ^ac
    (qemu) q

swtpm terminates now and one can take a copy of the current state:

    cp tpm/tpm2-00.permall /tmp

Then start both swtpm and qemu again as above, without any TPM
operations from userspace, and check:

    cmp tpm/tpm2-00.permall /tmp/tpm2-00.permall 
    tpm/tpm2-00.permall /tmp/tpm2-00.permall differ: byte 313, line 1

BTW, should the swtpm instance above really terminate when qemu
disconnects? It currently does, although -terminate is not given.

How can I enable more debug logging inside swtpm? Increasing the level
does not really provide much useful information.

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

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

[Patrick Ohly]

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

On Thu, 2017-11-09 at 13:53 +0100, Patrick Ohly wrote:
> 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.

I forgot to ask one conceptual question: in the proposed usage
scenario, does it make sense to take ownership of the TPM? All
passwords would have to be well-known, because there is no user or
other form of input available which could provide them. So taking
ownership doesn't really change much from a security perspective.

https://github.com/intel/tpm2-tools/wiki/How-to-use-tpm2-tools shows
that all NVRAM operations also work without taking ownership, but
doesn't go into the pros and cons of that.

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

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

[flihp]

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

Hi Patrick,

On 11/09/2017 04:53 AM, 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.

You may also want to take a look at similar work WindRiver has done with
tying disk encryption to the TPM2. Checking your code against an
existing implementation may be a good way to remove some variables from
your debugging:

https://github.com/WindRiver-OpenSourceLabs/cryptfs-tpm2

Regards,
Philip

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

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

[Stefan Berger]

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

On 11/09/2017 10:10 AM, Patrick Ohly wrote:
> On Thu, 2017-11-09 at 09:55 -0500, Stefan Berger wrote:
>> On 11/09/2017 07:53 AM, Patrick Ohly wrote:
>>> 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
>> swtpm_setup.sh, which this one seems to be derived from, should only
>> be
>> run once to simulate the TPM manufacturing. It's destructive to
>> existing
>> TPM 2 state. Are you running this every time?
> It's run once before the test, with a clean --tpm-state test. Then
> follow the install part, the reboot, and then booting into the
> installed image.

Nevertheless I'll extend swtpm_setup with --overwrite and 
--not-overwrite options to allow overwriting of existing state or to not 
allow it, and error out if state is found but the options are omitted.


>
>>> 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 did all of this with the latest versions of libtpms and swtpm and
>> it works fine for me.
> Which TPM tools (project and revision?) did you use?
>
I used the tpm2-tools and tpm2-tss available from Fedora 26.

    Stefan

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

[Patrick Ohly]

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

On Thu, 2017-11-09 at 09:55 -0500, Stefan Berger wrote:
> On 11/09/2017 07:53 AM, Patrick Ohly wrote:
> > 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
> 
> swtpm_setup.sh, which this one seems to be derived from, should only
> be 
> run once to simulate the TPM manufacturing. It's destructive to
> existing 
> TPM 2 state. Are you running this every time?

It's run once before the test, with a clean --tpm-state test. Then
follow the install part, the reboot, and then booting into the
installed image.

> > 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 did all of this with the latest versions of libtpms and swtpm and
> it works fine for me.

Which TPM tools (project and revision?) did you use?

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

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

[Javier Martinez Canillas]

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

[tpm2] using TPM2 NVRAM for storing LUKS password

[Patrick Ohly]

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