Was formerly part of HPE

Was formerly part of HPE

P6R participated in the OASIS KMIP and PKCS#11 interoperability demonstration at the 2016 RSA conference.
P6R was showcasing the latest release of its SKC product, which contains a full featured KMIP Client with UEFI support, and PKCS#11.

Here is a picture of the P6R station in the OASIS booth at the 2016 RSA Conference:

As part of this demonstration P6R participated in an OASIS run interoperation test with other vendors in the KMIP Technical Committee. The results of these tests is shown in the chart below (see P6R Inc SKC in graph).

P6R also released and demonstrated its extensible PKCS#11 library at the Conference:

P6R participated in the OASIS KMIP and PKCS #11 interoperability demonstration at the 2015 RSA conference.
P6R was showcasing the latest release of its SKC product, which contains a full featured KMIP Client with UEFI support, and PKCS11.

Here is a picture of the P6R station in the OASIS booth at the 2015 RSA Conference:

As part of this demonstration P6R participated in an OASIS run interoperation test with other vendors in the KMIP Technical Committee. The results of these tests is shown in the charts below.

Introduction

P6R has implemented a PKCS 11 Baseline Consumer as part of a SSH server’s Public Key Authentication protocol (i.e., RFC 4252). This implementation provides centralized Public Key management for SSH installations via the use of KMIP. With our PKCS 11 Consumer, the SSH server looks up a user’s Public Key on a remote KMIP server rather than some file system directory. This scheme makes adding or removing a user’s SSH login authentication as easy as creating or removing a set of keys from a KMIP server. This PKCS 11 Consumer is both a PKCS 11 and KMIP client.
(See PKCS11 Cryptographic Token Interface Profiles Version 2.40, 16-Sep-2014, OASIS Committee Specification 01, for the definition of a PKCS 11, Version 2.40, Baseline Consumer).

A PKCS 11 Consumer

This initial Consumer implementation was done as part of the
P6R’s SSH Server, but in the future it will be ported to other SSH servers. P6R’s SSH server includes support for the following authentication protocols: “The Secure Shell (SSH) Authentication Protocol”, RFC 4252, “Secure Shell Public Key Subsystem, RFC 4819, and “P6R’s Secure Shell Public Key Subsystem, RFC 7076. All three of these protocols have been implemented using PKCS 11 and comprise parts of the overall PKCS 11 Consumer client.

In the above figure, the Consumer is composed of all the blue boxes. The SecureCRT SSH client implements RFC 4252 & 4819, thus allowing a user to upload Public Keys into the SSH server for use in the Public Key Authentication protocol. SecureCRT also allows the user to list all uploaded Public Keys and to delete any from his account. Our server based implementation of RFC 4819 allows all keys to be stored on a KMIP server. After a user uploads a Public Key (initially logged in via a password) he can then switch his client to use Public Key Authentication instead of passwords. On his next login, the RFC 4252 plugin will find his matching Public Key on a KMIP server and he will be logged on.

The RFC 7076 plugin allows a user to upload Certificates as well as Public Keys. It supports the concept of namespaces which map directly to KMIP groups. P6R provides a SSH client that implements this protocol.

Why use PKCS 11?

P6R’s PKCS 11 Consumer is built using the P6R’s PKCS 11 provider. Currently this provider supports two token types: a KMIP server, and the P6R Software token with Keystore. The PKCS 11 API allows our SSH implementation to use either of these tokens with no code change. The token type in use is defined by a configuration file. Thus a customer using our PKCS 11 Consumer can easily choose to store their SSH Public Keys on a KMIP server, or a local Keystore using a remote Postgres database (see figure above), or a local Keystore using a local Sqlite database. In the future, when additional token types are supported more options for key storage become available again with no SSH server code changes.

Why use KMIP?

KMIP provides a standard way to manage all types of keys, certificates, and various opaque objects. It is supported by a growing list of vendors thus allowing choice and mobility from one vendor to another.
An introduction to its benefits appears in the following article: The rising danger to data is making KMIP important.

This document was updated on 21 March 2025.

[1] Introduction

