.net - 如果启用了 Windows FIPS 合规性策略，为什么不允许 .NET "Managed"加密类？

Question

我一直致力于使我们的 .NET 应用程序符合 FIPS，并发现 Managed加密类(例如 AESManaged )不符合 FIPS。我已经阅读了其他几篇关于哪些类是合规的文章和问题，例如 When will C# AES algorithm be FIPS compliant?和 http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/e0b4493f-6e20-4b75-a118-6b6e5d26a2a6 .看起来 CryptoServiceProvider 类符合 FIPS，但托管类不符合。

我只是想知道是否有人可以解释 CryptoServiceProvider 之间的区别类和 Managed上课？如果有人能解释为什么 CryptoServiceProvider类符合 FIPS，但托管类不符合，所以我可以向我的老板解释为什么我必须重写我们的加密方法。它们在底层有根本不同吗？还是 MS 只是没有对托管类(class)进行 NIST 认证？如果 Managed类只包装 CryptoServiceProvider类，那为什么不是 Managed类自动符合 FIPS？如果我编写一个类来将符合 FIPS 的类包装成我自己的更易于使用的类，我的软件是否不再符合 FIPS？

谢谢。

Answer 1

“符合 FIPS 标准”是错误的术语 - 您说的是 FIPS 认证的。不同之处在于，如果算法需要兼容引用实现和第三方实现，则需要符合描述该算法的相应 FIPS。但认证是另一回事。

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

另外我猜可能有技术原因阻止托管模块获得认证，但这只是一个猜测。 .NET(IL 和虚拟机)的性质可能与为认证过程定义的某些要求相矛盾，即它们无法通过认证。

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