Frequently Asked Questions

This section provides additional information by answering questions that are frequently asked by our customers.

How can we use a Luna Network HSM with a Key Manager?

A Luna Network 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 Luna Backup HSM that can then be locked away in a safe.

We need to identify corresponding keys (public and private) with certainty, prior to key deletion. The thumbprints we derive using certificate public key do not match the thumbprints of objects in the HSMs. Why? And what should we be doing?

The HSM-internal thumbprints are a hash of the key value and all its attribute values and are used only to identify/compare/match a a key/object when it exists on more than one Luna HSM. As well, Luna toolchains do not follow the classic CKA_ID method convention - CSP, KSP, and Java encode the CKA_ID differently for their own purposes.

So what can you do?

Comparing a public or private key’s modulus to the modulus in the certificate is a common method used to match a key pair with a certificate. Using CKA_LABEL is a possible approach.

Another approach is to verify the cert-keypair by encrypting some data with the public key (cert) in software then decrypting using the private key in hardware, to be sure the ID has not been tampered or misidentified.

We need to encrypt PANs on MS SQL Server 2008 (Extensible Key Management). We have a problem with the encrypted PAN, as the length is greater than the original PAN (16 digits).

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 Network HSM, such as certification.

2.Alternatively, you can switch to DataSecure. It has tokenization support and is, in general, designed for DB security.

"Makecert" fails when using Luna Network HSM with MS Authenticode, because the MD5 algorithm is not available when the HSM is in FIPS mode.
Error: CryptHashPublicKeyInfo failed => 0x80090005 (-2146893819) Failed, and FINIDigest_Init ***CKR_MECHANISM_INVALID***(296ms) {}

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

We are developing our application(s) in C#, and we want to integrate with Luna Network HSMs

If you want to integrate your C# application with Luna Network HSM 6.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.

We intend to use PKCS#11 data objects - is this supported in the API for your HSMs?

Yes, it's a basic requirement.
If you have concerns, you might wish to verify if Luna Network 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 SafeNet 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.

In our application, both for PKCS#11 and for the JCA/JCE Luna provider, we need to use CKM_SHAxxx_RSA_PKCS mechanism for Signing. Does Hashing occur at the Client or in the HSM?

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.

We were using another vendor's HSM - or are evaluating HSM products - to host an online sub- or issuing CA with MSCA. With the other vendor we must check "Allow administrator interaction when the private key is accessed by the CA" in the "Configure Cryptography" setup dialog. Luna Network HSMs seem to work regardless of whether that selection is checked or not.

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. Luna Network 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 Network HSM can "AutoActivate" partitions, which allows cached ("Activated") partition credentials to be retained through power interruptions as long as 2 hours in duration.

For Luna Network HSMs, as long as the user is registered in the KSP utility, and the partition is activated, the "Allow administrator 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 Network 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.