Стандарт FIPS 140-2 «Вимоги з безпеки для криптографічних модулів»

Встановлена державними нормативними документами класифікація засобів КЗІ на жаль не дає відповіді, яким шляхом мають бути вирішені питання щодо забезпечення безпеки цих засобів. У цьому сенсі становить певний інтерес вивчення федерального стандарту США FIPS 140-2 «Вимоги з безпеки для криптографічних модулів», що визначає зовнішній інтерфейс криптографічних модулів та загальні вимоги до них. Цей стандарт спрощує формування під час розробки засобів КЗІ переліку їх сервісів безпеки та відповідних профілів захисту.

Під криптографічним модулем в стандарті FIPS 140-2 розуміється набор апаратних та/або програмних засобів, що реалізують обрані функції безпеки, зокрема, алгоритми криптографічних перетворень, генерацію та розподіл ключів, автентифікацію тощо.

Цей стандарт регулює питання щодо криптографічних модулів, призначених для захисту несекретної інформації (що не є державною таємницею за класифікацією США).

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

Стандарт FIPS 140-2 висуває до криптографічних модулів наступні функціональні цілі щодо їх безпеки:

· застосування та безпечна реалізація для захисту конфіденційної інформації визначених функцій безпеки;

· захист модулю від його несанкціонованого використання або нештатної їх експлуатації;

· попередження несанкціонованого доступу до змісту модуля, включаючи ключі криптографічних перетворень та інших даних, що критичні для убезпечення інформації, яка захищається;

· виключення можливості несанкціонованої модифікації модулю, його криптографічних механізмів, включаючи підміну, вставку та віддалення ключів та інших критичних для цілей безпеки параметрів;

· відображення/ індикація режиму роботи (стану) модуля, забезпечення довіри тому, що модуль функціонує належним чином в заданому режимі;

· виявлення помилок та збоїв у функціонуванні модуля та попередження витоку внаслідок цих помилок конфіденційної інформації та параметрів модуля, критичних для безпеки.

З визначених цілей випливають визначені в стандарті одинадцять груп вимог щодо забезпечення безпеки на етапах проектування та реалізації модуля:

1. специфікація криптографічного модуля;

2. вимоги щодо портів та інтерфейсів модуля;

3. роли, сервіси та автентифікація;

4. модель у вигляді скінченного автомата;

5. фізична безпека;

6. експлуатаційне оточення;

7. управління криптографічними ключами;

8. електромагнітна сумісність;

9. самотестування;

10. довіра до проектування;

11. стримування інших атак.

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

Порти та інтерфейси модуля мають бути поділені на обов’язкові та додаткові. Також мають бути специфіковані (чітко описані) усі інтерфейси, а також всі маршрути вхідних та вихідних даних.

При цьому, порти, за допомогою яких передаються незахищені критичні з міркувань безпеки параметри, обов’язково на логічному рівні відокремлюються від інших портів.

Логічний розподіл ролей и сервісів обов’язкові та додаткові сприятиме підвищенню рівня безпеки. Необхідно також забезпечити особисту та ролеву автентифікацію.

Модель у вигляді скінченного автомата повинна поділяти всі його стани на обов’язкові та додаткові.

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

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

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

На требованиях электромагнитной совместимости мы останавливаться не будем.

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

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

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

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

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

Уровень безопасности 1 также позволяет реализовывать программные криптографические функции в ПК общего назначения. Такие реализации могут соответствовать приложениям с низким уровнем безопасности. Реализация в ПК криптографического программного обеспечения может быть более рентабельна, чем аппаратная реализация. Это позволит организациям выбрать решение из альтернативных криптографических решений, соответствующих требованиям безопасности низшего уровня.

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

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

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

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

• Соответствует функциональным требованиям, указанным в Общих Критериях (CC) Профиля Контролируемой Защиты Доступа (CAPP) и

• Оценена на уровне EAL2.

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

В итоге констатируем, что на втором уровне требуются:

• ролевая аутентификация;

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

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

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

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

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

Уровень безопасности 3 допускает программную реалізацію криптографічного модуля, що застосовуються у багатокористувачских системах з розподілом часу за умов використання операційної системи, яка :

• Соответствует функциональным требованиям, указанным в CAPP с дополнительным функциональным требованием Надежного Пути (FTP_TRP.1) и

• Оценена на уровне EAL3 с дополнительным требованием гарантии Модели Политики Безопасности Неофициальной Цели Оценки (ADV_SPM.1).

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

