Re: [PATCH v5 03/11] tpm: Allow PCR 23 to be restricted to kernel-only use

[James Bottomley]

On Mon, 2023-01-23 at 11:48 -0600, William Roberts wrote:
> On Fri, Jan 20, 2023 at 9:29 PM Jarkko Sakkinen <jarkko@xxxxxxxxxx>
> wrote:
> > 
> > On Sat, Jan 14, 2023 at 09:55:37AM -0500, James Bottomley wrote:
> > > On Tue, 2023-01-03 at 13:10 -0800, Matthew Garrett wrote:
> > > > On Tue, Jan 3, 2023 at 1:05 PM William Roberts
> > > > <bill.c.roberts@xxxxxxxxx> wrote:
> > > > 
> > > > > What's the use case of using the creation data and ticket in
> > > > > this context? Who gets the creationData and the ticket?
> > > > > Could a user supplied outsideInfo work? IIRC I saw some
> > > > > patches flying around where the sessions will get encrypted
> > > > > and presumably correctly as well. This would allow the
> > > > > transfer of that outsideInfo, like the NV Index PCR value to
> > > > > be included and integrity protected by the session HMAC.
> > > > 
> > > > The goal is to ensure that the key was generated by the kernel.
> > > > In the absence of the creation data, an attacker could generate
> > > > a hibernation image using their own key and trick the kernel
> > > > into resuming arbitrary code. We don't have any way to pass
> > > > secret data from the hibernate kernel to the resume kernel, so
> > > > I don't think there's any easy way to do it with outsideinfo.
> > > 
> > > Can we go back again to why you can't use locality?  It's exactly
> > > designed for this since locality is part of creation data. 
> > > Currently everything only uses locality 0, so it's impossible for
> > > anyone on Linux to produce a key with anything other than 0 in
> > > the creation data for locality.  However, the dynamic launch
> > > people are proposing that the Kernel should use Locality 2 for
> > > all its operations, which would allow you to distinguish a key
> > > created by the kernel from one created by a user by locality.
> > > 
> > > I think the previous objection was that not all TPMs implement
> > > locality, but then not all laptops have TPMs either, so if you
> > > ever come across one which has a TPM but no locality, it's in a
> > > very similar security boat to one which has no TPM.
> > 
> > Kernel could try to use locality 2 and use locality 0 as fallback.
> 
> I don't think that would work for Matthew, they need something
> reliable to indicate key provenance.

No, I think it would be good enough: locality 0 means anyone (including
the kernel on a machine which doesn't function correctly) could have
created this key.  Locality 2 would mean only the kernel could have
created this key.

By the time the kernel boots and before it loads the hibernation image
it will know the answer to the question "does my TPM support locality
2", so it can use that in its security assessment: if the kernel
supports locality 2 and the key wasn't created in locality 2 then
assume an attack.  Obviously, if the kernel doesn't support locality 2
then the hibernation resume has to accept any old key, but that's the
same as the situation today.

> I was informed that all 5 localities should be supported starting
> with Gen 7 Kaby Lake launched in 2016. Don't know if this is
> still "too new".

It's probably good enough.  Current laptops which can't use locality 2
are in the same position as now, but newer ones can provide more
security guarantees.

There is, however, another wrinkle: can Kaby Lake be persuaded, though
bios settings perhaps, to shut off the non zero localities?  This would
allow for a downgrade attack where you shut off locality 2 then present
a forged locality 0 key and hibernation image; the kernel will think,
because it can't access locality 2, that it's in a reduced security
environment so the key might be OK.  We could fix this by requiring
Kaby Lake and beyond to have locality 2 and refusing to hibernate if it
can't be accessed and building "is this Kaby lake or beyond" into the
check for should I have locality 2, but this is getting complex and
error prone.

James