Trusted Computing: Promise and Risk

[Guest LilBambi]

Trusted Computing: Promise and Risk

Computer security is undeniably important, and as new vulnerabilities are discovered and exploited, the perceived need for new security solutions grows. "Trusted computing" initiatives propose to solve some of today's security problems through hardware changes to the personal computer. Changing hardware design isn't inherently suspicious, but the leading trusted computing proposals have a high cost: they provide security to users while giving third parties the power to enforce policies on users' computers against the users' wishes -- they let others pressure you to hand some control over your PC to someone else. This is a "feature" ready-made for abuse by software authors who want to anticompetitively choke off rival software.It needn't be this way: a straightforward change to the plans of trusted computing vendors could leave the security benefits intact while ensuring that a PC owner's will always trumps the wishes of those who've loaded software or data onto the PC.

Examples of abuses of remote attestationLet's consider a few concrete examples of how TCG's attestation approach can harm interoperability or be used against computer owners. 1. On the WebA web site could demand a software attestation from people wishing to read it. If they declined to provide an attestation, the site would refuse to deal with them at all; if the attestation showed that they were using "unapproved" software, the site would likewise decline to interact with them. Only those who could produce a digital certificate proving that their computers' software was satisfactory to the remote site would be permitted to use it. And this certificate could be produced -- in the current TCG scheme of things -- only if its contents were accurate.Today, there is no really reliable way to achieve this effect. Therefore, attempts to coerce users into using particular software are currently ineffective; web sites are hard-pressed to control what operating systems and applications their users can use. Reverse engineering allows the creation of competitive new software that works well with existing software and services, and therefore computer owners have real choice. It is effectively impossible to punish them for choosing to use software other than that favored by those they deal with. If they want to use a different web browser or a different operating system, they know that they are unlikely to be locked out by the services most important to them.For instance, some of today's on-line banking services claim to "require" Microsoft's browser, but users of other software are readily able to instruct their browsers to impersonate Internet Explorer. As far as the bank is concerned, its customers are accessing the site with the browser it demanded, but the users are not locked into technology decisions dictated by the shortsightedness of their financial institutions.In a widely publicized case, MSN, the Microsoft Network, briefly refused to serve web pages to non-Microsoft browsers. In the interim, users of competitive products were able to fool MSN into thinking they were running Microsoft browsers. This would be impossible in an environment of routine NGSCB-style remote attestations. By allowing a web site to lock out disfavored software this way, these attestations would let anyone with market power leverage that power to control our software choices.Security has nothing to do with many sites' motivations for preventing the use of disfavored software. Indeed, their reasons may be entirely arbitrary. In some cases, a site operator wants to force you to use a particular program in order to subject you to advertising. By verifying your use of an "approved" client, the site can satisfy itself that you have been forced to view a certain number of advertisements.2. Software interoperability and lock-inSoftware interoperability is also at risk. A developer of a web server program, file server program, e-mail server program, etc., could program it to demand attestations; the server could categorically refuse to deal with clients that had been produced by someone other than the server program's publisher. Or the publisher could insist on licensing fees from client developers, and make its server interoperate only with those who had paid the fee. (It is similarly possible to create proprietary encrypted file formats which can only be read by "approved" software, and for which the decryption keys must be obtained from a network server and are extremely difficult to recover by reverse engineering.)The publisher in this case could greatly increase the switching costs for its users to adopt a rival's software. If a user has a large amount of important data stored inside a proprietary system, and the system communicates only with client software written by the proprietary system's publisher, it may be extremely difficult for the user to migrate his or her data into a new software system. When the new system tries to communicate with the old system in order to extract the data, the old system may refuse to respond.The Samba file server is an important example of interoperable software created through reverse engineering. Samba developers studied the network protocol used by Microsoft Windows file servers and created an alternative implementation, which they then published as free/open source software. Samba can be deployed on a computer network in place of a Windows file server, and Windows client machines will communicate with it just as if it were a Windows server. (Similarly, Samba provides the means to allow non-Windows clients to access Windows file servers.) Without competitive software like Samba, users of Windows clients would be forced to use Windows servers, and vice versa. But if software could routinely identify the software at the other end of a network connection, a software developer could make programs demand attestations and then forbid any rival's software to connect or interoperate. If Microsoft chose to use NGSCB in this way, it could permanently lock Samba out of Windows file services, and prevent any useful competing implementations of the relevant protocols except by specific authorization.Similarly, instant messaging (IM) services have frequently tried to lock out their competitors' clients and, in some cases, free/open source IM clients. Today, these services are typically unsuccessful in creating more than a temporary disruption for users. An attestation mechanism would be a powerful tool for limiting competition and interoperability in IM services. Some client applications could be permanently prevented from connecting at all, even though they offer features end-users prefer.These are examples of a more general problem of "lock-in", often practiced as a deliberate business strategy in the software industry, to the detriment of business and home computer users alike. Unfortunately, the TCG design provides powerful new tools to enable lock-in. Attestation is responsible for this problem; sealed storage can exacerbate things by allowing the program that originally created a file to prevent any other program from reading it. Thus, both network protocols and file formats can be used to attack software interoperability.

More examples in the article.Their conclusion:

ConclusionWe recognize that hardware enhancements might be one way to improve computer security. But treating computer owners as adversaries is not progress in computer security. The interoperability, competition, owner control, and similar problems inherent in the TCG and NCSCB approach are serious enough that we recommend against adoption of these trusted computing technologies until these problems have been addressed. Fortunately, we believe these problems are not insurmountable, and we look forward to working with the industry to resolve them.