Protected Audio Path: PAP

Protected Audio Path: PAP

PAP is analogous to PVP-UAB in that it would likely add content encryption capabilities. As with PVP-UAB, it would also need to do robust hardware authentication and would need to establish a key.

Think about PAP is as a collection bucket where we store future ideas about audio content protection. Current thinking is that PAP would provide protection all the way to the codec chip that has the digital-to-analog converter that makes the sounds. This might include protecting over whatever physical and wireless cables are in use in that future timeframe.

The most likely encryption candidate would be AES 128-bit counter mode, just like PVP. Instead of the ProtectedDXVA component doing the encryption, the encryption would be done in an Output Encryption APO in PUMA. In both the audio and video cases, the important thing is that the encryption is done inside the Protected Environment.

The proposed plan is that the hardware AES engine that does the decryption would be in the codec chip. This is a harder than in the case of a graphics chip, because codecs have far fewer gates and are also more price sensitive. The desire to not over burden codec chips is a contributing factor in not pushing to introduce audio encryption quickly. Adding AES engines to codec chips would at best take many years, and might turn out not to be feasible.

Establishing a session key is the hardest problem. It is not practical for an audio codec chip to do Diffie Hellman, because there is no natural math capability as there is in the case of graphics chip programmable shaders.

Providing robust hardware authentication is a big part of what PAP is about. As in the case of PVP, HFS can be used for hardware authentication. A codec chip is not as complex as a graphics chip, but even so there is enough sophistication that can be used in the HFS process. For PAP, the authentication would likely be done using a codec-specific user-mode authentication module that would plug into the POC component in the PUMA engine. Even though the user-mode module would be specific to a particular hardware manufacturer, the Microsoft class driver can still be used.

That still leaves the problem of how to establish a session key. Tentative plans address how to extend the HFS process to also generate a key at both ends of the wire. For want of a better name, this process is called MKey. The session key established between the Output Encryption APO and the audio codec chip would be used to encrypt a content key generated by the Output Encryption APO. It is the content key that the Output Encryption APO would use to encrypt the content.

As stated, the requirement to encrypt audio data is still many years away, and there is certainly no specification for how to do this yet. Having said that, Microsoft is eager to work with manufacturers of codec chips to plan for the future.

6. Summary

PVP-OPM provides reliable control of the various output protection schemes such as HDCP, Macrovision, CGMS-A, and resolution constrictors. It uses a simpler form of HFS for authentication and requires Content Industry robustness rules to be met for hardware implementations.

Manufacturers of graphics cards must implement the various protection mechanisms on card outputs, and must ensure that drivers have robust control of those outputs. Manufacturers must sign the PVP-OPM license to get a PVP-OPM certificate for their drivers. Without the certificate, Windows Vista will not be allowed to pass premium content to the driver.

PVP-UAB provides encryption of premium content as it passes over the PCIe bus to discrete graphics cards. It uses Diffie Hellman to establish as session key, seeded HFS for authentication, and AES 128-bit counter mode and an optional High Bandwidth Cipher for encrypting the data.

PUMA is the UMA engine (completely new for Windows Vista) running in the Windows Vista Protected Environment. PUMA also includes the same level of audio output protection management that is provided by Windows XP SAP, but it is done in a completely different way and takes advantage of the Windows Vista Protected Environment.

PAP is a much longer-term project that might aim to introduce encryption all the way to audio codec chips. It would have significant audio hardware implications, and would take years to do. Even though it is a long way in the future, it is good to start thinking about possibilities now.

1. Additional Resources

• 
  PVP-OPM and PVP-UAB: use PVP@microsoft.com
  
• 
  PUMA and PAP: use PUMA@microsoft.com
  
• 
  Windows XP COPP information:
  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/graphics/hh/graphics/dxvaguide_6bdc2bbd-b55a-44e1-9e6b-638589e319f1.xml.asp
  
• 
  Related WinHEC 2005 sessions
  

• 
  Protected Media Path and Driver Interoperability Requirements
  
• 
  Windows Audio/Video Excellence Requirements in Longhorn
  
• 
  High-Fidelity Audio from Integrated Audio Components
  
• 
  Windows Graphics Overview
  

2. Acronym Reference