It seems like every week I talk to a new Microsoft Windows customer who has just failed a security audit because they are not handling encryption keys correctly in their Microsoft applications. I hear an assortment of descriptions like this:
We’re doing encryption, but the encryption key is stored in a table in the database.
We’re doing encryption, but the key is burned in our C# code.
We’re doing encryption, but the key is stored in a flat file protected with a password.
We’re doing encryption, but our encryption key is weak - it’s just a password
These Microsoft customers are trying to do the right thing when it comes to encrypting sensitive data, they just did not get the proper security controls in place for the encryption keys. And this is understandable, Microsoft does not provide very good guidance in this area, and it is probably the area where most organizations fail to get encryption right. When you do encryption, using strong encryption keys and protecting them properly is the hardest part.
You’ve made a big investment in your application built on the Microsoft C# .NET architecture, so what do you do now?
It turns out that it is not difficult to remediate this problem. You need a few things:
- A good key manager built and certified to industry standards.
- A Windows software library that is friendly to your C# application.
- A developer who can implement some simple methods for key management.
Let’s look at how we help our customers solve these three challenges:
1) A key manager is easy. Our Alliance Key Manager solution is an easy-to-install and configure key management solution that runs as a Cloud instance (AWS, Azure), as a VMware virtual machine, as a network-attached hardware security module (HSM), or as a dedicated Cloud HSM. It configures in a few seconds and you have a fully functional, dedicated, FIPS 140-2 compliant key management solution. It even automatically creates unique encryption keys for you on the first boot.
2) The second thing you need is a good Windows .NET software library that makes retrieving the encryption key seamless. We provide that at no charge in the form of our Windows .NET Client. It installs on Windows in the usual way and is ready to add to your Visual Studio project. The Windows .NET Client software DLL handles all of the complexities for you. It makes the authenticated connection to the key server, audits all key retrieval activity, and caches the key for the best performance. Sample C# code shows you exactly how to do key retrieval from your code and is easy to implement.
3) The third thing you need is a good developer. With over 2 million Windows developers out there it is not hard to find one. Maybe this is you? Making the code change to incorporate key retrieval with Alliance Key Manager’s Windows .NET Client is really simple in C#. You just remove the logic of the burned in key or the logic to retrieve it from a file, add the Alliance Key Manager Windows .NET Client to your Visual Studio project, and put in code that looks something like this (see the sample code for the complete picture):
// Load the data to be encrypted
plaintext = Encoding.UTF8.GetBytes(data);
// Initialize for the client configuration file
SetClientConfiguration(keyService.ClientConfiguration);
// Retrieve the encryption key from the key server
key = keyService.GetSymmetricKey(keyName, instance);
// Perform encryption
using (var algorithm = new RijndaelManaged())
{
algorithm.Key = key.KeyBytes();
using (var encryptor = algorithm.CreateEncryptor())
{
ciphertext = encryptor.TransformFinalBlock(plaintext, 0,
plaintext.Length);
}
}
// Display the ciphertext (you would probably save it in a database)
Console.WriteLine("ciphertext: " + BitConverter.ToString(ciphertext));
The Alliance Key Manager Windows .NET Client code handles a lot of issues for you. Here are just a few:
Authentication
The Windows .NET Client performs the TLS connection to Alliance Key Manager and handles the full authentication sequence. You get a secure, mutually authenticated TLS connection without needing to handle that in your C# code.
High Availability Failover
You can define one or more Alliance Key Managers in a high availability failover group. If one key manager is not available due to a network failure or a key server failure, the client-side code will automatically use the next available key server. You can define a primary and multiple failover key servers, and you can mix and match cloud, virtual, and HSMs in your key management topology.
Performance
The Alliance Key Manager Windows .NET Client is designed for high performance. It will automatically securely cache encryption keys so that you don’t need to retrieve the keys more than one. If the key has been retrieved before in your current process it will be returned to you without a round-trip communications session with the key server. That gives you maximum performance.
PCI Compliance - Coalfire and PAG
Alliance Key Manager is FIPS 140-2 compliant (certificate 1449) and has been PCI validated by Coalfire, a top-tier QSA auditor. This means that you can achieve very rapid compliance with PCI and other compliance regulations without a lot of fuss. If you are under the gun to fix a compliance failure, you should start with a solution that provably meets the compliance regulation. Alliance Key Manager does exactly that. The PCI Product Applicability Guide is here.
Most C# applications that we see are well-modularized and the encryption logic is in one place, or a very small number of locations in the code. This makes the change to your code easy to make and easy to test. The complexity is handled for you in the Alliance Key Manager Windows .NET Client software.
You can find the Alliance Key Manager Windows .NET Client application on the supplemental download for the product. It is available at no charge and there are no client-side license fees. In addition to the installation package you will find full sample code and documentation. For interested developers, we also offer a free developer tools. As always, let us know if you have any questions.
Enjoy.
Patrick
