Configuring Network HSMs

This section illustrates how to set the date, time, and timezone. The same command is used for setting the date (sysconf –date...) and time (sysconf –time...). The settings for date, time, and timezone are read using the syntax status –date, status –time, and status –zone, respectively. Set the date, time, and timezone using the following sample as a guide:

cmslunasa] lunash:> sysconf -timezone -set US/Eastern
Timezone set to US/Eastern
Command Result : 0 (Success)

If the network uses the Domain Name System (DNS), the hostname for the HSM must be entered into the DNS record of the network to which the HSM connects. If DNS is not used in the network, then you can enter an arbitrary hostname. Set the hostname using the following sample as a guide:

cmslunasa] lunash:>net hostname ade_luna_sa
Success: Hostname ade_luna_sa set.
Command Result : 0 (Success)

This operation sets the domain name in which the HSM operates. Set the domain name using the following sample as a guide:

ade_luna_sa] lunash:>net domain luna_sa.test.com
Success: DomainName luna_sa.test.com set.
Command Result : 0 (Success)

This operation sets a new IP address for the DNS name server (this operation is optional if there is no DNS involved). Change the IP address of the DNS name server using the following sample as a guide:

ade_luna_sa] lunash:>net -dns -nameserver 192.168.5.78
Success: Nameserver 192.168.5.78 added
Command Result : 0 (Success)

This operation sets up the IP address for the Ethernet device for the HSM port (eth0 or eth1). Set up the IP address for an Ethernet device using the following sample as a guide:

[ade_luna_sa] lunash:>net interface -static -device eth0 -ip 192.168.5.200 -netmask 255.255.255.0 -gateway 192.168.5.1

If you are sure that you want to restart the network, then type 'proceed'; otherwise, type 'quit':

> proceed
Proceeding...
Restarting network service...
Shutting down loopback interface:  [ OK ]
Setting network parameters:  [ OK ]
Bringing up loopback interface:  [ OK ]
Bringing up interface eth0:  [ OK ]
Command Result: 0 (Success)

To verify your settings, use the ping command to ping the server name from the HSM environment using the following sample as a guide:

net ping <servername> or IP@
[ade_luna_sa] lunash:>net ping supreme.testLunadomain.testval.activcard.com
PING supreme.testLunadomain.testval.activcard.com (192.168.5.24) from 
192.168.5.200 : 56(84) bytes of data.
64 bytes from supreme.testLunadomain.testval.activcard.com (192.168.5.24): icmp_seq=0 ttl=128 time=492 usec
--- supreme.testLunadomain.testval.activcard.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.492/0.492/0.492/0.000 ms
Command Result: 0 (Success)

This operation adds a Network Time Protocol (NTP) server to the HSM server list. Add a server to the HSM server list using the following sample as a guide.

[ade_luna_sa] lunash:>sysconf ntp -addserver 192.168.5.200
Shutting down ntpd:                                  [ OK ]
Starting ntpd:                                       [ OK ]
NTP server 192.168.5.200 added
Command Result: 0 (Success)

The client’s network application and the HSM securely exchange data through a Network Trust Link (NTL). This operation changes the default certificate that is recorded in the HSM for NTLS (Network Trust Link Service) protected communications. Generate a new HSM server certificate using the following sample as a guide:

[ade_luna_sa] lunash:>sysconf regencert 192.168.5.200
WARNING!! This command will overwrite the current server certificate and private key.
All clients will have to add this server again with this new certificate.
If you are sure that you wish to proceed, then type 'proceed'; otherwise type 'quit':
> proceed
Proceeding...
'sysconf regenCert' successful. NTLS must be (re)started before clients can connect.
Please use the 'ntls show' command to ensure that NTLS is bound to an appropriate network device or IP address/hostname for the network device(s) NTLS should be active on. Use 'ntls bind' to change this binding if necessary.
Command Result: 0 (Success)

This command restarts NTLS on the HSM. Restart NTLS using the following sample as a guide:

[ade_luna_sa] lunash:>service r ntls
Checking for connected clients before stopping NTLS service:
There are no connected clients.  Proceeding...
Stopping ntls:                                             [ OK ]
Starting ntls:                                             [ OK ]
Command Result: 0 (Success)

