Townsend Security Data Privacy Blog

Fixing Encryption Key Management Audit Failures in Microsoft Windows C# Applications

Posted by Patrick Townsend on Dec 23, 2015 11:00:00 AM

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:

Encryption Key Management for Microsoft .NET 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

Encryption Key Management for Microsoft .NET

Topics: C#, Microsoft, .NET, Encryption Key Management

.NET Encryption and Key Management

Posted by Patrick Townsend on Aug 13, 2012 10:29:00 AM

Key Management in the Multi-Platform Environment

encryption key management white paper

Download the white paper "Key Management in the Multi-Platform Environment"

Click Here to Download Now

If you have Microsoft SQL Server with Extensible Key Management (EKM), the implementation of encryption and key retrieval with Alliance Key Manager, our encryption key management Hardware Security Module (HSM) is easy. Our HSM comes with the Windows EKM Provider software that you install, configure and deploy.  Problem solved.

But what if you have a significant investment in Microsoft applications that don’t support EKM?

For example, you might have applications built on SQL Server 2005 or SQL Server 2008/2012 Standard Edition which do not support EKM. You could upgrade to SQL Server 2008 R2 or SQL Server 2012, but there might be application roadblocks that prevent the upgrade right now.

Or, you might have applications written in a .NET language that update non-Microsoft databases, or which work with unstructured data.

These technical hurdles won’t stop you from using our encryption key manager to meet compliance requirements for protecting encryption keys. We provide a .NET Assembly and DLL that you can add to your .NET project to retrieve encryption keys from the HSM. A few lines of C# code and you are retrieving the encryption key from the HSM, and the problem is solved.

The sample code on the product CD will get you up and running quickly. There are C# sample applications with source code that you can use as a starting point in your projects. The Alliance Key Manager .NET Assembly works with any .NET language including C#, C, and C++.

The Alliance Key Manager .NET Assembly also works with the Common Language Runtime (CLR) environment, and with Stored Procedures. And you can mix and match your .NET languages, databases, and OS platforms.

The combination of automatic encryption (EKM, TDE, Cell Level Encryption) with the Alliance Key Manager .NET Assembly code means that you won’t have any gaps in your coverage of your Microsoft platforms.  Download our white paper "Key Management in the Multi-Platform Environment" for more information on securing your encryption keys.

Happy coding!

Patrick

Click me

Topics: Alliance Key Manager, Encryption, Key Management, Extensible Key Management (EKM), C#, Microsoft, .NET, SQL Server

Encryption and Key Management in a .NET World

Posted by Patrick Townsend on Feb 11, 2011 11:41:00 AM

encryption key managementAs we’ve developed more solutions for the Microsoft Windows platform I’ve come to appreciate the rich set of programming languages that Microsoft provides to developers, and the deep support they provide to both beginner and advanced programmers.  There is a large group of experts inside of Microsoft and in the outside developer community that generously supports Windows developers. Whether you develop in .NET, or C#, no one has done better than Microsoft and generating and supporting this developer community. At a recent SQL PASS conference I saw T-Shirts with the slogan:

    “2.7 Million Geeks Can’t Be Wrong”
    
What’s surprising about that 2.7 million number is that it is not surprising. There may actually be that many Microsoft developers out there.

Encryption and key management have become big challenges for Microsoft developers as various compliance regulations mature and require separation of encryption keys from the data they protect (see my previous blogs on this issue).  In the past a Microsoft developer might have used the Windows DPAPI to store encryption keys, or might have stored them in a SQL Server database. That approach can’t meet the requirements for Dual Control, Separation of Duties, and Split Knowledge required by good security practice and compliance regulations such as PCI DSS. These .NET, and C# developers are now changing their encryption strategy to incorporate external key managers into their applications.

That’s where a Microsoft developer often encounters some friction. Key management vendors are generally not responsive to the needs of a Microsoft developer and fail to provide interfaces that work naturally in this environment. Complex DLL implementations that require special .NET wrapper code, poor integration with the existing .NET encryption APIs, and the absence of quality sample code makes life difficult for the Microsoft developer. And this means that application development slows down and gets more expensive. That’s bad news in a Windows developer world.

I think we’ve done a lot of things right for Microsoft developers with our Alliance Key Manager solution. We provide a .NET assembly key retrieval library that integrates naturally in all of the Microsoft development languages. We also provide for key retrieval directly into .NET applications so that developers can use the native .NET encryption libraries. By not forcing server-based encryption or the use of special encryption libraries, the developer can decide for themselves the best approach to encryption once they have an encryption key retrieved to their application. This approach also supports Microsoft’s Managed Code architecture.

Developers also need some good example code to help speed development. So we’ve provided that with our Alliance Key Manager solution. You can install a working .NET GUI application that retrieves encryption keys from the server, and the install includes the Visual Studio project and source code.  And there are C# examples if you develop in that Microsoft language.

The last thing we’ve done to support the Microsoft Windows platform is integrate our encryption key retrieval routines with the Windows certificate store and native Windows communications facility. When a Windows application authenticates to the Alliance Key Manager server the certificates used for the secure TLS connection are under Windows security and control. And the TLS communications is done with native Windows communications APIs. This reduces the chance of loss of certificates and private keys, supports the MMC management of certificates, and integrates with Microsoft’s patch update strategy. That is just one less component to worry about.

The combination of an affordable FIPS-140-2 compliant key management solution with deep support for the Microsoft developer makes our Alliance Key Manager a great option for Windows users who need to meet security best practices and compliance regulations for key management.

You can get more information about Alliance Key Manager here.

And more information about support for the Microsoft .NET environment here.

Happy programming!

Patrick

Topics: Encryption, Key Management, C#, Microsoft, .NET