Security

Introduction

This guide brings together a set of guidelines and technical recommendations aimed at strengthening security in restricted environments that make intensive use of DINAMO HSMs DINAMO sensitive cryptographic material. These environments are particularly critical in financial institutions and service providers that operate systems such as the SPB (Brazilian Payment System) and Pix, where the integrity of institutional keys and certificates is a non-negotiable prerequisite for service continuity and for maintaining the trust placed in them by customers, counterparties, and regulatory agencies.

The practices described here are based on the principle of defense in depth: multiple layers of controls overlap so that the failure of any single layer does not compromise the entire system. The following text is organized into thematic sections, beginning with the most general infrastructure controls and progressively moving on to the specifics of secure HSM operation.

Note

See also the topic "Safety Procedures for the Operator."

Generic Infrastructure Controls

Before addressing the specific cryptographic details, it is essential that the environment in which the HSM is deployed adhere to basic security controls. An HSM operating within a permissive network—with poorly protected client machines and lax access policies—is significantly less effective, since an attacker will rarely need to target the HSM directly; instead, compromising the surrounding systems is sufficient.

Network Isolation

The environment must be isolated on a dedicated network, protected by firewalls configured to allow only traffic strictly necessary for operations. Administrative access must be performed exclusively through properly monitored bastion hosts or jump servers, and the HSM or operational machines must never be directly exposed to the Internet or general-purpose corporate networks. Whenever possible, the HSM’s management interfaces should reside on a VLAN separate from the VLAN used by client applications, separating the control plane from the data plane.

IP Filter

There is a feature in the HSM where all access—whether for transactional operations or administration—must go through access control lists based on the source IP address (and, optionally, user + IP). This restriction should be applied both at the firewall level and, preferably, within the HSM’s own configuration, creating a dual barrier. The IP filter eliminates a wide range of opportunistic attacks and drastically reduces the scope for brute-force and scanning attempts. It is recommended to periodically review these lists to remove entries for deactivated machines or employees who have left the company.

Password Policy

The institution must maintain a formal password policy that applies to all user accounts for the HSM and related systems. This policy must include, at a minimum:

1. Authentication failure control, with temporary or permanent account lockout after a set number of consecutive failed attempts, preventing brute-force attacks and generating alerts to be handled by the incident response team;

2. Minimum length and complexity requirements consistent with those defined in the manual—that is, a maximum of 16 characters, representing 128 bits—where the recommendation is to generate new passwords using a generator with a uniform distribution of Base62 characters, thereby avoiding predictable passwords and making dictionary attacks as difficult as possible;

3. Periodic rotation at defined intervals, supplemented by extraordinary rotation whenever there is suspicion of compromise or disconnection of custodians; this item is not a feature of the HSM but rather an architectural design practice for its use.

A password policy alone is insufficient as a security measure, but it forms the foundation on which other controls are built.

Target Account: The Foundation of Institutional Trust

Within the HSM, the institution must set up one or more accounts—referred to as partitions at the equipment manual level—intended exclusively for the safekeeping of institutional certificates. The recommended segregation is as follows:

• For the SPB, a target account must be maintained for each domain or participating institution;
• For the Pix, you must maintain one target account per institution;
• For other critical systems, apply the same segregation logic based on areas of responsibility.

The target account should be understood as the foundation of institutional trust within HSM. Its day-to-day use is, by design, rare: it is accessed primarily to grant sub-authorizations, that is, to authorize subordinate operational accounts to perform functions on behalf of the institution. In a normal operating cycle, this activity occurs very infrequently—often at intervals of months or years—which allows for the application of more restrictive controls without compromising operational agility.

Joint Custody

The password for the target account should never be entirely under the control of a single individual. The recommended mechanism is one involving multiple custodians, with at least two participants. This division of responsibility prevents unilateral actions, reduces the risk associated with coercion or individual bad faith, and establishes a formal, observable process for any critical action.

Restrictions by User and IP Address

In addition to shared custody, access to the target account must be contingent upon the authorized combination of user and source IP address. This physical-logical binding prevents any leaked credentials from being used outside the originally authorized workstation and treats any attempt to access the account from an unanticipated source as a security incident warranting immediate investigation.

Logins to these accounts should be monitored periodically by processing the machine logs.

Investment Account (App)

The day-to-day operation of the HSM, message signing, certificate validation, and other cryptographic functions used by internal systems must never be performed from the target account. This responsibility falls to an application account, created specifically for this purpose, using specific permissions.

Granular Permissioning

