This section examines the components in the PUMA engine concerned with security.
Aside from the Virtual Audio Server (VAS) receiving component, the PUMA architecture includes three protection-related component types of interest:
Virtual Protected Output (VPO) module
Protected Output Controller (POC)
Output Encryption Audio Processing Object (APO)
For simplicity, sometimes the entire collection of software is referred to as the POC software.
The PUMA protection components are written to operate a specific type of output protection system—for example, something as simple as S/PDIF Serial Copying Management System (SCMS), or something more complex involving key exchanges, authentication of hardware, digital certificates, and so on. The audio output itself can identify the appropriate POC software to load.
When the audio system loads and initializes for a particular output, it queries the audio output to find the required POC module. Audio policy (that came from the MIG) causes the POC object to load. The POC can now communicate directly with the audio device through the user-mode audio EndPoint object.
The POC uses an IKSControl interface exposed from the audio system’s standard KsRenderEndpoint user-mode object, which abstracts KS audio drivers. KS methods, properties, and events are defined specifically for the particular type of protection system.
The POC can also call an audio constrictor to reduce an audio signal’s sample rate, bit-rate, or both to meet content owner’s requirements. This can be used to reduce the information content of the signal by performing downsampling followed by upsampling. The actual output format is kept the same, but the audio will now be slightly fuzzy with less detail.
PUMA Driver Authentication
In the same way that the PUMA was authenticated before receiving premium content, the PUMA engine needs to authenticate the driver. This authentication is done by the POC module.
Authentication of the driver is accomplished by putting a key pair and certificate in the driver. Often the driver is a Windows UAA class driver, but it can also be a third-party driver. Users of a Windows class driver avoid the hassle of obtaining a license.
The key pair in the driver can also be used to establish a verified OMAC channel between the POC and the driver, and this can be used for both commands to the driver—for example, to turn off a particular output—and status back to get the driver to signal that the output has been turned off.
The key pair in the driver needs to be protected with obfuscation, so that the secret cannot be snooped when the Protected Environment is not in high-security mode.
As with PVP, it is necessary to sign a license agreement—in this case, a PUMA license—to get a driver certificate. The license agreement attests that the implementation meets the compliance rules. There is no requirement to sign the license; but without a certificate, no premium content will be passed to the driver.
Windows XP audio drivers will work on Windows Vista; however, for playing premium content, a new driver is required for Windows Vista. PUMA will check for the presence of a certificate before passing premium content to the driver.
Output Encryption APO
The Output Encryption APO is the module that will provide encryption of the audio data, if it becomes necessary in the future. For the initial release of Windows Vista, it is planned that just the interfaces to the module will exist, rather than any actual modules.
The planned implementation is that the audio system will request an Output Encryption APO from the POC. The audio policy will set up the audio engine such that the Output Encryption APO will be called as the last processing element for the audio data, before the data is passed to the driver. This allows the Output Encryption APO to encrypt the data according to the current protection policy. The POC will choose to not load an Output Encryption APO if encryption is not necessary (which it isn’t in 2006).
Virtual Protected Output - VPO
When an instance of MIG renders a protected stream, the audio policy will command the POC to create a VPO for that client. The purpose of the VPO is to contain the policy for the associated client. As VPOs are created and destroyed, and policies are set on them, the POC recalculates a resultant aggregate protection policy from all of the VPO policies. The POC is able to advise the hardware of the content policy through the same communication mechanism established when the POC was first loaded.
The VPO is the direct equivalent of the PUMA OTA that resides in the MIG, but the VPO runs in the PUMA process.
There are different variants of VPO for each output protection type. For the initial release of Windows Vista, the plan is for just one type, that is, the one designed to give SAP-equivalent protection with a few extra protection features.
Automatic Echo Cancellation: AEC
Automatic echo cancellation (AEC) is important in real-time communication scenarios and requires a reference signal from the output of the final mix to be passed up into the unprotected application environment. When premium content is playing, it is necessary to heavily constrict the resolution of this signal so as not to provide a worthwhile stealing mechanism for hackers.
The output from the global mix is passed through a licensed constrictor component to dramatically reduce its information content to a level that is not worth stealing, but is just about sufficient for AEC to work.
Audio Mix
With audio, there is always a mix going on. Most of the time it is just the simple situation of playing error sounds or providing notification of a phone call while playing back a movie.
The mix happens in the signal processing core of the audio engine, in user mode. It is the mixed signal that travels down to the hardware to play.
Inherent in the concept of an audio mix is the concept of a policy mix. The rules are simple—the policy that applies to the resulting mix is governed by the audio that has the most restrictive policy. For example, if the policy from one piece of audio A says S/PDIF must be turned off, and another piece of audio B says that the maximum sample rate allowed over S/PDIF is 48 kHz, then the policy for the mix will specify that the S/PDIF output must be turned off.
Mixes are, of course, dynamic. In the previous example, when piece of audio A is faded out (its volume goes to zero), then the system is now suddenly able to turn the S/PDIF output back on. Initially the S/PDIF would need to be constricted to 48 kHz; but when audio B is faded out, then the S/PDIF output no longer needs to be constricted, and other sounds would be able to play at 96 kHz or above.
Policy information is a stream just like the actual audio data is a stream. The two streams follow different paths through the system, but a reasonable degree of synchronization must be maintained between the streams.
That example might seem too extreme, but handling dynamic policy is the norm on a PC: When you first turn on a PC, the audio engine plays the Windows wake-up sound; the policy for this is completely unrestricted. When you launch an online subscription jukebox service, the policy from the service is applied, and that policy can change from tune to tune. When you pop in an HD-DVD or Blu-Ray DVD, the policy changes again. Finally, when you return to your desktop to shut down your PC, the policy restrictions are removed, and you hear the Windows shut-down sound.
Windows XP SAP vs. PUMA
Windows XP includes a mechanism for protecting the rendering of audio content. The capability was introduced in response to requests from content owners, but it is not believed that any content actually requires Secure Audio Path (SAP) protection. As of April 2005, no released third-party applications turn on this functionality. Content owners might decide to turn on SAP protection in the future, particularly to protect music downloaded from audio subscription services.
In some of recent attacks on Windows XP to try to steal audio content, it has been found that the SAP functionality would have prevented these attacks if the content had turned on the SAP feature. However, no one tries to crack a content-protection scheme if there isn’t any content protected by that scheme. Since there isn’t any SAP content, it has not had to withstand a barrage of attacks.
SAP is designed for the current Windows XP kernel-mode audio rendering system, and it will not work for the new Windows Vista audio architecture.
The MSDN web site presents a notice on all the pages that relate to SAP, indicating that the functionality provided by SAP will be done differently in future operating systems— which of course means Windows Vista, where the new mechanism for protecting audio content is PUMA.
No content protection scheme can be 100-percent secure, but the new PUMA architecture provides what we believe to be a better mechanism. The Protected Environment makes life easier for third-party applications that play premium audio content. PUMA also provides the protection that content owners require.
In Windows Vista, the SAP API will be stubbed out. Calling the API will not cause an application to crash, but a "Not Implemented" message will be returned from the call. Even though the SAP API will not be used in Windows Vista, the DDI used to talk with drivers will be fairly similar.
HDMI Audio on the PC
HDMI audio is going to be interesting in the PC world. At first glance, the addition of audio to the wire going to the display seems simple enough. The problem is that in the PC architecture, audio and video are rendered by very separate processes. The video software stack is very different from the audio software stack.
|
|
It is hard from a hardware perspective, too. Because of the technical complexity of the multiplexing of the audio into the video blanking intervals, it is not possible to just use Y-shaped cables to combine the audio and video—it is necessary for the audio to originate from the same circuit board as the video. This is hard when considering a discrete graphics card.
The problem is if graphics cards are going to have HDMI connectors, where will graphics cards get the audio from? With the advent of HDMI, an interesting PC ecosystem adjustment will happen. Graphics manufacturers will need to get into the audio business.
What will happen is that discrete graphics chips will need to have a UAA-compliant audio solution, such as an HD Audio controller on the same chip as the graphics. They will likely use both a vendor-supplied graphics driver and the Microsoft-supplied UAA HD Audio class driver.
Motherboards with integrated graphics and integrated audio that both use a single HDMI connector will be a popular configuration. When the user chooses to upgrade by adding a more powerful 3D discrete graphics card, then the user will have a system with two HDMI connectors.
Audio Content Protection with HDMI
The situation gets more complicated when the right things must happen with HDCP content protection. On the PC, HDCP protection is controlled by the video stack, and it is difficult to find a robust way for the audio stack to request that protection be turned on. The problem is not how to do it, but rather how to make it resilient against hackers inserting themselves in the path and turning it off again.
The problem manifests itself only in the case of premium audio accompanied by non-premium video. For example, for HD-DVDs or Blu-Ray DVDs, it is not a problem, because premium audio is always accompanied by premium video, so the video stack will always have already turned on the HDCP protection. Because the audio is carried by HDMI in the blanking intervals, the audio automatically gets protected when the video on that HDMI connector is protected.
Another problem is that as the HD Audio specification was originally written, the audio for HDMI just looks like an S/PDIF codec. Unfortunately, different content protection rules apply to S/PDIF compared with HDMI. As soon as there is a new connector type, new rules apply. It is not allowed to expose an HDMI audio codec as an S/PDIF codec. There are some concessions that apply to S/PDIF, so as not to obsolete overnight all the existing AV receivers; but those concessions don’t necessarily apply to audio over HDMI.
With S/PDIF, it is likely that content industry agreements in 2006 will allow compressed digital audio to be sent over an S/PDIF connector in unprotected form. This concession may go away in a few years, but it is still useful. For HDMI, there is uncertainty as to whether the Content Industry Agreements in 2006 will allow unprotected digital audio. It might be that HDCP is required.
It might be that the HD Audio specification gets modified (through the formal Engineering Change Request committee process), to allow HDMI audio codecs to be differentiated from S/PDIF codecs. That change process would take time though, and then it would be a while after that for hardware manufacturers to incorporate the changes. The solution must target the hardware that will be available in 2006.
Because there is currently no HD Audio specification amendment to provide a new HDMI codec type, Microsoft is considering adding to the audio class driver the robust ability to identify the S/PDIF codec being used for HDMI. This would be done using the one-to-one association between the HD Audio controller and a fixed-format S/PDIF codec. This approach is limited in that it would work only for the baseline HDMI audio mode—that is, 48-kHz 16‑bit stereo uncompressed audio. Even with that limitation, this approach would still provide a useful pragmatic way of supporting HDMI audio in 2006.
DVD-Audio
DVD-Audio is problematic with HDMI, because the premium audio is often accompanied by non-premium video. If the video is not premium content, then HDCP will not be turned on. Plans for Windows Vista do not yet include a robust way for the audio stack to request protection. DVD-Audio over HDMI will not be possible in the first version of Windows Vista. There is, however, no output protection problem with DVD-Audio being rendered from the high-quality analog audio outputs that are now common on motherboards, based on UAA-compliant HD Audio technology.
| 