Even in small-scale environments, managing cryptographic relationships and crypto key lifecycles can be difficult. The list of barriers to success can become overwhelming for CISOs and IT Security Professionals who work in the world of international crypto architectures, such as those found in banking and finance.
The good news is that with a clear understanding of the relationship and communication between Hardware Security Modules (HSMs) and Key Management Systems (KMSs), protecting your mission-critical business applications may be easier than you think.
Relating KMSs to HSMs
The generation, protection, rotation, distribution and eventual retirement of keys, collectively known as the “key lifecycle”, must be handled with the utmost care, especially keys used to protect particularly sensitive or valuable data (e.g. credit card data, financial transactions, etc.).
Modern key management systems are built for this purpose, allowing keys to be managed pro-actively throughout their entire lifecycle. A key management system (KMS) is typically a server (administered via a remote PC client) that acts as a centralised hub, controlling the lifecycle of keys and securely handling both outbound (Push) and inbound (Pull) key distribution requests. Key management systems also keep secure audit logs to track keys for security and compliance reasons. A KMS server should be backed up by its own dedicated HSM to allow the key management team to securely administer the lifecycle of keys. This ensures that the keys managed by the KMS are appropriately generated and protected.
HSMs are specialized cryptographic hardware devices that are independently certified to standards such as FIPS 140-2, Common Criteria or PCI-HSM. An HSM acts as the trusted source for strong cryptography and key generation and provides the logical and physical protection necessary to protect sensitive keys as well as performing the appropriate cryptographic functions for applications/systems that rely on strong crypto. For example, when an HSM executes a cryptographic operation for a secure application (e.g. key generation, encryption or authentication), it ensures that the keys are never exposed “in-the-clear” outside the secure environment of the HSM.
When the KMS needs to generate keys and distribute key information, it interacts with its dedicated HSM to generate, retrieve, encrypt, and share the keys to the authorized target (secure application server or another HSM). This communication is typically governed by the PKCS #11 standard which provides the requirements for this interaction. The result is a set of standard APIs that are used to ensure secure interaction between the KMS and HSM.
HSMs are also commonly thought of as key management systems in their own right. In this scenario, the HSMs are dedicated to protect the keys of a particular application/system and to offload cryptographic processing from the application server. HSMs, however, are not very easy to administer when it comes to managing the lifecycle of the keys. This is not really a problem with a singular location, but when multiple locations and applications come into play, the challenges to maintain security and compliance can grow exponentially. This is where a centralized KMS becomes an ideal solution.
In short, a key management system is used to provide streamlined management of the entire lifecycle of cryptographic keys according to specific compliance standards, whereas an HSM is the foundation for the secure generation, protection and usage of the keys. There are numerous systems/applications within a financial services organisation that require their own dedicated HSM(s) for a root of trust. A centralized key management system should be capable of managing the lifecycle of the application keys that are used and protected by these HSMs throughout the organisation.
Centralized KMS for Improved Overview and Efficiency
When dealing with a large IT infrastructure, the first challenge is dealing with the sheer volume of online applications and the resulting volume of cryptographic keys that must be managed. Banking and finance organisations that interact on a global scale will have to deal with hundreds of applications and a plethora of sensitive keys that are spread across multiple business units and geographical locations.
One of the primary goals of a key management system is efficient operation and optimisation. Managing, tracking, and updating application keys across a distributed network can be time-consuming and costly for a bank or government organisation. This necessitates a thorough understanding of which of the network's many keys require attention. Administrators must then locate exactly where the keys are stored and travel to each location to manually update the keys (this also requires gaining access to the hardware/system that stores the key) in the absence of a centralised overview and automated processes.
Using a centralised key management system, this process can be managed centrally from a secure operations venue with multiple and securely authenticated users, each with their own authorised administrative role. System administrators or operators can update or configure these keys on each application with a single click - even from another continent.
Integration with HSM Targets for Automated Key Updates
Another significant challenge of key management in large international environments is dealing with a diverse range of target applications and HSMs, where key material in various formats must be shared or updated on individual systems. In order to effectively manage the key lifecycle for the systems/applications that use the keys, your centralised KMS must be able to seamlessly integrate and communicate with these external HSMs. Listeners can be used as part of a centralised KMS solution to overcome this barrier.
Such Listeners are software components that are deployed between the CKMS server and the target HSMs or key target. Their role is to allow keys to be automatically pushed to the HSMs. They are also capable of interacting with a range of key targets such as the Java Key Store, Microsoft Certificate Store and cloud applications for BYOK.
Since the listener sits between the centralized KMS and the target HSM, it will receive encrypted key information directly from the KMS server. It will then make this information available to the target HSM utilizing a predefined distribution interface. This distribution interface might consist of password-protected user accounts, master key encryption and integrity protected settings and logs. This ensures that information regarding the key is never available unencrypted outside of the HSM.
When these Listeners are deployed, there is a one-time initialization process that is required as part of the setup. This involves the manual exchange of a Root Key Encryption Key (Root KEK) in order to establish a trust channel between the Central KMS and the HSM. Once this setup process is completed, keys can be pushed, updated, and deleted as necessary.
Benefits of Centralized Key Management
Large international structures need the ability to handle large volumes of keys and the integration with a wide range of secure applications / HSMs. A Centralized KMS structure with proper communication with HSMs will certainly achieve this objective. In addition, these large organizations will benefit from the significant efficiency aspects of centralized key management. This includes reduced overhead to manage the infrastructure as well as streamlined processes and procedures - while reducing exposure to the risk of audit and compliance failures.