On Sun, Apr 24, 2016 at 01:15:15AM +0200, Lars Seipel wrote: > On Sat, Apr 23, 2016 at 02:57:55PM +0200, Kevin Kofler wrote: > > Matthew Garrett wrote: > > > Remote attestation is a mechanism by which […] > > > > How does the remote machine know that what is answering is a physical TPM > > and not a software emulation? Does it need to have the individual TPM's > > public key in advance? > > If I understood it correctly, the TPM keys can be chained back to a > manufacturer key and likely some kind of CA. So while software emulation > is unfeasible without the ability to extract private keys from either > TPMs or their vendors, you should be able to buy any TPM, feed it with > exactly the values you want, and get yourself a signed attestation of > TPM state that has no relationship to what is actually running on your > computer. That works as long as the other side only verifies against > some generic vendor public key. Yes, but this isn't a one-time thing because the protocol includes nonces to check for freshness: https://seclab.stanford.edu/pcl/cs259/projects/cs259_final_lavina_jayesh/CS259_report_lavina_jayesh.pdf
> If you precisely know the key the signature should've been made with > (e.g. because you did the initial machine setup and then left it with > some colocation facility) you can verify it against the expected public > key directly. Used this way, remote attestation might actually be > useful. Also, it would appear each TPM is intended to get its own key pair and a certificate signed by a CA, so it's the cert and trusted CA you'd want to replace. That way if you think a TPM was compromised, you can revoke the TPM's cert & thus blacklist the TPM (vs. having one key pair shared by all TPMs).
smime.p7s
Description: S/MIME cryptographic signature
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
