On Tue, May 8, 2018 at 10:36 AM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> 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. 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. > > > 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.) Best, David
