Home > |
---|
If you fail three consecutive login attempts as HSM Security Officer (or SO), the HSM contents are rendered unrecoverable. This is a security feature (you DO have your important material backed up, don't you?) meant to thwart repeated, unauthorized attempts to access your cryptographic material. The number is not adjustable.
Note: The system must actually receive some erroneous/false
information before it logs a failed attempt -- if you merely forget to
insert a PED Key (for PED-authenticated HSMs), or inserted the wrong color key, that is not counted as a failed attempt.
To fail a login attempt on a Password-authenticated HSM, you would need to type an incorrect password. To fail a login attempt on a PED-authenticated HSM, you would need to insert an incorrect PED Key of the correct color, or to type an incorrect PED PIN, if one had been set for that PED Key.
As soon
as you successfully authenticate, the counter is reset to zero.
View a table that compares and contrasts various "deny access" events or actions that are sometimes confused. See Comparison of Destruction/Denial Actions.
Other roles and functions that need authentication on the HSM have their own responses to too many bad authentication attempts. Some functions do not keep a count of bad attempts; the simple failure of a multi-step or time-consuming operation is considered sufficient deterrent to a brute-force attack. The table in the next section summarizes the responses.
Role |
Threshold (number of tries) |
Result of too many bad login attempts | Recovery |
---|---|---|---|
HSM SO | 3 | HSM is zeroized (all HSM objects identities, and all partitions are gone) | HSM must be reinitialized. Contents can be restored from backup(s). |
Partition SO | 3 | Partition is zeroized. | Partition must be reinitialized. Contents can be restored from backup. |
Audit | 10 | Lockout | Unlocked automatically after 10 minutes. |
Crypto Officer [Note 1] |
10 (can be decreased by SO,) | Lockout | Must be unlocked/reset by the partition's SO. |
Crypto User [Note 2] |
10 (can be decreased by SO) | Lockout | Must be unlocked/reset by the partition's CO. |
Domain | n/a | Operation fails | Retry the operation with the correct Domain - usually that would be a backup or restore |
Remote PED Key | n/a | Operation fails | Retry establishing a Remote PED connection, providing the correct orange PED Key (PED-authenticated only). |
Secure Recovery Key | n/a | Recovery from tamper or Secure Transport Mode fails. Entire HSM is locked. The only operation that is not locked out is establishing a Remote PED connection. | Retry recovery from tamper or from STM, providing the correct purple PED Key (PED-authenticated only). |
[Note 1] If the policy "SO can reset PIN" is on, then this user is locked. If "SO can reset PIN" is off, then this user is deleted - as is any user that depends upon it, specifically the Crypto User. | |||
[Note 2] The Crypto User is created by the Crypto Officer. Therefore, only the Crypto Officer, and not the SO of the partition, is able to reset the Crypto User. If the policy "SO can reset PIN" is off, then this user is deleted, rather than locked out when too many bad attempts are made on the CU. Similarly, if too many bad attempts are made on his creator the Crypto Officer, and that role is deleted, then the associated CU is also deleted. |
The configurable policy “SO/HSM Admin can reset User PIN” [HSM policy #15] allows you to control the outcome of too many consecutive bad authentication attempts. If the policy is “on” then the outcome is that the HSM Partition is locked out. This means that the Partition and its contents can be accessed again after the HSM Admin resets the HSM Partition Owner’s password. If the policy is “off”, then the partition is zeroized after too many bad attempts – meaning that all contents become inaccessible and the partition must be recreated.
“Ignore failed challenge responses” can be set per partition, which ensures that failed HSM Partition Password attempts do not cause the “failed login attempt” counter to increment.