spellcheck and corrections

main.tex

@@ -18,8 +18,8 @@
 
 \newcommand{\documenttitle}{Hardware Support for DRM: Can Trusted Execution Environments save us from System Lockdown?}
 
-\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 approches for copy protection involve locking down systems, criticized as endangering general computation and user freedom.  \\
+\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 lockdown, and output protection of all covered architectures, we find that the usage of trusted execution environments reduces the required system lockdown for DRM protection.  But many other negative effects of DRM can not be solved with this approach.}
+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
 \usepackage[
@@ -106,13 +106,13 @@ Security, DRM, Trusted Execution Environments, SGX, TrustZone, TPM, HTML5 EME
 
 \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.  \\
+\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 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} 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}
+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 as well as 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 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?
 
@@ -144,15 +144,15 @@ Additionally, \acp{TPM} provide important support functionality cryptographic al
 
 \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.
+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 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.
+\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 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).  \\
+How these dedicated virtual resources are actually backed by physical 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.
 
@@ -177,25 +177,25 @@ So how can these hardware security mechanisms be used to support DRM mechanisms
 \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}.
+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}.
 
-Plugins are automatically loaded when they are placed into the \texttt{/system/lib/drm/plugins/native/} directory.  \\
+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'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 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 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 postprocessing.  But still all cryptographic keys remain secured within the \ac{TEE}.  \\
+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 lockdown.
+cryptographic information and decrypted content on host operating system'', which can be considered as a system-level lock down.
 
 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.
+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.
+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.  
 
@@ -204,7 +204,7 @@ In \cite{livshitsSecurityNativeDRM2015} Livshits et al. analyze current web brow
  \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}.  \\
+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.  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}
@@ -215,7 +215,7 @@ One interesting side-note is that due to the usage of the \textit{ISO Common Enc
 \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.  \\
+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 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.
 
@@ -228,16 +228,16 @@ In 2009 Yu et al. have proposed a \ac{DRM} architecture based on \ac{TPM}, calle
  \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 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{\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.
+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 \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.  \\
+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 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:
+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 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:
 
 \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
@@ -262,7 +262,7 @@ Although encrypting the communication between \ac{CDM} and license server withou
 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.
+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}}
 
@@ -278,20 +278,20 @@ For directly attached screens on devices like smartphones, tablets or laptops re
 
 \subsection{Further Downsides of DRM}
 
-While the usage of \acp{TEE} can indeed increase the security of \ac{DRM} schemes while at the same tame taking away the need for total system lockdown, 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.
+While the usage of \acp{TEE} can indeed increase the security of \ac{DRM} schemes while at the same tame 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 jurisdiction 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 anymore.  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 movie to embed it into your own work.  \\
+DRM protection of media content undermines several copyright exemption and customer rights.  While most jurisdiction 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} rased awareness for this again:  After moving from Australia to Canada, a person lost their ability re-download several purchased movies.  This happened due to regionally-limited licensing deals of the publisher.  While already downloaded movie 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.  \\
+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 proprietar 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
+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 \acp{CDM} to contain secret data anymore, it should be possible to create open source \acp{CDM} which can be built reproducibly.
+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 \acp{CDM} to contain secret data any more, it should be possible to create open source \acp{CDM} which can be built reproducibly.
 
 \section{Summary}