- From: <bugzilla@jessica.w3.org>
- Date: Fri, 18 Apr 2014 02:59:05 +0000
- To: public-html-bugzilla@w3.org
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 the QA Contact for the bug.
Received on Friday, 18 April 2014 02:59:06 UTC