blog-how-to-select-an-hsm-stage

How to select an HSM

  As the choice of Hardware Security Module is dependent on the specific application it is used for, in this article some general recommendations are provided by outlining a list of potential criteria to consider, irrespective of what you intend to use the HSM for.

Implementation services

What kind of implementation services does the vendor offer?

When analyzing various HSM vendors, it is worth considering their portfolio and assistance during implementation. First of all, make sure a vendor offers a diverse range of HSM solutions and supports all kinds of applications. A wide range of general purpose and payment applications allows you to support any combination of firmware and software options across different deployment models (on-premises, cloud and hybrid). This will help you choose a solution that fits your company needs.

Did you know?
The latest Hardware Security Module OEM competitive assessment by ABI Research, announced Utimaco as the ‘Top Implementer’ in the HSM market. The Utimaco portfolio provides the most comprehensive and diverse range of solutions, serving all types of applications, at all price points (from entry-level to top-of-the-line), and in various form factors. According to the report - ‘It is possible because Utimaco has worked from the basis of building a uniform underlying hardware platform upon which various (and multiple) firmware stacks and software options can be added, and which include cloud ready Application Program Interfaces (APIs)’.

Technical factors

Technical factors

Consider the following:

  • 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, enquire 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:

1. Microsoft MS CSP/CNG: The Microsoft “standard” API is the easiest way to connect to an HSM when using Windows;

2. JCE: The “standard” Java developer.

3. PKCS#11: The “industry standard”, but there are some pitfalls such as known security issues and vendor proprietary extensions. 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 vendors.

Software and Serviceability

Software and Serviceability

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 management 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 physical, 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)?
Architecture & Deployment

Architecture & Deployment

Hardware Security Modules can be operated on premise, hosted or as a service from the cloud.

On-premise deployments provide the following options:

  • Network-attached HSM: for larger-scale deployments, particularly where multiple applications/servers/clients need to utilize HSM services.
  • Embedded HSM (PCIe card): this is a more cost-effective solution compared to network-attached HSMs. It is worth noting that these types of solutions require greater processing power in order to run multiple applications simultaneously.
  • Scalable Containerized HSM: for true multi-tenant solutions (for example, in cloud platforms operating independent client accounts), allowing to run independent HSMs-deployments, policies and firmwares per container. We strongly advise against weak multi-tenant solutions operating with one single firmware or policy engine.

Hosted or as-a-service solutions

  • Hosted or as a service provides physically independent HSMs in the cloud: This solution offers the highest level of physical protection against unauthorized physical access and is ideally compliant with FIPS 140-2, level 4 per tenant. However, the scalability of such a solution is only on the level of locally deployed physical servers.
  • As-a-service solution which provides fully or partially managed shared HSMs. Management functions like key management could be part of the service solution or might be done by the customer on premise or in a different cloud.
  • As-a-service solution which provides tenants in containerized HSM, FIPS 140-2 level 3 protected per tenant. Such containers provide individual policies and firmware per tenant and provide the scalability advantages of the cloud. They are outside the cloud service provider’s (CSP) infrastructure and preserve the customer’s full control over their encryption requirements
  • Using the CSP’s HSM-Cluster: Allowing for benefit of the cloud platforms’ services (including AWS, Azure, Google Cloud). Control of the keys is limited.
Certification

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 fulfills 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 e.g. PCI-HSM, DK approval or NITES (Singapore CC 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.

Utimaco is able to offer HSM solutions which can be both PCI-HSM and FIPS 140-2 or 3 compliant (or none at all if not required).

Soft factors

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)?
End-of-Life Replacements

End-of-Life Replacements

When replacing an existing / end of life HSM, proprietary solutions may require the need for changes in all connected applications. The preferable solution would be the choice of a application-agnostic and crypto-agile HSM, which are able to:

  • Host relevant keys and key blocks
  • Connect to major key management systems
  • Connect to typical industry-grade apps with a documented application record

As a result, replacements in the frame of service cycles will be fast, without requiring much investment in time or human resources.

Important factors

Important factors

  • 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.

 

Leading the Way in the HSMs Market in 2022

Leading the Way in the HSMs Market in 2022

ABI Research* is a global technology intelligence company that provides actionable research and strategic guidance to global technology leaders, innovators, and decision makers. 

Utimaco is proud to have been ranked Overall Leader and Top Implementer in their Competitive Ranking for Hardware Security Module: Original Equipment Manufacturer.

Award Banner Overall Leader

 

According to the report - ‘No other HSM vendor currently offers this level of diversity, and Utimaco is unique in this regard’. 

Award Banner Top Implementer

 

When selecting your HSMs, why not choose the leader in the market, as awarded by ABI Research. Discover Utimaco’s portfolio here.

Verwandte Produkte

Verwandte Produkte

Wie können wir Ihnen helfen?

Sprechen Sie mit einem unserer Spezialisten und erfahren Sie, wie Utimaco Sie unterstützen kann.