HTML5 EME DRM

glossary.tex

@@ -1,12 +1,16 @@
+\acro{API}{Application Programming Interface}
 \acro{CDM}{Content Decryption Module}
 \acro{DMCA}{Digital Millenium Copyright Act}
 \acro{DRM}{Digital Rights Management}
 \acro{EME}{Encrypted Media Extensions}
 \acro{IPC}{inter-process communication}
 \acro{OS}{operating system}
+\acro{PAVP}{Protected Audio Video Path}
 \acro{SGX}{Software Guard Extensions}
 \acro{SoC}{system on a chip}
-\acro{TPM}{Trusted Platform Module}
+\acro{TCB}{trusted computing base}
 \acro{TEE}{Trusted Execution Environment}
+\acro{TPM}{Trusted Platform Module}
 \acro{UEFI}{Unified Extensible Firmware Interface}
 \acro{WIPO}{World Intellectual Property Organization}
+\acro{W3C}{World Wide Web Consortium}

main.tex

@@ -193,14 +193,46 @@ cryptographic information and decrypted content on host operating system'', whic
 
 \subsection{HTML5 EME}\label{sec:HTML5_EME}
 
+To be able to provide DRM support for media content in the web, the \ac{EME} have been standardized by the \ac{W3C} \cite{w3cEncryptedMediaExtensions2017}.  \ac{EME} are not a \ac{DRM} system themselves, but provide a standardized javascript \acsu{API} for mediation between HTML5 media elements and so-called \acp{CDM}.  These \acp{CDM} are not standardized in \ac{EME} but are proprietary modules managing the actual \ac{DRM} scheme including license management, key retrieval, decryption and (optionally) decoding.
 
