Re: AES-CTR inside vs. outside the media container (was: Re: Encrypted Media proposal: Summary of the discussion so far)

On 3/7/12 9:34 AM, Mark Watson wrote:
> On Mar 7, 2012, at 4:54 AM, Henri Sivonen wrote:
>
>> On Mon, Mar 5, 2012 at 2:57 AM, Mark Watson<watsonm@netflix.com>  wrote:
>>> This is how we at Netflix are able to work with multiple CDMs but one set of media files using the ISO Common Encryption standard for mp4 files.
>> Other than ISO Common Encryption being already deployed, what's the
>> benefit of encrypting codec data the mp4 container using AES-CTR as
>> opposed to encrypting the entire mp4 file using AES-CTR?
> Hi Henri,
>
> In ISO Common Encryption, the following parts of the file are in the clear:
> - index information for random access and adaptive stream switching
> - codec initialization and compatibility information
> - sample timing and dependency information
> - headers providing content protection initialization information (possibly for multiple content protection schemes)
>
> This allows a number of functions to be performed before decryption:
> - determining compatibility and initializing codecs
> - construction of HTTP requests for specific time ranges (basically, all of the adaptive streaming logic)
> - extraction of samples into a common container-independent format (elementary streams) with attention to audio/video synchronization
> - selection and initialization of a content protection system

Decryption of index blocks is not a big deal. The overhead is absolutely 
minimal; instead of seeking to position N, you seek to position N - N 
MOD blocksize.

The multiple content protection schemes (and multiple keys) case, of 
course, is a very different thing.

This one sticks:
"- headers providing content protection initialization information 
(possibly for multiple content protection schemes)"

-Charles

Received on Wednesday, 7 March 2012 20:45:16 UTC