301 lines
29 KiB
TeX
Executable File
301 lines
29 KiB
TeX
Executable File
\documentclass[10pt,conference,twocolumn,final,a4paper]{IEEEtran}
|
||
|
||
\usepackage{ifluatex}
|
||
\ifluatex
|
||
\usepackage{fontspec}
|
||
\defaultfontfeatures{Ligatures=TeX} % To support LaTeX quoting style
|
||
%\setromanfont{Vollkorn}
|
||
\else
|
||
\usepackage[T1]{fontenc}
|
||
\usepackage[utf8]{inputenc}
|
||
\fi
|
||
|
||
\usepackage{clrscode}
|
||
\usepackage{xcolor}
|
||
\usepackage[]{graphicx}
|
||
|
||
\usepackage{acronym}
|
||
|
||
\newcommand{\documenttitle}{Here be dragons}
|
||
|
||
\newcommand{\abstracttext}{Abstract goes here}
|
||
|
||
% set pdf metadata
|
||
\usepackage[
|
||
pdftitle={\documenttitle},
|
||
pdfauthor={Oliver Schmidt},
|
||
breaklinks
|
||
]{hyperref}
|
||
\usepackage{breakurl}
|
||
|
||
\newcommand{\comment}[1]{{\parindent0pt\fbox{\begin{minipage}{0.45\textwidth}{\em #1}\end{minipage}}}}
|
||
\newenvironment{changed}{\red}{\color{black}}
|
||
\newcommand{\todo}[1]{ \color{red} \footnote{ \color{red}[#1] \color{black}} \color{black}}
|
||
\newcommand{\Hide}[1]{%
|
||
{
|
||
\parindent0pt
|
||
\emph{\scriptsize #1}
|
||
}
|
||
}
|
||
%\renewcommand{\Hide}[1]{}
|
||
|
||
|
||
\pagenumbering{arabic}
|
||
|
||
\begin{document}
|
||
|
||
%----------------------------------------------------------------------
|
||
% Title Information, Abstract and Keywords
|
||
%----------------------------------------------------------------------
|
||
\title{\documenttitle}
|
||
|
||
|
||
% % %
|
||
% In case of double blind submissions:
|
||
%\author{
|
||
% \IEEEauthorblockN{Anonymous}
|
||
% \IEEEauthorblockA{Some Research Group\\
|
||
% Some Institution\\
|
||
% Some Email Addresses%
|
||
% }
|
||
%}
|
||
|
||
\author{
|
||
\IEEEauthorblockN{Oliver Schmidt}
|
||
\IEEEauthorblockA{TU Dresden\\
|
||
oliver.schmidt3$[$at$]$mailbox.tu-dresden.de%
|
||
}
|
||
}
|
||
|
||
|
||
\maketitle
|
||
|
||
% force pagenumbering
|
||
\thispagestyle{plain}
|
||
\pagestyle{plain}
|
||
|
||
% % %
|
||
% sources on writing papers:
|
||
% look for a /good/ outline at the end of this text, the /why/ is found at this link:
|
||
% http://homepages.inf.ed.ac.uk/bundy/how-tos/writingGuide.html
|
||
% http://www-net.cs.umass.edu/kurose/writing/
|
||
% http://www.cs.columbia.edu/~hgs/etc/writing-style.html
|
||
% Read ``Zen - or the art of motorcycle maintenance'' to understand what science and research is
|
||
% Read ``The craft of research'' to /really/ learn how to conduct research and report about it! :-)
|
||
% some hints on plagiarism: http://www.williamstallings.com/Extras/Writing_Guide.html
|
||
% read the text above again. the most important part (that we all tend to forget) is only 5 paragraphs
|
||
|
||
\begin{abstract}
|
||
|
||
\abstracttext
|
||
|
||
\end{abstract}
|
||
|
||
\begin{IEEEkeywords}
|
||
% Are NOT: Peer-To-Peer, Anonymity, Privacy.
|
||
% BUT TAKEN FROM THIS LIST:
|
||
% http://www.ieee.org/organizations/pubs/ani_prod/keywrd98.txt
|
||
Security, DRM, Trusted Execution Environments, SGX,
|
||
\end{IEEEkeywords}
|
||
% }
|
||
|
||
\maketitle
|
||
|
||
\IEEEpeerreviewmaketitle
|
||
|
||
\section{Introduction}
|
||
|
||
\IEEEPARstart{S}{ince} early on in the so-called ``information economy'', publishers have tried to limit the distribution of their digital goods to the buyers only. In his keynote ``The coming war on general computation'' at the 28th Chaos Communication Congress \cite{corydoctorowComingWarGeneral2011}, Cory Doctorow outlines the development of copy-protection mechanisms from first including uncopyable bad sectors to the floppy disks on which programs were distributed or tying the execution to dongles and license keys, to encrypted music and video files protected with dedicated \ac{DRM} schemes. \\
|
||
But these attempts were mostly based on obscuring the protection mechanism used, thus being vulnerable to circumvention through reverse-engineering, patching out the protection mechanism or retaining the supposedly-secret media decryption keys even after the usage license expired. The renowned IT security collumnist and expert Bruce Schneier commented on these attempts: ``Digital files 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.
|
||
|
||
Doctorow warns that all countermeasures trying to ensure copy protection of digital content are going to result in creating ``appliances'', which are still general purpose computers, but locked down with ``some combination of rootkits, spyware, and code-signing to prevent the user from knowing which processes are running, from installing her own software, and from terminating processes that she doesn't want.'' \cite{corydoctorowComingWarGeneral2011} \\
|
||
Additionally, international agreements based on the \ac{WIPO} Copyright Treaty \cite{worldinternationalcopyrightorganizationWIPOCopyrightTreaty1996}, its most prominent implementation being the US-American \ac{DMCA}, make the circumvention of ``technical protection measures'' such as \ac{DRM} illegal.
|
||
|
||
So right now we are in a situation, where all major publishers of e.g. video\footnote{all Hollywood movie publishers require adhering to certain protec standards like \cite{movielabsinc.MovieLabsSpecificationEnhanced2018}} and audio\footnote{although legal music file purchases are mostly \ac{DRM}-free, the consumption model of streaming has brought back DRM to platforms like Spotify or Deezer} content, and video games\footnote{Valve's Steam platform integrates its own DRM into sold games; other publishers as well as gaming consoles have their own DRM systems as well}. Thus right now, all software using this content has to be proprietary and whole platforms are being locked down more and more. This development is most apparent in non-PC platforms like mobile devices, where unlocking the bootloader (if even possible) results in deletion of \ac{DRM} keys of the device. \cite{sonydeveloperworldUnlockBootloaderOpen}
|
||
|
||
But in recent years modern CPU architectures have introduced special hardware-backed \acp{TEE} to provide a secured environment for security-critical code to be executed in isolation from the main \textit{untrusted} \ac{OS}. Can these TEEs and other special hardware trust-anchors provide the possibility to present \ac{DRM}-secured content in an otherwise open and open source system, not having to lock it down completely?
|
||
|
||
\todo{outline}
|
||
|
||
% % %
|
||
% Literature Survey and Background
|
||
\section{Background: Trust Anchors and Trusted Execution}
|
||
\label{sec:background}
|
||
|
||
This section first gives an overview about technologies used for having a trust anchor in a running system. Though these approaches are often used for locking down whole systems, they may also provide the basis for building more open systems with a \ac{TEE}. \\
|
||
Afterwards we cover the technologies dedicated to provide a \ac{TEE} in modern processor architectures.
|
||
|
||
\subsection[SecureBoot]{UEFI Secure Boot}\label{sec:SecureBoot}
|
||
|
||
\textit{Secure Boot} is a functionality of the \ac{UEFI} boot firmware component \cite{unifiedefiforuminc.UEFISpecificationVersion2017} to allow only the launch of authenticated boot images. To achieve that, boot images can be signed with X.509 certificates. Only if the image verifies correctly against a key stored in non-volatile firmware memory or against an entry in an explicit allow list of signatures. This first check on which bootloader or \ac{OS} image to launch can be the anchor of a trust chain, if each consecutive execution step also checks the authenticity of software to be launched. The allow and deny lists can be updated from the running \ac{OS} and deploying own custom platform keys for verification can be possible through setup-mode of \ac{UEFI}.
|
||
|
||
Firmwares adhering to the \ac{UEFI} standard are the dominant system software for the PC platform (including x86 devices like servers, laptops and mobile devices, but also more and more devices with ARM chipsets). Microsoft has been criticized for requiring devices \cite{MicrosoftHardwareCertification2014} shipped with the Windows \ac{OS} to have Secure Boot enabled by default, verifying boot images against Microsoft's key, mentioning that this could lead to lock-down of consumer hardware and the inability to install alternative operating systems on it. \\
|
||
Earlier versions of the requirements mandated an option to disable Secure Boot on x86 devices while also mandating that it must always be enabled on ARM-based devices. \cite{moodyMicrosoftBlockingLinux} Nevertheless complete lockout of other operating systems doesn't seem to be imminent at least on x86 devices as there is a shim bootloader signed by Microsoft \cite{matthewgarrettAnnouncingShimReview}, enabling the launch of other unsigned boot images. The signature of this specific binary could though be put on the firmware's deny list through updates.
|
||
|
||
\subsection{TPM}\label{sec:TPM}
|
||
|
||
\acp{TPM} are dedicated hardware components offering a variety of security services to a system \cite{197213}: \\
|
||
\acp{TPM} provide \textbf{secure storage} inside the module to store sensitive data like cryptographic keys in such a way that it can't be leaked to or stolen from processes running on the main CPU. \\
|
||
These stored keys can be used to execute cryptographic operations on behalf of the system, without the keys getting transferred to the outside of the module. \\
|
||
The \textbf{attestation} functionality can attest the identity of software by calculating a hash sum of the supplied binary, signing it with its internal key to prove a certain system configuration or software version to third parties having a corresponding verification key. When pre-deployed with a unique key, all previously mentioned functionality can be combined to provide a \textbf{unique machine identity} and form a hardware trust anchor for running systems. \\
|
||
A \textbf{continuous trust chain} can be built from the boot-up on if all software components, starting from the firmware on, let the \ac{TPM} attest the processes to be launched and compare these attestations with the ones stored previously in the module's secure storage. A similar boot policy is \textit{authenticated booting}, where the \ac{TPM} calculates the checksum of each boot stage but doesn't enforce any signature checks but only stores the results inside its secure internal registers, from where the system status can be queried later on.\cite{hartigLateralThinkingTrustworthy2017} In contrast to UEFI Secure Boot (\ref{sec:SecureBoot}), it is also possible to securely attest and launch code using special \textit{late-launch} CPU instructions introduced into AMD and Intel chipsets without providing a continuous trust chain from the firmware on \cite{hartigLateralThinkingTrustworthy2017}. \\
|
||
Additionally, \acp{TPM} provide important support functionality cryptographic algorithms like \textbf{secure counters}, a \textbf{secure clock} for peripherals and a \textbf{secure source of entropy}. \cite{197213}
|
||
|
||
\subsection{Trusted Execution Environments}
|
||
|
||
To allow separating the execution of security critical code from the large untrusted codebase of the rest of the system, all major processor vendors have intruduced so called \acp{TEE}. These are separated co-processors, either dedicated or virtualized, providing a computing environment with at least its own computing resources, registers and memory (areas) isolated from the untrusted parts of the running system.
|
||
|
||
This section is mostly not based on the vendor's refrence manuals but on other papers reviewing the apllicability of such environments. \cite{hartigLateralThinkingTrustworthy2017,197213,livshitsSecurityNativeDRM2015}
|
||
|
||
\subsubsection{ARM TrustZone}\label{sec:TrustZone}
|
||
|
||
\textit{ARM trust zone} \cite{armlimitedARMSecurityTechnology2005} is a set of security extensions for processors, currently available for the ARMv8 architecture. Additionally, the processor vendor AMD has announced to include TrustZone co-processors into some of their x86 processors. It divides the physical processing environment into two separate \textit{worlds} that can be switched. The \textbf{secure world}, being the initial processor state after reset, and the \textbf{normal world}, where all legacy and non-critical code is run. Each world provides its own runtime environment with (virtually) dedicated registers, memory, processor, caches and interrupts. Additionally, each world runs its own operating system, with general purpose \acp{OS} running in the normal world, while the secure world tends to use special purpose \acp{OS} like the \textit{Trusty OS} \cite{TrustyTEE} used by the Android OpenSource Project.
|
||
|
||
How these dedicated virtual resources are actually backed by physical depends on the implementationof the \ac{SoC}. Resources can either be strongly partitioned (e. g. memory), shared between worlds (often the case for caches, processor) or assigned exclusively to one of the worlds (most I/O devices, separate register banks). \\
|
||
The memory is strongly partitioned on boot-up, rendering the worlds inaccessible to each other. This memory isolation is supported by marking the secure world with an additional bit at the hardware level. \\
|
||
Communication between the worlds is made possible by the \textit{secure monitor} processor mode, controlled by a dedicated register. This monitor mode can implement context switches between the worlds as it can access copies of non-secure registers from the secure context. ARM CPUs always boot first into the secure world and hand over control to the non-secure world after initialization. Later on, the normal world can use a special \textit{secure monitor call} instruction to give control to the secure monitor mode, performing a context switch. Interrupts can directly map into the secure monitor mode.
|
||
|
||
With the memory only being separated but not encrypted, TrustZone's security relies on having a connection to its memory which can't be eavesdropped upon.
|
||
|
||
\subsubsection{Apple SecureEnclave Processor}\label{sec:SecureEnclave}
|
||
|
||
Although Apple's own \acp{SoC} use the ARM architecture, the company has decided to use their own secure co-processor solution instead of TrustZone (\ref{sec:TrustZone}). Their \textit{Secure Enclave Processor} is a dedicated processor, running an L4 microkernel, communicating with the main CPU over a bus system and accessing the system's memory using inline-encryption. \cite{hartigLateralThinkingTrustworthy2017}
|
||
|
||
\subsubsection{Intel SGX}\label{sec:SGX}
|
||
|
||
Intel's \acf{SGX} are a method to launch multiple trusted components into their own fully isolated \textit{enclaves} and thus, according to \cite{hartigLateralThinkingTrustworthy2017}, can be seen as a more advanced version of the late-launch approach (\ref{sec:TPM}).
|
||
Enclaves can be scheduled by the OS like normal processes, but code and memory of enclaves are only visible from the inside. Enclave memory resides in the common system's DRAM but is transparently encrypted. \\
|
||
Additionally, \ac{SGX} includes attestation of code running within an enclave similar to \ac{TPM}, but itself doesn't provide secure storage or other \ac{TPM} features. \\
|
||
As only userland code running in ring 3 can be run inside enclaves, relying on the \ac{OS} for scheduling and resource management, \ac{SGX} is vulnerable to side-channel attacks \cite{peinadom.ControlledChannelAttacksDeterministic2015}.
|
||
|
||
|
||
(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?
|
||
|
||
\subsection{Android DRM architecture}\label{sec:AndroidDRM}
|
||
|
||
The Android platform provides its own DRM framework\cite{AndroidDRMFramework}, providing an API for applications to communicate with a \textit{DRM manager} over \ac{IPC}. This DRM manager then runs plug-ins managing the actual DRM schemes as separate processes for isolation purposes. \\
|
||
The level of protection provided by the DRM plugin varies depending on the plugin itself and on the capabilities of the hardware platform. Plugins may rely on secure boot for a verified chain of trust from the firmware level on, use protected output mechanisms provided by the hardware platform and even run the programs inside a \ac{TEE}.
|
||
|
||
Plugins are automatically loaded when they are placed into the \texttt{/system/lib/drm/plugins/native/} directory. \\
|
||
One issue we see here is that there's no mention of authenticity checking of plug-ins mentioned in the documentatiion. \cite{AndroidDRMFramework} This can enable DRM plugins to claim to be able to decrypt a certain stream and thus at least result in the user not being able to decrypt their media with the proper add-on. Additionally it might also open up attack vectors for the communication with a license server, as shown later. \\
|
||
|
||
One cross-platform DRM plugin solution is \textbf{WiDevine} \cite{googleWidevineDRMArchitecture2017}, currently owned by Google. It provides native solutions for the Android, iOS and HTML5 platform. Thus the \ac{DRM} decryption process is very similar to the one specified in HTML5 \acs{EME} and will be covered in section \ref{sec:HTML5_EME} in more detail. \\
|
||
The reason we look at the example of the WiDevine Android plugin is that it supports different security levels, depending on the use of hardware security mechanisms \cite{googleWidevineDRMArchitecture2017}: For security level 1, ``[a]ll content processing, cryptography, and control is performed within the Trusted Execution
|
||
Environment (TEE).'' This includes that even the decrypted video frames are to be passed to the graphics hardware using a secured mechanism. \\
|
||
This is not the case for security level 2: There only the cryptographic operations are done within a \ac{TEE}, but the decrypted video content is passed to processes running outside of a secure environment for further decoding, demuxing and postprocessing. But still all cryptographic keys remain secured within the \ac{TEE}. \\
|
||
And security level 3 is provided on devices without a \ac{TEE} at all, where ``[a]ppropriate measures may be taken to protect the
|
||
cryptographic information and decrypted content on host operating system'', which can be considered as a system-level lockdown.
|
||
|
||
\subsection{HTML5 EME}\label{sec:HTML5_EME}
|
||
|
||
To be able to provide DRM support for media content in the web, the \ac{EME} have been standardized by the \ac{W3C} \cite{w3cEncryptedMediaExtensions2017}. \ac{EME} are not a \ac{DRM} system themselves, but provide a standardized javascript \acsu{API} for mediation between HTML5 media elements and so-called \acp{CDM}. These \acp{CDM} are not standardized in \ac{EME} but are proprietary modules managing the actual \ac{DRM} scheme including license management, key retrieval, decryption and (optionally) decoding.
|
||
|
||
In \cite{livshitsSecurityNativeDRM2015} Livshits et al. analyze current web browsers and their \ac{EME} implementations for potential vulnerabilities and propose an architecture to back \acp{CDM} with \ac{TEE}-usage – not only for higher security but also to fulfill the requirements of media publishers of having hardware-backed copy protection.
|
||
|
||
\textbf{EME flow:} For the playback of \ac{DRM} protected media, information has to be exchanged between the web application and its media file, the \ac{CDM} and license/ key servers.
|
||
|
||
\begin{figure}
|
||
\includegraphics[width=0.49\textwidth]{figures/eme-sequence-diagram.png}
|
||
\caption{Sequence of information exchange between \ac{EME}\label{fig:EMEsequence} components, source \cite{livshitsSecurityNativeDRM2015}}
|
||
\end{figure}
|
||
|
||
First the browser's media stack parses the embedded media file and discovers the \textit{key id} emebdded into the media file's metadata. This fires a \textit{needkeys} event including some initialization data to the web application which then creates the \textit{mediaKeys} and \textit{mediaKeySession} for a specific key system. The initialization data is then pushed to a \ac{CDM} implementing the key system. The \ac{CDM} then creates a \textit{keymessage} for a license server, which is then sent to the license server by the browser and of which the response is passed back to the \ac{CDM} to decrypt the received license and update the \textit{mediaKeySession}. \\
|
||
After a \textit{keyadded/keyerror} event fired back to the web application indicating the success status of the license retrieval, it can finally initiate the playback of the media file, causing the \ac{CDM} to decrypt it using the received license key.
|
||
|
||
Hereby all javascript events fired from the \ac{CDM} to the web aplication contain byte buffers, which the web application running in browser context passes around and sends them to the respective servers. But these byte buffers are usually encrypted by the \ac{CDM} and thus incomprehensible to the browser handling them. \cite{WhatEMEHsivonen}
|
||
|
||
|
||
\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} \\
|
||
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.
|
||
|
||
- WiDevine quote \\
|
||
|
||
\subsection{TBDRM}\label{sec:TBDRM}
|
||
|
||
Android DRM, EME DRM arch, TBDRM (-> fTPM), InkTag?
|
||
|
||
\section{shortcomings}\label{sec:shortcomings}
|
||
|
||
\subsection{shortcomings on open systems}
|
||
|
||
Both the WiDevine architecture \cite{googleWidevineDRMArchitecture2017} and the \ac{TEE}-backed HTML5 \ac{EME} approach leave an important attack vector uncovered: It's not specified how \acp{CDM} authenticate against the license server they get the decryption key from. While all information between the \ac{CDM} and the license server is encrypted and thus meaningless to the browser or other software in the middle of the communication, on an open system it should be possible to read, reverse-engineer and even manipulate the \ac{CDM} binary\footnote{under the \ac{WIPO} copyright treaty or the \ac{DMCA} this is illegal, but still technically possible}, as they have to be stored somewhere (SGX and TrustZone don't provide secure permanent storage) or transmitted to the computer for installation. Livshitz et al. even mention reverse-engineering and manipulation in the security objectives of their paper \cite{livshitsSecurityNativeDRM2015}, but don't provide any countermeasures. \\
|
||
Although encrypting the communication between \ac{CDM} and license server without parties in the middle being able to eavesdrop on the license key transferred is indeed possible, e.g. using a Diffie-Hellman key exchange for generating a session key\footnote{although this could become a bit cumbersome in HTML5 EME as the browser has to relay all steps of the key exchange before actual payload information can be sent}, the license server can't check the authenticity of the \ac{CDM} it's communicating with. Including a private authentication key into the \ac{CDM} binary is insecure as the key could be recovered from attackers by reverse engineering. And if there's no need to authenticate the \ac{CDM} against the license server or modified \acp{CDM} are still able to do that using an extracted private key, a modified \ac{CDM} can either deliberately leak the key or the decrypted content to the untrusted \ac{OS}.
|
||
|
||
As a countermeasure we suggest the usage of attestation mechanisms provided e. g. remote attestation of \ac{SGX} or (f)\ac{TPM} to verify the integrity of the used \ac{CDM}. Especially for SGX though this is only a starting point and special care needs to be taken for remote attestation to be successful, as pointed out in \cite{swamiyogeshIntelSGXRemote2017}.
|
||
|
||
The Android DRM framework seems to put emphasis on locking down the whole system with a trusted boot chain instead, as stated in the Android documentation: ``The combination of hardware security functions, a trusted boot mechanism, and an isolated secure OS for handling security functions is critical to providing a secure device.'' \cite{AndroidDRMFramework} \\
|
||
This is also apparent in the light of several apps using the Android DRM framework not being available on rooted devices. One example is the Netflix app, which uses the WiDevine DRM scheme. \cite{corvindavenportNetflixConfirmsIt2017} This app can not be installed from the Play Store\footnote{Google's app store for the Android platform, by far the most popular one and default on Google-certified devices} on rooted Android devices, though already installed apps or ones installed through side-loading still continue to function. This is the case because installation from Play Store for this app is tied to the device's \textit{SafetyNet} status, which tries to detect tampering with the device's software. The Android DRM framework itself though also offers \acp{API} for getting the security status of a DRM plugin (see \ref{sec:AndroidDRM}), including whether a DRM plugin fully uses the \ac{TEE} of a device. Due to the ambiguous restriction enforcement it remains unclear whether banning the store installation of such apps on rooted devices is a sign of Google not fully trusting the security of \ac{TEE}-backed DRM even on open devices or if this is just a side effect of administrational policies of the store. But at least this is not a sign pointing towards the acceptance of \ac{DRM} on open platforms.
|
||
|
||
\subsection{further downsides of DRM}
|
||
|
||
What parts need to be locked down?
|
||
|
||
WiDevine/ Netflix ban from rooted devices
|
||
|
||
- remaining other problems: cultural heritage, inflexibility, tied to a certain technological platform
|
||
|
||
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."
|
||
|
||
\section{Summary}
|
||
% % %
|
||
% Theory (probably)
|
||
|
||
|
||
\section{Glossary}
|
||
\label{sec:glossary}
|
||
|
||
\nobreak
|
||
|
||
\begin{acronym}[GN6ASL]
|
||
\input{glossary.tex}
|
||
\end{acronym}
|
||
|
||
\bibliographystyle{IEEEtran}
|
||
\bibliography{mybib}
|
||
|
||
%----------------------------------------------------------------------
|
||
|
||
\end{document}
|
||
|
||
|
||
% % %
|
||
% A good outline for a computer science paper (according to Al Bundy)
|
||
%
|
||
% Title
|
||
% * - ideally the title should state the hypothesis of the paper
|
||
%
|
||
% Abstract
|
||
% * - state hypothesis and summarise the evidence that supports or refutes it
|
||
%
|
||
% Introduction
|
||
% * - motivate the contribution!
|
||
%
|
||
% Literature Survey
|
||
% * - broad and shallow account of the field, rival approaches, drawbacks of each, major outstanding problems
|
||
%
|
||
% Background
|
||
% * - states previous work in more detail, where this is necessary for understanding
|
||
%
|
||
% Theory
|
||
% * - underlying theory, definitions, theorems etc.
|
||
%
|
||
% Specification
|
||
% * - requirements and specs of implementation
|
||
%
|
||
% Implementation Evaluation Related Work
|
||
% * - narrow but deep comparison with main rivals
|
||
%
|
||
% Further Work Conclusion
|
||
% * - summarise research, discuss significance, restate hypothesis and the evidence for and against it, - recapitulate original motivation, reassess the state of the field in the light of this new contribution
|
||
%
|
||
% Appendices
|
||
%
|