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

346 lines
41 KiB
TeX
Executable file
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

\documentclass[10pt,conference,twocolumn,final,a4paper]{IEEEtran}
\usepackage{ifluatex}
\ifluatex
\usepackage{fontspec}
\defaultfontfeatures{Ligatures=TeX} % To support LaTeX quoting style
%\setromanfont{Vollkorn}
\else
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\fi
\usepackage{clrscode}
\usepackage{xcolor}
\usepackage[]{graphicx}
\usepackage{acronym}
\newcommand{\documenttitle}{Here be dragons}
\newcommand{\abstracttext}{Abstract goes here}
% set pdf metadata
\usepackage[
pdftitle={\documenttitle},
pdfauthor={Oliver Schmidt},
breaklinks
]{hyperref}
\usepackage{breakurl}
\newcommand{\comment}[1]{{\parindent0pt\fbox{\begin{minipage}{0.45\textwidth}{\em #1}\end{minipage}}}}
\newenvironment{changed}{\red}{\color{black}}
\newcommand{\todo}[1]{ \color{red} \footnote{ \color{red}[#1] \color{black}} \color{black}}
\newcommand{\Hide}[1]{%
{
\parindent0pt
\emph{\scriptsize #1}
}
}
%\renewcommand{\Hide}[1]{}
\pagenumbering{arabic}
\begin{document}
%----------------------------------------------------------------------
% Title Information, Abstract and Keywords
%----------------------------------------------------------------------
\title{\documenttitle}
% % %
% In case of double blind submissions:
%\author{
% \IEEEauthorblockN{Anonymous}
% \IEEEauthorblockA{Some Research Group\\
% Some Institution\\
% Some Email Addresses%
% }
%}
\author{
\IEEEauthorblockN{Oliver Schmidt}
\IEEEauthorblockA{TU Dresden\\
oliver.schmidt3$[$at$]$mailbox.tu-dresden.de%
}
}
\maketitle
% force pagenumbering
\thispagestyle{plain}
\pagestyle{plain}
% % %
% sources on writing papers:
% look for a /good/ outline at the end of this text, the /why/ is found at this link:
% http://homepages.inf.ed.ac.uk/bundy/how-tos/writingGuide.html
% http://www-net.cs.umass.edu/kurose/writing/
% http://www.cs.columbia.edu/~hgs/etc/writing-style.html
% Read ``Zen - or the art of motorcycle maintenance'' to understand what science and research is
% Read ``The craft of research'' to /really/ learn how to conduct research and report about it! :-)
% some hints on plagiarism: http://www.williamstallings.com/Extras/Writing_Guide.html
% read the text above again. the most important part (that we all tend to forget) is only 5 paragraphs
\begin{abstract}
\abstracttext
\end{abstract}
\begin{IEEEkeywords}
% Are NOT: Peer-To-Peer, Anonymity, Privacy.
% BUT TAKEN FROM THIS LIST:
% http://www.ieee.org/organizations/pubs/ani_prod/keywrd98.txt
Security, DRM, Trusted Execution Environments, SGX,
\end{IEEEkeywords}
% }
\maketitle
\IEEEpeerreviewmaketitle
\section{Introduction}
\IEEEPARstart{S}{ince} early on in the so-called ``information economy'', publishers have tried to limit the distribution of their digital goods to the buyers only. In his keynote ``The coming war on general computation'' at the 28th Chaos Communication Congress \cite{corydoctorowComingWarGeneral2011}, Cory Doctorow outlines the development of copy-protection mechanisms from first including uncopyable bad sectors to the floppy disks on which programs were distributed or tying the execution to dongles and license keys, to encrypted music and video files protected with dedicated \ac{DRM} schemes. \\
But these attempts were mostly based on obscuring the protection mechanism used, thus being vulnerable to circumvention through reverse-engineering, patching out the protection mechanism or retaining the supposedly-secret media decryption keys even after the usage license expired. The renowned IT security collumnist and expert Bruce Schneier commented on these attempts: ``Digital files can not be made uncopyable, any more than water can be made not wet.'' \cite{bruceschneierCryptoGramMay152001} The underlying vulnerability of all these copy protection schemes was that they were attempting to ``[\dots] figure out how to stop computers from running certain programs and inspecting certain files and processes.'' \cite{corydoctorowComingWarGeneral2011} But as modern day computers are mostly general computation machines, they are inherently based on copying data and computing on them.
Doctorow warns that all countermeasures trying to ensure copy protection of digital content are going to result in creating ``appliances'', which are still general purpose computers, but locked down with ``some combination of rootkits, spyware, and code-signing to prevent the user from knowing which processes are running, from installing her own software, and from terminating processes that she doesn't want.'' \cite{corydoctorowComingWarGeneral2011} \\
Additionally, international agreements based on the \ac{WIPO} Copyright Treaty \cite{worldinternationalcopyrightorganizationWIPOCopyrightTreaty1996}, its most prominent implementation being the US-American \ac{DMCA}, make the circumvention of ``technical protection measures'' such as \ac{DRM} illegal.
So right now we are in a situation, where all major publishers of e.g. video\footnote{all Hollywood movie publishers require adhering to certain protec standards like \cite{movielabsinc.MovieLabsSpecificationEnhanced2018}} and audio\footnote{although legal music file purchases are mostly \ac{DRM}-free, the consumption model of streaming has brought back DRM to platforms like Spotify or Deezer} content, and video games\footnote{Valve's Steam platform integrates its own DRM into sold games; other publishers as well as gaming consoles have their own DRM systems as well}. Thus right now, all software using this content has to be proprietary and whole platforms are being locked down more and more. This development is most apparent in non-PC platforms like mobile devices, where unlocking the bootloader (if even possible) results in deletion of \ac{DRM} keys of the device. \cite{sonydeveloperworldUnlockBootloaderOpen}
But in recent years modern CPU architectures have introduced special hardware-backed \acp{TEE} to provide a secured environment for security-critical code to be executed in isolation from the main \textit{untrusted} \ac{OS}. Can these TEEs and other special hardware trust-anchors provide the possibility to present \ac{DRM}-secured content in an otherwise open and open source system, not having to lock it down completely?
\todo{outline}
% % %
% Literature Survey and Background
\section{Background: Trust Anchors and Trusted Execution}
\label{sec:background}
This section first gives an overview about technologies used for having a trust anchor in a running system. Though these approaches are often used for locking down whole systems, they may also provide the basis for building more open systems with a \ac{TEE}. \\
Afterwards we cover the technologies dedicated to provide a \ac{TEE} in modern processor architectures.
\subsection[SecureBoot]{UEFI Secure Boot}\label{sec:SecureBoot}
\textit{Secure Boot} is a functionality of the \ac{UEFI} boot firmware component \cite{unifiedefiforuminc.UEFISpecificationVersion2017} to allow only the launch of authenticated boot images. To achieve that, boot images can be signed with X.509 certificates. Only if the image verifies correctly against a key stored in non-volatile firmware memory or against an entry in an explicit allow list of signatures. This first check on which bootloader or \ac{OS} image to launch can be the anchor of a trust chain, if each consecutive execution step also checks the authenticity of software to be launched. The allow and deny lists can be updated from the running \ac{OS} and deploying own custom platform keys for verification can be possible through setup-mode of \ac{UEFI}.
Firmwares adhering to the \ac{UEFI} standard are the dominant system software for the PC platform (including x86 devices like servers, laptops and mobile devices, but also more and more devices with ARM chipsets). Microsoft has been criticized for requiring devices \cite{MicrosoftHardwareCertification2014} shipped with the Windows \ac{OS} to have Secure Boot enabled by default, verifying boot images against Microsoft's key, mentioning that this could lead to lock-down of consumer hardware and the inability to install alternative operating systems on it. \\
Earlier versions of the requirements mandated an option to disable Secure Boot on x86 devices while also mandating that it must always be enabled on ARM-based devices. \cite{moodyMicrosoftBlockingLinux} Nevertheless complete lockout of other operating systems doesn't seem to be imminent at least on x86 devices as there is a shim bootloader signed by Microsoft \cite{matthewgarrettAnnouncingShimReview}, enabling the launch of other unsigned boot images. The signature of this specific binary could though be put on the firmware's deny list through updates.
\subsection{TPM}\label{sec:TPM}
\acp{TPM} are dedicated hardware components offering a variety of security services to a system \cite{197213}: \\
\acp{TPM} provide \textbf{secure storage} inside the module to store sensitive data like cryptographic keys in such a way that it can't be leaked to or stolen from processes running on the main CPU. \\
These stored keys can be used to execute cryptographic operations on behalf of the system, without the keys getting transferred to the outside of the module. \\
The \textbf{attestation} functionality can attest the identity of software by calculating a hash sum of the supplied binary, signing it with its internal key to prove a certain system configuration or software version to third parties having a corresponding verification key. When pre-deployed with a unique key, all previously mentioned functionality can be combined to provide a \textbf{unique machine identity} and form a hardware trust anchor for running systems. \\
A \textbf{continuous trust chain} can be built from the boot-up on if all software components, starting from the firmware on, let the \ac{TPM} attest the processes to be launched and compare these attestations with the ones stored previously in the module's secure storage. A similar boot policy is \textit{authenticated booting}, where the \ac{TPM} calculates the checksum of each boot stage but doesn't enforce any signature checks but only stores the results inside its secure internal registers, from where the system status can be queried later on.\cite{hartigLateralThinkingTrustworthy2017} In contrast to UEFI Secure Boot (\ref{sec:SecureBoot}), it is also possible to securely attest and launch code using special \textit{late-launch} CPU instructions introduced into AMD and Intel chipsets without providing a continuous trust chain from the firmware on \cite{hartigLateralThinkingTrustworthy2017}. \\
Additionally, \acp{TPM} provide important support functionality cryptographic algorithms like \textbf{secure counters}, a \textbf{secure clock} for peripherals and a \textbf{secure source of entropy}. \cite{197213}
\subsection{Trusted Execution Environments}
To allow separating the execution of security critical code from the large untrusted codebase of the rest of the system, all major processor vendors have intruduced so called \acp{TEE}. These are separated co-processors, either dedicated or virtualized, providing a computing environment with at least its own computing resources, registers and memory (areas) isolated from the untrusted parts of the running system.
This section is mostly not based on the vendor's refrence manuals but on other papers reviewing the apllicability of such environments. \cite{hartigLateralThinkingTrustworthy2017,197213,livshitsSecurityNativeDRM2015}
\subsubsection{ARM TrustZone}\label{sec:TrustZone}
\textit{ARM trust zone} \cite{armlimitedARMSecurityTechnology2005} is a set of security extensions for processors, currently available for the ARMv8 architecture. Additionally, the processor vendor AMD has announced to include TrustZone co-processors into some of their x86 processors. It divides the physical processing environment into two separate \textit{worlds} that can be switched. The \textbf{secure world}, being the initial processor state after reset, and the \textbf{normal world}, where all legacy and non-critical code is run. Each world provides its own runtime environment with (virtually) dedicated registers, memory, processor, caches and interrupts. Additionally, each world runs its own operating system, with general purpose \acp{OS} running in the normal world, while the secure world tends to use special purpose \acp{OS} like the \textit{Trusty OS} \cite{TrustyTEE} used by the Android OpenSource Project.
How these dedicated virtual resources are actually backed by physical depends on the implementationof the \ac{SoC}. Resources can either be strongly partitioned (e. g. memory), shared between worlds (often the case for caches, processor) or assigned exclusively to one of the worlds (most I/O devices, separate register banks). \\
The memory is strongly partitioned on boot-up, rendering the worlds inaccessible to each other. This memory isolation is supported by marking the secure world with an additional bit at the hardware level. \\
Communication between the worlds is made possible by the \textit{secure monitor} processor mode, controlled by a dedicated register. This monitor mode can implement context switches between the worlds as it can access copies of non-secure registers from the secure context. ARM CPUs always boot first into the secure world and hand over control to the non-secure world after initialization. Later on, the normal world can use a special \textit{secure monitor call} instruction to give control to the secure monitor mode, performing a context switch. Interrupts can directly map into the secure monitor mode.
With the memory only being separated but not encrypted, TrustZone's security relies on having a connection to its memory which can't be eavesdropped upon.
\subsubsection{Apple SecureEnclave Processor}\label{sec:SecureEnclave}
Although Apple's own \acp{SoC} use the ARM architecture, the company has decided to use their own secure co-processor solution instead of TrustZone (\ref{sec:TrustZone}). Their \textit{Secure Enclave Processor} is a dedicated processor, running an L4 microkernel, communicating with the main CPU over a bus system and accessing the system's memory using inline-encryption. \cite{hartigLateralThinkingTrustworthy2017}
\subsubsection{Intel SGX}\label{sec:SGX}
Intel's \acf{SGX} are a method to launch multiple trusted components into their own fully isolated \textit{enclaves} and thus, according to \cite{hartigLateralThinkingTrustworthy2017}, can be seen as a more advanced version of the late-launch approach (\ref{sec:TPM}).
Enclaves can be scheduled by the OS like normal processes, but code and memory of enclaves are only visible from the inside. Enclave memory resides in the common system's DRAM but is transparently encrypted. \\
Additionally, \ac{SGX} includes attestation of code running within an enclave similar to \ac{TPM}, but itself doesn't provide secure storage or other \ac{TPM} features. \\
As only userland code running in ring 3 can be run inside enclaves, relying on the \ac{OS} for scheduling and resource management, \ac{SGX} is vulnerable to side-channel attacks \cite{peinadom.ControlledChannelAttacksDeterministic2015}.
\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}\label{sec:AndroidDRM}
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. \\
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.
The architecture overview doesn't mention how to persistently store the acquired decryption keys. At the same time we know that apps\footnote{example: Netflix for Android \url{https://help.netflix.com/en/node/54816}} are offering functionality like an offline mode, requiring persistent storage of keys.
\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}
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}). \\
On systems with \ac{SGX}, the \ac{CDM} is launched inside a secure enclave created by the browser. 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 DXVA 2.0\footnote{\textit{DirectX Video Acceleration}, a proprietary API available on Microsoft Windows and Xbox} 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. \\
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.
\subsection{TBDRM}\label{sec:TBDRM}
In 2009 Yu et al. have proposed a \ac{DRM} architecture based on \ac{TPM}, called \textit{TBDRM}. \cite{yuTBDRMTPMBasedSecure2009} Their approach relies on multiple components checking each others authenticity, relying on the attestation functionality of \ac{TPM} for constructing a hardware trust chain and authenticity checking, and on \ac{TPM} key management functionality for binding content to a certain player component.
\begin{figure}
\includegraphics[width=0.49\textwidth]{figures/tbdrm_high_level_arch.png}
\caption{high-level architecture of TBDRM components, source: \cite{yuTBDRMTPMBasedSecure2009}}\label{fig:TBDRM_arch}
\end{figure}
The high-level architecture of TBDRM is outlined in Fig. \ref{fig:TBDRM_arch}. The encrypted content itself can be delivered independently from the license, which consists out of a usage policy for the content, its decryption key and some metada for describing and identifying the matching content. \\
The trust basis for all other client components is provided by the \textit{\acl{AA}}. This component can attest the authenticity and identity of the \textit{\ac{VC}}, which ensures and attests freshness of a license, the \textit{\ac{DC}} handling the actual content decryption and policy enforcement, and the actual media \textit{player} component. \\
When requesting a license, the \ac{LD} decides whether to give a license based on the attested identity of the \ac{DC} and the license version requested. At playback, the trustworthyness of the player component is first attested to the \ac{DC} by the \ac{AA}, the same is done for the \ac{VC} afterwards. If all components are trustworthy to the \ac{DC} and the \ac{VC} also has verified the freshness of the license, the \ac{DC} checks the requested usage permission against the usage policy of the licenses. If access can be granted, the media content is decrypted with the symmetric key provided by the license and passed to the player. If the usage policy mandates a version bump of the license (e. g. for enforcing a playback number limit), this is done by the \ac{VC} after playback.
For implementing this architecture, the authors proposed using several \ac{TPM} functionality for ensuring the security (persistent control of content, license integrity/ confidentiality/ freshness) of the DRM system. \\
In their prototype they ensure a \textbf{trust chain} from the boot on to each DRM scheme component by measuring each system boot step, starting at the hardware trust anchor provided by the \ac{TPM}. Measuring means the \ac{TPM} computing the hash of a component and storing the result into its internal platform configuration registers, from where it can be retrieved later. First the \ac{TPM} measures the hardware platform configuration, the bootloader containing a \textit{kernel measuring agent} and the kernel containing an \textit{application measurement agent} serving as the \ac{AA} component. A full trust chain can then be established by checking all component's measurements from the respective \ac{TPM} registers. Additionally the kernel contains the \ac{VC} component and the part of the \ac{DC} responsible for verifying the trustworthyness of all other components, turning all components of the system stack from the hardware to the kernel itself into parts of the \acl{TCB}. The player itself and the \ac{DC} part responsible for interpreting and deciding on policy rules are running in the user-space and are isolated from each other. The application measurement agent and the user-space \textbf{isolation} are done based on a Linux Security Module running in the kernel, the latter by preventing processes from accessing other processes address space e. g. using ptrace. \\
The \textbf{bind mechanism} for making license data only accessible to certain components is based the \ac{TPM} key management mechanism \textit{immigratable key} and \textit{key certification}. For binding a license to the current \ac{DC}, a new immigratable asymmetric keypair is created. When acquiring a license, the public key of that pair is certified by the \ac{TPM} and sent to the \acl{LD}. After verification, the \ac{LD} uses hybrid encryption for the license data by encrypting it symmetrically with a fresh key and encrypting that key asymmetrically with the received public key of the client. Thus the sent-back license can only be decrypted and used by the trusted \ac{DC}. The TBDRM proposal doesn't specify whether licenses can be saved to persistent storage. \\
\textbf{Freshness} of licenses is ensured within the \ac{VC} by using the monotonic counters of the \ac{TPM}. The state of each counter is bound to the \ac{VC} and can be stored on disk for persisting. The paper itself does not go into detail which cryptographic algorithms are used for persistence, we want to emphasize the usage of authenticated encryption for storing such counter values. Malleable or unauthenticated encryption like plain RSA would not be sufficient for storing such a small, easy guessable counter value.
The TBDRM paper builts on hardware \acp{TPM} conforming to the TPM 1.2 specification. This version of TPM has been deprecated for several years now due to its cryptographic algorithms having become less secure and its different implementations being ambiguous. The successing version of the specification, TPM 2.0, is backwards incompatible but provides roughly the same functionality. Thus porting the TBDRM approach to work with TPM 2.0 should be doable. \\ A TPM 2.0 based variant of TBDRM can also become interesting for vendors not wanting to include a dedicated TPM chip into their device, but having a CPU with \ac{TEE} functionality: With \textbf{fTPM} \cite{197213} Microsoft researchers have presented an implementation of the TPM 2.0 specification using \aclp{TEE}, specifically ARM TrustZone (described in \ref{sec:TrustZone}) as their basis, complemented with some additional hardware components. They first analyze the shortcomings of \acp{TEE} compared with the functionality provided by \acp{TPM}. The shortcomings of the ARM TrustZone \ac{TEE} relevant for TBDRM are its lack of secure storage (required for key storage), lack of secure persistent counters (used by the \ac{VC}) and lack of secure entropy source (used for key generation). For overcoming these shortcomings, they took different approaches:
\begin{itemize}
\item \textit{adding additional hardware}: replay-protected, authenticated storage (eMMC with replay-protected memory block), hardware fuses available only to the secure world as seeds for key generation, a physical entropy generator
\item \textit{design compromises}: no long-running \ac{TEE} processes to increase system stability -- cooperative checkpointing for splitting up RSA key generation into multiple short steps
\item \textit{modified TPM 2.0 semantics}: changing semantics of services slightly while still maintaining verifiable security guarantees
\end{itemize}
As fTPM requires additional hardware components to be included already during system design, it can not be applied to existing devices lacking these components. But if these small additional requirements are taken care of during system design, hardware-complemented \ac{TEE} features of modern CPUs can provide TPM-compliant services. This is the case on all ARM-based devices by Microsoft shipped with the Windows \ac{OS}, where the required TPM functionality is provided by fTPM.
\section{Shortcomings}\label{sec:shortcomings}
\subsection{shortcomings on open systems}
As the aim of this paper is to evaluate the feasibility of providing \ac{DRM} protection on otherwise open platforms, in this section we look at what security challenges arise for the presented DRM architectures, which parts of the system need to be secured and which of these can remain open.
\subsubsection{authentication at license server}
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. \\
Although encrypting the communication between \ac{CDM} and license server without parties in the middle being able to eavesdrop on the license key transferred 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. Including a private authentication key into the \ac{CDM} binary is insecure as the key could be recovered from attackers by reverse engineering. And if there's no need to authenticate the \ac{CDM} against the license server or modified \acp{CDM} are still able to do that using an extracted private key, a modified \ac{CDM} can either deliberately leak the key or the decrypted content to the untrusted \ac{OS}.
As a countermeasure we suggest the usage of attestation mechanisms provided e. g. remote attestation of \ac{SGX} or (f)\ac{TPM} to verify the integrity of the used \ac{CDM}. Especially for SGX though this is only a starting point and special care needs to be taken for remote attestation to be successful, as pointed out in \cite{swamiyogeshIntelSGXRemote2017}.
The Android DRM framework seems to put emphasis on locking down the whole system with a trusted boot chain instead, as stated in the Android documentation: ``The 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} \\
This is also apparent in the light of several apps using the Android DRM framework not being available on rooted devices. One example is the Netflix app, which uses the WiDevine DRM scheme. \cite{corvindavenportNetflixConfirmsIt2017} This app can not be installed from the Play Store\footnote{Google's app store for the Android platform, by far the most popular one and default on Google-certified devices} on rooted Android devices, though already installed apps or ones installed through side-loading still continue to function. This is the case because installation from Play Store for this app is tied to the device's \textit{SafetyNet} status, which tries to detect tampering with the device's software. The Android DRM framework itself though also offers \acp{API} for getting the security status of a DRM plugin (see \ref{sec:AndroidDRM}), including whether a DRM plugin fully uses the \ac{TEE} of a device. Due to the ambiguous restriction enforcement it remains unclear whether banning the store installation of such apps on rooted devices is a sign of Google not fully trusting the security of \ac{TEE}-backed DRM even on open devices or if this is just a side effect of administrational policies of the store. But at least this is not a sign pointing towards the acceptance of \ac{DRM} on open platforms.
\subsubsection{size of the \acl{TCB}}
The advantage of the approaches where \aclp{CDM} run inside a \ac{TEE} is that, given the \ac{TEE} technology itself is secure, authentication issues like the ones just described can be overcome and the cryptographic primitives used are semantically secure, only the \ac{TEE} running the (proprietary) CDM itself is part of the \ac{TCB}. All other software on the untrusted (virtual) processor, even the operating system, might be modified freely as all sensitive data (plain content, cryptographic keys) are never accessible outside of the secured environment. When using ARM TrustZone though, care needs to be taken of other code running within the secure world. As there is only one secure world available, all programs running within the \ac{TEE} have to share the same environment, on top of a special purpose operating system like the Trusty \ac{OS} \cite{TrustyTEE} used on Android devices. There, processes running on top of the \ac{OS} are isolated from each other via address space separation, utilizing the \ac{MMU}. So at least the \ac{CDM} and the trusted \ac{OS} it is running on are part of the \ac{TCB}. In the case of Trusty, even all processes running on top are bundled with the \ac{OS}, signed, and then verified by the firmware at boot similarly to Secure Boot. And still all vulnerabilities in code belonging to the \ac{TCB} are potentially security critical if exploitable, one example of it shown with a vulnerability in the \ac{TEE} \ac{OS} itself. \cite{shenExploitingTrustzoneAndroid2015}
For the TBDRM approach though the size of the \ac{TCB} is even larger, including the whole kernel and TBDRM's userland components. Firmware and bootloader are part of the trust chain and must not be modified for the DRM system to work, but are not a crucial part of the \ac{TCB} as the kernel running on top is measured by the \ac{TPM} independently. All of this requires a trustworthy \ac{TPM} implementation. \\
As measured boot is used, modified software components are not prevented from running but the DRM functionality would not work on systems not identified as trustworthy. Thus a dual-boot system can be imagined, where in one of the systems the kernel can be freely modified while loosing the ability to play DRM secured content, while the unchanged other system retains the ability of DRM-protected playback.
\subsubsection{media output on peripherals}
The secured rendering pipeline used in \ref{sec:HTML5_EME} only reaches to the GPU. But how to transfer the decoded audio and video data to the actual display device and speakers? \\
For directly attached screens on devices like smartphones, tablets or laptops relying on the display bus being physically hard to eavesdrop on might be a valid compromise. But as soon as it comes to attaching external display devices over standardized connectors (HDMI, DVI, DisplayPort) direct output grabbing becomes a threat. With these video output standards transmitting digital data, the quality loss during grabbing is neglectable. The state-of-the-art mechanism for DRM protection during transmission is \ac{HDCP}, which encrypts the content on its way to the display device. But with the master key having leaked and decryption hardware being available \cite{DBLP:conf/reconfig/LombG11}, \ac{HDCP} can be considered as broken.
\subsection{further downsides of DRM}
What parts need to be locked down?
WiDevine/ Netflix ban from rooted devices
- remaining other problems: cultural heritage, inflexibility, tied to a certain technological platform
valid copyright exceptions (private copy, quotation) are prevented
Doctorows Law: "Anytime someone puts a lock on something you own, against your wishes, and doesn't give you the key, they're not doing it for your benefit."
tracking, Mozilla
\section{Summary}
% % %
% Theory (probably)
\section{Glossary}
\label{sec:glossary}
\nobreak
\begin{acronym}[GN6ASL]
\input{glossary.tex}
\end{acronym}
\bibliographystyle{IEEEtran}
\bibliography{mybib}
%----------------------------------------------------------------------
\end{document}
% % %
% A good outline for a computer science paper (according to Al Bundy)
%
% Title
% * - ideally the title should state the hypothesis of the paper
%
% Abstract
% * - state hypothesis and summarise the evidence that supports or refutes it
%
% Introduction
% * - motivate the contribution!
%
% Literature Survey
% * - broad and shallow account of the field, rival approaches, drawbacks of each, major outstanding problems
%
% Background
% * - states previous work in more detail, where this is necessary for understanding
%
% Theory
% * - underlying theory, definitions, theorems etc.
%
% Specification
% * - requirements and specs of implementation
%
% Implementation Evaluation Related Work
% * - narrow but deep comparison with main rivals
%
% Further Work Conclusion
% * - summarise research, discuss significance, restate hypothesis and the evidence for and against it, - recapitulate original motivation, reassess the state of the field in the light of this new contribution
%
% Appendices
%
Reference in a new issue View git blame Copy permalink