In my previous blog, I recommended the use of OASIS KMIP as the go-to standard for delivering interoperability across enterprises (especially larger enterprises) for encryption key management purposes. This is even more critical where there are multiple vendor solutions in the mix. The use of KMIP goes much further than that simple reasoning (I’ll go into that in future articles) but let’s start with some quick foundation knowledge via a quick dive into the standard itself.
OASIS KMIP (Key Management Interoperability Protocol) is a specification that defines a standardized protocol for communication between Key Management Systems (KMS) or and consumers of cryptographic objects. KMIP refers to these as “servers” (KMS) and “clients” (the endpoints/consumers). KMIP provides a standard mechanism for clients to request and manage cryptographic keys, certificates, and other cryptographic objects. KMIP’s primary focus is to enable different KMS systems to interoperate, facilitating the secure exchange and management of cryptographic keys and objects across multiple platforms and applications. The KMIP specification includes protocols for secure key creation, storage, retrieval, deletion, and management operations, as well as standard definitions for cryptographic objects and their attributes.
The wire protocol itself defines the individual packets exchanged in a TTLV format (Tag, Type, Length Value) in a challenge/response sequence across a mutually authenticated TLS connection. Whilst some argue that KMIP can be a little verbose, it is this verbosity that delivers comprehensive capability to the standard. The tags, enumeration and formatting details of the KMIP messages are well defined in discrete chapters of the specification so I’ll leave that for future articles.
Focussing on the fundamentals, a large portion of the KMIP specification deals with describing the content within the message format. At a high level, KMIP describes its content as an “Object”, an “Operation” or an “Attribute”. Naturally the specification dives a little deeper in each of those areas but in essence a KMIP exchange will encode an Operation to be applied to an Object, involving some descriptive metadata (or Attributes) related to that Object. There are also specific Operations to manipulate the Attributes of a specific Object.
Objects
KMIP explicitly defines 8 Object types:
- Certificate;
- Certificate Request;
- Opaque Object;
- PGP Key;
- Private Key;
- Public Key;
- Secret Data;
- Split Key; and
- Symmetric Key.
Whilst this is the list of Objects that can be managed in a KMIP KMS, a KMIP KMS may be used to manage a wide variety of items used in common cybersecurity deployments such as biometrics, passwords and other credentials by registering/storing the item as either an “Opaque Object” (an Object that the KMS is unable to process or interpret) or as “Secret Data” (a cryptographic Object e.g. password that is not a defined KMIP Object). In most cases the fact that the KMS cannot interpret the value of these Objects does not affect the KMS’s ability to manage the Object, its Attributes and lifecycle. This makes the job of endpoint security solution developers much easier as any enterprise performing data at rest encryption, will likely have a KMIP KMS already deployed in the enterprise, meaning that applications can store and manage almost any sensitive item using the KMIP protocol.
Operations
As at KMIP v2.1, there are 57 client to server Operations with a handful of Operations classified as server-to-client Operations (I’ll leave these for another article). Whilst not a detailed list, the Operations cover:
- Requests for a server to create or register a new Object as well as Operations to trigger the standard NIST SP800-57 lifecycle transitions;
- Cryptographic Operations such as Sign, Hash, MAC, Derive and obtaining random strings;
- Operations to add, modify or remove Attributes attached to an Object;
- Discovery Operations to provide seamless interoperability between implementations at different KMIP versions (most commercially available servers support a number of previous KMIP versions for maximum interoperability);
- Operations for locating an Object based on its Attributes;
- Query Operations when an implementation may need to access Attributes without accessing the Object itself; and
- Import and export Operations to allow backup and/or migration of part/all of the keystore.
Attributes
The primary difference between key management (via KMIP) and key vaulting is the comprehensive array of Attributes that may be stored with a given Object. KMIP v2.1 contains 63 Attributes, some with defined data structures to represent a wide array of information about a given Object.
Primary amongst these Attributes is mandatory Universally Unique Identifier (UUID) which is issued by the KMS, is unique withing the KMS and assigned at the time of the Object’s creation or registration. The UUID is immutable, such that if a further key is derived, or versioned, the new key will obtain a new UUID with the original key retaining it’s UUID. All Operations on a given Object (or its Attributes) must use the UUID as the Object reference. Other Attributes include:
- Dates for lifecycle transitions;
- Cryptographic information;
- Quantum safe indicator and associated protection date;
- Key rotation information;
- Links and references to other Objects; and
- Object name (a unique, client assigned identifier).
This list is a very high-level categorization of the available Attributes but it does not take much imagination to recognize the tremendous potential of a well implemented KMIP system. Not only will such a system allow SecOps to proactively manage enterprises security Objects, it will also enable the identification and mitigation of risks as they arise, something that will become more and more critical in a post-quantum cryptography world.
TLDR
Hopefully this summary proves useful to some. It covered:
- KMIP Clients and Servers
- Assumes a TLS session for exchange of TTLV packets in challenge/response format
- Objects – usually cryptographic Objects like encryption keys, certs etc but can also manage almost any sensitive item
- Operations – actually doing stuff with the Object (create/store/retrieve/update)
- Attributes – the descriptive metadata associated with each Object.