schmittlauch
/
surveypaper-drm-tee
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

added section about Common Encryption

master
Trolli Schmittlauch 2018-09-19 22:31:53 +02:00
parent 9573c8ce69
commit eb1da93527
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
main.tex
View File

@ -208,6 +208,8 @@ After a \textit{keyadded/keyerror} event fired back to the web application indic
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}
One interesting side-note is that due to the usage of the \textit{ISO Common Encryption} standard for encryption of the media files, the same file can be decrypted by different \acp{CDM} implementing different \ac{DRM} schemes. As the license format and content of the encrypted byte buffers are proprietary, differing between various \ac{DRM} schemes, this requires the content provider to operate the respective license servers for each scheme. But having acquired a license, each \ac{CDM} can then decrypt the media file accordingly.
\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}). \\
@ -216,11 +218,9 @@ To prevent the leakage of the decrypted media during rendering and display, the
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 \\
\subsection{TBDRM}\label{sec:TBDRM}
Android DRM, EME DRM arch, TBDRM (-> fTPM), InkTag?
In 2009 Yu et al. have proposed a \ac{DRM} architecture based on \ac{TPM}, called \textit{TBDRM}. \cite{yuTBDRMTPMBasedSecure2009}
\section{shortcomings}\label{sec:shortcomings}