- Media providers may have to use the DRM system that Microsoft provides, since it has to be built into the kernel. If Microsoft lets people build their own DRM components, then there is the issue of misbehaving components and buggy kernel libraries.
- If you look at the diagram, the sound card driver is given full access to unencrypted data. This means that one could write a misbehaving third-party driver to capture streams. The SAP designers get around this by forcing the driver to be authenticated (see diagram). The DRM component is not "authenticated" though.
- The decryption now happens in the kernel. Let's hope that the decryption module is not buggy -- especially if Microsoft lets vendors write their own kernel modules for DRM. Not only could the player program crash, but this could cause the whole system to go down.
Will this protect DRM media from being copied? I doubt it. Academics (or benevolent hackers) will publish instructions on how to subvert all of this, then the script kiddies will pick up the proof-of-concept software to scrape the streams. I think the only way this can "solidify" enforcement of DRM is with ALL pieces in kernel mode being "authenticated" (proven safe by signature and cert. authority) or no DRM decryption should work. The problem with this is that the CA (probably a Microsoft database protected from subversion with Trusted Computing hardware) will have control over which modules are authorized -- essentially control over which flavors of DRM get to be used.
Is DRM really the right approach to protect artists' and publishers' copyright? Is this protected audio path a good idea? I don't know a whole lot about SAP (just reading the whitepapers for the first time), so I welcome others' opinions...