如果启用了Windows FIPS合规性策略,为什么不允许使用.NET"托管"加密类？

Question

我一直致力于使我们的.NET应用程序符合FIPS,并且发现ManagedCryptography类(例如AESManaged)不符合FIPS标准.我已经阅读了其他几篇关于哪些类符合的文章和问题,例如何时C#AES算法符合FIPS标准？和http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/e0b4493f-6e20-4b75-a118-6b6e5d26a2a6.它看起来像CryptoServiceProvider类符合FIPS,但Managed类不是.

我只是想知道是否有人可以解释CryptoServiceProvider类和Managed类之间的区别？如果有人可以解释为什么这些CryptoServiceProvider类符合FIPS,但是托管类不是,所以我可以向老板解释为什么我必须重写我们的加密方法.引擎盖下它们根本不同吗？或者MS有没有让Managed类获得NIST认证？如果Managed类只包装CryptoServiceProvider类,那么为什么Managed类不能自动符合FIPS？如果我编写一个类将FIPS兼容类包装到我自己更容易使用的类中,我的软件是否不再符合FIPS？

谢谢.

Answer 1

"FIPS兼容"是错误的术语 - 您正在谈论FIPS认证的术语.不同之处在于,如果算法需要与参考实现和第三方实现兼容,那么它需要符合描述此算法的相应FIPS.但认证是另一回事.

CryptoServiceProvider类调用CryptoAPI(非托管Windows API)来执行实际的加密操作,一些CryptoAPI模块通过FIPS认证(用于商业目的).显然,没有足够的理由来认证.NET托管类 - 如果您需要经过认证的模块,请使用CryptoAPI.认证需要大量的时间,精力和大量的资金.

此外,我猜可能有技术原因导致托管模块无法通过认证,但这只是猜测.可能会发生.NET(IL和虚拟机)的性质与为认证过程定义的某些要求相矛盾,即它们无法被认证.

至于你自己的包装类 - 有几家公司提供人员培训和认证.他们还提供咨询服务.我希望来自此类服务的人能在此回复,但如果您需要,也可以与他们联系.