This document was updated on 22 Feb 2014.

See the related product page SKC.

P6R has taken a unique approach in its KMIP toolkit design by supporting the translation of a KMIP binary message into a standard DOM tree.  This approach builds on existing P6R technology that supports parsing JSON into DOM trees.  The result is a powerful new tool that can be used for KMIP 1.0, 1.1, 1.2, and any future version of KMIP.

Our toolkit provides a layered set of APIs and applications so that a developer can select at what level or levels of abstraction he wishes to manipulate KMIP messages.

1. LAYERS

Using figure 1 above as a guide we will describe each layer of the toolkit design.

Layer 1 (the lowest layer), contains the KMIP message parser and encoder objects.   All KMIP operations and key encodings are supported.   At this level the developer is working with binary messages.  However, this layer does not include encryption.   As a separate component P6R’s encryption layer is available for use with keys, certificates and SSL.
Also at this layer is a higher level KMIP API.  This higher level API supports simple operations (e.g.,Get one managed object, Locate managed object(s), Locate and Check managed object(s)).

Layer 2, is the DOM tree object.  Our DOM tree contains a plugin architecture that was previously used to support XML and JSON parsers (see XSLT and XPath for JSON).  We have extended this with a 3rd plugin that takes a KMIP binary message as input and calls the objects from layer 1 to populate a DOM tree.   Since a KMIP message is essentially a tree of nested structures this translation is straight forward.  Once the KMIP message is represented by a DOM tree a wealth of P6R technologies’ are available for use.   Note, that the DOM object by itself supports the output of its contents into XML, JSON, JsonML and a KMIP binary message.  In addition, our DOM tree  has been extended to directly support binary nodes such as would be necessary for keys.

Layer 3, XPath 2.0 and XSLT 2.0, as we have done with JSON we have now done with KMIP.  Any part of the KMIP message can be searched for and extracted using the features in the XPath 2.0 language.  Also XSLT 2.0 supports transformation such as taking out just part of a KMIP message to create a new message or translating the entire message into yet another format such as SOAP.  XPath is meant to be extensible allowing a developer to easily add their own XPath functions specific to KMIP (e.g., testing for a message reply or a specific batch item).   Thus via XPath and XSLT our toolkit can be customized by any user.

Also at Layer 3 is P6R’s Rule Engine.  The Rule Engine uses the DOM object to represent its input of “stated facts”.  The Rule Engine uses XPath as part of its rule language .   Thus, for example, a Rule Set could be created to implement a KMIP policy or a validation of a message’s contents.  In addition, several Rule sets can be defined with a different  one loaded depending on some protocol or system state.

Our KMIP toolkit includes several supporting components which include P6R’s cryptographic objects, a Keystore to save protected keys in a client or in a server, and a database object that can be used to store object attributes and configuration information.   The P6R database object supports both SQLite and Postgres databases.

2. BENEFITS

There are many benefits to our approach and our software, here are just a few:

1) As with all P6R software, this toolkit supports multiple platforms: Linux, Solaris, and Windows.  It also provides several language bindings such as Python, Perl, and PHP.   All P6R software is written in C++.

2) Future versions of KMIP may support XML and JSON formats.  Our toolkit already supports this by using existing P6R technology with KMIP specific extensions.

3) Our layered approach allows a developer to use one or more layers of abstraction to process / generate KMIP messages.

4) Add in the rest of the P6R Platform and you are more than half way to a KMIP server (e.g., SNMP support is included and easily extended).  The toolkit by itself is intended for client development.

3. KMIP PROTOCOL CONFORMANCE

P6R’s KMIP client follows the standards defined in the following documents.

1) OASIS, “Key Management Interoperabilty Protocol Specification 1.0″, OASIS Standard, 15 June 2010.

2) OASIS, “Key Management Interoperabilty Protocol Specification 1.1″, OASIS Standard, 24 January 2013.

3) OASIS, “Key Management Interoperabilty Protocol Specification 1.2″, Working Draft 08, 21 August 2013.

4) OASIS, “Key Management Interoperability Protocol Test Cases Version 1.1″, Working Draft 10, 27 April 2012.

5) OASIS, “Key Management Interoperability Protocol Test Cases Version 1.2″, Working Draft 02, 06 August 2013.

6) OASIS, “KMIP Additional Message Encodings Version 1.0″, Working Draft 03, 10 August 2013.

7) OASIS, “KMIP Asymmetric Key Lifecycle Profile Version 1.0″, Working Draft 03, 10 August 2013.

8) OASIS, “KMIP Cryptographic Services Profile Version 1.0″, Working Draft 05, 10 August 2013.

9) OASIS, “KMIP Symmetric Key Foundry for FIPS 140-2 Profile Version 1.0″, Working Draft 03, 10 August 2013.

10) OASIS, “KMIP Symmetric Key Lifecycle Profile Version 1.0″, Working Draft 03, 10 August 2013.

11) OASIS, “KMIP Opaque Managed Object Store Profile Version 1.0″, Working Draft 03, 10 August 2013.

12) OASIS, “KMIP Tape Library Profile Version 1.0″, Working Draft 04a, 24 October 2013.

13) OASIS, “Key Management Interoperability Protocol Storage Array with Self-Encrypting Drives Profile Version 1.0″, Working Draft 04a, 24 October 2013.

KMIP 1.0 Operations — Client provides both synchronous and asynchronous versions of the following operations:

