13
Linaro Clear Key Implemented by: Matt Snoby Jan 2015 Revision 0.4

HKG15-407: Linaro Clear Key

  • Upload
    linaro

  • View
    251

  • Download
    1

Embed Size (px)

Citation preview

Linaro Clear Key Implemented by: Matt Snoby Jan 2015 Revision 0.4

Introduction CDM APIs. License / Key Exchange Provisioning What is a promise and how does it work? The Clear Key Implementation.

Linaro Clear Key CDM Class Class Relationships

OpenCDM Current state of the implementation Integrating 3rd Party DRM’s.

Introduction The goal of the Linaro external clear key implementations was for knowledge aggregation and a launch pad for future security offerings. Such things as decrypted buffer protection with ARM TrustZone® and integration with an external media engine (gstreamer) are examples where Linaro can help showcase current STB technology. This implementation will be open sourced for other developers to use as a reference.

CDM APIs. The implementation of the Chromium API of the Content Decryption Module (CDM) doesn’t look like what the EME picture looks like on the W3C webpage:

Specifically we do not see calls to Generate Request, License Request, etc in the API’s to the Chromium CDM implementation. The actual calls are methods such as: CreateSession, LoadSession, UpdateSession, CloseSession, RemoveSession. The picture really is a description from the point of view of the flow of information from the Javascript EME design, not the API calls of the CDM. This diagram ( with some details left out for brevity ) shows how the clear key conceptually works from the application to the decoded frame.

“A Key Session, or simply Session, provides a context for message exchange with the CDM as a result of which key(s) are made available to the CDM.”

1

Besides these CDM method calls that must be implemented, to decrypt content a decryptor object must be created. This object handles calls to add a key to the session and also extract keys from a JWK set, which is the format the license and keys are delivered in. The actual functionality of

2

decryption can be / should be ported to hardware acceleration. To be clear it is not necessary to implement a decryptor object as defined by chromium. As long as the CDM implementation properly handles the messaging events and promise callbacks the CDM can internally handle the decryption as it sees fit.

License / Key Exchange As the first paragraph of the EME spec says: “The API supports use cases ranging from simple clear key decryption to high value video (given an appropriate user agent implementation). License/key exchange is controlled by the application, facilitating the development of robust playback applications supporting a range of content decryption and protection technologies.” Once the Browser instantiates a CDM session (createSession), the CDM will fire a message to request to acquire a key from the license server. This does not go directly to the license server, this message is sent to the MediaKeySession in the browser then the application sends the message to the license server. Once the response from the server is obtained the response is sent to the CDM with the update message. The big difference between the existing embedded DRM systems of today and what the W3C is promoting is that all authentication and authorization functionality is now handled in the application, also no out of band communications or in other words direct communication can happen between the CDM (DRM system) and the licensing or other server ( ie secure gateway). This mentality is very different from the monolithic solutions that are currently promoted in the embedded DRM ecosystems. Systems such as Intertrust(R), PlayReady(R), Verimatrix and VideoGuard are examples that must be adapted to work with the EME specification. That’s not to say that these systems will not work with the EME specification, just that changes will have to be made to bring some logic out of the embedded key system and placed into the HTML5 / JavaScript application.

1 http://www.w3.org/TR/2014/WD-encrypted-media-20140828/#definitions 2 http://www.w3.org/TR/encrypted-media/#clear-key-license-format

Provisioning In current embedded DRM applications, provisioning of the hardware device is done in an out of band manner via calls between the DRM system and a secure server. For the EME spec this is not allowed. “The common API supports a simple set of content encryption capabilities, leaving application functions such as authentication and authorization to page authors. This is achieved by requiring content protection system­specific messaging to be mediated by the page rather than assuming out­of­band communication between the encryption system and a license or other server.” 3

Basically for privacy reasons the EME spec does not want any distinctive identifiers to be passed to the JavaScript application. However, distinctive identifiers that are encrypted can be sent to the CDM.

4

The data path must be through session messages. Once the CDM decrypts this distinctive identifier 5

the unencrypted distinctive identifier must never be shared outside of the CDM. Also for increased security the application must use secure transport (e.g. HTTPS) for all traffic containing messages from the CDM (e.g. all data passed from message events and update method calls). One final note, the distinctive identifier (or pairing data if you like) will be allowed to be reset by the user just like a cookie can be reset / deleted.

6

What is a promise and how does it work? Coming from an embedded background and jumping into the chromium source code had many nuances that I had never seen before, one of them was the concept of a promise. In its simplest form a promise represents the eventual result of an asynchronous operation. This is for scripting languages that need to know when an asynchronous operation has completed and what was the result of that operation. In the CDM implementation when a new session is created several function callbacks are registered with the promise_id. They are triggered automatically by the chromium cdmadapter code. Basically the implementer must register some function pointers for when certain operations have completed. For specific examples please see the chromium external clear key source code or the Linaro external key source code.

3 https://w3c.github.io/encrypted-media/ 4 https://w3c.github.io/encrypted-media/#definitions 5 https://w3c.github.io/encrypted-media/#encrypt-identifiers 6 https://w3c.github.io/encrypted-media/#allow-identifiers-to-be-cleared

The Clear Key Implementation. The call flows to decrypt data from the existing Linaro Clear Key implementation is shown in the sequence diagram below. The clear key implementation is a VERY simple implementation, it doesn’t support features such as persistent state sessions nor Server Certificates. Future enhancement to this design are to send the encrypted packets to a hardware decryptor and to send those decrypted packets via protected hardware to the hardware video decoder.

Linaro Clear Key CDM Class The Linaro Clear Key CDM is very much self contained in one source directory and implemented in an extended media class. Below you will find a UML diagram detailing the implementation that corresponds to the sequence diagram previously referenced.

Class Relationships

OpenCDM Fraunhofer FOKUS has created an open source implementation of a CDM interface, it has been tested against Microsoft PlayReady(R). The Fraunhofer FOKUS interface has added support for the media engine to authenticate itself to the DRM platform. That being said on an embedded system if the file system is readonly and the platform image is authenticated at boot, I wonder how necessary this feature is? The architecture notes for the OCDM (Open Content Decryption Module) : https://github.com/fraunhoferfokus/open-content-decryption-module/blob/master/docs/architecture_notes_ocdm.md Specifically the OCDM has 3 abstraction layers:

● Browser Glue ( implementation exists for Opera and Chromium) ● Core ● Communication

A more in-depth examination of running OCDM in chromium should be done. I would also note that having support for OCDM does not exclude support for the native chromium CDM at the same time. Multiple CDM’s can be available to the browser at once.

Current state of the implementation The Linaro Clear Key implementation has the same basic layout as the chromium external clear key implementation, however at this time there are no software decryptors and no video decoders implemented. It would be very easy to implement these features in software, however since the STB hardware is our target platform we need to implement platform software to target hardware acceleration. That being said the call flows are the same (just no decrypted video comes out the display). The next steps for the Linaro CDM should be the following:

● Move away from the DecryptandDecode implementation. This is how the initial work has been developed, the packets are decrypted and the decrypted frames are passed to the browser for rendering (via ffmpeg).

● Move away from the simple clear key implementation and use a simple DRM system that will have a license server so that keys can be fetched and the call flow is as close to real world as possible.

● Have the decrypted packets played back with gstreamer or some other media playback mechanism.

● Showcase the ability of the ARM TrustZone(R) to protect decrypted video buffers in a secure playback pipeline.

Integrating 3rd Party DRM’s. Integrating a third party DRM system such as VideoGuard or Verimatrix into an EME based solution is very much possible. Such has already been accomplished with solutions like Widevine and Playready. Some general steps that will be required for implementation include, but are not limited to:

1. A session based glue layer implemented on top of the DRM. 2. As previously described all communications to and from the secure server must happen through

the user agent ( web browser javascript app) in a secure https manner. No out of band communication is allowed.

3. A java script / html5 app must be written to do the authorization authentication and personalization of the connection. It must also proxy all communications to and from the CDM implementation.

4. All persistent sessions shall have to implement the CDM persistent memory API’s. These are just some of the changes that must be implemented to port an existing DRM system to a CDM / EME implementation.