VMWare vSphere 6.7 Key Management with HyTrust KeyControl

Recently I’ve changed jobs and joined a smaller company in the vicinity of my home. Still doing security stuff of course, but now with a focus on infrastructure again. As I soon discovered the company uses VMWare for it’s virtualization, which is great but a change for me personally. Having been a Hyper-V user for as long as I can remember I needed to educate myself quickly, specially on the security part of the product.

One thing that I was missing in the former vSphere product was the absence of encryption for the VM guest when it comes to using a TPM chip. As of the latest and the greatest release this is now an optional piece of virtual hardware that you can add for Windows Server 2016 or Windows 10 X64 editions. Cool stuff!!!

As I found out the hard way it’s a bit of a daunting task at first. Looking back at Hyper-V it’s just selecting a checkbox and all the magic happens under the hood. For a lab situation that’s wonderful, but for production purposes, where you put all the secrets on one box, perhaps not so much. With VCenter you need to enable the “Enterprise” way of working before you can add a Virtual TPM chip to a guest. Needless to say you can create a similar setup in Hyper-V, but this way of working with VCenter kind of forces you to think bigger, which isn’t necessarily a bad thing. So, in this guide I’ll show you how to create that infrastructure you need to enable the virtual TPM chip so you can encrypt those disks that hold confidential data, or, as in my case, just mess around with BitLocker drive encryption.

VMWare utilizes a Key Management System (KMS) for the storage of high confidential keys, such as those generated in a virtual TMP. Look at it as a high secure server that stores the keys to the kingdom. To make use of those keys a trust needs to be established between the VCenter and the KMS machine. Once a Windows guest requests a TPM operation, the VCenter requests new keys to protect the TPM itself on behalf of the guest. That request is then honored by the KMS server.

To get started with the setup we’ll be focusing on one of the vendor, HyTrust. This vendor provides  a preconfigured OVA template with their product KeyControl for easy setup. Just follow these steps to create your KMS server.

First go to the following link and download the KeyControl OVA file.


Extract it when done and import the OVA into your VCenter. I’ll assume that you know how to do that. Midway of the OVA deployment you’ll be asked a couple of question, like configuration, hostname, IP address etc. As for the configuration I’ve selected “Demo”.


This is really just a minimal install that will allow you to test drive the product for a month. A trial license key is shipped with the product that includes access to all product features and allows you to configure up to two KeyControl nodes and to protect up to five virtual machines. The trial license is automatically activated when you configure the first KeyControl node. If you need to extend the trial, you can apply here:



Add the network settings and complete the setup.

Once the OVA is deployed, power it on and login to the console of the VM. The first question the setup asks is to create a password for the root user. Please note this is not the password that we’ll be using later on in this post!


Proceed to the next screen when you’re done.


As this is not a cluster setup, we can select the default here and continue.

On the final setup screen you can note the IP address that you’ve used during the setup. Logoff in the next screen and close the console session. We won’t be needing it for our lab setup.

Next thing we need to do is go to the web interface. Point your browser to the fqdn or IP address of the KeyControl server. You’ll be presented with a wizard that will take you through the final steps of the process. Click on the “login” on the top right.


Use secroot/secroot as the default login.

Accept the “End-User License Agreement” and create a new password. As for the email notifications I’ve selected the “Disable email notifications” options, click “Continue”. Same applies to “Automatic Vitals Reporting”, click “Save and Continue”.


In the HyTrust KeyControl web interface klink on the “KMIP” button on the top and set the “State” to “Enable“. Click “Apply” to enable the KMS functionality, click “Proceed” on the “Overwrite all existing KMIP Server settings?“ pop-up. Please note the port number configured on this page (“5696”). This is the default port that we’ll be using later on.

Next, click on “Client Certificates” – “Actions” – “Create Certificate”.


In the “Create a New Client Certificate” pop-up screen fill in a name and an expiration date. Please note that you should leave the password blank! If a password is added the wizard for importing it into VCenter will fail. I don’t necessarily agree with this way of working but that’s the way it works for now. Click “Create” to generate the certificate. Only thing left here is to download the certificate so we can import it into VCenter at a later stage.

Select the certificate and in the “Actions” menu select “Download Certificate”.


Save it on a secure location on your system. You can safely logoff from the KeyControl server as we won’t be needing it anymore for this demo.

Let’s move to our VCenter server. On the top node of your VCenter node select the name of your host and click “Configure” on the right.


On the configuration options below open de “More” node and select “Key management Server”. Click “Add” on the right. Fill in the data according to your infrastructure requirements.


For the cluster name I’ve chosen VKMS, it’s something that you can refer to later if you’re setting up a cluster. Click “Add”. If VCenter can make a successful connection to the VKMS host it will preset an overview of the certificate it will add to it’s configuration.


Click “Trust” to continue.