Create, Create Key Pair, Register, Re-key, Derive Key, Certify, Re-certify, Locate, Check, Get, Get Attributes, Get Attribute List, Add Attribute, Modify Attribute, Delete Attribute, Obtain Lease, Get Usage Allocation, Activate, Revoke, Destroy, Archive, Recover, Validate, Query (synch only), Cancel, Poll

KMIP 1.1 Operations — Client provides both synchronous and asynchronous versions of the following operations:

Create, Create Key Pair, Register, Re-key, Derive Key, Certify, Re-certify, Locate, Check, Get, Get Attributes, Get Attribute List, Add Attribute, Modify Attribute, Delete Attribute, Obtain Lease, Get Usage Allocation, Activate, Revoke, Destroy, Archive, Recover, Validate, Query (synch only), Cancel, Poll, Re-key Key Pair, Discover Versions (synch only)

KMIP 1.2 Operations — Client provides both synchronous and asynchronous versions of the following operations:

Create, Create Key Pair, Register, Re-key, Derive Key, Certify, Re-certify, Locate, Check, Get, Get Attributes, Get Attribute List, Add Attribute, Modify Attribute, Delete Attribute, Obtain Lease, Get Usage Allocation, Activate, Revoke, Destroy, Archive, Recover, Validate, Query (synch only), Cancel, Poll, Re-key Key Pair, Discover Versions (synch only), Encrypt, Decrypt, Sign, Signature Verify, MAC, MAC Verify, RNG Retrieve, RNG Seed, Hash, Create Split Key, Join Split Key

We claim conformance to the following standard defined test cases using Tag Type Length Value (TTLV), XML, and JSON message encodings for all tests:

KMIP Version 1.0 Test Cases Supported
TC-311-10	Create / Destroy
TC-312-10	Register / Create / Get attributes / Destroy
TC-313-10	Create / Locate / Get / Destroy
TC-314-10	Dual Client Test Case, ID Placeholder-linked Locate & Get Batch
TC-315-10	Register / Destroy Secret Data
TC-32-10	Asynchronous Locate
TC-41-10	Revoke Scenario
TC-51-10	Get Usage Allocation Scenario
TC-61-10	Import of a Third-party Key
TC-71-10	Unrecognized Message Extension with Criticality Indicator False
TC-72-10	Unrecognized Message Extension with Criticality Indicator True
TC-81-10	Create a Key Pair
TC-82-10	Register Both Halves of a Key Pair
TC-91-10	Create a Key, Re-key
TC-92-10	Existing Key Expired, Re-key with Same Life-cycle
TC-93-10	Existing Key Compromised, Re-key with Same Life-cycle
TC-94-10	Create Key, Re-key with New Life-cycle
TC-95-10	Obtain Lease for Expired Key
TC-101-10	Create a Key, Archive and Recover it
TC-111-10	Credential, Operation Policy, Destroy Date
TC-121-10	Query, Maximum Response Size
TC-131-10	Register an Asymmetric Key Pair in PKCS1 Format
TC-132-10	Register an Asymmetric Key Pair and a Corresponding X509 Certificate
TC-134-10	Register Key Pair, Certify and Re-certify Public Key

Symmetric Key Lifecycle Profile
SKLC-M-1-10   Create, GetAttributes, Destroy
SKLC-M-2-10   Create, GetAttributes, Activate, GetAttributes, Destroy, Revoke, 
              GetAttributes, Destroy
SKLC-M-3-10   Create, GetAttributes, Activate, GetAttributes, ModifyAttribute, Revoke, 
              GetAttributes, Destroy
SKLC-O-1-10   Create, GetAttributes, Destroy, GetAttributes

Symmetric Key Foundry for FIPS 140-2 Profile
SKFF-M-1-10   Create, Destroy AES-128 
SKFF-M-2-10   Create, Destroy AES-192 
SKFF-M-3-10   Create, Destroy AES-256 
SKFF-M-4-10   Create, Destroy DES3-168  
SKFF-M-5-10   Create, Locate, Get, Destroy, Locate AES-128 
SKFF-M-6-10   Create, Locate, Get, Destroy, Locate AES-192  
SKFF-M-7-10   Create, Locate, Get, Destroy, Locate AES-256 
SKFF-M-8-10   Create, Locate, Get, Destroy, Locate DES3-168  
SKFF-M-9-10   Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy AES-128
SKFF-M-10-10  Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy AES-192  
SKFF-M-11-10  Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy AES-256  
SKFF-M-12-10  Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy DES3-168  
SKFF-O-1-10   Create, Destroy SKIPJACK-80 
SKFF-O-2-10   Create, Locate, Get, Destroy, Locate SKIPJACK-80 
SKFF-O-3-10   Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy SKIPJACK-80 
SKFF-O-4-10   Create, Destroy DES3-112  
SKFF-O-5-10   Create, Locate, Get, Destroy, Locate DES3-112 
SKFF-O-6-10   Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy DES3-112  

Asymmetric Key Lifecycle Profile Supported
AKLC-M-1-10   CreateKeyPair, GetAttributes, GetAttributes, Destroy
AKLC-M-2-10   CreateKeyPair, GetAttributes, Activate, GetAttributes, Destroy, Revoke, 
              GetAttributes, Destroy
AKLC-M-3-10   CreateKeyPair, GetAttributes, Activate, GetAttributes, Destroy, Revoke, 
              GetAttributes, Destroy
