2 min read

An Introduction to the Role of HSMs for PCI DSS Compliance

An Introduction to the Role of HSMs for PCI DSS Compliance

The Payment Card Industry Data Security Standard (PCI DSS) helps to safeguard cardholders’ private information. The Payment Card Industry Security Standards Council (PCI SSC) enforces the standard through recommendations and requirements that aim to ensure security across all organizations involved in the processing of cardholder information.

PCI DSS compliance ensures that baseline security levels are adhered to, which will give assurance to the clients and financial institutions that the risk of losses emanating from fraud and cyber attacks are within acceptable levels. For the scope of this discussion we will look at the role of HSMs in support of PCI DSS compliance.

New Call-to-actionAll financial institutions rely heavily on cryptography in transaction processing, including endpoint authentication, secure communications and card/PIN verification. For this they rely on hardware security modules (HSMs)These devices provide a high level of assurance for the confidentiality, integrity and availability of cryptographic keys and any private data being processed.

At a high level, HSMs are responsible for the secure generation and storage of the countless cryptographic keys that are used throughout the payments ecosystem.

They also act as dedicated cryptographic processing devices using cryptographic algorithms compliant with the FIPS 140-2 security standard. In particular, HSMs assure that the cryptographic keys for the cardholder data being processed by the servers are genuine.

As illustrated in figure 1, when a transaction is initiated at the merchant point-of-sale (POS) terminal, the transaction request is sent to the bank processing site through a secure tunnel, e.g. TLS v1.2. Instead of the keys used to validate client card details being maintained on the bank’s servers, the keys are protected and processed by the HSM. The bank server will get the HSM to confirm the validity of the encrypted information and the transaction will thereby either be authorized or declined.

HSMs-Key-Management-PCIDSS-compliance

Figure 1

PCI DSS requirement 3.6.2, relating to secure cryptographic key storage, dictates that mechanisms must be put in place to secure encryption keys used to encrypt cardholder related data. Storing the keys in unsafe locations will render an organization susceptible to cyber attacks. Encrypting the keys will provide an added layer of security. The requirement for dual control (i.e. two independent operators) when managing the HSM ensures confidence in the validity of the keys. For more details on the PCI DSS requirements relating to key management and HSMs, please read the Cryptomathic white paperAll these PCI DSS requirements can be met by HSMs which conform to FIPS 140-2 security level 3 and above.

The generation of the cryptographic keys is done inside the HSM, which is also the only place that the private and/or secret key(s) are available unencrypted. Once a transaction is initiated from a merchant and reaches the issuing bank, cryptographic checking will be carried out inside the HSM and all confirmation for validity will emanate there as well.

HSMs come in different sizes and forms - some are standalone devices connected to the server by Ethernet or USB, and some are just slotted onto the main board of computers via the PCI slot. The HSM devices are produced by specialist manufacturers and they have physical and logical characteristics depending on which security standard they aim to satisfy, such as FIPS or Common Criteria standards. 

In relation to PCI DSS, the level of protection HSMs provide is rated using the FIPS 140-2 standard (level 1 to 4). HSMs that are compliant with FIPS 140-2 security level 3 and above provide the highest level of security. They are designed with mechanisms that can detect physical compromise which will trigger the erasure of all the high security data.

New Call-to-action


References and Further Reading

Image: "Security", courtesy of Jurgen Appelo, Flickr (CC BY 2.0)