Re: EME compatibility with existing DRM systems

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


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

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