The latest generation of the main hypervisors has shown, among other things, a renewed and increased focus on security, with the most visible feature being VM encryption. It’s amazing to see how both VMware vSphere 6.5 and Microsoft Hyper-V 2016, both released in the same year, introduced this feature at the same time. But it’s less of a surprise if you think about all the security issues that IT admins and users are facing lately, with things like ransomware, cryptolocker and other threads.
In this first of a series of posts, we’ll look at the different solutions and some deep dive into the used technologies, and how operations like backups are impacted. In this first post, let’s talk about KMIP.
What is KMIP
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.
KMIP stands for Key Management Interoperability Protocol, 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). To better undertand how it does work, let me copy here some phrases from the dedicated wikipedia page.
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.
The types of managed object that are managed by KMIP include:
– Symmetric Keys
– Public and Private Keys
– Certificates and PGP Keys
– Split Keys
– Secret Data (passwords)
– Opaque Data for client and server defined extensions
Also worth to be noted, that TLS is used for link level security in communication between clients and servers.
Why it’s important
KMIP is not an encryption standard, but rather a interoperability and transport standard. With it, clients and servers coming from different vendors can securely exchange encryption keys:
Thanks to KMIP, a company can now leverage a single central key management server, using one of the many solutions already available with support for the KMIP standard, and then connect all the different clients to it. This dramatically reduces the complexity of the key lifecycle solution, that is already complicated by itself.
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.