As 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