Blog - Cryptomathic

Key Management and use cases for HSMs

Written by Asim Mehmood & Chris Allen | 17. November 2017

The rise of e-commerce enabled corporate organizations and banks to more easily expand their businesses and services around the world.

Online services, like e-banking, raise the need for encryption, decryption and strong authentication between identities and applications. For these purposes, enterprises deploy HSMs for the protection of clients and business transactions.

Hardware Security Modules

A Hardware security module (HSM) is a dedicated hardware machine with an embedded processor to perform cryptographic operations and protect cryptographic keys. Keys in the field of cryptography are analogous to the physical keys that lock a door. Appropriate management of cryptographic keys is essential for the operative use of cryptography. A crypto key passes through a lot of phases in its life such as generation, secure storage, secure distribution, backup, and destruction. An HSM is used explicitly to guard these crypto keys at every phase of their life cycle. Logical and physical security of cryptographic keys from adversaries and unauthorized practice is managed by HSMs.

HSM Compliance

A governing body within the payments industry named PCI SSC (Payment Card Industry Security Standards Council) was established in 2006 and designed a standard which includes a complete set of requirements for securing HSMs. The latest version 3.0 of the standard “Payment Card Industry PTS HSM Modular Security Requirements” was released in June 2016. These HSM security requirements are extracted from already existing ISO, ANSI, and NIST standards; and accepted/known good practice recognized by the financial payments industry.

Best Practices and uses for HSMs

The usage of HSMs can provide enhanced cryptographic throughput and results in a more secure and efficient architecture for your solution. The HSM becomes an invaluable component of the security solution, which not only minimizes business risks but also achieves state-of-the-art performance in cryptographic operations.

A security control is only effective if applied with the correct and proper understanding. Similarly, an HSM provides “foolproof” security for key management if the solution architecture design, application level implementation, security analysis, user education and security policy of the product are given proper research and considerations.