AKLC-O-1-10   CreateKeyPair, GetAttributes, Destroy, GetAttributes 

KMIP Opaque Managed Object Store Profile 
OMOS-M-1-10   Register small opaque object
OMOS-O-1-10   Register large (>10k) opaque object

KMIP Tape Library Profile Version 1.0
TL-M-1-10     Configuration
TL-M-2-10     Write with new (created) key
TL-M-3-10     Read an encrypted tape  

Key Management Interoperability Protocol Storage Array with Self-Encrypting Drives 
   Profile Version 1.0
SASED-M-1-10  Configuration
SASED-M-2-10  Register the authentication key
SASED-M-3-10  Retrieve Authentication Key  

SEPATON Profile Version 1.0
SEPATON-1-10 Query
SEPATON-2-10 Locate, Create
SEPATON-3-10 Locate, Get, GetAttributes, Activate, GetAttributes 

KMIP Version 1.1 Test Cases Supported
TC-311-11	Create / Destroy
TC-312-11	Register / Create / Get attributes / Destroy
TC-313-11	Create / Locate / Get / Destroy
TC-314-11	Dual Client Test Case, ID Placeholder-linked Locate & Get Batch
TC-315-11	Register / Destroy Secret Data
TC-32-11	Asynchronous Locate
TC-41-11	Revoke Scenario
TC-51-11	Get Usage Allocation Scenario
TC-61-11	Import of a Third-party Key
TC-71-11	Unrecognized Message Extension with Criticality Indicator False
TC-72-11	Unrecognized Message Extension with Criticality Indicator True
TC-81-11	Create a Key Pair
TC-82-11	Register Both Halves of a Key Pair
TC-91-11	Create a Key, Re-key
TC-92-11	Existing Key Expired, Re-key with Same Life-cycle
TC-93-11	Existing Key Compromised, Re-key with Same Life-cycle
TC-94-11	Create Key, Re-key with New Life-cycle
TC-95-11	Obtain Lease for Expired Key
TC-101-11	Create a Key, Archive and Recover it
TC-111-11	Credential, Operation Policy, Destroy Date
TC-112-11	Device Credential, Operation Policy, Destroy Date
TC-121-11	Query, Maximum Response Size
TC-122-11	Query Vendor Extensions
TC-131-11	Register an Asymmetric Key Pair in PKCS1 Format
TC-132-11	Register an Asymmetric Key Pair and a Corresponding X509 Certificate
TC-133-11	Create, Re-key Key Pair
TC-134-11	Register Key Pair, Certify and Re-certify Public Key
TC-141-11	Key Wrapping using AES Key Wrap and No Encoding
TC-142-11	Key Wrapping using AES Key Wrap with Attributes
TC-151-11	Locate a Fresh Object from the Default Group
TC-152-11	Client-side Group Management
TC-153-11       Default Object Group Member
TC-161-11	Discover Versions
TC-171-11	Handling of Attributes and Attribute Index Values
TC-181-11	Digests of Symmetric Keys
TC-182-11	Digests of RSA Private Keys

Symmetric Key Lifecycle Profile
SKLC-M-1-11   Create, GetAttributes, Destroy
SKLC-M-2-11   Create, GetAttributes, Activate, GetAttributes, Destroy, Revoke, 
              GetAttributes, Destroy
SKLC-M-3-11   Create, GetAttributes, Activate, GetAttributes, ModifyAttribute, Revoke, 
              GetAttributes, Destroy
SKLC-O-1-11   Create, GetAttributes, Destroy, GetAttributes

Symmetric Key Foundry for FIPS 140-2 Profile
SKFF-M-1-11   Create, Destroy AES-128 
SKFF-M-2-11   Create, Destroy AES-192 
SKFF-M-3-11   Create, Destroy AES-256 
SKFF-M-4-11   Create, Destroy DES3-168  
SKFF-M-5-11   Create, Locate, Get, Destroy, Locate AES-128 
SKFF-M-6-11   Create, Locate, Get, Destroy, Locate AES-192  
SKFF-M-7-11   Create, Locate, Get, Destroy, Locate AES-256 
SKFF-M-8-11   Create, Locate, Get, Destroy, Locate DES3-168  
SKFF-M-9-11   Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy AES-128
SKFF-M-10-11  Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy AES-192  
SKFF-M-11-11  Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy AES-256  
SKFF-M-12-11  Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy DES3-168  
SKFF-O-1-11   Create, Destroy SKIPJACK-80 
SKFF-O-2-11   Create, Locate, Get, Destroy, Locate SKIPJACK-80 
SKFF-O-3-11   Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy SKIPJACK-80 
SKFF-O-4-11   Create, Destroy DES3-112  
SKFF-O-5-11   Create, Locate, Get, Destroy, Locate DES3-112 
SKFF-O-6-11   Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy DES3-112  

Asymmetric Key Lifecycle Profile Supported
AKLC-M-1-11   CreateKeyPair, GetAttributes, GetAttributes, Destroy
AKLC-M-2-11   CreateKeyPair, GetAttributes, Activate, GetAttributes, Destroy, Revoke, 
              GetAttributes, Destroy
AKLC-M-3-11   CreateKeyPair, GetAttributes, Activate, GetAttributes, Destroy, Revoke, 
              GetAttributes, Destroy
AKLC-O-1-11   CreateKeyPair, GetAttributes, Destroy, GetAttributes 