P6R has implemented the PKCS 11 Versions 2.40, 3.0, 3.1, and parts of the draft 3.2 specification. Our library meets the requirements for conformance profiles of an Extended Provider and Authentication Token (see PKCS11 Cryptographic Token Interface Profiles Version 3.0, 15-June-2020, OASIS Standard). Currently, our library supports eleven types of tokens: a KMIP server, a Software token, a Thales Luna HSM (SafeNet/Gemalto), a Utimaco CryptoServer HSM, a Entrust nShield Connect HSM (formerly nCipher), a FutureX HSM, a DocuSign HSM, a Utimaco Atalla AT1000 HSM, a YubiHSM 2.0, a AWS CloudHSM, and the Marvell LiquidSecurity HSM. Our library also allows a customer to provide their own token types via a plugin interface. One of the benefits of the PKCS 11 API is that it provides a standard based Keystore API.

Supporting these different types of tokens in one PKCS 11 library facilitates some interesting applications. For example, an application could store millions of keys in a KMIP server (along with extensive meta data) yet use an HSM to perform all encryption operations. In fact, the keys stored in the KMIP server could all be wrapped and only unwrapped once moved into an HSM. This can be done from a single PKCS 11 API instance. Another example is to use a KMIP server instead of an existing HSM vendor for Oracle TDE integration.

P6R’s PKCS 11 library is contained in both P6R’s Secure KMIP Client (SKC) and P11 products.

[2] The KMIP Token

The KMIP token uses the facilities of a remote KMIP server to implement the features of the PKCS 11 Version 2.40 API. This token type uses P6R’s Secure KMIP Client (SKC) SDK to communicate with a configured KMIP server. As of this writing, SKC works with all known commercially available KMIP servers. Our PKCS 11 library allows the definition of any number of KMIP tokens all pointing to the same or different KMIP servers.

An important benefit of this token is that it allows developers familiar with PKCS 11 to store their keys on a KMIP server without having to learn about the KMIP protocol or KMIP SDKs. All that is required is that this token be properly configured to make a valid TLS connection to a remote KMIP server, which is a process an installer program can help with.

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 attributes 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.

The KMIP token currently implements the following PKCS 11 API 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_CopyObject, 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_SignUpdate, C_SignFinal, C_VerifyInit, C_Verify, C_VerifyUpdate, C_VerifyFinal, 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_DeriveKey, C_WrapKey, C_UnwrapKey (if the KMIP server supports unwrapping), C_GetInterfaceList, C_GetInterface, C_LoginUser, C_SessionCancel, C_MessageEncryptInit, C_MessageEncryptFinal, C_EncryptMessage, C_EncryptMessageBegin, C_EncryptMessageNext, C_MessageDecryptInit, C_MessageDecryptFinal, C_DecryptMessage, C_DecryptMessageBegin, C_DecryptMessageNext, C_MessageSignInit, C_MessageSignFinal, C_SignMessage, C_SignMessageBegin,C_SignMessageNext, C_MessageVerifyInit, C_MessageVerifyFinal, C_VerifyMessage, C_VerifyMessageBegin, and C_VerifyMessageNext.

The KMIP token currently implements the following PKCS 11 Version 3.2 API functions:
C_EncapsulateKey, C_DecapsulateKey, C_VerifySignatureInit, C_VerifySignature, C_VerifySignatureUpdate, and C_VerifySignatureFinal.

This token supports the following PKCS 11 objects: CKO_DATA, CKO_CERTIFICATE, CKO_PUBLIC_KEY, CKO_PRIVATE_KEY, CKO_SECRET_KEY, CKO_DOMAIN_PARAMETERS and CKO_PROFILE.

This token supports the PKCS 11 CKA_UNIQUE_ID attribute in versions 2.40, 3.0, and 3.1. This attribute provides a token assigned unique identifier for any object residing on a token.

Post-Quantum Cryptograph (PQC) support

