Vivek’s Soapbox

Seth Schoen has proposed owner override as a mechanism to mitigate some of the treacherous aspects of remote attestation:

TCG should empower computer owners to override attestations deliberately to defeat policies of which they disapprove. Giving the owner this choice preserves an essential part of the status quo: third parties can never know for sure what’s running on your PC. TCG already defines a platform owner concept. The TCG specification also should provide for a facility by which the platform owner, when physically present, can force the TPM chip to generate an attestation as if the Platform Configuration Registers (PCRs) contained values of the owner’s choice instead of their actual values.

Stefan Bechtold has a critique of owner override. Besides that, I believe owner override suffers from another fundamental shortcoming.

The reason trusted hardware (in the form of a TPM, in this case) is needed is that software cannot vouch for its own integrity. Its easy to simply go one level of abstraction below any piece of software, subvert it at the lower level, and make it believe that everything is OK. This is the fundamental principle that rootkits use. Secret keys cannot be stored in software because other software can easily snoop it. So we need something outside the software stack — trusted hardware — that can reliably and accurately measure software integrity, and then also securely report it (to either the local user, or remote entities).

The hardware must be designed in such a way that its measurements and reports cannot be forged and tampered with. That is the central guarantee that trusted hardware buys us. And if the user were able to “forge” PCR entries in the TPM, that would simply invalidate the entire design of the TPM.

Besides, owner override will probably be performed on behalf of the owner by a piece of software. What if the owner-override software is taken over by malware? The possibility certainly exists. Then we are back to square one, and we might as well have had systems without a TPM in the first place.

Owner-override also has implications for sealed storage. The sealed storage functionality in the TPM binds encrypted data to a particular PCR value (this has its own problems and people have been investigating alternatives). The idea is that deviations from that PCR value indicate that your system has been compromised, and so the data will not be exposed in the clear. If I could put in my own PCR values, sealed storage would be useless.

In effect, owner override completely demolishes the very technical end for which trusted hardware was put into systems in the first place.

I don’t think that we need to throw the baby out with the bath water. I agree with Seth when he says that remote attestation has a number of flaws (I’ve pointed out a few in our paper). However, I also think that Trusted Computing can significantly help with security in general, and rather than severely crippling it, we should look for technical means to overcome its shortcomings. There are a number of proposals out there that recognize the problems with remote attestation, and present alternatives:

• Direct Anonymous Attestation (paper)recognizes that privacy is one of the biggest problems with standard remote attestation and brings pseudo-anonymity to remote attestation. It is now part of the TPM 1.2 specification.
• Property-based attestation uses a trusted third party to map signed hashes to program properties.
• Last, but not least, our very own technique, Semantic Remote Attestation, attests program behavior rather than program binaries. (I talk more about it here)