[tpm2] Re: System design question

Roberts, William C <william.c.roberts at intel.com> Wed, 31 Aug 2022 19:21:34 +0000
Newsgroups dev.linux.lists.tpm2
Message-ID <SN6PR11MB34377A12E7880536240A23B9B8789@SN6PR11MB3437.namprd11.prod.outlook.com>

> -----Original Message-----
> From: Felix Rubio Dalmau <felix(a)kngnt.org>
> Sent: Sunday, August 28, 2022 4:39 AM
> To: tpm2(a)lists.01.org
> Cc: Roberts, William C <william.c.roberts(a)intel.com>
> Subject: Re: [tpm2] Re: System design question
> 
> Hey William,
> 
> Thank you for your answer, I have just been playing with the tpm2_tools in
> latest Debian 11.4, trying to follow your reasoning, but there is something I
> am missing:
> 
> As secureboot does not check the initramfs, my approach is to make the full
> disk encryption key depend on PCR registers 0,1,7 and 9 (for what I have
> read, from kernel 5.13 on, the measurements of initramfs go to PCR 9), or a
> rescue password. This approach implies having a script in place so that the
> first time a new kernel + initramfs boot I will get those measurements
> somewhere and then I can rebuild the policies with the correct contents
> (that is, until I find a way to precalculate the value of PCR 9 out of the
> initramfs file itself...
> assuming is possible).
> 
> In your email you say "[...]
> > So really all that needs to occur is the code/script needs to be in
> > place that does the normal PCR flow or rescue flow. The create call
> > can be hardcoded to the known hash, that isn't changing and can be
> > included in the filesystem when generated.
> [...]" but I do not see how would that be achieved: my current normal PCR
> flow goes like this:
> 
> tpm2_startauthsession -Q -S session.ctx --policy-session tpm2_policypcr -Q -
> S session.ctx -l sha256:0,1,7,9 tpm2_policypassword -Q -S session.ctx
> tpm2_policyor -Q -S session.ctx sha256:rescue.policy,regular.policy
> SECRET=`tpm2_unseal -Q -c 0x81010001 -p
> "session:session.ctx+$REGULAR_PASS"`
> tpm2_flushcontext -Q session.ctx
> tpm2_pcrextend -Q
> 0:sha256=00000000000000000000000000000000000000000000000...

So you do this to prevent unseal later right?
Theirs discussion on systemd to standardize this, amongst a lot of other things
you may find interesting
https://github.com/systemd/systemd/issues/22637

> 
> I think I understand, from user answer, that I should be able to replace
>         tpm2_policyor -Q -S session.ctx sha256:rescue.policy,regular.policy
> by
>         tpm2_policyor -Q -S session.ctx <output of precalculated digest>
> 
> But still, this does not fix the issue: the moment I hardcode this value in my
> initramfs, its measurement on PCR 9 will change. 

Ahh yeah, including PCR 9 causes a chicken and egg problem where the egg
Is initramfs. I don't see a way to break this dependency except by 
just need to calculate the value by running all those commands. :-(

Sorry my suggestion didn't work, it didn't occur to me at the time (facepalm).

> The only way out I see is to
> avoid storing this information on the initramfs itself, and this is when the
> nvram came into the picture. Given that nvram is scarce, maybe I can get
> away by storing on it the digest of the policyor, and adding it somehow to the
> session after reading it?
> 

Policyor depends on the hashes of policy A and B... I don't see that breaking
The dependency offhand. I have other ideas, but they have issues as well.
I think the simplest thing is just run the commands.

> Regards, and thank you very much for giving this issue a thought!
> 
> Felix
>