[tpm2] Re: System design question

[tpm2] Re: System design question

[Felix Rubio Dalmau]

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

My apologies, I have not played with TPM for long time: I had forgotten I 
could tpm2_nvdefine, and then tpm2_nvwrite/nvread.

Regards!
Felix

[tpm2] Re: System design question

[Roberts, William C]

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

On Sun, 2022-08-21 at 09:17 +0200, Felix Rubio Dalmau wrote:
> Hi everybody,
> 
> I am playing with a QEMU VM that uses swtpm. My goal is to make a
> stable, easily maintainable setup to have ZFS native full disk
> encription, and I am facing a problem:
> 
> * I was relying on GRUB2 signature-checking capabilities to make sure
> that, besides the kernel (that is checked by Secure Boot anyway),
> initramfs had not been tampered with. However, this introduces yet a
> new (GPG) private key that needs to be stored, initramfs needs to be
> signed when changed, etc.
> * Recently I have learned that from kernel 5.10 on, the measurements
> of initramfs can be found on PCR9, so I modified my PCR-based policy
> to make use of registers 0,1,7 and 9 and I am planning to remove the
> GRUB2 checks. But the problem now is: After generating the policies,
> which I do by....
> 
> ```bash
> # Recreate the PCR-based policy
> tpm2_startauthsession -S session.ctx
> tpm2_policypcr -S session.ctx -L regular.policy -l sha256:0,1,7,9
> tpm2_policypassword -S session.ctx -L regular.policy
> tpm2_flushcontext session.ctx
> 
> # session for auth based on rescue password
> tpm2_startauthsession -S session.ctx
> tpm2_policysecret -S session.ctx -L rescue.policy -c o
> '<tpm_ownerpass>'
> tpm2_flushcontext session.ctx
> 
> # compound both policies using OR
> tpm2_startauthsession -S session.ctx
> tpm2_policyor -S session.ctx -L compound.policy
> sha256:rescue.policy,regular.policy
> tpm2_flushcontext session.ctx
> 
> # create the seal object (the FS password is requested to the user)
> tpm2_create -C prim.ctx -c key.ctx -u key.pub -r key.priv -L
> compound.policy -i- -p '<disk_unlock_password>' -a
> 'fixedtpm|fixedparent'
> 
> # persist the object to the TPM
> tpm2_evictcontrol -c key.ctx 0x81010001 -P '<tpm_ownerpass>'
> ```
> 
> ... then I need to store regular.policy and rescue.policy in
> initramfs, which will produce a different hash next time.
> 
> Therefore, the question is: is there any way I can store the policies
> in the TPM itself, so that I do not have to rebuild initramfs? Do you
> guys think this is not the way to go, and there is a better approach?
> 

Policy Hashes are stable and can be computed without the use of the
tpm. 
You don't really need to save those policy files as they are just the
hash. Polcies are enforced by ensuring the hash generated on the
sessoion via policy commands matches the policy field in the public
portion of the object and that additional state, dependent on the
policy commands, is also verified (like policy secret password).

tpm2 policysecret -S s.ctx -co -L policy.dat
0d84f55daf6e43ac97966e62c9bb989d3397777d25c5f749868055d65394f952

xxd -p -c256 policy.dat 
0d84f55daf6e43ac97966e62c9bb989d3397777d25c5f749868055d65394f952

The policy files are just a way to move the digest between tools.

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. If that doesn;t work we could support
embedding the raw hex hash into the create command as an argument
rather than a file argument.

> Thank you very much!
> Felix
> 
> _______________________________________________
> tpm2 mailing list -- tpm2(a)lists.01.org
> To unsubscribe send an email to tpm2-leave(a)lists.01.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[tpm2] Re: System design question

[Roberts, William C]

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

On Sun, 2022-08-21 at 14:05 +0200, Felix Rubio Dalmau wrote:
> My apologies, I have not played with TPM for long time: I had
> forgotten I 
> could tpm2_nvdefine, and then tpm2_nvwrite/nvread.
> 

The best rule of thumb is to do everything you can to not use NV
Indices. This is a very small and finite amount of space. I don't think
you need to use these if you just "hardcode" the hash values.

> Regards!
> Felix
> 
> _______________________________________________
> tpm2 mailing list -- tpm2(a)lists.01.org
> To unsubscribe send an email to tpm2-leave(a)lists.01.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[tpm2] Re: System design question

[Roberts, William C]

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

On Mon, 2022-08-22 at 13:08 +0000, Roberts, William C wrote:
> On Sun, 2022-08-21 at 09:17 +0200, Felix Rubio Dalmau wrote:
> > Hi everybody,
> > 
> > I am playing with a QEMU VM that uses swtpm. My goal is to make a
> > stable, easily maintainable setup to have ZFS native full disk
> > encription, and I am facing a problem:
> > 
> > * I was relying on GRUB2 signature-checking capabilities to make
> > sure
> > that, besides the kernel (that is checked by Secure Boot anyway),
> > initramfs had not been tampered with. However, this introduces yet
> > a
> > new (GPG) private key that needs to be stored, initramfs needs to
> > be
> > signed when changed, etc.
> > * Recently I have learned that from kernel 5.10 on, the
> > measurements
> > of initramfs can be found on PCR9, so I modified my PCR-based
> > policy
> > to make use of registers 0,1,7 and 9 and I am planning to remove
> > the
> > GRUB2 checks. But the problem now is: After generating the
> > policies,
> > which I do by....
> > 
> > ```bash
> > # Recreate the PCR-based policy
> > tpm2_startauthsession -S session.ctx
> > tpm2_policypcr -S session.ctx -L regular.policy -l sha256:0,1,7,9
> > tpm2_policypassword -S session.ctx -L regular.policy
> > tpm2_flushcontext session.ctx
> > 
> > # session for auth based on rescue password
> > tpm2_startauthsession -S session.ctx
> > tpm2_policysecret -S session.ctx -L rescue.policy -c o
> > '<tpm_ownerpass>'
> > tpm2_flushcontext session.ctx
> > 
> > # compound both policies using OR
> > tpm2_startauthsession -S session.ctx
> > tpm2_policyor -S session.ctx -L compound.policy
> > sha256:rescue.policy,regular.policy
> > tpm2_flushcontext session.ctx
> > 
> > # create the seal object (the FS password is requested to the user)
> > tpm2_create -C prim.ctx -c key.ctx -u key.pub -r key.priv -L
> > compound.policy -i- -p '<disk_unlock_password>' -a
> > 'fixedtpm|fixedparent'
> > 
> > # persist the object to the TPM
> > tpm2_evictcontrol -c key.ctx 0x81010001 -P '<tpm_ownerpass>'
> > ```
> > 
> > ... then I need to store regular.policy and rescue.policy in
> > initramfs, which will produce a different hash next time.
> > 
> > Therefore, the question is: is there any way I can store the
> > policies
> > in the TPM itself, so that I do not have to rebuild initramfs? Do
> > you
> > guys think this is not the way to go, and there is a better
> > approach?
> > 
> 
> Policy Hashes are stable and can be computed without the use of the
> tpm. 
> You don't really need to save those policy files as they are just the
> hash. Polcies are enforced by ensuring the hash generated on the
> sessoion via policy commands matches the policy field in the public
> portion of the object and that additional state, dependent on the
> policy commands, is also verified (like policy secret password).
> 
> tpm2 policysecret -S s.ctx -co -L policy.dat
> 0d84f55daf6e43ac97966e62c9bb989d3397777d25c5f749868055d65394f952
> 
> xxd -p -c256 policy.dat 
> 0d84f55daf6e43ac97966e62c9bb989d3397777d25c5f749868055d65394f952
> 
> The policy files are just a way to move the digest between tools.
> 
> 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. If that doesn;t work we could
> support
> embedding the raw hex hash into the create command as an argument
> rather than a file argument.

FYI I have support for embedding the digest as a hex string value to
the -L policy argument on the various tools here:
  - https://github.com/tpm2-software/tpm2-tools/pull/3117


> 
> > Thank you very much!
> > Felix
> > 
> > _______________________________________________
> > tpm2 mailing list -- tpm2(a)lists.01.org
> > To unsubscribe send an email to tpm2-leave(a)lists.01.org
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> _______________________________________________
> tpm2 mailing list -- tpm2(a)lists.01.org
> To unsubscribe send an email to tpm2-leave(a)lists.01.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[tpm2] Re: System design question

[Felix Rubio Dalmau]

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

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

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

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

Felix

[tpm2] Re: System design question

[Roberts, William C]

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



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

[tpm2] Re: System design question

[David Challener]

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

Generally you use NV when you either have a problem with hash loops (which
is solvable, by the way), or you don't have access to other storage that
can be read when you need the value.

On Mon, Aug 22, 2022, 9:09 AM Roberts, William C <
william.c.roberts(a)intel.com> wrote:

> On Sun, 2022-08-21 at 14:05 +0200, Felix Rubio Dalmau wrote:
> > My apologies, I have not played with TPM for long time: I had
> > forgotten I
> > could tpm2_nvdefine, and then tpm2_nvwrite/nvread.
> >
>
> The best rule of thumb is to do everything you can to not use NV
> Indices. This is a very small and finite amount of space. I don't think
> you need to use these if you just "hardcode" the hash values.
>
> > Regards!
> > Felix
> >
> > _______________________________________________
> > tpm2 mailing list -- tpm2(a)lists.01.org
> > To unsubscribe send an email to tpm2-leave(a)lists.01.org
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> _______________________________________________
> tpm2 mailing list -- tpm2(a)lists.01.org
> To unsubscribe send an email to tpm2-leave(a)lists.01.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>

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