Discussion about using NV indexes for kernel properties like localities and PCRs

Discussion about using NV indexes for kernel properties like localities and PCRs

[James Bottomley]

At Linux Plumbers Conference (https://lpc.events) there were several
discussions about some of the problems with TPMs in modern laptops,
like localities are very useful for key sealing policies (so they could
only be unwrapped by the kernel), but most laptops/servers can't use
them and also that 24 is too small a number of PCRs.  For the former,
instead of making the kernel operate in a different locality from the
user and using a TPM2_PolicyLocality, we could get the kernel to create
a well known NV PIN index with a random authorization only it knew and
seal policies to it with TPM2_PolicySecret, so that only the kernel
could construct the authorization to satisfy the policy.  The PCR
problem can be partly solved by using NV Extend indexes, which behave
very much like PCRs.

The flaw in both the above is that absent the ability to create
platform NV indexes (which is impossible in modern firmware because the
platform hierarchy gets locked out), anyone possessing the owner
password (which is defined to be empty) can delete and recreate the
index, causing the authorization to change for NV PIN and resetting the
PCR for NV Extend.  To mitigate this, we could block out a range of NV
indexes to be only accessible with the kernel (say 256 with handles of
the form 010f0ffXX - I chose this so as not to be too close to either
the beginning or end, but obviously the exact prefix is up for
discussion).  The kernel would then snoop TPM2_NV_DefineSpace and
TPM2_NV_UndefineSpace commands and trap and report an error for any
attempt to add or delete an index in this range.  We could then get the
kernel to create its PIN NV and say 127 NV Extend indexes, which
userspace would be able to extend, query and make policies on but not
delete.

I'm bringing this up for discussion now, in case anyone has a better
idea or wants to add nuances (like measuring the creation to a real PCR
and adding an event log to measured boot) before I (or someone else)
look into coding it up.

Regards,

James

Re: Discussion about using NV indexes for kernel properties like localities and PCRs

[Lennart Poettering]

On Fr, 01.12.23 15:23, James Bottomley (James.Bottomley@HansenPartnership.com) wrote:

> At Linux Plumbers Conference (https://lpc.events) there were several
> discussions about some of the problems with TPMs in modern laptops,
> like localities are very useful for key sealing policies (so they could
> only be unwrapped by the kernel), but most laptops/servers can't use
> them and also that 24 is too small a number of PCRs.  For the former,
> instead of making the kernel operate in a different locality from the
> user and using a TPM2_PolicyLocality, we could get the kernel to create
> a well known NV PIN index with a random authorization only it knew and
> seal policies to it with TPM2_PolicySecret, so that only the kernel
> could construct the authorization to satisfy the policy.  The PCR
> problem can be partly solved by using NV Extend indexes, which behave
> very much like PCRs.
>
> The flaw in both the above is that absent the ability to create
> platform NV indexes (which is impossible in modern firmware because the
> platform hierarchy gets locked out), anyone possessing the owner
> password (which is defined to be empty) can delete and recreate the
> index, causing the authorization to change for NV PIN and resetting the
> PCR for NV Extend.  To mitigate this, we could block out a range of NV
> indexes to be only accessible with the kernel (say 256 with handles of
> the form 010f0ffXX - I chose this so as not to be too close to either
> the beginning or end, but obviously the exact prefix is up for
> discussion).  The kernel would then snoop TPM2_NV_DefineSpace and
> TPM2_NV_UndefineSpace commands and trap and report an error for any
> attempt to add or delete an index in this range.  We could then get the
> kernel to create its PIN NV and say 127 NV Extend indexes, which
> userspace would be able to extend, query and make policies on but not
> delete.
>
> I'm bringing this up for discussion now, in case anyone has a better
> idea or wants to add nuances (like measuring the creation to a real PCR
> and adding an event log to measured boot) before I (or someone else)
> look into coding it up.

Why would that be necessary though? The "name" of an nvindex pins the
access policy of the nvindex. And nvindexes are always created
uninitialized, thus to to initialize one you just created
(i.e. execute the first write to it) you must be able to fulfill the
write policy set for it. But if you can do that, then why bother with
deleting/recreating them in the first place? And if you set a
different access policy on them then the "name" of the nvindex would
change, and it would become useless in all references from other
objects/quotes/…

This logic is explicitly mentioned in that tpm book btw, it took me a
while to grok how great that concept is, since it basically means you
don't have to be concerned about removed/readded nvindexes at all.

Lennart

--
Lennart Poettering, Berlin

Re: Discussion about using NV indexes for kernel properties like localities and PCRs

[James Bottomley]

On Fri, 2023-12-01 at 22:35 +0100, Lennart Poettering wrote:
> On Fr, 01.12.23 15:23, James Bottomley
> (James.Bottomley@HansenPartnership.com) wrote:
> 
> > At Linux Plumbers Conference (https://lpc.events) there were
> > several discussions about some of the problems with TPMs in modern
> > laptops, like localities are very useful for key sealing policies
> > (so they could only be unwrapped by the kernel), but most
> > laptops/servers can't use them and also that 24 is too small a
> > number of PCRs.  For the former, instead of making the kernel
> > operate in a different locality from the user and using a
> > TPM2_PolicyLocality, we could get the kernel to create
> > a well known NV PIN index with a random authorization only it knew
> > and seal policies to it with TPM2_PolicySecret, so that only the
> > kernel could construct the authorization to satisfy the policy. 
> > The PCR problem can be partly solved by using NV Extend indexes,
> > which behave very much like PCRs.
> > 
> > The flaw in both the above is that absent the ability to create
> > platform NV indexes (which is impossible in modern firmware because
> > the platform hierarchy gets locked out), anyone possessing the
> > owner password (which is defined to be empty) can delete and
> > recreate the index, causing the authorization to change for NV PIN
> > and resetting the PCR for NV Extend.  To mitigate this, we could
> > block out a range of NV indexes to be only accessible with the
> > kernel (say 256 with handles of the form 010f0ffXX - I chose this
> > so as not to be too close to either the beginning or end, but
> > obviously the exact prefix is up for discussion).  The kernel would
> > then snoop TPM2_NV_DefineSpace and TPM2_NV_UndefineSpace commands
> > and trap and report an error for any attempt to add or delete an
> > index in this range.  We could then get the kernel to create its
> > PIN NV and say 127 NV Extend indexes, which userspace would be able
> > to extend, query and make policies on but not delete.
> > 
> > I'm bringing this up for discussion now, in case anyone has a
> > better idea or wants to add nuances (like measuring the creation to
> > a real PCR and adding an event log to measured boot) before I (or
> > someone else) look into coding it up.
> 
> Why would that be necessary though? The "name" of an nvindex pins the
> access policy of the nvindex.

I assume you're talking about using TPM2_PolicyNameHash coupled with
TPM2_PolicyNV?  That pins to NV index value and name, but the problem
is that still doesn't necessarily solve the deletion problem (see
below).

>  And nvindexes are always created uninitialized, thus to to
> initialize one you just created (i.e. execute the first write to it)
> you must be able to fulfill the write policy set for it. But if you
> can do that, then why bother with deleting/recreating them in the
> first place?

Well, I wasn't really considering using a policy for the index, I was
thinking of using the index for other policies (like key release). 
However, even though you can have a policy for read and write, you
can't have a policy for delete unless you have access to the platform
hierarchy (which the problem statement above explained is getting
increasingly unlikely), so your index can still be reset by deleting
and recreating it (even if it is recreated with the same policy). 
You're right that such an index would be detectably uninitialized
unless whoever deleted it can also write to it.

>  And if you set a different access policy on them then the "name" of
> the nvindex would change, and it would become useless in all
> references from other objects/quotes/…

Right but to take a NV Extend index, you're saying I can delete it and
recreate it with exactly the same policy and attributes (so same name)
but then to prevent me placing malicious entries in it, the policy has
to be narrowly crafted to prevent malicious actors extending it
(because then policy can't tell the difference between that recreated
index and the original one).  I've thought about this, but haven't ever
really been able to come up with usable policies, because all such
policies end up requiring either a privileged locality to write from or
a shared secret between the TPM and the trusted writer.

> This logic is explicitly mentioned in that tpm book btw, it took me a
> while to grok how great that concept is, since it basically means you
> don't have to be concerned about removed/readded nvindexes at all.

Which TPM book is this?

James

Re: Discussion about using NV indexes for kernel properties like localities and PCRs

[Lennart Poettering]

On Fr, 01.12.23 17:23, James Bottomley (James.Bottomley@HansenPartnership.com) wrote:

> > > The flaw in both the above is that absent the ability to create
> > > platform NV indexes (which is impossible in modern firmware because
> > > the platform hierarchy gets locked out), anyone possessing the
> > > owner password (which is defined to be empty) can delete and
> > > recreate the index, causing the authorization to change for NV PIN
> > > and resetting the PCR for NV Extend.  To mitigate this, we could
> > > block out a range of NV indexes to be only accessible with the
> > > kernel (say 256 with handles of the form 010f0ffXX - I chose this
> > > so as not to be too close to either the beginning or end, but
> > > obviously the exact prefix is up for discussion).  The kernel would
> > > then snoop TPM2_NV_DefineSpace and TPM2_NV_UndefineSpace commands
> > > and trap and report an error for any attempt to add or delete an
> > > index in this range.  We could then get the kernel to create its
> > > PIN NV and say 127 NV Extend indexes, which userspace would be able
> > > to extend, query and make policies on but not delete.
> > >
> > > I'm bringing this up for discussion now, in case anyone has a
> > > better idea or wants to add nuances (like measuring the creation to
> > > a real PCR and adding an event log to measured boot) before I (or
> > > someone else) look into coding it up.
> >
> > Why would that be necessary though? The "name" of an nvindex pins the
> > access policy of the nvindex.
>
> I assume you're talking about using TPM2_PolicyNameHash coupled with
> TPM2_PolicyNV?  That pins to NV index value and name, but the problem
> is that still doesn't necessarily solve the deletion problem (see
> below).

I was thinking TPM2_PolicyAuthorizeNV and similar things too. They
generally pin NVs by "name".
>
> >  And nvindexes are always created uninitialized, thus to to
> > initialize one you just created (i.e. execute the first write to it)
> > you must be able to fulfill the write policy set for it. But if you
> > can do that, then why bother with deleting/recreating them in the
> > first place?
>
> Well, I wasn't really considering using a policy for the index, I was
> thinking of using the index for other policies (like key release).
> However, even though you can have a policy for read and write, you
> can't have a policy for delete unless you have access to the platform
> hierarchy (which the problem statement above explained is getting
> increasingly unlikely), so your index can still be reset by deleting
> and recreating it (even if it is recreated with the same policy).
> You're right that such an index would be detectably uninitialized
> unless whoever deleted it can also write to it.

Yes, deletion doesn't really matter as long as the write policy for
the NV is properly chosen so that whoever deletes/recreates the NV
cannot write to it.

> >  And if you set a different access policy on them then the "name" of
> > the nvindex would change, and it would become useless in all
> > references from other objects/quotes/…
>
> Right but to take a NV Extend index, you're saying I can delete it and
> recreate it with exactly the same policy and attributes (so same name)
> but then to prevent me placing malicious entries in it, the policy has
> to be narrowly crafted to prevent malicious actors extending it
> (because then policy can't tell the difference between that recreated
> index and the original one).  I've thought about this, but haven't ever
> really been able to come up with usable policies, because all such
> policies end up requiring either a privileged locality to write from or
> a shared secret between the TPM and the trusted writer.

So my understanding is that you want fake PCRs, i.e. NV indexes that
are world-readable, and world-extendable, and cannot be reset,
correct?

So a write policy like this should work, no:

    A TPM2_PolicyOR with three branches:
        1. TPM2_PolicyCommandCode(TPM2_NV_Write) +
           TPM2_PolicyNvWritten(writtenSet=false) +
           TPM2_PolicySigned(…)
        2. TPM2_PolicyCommandCode(TPM2_NV_Write) +
           TPM2_PolicyNvWritten(writtenSet=true)
        3. TPM2_PolicyCommandCode(TPM2_NV_Read)

(where "+" is suposed to mean AND...)

So the first branch covers initialization. The branch first checks for
*Write* access, and whether the NV hasn't been written yet. It then
combines that with PolicySigned policy whith some public key. The idea
would be to use a key pair here that you generate for this purpose
only and throw it away after initialization. You could use other
policies here too i guess. Important is that you use a policy here
that only you as the creator can fulfill, and that fully pins all
authentication objects you use, like PolicySigned does.

The second branch covers later extensions, all it checks is that the
PCR is already initialized, and then makes no further restructions.

The third branch covers reading, and makes no restrictions beyond that.

I haven't tested the above, but it was my understanding that this is
how you'd do it.

Crucial in all of the above is that you reference the NV indexes
afterwards by their full name (thus also by their policy, which pins
the public key of TPM2_PolicySigned), instead just by their numeric
handle. Because if you'd ref them by their numeric handle only, then
of course anyone can recreate them with a different policy without you
noticing it. The important part is that you assign a policy to the NV
index that ensures only you could have initialized them, because they
pin some resource only you have control over.

In upcoming systemd 255 we now provide an IPC API for local clients to
measure stuff into PCRs, and write a TCG-CEL record about it
automatically. I was looking into extending that to also allow writing
NV-index based "fake PCRs" and the above is basically what I had in
mind to implement that.

But admittedly I am talking a bit out of my ass here, since I did not
in fact implement the above. But I don't see why it wouldn't work.

> > This logic is explicitly mentioned in that tpm book btw, it took me a
> > while to grok how great that concept is, since it basically means you
> > don't have to be concerned about removed/readded nvindexes at all.
>
> Which TPM book is this?

"A practical guide to TPM 2.0". The one that always shows up in your
google searches...

Lennart

--
Lennart Poettering, Berlin

Re: Discussion about using NV indexes for kernel properties like localities and PCRs

[James Bottomley]

On Mon, 2023-12-04 at 10:20 +0100, Lennart Poettering wrote:
> On Fr, 01.12.23 17:23, James Bottomley
> (James.Bottomley@HansenPartnership.com) wrote:
[...]
> > > > I'm bringing this up for discussion now, in case anyone has a
> > > > better idea or wants to add nuances (like measuring the
> > > > creation to a real PCR and adding an event log to measured
> > > > boot) before I (or someone else) look into coding it up.
> > > 
> > > Why would that be necessary though? The "name" of an nvindex pins
> > > the access policy of the nvindex.
> > 
> > I assume you're talking about using TPM2_PolicyNameHash coupled
> > with TPM2_PolicyNV?  That pins to NV index value and name, but the
> > problem is that still doesn't necessarily solve the deletion
> > problem (see below).
> 
> I was thinking TPM2_PolicyAuthorizeNV and similar things too. They
> generally pin NVs by "name".

Heh, well, you have to be careful with that one as I just discovered
with NV PINs.  Most of the TPMs I have in my system actually comply
with rev 116.  NV PIN was added in rev 124 and PolicyAuthorizeNV in rev
132 which means they're not universally supported by TPM2 systems.

> > >  And nvindexes are always created uninitialized, thus to to
> > > initialize one you just created (i.e. execute the first write to
> > > it) you must be able to fulfill the write policy set for it. But
> > > if you can do that, then why bother with deleting/recreating them
> > > in the first place?
> > 
> > Well, I wasn't really considering using a policy for the index, I
> > was thinking of using the index for other policies (like key
> > release). However, even though you can have a policy for read and
> > write, you can't have a policy for delete unless you have access to
> > the platform hierarchy (which the problem statement above explained
> > is getting increasingly unlikely), so your index can still be reset
> > by deleting and recreating it (even if it is recreated with the
> > same policy). You're right that such an index would be detectably
> > uninitialized unless whoever deleted it can also write to it.
> 
> Yes, deletion doesn't really matter as long as the write policy for
> the NV is properly chosen so that whoever deletes/recreates the NV
> cannot write to it.
> 
> > >  And if you set a different access policy on them then the "name"
> > > of the nvindex would change, and it would become useless in all
> > > references from other objects/quotes/…
> > 
> > Right but to take a NV Extend index, you're saying I can delete it
> > and recreate it with exactly the same policy and attributes (so
> > same name) but then to prevent me placing malicious entries in it,
> > the policy has to be narrowly crafted to prevent malicious actors
> > extending it (because then policy can't tell the difference between
> > that recreated index and the original one).  I've thought about
> > this, but haven't ever really been able to come up with usable
> > policies, because all such policies end up requiring either a
> > privileged locality to write from or a shared secret between the
> > TPM and the trusted writer.
> 
> So my understanding is that you want fake PCRs, i.e. NV indexes that
> are world-readable, and world-extendable, and cannot be reset,
> correct?

Yes, effectively a simple extension of the PCR system beyond 24 indexes
for anyone to use.

> So a write policy like this should work, no:
> 
>     A TPM2_PolicyOR with three branches:
>         1. TPM2_PolicyCommandCode(TPM2_NV_Write) +
>            TPM2_PolicyNvWritten(writtenSet=false) +
>            TPM2_PolicySigned(…)
>         2. TPM2_PolicyCommandCode(TPM2_NV_Write) +
>            TPM2_PolicyNvWritten(writtenSet=true)
>         3. TPM2_PolicyCommandCode(TPM2_NV_Read)
> 
> (where "+" is suposed to mean AND...)

Well, no, that would mean the entity doing the create (first write) has
to be able to sign the command.  That requires a permanent secret (the
private key).  The problem I have is that I want to do this in the
kernel.  The kernel can generate ephemeral secrets but not permanent
ones that last across a boot and it certainly can't usefully (without
leaking) carry persistent private keys, so whatever scheme we come up
with for the kernel can't code a policy that contains a long lived
secret.  That's why I went for restricted creation and deletion: The
kernel can create the index and populate it with a random auth known
only to it and no-one else can delete and recreate.  Thus we have an
index that can be mentioned in PolicNV of a sealed object meaning that
only the kernel can unseal it.  For the NV Extend Indexes it means
they're wold readable and writable but usable by anyone and possessing
a no reset guarantee.

