Re: Comments on draft opinion on EME

Hi Sergey,

Thanks for your responses. I've added some follow-up comments below.


On Tue, Aug 19, 2014 at 12:18 PM, Sergey Konstantinov <twirl@yandex-team.ru>
wrote:

> Hi, Mark.
> Thank you very much for your comments.
>
> 19.08.2014, 20:13, "Mark Watson" <watsonm@netflix.com>:
>
> Dear TAG,
>
> I read the draft opinion on EME [1] and have a few comments:
>
> (1) It is certainly the intention that the websites, not the CDM, performs
> user authentication and authorization in the usual ways websites do. If
> this isn't clear, we should make that clearer in the specification
>
> (2) Whilst the primary purpose of the Content Decryption Module is indeed
> "decryption", there are a number of additional functions it has to perform
> to order to be able to do the decryption.
> - first, it has to receive the decryption keys. Since one objective is
> often to keep these keys secret, some secure protocol is needed to do this
> and this is the purpose of the opaque message exchange - mediated by the
> website - between CDM and a server side peer.
>
>
> I strongly disagree. There is absolutely no need in any kind of opaque
> message exchange since assymetric cryptography exists. You may transfer
> session keys transparently, and I will strongly object against inventing
> "secret" protocols.
>

​I did not say it was in principle *necessary* for a message exchange to be
opaque to deliver keys securely, since as you say things such as asymmetric
cryptography or key wrapping exist. I said this was the purpose of the
​opaque message exchange in EME.

We are not proposing to invent any new secret protocols - in fact we have
placed the design of that protocol out of scope for our work precisely
since we wish to be able to support existing protocols used by the existing
DRM systems. I understand the desire for an open standard protocol here and
that is discussed below.


>
>
>
> - second, there is the question of "robustness" (for example, see [2]) -
> which I will return to in more detail below - which often necessitates
> authentication and authorization of the CDM itself (as distinct from the
> user). Again, this is achieved through the opaque message exchange.
>
>
> Again, the only thing that must remain hidden is private session key, and
> that's solely the responsibility of the CDM itself, so there is no need to
> address this issue in a spec.
>

​I don't know what you mean by "session key", could you clarify ?

In any case, the specification only goes as far as providing a
communication path between CDM and its server-side peer. We explicitly want
to avoid the need for any direct communication between CDM and its peer
(i.e. we do not want to have to give the CDM network access).


>
>
> - third, compliance to the robustness rules - again, see below - often
> implies restrictions on what can be done with the media subsequent to
> decryption. The CDM is expected to take care of this, for example handing
> off to a media pipeline that is also compliant to the robustness rules or
> performing decoding and possibly rendering itself.
>
> A "license" is exactly the information needed to provide the CDM with the
> decryption keys and conditions regarding their use. Since the license
> contains the decryption keys, the processing of the license needs to be
> within a component subject to robustness rules and we have placed all such
> functions with the CDM. Perhaps the CDM is mis-named ?
>
>
> CDM is obviously misnamed, but that's not the problem. The problem is
> proprietary format of license. I'd prefer to have open and transparent
> format since (a) it decreases risks of exploiting possible vulnerabilities
> in decryption module; (b) I don't really understand why "conditions
> regarding their use" shall be kept in secret.
>

I share your preference, but I do not know how to acheive that.


