[linux-elitists] MS Secure Audio Path Model/MS DRM OS Patent

Ruben Safir ruben@mrbrklyn.com
Wed Jan 2 20:50:22 PST 2002

>From nyfairuse -----

On 2002.01.02 23:34:29 -0500 Seth Johnson wrote:

(Adam Warner forwarded the following link [watch the word
wrap], with a discussion of the ramifications of MS's Secure
Audio Path technology and DRM OS patent.  What strikes me in
particular about this development is that whereas I had been
suspecting that all the recent talk of "security" would
translate into content control, that connection has already
been implemented in the recent MS OS releases. -- Seth)


(Following are the first two posts in the thread:)

From: Adam Warner (usenet@consulting.net.nz)
Date: 2001-12-11 02:18:23 PST 


I've just been familiarising myself with this. Basically
it's designed to allow content producers to stop anyone
having access to an unencrypted audio stream. You almost
certainly couldn't achieve this on an open source operating
system (no access to /dev/dsp?[1]) so it's very interesting
to see the lengths Microsoft is going to make this a reality
under Windows.

You may not be aware that every audio driver included with
Windows XP and Windows ME are Secure Audio Path signed and
certified by Microsoft (I'd forgotten about that after
reading about it in a Wired article a while ago that was
concerned about the power this could give to Microsoft).

   Drivers included with Windows Millennium Edition and
Windows XP are certified as SAP-compliant.

This kind of driver design--where you ultimately encrypt
content all the way to the low level sound card drivers
themselves--indicates to me that Microsoft's talk about
shared source has very little in common with open source.
The level of control being implemented here is
extraordinary. If you look at the SAP model from the link
you'll see the content only becomes unencrypted at the
kernel and system level (there's a small exception to
provide very poor quality sound to manipulate for visual
display[2]). Apps like a graphic equaliser will not work[3].
You don't want anyone else having the ability to manipulate
kernel/system level functionality. And I suspect you'd want
binary only audio drivers as well.

I thought I'd share a funny quirk about the implementation.
One part of the implementation is a Driver Security Level:

   Driver Security Level

   Each SAP-compliant audio driver has a security level and
content owners can specify the minimum security level a
driver must have to play their packaged files.

Well if you click on the "Next" link you'll see the current
definition of these security levels. That's right. Content
can be prohibited from running on Windows ME (that will run
on Windows XP) by setting a required security level greater
than 1100!


[1] It would at least require high levels of developer
complicity. And when you see the lengths Andre Hedrick
(Linux IDE guru) when to in fighting CPRM such levels of
support would be unlikely.


Linux Journal appears to be down right now. This is the
Google cache of the Q&A:

[2] Some applications are used to view a music signal. For
example, some applications display flashing lights in time
with the music signal, but do not modify it. To accommodate
the use of such applications, a small part of the music is
decrypted and passed in clear form with the encrypted
content. The resulting signal is very poor (worse than
telephone quality) but suffices for applications used to
view signals.

[3] In the Secure Audio Path model, applications cannot be
used to modify packaged music in any way. For example, when
an application is used to intercept a music signal, the
signal sounds like random noise. As a result, applications
used to modify signals (such as an equalizer) cannot change
the sound of the music.

From: Adam Warner (usenet@consulting.net.nz)
Date: 2001-12-13 13:18:24 PST 

My discussion of this was timely. It became widely known
today that Microsoft have secured a patent on a Digital
Rights Management Operating System:


Covered here:

An observant person noted this in the description:

   A fundamental building block for client-side content
security is a secure operating system. If a computer can be
booted only into an operating system that itself honors
content rights, and allows only compliant applications to
access rights-restricted data, then data integrity within
the machine can be assured. This stepping-stone to a secure
operating system is sometimes called "Secure Boot." If
secure boot cannot be assured, then whatever rights
management system the secure OS provides, the computer can
always be booted into an insecure operating system as a step
to compromise it.

Imagine if current computer hardware was redesigned so that
it could only boot a (Microsoft) Digital Rights Management
Operating System.


New Yorkers for Fair Use -
because it's either fair use or useless....

Brooklyn Linux Solutions
http://www.mrbrklyn.com - Consulting
http://www.brooklynonline.com - For the love of Brooklyn
http://www.nylxs.com - Leadership Development in Free Software
http://www.nyfairuse.org - The foundation of Democracy
http://www2.mrbrklyn.com/resources - Unpublished Archive or stories and articles from around the net
http://www2.mrbrklyn.com/mp3/hooked.mp3 - Spring is coming....
http://www2.mrbrklyn.com/downtown.html - See the New Downtown Brooklyn....


More information about the linux-elitists mailing list