> 3. Local software can perform these operations, refusing to decrypt > content unless an acceptable endorsement is provided by the TPM.
That's one of the points I never understood... So far I know, on x86, there is no instruction which makes it possible to call the tpm device from userspace. Well, the software could use the IOPL field in the EFLAGS register to check if its in/out instructions are not trapped by an aggressive kernel, but a) a complete hardware emulator (bochs-like) could lie about the content of eflags, and b) if the software has to be able to use direct I/O, then it turns any software which requires TPM attestation into a very big potential security hole. So my first question is : how does the local software has to proceed, in order to check that the endorsement key he got from the kernel was really provided by the TPM? My other question is : how does the software knows that this endorsement key is acceptable? Well, if the software was installed by the hardware provider, this would be no problem, but otherwise : a) if it had to carry with itself any possible valid endorsement key value, or even only their signed hash value, it would make it very easy to break one of them, and then all the security would be defeated; and b) if it has to rely on a remote attestation, since it can't call directly the network card to ask the TPM-provider about the validity of this key (for the very same reason it can't call the tpm device directly), how should he behave in order to check that the answer he got wasn't simply faked? Emmanuel Colbus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
