The HSM is a vital component in guaranteeing the secrecy and additionally information integrity of business transactions. HSMs are appropriately secure during their entire lifecycle to help incite trust in the authenticity of the business transactions. Since the release of PCI PIN Transaction Security (PTS) Hardware Security Module (HSM) version 3 in June 2016, companies have started working on v3 compliant HSMs which is necessary for security and legal obligations.

PCI PTS HSM started from the version 1.0 which was released in April 2009. After the release of version 1.0, hundreds of cryptographic modules & HSM vendors complied this standard and got their devices v1.0 validated. The updated version 2.0 which was publicly released in May 2012 is being used less since the inception of version 3.0. This article enlightens the merchants with a rundown of the distinctive critical security requirements against which their HSMs will be evaluated to get PCI PTS HSM version 3.0 certified.

Distinctive Requirements between PCI PTS HSM v2.0 and v3.0

The distinctive requirements between PCI PTS HSM v2.0 and v3.0 are

  1. Requirements for Key-Loading Devices
  2. HSM Remote Administration Platform

Requirements for Key Loading Devices

Key Loading is functionality that must be met by devices that perform key injection of either clear-text or enciphered keys or their components.

New call-to-action

The detailed requirements of key loading are: 

  • If the actual HSM manufacturer company is responsible for the initial key loading process, the authenticity of the security-related components of HSM must be validated by the manufacturer.
  • If the actual HSM manufacturer company is not responsible for the initial key loading process, then the security mechanism for initial deployment to assure the verification of the authenticity of the security-related components of HSM must be provided by the manufacturer.
  • In case the HSM supports the generation of cryptographic keys (symmetric or asymmetric key pairs), the generated key material should not be visible during the
    generation process in plain-text form at any time.
  • In case the HSM is capable of generating symmetric keys or asymmetric key pairs which are not cryptographically used by the HSM, the key(s) are immediately erased after the transmission mechanism.
  • The HSM should not store or retain any sort of key-related information that may disclose any key that the HSM had previously generated and transferred to another cryptographic component.
  • In case the HSM has components with different security levels, it is not permissible to transfer a key from a higher security component to a lower security component in the device.
  • When the HSM has been deployed and contains sensitive cryptographic key material, there must not be a possible method to alter the device functionality/firmware without the erasure/zeroization (immediate and/or automatic) of the cryptographic keys.

Requirements for Remote Administration

HSMs are mostly deployed in data centers which are physically secure by many access control mechanisms. Therefore, the need for remote administration of HSMs is a basic requirement which includes the basic device management functions such as checking the status and upgrading firmware to advanced level operation such as device configuration and key-loading services.

  • The secure web interface should be designed in such a way that input of more than one password (dual or multiple controls) must be required in order to enter a sensitive state and that it is highly unlikely that the device can inadvertently be left in the sensitive state.
  • Sensitive functions and the corresponding information must only be used in the protected area(s) of the HSM. Sensitive functions which deal with sensitive information must be protected from unauthorized substitution and/or modification.
  • HSM design aspects must ensure that after the completion of the HSM initialization process only it can be put in cryptographically operational service.
  • Critical device management operations such as the disabling/enabling of HSM functions and change of passwords are only permitted when the device is in a sensitive state.

Conclusion

There is always a need for improvement in security. Since the release of PCI PTS HSM version 3.0, vendors are swiftly shifting/complying their devices to the latest standard. The updated v3.0 standard emphasizes on the requirements for key-loading devices and HSM remote administration from the basic device management functions to advanced level operations.

New call-to-action

References and Further Reading