The following command must be sent to bind NTLS (in the HSM) to the physical Ethernet port (eth0 or eth1). Bind NTLS using the following sample as a guide:

[ade_luna_sa] lunash:>ntls bind none -bind 192.168.5.200
Success: NTLS binding hostname or IP Address 192.168.5.200 set.
NOTICE: The NTLS service must be restarted for new settings to take effect.
If you are sure that you wish to restart NTLS, then type 'proceed'; otherwise type 'quit':
> proceed
Proceeding...
Restarting NTLS service...
Stopping ntls:                                             [ OK ]
Starting ntls:                                             [ OK ]
Command Result: 0 (Success)

ade_luna_sa] lunash:>ntls bind eth0

To check the correct execution of the binding, use the following command:

[ade_luna_sa] lunash:>ntls show
NTLS bound to network device: none IP Address: "192.168.5.200" (eth0)
Command Result: 0 (Success)

This option displays information related to the licenses, especially partition licenses. Display the maximum number of partitions that are available in your HSM using the following command (this sample illustrates a two-partition maximum):

[ade_luna_sa] lunash:>hsm displayLicenses
This option returns the HSM
HSM CAPABILITY LICENSES
License ID    Description
======     ===========
0, 9768e         K5Base
0, 9765f         ECC
0, 97660         KCDSA
0, 97656         Objects320
0, 97651         Performance1200
0, 97659         2 Partitions
0, 9768d         Offboard Storage KE
0, 9764d         FIPS3
Command Result:  0 (Success)

This operation completely clears up the HSM content. For example, existing partitions, keys, or any data that are recorded in the HSM are deleted.

During this procedure, a SafeNet iKey must be plugged into the PED device and assigned with a blue sticker. This iKey is owned by the HSM administrator. The HSM administrator is prompted to enter his PED key PIN directly on the PED device.

The HSM administrator may be prompted to create a red PED key called a Domain key. The Domain key contains the Key Domain Vector (shared across a group of HSMs) which is used to duplicate partitions in a clone HSM An exact copy of a Principal HSM. The keys stored in the Clone HSM are identical to those stored in the Principal HSM, allowing you to use multiple card issuance servers with the same card issuance master keys. Created with HSM manufacturer tools.. The initialization of the red PED key is optional for use in the ActivID KMS environment.

The following sample illustrates HSM initialization with a new label: ade_luna_sa. After performing the init operation, the administrator must login again.

lunash:> hsm init -label ade_luna_sa
[ade_luna_sa] lunash:>hsm init -label ade_luna_sa
CAUTION:      Are you sure you wish to re-initialize this HSM? All partitions and data will be erased.
              Type 'proceed' to initialize the HSM, or 'quit' to quit now.
              > proceed
Luna PED operation required to initialize HSM - use gray and blue PED keys.
Luna PED operation required to login as HSM Administrator - use blue PED key.
Luna PED operation required to generate cloning domain - use red PED key.
'hsm init' successful.
Please wait while the HSM is reset to complete the initialization process.
Command Result: 0 (Success)

Use the following command to display the HSM policies:

[ade_luna_sa] lunash:>hsm -showPolicies  
HSM Label:   ade_luna_sa 
Serial #:    950217 
Firmware:    4.6.1  
The following capabilities describe this HSM, and cannot be altered except using firmware or capability updates.
Description                              Value 
===========                   =====
Enable PIN-based authentication          Disallowed 
Enable PED-based authentication          Allowed
Performance level                        9 
Enable M of N                            Allowed 
Enable domestic mechanisms & key sizes   Allowed 
Enable masking                           Allowed 
Enable cloning                           Allowed 
Enable special cloning certificate       Disallowed 
Enable full (non-backup) functionality   Allowed 
Enable ECC mechanisms                    Allowed 
Enable non-FIPS algorithms               Allowed 
Enable MofN auto-activation              Allowed 
Enable SO reset of partition PIN         Allowed 
Enable network replication               Disallowed 
Enable Korean Algorithms                 Allowed 
FIPS evaluated                           Disallowed 
Manufacturing Token                      Disallowed 
Enable Remote Authentication             Allowed 
Enable forcing user PIN change           Allowed 
Enable offboard storage                  Allowed 
Enable partition groups                  Disallowed 
Enable non-FIPS accelerator mode         Disallowed  
The following policies are set due to current configuration of this HSM and cannot be altered directly by the user.
  Description                              Value 
