Moving Payments to the Cloud

Meet some Two-key Triple DES within an HSM

https://asecuritysite.com/des

Moving Payments to the Cloud

Meet some Two-key Triple DES within an HSM

There is little to stop payments from moving fully into the Cloud, apart from where there are regulatory requirements or where there is poor network connectivity. We now live in an always-on networking society, where ISP (Internet Service Providers) now promote network resilience as a key selling point (and with 4G and broadband support):

So, would debate whether it was really unbreakable, but it certainly shows that network resilience is now a key feature for network connectivity.

But, surely payments must be done on a trusted piece of hardware? Well, not quite, as the main element of the payment is that it can be processed in a secure enclave, where the processing and encryption keys cannot be tampered with. In fact, moving into the cloud could have many advantages, including the fact that the device does not need to be set up to store sensitive information. The Cloud, too, offers enhanced audibility and logging of data.

The solution to this is to use a Hardware Security Module (HSM) in the Cloud, which is now offered by AWS with their AWS Payment Cryptography:

A core part of the service is that it complies with payment card industry (PCI) standards (such as PCI PIN, PCI P2PE, and PCI DSS), without needing a dedicated payment HSM and supporting the closer binding to other Cloud-based services. AWS claims the latency for payment processing is also low with elastic provisions for scale-ups. An option also allows the shares of encryption keys with other partners.

A core part of the HSM is to securely store customer PIN numbers and will help payments where the payment system needs to store a customer’s PIN on a long-term basis. With your Amazon online shopping, for example, you never have to enter your PIN for payment, as your PIN number has been stored securely on their systems. In the HSM, too, we can generate CVV, CVV2 and ARQC values, where sensitive details never exist outside the HSM in an unprotected form.

With AWS, we identify keys with an ARN (Amazon Resource Number), which is unique to the instance of the keys. These keys are managed in the KMS (Key Management Service), where symmetric keys and the private keys for public keys are which are then stored in an HSM. Symmetric keys are used for symmetric key encryption (such as AES) and MAC signatures (such as HMAC), while asymmetric keys (such as RSA and ECDSA) are used to sign and verify. In the following, the ARN will be generated from the key ID:

and where the ARN is then derived from the Key ID:

2KEY TDES

2KEY TDES is Two-key Triple DES and has a 112-bit equivalent key size. It basically uses the DES encryption method (which is insecure in its 56-bit form), three times, and uses two keys: K1 and K2:

The 2KEY TDES is used to generate and verify CVV/CVV2 values. These are used in the CVV/CVV2 request, and where the response includes an ARN (Amazon Resource Name) for future calls, and a KCV (Key Check Value).

$ aws payment-cryptography create-key --exportable \
--key-attributes KeyAlgorithm=TDES_2KEY,\
KeyUsage=TR31_C0_CARD_VERIFICATION_KEY,KeyClass=SYMMETRIC_KEY,

The response to this is the creation of the key:

KeyModesOfUse='{Generate=true,Verify=true}'{
"Key": {
"CreateTimestamp": "2022-10-26T16:04:11.642000-07:00",
"Enabled": true,
"Exportable": true,
"KeyArn": "arn:aws:payment-cryptography:us-east-2:111122223333:key/hjprdg5o4jtgs5tw",
"KeyAttributes": {
"KeyAlgorithm": "TDES_2KEY",
"KeyClass": "SYMMETRIC_KEY",
"KeyModesOfUse": {
"Decrypt": false,
"DeriveKey": false,
"Encrypt": false,
"Generate": true,
"NoRestrictions": false,
"Sign": false,
"Unwrap": false,
"Verify": true,
"Wrap": false
},
"KeyUsage": "TR31_C0_CARD_VERIFICATION_KEY"
},
"KeyCheckValue": "B72F",
"KeyCheckValueAlgorithm": "ANSI_X9_24",
"KeyOrigin": "AWS_PAYMENT_CRYPTOGRAPHY",
"KeyState": "CREATE_COMPLETE",
"UsageStartTimestamp": "2022-10-26T16:04:11.559000-07:00"
}
}

In this case the ARN is:

arn:aws:payment-cryptography:us-east-2:111122223333:key/hjprdg5o4jtgs5tw

Pin Encryption Key (PEK)

The PEK is used to encryption PIN values and uses a KEY TDES key. This can store PINs in a secure way, and then decrypt them when required. The response back will produce an ARN and a KCV (Key Check Value). An example command to generate the key is:

$ aws payment-cryptography create-key --exportable --key-attributes \
KeyAlgorithm=TDES_3KEY,KeyUsage=TR31_P0_PIN_ENCRYPTION_KEY, \
KeyClass=SYMMETRIC_KEY,/
KeyModesOfUse='{Encrypt=true,Decrypt=true,Wrap=true,Unwrap=true}'

RSA Key

In order to authenticate the server, we need an RSA key pair, and keep the private key in the HSM, but expose the public key. For this, we need a 2K or 4K RSA key pair. This is generated with:

$ aws payment-cryptography create-key --exportable \
--key-attributes KeyAlgorithm=RSA_2048,\
KeyUsage=TR31_D1_ASYMMETRIC_KEY_FOR_DATA_ENCRYPTION, \
KeyClass=ASYMMETRIC_KEY_PAIR,
KeyModesOfUse='{Encrypt=true, Decrypt=True,Wrap=True,Unwrap=True}'

PIN Verification Value (PVV) Key

The PVV key is used to create a key checking the calculated PVV. An example call is:

$ aws payment-cryptography create-key --exportable/
--key-attributes KeyAlgorithm=TDES_3KEY,/
KeyUsage=TR31_V2_VISA_PIN_VERIFICATION_KEY,/
KeyClass=SYMMETRIC_KEY,KeyModesOfUse='{Generate=true,Verify=true}'

Conclusions

For security, the Cloud can considerably enhance security, but we need to make sure that we run our trusted code in secure enclaves. If you are interested in cryptography, try here:

https://asecuritysite.com/des/

and in AWS:

https://asecuritysite.com/aws

and specifically for cryptography in the cloud:

https://asecuritysite.com/aws/labs