"We have successfully extracted attestation keys, which are the primary mechanism used to determine whether code is running under SGX. This allows any hacker to masquerade as genuine SGX hardware, while in fact running code in an exposed manner and peeking into your data. We demonstrate concrete security breaks on real-world software utilizing SGX, such asSecret Network,Phala,Crust, andIntegriTEE."
“[As SGX] memory encryption is deterministic, we are able to build a mapping between encrypted memory and its corresponding unencrypted memory. Although we cannot decrypt arbitrary memory, this encryption oracle is sufficient to break the security of constant-time cryptographic code.”
"WireTap is considered by Intel to be outside the threat model, as SGX offers no protections against physical attacks. Thus, there are no current mitigations besides running servers in secure physical environments. At the time of publication SGX running on Scalable Xeon servers is vulnerable to memory interposition attacks and we expect this will remain the case in the foreseeable future. We also reccomend reviewingIntel’s guidanceon WireTap and BatteringRAM."
This surely is an interesting attack based on a design flaw, but it requires physical access to the server. It isn’t news that substantial SGX vulnerabilities exist in both integrity and confidentiality if physical access of the attacker must be assumed.
This just emphasizes that SGX solutions shouldn’t rely on the security of a single machine alone or reliably limit who can have physical access. This new vulnerability doesn’t actually change anything in the general threat model evaluation of SGX.
IMO SGX still is a security enhancement if applied correctly.
Yes, that’s why it blows up the possibility of permissionless participation.
In other contexts, like banking or permissioned and trusted providers, it is less critical, but reintroduces full trust.
First you cannot assume any confidentiality in multi party computations and you need to check the correctness of them, so the model brings you nothing besides unedeed and costly redundancy?
Another fun attack using this: You work for a shipping or delivery company and run this attack on every CPU being shipped to some known heavy SGX user’s data center, like say Amazon. lol
If you want SGX then you should buy your CPU at some computer store in random cities, and pay in cash. At that point, you could’ve a zkSNARK anonymize your specific CPU, so if someone pre-broke it then they cannot realize which one you’re using.
You do need the node to be identified of course, because otherwise you need some complex process for registering the CPU via a threshold OPRF or whatever, but you could’ve the node be anonymouse identified using a ring VRF. All this last part seems othogonal to the attack of course.