W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > February 2014

Re: Relationship of the Netflix KeyWrap proposal to EME

From: Henri Sivonen <hsivonen@hsivonen.fi>
Date: Wed, 19 Feb 2014 12:12:32 +0200
Message-ID: <CANXqsRKuCRu43_ZeP1r15=3eDjGAr=nGCEZY5sfz=pihFiqqYQ@mail.gmail.com>
To: public-webcrypto-comments@w3.org
On Thu, Oct 24, 2013 at 2:11 PM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:
>> The video provider's site establishes a secure
>> communication channel between the video
>> provider's page on the TV and the video
>> provider's servers, proving to the servers
>> that Ryan's TV is indeed one of those that
>> meets the security requirements by use of
>> the cryptographic key and identifier
>> pre-provisioned on the TV.
>
> It seems to me that this is the bread and butter of EME Key Systems.
> Since Netflix uses EME anyway, why is there a need to duplicate this
> via the Web Crypto API?

To expand on this:
When playback of a video is about to start, it is clearly the
responsibility of an EME Key System to ensure that the video doesn't
play unless the "security" (which I take mean DRM robustness)
requirements are met. It is weird to suggest that this would also be a
use case for the Web Crypto API--especially when Netflix is behind
both the EME proposal and the Key Wrap proposal.

To the extent different CDMs have different levels of robustness, in
order to provide a good experience, it is reasonable to be able to
query the robustness level in advance of playback in order to not
offer content to the user unless the user's current browsing setup is
actually able to proceed to playback. Still, it seems to me that this
should be handled via the EME Key System. Experience indicates that
the best way to check if a browser is able to do something to try to
do it. Having the browser tell you what it supports separately from
trying to do it doesn't work. Developers make mistakes or have
incentives to make they software lie. E.g. the DOM hasFeature() method
was a miserable failure. Therefore, it seems like the wrong design to
try to correlate pre-provisioned Web Crypto keys with the robustness
level of an EME CDM. Furthermore, it seems particularly wrong to do
this using service-specific keys, since it is obvious that multiple
services that aren't known in advance will want to query the
robustness level.

It seems to me that to query the level of CDM robustness in the way
that is analogous with the way if feature querying that has been
proven to work on the Web is to create a hidden <video> element, load
an as short as possible video encrypted and packaged the same way as
the actual content on the service into the <video> element and calling
.play() on it to provoke an EME message that presumably contains proof
of possession of pre-provisioned CDM-scoped keys and, therefore, could
be used to make the sort of inferences that the Key Wrap drafts
suggests be made from service-specific pre-provisioned keys.

Where does this line of thinking go wrong in a way that the Key Wrap
proposal would fix?

-- 
Henri Sivonen
hsivonen@hsivonen.fi
https://hsivonen.fi/
Received on Wednesday, 19 February 2014 10:13:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:27 UTC