Key Management Interoperability Protocol

This article was due to content flaws on the quality assurance side of the computer science editorial added. This is done in order to bring the quality of the articles from the subject area of computer science to an acceptable level. Help to eliminate the shortcomings in this article and take part in the discussion ! ( + )

The Key Management Interoperability Protocol ( KMIP ) offers a uniform standard for communication between a Key Lifecycle Management System (KLMS) and its clients. This enables central key management to be used and data security to be increased. The protocol is standardized by OASIS .

Protocol definition

The KMIP specification defines what a message must look like and what information can be exchanged. Some functionalities of the client and server , for example error handling, are specified. Others can be implemented as desired. A client or server does not have to implement the complete functionality defined in the protocol, but only what is actually required. The protocol specification does not specify how the authentication between client and server is carried out. However, two authentication profiles are described in an accompanying document. Versions of the TLS are used for both profiles . TLS is not only used for authentication, it also ensures the integrity of the data .

Objects

When it comes to objects, a distinction is made between base objects and managed objects . Base objects are information that specify a managed object . The base objects include, for example, attributes, key value and key wrapping data.

A managed object is an object with cryptographic content that is managed by the KLM system. This includes the various keys and certificates . In addition, templates can be created which enable the administrator of a KLM system to summarize attributes of frequently used processes. For example, a template for a symmetric key can be created in which the algorithm and the length of the key are defined. If a key is to be created according to these specifications, the name of the template is passed instead of the desired attributes. The Secret Data Object (e.g. for passwords ) or the Opaque Object are used to save other objects that are to be kept secret . The data in the Opaque Object need not be able to be interpreted by the server. For example, a key is saved even though the server does not support the encryption algorithm used .

Attributes

There are various attributes to specify the managed objects . In the table all attributes are listed with their most important properties. There are attributes that are mandatory for every object or for certain objects, others are optional. Several instances of some attributes can exist per object. This is important for the link, for example. A public key has a link to the associated private key and, in addition to the certificate, which links the key to an identity. The KMIP specification also describes for each attribute who is allowed to create, change or delete it and for which operations the attribute is set implicitly.

attribute	description
Unique identifier	Unique designation of an object within a KLMS Is set by the server when it is created and cannot be changed
Surname	Name of the object Set by the client Required by the client to reference the object
Object Type	Type of object ( public key, private key, etc.)
Cryptographic Algorithm	Algorithm used by the object ( RSA , DES , AES etc.)
Cryptographic Length	Length of the key in bits
Cryptographic parameters	Parameters for certain applications (e.g. hash algorithm )
Cryptographic Domain Parameters	Parameters for creating a key pair
Certificate Type	Type of certificate ( X.509 , PGP etc.)
Certificate Identifier	Identification of a certificate (issuer of the certificate and, if available, serial number)
Certificate Subject	Identification of the subject (person or device) of a certificate Can contain several descriptions (name, email address, IP address, etc.)
Certificate issuer	Identification of the issuer of a certificate Can contain several descriptions (name, email address, IP address, etc.)
Digest	Hash value of key, certificate, secret data or opaque object Multiple hash values possible (with different algorithms)
Operation Policy Name	Description of which clients are allowed to perform which operations on the object Server has at least one standard setting (default policy)
Cryptographic Usage Mask	Bit mask Describes the permitted uses of a key
Lease time	Interval during which the object may be used
Usage limits	Describes the limited use of an object Usage is limited only operations to protect information (e.g. encryption ), operations to process protected information (e.g. decryption ) can be used indefinitely Contains unit (e.g. bytes to be encrypted ), current counter and total number of units allowed
State	Current status of the object Can only be changed by the server
Initial date	Time and date of creation / registration of the object
Activation Date	Activation time and date Object may be used for protective operations ( decryption or unwrapping) from the activation date
Process Start Date	Time and date from when the object may be used for processing encrypted information Must not be earlier than the activation time
Protect Stop Date	Time and date from when an object may no longer be used for protective operations ( encryption or wrapping) Must not be later than the deactivation time
Deactivation date	Time and date of deactivation
Destroy Date	Time and date the object was deleted
Compromise Occurrence Date	Time and date of when the object as a compromised applies
Compromise date	Time and date of the change in the Compromised State
Revocation Reason	Reason why an object is canceled
Archive Date	Time and date when the object was archived
Object Group	Name of an object group
link	Relationships between the objects ( private key - public key, public key - certificate , etc.) Multiple links per object possible
Application Specific Information	Additional, application-specific information about an object
Contact information	Contact information (people / devices responsible for an object)
Last change date	The time and date of the last change
Custom attributes	Provider-specific attribute Client or server side

