Security
The security model
What a Nitro Enclave protects, what it doesn’t, and what you’d still have to trust. Plainly, because a security review will ask anyway.
What we’re protecting
Two things. The private key, which must never be readable outside the enclave. And the rule that nothing gets signed unless it passes your policy.
What the enclave gives you
In AWS’s own words:
Enclaves are separate, hardened, and highly-constrained virtual machines. They provide only secure local socket connectivity with their parent instance. They have no persistent storage, interactive access, or external networking. Users cannot SSH into an enclave, and the data and applications inside the enclave cannot be accessed by the processes, applications, or users (root or admin) of the parent instance.
That’s from the Nitro Enclaves user guide. The Nitro Hypervisor gives the enclave its own CPUs and memory, taken from the instance, and the instance can’t reach them. The enclave can also prove what it’s running: it asks the Nitro Security Module for a signed attestation document that carries the measurements of its image, and AWS KMS can check those measurements before it releases a key.
How a key would get in
Today it doesn’t: the enclave creates its own key and wipes it when it stops. To keep a key across restarts, the design seals it with AWS KMS under a key policy that allows decryption only for an enclave whose measurement matches the image you approved, using KMS’s attestation conditions on PCR0 and the image hash. That policy is written; the enclave’s side isn’t built yet. More on the key’s lifecycle.
What you still have to trust
- AWS. The Nitro Hypervisor, the hardware and KMS sit under everything. An enclave protects you from your own instance, its admins, its root user and anyone who breaks into it. It doesn’t protect you from AWS.
- The image. Attestation proves which image is running, not that the image is any good. It means something only if you build the image yourself from the source, or check that our build reproduces the same measurement. We haven’t shown reproducible builds yet, so in a pilot you’d build it in your own account.
- Your policy. The enclave enforces your rules exactly as written. It can’t tell a bad rule from a good one.
- Us. You’d be running code we wrote: read it, and we’ll walk you through it. One thing to know up front: the prototype’s host has a licence step that sends the enclave’s attestation document and a licence key to our server before signing is unlocked. Your keys and orders are never part of it.
What it doesn’t stop
- A trading strategy that sends bad orders your policy allows.
- Someone with control of the instance stopping the enclave. They can’t read the key, but they can switch it off, and today the key goes with it.
- Side channels on hardware the enclave shares with its instance. We haven’t analysed them.
- Bugs in Sentinel itself.
What we don’t have yet
No third-party security review of Sentinel. No SOC 2 report or other certification. No bug bounty. We’d rather show you the design and the code than a badge we haven’t earned. The signing library underneath, RustCrypto’s k256, was reviewed by NCC Group in 2023, which isn’t the same thing as a review of Sentinel.
Reporting a problem
Email [email protected] with what you found and how to reproduce it. We’ll answer, keep you posted on the fix, and credit you if you’d like. Our contact details are also in security.txt.