|
Home > |
|---|
Beginning with Luna HSM 5.2, Luna HSMs consolidate and enhance auditing of HSM operations.
For Luna PCI and Luna G5 (and the Luna Backup HSM), the audit logging is managed by the HSM Audit role, through a set of lunacm:> 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.
For factory configured Luna HSMs, and after upgrading earlier Luna HSM versions to Luna HSM 5.2, the HSM supports an audit role with authentication via a white Audit PED Key (or an "audit" password for password-authenticated HSMs).
A Luna HSM Audit role allows complete separation of Audit responsibilities from the Security Officer (SO or HSM Admin), the Partition User (or Owner), and other HSM roles. If the Audit role is initialized, the HSM and Partition administrators are prevented from working with the log files, and auditors are unable to perform administrative tasks on the HSM.
For Luna HSMs with Password Authentication, the auditor logs into the HSM to perform his/her activities using a password, which can be different from the Security Officer (SO) or Partition User passwords, in order to keep the roles separate.
For Luna HSMs with PED Authentication, the auditor logs in to perform his/her activities using a white PED Key. The Audit feature works only with Luna PED version 2.5.0-1 or newer. Older versions of PED firmware are not aware of the Audit role and Audit Key.
Audit initialization - creating the Auditor role (and imprinting the white PED Key for PED authenticated HSMs) does not require the presence or cooperation of the HSM SO.
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 ------------------------------------ changePw changePw Change Audit Password init i Initialize HSM Audit User login logi Login HSM as Audit logout logo Logout HSM as Audit 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 lunacm:>
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, root), but the role you can access within the HSM.
Here is a summary overview of the security audit logging feature:
•Log entries originate from the Luna HSM
•Each entry includes the when, who, what, and result of the logging event
•Multiple categories of audit logging are supported
•Audit management is a separate role - the role creation does not require the presence or cooperation of the Luna HSM SO
•The category of audit logging is configurable by (and only by) the audit role
•Audit log integrity is ensured against -
- 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
•Log origin is assured
•Certain critical events are logged unconditionally, regardless of the state of the audit role (initialized or not) -
- Tamper
- Decommission
- Zeroization
- SO creation
- Audit role creation
When manufactured, each HSM computes a 256-bit (or 32 bytes) secret random number, called the “log secret”, and saves it on the HSM Flash memory. The log secret is later used to prove that a log record originated from that HSM.
When the HSM needs to log a message, it computes the SHA256-HMAC of all data to be logged, plus the HMAC of the previous log entry, and the log secret. The HMAC is stored in HSM RAM. The record 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 record on the host hard drive. If this is the very first record to be sent to the host ever, then there is no previous HMAC; in this case, the HMAC is set to all zeroes. 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 end-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 in exactly 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 one 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. When checking truncation, the host would send the newest record in its log; and, the HSM would compute the HMAC and compare it to the one in flash. If it does not match, then truncation has occurred.
Each message is a fixed-length, newline-terminated string. The table below shows the width and meaning of the fields in a message.
| Offset | Count | 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 | 88 | Data for this record as ASCII-HEX (raw data) |
| 439 | 1 | Newline '\n' |
The raw data for the message is stored in ASCII-HEX form, along with a human-readable version. This makes messages larger, but simplifies the verification process, as the HSM expects raw data records to work with.
The following is a sample log record. It is separated into multiple lines for readability even though it is a one-line 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 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)”.
The HMAC of previous record is “29C51014B6F131EC67CF48734101BBE301335C25F43EDF8828745C40755ABE25”.
The remainder is the raw data for this record in the form of ASCII-HEX.
Log Rotation Categories, Rotation Intervals, and other Configurable Factors are covered here in the Administration & Maintenance Manual. Command syntax is in the Reference Manual.
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 audit officer is allowed to synchronize the time.
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 this, the HSM generates a key-cloning vector (KCV, a.k.a the Domain key) for the audit role whenever 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, assuming that HSM is in the same domain, the host passes to the target HSM the wrapped secret, which the HSM subsequently decrypts; any records submitted to the 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 to a separate parameter area for the wrapped log secret.
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.
The log capacity of Luna HSMs varies depending upon the physical memory available on the device. The Luna PCI-E HSM and the HSM contained in the Luna SA appliance are the SafeNet K6 HSM card. The HSM inside both the Luna G5 and the Luna [Remote] Backup HSM is the SafeNet G5 HSM module.
The K6 HSM has approximately 16 MB available for Audit logging (or more than 200,000 records, depending on the size/content of each record).
The G5 HSM has approximately 4 MB available for Audit logging (or more than 50,000 records, depending on the size/content of each record).
In both cases, the normal function of Audit Logging is to export log entries constantly to the file system. Short-term, within-the-HSM log storage capacity becomes important only in the rare situations where the HSM remains functioning but the file system is unreachable from the HSM. This would be a rare or unlikely event for an HSM connected to a server or workstation, and almost unheard-of in the closed and hardened environment of (for example) a Luna SA appliance.
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.
Audit Logging configuration is not removed or reset upon HSM re-initialization. It survives tamper and factory reset. 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 SO cannot modify the logging configuration, and therefore cannot hide any activity from auditors.
As a general rule, you should not delete a file while it is open and in use by an application. In most systems, 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 can lose log entries.
The workaround is to restart the pedClient daemon, which creates a new log file.
/usr/safenetlunaclient/bin/pedClient -m stop
then
/usr/safenetlunaclient/bin/pedClient -m start