Staff Technologist Seth Schoen, EFF's resident expert on trusted computing, recently attended this year's Windows Hardware Engineering Conference (WinHEC). This is the third 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 two posts can be found here and here.


In the near future, when you try to install software to time-shift your favorite Real Audio webcast, your PC might disable all media player applications. Until you remove the software, your PC will remain crippled. Or perhaps you want to watch a downloaded movie on a wide-screen TV, but your PC might turn off its video card's analog output.

Welcome to the world of Windows Longhorn (now known as Vista) and the Protected Media Path, where Microsoft, copyright holders, and DRM licensors may grant or revoke permission to use your own computer and digital media.

(Read on after the jump.)

According to announcements at 2005 Windows Hardware Engineering Conference (WinHEC), Microsoft's Windows Longhorn will go to great lengths to prevent users from tinkering with their own software environments. The proximate cause of the new restrictions is a scheme called Protected Media Path (PMP), which helps Longhorn make DRM for audio and video significantly stronger.

PMP has its roots in an earlier Microsoft initiative called Secure Audio Path (SAP). PMP works with video as well as audio, is more sophisticated than SAP, and calls for significantly further-reaching changes at the operating system level.

WinHEC participants described Microsoft's PMP work as largely motivated by an effort to induce the major US movie studios to authorize next-generation DVDs to be played on Windows. DRM engineers frequently referred to "next-generation content" and to the risk that the Windows PC platform would be cut off entirely from (lawful) access to it unless much of the industry meets Hollywood's demands. There's much to doubt in this story, but Microsoft and its business partners are playing along with it.

PMP includes several phases and features which Microsoft plans to introduce over time. One such feature is COPP, which allows applications to selectively disable the use of particular video cards or particular outputs on a video card. (For example, an application could refuse to output to a DVI output without HDCP encryption, or to an analog VGA output, or to a YPbPr component video output.) In the consumer electronics world, this functionality is known as "selectable output control"; it gives software and encrypted media increased power to intentionally break compatibility in obsolete already-purchased equipment. If video card manufacturers fail to implement selectable output control, their video cards will not receive Microsoft compatibility logo approval, cannot be used in Media Center Edition PCs, cannot be bundled with PCs whose manufacturers receive certain discounts and incentives from Microsoft, and may be intentionally unsupported by DRM applications running on Windows Lonhorn.

PMP will also eventually provide a means of requiring authentication of output devices and encryption of communication between software and an authenticated output device. (See our separate article on device authentication for more information.)

Finally, PMP will create a kernel-enforced construct called a Protected Environment (PE) in which particular software modules, including drivers and other code, that are trusted by particular entertainment companies can run and enforce DRM restrictions. The construction and protection of the PE requires the further-reaching changes to the way that software, especially drivers, is developed for the Windows platform; it also gives Microsoft a new kind of power over Windows software developers.

Components that are loaded into the PE by the Windows kernel must be signed and authenticated; software developers must also have produced them pursuant to a license with Microsoft, and their developers must have committed to follow certain policies that Microsoft promulgates. Publishers can associate policies with their published works indicating which components they trust, and the PE will enforce these policies.

Perhaps most significantly, the PE will be subject to a "global revocation list" maintained by Microsoft and distributed through Windows Update and possibly other channels. Microsoft will maintain and sign the revocation list, and its updates will have ever-increasing version numbers. Works meant to be played back through PMP can require a particular minimum revocation list version number; the PE will not allow a restricted work to be played at all unless the computer has loaded a revocation list at least as recent as the one specified by the work. If a software component appears on the revocation list, the PE will not load it, or will warn applications that a revoked software component has been loaded.

Drivers that run in kernel mode will fall into three categories. First, some drivers are meant to participate in the PE; these drivers must be signed and created subject to a license with Microsoft, and must follow certain policies and coding practices that Microsoft promulgates. Their code must be submitted to Microsoft for review, and Microsoft has the right to revoke them if it discovers a violation of its policies and standards. Under certain conditions, Microsoft can even fine licensees who write participating drivers that are subsequently revoked.

Second, some drivers are not meant to participate in the PE. Even though these drivers are unrelated to DRM functions or output functions, and even though Microsoft does not author them, Microsoft demands that the drivers' authors sign them, and Microsoft retains the ability to revoke these third-party drivers. For example, if Microsoft decides that a third-party mouse drive or third-party USB storage device driver does not meet its security standards (for example, if the driver ever allows user programs such as a debugger to gain kernel-level privilege), Microsoft can add the third-party driver to the revocation list. If Microsoft revokes such a driver, the PE cannot be established on a system where the driver is loaded. Thus, users who want to use applications that require the PE to be established have a powerful incentive to stop using the revoked driver version.

