Re: Relationship of the Netflix KeyWrap proposal to EME

Has there been a response to the below-quoted comments? If there have
been, I've missed them.

On Thu, Oct 24, 2013 at 2:11 PM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:
> I'm trying to understand the motivation of the KeyWrap proposal and
> especially how Netflix specifically wants to use it in their service.
> The proposal links to a use case document that has a section about
> Video Services:
> http://www.w3.org/TR/webcrypto-usecases/#authenticated-video-services
>
> I would like to understand why the Video Service use case in general
> should be addressed by the Web Crypto API as opposed to being
> addressed by an EME Key System and I would like to understand how the
> Web Crypto API is used with the Netflix service in practice when the
> service also uses EME.
>
> Quoting from the use case document:
>> A Video Service Provider wishes to distribute high quality
>> commercial video to users of web-enabled TVs and Set
>> Top Boxes. The video in question can only be delivered
>> to devices with certain capabilities that meet the service
>> provider's security requirements, which may vary based
>> on the content and content quality to be delivered.
>
> Sounds a lot like an introduction for motivating EME.
>
>> In order to determine whether the device is indeed
>> approved to be used with the video service, the
>> service provider arranges for suitable devices to
>> each be pre-provisioned with a cryptographic key
>> and associated identifier by the device
>> manufacture, which are made known to the service
>> provider.
>
> Why should a factory-provisioned key be used with the Web Crypto API
> as opposed to being used by an EME Key System?
>
> In order for the server to be able to make approval/capability
> inferences from evidence of the client's possession of key material
> available to the Web Crypto API, the whole browser along with the Web
> Crypto API implementation would have to be Tivoized, which is
> undesirable. A good reason why EME separates the CDM from the User
> Agent is to allow the lock-down to be minimized to the CDM so that the
> User Agent can stay as an agent of the user that isn't locked down
> against the user.
>
> Moreover, it seems like a bad idea to have to have service-specific
> factory-provisioned keys as opposed to merely having Key
> System-specific factory-provisioned keys on a TV, since the latter has
> broader applicability.
>
>> 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?
>
>> The video provider's page on the TV
>> likewise verifies that it is talking to a
>> genuine server, preventing the hijacking
>> of Ryan's video watching by a malicious
>> third party.
>
> This is what TLS certificates used together with https are for.
>
>> Ryan creates an account with the service
>> provider and signs up for the lowest level
>> of service, which enables him to connect
>> five devices to the service at any one time.
>> Ryan's account creation involved the
>> creation of a specific key pair to uniquely
>> identify him, and safely exchanges keys
>> with the video service's servers.
>>
>> The video service provider is able to track
>> the number of devices Ryan has connected
>> to the service by virtue of the pre-provisioned
>> keys and identifiers, so that when he
>> attempts to connect a sixth device, the
>> service can prompt him to upgrade his
>> service level or deactivate one of the
>> existing devices.
>
> Why is it useful to track the number of Ryan's connected devices if
> the service limits Ryan to using one device to play back content at
> any given moment? I thought that's how Netflix worked. At least when I
> log into Netflix, there is no warning of the act of logging in from a
> new device eating up device number quota. Does Netflix specifically
> need to track the number of devices? Why?  Isn't tracking the number
> of devices old-fashioned with always-on networking that allow limiting
> the number of devices playing back content simultaneously?
>
>> Ryan finally attempts to play some video
>> through the service. By virtue of the secure
>> connection, the video service provider is
>> able to make content authorization
>> decisions that are tailored to the security
>> capabilities of the exact make, model and
>> version of TV that Ryan has purchased,
>> thereby ensuring that the content providers
>> security requirements are met in respect
>> of the specific content requested.
>
> Again, isn't this supposed to be handled by an EME Key System?
>

On Wed, Feb 19, 2014 at 12:12 PM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:
> 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 Friday, 20 February 2015 13:43:22 UTC