Digital Rights Management on the PC fundamentally depends on software tamper resistance. Unlike cryptography, which has strong theoretical underpinnings and easily understood principles (e.g., "keep the key secure and the encrypted data is secure, too"), tamper resistance is more a matter of hiding in plain sight. It is an intellectual contest in which the defender succeeds by frustrating the adversary's attempts to understand the software, while still enabling the computer to run the software successfully and efficiently.

When PC DRM was being explored in the mid-nineties, designers came up with a wide variety of tamper resistance approaches. Often, however, they concluded that even though a particular approach might seem effective, only Microsoft would have the resources, scope, and platform control to make it practical. Now, ten years later, it seems that they were right.  Details are coming out about Microsoft's plans for DRM protection in the upcoming Windows Vista OS, which indeed contains a lot of tamper resistance mechanisms that could only have been done by Microsoft... and that might be effective.

A few concepts stand out amid the specifications:

• Protected Path: More specifically known as Protected Video Path (PVP) and Protected User Mode Audio (PUMA), these are mechanisms to support DRM rules about safe content presentation. For example, a DRM system can require that no unencrypted content travel over an accessible PCI bus, or that high-definition video output is permitted only if the video card and monitor support HDCP. Many of the protected path mechanisms are implemented in kernel-mode device drivers.
• Protected Environment: This is a Windows kernel mechanism to ensure that kernel-mode drivers are safe for protected content. Drivers that handle protected content must be digitally signed and authorized by Microsoft, and must implement specific security functions. Other kernel-mode drivers must also be signed, to ensure that they have a known origin and have not been tampered with. Unless all these signature and authorization checks pass, protected content cannot be played.

Some OCP mechanisms are planned for Windows Vista in 2006 (the basic video and audio protections, and the protected environment), and improvements are promised soon after. The work is not all Microsoft's: they credit Intel, ATI, NVidia, S3, and Matrox as "key partners", which is essential because those partners need to create the driver software and add security hardware (particularly for video cards) that implement some parts of OCP.

In the longer term, although no specific plans were announced, the OCP technology seems likely to dovetail with the Microsoft's currently dormant Next Generation Secure Computing Base (NGSCB, formerly known as Palladium) hardware security technology. Although not dependent on NGSCB, OCP is clearly something that could benefit from NGSCB protection. It is the initial realization of mechanisms very much like what NGSCB critics have been warning about. NGSCB had been dependent on the Trusted Computing Group's Trusted Platform Module (TPM) specification, and the TPM 1.2 mechanisms would be useful in providing remote proof that OCP is present on a PC.

At a high level, OCP's Protected Path and Protected Environment ideas seem straightforward and like reasonable ways to satisfy the needs of content providers. In implementation, however, there is a great deal of software complexity, management process, and supporting infrastructure.

