Hardening HSMs for Banking-Grade Crypto Wallets

Hardening HSMs for Banking-Grade Crypto Wallets

Speakers: JP Aumasson, Shervine Majeri

Conference: Black Hat USA

YouTube: https://www.youtube.com/watch?v=HpQP3lMg3iw

Overview

In an era where digital assets represent significant value, the security of cryptographic keys underpinning these assets is paramount, especially for financial institutions managing billions of dollars. This talk, "Hardening HSMs for Banking-Grade Crypto Wallets," delivered by JP Aumasson and Shervine Majeri, delves into the critical role of Hardware Security Modules (HSMs) in safeguarding virtual money, including cryptocurrencies like Bitcoin, tokenized securities, and stablecoins. The presentation targets the high-assurance security needs of banks and large financial entities, offering practical, battle-tested strategies for deploying and hardening HSMs to protect these valuable assets.

The speakers, both from Taurus, a company specializing in hardware security for crypto assets, emphasize that while HSMs are foundational security components, their effective implementation requires a deep understanding of their internal mechanisms, potential attack surfaces, and robust hardening techniques. The core message revolves around reducing the attack surface of HSMs, ensuring secure key management throughout its lifecycle, and implementing stringent access controls. This research is vital for anyone involved in securing large-scale digital asset operations, providing a blueprint for achieving "banking-grade" security in the complex landscape of crypto finance.

Background

▶ Watch: Introduction: HSMs for banking-grade crypto assets (1:00)

The foundation of secure digital asset management lies in robust cryptographic practices, with key management identified as arguably the most challenging aspect of cryptography in practice. Hardware Security Modules (HSMs) emerge as the industry standard for addressing this challenge, offering a dedicated, tamper-resistant environment for cryptographic operations and key storage. According to NIST FIPS 140-3, a standard for cryptographic modules, an HSM is a specific type of cryptographic security module featuring hardware components designed to protect the entire crypto key life cycle. This cycle encompasses key generation (often from a Pseudo-Random Number Generator, PRNG), provisioning, configuration, storage, usage (e.g., encryption, decryption, signature, MAC), rotation, and eventual deletion.

HSMs provide various interfaces for interaction and administration. For cryptographic processing, common interfaces include PCI Express (for direct integration into a server) and, most predominantly, TCP/IP communication utilizing the PKCS#11 API. PKCS#11 is a widely adopted standard API for cryptographic tokens, enabling applications to interact with HSMs for key management and cryptographic operations. For administrative tasks, HSMs often expose interfaces such as SSH for command-line access, HTTP(S) for web-based management (with or without TLS depending on the model), and sometimes even a graphical user interface (GUI). Less commonly, USB connectivity might be present but is typically not used for high-volume crypto processing. The diversity of these interfaces, while offering flexibility, also contributes to the potential attack surface that requires careful management and hardening.

Internally, HSMs are designed with several security controls to ensure the isolation and protection of cryptographic material. A critical feature is the concept of slots or partitions. These are logical separations within a single physical HSM appliance, allowing different teams, applications, or users to securely share the same hardware. Each slot or partition operates with its own dedicated data space, user accounts, and distinct security policies, preventing unauthorized access or interference between partitions. For instance, a user of slot number two cannot read or write data belonging to slot number three, four, or five. This multi-tenancy capability is crucial for large organizations seeking to consolidate their cryptographic infrastructure efficiently and securely.

Beyond logical partitioning, HSMs implement sophisticated role-based access control (RBAC), and in some cases, attribute-based access control (ABAC). Unlike simpler systems with a single "root" user, HSMs typically define multiple administrative roles:

• Administrator: Possesses broad control, including access to audit logs, system resets, and user creation.
• Security Officer (SO) (Administration): Holds specific high-level security responsibilities, such as resetting the initial PIN or password of the Administrator or setting trusted public keys, but with limited operational capabilities compared to the Administrator.
• Partition User (Token User): An account specific to a particular slot or partition, authorized to perform cryptographic operations within that partition.
• Partition Security Officer (Token Security Officer): Manages security aspects specific to a partition, such as resetting the PIN for a Partition User.

