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

> On Mar 7, 2012, at 12:44 PM, Charles Pritchard wrote:
>
>> 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.
> What I mean is that because the index is in the clear, then code handling the data in advance of the decryption function can handle construction of byte ranges (which is needs the in-the-clear index to construct), rate adaptation decisions etc.

Appreciating that you are working with an existing standard and existing 
hardware solutions:

Secure communications are supposed to be secure end-to-end, in their 
entirety. Yes, some solutions do leak information. There have been some 
studies about encrypted streaming of voice conversations, and 
determining content through looking at the amount of bandwidth used over 
a given duration (more noise requires more data; less noise is often 
compressed, requiring less data).

That the data is handed out in the clear, is an artifact of the design 
process -- it was designed with DRM as the goal, not secure communications.

Why wouldn't the decryption function handle index data? I imagine that 
design decision was because it would require an additional key, and 
since security was not the goal, that mechanism was left out. The 
alternative theory follows.


>> The multiple content protection schemes (and multiple keys) case, of course, is a very different thing.
> Things (plural): multiple content protection schemes and multiple keys are orthogonal features.
What I mean is that the multiple key scheme is a tangible benefit over 
single-key AES that Hixie has proposed.
The rest of the items you outlined I don't think of as benefits.

>> This one sticks:
>> "- headers providing content protection initialization information (possibly for multiple content protection schemes)"
> Not sure what you mean. The idea of common encryption is that the same 
> file could be decoded by multiple protection systems, e.g. PlayReady 
> or Widevine. This is what could make CDMs substitutable. 

What I mean, is that's the only bullet point that I see as relevant. The 
rest are quirks of a packaging format that could have aimed higher. 
Think opening a password-protected archive -- you wouldn't want people 
to see file names before they provide the password.

Yes, this issue your bringing up is important.

First, there are real-world hardware devices that consume keys, and 
those keys need to be passed into those devices. Second, there are real 
world instances of multiple protection systems using multiple keys all 
able to decrypt the same file. Yes, the multiple CDMs item seems pretty 
real to me. Meanwhile, Hixie and Henri are saying, let's all go to once 
CDM, AES.

As with the codec dispute, I don't think it's realistic. The market 
already has hardware out there. That's one big reason why we have 
multiple codecs. I know in some future reality, we can just junk that 
old hardware, or use compatibility layers and services to support it. In 
some sense, we're doing that already with mobile devices and online 
re-streaming services.

I don't see a resolution happening here between the two camps. That's 
ok, but I do want to make sure we have good grounds in the facts.

I'd like it if we could focus at some point on some greater purpose than 
standardizing and/or pushing back against DRM. As I've repeated 
throughout the thread, I'd like secure streaming of media to be the 
issue at hand. MP4 has packaging leaks. The AES encryption proposal by 
Hixie still leaks content to the UA and/or OS.

My issue with Hixie's side is that it does not try to or want to address 
the idea of isolated media playback, as found in some devices; and my 
issue with the other side, is that the use case focuses solely on DRM 
content of publicly accessible media -- there's no concern for actual 
media security, just DRM as it applies to content distributors.

If Netflix can not do the work to reach-out beyond their own use case, 
and examine Encrypted Media for secured communications, then that's a 
real let-down. I'd say the same to Hixie; if a method is not available 
to marshal data through the OS for hardware-based encryption, that's a 
real let-down.

It seems we've all agreed that HTTPS/TLS is great, but that we want 
something more agnostic to the networking protocol.

-Charles

Received on Wednesday, 7 March 2012 21:21:39 UTC