Skip to content

Instantly share code, notes, and snippets.

@torgo

torgo/EME Opinion Draft.md Secret

Forked from twirl/EME Opinion Draft.md
Last active August 29, 2015 14:01
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save torgo/cdd9a994b92be9b4a678 to your computer and use it in GitHub Desktop.
Save torgo/cdd9a994b92be9b4a678 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 the current scheme, the CDM uses the browser (user agent) as a channel for transferring information to a third-party server and getting responses back. The scheme doesn't set any limit on what information could be sent and received; furthermore, the encryption algorithms used are intended to be kept secret.

This scheme exposes two kinds of potential risks.
1.1. Risk of spoiling private information via license requests. If the 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 a vulnerability in the encryption algorithm or if the License Server master key was compromised. 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 known method of attack against web users.

Coincidentally, the security problems are strictly related to architectural ones:
2.1. Using the CDM for user authentication and license checking is wrong from architectural point of view. Issuing license requests and checking responses is clearly not a responsibility of a Content Decryption Module. Obviously, the webapp must be capable of identifying the user and checking user permissions on its own behalf; why the decryption module needs to check the license is difficult to understand. Correct separation of concerns should limit CDM's responsibility to (a) establishing a 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. The 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, a proper scheme of CDM, user agent, and third-party servers interaction should be as follows.

  1. The CDM provides its cryptographic key material into system key storage upon installation.
  2. When the user requests some protected content, the webapp (a) authenticates the user and checks permissions; (b) prepares session information (user id, content id, session id, etc); (c) encrypts or signs session information with the CDM keying material; (d) derives public session key from the CDM keying material; (e) sends encrypted/signed session data and session key to the CDN.
  3. In response to such a request, the CDN generates a second public session key and (optionally) a public certificate and sends them back to the webapp; the webapp then attaches the key and certificate to the media element; the user agent passes the key and certificate to the CDM.
  4. The 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.)

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