> So the first branch covers initialization. The branch first checks
> for *Write* access, and whether the NV hasn't been written yet. It
> then combines that with PolicySigned policy whith some public key.
> The idea would be to use a key pair here that you generate for this
> purpose only and throw it away after initialization. You could use
> other policies here too i guess. Important is that you use a policy
> here that only you as the creator can fulfill, and that fully pins
> all authentication objects you use, like PolicySigned does.
> 
> The second branch covers later extensions, all it checks is that the
> PCR is already initialized, and then makes no further restructions.
> 
> The third branch covers reading, and makes no restrictions beyond
> that.
> 
> I haven't tested the above, but it was my understanding that this is
> how you'd do it.
> 
> Crucial in all of the above is that you reference the NV indexes
> afterwards by their full name (thus also by their policy, which pins
> the public key of TPM2_PolicySigned), instead just by their numeric
> handle. Because if you'd ref them by their numeric handle only, then
> of course anyone can recreate them with a different policy without
> you noticing it. The important part is that you assign a policy to
> the NV index that ensures only you could have initialized them,
> because they pin some resource only you have control over.
> 
> In upcoming systemd 255 we now provide an IPC API for local clients
> to measure stuff into PCRs, and write a TCG-CEL record about it
> automatically. I was looking into extending that to also allow
> writing NV-index based "fake PCRs" and the above is basically what I
> had in mind to implement that.
> 
> But admittedly I am talking a bit out of my ass here, since I did not
> in fact implement the above. But I don't see why it wouldn't work.

