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 года и отозван 25 мая 2002 года^[5]. Этот стандарт разрабатывался рабочей группой, состоявшей из представителей государственных структур и производителей криптографического оборудования. Группа определила четыре «уровня безопасности» и одиннадцать «областей требований», указанных выше, и установила нормативы по каждой области для каждого уровня.

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

FIPS 140-3, утверждённый 22 марта 2019 года и анонсированный^[7] в мае 2019 года, действует в течение переходного периода с замещением FIPS 140-2 и согласован с двумя международными стандартами: ISO/IEC 19790:2012(E) «Информационная технология — Технические методы безопасности — Требования к криптографическим модулям» и ISO/IEC 24759:2017(E) «Информационная технология — Технические методы безопасности — Требования к тестированию криптографических модулей». В первом проекте стандарта^[8] NIST предложил новый раздел по программной защищённости, дополнительный уровень доверия (уровень 5), а также требования по противодействию атакам Simple Power Analysis (SPA) и Differential Power Analysis (DPA). Однако проект от 11 сентября 2009 года вернулся к четырём уровням, ограничив программные реализации первыми двумя.

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

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