Re: Encrypting content stored on untrusted CDNs

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?


> There may be more than one key associated with a given resource.

Can you elaborate on that?


> 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.)


> 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). It's when you're trying to prevent the user from getting to the 
content that it stops making any kind of sense.

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

Received on Wednesday, 29 February 2012 00:32:06 UTC