Meet PCI compliance with credit card tokenization

8th March 2022 Anthony Mashford 0 Comments

In building and running a business, the safety and security of your and your customers' sensitive information and data is a top priority, especially when storing financial information and processing payments are concerned. The Payment Card Industry Data Security Standard (PCI DSS)¹ defines a set of regulations put forth by the largest credit card companies to help reduce costly consumer and bank data breaches.

In this context, PCI compliance refers to meeting the PCI DSS’ requirements for organizations and sellers to safely and securely accept, store, process, and transmit cardholder data during credit card transactions, to prevent fraud and theft.

Towards confidential computing

In June 2021, the Monetary Authority of Singapore (MAS)² issued an advisory circular on addressing the technology and cyber security risks associated with public cloud adoption. The paper describes a set of risk management principles and best practice standards to guide financial institutions in implementing appropriate data security measures to protect the confidentiality and integrity of sensitive data in the public cloud, taking into consideration data-at-rest, data-in-motion, and data-in-use where applicable³. Specifically, at section 21, reported below, for data that is being used or processed in the public cloud, financial institutes (FIs) may implement confidential computing solutions if available from the cloud service provider. Confidential computing solutions protect data by isolating sensitive data in a protected, hardware-based computing enclave.

Data security and cryptographic key management

FIs should implement appropriate data security measures to protect the confidentiality and integrity of sensitive data in the public cloud, taking into consideration data-at-rest, data-in-motion and data-in-use where applicable.

For data-at-rest, that is, data in cloud storage, FIs may implement additional measures e.g. data object encryption, file encryption or tokenization in addition to the encryption provided at the platform level.
For data-in-motion, that is, data that traverses to and from, and within the public cloud, FIs may implement session encryption or data object encryption in addition to the encryption provided at the platform level.
For data-in-use, that is, data that is being used or processed in the public cloud, FIs may implement confidential computing solutions if available from the CSPs. Confidential computing solutions protect data by isolating sensitive data in a protected, hardware-based computing enclave during processing.

Confidential virtual machines

On these premises, FIs can leverage Azure confidential computing for building an end-to-end data and code protection solution on the latest technology for hardware-based memory encryption. The solution presented in this article for processing credit card payments makes use of confidential virtual machines (CVMs) running on AMD Secure Encrypted Virtualization (SEV)—Secure Nested Paging (SNP) technology.

AMD introduced SEV to isolate virtual machines (VMs) from the hypervisor. Hypervisors are typically considered trusted components in the virtualization security model, but many customers have demanded a stronger VM trust model which removes, for example, the exposure to vulnerabilities in the cloud provider’s infrastructure. With SEV, individual VMs are assigned a unique encryption key wired in the CPU, used for automatically encrypting the memory allocated by the hypervisor to run a VM.

The latest generation of SEV technology includes SNP capability. SNP adds new hardware-based security by providing strong memory integrity protection from potential attacks to the hypervisor, including data replay and memory re-mapping.

Azure confidential computing offers confidential VMs based on AMD processors with SEV-SNP technology. Confidential VMs are for tenants with high security and confidentiality requirements. You can use confidential VMs for migrations without making changes to your code, with the platform protecting your VM’s state from being read or modified. Benefits of confidential VMs include:

Robust hardware-based isolation between virtual machines, hypervisor, and host management code.
Attestation policies to ensure the host’s compliance before deployment.
Cloud-based full-disk encryption before the first boot.
VM encryption keys that the platform or the customer (optionally) owns and manages.
Secure key release with cryptographic binding between the platform’s successful attestation and the VM’s encryption keys.
Dedicated virtual Trusted Platform Module (TPM) instance for attestation and protection of keys and secrets in the virtual machine.

The provisioning of a confidential VM in Azure is as simple as any other regular virtual machine, using your preferred tool, either manually via the Azure Portal, or by scripting with Azure command-line interface (CLI). Figure 2 shows the process of creating a virtual machine in the Azure Portal, with specific attention to the “Security type” attribute. For provisioning a confidential VM based on AMD SEV-SNP technology, you have to select that specific entry in the dropdown list. At the time of writing (February 2022), confidential VMs are in preview in Azure, and thus limited in availability across regions. As this service enters general availability, more regions will be available for deployment.

Figure 1: Confidential Virtual Machine in Azure Portal.

Credit card tokenization

In the scenario above in Figure 2, the process of tokenization is a random oracle, which is a process that, given an input, generates a non-predictable output. The random output always varies even if the same input is provided. For example, when a customer makes a second payment using the same credit card used in a previous transaction, the token generated will be different. Lastly, when providing that random output back to the service, the tokenization interface fetches the original input.

Not by coincidence that I used the term “interface” for describing this tokenization service. Indeed, the technical implementation of such random generator is a Web API running in the .NET 6 runtime. Figure 3 describes the reference architecture for the solution.

Figure 2: Credit card tokenization architecture reference.

