Staff Technologist Seth Schoen, EFF's resident expert on trusted computing, recently attended this year's Windows Hardware Engineering Conference (WinHEC). This is the second of a four-part series in which Schoen provides detailed updates on the status of Microsoft's security and lockware strategies for Windows. The outcome of these strategies will affect to what degree people using the platform and "trusted" PCs can maintain a desirable level of control over their own computers. The first post in the series can be found here.

*****

It has been difficult for most software that communicates with peripherals on the PC platform to answer two questions confidently:

(1) Am I talking to the particular make and model of peripheral I think I am?

(2) Am I talking to genuine physical hardware, rather than software that mimics its functionality?

(There are also other related questions that are somewhat more obscure; for example, "If I am talking to genuine physical hardware, is it physically installed in this computer as opposed to someone else's computer?")

Hardware vendors are now architecting systems that can answer these questions accurately. In so doing, they endanger the benefits PC users have long enjoyed due to weaknesses in device authentication.

(Read on after the jump.)

Ever since the ISA Plug-n-Play specification (and from the creation of the PCI bus), devices have had a means of identifying themselves. For example, a PCI video card will answer a request to identify itself by stating its device class (likely 0300, "VGA compatible controller"), manufacturer ID, and device model ID. There has not, however, been any sort of technical guarantee about the accuracy of such information. A manufacturer could create devices that claim to be other sorts of devices, and the only adverse consequence would be a greater likelihood of driver incompatibility.

"Device authentication" refers to techniques for giving software authentic information about what sort of hardware it is communicating with, and, in some cases, to giving hardware peripherals authentic information about the software that is communicating with them. The PCI ID system just discussed can be seen as a form of device authentication, but one without any sort of cryptographic basis. Stronger device authentication using cryptography has always been conceptually possible but has rarely been practiced on the PC (partly because of a traditional separation between hardware and software developers, partly because of implementation costs, and partly because of a lack of motivation prior to the emergence of the current DRM craze). One could argue that cryptographic smartcards are a species of device authentication because they can contain secret information that is difficult to copy and that can be used to prove that a device is present. However, very few PC users today use any sort of smartcard with their PCs.

The weakness of current device authentication techniques offers several significant benefits to PC users:

(1) Competition.

In principle, the indistinguishability of devices is a good thing for competition because it prevents tying between driver software and hardware. For example, a competitor could make a new device that mimics the interface of an existing device all the way down to identifying itself the same way. (This might be important if some existing software expected to talk only to a single device model, for example.)

In practice, the complexity of device drivers has usually made such tying possible even without formal device authentication mechanisms. (One could also say that the complexity of device drivers has served as a de facto device authentication mechanism.) Also, manufacturers who specifically want, for business reasons, to tie hardware and software together -- like Apple's iPod and iTunes -- have been creative in creating their own proprietary device authentication techniques.

Today, stronger protection for competition comes from the fact that many hardware manufacturers voluntarily implement the same interface standards, which makes rival devices relatively if not always completely substitutable for one another.

(2) Emulation/virtualization.

The indistinguishability of devices makes it easier to guarantee that existing software will continue to work under emulators and virtualizers like VMWare, Bochs, VirtualPC, and others. These emulators allow users to run software within a virtual machine, providing security and compatibility benefits. Software that was originally written for a particular machine can typically run without modification on an emulated version of that machine.

One key to making this work is emulating the machine's hardware -- that is, producing software constructs that look to software under emulation like real hardware. Emulator developers will code up software equivalents of hard drives, video cards, sound cards, keyboards, and more. Programs running within the emulator may not be able to tell the difference, and, indeed, in the ideal emulator could never tell the difference. That inability to distinguish physical from emulated hardware is vital to getting recalcitrant software to run under emulation.

(3) Virtualized hardware for redirection and recording.

