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

Android DRM + WiDevine

Browse source
This commit is contained in:
Trolli Schmittlauch 2018-09-13 13:36:47 +02:00
parent 99dd83b1aa
commit ae2b40c693
3 changed files with 37 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

30
main.tex
View file

@ -26,7 +26,7 @@
pdfauthor={Oliver Schmidt},
breaklinks
]{hyperref}
%\usepackage{breakurl}
\usepackage{breakurl}
\newcommand{\comment}[1]{{\parindent0pt\fbox{\begin{minipage}{0.45\textwidth}{\em #1}\end{minipage}}}}
\newenvironment{changed}{\red}{\color{black}}
@ -171,7 +171,33 @@ As only userland code running in ring 3 can be run inside enclaves, relying on t
(InkTag?)
Android DRM, EME DRM arch, TBDRM (-> fTPM)
\section{Hardware Support for DRM systems}
So how can these hardware security mechanisms be used to support DRM mechanisms and make them run securely within a still open platform?
\subsection{Android DRM architecture}
The Android platform provides its own DRM framework\cite{AndroidDRMFramework}, providing an API for applications to communicate with a \textit{DRM manager} over \ac{IPC}. This DRM manager then runs plug-ins managing the actual DRM schemes as separate processes for isolation purposes. \\
The level of protection provided by the DRM plugin varies depending on the plugin itself and on the capabilities of the hardware platform. Plugins may rely on secure boot for a verified chain of trust from the firmware level on, use protected output mechanisms provided by the hardware platform and even run the programs inside a \ac{TEE}.
Plugins are automatically loaded when they are placed into the \texttt{/system/lib/drm/plugins/native/} directory. \\
One issue we see here is that there's no mention of authenticity checking of plug-ins mentioned in the documentatiion. \cite{AndroidDRMFramework} This can enable DRM plugins to claim to be able to decrypt a certain stream and thus at least result in the user not being able to decrypt their media with the proper add-on. Additionally it might also open up attack vectors for the communication with a license server, as shown later. \\
This might be the reason for the Android documentation to state that ``[t]he combination of hardware security functions, a trusted boot mechanism, and an isolated secure OS for handling security functions is critical to providing a secure device.'' \cite{AndroidDRMFramework}
One cross-platform DRM plugin solution is \textbf{WiDevine} \cite{googleWidevineDRMArchitecture2017}, currently owned by Google. It provides native solutions for the Android, iOS and HTML5 platform. Thus the \ac{DRM} decryption process is very similar to the one specified in HTML5 \acs{EME} and will be covered in section \ref{sec:HTML5_EME} in more detail. \\
The reason we look at the example of the WiDevine Android plugin is that it supports different security levels, depending on the use of hardware security mechanisms \cite{googleWidevineDRMArchitecture2017}: For security level 1, ``[a]ll content processing, cryptography, and control is performed within the Trusted Execution
Environment (TEE).'' This includes that even the decrypted video frames are to be passed to the graphics hardware using a secured mechanism. \\
This is not the case for security level 2: There only the cryptographic operations are done within a \ac{TEE}, but the decrypted video content is passed to processes running outside of a secure environment for further decoding, demuxing and postprocessing. But still all cryptographic keys remain secured within the \ac{TEE}. \\
And security level 3 is provided on devices without a \ac{TEE} at all, where ``[a]ppropriate measures may be taken to protect the
cryptographic information and decrypted content on host operating system'', which can be considered as a system-level lockdown.
\subsection{HTML5 EME}\label{sec:HTML5_EME}
\subsection{TBDRM}
Android DRM, EME DRM arch, TBDRM (-> fTPM), InkTag?
\section{lockdown/ openness}