Finally, some authors do not sign their drivers (as in the status quo). Microsoft strongly disapproves of this practice, and all such unsigned drivers will be treated as revoked by default; that is, the PE cannot be established if such drivers are present.

The result of all of this is that all third-party developers of device drivers that need to run with kernel privilege on Windows will be need to obey Microsoft's policies about not implementing features that might undermine the PE. (This means that some existing drivers that intentionally give the authorized user privileged access to the system will be considered insecure.) If they do not obey these policies, they can be revoked and they will no longer be usable on systems where a user needs to establish the PE. Microsoft has not provided details of the user interface that will inform the user about revoked drivers or software components, but it's a safe bet that it will place the blame on the developers of the revoked software -- not on the Protected Media Path system, Microsoft, or the movie studios.

One important distinction between participating and non-participating drivers is that participating drivers (that are meant to run in the PE) can only be loaded if Microsoft has pre-approved them. By contrast, non-participating drivers (that are not meant to run in the PE but that nonetheless have kernel privilege) can be loaded, even in the presence of the PE, unless Microsoft has affirmatively revoked them. As we explain below, this means that -- in the PMP system as currently described -- people can develop and use signed drivers that violate the PMP's security policies, as long as those drivers never come to Microsoft's attention.

In Windows Longhorn, PMP will not use trusted computing hardware features to prevent reverse engineering; therefore, traditional software attacks will continue to be effective, although they may be more costly and annoying to implement than in the past because of increased efforts to support DRM at lower layers of the operating system, to make more extensive use of code signing, and to obfuscate binary code to slow down reverse engineering. Future versions of
Windows may begin to use trusted computing hardware to prevent reverse engineering and modification of the PMP code. This application of trusted computing is not in users' interests, but it may be difficult for users to co-ordinate resistance to it because of the large number of companies supporting it. (Microsoft has not announced whether it will use trusted computing as part of its Windows Product Activation scheme, but it might be possible to require the use of a TPM-enabled platform as part of the Windows activation process. If Microsoft does so, it would be difficult to opt out of the use of the TPM while continuing to use Windows; the product activation step could also be used to bootstrap the enforcement of other DRM policies.)

What will be the consequences of the implementation of PMP? It's instructive to compare PMP to the DRM system that is one of the reasons for its creation -- the AACS system, which will be included on next-generation DVDs as a replacement for today's CSS. Ed Felten recently
explained why AACS is likely to harm innovation and competition, without doing much to deter copyright infringement. AACS includes an elaborate scheme to allow copyright industries to revoke unauthorized playback software or equipment -- if it's distributed to the public. It can, however, be used in private:

If somebody, somewhere makes his own player using a reverse-engineered DeviceID, and doesn't release that player to the public, then he will be able to use it with impunity to play or rip discs. His DeviceID can only be blacklisted if the licensing authority learns what it is, and the authority can't do that without getting a copy of the player. Even if a player is released to the public, it will still make all existing discs rippable.

The PMP PE and its revocation list have precisely the same structural problem. They give Microsoft -- and the movie studios -- tremendous power over what kind of software can be run in the kernel of a Windows machine. For the first time, Microsoft can directly impose costs on users who use software that Microsoft dislikes by breaking those users' media players unless the users uninstall the disapproved software. Yet copyright infringement is still easy. The infringers just need to write and sign device drivers that break the PMP PE by deliberately violating Microsoft's policies. Then they need to refrain from publishing those drivers. (Even if Microsoft tries to scrutinize third-party drivers, it should be straightforward to introduce an intentional "bug" in a driver, claim it's an internal development version, and never release it to the public. This might be possible even in a world where Microsoft reviewed all Windows driver source code, a level of supervision far more intrusive than what Microsoft has announced at WinHEC.) The infringers can continue to attack DRM in private and publish decrypted copies of movies; even if their drivers are leaked and Microsoft revokes them, they will still work for decrypting movies published prior to the date of revocation. The analogy between the effects of AACS and the effects of PMP is thus fairly direct.

Like AACS, the implementation of PMP would limit what kind of media technology is generally available to the public. Like AACS, it would help restrict the feature set that published or generally-available products could implement. Like AACS, it will give more power to those who control the keys, and more leverage over unrelated areas of technology. And like AACS, it will not stop copyright infringement.