One complexity is software authentication, because the Protected Environment requires that drivers be both authentic and sound. This puts Microsoft in the business of analyzing, testing, and authorizing new driver versions--not just determining that they appear not to break Windows or cause incompatibility problems (which are the main goals of Microsoft's Windows Hardware Qualification Labs testing today), but that they provide a secure implementation of required protection features.

To implement OCP, device drivers have numerous new security responsibilities. Drivers must ensure that the hardware they control is authentic and is not being tampered with. Such checks are intended to prevent content from being captured by substituting bogus hardware. For example, there is a a new mechanism called "tilt bits". Like the tilt sensor in a pinball machine, which detects when the table is being shaken or abused and terminates the game, the "tilt bits" mechanism requires the driver to make checks on a regular basis so that it can inform Windows if it detects anything suspicious. Windows will respond by terminating the game: no more playing of protected until after a clean reboot. These checks are intended to happen frequently, perhaps even with every video frame.

Drivers also are required to use cryptographically secure communication channels to communicate with Windows--public key and secret key encryption are used to establish something like an SSL connection between the driver and the Windows kernel, preventing adversaries from snooping on or altering that communication. Drivers and the hardware they control must also encrypt the content itself any time it is exposed inside the PC. This prevents adversaries from, for example, capturing unencrypted content by monitoring the PCI bus.

Device driver writers and hardware designers who have traditionally concentrated on low-level hardware access, cost, and performance may find all of these new software functions and hardware requirements to be unfamiliar and daunting to implement.

Another complexity is revocation. Authorization is not particularly useful unless it can be revoked when a compromise is discovered. Microsoft plans to run a revocation infrastructure that distributes a Microsoft Global Revocation List to identify no-longer-authorized driver software, presumably through the Windows Update mechanism. Drivers will be added to this list if they are discovered to contain exploitable security flaws, and DRM rules can be written to require that the list is appropriately fresh (Windows Rights Management Services, Microsoft's Enterprise DRM solution, already contains this type of capability.). Software revocation is problematic because of the potential effect on customers who may suddenly be unable to play content through no fault of their own, so revocation will likely only occur well after updates are distributed, leaving a long window of content vulnerability.

A third, and perhaps the most serious, complexity is that of the user experience. These new mechanisms will render much current hardware obsolete for delivering protected content, and they will have the potential to introduce new inexplicable error scenarios.

The hardware obsolescence problem seems worst for video: Today, users do not need to replace their video monitors when upgrading to a new PC or new OS, and those who have invested more than the cost of their PCs in high-quality displays will likely be outraged if their PCs tell them that they must upgrade their wall-filling plasma displays. Microsoft is not setting the rules here -- only allowing content providers to do so -- but there is certainly potential for consumer backlash if a movie studio only allows movies to be played on video hardware that barely even exists today. It seems likely that there will be a considerable period when these new mechanisms are present but are not widely used.

For most end-users, if the protections say "no", the reason is likely to be mysterious. Has a driver been revoked? Has tampering been (erroneously) detected? Why can't I play this movie today when I could play that one yesterday? Does this message mean I'm a criminal? Questions like these are outside the scope of most user experience, and they seem likely to represent a major support burden and potential for unhappiness with the associated business models.

The OCP mechanisms clearly represent a major investment by Microsoft, both from a software development standpoint and in management cost for all the testing, authorization, revocation, and support activities. That sophistication and investment say that Microsoft is in it for the long haul, and may be planning on several years, and several versions, before the protections are widely used. Adoption is slow: for example, Windows XP included a precursor mechanism called Secure Audio Path, but as of April 2005, Microsoft knew of no third-party applications that enabled it.  Confirming the long-term nature of OCP, there is a major focus on protecting against hardware-based attacks that, today, are quite rare because they are so much more expensive and less practical than software attacks.

Will OCP's technology be effective? Well, Microsoft may be in a better position to do this well than anyone else, and they are putting a lot of resources into it, but in many ways OCP process resembles the Strategic Defense Initiative (SDI) of the Reagan era. OCP is like SDI in that it is large, expensive, complex, dependent on major technical advances, and largely motivated by political concerns. The requirements that drove this development came principally from the media industry, and the goal is a political one: make content producers comfortable with PC-based content delivery. At least OCP seems likely to be successful in satisfying its political goals, at least in the near term.

However, OCP also resembles SDI in another crucial way: it seems unlikely to be very effective in actual use. As with SDI, the advantages rest largely with the adversary: simple and low-cost measures had the potential to make much of SDI irrelevant, and the defender's cost to counter those measures was exponentially greater than the adversary's cost to use them. Just as the fall of the Soviet Union has led to a proliferation of much less manageable (and arguably more serious) threats, OCP technology may have a similar effect.

Software tamper resistance is a battle of wits. The defenders must anticipate and counter all possible attacks and deploy those solutions rapidly on a wide variety of platforms, while the adversaries need only to find a single flaw to exploit. Especially in combination with NGSCB, OCP's protections could be significantly stronger, but the fundamental equation doesn't change: the adversary only has to exploit a single flaw -- although if NGSCB were to re-enter the picture, a hardware-based attack might be the easier route.

The larger business issues are also cloudy. Much of the PC's success derives from its inherently open nature, yet it is not clear that the PC platform can be both open and secure, nor that consumers will find the costs and consequences acceptable. There is much clever technology in OCP, but the underlying problem -- of preserving the content producers' business models -- is not obviously solvable with technology.

Get DRM Watch Newsletter

Click here to subscribe to DRM Watch