Payment HSM Certifications – what do they mean?
Bernard Foot, Strategy Analyst at MYHSM, the Payment HSM as a Service provider, looks at the certifications available for Payment HSMs to see what they really tell you.
Do you need to worry about certifications?
I guess it’s always better to use certified products. But you don’t really have a choice if you’re using an HSM for payments: you’ll need to conform to PCI standard, and many of these (inc. PIN, P2PE, Card Production and Provision, 3D-Secure, Token Service Provider) require the use of certified Payment HSMs. The certifications accepted by PCI are their own PCI PTS HSM and FIPS 140-2.
Sounds Straightforward
I think all Payment HSMs claim to have both certifications, so it’s a tick in the box by your QSA. Perhaps. But your QSA may dig deeper to ensure the letter of the law is implemented. And if your focus is on assuring security rather than “just” getting through a PCI assessment, you want to know what these certifications actually tell you.
FIPS 140-2
FIPS (Federal Information Processing Standard) standards are used by the US and Canadian governments for government purchases, but many have been adopted in the commercial world in the absence of relevant industry norms. FIPS 140-2 is the 2nd version of the standard for secure cryptography modules first published in 1994.
There are some important points to understand about FIPS 140-2. Firstly, it is concerned with cryptography in general rather than the payments industry specifically.
Secondly, FIPS-certified modules can operate in a non-FIPS mode, such that the certification no longer applies. The various PCI standards have different wording around FIPS compliance: P2PE v2.0 requires that any operation in non-FIPS mode is documented and justified.
Thirdly, vendors choose what part of their product is certified. Payment HSM manufacturers typically certify just the core cryptographic module: this is the most significant technology in the HSM, but it is not the whole HSM. (Some modules are card-based products to be installed in host computers, raising questions as to what the physical boundary of the HSM is.)
And typically the certified firmware is just a bootstrap to ensure that only authorised applications are loaded. But the applications themselves are not certified, so as soon as an application to do anything useful runs, the HSM is no longer FIPS-certified. P2PE v2.0, again, requires that use of non-FIPS validated software must be documented.
It may also be that only a subset of the required algorithms are covered by the FIPS 140-2 certificate, the others having other FIPS certifications.
FIPS 140-2 certification certainly has value in assuring the security credentials of the product and QSAs generally seem happy to accept it for PCI compliance, but I struggle to understand how the requirement for the HSM (i.e. the whole device) to be certified is met.
PCI PTS HSM
PCI brought out their own HSM standard under the PTS (PIN Transaction Security) programme in 2009, now at its third version. Some of its requirements are derived from FIPS 140-2. The PCI standard is specifically for Payment HSMs, covering the whole HSM (including firmware and applications), and device management during manufacturing and shipment. But there are gotchas to look out for.
Because firmware and applications are included, vendors may not get all versions approved, or urgent updates may be released prior to getting approval. To assure an HSM is PCI approved, you need to check the installed software version is listed in the online approval.
The HSM vendor may offer a software customisation service, or the HSM may have a facility to run customer-developed software. Use of these facilities would mean that the HSM is no longer approved – unless the custom software has been put through the approval process.
Some PCI-approved HSMs have a non-PCI mode, for example to support legacy applications using non-approved algorithms or PIN block formats. Taking advantage of this means the HSM is no longer PCI-approved.
The PCI approval may limit the HSM to being deployed in a controlled environment: this places onus on the user to ensure they are providing an acceptable environment.
The Take-Aways
Your Payment HSM almost certainly has a FIPS 140-2 or PCI PTS HSM approval to meet the needs of your QSA. However, there are plenty of opportunities to invalidate the approval.
But if you really want to understand what has actually been tested and approved on your HSMs, you need to carefully read the approval material on the NIST (for FIPS) and PCI websites, and in particular the HSM’s Security Policies. And then make sure that your deployment architecture supports the approvals you want.
Or you can use Payment HSM as a Service and let the service provider worry about that!