Re: Some comments on the draft TAG EME paper

What Henri says is accurate. I have just two comments to add below ...


On Fri, Feb 28, 2014 at 3:43 AM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:

> On Fri, Feb 28, 2014 at 2:25 AM, Mark Watson <watsonm@netflix.com> wrote:
> > - This may not be material here, but it is not proposed to include EME in
> > HTML proper. It's a separate, optional, extension specification.
>
> That indeed doesn't seem material.
>
> > "If a user is authorised to access a piece of content, they must be able
> to
> > do so on a platform [browser, operating system, hardware] of their
> choice."
> >
> > We have a situation - like it or not - where the licensing terms for some
> > content constrain the platforms on which it may be viewed. So a user
> cannot
> > even become "authorised to access a piece of content" unless their
> "platform
> > of choice" is within that specific set.
>
> In other words, DRM involves a cryptographically attested form of UA
> sniffing in order to cater for intentional incompatibility and it's
> likely illegal for the victim to take countermeasures by faking its
> identity. (As seen in
>
> http://blogs.msdn.com/b/ieinternals/archive/2014/02/19/internet-explorer-and-everybody-else-version-lies-for-compatibility.aspx
> , countermeasures are often necessary and often taken when allowed.)
>
> > "Creating content that can only be used on a particular platform limits
> the
> > lifetime of that content. Content with a limited lifetime is contrary to
> the
> > best interests of consumers of that content.
> > "
> > There is an assumption here that the content is naturally persistent in
> some
> > way.
>
> It seems to me that many opinions related to EME are based on
> assumptions that don't hold for the primary use case of EME (i.e.
> streaming in general and on Netflix in particular). That is, opinions
> tend to often assume a model where there's a single file per title (as
> opposed to multiple fragments of content assembled by a JS program
> using MSE) and even that the file is sold to the user to hold onto (as
> opposed to the data existing on the client device only ephemerally
> when playback is invoked on a streaming site where access is sold on a
> time window basis).
>
> > It has always been clear that the main purpose of EME is to provide a
> common
> > API for DRM systems.
>
> Indeed.
>
> > In fact the encryption technologies specified by EME *are* platform
> > independent and even DRM-independent. The Common Encryption specification
> > for ISO files specifies exactly how the content is encrypted and there is
> > nothing proprietary about that.
>
> For completeness:
>
> 1) Since the W3C doesn't generally reference media format normatively,
> the EME references to CENC and WebM crypto are not normative. However,
> it's fair to expect that most EME deployments will likely use CENC, as
> that's already seen as shipped and deployed. Still, EME leaves
> available the option to have DRM-dependent encryption formats. Such
> formats aren't just theoretical, since, AFAICT, iTunes movie rentals
> use non-CENC DRM packaging in the MP4 container.
>
> 2) Even though the actual media data in CENC files is DRM-independent
> (and the possibility to define something like Clear Key theoretically
> makes whether a file is DRMed at all not a property of the file
> itself[1]), CENC headers are DRM-dependent. That is CENC packaging
> involves Protection System Specific Header (PSSH) boxes. So the file
> is DRM-independent except for its headers. However,
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24027 has potential to
> yield a general-purpose PSSH format, so, in theory, CENC files could
> become truly DRM-independent in the future if CDM vendors decide to
> support the upcoming Clear Key PSSH format for their proprietary DRM
> Key Systems.
>
> > As it stands, the statement is like insisting that <object> be
> > platform independent - i.e. that <object> ensure all plugins are platform
> > independent.
>
> Indeed.
>
> > It is straightforward to imagine, for example, that WebCrypto might
> provide
> > the primitives necessary to implement a DRM key exchange protocol in
> > Javascript. For such a thing to meet robustness requirements, the
> > implementation of the cryptographic primitives would need to be within
> some
> > kind of Trusted Execution Environment.
>
> (Other readers of www-tag may want to read
> http://www.openvirtualization.org/open-source-arm-trustzone.html as an
> intro on the TEE topic.)
>
> > To ensure platform independence, this
> > TEE and its robustness requirements would need to be standardized and
> > present on all platforms, but this is likely not possible in Free
> Software,
> > for example. Furthermore, some mechanism would be needed for this TEE to
> > attest to its properties, meaning inclusion of secret keys from some
> > authority that vets the TEE implementations / deployments. Essentially,
> this
> > idea exports several of the properties / requirements of DRMs into the
> > WebCrypto implementation.
>
> Indeed. To avoid that, the JavaScript program should refrain from
> using Web Crypto and should instead implement the necessary algorithms
> itself in an obfuscated form.
>

