\HeadingLevelC{Attestation Chain of Trust}
\label{sec:chain_of_trust}

Sanctum has three pieces of trusted software: the measurement root, which is
burned in on-chip ROM, the security monitor (\S~\ref{sec:monitor}), which must
be stored alongside the computer's firmware (usually in flash memory), and the
signing enclave, which can be stored in any untrusted storage that the OS can
access.

The expectation is that the trusted software is amenable to rigorous analysis: the
implementation of a security monitor for Sanctum is written with verification
in mind, and has fewer than 5 kloc of C++, including a subset of the standard
library and the cryptography for enclave attestation.


\HeadingLevelD{The Measurement Root}
\label{sec:mroot}

The measurement root (\texttt{mroot}) is stored in a ROM at the top of the
physical address space, and covers the reset vector. Its main responsibility is
to compute a cryptographic hash of the security monitor and generate a monitor
attestation key pair and certificate based on the monitor's hash, as shown in
Figure~\ref{fig:mroot}.

\begin{figure}[!htbp]
  \centering
  \includegraphics[width=80mm]{figures/mroot.pdf}
  \caption{
    Sanctum's root of trust is a measurement root routine burned into the CPU's
    ROM. This code reads the security monitor from flash memory and generates
    an attestation key and certificate based on the monitor's hash. Asymmetric
    key operations, colored in blue, are only performed the first time a
    monitor is used on a computer.
  }
  \label{fig:mroot}
%\EndFigure
\end{figure}

The security monitor is expected to be stored in non-volatile memory (such as
an SPI flash chip) that can respond to memory I/O requests from the CPU,
perhaps via a special mapping in the computer's chipset. When \texttt{mroot}
starts executing, it computes a cryptographic hash over the security monitor.
\texttt{mroot} then reads the processor's key derivation secret, and derives a
symmetric key based on the monitor's hash. \texttt{mroot} will eventually hand
down the key to the monitor.

The security monitor contains a header that includes the location of an
attestation key existence flag. If the flag is not set, the measurement root
generates a monitor attestation key pair, and produces a monitor attestation
certificate by signing the monitor's public attestation key with the
processor's private attestation key. The monitor attestation certificate
includes the monitor's hash.

\texttt{mroot} generates a symmetric key for the security monitor so it may
encrypt its private attestation key and store it in the computer's SPI
flash memory chip. When writing the key, the monitor also sets the monitor
attestation key existence flag, instructing future boot sequences not to
re-generate a key. The public attestation key and certificate can be stored
unencrypted in any untrusted memory.

Before handing control to the monitor, \texttt{mroot} sets a lock that blocks
any software from reading the processor's symmetric key derivation seed and
private key until a reset occurs. This prevents a malicious security monitor
from deriving a different monitor's symmetric key, or from generating a monitor
attestation certificate that includes a different monitor's measurement hash.

The symmetric key generated for the monitor is similar in concept to the Seal
Keys produced by SGX's key derivation process, as it is used to securely store
a secret (the monitor's attestation key) in untrusted memory, in order to avoid
an expensive process (asymmetric key attestation and signing). Sanctum's key
derivation process is based on the monitor's measurement, so a given monitor is
guaranteed to get the same key across power cycles. The cryptographic
properties of the key derivation process guarantee that a malicious monitor
cannot derive the symmetric key given to another monitor.


\HeadingLevelD{The Signing Enclave}
\label{sec:sanctum_signing_enclave}

In order to avoid timing attacks, the security monitor does not compute
attestation signatures directly. Instead, the signing algorithm is executed
inside a signing enclave, which is a security monitor module that executes in
an enclave environment, so it is protected by the same isolation guarantees
that any other Sanctum enclave enjoys.

The signing enclave receives the monitor's private attestation key via an API
call. When the security monitor receives the call, it compares the calling
enclave's measurement with the known measurement of the signing enclave. Upon a
successful match, the monitor copies its attestation key into enclave memory
using a data-independent sequence of memory accesses, such as \texttt{memcpy}.
This way, the monitor's memory access pattern does not leak the private
attestation key.

Sanctum's signing enclave authenticates another enclave on the computer and
securely receives its attestation data using
mailboxes~(\S~\ref{sec:mailboxes}), a simplified version of SGX's local
attestation (reporting) mechanism. The enclave's measurement and attestation
data are wrapped into a software attestation signature that can be examined by
a remote verifier. Figure~\ref{fig:attestation_chain} shows the chain of
certificates and signatures in an instance of software attestation.

\begin{figure}[!htbp]
  \centering
  \includegraphics[width=80mm]{figures/attestation_chain.pdf}
  \caption{
    The certificate chain behind Sanctum's software attestation signatures.
  }
  \label{fig:attestation_chain}
%\EndFigure
\end{figure}
