учебники, программирование, основы, введение в,

 

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

Основные понятия и идеи стандарта FIPS 140-2
В федеральном стандарте США FIPS 140-2 "Требования безопасности для криптографических модулей" под криптографическим модулем понимается набор аппаратных и/или программных (в том числе встроенных) компонентов, реализующих утвержденные функции безопасности (включая криптографические алгоритмы, генерацию и распределение   криптографических ключей, аутентификацию) и заключенных в пределах явно определенного, непрерывного периметра.
В стандарте FIPS 140-2 рассматриваются криптографические модули, предназначенные для защиты информации ограниченного доступа, не являющейся секретной, т. е. речь идет о промышленных изделиях, представляющих интерес для основной массы организаций. Наличие подобного модуля - необходимое условие обеспечения защищенности сколько-нибудь развитой информационной системы, однако, чтобы выполнять предназначенную ему роль, сам модуль также нуждается в защите, как собственными средствами, так и средствами окружения (например, операционной системы).
Согласно стандарту, перед криптографическим модулем ставятся следующие высокоуровневые функциональные цели безопасности:

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

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

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

Спецификация модуля включает определение криптографического периметра, реализуемых функций и режимов, описание модуля, его аппаратных и программных компонентов, а также документированную политику безопасности.
Среди портов и интерфейсов  модуля должны быть выделены обязательные и дополнительные. Следует специфицировать все интерфейсы, а также все маршруты входных и выходных данных. Кроме того, порты для незащищенных параметров, критичных для безопасности, должны быть логически отделены от других портов.
Среди ролей и сервисов необходимо провести логическое разделение на обязательные и дополнительные, обеспечить персональную или ролевую аутентификацию.
Модель в виде конечного автомата должна описывать деление на обязательные и дополнительные состояния.
Меры физической самозащиты модуля включают замки, защитные кожухи, сохраняющие свидетельства вторжений пломбы, средства оперативного выявления и реагирования на попытки вторжений, меры по противодействию атакам, основанным на использовании нештатных внешних условий.
Ядром допустимого эксплуатационного окружения должна служить операционная система, удовлетворяющая требованиям утвержденного профиля защиты, обеспечивающая произвольное управление доступом, протоколирование и аудит, доверенные маршруты. Кроме того, следует применять утвержденные методы контроля целостности и построить модель политики безопасности.
В число поддерживаемых механизмов управления ключами должны входить генерация случайных чисел, распределение ввод/вывод, хранение и обнуление ключей.
На требованиях электромагнитной совместимости мы останавливаться не будем.
При включении питания и при выполнении определенных условий необходимо выполнение тестов криптографических алгоритмов, контроль целостности программного обеспечения, проверки критичных функций.
Меры доверия проектированию должны включать конфигурационное управление, процедуры безопасной установки, генерации и распространения. Следует подготовить функциональную спецификацию, при реализации использовать язык высокого уровня, продемонстрировать соответствие проекта и политики, снабдить пользователей соответствующими руководствами.
Наконец, предусматриваются меры по сдерживанию атак, для которых пока нет стандартизованных требований.
Стандартом FIPS 140-2 предусмотрено четыре уровня защищенности криптографических модулей, что позволяет экономически целесообразных образом защищать данные разной степени критичности (регистрационные журналы, счета на миллионы долларов или данные, от которых зависит жизнь людей) в разных условиях (строго охраняемая территория, офис, неконтролируемый объект).
К первому (самому слабому) уровню применяется минимальный набор требований безопасности, которым удовлетворяет, например, шифрующая плата для персонального компьютера. Программные компоненты соответствующих модулей могут выполняться на универсальных вычислительных системах с несертифицированной ОС.
На втором уровне требуются:

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

К третьему уровню предъявляются следующие дополнительные требования:

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

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

Требования безопасности. Часть 1. Спецификация, порты и интерфейсы, роли, сервисы и аутентификация
Мы приступаем к детальному рассмотрению первых трех из перечисленных выше одиннадцати групп требований безопасности.
В спецификации криптографического модуля должны фигурировать аппаратные и/или программные компоненты, влияющие на его безопасность и заключенные в пределах определенных физических границ - криптографического периметра. Если модуль является программным, в пределах периметра окажутся процессор и другие аппаратные компоненты, хранящие и защищающие программы.
В спецификации должны быть определены физические порты и логические интерфейсы, все входные и выходные маршруты данных.
Следует описать ручные и логические средства управления криптографическим модулем, физические или логические индикаторы состояния, применимые физические (в частности, электрические) и логические характеристики.
В проектной документации необходимо представить схемы взаимосвязей таких компонентов, как микропроцессоры, буферы ввода/вывода, буферы открытых и шифрованных данных, управляющие буферы, ключевая, рабочая и программная память. Проект должен выполняться с использованием языка спецификаций высокого уровня.
Следует специфицировать все данные, критичные для безопасности, в том числе криптографические ключи, аутентификационные данные, параметры криптографических алгоритмов, регистрационные данные и т.д.
Обязательный элемент документации - политика безопасности   криптографического модуля.
Прохождение всех информационных потоков, как и физический доступ к модулю, производится через определенный набор физических портов и логических интерфейсов. Интерфейсы должны логически различаться, хотя они могут разделять один порт (например, для ввода и вывода данных) или охватывать несколько портов (например, вывод данных может осуществляться через последовательный и параллельный порты). Прикладной программный интерфейс программного компонента модуля может трактоваться как один или несколько логических интерфейсов.
Следующие четыре логических интерфейса являются обязательными:

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

