Surveypaper for the lecture "Influential OS Research", dealing with hardware support (trusted execution environments" for DRM
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

354 lines
49 KiB

\defaultfontfeatures{Ligatures=TeX} % To support LaTeX quoting style
\newcommand{\documenttitle}{Hardware Support for DRM: Can Trusted Execution Environments save us from System Lock-down?}
\newcommand{\abstracttext}{Nowadays, all major publishers of popular media content mandate the usage of DRM copy protection for their published works. But as preventing digital content from being copied is a difficult problem, the current approaches for copy protection involve locking down systems, criticized as endangering general computation and user freedom. \\
This survey looks at the available hardware support technologies for providing hardware trust anchors or trusted execution environments, ranging from Secure Boot and TPM to Intel SGX and TrustZone, and evaluates their usage in the DRM architectures of Android and the HTML5 EME browser stack. Showing shortcomings in authenticity checking of components, different levels of required lock-down, and output protection of all covered architectures, we find that the usage of trusted execution environments reduces the required system lock-down for DRM protection. But many other negative effects of DRM can not be solved with this approach.}
% set pdf metadata
pdfauthor={Oliver Schmidt},
\newcommand{\comment}[1]{{\parindent0pt\fbox{\begin{minipage}{0.45\textwidth}{\em #1}\end{minipage}}}}
\newcommand{\todo}[1]{ \color{red} \footnote{ \color{red}[#1] \color{black}} \color{black}}
\emph{\scriptsize #1}
% Title Information, Abstract and Keywords
% % %
% In case of double blind submissions:
% \IEEEauthorblockN{Anonymous}
% \IEEEauthorblockA{Some Research Group\\
% Some Institution\\
% Some Email Addresses%
% }
\IEEEauthorblockN{Oliver Schmidt}
\IEEEauthorblockA{TU Dresden\\
% force pagenumbering
% % %
% sources on writing papers:
% look for a /good/ outline at the end of this text, the /why/ is found at this link:
% 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:
% read the text above again. the most important part (that we all tend to forget) is only 5 paragraphs
% Are NOT: Peer-To-Peer, Anonymity, Privacy.
Security, DRM, Trusted Execution Environments, SGX, TrustZone, TPM, HTML5 EME
% }
\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 uncopiable 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 columnist 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 film publishers require adhering to certain protection 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 and gaming consoles have their own DRM systems as well} require the usage of \ac{DRM} for protecting their published works. 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 \acp{TEE}s and other special hardware trust-anchors provide the possibility to present \ac{DRM}-secured content in an otherwise open and open source system? Or does \ac{DRM} only work on completely locked-down systems?
In \ref{sec:background} we first give an overview of common technologies used for providing trust anchors for running systems or isolating software into a trusted environment. Afterwards, \ref{sec:hw_DRM} covers existing DRM architectures already utilizing \acp{TEE}. Aiming for the usage on systems as open as possible, \ref{sec:shortcomings} looks at the security of the presented architectures on such systems and at last takes a look at other problematic effects of DRM usage.
% % %
% Literature Survey and Background
\section{Background: Trust Anchors and Trusted Execution}
This section first gives an overview about technologies used for having a trust anchor in a running system. Although these approaches are often used for locking down whole systems, they may also provide the basis for building more open systems by tying trust to hardware anchors instead of a locked-down software stack. \\
Afterwards we cover the technologies dedicated to providing 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, it is launched by the firmware. 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).
\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 not 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. Based on reference signatures stored in the module's secure storage, each component can then decide to allow or refuse the next software to launch. A similar boot policy this attestation-checking during boot is \textbf{authenticated booting}. Again the \ac{TPM} calculates the checksum of each boot stage but does not enforce any signature checks and only stores the results inside its secure internal registers, from where the system status can be queried later.\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 for 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 introduced so called \acp{TEE}. These are separated co-processors, either dedicated or virtualised, 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 applicability 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 Open Source Project.
How these dedicated virtual resources are actually backed by physical ones depends on the implementation of 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 not 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 does not provide other \ac{TPM} features like secure non-volatile storage. \\
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}\label{sec:hw_DRM}
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 plug-in varies depending on the plug-in itself and on the capabilities of the hardware platform. Plug-ins 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}.
Plug-ins are automatically loaded when they are placed into the \texttt{/system/lib/drm/plug-ins/native/} directory. \\
One issue we see here is that there is no mention of authenticity checking of plug-ins in the documentation. \cite{AndroidDRMFramework} This can enable DRM plug-ins 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 post processing. 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 lock down.
The architecture overview does not mention how to persistently store the acquired decryption keys. At the same time we know that apps\footnote{example: Netflix for Android \url{}} 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. analyse 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 fulfil 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.
\caption{Sequence of information exchange between \ac{EME}\label{fig:EMEsequence} components, source \cite{livshitsSecurityNativeDRM2015}}
First the browser's media stack parses the embedded media file and discovers the \textit{key id} embedded 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. After the initialization data is pushed to a \ac{CDM} implementing the key system, it generates a \textit{keymessage} for a license server. The message is then sent to the license server by the browser, passing the response back to the \ac{CDM} as well which decrypts the received license and updates 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 application 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} standard 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 we are looking at the usage of \ac{DRM} in an as-open-as-possible system, we would 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 re-encrypted 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 is not 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 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.
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.
\caption{high-level architecture of TBDRM components, source: \cite{yuTBDRMTPMBasedSecure2009}}\label{fig:TBDRM_arch}
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 metadata for describing and identifying the matching content. \\
The trust basis for all other client components is provided by the \textit{\acf{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 trustworthiness of the player component is first attested to the \acl{DC} by the \acl{AA}, the same is done for the \acl{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 trustworthiness 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 on 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 does not specify whether licenses can be saved to persistent storage. \\
\textbf{Freshness} of licenses is ensured within the \ac{VC} by using 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. While 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 builds 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 analyse 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:
\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
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.
\subsection{shortcomings on open systems}\label{sec:shortcomings_open}
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 is 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 do not 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 do not 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 not check the authenticity of the \ac{CDM} it is 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 is 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 e. g. remote attestation of \ac{SGX} or (f)\ac{TPM} for verifying 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 plug-in (see \ref{sec:AndroidDRM}), including whether a DRM plug-in 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. As the \ac{TPM} provides important the cryptography and trust services to the system, it is part of the \ac{TCB} as well. \\
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.
When using UEFI SecureBoot, there needs to be a trusted path from the firmware to the trusted DRM software (e. g. a \ac{CDM}) to be able to verify the authenticity the component. Additionally, appropriate measures need to be taken to ensure that data inside the trusted DRM component can not be read by untrusted processes. This results in a \ac{TCB} comprising the whole operating system and all higher-privilege user land components. Effectively, this results in a lock-down of the whole system.
In practice, Microsoft requires devices \cite{MicrosoftHardwareCertification2014} shipped with the Windows \ac{OS} to have Secure Boot enabled by default, verifying boot images against Microsoft's key. This requirement has been criticized as it might 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} 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.
\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}
While the usage of \acp{TEE} can indeed increase the security of \ac{DRM} schemes while at the same time taking away the need for total system lock-down, there are quite a number of other issues with the usage of DRM protection for media. Most of them are less purely technical but concern the social and political effects of its technical properties.
The designed purpose of \ac{DRM} systems is to restrict the usage of protected media files to follow the exact policies of the publisher -- and that is exactly what it does. The problem here: The outlined policies of the publisher do not always cover legal or legitimate use cases of the media. In their campaign leaflet on DRM and its downsides \cite{freesoftwarefoundationeuropeDRMStrangeBroken2012}, the Free Software Foundation Europe outlines several problems of DRM usage: \\
DRM protection of media content undermines several copyright exemption and customer rights. While most jurisdictions know exemptions for lending works out to friends and family or making private copies for them, this copyright exception is not granted when so-called \textit{effective measures} of copy protection are taken by the publisher. All DRM mechanisms are considered as such and are illegal to circumvent, taking away these user rights. At the same time we notice that, at least in Germany, collector societies are still charging and collecting remuneration fees for this exception customers are not allowed to use any more. A similar copyright exemption is the liberty of quotation. But with DRM protection, it is not possible to e. g. cut a certain video sequence from a film to embed it into your own work. \\
In the United States, there is even the concept of \textit{fair use} allowing the remix of existing works to create new works of art. As DRM systems prevent editing and further processing of the content, this right is also prevented from being executed. \\
In DRM systems only certain pieces of software are allowed to process the protected content -- in the case of TBDRM these are the players trusted by the license distributor. Often publishers forget the reliance of disabled people on certain assistance software. Such screen readers, image or audio enhancers are rarely on the list of trusted software able to process the protected content and thus can not enable disabled people access to the content.
DRM protection is also a threat to the availability of content, both in the short and in the long term. Recently, an anecdote \cite{bergmayerItAlwaysDRM2018} raised awareness for this again: After moving from Australia to Canada, a person lost their ability re-download several purchased films. This happened due to regionally-limited licensing deals of the publisher. While already downloaded film files could still be played back, because of DRM protection they were tied to a single device only. Playback of the legally bought films on other devices would have required a re-download, which was not possible in that jurisdiction. \\
This illustrates the downsides of DRM protected content always being bound to something out of the control of the consumer who bought it: For acquiring the required decryption keys, license servers need to be online, reachable and supporting the technology required for the media to be played back. Additionally, these proprietary DRM schemes are always bound to a certain technology platform (e. g. ARM TrustZone and Android) with only their vendor having the ability to make content bought for a previous technology available on a new platform. While the \textit{Common Encryption} standard is a step into the right direction, we are still in a situation where content regularly becomes unavailable because of companies going out of business, deciding not to make old content available on new platform or switching off licensing servers\footnote{example: in 2008 Microsoft switched off their ``Plays for Sure'' licensing servers \cite{sterlingDeadMediaBeat2008}}. This is also a threat to preserving cultural heritage, as even personal backups of the media files are useless without the non-exportable respective keys.
The seemingly endless possibilities of restrictions motivated companies to also offer business options requiring heavy user tracking. For example, \textit{node locking} -- binding content to a specific computer only -- causes several DRM schemes to create detailed profiles of the computer it is running on and the user's activities. Because of that Mozilla decided in their implementation of the HTML5 EME standard to run \acp{CDM} only sandboxed, limiting tracking and privacy intrusion. \cite{andreasgalReconcilingMozillaMission2014} \\
As \acp{CDM} are proprietary\footnote{The WiDevine architecture overview even mentions this as a key security concept: ``This unique mix of open source and protected source
enables WiDevine DRM to make it easy to create custom playback applications that are
encrypted and secure.'' \cite{googleWidevineDRMArchitecture2017}}, both the amount of user tracking they do and their security can not be evaluated, as under the WIPO agreement reverse-engineering copy-protection mechanisms is heavily restricted. With the availability of \aclp{TEE} and the usage of attestation, not requiring \ac{CDM} binaries to contain secret data any more, it should be possible to create open source \acp{CDM} which can be built reproducibly.
As presented on the examples of the covered \ac{DRM} schemes, the usage of hardware support mechanisms -- especially of \aclp{TEE} -- can enable reliable content protection on systems without having to lock them down completely. All presented approaches had shortcomings in the areas of authentication and authenticity checking, size of the locked-down system base (\ac{TCB}) or actual output mechanisms, but when combining ideas from these different schemes the result is more resilient to threats.
However, the usage of \ac{DRM} implies several other problems that are not solved by the usage of hardware support.
% % %
% 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