Arguendo
In our TCPA meeting yesterday, I had an idea. It's clear that trusted computing systems could be used in ways which unambiguously provide security benefits to end-users and act in the end-users' interests. Is it possible that these systems could be designed only to do this and specfically not to be useful for any other purpose?
Design constraints like this are always interesting; sometimes they're accomplished in very practical ways. I think of the denaturation of alcohol -- in order to guarantee that some alcohol will be used only for non-intoxicating purposes, it can be mixed with a low concentration of a much more dangerous poison, or something which tastes downright awful. That kind of poisoning or contamination will protect essentially all non-food uses of the alcohol, but prevent uses in foods and beverages.
How could you "denature" a trusted computing system so that it would be useful for purposes which benefit the computer's owner but not, in general, for any other purposes? If this could be done, how would that possibility change the way we think about trusted computing systems?
So here is a thought experiment: add to the requirements for a trusted computing system a rule that there should be a physical button or keypad attached to the device, as well as an interface for removable recordable media of some sort. When the physical button is activated or a particular passphrase is entered on the keypad, the device must sequentially write the entire contents of its memory, without regard for trusted computing domain separation or access control rules, rules, into a file on the removable media. (You need to define "the entire contents of its memory" carefully to guarantee that memory physical located, e.g., within a CPU will be included if it's directly addressable by software.) The media can then be removed and read inside another computer.
I'm going to call this feature an Owner Override function, because it allows the owner of the computer to override certain policies the owner might consider disadvantageous (such as not allowing the owner to read some data which was saved using sealed storage). In the alternative, you can implement this in a technically different way and call it something like "owner-directed migration", a direct attack on Pd "migration disposition" in which a creator of a file or an application might have defined certain rules about migration.
We know that the basic technology for assuring that a function like this is never triggered from software is already implemented; it's a design requirement of TCPA and Palladium, ordinarily referred to as "physical presence indication". The system is required to be engineered in such a way that it can reliably determine whether you are there in front of it or not. (In particular, it needs to be able to reliably determine that a particular instruction was generated from hardware by a physical action, and not from software. This is meant to guarantee that malicious code can't impersonate an end-user in order to trick the system into undermining certain kinds of privacy or security protections.)
On reflection, I don't see anything in the physical presence indication concept which prevents it from being extended to include a broad mechanism for overriding policies. Already, there are things you can do with physical presence in these trusted computing system which you simply can't do otherwise; why is "override security" not one of them? (It is, de facto, in all existing PC hardware! What's more, I don't believe that any parts of ordinary PC hardware before 1995 were specifically designed to prevent users from altering any part of user-visible functionality. Maybe someone can find an interesting counterexample, because it seems very possible that there is one. Incidentally, the feature I'm proposing as an Owner Override is not really very different technically from existing suspend-to-disk functionality provided in many laptops.)
The point of this exercise is not to suggest that TCPA actually ought to require this (although I am sure that would be a straightforward way of dealing with many consumer advocates' concerns!). The point is to try to show that, as a technological matter, the functionality which unambiguously protects an end-user can be separated from the functionality which ambiguously protects the end-user or has some potential to undermine or compromise the end-user's interests.
And the fact that physical presence indication is already designed in means that perhaps the biggest part of the required infrastructure is already in place. The machine already has a way to distinguish requests made by its user from requests made by software. That distinction could enables features, like Owner Override, which work outside of the default trusted computing security models in which policies are defined by software authors.
The next step with regard to this idea is to ask what would happen if it were implemented. I argue:
- There are certain benefits which result from trusted computing systems and there are also certain disadvantages.
- There is a certain pattern of allocation or distribution of the benefits and disadvantages to various parties.
- In particular, many people are beginning to become concerned because they perceive that there is a substantial risk that the benefits will mostly accrue to powerful organizations with large amounts of bargaining power and that the disadvantages will mostly fall to individuals and less-powerful organizations with small amounts of bargaining power -- that is, that trusted computing infrastructure can magnify, reiterate, or reinforce existing disparities of power. (For example, a monopolist can in principle use it effectively to reinforce a monopoly, whereas a rival of the monopolist probably can't use it effectively to attack the monopoly.)
- There is a small technological change -- some form of Owner Override -- which would eliminate some of the benefits and some of the disadvantages, but appears to ensure that those benefits which remained would accrue exclusively to end users.
We already know a practical reason why this wouldn't be done: because the first customers trusted computing vendors anticipate are corporate IT departments, who explicitly want to limit end-users' control over computers, and are always saying so and spending millions of dollars on products which purport to let them do so. Although there is much debate about the ethics of workplace control, many people consider the IT departments' exercise of control justified by default because the end-users are not the owners of the computers.
However, when the end-users are the owners of the computers, there is a high likelihood that their view of what the technology should or shouldn't do is not identical to the view of corporate IT departments. End-users would not necessarily see a system capable of being used to restrict end-users' control as in their interest, even though it is entirely true that the system need not necessarily be used that way and that there is a bargaining problem whose outcome would determine whether or to what extent it is used that way. (I wrote earlier about many precedents which suggest that there are certain capabilities you don't want to be given, because they can ultimately turn out to be a curse rather than a blessing. I think my favorite of these was "knowing how to build St. Basil's Cathedral").
I think the point bears repeating: the functions corporate IT managers want (including controlling end-users) are not necessarily the functions end-users would choose for themselves. That may mean that a technology developed for one part of the computing world will be an odd match for a different part. End-users are obviously much more likely to choose machines with an Owner Override, where corporate IT managers are obviously much more likely to choose machines without it.
Let's assume that there were a choice -- that there were fairly robust competition among several different trusted computing proposals, perhaps, and some of them included an Owner Override and others didn't. How can end-users think about whether having an Owner Override (a well-documented Owner Override, built into the published specifications for the trusted computing technologies themselves) would be a good thing for them, relative to not having it?
-
In the personal-security and network-security application context, you
say:
- My personal security can be protected equally well if there is a documented physical backdoor, with appropriate safeguards, which will let me effectively override policies which in my considered opinion I do not want my computer to enforce.
- I would argue that the way I have described this, an organization like a bank would not have, as a result of the Owner Override, a significantly diminished incentive to trust you or your computer (although there are some edge cases in which they might discover such an incentive).
-
In the DRM context, you say:
- Do I believe that the benefits to me of being able to do DRM are worth the disadvantages to me of having other people use DRM to control me? Consider that there are market power disparities.
-
There are other applications like games and distributed computing;
in that context, you say:
- Do I believe that the benefits to me of being able to prevent cheating in games, and being able to participate in reliable distributed computing projects, and share other resources in a fair or fairly-compensated way, are worth the disadvantages to me of having other people use DRM to control me?
