\HeadingLevelB{Intel SGX is Not the Answer}

Unfortunately, although the SGX design includes a vast array of defenses against a
variety of software and physical attacks, it fails to offer meaningful software
isolation guarantees. The SGX threat model protects against all direct attacks,
but excludes ``side-channel attacks'', even if they can be performed via
software alone.

Alarmingly, cache timing attacks require only unprivileged software
running on the victim's host computer, and do not rely on any physical
access to the machine. This is particularly concerning in a cloud computing
scenario, where gaining software access to the victim's computer only
requires a credit card \citep{ristenpart2009colocation}, whereas physical
access is harder, requiring trespass, coercion, or social
engineering on the cloud provider's employees.

Similarly, in many Internet of Things (IoT) scenarios, the processing units have
some amount of physical security, but they run outdated software stacks that
have known security vulnerabilities. For example, an attacker may exploit a
vulnerability in an IoT lock's Bluetooth stack and obtain software execution
privileges, then mount a cache timing attack on its access-granting process,
and obtain the cryptographic key that opens the lock.

Furthermore, the analysis
%~\citep{costan2016sgxexplained}
of SGX documentation as described in Part I of this work reveals that it
is impossible for anyone but Intel to reason about SGX's security properties,
because significant implementation details are not covered by the publicly
available documentation. This is a concern, as the myriad of
security vulnerabilities \citep{wojtczuk2011txt, wojtczuk2009txt,
wojtczuk2009txt2, duflot2006smm, rutkowska2008remap, wojtczuk2009smm,
wecherowski2009smm, embleton2010smm} in TXT~\citep{grawrock2009txt}, Intel's
previous attempt at securing remote computation, show that securing the
machinery underlying Intel's processors is incredibly challenging, even in the
presence of strong economic incentives.

If a successor to SGX claimed to protect against cache timing attacks,
substantiating such a claim would require an analysis of its hardware and
microcode, and ensuring that no implementation detail is vulnerable to cache
timing attacks. Barring a highly unlikely shift to open-source hardware from
Intel, such analysis will never happen.

A concrete example: the SGX documentation \citep{intel2013sgxmanual,
intel2014sgx2manual} does not state where SGX stores the EPCM (enclave page
cache map). If the EPCM is stored in cacheable RAM, page translation
verification is subject to cache timing attacks. Interestingly, this
detail is unnecessary for analyzing the security of today's SGX
implementation, as we know that SGX uses the operating system's
page tables, and page translations are therefore vulnerable to cache timing
attacks. The example does, however, demonstrate the fine nature of crucial
details that are simply undocumented in today's hardware security
implementations.

%  %% This no longer appears to be entirely factual:
%  Furthermore, SGX includes a hardware-enforced
%  licensing scheme that requires developers who wish to take advantage of SGX's
%  security to negotiate a business agreement with Intel. If SGX gains
%  widespread adoption, the licensing scheme built into it would give Intel the
%  power to choose winners and losers in any market where products can benefit
%  from secure remote computation, which includes Software as a Service (SaaS),
%  video games, and Internet of Things (IoT) applications. This is very similar
%  to the Net Neutrality issue in the United States, where a handful of
%  colluding Internet Service Providers are stifling innovation by extorting
%  money from service providers in return for not throttling the traffic between
%  the services and their users.

In summary, while the principles behind SGX have great potential, the SGX
design does not offer meaningful isolation guarantees, and the SGX implementation
is not open enough for independent researchers to be able to analyze its
security properties. % and the SGX licensing plan threatens to have a chilling
%  effect on security software innovations.
