Synchronize keys automatically from payment HSMs to AWS Payment Cryptography

Overview

The payments industry has seen significant growth and transformation in recent years, driven by the rapid adoption of digital and mobile payment technologies. According to McKinsey, “Payments revenues grew at 11 percent in 2022—a double-digit rate for the second consecutive year—reaching more than $2.2 trillion, an all-time high”. This growth brings challenges in ensuring payment security, meeting compliance and data sovereignty requirements, and scaling to meet the growing demand. Customers have been increasingly moving their critical payment workloads to the cloud to address these challenges. One of the questions that customers have asked is how to move their payment HSM based workloads to the cloud. This is where AWS Payment Cryptography (APC) comes in. It helps with the undifferentiated heavy lifting of providing payment HSMs as a managed service while meeting payment industry compliance, regulatory and scalability requirements.

How AWS Payment Cryptography helps

AWS Payment Cryptography helps payment companies in their cloud journey with goals of increasing operational efficiency and lowering costs.

1. Facilitates data center exits. Because companies need to manage HSMs either in their own data centers or third-party co-locations, they cannot fully migrate to the cloud. AWS Payment Cryptography is cloud native, favoring companies to run their entire workload on the cloud.
2. Lowering Total Cost of Ownership (TCO). As a highly sensitive and critical hardware, payment HSMs require complex setup and management. Data centers typically need to secure them, allowing only privileged access. As such, these HSMs normally need dedicated teams with specialized skills to manage them, which makes it costly. AWS Payment Cryptography is a fully managed service that handles the undifferentiated heavy lifting of maintaining HSMs, reducing management costs. Additionally, the service is elastic and automatically scales to meet customers payment processing demands without requiring manual intervention or capacity planning.
3. Provides API based operations instead of socket-based commands. HSMs commands can be complex and need special skills to operate because they lack standards across different brands of HSMs. AWS Payment Cryptography is fully API based backed by multiple language SDKs. This empowers customers to use payment cryptographic functions with languages they’re comfortable with, without the need to understand HSM commands and syntaxes.
4. Faster time to market. AWS Payment Cryptography eliminates the need to manage payment HSMs enabling companies to quickly deploy and scale their payment processing applications. It also supports PCI (Payment Card Industry) complaint electronic key exchange process using TR34, TR31, and ECDH (Elliptic Curve Diffie-Hellman) protocols making the bootstrapping process faster than exchanging keys via traditional paper based mechanism.
5. Compliant by default. AWS manages infrastructure compliance for PCI PIN, PCI P2PE, and PCI DSS, and also geographic compliance requirements. It operates in a shared responsibility model where customers handle the compliance of their applications.

Moving keys from Payment HSMs to AWS Payment Cryptography

One of the common questions we get from customers is how can they synchronize or migrate keys from their existing payment HSMs to AWS Payment Cryptography? In this blog post, we will discuss several PCI compliant approaches to synchronize keys electronically to AWS Payment Cryptography. We provide sample code to perform the synchronization from common HSMs such as Thales payShield 10K, Atalla AT1000 and Futurex GSP3000.

There are different electronic key exchange protocols supported by AWS Payment Cryptography. Below are general guidelines for deciding which protocol to use:

1. TR34 is an asymmetric key exchange protocol for exchanging symmetric keys using asymmetric cryptography based on certificate-based Remote Key Loading (RKL) protocol. It is a standard established by the Accredited Standards Committee X9 for the secure exchange of cryptographic keys, particularly in financial transactions.
   Its primary use is for exchanging Key Encryption Keys (KEK), although it also works for exchanging working keys. This method is suitable for TDES and AES-128 keys.
2. TR31 is a symmetric key exchange protocol established by the Accredited Standards Committee X9 for secure exchange of cryptographic keys used in financial transactions. Also, the American National Standards Institute (ANSI) defined the TR31 key block format to allow the safe exchange of cryptographic keys by including key attributes in the exchanged data. Its primary use is for exchanging symmetric working keys such as PEK (PIN Encryption Key), CVK (Card Verification Key), PVK (PIN Verification Key), etc. It is suitable for exporting any TDES or AES key subject to TR-31 valid combinations. Also, the wrapping key cipher must be at least as strong as the key to be exported.
3. Elliptic Curve Diffie-Hellman (ECDH) is a key derivation method that uses ECC asymmetric cryptography to establish a shared key between two parties without requiring pre-exchanged keys. It is used to exchange any type of symmetric key. It currently is the only approach in AWS Payment Cryptography to transfer up to AES-256 keys.