The speakers strongly emphasize the importance of segregating these accounts and their corresponding credentials. Best practice dictates that different individuals, teams, or Key Management System (KMS) instances should hold distinct credentials with segregated permissions to prevent a single point of compromise from undermining the entire HSM security posture. The strategies presented in the talk are not theoretical but are "battle-tested" and actively used in production environments, underscoring their practical applicability and proven efficacy.

Key Findings

▶ Watch: Presentation Agenda: What the talk covers (2:50)

The central finding of this talk is that while Hardware Security Modules (HSMs) are inherently designed for high security, achieving "banking-grade" protection for crypto assets requires a deliberate and comprehensive hardening strategy that goes beyond default configurations. The speakers identified that the complexity and multi-functional nature of HSMs, with their various interfaces and internal controls, present a significant attack surface that must be meticulously understood and minimized.

Key findings include:

• Key Management is Paramount: The talk reinforces that the key lifecycle (generation, storage, use, rotation, deletion) is the most vulnerable and critical aspect of any cryptographic system. HSMs provide the necessary primitives, but their secure orchestration and management are the user's responsibility.
• HSM Attack Surface Analysis: The presentation meticulously breaks down the different ways an HSM can be interacted with – from physical access (though not the primary focus of this talk) to various software and network interfaces (PCI Express, TCP/IP, SSH, HTTP(S), GUI, USB). Each interface represents a potential vector for attack if not properly secured, configured, and monitored.
• Logical Segregation is Fundamental: The concept of slots or partitions within an HSM is highlighted as a foundational security control. This logical separation is crucial for multi-tenant environments, ensuring that cryptographic keys and data for one application or team remain isolated from others.
• Granular Role-Based Access Control (RBAC) is Essential: HSMs offer sophisticated user and administrative roles (Administrator, Security Officer, Partition User, Partition Security Officer). The talk underscores that proper implementation of these roles, including strict segregation of duties and independent credential management, is non-negotiable for preventing insider threats or compromise through a single account.
• "Battle-Tested" Practicality: A significant finding is that the presented hardening strategies are not theoretical but are derived from real-world, production environments, specifically within the context of managing billions of dollars in crypto assets for financial institutions. This practical validation lends significant weight to the recommendations.
• Cloud HSMs Require Specific Considerations: The speakers briefly touch upon Cloud HSM or HSM as a service, implying that while the underlying principles remain, the shared responsibility model and cloud-specific attack vectors introduce additional hardening requirements.

In essence, the talk concludes that an HSM is a powerful security tool, but its full potential for banking-grade security is only realized through a proactive and informed approach to configuration, access management, and ongoing operational security, focusing on minimizing its accessible attack surface and rigorously managing cryptographic keys.

Technical Deep Dive

▶ Watch: Defining an HSM: Dedicated crypto key processor (4:00)

The technical core of securing banking-grade crypto wallets with HSMs revolves around understanding the module's architecture, its cryptographic capabilities, and its intricate access control mechanisms. An HSM, as defined by the speakers and aligned with NIST FIPS 140-3, is far more than just a secure storage device; it's a dedicated crypto processor specifically engineered to safeguard the crypto key life cycle. This life cycle is a continuous process beginning with the secure generation of keys using a Pseudo-Random Number Generator (PRNG), followed by their provisioning, configuration, secure storage within the HSM's tamper-resistant boundaries, and controlled usage for operations like encryption, decryption, digital signatures, and Message Authentication Codes (MACs). Crucially, the lifecycle extends to key rotation (generating new keys and retiring old ones) and secure deletion, ensuring that keys are not retained beyond their operational necessity. The speakers underscore that key management is universally acknowledged as the most challenging aspect of practical cryptography, making the HSM's role in this process indispensable.

Interfacing with an HSM can occur through several channels, each presenting distinct security considerations:

• PCI Express: For direct server integration, an HSM card can be inserted into a PCI Express slot. This provides high-speed, low-latency access, often preferred for performance-critical applications.
• TCP/IP: The most common network interface, allowing applications to communicate with the HSM over a network. This typically utilizes the PKCS#11 API (Cryptoki), an industry-standard interface that defines a platform-independent API to cryptographic tokens. PKCS#11 enables applications to perform cryptographic operations and manage keys without direct access to the sensitive key material, which remains protected within the HSM.
• SSH/HTTP(S)/GUI: These interfaces are primarily for administrative operations. SSH provides a secure command-line interface, while HTTP(S) offers web-based management. The presence of a GUI (graphical user interface) further simplifies administration for some models. The security of these interfaces, including the use of TLS for HTTP, is paramount to prevent unauthorized configuration changes or access to audit logs.
• USB: While present on some HSMs, USB is less commonly used for core cryptographic processing due to potential security and performance limitations compared to network or PCI Express interfaces.

