- From: <bugzilla@jessica.w3.org>
- Date: Wed, 30 Apr 2014 05:17:24 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25385 --- Comment #5 from GEXIN1984@GMAIL.COM --- (In reply to David Dorwin from comment #2) > (In reply to GEXIN1984 from comment #0) > > 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. > > Which source code are you referring to? The JavaScript application or the > user agent source code? JS Source code, a malicious user can read the code and easily find out the content key inside it. > > Some encryption is more secure than an unencrypted file sitting on a CDN. > The key could be provided to the user agent in ways, including WebCrypto, > that keep it secure during transit. > > > 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." > > WebCrypto might protect the key from JavaScript, but there is no implied > security within the user agent. I’m not referring security inside user agent. I’m talking about security in JS environment. > > This seems like a lot more specification for only a slightly more secure > solution. We could probably accomplish something similar by having Clear Key > (or a variant) provide a public key in the license request. This would also > be consistent with the flow used by other key systems. This might be worth > considering, especially if there are content providers that would use it. I just think the Webcrypto has already provide a method, if reused here, it maybe simpler for specification. However, if my proposal is too complex, provide a public key to encrypt the simple key can also work, I think. But what I want to emphasize is that the plain text content key should not be available in JS environment. That is the main issue. The UA may decrypt the content key using the private key and then directly pass it to the simple key CDM. Then the content key is not exposed to the JS. > > Importing content keys from outside the browser is out of scope for EME. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 30 April 2014 05:17:25 UTC