I think it could work.  However to be effective in the above
PolicySigned, the entity creating the NV index will have to sign the
nonceTPM, meaning systemd will have to have the private key ... how
does that get provisioned? (it seems like a similar problem to
provisioning the kernel with a private key)

> 
> > > This logic is explicitly mentioned in that tpm book btw, it took
> > > me a while to grok how great that concept is, since it basically
> > > means you don't have to be concerned about removed/readded
> > > nvindexes at all.
> > 
> > Which TPM book is this?
> 
> "A practical guide to TPM 2.0". The one that always shows up in your
> google searches...

Thanks ... I didn't know anyone had written an actual book about the
TPM. I usually just get my insights from the architecture documents
(and how they change).

James

Re: Discussion about using NV indexes for kernel properties like localities and PCRs

[Lennart Poettering]

On Mo, 04.12.23 08:01, James Bottomley (James.Bottomley@HansenPartnership.com) wrote:

> On Mon, 2023-12-04 at 10:20 +0100, Lennart Poettering wrote:
> > On Fr, 01.12.23 17:23, James Bottomley
> > (James.Bottomley@HansenPartnership.com) wrote:
> [...]
> > > > > I'm bringing this up for discussion now, in case anyone has a
> > > > > better idea or wants to add nuances (like measuring the
> > > > > creation to a real PCR and adding an event log to measured
> > > > > boot) before I (or someone else) look into coding it up.
> > > >
> > > > Why would that be necessary though? The "name" of an nvindex pins
> > > > the access policy of the nvindex.
> > >
> > > I assume you're talking about using TPM2_PolicyNameHash coupled
> > > with TPM2_PolicyNV?  That pins to NV index value and name, but the
> > > problem is that still doesn't necessarily solve the deletion
> > > problem (see below).
> >
> > I was thinking TPM2_PolicyAuthorizeNV and similar things too. They
> > generally pin NVs by "name".
>
> Heh, well, you have to be careful with that one as I just discovered
> with NV PINs.  Most of the TPMs I have in my system actually comply
> with rev 116.  NV PIN was added in rev 124 and PolicyAuthorizeNV in rev
> 132 which means they're not universally supported by TPM2 systems.