KMIP Opaque Managed Object Store Profile 
OMOS-M-1-11   Register small opaque object
OMOS-O-1-11   Register large (>10k) opaque object

KMIP Tape Library Profile Version 1.0
TL-M-1-11     Configuration
TL-M-2-11     Write with new (created) key
TL-M-3-11     Read an encrypted tape  

Key Management Interoperability Protocol Storage Array with Self-Encrypting Drives 
   Profile Version 1.0
SASED-M-1-11  Configuration
SASED-M-2-11  Register the authentication key
SASED-M-3-11  Retrieve Authentication Key  

KMIP Version 1.2 Test Cases Supported	
TC-311-12    Create / Destroy
TC-312-12    Register / Create / Get attributes / Destroy
TC-313-12    Create / Locate / Get / Destroy
TC-314-12    Dual Client Test Case, ID Placeholder-linked Locate & Get Batch
TC-315-12    Register / Destroy Secret Data
TC-32-12     Asynchronous Locate
TC-41-12     Revoke Scenario
TC-51-12     Get Usage Allocation Scenario
TC-61-12     Import of a Third-party Key
TC-71-12     Unrecognized Message Extension with Criticality Indicator False
TC-72-12     Unrecognized Message Extension with Criticality Indicator True
TC-81-12     Create a Key Pair
TC-82-12     Register Both Halves of a Key Pair
TC-91-12     Create a Key, Re-key
TC-92-12     Existing Key Expired, Re-key with Same Life-cycle
TC-93-12     Existing Key Compromised, Re-key with Same Life-cycle
TC-94-12     Create Key, Re-key with New Life-cycle
TC-95-12     Obtain Lease for Expired Key
TC-101-12    Create a Key, Archive and Recover it
TC-111-12    Credential, Operation Policy, Destroy Date
TC-112-12    Device Credential, Operation Policy, Destroy Date
TC-121-12    Query, Maximum Response Size
TC-122-12    Query Vendor Extensions
TC-131-12    Register an Asymmetric Key Pair in PKCS1 Format
TC-132-12    Register an Asymmetric Key Pair and a Corresponding X509 Certificate
TC-133-12    Create, Re-key Key Pair
TC-134-12    Register Key Pair, Certify and Re-certify Public Key
TC-141-12    Key Wrapping using AES Key Wrap and No Encoding
TC-142-12    Key Wrapping using AES Key Wrap with Attributes
TC-151-12    Locate a Fresh Object from the Default Group
TC-152-12    Client-side Group Management
TC-153-12    Default Object Group Member
TC-161-12    Discover Versions
TC-171-12    Handling of Attributes and Attribute Index Values
TC-181-12    Digests of Symmetric Keys
TC-182-12    Digests of RSA Private Keys
TC-PGP-1-12  Register PGP Key - RSA
TC-MDO-1-12  Register MDO Key
TC-MDO-2-12  Locate MDO keys by Key Value Present
TC-MDO-3-12  Register MDO Key using PKCS11 URI
TC-SJ-1-12   Create and Split/Join
TC-SJ-2-12   Register and Split / Join
TC-SJ-3-12   Join Split Keys
TC-SJ-4-12   Register and Split / Join with XOR

Symmetric Key Lifecycle Profile
SKLC-M-1-12   Create, GetAttributes, Destroy
SKLC-M-2-12   Create, GetAttributes, Activate, GetAttributes, Destroy, Revoke, 
              GetAttributes, Destroy
SKLC-M-3-12   Create, GetAttributes, Activate, GetAttributes, ModifyAttribute, Revoke, 
              GetAttributes, Destroy
SKLC-O-1-12   Create, GetAttributes, Destroy, GetAttributes

Symmetric Key Foundry for FIPS 140-2 Profile
SKFF-M-1-12   Create, Destroy AES-128 
SKFF-M-2-12   Create, Destroy AES-192 
SKFF-M-3-12   Create, Destroy AES-256 
SKFF-M-4-12   Create, Destroy DES3-168  
SKFF-M-5-12   Create, Locate, Get, Destroy, Locate AES-128 
SKFF-M-6-12   Create, Locate, Get, Destroy, Locate AES-192  
SKFF-M-7-12   Create, Locate, Get, Destroy, Locate AES-256 
SKFF-M-8-12   Create, Locate, Get, Destroy, Locate DES3-168  
SKFF-M-9-12   Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy AES-128
SKFF-M-10-12  Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy AES-192  
SKFF-M-11-12  Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy AES-256  
SKFF-M-12-12  Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy DES3-168 
SKFF-O-1-12   Create, Destroy SKIPJACK-80 
SKFF-O-2-12   Create, Locate, Get, Destroy, Locate SKIPJACK-80 
SKFF-O-3-12   Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy SKIPJACK-80 
SKFF-O-4-12   Create, Destroy DES3-112  
SKFF-O-5-12   Create, Locate, Get, Destroy, Locate DES3-112 
SKFF-O-6-12   Create, Get, Activate, Revoke, Locate, Add/Mod/Del Attributes, Destroy DES3-112  
 
Asymmetric Key Lifecycle Profile Supported
AKLC-M-1-12   CreateKeyPair, GetAttributes, GetAttributes, Destroy
AKLC-M-2-12   CreateKeyPair, GetAttributes, Activate, GetAttributes, Destroy, Revoke, 
              GetAttributes, Destroy
