FIPS 140 - FIPS 140

Серия 140 Федеральных стандартов обработки информации ( FIPS ) - это стандарты компьютерной безопасности правительства США, которые определяют требования к модулям криптографии .

По состоянию на октябрь 2020 года FIPS 140-2 и FIPS 140-3 принимаются как текущие и активные. FIPS 140-3 был утвержден 22 марта 2019 г. в качестве преемника FIPS 140-2 и вступил в силу 22 сентября 2019 г. Тестирование FIPS 140-3 началось 22 сентября 2020 г., хотя сертификатов проверки FIPS 140-3 не было. выдано еще. Тестирование FIPS 140-2 по-прежнему доступно до 21 сентября 2021 года (позже оно было изменено для приложений, которые уже обрабатываются до 1 апреля 2022 года), что создает перекрывающийся переходный период в один год. Отчеты об испытаниях FIPS 140-2, которые остаются в очереди CMVP, по-прежнему будут получать проверки после этой даты, но все проверки FIPS 140-2 будут перемещены в Исторический список 21 сентября 2026 года, независимо от их фактической даты окончательной проверки.

Назначение FIPS 140

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

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

Программа проверки криптографических модулей (CMVP) осуществляется совместно Национальным институтом стандартов и технологий (NIST) правительства США и Управлением безопасности связи (CSE) правительства Канады. Правительство США требует использования проверенных криптографических модулей для всех несекретных видов использования криптографии. Правительство Канады также рекомендует использовать проверенные FIPS 140 криптографические модули в несекретных приложениях своих ведомств.

Уровни безопасности

FIPS 140-2 определяет четыре уровня безопасности, называемых просто от «Уровень 1» до «Уровень 4». В нем не указывается подробно, какой уровень безопасности требуется для того или иного конкретного приложения.

  • FIPS 140-2, уровень 1, самый низкий, предъявляет очень ограниченные требования; в общем, все компоненты должны быть «производственного уровня», и должны отсутствовать различные вопиющие виды ненадежности.
  • FIPS 140-2 уровня 2 добавляет требования к физической защите от несанкционированного доступа и аутентификации на основе ролей.
  • FIPS 140-2 уровня 3 добавляет требования к физической защите от несанкционированного доступа (что затрудняет доступ злоумышленников к конфиденциальной информации, содержащейся в модуле) и аутентификации на основе идентификации, а также к физическому или логическому разделению между интерфейсами, с помощью которых "критично". параметры безопасности "входят и выходят из модуля и других его интерфейсов.
  • FIPS 140-2 уровня 4 ужесточает требования к физической безопасности и требует устойчивости к атакам со стороны окружающей среды.

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

Объем требований

FIPS 140 предъявляет требования в одиннадцати различных областях:

  • Спецификация криптографического модуля (что должно быть задокументировано)
  • Порты и интерфейсы криптографического модуля (какая информация поступает и выходит, и как она должна быть разделена)
  • Роли, службы и аутентификация (кто что может делать с модулем и как это проверяется)
  • Модель с конечными состояниями (документация о высокоуровневых состояниях, в которых может находиться модуль, и о том, как происходят переходы)
  • Физическая безопасность ( свидетельство несанкционированного доступа и устойчивость , а также устойчивость к экстремальным условиям окружающей среды)
  • Операционная среда (какую операционную систему использует модуль)
  • Управление криптографическими ключами (генерация, ввод, вывод, хранение и уничтожение ключей)
  • EMI / EMC
  • Самотестирование (что и когда нужно тестировать, и что делать, если тест не прошел)
  • Обеспечение проектирования (какая документация должна быть предоставлена, чтобы продемонстрировать, что модуль был хорошо спроектирован и реализован)
  • Защита от других атак (если модуль предназначен для защиты , скажем, от TEMPEST- атак, в документации должно быть указано, как именно)

Краткая история

FIPS 140-1, выпущенный 11 января 1994 года, был разработан правительственной и отраслевой рабочей группой, состоящей из поставщиков и пользователей криптографического оборудования. Группа определила четыре «уровня безопасности» и одиннадцать «областей требований», перечисленных выше, и определила требования для каждой области на каждом уровне.

FIPS 140-2 , выпущенный 25 мая 2001 г., учитывает изменения в доступных технологиях и официальных стандартах с 1994 г., а также комментарии, полученные от поставщиков, тестировщиков и сообществ пользователей. Это был основной входной документ для международного стандарта ISO / IEC 19790 : 2006 Требования безопасности для криптографических модулей, выпущенного 1 марта 2006 года. NIST выпустил специальную публикацию 800-29, в которой излагаются существенные изменения с FIPS 140-1 на FIPS 140-2.

FIPS 140-3 , выпущенный 22 марта 2019 г. и объявленный в мае 2019 г., в настоящее время находится в перекрывающемся переходном периоде, чтобы заменить FIPS 140-2 и согласовывает руководство NIST с двумя международными стандартами: ISO / IEC 19790: 2012 (E) Информационные технологии - Методы безопасности - Требования безопасности для криптографических модулей и информационные технологии ISO / IEC 24759: 2017 (E) - Методы безопасности - Требования к тестированию криптографических модулей . В первой черновой версии стандарта FIPS 140-3 NIST представил новый раздел о безопасности программного обеспечения, один дополнительный уровень гарантии (Уровень 5) и новые требования к простому анализу мощности (SPA) и дифференциальному анализу мощности (DPA). Однако в проекте, выпущенном 11 сентября 2009 года, было возвращено четыре уровня безопасности и ограничены уровни безопасности программного обеспечения уровнями 1 и 2.

Критика

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

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

Смотрите также

использованная литература

внешние ссылки