Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2018-05-10 at 09:25 -0500, David R. Bild wrote:
> On Tue, May 8, 2018 at 10:36 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > 
> > On Tue, 2018-05-08 at 10:29 -0500, David R. Bild wrote:
> > > On Tue, May 8, 2018 at 10:25 AM, James Bottomley
> > > <James.Bottomley@hansenpartnership.com> wrote:
> > > > 
> > > > I don't see any reason to set an unreachable password for the
> > > > platform hierarchy if the UEFI didn't.  If the desire is to
> > > > disable the platform hierarchy, then it should be disabled, not
> > > > have a random password set.
> > > 
> > > "Set random password and throw away the key" was my way of
> > > disabling the platform hierarchy.  Is there a better way of doing
> > > that?
> > 
> > Well, yes, use TPM2_HierarchyControl to set phEnable to CLEAR.
> 
> 
> I'm not sure that will work for us.  Let me give a little more detail
> about this card.
> 
> The TPM holds access credentials for connecting to the Xaptum
> network. This approach enables secure, zero-touch provisioning for
> IoT devices:  Xaptum pre-provisions the TPMs *before* they are
> assembled onto a device PCB. The device is shipped directly from
> factory to end customer. The first time it turns on, the TPM is used
> to authenticate the Xaptum network. Using a TPM protects the
> credentials from being copied or duplicated by someone in the
> manufacturing chain.

OK, so these are effectively DevId keys.  However, what makes you think
knowing the platform auth allows you to duplicate the keys?  As long as
you created them correctly (as in without duplication authority) then
even knowing the platform authorization I can't get them out of your
TPM.

> These cards are designed for existing devices, like IoT gateways. You
> can't add a TPM to an existing PCB, but you can plug in a mini PCI-e
> card.
> 
> We provision the credentials (the DAA secret key, specifically) under
> the platform hierarchy. The key can be used without platform
> authorization, but not removed.  If we disable the platform hierarchy
> entirely, I think the credentials will no longer be available for
> use.

That's certainly true if you actually need to use the platform
hierarchy.  Your initial emails on the subject did say you were
disabling it though ...

> > > > I'd also say this is probably the job of early boot based on
> > > > policy.
> > > 
> > > Agreed.  And since this card has no "early boot", the
> > > driver/kernel need to do it.
> > 
> > Early boot means userspace. for a hot pluggable device, this would
> > probably be something in udev if you follow the no-daemon model and
> > the daemon could do it if you do follow the daemon model.
> 
> Could you expand on the udev approach?  I might not understand enough
> about udev (or the coming TPM resource manager changes) to follow the
> suggestion.
> 
> This seems unsafe to me.  There's a race between a malicious
> userspace program and the daemon to set the platform
> authorization.  If the malicious program wins, it can reset the TPM,
> removing the credentials, and the device won't be able to connect to
> the Xaptum network. (This is a liveness concern, not safety.  A
> denial-of-service attack, essentially.)

OK, I'm getting confused by your threat model.  I don't think knowing
the platform auth I can obtain your keys.  However, I agree, I can
definitely remove them.  However, setting platform auth doesn't solve
this: I can execute a TPM2_Clear to regain the platform auth and if you
disable this, I can't re-own the TPM at all.

James