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

Encryption Options for Microsoft SQL Server

Posted by Michelle Larson on Aug 20, 2014 7:45:00 AM

Encrypting data in Microsoft SQL Server is easy to do, yet often difficult to understand because of the different encryption options offered in various versions.

SQL Server Encryption Options Podcast It used to be said that “encryption is the hardest part of data security, and key management is the hardest part of encryption”. While that may have been true a few years ago, we are constantly working to make affordable, easy-to-use, defensible solutions that meet security best practices and industry compliance regulations. Separating and managing the encryption keys from the data they protect is still one of the biggest challenges in terms of doing an encryption project right, so let’s take a look at what encryption & key management options are available for SQL Server users.

If you are running the Enterprise Edition of SQL Server, version 2008 or newer, you have access to Microsoft’s architecture for encryption called Extensible Key Management (EKM). This provider interface allows for third-party key management systems to be easily incorporated in order to separate encryption keys from the encrypted data they protect. A key management solution should provide Windows client libraries, guidance, and sample code within the solution.

The SQL Server EKM architecture supports:

Transparent Data Encryption (TDE)
With TDE, the entire database table (including the logs you are collecting) is encrypted.  It is a very easy mechanism to use for encryption and since it is transparent, no application level changes are needed, it only takes a few commands to implement. TDE protects data at rest, including backups and log files.

Cell Level Encryption
Also known as column-level encryption, this allows for you to selectively encrypt certain columns of information in your database. This option makes sense if you have large databases of information, and only access encrypted columns periodically.

If you are running older versions of SQL Server (pre-2008), or using non-enterprise editions such as standard, web, or express; you do not have access to TDE or EKM. You still have good options for protecting your data with encryption, just remember the encryption key needs to be separated from the encrypted data it protects.

When you don’t have the EKM architecture, another option for encrypting data in your SQL Server database is to perform encryption and decryption at the application layer using .NET-based encryption. All editions of SQL Server support the ability to perform encryption from within the .NET framework with very straightforward code functions.

C# and VB.NET Application Encryption
If you are developing in .NET you only need to plug in the client side application and implement a few lines of code for your encryption and decryption calls.

Column Level Encryption
Another approach would be to combine User Described Functions (UDFs) with triggers and views to help automate the encryption and decryption at the column level.

Moving SQL Server Data to the Cloud

As more companies migrate their applications and data to the cloud, there are security issues to consider before making that move. Microsoft Azure SQL Database (MASD) -which has also been called SQL Azure, SQL Server Data Services, SQL Services, Windows Azure SQL Database- is a cloud-based service from Microsoft offering database capabilities as a part of the Azure Services Platform. The service is easy to use and readily available, just know that there are some constraints and some features of EKM that are not available when using MASD.  

Most businesses migrating to the cloud will choose to run virtual machines that contain the Windows OS and a full implementation of the SQL Server database. By using a virtual machine, encryption and key management, including EKM with TDE, can be fully supported and provide the level of security you expect and compliance regulations require!  

You have many options still available for your key management solution when your data has been moved to the cloud. Our NIST validated, FIPS 140-2 compliant Alliance Key Manager solutions are available as:

    • Hardware Security Module (HSM) - a hardened appliance that you can rack up in your own data center
    • Cloud HSM - dedicated hardware device in our hosted cloud environment
    • VMware - deploy as a virtual appliance
    • Cloud - deploy in Windows Azure, Amazon Web Services, or IBM Cloud as a standard cloud instance or virtual private cloud

To learn more about encrypting data on SQL Server, managing encryption keys, and how we are helping companies protect their data with Alliance Key Manager, download the podcast on Encryption Options on SQL Server.  

SQL Server Encryption Options Podcast

Topics: Alliance Key Manager, Extensible Key Management (EKM), .NET, Encryption Key Management, SQL Server, Podcast, Cell Level Encryption, Transparent Data Encryption (TDE)

Encrypting Data with .NET Libraries

Posted by Michelle Larson on Jul 18, 2014 11:40:00 AM

Encryption and key management continue to be perceived as challenges for .NET developers as more compliance regulations and state laws require the physical separation of encryption keys from the data they protect.

White Paper: Key Management in a Multi-Platform Environment In the past, .NET developers might have used the Windows DPAPI to store encryption keys, or might have stored them in a SQL Server database. That approach does not meet the requirements for dual control, separation of duties, and split knowledge required by security best practices and compliance regulations such as PCI DSS, HIPAA/HITECH, GLBA/FFIEC, and others.

Historically, Microsoft .NET developers expected to experience some heartburn with an encryption key manager because:

  • Key management vendors were historically not responsive to the needs of a .NET developer and failed to provide interfaces that work naturally in this environment
  • Complex DLL implementations required special .NET wrapper code
  • Poor integration with the existing .NET encryption APIs
  • The absence of quality sample code which made life difficult for the Microsoft  .NET developer or slowed down application development

There have been a lot of changes that now make it easier on Microsoft .NET developers to approach encryption and key management. A key manager solution should:

  • Provide a .NET assembly key retrieval library that integrates naturally in all of the Microsoft development languages.
  • 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, you decide the best approach to encryption once an encryption key is retrieved to the application (this approach also supports Microsoft’s Managed Code architecture)
  • Offer vetted sample code to help speed development! 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
  • Integration of encryption key retrieval routines with the Windows certificate store and native Windows communications facility.
    • When a Windows application authenticates, the certificates used for the secure TLS connection are under Windows security and control. 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.

As a developer, you might have applications written in a .NET language that update non-Microsoft databases, or which work with unstructured data. These technical hurdles should not stop you from using an encryption key manager to meet compliance requirements for protecting encryption keys.

  • Look for 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# or VB.NET code and you are retrieving the encryption key from the HSM.
  • Make sure sample code is provided on the product CD to get you up and running quickly. There should be sample applications with source code that you can use as a starting point in your projects.
  • The .NET Assembly should work with any .NET language. It should also work with the Common Language Runtime (CLR) environment, and with Stored Procedures. Make sure you can mix and match your .NET languages, databases, and OS platforms.

The combination of NIST validated encryption and an affordable FIPS 140-2 compliant key management solution with solid support for the Microsoft .NET developer makes our Alliance Key Manager a great option for users who need to meet security best practices and compliance regulations for key management. It is time to change your encryption strategy to incorporate solid encryption and an external key manager, whether that is an HSM, Cloud HSM, or virtual environment.

Download our white paper, Key Management in the Multi-Platform Environment, for more information on securing your encryption keys.

White P

Topics: Alliance Key Manager, Microsoft, .NET, Encryption Key Management, White Paper

.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