https://jbeekman.nl/SGX – Technology & Policy2017-03-01T12:00:00ZJethro Beekmanhttps://jbeekman.nl/bloghttps://jbeekman.nl/favicon.icotag:jbeekman.nl,2017-03-01:/blog/2017/03/sgx-side-channel-attacks/On the recent side-channel attacks on Intel SGX – Technology & Policy2017-03-01T12:00:00Z2017-03-01T12:00:00Z<p><a href="https://en.wikipedia.org/wiki/Side-channel_attack">Side-channel attacks</a> are
my favorite attack in computer security because they poke giant holes in the
abstraction and security models that system designers are using. When I hear of
a new attack avenue in this space, my first reaction often is “wow, that is
<em>so</em> cool” and “I didn’t even think about that.”</p>
<p>In the past week, <a href="https://arxiv.org/abs/1702.07521">two</a>
<a href="https://arxiv.org/abs/1702.08719">papers</a> have been published on arXiv
detailing side-channel attacks on <a href="https://software.intel.com/en-us/sgx">Intel
SGX</a>. While the existence of such attacks
should be taken seriously by people designing systems using Intel SGX (which
includes yours truly), these particular attacks are not very interesting.</p>
<p>First of all, these attacks really shouldn’t come as a surprise to anyone
following this space. Cache-based side-channel attacks are a well-known attack
vector. Many papers detailing new techniques have been published over the last
couple of years. There’s <a href="http://www.cs.tau.ac.il/~tromer/papers/cache.pdf">Evict+Time and
Prime+Probe</a>,
<a href="https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-yarom.pdf">Flush+Reload</a>,
<a href="https://arxiv.org/abs/1511.04594">Flush+Flush</a>, etc. <a href="https://eprint.iacr.org/2016/613">Ge et.
al.</a> present a good overview of the current
state of the art. Intel explicitly states in their <a href="https://software.intel.com/sites/default/files/managed/ae/48/Software-Guard-Extensions-Enclave-Writers-Guide.pdf">Enclave Writer’s
Guide</a>
that they don’t protect against attacks at cache line or higher granularity.</p>
<p>Second of all, both attacks are exploiting well-known flaws in modular
exponentiation implementations. We <em>know</em> how to do constant-time RSA. On top
of that, both papers are at best slightly misleading in describing their attack
targets.</p>
<p>From the <a href="https://arxiv.org/abs/1702.07521">first paper</a>:</p>
<blockquote>
<p>As our victim enclave we chose an RSA implementation from the Intel IIP
crypto library in the Intel SGX SDK. The attacked decryption variant is a
fixed-size sliding window exponentiation, the code is available online at
<a href="https://github.com/01org/linux-sgx/blob/6662022/external/crypto_px/sources/ippcp/src/pcpngrsamontstuff.c#L336">[32]</a>.
The Intel IIP library includes also a variant of RSA that is hardened against
cache attacks
<a href="https://github.com/01org/linux-sgx/blob/6662022/external/crypto_px/sources/ippcp/src/pcpngrsamontstuff.c#L438">[33]</a>.</p>
</blockquote>
<p>If you look at how these two variants are used, you can see that only
<a href="https://github.com/01org/linux-sgx/blob/6662022/external/crypto_px/sources/ippcp/src/pcpngrsaencodec.c#L180">computations with the public
exponent</a>
are done with the “vulnerable” variant, whereas <a href="https://github.com/01org/linux-sgx/blob/6662022/external/crypto_px/sources/ippcp/src/pcpngrsaencodec.c#L265">computations with the private
exponent</a>
use the “hardened” variant. So, unless you are somehow swapping your public and
private exponents, using this crypto library as documented will prevent this
attack for you.</p>
<p>From the <a href="https://arxiv.org/abs/1702.08719">second paper’s abstract</a>:</p>
<blockquote>
<p>We perform a Prime+Probe cache side-channel attack on a co-located SGX
enclave running an up-to-date RSA implementation that uses a constant-time
multiplication primitive.</p>
</blockquote>
<p>Even though the library they use might have a multiplication primitive that is
constant-time, as the authors explain further on in the paper, the modular
exponentiation primitive is not. In fact, the modular exponentiation algorithm
is the textbook example of an algorithm with a secret-dependent branch:</p>
<div class="language-c++ highlighter-coderay"><div class="CodeRay">
<div class="code"><pre><span style="color:#0a8;font-weight:bold">int</span> modexp(<span style="color:#0a8;font-weight:bold">int</span> base, <span style="color:#0a8;font-weight:bold">int</span> exponent, <span style="color:#0a8;font-weight:bold">int</span> modulus) {
<span style="color:#0a8;font-weight:bold">int</span> result = <span style="color:#00D">1</span>;
<span style="color:#080;font-weight:bold">for</span> (<span style="color:#0a8;font-weight:bold">int</span> i = <span style="color:#00D">0</span>; i < exponent.bits(); i++) {
result = modsqr(result, modulus);
<span style="color:#080;font-weight:bold">if</span> (exponent & (<span style="color:#00D">1</span><<i)) { <span style="color:#777">// access bit `i`</span>
result = modmul(result, base, modulus);
}
}
<span style="color:#080;font-weight:bold">return</span> result;
}
</pre></div>
</div>
</div>
<p>If for each iteration of the loop you can detect whether the multiplication
happenned or not, you can reconstruct the individual bits of the exponent. This
is a fun attack, but as mentioned, this is basically the most well-known timing
attack, <a href="https://www.eng.tau.ac.il/~yash/infosec-seminar/2005/kocher95.pdf">first described by Kocher 22 years
ago</a>. Oh and
the library? It implements the blinding mitigation also mentioned in that
seminal paper.</p>
<p>To summarize: Yes, programs running with Intel SGX are vulnerable to
side-channel attacks. The same side-channel attacks that have been used for
years on modern x86 platforms. This is well-documented. SGX does present a
slightly different threat model which makes deployment of side-channel attacks
more likely. Hopefully everyone using SGX is implementing countermeasures. They
do exist, and are already implemented by most cryptography libraries.</p>
<p><a href="https://en.wikipedia.org/wiki/Side-channel_attack">Side-channel attacks</a> are
my favorite attack in computer security because they poke giant holes in the
abstraction and security models that system designers are using. When I hear of
a new attack avenue in this space, my first reaction often is “wow, that is
<em>so</em> cool” and “I didn’t even think about that.”</p>tag:jbeekman.nl,2015-10-13:/blog/2015/10/intel-has-full-control-over-sgx/Intel has full control over SGX – Technology & Policy2015-10-13T12:00:00Z2015-10-13T12:00:00Z<p>Intel has full control over what software you can run in SGX. This might seem
redundant: Intel makes the processor, so of course they have full control. Yet
the truth is slightly more inconvenient. When Intel processors don’t run the
instructions in your standard software (whether incorrectly or at all), that is
a defect at best and a breach of contract at worst. Yet the SGX instruction set
<em>includes in its specification</em> that Intel has the authority to make this
go/no-go decision.</p>
<p>Let’s take a closer look at how exactly this is specified, since it is pretty
well-hidden. After creating and measuring a secure enclave using ECREATE, EADD,
and EEXTEND, the EINIT instruction needs to be executed before execution
control can be transferred to the enclave. The EINIT instruction has 2 inputs:
SIGSTRUCT and EINITTOKEN. SIGSTRUCT contains information about the enclave
including an expected hash of the memory. As the name implies, SIGSTRUCT is
also cryptographically signed using some key. EINITTOKEN also contains
information about the enclave including the same expected hash of the memory as
well as the expected public key for the signature. EINITTOKEN must be
<a href="https://en.wikipedia.org/wiki/Message_authentication_code">MAC</a>ed using the
so-called <em>launch key</em>. Both SIGSTRUCT and EINITTOKEN are checked by EINIT and
must be valid for execution to proceed succesfully.</p>
<p>Since the launch key is a symmetric cryptography device, surely this key is not
widely distributed and most likely is CPU-specific. But how can one obtain this
key? The EGETKEY instruction can be used to obtain SGX keys, including the
launch key. But this is a user-mode instruction that can only be executed from
inside an enclave. There seems to be a chicken-and-egg problem here: to launch
an enclave, we need the launch key. To get the launch key, we need to launch an
enclave! Here’s the catch: the EINITTOKEN need not be valid if SIGSTRUCT is
signed by an Intel key that is baked into the processor.</p>
<p>Thus, Intel can distribute an Intel-signed “launch enclave” that is able to
hand out correctly-MACed EINITTOKENs that can then be used to start other
enclaves. But they can include whatever logic they want in the launch enclave
so Intel can at its sole discretion choose not to MAC a particular EINITTOKEN.</p>
<p>As most things SGX, this “feature” is severely underdocumented. The terms
“launch key” and “launch enclave” are only mentioned a few times in the SGX
programming reference and never in the whitepapers or tutorials. At the time of
writing, nowhere else on the Internet is there any mention of these keywords,
except for one <a href="https://www.quora.com/What-are-some-good-uses-for-Intel-Software-Guard-Extensions-SGX">insightful Quora
answer</a>
that I wish I had read months ago.</p>
<p>What reason could Intel have for this architecture? Along with the fact that
<a href="/blog/sgx-hardware-first-look">SGX is being disabled by default</a>, this looks
like Intel is again just setting this security technology up for failure due to
the lack of widespread adoption by developers and users alike (cf. TXT, SMX,
TPM).</p>
<p>Intel has full control over what software you can run in SGX. This might seem
redundant: Intel makes the processor, so of course they have full control. Yet
the truth is slightly more inconvenient. When Intel processors don’t run the
instructions in your standard software (whether incorrectly or at all), that is
a defect at best and a breach of contract at worst. Yet the SGX instruction set
<em>includes in its specification</em> that Intel has the authority to make this
go/no-go decision.</p>tag:jbeekman.nl,2015-10-08:/blog/2015/10/sgx-hardware-first-look/SGX Hardware: A first look – Technology & Policy2015-10-08T12:00:00Z2015-12-09T12:00:00Z<p>Without much fanfare, Intel has released <a href="https://software.intel.com/en-us/isa-extensions/intel-sgx">Software Guard Extensions
(SGX)</a> in Skylake.
When I say “without much fanfare,” I mean practically only the following
paragraph hidden on page 3 of a <a href="http://download.intel.com/newsroom/kits/core/6thgen/pdfs/6th_Gen_Intel_Core-Intel_Xeon_Factsheet.pdf">press fact
sheet</a>:</p>
<blockquote>
<p><strong>BETTER SECURITY.</strong> The Skylake architecture has been designed to enable better
security, including Intel® Software Guard Extensions (Intel® SGX) that can
provide an additional level of hardware-based protection by putting data into
a secure container on the platform, and Intel® Memory Protection Extensions
(Intel® MPX) that can help prevent buffer flow attacks. [What’s a buffer flow
attack? <em>Ed.</em>] To be fully utilized, Intel SGX and Intel MPX require additional
software capabilities, which will begin to be delivered by the ecosystem
later this year.</p>
</blockquote>
<p>It has been extremely difficult to find actual hardware that supports SGX. BIOS
support is required–the BIOS needs to set aside memory for the Enclave Page
Cache (EPC)–but of course no vendor will mention anything about this on their
website, nor will they (be able to) answer when you inquire regarding this
specific issue.</p>
<p>To my delight, by using Google to search past week results for “intel sgx” for
the last few months, I was finally able to find a driver download site that
linked this <a href="http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=F84XC">Dell
driver</a>.
According to Dell’s website, this driver is compatible with the following machine models:</p>
<ul>
<li>Inspiron 11 i3153</li>
<li>Inspiron 11 i3158</li>
<li>Inspiron 13 i7353</li>
<li>Inspiron 13 i7359</li>
<li>Inspiron 15 i7568</li>
</ul>
<p>At first I couldn’t find these models mentioned anywhere, but a few days later
the i7359 showed up at
<a href="http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&Description=dell+i7359">NewEgg</a>
and then at <a href="http://frys.com/search?query_string=dell+i7359">Frys</a>. So, I drove
to Sunnyvale (where Frys had the i7359-2435SLV in stock) and I can now confirm
that <strong>SGX is real</strong>:</p>
<div style="width:100%;text-align:center">
<a href="/img/blog/sgx-hardware-first-look/bios1.jpeg"><img src="/img/blog/sgx-hardware-first-look/bios1-small.jpeg" style="width:45%;margin-right:3.3%" /></a>
<a href="/img/blog/sgx-hardware-first-look/bios2.jpeg"><img src="/img/blog/sgx-hardware-first-look/bios2-small.jpeg" style="width:45%" /></a>
</div>
<p>It’s interesting to note that SGX was disabled in the BIOS by default, so most
consumers will not be able to benefit from this feature at all.</p>
<p>The maximum size of the EPC on this laptop is 128MB. This means that enclaves
requiring more memory than that will need regular paging between the EPC and
main memory. It’s not clear whether such a copy would require re-encryption of
the page, the EPC itself is already encrypted so it might not be necessary.</p>
<p>The laptop comes with Windows 10 which runs excruciatingly slow–not surprising
considering it only has 4GB of RAM. I installed Arch Linux on it because it’s
one of the few distro’s that has an installer with a very recent kernel
(4.2.2), required for such new hardware.</p>
<p>I collected some CPUID and MSR information to see what SGX features are
supported:</p>
<blockquote>
<p><strong>CPUID</strong></p>
<pre><code> bit 2 (SGX) is set
v
7h(0h) 00000000h 029c67afh 00000000h 00000000h
Max. enclave size 2^31 bytes (32-bit mode)
Max. enclave size 2^36 bytes (64-bit mode) |
No extended SSA features supported | |
SGX version 1 supported | |\/|
v v vvvv
12h(0h) 00000001h 00000000h 00000000h 0000241fh
all enclave attributes supported
|\ all XSAVE bits supported
vv vv
12h(1h) 00000036h 00000000h 0000001fh 00000000h
EPC physical address 80200000h
////| |\\\\\\\ EPC size 93.5 MiB
vvvvv vvvvvvvv vvvvv vvvvvvvv
12h(2h) 80200001h 00000000h 05d80001h 00000000h
</code></pre>
<p><strong>MSR</strong></p>
<pre><code> bit 18 (SGX_ENABLE) is set
| bit 0 (LOCK) is set
v v
3ah 00000000_00040005h (IA32_FEATURE_CONTROL)
</code></pre>
</blockquote>
<p>I’m currently writing a simple Linux kernel driver to be able to actually use
SGX. I managed to generate a Page Fault using the <code>ENCLS[EBLOCK]</code> instruction,
so at least something seems to be working.</p>
<p>I really wish Intel would be more forthcoming with information about and
developer support for SGX. The hardly-announced release and default-disabled
BIOS setting don’t warrant much hope for the future of SGX.</p>
<p>In the mean time, I intend to write more blog posts in the near future as I try
to get SGX up and running. Here’s a cliff hanger for you: the Dell driver
package mentioned earlier contains a file <code>aesm_service.exe</code> that contains the
string “SGX EPID provisioning network failure.” I’ll try to tell you more about
it next time.</p>
<p><strong>Update 2015-12-09:</strong> Please see my
<a href="https://github.com/jethrogb/sgx-utils">sgx-utils</a> repository for any
open-source SGX utilities, including a bare-bones development Linux driver.</p>
<p>Without much fanfare, Intel has released <a href="https://software.intel.com/en-us/isa-extensions/intel-sgx">Software Guard Extensions
(SGX)</a> in Skylake.
When I say “without much fanfare,” I mean practically only the following
paragraph hidden on page 3 of a <a href="http://download.intel.com/newsroom/kits/core/6thgen/pdfs/6th_Gen_Intel_Core-Intel_Xeon_Factsheet.pdf">press fact
sheet</a>:</p>