Key Management Interoperability Protocol

The Key Management Interoperability Protocol (KMIP) is an extensible communication protocol that defines message formats for the manipulation of cryptographic keys on a key management server. This facilitates data encryption by simplifying encryption key management. Keys may be created on a server and then retrieved, possibly wrapped by other keys. Both symmetric and asymmetric keys are supported, including the ability to sign certificates. KMIP also allows for clients to ask a server to encrypt or decrypt data, without needing direct access to the key.

Participants in the OASIS 2017 interop at the 2017 RSA conference.

The KMIP standard was first released in 2010. Clients and servers are commercially available from multiple vendors. The KMIP standard effort is governed by the OASIS standards body. Technical details can also be found on the official KMIP page and wiki.

Description

A KMIP server stores and controls Managed Objects such as symmetric and asymmetric keys, certificates, and user defined objects. Clients then use the protocol to access these objects subject to a security model that is implemented by the servers. Operations are provided to create, locate, retrieve and update managed objects.

Each managed object has an immutable Value such as a key block that contains a cryptographic key. They also contain mutable Attributes which can be used to store meta data about the keys. Some attributes are derived directly from the Value, such as the cryptographic algorithm and length of a key. Other attributes are defined in the specification for the management of objects such as the Application Specific Identifier which is usually derived from tape identification data. Additional identifiers can be defined by the server or client as need by the application.

Each object is identified by a unique and immutable object identifier that is generated by the server and is used to Get object values. Managed objects may also be given a number of mutable but globally unique Name attribute which can be used to Locate objects.

Objects

The types of managed objects that are managed by KMIP include:

  • Symmetric Keys used for algorithms such as AES.
  • Public and Private Keys used for asymmetric algorithms such as RSA and ECDH. Separate objects are used to store the public and private key, so that a user may have permission to access one but not the other. Related objects usually contain Link attributes that contain the other object's unique identifier.
  • Certificates and PGP Keys.
  • Split Keys, with each split being a distinct object that can be managed independently from the other splits.
  • Secret Data, such as passwords.
  • Opaque Data for client and server defined extensions.
  • Certificate Signing Requests.

Operations

The operations provided by KMIP include:

  • Create, which creates a new managed object such as a symmetric key, and return the identifier.
  • Create Key Pair, which creates which creates two objects that represent asymmetric keys.
  • Get, which retrieves an object's value given its unique identifier. The returned value may be wrapped (encrypted) with another key that is on the server for additional security.
  • Register, which stores an externally generated key value.
  • Add Attributes, Get Attributes, Modify Attributes and Set Attribute. These can be used to manipulate mutable attributes of a managed object.
  • Locate, which retrieves a list of objects based on a predicates.
  • Re-Key, which creates a new key that can replace an existing key. There are also attributes that can be used to have the server automatically rotate keys after a given period or number of uses. The Name is moved to the new key and is normally used to retrieve a key for protection operations such as encrypt and sign. The old key can also be retrieved using the Unique Identifier for process operations such as decryption and signature verification.
  • (Re-)Certify which certifies a certificate.
  • Split and Join n of m keys.
  • Encrypt, Decrypt, MAC etc. Cryptographic operations performed on the key management server. The key itself could be marked as not Extractable in which case its value never leaves the server.
  • Export and Import keys to other KMIP servers.
  • Operations to implement the NIST key life cycle.

Key Life Cycle

Each key has a cryptographic state as defined by the National Institute of Standards and Technology (NIST). Keys are created in an Initial state, but must be Activated before they can be used. They may then be Deactivated and eventually Destroyed. The key may also be marked as Compromised.

Operations are provided that manipulate the state in conformance with the NIST life cycle guidelines. The state of a key may be interrogated using the State attribute or the attributes that record dates of each transformation such as Activation Date. Dates can be specified into the future so that keys automatically become unavailable for specified operations as they expire.

Message Structure

KMIP is a stateless protocol in which messages are sent from a client to a server and then the client normally waits for a reply. Each request may contain many operations which enables the protocol to efficiently handle large numbers of keys. There are also advanced features to process requests asynchronously.

The KMIP protocol specifies several different types of encodings. The main one is a type-length-value encoding of messages, called TTLV (tag, type, length, value). Nested TTLV structures allow for encoding of complex, multi-operation messages in a single binary message.

There are also well defined XML and JSON encodings of the protocol for environments where binary is not appropriate. A very compact CBOR encoding is also provided for applications that require it.

All of these protocols are expected to be transmitted using TLS protocol in order to ensure integrity and security. However, it is also possible to register and retrieve keys that are wrapped (encrypted) using another key on the server, which provides and additional level of security.

System Management

KMIP provides standardized mechanisms to manage a KMIP server by suitably authorized administrative clients using System Objects.

User objects can be created and authorized to perform specific operations on specific managed objects. Both Managed Objects and Users can be assigned to groups, and those groups can form a hierarchy which facilitates efficient management of complex operating environments.

KMIP also provides a provisioning system that facilitates providing end points with credentials using simple one time passwords.

Default values of attributes can be provided, so that simple clients need not specify cryptographic and other parameters. For example, an administrative user might specify that all "SecretAgent" keys should be 192 bit AES keys with CBC block chaining. A client then only needs to specify that they wish to create a "SecretAgent" key to have those defaults provided. It is also possible to enforce constraints on key parameters that implement security policy.

