Authentication is required for PVP-OPM and PVP-UAB, because a hacker might try to introduce a hardware emulator device that behaves like the graphics chip—for example, leaving unprotected digital outputs turned on while reporting that they’ve been turned off.
To prevent this, the vendor-supplied driver must authenticate the graphics chip, to determine that it is talking directly to the proper graphics chip.
|
|
The standard crypto method for establishing the identity of something at the other end of the wire involves using a key pair in the device, and a public key infrastructure. Although using unique keys is allowed by PVP-OPM and PVP-UAB, it is expensive to put unique keys in graphics chips, so while this is allowed, it is not required.
Authentication of graphics chips, however, can make use of the complexity of modern graphics chips, which have a complex arrangement of a large number of gates and a complex state model. For purposes of authentication, the device driver can ask complex questions of the hardware and then check the answers. Some possible test vectors could result in predictable answers—for example, loading a program on a shader that multiplies 2 x 2 and reports back 4 as an answer, but this would not be useful. The HFS test vectors must to be devised such that each manufacturer’s chip will return a different answer in some subtle way.
Each graphics card manufacturer is responsible for specifying the actual authentication tests, because only they know the subtle idiosyncrasies of their chip. Such tests could involve loading a surface with an image, and then getting the chip to apply various visual effects to the image and reporting back the resulting pixels. Each chip design will return a subtly different set of pixels as the answer. Because of the complexity of modern graphics chips, it is extremely unlikely that a hacker could build an emulation of the graphics chip that would produce the same answer. Another possibility is to exercise a portion of the boundary scan shift register chain in the chip and then check the answer. This would effectively be a complete self-test of that part of the chip, but this is considered to be an excessive test.
When a user-accessible bus is present in the path—for example, in the case of a discrete graphics card—the HFS tests need to be “seeded” to prevent replay attacks, that is, the hacker device providing an answer it learned by snooping a valid device earlier. For PVP-OPM, when a user-accessible bus is present, a random seed is required; but in the case of PVP-UAB, the seed must be derived from the session-key generation process.
Because of the seed, the answer to the challenge questions will always be different, but the driver software can determine whether the answer is correct, because it knows the seed it used with the question. To determine the correct answer, the driver software will use either a software emulation of the appropriate part of the chip hardware, or will use a lookup table of answers.
A benefit of using a lookup table is that it can contain answers learned from real hardware, rather than having to write a software emulation of the unique hardware functionality being used for HFS.
In the case of graphics functionality being implemented as part of the motherboard chipset—for example, in the north bridge—it is extremely difficult for a hacker to produce an emulator. The HFS requirement is that the driver can prove beyond reasonable doubt that the hardware it is talking to is the valid hardware. In the case of motherboard chipset integrated graphics (that is, a Bus 0 device), it is only necessary for the driver to check some simple attributes to satisfy the “beyond reasonable doubt” requirement.
The graphics hardware manufacturer must do whatever is appropriate to prove that the driver is talking to genuine hardware. If a particular implementation proves to be insufficient, as highlighted by a hack or a valid complaint from content owners, then the related driver might need to be revoked, and a new driver would have to be deployed with additional HFS tests.
The questions asked by the driver software must result in answers that are difficult for anything other than valid hardware to produce. Two mechanisms can be used for this:
The calculation of the answer in hardware must be so complex that it would be impractical for anyone to emulate the hardware necessary to calculate the answer.
- Or -
The internal workings of the graphics chip must be kept secret, such that a hacker building an emulator could not find out the required information.
In practice, using a combination of complexity and secrecy is likely to be the best option. When secrets are involved, the HFS code in the vendor-supplied driver should be obfuscated to prevent it being reverse engineered, although there is no absolute requirement to do obfuscation.
HFS implemented in the driver must be able to verify beyond reasonable doubt that the hardware it is talking to is genuine. The complexity of the HFS required depends on the type of hardware. For an integrated graphics chip, it is easy to check beyond reasonable doubt that it is genuine, because it is a Bus 0 device. For a discrete graphics chip, it is a harder task to verify this, so more tests are needed in the HFS process.
A big benefit of HFS is that it is done in the driver, so if a hack occurs, it is possible to revoke and renew the driver, which is not possible with global secrets stored in hardware.
HFS and Drivers Supporting Multiple Chips
Often, a graphics driver serves many different chips, some old, and some new, some that conform to PVP-OPM and PVP-UAB requirements, and some that don’t. The driver must report its certificate to the operating system for the cases where the hardware is compliant, and not report it when the hardware is not compliant.
Therefore, the driver must be able to reliably identify which chip it is talking to, using HFS. Typically a lookup table in the driver is used to decide whether to report the certificate to the operating system. A driver that serves multiple chip types must ensure that the certificate granted to the driver is never returned to the operating system for chips that do not meet the compliance rules. If this is found to happen, then the driver will be revoked, and a corrected version must be deployed before high-level premium content can play.
The Windows Vista Protected Environment will, after due process, revoke any driver that is found to be leaking premium content (either itself, or from the hardware it controls). It is a serious business to have to revoke a driver’s certificate—even though revocation involves due process, is under the control of the user, and is typically accompanied by a renewed fixed version of the driver. If the same driver is used for all the manufacturer’s chip designs, then a revocation could cause all that company’s products to need a new driver. The plan for Windows Vista is that the HFS chip identification mechanism will be used to provide greater revocation granularity than just the driver level.
HFS and User-Accessible Bus Reporting
The HFS process in the vendor-supplied driver will also report to the operating system whether the particular graphics chip has a user-accessible bus—essentially, whether it is a discrete graphics chip or integrated.
For a discrete graphics chip on the motherboard, it is OK to report that there is no user-accessible bus present; but it must be possible for the HFS process to reliably determine that the chip is indeed on the motherboard rather than on an add-in card. In practice, it is expected that discrete graphics chip manufacturers will use different pin-out or bond wire options, or BIOS options, for chips on motherboards.
In the HFS process, the UAB bit is a very valuable bit, because a hacker could try to set it to "no- UAB" even when a UAB is present. Great care must be taken to ensure the setting of the bit is properly protected. However, obfuscating the code that sets the UAB bit is not required, because the driver is trusted; this is because it is in the Protected Environment, and there is no secret involved.
PVP-OPM Architecture - simplified view of the various components involved in PVP-OPM
|
