W3C home > Mailing lists > Public > public-html-media@w3.org > April 2014

[Bug 25385] New: clear key cannot provide basic protection, why not considering web cryptography API

From: <bugzilla@jessica.w3.org>
Date: Fri, 18 Apr 2014 02:59:05 +0000
To: public-html-media@w3.org
Message-ID: <bug-25385-5436@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25385

            Bug ID: 25385
           Summary: clear key cannot provide basic protection, why not
                    considering web cryptography API
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: Encrypted Media Extensions
          Assignee: adrianba@microsoft.com
          Reporter: GEXIN1984@GMAIL.COM
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

According to the EME spec, a "clear key" Key System needs to be supported to
"ensures that there is a common baseline level of protection that is guaranteed
to be supported in all user agents, including those that are entirely open
source. Thus, content providers that need only basic protection can build
simple applications that will work on all platforms without needing to work
with any content protection providers."
However, the clear key may not be able to achieve the goal to provide even a
"basic protection" as the key is in plain text. Attackers can easily get the
key from the source code and use it to decrypt the content. It is obvious that
encrypted content with a plain text key is not any more secured than just plain
text content.
My suggestion is to use the API defined in Web cryptography work group to
provide a more flexible basic protection. The key defined in the web
cryptography API is not exposed in JS environment, it can be used as the
content key in DRM system. One possible solution is that the client generates a
key pair, the server encrypts the key with public key of the client, and then
the client uses its private key to unwrap the key. The content key may also be
import from out side the browser.
I think this method may be much more secured than the clear key and can be used
by content providers who "need only basic protection can build simple
applications that will work on all platforms without needing to work with any
content protection providers."
Thanks
Ge Xin

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 18 April 2014 02:59:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:03 UTC