Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

On Tue, Feb 28, 2012 at 12:35 AM, Mark Watson <watsonm@netflix.com> wrote:
> These are obviously fairly general statements - the proposal doesn't prescribe a model for where CDMs will come from and we appreciate opinions and ideas on that topic.

Without knowing the nature of the CDMs, the impact of the proposal
can't be evaluated. It can't even be evaluated if the proposal
proposes a sensible API without having a good idea of what kind of
things CDMs would be.

But let's take a step back from CDMs and try to understand the
motivating requirements better.

So far, the requirements from the content provider point of view that
I've seen are:
 * Decrypted data must not be available to JavaScript
 * Speedbump to deter users from saving decrypted content
 * Hiding content from untrusted CDNs that host the content
 * Hiding content from eavesdroppers when the content is served over
HTTP without SSL/TLS

(I also saw that there are unbounded requirements that can't be
enumerated for all content providers in general, but I hope it's
possible to gain a better understanding of the requirements of Netflix
in particular later on. After all, there must be some process that
lead to Netflix deciding to use whatever DRM Netflix now uses in
various cases.)

>From the browser point of view (well, open source browser at least),
some obvious requirements are:
 * The system is fully specified and doesn't involve any
implementation-side secrets
 * The system can be implemented by anyone and in Open Source software
 * The system doesn't require browsers to interface with 3rd-party
black boxes that the browser vendors don't control (i.e. it should be
possible to have a fully-functional fully open source implementation
of the interoperable Web platform including all the supporting
software in the style of B2G and Chromium OS.)

Here's a description of a straw feature that I believe meets all the
above requirements. Would this system be adequate for Netflix to serve
movies to a browser that implements this feature? If not, why not
specifically? (The main purpose of this exercise is to gain better
understanding of the requirements. This isn't an offer to implement
this straw feature.)

- -

This feature adds a decryption layer to the browser's HTTP stack and
an API for initializing decryption keys from a different origin. Also,
the Same Origin Policy is extended to block obvious access to
decrypted data from JavaScript.

The browser maintains a key storage that holds tuple of key,
sha1(key), origin of key, list of authorized origins and time to live.
There's a JavaScript API navigator.addKey(keyUrl,
arrayOfAuthorizedOrigins, timeToLiveSeconds, doneCallback). keyUrl is
a URL of the same origin as the caller of the API. The payload
retrieved from the URL is key material to be added to the key storage.
arrayOfAuthorizedOrigins is an array of origins serialized as strings
that are authorized to serve content to be decrypted using the key.
(This is a privacy mechinism against other origins probing the key
store in case an untrusted CDN has leaked key hashes. More on hashes
later.) timeToLiveSeconds is the number of seconds after which the
browser purges this keystore entry. doneCallback is a JavaScript
function that the browser calls after it has retrieved and processed
keyUrl. Upon success, a single argument true is passed. Upon failure,
a single argument false is passed. (Note: The key material is not
exposed to JS.) The browser generates an id for the key by hashing the
key material with SHA-1. Origin of key is set to the origin of the
caller of the API which has to be the same as the origin of keyUrl.

When an HTTP response includes the response header Content-Encoding:
AES256, the processing happens as follows (if any step fails, treat as
like other HTTP errors):

The HTTP implementation gets the value of another response header
called Key-SHA1 and base64-decodes it. Then, the browser's key storage
is searched for a key whose sha1(key) entry matches this value and
whose list of authorized origins containst the origin of the HTTP
response and decrypts the response payload using AES256 using the
located key as the decryption key. The decrypted payload is exposed to
the other parts of the browser as having origin E(origin of key).

Origins of the type E(Origin) have the following properties:

 * A resource of origin E(Origin) can be included as embedded content
(<img>, <video>, <audio>) in (and only in) a document whose origin is
Origin.
 * For the purpose of JavaScript access to the data of the resource
(be it raw bytes or pixel data), E(Origin) is considered to be
different-origin with every origin including the origin(s)
representing the authority of browser extensions.
 * Browsers disable the "Save As..." context menu for embedded content
whose origin is of the form E(Origin)

When the layer above the HTTP layer request the HTTP stack to perform
a range request on a Content-Encoding: AES256 resource, the HTTP stack
must extend the range such that the range consists of full AES256
blocks in both directions. (The lack of block chaining is deliberate
so that seeking is possible.)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 29 February 2012 08:28:12 UTC