This section describes what happens when content is played.
PVP-OPM Play Sequence
1. On play, form policy object
When the content is about to play, the ITA for the content forms a policy object and passes it by way of the policy engine to the OPM Output Trust Authority (OTA). The OPM OTA maps the output policy requests given in the policy object with the available output protection mechanisms.
2. OPM OTA
The OPM OTA routes requests for resolution constrictions to the Enhanced Video Renderer (EVR) and routes all other output protection requests to the OPM component.
3. PVP-OPM commands to vendor-supplied driver
Next, the OPM component sends a set of commands to the vendor-supplied kernel-mode driver to request the required protections on the various outputs and, as required, to request that various outputs be disabled. Even if the Protected Environment has dropped out of high-level security mode, there is no fundamental need for these commands to be verified, because security is mainly associated with the resulting status messages. However, OMAC is also included on the commands as an extra precautionary measure.
4. Vendor-supplied driver commands sent to chip
Next, the vendor-supplied kernel-mode driver sends commands to the hardware to turn on protection and to turn off unprotected outputs as appropriate.
5. Vendor-supplied driver queries chip
The vendor-supplied kernel-mode driver then queries the hardware to get the state of the outputs—that is, what protection is enabled and what outputs are turned on or off. The graphics hardware manufacturer is responsible for ensuring that these messages from the hardware to the driver—for example, through complexity, obfuscation or hashing—are sufficiently difficult for a hacker to interfere with. In addition to an initiated request, the vendor-supplied driver is required to poll the state of the hardware outputs at least once every 30 milliseconds if a user-accessible bus is present.
To further ensure no tampering of the output status reporting in the discrete graphics case, it is recommended that, a message-hashing mechanism be used between the driver and the hardware. In such a scheme, the graphics chip could form a signature hash of all the status messages it has sent since the last signature reset command from the driver. The driver would calculate a signature hash from the status commands it received, and then compare that hash signature with the one sent up from the chip. Using a signature hash is only a recommendation, but is an example of how manufacturers can demonstrate their intent to protect premium content.
6. OPM queries vendor-supplied driver
The OPM component queries the driver to find the status of the outputs, that is, whether the output protection is on and the on/off state of the outputs. In addition to being protected by the Windows Vista Protected Environment, the status messages from the driver are protected with OMAC, using the driver’s key pair that is part of the PVP certificate. This backup security mechanism is provided so that mid-level security (like Windows XP) can still be provided, even if the Protected Environment detects a problem and doesn’t allow high-level content to play.
7. PVP-OPM compares and reports if safe
In this final step, PVP-OPM compares the output state received from the driver with the output state it requested; if they are the same, then PVP-OPM tells the MIG controller that PVP-OPM is happy for the premium content to be played.
Driver applies tilt detection mechanism (as needed)
Tilt bits are provided in the DDI as the driver’s mechanism for reporting that a hacker is suspected. If at any time the graphics driver determines that something improper has happened, then it can set the appropriate tilt bit—for example, if the hash of an output status message doesn’t match the message. If any tilt bit gets set, then Windows Vista will initiate a full reset of the graphics subsystem, so everything will restart, including re-authentication.
The tilt bits are also used by the driver in PVP-UAB to report problems with its bus encryption mechanisms. When setting a tilt bit, the vendor-supplied kernel-mode driver will also typically invalidate its session key as a further precaution.
There is no requirement regarding the circumstances under which a driver should set a tilt bit. Adopting this mechanism is another example of the hardware manufacturer showing their intent to properly protect premium content. An example of its use is as follows:
A hacker might try to use a hardware signal-injection device on the PCIe bus to try to force the graphics chip out of virtual memory mode, in order to read back premium content from VRAM. The graphics chip could detect that it was no longer in virtual memory mode, and could then set a tilt bit to request that premium content not be sent.
Another scenario might be a hacker trying to feed the graphics chip a fake page table, using a hardware injection device.
As part of the tilt detection mechanism, the hardware manufacturer might choose to have the driver track the state the chip is supposed to be in and compare that with the actual state.
Windows Vista will poll the state of the tilt bits at some frequency—likely on every video frame. It will be the same mechanism used to frequently check Output Protection Management states.
|
