Why are the .NET "Managed" Cryptography classes NOT FIPS compliant?

Question

I have been working on making our .NET application FIPS compliant, and have found that the Managed Cryptography classes (such as AESManaged) are not FIPS compliant. I have read several other articles and questions on which classes are compliant, such as http://stackoverflow.com/questions/939040/when-will-c-aes-algorithm-be-fips-compliant and http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/e0b4493f-6e20-4b75-a118-6b6e5d26a2a6. It looks like the CryptoServiceProvider classes ARE FIPS compliant, but the Managed classes are not.

I am just wondering if someone can explain the difference between the CryptoServiceProvider classes and the Managed classes? And if someone can explain why the CryptoServiceProvider classes are FIPS compliant, but the Managed classes are not, so I can explain to my boss why I have to rewrite our encryption methods. Are they fundamentally different under the hood? Or has MS just not subjected the Managed classes to NIST certification? If the Managed classes just wrap the CryptoServiceProvider classes, then why aren't the Managed classes automatically FIPS compliant? And if I write a class to wrap a FIPS compliant class into a more easily usable class of my own, is my software no longer FIPS compliant?

Thanks.

Answer 1

"FIPS-compliant" is wrong term - you are talking about FIPS-certified ones. The difference is that if the algorithm needs to be compatible with reference implementation and third-party implementations, then it needs to be compliant to corresponding FIPS that describes this algorithm. But certification is a different story.

CryptoServiceProvider classes call CryptoAPI (unmanaged Windows API) to perform actual crypto operations, and some CryptoAPI modules are FIPS-certified (for business purposes). Obviously there were not enough reasons to certify .NET managed classes - if you need certified modules, use CryptoAPI ones. Certification takes lots of time, efforts and significant amount of money.

Also I guess there can be technical reasons that prevent the managed modules from certification, but this is just a guess. It can happen that the nature of .NET (IL and virtual machine) contradict to some requirements defined for certification process, i.e. they just can't be certified.

As for your own wrapper classes - there exist several companies that provide personnel training and certification itself. They also offer consulting services. I hope that somebody from such service responds here, but you can contact them as well if you need.