\HeadingLevelB{Threat Model}
\label{sec:threat_model}

Sanctum isolates the software inside an \textbf{enclave} from other software on
the same computer. All outside software, including privileged system software,
can only interact with an enclave via a small set of primitives provided by the
security monitor. Programmers are expected to move the sensitive code in their
applications into enclaves. In general, an enclave receives encrypted sensitive
information from outside, decrypts the information and performs some
computation on it, and then returns encrypted results to the outside world.


For example, medical imaging software would use an enclave to decrypt a
patient's X-ray and produce a diagnostic via an image processing algorithm.
Application code that does not handle sensitive data, such as receiving
encrypted X-rays over the network and storing the encrypted images in a
database, would not be enclaved.

Sanctum assumes that an attacker can compromise any operating system and hypervisor
present on the computer executing the enclave, and can launch rogue enclaves.
The attacker knows the target computer's architecture and micro-architecture.
The attacker can analyze passively collected data, such as page fault
addresses, as well as mount active attacks, such as direct or DMA memory probing, and cache timing attacks.

Sanctum's isolation protects the integrity and privacy of the code and data
inside an enclave against any practical \textbf{software} attack that relies
on observing or interacting with the enclave software via means outside
the interface provided by the security monitor. In other words, Sanctum does not
protect enclaves that leak their own secrets directly (e.g., by writing to
untrusted memory) or by timing their operations (e.g., by modulating their
completion times). In effect, Sanctum solves the security problems that emerge
from sharing a computer among mutually distrusting applications.

This distinction is particularly subtle in the context of cache timing attacks.
Sanctum does not protect against attacks like the one in \citep{brumley2005rsa}, where the victim
application leaks information via its public API, and the leak occurs even if
the victim runs on a dedicated machine. Sanctum \emph{does} protect against attacks
like Flush+Reload~\citep{yarom2013llctiming}, which exploit shared hardware
resources to interact with the victim via methods outside its public API.

Sanctum also defeats attackers who aim to compromise an OS or
hypervisor by running malicious applications and enclaves. This addresses
concerns that enclaves provide new attack vectors for malware
\citep{wojtczuk2013sgx2, davenport2014sgx}. Sanctum assumes that the benefits of
meaningful software isolation outweigh enabling a new avenue for frustrating malware detection and reverse engineering
\citep{dunn2011cloaking}.

Lastly, Sanctum protects against a malicious computer owner who attempts to lie
about the security monitor running on the computer. Specifically, the attacker
aims to obtain an attestation stating that the computer is running an
uncompromised security monitor, whereas a different monitor had been loaded in
the boot process. The uncompromised security monitor must not have any known
vulnerability that causes it to disclose its cryptographic keys. The attacker
is assumed to know the target computer's architecture and micro-architecture,
and is allowed to run any combination of malicious security monitor,
hypervisor, OS, applications and enclaves.

Sanctum does not prevent timing attacks that exploit bottlenecks in the cache
coherence directory bandwidth or in the DRAM bandwidth, deferring these to
future work. The {\em latency} of memory operations exhibited by high-end DRAM controllers, however,
has been shown a viable threat surface for timing attacks~\citep{dram_timing_attack},
including in the context of SGX enclaves~\citep{dram_timing_attack_sgx}, meaning Sanctum
enclaves must map DRAM regions to disjoint DRAM banks (this is the responsibility of the OS, and is
checked during attestation), or implement a constant
access latency DRAM controller, in order to guarantee confidentiality
of DRAM accesses. In general, any component of the system that exhibits variable
timing due to the behavior of software must be considered a potential threat surface
and addressed appropriately.

Sanctum does not protect against denial-of-service (DoS) attacks by
compromised system software: a malicious OS may deny service by refusing to
allocate any resources to an enclave. Sanctum \emph{does} protect against malicious
enclaves attempting to DoS an uncompromised OS.
%, as the operating system is always able to take away all CPU cores from an
%enclave, and then delete the enclave.

Sanctum assumes correct underlying hardware, so it does not
protect against software attacks that exploit hardware bugs (fault-injection attacks), such as rowhammer
\citep{kim2014rowhammer, google2015rowhammer}.

Sanctum's isolation mechanisms exclusively target software attacks.
\S~\ref{sec:related_work} mentions related work that can harden a Sanctum
system against some physical attacks. Furthermore, software attacks
that rely on sensor data are considered to be physical attacks. For example, Sanctum does not address
information leakage due to power variations, because software would require a
temperature or current sensor to carry out such an attack.
