Audit Logging
Each event that occurs on the HSM can be recorded in the HSM event log, allowing you to audit your HSM usage. The HSM event log is viewable and configurable only by the audit user role. This audit role is disabled by default and must be explicitly enabled.
This chapter describes how to use audit logging to provide security audits of HSM activity. It contains the following sections:
>Audit Logging General Advice and Recommendations
>Configuring and Using Audit Logging
>Changing the Auditor Credentials
>Audit Log Categories and HSM Events
Audit Logging Features
The following list summarizes the functionality of the audit logging feature:
>Log entries originate from the Luna Network HSM 7 (cryptographic module - the feature is implemented via HSM firmware (rather than in the library), for maximum security.
>Log origin is assured.
>Logs and individual records can be validated by any Luna Network HSM 7 that is a member of the same domain.
>Audit Logging can be performed on password-authenticated and multifactor quorum-authenticated (both FIPS 140-3 level 3) configurations, but these configurations may not validate each other's logs - see the "same domain" requirement, above.
NOTE The "same domain" requirement still applies, but with the introduction of Extended Domain Management [ see Universal Cloning and Domain Planning ] (Partition Policy 44) in firmware version 7.8.0, you can change/add domains, such that the verifying HSM could be given the same domain as the original logging HSM.
Thus, from Luna HSM firmware version 7.8.0 onward, it is possible
•for a Multifactor Quorum HSM log to be validated by a Password-authenticated HSM
or
•for a Password-authenticated HSM log to be validated by a Multifactor Quorum HSM.
>Each entry includes the following:
•When the event occurred
•Who initiated the event (the authenticated entity)
•What the event was
•The result of the logging event (success, error, etc.)
>Multiple categories of audit logging are supported, configured by the audit role.
>Audit management is a separate role - the role creation does not require the presence or co-operation of the Luna Network HSM 7 SO.
>The category of audit logging is configurable by (and only by) the audit role.
>Audit log integrity is ensured against the following:
•Truncation - erasing part of a log record
•Modification - modifying a log record
•Deletion - erasing of the entire log record
•Addition - writing of a fake log record
>The following critical events are logged unconditionally, regardless of the state of the audit role (initialized or not):
•Tamper
•Decommission
•Zeroization
•SO creation
• Audit role creation
Types of events included in the logs
The events that are included in the log is configurable by the audit role. The types of events that can be logged include the following:
>log access attempts (logins)
>log HSM management (init/reset/etc)
>key management events (key create/delete)
>asymmetric key usage (sig/ver)
>first asymmetric key usage only (sig/ver)
>symmetric key usage (enc/dec)
>first symmetric key usage only (enc/dec)
>log messages from CA_LogExternal
>log events relating to log configuration
Each of these events can be logged if they fail, succeed, or both.
Event log storage
When the HSM logs an event, the log is stored on the HSM. The audit user cannot view these log entries. Before a log can be viewed, it must be rotated. Log rotation saves the log entries on the HSM to the
TIP Log entries are stored in the cryptographic module (HSM) until they are rotated off. Log entries are not rotated out of the cryptographic module until the audit user is initialized and audit logging is configured. By default, even if there is no audit user or configuration, the cryptographic module logs unconditional events within its own memory, like:
>zeroize
>decommission
>hardware tamper
>card removal
>etc.
If the crypto module internal space ever fills completely with log records,
>whether slowly from unconditional logs, or
>quickly from more voluble high-volume event recording,
...the HSM / cryptographic module would stop all operations that were not
To avoid that ever happening, configure audit logging to organize log parameters and handling, being sure to set sufficient frequency of rotation for the volume of record generation that you enable.
Best practice is to:
>initialize the audit role as soon as the HSM is first powered on for production audit init
>configure the log storage path on the external file system, along with the types of events to log, the rotation interval, etc. audit config
>then, initialize the HSM Security Officer (this helps ensure that all messages, demanded by your auditing authority, are captured) hsm init
>then, proceed with partition initialization and usage with your application(s)
>then, revisit audit log configuration at regular intervals to tune the balance between
•desired message types,
•volume of audited actions normally performed (*),
•and so on
>when you change behavior of the crypto module or change the types of events to audit, be sure to revisit also the rotation interval.
[* Example, you might always want to record the generation of keys, but if usage of those keys is very high-volume (like in some signature use-cases), and thus would generate a high volume of log entries, it might be permissible, and prudent, to log only first-use of any key. Check with the relevant authority.]
Audit log locations in the HSM appliance
When viewing HSM appliance information (like status disk), you might see mention of two log-file locations.
>The folder /var/audit receives the HSM audit logs only. This is for HSM events and cryptographic operations. No information about host system events is logged here.
>The folder /var/log/audit is for the appliance operating system (host system) audit logs. No information about cryptographic operations is logged here.
Event logging impacts HSM performance
Each audit log record generated requires HSM resources. Configuring event logging to record most, or all, events may have an impact on HSM performance. You may need to adjust your logging configuration to provide adequate logging without significantly affecting performance. By default, only critical events are logged, imposing virtually no load on the HSM.
Audit limitations and Controlled tamper recovery state
The following conditions apply when HSM Policy "48: Do controlled tamper recovery" is enabled (default setting).
>Auditor (the Audit role) cannot verify the integrity of audit logs until after recovery from tamper.
>Auditor cannot be initialized when the HSM is in controlled tamper recovery state.
>Existing Audit role can login when in controlled tamper recovery state.
>Existing Audit role cannot make audit config changes when in controlled tamper recovery state.
>Existing Audit role cannot export the audit secret when in controlled tamper recovery state.
The Audit Role
The audit logging function is controlled by two roles on Luna Network HSM 7, that must be used together:
>The "audit" appliance account (use SSH or PuTTy to log in as "audit", instead of "admin", or "operator", or "monitor", etc.)
>The "audit" HSM account (accessible only if you have logged into the appliance as "audit"; this account must be initialized)
On Luna Network HSM 7, the audit logging is managed by an audit user (an appliance system role), in combination with the HSM audit role, through a set of LunaSH commands. The audit user can perform only the audit-logging related tasks and self-related tasks. Other HSM appliance users, such as admin, operator, and monitor, have no access to the audit logging commands.
A default appliance (LunaSH) audit user is automatically created, but must be enabled. Upon first login, the audit user is asked to change their password. That appliance audit user would need to initialize the HSM audit role first, before being able to administer the audit logging. The Luna Network HSM 7 admin user can create more audit users when necessary.
To simplify configuration,
>The maximum log file size is capped at 50 MB.
>The log path is kept internal.
>The rotation offset is set at 0.
Audit User on the Appliance
The appliance audit user is a standard user account on Luna Network HSM 7, with default password "PASSWORD" (without the quotation marks). By default, the appliance audit user is disabled. Therefore, you must enable it in LunaSH before it becomes available. See user enable for the command syntax.
Audit Role on the HSM
A Luna Network HSM 7 Audit role allows complete separation of Audit responsibilities from the HSM Security Officer (HSM SO), the Crypto Officer(or User), and other HSM roles. If the Audit role is initialized, the HSM and Partition SOs are prevented from working with the log files, and auditors are unable to perform administrative tasks on the HSM. As a general rule, the Audit role should be created before the HSM Security Officer role, to ensure that all important HSM operations (including those that occur during initialization), are captured.
Use the LunaSH command audit init to initialize the audit role, as described in audit init.
Password-authenticated HSMs
For Luna Network HSM 7s with Password Authentication, the auditor role logs into the HSM to perform their activities using a password. After initializing the Audit role on a password-authenticated HSM, log in as the Auditor and set the domain (see role setdomain). This step is required before setting logging parameters or the log filepath, or importing/exporting audit logs.
Multifactor Quorum-authenticated HSMs
For Luna Network HSM 7s with multifactor quorum authentication, the auditor role logs into the HSM to perform their activities using the Audit (white) PED key.
Role Initialization
Creating the Audit role
Appliance Audit User Available Commands
The Audit role has a limited set of operations available to it, on the HSM, as reflected in the reduced command set available to the "audit" user when logged in to the shell (LunaSH).
login as: audit audit@192.20.11.78's password: Last login: Fri Mar 31 09:37:53 2020 from 10.124.0.31 Luna SA 7.7.0 Command Line Shell - Copyright (c) 2001-2020 SafeNet, Inc. All rights reserved. lunash:>help The following top-level commands are available: Name (short) Description -------------------------------------------------------------------------------- help he Get Help exit e Exit Luna Shell hsm hs > Hsm audit a > Audit my m > My network n > Network
Audit Log Secret
The HSM creates a log secret unique to the HSM, computed during the first initialization after manufacture. The log secret resides in flash memory (permanent, non-volatile memory), and is used to create log records that are sent to a log file. Later, the log secret is used to prove that a log record originated from a legitimate HSM and has not been tampered with.
Log Secret and Log Verification
The 256-bit log secret which is used to compute the HMACs is stored in the parameter area on the HSM. It is set the first time an event is logged. It can be exported from one HSM to another so that a particular sequence of log messages can be verified by the other HSM. Conversely, it can be imported from other HSMs for verification purpose.
To accomplish cross-HSM verification, the HSM generates a key-cloning vector (KCV, a.k.a. the Domain key) for the audit role when it is initialized. The KCV can then be used to encrypt the log secret for export to the HOST.
To verify a log that was generated on another HSM, assuming it is in the same domain, we simply import the wrapped secret, which the HSM subsequently decrypts; any records that are submitted to the host for verification will use this secret thereafter.
When the HSM exports the secret, it calculates a 32-bit checksum which is appended to the secret before it is encrypted with the KCV.
When the HSM imports the wrapped secret, it is decrypted, and the 32-bit checksum is calculated over the decrypted secret. If this doesn’t match the decrypted checksum, then the secret that the HSM is trying to import comes from a system on a different domain, and an error is returned.
To verify a log generated on another HSM, in the same domain, the host passes to the target HSM the wrapped secret, which the target HSM subsequently decrypts; any records submitted to the target HSM for verification use this secret thereafter.
Importing a log secret from another HSM does not overwrite the target log secret because the operation writes the foreign log secret only to a separate parameter area for the wrapped log secret.
CAUTION! Once an HSM has imported a wrapped log secret from another HSM, it must export and then re-import its own log secret in order to verify its own logs again.
Audit Log Records
A log record consists of two fields – the log message and the HMAC for the previous record. When the HSM creates a log record, it uses the log secret to compute the SHA256-HMAC of all data contained in that log message, plus the HMAC of the previous log entry. The HMAC is stored in HSM flash memory. The log message is then transmitted, along with the HMAC of the previous record, to the host. The host has a logging daemon to receive and store the log data on the host hard drive.
For the first log message ever returned from the HSM to the host there is no previous record and, therefore, no HMAC in flash. In this case, the previous HMAC is set to zero and the first HMAC is computed over the first log message concatenated with 32 zero-bytes. The first record in the log file then consists of the first log message plus 32 zero-bytes. The second record consists of the second message plus HMAC1 = HMAC (message1 || 0x0000). This results in the organization shown below.
| MSG 1 | HMAC 0 |
| . . . | |
| MSG n-1 | HMAC n-2 |
| MSG n | HMAC n-1 |
| . . . | |
| MSG n+m | HMAC n+m-1 |
| MSG n+m+1 | HMAC n+m |
| . . . | |
| MSG end | HMAC n+m-1 |
| Recent HMAC in NVRAM | HMAC end |
To verify a sequence of m log records which is a subset of the complete log, starting at index n, the host must submit the data illustrated above. The HSM calculates the HMAC for each record the same way as it did when the record was originally generated, and compares this HMAC to the value it received. If all of the calculated HMACs match the received HMACs, then the entire sequence verifies. If an HMAC doesn’t match, then the associated record and all following records can be considered suspect. Because the HMAC of each message depends on the HMAC of the previous one, inserting or altering messages would cause the calculated HMAC to be invalid.
The HSM always stores the HMAC of the most-recently generated log message in flash memory. When checking truncation, the host would send the newest record in its log to the HSM; and, the HSM would compute the HMAC and compare it to the one in flash. If it does not match, then truncation has occurred.
Audit Log Message Format
Each message is a fixed-length, comma delimited, and newline-terminated string. The table below shows the width and meaning of the fields in a message.
| Offset | Length (Chars) | Description |
|---|---|---|
| 0 | 10 | Sequence number |
| 10 | 1 | Comma |
| 11 | 17 | Timestamp |
| 28 | 1 | Comma |
| 29 | 256 | Message text, interpreted from raw data |
| 285 | 1 | Comma |
| 286 | 64 | HMAC of previous record as ASCII-HEX |
| 350 | 1 | Comma |
| 351 | 96 | Data for this record as ASCII-HEX (raw data) |
| 447 | 1 | Newline '\n' |
The raw data for the message is stored in ASCII-HEX form, along with a human-readable version. Although this format makes the messages larger, it simplifies the verification process, as the HSM expects to receive raw data records.
Example
The following example shows a sample log record. It is separated into multiple lines for readability even though it is a single record. Some white spaces are also omitted.
38,12/08/13 15:30:50,session 1 Access 2147483651:22621 operation LUNA_CREATE_CONTAINER returned LUNA_RET_SM_UNKNOWN_TOSM_STATE(0x00300014) (using PIN (entry=LUNA_ENTRY_DATA_AREA)), 29C51014B6F131EC67CF48734101BBE301335C25F43EDF8828745C40755ABE25, 2600001003600B00EA552950140030005D580000030000800100000000000000000000000000000000000000
The sequence number is “38”. The time is “12/08/13 15:30:50”.
The log message is “session 1 Access 2147483651:22621 operation LUNA_CREATE_CONTAINER returned LUNA_RET_SM_UNKNOWN_TOSM_STATE(0x00300014) (using PIN (entry=LUNA_ENTRY_DATA_AREA))”.
In the message text, the “who” is the session identified by “session 1 Access 2147483651:22621” (the application is identified by the access ID major = 2147483651, minor = 22621).
The “what” is “LUNA_CREATE_CONTAINER”.
The operation status is “LUNA_RET_SM_UNKNOWN_TOSM_STATE(0x00300014)”.
The HMAC of previous record is “29C51014B6F131EC67CF48734101BBE301335C25F43EDF8828745C40755ABE25”.
The remainder is the raw data for this record as ASCII-HEX.
>The “who” is LunaSH session “session 1 Access 2147483651:22621”
(identified by the lunash access ID major = 2147483651, minor = 22621).
>The “what” is “LUNA_CREATE_CONTAINER”.
>The operation status is “LUNA_RET_SM_UNKNOWN_TOSM_STATE(0x00300014)”.
Timestamping
The HSM has an internal real-time clock (RTC). The RTC does not have a relevant time value until it is synchronized with the HOST system time. Because the HSM and the host time could drift apart over time, periodic re-synchronization is necessary. Only an authenticated Auditor is allowed to synchronize the time.
Time Reported in Log
When you perform audit show, you might see a variance of a few seconds between the reported HSM time and the Host time. Any difference up to five seconds should be considered normal, as the HSM reads new values from its internal clock on a five-second interval. So, typically, Host time would show as slightly ahead.
Log Capacity
LOG FULL condition
If you receive CKR_LOG_FULL, the log capacity has been reached, and all HSM operations will stop. This is to prevent the HSM from performing unlogged operations. In this condition, most HSM commands will not work; only commands that allow the Auditor to log in, clear the log storage, set the logging configuration, or reset the HSM to factory conditions are permitted.
See Copying Log Files Off the Appliance for details of this recovery procedure.
Configuration Persists Unless Factory Reset is Performed
Audit logging configuration is not removed or reset upon HSM re-initialization or a tamper event. Factory reset or HSM decommission will remove the Audit user and configuration. Logs must be cleared by specific command. Therefore, if your security regime requires decommission at end-of-life, or prior to shipping an HSM, then explicit clearing of HSM logs should be part of that procedure.
This is by design, as part of separation of roles in the HSM. When the Audit role exists, the HSM SO cannot modify the logging configuration, and therefore cannot hide any activity from auditors.
NTLS is stopped but log still records LUNA_OPEN_SESSION/LUNA_CLOSE_SESSION messages
LUNA_OPEN_SESSION and LUNA_CLOSE_SESSION messages continue to appear in the audit logs, even though NTLS is stopped and applications cannot connect.
This is expected: inside the Luna Network HSM 7 appliance, a system state-of-health monitor routinely calls "hsm show", to ensure that the HSM is still functioning. Those calls trigger audit log messages.
Comparing Syslog vs Audit log
TIP The distinction, between an HSM (or cryptographic module) and its host, is obvious when an HSM is a circuit board/card that you install in a computer, or a USB-connected external unit. However, when an HSM card is an integral part of a network HSM appliance, it can be common usage to refer to the whole unit as "the HSM".
For management of the devices it is important to differentiate between the configuration and operation of the host and the configuration and operation of the cryptographic module within, such as when addressing
•the system logs of the host and
•the audit logs of the cryptographic module.
|
Function or |
Syslog | Audit Log |
|---|---|---|
| Managed by |
Managed by Luna Network HSM 7 appliance admin user via Luna Shell "syslog" commands. |
Managed byLuna Network HSM 7 appliance audit user via Luna Shell "audit log" commands. |
| Source of log
messages |
Captures events in the host system, not including any activity within the embedded HSM/cryptographic module. | Captures events that occur inside the HSM/cryptographic module. |
| Control of behavior | Behavior is broadly standardized but specifics depend on the host and its operating system. See Configuring System Logging. | Behavior is controlled by HSM firmware, modified by configuration settings. See Audit Logging. |
| Location where log records are stored |
Events are logged to the host file system, and can be sent to a remote logging server. Default is plain-text, but TLS encryption is a wise option. |
Events are initially logged only to a dedicated space of approximately 16MB within the cryptographic module, but can be exported, in encrypted state, to the host file system, and can further be sent to a remote logging server. |
|
Remote logging is generally a best practice. The receiving host and port configuration must not be the same for both remote syslog and remote audit log. See syslog remotehost add and audit remotehost add. |
||
| Security of logs | Appliance host logs are stored in plain text in the default log file location. They are as secure as the physical and digital access protection that you provide for the host and for any Remote Log Server you choose to use, and can be protected in transit by invoking TLS. |
Audit logs are protected by layers of encryption where they are created and initially reside, within the cryptographic module. They are encrypted when they move from the limited storage of the cryptographic module to the host file system, and remain encrypted if forwarded to a Remote Log Server. Their integrity is assured and the audit logs can be verified and unlocked by an HSM in the same security/cloning domain as the originating cryptographic module. |
| Log record and
file accumulation |
The appliance protects itself by deleting the oldest log files when/if they are allowed to accumulate to the point of filling the allotted space (see below). This allows the most recent logs to always be available. [* Remote logging is a best practice in virtually any logging scenario.] See Exporting System Logs and Deleting System Logs and Rotating System Logs. Log rotation on the Luna Network HSM 7 appliance ensures that cleanup occurs on a daily or weekly or monthly basis. NOTE The space in the syslog folder in the Luna Network HSM 7 appliance is 9.7GB; if you reach or exceed that, you begin losing the oldest logs, and your syslog configuration might be in need of adjustment for log rotation and remote logging. |
Audit log records accumulate in the limited space inside the HSM/cryptographic module (approximately 16MB in NVRAM) until that space approaches being full, at which time the cryptographic module stops performing cryptographic functions and partition creation, recording only audit log messages until the audit logs are rotated out (in encrypted form) to the host file system. Obviously, it should never be allowed to get to that state in a production environment. NOTE The space in NVRAM that is allocated to audit logs can handle in the range of a couple of hundred thousand entries. That might sound like a lot, and it is if you are prudent with audit configuration. However, see below. The space in the Luna Network HSM 7 file system for exported Audit logs is 220GB.
Once the crypto module's audit-log space is unclogged, cryptographic operations can resume. This design strategy protects the continuity of the audit logs - the audit trail - that is so important in compliance audits and forensic investigations. |
| Logging best practices |
Syslog is ubiquitous, as are compendia of best practices and advice. Confer with your organization's security and compliance teams for their requirements and wishes, regarding logging for network-connected equipment. At a minimum, consider automatic sending to a remote logging server, and invoking TLS for the transfer. Where both udp and tcp network protocols are available: •udp is faster, but can drop packets/records •tcp is slower, but verifies and resends if packets are missed or dropped. If you are in the financial industry, choose RELP for Remote Syslog, perhaps with a TLS wrapper. |
For Audit Logging, best practice is very application dependent. For (say) a certification authority you might configure •"First Asymmetric Key Usage Only" (value "='first'), •"HSM management" (value 'manage'), •access attempts (value 'access'), and •Key management events (value 'keymanage') -- Security and Compliance auditors are likely to want to know when the key was first used, but might not need a record of every usage, which would generate a lot of audit records. But, if a record of every usage is a requirement, then certainly configure for it, but also configure audit log export and rotation (and remote logging*) on a schedule that keeps the audit-log corner of the cryptographic module's NVRAM from filling up with the probable high volume of audit logs. In contrast, for an application that performs many key generations, ongoing operation would generate huge numbers of logs, and it might be sufficient to configure the crypto module to log only failures. Generally, avoid logging all possible events; start small and increase logging scope until you achieve an acceptable balance between •coverage of cryptographic module activity and •performance of the of the cryptographic module (logging activity does consume or divert HSM resources). [* Remote logging is a best practice in virtually any logging scenario.] |
Audit Logging Enhancement
Using Luna Appliance Software 7.9.0, Luna HSM Firmware 7.8.9, and Luna HSM Client 10.8.0 or newer, the audit logs provide an improved ability to track individual sessions and client activity.
Example
This example illustrates audit logs showing C_Initialize()/C_Finalize() markers with matching access IDs for NTLS with multiple clients (2) working against a single Luna Network HSM 7 appliance.
First, prepare the HSM
[localhost] lunash:>hsm sh Appliance Details: ================== Software Version: 7.9.0 HSM Details: ============ HSM Label: LNH_198 Serial #: 573407 Bootloader: 1.1.5 Firmware: 7.9.0 HSM Model: Luna K7 HSM Part Number: 808-000073-001 Authentication Method: Password HSM Admin login status: Not Logged In HSM Admin login attempts left: 3 before HSM zeroization! RPV Initialized: No Audit Role Initialized: Yes Remote Login Initialized: No Manually Zeroized: No Secure Transport Mode: No HSM Tamper State: No tamper(s) Partitions created on HSM: ========================== Partition: 1335066958566, Name: Test Number of partitions allowed: 100 Number of partitions created: 1 FIPS Operation: ===================== The HSM is NOT in FIPS approved operation mode. System Times: ============= HSM Time: Thu Oct 24 17:05:06 UTC 2024 Host Time: Thu Oct 24 17:05:07 UTC 2024 Difference: 1 sec HSM Storage Information: ======================== Maximum HSM Storage Space (Bytes): 67108864 Space In Use (Bytes): 1335925 Free Space Left (Bytes): 65772939 Environmental Information on HSM: ================================= Battery Voltage: 3.072 V Battery Warning Threshold Voltage: 2.750 V System Temp: 40 deg. C System Temp Warning Threshold: 75 deg. C Functionality Module HW: FM Ready ======================= Command Result : 0 (Success)
Log in as HSM SO.
[localhost] lunash:>hsm login Please enter the HSM Administrators' password: > ********** par creat'hsm login' successful. Command Result : 0 (Success)
Create some partitions.
[localhost] lunash:>par create -par Par1 -f
Force option used. Proceed prompt bypassed.
'partition create' successful.
Command Result : 0 (Success)
[localhost] lunash:>par create -par Par2 -v 1 -f
Force option used. Proceed prompt bypassed.
'partition create' successful.
Command Result : 0 (Success)
[localhost] lunash:>par l
Storage (bytes)
Partition ----------------------------------
Partition Name Version Objects Total Used Free
=================== ================================ =========== ======= ======= ======= =======
1335066958566 Test 0 0 648381 0 648381
1335066958567 Par1 0 0 648381 0 648381
1335066958568 Par2 1 0 648381 0 648381
Command Result : 0 (Success)
[localhost] lunash:>
Configure a client.
################################################################################################################
Client1
################################################################################################################
[root@aa1239 bin]# ./lunacm
lunacm (64-bit) v10.7.3. Copyright (c) 2024 Thales Group. All rights reserved.
Available HSMs:
Current Slot Id: None
lunacm:>ccfg dp -n 192.168.141.198 -c 192.168.140.45 -par Par1 -pw 1q@W3e$R -f -v
Please wait while we set up the connection to the HSM. This may take several minutes...
Using username "admin".
Last login: Thu Oct 24 13:04:58 2024 from 10.124.106.204
Luna Network HSM Command Line Shell v7.9.0. Copyright (c) 2024 Thales Group. All rights reserved.
Using username "admin".
Last login: Thu Oct 24 13:06:41 2024 from 192.168.140.45
Luna Network HSM Command Line Shell v7.9.0. Copyright (c) 2024 Thales Group. All rights reserved.
sysconf forceSOLogin show
HSM Administrator Login Enforcement is NOT enabled.
Command Result : 0 (Success)
Using username "admin".
Last login: Thu Oct 24 13:06:54 2024 from 192.168.140.45
Luna Network HSM Command Line Shell v7.9.0. Copyright (c) 2024 Thales Group. All rights reserved.
client list
No clients are registered.
Command Result : 0 (Success)
Using username "admin".
Last login: Thu Oct 24 13:07:08 2024 from 192.168.140.45
Luna Network HSM Command Line Shell v7.9.0. Copyright (c) 2024 Thales Group. All rights reserved.
partition list
Storage (bytes)
Partition ----------------------------------
Partition Name Version Objects Total Used Free
=================== ================================ =========== ======= ======= ======= =======
1335066958566 Test 0 0 648381 0 648381
1335066958567 Par1 0 0 648381 0 648381
1335066958568 Par2 1 0 648381 0 648381
Command Result : 0 (Success)
Exiting...
Command Result : 0 (Success)
192.168.140.45.pem | 1 kB | 1.1 kB/s | ETA: 00:00:00 | 100%
server.pem | 1 kB | 1.1 kB/s | ETA: 00:00:00 | 100%
New server 192.168.141.198 successfully added to server list.
Using username "admin".
Last login: Thu Oct 24 13:07:21 2024 from 192.168.140.45
Luna Network HSM Command Line Shell v7.9.0. Copyright (c) 2024 Thales Group. All rights reserved.
client register -c 192.168.140.45 -i 192.168.140.45
'client register' successful.
client assignPartition -c 192.168.140.45 -p "Par1"
'client assignPartition' successful.
Command Result : 0 (Success)
The following Luna SA Slots/Partitions were found:
Slot Serial # Label
==== ================ =====
0 1335066958567
Reloading Configuration and slot(s)...
Command Result : No Error
lunacm (64-bit) v10.7.3. Copyright (c) 2024 Thales Group. All rights reserved.
Available HSMs:
Slot Id -> 0
Label ->
Serial Number -> 1335066958567
Model -> LunaSA 7.9.0
Firmware Version -> 7.9.0
Bootloader Version -> 1.1.5
Configuration -> Luna User Partition With SO (PW) Key Export With Cloning Mode
Slot Description -> Net Token Slot
FM HW Status -> FM Ready
Current Slot Id: 0
lunacm:>par init -l Par1 -p userpin123 -d Thales -f -a
Initialization was successful and '-auth' was specified.
Performing a 'Partition SO' login.
Command Result : No Error
lunacm:>e
View logs
[root@aa1239 bin]# 92871,24/10/24 17:08:07,S/N 573407 Access 13538f8fcc265576 external message follows: lunacm(2462536) : Hostname aa1239 : User root : S/N 1335066958567 : C_Initialize() 92872,24/10/24 17:08:07,S/N 573407 Access 13538f8fcc265576 external message follows: S/N 1335066958567 : Partition Label not set 92873,24/10/24 17:08:07,S/N 1335066958567 session 2 Access 13538f8fcc265576 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 2 92874,24/10/24 17:08:07,S/N 573407 Access c9208868de52bcfe external message follows: Access F654004FDC4E08CA367B8A8D9767F3B9 from 192.168.140.45:33928 is mapped to 7923CFFB2513811305E5C2 92875,24/10/24 17:08:07,S/N 1335066958567 session 2 Access 13538f8fcc265576 operation LUNA_CLOSE_SESSION returned RC_OK(0x00000000) session handle 2 92883,24/10/24 17:08:27,S/N 1335066958567 operation LUNA_PARTITION_INIT returned RC_OK(0x00000000) 92884,24/10/24 17:08:27,S/N 1335066958567 session 2 Access 13538f8fcc265576 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 2 92885,24/10/24 17:08:27,S/N 573407 Access c9208868de52bcfe external message follows: Access F654004FDC4E08CA367B8A8D9767F3B9 from 192.168.140.45:33928 is mapped to 7923CFFB2513811305E5C2 92886,24/10/24 17:08:27,S/N 1335066958567 session 2 Access 13538f8fcc265576 operation LUNA_LOGIN returned RC_OK(0x00000000) roleID=1 container=15 92887,24/10/24 17:08:27,S/N 1335066958567 session 2 Access 13538f8fcc265576 operation LUNA_GEN_KCV returned RC_OK(0x00000000) container=15 92888,24/10/24 17:08:27,S/N 1335066958567 session 2 Access 13538f8fcc265576 operation LUNA_LOGOUT returned RC_OK(0x00000000) roleID=1 container=15 92889,24/10/24 17:08:27,S/N 1335066958567 session 2 Access 13538f8fcc265576 operation LUNA_CLOSE_SESSION returned RC_OK(0x00000000) session handle 2 92890,24/10/24 17:08:27,S/N 1335066958567 session 2 Access 13538f8fcc265576 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 2 92891,24/10/24 17:08:27,S/N 573407 Access c9208868de52bcfe external message follows: Access F654004FDC4E08CA367B8A8D9767F3B9 from 192.168.140.45:33928 is mapped to 7923CFFB2513811305E5C2 92892,24/10/24 17:08:27,S/N 1335066958567 session 2 Access 13538f8fcc265576 operation LUNA_LOGIN returned RC_OK(0x00000000) roleID=1 container=15 92893,24/10/24 17:08:27,S/N 1335066958567 session 2 Access 13538f8fcc265576 operation LUNA_AUTHORIZE_KEY returned RC_OK(0x00000000) 92894,24/10/24 17:08:32,S/N 1335066958567 session 2 Access 13538f8fcc265576 operation LUNA_CLOSE_SESSION returned RC_OK(0x00000000) session handle 2 92895,24/10/24 17:08:32,S/N 573407 Access 13538f8fcc265576 external message follows: lunacm(2462536) : Hostname aa1239 : User root : S/N 1335066958567 : C_Finalize()
Configure another client
################################################################################################################
Client2
################################################################################################################
[root@aa4803 bin]# ./lunacm
lunacm (64-bit) v10.7.3. Copyright (c) 2024 Thales Group. All rights reserved.
Available HSMs:
Current Slot Id: None
lunacm:>ccfg dp -n 192.168.141.198 -c 192.168.141.169 -par Par2 -pw 1q@W3e$R -f -v
Please wait while we set up the connection to the HSM. This may take several minutes...
Using username "admin".
Last login: Thu Oct 24 13:25:34 2024 from 192.168.141.169
Luna Network HSM Command Line Shell v7.9.0. Copyright (c) 2024 Thales Group. All rights reserved.
Using username "admin".
Last login: Thu Oct 24 13:25:44 2024 from 192.168.141.169
Luna Network HSM Command Line Shell v7.9.0. Copyright (c) 2024 Thales Group. All rights reserved.
sysconf forceSOLogin show
HSM Administrator Login Enforcement is NOT enabled.
Command Result : 0 (Success)
Using username "admin".
Last login: Thu Oct 24 13:25:57 2024 from 192.168.141.169
Luna Network HSM Command Line Shell v7.9.0. Copyright (c) 2024 Thales Group. All rights reserved.
client list
registered client 1: 192.168.140.45
Command Result : 0 (Success)
Using username "admin".
Last login: Thu Oct 24 13:26:10 2024 from 192.168.141.169
Luna Network HSM Command Line Shell v7.9.0. Copyright (c) 2024 Thales Group. All rights reserved.
partition list
Storage (bytes)
Partition ----------------------------------
Partition Name Version Objects Total Used Free
=================== ================================ =========== ======= ======= ======= =======
1335066958566 Test 0 0 648381 0 648381
1335066958567 Par1 0 0 648381 0 648381
1335066958568 Par2 1 0 648381 0 648381
Command Result : 0 (Success)
Exiting...
Command Result : 0 (Success)
Private Key created and written to: /usr/safenet/lunaclient/cert/client/192.168.141.169Key.pem
Certificate created and written to: /usr/safenet/lunaclient/cert/client/192.168.141.169.pem
192.168.141.169.pem | 1 kB | 1.1 kB/s | ETA: 00:00:00 | 100%
server.pem | 1 kB | 1.1 kB/s | ETA: 00:00:00 | 100%
New server 10.124.141.198 successfully added to server list.
Using username "admin".
Last login: Thu Oct 24 13:26:23 2024 from 192.168.141.169
Luna Network HSM Command Line Shell v7.9.0. Copyright (c) 2024 Thales Group. All rights reserved.
client register -c 192.168.141.169 -i 192.168.141.169
'client register' successful.
client assignPartition -c 192.168.141.169 -p "Par2"
'client assignPartition' successful.
Command Result : 0 (Success)
The following Luna SA Slots/Partitions were found:
Slot Serial # Label
==== ================ =====
0 1335066958568
Reloading Configuration and slot(s)...
Command Result : No Error
lunacm (64-bit) v10.7.3. Copyright (c) 2024 Thales Group. All rights reserved.
Available HSMs:
Slot Id -> 0
Label ->
Serial Number -> 1335066958568
Model -> LunaSA 7.9.0
Firmware Version -> 7.9.0
Bootloader Version -> 1.1.5
Configuration -> Luna User Partition With SO (PW) Key Export With Cloning Mode
Slot Description -> Net Token Slot
FM HW Status -> FM Ready
Current Slot Id: 0
lunacm:>par init -l Pri2 -p userpin123 -d Thales -f -a
Initialization was successful and '-auth' was specified.
Performing a 'Partition SO' login.
Command Result : No Error
lunacm:>e
View logs.
[root@aa4803 bin]# 93167,24/10/24 17:27:12,S/N 573407 Access 0ef36e945c388a74 external message follows: lunacm(1740793) : Hostname aa4803 : User root : S/N 1335066958568 : C_Initialize() 93168,24/10/24 17:27:12,S/N 573407 Access 0ef36e945c388a74 external message follows: S/N 1335066958568 : Partition Label not set 93169,24/10/24 17:27:12,S/N 1335066958568 session 2 Access 0ef36e945c388a74 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 2 93170,24/10/24 17:27:12,S/N 573407 Access c9208868de52bcfe external message follows: Access 55882F7C1564D99F6B5DDD44A4466595 from 192.168.141.169:53336 is mapped to 6316307ADD431B95F458C 93171,24/10/24 17:27:12,S/N 1335066958568 session 2 Access 0ef36e945c388a74 operation LUNA_CLOSE_SESSION returned RC_OK(0x00000000) session handle 2 93172,24/10/24 17:27:27,S/N 1335066958568 operation LUNA_PARTITION_INIT returned RC_OK(0x00000000) 93173,24/10/24 17:27:27,S/N 1335066958568 session 2 Access 0ef36e945c388a74 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 2 93174,24/10/24 17:27:27,S/N 573407 Access c9208868de52bcfe external message follows: Access 55882F7C1564D99F6B5DDD44A4466595 from 192.168.141.169:53336 is mapped to 6316307ADD431B95F458C 93175,24/10/24 17:27:27,S/N 1335066958568 session 2 Access 0ef36e945c388a74 operation LUNA_LOGIN returned RC_OK(0x00000000) roleID=1 container=72 93176,24/10/24 17:27:27,S/N 1335066958568 session 2 Access 0ef36e945c388a74 operation LUNA_GEN_KCV returned RC_OK(0x00000000) container=72 93177,24/10/24 17:27:27,S/N 1335066958568 session 2 Access 0ef36e945c388a74 operation LUNA_LOGOUT returned RC_OK(0x00000000) roleID=1 container=72 93178,24/10/24 17:27:27,S/N 1335066958568 session 2 Access 0ef36e945c388a74 operation LUNA_CLOSE_SESSION returned RC_OK(0x00000000) session handle 2 93179,24/10/24 17:27:27,S/N 1335066958568 session 2 Access 0ef36e945c388a74 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 2 93180,24/10/24 17:27:27,S/N 573407 Access c9208868de52bcfe external message follows: Access 55882F7C1564D99F6B5DDD44A4466595 from 192.168.141.169:53336 is mapped to 6316307ADD431B95F458C 93181,24/10/24 17:27:27,S/N 1335066958568 session 2 Access 0ef36e945c388a74 operation LUNA_LOGIN returned RC_OK(0x00000000) roleID=1 container=72 93182,24/10/24 17:27:27,S/N 1335066958568 session 2 Access 0ef36e945c388a74 operation LUNA_AUTHORIZE_KEY returned RC_OK(0x00000000) 93183,24/10/24 17:27:32,S/N 1335066958568 session 2 Access 0ef36e945c388a74 operation LUNA_CLOSE_SESSION returned RC_OK(0x00000000) session handle 2 93184,24/10/24 17:27:32,S/N 573407 Access 0ef36e945c388a74 external message follows: lunacm(1740793) : Hostname aa4803 : User root : S/N 1335066958568 : C_Finalize()
