Почему классы криптографии ".NET" .NET запрещены, если включена политика соответствия Windows FIPS?

Question

Я работал над тем, чтобы сделать наше приложение .NET совместимым с FIPS, и обнаружил, что классы криптографии Managed (такие как AESManaged) не соответствуют FIPS. Я прочитал несколько других статей и вопросов о том, какие классы совместимы, например, Когда алгоритм AES C # будет FIPS-совместимым? и http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/e0b4493f-6e20-4b75-a118-6b6e5d26a2a6. Похоже, что классы CryptoServiceProvider совместимы с FIPS, но Управляемых классов нет.

Мне просто интересно, может ли кто-нибудь объяснить разницу между классами CryptoServiceProvider и Managed? И если кто-то может объяснить, почему классы CryptoServiceProvider соответствуют FIPS, а классы Managed - нет, то я могу объяснить своему боссу, почему я должен переписать наши методы шифрования. Они принципиально отличаются под капотом? Или MS просто не подвергла управляемые классы сертификации NIST? Если классы Managed просто обертывают классы CryptoServiceProvider, то почему классы Managed не соответствуют FIPS автоматически? И если я напишу класс, чтобы превратить класс, соответствующий FIPS, в более удобный для меня класс, будет ли мое программное обеспечение больше не соответствовать FIPS?

Спасибо.

Answer 1

«FIPS-совместимый» - это неправильный термин - вы говорите о FIPS-сертифицированных. Разница состоит в том, что если алгоритм должен быть совместим с эталонной реализацией и сторонними реализациями, то он должен быть совместимым с соответствующим FIPS, который описывает этот алгоритм. Но сертификация - это отдельная история.

Классы CryptoServiceProvider вызывают CryptoAPI (неуправляемый API Windows) для выполнения реальных операций шифрования, а некоторые модули CryptoAPI сертифицированы FIPS (для деловых целей). Очевидно, не было достаточных причин для сертификации управляемых классов .NET - если вам нужны сертифицированные модули, используйте CryptoAPI. Сертификация требует много времени, усилий и значительных денег.

Также я полагаю, что могут быть технические причины, препятствующие сертификации управляемых модулей, но это только предположение. Может случиться, что природа .NET (IL и виртуальная машина) противоречит некоторым требованиям, определенным для процесса сертификации, то есть они просто не могут быть сертифицированы.

Что касается ваших собственных классов обертки - существует несколько компаний, которые сами проводят обучение и сертификацию персонала. Они также предлагают консультационные услуги. Я надеюсь, что кто-то из таких служб ответит здесь, но вы также можете связаться с ними, если вам нужно.