A payment transaction is initiated by the customer and payment data is transferred to the .NET Web API. This API is running on a confidential VM, in an isolated environment that is not accessible by the cloud service provider.
The random token is generated by the API based on the input data. Tokenization includes also encryption of such data, with a symmetric cryptographic algorithm (AES specifically).
The encryption key is stored in Azure Key Vault running on a managed Hardware Secure Module (HSM). This is a critical component of the confidential solution, as the encryption key is preserved inside the HSM and never exposed to the cloud provider or any other rogue administrator. Only the Web API app is authorized to access the secret key.
The following code snippets show the implementation of the key retrieval from AKV inside the Get method of the Web API.

[HttpGet(Name = "GetToken")] public async Task<TokenTuple> Get(CreditCard card)
{ // Retrieve the AES encryption key from AKV string akvName = Environment.GetEnvironmentVariable("KEY_VAULT_NAME"); var akvUri = $"https://{akvName}.vault.azure.net"; var akvClient = new SecretClient(new Uri(akvUri), new Azure.Identity.DefaultAzureCredential()); var secret = await akvClient.GetSecretAsync("AesEncryptionKey"); EncryptionKey key = JsonSerializer.Deserialize<EncryptionKey>(secret.Value.Value);

Azure Key Vault Managed HSM is a fully managed, highly available, single-tenant, standards-compliant cloud service that enables you to safeguard cryptographic keys for your cloud applications, using FIPS 140-2 Level 3 validated HSMs.

The service is highly available and zone resilient (where availability zones are supported): Each HSM cluster consists of multiple HSM partitions that span across at least two availability zones. If the hardware fails, member partitions for your HSM cluster will be automatically migrated to healthy nodes.

Each Managed HSM instance is dedicated to a single customer and consists of a cluster of multiple HSM partitions. Each HSM cluster uses a separate customer-specific security domain that cryptographically isolates each customer's HSM cluster.

The HSM is FIPS 140-2 Level 3 validated, which means that it meets compliance requirements with Federal Information Protection Standard 140-2 Level 3.

AKV Managed Hardware Security Module (MHSM) also meets data residency as it doesn't store and process customer data outside the region the customer deploys the HSM instance in.

Lastly, with AKV MHSM, customers can generate HSM-protected keys in their own on-premises HSM and import them securely into Azure.
The obtained encryption key is then used to encrypt the payment data with a symmetric cipher. The encrypted value is associated with a newly generated token and added as a message to the queue. In the code snippet below, the pair token and encrypted data is stored in a tuple object and then enqueued.
// Encrypt the credit card information string json = JsonSerializer.Serialize(card); string encrypted = SymmetricCipher.EncryptToString(json, key);

// Generate token Token token = Token.CreateNew();

// Add the token tuple to the queue TokenTuple tuple = new (token, encrypted); QueueManager.Instance.Enqueue(tuple);
The generated token is added to an in-memory queue. There is no persistence of data in the solution. The token expires after a configurable amount of time, typically a few seconds, that allows the payment gateway to process the payment information from the queue. The combination of running this solution on a confidential infrastructure, as well as the volatility of data in the queue, makes the system PCI compliant: no sensitive payment data is stored and processed in clear text.
The queue mechanism can be implemented with any highly reliable queen engine, such as RabbitMQ. By running in a CVM, confidentiality of data in the queue is retained also during in-memory processing utilizing a third-party application such as RabbitMQ or similar with no code changes.
The payment gateway implements the Publish-Subscribe pattern (Pub-Sub) for retrieving messages from the queue, using a webhook for registering the endpoint to invoke and de-queue a message.
[HttpGet(Name = "ResolveToken")] public async Task Post(string subscriberUri) { TokenTuple tuple = QueueManager.Instance.Dequeue(); await HttpClientFactory.PostAsync(subscriberUri, tuple); }

Get started

To get started with Azure confidential computing and implement a similar solution, I recommend having a look at our official Azure confidential computing documentation.

More specifically, you may want to start by creating a confidential VM as your test environment for publishing your code. You can follow the instructions described in this article to configure a CVM manually in the Azure Portal, or you may want to leverage an ARM template for automation.

A confidential VM is exactly like any other VM, just more confidential! That is, any data and code running in a CVM are isolated from the hypervisor and thus not visible to the cloud service provider. As any IaaS service, you are still responsible for provisioning and maintenance, including OS patching and runtime installation. And as any other VM, you have the freedom to install and run any software you want that is compatible with the installed operating system. This, basically, enables you to “lift and shift” any existing application and code to Azure confidential computing, and get immediate benefits of the in-memory data protection that Azure confidential computing delivers.

References

¹The Payment Card Industry Data Security Standard (PCI DSS).

²The Monetary Authority of Singapore (MAS).

³Advisory on Addressing the Technology and Cyber Security Risks Associated with Public Cloud Adoption, MAS, June 1, 2021.

Source: Azure Blog Feed

Mashford's Musings