This token currently supports PQC requirements in the following way:
(a) support for the Version 3.2 function list, CK_FUNCTION_LIST_3_2_PTR_PTR;
(b) implementations of new functions C_EncapsulateKey() and C_DecapsulatedKey();
(c) extensions to functions: C_CreateObj(), C_GenerateKeyPair() and
C_GetAttributeValue() to handle PQC keys;
(d) support for the mechanisms: CKM_ML_KEM_KEY_PAIR_GEN, CKM_ML_KEM,
CKM_ML_DSA_KEY_PAIR_GEN, CKM_ML_DSA, CKM_SLH_DSA_KEY_PAIR_GEN, CKM_SLH_DSA;
(e) support for new attributes: CKA_PARAMETER_SET, CKA_ENCAPSULATE, CKA_DECAPSULATE;
(f) support for ML_KEM parameter sets: CKP_ML_KEM_512, CKP_ML_KEM_768, CKP_ML_KEM_1024;
(g) support for ML_DSA parameter sets: CKP_ML_DSA_44, CKP_ML_DSA_65, CKP_ML_DSA_87;
(h) support for SLH_DSA parameter sets: CKP_SLH_DSA_SHA2_128S, CKP_SLH_DSA_SHA2_128F,
CKP_SLH_DSA_SHA2_192S, CKP_SLH_DSA_SHA2_192F, CKP_SLH_DSA_SHA2_256S,
CKP_SLH_DSA_SHA2_256F, CKP_SLH_DSA_SHAKE_128S, CKP_SLH_DSA_SHAKE_128F,
CKP_SLH_DSA_SHAKE_192S, CKP_SLH_DSA_SHAKE_192F, CKP_SLH_DSA_SHAKE_256S,
CKP_SLH_DSA_SHAKE_256F; and
(i) support for TLS 1.3 PQC Hybrid Key Agreement.

[3] The Software Token

The Software 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/C++ object wrapper around OpenSSL’s C language API.

The Software token currently implements the following PKCS 11 API 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_CopyObject, C_DestroyObject, C_GetAttributeValue, C_SetAttributeValue, C_FindObjectsInit, C_FindObjects, C_FindObjectsFinal, C_GenerateKey (not including domain parameters), C_GenerateKeyPair, 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 and C_DigestFinal.

This token also supports the new PKCS#11 CKA_UNIQUE_ID attribute. This new attribute provides a token assigned unique identifier for any object residing on a token.

[4] The Thales Luna HSM Token (SafeNet/Gemalto)

The Thales Luna HSM can be configured to look like another token. We map one slot of a Thales Luna HSM into one slot of our P6R PKCS 11 library. To use this token requires the proper setup and configuration of a Luna HSM both on the hardware server and client machine as documented in the Thales product literature. Also the proper configuration of the P6R’s PKCS 11 library is required, which is described in detail in the SKC product documentation.

[5] Utimaco Atalla AT1000 HSM Token (formerly HPE, Micro focus)

The Atalla AT1000 HSM (formerly Network Security Processor – NSP) can be configured to look like another token. We map each NSP and Virtual NSP into a separate slot of our P6R PKCS 11 library. We have written a special token for the NSP so that we could put a PKCS 11 API around it. Basically we added parts of our Software Token to build an NSP token that allows us to store all NSP generated keys into our Keystore. In addition, all PKCS 11 attributes, none of which are natively supported by the NSP, are also maintained in our Keystore. The P6R Keystore can use either a local Sqlite database or a local or remote Postgres database. Thus using our NSP token its generated keys and PKCS 11 attributes can be managed in a client local or networked centralized database.

This token supports the following PKCS 11 mechanisms: CKM_AES_KEY_GEN, CKM_DES_KEY_GEN, CKM_DES2_KEY_GEN, CKM_DES3_KEY_GEN, CKM_SHA_1_HMAC, CKM_SHA256_HMAC, CKM_RSA_PKCS_KEY_PAIR_GEN, CKM_RSA_PKCS, CKM_SHA1_RSA_PKCS, CKM_SHA224_RSA_PKCS, CKM_SHA256_RSA_PKCS, CKM_SHA384_RSA_PKCS, CKM_SHA512_RSA_PKCS, CKM_RSA_X_509, CKM_DES_CBC, CKM_DES_CBC_PAD, CKM_DES_CFB8, CKM_DES_CFB64, CKM_DES_OFB64, CKM_DES3_CBC, CKM_AES_CBC, CKM_AES_CBC_PAD, CKM_SHA_1, CKM_SHA224, CKM_SHA256, CKM_SHA384, CKM_SHA512, CKM_MD2, CKM_MD5, and CKM_RIPEMD160. All digest calculations are done in the PKCS 11 client with the use of OpenSSL, but all other calculations are done on the NSP.

