|
Home > |
|---|
This section provides additional information by answering questions that are frequently asked by our customers.
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.
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 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 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.