Exchanging Certificates between the Client System and the HSM

One certificate is attached to the HSM (which is generated internally), and a second certificate is generated on the client system. These certificates are used to mutually authenticate the HSM and the client, and thus encrypt the transport of sensitive data between them using the NTL protocol. To perform the exchange of certificates between the client system and the HSM, complete the following procedures.

At this point in the process, you have completed the first leg of the NTL protocol with the HSM having created a new NTLS certificate. In the following description, it is assumed that the client system operates in a Windows environment (refer to the Thales / Thales TCT software installation package for specific information about Linux-based environments). 

To request the certificate from the HSM, open a command prompt window, and then call the PuTTY Secure Copy (PSCP) utility provided by Thales / Thales TCT.

The server.pem file is stored in the calling directory (for example, C:\Program Files\SafeNet\LunaClient). This file contains the HSM Server certificate.

Note: During this operation, the certificate is retrieved from the HSM and stored on the client system. The next procedure is to effectively register this certificate with the client system.

To register the HSM server certificate with a Windows-based client system, you must use the Utility Virtual Tape Library (vtl) executable provided by Thales / Thales TCT. Use the following sample commands as a guide to registering the HSM server certificate on the server list.

If you are working with DNS, then you must use the domain name instead of the IP address for the clientHostName. For example:

Copy 
xxx.yyyyyy.testval.activcard.com

If you are not working with a DNS, then you must use the following command format. Use the dotted decimal notation format for the clientHostName (for example, the client IP address in the following example is 192.168.5.174).

After the completion of this request, the private key and certificate files containing the client certificate and associated private key are stored on the client system.

Once created, the client certificate must be transmitted to the HSM. Use the following export process sample as a guide.

To assign the client certificate to the HSM, use the PuTTY tool or Secure Shell (SSH) to perform this procedure. In a Windows-based environment, the freeware PuTTY utility establishes SSH communication with the HSM. In a Linux-based environment, use SSH to perform the same procedure. Use the following sample as a guide to register the client certificate.

Copy 
[ade_luna_sa] lunash:> client -register -client supreme -hostname supreme-
testLunadomain.testval.activcard.com
'client register' successful
Note:  
  • If you are not using a DNS, you must use the IP address instead of the hostname as shown in the following sample:
    • Copy
    [ade_luna_sa] lunash:> client –register –client supreme –ip 192.168.5.174.
  • The name of the client can be any string that uniquely identifies the client certificate.
  • To verify that the client certificate is properly registered, the following command is called:
    • Copy
    [ade_luna_sa] lunash:> client –list
    Registered client 1: supreme

The client system can access only specific partitions that the HSM administrator has enabled or assigned to the client, as shown in the following example:

Note: The partition name reflects the name assigned to the partition when partitions were created in the HSM. To list the available partitions run the following commands:
    Copy
    [ade_luna_sa] lunash:>partition list
    Partition: 902514001,     Name: ade_partition.

Use the commands in the following sample as a guide to verify the partition or partitions assigned to a specific client:

Copy 
[ade_luna_sa] lunash:>client –show –client supreme
Client ID:     supreme
IPAddress:     192.168.5.174
Partitions: “ade_partition”
Note: This sample shows a single partition only (ade_partition) created in the HSM. However, several partitions can exist and be assigned to a specific client. The maximum number of partitions is defined at the time the HSM is initialized.

In the previous procedure, a check was made of the contents of the HSM and the association (if any) between the client and HSM, on the HSM side (with verification performed on the HSM side). To perform a similar verification on the client side, open a command window and issue the vtl verify command as illustrated next.

At this point, the HSM is ready for use in an ActivID KMS installation for initializing the cryptographic keys in each partition. When the keys have been generated/loaded using ActivID KMS, the HSM is connected to ActivID CMS to provision the cards.