This token currently implements the following PKCS 11 API functions: C_Initialize, C_Finalize, C_GetSlotInfo, C_InitToken, C_GetTokenInfo, C_GetMechanismList, C_GetMechanismInfo, C_OpenSession, C_CloseSession, C_GetSessionInfo, C_InitPIN, C_SetPIN, C_Login, C_Logout, C_CreateObject (objects stored in the P6R Keystore), C_DestroyObject, C_GetAttributeValue, C_SetAttributeValue, C_FindObjectsInit, C_FindObjects, C_FindObjectsFinal, C_GenerateRandom (uses NSP hardware random number generator), C_SignInit, C_Sign, C_SignUpdate, C_SignFinal, C_VerifyInit, C_Verify, C_VerifyUpdate, C_VerifyFinal, C_EncryptInit, C_Encrypt, C_EncryptUpdate, C_EncryptFinal, C_DecryptInit, C_Decrypt, C_DecryptUpdate, C_DecryptFinal, C_DigestInit, C_Digest, C_DigestUpdate, C_DigestFinal, C_GenerateKey, C_GenerateKeyPair, C_WrapKey, and C_UnwrapKey.

For this and all 3rd party tokens the PKCS 11 API functions: C_GetInfo, C_GetFunctionList, C_GetSlotList, and C_CloseAllSessions are handled by the PKCS 11 provider module that dynamically loads all tokens (i.e., the green box in the picture above).

This token also supports the new PKCS#11 CKA_UNIQUE_ID attribute. This new attribute provides a token assigned unique identifier for any object residing on a token.

[6] The Utimaco HSM Token

The Utimaco CryptoServer HSM can be configured to look like another token. We map one slot of a Utimaco HSM into one slot of our P6R PKCS 11 library. This integration supports all existing Utimaco PKCS 11 vendor extensions. To use this token requires the proper setup and configuration of a network-attached HSM both on the hardware server and client machine as documented in the Utimaco product literature. Also the proper configuration of both the Utimaco and P6R’s PKCS 11 libraries is required, which is described in detail in the SKC product documentation.

[7] Entrust (formerly nCipher)

The Entrust nShield Connect HSM can be configured to look like another token. We map one slot of an Entrust HSM into one slot of our P6R PKCS 11 library. This integration supports existing Entrust PKCS 11 vendor extensions (e.g., C_LoginBegin()). To use this token requires the proper setup and configuration of a nShield network-attached HSM both on the hardware server and client machine as documented in the Entrust product literature. The last step is the proper configuration of the P6R’s PKCS 11 library, which is described in detail in the SKC product documentation along with working examples.

[8] The FutureX HSM Token

The FutureX HSM can be configured to look like another token. We map one slot of a FutureX HSM into one slot of our P6R PKCS 11 library. This integration supports most of the existing FutureX PKCS 11 vendor extensions (e.g., C_FX_GetLogFile()). To use this token requires the proper setup and configuration of a network-attached HSM both on the hardware server and client machine as documented in the FutureX product literature. The last step is the proper configuration of both the FutureX and P6R’s PKCS 11 libraries, which is described in detail in the SKC product documentation along with working examples.

[9] The DocuSign HSM Token

The DocuSign HSM can be configured to look like another token. We map one slot of a DocuSign HSM into one slot of our P6R PKCS 11 library. To use this token requires the proper setup and configuration of a network-attached HSM both on the hardware server and client machine as documented in the DocuSign product literature. The last step is the proper configuration of both the DocuSign and P6R’s PKCS 11 libraries, which is described in detail in the SKC product documentation along with working examples.

[10] YubiHSM 2.0 Token

The YubiHSM 2.0 can be configured to look like another token. We map one slot of a YubiHSM into one slot of our P6R PKCS 11 library. To use this token requires the proper setup of a YubiHSM using the software tools that come with the product. The form factor of this HSM makes for a set of interesting use cases (e.g., encrypting the keys used to protect a local P6R keystore).

[11] AWS CloudHSM

The AWS CloudHSM can be configured to look like another token. We map one slot of a CloudHSM into one slot of our P6R PKCS 11 library. To use this token requires the proper setup of a CloudHSM using the software tools that AWS provides. Additionally, the P6R’s PKCS#11 library has to run on an AWS CloudHSM EC2 client instance.
P6R’s KSG product, which uses this PKCS#11 library, is listed under AWS CloudHSM Integrations.
Both P6R’s PKCS 11 and KSG products have been tested with AWS CloudHSM PKCS#11 SDK5 library.

[12] Marvell LiquidSecurity HSM

The Marvell HSM can be configured to look like another token. We map one slot of a Marvell HSM into one slot of our P6R PKCS 11 library. To use this token requires the proper setup of a Marvell HSM using the software tools that Marvell provides. The Marvell HSM version that we tested with had slot identifiers starting at 1.

