Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 45 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
A Hardware Security Module (HSM) is a physical computing device that safeguards and manages cryptographic secrets (primarily digital keys), performs encryption/decryption operations, generates digital signatures, and provides strong authentication through tamper-resistant hardware that isolates cryptographic operations from potentially compromised host systems.
A Hardware Security Module (HSM) is a dedicated physical computing device designed to provide the highest level of protection for cryptographic key material and cryptographic operations. Unlike software-based key management solutions that rely on operating system security, HSMs implement security at the hardware level through physical tamper-resistance, secure key storage in dedicated hardware, and isolated execution environments for cryptographic operations.
In the context of KERI (Key Event Receipt Infrastructure) and the broader vLEI (verifiable Legal Entity Identifier) ecosystem, HSMs serve as critical infrastructure components for protecting the most sensitive cryptographic operations, particularly for high-value identifiers such as GLEIF Root AIDs, QVI (Qualified vLEI Issuer) identifiers, and enterprise autonomic identifiers requiring the highest security assurance levels.
HSMs provide comprehensive key lifecycle management with hardware-enforced security boundaries:
Key Generation: HSMs generate cryptographic key pairs using hardware-based CSPRNG (Cryptographically Secure Pseudorandom Number Generators) that provide information-theoretic security. The entropy sources are typically hardware-based (thermal noise, quantum effects) rather than software-based, providing stronger randomness guarantees. For KERI implementations, this means can be created with keys generated in HSM-protected environments, ensuring the begins with maximum cryptographic strength.
When selecting HSMs for KERI implementations, prioritize:
Direct Integration: Application code calls HSM APIs directly for each cryptographic operation. Provides maximum security but requires careful error handling and session management.
Abstraction Layer: Create a key management abstraction that can use HSMs, TEEs, or software keys interchangeably. Enables testing with software keys and production deployment with HSMs without code changes.
Proxy Pattern: Deploy an HSM proxy service that handles HSM communication, allowing multiple applications to share HSM resources while maintaining access control.
Session Pooling: Maintain persistent HSM sessions rather than opening/closing for each operation. Session establishment has significant overhead.
Batch Operations: Where possible, batch multiple signing operations into single HSM calls to reduce round-trip latency.
Caching: Cache public keys and non-sensitive metadata to avoid repeated HSM queries. Never cache private keys or signatures.
Async Operations: Use asynchronous HSM APIs to prevent blocking application threads during cryptographic operations.
Access Control: Implement strict role-based access control at both HSM and application levels. Use separate credentials for key management vs. signing operations.
Audit Logging: Enable comprehensive HSM audit logging and integrate with SIEM systems. Monitor for unusual patterns (excessive failed authentications, unexpected key operations).
Network Security: For network-attached HSMs, use dedicated VLANs, mutual TLS authentication, and IP whitelisting. Consider HSM-specific firewalls.
Key Storage: Private keys never leave the HSM in plaintext form. The hardware enforces that private key material remains within the tamper-resistant boundary throughout its lifecycle. Keys are stored in encrypted form using hardware-protected master keys, and the HSM's firmware prevents extraction even by privileged administrators. This property is critical for KERI controllers managing high-value identifiers where key compromise would have severe consequences.
Key Rotation and Pre-rotation: HSMs can securely manage KERI's pre-rotation mechanism by generating and storing next-key material in isolated hardware. The pre-rotated keys remain unexposed until the rotation event occurs, providing quantum-resistant security properties. The HSM can maintain both current signing keys and pre-committed rotation keys in separate hardware-protected key slots.
Digital Signature Generation: HSMs perform digital signature operations entirely within the hardware boundary. For KERI key events, this means the signing operation for establishment events and interaction events occurs in hardware, with only the resulting signature exiting the device. The private key never enters system memory where it could be compromised by malware or side-channel attacks.
Signature Verification: While less security-critical than signing (since verification uses public keys), HSMs can also perform signature verification operations. In KERI witness or watcher implementations, HSMs could verify incoming key event signatures, though this is typically performed in software for performance reasons.
Encryption and Decryption: HSMs support symmetric and asymmetric encryption operations. For KERI implementations using CESR (Composable Event Streaming Representation) with encrypted payloads, HSMs can perform the encryption/decryption operations while keeping decryption keys hardware-protected.
Hash Function Computation: HSMs implement cryptographic hash functions (Blake3, SHA-256, etc.) used for creating SAIDs (Self-Addressing Identifiers) and digests in KERI event chains. While hashing is typically not security-critical enough to require HSM protection, some high-assurance implementations may perform all cryptographic operations in hardware.
Multi-Factor Authentication: HSMs enforce MFA (Multi-Factor Authentication) for administrative access and cryptographic operations. Typical authentication factors include:
For KERI implementations, this means that signing a critical rotation event for a GLEIF Root AID might require multiple authorized individuals to authenticate to the HSM before the signing operation proceeds.
Role-Based Access Control: HSMs implement granular access control policies defining which users or applications can perform which operations on which keys. A KERI implementation might configure:
Dual Control and Split Knowledge: High-security HSM configurations require multiple authorized individuals to jointly authorize sensitive operations. For example, rotating the keys for a QVI identifier might require three out of five authorized QARs (QVI Authorized Representatives) to authenticate simultaneously.
HSMs implement multiple layers of physical security:
Tamper Detection: Sensors detect physical intrusion attempts including:
Tamper Response: Upon detecting tampering, HSMs execute security responses:
For KERI implementations, this means that physical attacks on HSMs protecting witness infrastructure or controller keys will result in key destruction rather than compromise, forcing attackers to rely on duplicity detection mechanisms rather than stolen keys.
Tamper Evidence: HSMs use physical seals, coatings, and packaging that show visible evidence of tampering attempts. This enables detection of supply chain attacks or physical compromise during shipping or storage.
HSMs operate within specified environmental parameters and include protections against:
Rack-Mounted Appliances: Enterprise HSMs are typically 1U or 2U rack-mounted devices connected to data center networks. These provide:
For KERI infrastructure, network HSMs might protect:
Internal Cards: PCIe HSMs install directly into server motherboards, providing:
USB Tokens: Portable HSMs in USB form factor offer:
KERI implementations might use USB HSMs for:
HSM-as-a-Service: Cloud providers offer HSM services where:
For KERI implementations, cloud HSMs enable:
Important Security Consideration: Cloud HSMs introduce trust assumptions about the cloud provider's physical security and operational practices. The vLEI Ecosystem Governance Framework specifies requirements for HSM deployment models based on identifier security requirements.
When creating a new AID with HSM-protected keys:
The derivation code in the AID prefix indicates the cryptographic algorithm (e.g., Ed25519, ECDSA secp256k1) but does not reveal whether keys are HSM-protected. This maintains privacy about the controller's security infrastructure.
For key rotation with HSM protection:
The HSM enforces that rotation events can only be signed by keys authorized in the previous establishment event, preventing unauthorized rotations even if the HSM is compromised at the API level.
Witness Signing: Witnesses use HSMs to sign receipts for observed key events. The witness AID's private keys remain in the HSM, preventing compromise even if the witness host is breached. The KAWA (KERI's Algorithm for Witness Agreement) consensus mechanism benefits from HSM-protected witness identities that cannot be impersonated.
Watcher Key Protection: Watchers operating in promiscuous mode may use HSMs to protect their own identities and signing keys, though the keys they are watching (other AIDs) are public information.
HSMs support KERI multi-sig configurations:
Threshold Signatures: For a multi-sig AID requiring M-of-N signatures, each of N key holders can use separate HSMs. The signing threshold is enforced at the KERI protocol level, while each HSM enforces that its individual key cannot be misused.
Distributed Key Generation: Some HSM implementations support distributed key generation protocols where multiple HSMs jointly generate key shares without any single HSM ever holding the complete private key. This provides additional security for high-value identifiers.
Hierarchical Deterministic Keys: HSMs can implement HD key derivation for KERI, allowing a single master seed in the HSM to derive multiple child keys for different purposes (signing, rotation, delegation) while maintaining a single backup requirement.
HSMs address multiple attack vectors:
Memory Scraping: Since private keys never enter host system memory, malware cannot extract them through memory dumps or process inspection.
Side-Channel Attacks: HSM hardware implements countermeasures against:
Physical Attacks: Tamper-resistant enclosures and zeroization mechanisms protect against physical key extraction attempts.
API-Level Attacks: While HSMs protect key material, they must expose APIs for cryptographic operations. Attackers with API access can:
KERI's duplicity detection mechanisms provide defense-in-depth: even if an attacker gains API access to sign unauthorized events, the witness network and watchers will detect conflicting events.
Supply Chain Attacks: HSMs could be compromised during manufacturing or shipping. Mitigation strategies include:
Insider Threats: Authorized HSM administrators could potentially abuse their access. Controls include:
HSMs provide partial protection against quantum computing threats:
Current Protection: HSMs protect private keys from quantum attacks because the keys never leave the hardware. Even with a quantum computer, an attacker cannot break encryption protecting keys inside the HSM without physical access.
Algorithm Transition: HSMs can be updated to support post-quantum cryptographic algorithms. KERI's crypto-agility through derivation codes allows smooth transition to quantum-resistant algorithms as HSM firmware is updated.
Pre-rotation Advantage: KERI's pre-rotation mechanism provides quantum resistance even with current algorithms, since pre-rotated keys are hidden and can be quantum-resistant algorithms even if current keys are not.
HSM operations introduce latency compared to software cryptography:
Network HSMs: API calls over network add 1-10ms latency per operation PCIe HSMs: Lower latency (microseconds) but still slower than CPU-based crypto Throughput: Enterprise HSMs handle thousands of operations per second, but this is orders of magnitude slower than software implementations
For KERI implementations:
HSM costs vary significantly:
Enterprise HSMs: $10,000-$50,000+ per device USB Tokens: $50-$500 per device Cloud HSM Services: $1-$2 per hour plus per-operation fees
The vLEI Ecosystem Governance Framework specifies HSM requirements based on identifier criticality:
HSM key backup requires careful procedures:
Key Escrow: Some HSMs support encrypted key export for backup, protected by:
Disaster Recovery: Organizations must balance:
For KERI, the pre-rotation mechanism provides an additional recovery option: if current keys are lost but pre-rotated keys are backed up separately, control can be recovered through rotation.
HSMs are certified under various standards:
FIPS 140-2/140-3: U.S. federal standard with four security levels:
The vLEI Governance Framework specifies minimum FIPS levels for different identifier types.
Common Criteria: International security evaluation standard (EAL1-EAL7)
PCI HSM: Payment Card Industry requirements for payment processing
eIDAS: European Union requirements for qualified electronic signatures
TEEs like Intel SGX, ARM TrustZone, or AMD SEV provide software-based secure enclaves:
Advantages over HSMs:
Disadvantages compared to HSMs:
The vLEI framework allows TEEs as an alternative to HSMs for some use cases, particularly for witness infrastructure where cost and performance are critical.
TPMs are simpler hardware security devices:
Similarities to HSMs:
Differences from HSMs:
TPMs are suitable for protecting individual controller keys on personal devices but not for high-volume infrastructure like witnesses.
MPC protocols distribute key material across multiple parties:
Advantages:
Disadvantages:
KERI's native multi-sig support can be enhanced with MPC, where each participant uses an HSM to protect their key share.
When implementing KERI with HSM protection, consider:
Security Requirements:
Performance Requirements:
Operational Requirements:
Integration Requirements:
Key Ceremony Procedures: Document and follow formal procedures for:
Separation of Duties: Implement organizational controls:
Defense in Depth: Combine HSM protection with:
Testing and Validation: Before production deployment:
Hardware Security Modules represent the highest level of cryptographic key protection available for KERI implementations. By providing tamper-resistant hardware, isolated cryptographic operations, and comprehensive key lifecycle management, HSMs enable organizations to deploy high-value identifiers with confidence that key material is protected against a wide range of attacks.
The integration of HSMs with KERI's pre-rotation mechanism, witness infrastructure, and duplicity detection creates a defense-in-depth architecture where even HSM compromise does not necessarily result in identifier compromise. The vLEI Ecosystem Governance Framework provides clear guidance on when HSM protection is required versus when alternative technologies like TEEs or software-based key management are acceptable.
As KERI adoption grows and high-value use cases emerge (enterprise identity, financial credentials, government identifiers), HSM integration will become increasingly important for meeting security and compliance requirements while maintaining the decentralized, portable nature of KERI identifiers.
Physical Security: Ensure HSMs are deployed in physically secure data centers with access controls, video surveillance, and environmental monitoring.
Backup Strategy: Implement M-of-N key splitting for HSM backups where multiple custodians must cooperate to restore keys. Store backup materials in geographically separate secure locations.
Failover Configuration: Deploy HSM clusters with automatic failover for high-availability requirements. Test failover procedures regularly.
Key Ceremony Documentation: Document all key generation, backup, and recovery procedures. Conduct regular drills to ensure procedures remain current and staff are trained.
Development: Use software HSM emulators (SoftHSM) for development and testing. These provide PKCS#11 compatibility without hardware costs.
Staging: Deploy actual HSMs in staging environments to test performance, failover, and operational procedures before production.
Production: Implement comprehensive monitoring and alerting for HSM health, performance, and security events.
Key Handle Management: Carefully track HSM key handles and slots. Losing track of which keys are in which slots can lead to operational failures.
Session Timeouts: HSM sessions may timeout during long-running operations. Implement session refresh and retry logic.
Firmware Updates: HSM firmware updates may require downtime and key backup/restore. Plan maintenance windows carefully.
Vendor Lock-in: Different HSM vendors have incompatible key formats and APIs. Design abstraction layers to enable vendor migration if needed.
Cost Management: Cloud HSM services charge per operation. Monitor usage and optimize to avoid unexpected costs at scale.