AKLC-M-3-12   CreateKeyPair, GetAttributes, Activate, GetAttributes, Destroy, Revoke, 
              GetAttributes, Destroy
AKLC-O-1-12   CreateKeyPair, GetAttributes, Destroy, GetAttributes 

KMIP Opaque Managed Object Store Profile 
OMOS-M-1-12   Register small opaque object
OMOS-O-1-12   Register large (>10k) opaque object

KMIP Tape Library Profile Version 1.0
TL-M-1-12     TL-M-1-12 Configuration
TL-M-2-12     TL-M-2-12 Write with new (created) key
TL-M-3-12     TL-M-3-12 Read an encrypted tape  

Key Management Interoperability Protocol Storage Array with Self-Encrypting Drives 
   Profile Version 1.0
SASED-M-1-12  Configuration
SASED-M-2-12  Register the authentication key
SASED-M-3-12  Retrieve Authentication Key  

KMIP Cryptographic Services Profile (KMIP 1.2) Supported
CS-BC-M-1-12  Encrypt with New Symmetric Key   
CS-BC-M-2-12  Decrypt with New Symmetric Key
CS-BC-M-3-12  Encrypt and Decrypt with New Symmetric Key
CS-BC-M-4-12  Encrypt with Known Symmetric Key
CS-BC-M-5-12  Decrypt with Known Symmetric Key
CS-BC-M-6-12  Encrypt and Decrypt with Known Symmetric Key 
CS-BC-M-7-12  Encrypt with Known Symmetric Key with Usage Limits
CS-BC-M-8-12  Encrypt and Decrypt with Known Symmetric Key and PKCS5 Padding
CS-BC-M-9-12  Encrypt and Decrypt with Known Symmetric Key and PKCS5 Padding
CS-BC-M-10-12 Encrypt and Decrypt with Known Symmetric Key and PKCS5 Padding and CBC
CS-BC-M-11-12 Encrypt and Decrypt with Known Symmetric Key and PKCS5 Padding and CBC and IV
CS-BC-M-12-12 Encrypt and Decrypt with Known Symmetric Key and PKCS5 Padding and CBC and IV
CS-BC-M-13-12 Encrypt and Decrypt with Known Symmetric Key and PKCS5 Padding and CBC 
              and Random IV
CS-BC-M-14-12 Encrypt and Decrypt with Known Symmetric Key Date Checks
CS-RNG-M-1-12 RNG Retrieve
CS-RNG-O-1-12 Seed RNG with Server Accept
CS-RNG-O-2-12 Seed RNG with Server Partial Accept
CS-RNG-O-3-12 Seed RNG with Server Ignore
CS-RNG-O-4-12 Seed RNG with Server Deny
CS-AC-M-1-12  Sign with Known Asymmetric Key
CS_AC-M-2-12  Signature Verify with Known Asymmetric Key
CS-AC-M-3-12  Sign and Signature Verify with Known Asymmetric Key
CS-AC-M-4-12  MAC with Known Key
CS_AC-M-5-12  MAC Verify with Known Key
CS-AC-M-6-12  MAC and MAC Verify with Known Key
CS-AC-M-7-12  Hash
CS-AC-M-8-12  Sign and Signature Verify with Known Asymmetric Key Date Checks

KMIP Additional Message Encodings Supported (for KMIP 1.0, 1.1 & 1.2)
MSGENC-HTTPS-1-10 HTTPS POST: Query, Maximum Response Size
MSGENC-XML-1-10 Message Encoding XML: Query, Maximum Response Size (In addition, we have run all above test cases in XML mode.)
MSGENC-JSON-1-10 Message Encoding JSON: Query, Maximum Response Size (In addition, we have run all above test cases in JSON mode.)

Managed Objects Supported
Certificate, Symmetric Key, Public Key, Private Key, Split Key, Template, Secret Data, Opaque Object, PGP Key

Cryptographic Algorithms
DES, 3DES, DES-X, AES (including counter mode), RSA, DSA, DH, HMAC-SHA1, HMAC-SHA224
HMAC-SHA256, HMAC-SHA384, HMAC-SHA512, HMAC-MD2, HMAC-MD4, HMAC-MD5, Blowfish, CAST5, RC2

Key Format Types
Raw, Opaque, PKCS#1, PKCS#8, X.509, Transparent Symmetric Key, Transparent DSA Private Key
Transparent DSA Public Key, Transparent RSA Private Key, Transparent RSA Public Key

Certificate Types
X.509

Support for the Suite B Profile
This profile is defined by the document:
OASIS, “KMIP Suite B Profile Version 1.0″, Working Draft 03a, 24 October 2013. P6R’s KMIP client uses the OpenSSL library for its SSL/TLS support (see http://www.openssl.org/). Our client allows the user to select the ciphers to use for SSL/TLS via the API call:

setSSLOptions( const P6WCHAR* pCiphers, P6SECURESOCKETFLAGS fSecureFlags )

where the “pCiphers” paramter is a pointer to a NULL terminated character string containing the OpenSSL cipher command (see http://www.openssl.org/docs/apps/ciphers.html). If pCiphers parameter is NULL, then the secure default will be automatically be used: “TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:@STRENGTH” which enables SSLv3 and TLSv1, disables SSLv2, disables ciphers that do not use authentication, disables 3DES, and prefers the strongest ciphers first. The only constraint, is that the specified ciphers in the setSSLOptions API call are supported by the OpenSSL library in use, whether supplied by the customer or P6R.

4. A FEW EXAMPLES

Example 1: included below are 4 files containing the same KMIP 1.0 message. The first file is a dump of its binary bytes. The remaining files are translations into XML, JSON, and JsonML.  All the translated files came from the same DOM tree.

1) kmip-binary   2)  kmip-xml   3) kmip-json   4)  kmip-jsonml

