There is considerable work on the Microsoft side of PVP-UAB, but there are also considerable requirements placed on discrete graphics chip manufacturers.
AES 128-bit Counter Mode
Discrete graphics chips are required to implement AES 128-bit counter mode decryption, for receiving encrypted compressed (and semi-compressed, and occasionally uncompressed) premium content over the PCIe bus. This must be a hardware decryption engine on the graphics chip, not in the driver.
It is envisioned that compressed and semi-compressed streams can be up to 50 MBytes/sec, and this is the minimum requirement for the hardware decryption engine. In practice, it is the software encryption that is likely to be the bottleneck, rather than the hardware decryption.
The AES encryption of the content happens in a user-mode component that resides in the MIG-protected user-mode environment. The component is called ProtectedDXVA, which is Microsoft DirectX® Video Acceleration (VA) version 2.0, with added PVP-UAB protection capabilities.
The AES encryption is only to protect from a hardware snoop of the bus, and is not necessary for preventing software attacks, because those are already mitigated using the Windows Vista Protected Environment.
In the case of fully compressed and semi-compressed video, MacroBlock control data won’t be encrypted, because the LDDM kernel-mode component lower in the software stack needs to make surface translation decisions based on it. Everything else will be fully encrypted.
MacroBlock control data is not even the motion vectors, but rather GPU instructions that are derived from the motion vectors, a bit like motion vectors that have been through a compiler. It would not be possible to extract any kind of picture from the unencrypted control data. Even a determined hacker would at most only be able to see an indication of which areas of the screen had motion, but would have no idea what that motion corresponded to.
High Bandwidth Cipher
AES 128-bit counter mode is the only actual cipher that PVP-UAB requires to be implemented. When AES 128-bit counter mode is the only cipher available, the PVP-UAB software will, if required by the content policy, encrypt even uncompressed premium video using it. The degree to which this works depends on the resolution of the content and the available CPU power. There is no security risk associated with the resolution being too high, but the video would potentially start to stutter.
The problem with regular AES is that it takes about 20 CPU clocks to encrypt each byte. This is OK for compressed or semi-compressed video, but for the multiple HD uncompressed case, it is too much even for a 2006 processor. A dual HD uncompressed stream with potential sub-picture information can be up to 250 MBytes/sec.
An encryption mechanism more like 4 or 5 CPU clocks per byte was required. Schemes such as Linear-Feedback Shift Register (LFSR) were considered, but did not provide the required security strength. The security bar for uncompressed premium video is not quite as high as for compressed premium video, but it is still very high.
In response to the 4 or 5 clocks-per-byte challenge, the concept of re-encoding the AES cipher blocks to allow mild re-use was born. A specific implementation of this concept was invented by two cryptographers at Intel, Ernie Brickell and Gary Graunke.
The Intel Cascaded Cipher is a mechanism for re-using each 128-bit cipher block a number of times. It does this by applying Serpent encryption to the cipher blocks coming out of the AES engine, rather than just using the XOR function that regular AES 128-bit counter mode uses.
The security level achieved for typical video data is estimated to be approaching that of regular AES. This assertion is being tested by Intel putting its Cascaded Cipher out to the crypto community to get their security assessment—that is, to see if they can break it.
Depending on content industry agreements, it is hoped that the High Bandwidth Cipher can be used instead of regular AES when content must be software encrypted, since it will take less processor cycles.
Regular AES still needs to be provided, however, for when content specifically says that full AES is required. AES 128-bit counter mode also provides the base-level cipher that can be relied on always being present.
A license for using the Cascaded Cipher is required from Intel, to ensure that the Cascaded Cipher is properly implemented. Intel is working with the crypto community to prove the security strength of their Cascaded Cipher. It is important to prove to premium content providers that the encryption system will properly protect their content. It is also necessary to obtain the content industry’s written agreement as to it meeting their security bar.
All of this would be in vain if a particular bad implementation of the Intel Cascaded Cipher exposed a security hole; hence, the important need for a license.
The Intel Cascaded Cipher is the default preferred cipher to use as the High Bandwidth Cipher in PVP-UAB. It is a promising design, but it is not, however, the only possibility for the High Bandwidth Cipher.
Other companies are free to invent their own High Bandwidth Cipher, but security considerations mean that there is a high bar to meet before a new cipher can be approved for use. The proposed requirements—which also apply to the Intel Cascaded Cipher—are as follows:
1. Public review
It must have received a public review by the crypto community, and sufficient evidence must have been amassed as to its security strength.
2. Content industry acceptance
The evidence must be presented to Hollywood and other content owners, and they must agree that it provides the required level of security. Written proof from at least three of the major Hollywood studios is required.
3. Available for anyone
The cipher must be available for anyone to use under reasonable and non-discriminatory terms.
4. Encryption module provided
An “Encryption Module” that implements the high bandwidth encryption interface must be provided to Microsoft, so that we can encrypt using that cipher.
When Microsoft has received a written agreement from sufficient content owners, plus proof that the new cipher is available on non-discriminatory, fair, and reasonable terms, then we will approve the cipher for use with PVP-UAB. The encryption module will be linked into the ProtectedDXVA component in Windows.
Establishing a new cipher involves a lot of work and elapsed time. If other companies want to do the same public review work that Intel is doing, and meet all the other criteria that Intel is meeting, then they can use their own cipher. If two or three ciphers become established, then it is envisioned that smaller graphics companies will pick the one they like best—hence, the requirement that all ciphers be available on reasonable non-discriminatory terms.
Microsoft will provide a DDI that allows discrete graphics drivers to tell the ProtectedDXVA component which High Bandwidth Cipher standard, or standards, they support.
Hardware manufacturers can also report through the DDI that they do not provide any High Bandwidth Cipher. In this situation the ProtectedDXVA component will always encrypt using regular AES, even when needing to send uncompressed premium content.
In the case of premium content, whether video can play back smoothly when using regular AES with uncompressed video will be a function of the resolution of the uncompressed video and the power of the processor. It is unlikely to work well in 2006 for uncompressed HD premium content, but it is likely to be OK for uncompressed standard definition.
Also (as described later), premium content is usually sent to the graphics chip in semi-compressed (DirectX VA) form, rather than uncompressed. The market can decide whether graphics chips that do not provide a High Bandwidth Cipher achieve customer acceptance.
It is highly recommended that a High Bandwidth Cipher be provided, and it is also recommended (but not required) that the Intel Cascaded Cipher is the best choice for the High Bandwidth Cipher.
It is a fundamental requirement to support AES 128-bit counter mode hardware decryption in graphics chips.
Issues with Encrypting Uncompressed Video
There are some negatives associated with encrypting uncompressed video to send it over the PCIe bus to the graphics card. The biggest problem is the large amount of CPU power that it takes to encrypt uncompressed, even when using the High Bandwidth Cipher. When possible, a better solution is to not send the premium video as uncompressed—that is, it is better to send it as semi-compressed and get the graphics chip to decode it.
It is a PVP-UAB requirement that discrete graphics chips implement at least iDCT and Motion Comp decode acceleration for MPEG2 and Windows Media® Version 9/VC-1.
Given decode acceleration capability in the graphics chip, using the High Bandwidth Cipher for uncompressed just becomes a fallback solution for people that, for premium content, want to use software decoding or want to process raw pixels in software. This is likely to be rare given modern graphics chips, but it is important to not disallow it.
The implications of not having a fallback solution for uncompressed would be that software decoders could not be used for premium content. Software de-interlacing would also not be possible, nor would pure software overlaying of graphics onto the video, nor doing video effects purely in software.
It would be a radical step to say the CPU is not allowed to do full video decoding. Today, that would be a big problem for Windows Media and other non-MPEG2 codecs, but in the Windows Vista timeframe, graphics chips will have hardware WM decode acceleration.
Establishing the Session Key
The hardest thing about encryption is the establishing of a key, rather than the actual encryption. The standard crypto way of having a key for use in encryption is to have an RSA key pair in the receiving device.
|
|
Content would be encrypted by the sender, using the receiver’s public key, and the receiver would decrypt using its private key. Long term, this may be the solution that graphics chip manufacturers choose, but the problem is that it is not currently economically viable to require that graphics chips have unique key pairs, because that would involve expensive nonvolatile memory or fuses, and it would involve lengthy programming on the production line.
Instead, for PVP-UAB, Diffie Hellman is the recommended—and minimum security bar—method to establish a key.
It is necessary to establish a key that is known by both ends of the wire, but nobody else. The “nobody else” requirement means that the key cannot be just transmitted over the wire to get it the same at both ends, because a hacker could snoop the wire to get the key.
The key needs to be derived at both ends of the wire independently, and both ends need to arrive at the same answer, or else the receiving end won’t be able to decrypt the content encrypted by the sending end.
Once one key has been established, then any number of other keys can be sent across the wire by encrypting them with the first key. With the recommended—and minimum bar—implementation of PVP-UAB, the all important first key is produced using 2048-bit Diffie Hellman. This key, made from the Diffie Hellman exchange, is called the session key.
At the receiving end, it must be generated using the graphics hardware, rather than the graphics driver, because it is only the hardware that is at the receiving end of the wire. The software end of the key derivation is done in kernel mode by the vendor-supplied driver.
Lots of math is involved in calculating a Diffie Hellman key, but this is something that a modern graphics chip can do, particularly given its programmable shader capability. It is OK for the key-generation process to take up to 1 second, because it only happens once at system boot or when re-initializing after hibernation. There is no requirement to use a shader for Diffie Hellman—it is perfectly OK to use a dedicated hardware engine, if preferred.
The actual 128-bit session key is derived from the 2048-bit Diffie Hellman number, by putting all 2048 bits through an AES Davies-Meyer hash process. The hashing is actually done in the Microsoft LDDM kernel-mode component, after it is passed the Diffie Hellman number from the vendor-supplied driver.
There is no requirement to store the 2048-bit Diffie Hellman number. It is actually preferable if the vendor-supplied driver and the graphics chip forget the Diffie Hellman number once the session key has been derived from it.
A weakness with standard Diffie Hellman is that it is susceptible to man-in-the-middle attacks. Diffie Hellman man-in-the-middle attacks can be avoided if the identity of the device at the other end of the wire can be established. It is necessary to tightly couple the Diffie Hellman process with the authentication process, to avoid a man-in-the-middle being inserted between the two processes.
| 