+In \cite{livshitsSecurityNativeDRM2015} Livshits et al. analyze current web browsers and their \ac{EME} implementations for potential vulnerabilities and propose an architecture to back \acp{CDM} with \ac{TEE}-usage – not only for higher security but also to fulfill the requirements of media publishers of having hardware-backed copy protection.
+
+\textbf{EME flow:} For the playback of \ac{DRM} protected media, information has to be exchanged between the web application and its media file, the \ac{CDM} and license/ key servers.  
+
+\begin{figure}
+ \includegraphics[width=0.49\textwidth]{figures/eme-sequence-diagram.png}
+ \caption{Sequence of information exchange between \ac{EME}\label{fig:EMEsequence} components, source \cite{livshitsSecurityNativeDRM2015}}
+\end{figure}
+
+First the browser's media stack parses the embedded media file and discovers the \textit{key id} emebdded into the media file's metadata.  This fires a \textit{needkeys} event including some initialization data to the web application which then creates the \textit{mediaKeys} and \textit{mediaKeySession} for a specific key system.  The initialization data is then pushed to a \ac{CDM} implementing the key system.  The \ac{CDM} then creates a \textit{keymessage} for a license server, which is then sent to the license server by the browser and of which the response is passed back to the \ac{CDM} to decrypt the received license and update the \textit{mediaKeySession}.  \\
+After a \textit{keyadded/keyerror} event fired back to the web application indicating the success status of the license retrieval, it can finally initiate the playback of the media file, causing the \ac{CDM} to decrypt it using the received license key.
+
+Hereby all javascript events fired from the \ac{CDM} to the web aplication contain byte buffers, which the web application running in browser context passes around and sends them to the respective servers.  But these byte buffers are usually encrypted by the \ac{CDM} and thus incomprehensible to the browser handling them. \cite{WhatEMEHsivonen}
+
+
+\textbf{Integration with a \ac{TEE}:}  The \ac{EME} standards only mandates the content decryption to take place in the \ac{CDM}, so the media file might as well be passed back to the browser's media stack for decoding and rendering.  Livshits et al. identified this as potential vulnerabilities of a \ac{DRM} scheme, as the decrypted media data might be easily grabbed from the browser context by abusing security vulnerabilities, adding add-ons (browser extensions) to the running browser or grabbing the content from pipes between the media stack's components. \cite{livshitsSecurityNativeDRM2015}  As I'm looking at the usage of \ac{DRM} in an as-open-as-possible system I'd like to add the possibility of just changing the source code of an available open source browser\footnote{both Chromium and Firefox are open source browsers supporting the EME standard} to additionally capture all media data passed back to it for decryption.  \\
+As a countermeasure, they propose to move both the \ac{CDM} as well as the whole media decoding and rendering stack to a \ac{TEE}, making the browser player part of the \ac{TCB}.  For that purpose they extend the \ac{EME} architecture by adding a \ac{CDM} proxy component running in browser context, which has to forward EME calls to the real \ac{CDM} running within the TEE.  They specify how to run the \ac{CDM} using Intel \ac{SGX} (see \ref{sec:SGX} or using ARM TrustZone (see \ref{sec:TrustZone}).  \\
+On systems with \ac{SGX}, the \ac{CDM} is launched inside a secure enclave created by the browser.\todo{maybe elaborate on launching SGX enclaves a bit}  When utilizing TrustZone, inside the normal world the browser notifies its \ac{OS} that the license- or metadata needs to be exchanged to the secure world.  Initiating a \textit{secure monitor call}, the data is transferred to the secure world where the \ac{CDM} can now create a license request or can decrypt the media content.  \\
+To prevent the leakage of the decrypted media during rendering and display, the media pipeline has to be secured as well.  In \cite{livshitsSecurityNativeDRM2015} this is done for the graphics pipeline by utilizing measures available on the respective hardware platforms:  On \textit{\ac{SGX} platforms}, \ac{PAVP} is used to create a video surface within the browser context.  From the \ac{SGX} context a \todo{``secure mechanism'' for key exchange to TEE mentioned but not specified} DXVA 2.0\todo{???} is used to exchange a key with the GPU with which the DRM-decrypted media content is reencrypted before being sent to the surface.  Inaccessible to the browser context, the media is decrypted and decoded directly on the GPU and then sent to the display device.\todo{secure tansmission to display device, HDCP}  \\
+The audio pipeline isn't mentioned, but with combined transmission of audio and video signals like in HDMI or DisplayPort we consider this covered as well.  \\
+On platforms with \textit{ARM TrustZone}, memory sections can be dedicated to the secure world only and device's access to these sections can be limited to certain devices.  This ability is used to store raw video frames, decoded in software running inside the \ac{TEE}, to be accessed by the GPU only.  Additionally, a session between the \ac{CDM} inside the TEE and the GPU can be authenticated with certificates, enabling video decoding directly on the GPU similarly to the approach taken on \ac{SGX} systems.
+
+- WiDevine quote \\
+- attacker model supposed to protect against reverse engineering/ tampering – but no countermeasures mentioned
+- how to identify against the licens server? -> attestation required
 
 \subsection{TBDRM}
 
 Android DRM, EME DRM arch, TBDRM (-> fTPM), InkTag?
 
+\section{shortcomings}
 
-\section{lockdown/ openness}
+\subsection{shortcomings on open systems}
+
+Both the WiDevine architecture \cite{googleWidevineDRMArchitecture2017} and the \ac{TEE}-backed HTML5 \ac{EME} approach leave an important attack vector uncovered:  It's not specified how \acp{CDM} authenticate against the license server they get the decryption key from.  While all information between the \ac{CDM} and the license server is encrypted and thus meaningless to the browser or other software in the middle of the communication, on an open system it should be possible to read, reverse-engineer and even manipulate the \ac{CDM} binary\footnote{under the \ac{WIPO} copyright treaty or the \ac{DMCA} this is illegal, but still technically possible}, as they have to be stored somewhere (SGX and TrustZone don't provide secure permanent storage) or transmitted to the computer for installation.  Livshitz et al. even mention reverse-engineering and manipulation in the security objectives of their paper \cite{livshitsSecurityNativeDRM2015}, but don't provide any countermeasures.  \\
+Encrypting the communication between \ac{CDM} and license server without parties in the middle being able to eavesdrop on the license key transfered is indeed possible, e.g. using a Diffie-Hellman key exchange for generating a session key\footnote{although this could become a bit cumbersome in HTML5 EME as the browser has to relay all steps of the key exchange before actual payload information can be sent}, the license server can't check the authenticity of the \ac{CDM} it's communicating with.
+
+\subsection{further downsides of DRM}
 
 What parts need to be locked down?
 

mybib.bib

@@ -168,9 +168,12 @@ This paper's contributions are a summary of the Intel-specific architectural and
   file = {/home/spiollinux/Zotero/storage/DWM7DMMX/netflix-use-of-google-drm-means-rooted-android-devices-are-banned-170515.html}
 }
 
-@misc{EncryptedMediaExtensions,
+@misc{w3cEncryptedMediaExtensions2017,
   title = {Encrypted {{Media Extensions}} - Www.W3.Org/},
   howpublished = {https://www.w3.org/TR/encrypted-media/},
+  author = {{W3C}},
+  month = sep,
+  year = {2017},
   file = {/home/spiollinux/Zotero/storage/SITPHQSQ/encrypted-media.html}
 }