The PKCS #11 subsystem provides applications a method for accessing hardware devices (tokens) in a device-neutral manner. The content in this chapter conforms to Version 2.01 of the PKCS #11 standard.
This subsystem has been implemented using the following components:
This chapter includes the following information:
The IBM 4758 Model 2 Cryptographic Coprocessor provides a secure computing environment. Before attempting to configure the PKCS #11 subsystem, verify that the adapter has been properly configured with a supported microcode.
The PKCS #11 subsystem is designed to automatically detect adapters capable of supporting PKCS #11 calls during installation and at reboot. For this reason, any IBM 4758 Model 2 Cryptographic Coprocessor which is not properly configured will not be accessible from the PKCS #11 interface and calls sent to the adapter will fail. Complete the following to verify that your adapter is set up correctly:
lsdev -Cc adapter | grep crypt
If the IBM 4758 Model 2 Cryptographic Coprocessor does not show in the resulting list, check that the card is seated properly and that the supporting software is correctly installed.
csufclu /tmp/l ST device_number_minor Verify that the Segment 3 Image has the PKCS #11 application loaded. If it is not loaded refer to the adapter specific documentation to obtain the latest microcode and installation instructions.
Note: If this utility is not available, then the supporting software has not been installed.
The PKCS #11 subsystem automatically detects devices supporting PKCS #11. However, in order for some applications to use these devices, some initial set up is necessary. These tasks include:
These tasks can be performed through the API (by writing a PKCS #11 application) or by using the SMIT interface. The PKCS #11 SMIT options are accessed either through Manage the PKCS11 subsystem from the main SMIT menu, or by using the smit pkcs11 fast path.
Each adapter or PKCS #11 token must be initialized before it can be used successfully. This initialization procedure involves setting a unique label to the token. This label allows applications to uniquely identify the token. Therefore, the labels should not be repeated. However; the API does not verify that labels are not re-used. This initialization can be done through a PKCS #11 application or by the system administrator using SMIT. If your token has a Security Officer PIN, the default value is set to 87654321. To ensure the security of the PKCS #11 subsystem, this value should be changed after initialization.
To initialize the token:
Note: This will erase all information on the token.
If the correct PIN is entered, the adapter will be initialized or reinitialized after the command has finished running.
If your token has an SO PIN, you can change the PIN from its default value, as follows:
After the token has been initialized, it might be necessary to set the user PIN to allow applications to access token objects. Refer to your device specific documentation to determine if the device requires a user to log in before accessing objects.
To initialize the user PIN:
To reset the user PIN, you can either reinitialize the PIN using the SO PIN or set the user PIN by using the existing user PIN. To do this:
Your token might not support strong cryptographic operations without loading a function control vector. Please refer to your device specific documentation to determine if your token needs a function control vector and where to locate it.
If a function control vector is required you should have a key file. To load the function control vector:
For an application to use the PKCS #11 subsystem, the subsystem's slot manager daemon must be running and the application must load in the API's shared object.
The slot manager is normally started at boot time by inittab calling the /etc/rc.pkcs11 script. This script verifies the adapters in the system before starting the slot manager daemon. As a result, the slot manager daemon is not available before the user logs on to the system. After the daemon starts, the subsystem incorporates any changes to the number and types of supported adapters without intervention from the systems administrator.
The API can be loaded either by linking in the object at runtime or by using deferred symbol resolution. For example, an application can get the PKCS #11 function list in the following manner:
d CK_RV (*pf_init)();
void *d;
CK_FUNCTION_LIST *functs;
d = dlopen(e, RTLD_NOW);
if ( d == NULL ) {
return FALSE;
}
pfoo = (CK_RV (*)())dlsym(d, "C_GetFunctionList");
if (pfoo == NULL) {
return FALSE;
}
rc = pf_init(&functs);