# Security in AWS Payment Cryptography
Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations.
Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security of the cloud and security in the cloud:
+ **Security of the cloud**—AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to AWS Payment Cryptography, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud**—Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.
This topic helps you understand how to apply the shared responsibility model when using AWS Payment Cryptography. It shows you how to configure AWS Payment Cryptography to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your AWS Payment Cryptography resources.
**Topics**
+ [Data protection](data-protection.md)
+ [Resilience](resilience.md)
+ [Infrastructure security](infrastructure-security.md)
+ [Use Amazon VPC and AWS PrivateLink](vpc-endpoint.md)
+ [Hybrid post-quantum TLS](pqtls.md)
+ [Security best practices](security-best-practices.md)
# Data protection in AWS Payment Cryptography
The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in AWS Payment Cryptography. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*.
For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3.
+ Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
+ Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.
+ If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with AWS Payment Cryptography or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.
AWS Payment Cryptography stores and protects your payment encryption keys to make them highly available while providing you with strong and flexible access control.
**Topics**
+ [Protecting key material](#key-protection)
+ [Data encryption](#data-encryption)
+ [Encryption at rest](#encryption-rest)
+ [Encryption in transit](#encryption-transit)
+ [Internetwork traffic privacy](#internetwork)
## Protecting key material
By default, AWS Payment Cryptography protects the cryptographic key material for payment keys managed by the service. In addition, AWS Payment Cryptography offers options for importing key material that is created outside of the service. For technical details about payment keys and key material, see AWS Payment Cryptography Cryptographic Details.
## Data encryption
The data in AWS Payment Cryptography consists of AWS Payment Cryptography keys, the encryption key material they represent, and their usage attributes. Key material exists in plaintext only within AWS Payment Cryptography hardware security modules (HSMs) and only when in use. Otherwise, the key material and attributes are encrypted and stored in durable persistent storage.
The key material that AWS Payment Cryptography generates or loads for payment keys never leaves the boundary of AWS Payment Cryptography HSMs unencrypted. It can be exported encrypted by AWS Payment Cryptography API operations.
## Encryption at rest
AWS Payment Cryptography generates key material for payment keys in PCI PTS HSM-listed HSMs. When not in use, key material is encrypted by an HSM key and written to durable, persistent storage. The key material for Payment Cryptography keys and the encryption keys that protect the key material never leave the HSMs in plaintext form.
Encryption and management of key material for Payment Cryptography keys is handled entirely by the service.
For more details, see AWS Key Management Service Cryptographic Details.
## Encryption in transit
Key material that AWS Payment Cryptography generates or loads for payment keys is never exported or transmitted in AWS Payment Cryptography API operations in cleartext. AWS Payment Cryptography uses key identifiers to represent the keys in API operations.
However, some API operations export keys encrypted by a previously shared or asymmetric key exchange key. Also, customers can use API operations to import encrypted key material for payment keys.
All AWS Payment Cryptography API calls must be signed and be transmitted using Transport Layer Security (TLS). AWS Payment Cryptography requires TLS versions and cipher suites defined by PCI as "strong cryptography". All service endpoints support TLS 1.2—1.3 and hybrid post-quantum TLS.
For more details, see AWS Key Management Service Cryptographic Details.
## Internetwork traffic privacy
AWS Payment Cryptography supports an AWS Management Console and a set of API operations that enable you to create and manage payment keys and use them in cryptographic operations.
AWS Payment Cryptography supports two network connectivity options from your private network to AWS.
+ An IPSec VPN connection over the internet.
+ AWS Direct Connect, which links your internal network to an AWS Direct Connect location over a standard Ethernet fiber-optic cable.
All Payment Cryptography API calls must be signed and be transmitted using Transport Layer Security (TLS). The calls also require a modern cipher suite that supports perfect forward secrecy. Traffic to the hardware security modules (HSMs) that store key material for payment keys is permitted only from known AWS Payment Cryptography API hosts over the AWS internal network.
To connect directly to AWS Payment Cryptography from your virtual private cloud (VPC) without sending traffic over the public internet, use VPC endpoints, powered by AWS PrivateLink. For more information, see Connecting to AWS Payment Cryptography through a VPC endpoint.
AWS Payment Cryptography also supports a hybrid post-quantum key exchange option for the Transport Layer Security (TLS) network encryption protocol. You can use this option with TLS when you connect to AWS Payment Cryptography API endpoints.
# Resilience in AWS Payment Cryptography
AWS global infrastructure is built around AWS Regions and Availability Zones. Regions provide multiple physically separated and isolated Availability Zones, which are connected through low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures.
For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).
## Regional isolation
AWS Payment Cryptography is a Regional service that is available in multiple regions.
The Regionally isolated design of AWS Payment Cryptography ensures that an availability issue in one AWS Region cannot affect AWS Payment Cryptography operation in any other Region. AWS Payment Cryptography is designed to ensure zero planned downtime, with all software updates and scaling operations performed seamlessly and imperceptibly.
The AWS Payment Cryptography Service Level Agreement (SLA) includes a service commitment of 99.99% for all Payment Cryptography APIs. To fulfill this commitment, AWS Payment Cryptography ensures that all data and authorization information required to execute an API request is available on all regional hosts that receive the request.
The AWS Payment Cryptography infrastructure is replicated in at least three Availability Zones (AZs) in each Region. To ensure that multiple host failures do not affect AWS Payment Cryptography performance, AWS Payment Cryptography is designed to service customer traffic from any of the AZs in a Region.
Changes that you make to the properties or permissions of a payment key are replicated to all hosts in the Region to ensure that subsequent request can be processed correctly by any host in the Region. Requests for cryptographic operations using your payment key are forwarded to a fleet of AWS Payment Cryptography hardware security modules (HSMs), any of which can perform the operation with the payment key.
## Multi-tenant design
The multi-tenant design of AWS Payment Cryptography enables it to fulfill the availability SLA, and to sustain high request rates, while protecting the confidentiality of your keys and data.
Multiple integrity-enforcing mechanisms are deployed to ensure that the payment key that you specified for the cryptographic operation is always the one that is used.
The plaintext key material for your Payment Cryptography keys is protected extensively. The key material is encrypted in the HSM as soon as it is created, and the encrypted key material is immediately moved to secure storage. The encrypted key is retrieved and decrypted within the HSM just in time for use. The plaintext key remains in HSM memory only for the time needed to complete the cryptographic operation. Plaintext key material never leaves the HSMs; it is never written to persistent storage.
For more information about the mechanisms that AWS Payment Cryptography uses to secure your keys, see AWS Payment Cryptography Cryptographic Details.
# Infrastructure security in AWS Payment Cryptography
As a managed service, AWS Payment Cryptography is protected by the AWS global network security procedures that are described in the [Amazon Web Services: Overview of Security Processes](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) whitepaper.
You use AWS published API calls to access AWS Payment Cryptography through the network. Clients must support Transport Layer Security (TLS) 1.2 or later. Clients must also support cipher suites with perfect forward secrecy (PFS) such as Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). Most modern systems such as Java 7 and later support these modes.
Additionally, requests must be signed using an access key ID and a secret access key that is associated with an IAM principal. Or you can use the [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) to generate temporary security credentials to sign requests.
## Isolation of physical hosts
The security of the physical infrastructure that AWS Payment Cryptography uses is subject to the controls described in the Physical and Environmental Security section of Amazon Web Services: Overview of Security Processes. You can find more detail in compliance reports and third-party audit findings listed in the previous section.
AWS Payment Cryptography is supported by dedicated commercial-off-the-shelf PCI PTS HSM-listed hardware security modules (HSMs). The key material for AWS Payment Cryptography keys is stored only in volatile memory on the HSMs, and only while the Payment Cryptography key is in use. HSMs are in access controlled racks within Amazon data centers that enforce dual control for any physical access. For detailed information about the operation of AWS Payment Cryptography HSMs, see AWS Payment Cryptography Cryptographic Details.
# Connecting to AWS Payment Cryptography through a VPC endpoint
You can connect directly to AWS Payment Cryptography through a private interface endpoint in your virtual private cloud (VPC). When you use an interface VPC endpoint, communication between your VPC and AWS Payment Cryptography is conducted entirely within the AWS network.
AWS Payment Cryptography supports Amazon Virtual Private Cloud (Amazon VPC) endpoints powered by [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/). Each VPC endpoint is represented by one or more [Elastic Network Interfaces](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) (ENIs) with private IP addresses in your VPC subnets.
The interface VPC endpoint connects your VPC directly to AWS Payment Cryptography without an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. The instances in your VPC do not need public IP addresses to communicate with AWS Payment Cryptography.
**Regions**
AWS Payment Cryptography supports VPC endpoints and VPC endpoint policies in all AWS Regions in which [AWS Payment Cryptography](https://docs.aws.amazon.com/general/latest/gr/payment-cryptography.html) is supported.
**Topics**
+ [Considerations for AWS Payment Cryptography VPC endpoints](#vpce-considerations)
+ [Creating a VPC endpoint for AWS Payment Cryptography](#vpce-create-endpoint)
+ [Connecting to an AWS Payment Cryptography VPC endpoint](#vpce-connect)
+ [Controlling access to a VPC endpoint](#vpce-policy)
+ [Using a VPC endpoint in a policy statement](#vpce-policy-condition)
+ [Logging your VPC endpoint](#vpce-logging)
## Considerations for AWS Payment Cryptography VPC endpoints
**Note**
Although VPC endpoints allows you to connect to the service in as few as one availability zone(AZ), we recommend connecting to three availability zones for high availability and redundancy purposes.
Before you set up an interface VPC endpoint for AWS Payment Cryptography, review the [Interface endpoint properties and limitations](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-interface-limitations) topic in the *AWS PrivateLink Guide*.
AWS Payment Cryptography support for a VPC endpoint includes the following.
+ You can use your VPC endpoint to call all [AWS Payment Cryptography Control plane operations](https://docs.aws.amazon.com/payment-cryptography/latest/APIReference/API_Operations.html) and [AWS Payment Cryptography Data plane operations](https://docs.aws.amazon.com/payment-cryptography/latest/DataAPIReference/API_Operations.html) from a VPC.
+ You can create an interface VPC endpoint that connects to an AWS Payment Cryptography region endpoint.
+ AWS Payment Cryptography consists of a control plane and a data plane. You can chose to setup one or both sub-services AWS PrivateLink but each is configured separately.
+ You can use AWS CloudTrail logs to audit your use of AWS Payment Cryptography keys through the VPC endpoint. For details, see [Logging your VPC endpoint](#vpce-logging).
## Creating a VPC endpoint for AWS Payment Cryptography
You can create a VPC endpoint for AWS Payment Cryptography by using the Amazon VPC console or the Amazon VPC API. For more information, see [Create an interface endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint) in the *AWS PrivateLink Guide*.
+ To create a VPC endpoint for AWS Payment Cryptography, use the following service names:
```
com.amazonaws.region.payment-cryptography.controlplane
```
```
com.amazonaws.region.payment-cryptography.dataplane
```
For example, in the US West (Oregon) Region (`us-west-2`), the service names would be:
```
com.amazonaws.us-west-2.payment-cryptography.controlplane
```
```
com.amazonaws.us-west-2.payment-cryptography.dataplane
```
To make it easier to use the VPC endpoint, you can enable a [private DNS name](https://docs.aws.amazon.com/vpc/latest/privatelink/verify-domains.html) for your VPC endpoint. If you select the **Enable DNS Name** option, the standard AWS Payment Cryptography DNS hostname resolves to your VPC endpoint. For example, `https://controlplane.payment-cryptography.us-west-2.amazonaws.com` would resolve to a VPC endpoint connected to service name `com.amazonaws.us-west-2.payment-cryptography.controlplane`.
This option makes it easier to use the VPC endpoint. The AWS SDKs and AWS CLI use the standard AWS Payment Cryptography DNS hostname by default, so you do not need to specify the VPC endpoint URL in applications and commands.
For more information, see [Accessing a service through an interface endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#access-service-though-endpoint) in the *AWS PrivateLink Guide*.
## Connecting to an AWS Payment Cryptography VPC endpoint
You can connect to AWS Payment Cryptography through the VPC endpoint by using an AWS SDK, the AWS CLI or AWS Tools for PowerShell. To specify the VPC endpoint, use its DNS name.
For example, this [list-keys](https://docs.aws.amazon.com/payment-cryptography/latest/APIReference/list-keys.html) command uses the `endpoint-url` parameter to specify the VPC endpoint. To use a command like this, replace the example VPC endpoint ID with one in your account.
```
$ aws payment-cryptography list-keys --endpoint-url https://vpce-1234abcdf5678c90a-09p7654s-us-east-1a.ec2.us-east-1.vpce.amazonaws.com
```
If you enabled private hostnames when you created your VPC endpoint, you do not need to specify the VPC endpoint URL in your CLI commands or application configuration. The standard AWS Payment Cryptography DNS hostname resolves to your VPC endpoint. The AWS CLI and SDKs use this hostname by default, so you can begin using the VPC endpoint to connect to an AWS Payment Cryptography regional endpoint without changing anything in your scripts and applications.
To use private hostnames, the `enableDnsHostnames` and `enableDnsSupport` attributes of your VPC must be set to `true`. To set these attributes, use the [ModifyVpcAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVpcAttribute.html) operation. For details, see [View and update DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) in the *Amazon VPC User Guide*.
## Controlling access to a VPC endpoint
To control access to your VPC endpoint for AWS Payment Cryptography, attach a *VPC endpoint policy* to your VPC endpoint. The endpoint policy determines whether principals can use the VPC endpoint to call AWS Payment Cryptography operations with specific AWS Payment Cryptography resources.
You can create a VPC endpoint policy when you create your endpoint, and you can change the VPC endpoint policy at any time. Use the VPC management console, or the [CreateVpcEndpoint](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateVpcEndpoint.html) or [ModifyVpcEndpoint](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVpcEndpoint.html) operations. You can also create and change a VPC endpoint policy by [using an AWS CloudFormation template](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-vpcendpoint.html). For help using the VPC management console, see [Create an interface endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint) and [Modifying an interface endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#modify-interface-endpoint) in the *AWS PrivateLink Guide*.
For help writing and formatting a JSON policy document, see the [IAM JSON Policy Reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) in the *IAM User Guide*.
**Topics**
+ [About VPC endpoint policies](#vpce-policy-about)
+ [Default VPC endpoint policy](#vpce-default-policy)
+ [Creating a VPC endpoint policy](#vpce-policy-create)
+ [Viewing a VPC endpoint policy](#vpce-policy-get)
### About VPC endpoint policies
For an AWS Payment Cryptography request that uses a VPC endpoint to be successful, the principal requires permissions from two sources:
+ An [identity-based policy](security_iam_id-based-policy-examples.md) must give the principal permission to call the operation on the resource (AWS Payment Cryptography keys or alias).
+ A VPC endpoint policy must give the principal permission to use the endpoint to make the request.
For example, a key policy might give a principal permission to call [Decrypt](https://docs.aws.amazon.com/payment-cryptography/latest/DataAPIReference/API_DecryptData.html) on a particular AWS Payment Cryptography keys. However, the VPC endpoint policy might not allow that principal to call `Decrypt` on that AWS Payment Cryptography keys by using the endpoint.
Or a VPC endpoint policy might allow a principal to use the endpoint to call [StopKeyUsage](https://docs.aws.amazon.com/payment-cryptography/latest/APIReference/API_StopKeyUsage.html) on certain AWS Payment Cryptography keys. But if the principal doesn't have those permissions from a IAM policy, the request fails.
### Default VPC endpoint policy
Every VPC endpoint has a VPC endpoint policy, but you are not required to specify the policy. If you don't specify a policy, the default endpoint policy allows all operations by all principals on all resources over the endpoint.
However, for AWS Payment Cryptography resources, the principal must also have permission to call the operation from an [IAM policy](security_iam_id-based-policy-examples.md). Therefore, in practice, the default policy says that if a principal has permission to call an operation on a resource, they can also call it by using the endpoint.
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Principal": "*",
"Resource": "*"
}
]
}
```
To allow principals to use the VPC endpoint for only a subset of their permitted operations, [create or update the VPC endpoint policy](#vpce-policy-create).
### Creating a VPC endpoint policy
A VPC endpoint policy determines whether a principal has permission to use the VPC endpoint to perform operations on a resource. For AWS Payment Cryptography resources, the principal must also have permission to perform the operations from an [IAM policy](security_iam_id-based-policy-examples.md).
Each VPC endpoint policy statement requires the following elements:
+ The principal that can perform actions
+ The actions that can be performed
+ The resources on which actions can be performed
The policy statement doesn't specify the VPC endpoint. Instead, it applies to any VPC endpoint to which the policy is attached. For more information, see [Controlling access to services with VPC endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) in the *Amazon VPC User Guide*.
The following is an example of a VPC endpoint policy for AWS Payment Cryptography. When attached to a VPC endpoint, this policy allows `ExampleUser` to use the VPC endpoint to call the specified operations on the specified AWS Payment Cryptography keys. Before using a policy like this one, replace the example principal and [key identifier](concepts.md#concepts.key-identifer) with valid values from your account.
```
{
"Statement":[
{
"Sid": "AllowDecryptAndView",
"Principal": {"AWS": "arn:aws:iam::111122223333:user/ExampleUser"},
"Effect":"Allow",
"Action": [
"payment-cryptography:Decrypt",
"payment-cryptography:GetKey",
"payment-cryptography:ListAliases",
"payment-cryptography:ListKeys",
"payment-cryptography:GetAlias"
],
"Resource": "arn:aws:payment-cryptography:us-east-2:111122223333:key/kwapwa6qaifllw2h"
}
]
}
```
AWS CloudTrail logs all operations that use the VPC endpoint. However, your CloudTrail logs don’t include operations requested by principals in other accounts or operations for AWS Payment Cryptography keys in other accounts.
As such, you might want to create a VPC endpoint policy that prevents principals in external accounts from using the VPC endpoint to call any AWS Payment Cryptography operations on any keys in the local account.
The following example uses the [aws:PrincipalAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalaccount) global condition key to deny access to all principals for all operations on all AWS Payment Cryptography keys unless the principal is in the local account. Before using a policy like this one, replace the example account ID with a valid one.
```
{
"Statement": [
{
"Sid": "AccessForASpecificAccount",
"Principal": {"AWS": "*"},
"Action": "payment-cryptography:*",
"Effect": "Deny",
"Resource": "arn:aws:payment-cryptography:*:111122223333:key/*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalAccount": "111122223333"
}
}
}
]
}
```
### Viewing a VPC endpoint policy
To view the VPC endpoint policy for an endpoint, use the [VPC management console](https://console.aws.amazon.com/vpc/) or the [DescribeVpcEndpoints](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcEndpoints.html) operation.
The following AWS CLI command gets the policy for the endpoint with the specified VPC endpoint ID.
Before using this command, replace the example endpoint ID with a valid one from your account.
```
$ aws ec2 describe-vpc-endpoints \
--query 'VpcEndpoints[?VpcEndpointId==`vpce-1234abcdf5678c90a`].[PolicyDocument]'
--output text
```
## Using a VPC endpoint in a policy statement
You can control access to AWS Payment Cryptography resources and operations when the request comes from VPC or uses a VPC endpoint. To do so, use one an [IAM policy](security_iam_id-based-policy-examples.md)
+ Use the `aws:sourceVpce` condition key to grant or restrict access based on the VPC endpoint.
+ Use the `aws:sourceVpc` condition key to grant or restrict access based on the VPC that hosts the private endpoint.
**Note**
The `aws:sourceIP` condition key is not effective when the request comes from an [Amazon VPC endpoint](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html). To restrict requests to a VPC endpoint, use the `aws:sourceVpce` or `aws:sourceVpc` condition keys. For more information, see [Identity and access management for VPC endpoints and VPC endpoint services](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-iam.html) in the *AWS PrivateLink Guide*.
You can use these global condition keys to control access to AWS Payment Cryptography keys, aliases, and to operations like [CreateKey](https://docs.aws.amazon.com/payment-cryptography/latest/APIReference/API_CreateKey.html) that don't depend on any particular resource.
For example, the following sample key policy allows a user to perform particular cryptographic operations with a AWS Payment Cryptography keys only when the request uses the specified VPC endpoint, blocking access both from the Internet and AWS PrivateLink connections (if setup). When a user makes a request to AWS Payment Cryptography, the VPC endpoint ID in the request is compared to the `aws:sourceVpce` condition key value in the policy. If they do not match, the request is denied.
To use a policy like this one, replace the placeholder AWS account ID and VPC endpoint IDs with valid values for your account.
------
#### [ JSON ]
****
```
{
"Id": "example-key-1",
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EnableIAMPolicies",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:root"
]
},
"Action": [
"payment-cryptography:*"
],
"Resource": "*"
},
{
"Sid": "RestrictUsageToMyVPCEndpoint",
"Effect": "Deny",
"Principal": "*",
"Action": [
"payment-cryptography:EncryptData",
"payment-cryptography:DecryptData"
],
"Resource": "arn:aws:payment-cryptography:us-east-1:111122223333:key/*",
"Condition": {
"StringNotEquals": {
"aws:sourceVpce": "vpce-1234abcdf5678c90a"
}
}
}
]
}
```
------
You can also use the `aws:sourceVpc` condition key to restrict access to your AWS Payment Cryptography keys based on the VPC in which VPC endpoint resides.
The following sample key policy allows commands that manage the AWS Payment Cryptography keys only when they come from `vpc-12345678`. In addition, it allows commands that use the AWS Payment Cryptography keys for cryptographic operations only when they come from `vpc-2b2b2b2b`. You might use a policy like this one if an application is running in one VPC, but you use a second, isolated VPC for management functions.
To use a policy like this one, replace the placeholder AWS account ID and VPC endpoint IDs with valid values for your account.
------
#### [ JSON ]
****
```
{
"Id": "example-key-2",
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAdminActionsFromVPC12345678",
"Effect": "Allow",
"Principal": {
"AWS": "111122223333"
},
"Action": [
"payment-cryptography:Create*",
"payment-cryptography:Encrypt*",
"payment-cryptography:ImportKey*",
"payment-cryptography:GetParametersForImport*",
"payment-cryptography:TagResource",
"payment-cryptography:UntagResource"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:sourceVpc": "vpc-12345678"
}
}
},
{
"Sid": "AllowKeyUsageFromVPC2b2b2b2b",
"Effect": "Allow",
"Principal": {
"AWS": "111122223333"
},
"Action": [
"payment-cryptography:Encrypt*",
"payment-cryptography:Decrypt*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:sourceVpc": "vpc-2b2b2b2b"
}
}
},
{
"Sid": "AllowListReadActionsFromEverywhere",
"Effect": "Allow",
"Principal": {
"AWS": "111122223333"
},
"Action": [
"payment-cryptography:List*",
"payment-cryptography:Get*"
],
"Resource": "*"
}
]
}
```
------
## Logging your VPC endpoint
AWS CloudTrail logs all operations that use the VPC endpoint. When a request to AWS Payment Cryptography uses a VPC endpoint, the VPC endpoint ID appears in the [AWS CloudTrail log](monitoring-cloudtrail.md) entry that records the request. You can use the endpoint ID to audit the use of your AWS Payment Cryptography VPC endpoint.
To protect your VPC, requests that are denied by a [VPC endpoint policy](#vpce-policy), but otherwise would have been allowed, are not recorded in [AWS CloudTrail](monitoring-cloudtrail.md).
For example, this sample log entry records a [GenerateMac](https://docs.aws.amazon.com/payment-cryptography/latest/DataAPIReference/API_GenerateMac.html) request that used the VPC endpoint. The `vpcEndpointId` field appears at the end of the log entry.
```
{
"eventVersion": "1.08",
"userIdentity": {
"principalId": "TESTXECZ5U9M4LGF2N6Y5:i-98761b8890c09a34a",
"arn": "arn:aws:sts::111122223333:assumed-role/samplerole/i-98761b8890c09a34a",
"accountId": "111122223333",
"accessKeyId": "TESTXECZ5U2ZULLHHMJG",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "TESTXECZ5U9M4LGF2N6Y5",
"arn": "arn:aws:iam::111122223333:role/samplerole",
"accountId": "111122223333",
"userName": "samplerole"
},
"webIdFederationData": {},
"attributes": {
"creationDate": "2024-05-27T19:34:10Z",
"mfaAuthenticated": "false"
},
"ec2RoleDelivery": "2.0"
}
},
"eventTime": "2024-05-27T19:49:54Z",
"eventSource": "payment-cryptography.amazonaws.com",
"eventName": "CreateKey",
"awsRegion": "us-east-1",
"sourceIPAddress": "172.31.85.253",
"userAgent": "aws-cli/2.14.5 Python/3.9.16 Linux/6.1.79-99.167.amzn2023.x86_64 source/x86_64.amzn.2023 prompt/off command/payment-cryptography.create-key",
"requestParameters": {
"keyAttributes": {
"keyUsage": "TR31_M1_ISO_9797_1_MAC_KEY",
"keyClass": "SYMMETRIC_KEY",
"keyAlgorithm": "TDES_2KEY",
"keyModesOfUse": {
"encrypt": false,
"decrypt": false,
"wrap": false,
"unwrap": false,
"generate": true,
"sign": false,
"verify": true,
"deriveKey": false,
"noRestrictions": false
}
},
"exportable": true
},
"responseElements": {
"key": {
"keyArn": "arn:aws:payment-cryptography:us-east-2:111122223333:key/kwapwa6qaifllw2h",
"keyAttributes": {
"keyUsage": "TR31_M1_ISO_9797_1_MAC_KEY",
"keyClass": "SYMMETRIC_KEY",
"keyAlgorithm": "TDES_2KEY",
"keyModesOfUse": {
"encrypt": false,
"decrypt": false,
"wrap": false,
"unwrap": false,
"generate": true,
"sign": false,
"verify": true,
"deriveKey": false,
"noRestrictions": false
}
},
"keyCheckValue": "A486ED",
"keyCheckValueAlgorithm": "ANSI_X9_24",
"enabled": true,
"exportable": true,
"keyState": "CREATE_COMPLETE",
"keyOrigin": "AWS_PAYMENT_CRYPTOGRAPHY",
"createTimestamp": "May 27, 2024, 7:49:54 PM",
"usageStartTimestamp": "May 27, 2024, 7:49:54 PM"
}
},
"requestID": "f3020b3c-4e86-47f5-808f-14c7a4a99161",
"eventID": "b87c3d30-f3ab-4131-87e8-bc54cfef9d29",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111122223333",
"vpcEndpointId": "vpce-1234abcdf5678c90a",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "vpce-1234abcdf5678c90a-oo28vrvr.controlplane.payment-cryptography.us-east-1.vpce.amazonaws.com"
}
}
```
# Using hybrid post-quantum TLS
AWS Payment Cryptography and many other services supports a hybrid post-quantum key exchange option for the Transport Layer Security (TLS) network encryption protocol. You can use this TLS option when you connect to API endpoints or when using the AWS SDKs. These optional hybrid post-quantum key exchange features are at least as secure as the TLS encryption we use today and are likely to provide additional long-term security benefits.
The data that you send to enabled services is protected in transit by the encryption provided by a Transport Layer Security (TLS) connection. The classic cipher suites based on RSA and ECC that AWS Payment Cryptography supports for TLS sessions make brute force attacks on the key exchange mechanisms infeasible with current technology. However, if large scale or cryptographically relevant quantum computers (CRQC) becomes practical in the future, the existing TLS key exchange mechanisms will be susceptible to these attacks. It is possible that adversaries may begin harvesting encrypted data now with the hope that they can decrypt it in the future (harvest now, decrypt later). If you’re developing applications that rely on the long-term confidentiality of the data passed over a TLS connection, you should consider a plan to migrate to post-quantum cryptography before large-scale quantum computers become available for use. AWS is working to prepare for this future, and we want you to be well-prepared, too.
![\[An adversary who has previously recorded a TLS session. Years later, when the adversary has a CRQC, the adversary can first recover the session key by breaking the classical key exchange using the CRQC. The adversary can then decrypt the data using the discovered session key. The previously transmitted data, if still valuable, is now compromised.\]](http://docs.aws.amazon.com/payment-cryptography/latest/userguide/images/pqtls-risk2.png)
To protect data encrypted today against potential future attacks, AWS is participating with the cryptographic community in the development of quantum-resistant or *post-quantum* algorithms. AWS has implemented *hybrid* post-quantum key exchange cipher suites that combine classic and post-quantum elements to ensure that your TLS connection is at least as strong as it would be with classic cipher suites.
These hybrid cipher suites are available for use on your production workloads when using recent versions of the AWS SDKs. For more information about how to enable/disable this behavior, please see [Enabling hybrid post-quantum TLS](pqtls-details.md)
![\[A TLS session that is secured both using classical key agreement and post-quantum key agreement. An adversary today cannot break the classical part of the key agreement. If the adversary records the data and tries to decrypt it in the future with a CRQC, the post-quantum key agreement keeps the session key safe. Thus, today’s transmitted data remains safe against discovery even in the future. This is why hybrid post-quantum TLS is important today.\]](http://docs.aws.amazon.com/payment-cryptography/latest/userguide/images/pqtls-mitigation.png)
## About hybrid post-quantum key exchange in TLS
The algorithms that AWS uses are a *hybrid* that combines [Elliptic Curve Diffie-Hellman](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman) (ECDH), a classic key exchange algorithm used today in TLS, with [Module-Lattice-Based Key-Encapsulation Mechanism](https://csrc.nist.gov/pubs/fips/203/final) (ML-KEM), a public-key encryption and key-establishment algorithm that the National Institute for Standards and Technology (NIST) [ has designated as its first standard](https://csrc.nist.gov/pubs/fips/203/final) post-quantum key-agreement algorithm. This hybrid uses each of the algorithms independently to generate a key. Then it combines the two keys cryptographically.
## Learn more about PQC
For information about the post-quantum cryptography project at the National Institute for Standards and Technology (NIST), see [Post-Quantum Cryptography](https://csrc.nist.gov/Projects/Post-Quantum-Cryptography).
For information about NIST post-quantum cryptography standardization, see [Post-Quantum Cryptography Standardization](https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization).
# Enabling hybrid post-quantum TLS
AWS SDKs and tools have cryptographic capabilities and configuration that differ across language and runtime. There are three ways that an AWS SDK or tool currently provides PQ TLS support:
**Topics**
+ [SDKs with PQ TLS enabled by default](#pq-tls-default)
+ [Opt-in PQ TLS support](#pq-tls-opt-in)
+ [SDKs that rely on System OpenSSL](#pq-tls-open-ssl)
+ [AWS SDKs and tools not planning to support PQ TLS](#pq-tls-nosupport)
## SDKs with PQ TLS enabled by default
**Note**
As of 6-Nov-2025, AWS SDK and its underlying CRT libraries for MacOS and Windows uses system libraries for TLS, so PQ TLS capabilities on those platforms is generally determined by system-level support.
### AWS SDK for Go
The AWS SDK for Go uses Golang’s own TLS implementation provided by its standard library. Golang supports and prefers PQ TLS as of v1.24, so AWS SDK for Go users can enable PQ TLS by simply upgrading Golang to v1.24
### AWS SDK for JavaScript (browser)
The AWS SDK for JavaScript (browser) uses the browser’s TLS stack, so the SDK will negotiate PQ TLS if the browser runtime supports and prefers it. Firefox launched support for PQ TLS in v132.0. Chrome announced support for PQ TLS in v131. Edge supports opt-in PQ TLS in v120 for desktop and 140 for Android.
### AWS SDK for Node.js
As of Node.js v22.20 (LTS) and v24.9.0, Node.js statically links and bundles OpenSSL 3.5. This means that PQ TLS is enabled and preferred by default for those and subsequent versions.
### AWS SDK for Kotlin
The Kotlin SDK supports and prefers PQ TLS on Linux as of v1.5.78. Because AWS SDK for Kotlin’s CRT-based client relies on system libraries for TLS on MacOS and Windows, support for PQ TLS will depend on those underlying system libraries.
### AWS SDK for Rust
The AWS SDK for Rust distributes distinct packages (known as “crates” in the Rust ecosystem) for each service client. These are all managed in a consolidated GitHub repository, but each service client follows its own version and release cadence. The consolidated SDK released PQ TLS preference on 8/29/25, so any individual service client version released after that date will support and prefer PQ TLS by default.
You can determine the minimum version supporting PQ TLS for a particular service client by navigating to the relevant crates.io version URL (for example, AWS Payment Cryptography's is [here](https://crates.io/crates/aws-sdk-paymentcryptography/versions)) and finding the first version published after 29-Aug-25. Any service client version published after 29-Aug-25 will have PQ TLS enabled and preferred by default.
## Opt-in PQ TLS support
### AWS SDK for C\$1\$1
By default, the C\$1\$1 SDK uses platform-native clients like libcurl and WinHttp. Libcurl generally relies on system OpenSSL for TLS, so PQ TLS is only enabled by default if system OpenSSL is ≥ v3.5. You can override this default in C\$1\$1 SDK v1.11.673 or later, and opt-in to the AwsCrtHttpClient which supports and enables PQ TLS by default.
Notes on Building for Opt-In PQ TLS You can fetch the SDK’s CRT dependencies with [this script](https://github.com/aws/aws-sdk-cpp/blob/main/prefetch_crt_dependency.sh). Building the SDK from source is described [here](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/sdk-from-source.html) and [here](https://github.com/aws/aws-sdk-cpp/tree/main?tab=readme-ov-file#building-from-source), but note that you may need a few additional CMake flags:
```
-DUSE_CRT_HTTP_CLIENT=ON \
-DUSE_TLS_V1_2=OFF \
-DUSE_TLS_V1_3=ON \
-DUSE_OPENSSL=OFF \
```
### AWS SDK for Java
As of v2, AWS SDK for Java provides an AWS Common Runtime (AWS CRT) HTTP Client that can be configured to perform PQ TLS. As of v2.35.11, the AwsCrtHttpClient enables and prefers PQ TLS by default wherever it’s used.
## SDKs that rely on System OpenSSL
Several AWS SDKs and tools depend on the system's libcrypto/libssl library for TLS. The system library most often used is OpenSSL. OpenSSL enabled PQ TLS support in version 3.5, so the easiest way to configure these SDKs and tools for PQ TLS is to use it on an operating system distribution that has at least OpenSSL 3.5 installed.
You can also configure a Docker container to use OpenSSL 3.5 to enable PQ TLS on any system that supports Docker. See Post-quantum TLS in Python for an example of setting this up for Python.
### AWS CLI
PQ TLS support with the [AWS CLI installer](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) is coming soon. To enable immediately, you can use alternative installers for the AWS CLI, which varies by operating system, and can enable PQ TLS.
For MacOS, install the AWS CLI via [Homebrew](https://brew.sh/) and ensure that your Homebrew-vended OpenSSL is upgraded to version 3.5\$1. You can do this with “brew install openssl@3.6” and validate with “brew list \$1 grep openssl”.
For Ubuntu or Debian Linux: ensure the Linux distribution you are using has OpenSSL 3.5\$1 installed as system OpenSSL. Then, install the AWS CLI using apt or [PyPI](https://pypi.org/project/awscliv2/). With these prerequisites, the AWS CLI vended by apt or PyPI will be configured to negotiate PQ-TLS. For step-by-step instructions to validate the installation, see [github repository](https://github.com/aws-samples/sample-post-quantum-tls-python/) and accompanying [blog post](https://aws.amazon.com/blogs/security/post-quantum-tls-in-python/).
### AWS SDK for PHP
The AWS SDK for PHP relies on system libssl/libcrypto. To use PQ TLS, use this SDK on an operating system distribution that has at least OpenSSL 3.5 installed.
### AWS SDK for Python (Boto3)
The AWS SDK for Python (Boto3) relies on system libssl/libcrypto. To use PQ TLS, use this SDK on an operating system distribution that has at least OpenSSL 3.5 installed.
### AWS SDK for Ruby
The AWS SDK for Ruby relies on system libssl/libcrypto. To use PQ TLS, use this SDK on an operating system distribution that has at least OpenSSL 3.5 installed.
### AWS SDK for .NET
On Linux, AWS SDK for .NET relies on system libssl/libcrypto. To use PQ TLS, use this SDK on an operating system distribution that has at least OpenSSL 3.5 installed. On Windows and MacOS, PQ TLS is available starting in [.NET 10](https://devblogs.microsoft.com/dotnet/post-quantum-cryptography-in-dotnet/) and [Windows 11](https://techcommunity.microsoft.com/blog/microsoft-security-blog/post-quantum-cryptography-apis-now-generally-available-on-microsoft-platforms/4469093). On MacOS, TLS 1.3 support (a prerequisite for PQ TLS) can be enabled by opting-in to Apple's Network.framework as described [here](https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-10/libraries#tls-13-for-macos-client). Assuming a minimum .NET version of 10, PQ TLS should then be enabled.
## AWS SDKs and tools not planning to support PQ TLS
There are currently no plans to support the following language SDKs and tools:
+ AWS SDK for SAP
+ AWS SDK for Swift
+ AWS Tools for Windows PowerShell
# Security best practices for AWS Payment Cryptography
AWS Payment Cryptography supports many security features that are either built-in or that you can optionally implement to enhance the protection of your encryption keys and ensure that they are used for their intended purpose, including [IAM policies](security_iam_service-with-iam.md), an extensive set of policy condition keys to refine your key policies and IAM policies and built-in enforcement of PCI PIN rules regarding key blocks.
**Important**
The general guidelines provided do not represent a complete security solution. Because not all best practices are appropriate for all situations, these are not intended to be prescriptive.
+ **Key Usage and Modes of Use**: AWS Payment Cryptography follows and enforces key usage and mode of use restrictions as described in ANSI X9 TR 31-2018 Interoperable Secure Key Exchange Key Block Specification and consistent with PCI PIN Security Requirement 18-3. This limits the ability to use a single key for multiple purposes and cryptographically binds the key metadata (such as permitted operations) to the key material itself. AWS Payment Cryptography automatically enforces these restrictions such as that a key encryption key (TR31\$1K0\$1KEY\$1ENCRYPTION\$1KEY) cannot also be used for data decryption. See [Understanding key attributes for AWS Payment Cryptography key](keys-validattributes.md) for more details.
+ **Limit sharing of symmetric key material**: Only share symmetric key material (such as Pin Encryption Keys or Key Encryption Keys) with at most one other entity. If there is a need to transit sensitive material to more entities or partners, create additional keys. AWS Payment Cryptography never exposes symmetric key material or asymmetric private key material in the clear.
+ **Use aliases or tags to associate keys with certain use cases or partners**: Aliases can be used to easily denote the use case associated with a key such as alias/BIN\$112345\$1CVK to denote a card verification key associated with BIN 12345. To provide more flexibility, consider creating tags such as bin=12345, use\$1case=acquiring,country=us,partner=foo. Aliases and tags can also be used to limit access such as enforcing access controls between issuing and acquiring use cases.
+ **Practice least privileged access**: IAM can be used to limit production access to systems rather than individuals, such as prohibiting individual users from creating keys or running cryptographic operations. IAM can also be used to limit access to both commands and keys that may not be applicable for your use case, such as limiting the ability to generate or validate pins for an acquirer. Another way to use least privileged access is to restrict sensitive operations (such as key import) to specific service accounts. See [AWS Payment Cryptography identity-based policy examples](security_iam_id-based-policy-examples.md) for examples.
**See also**
+ [Identity and access management for AWS Payment Cryptography](security-iam.md)
+ [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*