Yeah, I am aware. In systemd we started to use TPM2_PolicyAuthorizeNV
now (for implementing a PCR access policy for disk encryption that can
relatively nicely handle PCR changes), but I have the luxury to simply
say that this is not supported on old TPMs, and treat old TPMs like
non-existing TPMs.

> Yes, effectively a simple extension of the PCR system beyond 24 indexes
> for anyone to use.
>
> > So a write policy like this should work, no:
> >
> >     A TPM2_PolicyOR with three branches:
> >         1. TPM2_PolicyCommandCode(TPM2_NV_Write) +
> >            TPM2_PolicyNvWritten(writtenSet=false) +
> >            TPM2_PolicySigned(…)
> >         2. TPM2_PolicyCommandCode(TPM2_NV_Write) +
> >            TPM2_PolicyNvWritten(writtenSet=true)
> >         3. TPM2_PolicyCommandCode(TPM2_NV_Read)
> >
> > (where "+" is suposed to mean AND...)
>
> Well, no, that would mean the entity doing the create (first write) has
> to be able to sign the command.  That requires a permanent secret (the
> private key).  The problem I have is that I want to do this in the
> kernel.  The kernel can generate ephemeral secrets but not permanent
> ones that last across a boot and it certainly can't usefully (without
> leaking) carry persistent private keys, so whatever scheme we come up
> with for the kernel can't code a policy that contains a long lived
> secret.

These fake-PCR NVs are semi-persistent anyway (i.e. their definition
is persistent, but their value is not). Hence if you allocate one NV
index for this anyway, then maybe just allocated a second, and you
might just store the key in it? And that other NV index uses
TPM2_NV_ReadLock stuff so that it can be read during early boot, and
then no more until a reset happens.

I suggested this to Matthew for the hibernation stuff: store the
encryption secret in an nvindex and make sure it is only accessible
during kernel initialization, and not later via the read lock stuff.

Lennart

--
Lennart Poettering, Berlin