Re: Secure release and persistence

On Wed, Apr 29, 2015 at 5:05 PM, David Dorwin <ddorwin@google.com> wrote:

>
>
> On Wed, Apr 29, 2015 at 9:55 AM, Jerry Smith (WINDOWS) <
> jdsmith@microsoft.com> wrote:
>
>>  In fact, I wasn’t referring to different types of keys, only tracking
>> the use of individual keys.  At least one exploit we’ve discussed is an
>> organized attempt to represent multiple users as one, and many concurrent
>> sessions as play starts that weren’t continued.  Each playback would have
>> at least one key associated with it, and the start and latest encryption
>> markers that Mark proposed would let a service track how long each one was
>> used.  That would allow the service to identify organized exploits and
>> manage them.
>>
>
> Thanks for clarifying. As far as I am aware, this solution has not
> previously been discussed (publicly) nor has this exploit in relation to
> secure key release.
>
>>
>>
>> Jerry
>>
>>
>>
>> *From:* Mark Watson [mailto:watsonm@netflix.com]
>> *Sent:* Wednesday, April 29, 2015 9:36 AM
>> *To:* David Dorwin
>> *Cc:* Jerry Smith (WINDOWS); public-html-media@w3.org
>> *Subject:* Re: Secure release and persistence
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 29, 2015 at 9:22 AM, David Dorwin <ddorwin@google.com> wrote:
>>
>>
>>
>> On Tue, Apr 28, 2015 at 12:07 PM, Jerry Smith (WINDOWS) <
>> jdsmith@microsoft.com> wrote:
>>
>>  This makes sense to me, Mark.  You are looking for markers to bound the
>> usage of keys so that keys used for extended playback can be distinguished
>> from keys used to start, but not watch content.  Persisting first and
>> latest decrypt times accomplishes this.
>>
>>
>>
>> I'm not sure what you're referring to with these two types of keys, but I
>> don't think Mark has mentioned anything about different types of keys. As
>> far as I know, the Netflix use case is for a single key used for the entire
>> duration of the content. Clearly, there is still a lot of confusion (on one
>> or both of our parts) about what exactly this feature is and what it is
>> used for.
>>
>>
>>
>> ​I didn't sense any confusion in Jerry's mail. I think this comment is a
>> little self-serving. He is right that the secure release information can
>> give us reliable information about how long each key is used for. There are
>> no different "kinds" of keys, but there can be multiple licenses involved
>> in a session.​
>>
>
> I said there was confusion, not necessarily in Jerry’s email. It may have
> been on my part due to insufficient description and my not being involved
> in some other conversations. I'll ignore the inferences of your second
> sentence.
>
> If “reliable information about how long each key is used for” or
> distinguishing keys used for extended playback vs. those used to start is a
> desired feature/use case, I am not aware of that being discussed
> (publicly).
>

​The requirement is, and always has been, to reconcile the use of (and in
particular the destruction of) keys as seen by the CDM with what is seen by
the application servers. The latter can easily be forged by modifying the
JS code, wheras this is more difficult for the former.

It's true that this group has not gone into more detail about the contents
of the release message before, just as we have not ​gone into details about
the contents of the other messages, but there is no change here, just more
detail where previously there was less. We're edging in that direction for
all the messages, per Joe's protocol proposal, but we're all aware how
these things work even if the details have not been made public (yet).

I proposed this additional detail because it allows us to define the
mechanism in a way that clearly does not require any processing at the
close (graceful or otherwise) of the browsing session. It's true that such
processing on close is available to native apps and it's true that I had
asked that we do not exclude that possibility here. However, I've withdrawn
that request, in response to your comments. We can make it as clear as you
like in the specification that such processing is not expected / required /
allowed / ....

...Mark




>
>>
>> ...Mark
>>
>>
>>
>>
>>
>>
>>
>> Jerry
>>
>>
>>
>> *From:* Mark Watson [mailto:watsonm@netflix.com]
>> *Sent:* Tuesday, April 28, 2015 8:02 AM
>> *To:* public-html-media@w3.org
>> *Subject:* Secure release and persistence
>>
>>
>>
>> All,
>>
>>
>>
>> Hopefully this will catch you in your newly-freed "EME hour" :-)
>>
>>
>>
>> As promised at the F2F I will draft spec updates this week to fill in the
>> missing details of this feature. However, I would like to make one
>> significant change in response to comments at the F2F and previously
>> regarding exactly what is persisted.
>>
>>
>>
>> The spec describes persistence of a "record of license destruction".
>> Aside from the fact that we have no concept in our spec of "license", this
>> is not typically how this feature is implemented in DRMs and suggests a
>> need to persist data at close / shutdown / crash or other events that cause
>> license destruction.
>>
>>
>>
>> In practice, what is persisted  is a record of available keys at a point
>> in time. This is updated regularly *during streaming*. There is no update
>> on close / shutdown / crash. In a later browsing session, this record is
>> compared with the actually available keys and a discrepancy is taken as
>> evidence that keys were destroyed.
>>
>>
>>
>> I propose that we describe this persisted data explicitly as "for each
>> key in the session, the *first decrypt time* and the *latest decrypt
>> time*".*
>>
>>
>>
>> Are there any comments on that before I implement it ?
>>
>>
>>
>> Based on this change in description, I suggest we call this session type "
>> *tracked*" - or something similar - since really we are 'tracking' the
>> usage of keys. This name will also invite appropriate scrutiny of the
>> persisted data properties.
>>
>>
>>
>> ...Mark
>>
>>
>>
>> * there may of course be other CDM-specific information persisted and
>> included in the release message. For example if the CDM has a concept of
>> licenses, then license correlation identifiers may be present. Also, how
>> the CDM communicates time in its messages may be CDM-specific.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>