The ProtectToolkit-C Model
The model for ProtectToolkit-C is based on standard PKCS #11 processing. ProtectToolkit-C running in hardware mode is depicted below to show how an application sends requests to a token via the PKCS #11 interface.
Figure 1: ProtectToolkit-C Model
Slots and Tokens
In the PKCS #11 model, a slot represents a device interface and a token represents the actual cryptographic device. For example, a smart card reader would represent a slot and the smart card would represent the token.
ProtectToolkit-C supports three different slot types: user slots, smart card slots and admin slots. These are described below.
User Slots
User slots are created by the Administrator for use with applications. Each slot automatically holds a User token. All cryptographic mechanisms are supported with these tokens. The system is configurable such that any number of User slots may be created. It is also possible to specify the security policy setting for these slots.
In the default configuration, a single User slot is available. The Administrator can add more slots as required for the local configuration. HSM performance degrades as the number of slots increases. Creating too many slots may cause unacceptable performance. To ensure reasonable performance, it is recommended that you create no more than 200 slots.
Smart Card Slots
Smart card slots are automatically created and configured for each smart card reader attached to the HSM's external serial ports. The smart card tokens can be used for storage of data objects. Their primary purpose is key backup and restoration. To protect objects stored on the token from unauthenticated access, these objects may be PIN-protected. The smart card slots do not support cryptographic operations.
When a supported smart card token is inserted into a configured smart card slot, it will become available to the ProtectToolkit-C system. New smart card tokens are blank and require initialization before use. The storage format and layout of files on the tokens is proprietary and can store a maximum of 5 objects (up to the storage capacity of the actual token). Objects may be deleted; however, the storage allocated to the object is not reclaimed until the token is re-initialized by the Security Officer or Administrator.
The Admin Slot
The Admin slot is designated for the administrator and is used for configuration and administration of the HSM. There is only one Admin slot for each HSM.
The Admin slot holds the Admin token and it is on this token that the administration objects reside. For more information about administration objects, see Administration Objects.
PKCS #11 Objects
As shown in ProtectToolkit-C Model, each token may contain a number of objects. The PKCS #11 standard allows for these different types of objects:
>Data objects, which are defined by an application
>Certificate objects, which represent digital certificates such as X.509
>Key objects, which can be public, private or secret cryptographic keys
Each object in the system is comprised of a number of attributes. These attributes describe the actual object as well as the access policy for that object. For example, each object may be classified as public or private; this classification determines who may access the object. A public object is visible to any user (or application), whereas a private object is only visible once the user is authenticated to the token where that object is stored.
For a complete description of the object attributes, see PKCS #11 Attributes.
NOTE It is recommended that the number of objects stored in any single token be less than 1000, and that the number of objects stored on the entire HSM be less than 2000.
Administration Objects
In addition to the object classes defined within PKCS #11, ProtectToolkit-C introduces a new set of objects known as administration objects.
The administration objects represent the hardware and contain HSM configuration settings. They can be queried by the application and some can be modified by an administrator. The default administration objects are automatically created when ProtectToolkit-C initializes.
The administration objects reside on a special token referred to as the Admin token. This token has a fixed security policy. The Admin token resides only in the Admin slot on the HSM.
User Roles
As part of the ProtectToolkit-C configuration process, different user roles are assigned to those responsible for the application’s administration and use.
For ProtectToolkit-C there are four defined roles available. These are:
>Security Officer (SO)
>Token Owner or User
>Administration Security Officer (ASO)
>Administrator
Standard PKCS #11 defines the first two of these, the Security Officer (SO) and the Token Owner or User. Each slot and its associated token will have an SO and a User, each with their own respective PINs.
>A Security Officer grants and revokes access to a token and assists with key backups
>A Token Owner uses the token for the application
Two additional roles are defined that are only available on the Admin token. The holders of these roles handle HSM-level administration and management. These are the Administration Security Officer (ASO) and the Administrator. These roles effectively mirror their standard PKCS #11 counterparts.
NOTE The services available to the various roles depend on the security policy set for the HSM.
PINs and Passwords
PINs and passwords are used to authenticate users and to provide access to secured computer systems. In Cryptoki and ProtectToolkit-C, they are defined as variable-length strings of characters selected from the ANSI C character set. User PINs are case-sensitive, and must be 4-32 characters in length. If you are using Multifactor Authentication (One-Time Password), the PIN length becomes 10-38 characters (userpin + OTP).
NOTE The term password is not defined as something distinct from a PIN in Cryptoki environments. You will find the terms used interchangeably in Cryptoki-related documentation.
PIN Retry Delay
A brute-force search of PINs can be stopped using two approaches:
1.Prevent logging in after a certain number of PIN failures.
2.Enforce a time-delay between login attempts after a certain number of PIN failures.
The time-delay approach is used for ProtectToolkit-C implementations utilizing the ProtectServer Network HSM.
After the third failed PIN presentation, the device imposes a delay (lengthening in increments of 5 seconds) before the next presented PIN is checked:
>third failed attempt = delay of 5 seconds
>fourth failed attempt = delay of 10 seconds
>fifth failed attempt = delay of 15 seconds
>etc.
If a PIN presentation occurs before the delay period has expired, the attempt fails with an error indicating that the PIN is locked.