Operations

A distinction is made between the operations by whom they are initiated. Most of them are client-to-server operations. In addition, there are few server-to-client operations. The KMIP specification describes which information a request and the corresponding response contain. The operations and their most important properties are listed in the following subsections. The division is made according to the purpose of use.

Client-to-server operations

A client can support a subset or all of the operations. If he wants to send several operations to the server at the same time, these can be combined in one message to form a batch .

The table below contains the operations that create a new object or update the content of an existing object. The KLMS can issue certificates itself or request certification from an external service ( certification authority ) .

surgery	description
Create	Create a symmetric key Request contains specifying attributes and / or templates
Create key pair	Creating a key pair with a private and public key Request contains specifying attributes and / or templates Automatic creation of a link attribute that connects the two new objects
register	Registration of an object passed by the client The request contains at least the attributes Cryptographic Algorithm, Cryptographic Length and Cryptographic Usage Mask
Re-key	Creating a symmetric key that replaces an existing key Attributes are taken from the existing key ( cryptographic algorithm, cryptographic length, etc.) or set anew ( initial date, unique identifier, etc.) Automatic creation of a link attribute that connects the old with the new key
Derive Key	Derive symmetric key / secret data from key / secret data The object to be derived must be known to the KLMS The derivative key bit in the cryptographic usage mask must be set Automatic creation of a link attribute that connects the original object with the derived object
Certify	Create a certificate for a public key Automatic creation of a link attribute that connects the certificate with the public key
Re-certify	Renewal of a certificate Automatic creation of a link attribute that connects the old and the new certificate

Operations that are needed to find and retrieve objects and to check their usage are listed in the next table.

surgery	description
Locate	Find an object that is described by one or more attributes Unsuccessful search results in an empty answer Successful search results in an answer with one or more unique identifiers
Check	Check the use of the object for a specific application If granted permission application with the identifier Unique answered In the event of unauthorized use, the attributes responsible for the failure of the request are sent back
Get	Get an object Selection of the object with the unique identifier

The following table shows the operations that relate to the attributes of objects. The desired object is selected with the unique identifier and the attribute is selected with the attribute name.

surgery	description
Get Attributes	Query of certain attributes of an object
Get Attribute List	Query of all attributes of an object
Add attributes	Creating a new attribute for an existing object Several new attributes can be combined into a batch.
Modify attributes	Change of an attribute
Delete attribute	Deleting an attribute

Operations, which are listed in the next table, deal with the use of objects. As mentioned above, the object is selected by specifying the unique identifier. Some of the following operations may only be requested by certain clients (for example, the administrator or the creator of an object). The identity of these clients must be verified by means of authentication.

surgery	description
Obtain lease	Extension of the service life
Get Usage Allocation	Allocation of usable units for protective functions (see Usage Limits )
Activate	Activation of an object Change of state from pre-active to active
Revoke	Cancellation of an object Revocation Reason contains the reason for the cancellation Depending on the reason, the status changes to Compromised or Deactivated
Destroy	Deleting a key or a template Objects in the pre-active or deactivated state are deleted immediately Objects in the Active state are first deactivated
Archives	Archiving an object
Recover	Restoring an archived object
Validate	Confirmation of the validity of a certificate chain (certificate chain) Request may Certificates and unique identifiers contained

The next table describes the asynchronous operations as well as an operation to poll the server. Operations are said to be asynchronous if the server does not respond immediately. The client can poll to receive the response at a later time. This approach is chosen when operations require a certain processing time (e.g. restoring an object).

surgery	description
Query	Query of server-specific properties The Query Operations option lists the operations supported by the server The "Query Objects" option lists the object types supported by the server
Cancel	Cancel an asynchronous operation The server's response contains the result (aborted, abort not possible, operation completed before abort, failed, not available)
Poll	Asynchronous operation query For current operation status is pending (pending) returned When the operation is completed, the result of the operation is returned

Server-to-client operations

For certain processes it makes sense for a KLM server to initiate communication. The server sends the client a request (request message). The client replies with a response message. When using these operations, clients must log on to the server. The type of login is not specified in the protocol . However, authentication is expected to take place to prevent a man-in-the-middle attack .

