HKG15-407: EME implementation in Chromium: Linaro Clear Key --------------------------------------------------- Speaker: Matt Snoby Date: February 12, 2015 --------------------------------------------------- ★ Session Summary ★ An example of a key system from a Clear Key point of view. Linaro implemented a sample CDM plugin for Chromium capable to exercise the EME implementation of the browser. The presentation gives an insight to the EME/CDM implementation in Chromium and the guidelines to integrating various DRM systems. We will present call flows with example classes, experiences learned, and example of things to watch out for. -------------------------------------------------- ★ Resources ★ Pathable: https://hkg15.pathable.com/meetings/250835 Video: https://www.youtube.com/watch?v=dJqCbTfKrMk Etherpad: http://pad.linaro.org/p/hkg15-407 Also see presentation: http://www.slideshare.net/linaroorg/hkg15407-eme-implementation-in-chromium-linaro-clear-key-44732418 --------------------------------------------------- ★ Event Details ★ Linaro Connect Hong Kong 2015 - #HKG15 February 9-13th, 2015 Regal Airport Hotel Hong Kong Airport --------------------------------------------------- http://www.linaro.org http://connect.linaro.org

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

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

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

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

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

6. “​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

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

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

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

10. Class Relationships

11. 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_n
otes_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.

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

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