On 10/02/07, Michael Sparks wrote: > > The TPM was designed with this in mind, and each TPM has its own keys. > > Because they're internal to the TPM and can't be extracted by software, > > you can have confidence in the TPM's authenticity. > > This is waaaay off topic, but how does a remote third party that wants to > trust your system tell the difference between (for example): > > * A remote system that's just been bought that's using the TPM to securely > store keys for a secure store/streaming system > > * A remote system that is running a virtual machine that looks to the > operating system sitting inside that virtual machine as if it has a TPM > module, and that remote machine looks like its just been installed, and > the virtualised OS is otherwise installed identically.
It's all about the keys installed at manufacture. Obviously, the TPM is just a computer itself (usually an 8 bit micro, but a computer nonetheless) and could be emulated in software. The security comes from the isolation of the TPM and the main computer - there is memory in the TPM that cannot be accessed from the big bad outside world. By placing a key in the device during manufacture (known as the Endorsement Key - Google Pt 1), there is an identification that cannot be spoofed by a rogue TPM. The public part of the Endorsement Key is signed by a certificate authority as belonging to a particular TPM. Now, an Attestation Identity Key is generated by the TPM for use by an application that wants to check the validity of the TPM. That's a private/public key pair that is signed by the private Endorsement Key. That new key can be sent to the certificate authority, who can check the Endorsement Key's signature - and also if that Endorsement Key has been revoked. If all's ok, the certificate authority signs the Attestation Identity Key, so the application (who also trusts the CA) knows the TPM is ok. There is also a more advanced method for validating the authenticity of a TPM without the need for trusted third party involvement, called Direct Anonymous Attestation. This presentation gives an overview of DAA: http://www.zurich.ibm.com/security/daa/daa-slides-ZISC.pdf Slightly more in depth presentation: https://www.trustedcomputinggroup.org/news/presentations/051012_DAA-slid es.pdf This paper describes in detail with proofs. Exercise for the reader! http://www.hpl.hp.com/techreports/2004/HPL-2004-93.pdf > For all intents and purposes the remote third party (eg a person wanting > to trust) should get the same responses from the secure system, and the > supposedly secure system. If the virtualised TPM has the correct EK, you'd be right. > I don't work with these things, but having read the linux journal > article[1] sometime back, and knowing how virtualisation works, and the > fact that any hardware system can be emulated I can't see how a remote > third party can truly tell the difference. > > [1] For anyone else, if they haven't read this, its worth reading since > you'll see that TCPA/TPM is a double edged sword that has many real > uses beyond things like DRM. (Once I read it, it struck me that its > primary use is for helping lock down a military laptop in the event > of it being compromised/stolen in an even more secure fashion than > people who are used to used an encrypted loopback device are used to) Thanks for mentioning that. Honestly, DRM != TPM. Although it's intended for day-to-day use in locking down enterprise PCs more than the military. For example, Vista's Bitlocker will take advantage of a TPM to store the drive encryption key (that's the only use that Vista puts the TPM to, as far as I'm aware) The TCG is not oblivious to the bad press it has received from certain in the community. Design decisions are made around principles that seem fine to me. For example, from: https://www.trustedcomputinggroup.org/specs/bestpractices/Best_Practices _Principles_Document_V2_0.pdf "Each owner should have effective choice and control over the use and operation of the TCG-enabled capabilities that belong to them; their participation must be opt-in. Subsequently any user can reliably disable the TCG functionality in a way that does not violate the owner's policy." Note the dichotomy between user and owner - I'm using my company's laptop right now, and it's their right to lock it down. But if I were using my desktop, that decision would be mine to make. > Based on your comments, I'm guessing that the TPMs themselves have default > hardware keys as well as being able to generate keys and those default > keys can in fact be authenticated rather than just being able to > generated? What's to stop someone opening up the hardware to find out what > that is? Obviously that's outside the realms of your average developer, > but it's not outside the capabilities of a commercial company. That's right (as explained above). I've mentioned before that security isn't binary, and you only spend as much on security as is economically sensible. Most TPMs will be developed on tamperproof processes, and give smartcard level protection to secrets. That's strong - not perfect - but you need to be determined and well resourced to extract secrets from a well designed device. There are few commercial companies that I would expect to have such capabilities. In addition, there are no class secrets in the TPM, meaning if you do crack one - you've only cracked one. > All clearly hypothetical examples, with varying levels of likelihood, but > since you say you work in the area, I'm curious as to the answer or > pointers since I suspect there is :) The guys who develop these specs think about them! Cryptographers have come up with some fantastic maths - DAA is beyond my skill to invent. But if you really want to blow your mind, look at the revocation mechanisms for AACS. > Feel free to respond with terms that I should google for BTW :) Hope to have helped! Tim -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/[email protected]/
