TIW 2010: CyLab's Bryan Parno on Bootstrapping Trust 101
By Richard Power
CyLab’s Bryan Parno spoke on Bootstrapping Trust 101, from a paper written with Adrian Perrig and Jon McCune.
In our increasingly mobile and global computing environment, Parno explained, bootstrapping trust is both necessary and difficult; Parno also identified three challenges in endeavoring to bootstrap trust: hardware assurance, ephemeral software and user interaction.
“Hardware is durable, but can we do better?” “We care about the software currently in control.
Many properties matter. But which property matters most?”
Human factors include: “How can the user trust the device? How should attestation be communicated to the user? What does a user do with failed attestation?”
To illustrate some of the issues involved in bootstrapping trust, Parno suggested a “simple thought experiment.”
“Let’s imagine that tomorrow, one of you develops the perfect algorithm for determining control flow. So any program, you could output yes or no whether or not this program reflects its control flow, or ever deviates from what you intended it to do. And the question is, ‘Is that enough to bootstrap trust?’ Can we use that magic program to decide if we want to trust a particular computer? I would argue that the answer is “No,” because all that does is takes the entire space of programs divides them into a smaller subset, and this smaller subset is of those programs who respect the control flow. And so all we learn from the algorithm is that the program we are about to give our information to falls somewhere within the subset. The problem is that there are good programs that respect the control flow, and there are some good programs that don’t respect the control flow (i.e., that are badly designed). There are also malicious programs that are badly designed, and but there are also some that are well designed. I have downloaded some malware examples that compile better than some open source products that are available. Just the fact that it is designed well does not tell us what it is intended to do …
So what you actually care about is the identity of the particular piece of code that you are running, not one of these higher level properties, like type safety or control flow. Those properties are nice, but what you really care about is which particular program you are running.
What do we mean by ‘code identity’? Some high level attempt to capture this particular program, and differentiate it from all other possible programs. State of the art trust combines a number of factors: the binary you are actually going to run, maybe libraries that it loads … and then we also care about any configuration files or inputs it was given when it first started, because that two can influence its behavior … all this information is condensed down into a hash, so you take something like SHA-1 and run it over all of this information, and you end up with one nice value that you can use to represent this particular program.
How can we use code identity as a trust foundation? Well, given that you know what program is going to run, because you have been given its binaries and its inputs, you may be able to compute some of these additional properties. So you can run that magic algorithm and decide if control flow is respected, you can run a type checker and decide is this type safe. And so, just knowing code identity, you can infer all of these other properties, where as I argued earlier, you can’t go the other way.
What can this do for you, at a high level? Well, there have been a number of applications … from a research perspective, there have been techniques to secure the boot process of your computer, so as your computer boots up you can check the identity of piece of code and make sure that it is the correct one, so you will never use unintended code, there is also work concerning trusted third parties; a lot of protocols require the trust of third parties so that two individuals can exchange secrets and other information, and with the ability to know what code is running, you can have sort of a stronger notion of trust, rather than trusting, let’s say Verisign or Microsoft, you check the code and say, ‘OK, this is the code they are supposed to be running, we can trust them to perform whatever task …”
Parno went on to explore how to establish code identity, how to use it as a basis for secure booting, how to record code identity, and how to attest and interpret. He also examined load-time versus run-time properties, and other issues.
In conclusion, Parno asserted that code identity is critical to bootstrapping trust, that there are assorted roots of trust available, and that many open questions remain.
