diff for duplicates of <1525963652.3258.4.camel@HansenPartnership.com> diff --git a/a/1.txt b/N1/1.txt index 34f054f..74994e8 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -7,23 +7,23 @@ On Thu, 2018-05-10 at 09:25 -0500, David R. Bild wrote: > > > <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 +> > > > 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 +> > > 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 +> 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 +> 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 @@ -42,7 +42,7 @@ TPM. > > 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 +> authorization, but not removed. If we disable the platform hierarchy > entirely, I think the credentials will no longer be available for > use. @@ -53,22 +53,22 @@ 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 +> > > 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 +> 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 +> 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, +> 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 +> 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 @@ -78,3 +78,7 @@ 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 +--- +To unsubscribe from this list: send the line "unsubscribe linux-usb" in +the body of a message to majordomo@vger.kernel.org +More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index af7cc9f..7069b23 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,14 +1,5 @@ - "ref\020180430125418.31344-1-david.bild@xaptum.com\0" - "ref\020180504130022.5231-3-david.bild@xaptum.com\0" - "ref\020180504190638.ikqhdvcqccakzdjd@ziepe.ca\0" - "ref\0CAAi9uDvyzk1vnQVXkJxRCATy85g4nwMLJjqu6rr1YZn9NV_TYw@mail.gmail.com\0" - "ref\020180508105515.GB6132@linux.intel.com\0" - "ref\01525793148.3672.8.camel@HansenPartnership.com\0" - "ref\0CAAi9uDvgd5+d5fNbSGEeEVvdHLzwid6SqC0BVA3BPXkFWR4ooQ@mail.gmail.com\0" - "ref\01525793785.3672.12.camel@HansenPartnership.com\0" - "ref\0CAAi9uDsLmW3K=1UYsmJKOc6hsXqcJXFHyO_scMan5u8d94D9=Q@mail.gmail.com\0" "From\0James Bottomley <James.Bottomley@hansenpartnership.com>\0" - "Subject\0Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM\0" + "Subject\0[v3,2/2] usb: misc: xapea00x: perform platform initialization of TPM\0" "Date\0Thu, 10 May 2018 07:47:32 -0700\0" "To\0David R. Bild <david.bild@xaptum.com>\0" "Cc\0Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>" @@ -29,23 +20,23 @@ "> > > <James.Bottomley@hansenpartnership.com> wrote:\n" "> > > > \n" "> > > > I don't see any reason to set an unreachable password for the\n" - "> > > > platform hierarchy if the UEFI didn't. If the desire is to\n" + "> > > > platform hierarchy if the UEFI didn't.\302\240\302\240If the desire is to\n" "> > > > disable the platform hierarchy, then it should be disabled, not\n" "> > > > have a random password set.\n" "> > > \n" "> > > \"Set random password and throw away the key\" was my way of\n" - "> > > disabling the platform hierarchy. Is there a better way of doing\n" + "> > > disabling the platform hierarchy.\302\240\302\240Is there a better way of doing\n" "> > > that?\n" "> > \n" "> > Well, yes, use TPM2_HierarchyControl to set phEnable to CLEAR.\n" "> \n" "> \n" - "> I'm not sure that will work for us. Let me give a little more detail\n" + "> I'm not sure that will work for us.\302\240\302\240Let me give a little more detail\n" "> about this card.\n" "> \n" "> The TPM holds access credentials for connecting to the Xaptum\n" "> network. This approach enables secure, zero-touch provisioning for\n" - "> IoT devices: Xaptum pre-provisions the TPMs *before* they are\n" + "> IoT devices: \302\240Xaptum pre-provisions the TPMs *before* they are\n" "> assembled onto a device PCB. The device is shipped directly from\n" "> factory to end customer. The first time it turns on, the TPM is used\n" "> to authenticate the Xaptum network. Using a TPM protects the\n" @@ -64,7 +55,7 @@ "> \n" "> We provision the credentials (the DAA secret key, specifically) under\n" "> the platform hierarchy. The key can be used without platform\n" - "> authorization, but not removed. If we disable the platform hierarchy\n" + "> authorization, but not removed.\302\240\302\240If we disable the platform hierarchy\n" "> entirely, I think the credentials will no longer be available for\n" "> use.\n" "\n" @@ -75,22 +66,22 @@ "> > > > I'd also say this is probably the job of early boot based on\n" "> > > > policy.\n" "> > > \n" - "> > > Agreed. And since this card has no \"early boot\", the\n" + "> > > Agreed.\302\240\302\240And since this card has no \"early boot\", the\n" "> > > driver/kernel need to do it.\n" "> > \n" "> > Early boot means userspace. for a hot pluggable device, this would\n" "> > probably be something in udev if you follow the no-daemon model and\n" "> > the daemon could do it if you do follow the daemon model.\n" "> \n" - "> Could you expand on the udev approach? I might not understand enough\n" + "> Could you expand on the udev approach?\302\240\302\240I might not understand enough\n" "> about udev (or the coming TPM resource manager changes) to follow the\n" "> suggestion.\n" "> \n" - "> This seems unsafe to me. There's a race between a malicious\n" + "> This seems unsafe to me.\302\240\302\240There's a race between a malicious\n" "> userspace program and the daemon to set the platform\n" - "> authorization. If the malicious program wins, it can reset the TPM,\n" + "> authorization.\302\240\302\240If the malicious program wins, it can reset the TPM,\n" "> removing the credentials, and the device won't be able to connect to\n" - "> the Xaptum network. (This is a liveness concern, not safety. A\n" + "> the Xaptum network. (This is a liveness concern, not safety.\302\240\302\240A\n" "> denial-of-service attack, essentially.)\n" "\n" "OK, I'm getting confused by your threat model. I don't think knowing\n" @@ -99,6 +90,10 @@ "this: I can execute a TPM2_Clear to regain the platform auth and if you\n" "disable this, I can't re-own the TPM at all.\n" "\n" - James + "James\n" + "---\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-usb\" in\n" + "the body of a message to majordomo@vger.kernel.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -cf90bdada13eb15bfd8de1c7659b8096cd13af9c9d5605ac2d0a1a27053909f5 +5af490e0476d850551d152bca7fb5a3f2af851dba99630dd8876fa9c0a9d0aa1
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.