surgery	description
Notify	Notification of events that have led to changes in attributes Object with identifier Unique described Notification contains list of changed attributes
Put	Transmission of objects to the client New: new object is transmitted Replace: Object replaces an existing object (e.g. new certificate)

Message format

A message always consists of a header , followed by one or more stacked batch objects and optional message extensions.

Structure of a KMIP request message

Structure of a KMIP response message

A distinction is made between two message types in the header: request and response. The protocol version and the batch count are specified in both headers . The batch count indicates how many operations are requested with this message. There is also additional data, depending on the type. A batch object specifies the desired operation and contains all the attributes required for it. The dotted attributes in the following figures are optional.

Tag-Type-Length-Value (TTLV) coding is used to guarantee simple processing (see figure).

Tag : Identification of the following information of the TTLV segment, coded as a six-digit hexadecimal number , whereby this always starts with 42 ("42XXXX")
Type : Type of the following information (Structure, Integer, Long Integer, Big Integer, Enumeration, Boolean, Text String, Byte String, Date-Time, Interval)
Length : Length of the following information in bytes
Value : The actual value or core of the TTLV segment (coded differently depending on the data type)

Structures are used to create nested content. Further TTLV segments can occur in the value part of a structure. The number of bytes of all elements contained in the structure is then specified as the length of the structure .

Example of message encoding

A message from the KMIP client to the KLMS server to create a symmetric key can look like this, represented as a byte stream in hexadecimal form . Broken down according to the TTLV scheme and interpreted according to the KMIP specification, this message is a request from the client to the server . The client requires a symmetric key for encryption and decryption with the AES algorithm. The key should have a length of 128 bits .

Use cases

Use cases were developed in addition to the specification . The processes of various scenarios and the messages to be exchanged were described. On the one hand, the use cases can be used to understand the flow of communication. On the other hand, an implementation of the KMIP that runs on a KLMS can be tested with it. The use cases only contain realistic applications; they are not suitable for testing possible attacks on the system.

Open source implementation KMIP4J

While some software companies have been working with proprietary implementations of KMIP for a while , there was no freely available software. With KMIP4J there is now an open source implementation of KMIP 1.0. This is available on SourceForge .

Web links

oasis-open.org / ... - Official website of the committee for the KMIP standard
wiki.oasis-open.org / ... - reference implementations
Key Management Interoperability Protocol Specification Version 1.0 (PDF; 2.0 MB)
Key Management Interoperability Protocol Use Cases Version 1.0 ( MS Word ; 1.0 MB)
Key Management Interoperability Protocol Usage Guide Version 1.0 ( MS Word ; 453 kB)
Key Management Interoperability Protocol Profiles Version 1.0 (PDF; 197 kB)
White Paper: Key Management Interoperability Protocol (PDF; 1.1 MB)
KMIP4J on Sourceforge

Individual evidence

↑ http://xml.coverpages.org/KMIP/KMIP-WhitePaper.pdf
↑ Key Management Interoperability Protocol Specification Version 1.0 - OASIS Standard
↑ http://docs.oasis-open.org/kmip/spec/v1.0/cs01/kmip-spec-1.0-cs-01.pdf
↑ Key Management Interoperability Protocol Profiles Version 1.0 Committee Specification , June 15, 2010, (PDF)
↑ Kurose and Ross: Computer Networks - The Top-Down Approach. Pearson Deutschland GmbH, Munich 2012.
↑ http://docs.oasis-open.org/kmip/usecases/v1.0/cs01/kmip-usecases-1.0-cs-01.doc

[1] ttp://xml.coverpages.org/KMIP/KMIP-WhitePaper.pdf

[2] Key Management Interoperability Protocol Specification Version 1.0 - OASIS Standard

[3] ttp://docs.oasis-open.org/kmip/spec/v1.0/cs01/kmip-spec-1.0-cs-01.pdf

[4] Key Management Interoperability Protocol Profiles Version 1.0 Committee Specification , June 15, 2010, (PDF)

[5] Kurose and Ross: Computer Networks - The Top-Down Approach. Pearson Deutschland GmbH, Munich 2012.

[6] ttp://docs.oasis-open.org/kmip/usecases/v1.0/cs01/kmip-usecases-1.0-cs-01.doc