Working with TR34

The process involves transporting a key from Key Distribution Host (KDH), such as the HSMs, to a Key Receiving Device (KRD), such as the AWS Payment Cryptography service. The following are the high-level steps for TR34 key exchange:

1. KDH sets up SigningKeyPair and creates a certificate signing request (CSR) to sign the public key using a Certificate Authority (such as AWS Private Certificate Authority). Then shares the CA certificate with KRD. This is to verify the SigningPublicKeyCertificate in a later step.
2. KRD sets up WrappingKeyPair and shares the WrappingPublicKey with KDH.
3. KDH generates a TR34 key block for the transport key by encrypting the key using KRD WrappingPublicKey and signing it using KDH SigningPrivateKey.
4. KRD receives the TR34 Encrypted Key block and the SigningPublicKeyCertificate and will verify and extract the SigningPublicKey using the CA certificate shared in step (1). KRD verifies the signature on the encrypted key block using KDH SigningPublicKey and unwraps the key using KRD WrappingPrivateKey.

Figure 1 shows a TR34 key exchange flow.

Figure 1 TR34 key exchange flow

Figure 2 shows the TR34 key block format. Refer to ANSI X9 TR-34 Standard for further details.

Figure 2 TR34 key block format

Working with TR31

Below are the high-level steps for the TR31 key exchange:

1. KDH and KRD first share a key encryption key (KEK), typically using the TR34 protocol.
2. KDH generates a TR31 key block of a working key (such as PEK, CVK, PVK, etc.) wrapped by the exchanged KEK.
3. KRD uses the exchanged KEK to unwrap the key from the TR31 payload.

See in Figure 3 a TR31 key exchange flow:

Figure 3 TR31 key exchange flow

Figure 4 shows the TR31 key block format. Refer to ANSI X9 TR-31 Standard for further details.

Figure 4 TR-31 key block format

Working with ECDH

When importing, the sending system is commonly known as Party U (Initiator) and the receiving system is known as Party V (Responder). The sending system derives a symmetric KEK using ECDH, which is then used to wrap the actual working key (such as PEK, PVK, etc.) that needs to be transported. The receiving system also generates the same KEK using ECDH.

Below are high-level steps for ECDH key exchange:

1. On Party V (AWS Payment Cryptography which receives the key), generate an ECC Key pair. Party U gets the public key from party V and installs it.
2. Generate an ECC key pair on the source system (Party U) and provide the certificate chain that signs the Party U public key to Party V.
3. Party U will derive a Key Encryption Key using Party U’s private key, Party V’s public key and ECDH Key Derivation Function parameters. Key Derivation Function parameters include

• • Key Derivation Function (KDF): The KDF is a cryptographic algorithm that takes the shared secret and other parameters as input to generate the desired keying material. AWS Payment Cryptography supports 2 KDFs – KDF as defined in NIST SP 800-56A and KDF as defined in ANSI X9.63.
  • Derive Key Algorithm: The algorithm of the key (KEK) to be derived. Refer to the supported algorithms here.
  • Hash Algorithm: Hashing algorithm to be used in the KDF. AWS Payment Cryptography algorithms include SHA256, SHA384 and SHA512.
  • Shared Information: Additional information that you can include in the key derivation to add context or bind the derived key to a specific purpose.

4. Export the key in TR31 format using the KEK derived from the source system (Party U). This key to be transported can be TDES or AES, subject to TR-31 valid combinations, and the wrapping key cipher must be at least as strong as the key to be exported.
5. On Party V, the same KEK will be derived using Party V’s private key, Party U’s public key and the same ECDH key derivation function parameters to unwrap the incoming TR31 payload and obtain the transported key.

