What’s up with the Cryptography Application Block?

  • Article

I know that when many of you downloaded the November CTP of Enterprise Library, you were surprised to find out that it didn’t include the Cryptography Application Block. That’s not too surprising, as it took our team by surprise as well. I wanted to give you a little more background on what brought us to this point and what we plan on doing moving forward.

All patterns & practices deliverables, including the Enterprise Library Application Blocks, go through an extensive review process before they can be released. This includes functional, performance and security testing performed within the patterns & practices team, as well as external security reviews and sign-offs by the product groups within Microsoft who look after the related platform features and scenarios. These processes are nothing new, and the previous releases of Enterprise Library passed all of the necessary reviews and sign-off processes.

As we’ve progressed with the development of Enterprise Library for .NET Framework 2.0, we’ve of course been going through these processes to ensure we are shipping the highest quality code possible. Even though we didn’t have time to include any significant changes to the Cryptography Application Block from the previous version, we still need to put all blocks through the review processes each time. As it turned out, the company has just launched some new internal review processes for all cryptography related code that didn’t exist in the past. This new process raises the bar beyond what was required with previous processes, and unfortunately it will take some time to go through this new process and update the block with any recommended changes. Normally this kind of process change would go unnoticed by customers (especially for typical Microsoft products with multi-year development cycles), but in this instance the timing of the new process was incompatible with our release plans, and we had to make the difficult decision to temporarily remove the block from Enterprise Library until we have completed the necessary reviews. This means that the block is not included in the November CTP, and there is a good chance it will not make it into the official release of Enterprise Library for .NET Framework 2.0. Our current plan (subject to change, as are all plans) is to release the block separately as soon as it is complete, and roll it back into the next update of Enterprise Library.

Now I want to take this opportunity to dispel some of your potential concerns:

  • This delay was not the result in any specific security bugs found in the Cryptography Application Block. Instead, it is the result of new processes and more stringent requirements that will result in a more secure solution. Security needs to be conidered in light of a threat model - and with the new process we are involving more people to create and review this threat model. Because the review process has not yet completed, we don’t know exactly which (if any) changes will be required in the block – but the idea is that it will push us even further up the scale of secure solutions and improve alignment with related features in the .NET Framework. It does not mean that the original block is “insecure”.
  • If you have already deployed previous versions of the Cryptography Application Block, you should not be concerned with the security of your solution if you have followed the recommended development practices such as encrypting any configuration files storing keys and encrypting the keys using DPAPI. The code and recommended development processes were extensively reviewed and passed all required sign-off processes at the time.
  • If you have used the Cryptography Application Block in the past and want to move your applications to .NET Framework 2.0, many of the scenarios requiring the previous cryptography solution can now be met without the Cryptography Application Block. Specifically, configuration files can now be encrypted directly using System.Configuration, and the authentication database used by the new ASP.NET Membership system supports password hashing out-of-the-box. Furthermore, the new ProtectedData class provides simple access to DPAPI from managed code, and the <cryptographySettings> configuration section lets you define your cryptography algorithms in configuration files.
  • We still believe that Enterprise Library should make it easier for developers to implement common cryptography scenarios with less code and fewer errors. As a result we are still committed to finishing and delivering this block.

I hope this gives you a better understanding if where we are at now. If you have any more questions or concerns, please let us know – and if we have any more news, I’ll be sure to let you know.

This posting is provided "AS IS" with no warranties, and confers no rights.