Федеральный стандарт США FIPS 140-2 "Требования безопасности для криптографических модулей"

Требования безопасности. Часть 4. Самотестирование, доверие проектированию, сдерживание прочих атак, другие рекомендации.

Мы приступаем к рассмотрению трех последних из одиннадцати предусмотренных стандартом FIPS 140-2 групп требований безопасности для криптографических модулей.

Криптографический модуль должен выполнять самотестирование при включении питания, при выполнении некоторых условий (когда вызывается функция безопасности, для которой предусмотрено тестирование), а также по требованию оператора.

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

Специфицированы следующие виды проверок:

• тесты криптографических алгоритмов;
• контроль целостности программного обеспечения;
• тесты функций, критичных для безопасности модуля.

В число проверок, выполняемых по условию, входят:

• проверка взаимной согласованности парных ключей ;
• контроль загружаемых программ;
• контроль ключей, вводимых вручную;
• тест генератора случайных чисел;
• тест режима обхода.

Меры доверия проектированию, заданные стандартом, распространяются на конфигурационное управление, процедуры безопасной установки, генерации и распространения, процесс разработки и документацию.

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

На втором уровне предусмотрена функциональная спецификация с неформальным описанием модуля, внешних портов и интерфейсов, их назначения.

На третьем уровне программные компоненты должны быть реализованы на языке высокого уровня, за исключением, быть может, небольшого числа ассемблерных вставок. Высокоуровневая спецификация требуется и для аппаратуры.

На четвертом уровне устанавливается формальная модель политики безопасности с обоснованием ее полноты и непротиворечивости и неформальной демонстрацией соответствия функциональным спецификациям. В исходных текстах программных компонентов должны быть представлены необходимые предусловия и ожидаемые постусловия.

Комплект документации состоит из руководства крипто-офицера (аналог руководства администратора) и пользователя.

Криптографические модули могут стать объектом самых разных атак, основанных, например, на анализе потребляемого электропитания или времени выполнения операций, на переводе модуля в сбойный режим, на анализе побочных электромагнитных излучений и наводок и т.д.

Для противодействия анализу потребляемого электропитания в модуль могут встраиваться конденсаторы, использоваться внутренние источники питания, вставляться специальные инструкции для выравнивания потребления электропитания в процессе выполнения криптографических функций.

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

Для противодействия атакам, основанным на переводе модуля в сбойный режим, стандарт рекомендует описанные выше меры физической защиты.

В качестве приложений стандарт FIPS 140-2 содержит рекомендации, дополняющие одиннадцать групп требований безопасности. К ним относятся:

• сводка требований к документации;
• рекомендуемые правила разработки программного обеспечения;
• рекомендуемое содержание политики безопасности   криптографического модуля.

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