Trusted Computing Blog

What is the deal with Virtualization and Trusted Computing? Why is Intel so interested? In this entry I will discuss why those technologies could shape the future of computing.

To understand the why, first we need to understand the problem with the “killer” application of TC, which is attestation. Attestation basically “fingerprints” your computer, so other parties can verify the correctness of your current state.

Attestation

The main goal of attestation is to provide (securely) a snapshot of the current state to other parties.

When the computer boots up, in a computer TCG enabled, the first thing that will execute is the so called CRT (Core Root of Trust). This CRT will measure (hash using SHA1) the next software to be loaded (BIOS), as well as some configuration files related to the firmware. The BIOS, will then measure the next piece of software to be launched (bootloader, possibly) and execute it.

If the Bootloader has been TCG enabled (for example, Trusted Grub) then it will in turn measure the Operating System. In theory, the OS will have to continue with the chain of trust, measuring every piece of codes that executes, and main configuration files. Some examples on the reserch arena on how and what can we measure are BEAR and TCGLinux.

Once all this information is acquired, this information could be sent to challenging parties, as outlined by the Trusted Network Connect specifications.

The Problems with atttestation

The first, and probably biggest problem, is the Time of Execution vs. Time of Attestation. The attested unit will provide a snapshot of its state at the moment of attestation, but what happens next? The attacker can subvert the machine right after attestation. Works like BIND tries to address this problem

The second problem are the attestation metrics and the interface to collect the information. How can we measure a monster like Windows XP? How can we avoid from subverting the interface collectors themselves (drivers) by, for example, installing a Rootkit?

The proposed solution by Intel and Microsoft is to create a Secure Kernel, that will run in parallel with you commodity OS. This secure kernel will be minimalist, and difficult to change from the user perspective. The secure Kernel will be inaccessible by the commodity OS, but the reverse will not apply, hence the SK is granted unrestricted access to the commodity OS. This is not new

Xen and Nexus

Nexus was the solution proposed by Microsoft and its NGSCB, but that didn’t seem to quite catch up, at least, not yet. From their website

Our original approach was to create a new secure computing base that would run parallel to the regular Windows environment

Now the only care for what they call “A Secure Startup”, which is just an “Attested” startup. Is yet to be seen how they will deal with the mentioned problems. Why? They say

customers were concerned [they have to] rewrite all of their applications

Probably true, although the Nexus could have worked somehow transparently. But I believe Microsoft don’t really care about this. The main problem is that there is no money to make, and quite a bit to loose if the new implementation really breaks some applications.

But Intel is still working on the problem, as shown by their vigorous support for the open source virtual machine monitor named Xen. There is a good reason behind this: Intel has a big winning ticket at the end of the road. If this architecture catches up, Intel will gain power on interfacing issues, like drivers (and, of course, to “sign” and “authorize” peripherals). Note that Xen is not VMware, does not implement an “OS inside OS” (Actually, this is also been researched on Terra). Xen is a layer between OS and Hardware which could control multiple OS’s.

Currently Microsoft is a bully in matters like drivers and peripherals. But if Intel pushes Xen, and it ships on, say, servers first were virtualization has lots of applications, they could force some major changes on the business. The next step is to use security as a convincing reason to force virtualization to the rest of us, as outlined by Carlos Rozas at the Xen summit.

BIND was presented at the last IEEE security symposium by IBM research.

BIND tackles the problem of attestation, but instead of attesting a whole machine, they suggest to attest the executing process in memory. To avoid dealing with the inherent problem of insecure paths and insecure execution, the work assumes that the system has a Secure Kernel (SK), a secure processor (AMD’s SEM chip) and a location aware TPM (so the main kernel cannot override the PCR’s). With all that elements in place, the steps are:

• Have the insecure OS call the SK
• attest the process by extending a PCR register
• execute the process in the SEM
• send this attestation along with the output of the process

As a system researcher I believe that, even when you make some assumptions, you need to make at least an effort to implement your solution. Accessing the TPM alone, which sits in the LPC bus, takes usually a second. This will be prohibitive for many processes if we do this type of fine-grained attestation. But I guess we can throw yet one more assumption, that the TPM is faster than current implementation.

IBM research usually looks far ahead in the future. The amount of work to implement such a system is colossal (Virtual Machine, Secure Kernel, secure processor, TPM with added capabilities). But maybe that is were we headed? A brownie for the first open source implementation!

Trusted Computing is arriving slowly but with firm steps to all computers. Trusted Platform Modules (TPM) are now embedded in many computers, and is expected that by 2008 most systems will be shipped with a TCG complient TPM.

While TPM 1.1, the current version shipped with many computers, is nothing more than a smartcard sitting in the LPC bus, the next TPM version promises many more features. The uses of trusted computing are many, including remote attestation, secure storage, and, yes, DRM. Some more interesting uses can be found here