Re: Encrypting content stored on untrusted CDNs

On Feb 28, 2012, at 3:09 PM, Ian Hickson wrote:

> On Tue, 28 Feb 2012, Mark Watson wrote:
>> 
>> The server is not necessarily trusted. As I said, https services from 
>> CDNs (where they also sell you trustworthiness) are more expensive than 
>> http ones.
>> 
>> So I want the content encrypted in storage as well as transport.
> 
> This particular use case makes a lot of sense, and seems much more broadly 
> applicable than just media. For example, you could have a CDN store 
> private user information in the form of a JSON blob but want it encrypted 
> on the CDN. Or you could have the user's private image library stored on a 
> CDN, and want only the user to be able to see the content.
> 
> One way to solve this would be to provide a method that takes an 
> ArrayBuffer key and a URL, and have any subsequent fetch of that URL for 
> the browsing context be decrypted automatically using that key:
> 
>   navigator.addKeyForURL('http://cdn.example.net/video123', mykey);
>   myVideo.src = 'http://cdn.example.net/video123';
>   myVideo.autoplay = true;
> 
> The scoping for such a feature would be hard to specify though.
> 
> 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.

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. There are container format-specific specifications for this, for example the Common Encryption specification for the ISO file format (mp4). There may be more than one key associated with a given resource. 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.

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.

...Mark

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

Received on Tuesday, 28 February 2012 23:55:28 UTC