I just saw a banner ad on slashdot that said "Switching from Windows to Linux can be prohibitively expensive" (presumably a quote from some research report or some IT manager's experience).
The subtext that wasn't included: "And we're eager to keep it that way!"
I just got the most recent issue of the FSF Bulletin in the mail. The Bulletin included an article about the progress toward GPL v3, which mentions again the trusted computing issue. There is only a passing reference to it:
To the extent that the movement has identified technological or legal measures likely to be harmful to freedom, such as ``trusted computing'' or a broadening of the scope of patent law, the GPL needs to address those issues from a perspective of political principle and the needs of the movement, not from primary regard for the industrial or commercial consequences.
This point is interesting and important in its own right, but I mention it here only because of the reference to trusted computing.
Let me try to clarify and elaborate on what I told FSF about this a while ago.
There are two obvious kinds of deleterious effects that TC can have on the free software movement. The first is that TC can be used to prevent users of free programs from accessing some kind of service at all, or from interoperating with some non-free program. The second is that TC can be used to prevent users who have the expressly-stated right to modify a free program from exercising that right, or to punish them if they do.
The first scenario arises in a few situations. One example would be a web site that demands that you access it only with Microsoft Internet Explorer, or a music store that demands that you access it only with iTunes, or a file server program that demands that you access it only with the client program that was written by the same company. Some of these examples are likely to involve DRM (trying to force you to use a client that enforces DRM rules), where others may not even have that excuse.
A TC platform strengthens the server's ability to control which client software can access it because the hardware on which the client is running can offer proof of the client's identity. The server can perform a key exchange with the client so that (absent a hardware attack on the TC platform) a session will be established with the session key shared only by the server and by an "authorized" client. This is hard to do without TC in the sense that if the "authorized" client knows something that it uses to authenticate itself, a reverse engineer can study the client and extract that information and then use it in the authentication process. The TCG design completely bypasses this: the client software does not need to contain any secrets to authenticate itself. Instead, the authentication is based on the entire system's boot history as observed by a trusted hardware component. The hardware component (the TPM) simply asserts that it saw a particular series of programs running on the system since boot time. (The use of "saw" here is an oversimplification; in fact, the TPM is dependent upon each program to allow it to "see" the next program in the chain.) If the server recognizes these programs, it can reason about whether they enforce security policies it approves of, including a policy of helping it identify which client program is over at the other end of the connection trying to communicate with it.
If the client is not one it recognizes, or the general software environment is not one it trusts, the server can simply refuse to communicate. Perhaps it can send an error message of some sort through the protocol to explain what's wrong.
The second scenario would arise most often today in an appliance like a TiVo. (TiVo, Inc., does not, as far as I know, use a TCG TPM as part of its hardware security in the most recent version of its product that it described to the FCC.) Suppose a manufacturer wants to use some free software in an appliance. If the software is licensed under a copyleft license, there will be some clause in the license like the GPL's "[y]ou must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program [...] to be licensed as a whole at no charge to all third parties under the terms of this License". OK, so our hypothetical manufacturer probably can't claim that as a matter of copyright law end users are forbidden to modify the software in the device. (If the manufacturer did claim this, then the original authors of the program, or other contributors, could say that the manufacturer had failed to "cause [the] work [...] to be licensed [...] to all third parties" and thus did not comply with the GPL's conditions on copying, and thus lacked valid permission to copy the program and was itself a copyright infringer.)
But just because end users have a copyright permission to exercise GPL-protected freedoms does not mean that they will have the technical means of doing so. The manufacturer can use technical means to make it hard for the user to modify the software in the device. With the exception of some enlightened manufacturers like Slim Devices (about whom more later), almost all manufacturers now use some kind of technical means to deter modification. This is in principle independent of how the software inside their devices is licensed. There is today no clear conceptual reason why the copyright licensing terms of embedded software have anything to do one way or the other with what technical means the manufacturer uses to make it easy or hard for end users to change the software.
And singling out trusted computing (in the narrow sense of the TCG TPM) here is probably a red herring. Manufacturers are able to use a wide variety of technologies, often custom technologies -- what we might call "bespoke trusted computing" -- to restrict or punish end-user modification. A TCG TPM may be too expensive, too complex, or a sort of overkill for this application. A TPM platform could certainly be used this way. One approach is to encrypt some of the software in the device, and require the device to be "activated" periodically by downloading the decryption key from the manufacturer. The activation process could involve the use of a TPM attestation to verify that the software requesting the decryption key was unmodified from the factory version.
Similarly, if an appliance (like a TiVo) uses some kind of data feed or on-line service provided by its manufacturer (like the TiVo guide data that reveals when particular programs are on TV), the appliance could contain a TPM and the manufacturer's server could ask client appliances to use the TPM to prove that their software is unmodified before receiving access to the service.
I do believe that bespoke solutions are much more common in the industry right now. All sorts of manufacturers have implemented hardware techniques to try to stop their customers from modifying embedded software, and virtually none of them are using TPMs for this. We can characterize what all of them are doing in the broadest sense as "trusted computing" -- they are trying to ensure that they can trust that the devices are implementing their policies as opposed to some other policies. But the similarities probably end there, because they are not necessarily using the same implementation techniques or any of the same technologies. One manufacturer's cell phone may do an attestation in a totally different way from another manufacturer's cell phone; one PVR may use a certain technique and another PVR may use a different one; one game console may check cryptographic signatures on operating system images and another may rely only on hardware tamper resistance.
The result of all this is that, TPM or no TPM, manufacturers have techniques for restricting changes to the embedded software configurations on their devices. And, TPM or no TPM, these techniques are usually defeasible by a dedicated reverse engineer. The reverse engineer faces three obvious problems: the reverse engineering process may be expensive, it may be difficult to share with other users, and it may be described as illegal in some jurisdictions. (In a way, all of these problems start to blur together -- a shame. "Tinkerers as thieves.")
Let's take stock of the situation. In the first place, we have proprietary software running on the PC platform and the ability to detect when it has been replaced by other software, in order to refuse to interoperate. In the second, we have proprietary devices that use a variety of techniques to prevent modification of their software, even though users might have an express authorization from the author of some of that software to modify it.
There is an interesting hybrid concern that I think was first expressed by Ross Anderson, which is that free software publishers can use TC to create proprietary software-like switching costs, lock-in, etc., by means of some kind of certification process. That is, they can have a certain "blessed" free software configuration (or distribution) with a cryptographic signature. Whoever changes it in any important way will void the validity of the signature. Perhaps the signature is important somehow for interoperability -- whether with DRM systems or on-line services or something else that clever business people will think up. (Importantly, I'm not sure there is any consensus on how far this has to go before it will be seen as a bad thing. The mere certification of a free software configuration as secure, reliable, etc., is something that the free software movement has generally supported. We have never seen a situation where the presence or absence of a particular certification has real technical consequences in terms of interoperability, and I don't think we've thought about it very much.)
The previous paragraph hints at an odd possibility: pure free software DRM implementations. Above, I noted that programs do not need to contain any secrets (as shipped) in order for their identity to be proven on a TPM platform. This literally does mean that a server can sometimes tell whether a free software program on a TPM platform will enforce DRM policies or not. (However, if the user makes any changes at all, the server can no longer tell. There is a remarkably severe penalty on those who modify their software. Proof-Carrying Code provides a possible way around this, if users are willing to accept the burden of constructing a proof that their changes don't undermine the verifier's security policy, and if the verifier is willing to accept the corresponding burden of verifying that proof.)
OK, so what can GPL v3 do to influence all of this?
One issue that I've talked about with FSF is the notion of "equivalent access to modify" software embedded in a device. The GPL v2 already contains an elegant definition of source code as "the preferred form of [a] work for making modifications to it". There could be an analogous definition of access to modify software -- along the lines of "the preferred means of access to a device for making modification to the software it contains". (That is, if you're an embedded device manufacturer and you include GPL v3-covered software in your device, and you have a technical means of modifying the software after the device is complete, you must give recipients of the device the same technical means.) However, this seems to become very muddy very quickly. I think it's possible (and valuable) to think of counterexamples where this seems to be difficult or impossible, or where this access becomes merged with other kinds of access that manufacturers might be reluctant to grant for entirely other reasons.
Another idea is that some GPL-covered software that is involved in the process of making TPM attestations could be designed not to co-operate with the attestation process, and then the GPL could forbid people to modify the software to co-operate. This is based on the idea that attestation is bad because it can be used to break interoperability or to punish people for modifying their software. (A more extreme interpretation might be that the GPL could allow authors of software to forbid downstream programmers from adding code that has the effect of invoking TPM extend or quote functions. Or a program could always do a TPM extend with random numbers, sort of the equivalent of scribbling in the TPM's memory, and downstream programmers could be forbidden to remove the code that has this effect.)
One problem with this is that, if it were adopted, it would also prevent use of the TPM for non-attestation applications such as secure key storage. There are already various people (especially at IBM) writing extremely useful free software TPM support that should allow you to use the TPM to do things like protect your GPG and SSH keys from certain kinds of software attacks. (They are still under your control in the sense that you can back them up and export them; you just enforce a policy that will forbid other programs from accessing them at run-time. This could make it a lot safer to have your GPG key on a network-connected machine.) It is particularly unfortunate that the TPM supports both extremely beneficial and extremely harmful applications in the same piece of hardware and even using the same code-identity concepts. It often reminds me of Eric Hoffer's claim that
Good and evil grow up together and are bound in an equilibrium that cannot be sundered. The most we can do is try to tilt the equilibrium toward the good.
Indeed, some trusted computing advocates have used this reasoning as an argument against proposals such as a boycott of TPM platforms (or as an argument against my Owner Override proposal). The reasons why the attestation applications that the free software movement disapproves of can or "cannot be sundered" from other trusted computing applications are an interesting debate that is beyond the scope of this article.
Another difficulty for the proposal just mentioned is that a lot of authors of free software do not see TPM support as a bad thing and thus will not go along -- and others see it as such a good thing that they will be willing to fork earlier versions in order to preserve their ability to implement TPM support. The number of programs that have a real ability to block or damage TPM support is probably relatively small; it excludes pretty much all user-space software, depending on the TPM software implementation model. It probably includes things like boot loaders and kernels, and an extremely small proportion of other related software. (Interestingly, on the PC, it currently includes portions of the BIOS, because of the way PC hardware manufacturers have implemented the trusted computing "core root of trust for measurement" concept. This is closely related to a fight that FSF is having for free BIOSes. Recently some trusted computing advocates argued to me that we really don't want to have entirely user-modifiable BIOS because of catastrophically bad next-generation boot sector viruses. I wish this sort of debate would occur in public.)
Most software just does not have the ability to participate in or interfere with TPM support, and, even if they had GPL v3 language specifically protecting their position, free software developers who disapprove of TPM support probably do not have any ability to stop other free software developers from implementing it.
Perhaps more significantly, nothing in GPL v3 or in the Linux kernel or in GRUB or LILO or any other free so
Contact: Seth David Schoen
