Re: Comments on draft opinion on EME

On Tue, Aug 19, 2014 at 2:15 PM, Mark Watson <watsonm@netflix.com> wrote:

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


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

>From a technical point of view, I believe the only requirements are that a)
the decryption key is encrypted with a key known only to the CDM and b) the
CDM can verify that the related policies apply to that key (to prevent
applying policies from one license to another key, for example).

This could probably be accomplished using an open unencrypted license
format (i.e. JSON with a standardized schema) that contains encrypted
content key(s) along with a hash (using a secret key) that
cryptographically ties the policy to the key(s). Such a standardized format
would go a long way towards ensuring a consistent set of capabilities and
behaviors across key systems.



> 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.
>>
>
I think "CDN" should be "license server" in the above sentence (at least
when discussing the current EME spec). As Mark mentions, there is no direct
connection. However, the path through the application could be secured. You
may want to weigh in on this bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332

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



>  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.
>>
>
This is in theory possible. (It would also involve client-side certificates
since the server needs to trust the client instead of the other way around
as in most HTTPS connections.) However, due to the robustness requirements
and need to establish a trust relationship with the client, such a
connection would need to terminate in the CDM. That would mean pulling the
network stack into the CDM or extending the trusted execution environment
to the network stack.

Similarly, any attempt to use WebCrypto to do the decryption would require
pulling (that part of) the WebCrypto implementation into the trusted
execution environment. The EME/CDM design, on the other hand, restricts the
trusted execution environment to (part of) the media stack.