Home » Articles

P6R’s KMIP Client Product Suite

By Mark Joseph - August 8, 2016 @ 10:09 pm

P6R KMIP software can support a wide range of customer requirements with various programming language and integration support.

Supported Programming Languages


1. C/C++ — Secure KMIP Client (SKC) SDK
2. Java Security Provider
3. Java Native Interface (JNI)p6javakmip is a wrapper around the SKC library
4. python extension modulep6pythonkmip is a wrapper around the SKC library with a similar API as defined by p6javakmip

Supported Integrations


1. PKCS#11 KMIP Token
2. Oracle Transparent Data Encryption (TDE) support via P6R’s PKCS#11 KMIP Token
In this integration the Oracle database thinks it is connected to a Hardware Security Module (HSM) but it actually is using a KMIP server.
3. KMIP used in a SSH server
4. KMIP Command Line Tool allows customers to script their access to a KMIP server

Supported Platforms


1. Linux x86 Kernel 2.6+ (32bit/64bit)
2. Windows 7/8+ (32bit/64bit), Windows Server 2008R2+ (32bit/64bit)
3. Unified Extensible Firmware Interface (UEFI) 64bit Tianocore Native PE Format
4. Intel and ARM processors

Supported KMIP Protocol Versions


Complete implementations of: 1.0, 1.1, 1.2, 1.3, (1.4 draft specification in development)

Supported KMIP Servers


1. Cryptsoft KMIP C Server SDK
2. Cryptsoft KMIP Java Server SDK
3. Dell KMIP Server
4. Fornetix Key Orchestration Server
5. HPE ESKM Server
6. IBM SKLM Server
7. QuintessenceLabs qCrypt Server
8. SafeNet KeySecure Server
9. Thales KeyAuthority KMIP Server
10. Townsend Security Alliance Key Manager
11. Utimaco KeyServer
12. Vormetric KMIP Server

Need a Command Line KMIP Client?

By Mark Joseph - June 4, 2016 @ 9:47 am

What was the need?

P6R sells a KMIP client SDK and a Transparent Data Encryption (TDE) Connector. The TDE connector uses PKCS#11 with a KMIP token so that an Oracle database can use a KMIP server to manage its keys. In supporting these products we have seen the need for a full featured, scriptable, KMIP command line tool that can be used with any KMIP Server.

There are similar questions that occur during KMIP application development, deployment, and support some of which include: What KMIP protocol version does the server support?; What KMIP features does the server support (e.g., streaming encryption)?; Is the TLS connection to a server working?; Did we create the key we attempted to create, what is its state, what are the attributes associated with it? Logging into the KMIP server’s Web front end won’t answer all of these questions and each server’s UI is different. Most KMIP application developers we talk to want their applications to work with all KMIP servers, and would prefer the tools they use to also work with all KMIP servers rather then one per server vendor.

We have gotten customer requests for such a tool and in response we have built a full featured, scriptable command line tool that was implemented with our own KMIP client SDK. Since we have tested our SDK with just about every KMIP server commercially available our KMIP command line tool should work with every KMIP server. Our KMIP client SDK product page documents all the servers we have test with: SKC Secure KMIP Client

Our Solution

It is important to note that KMIP supports more than just keys. It also supports a collection of objects which include: Certificates, Opaque objects, and Secret data such as passwords. So instead of just talking about keys we will try to use the generic term Managed Object wherever possible.

From our experience we have added the most commonly used and useful KMIP features to our command line tool. Basically each command performs one KMIP operation which includes: creating objects, exporting/importing objects, adding/modifying/deleting/listing attributes associated with objects, deleting objects, activate/revoking a key, re-keying keys, encrypt/decrypt files, obtain server generated random numbers, query server features, and searching for objects based on various filters (e.g., object type, attribute values associated with a Managed object). The search command is an very useful one. For example, we can assign a set of Managed Objects with the same KMIP custom attributes such as
“x-group-name = customerZ”. Then we can do a search (actual a KMIP Locate operation) for all Managed Objects with the associated attribute “x-group-name = customerZ”. The result of that search will be all the objects we stamped with the “x-group-name = customerZ” attribute value.

Another nice feature is that our command line tool can be configured to work with one or more KMIP servers at the same time. Each command requires the user to provide either the IP address or fully qualified domain name of a KMIP server as part of the command (e.g., “p6kmiptool -list -server kmiptest01.p6r.com ….”). Here are some simple examples of using our command line tool.


.......>p6kmiptool -config

----- Server List  -----
1> Server: [192.168.72.1]
2> Server: [kmiptest01.p6r.com]

Config found 2 items.


....>p6kmiptool -list -server kmiptest01.p6r.com -type symmetrickey

