> The security assumptions that SGX is built on are flawed. They assume that no side channel attacks will be mounted to determine the processes that occur in side the chip.
Protecting against side channel attacks and reverse engineering is the responsibility of developers who use SGX, according to Intel's website and user manual:
> Intel designs the Intel Software Guard Extensions to protect against known hardware attacks [...] Intel Software Guard Extensions is not designed to handle side channel attacks or reverse engineering. It is up to the Intel SGX developers to build enclaves that are protected against these types of attack.
Intel's assumptions appear to correctly account for the fact that side channels can occur. They have assessed whether their product is designed to protect against that class of attack, and assigned responsibility for defending against it. What do you think they should do differently?
You're correct. My original statement was wrong regarding Intel's assumption. The principle issue is that developers shouldn't assume that processes that occur in SGX are obfuscated in any sense because you can build SGX sidechannel detection within software that runs inside the enclave
The lecture I pointed to shows an example of this attack.
Protecting against side channel attacks and reverse engineering is the responsibility of developers who use SGX, according to Intel's website and user manual:
> Intel designs the Intel Software Guard Extensions to protect against known hardware attacks [...] Intel Software Guard Extensions is not designed to handle side channel attacks or reverse engineering. It is up to the Intel SGX developers to build enclaves that are protected against these types of attack.
Intel's assumptions appear to correctly account for the fact that side channels can occur. They have assessed whether their product is designed to protect against that class of attack, and assigned responsibility for defending against it. What do you think they should do differently?