Adding encryption to WebM RFC

[Frank Galligan]

Hello everyone,

As some of you may know Netflix, Microsoft, and Google published a joint proposal that can playback encrypted content within HTML5. In order for this to happen we will need to add encryption to WebM. We put up a WebM encryption RFC here: https://sites.google.com/a/webmproject.org/wiki/encryption/webm-encryption-rfc

Please take a look and post any questions or comments.

Thanks,

Frank

[Basil Mohamed Gohar]

I'm not able to reply to the HTML Working Group list at the W3, but I
will state here, firmly, that this is a major step backward for freedom
and openness on the web. Any specification that will restrict what the
user can do with their computer is unethical and has no place in open
standards, least of all on the web.

I'm talking about actually codifying in web standards a manner in which
a user's browser will be required to lock away access to content that
can be viewed but only under terms dictated by the so-called
content-providers. Such a restriction should not be possible on the
free and open web. This is all being hidden by the term "Encryption"
and "Encrypted Media" but what it really is is a method to standardize
DRM in our browsers.

I strongly object to any form of cooperation with such a standard. If
we yield on this, then we've lost the battle for the free-and-open web
in terms of media. WebM has always been about an option that preserved
freedom for users *and* content-creators free from the dictates of
outside parties. Introducing DRM into WebM and the HTML media elements
takes all of that away.

To learn more about how DRM has already affected other areas of our
lives, please visit the following site:

http://www.defectivebydesign.org/

This proposal is going to ensure that we will not be able to escape DRM
even on the Web.

--
Libre Video
http://librevideo.org

[abushcrafter]

+1

On Apr 10, 9:12 pm, Basil Mohamed Gohar <basilgo...@librevideo.org>
wrote:

> On 04/10/2012 02:42 PM, Frank Galligan wrote:> Hello everyone,
>
> > As some of you may know Netflix, Microsoft, and Google published a joint
> > proposal that can playback encrypted content within HTML5. In order for
> > this to happen we will need to add encryption to WebM. We put up a WebM
> > encryption RFC here:

> >https://sites.google.com/a/webmproject.org/wiki/encryption/webm-encry...

[Ryan Malayter]

On Apr 10, 3:12 pm, Basil Mohamed Gohar <basilgo...@librevideo.org>
wrote:

> I'm not able to reply to the HTML Working Group list at the W3, but I
> will state here, firmly, that this is a major step backward for freedom
> and openness on the web.  Any specification that will restrict what the
> user can do with their computer is unethical and has no place in open
> standards, least of all on the web.

There are lots of use cases for this go beyond "big media and DRM". If
you don't like such a specification, don't use it.

But I can guarantee you that Flash/Silverlight video will not die
until publishers have some ability to "raise the bar" in protecting
their content, however flawed the concept may be. Better a
standardized system with open protocols than a bunch of proprietary
plug-ins.

[fishor]

I love to see encryption support on WebM. Especially if it can replace
silver light.
One question: do you wont to encrypt complete stream or partial? For
example only key frames and vp8 header? Full encryption of video with
small resolution will add some extra load on CPU, but for HD video ...
it will be overkill.

[Frank Galligan]

Hi Basil,