Example 2: as a second example the same binary KMIP message used in #1 above is manipulated by an XSLT template to generate a Tag-Text output (with some values dropped).  The second file is the result of running the template on the same DOM tree generated in example 1.

Template: kmip-template1

Tag-Text result: kmip-tagtext

(Note that this template is just a very simple example of what is possible with XSLT & XPath 2.0.)

Example 3: the binary message below is generated from a KMIP test server while its XML version is an output from P6R’s KMIP client.  These messages are a more complex KMIP example of a response to a KMIP Query operation.

1) binary-queryresponse   2) xml-queryresponse

5. Product Summary

The toolkit provides C++ based component libraries that currently implement the KMIP 1.0/1.1/1.2 protocols. The toolkit provides full KMIP message parsing and message generation. The toolkit provides several different layers of abstraction, each building on the previous, enabling the developer to use whichever layer or layers best suit their needs. The toolkit comes with binaries for Linux, Solaris, and Windows platforms. The toolkit supports logging of incoming and outgoing KMIP messages in XML, JSON, and JsonML to simplify development and trouble shooting.

6. Interoperability Announcements

QuintessenceLabs Announces Interoperability Partnership With P6R – Project 6 Research

Thales e-Security (Thales Alliance for Solution and Application Providers (ASAP) member)

January 2014, OASIS Interop testing with the following KMIP servers: Cryptsoft (C and Java), Dell, HP, IBM, SafeNet, Thales, and Vormetric.

P6R in the OASIS Interop booth for RSA 2014

P6R, Inc is a member of OASIS and of the KMIP Technical Committee

Introduction

P6R has built a brand new implementation of an SSH server. As with all our software, this SSH server runs on multiple platforms which include: Windows, Linux, and Solaris. The main motivation for this project was to construct a server that could easily scale to performance demands that far exceed existing SSH implementations. A secondary motivation was to test out P6Platform’s high-performance threading and asynchronous IO functions.

Our server design has several main principles:

1. Threads should not block waiting for IO to complete.
2. A thread should not be tied to a single SSH session.
3. Protocol and application processing (e.g., shell, SCP, execs invocations) should not interfere with each other.
4. The server should allow a customer to use their own shell, exec, or subsystem implementations.

Thread Design