The internal security controls of an HSM are designed to enforce strict isolation and accountability. The concept of slots or partitions is fundamental. An HSM can host multiple, logically isolated partitions, each acting as an independent cryptographic module. Each partition has its own:

• Data Space: Dedicated memory or storage where keys and other cryptographic objects are stored, isolated from other partitions.
• Users: Separate user accounts with distinct credentials and permissions, specific to that partition.
• Security Policies: Configurable rules governing cryptographic operations, key attributes, and access controls unique to the partition.

This isolation ensures that a compromise in one application's partition does not affect others, critical for multi-tenant banking environments.

Role-Based Access Control (RBAC) is rigorously enforced across the HSM and its partitions. The speakers detail a layered approach to administrative and user roles:

• Global Administrative Roles:
• Administrator: This role holds extensive privileges, including the ability to access audit logs, reset the entire system, and create other users and partitions.
• Security Officer (SO) (Administration): This role has specific, high-level security-related powers, such as resetting the Administrator's initial PIN/password or setting trusted public keys, but generally cannot perform operational tasks or access sensitive data. This separation of duties between the Administrator and Security Officer is a critical control.
• Partition-Specific Roles:
• Partition User (Token User): Operates within a specific partition, performing cryptographic operations (e.g., signing transactions) using the keys stored therein.
• Partition Security Officer (Token Security Officer): Manages security aspects within their assigned partition, such as resetting the PIN for a Partition User within that slot.

The explicit recommendation is to segregate these accounts and their associated credentials. This means different physical persons or distinct automated systems (e.g., a Key Management System) should hold the credentials for different roles and partitions. This prevents a single point of compromise from granting an attacker full control over the HSM's operations and keys, significantly enhancing the overall security posture for banking-grade crypto wallets. The speakers repeatedly emphasize that these are not theoretical concepts but strategies "used in production, battle-tested," highlighting their real-world efficacy in protecting substantial financial assets.

Demo / Proof of Concept

▶ Watch: HSM Interfaces: How to interact with the device (4:30)

While the speakers, JP Aumasson and Shervine Majeri, extensively discussed the architectural and operational aspects of hardening HSMs for banking-grade crypto wallets, the transcript does not detail a specific live demonstration or a proof of concept conducted during the talk. Instead, the presentation focused on conveying practical knowledge derived from real-world implementations. The speakers explicitly stated that "almost everything we're going to present he's being used in production, battle tested, so it's not just us imagining stuff. It's really real um, very technology." This indicates that the hardening strategies and best practices shared are direct results of their company's (Taurus) experience in deploying and securing HSMs for financial institutions managing significant crypto assets, rather than a live technical exploit or defense demonstration. Therefore, this section acknowledges that no explicit demo was part of the recorded presentation, with the emphasis placed instead on the validated, real-world applicability of their methods.

Defensive Implications

▶ Watch: HSM Security Controls: Slots and partitions (5:20)

The detailed insights provided by JP Aumasson and Shervine Majeri offer critical defensive implications for organizations, particularly financial institutions, looking to secure their crypto assets using HSMs. Implementing these recommendations can significantly reduce the attack surface and enhance the resilience of cryptographic operations.

1. Strict Segregation of Duties and Credentials: The most fundamental defensive measure highlighted is the rigorous implementation of Role-Based Access Control (RBAC) and the segregation of duties. Organizations must ensure that different individuals or automated systems hold distinct credentials for the Administrator, Security Officer, Partition User, and Partition Security Officer roles. No single entity should possess all credentials or have overarching control. This minimizes the impact of a compromised account, preventing an attacker from gaining full control over the HSM and its keys.
2. Minimize the Attack Surface: Review and disable any unnecessary interfaces or services on the HSM. If USB connectivity is not required for core crypto processing, it should be physically or logically disabled. For administrative interfaces like SSH and HTTP(S), ensure they are restricted to an isolated management network, protected by strong authentication (e.g., multi-factor authentication, strong public key cryptography for SSH), and potentially IP whitelisting. Default configurations are rarely secure enough for banking-grade requirements.
3. Secure Key Lifecycle Management: Adhere strictly to best practices for the entire crypto key life cycle. This includes:

