Administration & Maintenance
The following are recurring questions from our customers and from people who are evaluating Luna products before purchase.
No. The Luna SA 1700 appliance comes with a single power supply, and you can purchase a second PS, remove the blanking plate and install the new PS into the empty slot for the same power-supply redundancy as Luna SA 7000, but you cannot increase the Luna SA 1700 performance. If you need the performance, buy a Luna SA 7000.
Note that you could buy and use the less-expensive Luna SA 1700 for your testing, development, or integration, and then purchase Luna SA 7000 appliances for your operational deployments where higher performance is desired. Other than performance, the two appliance models are functionally identical. An integration or application that works with one will work with the other, with no adjustment needed.
Note that the main difference (see next question) is performance using asymmetric operations. If your primary cryptographic activity is key-generation of any kind, or involves mostly symmetric operation, then Luna SA 1700 should suit your needs at a smaller investment.
Here is a quick summary of some excerpts from the performance testing:
* Key Generations – same performance for both
* Symmetric operations – same performance for both
* Asymmetric operations – check with your SafeNet Sales representative, but here are some samples.
- RSA 1024: 7000 signings/second vs 1700 signings/second
- RSA 2048: 1200 vs 350
- RSA 4096: 160 vs 50
- ECC P-256: 1000 vs 490
We provide repeatable numbers that you could achieve if you tested in an environment similar to our test-lab environment. This method provides numbers that you can compare against numbers from any of our competitors. In general, that means automated scripting to perform a given operation with a "standard" keysize, or standard input parameters, and ensuring that no other operation or latency is allowed to intrude - an isolated high-speed network with no other activity.
Operation outside a controlled laboratory environment is messy and sometimes unpredictable, with many variables that could affect testing if we did not control the parameters and conditions as tightly as possible. Therefore, all manufacturers' test numbers tend to be the best you can get under ideal conditions.
So, for example, we use the RSA 1024-bit key as the standard for performance of asymmetric sign and verify operations, because that is what the industry uses as a common basis of comparison. That remains true even though the 1024 key size is now generally considered too small for modern operational use, and most applications would tend to use 2048 key sizes (at least that was the case when this was written in 2013).
As well, we bombard the HSM with at least 30 threads simultaneously performing that simple test operation (this is down from a previously required 50 threads due to refinements in Luna SA 5.2). Any fewer might fail to exercise the HSM to its fullest. Significantly more threads would not increase the performance numbers, so we work in the "sweet spot" and we suggest that you do as well if performance is your greatest concern.
In operational, real-world situations, your clients are likely to have other responsibilities, or might make other requests of the HSM - for example, a fresh asymmetric key generation before each asymmetric signing operation would slow the sign/verify performance down to key-gen speeds... orders of magnitude slower than simple, repetitive signing that reuses a single key. Network latency and other factors also serve to degrade performance in non-laboratory operation.
Remember that our numbers are not based upon sequential access, but are based upon an optimal number of concurrent threads accessing the HSM. That optimal number differs from one HSM to the next. Best performance for the legacy Luna CA4 is achieved from roughly 4 - 8 threads with a slight drop-off after that due to the overhead of context switching. On Luna SA 5.0 and 5.1, the optimal number of threads has been in the range of 50, but refinements in Luna SA 5.2 have brought the optimal number of concurrent threads down to 30.
Command latency (the time required for any one command to complete) is not a direct inverse of TPS, and can be dependent on several things including the number of threads, the network latency, and the interleaving of different command types to the HSM. (That is, ideal signing performance can be achieved only if the HSM is processing only signing requests.) As the number of threads increases (and thus the corresponding TPS) the latency increases as well. So you might be seeing what appears to be 6 responses per millisecond, but the round-trip latency of any one of those commands might be as high as 500 ms (for example).
This is partially why, when you observe numbers from our tools, the numbers are quite variable for the first several seconds, and then settle around stable values as the testing proceeds.
Performance requirements should state both the total throughput and the maximum latency that a command must execute, and the ideal number of threads should be adjusted accordingly.
You are thinking of the HSM's flash memory, which would be used to store token objects. By their nature, those do not frequently change.
Your "key factory" application (generating keys that are pushed out to external devices like smart cards) should be generating your short-lived keys as session objects, rather than as token objects. Session objects do not use the flash memory at all - they are created and exist in the HSM's RAM only, which can perform virtually unlimited read/write operations.
Luna SA 5.2, and later, can do about 35 ECC P224 keys per second. You would then need one appliance for performance reasons, if you could count on steady demand with no peaks. Consider having a backup as well.
In the situation where you might encounter bursts of key generation traffic, prudence suggests one operational Luna SA, one in standby to accommodate the burst traffic, and a third unit for backup.
NTLS will not work through a load-balancer because it is an end-to-end TLS pipe between client and Luna SA. That is why we have our own HA feature.
Yes. At the client, generate the client cert with the command " vtl create -n <any IP address, real or virtual> "
Both client computers must have the Luna SA appliance's server cert in their client-side server-cert folders.
The Luna SA appliance must have the client certificate (built with the virtual IP address)
Also the following lines in the Chrystoki.conf file
LunaSA Client ={
ClientCertFile=\usr\LunaClient\cert\client\<your-cert-filename>.pem
ClientPrivKeyFile=\usr\LunaClient\cert\client\<your-filename>Key.pem
must point to the same cert and Keyfile on the clustered application servers.
Luna SA HA function is managed by the Client library. Individual Luna SA appliances are not in any way aware that they are members of an HA group. The Client takes care of that, based on the HA group configuration list.
There is no "master" HSM appliance in the Luna SA HA model. Where you might see or hear mention of a "Primary" member, that refers only to the member that happens to be the first on the configuration list. If you edit the list to place the name of a different Luna SA on top, then that becomes the new HA Group "primary" member.
When the Client has a request for HSM action, that request goes to the first member in the list, unless that member is busy. A member is busy if it has not yet responded to the most recent request that was sent to it.
Luna SA HA works on a "modified round-robin, least-busy" model. What that means is, if the primary member is busy, the client sends its next request to the next non-busy member of the HA Group. In practice, that means the primary member gets all the requests until the volume reaches a level that saturates the ability of the primary - OR a blocking request from another source prevents acceptance of new requests. Therefore, on a 7000 signings/second Luna SA doing exclusively 1024-bit RSA signings, your client would need to have approximately 30 simultaneous threads offering a total of nearly 7000 requests per second before the second member would begin seeing any requests. In other words, until the primary is fully occupied, the HA group looks like it is operating as a "hot-standby" arrangement.
The numbers above are ideal, of course. If you add network latency, or if you increase the key-size, or if you interleave other crypto operations, then the numbers must drop for the individual member, and the secondary member becomes part of the overall performance. And a third member, if you have a third active member in your group, and so on.
If you have any group members set to "Standby" status, then they do not contribute to group performance, even if the client can saturate the active members.
Note that PED operations against an HSM can block crypto operations until the PED operation has returned control to that HSM.
No. HA provides redundancy and can increase performance, but not capacity. Every HSM in an HA group gets synchronized with the other member[s], which means that the content of any one HSM in an HA group must be a clone of the content of any other member of that group. So, with more HA group members, you get more copies, not more space.
Those sorts of traps were specifically excluded because they can be used to establish a covert channel (an illicit signaling channel that can be used to communicate from a high assurance “area” to a lower assurance one in an effort to circumvent the security policy). Resource exhaustion events/alerts are the oldest known form of covert channel signaling. Exercise care with any HSM product that does allow such traps - what other basic security holes might be present?
Yes, it's a basic requirement.
If you have concerns, you might wish to verify if Luna HSMs' (and our API's) handling of data objects are conducive to the operation of your intended application(s). Luna API generally places no restrictions on whether data objects can be private or not. We understand that, in the past, some competitors' modules might have allowed only public data objects, if that was the basis of your question.
However, one concern that might arise is Java.
Java offers no support for data objects, and so we do not support them with the LunaProvider. Unexpected results can occur with Luna JCA if a data object is present in a partition. This might be the case if you attempt to use an application that uses the CSP, and then the JSP accesses the same partition. CSP inherently creates a data object for its own purposes.
Therefore, keep CSP and JSP clients tied to separate partitions. Generally do not allow JSP to connect to a partition that contains a data object, regardless of the source - Java (and therefore JSP) doesn't know what to do with it.
If your application scenario really does demand the use of both the Microsoft Cryptographic Provider and Java against a common partition, then consider upgrading/updating to Microsoft CNG and use our KSP, which does not inherently create a data object, and so would not cause conflict of that sort.
CKM_SHAxxx_RSA_PKCS is a PKCS#11 mechanism, not a Java method.
For PKCS#11 the digest operation is done within the HSM if that mechanism is called.
For Java, digests are done in software.
So, for that other vendor's product, you need to enter the additional credentials every time you need to issue a certificate? That seems a bit restrictive.
"Allow administrator interaction..." actually means "Allow administrator interaction if the underlying KSP requires it".
The Windows operating system passes a Windows handle that the KSP can use to render any GUI designed by a vendor (SafeNet or some other vendor).
Somewhere in the process a KSP reports that it can (or cannot) interact with the GUI so the application will (or will not) request GUI interaction; that is, pass a window handle to the KSP.
So, the <competitor product> KSP expects a window handle - implying hands-on action by an administrator, each time - whereas SafeNetKsp ignores the handle (if one was provided).
SafeNet's KSP was designed to register partitions ahead of time. SafeNet Luna HSMs can be Activated, which caches the administrative and enabling credentials, such that only the partition challenge (text string) is needed, which can be passed by your application without need for GUI interaction. Furthermore, Luna SA can "AutoActivate" partitions, which allows cached ("Activated") partition credentials to be retained through power interruptions as long as 2 hours in duration.
For Luna HSMs, as long as the user is registered in the KSP utility, and the partition is activated, the "Allow administer interaction..." check box (checked or not checked ) does not impose any additional, ongoing, authentication requirements -- no additional prompts for credentials from the GUI. After initial setup and Activation, the Luna HSM knows what to do, and doesn't need to pester you.
For root CAs, on the other hand, you always have the option of not activating the partition, so PED interaction would always be required to ensure close supervision for each use of the private key.
Each installation will have its own issues and peculiarities. For this discussion we will assume that both the Luna HSM server and the application server - PKI, web, other - that is the main client of the Luna HSM server are being moved. Here are some common steps to consider:
Physically, they are electronic devices, and should be stored in environments that are not subjected to extremes of temperature, humidity, dust, or vibration.
With that said, PED Keys that have their protective connector-caps in place are quite robust. PED Keys that have their caps on when not immediately in use have survived years of daily use being carried around in office-workers' pockets, here at SafeNet's Luna labs.
Procedurally, they should be labeled and stored (filed) so that they are readily identifiable according to the HSM(s), the partitions, and the roles with which they have been associated.
No. The only place where that might be appropriate is in a test lab where HSMs are constantly re-configured for test purposes, and where they never contain important cryptographic material. PED Keys are just generic iKeys until you make them into specific kinds of PED Key by your administrative actions with Luna HSMs and Luna PED. Once a blank iKey has been turned into a Security Officer (blue), Domain (red), Partition Owner/Partition User (black), Audit (white), Secure Recovery (purple), or Remote PED (orange) key, you must ensure that it is labeled as such and that you handle it and store it in a way that it can never be mistaken for a different PED Key.
We have had at least one customer call us in a panic because they had "lost" the SO and Domain and Partition keys to an enterprise-critical HSM. They actually still had those keys, mixed with many others in a box. As you know, Luna HSM authentications do not permit a lot of "guessing". For example, you get only three tries to present the correct blue PED Key for HSM SO login, before the HSM contents are lost forever. A customer staffer, new to her job asked: "You make the HSMs and keys, why can't you just give us another one?" We had to explain that there is no 'back door', ever, to a Luna HSM. We (SafeNet) did not make her PED Keys. We made the iKeys, and her predecessor created them as the PED Keys for her organization's HSMs.
Fortunately, that customer's critical HSMs were in an HA configuration that had not yet synchronized, and the secondary HSM was still in logged-in state. After trying several red PED Keys it was possible to get a backup of the secondary HSM and restore onto a re-initialized primary HSM. After that, our responding support engineer spent many hours teaching the customer staffers the basic security and HSM administrative knowledge that had been lost due to staff turn-over at that company. That enterprise customer has since installed rigorous procedures and documentation for handling of HSMs and HSM authentication secrets.
You are likely in for some cost and disruption, but this is not necessarily a fatal mistake.
At the present time (this note is written in February 2013) there is no way to recover from a tamper or from Secure Transport Mode if the external split of the Master Tamper Key (the SRK) is not available. If you haven't got a backup purple key, your HSM is locked the moment it experiences a tamper event, or if it was placed in Secure Transport Mode. The same applies if you do have the key, but have forgotten/lost the numeric PED PIN that you applied when the purple key was imprinted with the Secure Recovery Vector (the external split of the MTK). Either way, you must obtain an RMA and return the HSM to SafeNet for remanufacture. All HSM contents are lost.
As with every PED Key that you imprint, we recommend that you make at least one backup copy of the purple PED Key, as well. If you can find that valid backup purple key, you can recover the HSM and make a new split, without problem. If the purple key that you lost was the only one... then see the preceding paragraph.
Note that simply not having the external MTK split available is not the end of your HSM and its contents. As long as it has not been tampered, or was not placed into Secure Transport Mode, then the HSM is still working and is perfectly accessible to other key-holders. However, you should immediately back-up all important HSM contents to other HSMs and have SafeNet remanufacture the affected HSM. When that HSM is returned to you, it will be in one of two states:
a) it will have both MTK splits internal (no SRK created), or
b) it will have a new MTK and a new SRK (purple PED Key) if you requested that we ship the HSM to you in Secure Transport Mode.
In the first case, you have a "new" working HSM and can decide what you wish to do with respect to SRK - if it is not necessary to your security regime, simply never declare an external split and you will never need to worry about purple keys. Tamper events (if any) will be logged, but will recover automatically when the HSM restarts.
In the second case, you receive the HSM back from SafeNet, in STM (as requested) and you receive the associated purple key (SRK) by separate courier. You recover the HSM from Secure Transport Mode. At that point, you can elect to disable SRK (return the external split inside the HSM, simultaneously generating a new internal split pair, and invalidating your purple key). OR, you can elect to make a new external split. This imprints a new purple key (SRK) and invalidates the one that we shipped to you. You should make at least one backup copy of the new purple key when it is created, and take better care of your imprinted PED Keys in future.
Also, if your security regime does not require multi-factor authentication, then see the next question, about PED PINs.
Not at all. Or, rather, you do if you already set a PED PIN when you initialized/imprinted that PED Key. But a PED PIN is an optional item when you first initialize an HSM or create a partition, etc. You have the choice, and you don't want to impose a PED PIN requirement on yourself without good reason.
A PED Key is single-factor physical authentication - "something you have". If that is sufficient to satisfy your organization's security requirements, then you do not need to impose PED PINs.
You can just press [Enter] on the PED keypad when the PED Keys are being imprinted (that is just press the [Enter] key with no digits), and you would never be troubled by a PED prompt about PED PINs again.
PED PINs are an option - until one is imposed; then it becomes mandatory. Only if your security regime requires two-factor authentication should you consider applying PED PINs to your various PED Keys. Where the physical PED Key is "something you have", the PED PIN is the second factor, the "something you know". A PED PIN is a convenient and effective second factor, but it does represent an additional item for you to remember and to track.
If you lose track - if you fail to remember a PED PIN, or if you have several and don't remember which is which - you can find yourself locked out of your HSM or your HSM partition as surely as if you lost the physical PED Key. More surely, in fact, since you probably have physical backups of your PED Keys (you do, don't you?). Remember, typing a wrong PED PIN on the PED's keypad is the same as offering the wrong physical PED Key to the HSM. It counts as a bad login attempt. PED PINs are good and essential when you need one, but they are not something to impose without a solid security-based requirement.
We have documented procedures for cloning or backup/restore, and for migration from legacy HSMs to current HSMs, but the procedures are only to ensure that the operations complete successfully. Security of private keys is enforced by the HSM(s) and does not rely on procedure.
The encryption key is either 3-key TDES or AES 256, depending on the HSM firmware version, which itself is afforded the same high level of protection as a CA signing private key. The encryption key is derived using the data from the Red PED Key (48 bytes of HSM-generated random data) along with source and target HSM random nonces that are exchanged using RSA 2048 bit encryption. Both the source and target HSMs must be legitimate SafeNet HSMs and their RSA certificates (used to exchange encrypted nonces) are signed by the SafeNet manufacturing PKI when the devices are manufactured.
This happens for two reasons:
In the Chrystoki.conf file (or the Windows crystoki.ini file), for Luna G5, you can remove the empty slots by modifying the CardReader entry, like this:
CardReader = {
LunaG5Slots=0;
}
For Luna SA, 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 Luna 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 Luna 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 Luna HSM problem.
It means that the client did not receive the SSL handshake response from the appliance within 20 seconds (hard coded).
The following is a list of some potential causes:
- Network issue
- Appliance is under heavy load with connection requests - this can happen at start-up/restart, if client applications attempt to (re-)assert hundreds of connections all at once, without staging or staggering them, and the initial setup handshakes take too long for some transactions (start-up bottleneck). After a large number of simultaneous connections has been successfully established, they can be maintained without further problem.
- Appliance is under heavy load servicing connected clients crypto requests.
- Appliance was powered down (perhaps the power plug was pulled) in the middle of the handshake.
- There might be high CPU load on the client computer causing it to occasionally delay responses to the appliance.
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.
Those policies apply to PED-authenticated Luna SA, only.
For both PED-authenticated and Password authenticated HSMs, your client authenticates to a partition with a challenge password.
For PED-authenticated HSMs, the HSM partition must be in a state where it is able to accept that challenge password. That is, the extra layer of authentication - the Partition Owner's black PED Key - must have been presented first before the partition can be receptive to the challenge/password.
Password-authenticated HSMs have only the single layer of authentication - the challenge/password is all that is needed. The challenge password is both the client authentication and the partition administrator (Owner/User) authentication.
For PED-authenticated HSMs, activation and auto-activation enable caching of the first layer of authentication to provide a level of operational convenience similar to that of the Password-authenticated HSMs.
From the convenience point of view, none. But, whereas the Password-authenticated partition is "open for business" to anybody with that partition's password, as soon as the partition is created, a PED-authenticated partition is not. One implication is that all partitions of a multi-partition Password-authenticated HSM are available whenever any of them are available, which is essentially whenever the HSM is powered on.
The owner of a PED-authenticated HSM partition can disable client access to just one partition by deactivating (de-caching) just that one partition's PED Key authentication, so that the challenge/password is not accepted. Any other partitions on that HSM that are not deactivated (i.e., still have their black PED Key authentication cached) are still able to accept challenge/password from their clients.
You are not required to cache the PED Key data in order to use a partition. You could simply leave the PED Key for that partition inserted in a connected Luna PED, and press keypad keys on the PED whenever first-level authentication for partition access was required. Since this would defeat much of the reason for having a powerful networked HSM server, generally nobody does this with Luna SA in a production environment. (For the kind of application where that scenario might be appropriate, we recommend a host-installed Luna PCI-E HSM or a USB-connected Luna G5 HSM.)
You also have the option of partially engaging the PED Key caching feature by enabling Activation without enabling Auto-activation. In that case, you present your PED Key to activate the partition - which allows it to accept its partition challenge/password from clients - and the cached black PED Key authentication data is retained while the HSM has power (or until you explicitly de-cache). But the cached authentication does not survive a power outage or an intentional power cycle (because you chose to Activate, but not to AutoActivate as well). Thus, by applying different policy settings, you could have some partitions on your PED-authenticated HSM able to return to client availability immediately following a power-cycle/outage (no human intervention needed), while others would wait for your intervention, with a black PED Key, before becoming client-available.
A Luna HSM could be a Certificate Authority (CA) within your organization, and would operate in parallel with a Key Manager. It is normally the Key Manager that requests service from a CA, and not the other way around. For example, the Key Manager might generate an RSA key pair for an endpoint to use for authentication. The KM would then go to its associated CA and request a certificate for the public key.
The other typical use case for a KM looking to a CA for service is for confirming certificate validity, either through CRLs or OCSP.
In general, the HSM keeps keys safe within its confines, and exports only metadata about the contained objects. The metadata allows the KM or an integrated application to refer to the keys and objects within the HSM, when invoking cryptographic operations by the HSM, but not to touch the actual keys or objects themselves.
A CA's private key(s) are extremely valuable and often are used only by a CA application operating on a stand-alone server or one on a very minimally-connected subnet. Backup is normally done to a small form factor HSM that can then be locked away in a safe.
The issue is a common one and it arises because the CBC padding scheme requires an extra padding block (8 bytes), with all bytes having the hex value 8, to be appended if the length of the original plaintext is a multiple of the cipher’s block length. Another format issue often comes up as well since encrypted data does not generally represent well as decimal digits.
We suggest one of two options:
1. You can set up a shadow table to hold the encrypted PANs. The shadow table schema can then be set up for a sufficient number of hex numerals to hold the padded data or just make that field a binary blob. This takes some coding on your part, and the plaintext PANs would be retrieved into a dynamic view, rather than back into the “real” table, to protect their confidentiality. You should do this only if there is a hard requirement to use Luna HSM, such as certification.
2. Alternatively, you can switch to DataSecure. It has tokenization support and is, in general, designed for DB security.
The certificate always has an MD5 hash in it. Configure LunaCSP algorithm registration such that MD5 hashing is performed in software. For example:
# register.exe /algorithms
If you want to integrate your C# application with Luna HSM 5.x using PKCS#11 calls, rather than using Microsoft CAPI or CNG, then you might consider using "ncryptoki". At the time this note is being written, we have not created anything formal, but we have worked with some customers who are successfully using "ncryptoki" for that purpose.
Keep an eye on the Safenet C3 website, or ask your SafeNet technical representatives if anything new has been added. Or, you could engage SafeNet Professional Services for formal assistance with your project.
This section applies only to the host-installed Luna PCI-E (K6) HSM, but is included in the FAQ for all Luna HSM 5.x products because some customers deploy a mix of Luna HSMs.
In the majority of modern host computers/servers with compliant PCI express slots, Luna HSM just works.
We test the Luna HSM in a variety of representative computer systems / servers from major manufacturers. However, we cannot possibly test with all computers that are available on the market, or that were sold in recent years, or that come to market after we release the product. When we learn of a compatibility problem with a current, important brand and model computer, we work with the manufacturer to identify and resolve the issue, if possible.
If we test - or if customers report - that the Luna HSM does not work with a particular brand, model, and configuration of host system, we make that information available in Release Notes or via our Technical Support organization, so that you can make the necessary decisions without wasting time and effort.
If we learn that a particular make and model of host computer is partially able to support the Luna HSM, we publicize that information, and we hope that you will tell us if you encounter such a situation that we have not already seen.
When installing the Luna HSM into a new server/host computer, always try more than one PCI express slot if you encounter any issues. It often happens that, due to quirks of motherboard design, or of the associated BIOS, some slots will work properly with Luna HSMs while others do not. Almost always, if a particular PCI express physical slot is intended for use with video cards, or has been specially designated by the host for a particular type of hardware, then you can expect trouble with that slot. It is very possible that simply moving the Luna HSM card to another empty PCI express slot or swapping with another installed adapter card will get your Luna HSM working in the chosen host computer/server.
Contact SafeNet Technical Support if you encounter problems, but expect some of their initial trouble-shooting questions to center around the use of alternate physical slots for installation of your Luna HSM.
No. You can clone keys between HSMs that share a domain, but each HSM assigns its own object handles to incoming - or generated - objects.
Good PKCS#11 applications never make assumptions about the object handle number.
Typically, an application will find an object prior to use; for example, find by CKA_LABEL is the most common.
The label either is known to the user or is published somewhere application-specific; for example, Microsoft uses the certstore to store the label (a.k.a. container name).
Possible workarounds:
If your application already uses handles to access/identify keys, consider identifying keys by fingerprint (and possibly label) and devising your own mapping to the new handles for objects that you import (clone) into the HSM.
HOWEVER, that approach might not be feasible if you are not in a position to make API changes - such as, if you are using a third-party application, or if you are locked in by internal compliance/audit or by external compliance/audit. Then, perhaps you could consider using multiple HSMs in an HA group.
If you are accessing via an HA group, then the HA group has a single virtual handle for each object that your application would see, regardless of the "real" object handle on each HSM.
Did you verify that they were all on before you removed rack power?
Luna SA is configured to return to previous state on application of AC power. If the appliance was running, and power was removed, then when power is re-applied the appliance re-boots. If the appliance was not running when power was removed, then the appliance does not [re]start when power becomes available again, and you must manually toggle the appliance power switch.