The EFF's report on trusted computing [LWN.net]

The Electronic Frontier Foundation has released, to a fair amount of fanfare, its report on trusted computing. The report's author (Seth Schoen) has concluded that, while trusted computing architectures offer a number of security benefits, there are also potential problems that need to be addressed.

The report mentions four different technologies that make up current trusted computing efforts:

Memory curtaining. Modern operating systems already go to considerable lengths to keep one process from being able to mess with another process's memory. Memory curtaining takes things further by improving memory isolation support in the hardware, so that even the kernel cannot modify one process's memory while working on behalf of another process.
Secure I/O is the creation of a data path from the keyboard (or other input devices) to the application, and from the application to the screen which cannot be seen or modified by other processes. It is an attempt to stop software keystroke loggers, screen readers, and other eavesdropping tools.
Sealed storage works by hiding encryption keys within the system hardware, so that encrypted data cannot be read anywhere else.
Remote attestion is a hardware-supported mechanism for ensuring that the software running on a system has not been modified. The technology allows the generation of certificates that can allow a remote application (a web server, say) to be sure of the software it is talking to.

The report acknowledges that all of these technologies can help to improve the security of computer systems. With a trusted computing architecture in place, a worm which is able to exploit a hole in one program will find its ability to do anything interesting on the system much reduced. The EFF does not have any real problem with most of the technologies discussed.

That is not true, however, for remote attestation:

TCG attestation conspicuously fails to distinguish between applications that protect computer owners against attack and applications that protect a computer against its owner. In effect, the computer's owner is sometimes treated as just another attacker or adversary who must be prevented from breaking in and altering the computer's software.

A few cases where the remote attestation feature could backfire on users are mentioned. One is web servers which refuse to talk to anything other than the One Chosen Browser. There are sites which do that now, but most modern browsers are capable of masquerading as something else, so these techniques are not effective. Remote attestion would change that. Other examples include software interoperability (i.e. eliminating Samba forevermore), forced upgrades, and forced use of digital rights management schemes.

As a solution, the EFF suggests an "owner override" feature. The owner of a system could, while physically present at the machine, force it to produce an attestation for software that the owner has modified or replaced, making it look like something else. This feature would solve the problem for suitably capable users. It is hard to imagine users developing a widespread ability to safely perform overrides, however.

The real conclusion to be taken from this report is that the owners and users of computers need to maintain control over their machines. When your own computer treats you like an attacker, it has ceased to be truly yours, and it becomes a tool for controlling your behavior. Free software users have understood this point for years, of course. We have built a system that allows us to stay in control. But we need to be careful that the hardware platforms of the future do not take that control away from us.

to post comments

The EFF's report on trusted computing

Posted Oct 9, 2003 10:46 UTC (Thu) by rwmj (subscriber, #5474) [Link] (9 responses)

Can someone explain how these things really work.

I mean, I may be naive, but how can a remote server tell what browser I'm using, if I have the power to send back any response to that server?

At a basic level, I could set up a proxy which would tunnel request/responses to a single machine running the real browser. That way, hundreds of alternative browsers could be used, requiring only one real browser. I can then go further than that and decode the browser <-> server interactions and simulate them. If the "genuine" browser contains some sort of private key, I can decompile it to recover the key.

Rich.

The EFF's report on trusted computing

Posted Oct 9, 2003 11:05 UTC (Thu) by alspnost (guest, #2763) [Link] (1 responses)

And if you decompile it to recover the key, you'll be locked away forever under the DMCA....

The EFF's report on trusted computing

Posted Oct 9, 2003 11:12 UTC (Thu) by rwmj (subscriber, #5474) [Link]

If I lived in the USA, perhaps.

Rich.

The EFF's report on trusted computing

Posted Oct 9, 2003 14:10 UTC (Thu) by zlynx (guest, #2285) [Link]

The way it works, very roughly:

1) The system powers up.
2) The BIOS decides it is in secure mode.
3) A sealed encryption chip on the motherboard is used to verify the bootloader and the chip probably verifies the BIOS itself before loading.
4) The bootloader uses the chip to verify the OS and load it.
5) The OS uses the chip to verify drivers and user applications.

Because the cryptographic secret key used for verifying and signing binaries and other data is stored in the sealed encryption chip on the motherboard, it cannot be faked. The secret key never leaves the chip. The chip is designed to resist attempts to recover the key: it might self-destruct if opened, for example.

The EFF's report on trusted computing

