Technical Review of EME (DRM in HTML5)

I took some time this weekend to do a technical review of the Encrypted
Media Extensions (EME, aka. DRM in HTML5) specification.

   TL;DR: The Encrypted Media Extensions (DRM in HTML5) specification
   does not solve the problem the authors are attempting to solve,
   which is the protection of content from opportunistic or
   professional piracy. The HTML WG should not publish First Public
   Working Drafts that do not effectively address the primary goal of
   a specification.

The blog post can be found here:

http://manu.sporny.org/2013/drm-in-html5/

Full text is below:

   A few days ago, a new proposal was put forward in the HTML Working
   Group (HTML WG) by Microsoft, Netflix, and Google to implement
   [1]DRM in HTML5. This triggered an uproar about the [2]morality
   and ethics behind DRM and building it into the Web. There are good
   arguments about morality/ethics on both sides of the debate but
   ultimately, the HTML WG will decide whether or not to pursue the
   specification based on technical merit. I am a member of the HTML
   WG. I was also the founder of a start-up that focused on building
   a legal, peer-to-peer, content distribution network for music and
   movies. It employed DRM much like the current DRM in HTML5
   proposal. During the course of 8 years of technical development,
   we had talks with many of the major record labels. I have
   first-hand knowledge of the problem, and building a technical
   solution to address the problem.

The Problem

   The fundamental problem that the Encrypted Media Extensions (EME)
   specification is attempting to solve is to find a way to reduce
   piracy (since eliminating piracy on the Web is an impossible
   problem to solve). This is a noble goal as there are many content
   creators and publishers that are directly impacted by piracy.
   These are not faceless corporations, they are people with families
   that depend on the income from their creations. It is with this
   thought in mind that I reviewed the specification on a technical
   basis to determine if it would lead to a reduction in piracy.

Review Notes for Encrypted Media Extensions (EME)

Introduction

   The EME specification does not specify a DRM scheme in the
   specification, rather it explains the architecture for a DRM
   plug-in mechanism. This will lead to plug-in proliferation on the
   Web. Plugins are something that are detrimental to
   inter-operability because it is inevitable that the DRM plugin
   vendors will not be able to support all platforms at all times.
   So, some people will be able to view content, others will not.

   A simple example of the problem is Silverlight by Microsoft. Take
   a look at the [3]Plugin details for Silverlight, specifically,
   click on the "System Requirements" tab. Silverlight is Microsoft's
   creation. Microsoft is a HUGE corporation with very deep pockets.
   They can and have thrown a great deal of money at solving very
   hard problems. Even Microsoft does not support their flagship
   plugin on Internet Explorer 8 on older versions of their operating
   system and the latest version of Chrome on certain versions of
   Windows and Mac. If Microsoft can't make their flagship Web plugin
   work across all major Operating Systems today, what chance does a
   much smaller DRM plugin company have?

   The purpose of a standard is to increase inter-operability across
   all platforms. It has been demonstrated that plug-ins, on the
   whole, harm inter-operability in the long run. The one shining
   exception is Flash, but we should not mistake an exception for the
   rule. Also note that Flash is backed by Adobe, a gigantic
   multi-national corporation with very deep pockets.

1.1 Goals

   The goals section does not state the actual purpose of the
   specification. It states meta-purposes like: "Support a range of
   content security models, including software and hardware-based
   models" and "Support a wide range of use cases.". While those are
   goals, the primary goal isn't stated once in the Goals section.
   The only rational primary goal is to reduce the amount of
   opportunistic piracy on the Web. Links to [4]piracy data collected
   [5]over the last decade could help make the case that this is
   worth doing.

1.2.1. Content Decryption Module (CDM)

   When we were working on our DRM system, we took almost exactly the
   same approach that the EME specification does. We had a plug-in
   system that allowed different DRM modules to be plugged into the
   system. We assumed that each DRM scheme had a shelf-life of about
   2-3 months before it was defeated, so our system would rotate the
   DRM modules every 3 months. We had plans to create genetic
   algorithms that would encrypt and watermark data into the file
   stream and mutate the encryption mechanism every couple of months
   to keep the pirates busy. It was a very complicated system to keep
   working because one slip up in the DRM module meant that people
   couldn't view the content they had purchased. We did get the
   system working in the end, but it was a nightmare to make sure
   that the DRM modules to decrypt the information were rotated often
   enough to be effective while ensuring that they worked across all
   platforms.

   Having first-hand knowledge of how such a system works, it's a
   pretty terrible idea for the Web because it takes a great deal of
   competence and coordination to pull something like this off. I
   would expect the larger Content Protection companies to not have
   an issue with this. The smaller Content Protection companies,
   however, will inevitably have issues with ensuring that their DRM
   modules work across all platforms.

