Sorry I mean feasible not flexible. Forgive my English.

(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?

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.

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.

Importing content keys from outside the browser is out of scope for EME.

I agree with David. Suggest WONTFIX.

If a site uses HTTPS, the key can be delivered to the client JS in a way that is secure against an active MITM attack. The difficulty for the user to obtain the key is about the same for this case as for the proposed use of WebCrypto.

Actually, I don't think there is any additional security since JavaScript (or anything else) could have provided the public key.

(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.

(In reply to Mark Watson from comment #3)
> I agree with David. Suggest WONTFIX.
> 
> If a site uses HTTPS, the key can be delivered to the client JS in a way
> that is secure against an active MITM attack. The difficulty for the user to
> obtain the key is about the same for this case as for the proposed use of
> WebCrypto.

I can't agree with you. HTTPS can protect the key against MITM attack. But the user can easily get key by reading JS source code. This is the bug I raised. I want to propose a method to solve the bug, but HTTPS cannot.

(In reply to David Dorwin from comment #4)
> Actually, I don't think there is any additional security since JavaScript
> (or anything else) could have provided the public key.
What do you mean by JavaScript provided the public key? the WebCrypto API?
But by using this API, the content key decrypted is still exposed to JS, so it is not secure. So I propose to integrate the WebCrypto API with EME by passing the encrypted content key directly to the simple key CDM.

(In reply to GEXIN1984 from comment #5)
> I just think the Webcrypto has already provide a method, if reused here, it
> maybe simpler for specification.

The same level of security as Clear Key could be provided by WebCrypto, but that would introduce an additional path and set of APIs.

> 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.

Where does the public key come from? How does the license server know that it wasn't generated in JavaScript?

(In reply to GEXIN1984 from comment #7)
> (In reply to David Dorwin from comment #4)
> > Actually, I don't think there is any additional security since JavaScript
> > (or anything else) could have provided the public key.
> What do you mean by JavaScript provided the public key? the WebCrypto API?
> But by using this API, the content key decrypted is still exposed to JS, so
> it is not secure. So I propose to integrate the WebCrypto API with EME by
> passing the encrypted content key directly to the simple key CDM.

Is your goal to make the content key inaccessible to the user from JavaScript?

While WebCrypto can be used to accomplish this, there is nothing that enforces this. The user could bypass the WebCrypto calls and provide a fake public key that the user can then use to decrypt the content key. Without some more complex mechanism, there is no way to determine that the public key came from the UA.

Can we resolve this with the following text change?

Replace this:
This 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.

With this:
This ensures that there is a common baseline implementation that is guaranteed to be supported in all user agents, including those that are entirely open source. Thus content providers can build simple applications that will work on all platforms without needing to work with any specific content protection providers.

Note the removal of all mention of "protection". This makes it clear that no protection is required from a ClearKey key system implementation.

You're right. This is still not secured. Maybe the public key should be signed by UA. 
Then what if the CDM reuse the HTTPS client key to sign the public key it send? Or the CDM directly reuse the HTTPS key pairs for content key delivery? 
Because the HTTPS keys are the security mechanism that are already established between UA and server, which are not exploded to JS.
Thanks.
GE Xin
(In reply to David Dorwin from comment #8)
> (In reply to GEXIN1984 from comment #5)
> > I just think the Webcrypto has already provide a method, if reused here, it
> > maybe simpler for specification.
> 
> The same level of security as Clear Key could be provided by WebCrypto, but
> that would introduce an additional path and set of APIs.
> 
> > 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.
> 
> Where does the public key come from? How does the license server know that
> it wasn't generated in JavaScript?
> 
> (In reply to GEXIN1984 from comment #7)
> > (In reply to David Dorwin from comment #4)
> > > Actually, I don't think there is any additional security since JavaScript
> > > (or anything else) could have provided the public key.
> > What do you mean by JavaScript provided the public key? the WebCrypto API?
> > But by using this API, the content key decrypted is still exposed to JS, so
> > it is not secure. So I propose to integrate the WebCrypto API with EME by
> > passing the encrypted content key directly to the simple key CDM.
> 
> Is your goal to make the content key inaccessible to the user from
> JavaScript?
Yes, I think if the content key is accessible to JS, there is no security. But to hack UA is much more difficult.
> 
> While WebCrypto can be used to accomplish this, there is nothing that
> enforces this. The user could bypass the WebCrypto calls and provide a fake
> public key that the user can then use to decrypt the content key. Without
> some more complex mechanism, there is no way to determine that the public
> key came from the UA.

(In reply to GEXIN1984 from comment #10)
> You're right. This is still not secured. Maybe the public key should be
> signed by UA. 
> Then what if the CDM reuse the HTTPS client key to sign the public key it
> send? Or the CDM directly reuse the HTTPS key pairs for content key
> delivery? 
> Because the HTTPS keys are the security mechanism that are already
> established between UA and server, which are not exploded to JS.

WebCrypto has explicitly put interaction with TLS keys out-of-scope for the first version.

Regarding signing by the UA, there would need to be some secret embedded in the UA that would identify it as a "genuine" UA and it would need to be difficult for someone to obtain such a secret (since they could then just embed that secret in some Javascript and do the whole thing in Javascript). So, the secret can't just be in the source code (or, rather, if it was, then the solution has essentially the same security properties as the ClearKey solution).

This is exactly one of the problems (known as 'robustness') that DRM's address in some detail, so what you are proposing is really to define a DRM, albeit a simple one.

There are many other problems associated with such a task and we have not in this group set out to define a new DRM, even a simple one, so I would sill suggest WONTFIX for this one.