Re: Alternatives to DRM?

On 4/22/2013 8:00 AM, Henri Sivonen wrote:
> 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.

I don't see a basis for the assertion that it would win "authorization" 
to play protected content only after proving its un-modifiability.  That 
might be true today, but where content owners are willing to compromise 
has changed over the years and could change again.  It is reasonable to 
explore DReaM-type solutions - and if we discover that they don't 
satisfy the use cases of content owners, then reject them.  But it is 
not reasonable to reject DReaM type solutions only because we fear that 
they would not be accepted by content owners.

>   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."

I'm not a legal expert, but I concede that my superficial understanding 
is that DReaM is incompatible with GPL3; although not with other open 
source licenses.

>
> 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 Tuesday, 23 April 2013 02:56:50 UTC