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.
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 [1] and kmip wiki. [2]
A KMIP server stores and controls Managed Objects like symmetric and asymmetric keys, certificates, and user defined objects. Clients then use the protocol for accessing 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 comprises an immutable Value like a key-block containing a cryptographic-key. These objects comprise mutable Attributes which can be used for storing metadata about their keys. Some attributes are derived directly from the Value, like the cryptographic-algorithm and key-length. Other attributes are defined in the specification for the management of objects like the Application-Specific Identifier which is usually derived from tape-identification data. Additional identifiers can be defined by the server or client per application need.
Each object is identified by a unique and immutable object-identifier generated by the server and is used for getting object-values. Managed-objects may also be given a number of mutable yet globally unique Name attribute which can be used for Locating objects.
The types of managed-objects being managed by KMIP include:
The operations provided by KMIP include:
Each key has a cryptographic state defined by the National Institute of Standards and Technology (NIST). Keys are created in an Initial state, and must be Activated before they can be used. Keys may then be Deactivated and eventually Destroyed. A key may also be marked being Compromised.
Operations are provided for manipulating Key-state in conformance with the NIST life-cycle guidelines. A Key-state 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 thus keys automatically become unavailable for specified operations when they expire.
KMIP is a stateless protocol in which messages are sent from a client to a server and then the client normally awaits on a reply. Each request may contain many operations thus enables the protocol to efficiently handle large numbers of keys. There are also advanced features for processing 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 an additional level of security.
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 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 [3] and tape libraries, [4] but any organization can create a profile.
PKCS#11 is a 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.
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.
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.
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.
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><ProtocolVersionMajortype="Integer"value="3"/><ProtocolVersionMinortype="Integer"value="0"/></ProtocolVersion></RequestHeader><BatchItem><Operationtype="Enumeration"value="Locate"/><UniqueBatchItemIDtype="ByteString"value="1"/><RequestPayload><Attributes><Nametype="TextString"value="MyKeyName"/></Attributes></RequestPayload></BatchItem><BatchItem><Operationtype="Enumeration"value="Get"/><UniqueBatchItemIDtype="ByteString"value="2"/><RequestPayload><KeyWrappingSpecification><WrappingMethodtype="Enumeration"value="Encrypt"/><EncryptionKeyInformation><UniqueIdentifiertype="Integer"value="c6d14516-4d38-0644-b810-1913b9aef4da"/></EncryptionKeyInformation></KeyWrappingSpecification></RequestPayload></BatchItem></RequestMessage>
Documentation is freely available from the OASIS website. [5] 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 | Committee Draft | Main Features |
---|---|---|
1.0 | Oct 2010 | Initial version |
1.1 | Jan 2013 | |
1.2 | Jun 2014 | Cryptographic Operations (Encrypt, Decrypt, Sign etc.). Introduction of Profiles, including Application Identifiers for tape libraries. |
1.3 | 2015 | Streaming Cryptographic Operations; Client Registration; Locate offset/Limit; Deprecate Templates; RNG queries; |
1.4 | 2016 | 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.0 | 2018 | 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.1 | 2019 | Ping; Process and query asynchronous requests; Standardize server side key rotation; Set and query attribute defaults; Set and query constraints on attributes; [6] |
3.0 | 2021 | 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; Obliterate administrative operation; [7] |
The Lightweight Directory Access Protocol is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network. As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number.
Simple Network Management Protocol (SNMP) is an Internet Standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. Devices that typically support SNMP include cable modems, routers, switches, servers, workstations, printers, and more.
The Organization for the Advancement of Structured Information Standards is a nonprofit consortium that works on the development, convergence, and adoption of open standards for cybersecurity, blockchain, Internet of things (IoT), emergency management, cloud computing, legal data exchange, energy, content technologies, and other areas.
Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.
Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized authentication, authorization, and accounting (AAA) management for users who connect and use a network service. RADIUS was developed by Livingston Enterprises in 1991 as an access server authentication and accounting protocol. It was later brought into IEEE 802 and IETF standards.
In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.
Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols. The middleware creates a distributed communications layer that insulates the application developer from the details of the various operating systems and network interfaces. APIs that extend across diverse platforms and networks are typically provided by MOM.
S/MIME is a standard for public-key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFC 8551. It was originally developed by RSA Data Security, and the original specification used the IETF MIME specification with the de facto industry standard PKCS #7 secure message format. Change control to S/MIME has since been vested in the IETF, and the specification is now layered on Cryptographic Message Syntax (CMS), an IETF specification that is identical in most respects with PKCS #7. S/MIME functionality is built into the majority of modern email software and interoperates between them. Since it is built on CMS, MIME can also hold an advanced digital signature.
Key management refers to management of cryptographic keys in a cryptosystem. This includes dealing with the generation, exchange, storage, use, crypto-shredding (destruction) and replacement of keys. It includes cryptographic protocol design, key servers, user procedures, and other relevant protocols.
Web Services Security is an extension to SOAP to apply security to Web services. It is a member of the Web service specifications and was published by OASIS.
IEEE 802.11i-2004, or 802.11i for short, is an amendment to the original IEEE 802.11, implemented as Wi-Fi Protected Access II (WPA2). The draft standard was ratified on 24 June 2004. This standard specifies security mechanisms for wireless networks, replacing the short Authentication and privacy clause of the original standard with a detailed Security clause. In the process, the amendment deprecated broken Wired Equivalent Privacy (WEP), while it was later incorporated into the published IEEE 802.11-2007 standard.
Security Assertion Markup Language is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is an XML-based markup language for security assertions. SAML is also:
JSON-RPC is a remote procedure call (RPC) protocol encoded in JSON. It is similar to the XML-RPC protocol, defining only a few data types and commands. JSON-RPC allows for notifications and for multiple calls to be sent to the server which may be answered asynchronously.
Real-Time Messaging Protocol (RTMP) is a communication protocol for streaming audio, video, and data over the Internet. Originally developed as a proprietary protocol by Macromedia for streaming between Flash Player and the Flash Communication Server, Adobe has released an incomplete version of the specification of the protocol for public use.
Network Security Services (NSS) is a collection of cryptographic computer libraries designed to support cross-platform development of security-enabled client and server applications with optional support for hardware TLS/SSL acceleration on the server side and hardware smart cards on the client side. NSS provides a complete open-source implementation of cryptographic libraries supporting Transport Layer Security (TLS) / Secure Sockets Layer (SSL) and S/MIME. NSS releases prior to version 3.14 are tri-licensed under the Mozilla Public License 1.1, the GNU General Public License, and the GNU Lesser General Public License. Since release 3.14, NSS releases are licensed under GPL-compatible Mozilla Public License 2.0.
The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing, reliability and security.
In cryptography, PKCS #11 is one of the Public-Key Cryptography Standards, and also refers to the programming interface to create and manipulate cryptographic tokens.
An information card is a personal digital identity that people can use online, and the key component of an identity metasystem. Visually, each i-card has a card-shaped picture and a card name associated with it that enable people to organize their digital identities and to easily select one they want to use for any given interaction. The information card metaphor has been implemented by identity selectors like Windows CardSpace, DigitalMe or Higgins Identity Selector.
Distributed Data Management Architecture (DDM) is IBM's open, published software architecture for creating, managing and accessing data on a remote computer. DDM was initially designed to support record-oriented files; it was extended to support hierarchical directories, stream-oriented files, queues, and system command processing; it was further extended to be the base of IBM's Distributed Relational Database Architecture (DRDA); and finally, it was extended to support data description and conversion. Defined in the period from 1980 to 1993, DDM specifies necessary components, messages, and protocols, all based on the principles of object-orientation. DDM is not, in itself, a piece of software; the implementation of DDM takes the form of client and server products. As an open architecture, products can implement subsets of DDM architecture and products can extend DDM to meet additional requirements. Taken together, DDM products implement a distributed file system.
The SAML metadata standard belongs to the family of XML-based standards known as the Security Assertion Markup Language (SAML) published by OASIS in 2005. A SAML metadata document describes a SAML deployment such as a SAML identity provider or a SAML service provider. Deployments share metadata to establish a baseline of trust and interoperability.