Primus HSM - Configuration
After the initial setup the HSM can be configured to suit your use case. The configuration can be done either:
- Manually via the front panel display or via the serial console, or
- Automatically by loading an XML configuration file from an USB stick, via the display or via the serial console.
For detailed parameter description, values and ranges, please see Primus HSM User Guide. The Primus HSM configuration splits into 3 main categories:
Network Configuration
Within the network configuration, the interface, IP address, and port values can be configured for services such as:
- API processes (JCE, PKCS#11, MSCNG)
- High Availability
- Remote Administration (Decanus)
- NTP, SNMP, and logging
And other configuration such as:
- URL / IP settings
- Routing
- Interface Redundancy
- Bonding
- WebDAV Server
HSM cluster network example
Single or Multiple Interface
The Primus HSM can be connected either in single interface mode, or via multiple interfaces to physically separate the services (e.g. User data, management, HA, redundancy).
The Single Interface Mode allows to switch all services to interface 1 without changing the interface configuration of each service.
Configuring redundancy using the built-in RJ45 interface 4 is still possible when Single Interface Mode is enabled.
Interface Redundancy
Primus HSM supports redundant network connections by combining two interfaces of the same type, such as standard Ethernet or optical. If one connection fails, the other takes over automatically, helping to maintain continuous network availability.
Bonding Groups
The Primus HSM supports multiple combinations of network ports, known as bonding groups. For example, the built-in interface IF4 can be used on its own or paired with one of the other RJ45 ports for redundancy. It is also possible to configure the remaining RJ45 ports or the optical SFP+ ports (X2/E2/S2 devices only) into pairs to create up to three bonding groups in total.
| Parameter | Requirements |
|---|---|
Group 1: Bond IF 4 to the following built-in RJ45 interface | Built-in RJ45 interface |
Group 2: Bond remaining RJ45 IFs bundle the remaining two built-in RJ45 interfaces | Built-in RJ45 interface Bond IF 4 to > 0 and Bonding Mode > 0 |
Group 3: Bond SFP IFs bundle the two optical SFP interfaces | SFP optical interfaces |
Bonding Modes
Several bonding modes are available which define how interfaces work together.
| Redundancy mechanism | Bonding Mode |
|---|---|
| Active-backup bonding | 1 |
| Link Aggregation (LACP slow, passive) | 2 |
| Link Aggregation (LACP fast, passive) | 3 |
- Linux Bonding (Bonding Mode = 1)
- In this mode, only one interface is active at a time. If the active connection fails, the backup interface takes over automatically using the same IP address, making failover seamless.
- Link Aggregation (Bonding Mode = 2 or 3)
- Also known as LACP (Link Aggregation Control Protocol, IEEE 802.1AX-2008, formerly IEE 802.3ad), this method bundles two interfaces to increase bandwidth and provide failover. With LACP, the HSM and a connected switch coordinate the connection to ensure both interfaces work together. Mode 2 uses slower timeouts; Mode 3 provides faster response times. This setup requires configuration on the connected network switch.
This parameter allows to configure redundant access from different attached networks, e.g. operational and emergency network. The setting overrules the port assignment of services and applies the same firewall rules on all interfaces.
Network Attached Storage (WebDAV)
When use of USB memory sticks is prohibited, the data can be transferred to and or from a WebDAV server instead
(according RFC4918) using HTTP(S).
This feature is supported with firmware v3.0 and higher and requires appropriate licensing.
The HSM acts as a WebDAV client and allows mutual TLS authentication. WebDAV can be configured before running the initial wizard and can be tested before activation.
Network Time Protocol (NTP) – Overview and Configuration
NTP (Network Time Protocol) is a standard protocol used to synchronize the system clock of devices over a network to a reference time source. Accurate timekeeping is essential for cryptographic operations, as time is used in certificate validation, key expiration, logging, and audit trails. In Primus HSMs, NTP ensures consistent and reliable time synchronization across clustered units, which is critical for maintaining operational integrity and compliance with security standards.
Time and date can be set either manually or synchronized continuously via Network Time Protocol (NTP version 4, RFC5905). In Primus HSMs NTP is enabled by default.
Full NTP configuration can be done via command line or XML configuration file only (GUI shows hardware specific only some of the parameters).
Security Configuration
The setup of the device security policies requires Security Officer (SO) privileges. The policy of the device is set for the whole device. Optionally a configuration can be done for each individual User (Partition). The individual User configuration overrides the device security configuration, with some exceptions.
Configuration Parameters
The security configuration includes the following sections:
- Device Security
- Device Policy: such as login password, allowing Backup / Restore, Manual / Remote cloning, ...
- Device Crypto Policy: this policy is used in cases where User Security is not used. Includes other parameters as well.
- Management Policy: used management policies such as enabling SNMP, SO Configuration, Logging and more.
- Master Security: for configuring cluster parameters such as HA Master URL
- User Security: configuration per User (Partition), if enabled will overrule the device crypto policy for the defined User. Configuration such as API access, key import / export, management access and more.
Individual User Configuration
Individual User security configuration can be set, as part of a SO authorized operation. If per User configuration is enabled, the configuration parameters are applied to the User and override the device configuration with the following exception, which have to be enabled on device level as well:
- use of APIs (JCE, PKCS#11, MSCNG)
- client API Access
Factory default parameters are initially applied to all "User Security" parameters. The User configuration can be managed either through the HSM Device SO or the PSO via Decanus Terminal in Remote Partition Administration mode.
Security Officer configuration access may be revoked by the PSO for a particular Partition.
User configuration can be changed, either by modifying single parameters or via XML configuration file export/modify/import. Note that changes via XML configuration file do not allow Partition renaming.
Specific User settings can be modified through UI, Console or Decanus Terminal:
- Restricting User management
- Import, export or extraction of keys
- Cryptographic object management limitations
- Allowed APIs
- and more...
Logging Configuration
Primus HSM is continuesly logging events using the following logs:
- System Log (syslog)
containing non-sensitive events like network status, temperature, load, diagnostics, etc. to be sent to and analyzed by system and network monitoring tools. - Security/Audit Log (crypto log)
includes the system log plus sensitive and security relevant events like SO operations, configuration changes, key creation/changes, client logins/activity, etc. for audit trail analysis and archiving. - Partition Specific Log(s) (Security/Audit log)
if required, an independent dedicated log area can be activated per Partition, which is stored in a reserved area of that Partition so that the log cannot be flooded by events of other partitions. The log consists of the Security/Audit Log of the specific Partition. - Unplanned Restarts Log (crash log)
containing information of unplanned restarts due to power-off, watchdog, and other outages.
System Log, Security Log, and the Partition Specific Log need to be configured before use. The following parameters can be configured:
- Size
- Syslog streaming server connection
- Log level (Partition logging)
After a tamper event, the logs still remain and may be exported (Genesis role) and analyzed to identify the cause of the tamper. The logs are deleted during a factory reset.
It is possible to export all logs onto a USB storage device
(see Export Logs).
Securosys also provides a free Splunk app for log analysis.
Depending on configuration, the User specific Security Log can be read via the User Client API for informational or troubleshooting purposes (signed logs require firmware v3.0+).
The current syslog reference is listed in the Primus HSM User Guide chapter Logging References, or you can view the dedicated page on the Securosys Support Portal.
Partition specific Logging
For Partition specific logging, the User Security Configuration Partition Logging must be enabled and licensed.
To have an independent dedicated additional log buffer for a specific Partition, Partition logging can be activated under User Security configuration (license required). A dedicated log space is allocated within the User Partition, which must have sufficient free space. The space for key storage is reduced accordingly. Partition specific logs can be read out via Client API requests.
Reliable Syslog with Transport Layer Security (TLS)
Reliable Syslog with Transport Layer Security (TLS) is a method of securely transmitting syslog messages over a network using encryption and authentication. By wrapping syslog data in TLS, it ensures that log messages are not altered or intercepted in transit, and that the sender and receiver can verify each other's identity. This approach enhances the integrity and confidentiality of system logs.
TLS with server authentication (syslog-ng TLS) can be enabled on the Primus HSM to secure the transport to the next syslog hop in non-FIPS mode.
TLS activation applies to all configured System Log and Security Log receivers.
To activate, the base-64 encoded common root and issuing CA certificates of all syslog receivers (syslog and crypto log) have to be loaded into the HSM via XML network (or security) configuration file.
With TLS server authentication activated, the verification sequence is as follows:
- The HSM connects via TCP using TLS protocol to the configured server address and port and requests the servers’ certificate (including certificate chain) and public key
- The server sends it's certificate (including the complete certificate chain and public key)
- The HSM verifies the received certificate (chain) with the configured CA certificate(s)
- on verification failure (or the server does not support TLS) the connection is aborted
- on verification success the connection establishment continues, and log messages are sent via the secured connection