Все внешнее электрическое питание должно поступать через порт питания. Его может и не быть, если применяются внутренние батарейки.
Каждому обязательному логическому интерфейсу соответствует свой маршрут данных. Маршрут вывода данных логически отсоединяется от средств обработки в момент генерации, ручного ввода или обнуления ключей. Чтобы предотвратить непреднамеренный вывод данных, критичных для безопасности, следует предусмотреть два независимых внутренних действия, необходимых для использования интерфейсов, применяемых при выводе криптографических ключей, информации ограниченного доступа и т.п.
На третьем и четвертом уровнях безопасности порты (интерфейсы), предназначенные для ввода или вывода данных, критичных для безопасности, необходимо физически (логически) отделить от других портов (интерфейсов), а критичные данные должны поступать прямо в модуль (например, по непосредственно подсоединенному кабелю или доверенному маршруту).
В рамках криптографического модуля для операторов поддерживаются роли и ассоциированные с ними сервисы и права доступа (ролевой доступ рассматривался в курсе "Основы информационной безопасности"). Один оператор может быть приписан нескольким ролям. Если модуль поддерживает параллельную работу нескольких операторов, он должен управлять разделением ролей.
Требуется поддержка по крайней мере следующих ролей:

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

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

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

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


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

Могут быть предусмотрены и другие, дополнительные состояния:

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

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

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

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

  • путем постоянного отслеживания электрических и температурных параметров с выключением модуля или обнулением данных, критичных для безопасности, при выходе параметров за допустимые границы;
  • путем обеспечения устойчивости модуля к нештатным внешним условиям (например, модуль должен нормально работать при температурах от -100 до +200 градусов).

 

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

  • универсальное, с коммерческой операционной системой, управляющей как компонентами модуля, так и другими процессами и приложениями;
  • ограниченное, являющееся статическим, немодифицируемым (например, виртуальная Java-машина на непрограммируемой плате для персонального компьютера);
  • модифицируемое, которое может быть реконфигурировано и включать средства универсальных ОС.

Ядро универсального и модифицируемого окружения - операционная система. На первом уровне безопасности к ней предъявляются следующие требования:

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

Для второго уровня безопасности требуется использование ОС, сертифицированных на соответствие определенным профилям защиты на основе "Общих критериев" с оценочным уровнем доверия не ниже второго. Для защиты критичных данных должно применяться произвольное управление доступом с определением соответствующих ролей. Необходимо протоколирование действий крипто-офицера.
Характерная черта третьего уровня безопасности - использование доверенного маршрута.
На четвертом уровне безопасности криптографического модуля нужна ОС с оценочным уровнем доверия не ниже четвертого.
Требования безопасного управления криптографическими ключами охватывают весь жизненный цикл критичных данных модуля. Рассматриваются следующие управляющие функции:

  • генерация случайных чисел;
  • генерация ключей;
  • распределение ключей;
  • ввод/вывод ключей;
  • хранение ключей;
  • обнуление ключей.

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

Требования безопасности. Часть 4. Самотестирование, доверие проектированию, сдерживание прочих атак, другие рекомендации.
Мы приступаем к рассмотрению трех последних из одиннадцати предусмотренных стандартом FIPS 140-2 групп требований безопасности для криптографических модулей.
Криптографический модуль должен выполнять самотестирование при включении питания, при выполнении некоторых условий (когда вызывается функция безопасности, для которой предусмотрено тестирование), а также по требованию оператора.
Необходимо, чтобы тесты покрывали все функции модуля (зашифрование, расшифрование, аутентификацию и т.д.). Для определения правильности прохождения тестов может применяться как сравнение с заранее известными, эталонными результатами, так и анализ согласованности результатов двух независимых реализаций одной и той же функции.
Специфицированы следующие виды проверок:

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

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

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

Меры доверия проектированию, заданные стандартом, распространяются на конфигурационное управление, процедуры безопасной установки, генерации и распространения, процесс разработки и документацию.
Документация, представляемая разработчиком на первом уровне безопасности, должна специфицировать соответствие между проектом криптографического модуля и его политикой безопасности, а комментарии в исходном тексте - между проектом и программными компонентами.
На втором уровне предусмотрена функциональная спецификация с неформальным описанием модуля, внешних портов и интерфейсов, их назначения.
На третьем уровне программные компоненты должны быть реализованы на языке высокого уровня, за исключением, быть может, небольшого числа ассемблерных вставок. Высокоуровневая спецификация требуется и для аппаратуры.
На четвертом уровне устанавливается формальная модель политики безопасности с обоснованием ее полноты и непротиворечивости и неформальной демонстрацией соответствия функциональным спецификациям. В исходных текстах программных компонентов должны быть представлены необходимые предусловия и ожидаемые постусловия.
Комплект документации состоит из руководства крипто-офицера (аналог руководства администратора) и пользователя.
Криптографические модули могут стать объектом самых разных атак, основанных, например, на анализе потребляемого электропитания или времени выполнения операций, на переводе модуля в сбойный режим, на анализе побочных электромагнитных излучений и наводок и т.д.
Для противодействия анализу потребляемого электропитания в модуль могут встраиваться конденсаторы, использоваться внутренние источники питания, вставляться специальные инструкции для выравнивания потребления электропитания в процессе выполнения криптографических функций.
Средство сдерживания атак, основанных на анализе времени выполнения операций, - вставка дополнительных инструкций, сглаживающих различия во времени работы.
Для противодействия атакам, основанным на переводе модуля в сбойный режим, стандарт рекомендует описанные выше меры физической защиты.
В качестве приложений стандарт FIPS 140-2 содержит рекомендации, дополняющие одиннадцать групп требований безопасности. К ним относятся:

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

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

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика