On the recent side-channel attacks on Intel SGX

by Jethro Beekman – Mar 1, 2017 . Filed under: English, Technology, Security, SGX, Side-channel Attacks.

Side-channel attacks 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 so cool” and “I didn’t even think about that.”

In the past week, two papers have been published on arXiv detailing side-channel attacks on Intel SGX. 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.

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 Evict+Time and Prime+Probe, Flush+Reload, Flush+Flush, etc. Ge et. al. present a good overview of the current state of the art. Intel explicitly states in their Enclave Writer’s Guide that they don’t protect against attacks at cache line or higher granularity.

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

From the first paper:

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 [32]. The Intel IIP library includes also a variant of RSA that is hardened against cache attacks [33].

If you look at how these two variants are used, you can see that only computations with the public exponent are done with the “vulnerable” variant, whereas computations with the private exponent 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.

From the second paper’s abstract:

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.

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:

int modexp(int base, int exponent, int modulus) {
    int result = 1;
    for (int i = 0; i < exponent.bits(); i++) {
        result = modsqr(result, modulus);
        if (exponent & (1<<i)) { // access bit `i`
            result = modmul(result, base, modulus);
        }
    }
    return result;
}

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, first described by Kocher 22 years ago. Oh and the library? It implements the blinding mitigation also mentioned in that seminal paper.

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.