Posted Oct 9, 2003 14:14 UTC (Thu) by elanthis (guest, #6227) [Link] (5 responses)

(note: I'm not a cryptographer, and even if I was, this is a simplified explanation)

It would work very similar to SSL, I'd imagine. Server uses its public encryption key (built into the hardware, which doesn't allow you to extract private keys, only feed data thru the hardware engine to encrypt/decrypt it) and sends that to the client, which uses its software's key (signed with the hardware key) and sends that to the server, resulting in a secured connection (either using SSL or another similar protocol) that can not only uniquely identify the computer (servers can store inidividual's machines public keys for authorization purposes, or just a basic blacklist/whitelist) but also identify the software using the software's public key. If you use the software's public key without knowing the private key, your encrypted tunnel wouldn't work (data would be able to be encrypted/decrypted for it). The software's private key would be hidden away in the hardware, or protected using DRM methods, preventing you from "stealing" the key from the software.

This *could* all be used for security (keep out malicious clients or malicious servers), and the hidden-key-from-user is important for this (if users could steal/spoof the keys, then so could an attacker), but then it could also be used (as the article says) for lock-in purposes.

I also rather fear this technology since it could make security *worse*. As it is now, coders *have* to program securely, else their apps will be hacked. With this kind of technology, tho, I'd bet a *lot* more coders will just rely on the fact that only their "authorized" client will be connecting, and care a lot less about security. And then, as holes are always found, they will end up getting hacked. Sucky.

The EFF's report on trusted computing

Posted Oct 9, 2003 18:09 UTC (Thu) by proski (guest, #104) [Link] (4 responses)

I don't understand your proposal. Yes, it's possible to check that the user knows the key, but how do you check that the software that has the software key is running in pristine state? What prevents me from running the original software in an emulator as a backend to the software I want to use? What prevents me from modifying the hardware to change the code of the software I'm running, or even the way the code is interpreted?

If DRM is developed by people interested in hoarding their so called "intellectual property" rather than in security, then some hard hacks won't be a big problem because it's much cheaper to buy a DVD that to implement them. But if DRM is ever used for real security, e.g. for banking, it may not live up to its promise because it wasn't designed with the real security in mind.

The EFF's report on trusted computing

Posted Oct 9, 2003 19:17 UTC (Thu) by zlynx (guest, #2285) [Link] (2 responses)

An emulator may not be possible to write.

What if the security chip has more secret keys inside of it? It could have a per computer key (My PC, serial #blah), a per distributor key (Gateway), and a chip manufacturer key (IBM).

If your emulator can't return the correct response to prove it is a valid security chip, it can be rejected.

Now, I suppose some graduate student with time on his or her hands could use an electron microscope and a chemical bath to peel and scan a chip one layer at a time in order to extract the information, but it doesn't seem likely to me.

Now, without an emulator, the hardware controls what can be loaded and that is how it knows the software is pristine.

Look at Microsoft's XBox. That is using DRM. Mod chips are able to break it enough to fool the local system, but it cannot fool the XBox Live network because the mod chips cannot get real, valid security codes.

These things check the software is pristine, prevent writing emulators and prevent modifying the hardware.

The EFF's report on trusted computing

Posted Oct 10, 2003 1:39 UTC (Fri) by proski (guest, #104) [Link] (1 responses)

Leave the chip alone. I think it's safe to assume that a secure self-desctructing chip can be made for a reasonable price with the existing technology. What I mean is that it's possible to change the way how the authorized program interoperates with other hardware, including monitor, keyboard and network.

Suppose some company wants me to play their music online but not save it. The authorized software doesn't allow me to save music. But I can run rewire the system so that the decrypted audio signal goes not only to the sound card, but also to an additional device. This is possible for the analog signal, and it should be possible for the digital signal as well, unless the audio card also uses hard encryption and self-destructing technology.

Suppose some company wants me to use their browser with advertizing. I can write an emulator of the operating system (not of the authorized program) that would pass through all data to the chip and to the network, but not to the GUI. Then I could write a browser that would display the cache of the authorized browser, but without advertizing. If done right, there would be no way for the contents provider to catch me.

It's hard. That's why it wasn't done for X-Box. X-Box is not worth the trouble. But if a bank wants my computer to act an their behalf, they are better off reassessing the risks.

The EFF's report on trusted computing

Posted Oct 10, 2003 22:07 UTC (Fri) by zlynx (guest, #2285) [Link]

Maybe I'm missing something. Can you explain how you get the secure hardware to load your emulator?

The EFF's report on trusted computing

Posted Oct 10, 2003 21:46 UTC (Fri) by Ross (guest, #4065) [Link]

You would be sued for writing the emulator. To write a working one you would have to implement their cryptographic techinques including the secret keys. At it would not be at all easy to obtain the keys from the hardware. It certainly couldn't be done at a software level unless there was a bug in the implementation or you had a key to create an authorized operating system. Good luck.