Once a reliable session key is available, Windows Vista can use the session key to robustly pass other keys across the bus to the graphics chip. The various content streams are encrypted with stream-specific content keys, and the Diffie Hellman-established session key is used to get the various content keys to the graphics chip.
The ProtectedDXVA component, which is in the protected MIG environment in user mode, generates a content key using a random entropy process, and then uses this key to encrypt the content.
ProtectedDXVA then passes the content key down to the Windows Vista LDDM kernel-mode component, where the content key is encrypted with the session key (that came from the Diffie Hellman process), so that it can be safely sent over the wire to the graphics hardware. This process is called key wrapping. The LDDM component is responsible for generating and managing the counter values used in the encryption process.
Each video stream will typically have its own content key. This is true whether the content is being AES encrypted or encrypted with the High Bandwidth Cipher. The LDDM component will tell the graphics chip which key to use at any particular time.
There is no limit on the maximum number of content keys, although in practice there will probably be less than eight around at any one time. It is up to LDDM in Windows Vista to manage the use of the content keys.
To help ensure best security, it is required that the session key be stored on the actual graphics chip, rather than in VRAM. Content keys can be stored in VRAM if required (or any other RAM), because they are encrypted with the session key. Content keys will typically be decrypted just at the moment they are needed.
The ProtectedDXVA component keeps a duplicate copy of the content keys so that it can encrypt the various streams. In practice, ProtectedDXVA will tell the graphics card the content key on every DMA transfer.
Page-outs
Pages in the graphics subsystem can be paged out by the operating system when the need arises. There will be various priority levels that get assigned to surfaces, to influence how often a page-out may occur.
In the video context, a page-out would cause a glitch in the playback of the video. Given that this is extremely undesirable, video surfaces will be given a high priority, and in practice will only in exceptional circumstances be paged out. The problem is that a hacker may do something to induce a page-out.
Even higher priority than video playback is video capture and the actual desktop that is being displayed. The operating system will aim to keep these super-high priority “hard pinned” things to a minimum—that is, less than about 15 percent of the VRAM will ever be hard pinned. The priorities will be determined by the Microsoft LDDM graphics team, who are aware of the importance of maintaining good quality video playback.
In the case of discrete graphics, it is necessary to protect the data to be paged out, because it will be going over what may be regarded as a user-accessible bus. Fortunately, the AES decrypter on the graphics chip can also function as an encrypter, because it is actually the same algorithm used to encrypt AES as it is to decrypt.
Microsoft DirectX surfaces containing premium content in the local video memory are marked with a special protection bit, indicating protected transfer status for them. The bit can be examined to decide whether the surface page is required to be encrypted during paging operations.
The cipher used for page-out is required to always be AES 128-bit counter mode. The use of a High Bandwidth Cipher for page-outs is not supported. As mentioned, page-out of video pages is not expected to happen under normal user scenarios, so the fact that the AES engine in some implementations might be limited to only 50 MBytes/sec is not a problem.
A page key is generated by the LDDM component and is passed to the graphics chip by encrypting it with the session key. If the chip loses its keys—for example, due to hibernation—a new session key can be established, and this can be used to send the graphics chip the original page key.
Using System Memory
Given the data throughput possible with PCIe, there is a new class of discrete graphics cards that, to reduce costs, do not have much memory on the board. They use system memory accessed over the PCIe bus.
In the limit, this lack of local memory means that, for example, to decode, de-interlace, and render a frame of HD may require that an HD frame be sent backward and forward over the PCIe bus many times—it could be as many as 10 times.
|
|
The frames of premium content are required to be protected as they pass over the PCIe bus to system memory, and decrypted when they safely return to the graphics chip. It is the responsibility of the graphics chip to perform the encryption and decryption—there is no operating system involvement.
As far as the operating system is concerned, the frame of premium content is just sent to the graphics card once and never comes back. The operating system will just set the premium content header tag, to indicate that particular video frames must be properly safeguarded—that is, not passed in unprotected form over a UAB.
Depending on the hardware implementation, the on-chip cipher engine might, or might not, go fast enough to encrypt the 3 GByte/sec (in each direction) memory data bandwidth.
As memory encryption and decryption are done solely in the vendor’s hardware, without operating system involvement, it is not a fundamental requirement to use any particular High Bandwidth Cipher, as long as the protection meets the required security bar as specified by the Content Industry Agreements.
Rather than specify PVP-UAB–specific rules, it is a PVP-UAB license requirement that the protection used by the graphics hardware manufacturer meets the manufacturer’s interpretation of the requirements defined in the Advanced Access Control System (AACS) and 5C DTCP licenses, when accessing system memory over the PCIe bus.
It is the responsibility of the graphics hardware manufacturer to find and interpret these requirements, and to ensure that these requirements have been met. It is recommended that the protection used be the same as when uncompressed content is sent by PVP-UAB to the graphics card—that is, either AES 128-bit counter mode, or a cipher that meets the High Bandwidth Cipher compliance rules, for example, the Intel Cascaded Cipher.
As with all other PVP requirements, the typical mechanism for correcting any valid complaint from the content industry would, after due process, be revocation; that is, it will no longer be usable for high-level premium content.
| 