>
>
>
> (3) There seems to be some mis-understanding in the opinion about the
> relationship between CDM and CDN (for example, reference to a "secure
> channel" between CDM and CDN). We don't make any assumption about how the
> content is obtained, nor do we assume there is per-playback decryption key.
> In particular, the content key may be fixed for a given piece of content
> with the same key used for all playbacks for all users, such that the
> content can be stored and served from a regular web server.
>
>
> Well, I could imagine non-secure connection between CDM and CDN, but I
> will object against that on another basis: we should encourage encryption
> of any channel possibly providing sensitive information, including what
> people are watching or listening.
>

​There is no connection between CDM and CDN. The CDM should not be given
network access (and should ideally be sandboxed ​in other ways as well).
The content is obtained by the video element in the usual way the video
element obtains content (from a URL, from Media Source Extensions) and
passed to the CDM by the video element.


>
>
>
>
> (4) There is a very substantial difference architecturally between the
> MediaKeys object defined by EME and the CryptoKey object defined by
> WebCrypto. At the very least it is not reasonable to say that MediaKeys is
> "already defined" by WebCrypto without any analysis to back up the
> assertion. MediaKeys represents a collection of communication sessions
> within the scope of which licenses, containing keys and other information,
> may be securely delivered to the CDM - keys are just one part of this.
>
>
> Agreed, this thought is inaccurately explained; my intention was to say
> that we should encourage transferring as much functionality as possible to
> WebCrypto because (1) that certainly decreases risks of exploiting possible
> cryptographic algorithm implementations vulnerabilities, (2) that makes
> probing and security testing those algorithms not a subject of
> anti-circumvention law.
>
>
>
>
> (5) Regarding the three questions in the Interoperability section, it is
> worth considering how the answers to these change as a result of the
> introduction of EME (i.e. compared to the status quo):
>
>
>    1. I am an indie studio; what should I do in order to have my content
>    protected by popular DRM systems?
>
> *Today*: You will need to choose a plugin (Silverlight, Flash, develop
> your own), choose a DRM vendor (perhaps dictated by choice of plugin)
> develop or buy player code for that plugin, obtain a license from the DRM
> vendor and deploy license servers.
> *With EME*: For coverage across all browsers, you will require licenses
> and (back end) license servers for multiple DRMs, but otherwise you are
> developing in HTML5, not using plugins.
>
>
>    1. I am an indie browser maker; what should I do in order to make my
>    browser capable of using popular CDMs?
>
> *Today*: You need to support NPAPI plugins (with the associated security
> and privacy disadvantages for your users)
> *With EME*: In general, you will need to choose a DRM vendor, license
> their client-side component and integrate this component with your video
> element implementation. On some platforms - for example Windows - CDM
> functionality may be available through platform APIs so you could simply
> use those APIs to expose that functionality through your video element.
>
>
>    1. I am an indie DRM vendor; what should I do in order to make
>    browsers support my CDM?
>
> *Today*: You could package your DRM into an NPAPI plugin and try to
> persuade sites to use it
>
> *With EME*: You will need to negotiate with each browser vendor to
> persuade them to integrate your DRM.
>
> Note that it is not an objective of EME to make life easier for those
> using DRM, for DRM vendors or for UA implementors. The objective is to
> provided continued support for DRM in the absence of plugins, with
> consequent improvements to user security and privacy.
>
>
> I'm not convinced that these alternatives are better then current
> situation. My concern is that implementing EME will lead to predominance of
> several large content providers, browser vendors and DRM makers on the
> market and to splitting the Web into several closed ecosystems.
>

​I don't think anyone has claimed that the EME situation is better ​for DRM
vendors, studios or UA implementors than the plugin situation, except
insofar as content providers benefit when the user experience for their
customers is improved.

The general demise of plugins does indeed disadvantage small UA
implementors. Arguably, it also disadvantages web developers who are losing
an easy-to-use way to deploy their services. Despite this, the desire to
deprecate plugins is strong, and with good reason. I think everyone would
welcome ideas as to what to do about these things.

I don't follow how EME will "split the web into several closed ecosystems".
Could you explain ?


>
>
>
>
> (6) Alternative
>
> We already have open standard encrypted media formats [3]. It is the
> license / key exchange that remains proprietary. I am not sure I follow how
> the proposed alternative would work, but at a high level I see two
> components to it:
> (a) the idea of an open standard (presumably RF) for the license format
> and license delivery protocol
> (b) an architecture that permits implementation of this in JS using
> low-level primitives such as WebCrypto CryptoKey objects, system key store
> etc.
>
> Regarding (a), such a thing would obviously be welcomed by many people but
> it is my understanding that the IPR landscape in this area is such that
> this is a real challenge. At least, noone that I know who is familiar with
> the IPR thinks this can be done, so you would at least have trouble getting
> such people to invest time in the development of such a solution. One of
> the important things included with any license to DRM technology is
> indemnity with respect to the IPR held by various NPEs. Not a pretty
> situation, but that's the way it is.
>
> Regarding (b), the principle challenge is robustness. One of the things
> the proprietary solutions do is to provide a way for the CDM to attest to
> its robustness, so that the sender of the license has some confidence as to
> exactly what will be done with it - i.e. what code is going to receive it
> and what robustness rules that code complies to.
>
> Regarding the specific proposal, the CDN generally does nothing more than
> serve a flat encrypted file, so I don't understand the involvement of the
> CDN in the described procedure.
>
>
> Well, in my view current DRM systems are just doing something wrong. The
> easiest way to implement DRM is just (a) serving a CDN <-> CDM connection
> using secure connection (https for example), (b) keep private key secret.
> There is no need in any proprietary algorithm or exchange format *at all*,
> and I will be very happy if such alternative spec is developed.
>

​Please see the points above about avoiding direct network access from the
CDM.​

IIUC, though, your point is that it is not necessary for the algorithms to
be secret in order to achieve the security objectives. This is of course
true - none of the existing systems rely on obscurity for their security
properties and there are in fact open source DRM systems, though none have
found wide deployment AFAIK. But this doesn't address my points above.

Let's say, for the sake of argument, that we could implement an open DRM
key exchange protocol using WebCrypto primitives. Suppose there is a
WebCrypto CryptoKey object that represents a key pair stored within the CDM
and we simply encrypt the content key to that key pair, so we can be sure
the content key is only visible inside the CDM [This ignores a bunch of
functional requirements, but is sufficient for my argument].

If I implement and use such a scheme, the first problem I have, (a), is
from whom can I obtain IPR indemnity ?

The second problem I have, (b), is how will I know that the public key sent
to the server is indeed one half of the key pair the private key of which
is stored only within the CDM, to some known level of robustness ? How do I
know what the CDM is and what it will do with the content following
decryption ?

If you have answers to these questions, then we may be on our way to a
fully open solution. But in the meantime, the objective of EME is to
provide a cleaner and more constrained way to encapsulate the existing
proprietary solutions within browsers than plugins.

...Mark



>
>
>
>
> Best regards,
>
> Mark Watson
>
>
>
> [1] https://github.com/w3ctag/eme/blob/master/EME%20Opinion.md
> [2] http://www.microsoft.com/playready/licensing/compliance/
> [3]
> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/initdata-format-registry.html
>
>
>
> --
> Sergey Konstantinov
> Yandex Maps API Development Team Lead
> http://api.yandex.com/maps/
>
>