8 minmedium
A few notes on AWS Nitro Enclaves: KMS integration
This article catalogs passive and active attack classes against the communication channel between AWS Nitro Enclaves and AWS KMS. Passive attacks include data swap attacks on encrypted data keys, CMK substitution via manipulable metadata, key commitment issues, and replay attacks within the 5-minute attestation validity window. Active attacks exploit the lack of cryptographic binding between attestation documents and request parameters, requiring enclave-initiated TLS with a pinned CA for mitigation. The authors also identify vulnerabilities in the aws-nitro-enclaves-sdk-c library and recommend alternative SDKs.
Conf:high
Detection / Hunteropenrouter
What Happened
Researchers at Trail of Bits published a detailed analysis of security risks in how AWS Nitro Enclaves (isolated compute environments) communicate with AWS Key Management Service (KMS, a service for managing encryption keys). They found that a malicious server host can perform several types of attacks, including swapping encrypted data keys, substituting which master key is used, and replaying attestation documents within a 5-minute window. The official C-language SDK for enclave-KMS communication contains vulnerabilities that can be exploited from the host machine, so the researchers recommend using alternative libraries instead. Organizations using Nitro Enclaves with KMS should review their key policies, use encryption contexts, hardcode full key ARNs, implement enclave-initiated TLS with a pinned certificate, and audit their threat models to account for these risks.
Key Takeaways
- The aws-nitro-enclaves-sdk-c (C SDK) contains vulnerabilities exploitable from the parent host; use aws-nitro-enclaves-nsm-api (Rust) and Boto3 KMS.Client (Python) instead.
- Passive attackers can perform data swap attacks by substituting encrypted data keys or ciphertexts if encryption context is not properly used or is attacker-controlled.
- CMK substitution attacks allow a malicious host to force use of an unprotected CMK; mitigate by hardcoding full ARN, validating keyId in responses, and attesting IAM roles via sts:GetCallerIdentity.
- Active attacks (CMK substitution, data key replay, AES-CBC attacks on CiphertextForRecipient) are only preventable with enclave-initiated TLS with a pinned, attested CA certificate.
- KMS terminates TLS outside the HSM, meaning AWS insiders could theoretically constitute an active attacker threat; threat models should account for this.
Affected Systems
- AWS Nitro Enclaves
- AWS Key Management Service (KMS)
- Applications using aws-nitro-enclaves-sdk-c
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Malicious host or passive attacker observes or modifies enclave-KMS communication channel
- Data Swap: Attacker substitutes encrypted data key or ciphertext blob stored outside enclave, potentially providing arbitrary plaintext to enclave
- CMK Substitution: Attacker manipulates CiphertextBlob metadata (HBKID) or keyId parameter to force use of an unprotected CMK
- Replay: Attacker reuses a valid attestation document within the 5-minute validity window with different KMS operations or parameters
- Active Attack: Attacker modifies network traffic, changes CMK IDs in requests/responses, encrypts data keys under attestation pubkey, or attacks AES-CBC in CiphertextForRecipient responses
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No detection rules are provided. The article offers architectural checklists and policy examples for hardening enclave-KMS integrations.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | None | Attacks occur within the AWS cloud infrastructure layer (enclave-to-KMS communication). EDR agents on EC2 hosts have no visibility into Nitro Enclave network traffic or KMS API calls originating from inside the enclave. |
| Network Visibility | Medium | VPC flow logs and AWS CloudTrail can capture KMS API call metadata, but enclave-initiated TLS encrypts payload contents. VPC endpoints can restrict network paths. CloudTrail logs KMS API events including caller identity and key ID. |
| Detection Difficulty | Hard | Many attacks exploit legitimate KMS API operations with valid IAM credentials, making them indistinguishable from normal traffic without deep protocol-level inspection inside the enclave. Replay and data swap attacks occur at the cryptographic layer, below typical monitoring visibility. |
Required Log Sources
- AWS CloudTrail (KMS API calls)
- AWS CloudWatch alarms for KMS key deletion events
- VPC Flow Logs
- AWS Config for KMS key policy changes
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for KMS Decrypt or GenerateDataKey API calls that do not include a Recipient attestation parameter, which may indicate requests originating outside of an intended enclave workflow. | AWS CloudTrail KMS API event logs | Defense Evasion / Credential Access | Medium — legitimate non-enclave applications may also call these KMS operations without attestation parameters. |
| Consider hunting for KMS API calls where the keyId in the request differs from the keyId in the response, which may indicate CMK substitution attempts. | AWS CloudTrail KMS API event logs (requestParameters and responseElements fields) | Credential Access | Low — key ID mismatches between request and response are unusual in normal operations. |
| Consider hunting for repeated KMS API calls using the same attestation document within a short time window, which may indicate replay attacks. | AWS CloudTrail KMS API event logs with attestation document correlation | Credential Access | Medium — legitimate enclave applications may make multiple KMS calls in rapid succession. |
| Consider hunting for KMS key policy changes, especially kms:PutKeyPolicy operations, which may indicate an attempt to weaken key protections. | AWS CloudTrail KMS management events, AWS Config configuration changes | Persistence / Defense Evasion | Low — key policy changes should be rare and well-documented in change management. |
| Consider hunting for KMS API calls from IAM roles or accounts that differ from the expected attested role, which may indicate credential manipulation or unauthorized access. | AWS CloudTrail KMS API events with sts:GetCallerIdentity correlation | Initial Access / Credential Access | Low — if the expected IAM role is well-defined, deviations are suspicious. |
Control Gaps
- Network-based IDS/IPS cannot inspect enclave-KMS traffic when enclave-initiated TLS is used
- EDR has no visibility into Nitro Enclave internal operations or network calls
- CloudTrail does not log attestation document contents or encryption context values in full
- No public append-only transparency log exists for KMS key policy changes, making insider tampering difficult to detect externally
- KMS TLS termination occurs outside the HSM, creating a gap where AWS insiders could intercept traffic
Key Behavioral Indicators
- KMS API calls (Decrypt, GenerateDataKey) without Recipient attestation parameter from roles expected to use enclaves
- Key ID mismatch between request parameters and response elements in KMS API calls
- Rapid repeated KMS API calls from the same enclave session within the 5-minute attestation validity window
- KMS key policy modifications (kms:PutKeyPolicy) outside of scheduled maintenance windows
- KMS API calls referencing key aliases instead of full ARNs from enclave-associated IAM roles
- KMS scheduled key deletion events without corresponding change management records
False Positive Assessment
Low — This article describes architectural attack patterns rather than specific indicators. The detection hypotheses focus on anomalous KMS API usage patterns that should produce few false positives in well-understood environments, though environments with diverse non-enclave KMS usage may see higher noise on some queries.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. If using aws-nitro-enclaves-sdk-c, consider migrating to aws-nitro-enclaves-nsm-api (Rust) for attestation and Boto3 KMS.Client (Python) for KMS communication, as the C SDK contains exploitable vulnerabilities.
- Consider reviewing all KMS key policies associated with Nitro Enclaves for the insecure pattern where root principal is granted kms:* with full access, and replace with specific IAM role principals.
- If applicable to your environment, consider implementing CloudWatch alarms for KMS key deletion events and scheduled deletion periods that allow your team time to respond.
- Consider evaluating whether your enclave code hardcodes full CMK ARNs, validates keyId from KMS responses, and uses encryption context for all data key operations.
Infrastructure Hardening
- Consider implementing enclave-initiated TLS with a pinned, attested CA certificate (Amazon's KMS CA) to prevent active attacks if your threat model includes network-level adversaries.
- Evaluate whether VPC endpoints and VPC-based key policy conditions (aws:SourceVpc) can be added to restrict KMS access paths.
- Consider implementing Service Control Policies (SCPs) that prevent KMS key deletion across your organization's AWS accounts.
- If end-to-end verifiability is required, consider hardcoding the hash of the KMS key policy in the enclave and having the enclave validate the policy via kms:GetKeyPolicy before making attestation-protected requests.
- Consider making key policies effectively immutable by denying kms:PutKeyPolicy for all principals, using the --bypass-policy-lockout-safety-check flag during initial setup.
User Protection
- Consider implementing rate limits on user-triggered KMS operations to prevent billing abuse and denial of service.
- If your application exposes KMS operations to end-users, consider evaluating whether request quotas and data length limits are enforced.
- Consider reviewing whether multi-region KMS keys are needed for regional outage resilience, if your availability requirements demand it.
Security Awareness
- Consider incorporating the passive and active attack checklists from this article into your existing enclave security review processes.
- If your team builds enclave applications, consider requiring a cryptographic review of the enclave-KMS protocol design and implementation as part of your development lifecycle.
- Consider documenting your enclave's KMS communication protocol, including which KMS operations are used, how encryption context is determined, and how CMK ARNs are validated, to support future security audits.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping3 techniques
Tactic
Initial Access
Tactic
Persistence
Tactic
Credential Access
Additional IOCs
- Command Lines:
- Purpose: Inserting a deny-all policy on kms:PutKeyPolicy to make key policies immutable, requires bypass policy lockout safety check flag | Tools:
aws-cli| Stage: hardening |aws kms put-key-policy --bypass-policy-lockout-safety-check
- Purpose: Inserting a deny-all policy on kms:PutKeyPolicy to make key policies immutable, requires bypass policy lockout safety check flag | Tools:
Stay currentSubscribe via RSS
