\HeadingLevelB{Troubling Findings}
\label{sec:troubling_findings}

Reasoning about the security properties of Intel's SGX requires a significant
amount of background information that is currently scattered across many
sources. For this reason, a significant portion of this work is dedicated to
summarizing this prerequisite knowledge.

Section \ref{sec:architecture_background} summarizes the relevant subset of the
Intel architecture and the micro-architectural properties of recent Intel
processors. Section \ref{sec:security_background} outlines the security
landscape around trusted hardware system, including cryptographic tools and
relevant attack classes. Last, section \ref{sec:sgx_related} briefly describes
the trusted hardware systems that make up the context in which SGX was created.

After having reviewed the background information, section \ref{sec:sgx_model}
provides a (sometimes painstakingly) detailed description of SGX's programming
model, mostly based on Intel's Software Development Manual.

Section \ref{sec:sgx_extra} analyzes other public sources of information, such
as Intel's SGX-related patents, to fill in some of the missing details in the
SGX description. The section culminates in a detailed review of SGX's security
properties that draws on information presented in the rest of the paper. This
review outlines some troubling gaps in SGX's security guarantees, as well as
some areas where no conclusions can be drawn without additional information
from Intel.

That being said, perhaps the most troubling finding in our security analysis is
that Intel added a launch control feature to SGX that forces each computer's
owner to gain approval from a third party (which is currently Intel) for any
enclave that the owner wishes to use on the computer.
\S~\ref{sec:sgx_launch_control} explains that the only publicly documented
intended use for this launch control feature is a licensing mechanism that
requires software developers to enter a (yet unspecified) business agreement
with Intel to be able to author software that takes advantage of SGX's
protections. All official documentation carefully sidesteps this issue, and
has a minimal amount of hints that lead to the Intel's patents on SGX. Only
these patents disclose the existence of licensing plans.

The licensing issue may not bear much relevance now, as our
security analysis reveals that the limitations in SGX's guarantees mean that a
security-conscious software developer cannot in good conscience rely on SGX for
secure remote computation. At the same time, should SGX ever develop better
security properties, the licensing scheme described above becomes a major
problem, given Intel's near-monopoly market share of desktop and server CPUs.
Specifically, the licensing limitations effectively give Intel the power to
choose winners and losers in industries that rely on cloud computing.
