• About Us

  • Blog
  • Contact
Blog Security White Paper: Hardware Security Modules



DECEMBER 14 2023


Ilia Muravev

Table of Contents

Hardware Security Modules


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.

1. HSM

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:

  • Sensitive key data are located on server memory during operations;
  • Core dumps can reveal sensitive data;
  • Stored key data is only as secure as the passphrase (if any) protecting it.


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.

2. Entrust Security World

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.

Entrust Security World

The same Security World structure is often loaded onto multiple HSMs:

  • This allows HSMs in the same group to share keys with each other;
  • The same group of cardholders administers all of the integrated 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:

  • Configured to match the security policies of the business (or application);
  • Administered by a single group of cardholders.


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.

2.1 OCS and ACS

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:

  1. AES  (Advanced Encryption Standard) Keys are generated – aka the Master key;
  2. Master key splits to ACS (Administrator Card Set);
  3. World key is sent to EEPROM(Electrically Erasable Programmable Read-only Memory) on HSM;
  4. The world key is encrypted by the Master key and stored on host server.


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.

2.2 Remote File System

A Remote File System (RFS) is required by each nShield Connect.

Remote File System

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.

2.3 Security World Benefits

  1. No upper limit for quantity of keys you can protect;
  2. Destruction of HSM doesn’t provide any lost cryptographic objects;
  3. Each key can be protected by a different password or smart card;
  4. Scalability;
  5. Increased resilience;
  6. No single point of failure.

2.4 Security World Weaknesses

  1. All clients of the specific Security World see all existing keys in the structure;
  2. No option to create different client role hierarchy – all clients are operators;
  3. An unauthorized client can remove a keyblob from Security World.

3. SafeNet Luna Partitions

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.

SafeNet Luna Partitions

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.

3.2 Layered Encryption

HSM contains various domains, each domain encrypted by a separate key.

  • The Key Encryption Key (KEK) encrypts every key being used to ensure that your keys are never shown in plaintext. KEK is unique to each HSM and encrypts everything that is encrypted by the PinKey.
  • PinKey is a password or secret retrieved from the PED (PIN Entry Device). This key protects the client’s keys.
  • The General Storage Key (GSK) protects general storage objects.
  • The User Storage Key (USK), for each role, protects the content of the partition accessed by that role.
  • The Master Tamper Key (MTK) encrypts each object generated and stored within the HSM.


The flow of decryption is:

  1. KEK
  2. PinKey
  3. GSK or USK
  4. MTK

3.3 SafeNet Luna Benefits

  1. Multi-tenancy with strong access control;
  2. Vast role system;
  3. Better performance;
  4. Backend for CloudHSM.

3.4 SafeNet Luna Weaknesses

  1. Capacity limitations;
  2. Access control to partition, not to keys themselves;
  3. Requires additional HSM for backup.


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.


5. API

Applications use HSM by a standardized interface: PKCS11, JCE, MS Crypto API\CNG, OpenSSL, Vendor-specific API.

  • PKCS11 – an industry standard for various languages.
  • JCE – Java Crypto Provider.
  • MS Crypto API\CNG – used in Microsoft operational systems.
  • Open SSL engine.
  • Vendor-specific API – use Vendor-specific HSM on 100%.

6. Custom Firmware

6.1 nShield HSM

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.


6.2 Luna HSM

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.

6.3 ProtectServer 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.

Functionality Module

8. Roles

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

9. Backup

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.

10. Performance

HSM Stat Comparison