----- Object List  -----
1> Type: Symmetric Key, Unique Id: [4c5db22f-3747-4d19-9593-7fa1b83816aa]
2> Type: Symmetric Key, Unique Id: [a6efe3ed-08c5-418b-b76a-c15e1652a5ac], Alias: [frank]
3> Type: Symmetric Key, Unique Id: [80116b3e-156e-4079-abd8-34ff337fffad]
4> Type: Symmetric Key, Unique Id: [96a97e73-3e6a-4b95-8c93-65c1bd2966c9], Alias: [henry11]

List found 4 managed objects.


.....>p6kmiptool -attributes -server kmiptest01.p6r.com -uid a6efe3ed-08c5-418b-b76a-c15e1652a5ac

List of attributes associated with object [a6efe3ed-08c5-418b-b76a-c15e1652a5ac].

x-P6R-CMD-LABEL = frank, index 0
x-P6R-CMD-SKCCLIENT = true, index 0
Object Type = Symmetric Key (2), index 0
Cryptographic Algorithm = AES (3), index 0
Cryptographic Length = 256, index 0
Alternative Name = frank, index 0
Cryptographic Usage Mask = Encrypt, Decrypt, index 0

Digest hash algorithm = SHA256 (6), index 0
Digest value: b251c1ad58587d294421696063aad76f655f7c47055f83bc53dcc5a1de3c

Fresh = true, index 0
Initial Date = 2016-05-16T03:32:55Z, index 0
Last Change Date = 2016-05-16T03:32:55Z, index 0
Lease Time = 3600, index 0
Original Creation Date = 2016-05-16T03:32:55Z, index 0
State = Pre-Active (1), index 0

List of object attributes succeeded (error: eOk).


The current shipping version of our KMIP command line tool can be used to script access to a KMIP server and it runs on Linux and Windows. P6R’s KMIP command line tool comes standard with our SKC KMIP client SDK and is also available as a standalone product.

Using KMIP via a Java Security Provider

By Mark Joseph - May 9, 2016 @ 5:23 pm

This document was updated on 12 May 2016.

Introduction

P6R sells a PKCS 11 Version 2.40 Provider with a KMIP token. The KMIP token translates each PKCS 11 API function into and out of the KMIP protocol. The user of the PKCS 11 KMIP token does not even know they are talking to a KMIP server. Java supports PKCS 11 as a possible security provider via the SunPKCS11 wrapper. Also JCE provider products also directly support PKCS 11 wrappers (e.g., IAIK).

The significant benefit of using KMIP via a Java security provider is that a Java programmer can use KMIP without having to learn anything about KMIP. No company specific KMIP APIs to learn. Its even possible that existing Java programs can be converted (with the occasional tweak) to use KMIP this way. All that is required to make this work is some straightforward configuration.

Testing Environment

We have tested out our PKCS 11 library as a Java security provider both on Centos 6 and Windows using the following:

To build our Java examples we used: 
jdk1.8.0_65, language level 8.0, IntelliJ IDEA 2016.1.1
JVM: Java HotSpot(TM) 64-Bit Server VM by Oracle Corporation

Systems tested on:
[1] Windows 7 Ultimate, 64 bit
C:\....>java -version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
64 bit p6pkcs11.dll library 

[2] Centos6 Linux
[...... ~]$ cat /etc/redhat-release
CentOS release 6.7 (Final)
[....... ~]$ java -version
openjdk version "1.8.0_77"
OpenJDK Runtime Environment (build 1.8.0_77-b03)
OpenJDK 64-Bit Server VM (build 25.77-b03, mixed mode)
64 bit libp6pkcs11.so

Java Examples

Below are just a few code snippets that we have taken out of several of our Java test programs.

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.

Code example 4:

SecureRandom sr = SecureRandom.getInstance("PKCS11", "SunPKCS11-P6RPKCS11");
sr.setSeed("778373644".getBytes());

byte[] randomBytes = new byte[128];
sr.nextBytes(randomBytes);

Code example 4 shows how to use the random number generator on the KMIP server. The Java statement “sr.setSeed()” maps to the KMIP operation RNGSeed, and the statement “sr.nextBytes()” maps to the KMIP operation RNGRetrieve. Of course this mapping is done by the P6R PKCS#11 library. The trick in the above example is to make sure that the first parameter in the getInstance() call is “PKCS11″ and not the “SHA1PRNG” that appears in may Java examples of SecureRandom.

KMIP Server Capabilities

Well the above is all fine and good but how do I know what my KMIP server is capable of? Does my KMIP server support encryption, streaming encryption, what protocol version does it support? These are all basic questions and we provide the answer via our KMIP command line tool. Our command line tool, p6kmiptool, runs on Linux and Windows and provides scriptable access to many KMIP operations (e.g., one being KMIP Query).

>p6kmiptool -serverinfo -server {fully qualified host name}

KMIP server information:
server address: {fully qualified host name}:5696
using protocol version: 1.3

-------------------------
supported object: Certificate
supported object: SymmetricKey
supported object: SecretData
supported object: PublicKey
supported object: PrivateKey
supported object: Template
supported object: OpaqueObject
supported object: SplitKey
supported object: PGPKey

