3 ms·

> How did TPMs get these things right? To me, it seems they've gotten them direly wrong by baking in privileged keys. Even if TPMs came with no endorsement key

> How did TPMs get these things right? To me, it seems they've gotten them direly wrong by baking in privileged keys. Even if TPMs came with no endorsement key certificates, the platform could still trust-on-first-use the TPMs and create "privileged keys". The only way to prevent that would be to make TPMs useless. > I don't understand your counterpoint to my (3). It's not enough for the OS to have an option to not perform remote attestation - the owner needs to have the ability to perform a mock remote attestation. Otherwise a remote party can just demand remote attestation be done, and the owners's "choice" will have been nullified. I don't see how to do that without the party demanding attestation somehow establishing trust in your device, but that requires "privileged keys", and surely that party gets to say "no" (at least technologically; legally is another matter). There's also a tension in that attestation is very useful for enterprise security. I.e., servers and VMs in data centers and the cloud, as well as employer-provided personal devices. Hard to get that but also make it impossible for consumer personal devices to attest. Also, users do get better security from attestation, at the cost of being at the vendors' mercy regarding walled garden lock-in. TPMs are neutral in this, enabling both, secure systems and DRM, and preventing neither.

mindslight 4y ago
> Even if TPMs came with no endorsement key certificates, the platform could still trust-on-first-use the TPMs and create "privileged keys". The only way to prevent that would be to make TPMs useless I assume by "platform" you mean a remote party exerting control, bordering on non-consensual, over your local computer? If the hardware is not shipped with keys, the way to get around that would be to generate your own key external to the TPM, and load it into the TPM. Then the "platform" could trust that first-contact key all day long, but you would retain control. > I don't see how to do [mock attestation] without the party demanding attestation somehow establishing trust in your device That's the point of my requirement for the SE/TPM to spit out the attestation signing key when in reset mode. It grants the owner the ability to create mock attestations of the device as the previous owner knew it. Going forward, the owner can walk away and have the device create attestations that they can trust, with the condition that they aren't out of contact with the device for longer than the reset period. (The reset period requirement is what creates the distinction between a mere possessor, and the bona fide owner) > There's also a tension in that attestation is very useful for enterprise security. I.e., servers and VMs in data centers and the cloud, as well as employer-provided personal devices Yes, these are exactly the useful scenarios I envisioned when I wrote my comment, and would be fully supported with the requirements I laid out. What is not supported is claiming to sell someone a piece of hardware, while retaining indefinite control over it.
- cryptonector 4y ago
  > I assume by "platform" you mean [...] I mean the OEM who issues any "platform certificates" (in the TCG sense) for keys in the TPM's "platform key hierarchy". That would be, e.g., Dell. > If the hardware is not shipped with keys, the way to get around that would be to generate your own key external to the TPM, and load it into the TPM. If you have to do that every time, then you're always storing that key in the clear, and then you get no security advantage from having a TPM. If you have to do that once and then you get the key back wrapped in a secret key only the TPM knows, well, TPMs pretty much support that. And now the platform can do the thing you don't like: ship with such a wrapped key (and certificate for it), which then enables operating systems to implement DRM. You really can't get away from this. It's just not possible. Either you have a TPM-like device that is useful, or you don't have one, or you have one that's not useful (which is the same as not having one). > That's the point of my requirement for the SE/TPM to spit out the attestation signing key when in reset mode. It grants the owner the ability to create mock attestations of the device as the previous owner knew it. [...] Unfortunately that would ruin the TPM's security features in general. It would make it useless for enterprise, for example. > > There's also a tension in that attestation is very useful for enterprise security. I.e., servers and VMs in data centers and the cloud, as well as employer-provided personal devices > Yes, these are exactly the useful scenarios I envisioned when I wrote my comment, and would be fully supported with the requirements I laid out. Doesn't work. See above. > What is not supported is claiming to sell someone a piece of hardware, while retaining indefinite control over it. You can change the seeds any time you like.

mindslight 4y ago

> Even if TPMs came with no endorsement key certificates, the platform could still trust-on-first-use the TPMs and create "privileged keys". The only way to prevent that would be to make TPMs useless I assume by "platform" you mean a remote party exerting control, bordering on non-consensual, over your local computer? If the hardware is not shipped with keys, the way to get around that would be to generate your own key external to the TPM, and load it into the TPM. Then the "platform" could trust that first-contact key all day long, but you would retain control. > I don't see how to do [mock attestation] without the party demanding attestation somehow establishing trust in your device That's the point of my requirement for the SE/TPM to spit out the attestation signing key when in reset mode. It grants the owner the ability to create mock attestations of the device as the previous owner knew it. Going forward, the owner can walk away and have the device create attestations that they can trust, with the condition that they aren't out of contact with the device for longer than the reset period. (The reset period requirement is what creates the distinction between a mere possessor, and the bona fide owner) > There's also a tension in that attestation is very useful for enterprise security. I.e., servers and VMs in data centers and the cloud, as well as employer-provided personal devices Yes, these are exactly the useful scenarios I envisioned when I wrote my comment, and would be fully supported with the requirements I laid out. What is not supported is claiming to sell someone a piece of hardware, while retaining indefinite control over it.

cryptonector 4y ago
> I assume by "platform" you mean [...] I mean the OEM who issues any "platform certificates" (in the TCG sense) for keys in the TPM's "platform key hierarchy". That would be, e.g., Dell. > If the hardware is not shipped with keys, the way to get around that would be to generate your own key external to the TPM, and load it into the TPM. If you have to do that every time, then you're always storing that key in the clear, and then you get no security advantage from having a TPM. If you have to do that once and then you get the key back wrapped in a secret key only the TPM knows, well, TPMs pretty much support that. And now the platform can do the thing you don't like: ship with such a wrapped key (and certificate for it), which then enables operating systems to implement DRM. You really can't get away from this. It's just not possible. Either you have a TPM-like device that is useful, or you don't have one, or you have one that's not useful (which is the same as not having one). > That's the point of my requirement for the SE/TPM to spit out the attestation signing key when in reset mode. It grants the owner the ability to create mock attestations of the device as the previous owner knew it. [...] Unfortunately that would ruin the TPM's security features in general. It would make it useless for enterprise, for example. > > There's also a tension in that attestation is very useful for enterprise security. I.e., servers and VMs in data centers and the cloud, as well as employer-provided personal devices > Yes, these are exactly the useful scenarios I envisioned when I wrote my comment, and would be fully supported with the requirements I laid out. Doesn't work. See above. > What is not supported is claiming to sell someone a piece of hardware, while retaining indefinite control over it. You can change the seeds any time you like.