===========                     ===== 
PED-based authentication                 True 
Require M of N                           False
The following policies describe the current configuration of this HSM and maybe changed by the HSM Administrator. Changing policies marked "destructive" will zeroize (erase completely) the entire HSM.
Description                              Value        Code      Destructive ===========                  =====     ====    =========== 
Allow masking                            On           6         Yes 
Allow cloning                            On           7         Yes 
Allow non-FIPS algorithms                On           12        Yes 
Allow M of N auto-activation             On           13        No 
SO can reset partition PIN               On           15        Yes 
Allow Remote Authentication              On           20        Yes 
Force user PIN change after set/reset    Off          21        No 
Allow offboard storage                   On           22        Yes  
Command Result: 0 (Success)

This operation physically creates a partition in the HSM that is identified by a partition name. During this process, the user will be asked to plug in an iKey that is assigned to the partition owner. The user must put a black sticker on the iKey, and then enter a PIN code.

In return, the PED displays a password that must be written down (see the following sample). This password is used later by the client application to authenticate to the partition.

[luna_sa1] lunash:>par cr -partition luna_sa1_part1
(Do not forget to save the password partition; for example: pTYF-45xG-pXbE-AHs4)
Please ensure that you have purchased licenses for at least this number of partitions:      1
If you have purchased licenses for at least this number of partitions then type 'proceed'; otherwise type 'quit':
> proceed
Proceeding...
Please ensure that you copy the password from the Luna PED and that you keep it in a safe place.
Luna PED operation required to create a partition - use black PED key.
'partition create' successful.
Command Result: 0 (Success)

This operation modifies policies 22 and 23 and allows for activation and auto-activation on partitions. These changes are needed for a HSM with PED. Partition Activation (Policy 22) enables a partition holder to authenticate once to the partition and not require the partition holder to leave his or her black PED key remaining connected to the PED device.

Auto-Activation consists of an automatic re-activation of the partition in cases where short power outages occur (the client application can reconnect and continue using the partition without re-asking the partition owner’s consent). Use the following sample as a guide:

[luna_sa1] lunash:>partition changePolicy -partition luna_sa1_part1 -policy 22 -value 1
'partition changePolicy' successful.
Policy "Allow activation" is now set to: 1
[luna_sa1] lunash:>partition changePolicy -partition luna_sa1_part1 -policy 23 -value 1
'partition changePolicy' successful.
Policy "Allow auto-activation" is now set to: 1
Notice:  Auto activation parameters will be stored during next activation. It is recommended you activate this partition now.
Command Result: 0 (Success)

This operation allows any registered client application to activate and use the partition. The client application passes the password returned by the PED device at the time the partition was created. The black PED key from the partition owner is plugged into the PED which requires the partition owner to enter the PIN for the PED key (as shown in the following sample):

[luna_sa1] lunash:>partition activate -partition luna_sa1_part1
Please enter the password for the partition: 
> *******************
pTYF-45xG-pXbE-AHs4
Luna PED operation required to activate partition - use black PED key.
'partition activate' successful
Command Result: 0 (Success)

This option can be enabled on each of the partitions. This mode may be used if the High Availability mode is configured. The High Availability (HA) mode of operation is described briefly in this section. For details, see About High Availability Mode. For information about HSM support for HA mode, please refer to Thales / Thales Trusted Cyber Technologies documentation.

You can change the password that is used by the client to authenticate to a partition. Use the following sample as a guide:

[luna_sa1] lunash:>partition changePw -partition luna_sa1_part1 -newpw 12365478 -oldpw pTYF-45xG-pXbE-AHs4

There are other options that are not documented in this documentation that you can use to manage (or aid your understanding of) existing partitions in the HSM. For more information, refer to the Thales / Thales Trusted Cyber Technologies documentation for details. For example, to use the Delete Partition option, the Security Officer or HSM administrator must be logged into the HSM (using a PED blue key), in addition to the partition owner using a black PED.