The application account must be configured according to the principle of least privilege, with permissions limited to reading objects from the target account. Administrative operations, the creation of new keys outside the intended workflow, and access to objects from other applications must be explicitly prohibited. When an institution operates multiple distinct applications, it is strongly recommended that each have its own application account, so that a potential compromise of one application does not spread to the others.

Password Rotation

The App account credential does not have to be a plaintext password: the HSM supports the use of a PSK (Pre-Shared Key) of 128 bits (16 bytes), called ATOKEN, as an authentication mechanism. The ATOKEN is also rotatable, and because it is a randomly generated high-entropy secret, it eliminates the typical weaknesses of user-chosen passwords (predictability, reuse, susceptibility to dictionary attacks), making it the preferred option for application authentication.

The password, or ATOKEN, for the App account must be rotated periodically, in cycles consistent with the application’s criticality and the institution’s internal policy. To ensure that this rotation occurs without operational impact, there must be scripts or automated tools responsible for generating a new password, updating it in the HSM, and propagating it to the secret vault used by the applications. This process must be auditable, resistant to intermediate failures—that is, capable of recovering a consistent state if interrupted—and tested regularly outside of critical windows. App account passwords must never be stored in plaintext configuration files, code repositories, or collaboration tools.

Multi-Factor Authentication for the APP Account (Asymmetric Key + PSK)

For critical applications, it is recommended to upgrade the APP account authentication to two-factor authentication, combining the PSK (password or ATOKEN) with an X.509 certificate and its corresponding private key, associated with the partition. In this setup, the client authenticates to the HSM via mTLS (mutual TLS); the HSM validates the certificate presented by the application and then requests the corresponding PSK, so that possession of only one of the factors is insufficient to establish the session.

This model substantially increases the effective security level of authentication, as it combines something the application knows (the PSK, which has high entropy when generated as a 128-bit ATOKEN) with something the application possesses (the private key associated with the certificate). To ensure that the security guarantees of two-factor authentication are not compromised, the private key used in mTLS must not reside in an environment variable or in unrestricted configuration files: it must be stored in a file protected by access control lists (ACLs) in the file system, under a chain of custody distinct from the one that manages the PSK. Thus, a potential compromise of one of the factors—such as a leak of the PSK from the secret vault or unauthorized access to the private key—is not sufficient, on its own, to authenticate as the application.

The rotation of the two factors must be independent and automated, following the same principles described above. It should be noted that the HSM does not support all possible combinations of factors: specifically, the combination of ATOKEN and PSK is not supported by design; the recommended configuration for 2FA on the App account is therefore an asymmetric key (X.509 certificate) paired with a PSK.

List of Security Team Members

The addition, replacement, and removal of certificates in the HSM is a periodic task that is typically handled by a specialized security team. Each member of this team must have their own personal, individually assigned account in the HSM, rather than sharing generic credentials.

The existence of individual accounts yields three direct benefits:

• It creates accurate audit trails in which each operation involving the handling of objects is linked to an identifiable operator, facilitating review, forensic analysis, and accountability.

• It allows for the immediate revocation of access in the event of termination or a change in role, without the costs associated with changing shared passwords and redistributing them.

• It creates the conditions for implementing multi-factor authentication (MFA) on a per-user basis, combining a password with a second possession-based factor—such as a physical token, a smart card, or an authentication app—which substantially increases the cost of a successful attack.

The institution's security policy must require the use of MFA for these accounts, and no exceptions should be allowed on the grounds of operational convenience.

HSM Operator Users and Segregation of Privileges

In addition to certificate custody accounts and application accounts, the HSM allows for the creation of operator users, who are granted administrative functions not available to regular users. Typical responsibilities for this role include retrieving and viewing logs, creating new users, modifying device configuration parameters, and performing other maintenance operations that support the proper management of the equipment. Having a separate operator profile is essential so that routine administrative activities can be performed without the need to directly access target accounts or application accounts, thereby upholding the principle of separation of duties. An important note is that the master user master which comes as the default in the HSM and cannot be deleted) should not be used. This user has the same permissions as an operator, with the restriction (in addition to not being able to be deleted) that if its password is locked, it can only be unlocked via an operation on a local console physically connected to the HSM.

It is important to note, however, a fundamental safeguard provided by the HSM for these administrative users: there is no possibility for an operator user to use an object—such as a key—belonging to another partition to perform cryptographic operations, unless they have been granted explicit permission to do so. This property is crucial, as it means that administrative privileges do not automatically translate into privileges to use the cryptographic material in custody. The administrator can manage the device without thereby gaining operational access to the keys in the partitions; the barrier between the administration layer and the cryptographic usage layer is maintained by the HSM itself, regardless of the best practices implemented by the institution. This behavior, in and of itself, substantially reduces the risk associated with the compromise of administrative accounts and reinforces the value of partition segregation described in the previous sections.

