<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:base="https://jbeekman.nl/">
  <id>https://jbeekman.nl/</id>
  <title>Side-channel Attacks – Technology &amp; Policy</title>
  <updated>2017-03-01T12:00:00Z</updated>
  <link rel="alternate" href="https://jbeekman.nl/"/>
  <link rel="self" href="https://jbeekman.nl/blog/side-channel-attacks/"/>
  <author>
    <name>Jethro Beekman</name>
    <uri>https://jbeekman.nl/blog</uri>
  </author>
  <icon>https://jbeekman.nl/favicon.ico</icon>
  <entry>
    <id>tag:jbeekman.nl,2017-03-01:/blog/2017/03/sgx-side-channel-attacks/</id>
    <title type="html">On the recent side-channel attacks on Intel SGX – Technology &amp; Policy</title>
    <published>2017-03-01T12:00:00Z</published>
    <updated>2017-03-01T12:00:00Z</updated>
    <link rel="alternate" href="https://jbeekman.nl/blog/2017/03/sgx-side-channel-attacks/"/>
    <content type="html">&lt;p&gt;&lt;a href="https://en.wikipedia.org/wiki/Side-channel_attack"&gt;Side-channel attacks&lt;/a&gt; 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 
&lt;em&gt;so&lt;/em&gt; cool” and “I didn’t even think about that.”&lt;/p&gt;

&lt;p&gt;In the past week, &lt;a href="https://arxiv.org/abs/1702.07521"&gt;two&lt;/a&gt; 
&lt;a href="https://arxiv.org/abs/1702.08719"&gt;papers&lt;/a&gt; have been published on arXiv 
detailing side-channel attacks on &lt;a href="https://software.intel.com/en-us/sgx"&gt;Intel 
SGX&lt;/a&gt;. 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.&lt;/p&gt;

&lt;p&gt;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 &lt;a href="http://www.cs.tau.ac.il/~tromer/papers/cache.pdf"&gt;Evict+Time and 
Prime+Probe&lt;/a&gt;, 
&lt;a href="https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-yarom.pdf"&gt;Flush+Reload&lt;/a&gt;, 
&lt;a href="https://arxiv.org/abs/1511.04594"&gt;Flush+Flush&lt;/a&gt;, etc. &lt;a href="https://eprint.iacr.org/2016/613"&gt;Ge et. 
al.&lt;/a&gt; present a good overview of the current 
state of the art. Intel explicitly states in their &lt;a href="https://software.intel.com/sites/default/files/managed/ae/48/Software-Guard-Extensions-Enclave-Writers-Guide.pdf"&gt;Enclave Writer’s 
Guide&lt;/a&gt; 
that they don’t protect against attacks at cache line or higher granularity.&lt;/p&gt;

&lt;p&gt;Second of all, both attacks are exploiting well-known flaws in modular 
exponentiation implementations. We &lt;em&gt;know&lt;/em&gt; how to do constant-time RSA. On top 
of that, both papers are at best slightly misleading in describing their attack 
targets.&lt;/p&gt;

&lt;p&gt;From the &lt;a href="https://arxiv.org/abs/1702.07521"&gt;first paper&lt;/a&gt;:&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;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 
&lt;a href="https://github.com/01org/linux-sgx/blob/6662022/external/crypto_px/sources/ippcp/src/pcpngrsamontstuff.c#L336"&gt;[32]&lt;/a&gt;. 
The Intel IIP library includes also a variant of RSA that is hardened against 
cache attacks 
&lt;a href="https://github.com/01org/linux-sgx/blob/6662022/external/crypto_px/sources/ippcp/src/pcpngrsamontstuff.c#L438"&gt;[33]&lt;/a&gt;.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;If you look at how these two variants are used, you can see that only 
&lt;a href="https://github.com/01org/linux-sgx/blob/6662022/external/crypto_px/sources/ippcp/src/pcpngrsaencodec.c#L180"&gt;computations with the public 
exponent&lt;/a&gt; 
are done with the “vulnerable” variant, whereas &lt;a href="https://github.com/01org/linux-sgx/blob/6662022/external/crypto_px/sources/ippcp/src/pcpngrsaencodec.c#L265"&gt;computations with the private 
exponent&lt;/a&gt; 
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.&lt;/p&gt;

&lt;p&gt;From the &lt;a href="https://arxiv.org/abs/1702.08719"&gt;second paper’s abstract&lt;/a&gt;:&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;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.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;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:&lt;/p&gt;

&lt;div class="language-c++ highlighter-coderay"&gt;&lt;div class="CodeRay"&gt;
  &lt;div class="code"&gt;&lt;pre&gt;&lt;span style="color:#0a8;font-weight:bold"&gt;int&lt;/span&gt; modexp(&lt;span style="color:#0a8;font-weight:bold"&gt;int&lt;/span&gt; base, &lt;span style="color:#0a8;font-weight:bold"&gt;int&lt;/span&gt; exponent, &lt;span style="color:#0a8;font-weight:bold"&gt;int&lt;/span&gt; modulus) {
    &lt;span style="color:#0a8;font-weight:bold"&gt;int&lt;/span&gt; result = &lt;span style="color:#00D"&gt;1&lt;/span&gt;;
    &lt;span style="color:#080;font-weight:bold"&gt;for&lt;/span&gt; (&lt;span style="color:#0a8;font-weight:bold"&gt;int&lt;/span&gt; i = &lt;span style="color:#00D"&gt;0&lt;/span&gt;; i &amp;lt; exponent.bits(); i++) {
        result = modsqr(result, modulus);
        &lt;span style="color:#080;font-weight:bold"&gt;if&lt;/span&gt; (exponent &amp;amp; (&lt;span style="color:#00D"&gt;1&lt;/span&gt;&amp;lt;&amp;lt;i)) { &lt;span style="color:#777"&gt;// access bit `i`&lt;/span&gt;
            result = modmul(result, base, modulus);
        }
    }
    &lt;span style="color:#080;font-weight:bold"&gt;return&lt;/span&gt; result;
}
&lt;/pre&gt;&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;

&lt;p&gt;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, &lt;a href="https://www.eng.tau.ac.il/~yash/infosec-seminar/2005/kocher95.pdf"&gt;first described by Kocher 22 years 
ago&lt;/a&gt;. Oh and 
the library? It implements the blinding mitigation also mentioned in that 
seminal paper.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;
</content>
    <summary type="html">&lt;p&gt;&lt;a href="https://en.wikipedia.org/wiki/Side-channel_attack"&gt;Side-channel attacks&lt;/a&gt; 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 &amp;#x201C;wow, that is 
&lt;em&gt;so&lt;/em&gt; cool&amp;#x201D; and &amp;#x201C;I didn&amp;#x2019;t even think about that.&amp;#x201D;&lt;/p&gt;</summary>
  </entry>
</feed>

