- Newest
- Most votes
- Most comments
Q1: NSM lacks a monotonic counter
NSM provides three features—attestation reports, PCR state manipulation, and entropy (HWRNG)—but offers no persistent counters or sequence numbers.
While ExtendPCR is monotonic, it is so only within the enclave's lifetime. The value resets upon reboot, and since there is no persistent storage, it cannot be sealed and carried over. As you noted, the timestamp in the attestation document indicates when the document was generated; it reveals nothing about whether a "newer state" exists.
This is not an oversight but a gap in the platform design. While SGX (albeit with its own issues) has monotonic counters and TPMs have NV counters, Nitro does not.
Q3: No service other than KMS supports attestation binding—but the premise can be reframed
KMS (and recently NitroTPM) is the only service with condition keys (kms:RecipientAttestation:*) natively linked to attestation documents; other AWS services lack this feature.
However, if you terminate TLS within the enclave, you can achieve equivalent freshness guarantees for any service.
This is a point worth reconsidering. You mentioned that requests could be held or replayed unless cryptographically bound to a challenge chosen by the enclave for that specific request—but the TLS handshake serves as exactly that challenge. The enclave selects the ClientRandom, and session keys are derived uniquely for each handshake. Injecting a response from an old session into a new session will fail decryption and authentication.
Therefore:
- The vsock-proxy merely transports byte streams and cannot break TLS.
- Pin the AWS Root CA inside the enclave and perform SigV4 signing within the enclave.
- Directly invoke DynamoDB operations using strongly consistent reads and conditional writes.
The parent instance can only block or delay requests. This results in reduced availability, not a silent rollback. If the enclave is implemented with a "fail-closed" design, integrity is maintained.
Q2: Established Patterns
A configuration consisting of a single enclave and an untrusted host cannot solve this problem in principle. What is required is either trusted persistent state or a witness that the enclave can authenticate and whose freshness is guaranteed.
A standard academic approach is ROTE, a method where a group of enclaves across multiple platforms cooperatively maintain a monotonic counter. However, ROTE assumes a static set of nodes that must be pre-configured by an administrator, and it requires the application enclave to run on one of the ROTE nodes.
In practical terms, the following combinations offer realistic solutions:
1. TLS-in-enclave + DynamoDB conditional writes
Maintain a head hash and a version number, requiring a version match via ConditionExpression. While the host could spoof a successful write, the inconsistency would be exposed during the next strongly consistent read.
2. Duplication with existing KMS encryption context
Retain the "binding the head hash to the encryption context" mechanism you have already implemented. An attack would only succeed if both a DynamoDB rollback and the retention of the old KMS ciphertext were achieved simultaneously.
3. Placing the witness store in a separate account
As a countermeasure against privileged insiders on the host, this effectively establishes a separation of duties. The approach you considered—replicating data to an append-only store in a separate account—is correct; combining this with TLS-in-enclave ensures response freshness.
4. Enclave quorum
If truly strong guarantees are required, implement a consensus protocol (like Raft) across multiple enclaves—similar to ROTE—so that a rollback would require compromising the quorum. Signal and others have adopted this approach on SGX. Note, however, that operational costs will increase significantly. To summarize: Q1 is definitively "no"; regarding Q3, while it currently relies solely on KMS, the underlying assumptions can be restructured using TLS-in-enclave; and for Q2, the problem cannot be solved with a single enclave—the practical solution involves a combination of TLS-in-enclave, conditional writes, and cross-account isolation, whereas the complete solution requires a quorum.
Relevant content
asked 10 months ago
asked a year ago
Thank you — the point that the TLS handshake is the enclave-chosen challenge is what I was missing.
One gap though: I think TLS closes replay but not misdirection.
The enclave has no IAM identity of its own; credentials come from the parent. A malicious parent can supply credentials for an account it controls and point the enclave at its own DynamoDB table. The enclave then reads over a genuine, correctly pinned TLS session and gets entries that verify perfectly — because the attacker copied real, enclave-signed entries into that table. The rollback succeeds and every check passes.
TLS proves I'm talking to a DynamoDB endpoint, not to my table. KMS avoids this because the binding comes from the ciphertext being tied to a specific CMK, not from the transport.
Trail of Bits suggests attesting the expected IAM role and validating it at runtime via sts:GetCallerIdentity. Two questions:
Is comparing the full role ARN from sts:GetCallerIdentity against a value baked into the EIF sufficient? The account ID is in the ARN, so I think so, but I'd rather not assume.
Would you still keep the KMS encryption-context layer on top? My instinct is yes, since it's the only binding that doesn't depend on credential provenance.