nShield Security World

As security teams adapt to evolving compliance mandates and data protection requirements, encryption usage continues to accelerate. 

HSMs are foundational to modern IT infrastructure. They enable secure key generation, storage, and management for cryptographic operations. But as encryption use cases grow, organizations must scale their HSM environments without inflating costs or operational complexity.

nShield HSMs, underpinned by the Security World architecture, provide the tools to scale while optimizing security and cost-effectiveness.

Security World allows application keys to be managed across multiple HSMs, enforcing consistent policy alignment without compromising key security.

Figure 1: In a Security World deployment, security teams can uniformly manage logical groups of HSMs.

Creating and Managing a Security World

A Security World domain is initialized on an nShield HSM, which generates a master key and creates a set of smart cards known as the Administrator Card Set (ACS).

The ACS is used to program the same Security World master key into additional nShield HSMs, effectively enrolling them into the same Security World domain. This enables security teams to:

• Expand cryptographic processing capacity
• Replace or redeploy HSMs as needed

These sensitive operations require quorum authorization by security officers possessing ACS credentials.

The Security World architecture is dedicated to the security of sensitive keys, including the keys that are employed within user applications. Application keys can include the following:

• Private signing keys (e.g., e-invoicing applications)
• TLS/SSL handshake keys
• Symmetric encryption keys (e.g., credit card encryption)
• Root of trust keys (e.g., for database encryption, PKI certificate authorities)
• Machine identities
• Privileged access management keys

The application key token consists of the following categories of components:

Key Material

Key material is composed of the encrypted application key (using AES 256-bit). Users can choose which encryption key to use, which determines the authorization method for the application key.

Certificates and Records of State

When HSMs produce a key, a key generation certificate is created, which is also included in the application key token. The public key that was used to sign the key generation certificate is also included.

At the moment the HSM generates the key, the HSM’s state is recorded, offering a granular record of control and ownership. The state information provides a complete picture of the HSM that generated the key, including its identity and provenance.

Each nShield HSM has a long-term fixed key that is generated when the HSM is manufactured and never changes throughout the life of the HSM. This key signs the state message and includes a certificate or “warrant” signed by Entrust. The key that signs the warrant is always under the exclusive control of Entrust, proving that the HSM that generated the key is a genuine nShield HSM.

Access Control Lists (ACLs)

ACLs are a critical component of the metadata included in the application key token. Within Security World, several mechanisms ensure the integrity and security of ACLs.

When a key is generated, its associated ACL is wrapped together with the key, ensuring that it remains as secure as the key itself. This ACL stays with the key throughout its lifecycle, providing consistent policy enforcement wherever the key is used.

Importantly, the application assigns the ACL at the time of key generation, and this assignment is a one-time operation. An encrypted copy of the key for inclusion in the key token can only be created once, during the same session in which the key is generated, adding an additional layer of security.

ACLs define what a key is authorized to do. These capabilities may include:

• Whether the key can encrypt or decrypt
• Whether the key can wrap other keys or be wrapped
• What level of authorization is required for specific operations

ACLs can also range in complexity:

• In simple scenarios, they might permit basic operations like data encryption
• In advanced setups, they can define hierarchical key relationships, where multiple keys must be loaded via their respective tokens before certain operations are allowed

Additionally, ACLs can enforce usage constraints, such as:

• Operation timeouts
• Limits on the number of permitted operations

Through ACLs, Security World allows granular control and fine-tuned security over how keys are used, shared, and governed.

Authorization Tokens

In Security World environments, authorization tokens are used to control access to specific application keys. When an application key is generated, it can be associated with an authorization token. As a result, that key cannot be loaded onto an HSM unless the correct authorization token is presented and successfully validated.

There are three types of authorization tokens in Security World:

1. Smart Card Sets: Smart card sets provide multi-factor, quorum-based authorization. Security teams can define how many smart cards exist in a set and how many must be present to approve specific actions.

For example, in an environment with five administrator smart cards, administrators might require that at least three cards be presented to authorize the addition of a new HSM to the Security World domain.

There are two categories of smart card sets in a Security World domain:

• Administrator Card Sets (ACS): Used to authorize administrative tasks, such as disaster recovery operations
• Operator Card Sets (OCS): Used to authorize HSMs to access and use application keys.

2. Softcards: Softcards are software-based tokens that offer single-factor authorization. They are especially useful in environments where physical access to HSM smart card readers is not practical.

3. Module Protected Keys: This option is appropriate if you want to use the HSM to protect your keys, This option is suited to applications where 24-hour operation and automation is required, since no human intervention is required to use application keys.

The method of key usage authorization – whether via smart card, soft card, or module-protected keys – is selected at the time the key is created and stored in Security World.

Customizable Authorization Policies

Security World gives administrators powerful flexibility when implementing key usage authorization policies:

• Choose between OCS or softcard protection for each application key
• When using OCS, administrators can configure:
  • Number of cards in the set
  • Quorum requirements (how many cards must be present to authorize an operation)
  • Passphrases for each card – or whether to require one at all
  • Whether cards must remain inserted in the nShield HSMs smart card readers or can be removed after use

These features offer an extremely versatile and secure framework for enforcing cryptographic key access policies, balancing ease of use, compliance, and strong security controls.

Through the capabilities outlined above, application keys can be securely encrypted, safely distributed, and stored outside of the HSM – even across multiple HSMs – without compromising their security.

By leveraging robust policy controls, including smart cards, HSM-level policies, ACLs, and other built-in mechanisms, security teams can enforce uniform security policies across their entire environment, while still retaining the flexibility to apply granular controls to specific HSMs, technology stacks, user groups, and more.

In Security World environments, raw key material is always protected by certified nShield HSMs. When application key tokens are saved to storage outside of the HSM, they can be safely backed up and restored using standard backup procedures.

Authorized client applications can then load these tokens onto any HSM within the same Security World domain to perform cryptographic operations, ensuring security, portability, and operational continuity.