TBDRM and fTPM

glossary.tex

@@ -1,5 +1,6 @@
 \acro{API}{Application Programming Interface}
 \acro{CDM}{Content Decryption Module}
+\acro{CS}{Content Server}
 \acro{DMCA}{Digital Millenium Copyright Act}
 \acro{DRM}{Digital Rights Management}
 \acro{EME}{Encrypted Media Extensions}
@@ -14,3 +15,8 @@
 \acro{UEFI}{Unified Extensible Firmware Interface}
 \acro{WIPO}{World Intellectual Property Organization}
 \acro{W3C}{World Wide Web Consortium}
+\acro{AA}{Attestation Agent}
+\acro{LD}{License Distributor}
+\acro{VC}{Version Controller}
+\acro{DC}{DRM Controller}
+%\acro{

main.tex

@@ -106,7 +106,7 @@ Security, DRM, Trusted Execution Environments, SGX,
 \section{Introduction}
 
 \IEEEPARstart{S}{ince} early on in the so-called ``information economy'', publishers have tried to limit the distribution of their digital goods to the buyers only.  In his keynote ``The coming war on general computation'' at the 28th Chaos Communication Congress \cite{corydoctorowComingWarGeneral2011}, Cory Doctorow outlines the development of copy-protection mechanisms from first including uncopyable bad sectors to the floppy disks on which programs were distributed or tying the execution to dongles and license keys, to encrypted music and video files protected with dedicated \ac{DRM} schemes.  \\
-But these attempts were mostly based on obscuring the protection mechanism used, thus being vulnerable to circumvention through reverse-engineering, patching out the protection mechanism or retaining the supposedly-secret media decryption keys even after the usage license expired.  The renowned IT security collumnist and expert Bruce Schneier commented on these attempts:  ``Digital files cannot 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.  
+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.  
@@ -169,8 +169,6 @@ Additionally, \ac{SGX} includes attestation of code running within an enclave si
 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}.
 
 
-(InkTag?)
-
 \section{Hardware Support for DRM systems}
 
 So how can these hardware security mechanisms be used to support DRM mechanisms and make them run securely within a still open platform?
@@ -190,6 +188,8 @@ 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?}
+
 \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.
@@ -220,7 +220,32 @@ On platforms with \textit{ARM TrustZone}, memory sections can be dedicated to th
 
 \subsection{TBDRM}\label{sec:TBDRM}
 
-In 2009 Yu et al. have proposed a \ac{DRM} architecture based on \ac{TPM}, called \textit{TBDRM}. \cite{yuTBDRMTPMBasedSecure2009}
+In 2009 Yu et al. have proposed a \ac{DRM} architecture based on \ac{TPM}, called \textit{TBDRM}. \cite{yuTBDRMTPMBasedSecure2009}  Their approach relies on multiple components checking each others authenticity, relying on the attestation functionality of \ac{TPM} for constructing a hardware trust chain and authenticity checking, and on \ac{TPM} key management functionality for binding content to a certain player component.
+
+\begin{figure}
+ \includegraphics[width=0.49\textwidth]{figures/tbdrm_high_level_arch.png}
+ \caption{high-level architecture of TBDRM components, source: \cite{yuTBDRMTPMBasedSecure2009}}\label{fig:TBDRM_arch}
+\end{figure}
+
+The high-level architecture of TBDRM is outlined in Fig. \ref{fig:TBDRM_arch}.  The encrypted content itself can be delivered independently from the license, which consists out of a usage policy for the content, its decryption key and some metada for describing and identifying the matching content.  \\
+The trust basis for all other client components is provided by the \textit{\acl{AA}}.  This component can attest the authenticity and identity of the \textit{\ac{VC}}, which ensures and attests freshness of a license, the \textit{\ac{DC}} handling the actual content decryption and policy enforcement, and the actual media \textit{player} component.  \\
+When requesting a license, the \ac{LD} decides whether to give a license based on the attested identity of the \ac{DC} and the license version requested.\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.
+
+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}
+
+The TBDRM paper builts on hardware \acp{TPM} conforming to the TPM 1.2 specification.  This version of TPM has been deprecated for several years now due to its cryptographic algorithms having become less secure and its different implementations being ambiguous.  The successing version of the specification, TPM 2.0, is backwards incompatible but provides roughly the same functionality.  Thus porting the TBDRM approach to work with TPM 2.0 should be doable.  \\ A TPM 2.0 based variant of TBDRM can also become interesting for vendors not wanting to include a dedicated TPM chip into their device, but having a CPU with \ac{TEE} functionality:  With \textbf{fTPM} \cite{197213} Microsoft researchers have presented an implementation of the TPM 2.0 specification using \aclp{TEE}, specifically ARM TrustZone (described in \ref{sec:TrustZone}) as their basis, complemented with some additional hardware components.  They first analyze the shortcomings of \acp{TEE} compared with the functionality provided by \acp{TPM}.  The shortcomings of the ARM TrustZone \ac{TEE} relevant for TBDRM are its lack of secure storage (required for key storage), lack of secure persistent counters (used by the \ac{VC}) and lack of secure entropy source (used for key generation).  For overcoming these shortcomings, they took different approaches:
+
+\begin{itemize}
+ \item \textit{adding additional hardware}: replay-protected, authenticated storage (eMMC with replay-protected memory block), hardware fuses available only to the secure world as seeds for key generation, a physical entropy generator
+ \item \textit{design compromises}: no long-running \ac{TEE} processes to increase system stability -- cooperative checkpointing for splitting up RSA key generation into multiple short steps
+ \item \textit{modified TPM 2.0 semantics}: changing semantics of services slightly while still maintaining verifiable security guarantees
+\end{itemize}
+
+As fTPM requires additional hardware components to be included already during system design, it can not be applied to existing devices lacking these components.  But if these small additional requirements are taken care of during system design, hardware-complemented \ac{TEE} features of modern CPUs can provide TPM-compliant services.  This is the case on all ARM-based devices by Microsoft shipped with the Windows \ac{OS}, where the required TPM functionality is provided by fTPM.
+
 
 \section{shortcomings}\label{sec:shortcomings}
 

mybib.bib

@@ -344,4 +344,18 @@ This paper's contributions are a summary of the Intel-specific architectural and
   file = {/home/spiollinux/Zotero/storage/TVBERLMS/netflix-confirms-blocking-rootedunlocked-devices-app-still-working-now.html}
 }
 
+@book{arthurPracticalGuideTPM2015,
+  address = {Berkeley, CA},
+  title = {A {{Practical Guide}} to {{TPM}} 2.0},
+  isbn = {978-1-4302-6583-2 978-1-4302-6584-9},
+  language = {en},
+  urldate = {2018-09-21},
+  url = {http://link.springer.com/10.1007/978-1-4302-6584-9},
+  publisher = {{Apress}},
+  author = {Arthur, Will and Challener, David and Goldman, Kenneth},
+  year = {2015},
+  file = {/home/spiollinux/Zotero/storage/N826XYUM/10.1007978-1-4302-6584-9.pdf},
+  doi = {10.1007/978-1-4302-6584-9}
+}
+