How to select an HSM

Please find below a list of the relevant criteria for how to select a Hardware Security Module (HSM). As the choice of Hardware Security Module is dependent on the specific application it is used for, I would like to make some general recommendations by providing a list of potential criteria to take into account, irrespective of what you intend to use it for.

Some technical factors:

• Performance – Look at the performance factors for each type of HSM, but focus specifically on your use case: encryption/decryption/key generation/signing, symmetric, asymmetric, EC, etc. Ask about true performance figures, e.g. for a network-attached HSM, ask about the network configuration or for embedded cards, ask about standards released after the PCIe bus.
• Scalability – What are the limiting factors in terms of scalability, in connection with your application? Do you need a defined number of keys stored inside the HSM? How could you add another HSM? How easy would this be?
• Redundancy – What happens if one HSM breaks? How much would this impact on your operations? How easy would it be to replace without loss of service, etc.
• Backups – How are backup and restore processes carried out? How much effort would it be for your organization to implement these processes? Are you able to avoid irretrievably losing your data?
• API support – The API is the connection to your Application-Host environment. Here are some hints for dealing with questions about supported APIs:
  • Microsoft MS CSP/CNG: The Microsoft “standard” API is the easiest way to connect to an HSM when using Windows;
  • JCE: The “standard” Java developer.
  • PKCS#11: The “industry standard”, but there are some pitfalls such as known security issues and vendor proprietary extension. ATTENTION: Vendor proprietary extensions or mechanisms are use case-specific API extensions, and are not part of the PKCS#11 standard. This will increase costs when switching vendor.

Conclusion:

Choose the API that is compatible with your use case and operating system. If you are using Microsoft OS, choose CNG. If you are using an application that supports PKCS#11, choose PKCS#11. Ask for guidance on integration or How-to Guides.

• OS / hardware support – This requires different issues to be taken into consideration. The first of which is: Which operating systems are supported by the embedded card (PCIe-Driver)? Another issue: Which operating systems are supported by the network-attached HSM? Also: Which OS is supported by the managements tools, e.g. GUI/command line?
• Management – Can the HSM be managed remotely? Which functions can be activated and controlled remotely?
• Programmability – Most of your development will be at the other end of the APIs, but sometimes it can be useful to have the ability to write applications that run on the device, for greater flexibility or speed and to specify your API.
• Physical security – Ask yourself the question: How resistant to direct physical attack does your solution need to be? If, for whatever reason, you decide that it is particularly important, you might want to look for “active tamper detection and response”, as opposed to just “passive tamper resistance and evidence”. Or alternatively, in terms of FIPS 140-2, look for FIPS 140-2 level 4 hardware, or stick to the conventional FIPS 140-2 level 3.
• Algorithms – Does the HSM support the cryptographic algorithm you want to use, via the selected API (primitives, modes of operation and parameters e.g. curves, key sizes)?
• Authentication options – passwords; quorums; n-factors; smartcards; etc. At the very least, you should be looking for something that requires a configurable quorum size or password-authenticated users before allowing operations via use of a key.
• Policy options – You might want to be able to define policies, such as controlling whether or not: keys can be exported from the HSM (wrapped or unencrypted); a key can only be used for signing/encryption/decryption/…; authentication is required for signing, but not verifying, etc.
• Audit capability – Including both HSM-like operations (generated key, something signed with key Y) and handling connection problems or crashes. How easy is it going to be to integrate the logs into your monitoring system (syslog/snmp/other network accessible – or at least non-proprietary – output)?

Form factor:

Network-attached HSMs: For larger-scale deployments, particularly where multiple applications/servers/clients need to utilize HSM services.
Embedded HSM (PCIe card): This is a cheaper product compared to network-attached HSMs. It is worth noting that these types of solutions require greater processing power to run multiple applications simultaneously.

Certification:

• Certifications – One of the biggest areas of false interpretation. If you are buying a FIPS 140-2 level 3 certified product, it has to switch to so-called FIPS mode. FIPS mode means a restriction on API level, a restriction on algorithms (key length, usage, key attributes, etc.) Ask yourself the question: Which level do you actually need? What do you need for regulatory reasons?
  • FIPS 140-2: Certification schema by NIST under the CMVP. This framework is useful as it provides confirmation that the NIST-approved algorithms are working normally and that its implementation has passed a runtime known answer test. Regarding physical security, a FIPS 140 certificate with level 3 security tells you that a product fulfils the physical protection baseline, but no more than that!
  • Common criteria: Product evaluations can vary more in terms of providing assurance: Read the Security Target! At the moment, there is only one decent set of HSM Protection Profiles, so you are going to have to read the Security Problem Definition (threats and assumptions) at the very least, to give you an idea of what the evaluation is providing.
  • Other Certification Schema: Like PCI-HSM or DK approval, these schemas will be useful if you are in the relevant industry.
    In addition to the certifications, ask for references specific to your relevant industry sector or to government space. Don’t just rely on talk of ISO certification software development lifecycles.

Soft factors:

• What support does the vendor offer? Don’t just consider the different types of options; ask about reputation and for some tests!
• What kind of integration services does the vendor offer? If you have complex requirements, it might be worthwhile involving the vendor in your configuration/programming process.
• What does the roadmap look like? Is there an issue you might know of that will arise in years to come?
• What is the country of origin (design and manufacture)?

One final important factor to consider:

Cost: What about the cost per unit(s)? What about the cost for support and maintenance? What is included in the unit pricing? Do you pay per API, etc.?
Lead time. Be realistic! If you feel you need an HSM immediately, you are probably underestimating the complexity of an HSM. HSMs are not mass produced; a certain amount of time is required to manufacture HSMs to ensure quality.