237 lines
15 KiB
TeX
Executable File
237 lines
15 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 transfered 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{y} 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}
|
|
|
|
\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}
|
|
|
|
\subsubsection{Intel SGX}
|
|
|
|
lockdown techniques: TPM, secure boot
|
|
|
|
TEEs: SGX, TrustZone
|
|
|
|
(InkTag?)
|
|
|
|
Android DRM, EME DRM arch, TBDRM (-> fTPM)
|
|
|
|
|
|
\section{lockdown/ openness}
|
|
|
|
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
|
|
%
|