AWS Nitro Enclaves
aws.amazon.com
aws.amazon.com
From a side-channel perspective it's likely better than SGX as I presume EC2 already uses more resilient core affinity (e.g. no hyperthreaded core sharing across instances) and other mitigations, many of which aren't even possible with SGX.
OTOH, their PKI system and other implementation details are likely much more complicated than Intel's SGX system (which also utilizes an online, centralized authority), with many more avenues of attack. There are just many more moving parts with EC2. But it's difficult to say as it's all proprietary.
TL;DR: From a general data confidentiality perspective, EC2 is likely better. From a nation state-level attacker looking to subvert attestation, I'd lean Intel.
A primary point of SGX is confidentiality: the host OS can’t map and read enclave pages because the contents are encrypted and the hardware will generate an exception on any attempt. In other words, your data is confidential from even the infrastructure operator.
None of this confidentiality applies here, so it’s mostly irrelevant whether the side channels are better mitigated. The host OS can dump data whenever it wants. The better protections against side channels is pure speculation, ... and it’s nonsense to say that Nitro is uniquely capable of core isolation. This would work equally as well for limiting side channels for SGX — disabling hyperthreading is literally Intel’s recommendation AFAIK.
Of course, those side channels would still be exploitable by the host. But in this case, Amazon wouldn’t even need the side channels, since the door is wide open. This system appears to be providing only integrity measurements, a locked down data plane, and standard hypervisor isolation.
I’ve got nothing against this product (and I have mixed feelings about SGX) but the conclusion that EC2 is better for “general data confidentiality” is a weird assertion. Maybe you could make an argument that it makes integrity better, easier, etc. but not confidentiality.
You're still trusting Intel to truthfully verify attestation. Intel could lie about this. Ultimately you're trusting the vendor implementing the environment and providing the attestations to behave as they claim, independent of the technical characteristics of the environment.
But in terms of the technical characteristics, it seems far easier to mitigate side channels in an environment like EC2 than SGX. And that's what I based my opinion on.
The way they were described was as a secondary EC2 instance that inherited however much CPU and RAM from a primary instance that you wanted to assign it. He actually mentioned being able to run a full OS in the enclave. The secondary instance would be associated with a primary EC2 instance with strong constraints on connectivity, being only able to communicate with the primary EC2 instance via vsock and with KMS (maybe other AWS services as well).
Another session mentioned the code was cryptographically signed and potentially couldn’t be changed.