There may eventually be solutions along these lines, but we are a long way
from even being able to form opinions on feasibility.

Existing solutions based on software obfuscation bundle decrypt and decode
within the obfuscated code. Additionally, the technology available for
obfuscation of compiled code is much more advanced than for Javascript.
There is a long way to go before we could get to a solution that is both
performant and robust.


>
> > We have advocated support for this kind of thing
> > in WebCrypto,
>
> The use cases stated in the KeyWrap proposal indeed seem to duplicate
> use cases that one would expect an EME Key System to address, as noted
> in
> http://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Oct/0013.html


I know that I owe you a response on that thread.

The issue is not key wrap but pre-provisioned keys (key wrap has
applications without pre-provisioned keys).


>
>
> > but it seems only relevant to certain kinds of embedded
> > platform, not the web generally.
>
> Indeed. So why advocate it then?


The web platform is used in many situations, not only in general-purpose
web browsers. It seems reasonable to standardize extensions to the web
platform in W3C, wherever those extensions are intended to be used.


> Is the purpose of the KeyWrap
> proposal to enable Netflix to have DRM without a device
> vendor-provided EME CDM on systems that are Tivoized so that it's
> possible to reason about the characteristics of the software running
> on the device from a device identity attestation coupled with prior
> knowledge about promises made about the nature of the software and
> future software updates by the device vendor? Why wouldn't vendors who
> are willing to Tivoize their devices, provide identity attestation
> keys and make promises about the nature of future software updates not
> include a CDM while at it?
>

Those were long questions, but the answers are "no" and "no reason".

The reason pre-provisioned keys are useful on such devices has more to do
with the complexity of the supply-chain for those devices which dilutes the
value of the attestation provided by the CDM (i.e. that attestation is
restricted to CDM properties).

...Mark



>
> > One could further imagine that WebCrypto support a mode in which the
> output
> > of decryption operations is some handle to the data, not the data itself
> and
> > that there are media APIs which can accept such handles as a source of
> data
> > for playback. The same TEE that contains the WebCrypto primitive
> > implementations would provide the underlying support for these media APIs
> > and decode and render the media. This begins to look less like exporting
> DRM
> > properties into WebCrypto and more like simply bringing WebCrypto into
> the
> > DRM "black box".
>
> And, more to the point, as noted, it would not be just Web Crypto but
> also parts of the media stack. Going this route instead of the route
> that has a clear User Agent / CDM split could easily lead to a
> situation where the simplest solution is to let the whole browser fall
> into the DRM box instead of trying to maintain a separation between
> the parts of the browser that are in the DRM box and the parts that
> aren't. As long as the TAG can concerns about browsers becoming
> subject to anti-circumvention, the TAG should not advocate paths that
> could easily lead to the entire browser (engine) falling inside the
> DRM box.
>
> > there do exist open source DRMs.
>
> ...but the ones cited so far seem to have relied on Tivoization for
> robustness and, therefore, wouldn't work e.g. on the existing desktop
> systems.
>
> [1] Schrödinger's CENC file has both PlayReady and Clear Key PSSH
> boxes, so the file is DRMed and not DRMed at the same time. In other
> words, the DRMness depends not on the file but on the conditions under
> which the key is provided.
> --
> Henri Sivonen
> hsivonen@hsivonen.fi
> https://hsivonen.fi/
>