To implement some encryption solutions (like VM encryption, backup encryption, storage encryption) you need to manage symmetric keys in a secure way.
Key management has always been solved with proprietary solutions. Each vendor have offered in the past their own key management server/client combination, but as the complexity of datacenters increased, this designed has shown its limits. If you have multiple components, all in need of security keys, why you would need to run multiple key management solutions?
But in order to have a common solution, you first would need a protocol to let all the different components and vendor talk to each other, and this is what KMIP is about.
Key Management Interoperability Protocol (KMIP), and its 1.0 specification was first introduced in 2010. Its development and management is driven by OASIS (Organization for the Advancement of Structured Information Standards).
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 and user defined objects.
KMIP also allows for clients to ask a server to encrypt or decrypt data, without needing direct access to the key. 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.
The types of managed object that are managed by KMIP include:
- Symmetric-Keys used for algorithms like AES.
- Public and Private Keys used for asymmetric-algorithms like RSA, DSA and ECDH. Separate objects are used for storing the public and private key, thus a user may have permission to access one but not the other. Related objects usually contain Link attributes containing 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.
Also worth to be noted, that TLS is used for link level security in communication between clients and servers.
The operations provided by KMIP include:
- Create: creating a new managed object such as a symmetric key, and return the identifier.
- Create Key Pair: creating two objects that represent asymmetric keys.
- Get: retrieving 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: storing 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: retrieving a list of objects based on a predicates.
- Re-Key, Re-Key-Key-Pair: creating 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 – certifies a certificate.
- Split and Join N of M keys.
- Encrypt, Decrypt, MAC etc.: Cryptographic operations performed on the key management server. A key itself can be marked being not-Extractable, in which case its value never leaves the server.
- Export, Import: Move keys to and from other KMIP servers.
- Activate, Deactivate etc.: Operations to implement the NIST key life cycle.
The OASIS KMIP Technical Committee maintains a list of known KMIP implementations, which can be found on the OASIS website. As of December 2024, there are 35 implementations and 91 KMIP products in this list.
The VMware implementation
As you can read in this excellent article from Mike Foley, VMware has chosen to adhere to KMIP for its new security features introduced in vSphere 6.5. Specifically, VMware is using the KMIP version 1.1 protocol, and the new vCenter 6.5 acts as a KMIP client. Keys are not persistent in vCenter and are retrieved when needed from the registered KMIP Server. VMware itself doesn’t offer any KMIP server solution, so customers have to go out and buy one if they don’t have it yet. Be careful with the open source PYKMIP project: as much as it is really interesting to have a free KMIP server to run quick tests, as perfectly explained by WIlliam Lam in this article, this free server has NO KEY PERSISTENCE: upon reboot of the service every key is removed from memory, and they are not store anywhere else, so if you have encrypted a VM with one of those keys, you will never be able to open it again. There are many commercial solutions available on the market, and seems that VMware also is working on a more usable solution.
The good and the bad? For sure, one advantage of the design choice of VMware is that encryption is completely agnostic from the Guest OS. There is no compatibility list of the supported operating systems, because encryption happens at the hypervisor layer and is totally managed by ESXi. The Guest OS has no knowledge that it is running on encrypted disks. This allows for encryption services available to any OS, but it’s also the main limit of the design: every administrator with the proper rights can extract the vmdk and store it somewhere else in an un-encrypted state, like during a backup operation. This may or not may be a limit depending on the security needs of a customer, but surely the design choice of VMware was to put the focus on the hypervisor-level security, make it as transparent and possible, and move the security discussion to “who” has access to the disks. Other solutions like Microsoft Shielded VMs have chosen a different approach, but this is for another blog post. Another interesting advantage is that Encryption can be assigned as a storage policy to VMs via the SPBM framework, so admins can programmatically encrypt groups of VMs, based for example on the security level that is required for a given VM, and be sure that the encryption is always enforced.
Finally, performance. This should not be a problem as VM Encryption in vSphere 6.5 uses the AES-NI hardware acceleration offered by Intel in its modern CPUs.
See also:
