Vivek’s Soapbox

I finally submitted my dissertation to the UC Irvine library on Friday. After my final defense, this was the last hurdle to jump, and I have now officially completed my doctorate.

Here’s my dissertation. (PDF, 3.5 MB)

To cut a long story short, here is my thesis:

Remote attestation, one of the core mechanisms of Trusted Computing, can be
performed in a way that:

• reasons expressively about program behavior and dynamic properties
• enables a flexible, graded notion of trust
• avoids intractable management problems at both the client and server end
• does not tie attestation to a specific executable binary

In short, remote attestation can attest program properties, rather than program
binaries. I call this semantic remote attestation.

I gave a talk on semantic remote attestation in the language-based security seminar class today. Here are the slides for the talk.

There were many questions from the audience.

One of the questions — “Isn’t all this just about DRM?”

Unfortunately, while DRM is one of the possible applications of having a TPM in your machine, that is not the only thing about Trusted Computing. By itself, the TPM is a completely passive device. All it does is measure software, and then reliably and accurately report those measurements. It is policy-neutral. Policy is what is done in higher levels of software, like the OS, or a media player, based on the measurements reported by the TPM.

The central problem, in my opinion, is to have a trusted entity to vouch for software that is outside software, since software cannot vouch for itself.

There was also much discussion about the attack model. The TPM’s attack model only aims to protect against software attacks — with physical attacks all bets are off.

An interesting point, raised by Christian Stork: why can’t I load my own root keys into the TPM (as opposed to the manufacturer-certified keys that are embedded in every TPM), self-certify them, and then use them within my own PGP-like web of trust? Honestly, I don’t know. Maybe because the TPM designers think that web-of-trust models won’t work with the mass-deployment scenario they have in mind.

There was aso a lot of discussion about security policies. This is a recurring theme in almost all security research. The techniques are, relatively speaking, easy. The hard part is to specify a policy.

Oh — and going off topic — since I hand-wrote these slides on my Tablet PC, people are always surprised by the novelty of seeing hand-written slides on a PowerPoint presentation. Like my officemate, Andreas Gal, said: “We started with handwritten transparencies, then PowerPoint decks, and now we’re back to handwriting”. I said, “Yeah — but this time, it’s been done right!”

Here’s another example of how Trusted Computing can be used to provide application-level security guarantees.
Zhang, Chen and Sandhu investigate how Trusted Computing can be used to improve the integrity and authenticity properties of a distributed P2P network.

…we focus on the specific problems of data authenticity and integrity instead of discussing P2P security in general. We propose a general architecture that enhances the authenticity and integrity of data shared in these systems by using trusted computing (TC) technologies… Specifically, we propose a trusted reference monitor (TRM) in the platform of each peer beyond necessary trusted hardware and supporting functions. A TRM can monitor and verify the information a peer provides to ensure data authenticity.

They present an abstract architecture where every peer is endowed with a trusted reference monitor (TRM) that can gather and then transmit configuration data about its node to other peers (in the paper, they use Windows registry keys as an example). The TRM also acts as a mediator for access control decisions.

The basic trusted component is the trusted hardware including a TPM. A TRM is an application or service component running in the operating system’s user space, enforcing access control policies in general client-side platforms. The hardware, cooperating with the security kernel, provides necessary functions to the TRM, from basic cryptographic functions to platform and program attestation, and sealed storage for sensitive data.

(diagram taken from their paper)

Currently, most P2P systems are ridiculously easy to game. There are simply no checks on what a node says, and it could be saying anything at all. This is precisely the reason that we picked Gnutella as one of the example applications in our original paper on semantic remote attestation. As they point out in their paper, semantic remote attestation is one of the underlying techniques that could be used as a concrete implementation of their trusted reference monitor.
Complete citation for the paper:

Zhang, X.; Chen, S.; Ravi Sandhu, “Enhancing data authenticity and integrity in P2P systems,” Internet Computing, IEEE , vol.9, no.6pp. 42- 49, Nov.-Dec. 2005

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)

Stefan Bechtold talks about our paper on semantic remote attestation (local copy - slides of my USENIX VM talk) over on this TC Blog. In short, we think that remote attestation as it is now is fundamentally broken (see the paper for a long explanation of why), and semantic remote attestation tries to fix all that and attest program behavior rather than program binaries.

Stefan raises a couple of questions about our technique:

However, it seems to me that the proposal suffers from at least two limitations: First, although the authors give some examples of what kind of behavior their trusted virtual machine could analyze, it is an open question whether this mechanism can provide all the different kinds of information a remote challenger needs when he does a remote attestation. More work and explanation is probably needed in this area. Secondly, and more importantly, this proposal only works with applications written in Java and similar languages - as the language-based trusted virtual machine needs the high-level information that is included in Java bytecode.

(emphasis mine)

To address the first point: I think right now there is no general consensus on what kinds of information a remote challenger needs. There are some probable scenarios though: DRM comes to mind (and not just for corporate interests, for regular people too), as well as high-level application-specific properties that vary from application to application and are hard to generalize. In the case of file-sharing applications, one might want to enforce polices of the form “share file X only within group G”. Currently, we simply trust a client to respect such policies, with no way to either enforce or check them ourselves. For example, it turned out that a popular BitTorrent client was not properly respecting the “private” flag on torrents. Another related property is that of controlling information flow within a program. This comes up whenever a program manipulates sensitive information (financial records, confidential documents) on our behalf. We are currently working on ways to enhance the JVM with dynamic information-flow control capabilities, with the final goal of being able to remotely attest such properties.

Ultimately, semantic remote attestation itself is a policy-agnostic technique (as it should be!) and, in my view, has the capability to remotely attest a broad variety of high-level policies.

Now, the second point — this indeed is the more important, and more interesting question. Imagine that what we call the TrustedVM isn’t the JVM, but something lower on the software stack. Say, the operating system. Or even lower — the x86 instruction set. As we go lower in the abstraction tower, our “funnel” gets wider — we’re able to capture the behavior of more and more software. At the hardware instruction set level we can capture the behavior of the entire system (indeed, projects such as ReVirt have done this). There is a tradeoff though: lower levels of abstraction have lesser high-level information, and consequently, it is hard to make high-level policy decisions at a low level. For example, the OS is not aware of application-level policies such as “the reply to such-and-such network request must be of such-and-such form and possess such-and-such properties”. And don’t even think about doing such things at the ISA level.

So where does that leave us? We’re stuck with the age-old dilemma of choosing a sweet-spot along a tradeoff curve. Where is that sweet-spot? I honestly don’t know. But with more software being targeted to managed runtimes, my bet would be that the sweet-spot is at the level of the language runtime. And in the meanwhile, it would really interesting to see how the ideas of semantic remote attestation can be applied at the level of the operating system by (the age-old) technique of syscall interception.

Stefan Bechtold looks at Trusted Computing from a policy perspective.

Mention the word (or acronym) DRM and some synonyms immediately come to mind: draconian, Big Brother, evil. Or so the mainstream press and many other people would have us think. It seems as if DRM, and its vehicle, Trusted Computing, is just a plot for big media and big computing corporations to enslave us all, and make us pay for every pixel and microsecond of content, and in general, own our souls and condemn our progeny to bonded labor.

This story is the perfect example of how DRM is not just for the Disneys and Sonys of the world, but for regular people too. In short, BitComet is a bittorrent client that does not respect the “private” flag in torrent files (under certain conditions). This is useful for closed or private communities that want to share torrents only within the community. BitComet allows sharing of private torrents.

DRM is for regular people too. I want a way to share large files (pictures, videos) with only select people. I want a way to ensure that the programs which I use to do that will actually respect my rules, i.e., my digital rights. I want a way to ensure that marking content “private” is not just an informational attribute that can be overridden by a buggy or malicious program, but that the rule is actually enforced, and moreover, I know that it is being enforced.

Much of what is written about DRM is driven by fear and paranoia. If DRM can help the MPAA protect their content, it can help me protect mine too. Imagine how much easier it would be to share content online for individuals if DRM actually worked. While we’re cooking up doomsday scenarios where the MPAA owns my machine, why don’t we also think about some interesting ways in which individuals can make use of DRM?

Let’s see some ID, please. Trusted Computing in the mainstream press.

Lucky Green’s DEFCON X talk on Trusted Computing. (site seems to be down..?)

Ross Anderon’s Trusted Computing FAQ.

Interesting blog that covers technical aspects of Trusted Computing.

Trusted Computing Group Home