In the exercise above we’ve let our VCenter setup trust the VKMS server. All that remains is that we do the same for the VKMS server. You would expect to be logging into the VKMS again, but this can also be done from VCenter itself. That’s the reason we created the certificate in the beginning of this post. Select the VKMS host we just added.


The configuration window will open where we can select “Make KMS trust VCenter”. In the pop-up that appears we have to select a method how we’ll want to let our VKMS trust VCenter.


As we own the certificates we’ll use the third option “KMS Certificate and Private key”. Click “Next”.

Now here’s the trick that got me stuck for a while. In the “Upload KMS Credentials” page, the wizard asks for a KMS Certificate and private key. After a couple of attempts and doing a bit of reading, it appears that selecting the certificate we created twice does the trick.


Click the “Upload a file” and browse to the certificates we downloaded from the KeyControl server earlier. Select the certificate name we created earlier and select “Open”. Back in the wizard select “Establish trust”. On success everything will be set to green on the VCenter side.


And that’s really it!

All remains is creating a new virtual machine where you need to select: “Enable Windows Virtualization Based Security” on the “Select a Guest OS” page.


This will give you the option to add a Trusted Platform Module (TPM) chip at any time.

I hope that this blog post was helpful, and as always, feedback is appreciated.


Do you want to know a secret?

Do you want to know a secret? You probably do, question is, would you like it if anyone else knew your secret as well? I am guessing not. That is why, on the Internet, we use encryption for the data that we send and receive, just to make sure that someone else is not listening in on our conversation. Encryption is not only used when directly communicating with each other, it is also used for something we call “integrity”, a.k.a. “I want to make sure that I get what the other end is sending without anyone modifying it in transit”. So, use encryption anywhere!

The basis of encryption is that the parties that want to exchange information agree on a common secret. However, the challenge that they have is to exchange that secret without anyone else knowing it. And that’s where the fun begins. Let us take the following as an example.


Let’s suppose that Michael wants to send a confidential message to Rick without the ‘Evil dude” in the middle listening in. Obviously, they want to use encryption for that, but for this to work, they both need to agree on a secret that only they know. This secret needs to be transferred in such a way that only Michael and Rick know its content. So they need to figure out a way to do that without our “Evil dude” getting his hands on it.

The basis for this “key exchange” involves a mathematical solution called modulus divisions. In its most simplistic form it’s like how many times does x fit into y and what remains is the result. Let’s take this example:

23 Mod 13 = 10

The statement above says, “How many times does 13 fit into 23 and what is the remainder”? That’s really it. Now it can get very complex, but in essence, this is modules divisions. For our encryption to work we can’t just take any number, it needs to be a prime number. The reasoning behind it is that we need to use a unique capability from a prime number later on in the calculation. Remember that a prime number is a whole number that cannot be made by multiplying other whole numbers, if you can make it by multiplying other whole numbers it is a Composite Number.

Back to our modules example “23 Mod 13”, where we call 23 the generator and 13 the exponent. So first Michael and Rick agree on the generator (G) and the exponent (P) that they will use. As this is all send in clear text, our “Evil dude” will receive a copy as well.


To start with the fun, Michael will add a random (private) number to the generator and send the result to Rick. For kicks let’s add something like 15. So we get the following:

2315 Mod 13 = 12

The resulting number of 12 is send, in clear text (public information), to Rick, needless to say that our ears dropping person in the middle also gets a copy. Rick, receiving the package now does exactly the same with a random number he makes up. Let’s say the number 26. The result is

2326 Mod 13 = 9

This resulting number is send back to Michael for him to use.


So now both Michael and Rick have some public and private information. Michael has a private number (Let’s call it a key) of 15 and received a public key of 9. Rick has a private key of 26 and received a public key of 12. Our hacker has all the public information.

Now comes the magic. To calculate the shared secret both Michael and Rick will use the public information that they received and use it with their own key to generate the shared secret for further communications. So it goes like this.


Michael: (Rick’s public key)9 15 (Michael’s Private key) Mod 13 = (shared key)1

Rick: (Michael’s public key)12 26 (Rick’s private key) Mod 13 = (shared key)1

So what we have done here is take the public information we received from the person we want to set up a secure communications with and use exponentiation to calculate the secret. Once we have generated our secret we can now use that to further encrypt all our messages. Coincidental we could also use multiply both secrets and use that as an exponential in both cases. This is possible only by using prime numbers.

23(15*26=390) Mod 13 = 1

What I’ve shown you here are the essentials for public key exchange using Diffie-Hellman key exchange which is a popular cryptographic algorithm that allows Internet protocols to agree on a shared key and negotiate a secure connection. It is fundamental to many protocols including HTTPS, SSH, IPsec and protocols that rely on Transport Layer Security (TLS). Obviously, in my example, I’ve over simplified things just to make it understandable, in practice it’s a bit more complex using larger numbers, but the technique is the same.

As always if you have any questions, comments or remarks, just let me know.