This section explains how to record the client (ActivID CMS/KMS) on the DNS from the network server (using TestLuna as an example). The ActivID CMS server/KMS must be known by the DNS associated with TestLuna. Using the Microsoft Terminal Services Commands and its utility, run the following commands:

mstsc.exe in C:\WINDOWS\system32, Connect to client (192.168.xxx.xxx), 
<username>, <password>

1. Under Administrative Tools, click DNS, and then under TESTLUNA right-click testluna.testval.activecard.com and then click New Host (A). The New Host window is displayed.

   

2. Name—Enter the name of the client machine.

3. IP address—Enter the corresponding IP address using dotted decimal notation.

4. Click Add Host.

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.

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:

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.

[ade_luna_sa] lunash:> client -register -client supreme -hostname supreme-
testLunadomain.testval.activcard.com
'client register' successful

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:

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

[ade_luna_sa] lunash:>client –show –client supreme
Client ID:     supreme
IPAddress:     192.168.5.174
Partitions: “ade_partition”

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.

Before you create an HA group, verify the following list of prerequisites.

• The Allow Cloning and Enable Network Replication parameters are enabled.

• Allow Cloning is already enabled according to parameters listed in Using the ‘showPolicies’ Command. For details, see Creating Partitions. Make sure that Enable Network Replication is enabled by running the following command:

  Copy

  [adr_luna_sa] lunash;>hsm –changePolicy –policy 16 -value 1

• All HSM group members that belong to the same cloning domain must use the same red PED key.

• Each HSM must have at least one partition created. There is no requirement to use the same partition name. However, each partition must be set using the same password. This is the password that authenticates the client.

• Record the serial number of each partition that is created on each HSM. These partition numbers are required during the creation of the HA group.

• Each partition can be configured to be Auto-Activated (if this is not already the case).

• Assign the client to each partition (found on each HSM). For details, see Procedure 6: Assign a Client to an HSM Partition.

Important: When the HA group is created from the physical partitions, and the virtual partition is configured, the client must not attempt to communicate with the physical partitions that are merged in this HA group. Instead, the client must access ONLY the virtual partition.

1. On the client system, open a DOS window from the following location (C:\Program Files\SafeNet\LunaClient), and then call the vtl software using the haAdmin option. For example:

   Copy

   Vtl haAdmin –newGroup –serialNum 902514001 –label ade_test –password 12345678



Note: The serial number in the following example corresponds to the partition number in the first HSM part of the group. The password represents the authentication password for the client that allows access to the virtual partition exposed by the HA group.

2. To access other partitions that are on other existing HSMs in the HA group, run the following commands:

   Copy

   Vtl haAdmin –addmemember –group [groupname] –serialNum {serial number for the other partition] –password [Partition password]

This section describes how to delete an HA group. Use the commands in the following example as a guide:

ActivID KMS forces the operator to select the partition to use during an ActivID KMS session when there is more than one partition available. If there is only a single partition, that partition is automatically selected. Each partition is identified by a slot ID number as well as a token name (partition name). To identity a partition, ActivID KMS displays both the slot ID and token name for each partition.

To choose the correct partition, configure an ActivID CMS file, which includes either the recorder slot ID or token name (partition name). For example, for ActivID CMS for Windows, perform the following steps:

1. Locate the cmsslot.ini file on the ActivID CMS distribution.

2. In the <CMS_distribution>\HSM folder:

   • Copy the cmsslot.ini file to the Windows folder of your ActivID CMS server.

   • In the cmsslot.ini file specify either a TokenName or a SlotID (if the cmsslot.ini file is not found, ActivID CMS chooses to connect to the slot that has the fewer number of sessions).

     Note: If High Availability has been configured, the cmsslot.ini file must contain a reference to either a physical partition or to a virtual partition.

3. Locate the %PROGRAMDATA%\HID Global\Credential Management System\Local Files\pkcs11.cfg file and add the following line:

   Copy

   slot=xxxxxx

where xxxxx is the SlotID.