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

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