Maybe you can join the HTML WG or work with someone to post your views on the subject? (I'm not a member either).

I would really like to keep this thread technical and everything else on the W3C's list. Probably a fool's errand.

Frank

--
You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
To post to this group, send email to webm-d...@webmproject.org.
To unsubscribe from this group, send email to webm-discuss...@webmproject.org.
For more options, visit this group at http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.

[Frank Galligan]

Currently the RFC will encrypt all of the blocks for an entire stream. I was trying to keep features of encrypted files as low as possible, so content providers do not have to pick which players they will support or host multiple versions of the same file.

Frank

[Basil Mohamed Gohar]

On 04/17/2012 04:38 PM, Frank Galligan wrote:
> Hi Basil,
>
> Maybe you can join the HTML WG or work with someone to post your views
> on the subject? (I'm not a member either).
>
> I would really like to keep this thread technical and everything else
> on the W3C's list. Probably a fool's errand.
>
> Frank

I have tried to join the HTML WG list, but it's not a straightforward
process. As I'm not a member of any prominent organization or company,
I am not sure I'll get in. I will respect your wishes with regards to
this list, especially considering my point has already been made and
seconded by some others on the list.

[Vladimir Pantelic]

I find the IV handling overly complex. Is there not a way to
add a few bytes per frame that hold the needed IV data without
the player having to worry about getting the IV from the raw
timestamps correctly? (this is how it is .e.g done for
encrypted ASF streams in M$ DRM10, see PayloadExtension
SampleID)

Regards,

[Frank Galligan]

We could definitely do that. At 8 bytes the added overhead would be about 2 Kbps. If we were to move to an attached IV we could probably drop the IV to 4 bytes as then the IV would only have to increment by 1 per frame. So the overhead would be about 1 Kbps @ 30fps. Total overhead would be about 4 Kbps @ 30 fps.

The reason I didn't propose this first is I really wanted to keep the overhead down as much as possible. If developers want to use encrypted WebM over constrained networks, any extra overhead is going to really hurt (Anyone have this use case?).

What did you find too complex the restrictions or the the IV generation?

--
You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
To post to this group, send email to webm-d...@webmproject.org.

To unsubscribe from this group, send email to webm-discuss+unsubscribe@webmproject.org.

[Oleksij Rempel]

If i see it correctly, you do not use "EncryptedBlock Structure" from
matroska specification. Am i correct? If yes, then why?
http://matroska.org/technical/specs/index.html#encryptedblock_structure

[Frank Galligan]

I did not use encrypted block from Matroska mainly because then all tools that handle Matroska/WebM would have to be updated to support basically a new block format as the encrypted block has been deprecated for a while.

Why do you want to use the encrypted block? To encrypt only certain blocks of one stream? If so there are other things we can do to get the desired effect without breaking all the current tools.

Frank

--
You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
To post to this group, send email to webm-d...@webmproject.org.

To unsubscribe from this group, send email to webm-discuss...@webmproject.org.

[Frank Galligan]

I just want to add something about the complexity of including the IV with each frame. There will be added complexity to the tools as they will now have to ensure the IV is unique within the data. So if any frames are added or cut, all frames after that will have to be re-encrypted. (With cut frames we could get around the re-encrypting but we would need to add more rules about the IV which is what we are trying to alleviate). I'm not so worried about adding complexity to the tools as I am adding it to the players. 

We would probably need to add a rule to players to keep state anyway to make sure the IV is unique. This would be a check to make sure the a tool didn't have a bug or an attacker did not put frames with the same IV, which could be a security risk. I would want to double check with security experts. 

[Oleksij Rempel]

I just trying to imagine what should be done in gstreamer to implement it.
Do i understand it correctly:
wt = block timestamp in webm container
en = not ecryptet timestaps on ecnryption layer.
-->webm layer - [wt1], [wt2], [wt3]
-->enc layer - [en1], [en2], [en3]

If i seek, i need to know [en*] or [wt*]?

[Oleksij Rempel]

2012/4/18 Oleksij Rempel <lexa....@gmail.com>:

I mean if you do not use EncryptedBlock, then webm time timestamps
are encrypted?

[Frank Galligan]

I'm not sure what en is.

If you seek you only need to know wt, with which you can derive the encrypted frame's IV. 

--
You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
To post to this group, send email to webm-d...@webmproject.org.

To unsubscribe from this group, send email to webm-discuss...@webmproject.org.

[Frank Galligan]

No the Block header is not encrypted, so timestamps are not encrypted. The only part of the block that is encrypted is the payload. 

--
You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
To post to this group, send email to webm-d...@webmproject.org.

To unsubscribe from this group, send email to webm-discuss...@webmproject.org.

[Vladimir Pantelic]

Frank Galligan wrote:
> We could definitely do that. At 8 bytes the added overhead would be about 2 Kbps. If we were to move to an attached IV
> we could probably drop the IV to 4 bytes as then the IV would only have to increment by 1 per frame. So the
> overhead would be about 1 Kbps @ 30fps. Total overhead would be about 4 Kbps @ 30 fps.
>
> The reason I didn't propose this first is I really wanted to keep the overhead down as much as possible. If developers
> want to use encrypted WebM over constrained networks, any extra overhead is going to really hurt (Anyone have this use
> case?).

I guess people might want DRM to protect HD streaming,
not QQVGA, so I doubt the added overhead is an issue.

> What did you find too complex the restrictions or the the IV generation?

the fact that as a player I need to add logic and keep state in order
to generate the IV. I'd much rather just read 4 more bytes and pass
them to the DRM layer.. This also gives total freedom to the
content creator as how to handle the IV. If you codify IV handling
for the player, then you cast that in stone forever, no?

[Frank Galligan]

Hi Vladimir,

I updated the RFC to prepend an IV to each encrypted frame. When you get time check it out and post any comments.

Frank

[Vladimir Pantelic]

Frank Galligan wrote:
> Hi Vladimir,
>
> I updated the RFC to prepend an IV to each encrypted frame. When you get time check it out and post any comments.

With the client side handling of the IV gone, looks good to me.

What I don't get is why the IV has to increase by one for each frame,
why is it not just treated as an opaque value by the client that
is just fed to the decoder, leaving all the selection of IV to the
content protection side?

Regards,

Vladimir

[Steve Lhomme]

This overhead is OK for video, but what about audio ? It has many more
packets, especially with Vorbis. I suppose if a stream is encrypted
you wouldn't want to be able to decode the audio as well.

>> webm-discuss...@webmproject.org.

>> For more options, visit this group at
>> http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.
>>
>

> --
> You received this message because you are subscribed to the Google Groups
> "WebM Discussion" group.
> To post to this group, send email to webm-d...@webmproject.org.
> To unsubscribe from this group, send email to

> webm-discuss...@webmproject.org.

> For more options, visit this group at
> http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.

--
Steve Lhomme
Matroska association Chairman

[Frank Galligan]

Sorry this was so late.

Incrementing the IV by one is just another easy check on the client. If it were random, then either the client would have to keep a list of IV's or not perform the check.

Frank

[Vladimir Pantelic]

On 06/28/2012 02:57 AM, Frank Galligan wrote:
> Sorry this was so late.
>
> Incrementing the IV by one is just another easy check on the client. If
> it were random, then either the client would have to keep a list of IV's
> or not perform the check.

why would the client be concerned with the IV at all?? There is one IV
per frame and all the client needs to do is to pass the IV together with
the frame to the decoder/decryptor. What does it have to "check" for?

Vladimir

>
> Frank
>
>
> On Tue, May 29, 2012 at 4:07 AM, Vladimir Pantelic <vlad...@gmail.com
> <mailto:vlad...@gmail.com>> wrote:
>
> Frank Galligan wrote:
>
> Hi Vladimir,
>
> I updated the RFC to prepend an IV to each encrypted frame. When
> you get time check it out and post any comments.
>
>
> With the client side handling of the IV gone, looks good to me.
>
> What I don't get is why the IV has to increase by one for each frame,
> why is it not just treated as an opaque value by the client that
> is just fed to the decoder, leaving all the selection of IV to the
> content protection side?
>
> Regards,
>
> Vladimir
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "WebM Discussion" group.
> To post to this group, send email to webm-d...@webmproject.org

> <mailto:webm-d...@webmproject.org>.

> To unsubscribe from this group, send email to

> webm-discuss+unsubscribe@__webmproject.org
> <mailto:webm-discuss%2Bunsu...@webmproject.org>.

> For more options, visit this group at

> http://groups.google.com/a/__webmproject.org/group/webm-__discuss/?hl=en
> <http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "WebM Discussion" group.
> To post to this group, send email to webm-d...@webmproject.org.
> To unsubscribe from this group, send email to

> webm-discuss...@webmproject.org.

[Frank Galligan]

A re-used IV with the same encryption key will leak information. So having some component on the client (i.e. demuxer or decryptor) check that the IV is unique will make the client more secure.

Frank

    <mailto:webm-discuss@webmproject.org>.

    To unsubscribe from this group, send email to

    webm-discuss+unsubscribe@__webmproject.org
    <mailto:webm-discuss%2Bunsu...@webmproject.org>.

    For more options, visit this group at

    http://groups.google.com/a/__webmproject.org/group/webm-__discuss/?hl=en
    <http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en>.

--
You received this message because you are subscribed to the Google
Groups "WebM Discussion" group.
To post to this group, send email to webm-d...@webmproject.org.
To unsubscribe from this group, send email to

webm-discuss+unsubscribe@webmproject.org.

For more options, visit this group at
http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.

--
You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
To post to this group, send email to webm-d...@webmproject.org.

To unsubscribe from this group, send email to webm-discuss+unsubscribe@webmproject.org.

[John Koleszar]

This is true, of course, but that doesn't mean that it has to be enforced by the client. It could be done by the underlying crypto module, or not enforced at all, and left up to the content creator. Treating the value as opaque makes sense to me.

In fact, uniqueness is not sufficient. IVs should be unpredictable as well. There have been exploits against unique but predictable IVs, see http://rdist.root.org/2008/02/05/tlsssl-predictable-iv-flaw/ for one example.

To unsubscribe from this group, send email to webm-discuss...@webmproject.org.

[Frank Galligan]

I'm including the crypto module in the client. Whether the check is done in the decryptor or the demuxer is left left up to the client. I think performing the check in the decryptor is a fine place. I also wrote 3.7.2 as "Clients SHOULD check..."

I just didn't want to force the decyrptor to make the check as I know of some people wanted to perform the check in the demuxer. But I agree that the natural place to perform the check would be in the decyptor. What if I change the text to "Decryptors SHOULD check...". Then if your client wants to have another module perform the check before the decryptor as an optimization that is up to you.

I just want to reiterate, I'm not a security expert, but the link you sent is for CBC which is different than CTR. I have asked many times and none of the security experts I have talked to so far have had an issue with a predictable IV with CTR, as long the IV is unique.

Frank

[John Koleszar]

Ok, I missed the change from CBC to CTR. I don't have any objection to a sequential IV then.

I think it may be useful to define the check more loosely to explicitly allow out of order IVs over some bounded range. If you were to apply this to something like webrtc, frames arriving out of order will be an issue.

[Frank Galligan]

How about changing the "Initialization Vector Check" too:

3.7.2 Initialization Vector Check

Decryptors MUST check that IV values are strictly increasing, taking into account rollover of an unsigned 64 bit integer and out of order packets. 

3.7.2.1 Rollover Algorithm

An acceptable algorithm to check for rollover is if the previous IV was >= 2^64-2^16, and the new IV is < 2^16, then accept it.

3.7.2.2 Out of Order Algorithm

Some systems may need to support out of order decryption for a very limited range of frames. Decryptors MUST keep a sliding window of the previous 30 IV values from the last received IV to check against. I.e. The decryptor decrypted a frame with an IV value of 60, then the decryptor decrypted a frame with an IV value of 62. If the decryptor then received a frame with an IV value of 61 the decryptor will decrypt that frame. If then the decryptor received a frame with an IV value of 30 the decryptor MUST not decrypt that frame, because it falls outside the sliding window. If then the decryptor received a frame with an IV value of 60 the decryptor MUST not decrypt that frame, because that would violate the IV uniqueness rule. 

[Vladimir Pantelic]

On 07/03/2012 01:44 AM, Frank Galligan wrote:
> How about changing the "Initialization Vector Check" too:
>
> 3.7.2 Initialization Vector Check
>
> Decryptors MUST check that IV values are strictly increasing, taking
> into account rollover of an unsigned 64 bit integer and out of order

> packets. *

But these are now details of the actual DRM implementation, this has
got nothing to do with webm as the container format. no?

[Frank Galligan]

Yes they are details of the decryptor implementation. But this is a contract between the client and the decryptor. We do delve into other decryptor implementation issues such as what the decryptor MUST do with an integrity check failure. These rules are put into place so the client will know what the decryptor will do in certain situations. This way if a decryptor has undefined behavior the client may treat that decryptor as broken.

With that being said I think the main reason for the strictly increasing IV check was to stop someone from reordering the frames. Now that we have a use case which WebRTC will decode out of order, we should probably get rid of the IV check by the decryptor. Anyone have an issue if we do that?

Frank

Without this rule there could be an issue. If a decryptor doesn't implement the checks then decryptor may still work for normal use cases, but if someone is doing something to mess with the stream