Key Management and use cases for HSMs

With the rise of e-commerce, corporations and banks were able 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

HSMs can improve cryptographic throughput, resulting in a more secure and efficient architecture for your solution. The HSM becomes an invaluable component of the security solution, minimising business risks while also achieving cutting-edge performance in cryptographic operations.

A security control is only effective if it is used correctly and correctly. Similarly, an HSM provides "foolproof" key management security if the product's solution architecture design, application level implementation, security analysis, user education, and security policy are thoroughly researched and considered.

The following are some best practises and use cases for HSMs that are currently being used by security professionals around the world:

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: While cryptography is necessary in many cases and is greatly aided by the powerful performance of HSMs, it can be a rate-limiting factor in your business process. This can be due to latency (how long must *you* wait for a single transaction) or throughput (how many people can be served per second). Because they are optimised for these algorithms (and the data required is never very large), HSMs do an excellent job of minimising any performance hit from the use of Asymmetric (public key) cryptography; 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 use a hybrid architecture in which the HSM protects the master keys directly (asymmetric, like RSA) and the bulk encryption keys indirectly (symmetric, like AES). Database encryption is a prime example of this (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 in recent years, and the difference is no longer so noticeable that an HSM can protect all keys for all but the most latency-sensitive applications.
4. TRNG based onboard secure key generation: TRNGs (True Random Number Generators) are used in HSMs to generate real-time random numbers based on thermal, avalanche, and atmospheric noises. These random numbers are used as seeds to generate cryptographic keys in a secure manner. These random numbers are crucial to the security of keys and algorithms. The entire key/algorithm is cryptographically weak if the random number generator is predictable or 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 impeccable 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

• Selected articles on Key Management (2012-16), by Ashiq JA, Chuck Easttom, Dawn M. Turner, Guillaume Forget, James H. Reinholm, Matt Landrock, Peter Landrock, Steve Marshall, Torben Pedersen, Maria Stokes, John Trankenschuh and more 
• NIST Special Publication 800-57 Part 1 Revision 4 Recommendation for Key Management Part 1: General (2016), by Elaine Barker, Computer Security Division Information Technology Laboratory, National Institute of Standards and Technology
• “Cybersecurity Incidents What Happened.” (2016), the United States Office of Personnel Management.

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