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
>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 PCIe 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 PCIe 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 PCIe 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
>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.]
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
A Luna PCIe 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 LunaCM command role init -name Auditor to initialize the audit role, as described in role init.
Password-authenticated HSMs
For Luna PCIe 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 PCIe 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
Audit Role Available Commands
In LunaCM, all commands are visible to the person who launches the utility, and some can be used without specific authentication to the HSM, such as view/show/list commands, which might be classified as "monitoring" functions. Attempts to run operational or administrative commands that need role-specific authentication, without that authentication, result in an error message. The Audit role has a limited set of operations available to it, on the HSM, which constitutes any of the generally accessible monitoring commands, plus everything under the "audit" heading.
lunacm:>audit The following sub commands are available: Command Short Description ------------------------------------ verify v Verify a block of log messages config c Configure audit parameters export e Read the wrapped log secret from the HSM import m Import the wrapped log secret to the HSM time t Sync HSM time to host, or get HSM time status s Show status of logging subsystem logmsg logm Write a message to the HSM's log Syntax: audit <sub command> Command Result : No Error
Anyone accessing the computer and running LunaCM can see the above commands, but cannot run them if they do not have the "audit" role authentication (password or PED key, as appropriate).
What is important is not the role you can access on the computer (a named user, admin, operator), but the role you can access within the HSM.
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 time get, 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.
Ensure that you have set audit config correctly to rotate logs to the file system periodically in order to avoid this situation. In particular:
>filepath points to an existing location (no typos or other errors in specifying the filepath for log files)
>writing to that location is permitted (check the folder/directory permissions)
>the indicated location has sufficient space available to write log files (make some room if necessary).
See the later steps in Configuring Audit Logging for the 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.
Audit Logging Stops Working if the Current Log File is Deleted
As a general rule, you should not delete a file while it is open and in use by an application. In Linux, deletion of a file is deletion of an inode, but the actual file itself, while now invisible, remains on the file system until the space is cleaned up or overwritten. If a file is in use by an application - such as audit logging, in this case - the application can continue using and updating that file, unaware that it is now in deleted status.
If you delete the current audit log file, the audit logging feature does not detect that and does not create a new file, so you might lose log entries.
The workaround is to restart the pedclient daemon, which creates a new log file.
Example
1.You have configured audit logging, and the entire audit path is deleted. In Linux, the file isn’t actually deleted until the last reference to the file has been destroyed. Since the pedclient has the file open, logging continues, because technically the log file still exists. Applications, including the pedclient, have no idea that anything is wrong.
2.Upon stopping the pedclient, the log file is deleted. When the pedclient gets started again, the HSM tries to tell the pedclient to use the old path. This path doesn’t exist anymore, so log messages are not offloaded. At this point, the HSM starts storing log messages internally. With 16 MB of Flash memory dedicated to this purpose, that works out to 198,120 messages, maximum. This space can actually fill up very quickly, in as little as a few minutes under heavy load.
3.At this point the user must set the audit log path to a valid value. and the HSM offloads all stored log messages to the host. This takes a couple of minutes, during which time the HSM is unresponsive.
4.Once all messages have been offloaded, normal operation resumes with messages being sent to the host and not being stored locally inside the HSM.
Audit Logging Enhancement
Using 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 our test application multitoken running multiple threads on a Luna PCIe HSM 7
Prepare a Luna HSM.
C:\Program Files\SafeNet\LunaClient>lunacm.exe
lunacm.exe (64-bit) v10.7.3. Copyright (c) 2024 Thales Group. All rights reserved.
Available HSMs:
Slot Id -> 3
Label -> K7_new
Serial Number -> 1213492132454
Model -> Luna K7
Firmware Version -> 7.8.7
Bootloader Version -> 1.1.5
Configuration -> Luna User Partition With SO (PW) Key Export With Cloning Mode
Slot Description -> User Token Slot
FM HW Status -> FM Ready
Slot Id -> 103
Label -> K7_admin
Serial Number -> 521191
Model -> Luna K7
Firmware Version -> 7.8.7
Bootloader Version -> 1.1.5
Configuration -> Luna HSM Admin Partition (PW) Key Export With Cloning Mode
Slot Description -> Admin Token Slot
FM HW Status -> FM Ready
HSM Configuration -> Luna HSM Admin Partition (PW)
HSM Status -> L3 Device
HSM Certificates -> *** Test Certs ***
Current Slot Id: 3
lunacm:> par sp
Partition Capabilities
0: Enable private key cloning : 1
1: Enable private key wrapping : 1
2: Enable private key unwrapping : 1
3: Enable private key masking : 1
4: Enable secret key cloning : 1
5: Enable secret key wrapping : 1
6: Enable secret key unwrapping : 1
7: Enable secret key masking : 1
9: Enable digest key : 1
10: Enable multipurpose keys : 1
11: Enable changing key attributes : 1
15: Allow failed challenge responses : 1
16: Enable operation without RSA blinding : 1
17: Enable signing with non-local keys : 1
18: Enable raw RSA operations : 1
20: Max failed user logins allowed : 10
21: Enable high availability recovery : 1
22: Enable activation : 0
23: Enable auto-activation : 0
25: Minimum pin length (inverted: 255 - min) : 247
26: Maximum pin length : 255
28: Enable Key Management Functions : 1
29: Enable RSA signing without confirmation : 1
31: Enable private key unmasking : 1
32: Enable secret key unmasking : 1
33: Enable RSA PKCS mechanism : 1
34: Enable CBC-PAD (un)wrap keys of any size : 1
37: Enable enforcing Secure Trusted Channel : 1
39: Enable Start/End Date Attributes : 1
40: Enable Per-Key Authorization Data : 1
41: Enable Partition Version : 1
42: Enable CPv1 : 1
43: Enable non-FIPS algorithms : 1
44: Enable Extended Domain Management : 1
Partition Policies
0: Allow private key cloning : 1
1: Allow private key wrapping : 0
2: Allow private key unwrapping : 1
3: Allow private key masking : 0
4: Allow secret key cloning : 1
5: Allow secret key wrapping : 1
6: Allow secret key unwrapping : 1
7: Allow secret key masking : 0
9: Allow digest key : 0
10: Allow multipurpose keys : 1
11: Allow changing key attributes : 1
15: Ignore failed challenge responses : 1
16: Operate without RSA blinding : 1
17: Allow signing with non-local keys : 1
18: Allow raw RSA operations : 1
20: Max failed user logins allowed : 10
21: Allow high availability recovery : 1
25: Minimum pin length (inverted: 255 - min) : 247
26: Maximum pin length : 255
28: Allow Key Management Functions : 1
29: Perform RSA signing without confirmation : 1
31: Allow private key unmasking : 0
32: Allow secret key unmasking : 0
33: Allow RSA PKCS mechanism : 1
34: Allow CBC-PAD (un)wrap keys of any size : 1
37: Force Secure Trusted Channel : 0
39: Allow Start/End Date Attributes : 0
40: Require Per-Key Authorization Data : 0
41: Partition Version : 0
42: Allow CPv1 : 1
43: Allow non-FIPS algorithms : 1
44: Allow Extended Domain Management : 0
Command Result : No Error
lunacm:> e
C:\Program Files\SafeNet\LunaClient>
Launch multitoken with multiple threads.
C:\Program Files\SafeNet\LunaClient>multitoken.exe -m rsasigver -ns 3x5 -t 5 -password userpin123
multitoken.exe (64-bit) v10.7.3. Copyright (c) 2024 Thales Group. All rights reserved.
Warning: packet size not specified. Using default packet size of 16.
Warning: Key size not specified. Using default key size of 2048.
Initializing library...Finished Initializing
...done.
Do you wish to continue?
Enter 'y' or 'n': y
Constructing thread objects.
Logging in to tokens...
slot 3... Serial Number 1213492132454
Please wait, creating test threads.
Test threads created successfully. Test will run for 5 secs
RSA sign/verify 2048-bit : (packet size = 16 bytes)
Using token objects.
Logged in as Crypto Officer.
+ operations/second | elapsed
3, 0 3, 4 | total average | time (secs)
------ ------ | ------- ---------- | ------------
407.5 407.7 | 2037.7 2037.717* | 5
Waiting for threads to terminate.
C:\Program Files\SafeNet\LunaClient>
View audit logs
,705FD060F4AAE21B17B6DB14F5715BDB1393CA4E8A385D7CB64C6EDB58613C95,A4AA17400140CA006D1720670000000084B013DA0F91833AE7F3070000000000000000006C756E61636D2E657865283534373200
1551013,24/10/28 23:04:17,S/N 521191 Access d3c8c43fb2783150 external message follows: multitoken.exe(5604) : Hostname AA1239 : User Administrator : S/N 1213492132454 : C_Initialize() ,5ECB1873AD9C1EFA26AC317DBC3E9913BF9737A537BD44C3DEE22C30E412DD1F,A5AA17400140CA007118206700000000D3C8C43FB2783150E7F3070000000000000000006D756C7469746F6B656E2E6578652800
1551014,24/10/28 23:04:17,S/N 521191 Access d3c8c43fb2783150 external message follows: S/N 1213492132454 : Partition K7_new ,A45D090CD84C87C1DA607663A14172B2BEEFC9D51B7C4A07E880AD4A1F63352A,A6AA17400140CA007118206700000000D3C8C43FB2783150E7F307000000000000000000532F4E20313231333439323133323400
1551015,24/10/28 23:04:22,S/N 1213492132454 session 1 Access d3c8c43fb2783150 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 1 ,1F5A87E3B45783C602821F242275F32BD762C62C7FA3B6F308726A02CE77E66D,A7AA1740826024007618206700000000D3C8C43FB2783150667AC4891A0100000100000000000000000000000000000000000000
1551016,24/10/28 23:04:22,S/N 1213492132454 session 1 Access d3c8c43fb2783150 operation LUNA_LOGIN returned RC_OK(0x00000000) roleID=0 container=4 ,EE1479D301ACA2EB270DD506A18A1E597709727EE4E332C23144D9C4905FD50D,A8AA174002600D007618206700000000D3C8C43FB2783150667AC4891A0100000100000004000000070000000000000000000000
1551017,24/10/28 23:04:22,S/N 1213492132454 session 1 Access d3c8c43fb2783150 operation LUNA_AUTHORIZE_KEY returned RC_OK(0x00000000) ,114C9ED38FC3D4FB69C114677478BC372CDA55976E531A1CB58EFFC537190669,A9AA174005600F017618206700000000D3C8C43FB2783150667AC4891A0100000100000000000000000000000000000000000000
1551018,24/10/28 23:04:22,S/N 1213492132454 session 2 Access d3c8c43fb2783150 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 2 ,E5CBDAA34E9AA38CCAE99E4322FB6BC99727194DBFA6BCDA7190C49EF4FD34BA,AAAA1740826024007618206700000000D3C8C43FB2783150667AC4891A0100000200000000000000000000000000000000000000
1551019,24/10/28 23:04:22,S/N 1213492132454 session 3 Access d3c8c43fb2783150 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 3 ,FD3E4AC41E184C7BD9BE42CBDFE51627AABBD54301864420CAA0BD79DD66EFA8,ABAA1740826024007618206700000000D3C8C43FB2783150667AC4891A0100000300000000000000000000000000000000000000
1551020,24/10/28 23:04:22,S/N 1213492132454 session 4 Access d3c8c43fb2783150 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 4 ,4AF6B8AE67F6B1502B3CE0FD49D07FA923EF71E2FB31A77D92726907B9AB9E58,ACAA1740826024007618206700000000D3C8C43FB2783150667AC4891A0100000400000000000000000000000000000000000000
1551021,24/10/28 23:04:22,S/N 1213492132454 session 5 Access d3c8c43fb2783150 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 5 ,F5BEDCDBC2F5AE581719FCF79BF3DAA520CACD9718FE9924B4EE5F1E915F9E52,ADAA1740826024007618206700000000D3C8C43FB2783150667AC4891A0100000500000000000000000000000000000000000000
1551022,24/10/28 23:04:22,S/N 1213492132454 session 6 Access d3c8c43fb2783150 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 6 ,4404B5DD18FDE70461E50F3F20061AB54225668CFF865A329F48A4B8F0F9C250,AEAA1740826024007618206700000000D3C8C43FB2783150667AC4891A0100000600000000000000000000000000000000000000
1551023,24/10/28 23:04:22,S/N 1213492132454 session 2 Access d3c8c43fb2783150 operation LUNA_GENERATE_KEY_PAIR returned RC_OK(0x00000000) (generated private/public key handles=74/75) ,BAEE923CD7E1FF827B781A9C059C2AD51FB1F24D158DC4B748447F4689E22F6F,AFAA1740046019007618206700000000D3C8C43FB2783150667AC4891A01000002000000000000004B0000004A00000000000000
1551024,24/10/28 23:04:22,S/N 1213492132454 session 7 Access d3c8c43fb2783150 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 7 ,5E090FB546EFFAF1FCC8D024A7EF321ECD93B63EF6B12BE88B7B83AC1FC7D0D0,B0AA1740826024007618206700000000D3C8C43FB2783150667AC4891A0100000700000000000000000000000000000000000000
1551025,24/10/28 23:04:22,S/N 1213492132454 session 8 Access d3c8c43fb2783150 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 8 ,4792EDEF59F63D60869D8533A135E7AF1E727C459699EBE8A672D66D78BF0760,B1AA1740826024007618206700000000D3C8C43FB2783150667AC4891A0100000800000000000000000000000000000000000000
1551026,24/10/28 23:04:22,S/N 1213492132454 session 9 Access d3c8c43fb2783150 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 9 ,B6E4CC208F67C9ACC3650239774BCCCD863D11A7D0C38DFC0264D25A2DF32840,B2AA1740826024007618206700000000D3C8C43FB2783150667AC4891A0100000900000000000000000000000000000000000000
1551027,24/10/28 23:04:22,S/N 1213492132454 session 10 Access d3c8c43fb2783150 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 10 ,50F1329A1D5DA02C02698992A09C0B0FF700B80C5FD4C19E3E7A04E28AF5F0E5,B3AA1740826024007618206700000000D3C8C43FB2783150667AC4891A0100000A00000000000000000000000000000000000000
1551028,24/10/28 23:04:22,S/N 1213492132454 session 11 Access d3c8c43fb2783150 operation LUNA_OPEN_SESSION returned RC_OK(0x00000000) session handle 11 ,E5B4BC049AE3C25E7DCDC73DAD52E5881F416C0F0F99C688BE9AF791DC390CDD,B4AA1740826024007618206700000000D3C8C43FB2783150667AC4891A0100000B00000000000000000000000000000000000000
1551029,24/10/28 23:04:22,S/N 1213492132454 session 8 Access d3c8c43fb2783150 operation LUNA_SIGN_SINGLEPART returned RC_OK(0x00000000) (object handle=74) ,262CDBA90F5F481A510D92118C5B77B3992992E8401225D6BD9710A9D9EFB71B,B5AA17400A6069007618206700000000D3C8C43FB2783150667AC4891A01000008000000000000004A0000000000000000000000
1551030,24/10/28 23:04:22,S/N 1213492132454 session 9 Access d3c8c43fb2783150 operation LUNA_SIGN_SINGLEPART returned RC_OK(0x00000000) (object handle=74) ,AF0CB4C42596023D8579807232D9592F48C2D4BB884010E3BEE77C1828C0E459,B6AA17400A6069007618206700000000D3C8C43FB2783150667AC4891A01000009000000000000004A0000000000000000000000
1551031,24/10/28 23:04:22,S/N 1213492132454 session 7 Access d3c8c43fb2783150 operation LUNA_SIGN_SINGLEPART returned RC_OK(0x00000000) (object handle=74) ,820D9E6ED77088E125628FA3F33C34DCF99C26B4A9D8019848980F1A236C159A,B7AA17400A6069007618206700000000D3C8C43FB2783150667AC4891A01000007000000000000004A0000000000000000000000
1551032,24/10/28 23:04:22,S/N 1213492132454 session 10 Access d3c8c43fb2783150 operation LUNA_SIGN_SINGLEPART returned RC_OK(0x00000000) (object handle=74) ,44F08AA37991C20CE5936C1C8FE814BD63C700D821DC07A2EBE1B7615C688EBC,B8AA17400A6069007618206700000000D3C8C43FB2783150667AC4891A0100000A000000000000004A0000000000000000000000
1551033,24/10/28 23:04:22,S/N 1213492132454 session 11 Access d3c8c43fb2783150 operation LUNA_SIGN_SINGLEPART returned RC_OK(0x00000000) (object handle=74) ,BF7CC4E8A42A3568BB6519CD008E3EB3C664CE9C13CFD68FB0001CC87D01CA2E,B9AA17400A6069007618206700000000D3C8C43FB2783150667AC4891A0100000B000000000000004A0000000000000000000000
1551034,24/10/28 23:04:22,S/N 1213492132454 session 8 Access d3c8c43fb2783150 operation LUNA_VERIFY_SINGLEPART returned RC_OK(0x00000000) (using key handle=75) ,1E69B34A91E9D99FB8A36362F5FCDD7014546C47B138D781055D14F5434F7FF0,BAAA17400A606A007618206700000000D3C8C43FB2783150667AC4891A01000008000000000000004B0000000000000000000000
1551035,24/10/28 23:04:22,S/N 1213492132454 session 9 Access d3c8c43fb2783150 operation LUNA_VERIFY_SINGLEPART returned RC_OK(0x00000000) (using key handle=75)
,C68BEAEEC22BCDEA3089B0FA6B87D5D5197E24DB851570AB52A20D1443001EE6,2C0B1840026026007B18206700000000D3C8C43FB2783150667AC4891A0100000600000000000000000000000000000000000000
1575725,24/10/28 23:04:27,S/N 1213492132454 session 2 Access d3c8c43fb2783150 operation LUNA_DESTROY_OBJECT returned RC_OK(0x00000000) (object handle=74) ,C5400F83F81455AA3228F43A7DEE9D01DD38E78DA680B4D2C1F82D3068156567,2D0B1840046011007B18206700000000D3C8C43FB2783150667AC4891A01000002000000000000004A0000000000000000000000
1575726,24/10/28 23:04:27,S/N 1213492132454 session 2 Access d3c8c43fb2783150 operation LUNA_DESTROY_OBJECT returned RC_OK(0x00000000) (object handle=75) ,77C250C062B6615046E527921E42EAAD026E535ACB78B68B7A375DFDC71AF5A6,2E0B1840046011007B18206700000000D3C8C43FB2783150667AC4891A01000002000000000000004B0000000000000000000000
1575727,24/10/28 23:04:27,S/N 1213492132454 session 2 Access d3c8c43fb2783150 operation LUNA_CLOSE_SESSION returned RC_OK(0x00000000) session handle 2 ,9944504D25D6EFBF6314F9FBBF0157E378F11E65AE9E42025F39CC264E9A7938,2F0B1840026026007B18206700000000D3C8C43FB2783150667AC4891A0100000200000000000000000000000000000000000000
1575728,24/10/28 23:04:27,S/N 1213492132454 session 3 Access d3c8c43fb2783150 operation LUNA_CLOSE_SESSION returned RC_OK(0x00000000) session handle 3 ,6E7C33E2A8A9F595A112BE19ABA3B21ED11BC4BC8983C0AB9A092E1549403CF8,300B1840026026007B18206700000000D3C8C43FB2783150667AC4891A0100000300000000000000000000000000000000000000
1575729,24/10/28 23:04:27,S/N 1213492132454 session 5 Access d3c8c43fb2783150 operation LUNA_CLOSE_SESSION returned RC_OK(0x00000000) session handle 5 ,F70318339AEA97C7005E37967DC6CE5D180A085F3F3FB74F0ACCD9D24E51054F,310B1840026026007B18206700000000D3C8C43FB2783150667AC4891A0100000500000000000000000000000000000000000000
1575730,24/10/28 23:04:27,S/N 1213492132454 session 4 Access d3c8c43fb2783150 operation LUNA_CLOSE_SESSION returned RC_OK(0x00000000) session handle 4 ,7CEC50BBDCA439F2B30C7F58A38D97D9F24F9E0067ECDB54A1728CBCE4EB9C3F,320B1840026026007B18206700000000D3C8C43FB2783150667AC4891A0100000400000000000000000000000000000000000000
1575731,24/10/28 23:04:32,S/N 1213492132454 session 1 Access d3c8c43fb2783150 operation LUNA_CLOSE_SESSION returned RC_OK(0x00000000) session handle 1 ,4DBD5342C7D879BF015CD90F85461306003B517B82CB8944CF1A1E46F96D1D62,330B1840026026008018206700000000D3C8C43FB2783150667AC4891A0100000100000000000000000000000000000000000000
1575732,24/10/28 23:04:32,S/N 521191 Access d3c8c43fb2783150 external message follows: multitoken.exe(5604) : Hostname AA1239 : User Administrator : S/N 1213492132454 : C_Finalize()
