Re: EME compatibility with existing DRM systems

Sent from my iPhone

On May 9, 2013, at 11:56 AM, Gilles Boccon-Gibod <bok@bok.net> wrote:


On May 9, 2013, at 11:25 AM, Mark Watson <watsonm@netflix.com> wrote:



On Thu, May 9, 2013 at 11:04 AM, Gilles Boccon-Gibod <bok@bok.net> wrote:

>
> On May 8, 2013, at 9:02 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>
>
> On Wed, May 8, 2013 at 8:45 AM, Gilles Boccon-Gibod <bok@bok.net> wrote:
>
>>
>> On May 7, 2013, at 7:16 AM, Mark Watson <watsonm@netflix.com> wrote:
>>
>> Gilles,
>>
>> The design of EME is that CDMs do not interact directly with content
>> license servers*, but instead the license acquisition process is mediated
>> by the application.
>>
>> It's hard for the specification to *prohibit* such direct interaction,
>> but you would likely find that a KeySystem that subverted the design
>> approach would not be usable with most EME applications.
>>
>> The reason for this design is to avoid the need for service providers -
>> who must in practice support multiple DRM systems - to stand up multiple
>> front-end license servers. Also it avoids the need to delegate application
>> business logic such as user authentication and authorization to multiple
>> DRM servers. These functions are properly handled by the application and
>> the license server is used as a back-end server to provide licenses as
>> required by the application.
>>
>> As a result, existing DRM client components will likely need to be
>> wrapped in some way to form an EME CDM. In the case of Marlin that you
>> describe below it looks like you need to sign and encrypt the messages
>> using the credentials you would otherwise use for securing the TLS
>> connection.
>>
>>
>> That's understood. But doing that would defeat the purpose of the design
>> of the Marlin MS3 protocol and its performance characteristics.
>> One of they key reasons why MS3 works over TLS the way it does is that it
>> allows service providers to leverage existing software and hardware
>> infrastructure to scale the DRM processing: TLS is a well known protocol,
>> which has become a commodity. By choosing to leverage TLS as an
>> authenticated, encrypted channel, service providers can delegate the crypto
>> processing to off-the-shelf hardware and software solutions that implement
>> plain-old TLS.
>> When using a model where message signing and encryption is done at a
>> different layer (which, by the way, is done for other Marlin protocols,
>> such as Marlin BB), all that off-the-shelf-ness goes out the window, and
>> you're back to needing vendor-specific server software to implement the
>> crypto processing of the messages.
>>
>
> Based on our experience with a large-scale service, the performance and
> scalability advantages of TLS for this application messaging would be
> rendered insignificant by the operational and architectural complexity
> associated with having multiple front-end DRM servers and managing the TLS
> credentials. We have also found TLS to be slow, significantly impacting
> stream start times. And that is without considering the security
> implications of tying the DRM message security to a single, unchangeable,
> solution (which is not really my area).
>
>
> I think you may be confusing two very different things here. When you say:
> "We have also found TLS to be slow, significantly impacting stream start
> times", you are probably referring to using TLS for the stream data itself.
>

No, I am referring to using TLS for application control messages, including
key delivery.


> That is not at all what I'm talking about here. I'm talking about using
> TLS for key delivery only, not for the stream data. I explain this in more
> details in my second comment below.
>
>
>
>> It would be a huge step backward if using EME meant not being able to
>> take advantage of web-standard protocols like TLS. That would seem to be
>> going in the exact opposite direction from what organizations like W3C
>> usually strive for: more common standards, less vendor-specific technology.
>>
>
> You can certainly use TLS for your application messaging (from client JS
> to server), using XHR. What you can't do is bind this TLS connection to a
> DRM-controlled client credential (without some very special UA support).
> You'll need to do that binding in your CDM.
>
>
> That's precisely the point: using TLS from the client JS to a server with
> XHR is useless for the DRM. What the DRM server needs is to authenticate
> the end point that will be receiving the key data sent in the HTTP-over-TLS
> response (what you call "do that binding in your CDM").
> Maybe I should explain a bit more what the normal sequence is like (not in
> the EME architecture, but in currently deployed systems):
> When the client app wants to play an encrypted asset (stream, file, or any
> resource that's encrypted), the content service provides the client (after
> any service-level authentication, like logging into a user account, etc.)
> with an HTTPS URL that points to a DRM server. The URL contains any data
> that the service needs in order to decide what key to send back as a
> response to the client (typically, you will find in the URL a content ID,
> some transaction context, sometimes an encrypted key or key seed, etc.).
> When the DRM server receives the incoming SSL connection request, it
> responds with a server-hello with the "client authentication" bit set,
> requiring the client to authenticate itself with an X.509 certificate. The
> DRM client (CDM/KeySystem here) uses its X.509 DRM credentials to respond.
> The server then verifies that the client's certificate is acceptable (i.e
> is under the PKI root for the DRM), and sends an HTTP response with a
> payload that contains one or more keys and associated key usage
> information. The server can do so because it knows that the recipient can
> be trusted to handle the key material in accordance with the DRM's
> compliance and robustness rules.
>
> So, as you point out, what is needed here is "…to do that binding in your
> CDM.". But that's precisely what the current EME spec prevents
>

