A few notes on AWS Nitro Enclaves: Attack surface

Summary: Trail of Bits analyzed the attack surface of AWS Nitro Enclaves and found that the parent EC2 instance, whose kernel and nitro_enclaves drivers should be assumed attacker-controlled, is the only component with direct access to an enclave through the local vsock. The post covers vsock socket issues, CID confusion, entropy sources such as the Nitro TPM's nsm-hwrng, timing and L3 cache side channels, and memory limits, noting that enclave memory is carved from the parent instance and that Nitro provides no data sealing mechanism.
What you should know: The parent EC2 instance can take almost system-clock-precise timing measurements against its enclaves, so network jitter is not a mitigation, and in the worst case an enclave shares an L3 cache with that same parent. Because a single compromised enclave component should be treated as a total enclave compromise, the isolation you are relying on has a narrower margin than the architecture suggests.

Read the original at Trail of Bits Blog ↗