- 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