The following are some best practices and use cases for HSMs currently followed by security professionals all over the globe:

    1. Storage of CA Keys: The security of CA keys is most critical in a PKI (Public Key Infrastructure). If a CA key is compromised, the security of the whole infrastructure is at stake. The CA keys are mostly stored on dedicated HSMs to provide tamper and disclosure protection from unauthorized entities. A normal CA deployment consists of a root CA and an issuing or Sub CA. The root CA is always kept offline and never connected to any network. The issuing/Sub CA is kept online and responsible for all certificate and key management. A high level of physical controls and security mechanisms are deployed for the protection of Root and Sub CA servers.
    2. Storage of Application Master Keys: Cryptography, while essential in many cases and also helped considerably by the powerful performance of HSMs, can be a rate-limiting factor in your business process. This can be a result of either latency (how long do *you* have to wait for a single transaction) or throughput- how many people can be serviced per second. HSMs do an amazing job of minimising any performance hit from the use of Asymmetric (public key) cryptography since they are optimized for these algorithms (and the data needed is never very large) however, it is still more effective to use the CPU for any bulk (symmetric) encryption (while acknowledging the security vulnerability of doing this). Some applications employ this hybrid architecture where the HSM directly protects the master keys (asymmetric, like RSA) and indirectly protects the bulk encryption keys (symmetric, like AES). A prime example of this is database encryption (where high latency per transaction cannot be tolerated).
    3. Storage of All Application Keys: HSM manufacturers have been paying attention to their bulk encryption performance over the last few years and the difference is not so marked now, to the extent that it has become feasible for an HSM to protect all the keys for all but the most latency-sensitive of applications.
    4. TRNG based onboard secure key generation: HSMs incorporate TRNGs (True Random Number Generators) which generate real-time random numbers based on thermal, avalanche and atmospheric noises. These random numbers are used as seeds for the secure generation of cryptographic keys. The security of keys and algorithms is mainly dependent on these random numbers. If the random number generator is predictable or weak then the whole key/algorithm is cryptographically weak.
    5. Onboard secure key management: HSMs deliver the highest level of security because the usage of cryptographic keys is always performed in hardware. The HSMs are secure and tamper resistant devices to protect the stored keys. No whole key can be extracted or exported from an HSM in a readable format.
    6. Offloading crypto operations: Cryptographic operations are sometimes time-consuming and can slow down the applications. HSMs have dedicated and powerful crypto processors which can simultaneously carry out thousands of crypto operations. HSMs can be effectively used by offloading cryptographic operations from application servers.
    7. Communication with HSMs: As the HSM stores the most sensitive type of material (crypto keys), the access control mechanisms and workflows for the communication with HSM must be highly secure. The most well-known, commonly used and industry accepted standard for this purpose is PKCS #11. The PKCS #11 standard “PKCS #11 Cryptographic Token Interface Base Specification” was designed by RSA Labs in 1994 and the latest version (2.40) released in April 2015, is jointly designed by RSA Labs and OASIS. The PKCS #11 is one of the more focused technical standards that specify detailed requirements for standard public-key cryptographic functions and their platform-independent programming interfaces. It defines a platform-independent API to cryptographic tokens, such as HSMs and smart cards. All organizations which provide HSMs implement support of the PKCS #11 standard. The API is available as DLL file for Microsoft Windows-based deployment environments and SO files for Linux based environments. The API has an implementation of the most frequently used symmetric and asymmetric tokens/keys (DES/Triple DES, AES, RSA, DSA etc. keys and X.509 digital Certificates) and most commonly used encryption/decryption and hashing algorithms required to generate, change and discard these crypto tokens.
    8. Full Audit and Log traces and Multi-party User Authorization: HSMs must maintain log/record the order of crypto operations such as key management, encryption, decryption, digital signing and hashing according to the date and time at which the operation was carried out. The process of logging or recording the events involves the authenticity and protection of time source. The modification of date time settings interface requires strong authentication by a smart card or at least two persons to sanction or authorize this task.
    9. Zeroization of Keys: HSMs follow hard and severe design requirements. The most important material for an HSM is the key. In case of success of a physical or logical attack, HSMs zeroizes or erases all its keys so that they don’t fall into bad hands. The HSM (depending on its level of security) should “zeroize” itself (erase all sensitive data) if it detects physical tampering, for example, by means of physical penetration, anomalous electrical activity or anomalous temperature. This is to prevent an adversary who has gained physical access to the hardware from retrieving the keys protected within.
    10. FIPS 140-2 Validation: FIPS 140-2 is a device security standard to approve cryptographic modules such as HSMs and smart cards. It defines four levels of the security compliance of the HSM and is named from “Level 1” to “Level 4”. FIPS validation is not a benchmark for the product perfection and efficiency. It simply means that some rational standard security examinations were carried out on HSM by technical professionals at FIPS qualified testing sites.
    11. Support of Cryptographic Algorithms: The proper approach to incorporate security services for applications and protocols dealing with data security is the use of cryptographic methods. A lot of public/open source and proprietary algorithms are available. HSMs provide a lot of choices in the use of cryptographic mechanisms. This may include open source and proprietary or indigenous algorithms. Open source algorithms are public and have undergone stress testing and security analysis and should always be preferred. Adoptions of obsolete or less known/indigenous algorithms may result in a security breach of data and information. It is important that the HSM is properly configured not to use the proprietary algorithms in this case.

Key Management for HSMs

It has been often said that the hardest part of cryptography is key management. This is because the discipline of cryptography is a mature science where most of the major questions have been dealt with (although we are at an extremely interesting point in time- the dawn of the quantum computing age- where a whole new raft of questions will become relevant) whereas the discipline of key management is a relatively immature art, subject to individual design and preference rather than objective fact. An excellent example of this is the extremely diverse approaches that HSM manufacturers have taken to implement their key management with some ensuring that the keys never leave the physical confines of the HSM (secure but completely impractical since the HSM takes the keys down with it upon failure) and others allowing for key export (safely encrypting the keys before doing so (!)). In addition there have been many cases where HSM manufacturers have allowed some very insecure practices to go unchecked resulting in the possible export of key material - often as a result of poor design of an independent key management system (such as PKCS11- a very common standard).

So, when looking for a general purpose, secure, full key life-cycle management system, it is wise to inspect those that have an impeachable pedigree (excellent customer references and lengthy deployment lifetime at least 10 years in production). Each year, the list of providers of such systems gets shorter and shorter since it is a niche market and only the strongest survive.

References and Further Reading

Image: "Roaring", courtesy of dynamosquito, (CC BY-SA 2.0)