Re: Relationship of the Netflix KeyWrap proposal to EME

+1 to all of Henri's remarks. However, I believe this is for Mark to
address.
On Oct 24, 2013 4:11 AM, "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?
>
> --
> Henri Sivonen
> hsivonen@hsivonen.fi
> http://hsivonen.fi/
>
>