[13] Slot & Token definition

P6R’s Provider allows any number of slots to be defined and in each slot any 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 configuration file. This configuration file allows the definition of any P6R or customer specific behavior since the PKCS 11 interface allows for vendor extensions. 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.

[14] Oracle TDE Integration

P6R’s PKCS 11 Provider can be installed to work as an HSM with Oracle TDE. (See Section 8.2.6 Using Hardware Security Modules [HSM] with TDE.) Depending on how our PKCS 11 library is configured it can use anyone of the several supported token types: a KMIP Server, Utimaco HSM, Thales nShield HSM, or other market available HSM. In addition, via the supported plugin interface a customer could write their own token types and have it work with Oracle TDE (just as long as the required ciphers are supported by that token). Now a customer no longer needs a PKCS 11 library from each vendor but instead can simplify their development efforts with just one.

[15] PrimeKey’s SignServer Integration

Both the KMIP and Micro Focus Atalla HSM tokens can be configured to work with PrimeKey’s SignServer. For a KMIP token all keys can be created and stored in the KMIP server and all encryption can be performed on a KMIP server. This integration requires a KMIP server with KMIP protocol version 1.3 and greater with streaming capability supported.

[16] PDFlib Integration

The Micro Focus Atalla HSM token can be configured to work with the PDFlib PLOP DS. This integration supports document signing.

[17] Java Security Provider

We have been improving our integration with Java. At first we worked on integration with Keytool and Jarsigner, now our PKCS#11 library, with the KMIP token, can be used by plain old Java. With straightforward configuration the following examples of Java call our PKCS#11 library and our KMIP token. The result is that a Java programmer can use KMIP without having to learn anything about KMIP. No KMIP company specific APIs to learn. Its even possible that existing Java programs can be converted (with the occasional tweak) to use KMIP this way.
Code example 1:

KeyGenerator keyGen = KeyGenerator.getInstance("AES", "SunPKCS11-P6RPKCS11");
keyGen.init(128);
Key key = keyGen.generateKey();

// replace an older key
if (ks.containsAlias("symmetric_aes_128_key")) ks.deleteEntry("symmetric_aes_128_key");
ks.setKeyEntry("symmetric_aes_128_key", key, null, null);

Don’t see any KMIP calls here right? The magic is in the specification of the provider:
“SunPKCS11-P6RPKCS11″. The result is that the above code calls the KMIP server to generate the AES key. Then that key can be found later by calls to the keystore.

Code example 2:

// the "12345678" is the keystore's password (i.e., the PKCS#11 token's PIN)
KeyStore ks = KeyStore.getInstance("PKCS11", "SunPKCS11-P6RPKCS11");
ks.load(null, "12345678".toCharArray());
Key secretKey = ks.getKey("symmetric_aes_128_key", null);