-------------------------
supported operation: Query
supported operation: Locate
supported operation: Destroy
supported operation: Get
supported operation: Create
supported operation: Register
supported operation: GetAttributes
supported operation: GetAttributeList
supported operation: AddAttribute
supported operation: ModifyAttribute
supported operation: DeleteAttribute
supported operation: Activate
supported operation: Revoke
supported operation: Poll
supported operation: Cancel
supported operation: Check
supported operation: GetUsageAllocation
supported operation: CreateKeyPair
supported operation: ReKey
supported operation: Archive
supported operation: Recover
supported operation: ObtainLease
supported operation: ReKeyKeyPair
supported operation: Certify
supported operation: ReCertify
supported operation: DiscoverVersions
supported operation: Notify
supported operation: Put
supported operation: RNGRetrieve
supported operation: RNGSeed
supported operation: Encrypt
supported operations: Decrypt
supported operations: Sign
supported operation: SignatureVerify
supported operation: MAC
supported operation: MACVerify
supported operation: Hash
supported operation: CreateSplitKey
supported operation: JoinSplitKey

-------------------------
vendor: {company name} KMIP Server {version}

-------------------------
capability: streaming is supported
capability: asynchronous command processing is supported
capability: attestation is supported
capability: unwrap mode is not processed
capability: destroy action is key material deleted
capability: shredding algorithm is unsupported
capability: RNG mode is unspecified


Given the information above, we can conclude that the above server can handle all the functions of our Java Security provider (e.g., streaming encryption: C_EncryptInit(), C_EncryptUpdate() … multiple calls, and finally C_EncryptFinal().

Our PKCS 11 library also comes with an equally powerful command line tool of its own that lets the user see what is stored on a token (also runs on Linux and Windows).

>p6pkcs11tool -list 0 -p 12345678


----- Object List  (slotId: 0) -----
1> Type: Certificate, Alias: [rsa_private_key] ID: [rsa_private_key],   Token
2> Type: Secret Key , Alias: [symmetric_aes_128_key] ID: [], AES  Token
3> Type: Private Key, Alias: [C6AC22B2-5330-48CE-A950-47CA883C03F6] ID: [rsa_private_key], RSA  Token


The above syntax is p6pkcs11tool {operation} {slotid} -p {User PIN}.

The PKCS 11 command line tool is also feature rich including functions to clean up after applications that do not call C_CloseSession(), create keys, delete keys, import and export keys and certificates, etc.

P6R KMIP Client Integration With Thales keyAuthority

By Mark Joseph - March 26, 2016 @ 10:59 am


P6R KMIP Client Integration with HPE ESKM

By Mark Joseph - @ 10:45 am


PKCS#11 Library Integartion with HPE Atalla HSM

By Mark Joseph - March 22, 2016 @ 10:02 am


P6R demonstrates KMIP and PKCS#11 Products at RSA 2016

By Mark Joseph - March 4, 2016 @ 9:17 am

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:
014

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:
p11integration

P6R demonstrates KMIP Client SDK’s Standards Conformance at RSA 2015

By Mark Joseph - April 24, 2015 @ 5:08 pm

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:

014

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.

Integrating KMIP, PKCS 11, and SSH

By Mark Joseph - January 2, 2015 @ 10:06 pm

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.

PKCS 11 Consumer

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.

P6R’s PKCS 11 Provider

By Mark Joseph - November 22, 2014 @ 3:29 pm

This document was updated on 14 February 2017.

Introduction

P6R has implemented the 2.40 Version of the PKCS 11 specification. Our library meets the requirements for conformance of a PKCS 11 Extended Provider and Authentication Token (see PKCS11 Cryptographic Token Interface Profiles Version 2.40, 16-Sep-2014, OASIS Committee Specification 01). Currently, our library supports seven types of tokens: a KMIP server, a Software token, a Utimaco CryptoServer HSM, a Thales nShield Connect HSM, a FutureX HSM, a DocuSign PrivateServer HSM, and a Hewlett Packard Enterprise Atalla HSM (Network Security Processor). 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.

manyhsms

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_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_DeriveKey, C_WrapKey, and C_UnwrapKey (if the KMIP server supports unwrapping).

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.

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

The Hewlett Packard Enterprise (HPE) Atalla HSM Token

The HPE Atalla HSM (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_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_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.

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.

The Thales HSM Token

The Thales nShield Connect HSM can be configured to look like another token. We map one slot of a Thales HSM into one slot of our P6R PKCS 11 library. This integration supports existing Thales 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 Thales 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.

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.

The DocuSign ARX PrivateServer HSM Token

The DocuSign PrivateServer 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.

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.

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.

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.

Other Applications

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.

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.

References

  1. PKCS 11 OASIS standard
  2. KMIP OASIS standard
  3. P6R’s Secure KMIP Client SDK
  4. Key Management with a Powerful Keystore