|
Home > |
|---|
This happens for two reasons:
•PKCS#11 originated in a world of software cryptography, which only later acknowledged the existence of Hardware Security Modules, so initially it did not have the concept of physically removable crypto slots. PKCS#11 requires a static list of slots when an application starts. The cryptographic "token" can be inserted into, or removed from a slot dynamically (by a user), for the duration of the application.
•When the token is inserted, the running application must be able to detect that token. When the token is removed, the running application gets "token not present". Because we allow for the possibility of backup, and of "PKI Bundle", we routinely declare 'place-holder' slots that might later be filled by a physical SafeNet USB HSM, or a SafeNet Backup HSM, or a SafeNet DOCK2 with (potentially) two legacy token-style HSMs in its card-reader slots. As it happens, there are three (3) USB ports on a SafeNet Network HSM appliance, so we are allowing for a physical HSM connection to all of them.
In the Chrystoki.conf file (or the Windows crystoki.ini file), for SafeNet USB HSM, you can remove the empty slots by modifying the CardReader entry, like this:
CardReader = {
LunaG5Slots=0;
}
For SafeNet Network HSM, which has its configuration file internal to the appliance, and not directly accessible for modification, you cannot change the default cryptographic slot allotments.
You must ensure that SRK is disabled before you run the firmware update. (SRK is fundamental to Secure Transport Mode and to enforced tamper-event acknowledgement in PED-authenticated SafeNet HSMs). This brings the external split of the MTK (the Secure Recovery Vector) back inside the HSM.
Also, as with any update, you should backup any important HSM contents before proceeding.
After the update is completed, you can enable SRK again. This creates a new split of the MTK to populate a new purple PED Key.
(Applies to PED-authenticated SafeNet HSMs.)
As indicated on the BSAFE web site, they support only the NIST-approved curves (prime, Binary, and Koblitz). That includes most/all the curves from test items 0 through 37 in ckdemo, which is to say: the "secp", "X9_62_prime", and "sect" curves.
The X9.62 curves that are failing in this task are X9.62 binary/char2 curves which do not appear to be supported by BSAFE. So, you appear to be encountering a BSAFE limitation and not a SafeNet HSM problem.
Appliance Details: ================== Software Version: 4.4.0-27 Error: 'hsm show' failed. (310102 : LUNA_RET_SM_SESSION_REALLOC_ERROR) Command Result : 65535 (Luna Shell execution)
The error LUNA_RET_SM_SESSION_REALLOC_ERROR means the HSM cannot expand the session table.
The HSM maintains a table for all of the open sessions. For performance reasons, the table is quite small initially. As sessions are opened (and not closed) the table fills up. When the table gets full, the HSM tries to expand the table. If there is not enough available RAM to grow the table, this error is returned.
RAM can be used up buy an application that creates and does not delete a large number of session objects, as well as by an application that opens and fails to close a large number of sessions.
The obvious solution is proper housekeeping. Your applications MUST clean up after themselves, by closing sessions that are no longer in use - this deletes session objects associated with those sessions. If your application practice is to have long-lived sessions, and to open many objects in a given session, then your application should explicitly delete those session objects as soon as each one is no longer necessary.
By far, we see more of the former problem - abandoned sessions - and very often in conjunction with Java-based applications. Proper garbage collection includes deleting session objects when they are no longer useful, or simply closing sessions as soon as they are not required. Formally closing a session (or stopping / restarting the HSM) deletes all session objects within each affected session. These actions keep the session table small, so it uses the least possible HSM volatile memory.
The K6 HSM card, used in the SafeNet Network HSM and SafeNet PCI-E HSM products, is equipped with a non-replaceable battery that is expected to last the life of the product. If you notice a log message or other warning about ‘battery low’, or similar, contact SafeNet Technical Support.