| Your nitpicks and misinterpretations are not my factual errors. > TPM is not HSM Most TPMs we care about are their own piece of silicon. The software and firmware ones aren't real HSMs, but come on, we all know those are shortcuts to the real thing. > TPM is […] not enclave Never mentioned "enclave" in my article. > TPM […] does not allow running arbitrary computation. Hey, I said as much, that's the whole point of my article. > TPM is a specification […] Oh please. Can't I use the same word to refer to the TCG specs and actual instantiations in hardware or software? > HSM or TPM never release the signing key as authors writes. I never wrote that. > DICE does not release the initial seed used to derive the inital hash/key. Which is why I never said it did. > DICE addresses different market. […] Yes, I'm aware. I also noticed how the TCG manages to promote DICE without noticing it makes their baby TPM 2.0 obsolete. I'm guessing this is motivated cognition. In any case, I think the TCG should start working on a DICE-capable TPM 3.0 right away, and spare us the now needless complexity of TPM 2.0. |
Alas, TCG seems to have recognized the mistake, so they have recently proposed for the DICE to rely on a separate entity (the DPE) to handle all secrets and cryptographic operations:
https://trustedcomputinggroup.org/wp-content/uploads/TCG-DIC...
"Examples of environments that could be used for a DPE implementation are a secure coprocessor, discrete secure hardware, a Trusted Execution Environment (TEE), a type-1 hypervisor, operating system kernel, or another type of environment isolated with a hardware-backed mode switch."
The DPE re-introduces a whole class of problems (i.e. authentication and secure communications) that the DICE was meant to simplify away in the first place.