I just come back from ETISS08, the 3rd European Trusted Infrastructure Summer School at Oxford. The event was really well organised with a number of high-level speakers, including David Grawrock, Graeme Proudler (HP Labs), Paul Congdon (HP ProCurve CTO), Robert Thibadeau (Seagate Chief Technologist), Paul England (Microsoft) and many others.

For those who don’t know what Trusted Computing is, have a look at the wikipedia page, insight from Bruce Schneier or pure hatred from RMS. The idea is to use a hardware component called the Trusted Platform Module as a secure cryptographic device to secure the boot process of your computer and ensure the integrity of “important components”.

Here are some key concepts and concerns about Trusted Computing and my totally biased opinion about them:

Tamper Resistance: It is quite common to hear that the TPM is a tamper resistant hardware module (that’s what security hardware is for, right ?). Finally the story is quite different, the Trusted Computing Group doesn’t care much about hardware attacks. Mainly because tamper resistance = $$$.

Secure boot: this is one of the core features of TC, it allows you to boot securely by measuring (the rest of the world calls that hashing) each component before executing it and storing the hash securely in the TPM. BitLocker already uses that feature, and if your boot sequence has changed, BitLocker won’t be able to automatically extract the encryption key of your hard disk. This is a nice feature, however notice that we can only “lock” the boot process by checking if “something” has changed.

Attestation: the other Big Thing about TC. Remember that hashes about your boot process, operating system and other are stored in the TPM ? Now the idea of attestation is that some remote party would like to ensure that you are using a trusted OS or piece of software (notice the use of “trusted” and not “secure”). Well, TC can do that for you ! Your TPM contains a secret key called the Endorsement Key which can be used to sign the value of your Platform Configuration Register (i.e. the hash of your system configuration) and send that over the network. The remote party can check that the hash has been signed by a valid EK and is a hash of a valid boot with a trusted OS and software. Now, if you don’t see the obvious implementation problems, think again. Basically, there are so many valid systems, configurations and software that the number of hashes is unmanageable (plus they change each time you apply patches and they depend on the order in which you hash things). And you can just attest remotely that the software was OK when it was launched, not that it hasn’t been exploited in the mean time (and as David Grawrock pointed, hashing a memory image of a running program is HARD).

Privacy: there have been concerns about having a secret key (the EK) in a hardware module, somewhat out of reach of the user, which might be used to aggregate personal information on remote services. Therefore the system has been carefully designed to use the EK in very limited circumstances and to use indirect signing for attestation using Attestation Identity Keys or zero-knowledge proofs such as Direct Anonymous Attestation. There was a consensus that your privacy is more at risk when you purchase something on the internet or have a Facebook account than when you use a TPM, and I think this is true.

Security: you might have noted that the keyword here is trusted, not secure. There have been a lot of philosophical debate at the summer school about what is to be trusted, what is trustworthy, and how all that relates to correctness and security. Overall TC is not a revolution for computer security, it’s more a way to bypass the question.

Open Source Software: a lot of concern about TC comes from the FOSS community, probably because the Trusted Computing Group is manned by large companies and you can somehow feel a big red hovering DRM behind it. However, most practical sessions were based on Linux and Xen and there is an opentc.net research initiative. Plus there was a really hot debate when Graeme Proudler asked “can you trust open source software ?”

Digital Rights Management: this is probably the most common concern about DRM. Why should I trust Trusted Computing if it’s just a tool to implement stronger DRM techniques ? It’s true that DRM is one of the possibilities of TC, but honestly I think than most actual DRM implementations will rely on attestation (to ensure you use a “trusted” mp3 player for example), so as long as attestation doesn’t work in practice, there can be no DRM based on it.

Loss of Control: the other big concern about TC is the idea to have a hardware chip containing some secret code and cryptographic keys that you can’t control (to some extent). Graeme and David insisted that the Platform Owner (TC terminology) remains in control of the TPM, by design. But I think there is still some loss of control due to remote attestation, and this is also by design. Because the whole point of remote attestation and the technologies based on it (such as Trusted Network Connect) is not to protect your computer from malware, but to protect your corporate network from you. Therefore if the remote party doesn’t want to attest your OS/software configuration, you’re out. In Ian Levy’s terminology, it is a way to mitigate the “wetware” risk. This is probably a good way to control your network infrastructure and corporate network, but doesn’t solve the porn surfing workstation problem. Remember, the monkey behind the keyboard really wants to see the dancing bunnies !

Oh and by the way, I also met the cool guy behind Joebox there ! If you have a suspicious executable file to analyse, Joebox is the right tool for you.

(updated: Sven Türpe has posted some nice photos of Oxford and his presentation about BitLocker on his blog)