Microsoft has had great support in this joint effort with the graphics hardware manufacturers to solve this important problem on the PC platform. The first PVP-UAB compliant graphics cards are expected to be available to begin internal testing before the end of 2005.
The software for PVP-UAB is complex and is heavily influenced by the other major advance in the graphics-card world, that is, the move to the LDDM Advanced Scheduler model. PVP-UAB makes use of some of the architectural features of the Advanced Scheduler—primarily in the areas of surface management and the protected storing of keys. For discrete graphics, it is necessary to use an Advanced Scheduler LDDM driver. Integrated graphics, which doesn’t need bus encryption, can work with either a Basic Scheduler LDDM driver or an Advanced Scheduler LDDM driver.
The current plan is to provide a beta version of the PVP-UAB functionality with stable DDIs at the time of the initial release of Windows Vista. This timing is planned to help ensure that graphics cards work correctly when we ship the PVP-UAB feature.
PVP-UAB is not compatible with the Windows XP graphics driver model.
PVP-OPM and PVP-UAB Certification
This section briefly discusses certification for PVP-OPM and PVP-UAB.
To get a certificate, a graphics manufacturer will need to sign a legal document, promising to have done everything that the PVP-OPM or PVP-UAB specification specifies. To make it easier to separate the requirements from the recommendations, there is a Compliance Rules document that lists requirements from the specification in a concise form. This PVP Compliance Rules document forms part of the legal agreement.
It is an honor system, but if it turns out that a vendor has not met the requirements for any reason, then if a valid report of content leakage occurs, Microsoft will, after due process, need to revoke the driver’s ability to play high-level premium content. This revocation is actually a benefit to the graphics manufacturer, by helping to protect against actions that a content provider might take against that hardware manufacturer in case of leakage.
Content protection is about links in a chain. Each member of the PC industry that provides a link in that chain has a responsibility to protect premium content, to ensure that the content industry will trust its content to the PC.
The graphics driver uses HFS to determine whether the hardware is valid. In turn, the MIG software in the Protected Environment must determine that the graphics driver is valid, that it has performed the required authentication of the hardware, and that the hardware has implemented the requirements defined in the PVP Compliance Rules. The mechanism for this is the PVP certificate given to the driver when the requirements have been met and the license document has been signed.
PVP-OPM is an important part of the current protection of Windows Vista. PVP-UAB adds another important piece, that is, the encryption of content over the user-accessible bus. PVP-UAB is a superset of PVP-OPM (targeted at discrete graphics cards), and as such it is necessary to meet all the PVP-OPM requirements as a pre-requisite for obtaining a PVP-UAB certificate.
The PVP-OPM Compliance Rules require graphics chip manufacturers to have met the Content Industry Agreement hardware robustness rules. The certificate is only issued to manufacturers that attest to having met those rules.
It is recommended that a graphics manufacturer go beyond the strict letter of the specification and provide additional content-protection features, because this demonstrates their strong intent to protect premium content.
If you are a graphics chip manufacturer, the "links in the chain" responsibility includes making sure that you avoid selling chips to people who are trying to build hacker-friendly graphics boards. The easiest way to prevent this is to ensure that the necessary output encryption happens on chip, but it is not the only way.
The certificate in the driver is an embedded certificate with a corresponding key pair. This is useful because, in the case of PVP-OPM, there is a need to OMAC-sign the command-and-status messages. Implicitly, the certificate also serves as an identity.
The part of the driver code that has the private key is required to be obfuscated. The same signing tools used for COPP will be used for PVP, and it is envisioned that the graphics manufacturer will use the same obfuscation tools as used for COPP.
Graphics drivers are implemented such that there is only one driver used for the complete range of the manufacturer’s graphics chips. That range will encompass some chips that support the PVP requirements and some older chips that do not.
It is the driver’s responsibility (under the terms of the PVP license) to return the PVP certificate only when the driver is talking to a chip that provides the required PVP features. The driver will keep a list of chips served by the driver that conform to PVP requirements, and will return the certificate only when the driver has reliably determined (through HFS) that it is talking to a chip that is PVP compliant.
PVP-OPM – With and Without PVP-UAB
To clarify when graphics hardware needs both PVP-UAB and PVP-OPM, and when it is sufficient to just have PVP-OPM: the biggest factor is whether there is a user-accessible bus, and then whether the policy associated with specific content requires protection to be provided over user-accessible buses.
Integrated Graphics and PVP-UAB Solutions
In the case of integrated graphics, there is no user-accessible bus, so there is no need for the bus encryption and key mechanisms that PVP-UAB provides. However, there is a need for authentication—that is, a need for HFS—but the tests required to prove beyond reasonable doubt that the driver is talking to valid hardware are much simpler for integrated graphics than in the case of discrete graphics.
Output Protection Management is required for integrated graphics, that is, the full implementation as described in the PVP-OPM specification. What is not needed is the hashing mechanism that discrete graphics vendors might choose to implement, to ensure that status messages from the hardware back to the driver are not interfered with when they pass over the user-accessible bus.
In the case of integrated graphics, the Content Industry Agreement hardware robustness rules apply to the motherboard. These are discussed in the PVP-OPM specification, but they are just recommendations. It is the chipmaker’s responsibility to ensure that their chips are used only on boards that meet the Content Industry Agreement hardware robustness rules.
In the integrated graphics case, there is no need for key storage, and therefore integrated graphics will work equally well when using the LDDM Basic Scheduler. For integrated graphics, it must be an LDDM driver, but it can be the LDDM Basic Scheduler.
Discrete Graphics Chips on Motherboards
When a discrete graphics chip is on the motherboard, and there is no connector or header associated with the PCIe bus that goes to the graphics chip, then there is no need for bus encryption. In the case of a discrete graphics chip, it is likely that the chip does contain the circuitry necessary for decryption, but there is no need to turn on encryption.
However, if the same driver is used as in the discrete case and that driver cannot via its HFS mechanisms reliably identify any difference between the chip-on-motherboard case and the chip-on-separate-card case, then the ProtectedDXVA component will encrypt the content and the chip will need to decrypt it. This will mean unnecessary use of CPU cycles, but everything should work OK.
To avoid unnecessary use of CPU cycles, it is necessary to introduce a chip difference that the HFS mechanism can reliably detect, so that it can robustly report that no UAB is present. This could be done by loading different secrets into chips destined to be soldered on motherboards, or by using different wire-bonding on those chips. One possibility is that the ROM chip selected would not be bonded on such a chip variant, to prevent it being used on an external card.
Another possibility is that differences in the graphics BIOS can be used. The HFS mechanism might be able to determine whether a separate BIOS is present (therefore, it is a discrete card) or that the BIOS is integrated into the system BIOS (so it is the motherboard-down case). It is the graphics manufacturer’s responsibility to ensure that the HFS mechanism used is reliable and robust. In the event that it is not, then there is a real possibility that the PVP certificate for the driver might need to be revoked.
Using the HFS mechanism, the discrete chip on the motherboard would be identified as a different chip model number compared with that chip on a discrete card. The model number would be checked against the table in the driver to determine whether the PVP certificate is returned for that chip. Also in that table is a flag that specifies whether the chip is connected by way of a user-accessible bus. This information will be provided to the ProtectedDXVA component when it requests it through the DDI.
The ProtectedDXVA component will trust the driver if it returns a PVP certificate, and therefore will trust the driver to report whether the chip is connected using a user-accessible bus. If it is reported that there is no user-accessible bus, then the ProtectedDXVA component won’t encrypt the content.
A graphics chip soldered on a motherboard (or in an IC socket), connected by way of a HyperTransport bus, would not be classed as having a user-accessible bus, provided there is no connector to access the signals. If there is a connector on the HyperTransport bus, then it would likely be classed by some content owners as having a user-accessible bus.
In the case of a discrete graphics card, the situation is fairly straight forward. There is a PCIe bus, and since some premium content types are likely to require protection over the PCIe bus in the future, then PVP-UAB will be required.
Protected User Mode Audio: PUMA
This section examines what Microsoft is planning for audio output content protection in Windows Vista.
Traditionally, there has been less focus in the industry about protecting audio content compared with the video, but this is changing. We want to make the PC a safer place for premium audio content, in the same way that we’re making it safer for premium video content. Many of the same techniques used for video can be applied to protecting audio, but there are other interesting issues that make audio a separate consideration.
There is a trend on the PC toward using the Universal Audio Architecture (UAA) for rendering all audio. The protection capabilities in Windows Vista are all built around UAA.
The initiative to add audio output content protection to the PC platform involves incremental steps, rather than trying to do everything at once. There are no suitable protection mechanisms for some common digital audio connectors. Initially much of the protection for audio will have to come from turning off various audio outputs, if that is what the content specifies through its policy statement.
Some audio outputs are less problematic than others. It is now common to provide high-quality audio on the motherboard and to provide six analog channels of audio on jack plugs. Analog outputs can actually achieve very high quality, but are less problematic from a content protection perspective, because there is no digital signal to capture.
Without intervention, given the lack of suitable content protection mechanisms on some external audio connector types, it is possible that the advent of more premium audio content might mean that the only two viable audio output types from the PC are analog audio on jack plugs, and HDMI because it has HDCP protection.
| 