The three lines above actually do a KMIP Locate call for a key with a custom KMIP attribute set to “symmetric_aes_128_key”. In Java, “symmetric_aes_128_key” is referred to as the
alias. (Actually the code above first makes PKCS#11 C_FindObjects() calls which our KMIP token maps to KMIP Locate. Still all that is done for the Java programmer and totally hidden from them.)

Code example 3:

private static byte[] encryptData(Key secretKey, byte[] iv, String handling, byte[] clearText) { 
  byte[] cipherText = null;
  try {
      // with a security provider do the encrypt on the remote server
      Cipher encryptCipher = Cipher.getInstance(handling, "SunPKCS11-P6RPKCS11");
      IvParameterSpec IV = new IvParameterSpec(iv);
      encryptCipher.init(Cipher.ENCRYPT_MODE, secretKey, IV);
      cipherText = encryptCipher.doFinal(clearText);
   } catch (Exception e) {
       e.printStackTrace();
   }
   return cipherText;
}

Again see any KMIP calls here? The parameter “secretKey” was created in example 1 above. This code example shows that the encryption will be done on the KMIP server. We have also tested streaming encryption (requiring KMIP 1.3), with the call sequence encryptCipher.init(), encryptCipher.update() multiple calls of updates, and then encryptCipher.doFinal(), allowing encryption (and decryption) of large chunks of data. We have also done testing with public/private keys.

[18] Other Applications

Customers have integrated our PKCS 11 library using the KMIP token with the following: Hashicorp Vault (https://www.vaultproject.io/docs/vs/hsm.html, https://www.vaultproject.io/docs/configuration/seal/pkcs11.html) and OpenSC.

We have integrated our PKCS 11 library with our SSH server product that is described in the article: Integrating KMIP, PKCS 11, and SSH. While that article focuses on the KMIP token our SSH server implementation can use any of the tokens types defined above and any we add in the future.

P6R’s PKCS 11 library also ships with a command line tool. This executable is a PKCS 11 application in that it dynamically loads our library and calls C_GetFunctionList in order to obtain the API function pointers. A user can use this command line tool to initialize a token, set the SO or User’s PIN, list all configured slots, list information on a token, generate keys, import and export some certificates and keys, and list the contents of a token. We have been using this command line tool to manage our KMIP, Software, and HPE NSP tokens.

[19] Vendor Extensions

P6R defines the following vendor defined attribute:

CKA_P6R_GROUP 0x80001000UL
Data Type: RFC 2279 string                                       
MUST be specified when object is created with C_CreateObject.
MUST be specified when object is created with C_GenerateKey or C_GenerateKeyPair.

The purpose of this extension is to provide basic support for KMIP groups. CKA_P6R_GROUP maps into the KMIP “Object Group” attribute. Without the CKA_P6R_GROUP attribute defined the “default” KMIP 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.

[20] References

1. PKCS 11 OASIS standard
2. KMIP OASIS standard
3. P6R’s Secure KMIP Client SDK
4. Key Management with a Powerful Keystore
5. Hybrid key exchange in TLS 1.3

Introduction

This is the first part of a multi-part series on the challenges and techniques for creating Binary Compatible C++ Interfaces (BCCI). In researching this topic, I often found the issues enumerated without (or with very little) explanation as to why something should be avoided. As a result I have tried to include the “why” along with the “what” in this series of posts.

This first post will go through the causes of incompatibilities and the reasons why. The second post will summarize these into a set of rules, and discuss various ways to prevent or work around the incompatibilities. The third installment will cover implementing binary compatible C++ interfaces using some of the techniques discussed.

One of C++’s greatest short comings (at least with regards to interoperability) is the lack of an Application Binary Interface (ABI) as part of the standard. C++ is a language specification after all, and many would argue that is out of the scope of the standard to define specific implementations. The result is that binaries produced with one compiler, are not necessarily compatible with those produced by another compiler (or even by different versions of the same compiler!). This simple fact greatly hampers our ability as developers to easily create C++ libraries for distribution to a broad audience. This leaves developers with only two distribution options: (1) provide source for their libraries, or (2) provide multiple binaries, one for each version of each compiler that a customer might use. The matrix for that can get out of hand quickly.

A solution to this is to attempt to export all public APIs using a mechanism that creates a stable and cross-compiler compatible binary interface. Doing this does come with compromises, however you will have to decide if they are worth it or not for your specific situation. Continue Reading »

Introduction

Reference counting generally comes in two basic flavors: intrusive and non-intrusive. Non-intrusive reference counting basically means that the location of the variable which stores the reference value is outside of the “thing” being reference counted. COM interfaces make use of intrusive reference counting, meaning the underlying object maintains the reference count value itself internally. The purpose of having a reference count on a COM interface is to ensure that the lifetime of the underlying object includes the lifetimes of all the references to it.  P6COM follows the standard COM reference counting model, so if you are already familiar with COM reference counting, this should all be review. There are also many good references elsewhere on this topic (including section 3.3.2 of the official COM reference), this post is meant as a quick guide to COM reference counting rules, not an exhaustive treatise.

A Word On Smart Pointers

Most implementations of COM include smartptr’s to manage reference counting, and p6COM is no different in this regard. I strongly encourage you to use p6ComPtr<> to manage your interface pointers (or whichever smartptr your COM implementation provides). COM smart pointers reduce/remove interface leaks and reduce the amount of code that you need to write. They have huge benefits, please use them. See A Smart Pointer for p6COM for a small tutorial. That being said, you should still have a clear understanding of the rules involved.

The Rules

To be successful, it’s very important to understand exactly when to call addref() and release().  The following rules define a policy which must be consistently applied:

Rule 1 – Always call addref() on a new copy of an interface pointer and release() when it is no longer needed, except as the following rules specifiy.

In general, whenever you create or make a copy of an interface pointer you must call addref() on the pointer before you use it, and release() on the pointer when you no longer need it.

Rule 2 – Always addref() before returning an interface pointer to the caller.

You must ensure that when returning an interface pointer (directly or through an out parameter) it has a an additional reference count applied before returning. If the callee synthesizes the pointer, it must call addref():

P6ERR CSomeClass::createInstance(ISomeIface **ppIface)
{
   CSomeClass  *pSomeClass = NULL;

   if(!ppIface) return eInvalidArg;

   pSomeClass = new CSomeClass;
   (*ppIface) = static_cast<ISomeIface*>(pSomeClass);
   (*ppIface)->addref();      // addref() before returning

   return err;
}

If the callee makes a copy of an internal interface pointer, then addref() must be called.

P6ERR CSomeClass::createInstance(ISomeIface **ppIface)
{
   if(!ppIface) return eInvalidArg;

   (*ppIface) = m_pSomeIface; // An interface pointer stored internally in our object
   (*ppIface)->addref();      // addref() before returning
   return eOk;
}

It important to note that it is the callers (the one receiving the new interface pointer) responsibility to release() the interface when it is done using it. This is the thing that smart pointers are great at managing for you. No matter how diligent you try to be you will forget to do this at some point causing an interface leak. Smart pointers can ensure that this never happens.

Rule 2a – Exception: callee uses another method to create the interface pointer.

If the callee called another method which created the pointer, then it will have called addref() and no additional reference is needed.

P6ERR CSomeClass::createInstance(ISomeIface **ppIface)
{
   return someFactory(ppIface); // someFactory() will addref() before returning. 
                                // We just pass it up to the caller. Calling addref()
                                // again here would cause an interface leak.
}

As you can see it does not matter where the interface pointer came from, if you return it directly or through and out parameter, addref() must be called first.

Rule 3 – Call addref() when making a local copy of an interface pointer stored in a global variable.

A much better solution to this is not to use global variables. In a single threaded environment, called methods could release the global thereby invalidating the interface pointer in the local copy. You must call addref() before making any other calls. In a multi-threaded environment (assuming the interface itself if thread-safe), you must obtain the local copy and call addref() under a lock to ensure that it remains valid long enough to grab the reference. Once addref() has been called, the lock may be released and the interface used. You must call release on the local copy when you are done.

Rule 4 – addref() and release() need not be called on in parameters

The callee knows that by definition the interface pointer passed to it as an “in” parameter has a greater lifetime than itself. Therefore, the callee should not call addref() or release() on any “in” parameter.

P6ERR CSomeClass::someMethod(ISomeIface *pIface)
{
   // no addref()
   pIface->someOtherMethod();
   // No release()
   return eOk;
}

Rule 4a – Exception: callee stores interface pointer for later use.

An exception to this is if the callee makes a copy if the interface pointer for use at a later time (storing the copy internally or globally), addref() must called on the copy (and release once it is no longer needed).

P6ERR CSomeClass::someMethod(ISomeIface *pIface)
{
   m_pSomeIface = pIface;   // Save interface pointer for later use
   m_pSomeIface->addref();  // Make sure it sticks around till we need it
                            // We are now responsible for calling release()
                            // on m_pSomeIface when it is no longer needed.

   pIface->someOtherMethod();
   return eOk;
}

Rule 5 – addref() in-out parameters on the way in and out

This is somewhat of a special case and I urge you to not use in-out parameters of any type because they complicate things which leads to defects. When an interface pointer is passed via an “in-out” parameter, the caller must addref() the interface pointer on the way in (if it expects it to still be valid after the call) because the callee will need to release() it before storing the out-value on top of it. The callee then treats the out parameter as in Rule 2 above. It’s important to understand that the callee must always release() the incoming interface pointer, even if it is not overwritten with a new/different interface.

P6ERR CSomeClass::amethod(ISomeIface **ppInOutIface)
{   
   CSomeClass *pClass = NULL;

   (*ppInOutIface)->someMethod();  // Make use of the incoming interface
   (*ppInOutIface)->release();     // Release the incoming interface 
   (*ppInOutIface) = NULL;         // Good form to prevent anything from dangling

   if(NULL != (pClass = new CSomeClass)) {
      (*ppInOutIface) = static_cast<ISomeIface*>(pClass);
      (*ppInOutIface)->addref();
   }
   return eOk;
}

Here’s another example which calls another factory class to create the outbound interface and so does not have to addref() the interface pointer before returning.

P6ERR CSomeClass::aMethod(ISomeIface **ppInOutIface)
{
   (*ppInOutIface)->someMethod();  // Make use of the incoming interface
   (*ppInOutIface)->release();     // Release the incoming interface 
   (*ppInOutIface) = NULL;         // Good form to prevent anything from dangling

   // CSomeClass::createInstance() is a theoretical factory method 
   // which creates and returns an instance of ISomeIface. Following
   // Rule 2 it calls addref() on the interface pointer before 
   // returning it. Therefore we don't need to here and we pass it
   / back to the caller.
   return CSomeClass::createInstance(ppInOutIface); 
}

This should cover the majority of situations that you come across and the official documentation (and the plethora of books on COM) should handle the rest.

This document was updated on 27 April 2015.

We believe that standards are important and whenever possible we build our products to them. Below is a list of the standards that we have incorporated into P6R products.

ASN.1

• 1. ITU-T RecommendationX.690, “Information technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)”, 07/2002

JSON

• 1. The JSON Data Interchange Format
• 2. www.json.org
• 3. JsonML

Key packaging & storage

• 1. NIST Special Publication 800-130: A Framework for Designing Cryptographic Key Management Systems
• 2. PKCS #12, PKCS #8, PKCS #1

KMIP

• 1. KMIP Standard supported by P6R’s SKC Client

PKCS 11

• 1. PKCS #11 Cryptographic Token Interface Base Specification Version 2.40, 14-April-2015, OASIS Standard
• 2. PKCS #11 Cryptographic Token Interface Profiles Version 2.40, 14-April-2015, OASIS Standard
• 3. PKCS #11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40, 14-April-2015, OASIS Standard
• 4. PKCS #11 Cryptographic Token Interface Historical Mechanisms Specification Version 2.40, 14-April-2015, OASIS Standard

LDAP

• 1. RFC 1777 – Lightweight Directory Access Protocol
• 2. RFC 2251 – Lightweight Directory Access Protocol (v3)
• 3. RFC 2253 – Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
• 4. RFC 3377 – Lightweight Directory Access Protocol (v3): Technical Specification
• 5. RFC 4515 – Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters

Regular Expressions

• 1. J.Fridel, Mastering Regular Expressions, 2nd edition, O’Reilly, 2002, ISBN 0-596-00289-0>
• 2. Wall et al, “Programming Perl”. O’Reilly, 2000, 3rd Edition, ISBN 0-596-00027-8
• 3. ECMA-262, ECMAScript Language Specificiation, 5.1 Edition, June 2011
• 4. BRIEF, DOS-OS/2 User’s Guide, “The Programmer’s Editor”, 1991, SDC Software Patners II, L.P., Section Regular Expression Characters, pp.103 – 112
• 5. Microsoft BRIEF reference

SNMP

• 1. RFC 1157 – A Simple Network Management Protocol (SNMP)
• 2. RFC 1905 – Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)

