C_Login

This function operates as specified in PKCS#11 with the following exceptions:

>If the security mode NoClearPINs is enabled, then the pin value is encrypted by the host library before it is supplied to the module.

>To negate a brute force attack on the PIN, after the third failed attempt, a delay is imposed delay (incrementing in multiples of 5 seconds) until the next presented PIN is checked.

For example, after the third failed attempt, the device imposes a delay of 1*5 seconds, after the fourth the delay is 2*5=10 seconds, after the fifth, the delay is 3*5=15 seconds, and so on.

If a PIN presentation occurs before the delay period has expired, the attempt fails with CKR_PIN_LOCKED.

Synopsis

C_Login(
        CK_SESSION_HANDLE hSession,
        CK_USER_TYPE userType,
        CK_CHAR_PTR pPin,
        CK_ULONG ulPinLen
); 

Operation in WLD Mode

When SafeNet ProtectToolkit is configured to operate in WLD mode, the login state is replicated across all tokens in user slots associated with the same WLD slot. For example, if an application has 3 sessions, across 3 HSMs, with one session on each HSM then any change in the login state in one session, will result in the session on the other 2 HSMs being changed to the same session state. 

Temporary Pin Login

Under Cryptoki all authentication of users to the HSM is valid for the calling process only. Each application must authenticate separately. Once a process has authenticated is granted appropriate access to the services of the token.

With SafeNet ProtectToolkit-C - if a process forks a new process then the new process must authenticate itself - it can not inherit the authentication of the parent.

The Temporary Pin feature in this spec describes a new applications authentication method where a parent process can pass on its authentication to a child process without having to pass the sensitive pin value.

Challenge Response Login

A new type of User Authentication is provided. Instead of having to present the Pin value directly to the HSM the user will request a random challenge, for a specified password, from the HSM and then present a response computed from the challenge and password using a One Way Function.

The HSM will authenticate the user by verifying the response with the specified password and the most recently issued random challenge.

A new CKO_HW_FEATURE object called CKH_VD_USER is provided by the firmware to allow the application to obtain the random challenge for either the User Password or SO Password.

The Object has an attribute that an application can read to generate and obtain a random challenge.

A new challenge value will generated each time the attribute is read. A separate Challenge is held for each registered application. The same challenge can be used for User or SO authentication.

The calling application converts the challenge into a Response by using the following algorithm:-

Response = SHA-256( challenge | PVC)

Where PVC = LEFT64BIT( SHA1(password | userTypeByte)

A host side static library function CT_Gen_Auth_Response is provided in the SDK to assist developers in using this scheme.

The CKH_VD_USER has an attribute that an application can read to generate and obtain a Temporary PIN. Only one SO and one User Temporary PIN may exist at any one time in any single Token. Each read from this attribute will generate a new Temporary PIN.

Any Temporary PINs in a Token are automatically destroyed when the generating process logs off or is terminated or the HSM has reset – whichever comes first.

The Response and Temporary PIN are passed to the HSM using the C_Login function. The Function will be extended such that unused bits in the userType parameter will be set to indicate that a Response value or Temporary PIN is being used instead of the normal password.

The following bits are added to the userType parameter of the C_Login Function to specify the type of authentication required.

#define CKF_AUTH_RESPONSE           0x00000100
#define CKF_AUTH_TEMP_PIN           0x00001000