TriNetre - Archive for March 21, 2005

(no longer updated)

A recent post at Slashdot reminded me that I had intended to write on Trusted Computing (Treacherous Computing according to RMS) and how it could be a great enabler, but only if done correctly.

Before I proceed further let me clarify couple of things.

• The angle from which I am going to approach this issue - There is a technological and an ideological angle to approach this problem. I am choosing the technological angle mainly because if ideology is brought into the picture, it could cloud the issue by declaring a winner even before the fight.
• When I say Trusted Computing, I am referring to version 1.2 of the Trusted Computing Group's TPM Specification. I am going to examine the issues based on the specifications as it stands now and not how it can be extended to turn it into an evil or godly technology. Furthermore I do not refer to Microsoft's NGSCB initiative when discussing TPM in this post. Maybe in another post later on.

Let me start by trying to reply to a question raised in the Slashdot discussion:

A scenario played out last summer for me with... a local Mom and Pop grocery store kept EVERYTHING on their Windows XP PC, and one day it went toes-up. They were understandably distraught -- all of their business spreadsheets and wedding pictures (over 1G) were on the hard drive and they couldn't get to them. They were prepping the machine to be sent in to be re-imaged. I asked them if they knew that meant they were likely to lose their data. She was almost in tears. I went home, got my Knoppix CD, and with their permission, played... and, recovered ALL of their data and burned it redundantly to CD's.

So I ask, if theirs were a "trusted computing" machine, and I had tried to do the same thing for them with my Knoppix CD, would I have been able to? I'd hate to think this is one (of many) of the things we lose in this "better" world.

My answer would be, if the data was left in a unencrypted state (which is what it would be for a less than paranoid person), yes. Now that could give an idea where I am headed, so if you are from the other side of the "fight", you are free to switch off and just head to the comment section and blast me, but why not keep reading just to get enough arsenal?

Trusted Computing Platform Alliance (TCPA) chip provides three main functionalities:

1. Protected Capabilities - this provide functionality to store sensitive data into shielded locations (memories, registers etc.). These data locations can be accessed by protected capabilities. In effect it provides the ability to store in protected registers called Platform Configuration Registers (PCR), hashes of configuration information throughout the boot sequence. Once booted, data (such as symmetric keys for encrypted files) can be "sealed" under a PCR. The sealed data can only be unsealed if the PCR has the same value as at the time of sealing. This provides a "trusted" boot functionality.
2. Attestation - TCPA provides the avenue for third parties to preform remote attestation. The TCPA chip can report the data it stores in say the PCRs by signing the data with the Attestation Identity Key (AIK). AIKs are generated by the TPM. This credential related to the AIK key is provided by the TPM using an Endorsement Key (EK) that is generated at the time of manufacture of the chip. EK is the only key pair that cannot be re-created or changed by a end user. However, functionality has been provided to the end user to disable the use of the EK altogether.
3. Integrity Measurement, Storage and Reporting - This process allows the chip to obtain platform specific metrics, store these values and report these values if and when requested by a external third party.

One of the biggest "threat" perceived by the attacker of the TPM idea is the use of the "trusted boot" to register system specific values into the PCR. Yes, this can be used to collect details of various system binaries (for example IBM has developed a "TCG-based Integrity Measurement Architecture" that can be used to securely record hash of binaries like the GCC compiler, kernel image etc. While this much is possible, what is not possible is the ability of the chip/BIOS to prevent the machine from loading a new kernel image, or replacing the GCC compiler with a new one or letting the user boot into Linux instead of Windows. Let me repeat, the TPM chip cannot prevent the end user from booting into Linux or installing new softwares.

The only private key that cannot be loaded or cleared by the end user of the system is the Endorsement Key. This key is used to allow the TPM chip manufacturer endorse a chip to allow it to perform trusted attestation and reporting mentioned above. As admitted by IBM "There is certainly a privacy aspect of access to the endorsement key, as it uniquely identifies the platform, and the TCPA specification goes to great lengths to allow for anonymous certification." But it has to be noted at the same time that the user can turn off the use of EK and prevent programs from using the EK!

While the TPM chip architecture rely on "roots of trusts" - components that must be trusted to work properly, the chip is not designed for tamper resistance. Tamper resistance is not a requirement for the TPM specifications. For example, IBM's TPM predecessor "Embedded Security Subsystem" is actually implemented as an LPC daughterboard that is not secure against power analysis, RF analysis and timing attacks.

Making a DRM system using a chip with these "limitations" is not feasible, mainly because the threat model does not consider the end user (owner) as an attacker!

Since all that TPM provides is an attestation and reporting mechanism using the PCRs and other protected storage, it cannot prevent me from installing or booting into Linux. What is more, IBM has already developed Linux drivers to use their TPM chip capabilities.

Now to come back to the question I answered in the beginning, if I had TPM enabled machine installed with Windows, as long as the data is not encrypted using a TPM chip generated and protected private key (which is the case unless specifically asked by the machine owner's program), the data can be easily recovered by booting using a Knoppix CD.

For those interested in going deeper into the the debate over TPM, couple of reading materials are recommended:

• Ross Anderson's TCPA/Palladium Frequently Asked Questions", critical of TCPA.
• Lucky Green’s Defcon presentation (pdf), critical of TCPA.
• "Clarifying Misinformation on TCPA" (pdf), rebuttal to the points raised in the two documents listed above.
• TCG Main Specifications (zip).