The bulk of the specification

   The bulk of the specification is what you would expect from a
   system like this, so I won't go into the gory details. There were
   two major technical concerns I had while reading through the
   implementation notes.

   The first is that key retrieval is handled by JavaScript code,
   which means that anybody using a browser could copy the key data.
   This means that if a key is sent in the clear, the likelihood that
   the DRM system could be compromised goes up considerably because
   the person that is pirating the content knows the details
   necessary to store and decrypt the content.

   If the goal is to reduce opportunistic piracy, all keys should be
   encrypted so that snooping by the browser doesn't result in the
   system being compromised. Otherwise, all you would need to do is
   install a plugin that shares all clear-text keys with something
   like [6]Mega. Pirates could use those keys to then decrypt
   byte-streams that do not mutate between downloads. To my
   knowledge, most DRM'ed media delivery does not encrypt content on
   a per-download basis. So, the spec needs to make it very clear
   that opaque keys MUST be used when delivering media keys.

   One of the DRM systems we built, which became the primary way we
   did things, would actually re-encrypt the byte stream for every
   download. So even if a key was compromised, you couldn't use the
   key to decrypt any other downloads. This was massively
   computationally expensive, but since we were running a
   peer-to-peer network, the processing was pushed out to the people
   downloading stuff in the network and not our servers. Sharing of
   keys was not possible in our DRM system, so we could send the
   decryption keys in the clear. I doubt many of the Content
   Protection Networks will take this approach as it would massively
   spike the cost of delivering content.

6. Simple Decryption

     The "org.w3.clearkey" Key System indicates a plain-text clear
     (unencrypted) key will be used to decrypt the source. No
     additional client-side content protection is required.

   Wow, what a fantastically bad idea.

    1. This sends the decryption key in the clear. This key can be
       captured by any Web browser plugin. That plugin can then share
       the decryption key and the byte stream with the world.
    2. It duplicates the purpose of Transport Layer Security (TLS).
    3. It doesn't protect anything while adding a very complex way of
       shipping an encrypted byte stream from a Web server to a Web
       browser.

   So. Bad. Seriously, there is nothing secure about this mechanism.
   It should be removed from the specification.

9.1. Use Cases: "user is not an adversary"

   This is not a technical issue, but I thought it would be important
   to point it out. This "user is not an adversary" text can be found
   in the first question about use cases. It insinuates that people
   that listen to radio and watch movies online are potential
   adversaries. As a business owner, I think that's a terrible way to
   frame your customers.

   Thinking of the people that are using the technology that you're
   specifying as "adversaries" is also largely wrong. 99.999% of
   people using DRM-based systems to view content are doing it
   legally. The folks that are pirating content are not sitting down
   and viewing the DRM stream, they have acquired a non-DRM stream
   from somewhere else, like Mega or The Pirate Bay, and are watching
   that. This language is unnecessary and should be removed from the
   specification.

Conclusion

   There are some fairly large security issues with the text of the
   current specification. Those can be fixed.

   The real goal of this specification is to create a framework that
   will reduce content piracy. The specification has not put forward
   any mechanism that demonstrates that it would achieve this goal.

   Here's the problem with EME - it's easy to defeat. In the very
   worst case, there exist piracy rigs that allow you to point an HD
   video camera at a HD television and record the video and audio
   without any sort of DRM. That's the DRM-free copy that will end up
   on Mega or the Pirate Bay. In practice, no DRM system has survived
   for more than a couple of years.

   Content creators, if your content is popular, EME will not protect
   your content against a content pirate. Content publishers, your
   popular intellectual property will be no safer wrapped in anything
   that this specification can provide.

   The proposal does not achieve the goal of the specification, it is
   not ready for First Public Working Draft publication via the HTML
   Working Group.

References

   1.
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html
   2. http://www.defectivebydesign.org/
   3.
http://www.microsoft.com/getsilverlight/Get-Started/Install/Default.aspx
   4.
http://www.dga.org/Craft/DGAQ/All-Articles/1001-Spring-2010/Internet-Issues-Piracy-Statistics.aspx
   5.
http://www.musicweek.com/news/read/effects-of-blocking-pirate-bay-short-lived-criticised-as-ineffective/049604
   6.
http://techcrunch.com/2013/01/19/mega-launches-its-cloud-storage-and-file-sharing-service-as-the-privacy-company-amid-a-huge-surge-of-interest/

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
President/CEO - Digital Bazaar, Inc.
blog: Aaron Swartz, PaySwarm, and Academic Journals
http://manu.sporny.org/2013/payswarm-journals/

Received on Saturday, 26 January 2013 16:29:51 UTC