Figure 5 shows the ECDH key exchange flow:

Figure 5 ECDH key exchange flow

Steps to synchronize keys from Payment HSM to AWS Payment Cryptography

Now that we’ve covered the electronic key exchange mechanisms, let’s dive into the steps to exchange keys from Payment HSMs to AWS Payment Cryptography.

Prerequisites

1. Access to command shell or terminal to run the import commands.
2. Set up your AWS credentials with access to execute APIs on the AWS Payment Cryptography Service.
3. The migration scripts are in Python. As such, a Python environment is required to execute the scripts. Install the Python dependencies using the requirements.txt file under the appropriate HSM folder.
4. Ensure you have access to the HSM via DNS/IP and port number.

Note: We tested the scripts on Mac and Linux environments. They might require minor adjustments for Windows.

Thales payShield 10K

Thales payShield 10K is a payment HSM designed for payment applications, offering cryptographic processing and key management capabilities.

Configuration

1. Get the Thales payShield migration scripts from AWS Samples GitHub repository.
2. Ensure your HSM config file matches the sample config included with the scripts. We tested the scripts with this sample file.
3. Update input_config.json. Under ‘kdh/payshield’

a. Add the HSM host and port information.
b. The script can be configured to run either for a KeyBlock LMK(Local Master Key) or a Variant LMK. If using Variant LMK, set the field “variant_lmk” to true and set the slot number of the LMK for “variant_lmk_identifier”.
c. In the “krd” section, fill in the details for “apc” with the AWS region where you will import the key.

4. Execute the following commands to prepare the environment:

cd samples-for-payment-cryptography-service/tree/main/key-import-export/key_exchange
python -m venv .venv
source .venv/bin/activate 
pip3 install -r requirements.txt

TR-34 Key Import
The TR34 sample script imports a Key Encryption Key (KEK) from payShield 10K HSM into AWS Payment Cryptography. There are two options:

1. Import an existing KEK from payShield HSM. In the input_config.json file, under kdh/payshield/tr34, populate the “transport_key” with the LMK encrypted Key Encryption Key and “transport_key_kcv” with the key’s key check value.
2. Generate a new KEK during the import operation. Leave the “transport_key” and “transport_key_kcv” fields empty. The script will generate new keys during import.

Execute:

 python3 import_export_tr34.py --kdh payshield --krd apc

The previous command will return the Amazon Resource Name (ARN) of the KEK from AWS Payment Cryptography along with the HSM LMK encrypted KEK.

TR-31 Key Import
The TR31 sample script imports working keys from Payshield HSM into AWS Payment Cryptography. There are two options:

1. Import an existing working key from payShield. In the input_config.json file, under kdh/payshield/tr31, populate the “transport_key” with the LMK encrypted Key Encryption Key and “transport_key_kcv” with the key’s key check value.
2. Generate a new working key during the import operation. Leave the “transport_key” and “transport_key_kcv” fields empty. The script will generate new keys during import.

Before running the script, ensure you have established a Key Encryption Key (KEK) between your HSM and AWS Payment Cryptography by running the TR-34 import script.

Update the file input_config.json with the KEK:

• Under the kdh/payshield/tr31 section, set “kek” to the LMK encrypted value of the KEK.
• Under the krd/apc/tr31 section, set “kek” to the key ARN of the KEK you got from the TR-34 script output.

Execute:

python3 import_export_tr31.py --kdh payshield --krd apc

The previous command will return the Amazon Resource Name (ARN) of the working key imported in AWS Payment Cryptography.

ECDH Key Import

This is currently supported for Payshield HSM configured with KeyBlock LMK only and does not support variant LMK. The scripts provide two options for importing working keys from HSM to AWS Payment Cryptography:

1. Import an existing working key from payShield. In the input_config.json file under kdh/payshield/ecdh, populate the “transport_key” with the LMK encrypted key and “transport_key_kcv” with the key’s key check value.

2. Generate a new working key during the import operation. Leave the “transport_key” and “transport_key_kcv” fields empty. The script will generate new keys during import.

Execute:

python3 import_export_ecdh.py --kdh payshield --krd apc