Today, many software applications mimic hardware by redirecting application requests at some layer of an operating system. As just discussed, all emulators must do this in order to allow emulated software to communicate with the outside world. Mimicry is also useful for other purposes, including remote display and remote desktop applications. For instance, software that was written to display something on a locally attached monitor and to take input from a locally attached keyboard and mouse can be induced to interact instead with the same hardware on a machine hundreds or thousands of miles away.

Applications that mimic sound cards use many of the same redirection techniques to allow audio streams to be recorded as they are played. Programs like Total Recorder allow the computer user to make a copy of whatever audio is sent to the sound card, which is helpful when programs produce audio output but lack a built-in recording function.

(4) Privacy.

If software can identify hardware well enough to read serial numbers or other unique IDs, it can use these to identify the user of the computer and to transmit this information over the Internet. Although this is a perennial privacy concern about the PC platform, it is heightened as software gets more and more reliable and detailed information about its hardware environment.

Major hardware vendors are now taking giant steps toward several sorts of device authentication. These steps ultimately threaten each of the PC users' interests just described. Why would hardware vendors do this?

One major source of motivation for device authentication is Microsoft's Protected Media Path (PMP) project, a successor to the Secure Audio Path (SAP). PMP is motivated by entertainment companies' DRM ambitions and is being developed in consultation with them. Although parts of PMP are purely software-implemented and can work without hardware modification, Microsoft's complete PMP vision includes the ability to distinguish physical from virtual peripherals and to distinguish one peripheral make and model from another. Devices that lack authentication capabilities may not work with future software that uses PMP's device authentication features. Since PMP is expected to be used by authorized players for next-generation DVD discs, any manufacturer who doesn't play along risks forfeiting the Windows home theater market entirely.

Device authentication efforts are proceeding on several fronts and, for the most part, are not yet complete. The Trusted Computing Group's working group on peripherals, the PCI Forum, and Microsoft are all working on initiatives in this area, and standards documents for device authentication interfaces are likely to be published this year or next.

Device authentication is explicitly intended to break virtual soundcards and is projected to break emulators, or require the emulator developers to collaborate more closely with the developers of the hardware they emulate. Applications whose developers don't want them to work under emulation will obtain new weapons in their technology arsenal for detecting emulation.

What about the effect on privacy? The relationship between unique IDs in hardware, cryptographic protection of hardware interfaces, and privacy is complex. Privacy advocates observe that if there is something unique about your PC, software might be able to observe it and then reveal it over a network, providing the equivalent of a cookie that never expires, that can't be deleted, and that could potentially be shared across multiple sites or services. Making PCs truly indistinguishable from one another would mitigate this concern; so would preventing software from being able to access these sources of "uniqueness."

Technology developers often respond that there is no new privacy threat in adding a unique ID to any one hardware component, because PCs have contained many different unique IDs for years. For instance, a computer's Ethernet card and hard drive already contain serial numbers that are visible to software (and clever programmers can find numerous other things that could serve as unique IDs).

On the other hand, these existing approaches are not backed up with cryptography. It's difficult for software to tell whether the unique identifiers it observes in hardware are truly unique, or whether they might have been altered or tampered with. (For example, software running in an emulator might see the "hard drive" as having a serial number that's the same as the drive in every other copy of that emulator. Modern Ethernet cards have a means of altering their serial numbers from software, and other tricks abound for fooling software about its environment.) Once cryptographic device authentication enters the picture, however, software may acquire significantly stronger evidence about the hardware environment. It may become increasingly difficult to alter device serial numbers and to prevent software from learning -- and revealing -- which machine it's running on.

Ironically, the Trusted Computing Group spent a great deal of time addressing precisely this concern in connection with its Trusted Platform Module (TPM) chip. The TPM was carefully designed to prevent software from reading out its serial number and possibly using it as a cookie. Unfortunately, this privacy-protection effort may be for naught as other "authenticated" peripherals blithely give up their globally unique serial numbers to software -- in a cryptographically secured and trustworthy way.