Резюмируя изложенное, отметим, что к третьему уровню предъявляются следующие дополнительные требования:

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

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

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

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

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

Уровень безопасности 4 также защищает криптографический модуль против компрометации его безопасности из-за условий окружающей среды или флуктуаций напряжения и температуры вне нормальных рабочих диапазонов модуля. Намеренные отклонения от нормальных рабочих диапазонов могут использоваться нападающим, чтобы сорвать защиту криптографического модуля в течение нападения. Криптографический модуль должен включать специальные особенности защиты от изменений параметров окружающей среды, предназначенные для обнаружения таковых и уничтожения CSP. Иначе модуль должен подвергнуться строгому испытанию на отказ при воздействии окружающей среды, чтобы обеспечить разумную гарантию, что на модуль не будет воздействовать такие флуктуации вне нормального рабочего диапазона, которые могут ставить под угрозу безопасность модуля.

Уровень безопасности 4 допускает программную криптографию в многопользовательских системах с разделением времени при использовании с операционной системой, которая

• Соответствует функциональным требованиям, указанным для Уровня безопасности 3 и

• Оценена на уровне EAL4 с дополнительными требованиями гарантии Формального Моделирования Политики Безопасности (ADV_SPM.3), Анализа Плохо защищенного канала (AVA_CCA.1) и Модульности (ADV_INT.1).

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

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

Применяемая операционная система должна соответствовать оценочному уровню довериятне ниже четвертого.

Вимоги щодо безпеки криптографічних модулів включають декілька груп вимог, проаналізуємо їх більш детально.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• отображение состояния;

• выполнение тестов;

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

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

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

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

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

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

• включение/выключение питания (первичного, вторичного, резервного);

• обслуживание крипто_офицером (например, управление ключами);

• ввод ключей и других критичных данных;

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

• самотестирование;

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

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

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

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

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

Стандартом предусмотрены четыре разновидности криптографических модулей:

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

• состоящие из одной микросхемы;

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

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

Меры физической защиты структурированы в стандарте двумя способами.

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

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

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

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

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

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

На втором уровне безопасности предусмотрено обнаружение нарушений, а начиная с третьего – реагирование на нарушения.

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

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

• путем обеспечения устойчивости модуля к нештатным внешним условиям (например, модуль должен нормально работать при температурах от ‑10⁰ до +50⁰ градусов).

Эксплуатационное окружение. Эксплуатационное окружение – это совокупность необходимых для функционирования модуля средств управления аппаратными и программными компонентами. В стандарте FIPS 140‑2 рассматривается несколько видов окружения:

• универсальное, с коммерческой операционной системой, управляющей как компонентами модуля, так и другими процессами и приложениями;

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

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

Ядром универсального и модифицируемого окружения является операционная система.

На первом уровне безопасности к ней предъявляются следующие требования:

• должен использоваться только однопользовательский режим, параллельная работа нескольких операторов явным образом запрещается;

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

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

• целостность ПО модуля должна контролироваться утвержденными средствами.

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

Характерная черта третьего уровня безопасности – использование доверенного маршрута.

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

Управление криптографическими ключами. Требования безопасного управления криптографическими ключами охватывают весь жизненный цикл критичных данных модуля. Рассматриваются следующие управляющие функции:

• генерация случайных чисел;

• генерация ключей;

• распределение ключей;

• ввод/вывод ключей;

• хранение ключей;

• обнуление ключей.

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

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

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

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

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

Модуль должен ассоциировать введенный ключ (секретный или открытый) с владельцем (лицом, процессом и т.п.).

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

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

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

• тесты криптографических алгоритмов;

• контроль целостности программного обеспечения;

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

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

• проверка взаимной согласованности парных ключей;

• контроль загружаемых программ;

• контроль ключей, вводимых вручную;

• тест генератора случайных чисел;

• тест режима обхода.

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

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

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

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

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

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

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

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

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

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

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

• сводка требований к документации;

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

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

Заключна частина

Існуюча нормативно-правова база криптографічного захисту інформації в цілому відповідає вимогам світових підходів щодо законодавства у цій сфері, створює надійне підґрунтя для забезпечення ефективної діяльності в цій галузі, гармонійне враховує інтереси суб’єктів системи КЗІ та всебічно розглядає їх права та обв’язки.

Оскільки система КЗІ динамічно розвивається, то нормативна правова база діяльності також зазнає постійних змін, що потребує від дослідників, розробників, виробників та користувачів засобів та систем КЗІ постійного вдосконалення рівня правової підготовки та врахування останніх змін у повсякденній діяльності.