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

background: Apple SEP

master
Trolli Schmittlauch 2018-09-07 14:08:51 +02:00
parent eeb86baafc
commit e2c16a23b3
1 changed files with 8 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
main.tex
View File

@ -138,7 +138,7 @@ 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{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}. \\
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}
@ -147,7 +147,7 @@ To allow separating the execution of security critical code from the large untru
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}
\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.
@ -157,9 +157,13 @@ Communication between the worlds is made possible by the \textit{secure monitor}
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{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}
\subsubsection{Intel SGX}
lockdown techniques: TPM, secure boot