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 1:21 PM, Charles Pritchard wrote:

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

It was designed for use-cases where the index information and sample sizes/timing are not considered sensitive. Given that there are big chunks of functionality in a streaming system that need only that information, it's an advantage (for those use-cases) to have that information in the clear. DRM is certainly one of those use-cases.

I can't think of many applications where having this information in the clear is problematic, but your point is well taken that people can be very innovative in extracting sensitive information from apparently non-sensitive data. (And of course I'm not claiming that because I can't think of the applications they don't exist).

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

Do you mean, why not have one key for the index information and another for the media, where the index key is available to more code in the client than the media key ?

I think that's equivalent to transferring a common encryption mp4 file using TLS (or something like http+aes if you need to protect the file this way in storage as well).

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

That all seems fair enough to me. I've no objection to talking about additional requirements (such as fully secured communications, as you say), just an objection to excluding requirements that are important to us.  This side-thread started because Henri asked about the motivation for ISO Common Encryption.

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

Actually, we find HTTPS to be a bit of a pain. At least for delivering the media itself it's much simpler operationally - and cheaper when using third party CDNs - to use HTTP with encrypted files (files distributed in thousands upon thousands of CDN edge caches are in practice going to be accessible to a fair number of people. Even if only the CDN employees, thats quite a few. For a CDN to ensure these are secure - as they would have to if they were in the clear - requires work on their part).

> 
> -Charles
>

Received on Wednesday, 7 March 2012 22:09:08 UTC