• Strong Key Generation: Ensure keys are generated within the HSM using certified PRNGs (e.g., compliant with FIPS 140-3 standards).
• Controlled Provisioning and Usage: Define strict policies on how keys can be provisioned and used, leveraging the HSM's capabilities to enforce key attributes (e.g., non-exportable, specific usage flags).
• Regular Key Rotation: Implement automated or semi-automated processes for rotating keys, reducing the window of exposure for any single key.
• Secure Key Deletion: Ensure keys are cryptographically erased or securely destroyed when no longer needed, preventing recovery.

1. Leverage Partitioning for Isolation: Utilize the slots or partitions feature to logically isolate different applications, teams, or crypto asset types. Each partition should have its own dedicated security policies, users, and data space. This multi-tenancy capability prevents cross-contamination or unauthorized access between different cryptographic workloads sharing the same physical HSM.
2. Robust Logging and Auditing: The Administrator role has access to audit logs. It is critical to configure comprehensive logging for all HSM operations, especially key management and access attempts. These logs should be securely transmitted to a centralized Security Information and Event Management (SIEM) system for real-time monitoring, analysis, and long-term retention. Regular review of audit logs can detect anomalous behavior or attempted breaches.
3. Understand Vendor-Specific Features and Limitations: The speakers explicitly state that "not all HSMs are the same." Defenders must thoroughly understand the specific features, security controls, and potential limitations of their chosen HSM vendor and model. This includes familiarity with their FIPS 140-3 certification level and any vendor-specific hardening guides.
4. Consider Cloud HSM Implications: For organizations using Cloud HSM or HSM as a service, additional defensive considerations apply. While the cloud provider manages the physical hardware and underlying infrastructure, the customer retains responsibility for configuration, key management policies, and access control. This shared responsibility model requires careful alignment of security policies between the organization and the cloud provider.

By systematically addressing these defensive implications, organizations can significantly enhance the security posture of their HSM deployments, providing a robust foundation for protecting high-value crypto assets against sophisticated threats.

Key Takeaways

• HSMs are indispensable for banking-grade crypto asset security: Hardware Security Modules provide the necessary tamper-resistant environment and dedicated crypto processing capabilities to secure billions of dollars in cryptocurrencies, tokenized securities, and stablecoins for financial institutions.
• Key management is the hardest part of crypto and requires dedicated focus: The entire crypto key life cycle—from generation and provisioning to usage, rotation, and deletion—must be meticulously managed within the HSM to prevent compromise.
• HSMs offer robust internal security controls through partitions and RBAC: Features like slots/partitions enable secure multi-tenancy, while comprehensive Role-Based Access Control (RBAC) for Administrator, Security Officer, and Partition-specific roles ensures granular control and accountability.
• Minimizing the attack surface is crucial for HSM hardening: Organizations must actively reduce exposed interfaces (e.g., disabling unnecessary USB, restricting network access for SSH/HTTP(S)) and rigorously configure security policies beyond default settings.
• Strict segregation of duties and credentials is a non-negotiable security principle: Different individuals or systems must hold separate credentials for distinct HSM roles and partitions to prevent a single point of compromise from granting full control.
• Practical, battle-tested strategies are essential for real-world security: The hardening advice presented is not theoretical but based on production experience, validating its effectiveness in protecting high-value digital assets in complex financial environments.

About the Speaker(s)

JP Aumasson is a highly experienced cryptographer with 20 years in the field. He is the author of a well-regarded book on cryptography (now in its second version) and is a veteran speaker at Black Hat, having given multiple talks at the conference. He is associated with Taurus, a company focused on providing hardware security solutions for banks managing crypto assets.

Shervine Majeri is also affiliated with Taurus, where he has been working for over five years. This presentation marked his debut as a speaker at Black Hat, bringing his practical experience with HSMs to the stage alongside JP Aumasson.

Both speakers draw upon their extensive experience at Taurus, which specializes in "battle-tested" hardware security for crypto assets, particularly for the demanding requirements of banking and large financial institutions.