Re: Alternatives to DRM?

On Fri, Apr 12, 2013 at 6:29 PM, Jeff Jaffe <jeff@w3.org> wrote:
> DReaM [1] appears to indicate feasibility.  Whether a feasible solution is
> sufficiently practical for implementation (and sufficiently addresses the
> requirements of premium content use cases) arguably should be discussed in a
> Working Group.
>
> [1] http://en.wikipedia.org/wiki/Project_DReaM

DReaM is covered in footnote 198 of
http://wendy.seltzer.is/writing/seltzer-anticircumvention.pdf (PDF
page 46; journal page 956):
"This is the flaw in the purportedly “open source” model behind Sun’s
DReAM platform. Even if anyone can build an implementation of the
specification, it would win “authorization” to play protected content
only after proving its un-modifiability by others as a prerequisite to
obtaining permission. Developers writing such code would be unable to
comply with the downstream “freedom to modify” condition of the Free
Software Foundation GPL. Cf. Gerard Fernando, Tom Jacobs & Vishy
Swaminathan, PROJECT DREAM, AN ARCHITECTURAL OVERVIEW (2005),
http://www.openmediacommons.org/collateral/DReaM-Overview.pdf."

The footnote is attached to the sentence:
"Anticircumvention provides the hook by which to demand some DRM, and
no matter how open the process by which the DRM standard was
developed, devices implementing it will have to be closed."

(Thanks to Andreas Kuckartz for locating the footnote.)

I very much recommend the above journal article to everyone on this
mailing list. (Especially the second half for those who are too busy
to read the whole article.)

On Fri, Apr 12, 2013 at 7:34 PM, Mark Watson <watsonm@netflix.com> wrote:
> There is an open source implementation of OMA DRM:
> http://sourceforge.net/projects/openipmp/

This project seems dead, appears to have relied on Tivoization for
robustness and itself comes with warnings about royalties.

> However, we should be clear that this and any other open source DRM is
> likely still going to require license fees (to people not present in the
> W3C) and will be subject to robustness rules that require techniques to be
> used that make user-modification difficult (making it incompatible with
> GPLv3, but nevertheless still open source).

Indeed.

"Can the client side implementation of a DRM scheme be open source?"
is not a particularly good question, since it's too easy interpret it
as "Is it logically possible to design the client side implementation
of a DRM scheme so that its preferred form for making modifications
can be disclosed?"

The answer to that question is: In theory, yes for the case where
pixel and PCM output is not subject to robustness rules if the build
process takes not only the disclosed preferred form for making
modifications as its input but also takes randomness as its input and
the randomness is used to generate an asymmetric key pair whose
private key is embedded in the build output and the randomness is used
to give random values to obfuscation parameters of a compiler that is
able to obfuscate its output such that the private key is extremely
difficult to locate among the output and the runtime data structures
of the resulting program are also made inscrutable.

Then the build could be performed by a non-user entity trusted by
Hollywood not to lie about how the build was performed and a trust
root could sign the public key of the key pair whose private key was
embedded in the binary to certify that the binary came from the right
kind of build process, so servers handing out content keys could rely
on the certification in order to believe that client side
implementations in possession of a private key whose public key has
been certified has particular characteristics. However, if someone
else, e.g. an end-user, ran the build process, they'd end up with
different keys, which would render the build product useless assuming
that content providers targeted only keys that have been certified to
have emerged from a trusted entity performing the build.

(Also worth noting that the sort of compiler that the above
theoretical "yes" assumes would probably be harder to develop than a
compiler that could delegate part of the robustness to the secrecy of
the entire input to the compiler--not just of the values of
obfuscation parameters.)

If the pixel and PCM data is subject to robustness rules, too, then
you need a hardware-assisted implementation. If all
robustness-sensitive stuff goes on the hardware side, then, in theory,
the software driver could be trivial and entirely open (in the same
way as the Broadcom GPU "driver" for Raspberry Pi that just throws
stuff over the wall into a different realm of computing that's part of
"hardware" from the POV of the Linux kernel).

More relevant questions to ask would be:
"Can the end-user be allowed to build the client side implementation
of a DRM scheme from the preferred form for making modifications such
that the result is equivalent (in terms of being able to receive and
render content) to a build made by someone else?" and "Can the client
side implementation of a DRM scheme be royalty-free?"

The answer to the first question is no. DRM is premised on the user
being untrusted. If a user-built implementation of the client side of
a DRM scheme was allowed to receive and render content, it would
amount to trusting the user, which would contradict the premise of
DRM.

The answer to the second question is no *at least* as long as content
providers insist on using non-RF codecs and insist on high robustness
against the interception of decrypted codec data by the end-user. If
content providers insist on using non-RF codecs and don't allow the
decrypted codec data exit the client side DRM implementation in order
to go into an external decoder, the codecs have to be baked into the
client side DRM implementation rendering it as a whole non-RF
regardless of whether the DRM protocol and robustness techniques were
RF. (Yes, Windows allows an app to open an encrypted session with a
certified system decoder, but that feature is not available across all
platforms.)

--
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 22 April 2013 12:01:07 UTC