schmittlauch/surveypaper-drm-tee
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

background: ARM TrustZone

Browse source
This commit is contained in:
Trolli Schmittlauch 2018-09-07 13:51:37 +02:00
parent 8aada42e9a
commit eeb86baafc
3 changed files with 31 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
glossary.tex
View file

@ -1,6 +1,7 @@
\acro{DMCA}{Digital Millenium Copyright Act}
\acro{DRM}{Digital Rights Management}
\acro{OS}{operating system}
\acro{SoC}{system on a chip}
\acro{TPM}{Trusted Platform Module}
\acro{TEE}{Trusted Execution Environment}
\acro{UEFI}{Unified Extensible Firmware Interface}

22
main.tex
View file

@ -138,9 +138,29 @@ Earlier versions of the requirements mandated an option to disable Secure Boot o
\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{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}. \\
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

9
mybib.bib
View file

@ -281,4 +281,13 @@ This paper's contributions are a summary of the Intel-specific architectural and
file = {/home/spiollinux/Zotero/storage/FGYE9G6G/47438.html}
}
@article{armlimitedARMSecurityTechnology2005,
title = {{{ARM Security Technology Building}} a {{Secure System}} Using {{TrustZone Technology}}},
language = {en},
author = {{ARM Limited}},
year = {2005},
pages = {108},
file = {/home/spiollinux/Zotero/storage/285DX2TJ/ARM Security Technology Building a Secure System u.pdf}
}