Initial Configuration

In this section, it is assumed that:

>ProtectToolkit-C has been successfully installed on your system

>you can access the ProtectToolkit-C utilities used to carry out configuration tasks, as described in Configuration Items.

Synchronizing the HSM Time With the System Clock

When setting up a ProtectServer HSM for the first time, use the ctconf utility to synchronize the HSM with the system clock, to ensure that logs are produced with the correct time stamps (see ctconf).

To synchronize the HSM time with the system clock

Use the following command:

ctconf -t

Setting the Admin Token PINs

Following an initial installation or tamper event, it is necessary to introduce the Administrator and Administrator SO user roles by setting their initial PINs. This is done using the ctconf utility.

To set the Admin token PINs

1.From a command prompt, type ctconf and press ENTER.

You are prompted to set the Administration Security Officer (ASO) PIN. User PINs are case-sensitive, and must be 4-32 characters in length.

2.Enter the ASO PIN and press Enter. Enter this same PIN again for confirmation.

NOTE   PIN characters or asterisks (*) do not appear on screen while the PIN is being typed. For details of what constitutes a valid PIN see PINs and Passwords.

You are prompted to set the Administrator PIN. User PINs are case-sensitive, and must be 4-32 characters in length.

3.Enter the Administrator PIN and press Enter. Enter this same PIN again for confirmation.

4.On board each HSM is a real-time clock (RTC). If the RTC is out of synchronization with the host system clock, you are then prompted to allow synchronization. To synchronize the RTC to the host system clock type Y and then Enter. Otherwise, type N to abort.

After successful completion of the above, HSM configuration details are displayed. For example:

Current Adapter Configuration for Device 0:
Model             : PSI-E2:PL220
Serial Number     : 518687
Adapter Clock     : 30/08/2016 15:07:04 (-5:00+DST)
Battery Status    : GOOD
Security Mode     : Default (No flags set)
Transport Mode    : None
FM Support        : Enabled
FM Status         : No FM downloaded yet
Open Session Count: 0
Number of Slots   : 1
RTC Adjustment Access Control: Disabled

Following this, this message is displayed:

PLEASE NOTE that the firmware allows FMs to be downloaded; but the "Tamper 
before upgrade" security flag is not set. To protect existing keys against a
possible threat of a rogue FM, this flag should be set (using 'ctconf -ft')

NOTE   An FM is a functionality module. For more information see Installing a Functionality Module.

Finally, the utility closes and the operating system command prompt returns.

Selecting and Setting a Security Policy

A security policy is a set of security settings that control how ProtectToolkit-C is allowed to function. Setting the security policy is the most important part of ProtectToolkit-C initial configuration.

A number of security settings offered by ProtectToolkit-C can be used to implement typical security policies that meet certain standards or satisfy application integration requirements. Alternatively, custom security policies can be implemented.

Refer to Security Policies and User Roles for full details and instructions.

Setting up Slots

The Administrator will have to decide on the number of slots required for the particular environment. In its default initial configuration, ProtectToolkit-C will have one User slot, one Admin slot and one slot for each connected smart card reader.

As a general guide, the Administrator should create as many slots as there are applications, or users, that will want to perform PKCS #11 processing. This configuration allows for individual applications to be completely separate from each other.

For more information on the types of slots and tokens, see Slots and Tokens.

To create new user slots

Use the ctconf utility with the -c switch.

Example:

ctconf -c2

Since only the Administrator is authorized to create new slots, you will be prompted for the Administrator PIN.

This command will create two new User slots, each with an associated token. To check that the slots were created, use the ctstat utility, which will report information on all current slots and tokens.

Slots are numbered consecutively, with the last or highest slot number always being the Admin slot.

Example:

The current configuration is:

User	User	Admin
Slot 0	Slot 1	Slot 2

If two slots are added, the configuration becomes:

User	User	User	User	Admin
Slot 0	Slot 1	Slot 2	Slot 3	Slot 4

Multiple Adapter HSMs

When multiple HSM adapters (such as the ProtectServer PCIe HSM) are installed in a single machine, there will be multiple Admin slots - one per HSM. The slots for the second HSM will appear directly following the slots for the first HSM. Thus if two HSMs were installed with their default configuration, slot 0 and slot 2 would be user slots, slots 1 and 3 would be the Admin slots for the first and second HSM respectively.

Example:

HSM 1		HSM 2
User	Admin	User	Admin
Slot 0	Slot 1	Slot 2	Slot 3

Token Initialization

After creating a slot within ProtectToolkit-C, the token within that slot must be initialized so it may be used by an application. This initialization will assign a label and set up the Security Officer and User PINs for that token. In addition to initialization of User slots, this procedure is also applicable to any smart card tokens used with ProtectToolkit-C.

The party responsible for token initialization depends on the Security Policy that has been set for the adapter. In the case where ‘clear PINs’ are allowed, any user taking on the role as that token’s Security Officer can perform the token initialization. In the case where ‘clear PINs’ are not allowed, only the Administrator can perform the token initialization. For more information on Security Policies, see Security Policies and User Roles.

To initialize a token

The ctconf utility is used by the Administrator to initialize a token on a particular slot. Once a token is initialized, it may only be reinitialized, or reset, by the token SO, using the ctkmu or ctconf utility.

Example:

ctconf -n1

This example will initialize token 1 in slot 1.

ctconf will prompt for the token label to be entered, followed by the token SO PIN.

NOTE   A token initialization will destroy all objects on that token.  This is an important consideration when reinitializing a token that has already been used.

Following initialization of a token, the token SO should change the PIN set by the Administrator with the ctkmu utility. Instructions are provided in Changing a User or Security Officer PIN.

Next, the token SO must initialize the token user PIN using the ctkmu utility.

Example:

ctkmu p -s2

This example will initialize the user PIN on token 2. The SO PIN will be prompted for, followed by a prompt for the new User PIN.

Once both the SO and User PINs have been selected, the token is ready for use with an application. The User is advised to change his/her PIN from the one the SO assigned by repeating the above command.