Evaluating ITAR workloads in US commercial AWS Regions

This post distills how one Amazon Web Services (AWS) customer in the defense and aerospace industry interpreted the U.S. International Traffic in Arms Regulations (ITAR) and concluded that U.S. commercial AWS Regions could support their export-controlled workloads, including AI workloads, when configured appropriately.

This post is for informational purposes only. We encourage you to consult your legal and compliance teams before proceeding.

ITAR requirements

The ITAR, codified in Title 22 of the Code of Federal Regulations (CFR), states that it’s not a controlled export to send, store, or take technical data outside the U.S. This includes technical data that is:

• Unclassified
• Secured using “end-to-end encryption”
• Secured using cryptographic modules (hardware or software) compliant with the Federal Information Processing Standards (FIPS) Publication 140-2 or its successors, supplemented by software implementation, cryptographic key management, and other procedures and controls that are in accordance with guidance provided in current U.S. National Institute of Standards and Technology (NIST) publications, or by other cryptographic means that provide security strength that is at least comparable to the minimum 128 bits of security strength achieved by the Advanced Encryption Standard (AES-128).
• Not intentionally sent to a person or stored in a country listed under 22 CFR 126.1. If data is encrypted in transit, unintentional routing through the internet is not deemed to be stored in a country it transits.

Based on these ITAR requirements, the customer worked with their legal counsel to identify conditions they believed supported running their unclassified export-controlled workloads on AWS infrastructure.

For this customer, deployments were limited to U.S. commercial AWS Regions, with features that could store data outside the U.S. disabled. Commercial AWS Region operators aren’t necessarily U.S. persons, so operator access to ITAR data would still need to be controlled. To accomplish this, the customer specified that data must remain encrypted at rest and in transit. Decryption occurs only transiently for the duration of the processing operation. The customer evaluated AWS service metadata as part of this classification analysis.

How the customer evaluated AWS services

ITAR recognizes encryption as a control for protecting data. The following framework reflects one customer’s approach to evaluating AWS services for ITAR-controlled workloads. The customer evaluated four areas:

1. Cryptographic accreditation

The Federal Risk and Authorization Management Program (FedRAMP) Moderate authorization for U.S. commercial AWS Regions provides a useful baseline for cryptographic accreditation. Under FedRAMP 20x, AWS services at the Moderate impact level should use FIPS 140 validated cryptographic modules. Most services in U.S. commercial AWS Regions are in scope for FedRAMP Moderate authorization.

2. Data at rest

AWS Key Management Service (AWS KMS) customer managed keys (CMKs) are generated on FIPS 140-3 Security Level 3 validated hardware security modules (HSMs). All key materials for CMKs are generated within AWS KMS HSMs, and all cryptographic operations that require use of key material occur strictly within the FIPS 140-3 Security Level 3 boundary of these HSMs.

AWS KMS is designed so that no one, including AWS service operators, can retrieve plaintext key material from the HSMs. Quorum-based multiparty access controls are strictly enforced for management operations on these HSMs, such as changing the software configuration or introducing new HSMs into the service.

AWS KMS gives you total control over your keys. By using a CMK, you have control over the lifecycle of the key and the access policies that determine who can use your key under which conditions. AWS KMS authenticates and authorizes each API request that’s made to your key to verify the calling principal (user) has the necessary permissions to perform the requested action. These requests are logged under AWS CloudTrail for full auditability by you. AWS doesn’t access your keys without your authorization.

AWS KMS is integrated with AWS services to streamline using your keys. Support for client-side encryption uses open source libraries such as the AWS Encryption SDK.

3. Data in transit

Layer 1 – Physical

AWS data centers in U.S. commercial AWS Regions carry a Controlled Access Area designation per 12 Foreign Affairs Manual Exhibit 451.1.III.E, meeting the NIST Special Publication 800-53 Revision 5 SC-8(5) Protected Distribution System control for intra-data center traffic. Before leaving AWS secured facilities, data flowing across AWS Regions and between Availability Zones is automatically encrypted at the physical layer using AES-256. All inter-Region traffic using Amazon Virtual Private Cloud (Amazon VPC) peering, AWS Transit Gateway peering, or AWS Cloud WAN receives an additional layer of transparent encryption before leaving AWS data centers.

Layer 2 – Network

Nearly all generally available AWS services support connection through Amazon VPC using AWS PrivateLink, a private networking backbone partially built on the AWS Nitro System. When transmitting data between AWS Nitro instances, AWS automatically encrypts in-transit traffic using AES-256 in Galois Counter Mode (GCM). Customers can use Amazon VPC Encryption Controls to examine which parts of their network traffic flow over AWS Nitro hardware.

AWS PrivateLink provides network isolation, not encryption. Encryption at this layer might come from AWS Nitro hardware or from the application-level TLS described in the following section.

Layer 3 – Application

AWS services must enforce TLS at the application level. AWS currently supports TLS 1.2 and TLS 1.3 cipher suites, with restricted cipher suites for FIPS 140-3 endpoints.

For standard endpoints in U.S. commercial AWS Regions, AWS policy is to only implement TLS cipher suites that use AES-256, AES-128, or equivalent ciphers.

This customer preferred FIPS 140 endpoints in all situations where available. These endpoints use cryptography from AWS LibCrypto (AWS-LC) FIPS Module, thus further restricting ciphers to only AES-256 and AES-128. More information on AWS-LC FIPS can be found in this AWS Security post.

4. Data in use

At the time of writing, most services transiently decrypt data in volatile memory to operate on it, including for AI inference, query execution, or request processing. The customer accepted this constraint in light of the following mitigating factors.

Many AWS services use envelope encryption at rest, where a data key encrypts the data and a CMK wraps (encrypts) the data key. The CMKs are inaccessible to AWS operators, and the use of data keys is audited and protected from operator access during processing.

Some of the AWS core systems and services are designed with zero operator access, including Amazon Elastic Compute Cloud (Amazon EC2) through the AWS Nitro System, AWS Lambda, and Amazon Elastic Kubernetes Service (Amazon EKS). These services don’t have any technical means for AWS operators to access customer data. Instead, systems and services are administered using automation and secure APIs that protect customer data from inadvertent or even coerced disclosure.

Conclusion

We encourage you to consult your legal and compliance teams to evaluate how U.S. commercial AWS Regions could be used in light of your compliance requirements. For more information, see AWS Compliance Programs.