The previous command will return the Amazon Resource Name (ARN) of the key imported in AWS Payment Cryptography.

Futurex

The Futurex Payment HSM series are payment HSMs designed for payment applications offering cryptographic processing and key management capabilities.

Configuration
Note: The script assumes the HSM is configured with an AES-256 Partition Master Key.

1. Get the migration scripts from the AWS Samples GitHub repository.
2. Ensure your HSM config file matches the sample config included with the scripts. We tested the scripts with this sample file.
3. Update the input_config.json file. Under ‘kdh/futurex’

a. Add the HSM host and port information.
b. In the “krd” section, fill in the details for “apc” with the AWS region where you will import the key.

4. Execute the following to prepare the environment –

cd samples-for-payment-cryptography-service/tree/main/key-import-export/key_exchange
python -m venv .venv
source .venv/bin/activate 
pip3 install -r requirements.txt

TR-34 Key Import
The TR34 sample script imports a Key Encryption Key (KEK) from Futurex HSM into AWS Payment Cryptography. There are two options:

1. Import an existing KEK from Futurex HSM. In the input_config.json file, under kdh/futurex/tr34, populate “transport_key” with the LMK encrypted Key Encryption Key and “transport_key_kcv” with the key’s key check value.
2. Generate a new KEK during the import operation. Leave the “transport_key” and “transport_key_kcv” fields empty. The script will generate new keys during import.

Execute:

python3 import_export_tr34.py --kdh futurex --krd apc

The previous command will return the Amazon Resource Name (ARN) of the KEK from AWS Payment Cryptography along with the HSM LMK encrypted KEK.

TR-31 Key Import
The TR31 sample script imports working keys from Futurex HSM into AWS Payment Cryptography. There are two options:

1. Import an existing working key from Futurex. In the input_config.json file under kdh/futurex/tr31, populate “transport_key” with the PMK encrypted Key Encryption Key and “transport_key_kcv” with the key’s key check value.
2. Generate a new working key during the import operation. Leave the “transport_key” and “transport_key_kcv” fields empty. The script will generate new keys during import.

Before running the script, ensure you have established a Key Encryption Key (KEK) between your HSM and AWS Payment Cryptography by running the TR-34 import script.

Update the input_config.json file with KEK:

• Under the kdh/futurex/tr31 section, set “kek” to the PMK encrypted value of KEK.
• Under the krd/apc/tr31 section, set “kek” to the key ARN you got from the TR-34 script output.

Execute:

python3 import_export_tr31.py --kdh futurex --krd apc

The previous command will return the ARN of the key imported in AWS Payment Cryptography.

ECDH Key Import
The scripts provide two options for importing working keys from HSM to AWS Payment Cryptography:

1. Import an existing working key from futurex. In the input_config.json file, under kdh/futurex/ecdh, populate “transport_key” with the PMK encrypted key and “transport_key_kcv” with the key’s key check value.
2. Generate a new working key during the import operation. Leave the “transport_key” and “transport_key_kcv” fields empty. The script will generate new keys during import.

Execute:

python3 import_export_ecdh.py --kdh futurex --krd apc

The previous command will return the Amazon Resource Name (ARN) of the key imported in AWS Payment Cryptography.

Atalla AT1000

Atalla AT1000 is a payment HSM designed for payment applications offering cryptographic processing and key management capabilities.

Configuration
1. Get the Atalla migration scripts from the AWS Samples GitHub repository. The sample scripts for Atalla support key exchange using TR34 and TR31 protocols.

2. Execute the following to prepare the environment.

cd samples-for-payment-cryptography-service/tree/main/key-import-export/key_exchange/hsm/atalla
python -m venv .venv
source .venv/bin/activate 
pip3 install -r requirements.txt

Note: You will need to enable option E2 in Atalla otherwise it may restrict your ability to output certain keys (including KEKs). This is a common source of error 0607 (security violation).

TR-34 Key Import
To perform the key exchange with the provided scripts, Atalla requires establishing a trust between itself and AWS Payment Cryptography using the following steps:

1. Open a terminal window and navigate to the samples-for-payment-cryptography-service/tree/main/key-import-export/key_exchange/hsm/atalla directory
2. Call the AWS Payment Cryptography API GetParametersForImport and save the output under keys/params_for_import.json
3. Import the KRD (in this case is AWS Payment Cryptography) Leaf certificate into Atalla. You will find it in WrappingKeyCertificate from params_for_import.json.

Note: Typically, you import the CA certificate and then the leaf certificate. However, the Atalla command for importing chained certificates (123) does not support the SHA-512 hash function used by the AWS Payment Cryptography service, therefore, you must directly trust the leaf certificate using the command 12A which is a manual process requiring dual control.

The following are the steps to import the AWS Payment Cryptography certificate into Atalla:

a. Get the modulus of the public key certificate (WrappingKeyCertificate).

For example:
echo "LS0tLS1CRUdJTiBDRVJUSUZJQ..." | base64 -d | openssl x509 -modulus -noout

b. Trust the KRD public key on Atalla. To establish the trust, use command 12A. This is a two-step command that requires dual control, with the final output being an AKB (Atalla Key block) of the public key.

i. On Atalla execute:
<12A#1kREE000#010001#modulus##>

This returns a security challenge. The same 12A command needs to be rerun after completing the security challenge using the administrative screen on Atalla.

ii. Rerun the same command with security challenge:

<12A#1kREE000#010001#modulus#security challenge answer#>

The output of this command gives the public key AKB, which will look like:

<22A#OK#1kREE000,00030100010100B0357EB48EEEEAE......#>

iii. Save the output from the header onwards to the end of the response

1kREE000,00030.....BBB,26A8A315 on to the keys/tr34_offline_krd_public_key_akb file.

On the terminal, execute the following.

python3 atalla_to_apc_tr34.py <hsm address> <hsm port>

Example:

python3 atalla_to_apc_tr34.py '127.0.0.1' 7000 

The previous command will return the Amazon Resource Name (ARN) of the KEK from AWS Payment Cryptography along with the HSM LMK encrypted KEK.

TR-31 Key Import
Once you exchange the KEK with the TR-34 process, you are now ready to exchange the working keys between Atalla and AWS Payment Cryptography using the TR-31 protocol.

Execute the following commands to exchange a working key:

python3 atalla_to_apc_tr31.py --host <hsm address> --port <hsm port>
         -wrappingKey "1kDNE000,14FB26DD179D6AD587FA0181E599F6CC07F0C8D2AAA2334D,BB6AE577B37A1CD7" 
         --wrappedKey "1CDNE000,55343DEFA0898223CCCDD33AAAFFFF2342B09234ABCDEF54,CDA43234FFFED091" 
         --apcWrappingKeyARN "arn:aws:payment-cryptography:us-west-2:111222333444:key/rd56grgskugzelkz

In this example:

• wrappingKey is the Atalla MFK encrypted wrapping key. This is output of the TR34 import
• wrappedKey is the Atalla MFK encrypted working key
• apcWrappingKeyARN is the ARN of the wrapping key (KEK) imported into AWS Payment Cryptography. This is output of the TR34 import

The previous command will return the Amazon Resource Name (ARN) of the key imported in AWS Payment Cryptography.

Clean Up

The sample scripts will generate keys and make API calls, which will generate charges. Please review the pricing page for estimated charges. To avoid any recurring charges, delete the test keys if no longer needed.

Conclusion

As payment transactions grow, businesses face mounting pressure to optimize payment processing while driving innovation. AWS Payment Cryptography Service addresses this challenge by offering payment HSM capabilities as a managed service, eliminating the complexities of traditional HSM management. This service not only streamlines operations but also helps reduce HSM based payment transaction processing costs.

This blog post shows how AWS payment cryptography synchronizes keys with diverse HSM products using PCI DSS compliant industry-standard protocols including TR-34, TR-31, and ECDH. Once key synchronization completes, businesses leverage AWS Payment Cryptography Service to execute their payment workflows efficiently and securely.

We look forward to customers simplifying their card payment cryptographic operations using AWS Payment Cryptography. Please visit the guide to get started.