InvestorsHub Logo
icon url

waverider

08/18/05 9:00 AM

#92201 RE: waverider #92198

orda also RE: Linux symposium...........

I was under the impression that TPM were windows based and not Linux ready at this time. Why a Linux symposium?
icon url

orda

08/18/05 9:39 AM

#92202 RE: waverider #92198

I don't know. I'm not



even sure this was the same reference (person, source) as before. It would be nice to have it definitively cleared up or explained.

icon url

x-point

08/18/05 4:42 PM

#92262 RE: waverider #92198

waverider re: Ottawa Linux Symposium and the demo not working as intended.

What was said:

"TPM chips are meant to be credentialed by TPM chip manufacturers. The system gets a platform credential, and together an attestation ID is achieved. In theory. Manufacturers are not keeping the public side of TPM keys and the system is not working as intended as a result.

The TPM keys have to be manufacturer verifiable to work. Trusted systems where this is particularly important are things like bank machines and automatic voting machines."

Here is my take on this:

The TPMs work and the TPM keys work, but the trust infrastructure isn't working. While this isn't particularly good news it probably shouldn't be all that shocking when you look at the complexity of what is being built here; i.e. a broad based, public-network, electronic trust infrastructure.

(This will be rolled out in stages, and getting Trusted Platforms into the market is just the first stage IMO).

'Trust' is a relative concept, and different levels of trust will be acceptable to different entities. I may choose to trust my new PC/TPM platform because I bought it from Dell and I don't think that Dell will risk their reputation by selling a compromised product. So I am also trusting that they vetted out the TPM manufacturer and the system assembler. I am also trusting that UPS didn't allow anyone to tamper with the PC/TPM during shipment. This is all fine and good for me, a private individual, but perhaps not so fine if I am a bank, a nuclear research lab, or the Dept. of Homeland Security.

But what about if I buy a PC/TPM platform from a white box assembler? Is that trustworthy? And what if the TPM I need to trust isn't the one I bought and is in my posession, but rather it is the one YOU bought and is in your posession, and we are interacting over a network? Should I ever trust a kiosk PC/TPM to log in to my broker or bank. How do I know it really is my bank or broker that my TPM is attempting to set up a secure communication with?

The TCG approach to building trust into the user devices (local or remote) is to have the manufacturers and assemblers of the TPMs and the platforms issue signed guarantees that their products and their processes conform to the TCG specifications. So when I need to access some computation on your machine I can first inspect these attestation of conformance certificates pertaining to you machine that will then guide me as to what level of trust I wish to place in your machine.

So these researchers are saying that these conformance certifications aren't being provided when you buy a TPM based Trusted Platform, or at least that was the case when they did their research. But this doesn't mean that the TPM is without value to me; I can still use it along with my ETS to encrypt my files and folders and such. And because trusted servers apparently aren't in the market yet the services don't exist that make use of remote attestation and attestation identities anyway. But I do wonder how my new machine will become trustworthy when that day arrives.

In the interim perhaps entities like Diebold can establish through industry contacts, or perhaps by contract, that the TPM/Trusted Platforms that they are buying in fact conform to all TCG specifications. They may even get conformance certifications that attest to those facts.

Anyhow, I have e-mailed SKS about this but he hasn't responded as yet. I also e-mailed one of the researchers from the conference and I'll attach the main body of our exchange here:

Q: I know that TPMs are being utilized in the market so I have to conclude the proper EK credentials are shipping as well. As to the manufacturers keeping a copy of PubEK, I don't see any useful reason why they would need to, or how this would have any affect on the system of attestation working as intended.

A: It is not clear to me whether the EK is created during manufacturing time or when the user takes ownership of the system. Either way, the TPM credential is not being created, nor is the platform credential. The manufacturer needs to keep a copy of the PubEK or the certificate, so that the TPM can prove that it is a valid TPM rather than an artificial one when requesting an AIK.

Q: Something is holding up implementation of attestation services, but I fail to see how manufacturers failing to keep records of the PubEKs, or the certificates, could be the culprit. I thought perhaps it was that the PrivacyCA's were not yet ready with the their infrastructure

A: This is definitely true as well. It didn't help that the mechanism to request an AIK is completely different between the 1.1 and the 1.2 specification. But without some record of the PubEK or the certificate, there is no way to prove to the PrivacyCA that a valid TPM is requesting an AIK which is a fundamental requirement for attestation to work.

As an aside, Sean Smith published a book this spring about Trusted Computing which reflects the changes in the TCG specs since the Siani Pearson book was published. It is called "Trusted Computing Platforms: Design and Applications". A little pricey but worth it.