This library supports 2.40 Version of PKCS 11 (see https://www.oasis-open.org/committees/pkcs11/). It currently supports two types of "fixed" tokens. The first token is a KMIP server (see https://www.oasis-open.org/committees/kmip/). The second token is P6R's software token which uses P6R's Powerful Keystore (see https://www.p6r.com/articles/2011/06/05/key-management-with-a-powerful-keystore/) to store all PKCS 11 objects (e.g., CKO_SECRET_KEY, CKO_PUBLIC_KEY, CKO_PRIVATE_KEY, CKO_CERIFICATE, CKO_DOMAIN_PARAMTERS, CKO_DATA). Any number of slots can be defined and in each slot either type of token can be configured. For example, it is possible to have a PKCS 11 installation that points to several different KMIP servers and several different P6R software token instances each separate from the others. One of the benefits of the PKCS 11 API is that it provides a standard based Keystore API.
The current library meets the requirements for conformance of a PKCS #11 Baseline and Extended Provider (see PKCS #11 Cryptographic Token Interface Profiles Version 2.40, 16-Sep-2014, OASIS Committee Specification 01, http://docs.oasis-open.org/pkcs11/pkcs11-profiles/v2.40/cs01/pkcs11-profiles-v2.40-cs01.doc).
In a future release, this library will allow the user to define their own token types by defining a "plugin" component to extended its function.
An introduction to this product can also be found at: P6R's PKCS 11 Provider, https://www.p6r.com/articles/2014/11/22/p6rs-pkcs-11-provider/.
P6R's PKCS 11 client follows the standards defined in the following documents.
1) OASIS, PKCS #11 Cryptofraphic Token Interface Base Specification Version 2.40, Candidate OASIS Standard 01, 23 December 2014.
2) OASIS, PKCS #11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40, Candidate OASIS Standard 01, 23 December 2014.
3) OASIS, PKCS #11 Cryptographic Token Interfaces Historical Mechamisms Specification Version 2.40, Candidate OASIS Standard 01, 23 December 2014.
This library ships with the standard set of PKCS 11 2.40 ".h" files.
Note, the pkcs11.h file is meant to be slightly modified for the particular library and platform and we have made such modifications for use with our library. The pkcs11p6r.h file contains P6R vendor defined extensions.
The KMIP token uses the facilities of a remote KMIP server to implement the features of the PKCS 11 Version 2.40 API. A KMIP token is defined by a set of configuration parameters defined in the p6pkcs11.conf file (see Section "Basic Configuration Parameters"). This token type uses P6R's Secure KMIP Client (SKC) SDK (see https://www.p6r.com/software/skc.html) to communicate with the defined KMIP servers. As of this writing, SKC works with all known commercially available KMIP servers. Our PKCS11 library allows the definition of any number of KMIP tokens all pointing to the same or different KMIP servers.
The KMIP token has the following limitations with object attributes. CKA_ENCRYPT, CKA_DECRYPT, CKA_SIGN, CKA_SIGN_RECOVER, CKA_VERIFY, CKA_VERIFY_RECOVER, CKA_WRAP, CKA_UNWRAP, and CKA_DERIVE CANNOT be changed after an object (i.e., key, certificate, data, domain parameters) is created. This is because the KMIP protocol does not allow a client to modify the KMIP equivalent attributes after a KMIP object is created. However, this token implementation does support the modification of a CKO_DATA object’s CKA_VALUE attribute after the object has been created on a KMIP server.
If logging is turned on (see the Basic Configuration Parameters section below), then a directory will be created under the defined log path with the KMIP server's fully qualified domain (FQDN) name as the directory name (e.g., "../log/kmip01.corp.p6r.com" is created). Under the FQDN directory another directory is also created with the following format: "p6pkcs11-slot-X", where 'X' is replaced with the slot number starting at zero.
The following is a list of all supported PKCS 11 functions: C_Initialize, C_Finalize, C_GetInfo, C_GetFunctionList, C_GetSlotList, C_GetSlotInfo, C_GetTokenInfo, C_GetMechanismList, C_GetMechanismInfo, C_InitToken, C_InitPIN, C_SetPIN, C_OpenSession, C_CloseSession, C_CloseAllSessions, C_GetSessionInfo, C_Login, C_Logout, C_CreateObject, C_DestroyObject, C_GetAttributeValue, C_SetAttributeValue, C_FindObjectsInit, C_FindObjects, C_FindObjectsFinal, C_GenerateKey (not including domain parameters), C_GenerateKeyPair, C_SeedRandom, C_GenerateRandom, C_SignInit, C_Sign, C_VerifyInit, C_Verify, C_EncryptInit, C_Encrypt, C_EncryptUpdate, C_EncryptFinal, C_DecryptInit, C_Decrypt, C_DecryptUpdate, C_DecryptFinal, C_DigestInit, C_Digest, C_DigestUpdate, C_DigestKey, C_DigestFinal, C_WrapKey, and C_UnwrapKey.
Note, that not all KMIP servers will support the C_UnwrapKey function. In some cases, the KMIP token will detect this and then return the error code CKR_FUNCTION_NOT_SUPPORTED. In other cases, the C_UnwrapKey call will succeeded but subsequent attempts to retrieve the unwrapped key via calls to C_GetAttributeValue will fail, since the key remains in its wrapped format on the KMIP server.
Note, that not all KMIP servers support streaming operations such as C_EncryptUpdate, C_EncryptFinal, C_DecryptUpdate, C_DecryptFinal, C_DigestUpdate, C_DigestKey, C_DigestFinal. These streaming operations where added to KMIP 1.3 and are optional. When a server does not support these, or the KMIP version in use is not 1.3, then the error code CKR_FUNCTION_NOT_SUPPORTED will be returned for these PKCS 11 functions.
Currently, C_WrapKey ignores the CKA_WRAP_TEMPLATE attribute, and C_UnwrapKey ignores the CKA_UNWRAP_TEMPLATE attribute. These should be supported in the near future.
For the CKM_RSA_PKCS_KEY_PAIR_GEN mechanism C_GenerateKeyPair() only works if the attribute CKA_PUBLIC_EXPONENT is not included in the call. Thus for the KMIP token RSA key generation only needs the CKA_MODULUS_BITS attribute.
P6R's software token (or "soft token") uses P6R’s cryptographic API and Keystore to implement the features of the PKCS 11 Version 2.40 API. Both the cryptographic API and Keystore are included as part of the SKC product. Our PKCS 11 library allows the definition of any number of Software tokens where each token gets its own separate secure Keystore to manage PKCS 11 objects (e.g,. keys, certificates, domain parameters, data). P6R’s cryptographic API is a C++ object wrapper around OpenSSL’s C language API.
The location of each token's keystore id defined in configuration (see the Basic Configuration Parameters section below). The keystore's file created follows the format: "p6pkcs11-slot-X" where 'X' is replaced with the slot number starting at zero. The file 'p6pkcs11-slot-X.sig' is also created as long as the keystore in use is a local database.
The following is a list of all supported PKCS 11 functions: C_Initialize, C_Finalize, C_GetInfo, C_GetFunctionList, C_GetSlotList, C_GetSlotInfo, C_GetTokenInfo, C_GetMechanismList, C_GetMechanismInfo, C_InitToken, C_InitPIN, C_SetPIN, C_OpenSession, C_CloseSession, C_CloseAllSessions, C_GetSessionInfo, C_Login, C_Logout, C_CreateObject, C_DestroyObject, C_GetAttributeValue, C_SetAttributeValue, C_FindObjectsInit, C_FindObjects, C_FindObjectsFinal, and C_GenerateRandom.
A third party can create their own token types by implementing the p6tokenimpl.h interface in a P6R component.
The following are unsupported PKCS 11 features of P6R's KMIP and Software tokens and do not define any limits on third party provided tokens.
The following object attributes are unsupported in the current release: CKA_PRIME_BITS, CKA_SUBPRIME_BITS, CKA_SECONDARY_AUTH, CKA_AUTH_PIN_FLAGS, CKA_WRAP_TEMPLATE, CKA_UNWRAP_TEMPLATE, CKA_HW_FEATURE_TYPE, CKA_PIXEL_X, CKA_PIXEL_Y, CKA_RESOLUTION, CKA_CHAR_ROWS, CKA_CHAR_COLUMNS, CKA_COLOR, CKA_BITS_PER_PIXEL, CKA_CHAR_SETS, CKA_ENCODING_METHODS, CKA_MIME_TYPES, CKA_MECHANISM_TYPE, CKA_REQUIRED_CMS_ATTRIBUTES, CKA_DEFAULT_CMS_ATTRIBUTES, CKA_SUPPORTED_CMS_ATTRIBUTES, CKA_RESET_ON_INIT, CKA_HAS_RESET, CKA_VALUE_BITS, CKA_VALUE_LEN
The following objects are unsupported in the current release: CKO_HW_FEATURE, CKH_MONOTONIC_COUNTER, CKH_CLOCK, CKH_USER_INTERFACE
P6R’s Provider allows any number of slots to be defined and in each slot either type of token can be configured. For example, it is possible to have a PKCS 11 installation that points to several different KMIP servers and several different software token instances each separate from the others. All slots and tokens are defined via a the p6pkcs11.conf configuration file. This configuration file allows the definition of any P6R or customer specific behavior since the PKCS 11 interface is fixed by the OASIS Technical Committee. All keys and certificates required to communicate with a KMIP server or to encrypt/sign a Keystore’s contents are themselves securely stored in a PKCS 11 wide Keystore once the library is initialized.
The current KMIP token library supports the following mechanisms: CKM_AES_KEY_GEN, CKM_CAST5_KEY_GEN, CKM_BLOWFISH_KEY_GEN, CKM_TWOFISH_KEY_GEN, CKM_CAMELLIA_KEY_GEN, CKM_RC2_KEY_GEN, CKM_RC4_KEY_GEN, CKM_RC5_KEY_GEN, CKM_IDEA_KEY_GEN, CKM_SKIPJACK_KEY_GEN, CKM_DES_KEY_GEN, CKM_DES3_KEY_GEN, CKM_RSA_PKCS_KEY_PAIR_GEN, CKM_EC_KEY_PAIR_GEN, CKM_MD2_RSA_PKCS, CKM_MD5_RSA_PKCS, CKM_SHA1_RSA_PKCS, CKM_SHA224_RSA_PKCS, CKM_SHA256_RSA_PKCS, CKM_SHA384_RSA_PKCS, CKM_SHA512_RSA_PKCS, CKM_DSA_SHA1, CKM_DSA_SHA224, CKM_DSA_SHA256, CKM_ECDSA_SHA1, CKM_AES_CBC, CKM_BLOWFISH_CBC, CKM_BLOWFISH_CBC_PAD, CKM_TWOFISH_CBC, CKM_CAMELLIA_ECB, CKM_CAMELLIA_CBC, CKM_DES_ECB, CKM_DES_CBC, CKM_DES_CBC_PAD, CKM_IDEA_ECB, CKM_IDEA_CBC_PAD, CKM_CAST5_ECB, CKM_CAST5_CBC, CKM_CAST5_CBC_PAD, CKM_AES_OFB, CKM_AES_CFB8, CKM_AES_CFB64, CKM_AES_CFB128, CKM_SHA_1_HMAC, CKM_SHA224_HMAC, CKM_SHA256_HMAC, CKM_SHA384_HMAC, CKM_SHA512_HMAC, CKM_AES_CMAC, CKM_SHA_1, CKM_SHA224, CKM_SHA256, CKM_SHA384, CKM_SHA512, CKM_SHA512_224, CKM_SHA512_256, CKM_MD2, CKM_MD5, CKM_RIPEMD160, CKM_RC2_ECB, CKM_RC2_CBC, CKM_RC2_CBC_PAD, CKM_DES3_ECB, CKM_DES3_CBC, CKM_RC4, CKM_SKIPJACK_ECB64, CKM_SKIPJACK_CBC64, CKM_SKIPJACK_OFB64, and CKM_SKIPJACK_CFB64.
If a specific KMIP server does not support one of the above mechanisms (e.g., CKM_EC_KEY_PAIR_GEN), then it can be "disabled" via an entry in the p6pkcs11.conf file for the specific slot (see the description of the tokenDisabledMechs configuration parameter in Section "Basic Configuration Parameters").
P6R defines the following vendor defined attributes:
The purpose of this extension is to provide basic support for KMIP groups and it maps into the KMIP "Object Group" attribute. Without the CKA_P6R_GROUP attribute defined the standard "default" group is used. P6R's Keystore has the concept of namespaces. These are similar to groups in that they provide collections of objects. When CKA_P6R_GROUP is used for the Software token its value is mapped into the Keystore's namespace parameter. Without the CKA_P6R_GROUP attribute defined the Software token uses "PKCS11" namespace by default.
P6R defines the following vendor defined method:
P6R_DestroyToken() frees all contents in the token and disables its containing slot. This method is added so that a PKCS 11 application can remove a token programmatically.
Only the SO can make this call. The call cannot be made on a token that currently has any in-progress sessions (otherwise the CKR_SESSION_EXISTS error is returned). This function deletes all the stored content on a token and disables the token and slot from use. The slot is disabled by writing the slot identifier into the file specified in the "disabled" configuration parameter (see Section "Basic Configuration Parameters" below). Once a slot is disabled it will not be able to be used or (re-)initialized. Also calls to C_GetSlotInfo() and C_GetTokenInfo() will not return previous slot/token information.
To reuse the slot the SO must enable the slot again by removing its slot identifier from the file defined by the "disabled" configuration parameter, and then redefine (as desired) its token configuration in the p6pkcs11.conf file. Once completed the token can then be initialized as if new.
Return values: CKR_CRYPTOKI_NOT_INITIALIZED, CKR_ARGUMENTS_BAD, CKR_SLOT_ID_INVALID, CKR_SESSION_EXISTS, CKR_PIN_INCORRECT, CKR_DEVICE_ERROR, CKR_GENERAL_ERROR, CKR_FUNCTION_FAILED, CKR_OK
A slot is defined by a section in the p6pkcs11.conf file of the form: "[p6pkcs11-slot-X]". where "X" is replaced with the slot number. An example of such a configuration file with 3 slots where 2 are KMIP tokens and the 3rd is P6R's software token. Many of the configuration items match to standard slot and token information returned by the C_GetSlotInfo() and C_GetTokenInfo() PKCS 11 API functions. In addition to the configuration defined in this section, change to the p6kmip.conf file for KMIP logging is recommended (see the SKC documentation).
Other possible token configuration items:
Restrictions: 1) Each KMIP token must point to a different KMIP server. A KMIP server is defined by the "tokenKMIPServer" configuration parameter and is a fully qualified domain name with an optional port (e.g., "kmiptest01.p6r.com", "kmiptest01.p6r.com:5696"). Thus each slot "contains" a unique token. Note that multiple sessions are supported for each KMIP token. This restriction also prevents one slot from re-initializing its token out from under another slot with the same KMIP token definition.
The "[p6pkcs11-gen]" section contains the following PKCS 11 wide configuration parameters:
The "baseKeyPath" configuration parameter (string value), is the symmetric key protecting the PKCS 11 wide keystore is to be written to after it is generated by the library. This parameter can be either a full path to the key file or just the name of the key file. If it is just a file name then it will be treated as relative to the directory the library runs out of. Essentially, this is the one key that is kept in the clear.
The "keystore" configuration parameter (string value), is optional and can be either the full path to a directory where the PKCS 11 library wide keystore is to be created or a database URI of the standard for: "postgresql8://..." (see Keystore documentation). When this parameter is not provided then a default location is used. Otherwise, when using the full path to a local directory then a Sqlite database will be used. This keystore holds all the keys and certificates used to communicate to KMIP servers and all keys used to protect all other keystores created for software tokens.
The "logDir" configuration parameter (string value), is optional and when not provided a default location is used. Otherwise, the parameter must be a full path to the diretory where PKCS 11 log statements output should be written to.
The "disabled" configuration parameter (string value), is the full path to a file to create that holds all disabled slots as a result of executing the P6R_DestroyToken() extension method. The path must be to a writtable directory. This parameter is optional and is only required if the P6R_DestroyToken() method is to be used.
The "initialSessions" configuration paramter (positive numeric value), is optional and defines the number of possible, concurrent PKCS 11 library wide sessions to start with. This number will be used to pre-allocate sonme of the client memory to support those initial number of sessions. Note that the total number of open sessions is dynamic and will grow as need and as memory permits. This paramter defaults to 200. Note that each active session requires a chunk of memory to maintain its state.
The "pkcs11LibFlags" configuration parameter (bit mask), is optional and defines special library wide handling or features. The current set of valid flags are: { 1 for Recover PKCS11 keystore from Signature Mismatch error (0x80040011)}.
The "[p6pkcs11-slots-gen]" section contains the following PKCS 11 configuration parameters global across all defined slots:
The "slotCount" configuration paramter (positive numeric value), defines the number of slots defined by the p6pkcs11.conf file. Each defined slot gets its own configuration file section such as "[p6pkcs11-slot-X]" where 'X' is replaced with a positive integer starting at zero. With a slotCount of 3 the following configuration file sections should exist: "[p6pkcs11-slot-0]", "[p6pkcs11-slot-1]", "[p6pkcs11-slot-2]".
The "[p6pkcs11-tokens]" section contains third party token implementations via the p6tokenimpl.h interface definition.
Each item in this section consists of a token "name" with its component GUID. For example: test-template = "{2719EAA2-CBCC-44aa-8D76-3B63427F33E7}", defines a token named "test-template" with a component GUID of "{2719EAA2-CBCC-44aa-8D76-3B63427F33E7}". This section can contain any number of token implemenation definitions. In the configuration example above, the "[p6pkcs11-slot-2]" section defines its token implementation via the parameter: slotType="test-template".
When the "[p6pkcs11-slot-X]" section defines a Software token the following configuration parameters apply:
The "slotDescription" configuration parameter (string value), maps to the "slotDescription" field of the CK_SLOT_INFO PKCS 11 API structure. This field is limited to a maximum of 64 characters.
The "slotFlags" configuration parameter (positive numeric value), maps to the "flags" field of the CK_SLOT_INFO PKCS 11 API structure. Valid values of this flag field are defined in the specification: PKCS #11 Cryptographic Token Interface Base Specification Version 2.40, Section 3.2 Slot and token types, Table 5, Slot Information Flags.
The "slotManufacturer" configuration parameter (string value), maps to the "manufacturerID" field of the CK_SLOT_INFO PKCS 11 API structure. This field is limited to a maximum of 32 characters.
The "slotType" configuration parameter (string value), this is a P6R defined configuration value which defines the token type that runs out of the defined slot. Current valid P6R token names are: { "P6R-keystore", "P6R-KMIP" } where the first value is used to define a Software token and the second value is used for a KMIP token. This parameter can be used to specify a 3rd party token implementation defined in the "[p6pkcs11-tokens]" section. The token name indicates which token type is to be used by the slot and the PKCS 11 library ensures that the proper implementation is used.
The "tokenFirmwareVersion" configuration parameter (string value), maps to the "firwareVersion" field of the CK_TOKEN_INFO PKCS 11 API structure. For software tokens we use this field to define the version of the PKCS 11 library itself since the Software token is built into the library.
The "tokenManufacturer" configuration parameter (string value), maps to the "manufacturerID" field of the CK_TOKEN_INFO PKCS 11 API structure. For software tokens we use this field to define P6R as the manufacturer.
The "tokenModel" configuration parameter (string value), maps to the "model" field of the CK_TOKEN_INFO PKCS 11 API structure. Again for software tokens we use this field to define the value "KEYSTORE 1.3".
The "tokenSoftKeystore" configuration parameter (string value), is optional and can either the full path to a directory where the slot's keystore is to be created or a database URI of the standard for: "postgresql8://..." (see Keystore documentation). When this parameter is not provided then a default location is used. Otherwise, When using the full path to a local directory then a Sqlite database will be used. This keystore holds all the PKCS 11 defined objects for this token (e.g., CKO_SECRET_KEY, CKO_PUBLIC_KEY, CKO_PRIVATE_KEY, CKO_CERIFICATE, CKO_DOMAIN_PARAMTERS, CKO_DATA).
The "tokenDefaultGroup" configuration parameter (string value), can be used instead of the CKA_P6R_GROUP vendor attribute extension. For the KMIP Token this parameter maps to the KMIP "Object Group" attribute. For the Software Token is parameter maps to the P6R's Keystore namespace parameter. When not specified the library uses "PKCS11" as the built in default group.
When the "[p6pkcs11-slot-X]" section defines a KMIP token the following configuration parameters apply:
slotDescription, slotFlags, slotManufacturer, slotType, tokenFirmwareVersion, tokenManufacturer, tokenModel, and tokenDefaultGroup all are the same as described above.
The "tokenHardwareVersion" configuration parameter (string value), maps to the "hardwareVersion" field of the CK_TOKEN_INFO PKCS 11 API structure. This and the tokenFirmwareVersion can be used to define versions of the remote KMIP server.
The "tokenMaxSession" configuration parameter (string value), maps to both the "ulMaxSessionCount" and "ulMaxRwSessionCount" fields of the CK_TOKEN_INFO PKCS 11 API structure. If this string is set to "-1", then the default value of 100 is used for both of these fields. If this string is set to "0" that maps to the constant CK_EFFECTIVELY_INFINITE, then the only limit that will be checked is the maximum number of total sessions that the PKCS 11 library can handle at once.
The "tokenKMIPServer" configuration parameter (string value), is the fully quallified domain name (FQDN) of the remote KMIP server. It is passed to P6R's Secure KMIP Client (SKC) library.
The "tokenKMIPort" configuration parameter (positive numeric value), is optional with the default value of 5696 defined. It is passed to the SKC library.
The "tokenKMIPMaxVersion" configuration parameter (string value), this parameter defines the maximum KMIP protocol that PKCS 11 should use to communicate with a remote KMIP server. This is an optional field with its default value of "1.2" defined. This library calls the KMIP Discover Version operation to select a protocol version to use.
The "tokenKMIPVersion" configuration parameter (string value), is optional and defines the KMIP protocol version that PKCS 11 should use to start communicatation with a remote KMIP server. This has a default value of "1.2".
The "tokenKMIPsslOptions" configuration parameter (bit mask), is optional and maps to the SKC setSSLOptions( const P6WCHAR* pCiphers, P6SECURESOCKETFLAGS fSecureFlags ) API call's fSecureFlags parameter (see file p6kmpclient.h). This allows the caller to customize how it makes an TLS connection to a remote KMIP server. The default setting for this parameter is (P6SSF_METHOD_NEGOTIATE | P6SSF_SECURE_CLIENT | P6SSF_SECURE_CLIENT_AUTH | P6SSF_LOG_X509SUBJECTLOOKUPS) (see file p6net.h).
The "tokenKMIPInitFlags" configuration parameter (bit mask), is optional and maps to the SKC initialize( P6KMIPFLAGS flags, p6IKeystore* pCerts, P6KMIP_PREF preferences ) API calls's flags parameter (see file p6kmipclient.h. This has the default value of P6KMIPFLG_NOFLAGS. Note, that this parameter is how the user can control KMIP message logging (e.g., using the P6KMIPFLG_TRACE_MSGS flag value). See SKC documentation on the possible values for this parameter.
The "tokenKMIPUseFlags" configuration parameter (bit mask), is optional and controls how PKCS 11 uses KMIP in order to work around KMIP server bugs and other issues. The current set of valid flags are: { 1 for "Transparent Key Format bug" work around }.
The "tokenKMIPCertPEM" configuration parameter (string value), is the full path to a client side certificate (in PEM format) that was issued by a KMIP server to allow a KMIP client to authenticate itself. This certificate is copied into the PKCS 11 wide keystore for use by SKC to create a TLS connection to a KMIP server.
The "tokenKMIPPrivPEM" configuration parameter (string value), is the full path to the client's private key (in PEM format) that was issued by a KMIP server to allow a KMIP client to authenticate itself. This key is copied into the PKCS 11 wide keystore for use by SKC to create a TLS connection to a KMIP server.
The "tokenKMIPPrivSize" configuration parameter (positive numeric value), is the number of bits of the private key defined by the tokenKMIPPrivPEM configuration parameter.
The "tokenKMIPRootPEM" configuration parameter (string value), is the full path to the KMIP server's root certificate that was provided by a KMIP server to allow the Secure KMIP Client to create a TLS connection to the remote KMIP server.
The "tokenKMIPconnectTimeout", "tokenKMIPsendTimeout", "tokenKMIPreceiveTimeout", "tokenKMIPMaxBufSize", "tokenKMIPInitialBufCount", "tokenKMIPGrowBufsBy", "tokenKMIPPrvKeyEncode", "tokenKMIPPubKeyEncode", "tokenKMIPSymKeyEncode", and "tokenKMIPcompatibility1" configuration parameters (positive numeric values), are all optional and maps to the SKC initialize( P6KMIPFLAGS flags, p6IKeystore* pCerts, P6KMIP_PREF preferences ) API calls's P6KMIP_PREF parameter (see file p6kmipclient.h and SKC documentation). PKCS 11 library has a reasonable set of default values for each parameter.
The "tokenKMIPUserName" and "tokenKMIPPassword" configuration parameters (string values), are optional and map to KMIP user credentials (see SKC documentation p6kmipclient.h P6KMIP_CREDENTIAL definition).
The "tokenKMIPPassword", "tokenKMIPSerialNum", "tokenKMIPDeviceId", "tokenKMIPNetworkId", "tokenKMIPMachineId", and "tokenKMIPMediaId" configuration parameters (string values), are optional and map to KMIP device credentials (see SKC documentation p6kmipclient.h P6KMIP_CREDENTIAL definition).
The "tokenDisabledMechs" configuration parameter (list of positive integers base 10) contains a set of PKCS 11 mechanism identifier constants (e.g., 4160 for the constant CKM_EC_KEY_PAIR_GEN, and 272 CKM_RC4_KEY_GEN [see pkcs11t.h]) which are to be disabled for the token. Here disabled means that the mechanisms will not be provided in the output of the C_GetMechanismList() and C_GetMechanismInfo() calls. This configuration item is optional.