Generation and Management of Cryptographic Material

How keys are handled ultimately determines the quality of HSM usage. An HSM that operates with exportable keys—which are handled outside the device or transferred via insecure means—loses much of its purpose.

Non-Exportable Keys

Whenever possible, private keys should be generated directly within the HSM, with the non-exportable attribute set at the time of creation. This ensures that sensitive cryptographic material never leaves the device in plaintext, and even an administrator with elevated privileges is prevented from extracting it. This is the configuration that truly delivers on the protection guarantees offered by the HSM.

Appropriate Workflow for Certificates

The recommended workflow for obtaining an operational certificate is as follows: the private key is generated within the HSM; a Certificate Signing Request (CSR) is created from that key while still within the device; the CSR is sent to the certificate authority; and, finally, only the resulting signed certificate is imported. At no point does the private key leave the HSM. This process must be documented step by step, and the security team must be trained to reject alternative workflows that involve generating the key externally.

Transfer Between Partitions

In scenarios where the same key needs to be available on different partitions—for example, to meet high-availability requirements or for replication between equivalent environments—the transfer must be performed using the key backup and restore mechanism provided by the HSM itself. This mechanism transports the encrypted data with high-quality protection and preserves the original key’s non-exportability and access control properties. You should never resort to plaintext export or insecure intermediate formats to perform this transfer.

Physical and Operational Protection of Equipment

Logical security depends on a solid foundation of physical security. The HSM must be installed in an environment with audited physical access control, preferably in a vault or a locked rack within a classified data center.

Smart Cards and Shared Custody in Administrative Operations

Administrative operations on the equipment—such as startup, parameter changes, network changes, and others—must be protected by smart cards accompanied by PINs, which are also operated under a multi-custodian system. This combination requires the simultaneous physical presence of more than one authorized person for any critical action to be carried out, which replicates, at the administrative level, the same safeguards already described for the target account.

Segregation of Environments

Whenever feasible, different applications should run on separate HSMs or partitions. Separating SPB, Pix other critical systems is highly recommended, as it limits the impact of potential compromises and facilitates the assignment of responsibilities. Separation between the validation and production environments is mandatory: a production HSM must never be used for testing, and production keys must never pass through the validation environment. This rule must be treated as non-negotiable, even in the face of schedule pressures.

Dinamo HSMs Dinamo quickly brought online, so—by configuring the network and domain settings—it is possible to deploy an HSM previously used in another environment (such as a validation environment) into a production environment, for reasons such as replacing a machine or adding to the cluster. This operation does not cause any downtime in the target production environment.

Business Continuity and Disaster Recovery

From a practical standpoint, the loss of access to institutional keys is equivalent to the interruption of the services that depend on them. Therefore, the continuity strategy must be planned with the same rigor applied to preventive controls.

Backups must be performed periodically and managed according to a formal procedure that defines the frequency, responsible parties, storage locations, and retention period. Backups must be stored on secure media that is physically segregated from the production environment, preferably in more than one location.

Continuous Monitoring and Auditing

No set of controls can completely eliminate the possibility of incidents. The difference between a resilient institution and a vulnerable one often lies in the speed with which anomalies are detected and addressed.

HSM devices must be continuously monitored, ideally using protocols such as SNMP for collecting metrics and SMTP for sending alerts, in addition to integration with the corporate SIEM platform. They must generate specific alerts for at least the following events:

• Creation of new users or partitions—an unusual operation that warrants immediate review whenever it occurs outside of an authorized plan;
• Logins outside normal operating hours, particularly for app accounts or administrative accounts, which may indicate potential misuse of credentials;
• Repeated failed authentication attempts, which may indicate brute-force attacks or significant configuration errors;
• Changes to policies, configurations, or permissions that alter the device's security perimeter;
• Equipment health events, such as hardware failures, abnormal temperatures, ortampering, that require an immediate operational response.

The logs generated must be retained for a period consistent with regulatory requirements and the institution’s retention policy, and must be protected against tampering.

Final Recommendations

The best practices described in this guide do not constitute a static list. The threat landscape is constantly evolving, as are equipment capabilities, regulatory requirements, and counterparty demands. Therefore, it is recommended that this document be reviewed periodically—at least once a year—or whenever there are significant changes to the institution’s infrastructure, applicable legislation, or portfolio of critical applications.

It is also recommended that the adoption of these practices be accompanied by training and awareness programs aimed at the teams involved, as the effectiveness of the controls depends directly on the level of understanding and adherence among the professionals who operate them. The technical documentation for the equipment must remain accessible to the responsible team, especially when planning changes and responding to incidents.