Re: Encrypting content stored on untrusted CDNs

On Feb 28, 2012, at 4:31 PM, Ian Hickson wrote:

> On Tue, 28 Feb 2012, Mark Watson wrote:
>>> 
>>> Another way would be to do something similar to what Blob does, namely 
>>> create an object that returns a new URL representing the decoded 
>>> resource, as follows:
>>> 
>>>  var data = new DecodedURL('http://cdn.example.net/video123', mykey);
>>>  myVideo.src = URL.createObjectURL(data);
>>>  myVideo.autoplay = true;
>>> 
>>> (We can't use Blob itself because this has to be done cross-origin.)
>>> 
>>> Data would be encoded using AES256. I guess we could actually allow 
>>> AES128, 192, and 256 by just allowing the key argument to be either 
>>> 16, 24, or 32 bytes long.
> 
> Specifically, AES-CTR.
> 
> 
>> This may be fine for monolithic resources, for this use-case where the 
>> user has access to the keys and decrypted content.
>> 
>> For streaming media, though, encryption has to be applied in such a way 
>> that we can support seeking and adaptive stream switching.
> 
> With AES-CTR, so long as you know how many bytes in you are (which you do 
> for monolithic files or for things like DASH), you're fine.
> 
> 
>> There are container format-specific specifications for this, for example 
>> the Common Encryption specification for the ISO file format (mp4).
> 
> What does this provide that's better than just whole-file encryption?

All of the index, framing and timing information is in the clear. Only the media samples themselves are encrypted. This means a great deal of client logic: streaming, buffering etc. can be done before decryption, supporting an architecture where decryption, decoding and rendering are provided by the device or separate software module.

Another advantage is that a number of different content protection systems support this encryption format (or soon will). 

> 
> 
>> There may be more than one key associated with a given resource.
> 
> Can you elaborate on that?

This is feature of the file format. Some people imagine using that for key rotation. I guess a single file could have been assembled from multiple components with different keys (by a tool which did not have the keys).

In the case of adaptive streaming, the different resources may have different keys.

If the above sounds incomplete/weak that's just because I don't myself have a strong use-case for multiple keys for one file - but it's a feature of the Common Encryption format.

> 
> 
>> In some models, the URL passed to src isn't the actual media, but is a 
>> manifest describing the media. But it's just the media that is 
>> encrypted.
> 
> Interesting point.
> 
> This seems like an easy problem to solve, though. Just put the keys for 
> all the streams into the manifest. No need for an API for this. (If you're 
> concerned with a CDN getting to the data, it seems just as bad to let them 
> have access to the manifest, so you'd presumably want to encrypt that 
> also. Unless the manifest comes from the trusted server maybe? In which 
> case TLS would be sufficient for the manifest... In either case, though, 
> the manifest can contain the keys for the content streams.)

That would work for this model, yes.

> 
> 
>> This discussion arose, however, as we included this use-case as a 
>> specific baseline case in our proposal for a more general scheme. The 
>> more general scheme also addresses the use-cases that commercial video 
>> services are concerned with.
>> 
>> It's good that there is consensus now that this baseline case makes 
>> sense.
> 
> I don't think anyone has ever said anything against wire encryption. It 
> makes perfect sense to protect data from man-in-the-middle attacks, 
> especially in the context of private user data (e.g. a user's private 
> videos).

There were some arguments made (initially by Henri, I think), that https was sufficient for this use-case. I wanted to describe usecases where something like the clearkey keysystem, or indeed the ideas you outliine above, had some utility over plain https.

> It's when you're trying to prevent the user from getting to the 
> content that it stops making any kind of sense.

Yes, I understand this does not make any sense to you. But it does to others. It's a pre-requisite for services like Netflix to use HTML5 instead of plugins. This list is not the place to argue the ethics of that. W3C needs to decide whether to work on making that a possibility, or whether HTML5 is simply not going to be a suitable technology for our segment of the industry, which would be a shame.

...Mark

> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Wednesday, 29 February 2012 01:08:54 UTC