KMIP profiles

KMIP also defines a set of profiles, which are subsets of the KMIP specification showing common usage for a particular context. A particular KMIP implementation is said to be conformant to a profile when it fulfills all the requirements set forth in a profile specification document. OASIS has put forth various profiles describing the requirements for compliance towards storage arrays[1] and tape libraries,[2] but any organization can create a profile.

Relationship to PKCS#11

PKCS#11 is an C API used to control a hardware security module. PKCS#11 provides cryptographic operations to encrypt and decrypt, as well as operations for simple key management. There is considerable amount of overlap between the PKCS#11 API and the KMIP protocol.

The two standards were originally developed independently. PKCS#11 was created by RSA Security, but the standard is now also governed by an OASIS technical committee. It is the stated objective of both the PKCS#11 and KMIP committees to align the standards where practical. For example, the PKCS#11 Sensitive and Extractable attributes are being added to KMIP version 1.4. Many of the same people are on the technical committees of both KMIP and PKCS#11.

KMIP 2.0 provides a standardized mechanism to transport PKCS#11 messages from clients to servers. This can be used to target different PKCS#11 implementations without the need to recompile the programs that use it.

KMIP implementations

The OASIS KMIP Technical Committee maintains a list of known KMIP implementations, which can be found on the OASIS website. As of March 2017, there are 28 implementations and 61 KMIP products in this list.

Interoperability between implementations

The KMIP standard is defined using a formal specification document, testcases, and profiles put forth by the OASIS KMIP technical committee. These documents are publicly available on the OASIS website.

Interop booths at the 2015 RSA conference. Each vendor interoperates with each other vendor.

Vendors demonstrate interoperability during a process organized by the OASIS KMIP technical committee in the months before each RSA security conference. These demonstrations are informally known as interops. KMIP interops have been held every year since 2010. The following chart shows the number of individual tests performed by each client and server vendor combination since 2012.

Example

The following shows the XML encoding of a request to Locate a key named "MyKeyName" and return its value wrapped in a different key with ID "c6d14516-4d38-0644-b810-1913b9aef4da". (TTLV is a more common wire protocol, but XML is more human readable.)

<RequestMessage>
  <RequestHeader>
    <ProtocolVersion>
      <ProtocolVersionMajor type="Integer" value="3"/>
      <ProtocolVersionMinor type="Integer" value="0"/>
    </ProtocolVersion>
  </RequestHeader>
  <BatchItem>
    <Operation type="Enumeration" value="Locate"/>
    <UniqueBatchItemID type="ByteString" value="1"/>
    <RequestPayload>
      <Attributes>
        <Name type="TextString" value="MyKeyName"/>
      </Attributes>
    </RequestPayload>
  </BatchItem>
  <BatchItem>
    <Operation type="Enumeration" value="Get"/>
    <UniqueBatchItemID type="ByteString" value="2"/>
    <RequestPayload>
      <KeyWrappingSpecification>
        <WrappingMethod type="Enumeration" value="Encrypt"/>
        <EncryptionKeyInformation>
          <UniqueIdentifier type="Integer" value="c6d14516-4d38-0644-b810-1913b9aef4da"/>
        </EncryptionKeyInformation>
      </KeyWrappingSpecification>
    </RequestPayload>
  </BatchItem>
</RequestMessage>

Documentation

Documentation is freely available from the OASIS website. This includes the formal technical specification and a usage guide to assist people that are unfamiliar with the specification.

A substantial library of test cases is also provided. These are used to test the interoperability of clients and servers, but they also provide concrete examples of the usage of each standard KMIP feature.

Version history

Summary of KMIP versions and features.
Version Committee Draft Main Features
1.0 Oct 2010Initial version
1.1Jan 2013
1.2Jun 2014 Cryptographic Operations (Encrypt, Decrypt, Sign etc.). Introduction of Profiles, including Application Identifiers for tape libraries.
1.32015 Streaming Cryptographic Operations; Client Registration; Locate offset/Limit; Deprecate Templates; RNG queries;
1.42016 Better asynchronous operations; Import/export of keys to other servers; Support of PKCS #12; Standardized key wrapping; Certify Attributes; Client & Server Correlation Values; Descriptive Attributes; AEAD support; AES-XTS support; Create Secret Data; RSA PSS Support; Many extensions to Query.
2.02018 Removal of deprecated items; Efficient representation of attributes; Replacement of "x-" convention for custom attributes; Client Log operation; Date Time resolution 1 microsecond; Locate Destroyed; Better Error Handling and Result Reasons; ; Improved client Provisioning; new CSR object; Removal of Attribute Index; Support for tokenization; NIST Key Type attribute; Fixed length Unique Identifiers; Several new attributes and query extensions; Delegated Logins; Hashed Passwords; Multiple Unique ID placeholders; ReEncrypt support using data references; Set Attribute operation; PKCS #11 encapsulation.
2.12019 Ping; Process and query asynchronous requests; Standardize server side key rotation; Set and query attribute defaults; Set and query constraints on attributes; [3]
3.02020 Add an explicit concept of KMIP users, modeled as System Objects; Lifecycle improvements to references to other objects using names as well as unique identifiers; Formalize object groups and hierarchies; Enhancements to Locate operation; Obliterate administrative operation; New CBOR encoding option.[4]

See also

References

    • "OASIS KMIP Technical Committee".
    This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.