如果启用了Windows FIPS合规性策略,为什么不允许使用.NET“托管
我一直致力于使我们的.NET应用程序符合FIPS,并且发现Managed Cryptography类(例如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,但Managed类不符合.
我只是想知道是否有人可以解释CryptoServiceProvider类和托管类之间的区别?如果有人可以解释为什么CryptoServiceProvider类符合FIPS,但Managed类不是,那么我可以向老板解释为什么我必须重写我们的加密方法.引擎盖下它们根本不同吗?或者MS有没有让Managed类获得NIST认证?如果Managed类只包装了CryptoServiceProvider类,那么为什么Managed类不能自动符合FIPS?如果我编写一个类将FIPS兼容类包装到我自己更容易使用的类中,我的软件是否不再符合FIPS? 谢谢. 解决方法
“FIPS兼容”是错误的术语 – 您正在谈论FIPS认证的术语.不同之处在于,如果算法需要与参考实现和第三方实现兼容,那么它需要符合描述此算法的相应FIPS.但认证是另一回事.
CryptoServiceProvider类调用CryptoAPI(非托管Windows API)来执行实际的加密操作,一些CryptoAPI模块通过FIPS认证(用于商业目的).显然,没有足够的理由来认证.NET托管类 – 如果您需要经过认证的模块,请使用CryptoAPI.认证需要大量的时间,精力和大量的资金. 此外,我猜可能有技术原因导致托管模块无法通过认证,但这只是猜测.可能发生的是,.NET(IL和虚拟机)的性质与为认证过程定义的某些要求相矛盾,即它们无法被认证. 至于你自己的包装类 – 有几家公司提供人员培训和认证.他们还提供咨询服务.我希望来自此类服务的人能在此回复,但如果您需要,也可以与他们联系. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |