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

[Dr. Greg]

On Mon, Jan 23, 2023 at 11:48:25AM -0600, William Roberts wrote:

Good morning, I hope the week is going well for everyone.

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

Indeed, I was going to mention that.  Falling back means that the
security guarantee is lost, perhaps silently and lost on the owner of
the system, if they are not paying attention to things like the boot
logs.

One of the persistent challenges with these hardware security
technologies is that they need to be ubiquitous to be useful,
something that has historically plagued all of these technologies.

> 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 will be necessary, and important, to differentiate between
'supported' and 'available'.

Historically, security features have been SKU'ified, in other words,
made available only on specific SKU's, even when the platform writ
large has the necessary support.  These SKU's are designed to be
directed at various verticals or OEM's who are perceived to be willing
to pay more for enhanced security.

I've had conversations on whether or not hardware technologies would
be available and the conversation usually ends with the equivalent of:
"Show us the business case for supporting this."

Which translates, roughly, into how much money are we going to make if
we offer this.

Unfortunately, without being ubiquitous, as you note for a long period
of time, there is no development interest, which in turn translates
into no market 'pull'.  A rather troublesome dilemma for security
innovation.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity