Intel SGX Hardware Vulnerabilities


According to the article located here:

Intel SGX hardware is vulnerable to a speculative execution-based attack. Intel has addressed these vulnerabilities by updating the microcode where every time the processor leaves execution of an enclave, it also flushes the level 1 cache and other fixes. However, according to the article, “These cases don’t, however, completely eliminate the risks, especially when hyperthreading is used. With hyperthreading, one logical core can be within SGX, hypervisor, or SMM code, while the other logical core is not. The other logical core can thus snoop on level 1 cache, and the extra cache flushes can’t prevent this (though they can certainly make it less convenient, due to the increased chance of a flush occurring during an attack).”

What solutions are being offered in the short and long term to address these vulnerabilities? How will Enigma adapt to evolving threats? Once MPC is up and running does this eliminate this threat entirely (i.e. is the reliance on TEEs completely removed)?


The biggest concern with these recent attacks is being able to extract the remote attestation keys, allowing you not only to read information but to actually tamper with computations.

As the article described, to a large extent, the software patch goes most of the way in mitigating this, and the next batch of processors is likely going to fix these concerns completely.

That said, we aren’t planning to rely just on SGX for security. Discovery is being designed in a way that ensures multiple workers execute each computation (similarly to how the whitepaper described it with MPC). To do any damage, an attacker now has to compromise all/most of the nodes in a group, break each of their SGXes (which is still hard), and do so quickly enough before the network re-shuffles the groups (happens every epoch). Even without SGX, this method is secure assuming the groups are big enough (say 30-100 nodes). With SGX, I believe the groups can be made much smaller (e.g., 5-20 nodes per group and even less in the future when TEEs have been tested for years).

This gets trickier for privacy, and in fact - there’s a clear trade-off between integrity and privacy in that regard. It suffices to break a single node’s SGX in a computation to be able to leak the data. The more nodes participating in a computation, the riskier it becomes that one of them would be malicious enough to go through the trouble of leaking the data.

Decentralization helps here as well, because nodes in the network can’t predict which data their worker will compute over - so if I’m a malicious worker that is interested in leaking data, I need to:

  1. Break my SGX, which is hard now, and will be made harder and harder (and hopefully very expensive/infeasible) as TEE tech evolves.
  2. Hope that the shard of data I hold is meaningful to me in some way.

Beyond that, if you want stronger privacy guarantees - well that’s exactly what MPC is meant to help you with. With MPC, it’s no longer enough to break a single node to get any piece of data.