worked through all ToDos

glossary.tex

@@ -20,4 +20,5 @@
 \acro{VC}{Version Controller}
 \acro{DC}{DRM Controller}
 \acro{MMU}{Memory Management Unit}
+\acro{HDCP}{High-bandwidth Digital Content Protection}
 %\acro{

main.tex

@@ -188,7 +188,7 @@ This is not the case for security level 2:  There only the cryptographic operati
 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.
 
-\todo{storing DRM keys/ WiDevine?}
+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}
 
@@ -213,8 +213,8 @@ 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.\todo{maybe elaborate on launching SGX enclaves a bit}  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 a \todo{``secure mechanism'' for key exchange to TEE mentioned but not specified} DXVA 2.0\todo{???} 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.\todo{secure tansmission to display device, HDCP}  \\
+On systems with \ac{SGX}, the \ac{CDM} is launched inside a secure enclave created by the browser.  When utilizing TrustZone, inside the normal world the browser notifies its \ac{OS} that the license- or metadata needs to be exchanged to the secure world.  Initiating a \textit{secure monitor call}, the data is transferred to the secure world where the \ac{CDM} can now create a license request or can decrypt the media content.  \\
+To prevent the leakage of the decrypted media during rendering and display, the media pipeline has to be secured as well.  In \cite{livshitsSecurityNativeDRM2015} this is done for the graphics pipeline by utilizing measures available on the respective hardware platforms:  On \textit{\ac{SGX} platforms}, \ac{PAVP} is used to create a video surface within the browser context.  From the \ac{SGX} context DXVA 2.0\footnote{\textit{DirectX Video Acceleration}, a proprietary API available on Microsoft Windows and Xbox} is used to exchange a key with the GPU with which the DRM-decrypted media content is reencrypted before being sent to the surface.  Inaccessible to the browser context, the media is decrypted and decoded directly on the GPU and then sent to the display device.  \\
 The audio pipeline isn't mentioned, but with combined transmission of audio and video signals like in HDMI or DisplayPort we consider this covered as well.  \\
 On platforms with \textit{ARM TrustZone}, memory sections can be dedicated to the secure world only and device's access to these sections can be limited to certain devices.  This ability is used to store raw video frames, decoded in software running inside the \ac{TEE}, to be accessed by the GPU only.  Additionally, a session between the \ac{CDM} inside the TEE and the GPU can be authenticated with certificates, enabling video decoding directly on the GPU similarly to the approach taken on \ac{SGX} systems.
 
@@ -229,12 +229,12 @@ In 2009 Yu et al. have proposed a \ac{DRM} architecture based on \ac{TPM}, calle
 
 The high-level architecture of TBDRM is outlined in Fig. \ref{fig:TBDRM_arch}.  The encrypted content itself can be delivered independently from the license, which consists out of a usage policy for the content, its decryption key and some metada for describing and identifying the matching content.  \\
 The trust basis for all other client components is provided by the \textit{\acl{AA}}.  This component can attest the authenticity and identity of the \textit{\ac{VC}}, which ensures and attests freshness of a license, the \textit{\ac{DC}} handling the actual content decryption and policy enforcement, and the actual media \textit{player} component.  \\
-When requesting a license, the \ac{LD} decides whether to give a license based on the attested identity of the \ac{DC} and the license version requested.\todo{why is VC not checked/ attested?}  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.\todo{secure playback pipeline + output not covered}  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 trustworthyness of the player component is first attested to the \ac{DC} by the \ac{AA}, the same is done for the \ac{VC} afterwards.  If all components are trustworthy to the \ac{DC} and the \ac{VC} also has verified the freshness of the license, the \ac{DC} checks the requested usage permission against the usage policy of the licenses.  If access can be granted, the media content is decrypted with the symmetric key provided by the license and passed to the player.  If the usage policy mandates a version bump of the license (e. g. for enforcing a playback number limit), this is done by the \ac{VC} after playback.
 
 For implementing this architecture, the authors proposed using several \ac{TPM} functionality for ensuring the security (persistent control of content, license integrity/ confidentiality/ freshness) of the DRM system.  \\
 In their prototype they ensure a \textbf{trust chain} from the boot on to each DRM scheme component by measuring each system boot step, starting at the hardware trust anchor provided by the \ac{TPM}. Measuring means the \ac{TPM} computing the hash of a component and storing the result into its internal platform configuration registers, from where it can be retrieved later.  First the \ac{TPM} measures the hardware platform configuration, the bootloader containing a \textit{kernel measuring agent} and the kernel containing an \textit{application measurement agent} serving as the \ac{AA} component.  A full trust chain can then be established by checking all component's measurements from the respective \ac{TPM} registers.  Additionally the kernel contains the \ac{VC} component and the part of the \ac{DC} responsible for verifying the trustworthyness of all other components, turning all components of the system stack from the hardware to the kernel itself into parts of the \acl{TCB}.  The player itself and the \ac{DC} part responsible for interpreting and deciding on policy rules are running in the user-space and are isolated from each other.  The application measurement agent and the user-space \textbf{isolation} are done based on a Linux Security Module running in the kernel, the latter by preventing processes from accessing other processes address space e. g. using ptrace.  \\
 The \textbf{bind mechanism} for making license data only accessible to certain components is based the \ac{TPM} key management mechanism \textit{immigratable key} and \textit{key certification}.  For binding a license to the current \ac{DC}, a new immigratable asymmetric keypair is created.  When acquiring a license, the public key of that pair is certified by the \ac{TPM} and sent to the \acl{LD}.  After verification, the \ac{LD} uses hybrid encryption for the license data by encrypting it symmetrically with a fresh key and encrypting that key asymmetrically with the received public key of the client.  Thus the sent-back license can only be decrypted and used by the trusted \ac{DC}.  The TBDRM proposal doesn't specify whether licenses can be saved to persistent storage.  \\
-\textbf{Freshness} of licenses is ensured within the \ac{VC} by using the monotonic counters of the \ac{TPM}.  The state of each counter is bound to the \ac{VC} and can be stored on disk for persisting.\todo{binding malleability}
+\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:
 
@@ -247,7 +247,7 @@ The TBDRM paper builts on hardware \acp{TPM} conforming to the TPM 1.2 specifica
 As fTPM requires additional hardware components to be included already during system design, it can not be applied to existing devices lacking these components.  But if these small additional requirements are taken care of during system design, hardware-complemented \ac{TEE} features of modern CPUs can provide TPM-compliant services.  This is the case on all ARM-based devices by Microsoft shipped with the Windows \ac{OS}, where the required TPM functionality is provided by fTPM.
 
 
-\section{shortcomings}\label{sec:shortcomings}
+\section{Shortcomings}\label{sec:shortcomings}
 
 \subsection{shortcomings on open systems}
 
@@ -272,7 +272,8 @@ As measured boot is used, modified software components are not prevented from ru
 
 \subsubsection{media output on peripherals}
 
-With the master key having leaked and decryption hardware being available \cite{DBLP:conf/reconfig/LombG11}, HDCP can be considered as broken.
+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}
 
@@ -282,6 +283,8 @@ WiDevine/ Netflix ban from rooted devices
 
 - remaining other problems: cultural heritage, inflexibility, tied to a certain technological platform
 
+valid copyright exceptions (private copy, quotation) are prevented
+
 Doctorows Law: "Anytime someone puts a lock on something you own, against your wishes, and doesn't give you the key, they're not doing it for your benefit."
 
 tracking, Mozilla