Our server design uses two pools of threads. One pool is used to process all SSH protocol processing and the other to run application processing such as running a shell, executing execs, or running SSH subsystems. Each of these pools has its own p6IEventQ component which is used as a work queue. Each thread in a pool will block on its associated work queue to waiting for incoming work. Work arrives on a queue in the form of a message containing a predefined structure (e.g., with a type field indicating the type of the message (e.g., socket IO, file IO, application message between threads). For example, for SSH protocol threads incoming work could be new network connections or incoming packets on existing SSH sessions both arriving via socket IO. Notice, that the two independent thread pools satisfy item ‘c’ above from our design principles.

The SSH protocol threads communicate with the application threads by creating a message and placing it onto the work queue associated with the application threads. Such messages can contain data from an SSH client for a shell or maybe a SCP server. When an application thread has data to be sent/returned back to the SSH client it creates another message and places it on the work queue associated with the SSH protocol threads.

Another important point to make is that these messages also contain a local SSH session identifier and a SSH channel number (SSH sessions have multiple channels to send data over). When a new SSH session is initiated by a client connection the server allocates a session object and places it into a global map data structure indexed by session identifier. The session object contains all the state of the session including any data buffers, generated encryption keys, counters, etc.

The above mentioned session object must be found when an incoming packet arrives off of the network for an existing SSH session. This is easily done. The SSH server posts an outstanding socket read for all active sessions and associates its session object with the read. (Note that the thread does not block on this socket read request. But instead it checks its associated worker queue for other work to perform.) When a packet finally arrives for one of the outstanding socket reads a message is placed on the SSH worker queue with its associated session object. Notice that a session’s state is separate from the thread and thus any thread can service any SSH session request. Thus this state mechanism satisfies item ‘b’ above from our design principles.

Lastly, we should describe how application threads only need the data that is passed to them in order to run a shell, an exec command, or an SSH subsystem. This is accomplished by associating separate, newly created objects that implement a shell, an exec, or subsystem for each SSH channel in a session. These “application” objects maintain the application state over the lifetime of the SSH channel. These objects are included in the messages sent from the SSH protocol threads to the application threads. Thus when an application thread wakes up from waiting on its work queue it receives both data from a client and the object to process it. Again notice that all the state of the application is separated from the thread thus allowing any application thread to work on any application request. The benefit of this type of design is performance since threads are not dedicated to a specific session nor are they blocked waiting for IO to complete. This mechanism also supports item ‘b’ above from our design principles.

The application objects mentioned in the previous paragraph which implement a shell, exec, or subsystem are all P6R component objects that have a standard definition thus allowing a customer to write their own versions and replace those that come pre-existing with the SSH server.

Asychronous Design

Our p6IEventQ component supports an asynchronous IO model. The event queue supports several types of completion notifications (socket, file, timer, etc) and can be extended to support application specific messages as well. As an example of performing socket IO, an application would associate a socket component with the queue and then post requests to accept, connect, read, write, etc. to the queue. The applications thread (or threads) can then wait for an new event on the queue to receive the completion notification of the requested operation. The type of work returned on the queue is typed so that the waking thread can figure out how to handle it. (Note for socket IO the socket handle is also returned and for file IO the file handle is returned in the message as well.)

Thus this queue mechanism frees up threads to do other tasks instead of blocking and waiting for the requested IO to complete. Of course this requires a different style (and perhaps harder) of writing server code but the benefits can be significant performance gains. This queue design satisfies item ‘a’ above from out design principles.

Plugin Architecture

Out of the box our SSH server provides the following plugins:

1. A password authentication method
2. An asymmetric key authentication method
3. A limited CLI for an application shell (which allows the user to check the status of the system state such as number of threads running, amount of memory used, etc)
4. An exec command processor that implements SCP but nothing else. SCP allows for secure file and directory transfer between client and server.

 
A plugin is nothing more than a P6R component object which implements a defined interface(s). A plugin is found by either including its GUID in the SSH server’s configuration file or it is searched for by the server’s initialization code. Details on how plugins are implemented, defined, and loaded by the SSH server can be found in the server’s documentation.

The key point to take away from this section is that any of the plugins defined can be replaced by customer implemented versions. In addition, other authentication method plugins can be added easily (e.g., to support Kerberos). Also, any number of SSH subsystems can be defined and added to our server just as long as they define unique names (“[email protected]” is reserved for P6R applications). Thus our plugin architecture satisfies item ‘d’ above from our design principles.

Miscellaneous

Our SSH server performs session crypto re-keying based on several different schemes which can be controlled via configuration parameters.
We support re-keying based on time intervals, number of bytes transferred over the connection, and number of SSH packets transferred. One or more of the these schemes can be turned on at the same time.

We have added extensive logging at all levels of the server implementation. We also pass a flag into plugins indicating what level of logging has been requested. For example, we use this to turn on SCP protocol logging even though SCP is implemented in an exec component that runs in the application threads. Our SCP implementation handles Windows’ driver letters (e.g., “C:”, “e:”) in file paths so that transfer of files and directories from/to Windows and Unix works easily.

Lastly, we have tested our SSH server with all major SSH clients and command line SCP clients.

This document was updated on 30 March 2014.

Key management is essential for data at rest on disk and tape drives. Data at rest (e.g., financial, medial records) has to be stored for years. Stored in encrypted form the only way to access the real data is by reliably locating its associated key. For data in transit on computer networks long term data retention is not a requirement since keys are regularly replaced after a set amount of data or time. Data in transit applications can use easy modification of key meta data (e.g., change in key state), key association with certificates, and a fast key find. In addition, a flexible keystore should be able to handle application specific data stored near its keys. We have designed and built a powerful keystore as a building block for an overall solution to key management.

Requirements for a keystore

P6R’s keystore supports key management applications by addressing the following requirements:

1. Support both client and server applications with a software solution that can be used by itself or included as part of an appliance.
2. Support the storage of all types of keys, certificates, key — certificate relationships (e.g., key chains), and non-key, opaque, application specific data (e.g., passwords).
3. Provide a hierarchical naming structure to help applications organize keystore contents.
4. Enforce that all data in the keystore is encrypted and that the entire contents of the keystore is signed to prevent unauthorized modification (e.g., encryption of key material alone will not prevent the deletion of a key.)
5. Provide a powerful key look up mechanism that supports all types of queries (e.g., find all keys with ciphers like “AES” which would include “AES CFB”, “AES CBC” in the reesults).
6. Support the NIST Special Publication 800-130: “A Framework for Designing Cryptographic Key Management Systems” which defines extensive key meta data (e.g., includes a set of key states, use, and dates).
7. Allow arbitrary association of objects stored in a keystore (e.g., associate a public key with its matching private key).

8. Allow an application to associate any number of application specific attributes to an entry in a keystore (e.g., set the date of when a key “will expire”). Also allow queries to find entries in the keystore based on these attribute name value pairs (e.g., find all keys that “will expire” in 30 days).

Continue Reading »

Introduction

p6ComPtr<> is a smart pointer implementation designed for use with p6COM, P6R’s lite implementation of the Component Object Model. p6COM is the basis for our cross platform server framework as well as the library loader for our library products. p6ComPtr<> is a tool to help prevent component leaks and simplify the use and management of p6COM interfaces. COM interfaces have compelling advantages, but also have drawbacks. One advantage is reference counting which allows an interface’s lifetime to be managed intelligently. It turns out that this advantage is also a disadvantage because even the most fastidious developers make mistakes when managing an interfaces reference count manually through calls to addref() and release().

Continue Reading »

P6R’s RGX™ 1.0 Regular Expression Engine has some unique features that make it stand out from the crowd. One such feature is its regex-oriented tracing. Several others are described below.

First, we have added a new global modifier ‘P6MOD_FULLLOOKBEHIND’. This modifier allows the look behind meta character sequences ‘(?<=’ & ‘(?<!’ to match anywhere in the input string already seen. So for example, given the regex of ‘(?<=44 )\\btime\\b’ using the full look behind modifier would match the input string of: ‘Now 44 is the time to pay your bills’. The ’44′ is not right next to the ‘time’ string, but 44 is still found. In normal (Perl implemented) look behind the input string would have to be something like ‘Now is the 44 time to pay your bills’. Notice that in this last example, ’44′ is right before ‘time’.
Continue Reading »

It can be difficult to derive the correct regular expression for the problem you are trying to solve. There are many internet sites (e.g., Regular Expression Tester) and PC applications that help to construct what seems to be the right expression. However, how do you know that that expression is working properly in a production system? Sure a program can log each input string that a regex was successful for or failed on, but wouldn’t be better to see details on exactly what the regular expression was doing step by step against each input string. For this reason, we have added a regex-oriented tracing feature to P6R’s RGX™ 1.0 Regular Expression Engine.

Continue Reading »

1. The Problem

There is no standard way of translating an XML document into its JSON equivalent.  An acceptable translation scheme should be lossless (i.e., not lose any of the XML specific information).  Also a translation scheme should ensure that if the JSON document is converted back into XML that important XML aspects of the original document are maintained (e.g., element attributes, namespaces).

2. Detailed Translation Issues

The following three issues make it difficult to provide a lossless XML to JSON translation.
Continue Reading »

Introduction

P6Platform and other planned products are and will be built on our light-weight component object framework implementation called P6COM. We chose the Component Object Model (COM) for our products because it provides many advantages (but that’s a whole other article), and in order to realize those advantages you have to follow the rules. There are lots of excellent references on COM (you can find some of my favorites at the end of this article) and you should read them. This article is not meant to replace those texts and is really here as a summary, or a kind of cheat sheet to help remember the rules.
Continue Reading »

This article describes an advanced feature of P6R’s rule engine. (See our XJR SDK.) An introduction to that rule engine can be found at An XPath Enabled Rule Engine. The current article addresses the issue “how effective are my rules”?

Rule Execution Statistics

Passing the ‘P6RULE_KEEPSTATS’ flag into the p6IRuleEngine::initialize() method enables a powerful run-time feature. Automatically a subtree ‘/P6R:stats’ is created (similar to the subtree ‘/P6R:infer’ used to store inferred facts) off of the fact tree. In this tree the following counts are generated: (1) how many times a each rule is executed, and (2) the total number of rules that evaluated to true and those to false. Each count is done in relation to a rule set. After an evaluation this information can be output in a similar way that the inferred rules are output (i.e., p6IRuleEngine::outputStatistics()).

Below is an example output taken from one of our unit tests:

<?xml version="1.0" encoding="utf-8"?>
<P6R:stats xmlns:P6R="http://www.p6r.com/ruleengine">
   <redrover>
        <P6R:eval-true>2</P6R:eval-true>
        <P6R:eval-false>2</P6R:eval-false>
        <newset>2</newset>
   </redrover>
   <P6R:defaultset>
        <P6R:eval-true>4</P6R:eval-true>
        <Irvin>2</Irvin>
        <stoprules>2</stoprules>
   </P6R:defaultset>
</P6R:stats>

In the example above, ‘redrover’ is the name of a defined rule set. ‘P6R:defaultset’ is the XML friendly name used for the ‘#default’ rule set. ‘P6R:eval-true’ represents the count of the number of rules that evaluated to true, while ‘P6R:eval-false’ represents the opposite. The ‘newset’ element is a rule in the redrover rule set that ran twice. From these counts we can see what rules get executed and how often.
Continue Reading »

Other articles on this site have described the JSON support we have added to our XSLT 2.0 and XPath 2.0 products (see A SAX-like Parser for JSON, XSLT and XPath for JSON, and our XJR SDK.). In this article, we describe two additional extensions to our XSLT 2.0 and DOM parser products to support the output of JSON documents. The following XSLT example is currently running in our unit tests. We have kept it simple so it would fit here and yet convey the power of our tools.

First, here is the XSLT template that generates JSON:

<?xml version='1.0' encoding='UTF-8'?>
<xsl:stylesheet version='2.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>
<xsl:output method='json'/>
<xsl:variable name='gtlist' select='/staff/employee/name'/>
<xsl:template match='/'>
{{ "employee":
<xsl:text>  [</xsl:text>                                                        
<xsl:for-each select='$gtlist'>                                              
        <xsl:sort select='.' />                                                      
"<xsl:value-of select='.' />"                                                 
<xsl:if test='position() != last()'>,\n  </xsl:if>                             
</xsl:for-each>                                                               
<xsl:text>]\n}}</xsl:text>                                                      
</xsl:template>
</xsl:stylesheet>

The following also works to select JSON as the output method (i.e., it uses a proper QName for the method value):

<xsl:stylesheet version='2.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'
       xmlns:jn='http://www.json.org'

<xsl:output method='jn:json'/>
* * * * *

Or we can generate JsonML by the following modification to the top of the above template:

<xsl:stylesheet version='2.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform' 
     xmlns:jm='http://www.jsonml.org'>

<xsl:output method='jm:jsonml'/>
* * * * * 

Notice the necessity of using the double “{{” and “}}” characters because curly brakets are meaningful in XSLT (e.g., attribute value templates). The “{{” produces a single “{” in the output, and the “}}” character sequence produces a single “}” in the output. Also of interest is that our style sheet is using XSLT sorting.

Continue Reading »