Menu
Menu
VERSION 0.3
DATE:
DECEMBER 14 2023
AUTHOR:
Ilia Muravev
This paper introduces Hardware Security Modules. It describes their functions, architectures and implementations, as well as compares the pros and cons of different types of general use HSMs.
An HSM (Hardware Security Module) is a device that is specifically designed to protect cryptographic keys. The main idea behind HSM is to avoid the generation, usage, and storage of keys in an untrusted environment. Cryptographic client’s keys are created inside HSM using a certified hardware random number generator and encrypted by the module key. The module key is generated (or injected) when the HSM is initialized. The client keys never leave HSM as a plaintext value, nor are keys ever revealed in the clear on disk or memory. When the client uses a key, it can only access the reference to the key, rather than the value of the key itself.
HSM is a tamper-resistant device responsible for protecting keys against logical and physical attacks. Access to keys can be restricted using passphrases, USB keys, card sets, or passphrases.
This way HSM bypasses the main reasons software-only cryptography is vulnerable to key compromise:
HSMs implement one of two strategies of key storing: key in the box (SafeNet Luna, ProtectServer) or key out the box (nShield). Each strategy has its own pros and cons.
Entrust nShield HSM provides the concept of Security World. Security World creates a single security domain for keys and cryptographic objects that contain many HSMs and clients. All HSMs in the structure have the same module key, which makes it possible to use holder keys in any HSM from that particular Security World, however, not with the other unauthorized HSMs. Security Officer needs to load an existing module key in order to add a new HSM to the existing Security World structure.
The same Security World structure is often loaded onto multiple HSMs:
An HSM can only belong to one Security World at a time, although a Security World may contain many Hardware Security Modules and the host client machine could be a client of several nShield HSMs .
A Security World is an isolated security domain:
Encrypted Security World files can only be decrypted using the original encrypting module key. HSMs in other Security Worlds cannot understand the key token files in the \local directory, as they will have been encrypted using an entirely different module key.
Every key in the Security World is always protected by another key. The Security World either wraps the client key with the module key, or key is located on smart cards (Operator Card Set – OCS).
The wrapped application keys can then be stored on all authorized HSM clients meant to load the key into the integrated HSMs.
OCS is a 1 of N card or set K of N cards. There can be any number of OCS in a Security World as OCS can be created and deleted at any time.
Security World creation process:
The main ACS (Administrator Card Set) function is adding additional HSMs to the Security World. ACS quorum can reconstruct a root security world key. There is always only one ACS per Security Word, and it is created at the same time as the Security World.
A Remote File System (RFS) is required by each nShield Connect.
The Remote File System contains some extra directories which Connect uses for storing its configuration data (config and features) and log files. That’s also the location from which Connect reads files when loading the Security World or integrates a new nShield into the existing Security World.
The RFS resides on a server with the Security World software installed. A server is designated as an RFS before the HSM module configuration stage. The RFS can be situated on any server, however, typically a client server is chosen for this purpose.
A single RFS can serve multiple nShield Connects within a Security World domain, but there is only ever one RFS per Security World.
SafeNet Luna HSM implements a partition mechanism. Partitions allow the SafeNet Luna Network single physical HSM to be divided into several logical HSM partitions, each with independent data, access controls, and administrative policies.
Luna stores keys inside HSM, more specifically, keys are located in partitions. HSM Luna has two types of partition: one administrative and one or more application partitions.
The administrative partition is created by Security Officer when the HSM is initialized. This partition is used by the SO and Auditor and no keys are stored there. Instead, application partitions are used to store cryptographic objects. HSM holds one or more application partitions (independent virtual HSMs) that different users or clients can access. SO creates the application partition and clients configure and administrate the partition.
Multiple HSMs or partitions can be set to be a part of the same cloning domain. Key material cannot leave its cloning domain, therefore if an attacker were to try and copy your cryptographic material to a device that does not share a cloning domain with your HSM or partition, they would be unsuccessful. Using cloning domains ensures that key material can travel only between trusted and authorized devices. This adds a strong layer of defense against attackers. One Luna HSM can be shared between many clients (Host machines) and applications. Partitions are independent, and the application has access only to objects in its own partition.
Luna HSM doesn’t store any cryptographic objects in the clear. All objects are encrypted by multiple layers and are fully decrypted in temporary (volatile) memory only when needed.
HSM contains various domains, each domain encrypted by a separate key.
The flow of decryption is:
ProtecterServer is a convenient but limited HSM for applications operating like a PKCS11 provider. The client uses KeyStore, which is associated with Token. Each Token is protected by a password or OTP.
Applications use HSM by a standardized interface: PKCS11, JCE, MS Crypto API\CNG, OpenSSL, Vendor-specific API.
CodeSafe is a secure run-time environment within the certified HSM boundary, which gives an option to remove sensitive application/business logic from more vulnerable cloud or server environments.
The main idea is that we can load additional code that is executed inside the HSM (like a container). This computing platform is called SEE (Secure Execution Engine) machine. Only one SEE machine can be loaded to the HSM at a time.
While on the HSM, the CodeSafe App is isolated from other keys loaded onto the module: even the keys actively used in the App.
SEE machines run within the boundary of the HSM, code and memory are protected in the same manner as keys and can be signed and encrypted. Machines can accept input and provide output to the outside world. There are two options in the SEE machine: nCore API or designed protocol.
Functionality Module is custom-developed, customer-specific code that operates within the secure confines of HSM. FMs allow application developers to design security-sensitive program code that can be loaded into the HSM and operate as part of the HSM firmware. Luna supports Multi FMs. The FM may contain custom-designed functions that are in addition to the native command set of the HSM.
Same as Luna, ProtectServer also provides Functionality Module for developers to load their custom code into the HSM.
The custom application is executed on the host system. The application accesses patched PKCS#11 functions in the FM and the standard PKCS#11 functionality of the Cryptoki library provided in the firmware module. Only one patch PKCS11 function can be executed inside the HSM.
The nShield HSM has only two roles – Administrator and Operator – which are associated with their specific type of smart cards, Administrator Card Set and Operator Card Set.
SafeNet Luna has Security Officer (HSM initialization, global policy, Partitions creation, firmware), Auditor(logs), Partition Security Officer (initializes partition, creates CO credential), Crypto Officer (creates objects, backups, cryptographic operations, CU creation), Crypto User (initiatescrypto operation, creates public object).
ProtectServer roles: Security Officer (set the initial User PIN, reset Token), Token Owner (user, creates and uses public and private objects), Administration Security Officer (introduces the Administrator to the module), Administrator (HSM managment, HSM’s memory erasure, security policy adjustments).
nShield doesn’t provide any services for secure backup of keys. Keys are stored outside of the HSM in an encrypted form. Typically on folders: local(KM_DATA) or Remote File System(RFS). The backup process is initiated from the specific files on the hard disk.
Luna delivers Luna backups solution. The solution contains an HSM that allows secure backup partitions from the source HSM. This process requires PED.
ProtectServer provides PKCS11-like mechanism backup. For backup, the key should be wrapped and saved to external storage: a file or smart card.
