Press coverage of the event can be found here and here.

Further information on interop coverage can be found at the TCG site 

Press Release

Everybody knows about distributed projects like SETI@HOME, and perhaps you have also heard about the failed Lycos anti-spam screensaver. Criminals use botnets to create on-demand distributed DOS attacks. Could the same distributed computing paradigm be exploited by the government for military purposes?

Cyberwarfare has received increased attention lately. An article by James Mulvenon proposed the search for a cyberconflict agenda, and many argued on possible scenarios in the event of a cyberwar. Those issues are not solely based on futuristic settings: the news hyped recently the case of the “chinese cyberspies”, and how their actions threatened national security.

If we assume that computational power and bandwidth will be key factors in future conflicts, a valid question is whether the military will request for civilian help, a kind of (voluntary or obligatory) “military duty” for civilian computers. The cycles and bandwidth provided by civilians could be used for breaking cryptographic enemy keys using distributed computation, launching attacks against chosen strategic targets (enemy sites, etc) or automated web-crawling to gather intelligence or to hunt for specific enemy sites.

Of course, while activities like SETI@HOME doesn’t require a great level of confidence on the trustworthiness of the user, military activities do require a high level of trust in the machine. The machines need, as a minimum, to be correctly identified, and tested to be resistant to subversion. The information sent and received from the machine may be confidential, even by the machine owner. This was not possible under the current framework, but current research shows that Trusted Computing could provide this level of assurance.

The Terra project, for example, used virtual machines coupled with trusted computing to claim a high level of assurance on distributed applications, showing a “cheat-proof” quake as proof of concept. Research at IBM proposed a scheme (using a secure processor and memory) for fine grained attestation for sensitive applications. Adding confidentiality to those schemes using the internal keys of the TPM will not be difficult.

I am aware that the use of non-military computers by the government will raise lots of questions from the legal and policy standpoints. I am not an authority on the subject, but maybe Stefan could comment on the feasibility of such a scenario. In this article I only wnated to point out that TC technology allows the creation of such a botnet for the army.

Only hope you don’t get an email at work saying “The Secretary of the Army has asked me to express his deep regret that your laptop Fujitsu 8010d S/N 344455 was destroyed in action this morning on an heroic attack to the axis of evil’s central servers”

In the event you don’t happen to have the chip needed for trusted computing (Trusted Platform Module), or you are afraid of enabling it after reading the scare tales, you can still build software and test the different applications of trusted computing using Mario Strasser’s emulator. The emulator is in the form of a kernel module, and implements most of the functionalities described on the standard. If you don’t want a TPM any more, just rmmod the module.

If you already have the chip, the drivers are already on the Kernel since version 2.6.13. To my knowledge, Atmel and Infineon chips are supported. If you have older versions of the kernel, only Atmel chips are supported, but you can still download the drivers form here. I have succesfully used the driver on a Fujitsu E8010d laptop.

To access the chip from the application layer you need a software stack, called the Trusted Software Stack. IBM has already implemented the stack and libraries to create Trusted Computing compliant software for Linux. As defined by the standard, a software daemon (tcsd) is the single point used to access the drivers. The project is called Trousers, and it works well with the emulator (latest version on the subversion repository).

There is, however, not a stable project to implement the trust chain in the Linux OS and bootloader. Trusted Grub, TCGlinux (no sources readily available) and BEAR (no longer mantained) are some of these efforts, but none seems to provide a clear documentation on how to do that. While VISTA is supposed to provide support for the trust chain, I am unsure if the Linux community will follow suit and implement this capabilities on the mainstream Kernel. At least I know there is some efoort from the Gentoo distributions, with trusted gentoo

If you want to create your own TCG testbed (TPM, Drivers and TSS,), read my follow up article on putting it all together

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 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!

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