No, EME does not prevent it. Your CDM simply needs to sign your
client->server message with the client private key and include the
certificate chain with the message. The key would then encrypted with the
client public key (an maybe signed with the server private key, if you need
server authentication here).


Indeed, but that's not how TLS works. TLS is at the transport layer, not
the message layer. My point here is that EME forces you to have a key
delivery protocol that's message-based and precludes transport-level secure
authenticate channels.


Correct.

It also seems that even for message-based protocols, the EME only allow
one-shot message protocols, not multi-round (i.e there is only one Key Rest
/ Set Key per session).


No, you can have as many rounds as you need.




> : there is no way to have a direct authenticated TLS session between the
> DRM server and the CDM. Everything has to be proxied by the JS client,
> which precludes the use of TLS-based key delivery for DRM server
> scalability.
> Or are you suggesting that the EME model would allow someone "… to do that
> binding in your CDM"? If so, can you explain how that would work in the EME
> framework?
>
> While I do understand that you have a preference for proxy'ing messages
> through a single entry point in YOUR service architecture because you find
> that it works well for you, that's not a reason to force all other services
> to adopt the same architecture. By preventing the Marlin MS3 model to work
> within the EME framework as is currently stands, the EME model forces a
> whole existing ecosystem to radically change the way it currently operates.
>

As I explained, you can implement the direct DRM client to DRM server
messaging solution today without EME. EME is about enabling the
architecture I described. If Marlin doesn't want to work with that
architecture, noone is forcing it to.

An additional issue is that, unless I am mis-understanding, what you
propose requires the CDM to have socket access - not just access to the
browser HTTP stack. I say this because sending your request through the
browser HTTP stack would require that stack to have access to the client
credentials in order to establish the TLS connection. As soon as the client
credentials are outside the CDM, your security is lost.


Yes, the CDM implements its own TLS client endpoint and therefore needs
access to a TCP connection.


Which is a bas thing because it enables it to subvert browser security
measures such as the same origin policy.

...Mark



...Mark


>
> -- Gilles
>
>
> ...Mark
>
>
>>
>>
>> I would note that content protection  systems that interact directly with
>> license servers can be integrated into the video element without using EME
>> at all. For example Apple HLS supports a form of content encryption which
>> works in this way. The point of EME is to provide a uniform model so that
>> applications can easily support multiple DRMs.
>>
>> *Finally, for completeness, I should note that some DRM components
>> perform a one-off installation/initialization interaction with a server
>> maintained by the DRM provider, rather than the service provider. For this
>> reason such components may need network access.
>>
>> ...Mark
>>
>> Sent from my iPhone
>>
>> On May 7, 2013, at 5:35 AM, Gilles Boccon-Gibod <bok@bok.net> wrote:
>>
>> I found a video of a webinar given for the DTG group a month ago (
>> http://vimeo.com/62269279), where the speaker gives an overview of the
>> Encrypted Media Extensions.
>> There is one question that came up during the webinar regarding whether a
>> Key System implementation is "allowed" to interact directly with a DRM
>> server, without going through the user agent and application with a
>> keymessage event.
>> The speaker's response was that he wasn't sure whether it was
>> specifically forbidden or not, but that he couldn't see why it would be
>> needed.
>> He also mention in the talk that one of the goal of the EME spec was to
>> at least allow existing DRM systems to be supported through the proposed
>> architecture.
>> So I'd like to explain a concrete specific case for the Marlin DRM system
>> where the current EME architecture would be suboptimal, or at least require
>> an implementation to "cheat" a bit with regards to the intended use of the
>> keymessage/addkey workflow, which assumes that the communication between a
>> Key System and DRM servers can always be intermediated by the application
>> by passing it a keymessage to forward to the server and having the
>> application, then, relay the response in the addkey() call.
>> In the lightweight, "on-demand", mode of Marlin, called MS3, which is
>> often used when there is no persistent license delivered (a non-persistent
>> lightweight license is sent back to an authenticated client, just for use
>> within the context of a streaming session), the client needs a direct,
>> non-intermediated, communication with a server.
>> For scalability reasons, the protocol between the DRM client and the
>> server is based on a mutually-authenticated TLS session, not on a
>> signed/encrypted data payload that can be relayed (like a SOAP message
>> could be in the case of PlayReady for example). So there's no keymessage
>> that could be created by the Key System. The Key System must have a direct
>> TCP connection with the DRM server in order for the TLS handshake to be
>> done, and the response to be protected, end-to-end, from the server back to
>> the DRM client.
>> For Marlin MS3 to be used within the EME framework, I imagine that one
>> could circumvent the intent of the keymessage/addkey pattern, and pass in
>> the addkey() response (or the InitData of the createSession call) a payload
>> containing the URL of the DRM server which the DRM client must talk to, and
>> that the DRM client would simply go directly to the DRM server, bypassing
>> the application. That does not sound very clean.
>>
>> I'd love to hear what people on this email list think about this.
>>
>> Regards,
>>
>> -- Gilles
>>
>>
>>
>
>