SSH Server & Client

• 1. RFC 3526 – More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
• 2. RFC 4251 – The Secure Shell (SSH) Protocol Architecture
• 3. RFC 4252 – The Secure Shell (SSH) Authentication Protocol
• 4. RFC 4253 – The Secure Shell (SSH) Transport Layer Protocol
• 5. RFC 4254 – The Secure Shell (SSH) Connection Protocol
• 6. RFC 4256 – Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
• 7. RFC 4419 – Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
• 8. RFC 4819 – Secure Shell Public Key Subsystem
• 9. RFC 6668 – SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol
• 10. RFC 7076 – P6R’s Secure Shell Public Key Subsystem

XML

• 1. Extensible Markup Language (XML) 1.0 (Fourth Edition), W3C Recommendation 16 August 2006
• 2. XML Path Language (XPath) 2.0 (Second Edition), W3C Recommendation 21 April 2009
• 3. XSL Transformations (XSLT) Version 2.0, W3C Recommendation 23 January 2007
• 4. ISO 8601 – Data elements and interchange formats — Information interchange — Representation of dates and times
• 5. D.Browneww, SAX2, O’Reilly, 2002, ISBN 0-596-00237-8
• 6. Saxon Extensions

Miscellaneous

• 1. RFC 4648 – The Base16, Base32, and Base64 Data Encodings
• 2. Uuencoding
• 3. CRC32, CRC16 – A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS, 19 August 1993