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

Требования безопасности. Часть 1. Спецификация, порты и интерфейсы, роли, сервисы и аутентификация

Мы приступаем к детальному рассмотрению первых трех из перечисленных выше одиннадцати групп требований безопасности.

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

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

Следует описать ручные и логические средства управления криптографическим модулем, физические или логические индикаторы состояния, применимые физические (в частности, электрические) и логические характеристики.

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

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

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

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

Следующие четыре логических интерфейса являются обязательными:

• интерфейс ввода данных. Все данные, поступающие в модуль для обработки и/или использования (кроме управляющих данных, см. далее) должны вводиться через этот интерфейс ;
• интерфейс вывода данных. Все выходные данные (кроме информации о состоянии, см. далее) должны покидать модуль через этот интерфейс . При возникновении ошибочных ситуаций и во время выполнения тестов вывод должен быть запрещен;
• входной управляющий интерфейс. Через него должны подаваться все команды и сигналы (в том числе вызовы функций и ручные управляющие воздействия, например, нажатие на переключатель или клавишу), применяемые для управления функционированием криптографического модуля ;
• выходной интерфейс состояния. Через этот интерфейс выдаются все выходные сигналы, индикаторы и информация о состоянии (в том числе коды завершения и физические индикаторы, в частности, показания светодиодов), отображающие состояние криптографического модуля .

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

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

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

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

Требуется поддержка по крайней мере следующих ролей:

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

Если операторам разрешается производить обслуживание модуля (например, диагностирование аппаратуры и/или программ), поддерживается роль инженера, при активизации и завершении которой следует обнулять все незащищенные критичные данные.

Криптографический модуль должен предоставлять следующие сервисы:

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

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

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

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

В стандарте не оговорены требуемые механизмы аутентификации, специфицирована лишь их стойкость. Вероятность случайного успеха одной попытки должна составлять менее 1/1000000, вероятность случайного успеха какой-либо из нескольких попыток, производимых в течение минуты, - менее 1/100000. Это весьма (а на наш взгляд - чрезмерно) мягкие требования, если учитывать, что в году 525600 минут. Очевидно, необходимы меры противодействия многократным неудачным попыткам аутентификации.