Skip to content

Instantly share code, notes, and snippets.

@twirl

twirl/EME Opinion Draft.md Secret

Last active August 29, 2015 13:57
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save twirl/9483deeb93d134ad2aa8 to your computer and use it in GitHub Desktop.
Save twirl/9483deeb93d134ad2aa8 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
EME Opinion Draft.md

This is informal EME Opinion Draft proposed by Sergey Konstantinov. It is neither official nor informal TAG opinion on subject. Draft under discussion

There are two major problems in current EME design.

  1. Security and privacy issues.
  2. Architectural issues.

In current scheme CDM uses browser as a channel of transferring information to third-party server and getting responses back. The scheme doesn't set any limit on what information could be sent and received; furthermore, encryption algorithms are intended to be kept in secret.

This scheme exposes two kinds of potential risks.
1.1. Risk of spoiling private information via license requests. If license request contains any kind of information unknown to user agent (including CDM versions and hardware support information, which could be used for fingerprinting), it could be extracted if there was either vulnerability in encryption algorithm or compromise of License Server master key. Such problems occurred previously with browser extensions (for example, user MAC address sniffing via Java applet).
1.2. Risk of exploiting vulnerabilities in response parsing code. Since license response formats are to be kept in secret, CDMs will have proprietary response decrypting algorithms which could be compromised, thus creating a vector of attack via malformed license response. This kind of vulnerability (malformed proprietary data format) is a main method of attacking web users nowadays.

Coincidentally, security problems are strictly related to architectural ones:
2.1. Using CDM for user authentication and license checking is wrong from architectural point of view. Issuing license request and checking response are clearly not a responsibility of Content Decryption Module. Obviously, webapp must be capable of identifying user and checking user permissions on its own behalf; why decryption module needs to check license is very hard to understand. Correct separation of concerns should limit CDM responsibility to (a) establishing secure channel to third-party server (CDN), (b) decrypt frames. So, in fact, there is no need in either license request or response, both could be easily replaced with handshaking.
2.2. EME proposal specifies some objects and interfaces (notably MediaKeys) which are already defined in WebCrypto API, and exposes its own APIs instead of relying on underlying low-level system capabilities. Conversely, using standard system key storage and encryption algorithms could significantly decrease risks of exploitation of possible CDM vulnerabilities.

So, our recommendations are:

  1. Eliminate possible security and privacy issues by replacing license request and response with exchanging of standardized public keys and certificates.
  2. Replace custom data structures (MediaKeys, KeySystem) with corresponding WebCrypto entities.
  3. Rely on system key storage instead of using CDM itself.
  4. Exclude those parts of spec related to authenticating and permission checking since they could be easily implemented without exposing additional APIs.

In our opinion, proper scheme of CDM, user agent, and third-party servers interaction scheme should be like follows.

  1. CDM provides its cryptographic key material into system key storage upon installation.
  2. When user requests some protected content, webapp (a) authenticates user and checks permissions; (b) prepare session information (user id, content id, session id, etc); (c) encrypt or sign session information with CDM keying material; (d) derive public session key from CDM keying material; (e) send encrypted/signed session data and session key to CDN.
  3. In response to such a request CDN generates second public session key and (optionally) public certificate and sends them back to webapp; webapp attaches key and certificate to media element; user agent passes key and certificate to CDM.
  4. User agent streams encrypted frames from CDN to CDM to be decrypted using passed session key and redirected to video output.

Any additional functionality, if needed, should be implemented as a part of corresponding low-level APIs (WebCrypto, Streams, etc.)

@torgo
Copy link

torgo commented May 15, 2014

I have made some minor editorial changes in a fork here: https://gist.github.com/torgo/cdd9a994b92be9b4a678

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment