Криптографические стандарты для IT-инженера

Криптографические стандарты, которые нужно знать каждому IT-инженеру - FIPS, Suite B, CNSA

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

Некоторые из этих стандартов касаются практически любой IT-системы, не являясь жёстко “отраслевыми”, поэтому работающему с security-решениями нужно хотя бы рамочно ориентироваться в оных.

Данная статья – краткая выжимка из рассказываемого на курсе Microsoft 2821B, поэтому может рассматриваться как доп.материал для тех, кто нуждается в более глубоких знаниях, чем дающихся на ознакомительных и базовых курсах уровня MCSE / CCIE:Security.

Криптографические стандарты, которые нужно знать каждому IT-инженеру

Начнём.

FIPS 140-1 и FIPS 140-2

FIPS – это Federal Information Processing Standards, разрабатываемые для формализации требований к криптографической защите информации в гос.органах США. Чтобы какое-либо ПО или оборудование могло быть сертифицировано для использования в этих структурах – ну либо связанных с ними – должна быть возможность работы в “FIPS-режиме”.

На данный момент существует 2 принятых версии стандартов FIPS – FIPS 140-1 (с января 1994 года) и FIPS 140-2 (с мая 2001 года) – и рассматриваемый с 2009 года FIPS 140-3.

FIPS не содержит новых стандартов или криптоалгоритмов – он, фактически, задаёт “нижнюю планку”, в явном виде указывая “такой алгоритм использовать нельзя, слабоват” и подобное. Включение FIPS-совместимости не добавляет функционала, а отключает часть возможностей системы.

Включение FIPS 140-1

Совместимость с данным стандартом появилась ещё в древних версиях Windows NT – иначе бы эта ОС не стала основной используемой в американских гос.учреждениях.

Вот так выглядит штатная настройка Windows по включению совместимости с FIPS 140 на уровне ОС:

Настройка FIPS-140 в WindowsНастройка FIPS-140 в Windows
(кликните для увеличения до 989 px на 530 px)
Учебный центр Advanced Traininginfo@atraining.ru

После этого действия все встроенные криптографические модули – CryptoAPI, SCHANNEL (но не сборки .NET, например – т.к. их технически сложно отдать в NIST на валидацию FIPS-совместимости) будут работать исходя из требований FIPS 140. С самим текстом стандарта, если что, можно ознакомиться вот здесь.

Теперь немного про специфику применения FIPS-140 в различных подсистемах Windows и ПО.

FIPS 140-1 и EFS

Включение FIPS 140-1 меняет работу встроенной в NTFS 3.0 системы криптографической защиты объектов файловой системы, известной как EFS – Encrypting File System.

Если речь идёт о NT 5.0 / 5.1 SP0 (то есть от Windows 2000 до Windows XP с SP1), то для шифрования EFS используется алгоритм DESX (не обычный DES, это грубая ошибка – именно DESX, потому что уже на момент разработки NT 5.0 есть работы, показывающие, что использовать DES с эффективной длиной ключа в 56 бит для долгосрочного хранения информации небезопасно), использующий до 192 бит ключевого материала, но фактически представляющий из себя обычный DES с 56 эффективными битами ключа, к которому добавляется 2 дополнительных операции – предварительный XOR с первыми 64 битами ключевого материала и, после шифрования, дополнительный XOR с другими 64 битами ключевого материала. Человеческое название DESX – это “DES с забеляющей перестановкой”. В реализации Microsoft Windows данный алгоритм использует 128 бит, т.е. генерится ключевой материал, первой половинкой которого XOR’ят до DES’а, а второй – после.

После включения FIPS 140-1 EFS начинает использовать 3DES. Меняется, в итоге, сам алгоритм – он становится более стойким, т.к. делается не 2 раза XOR и 1 раз DES, а 3 раза DES.

Используемый в данный момент алгоритм можно увидеть вот по такому адресу:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\EFS\AlgorithmID

Впрочем, начиная с Windows XP SP1 шифрующая файловая система EFS будет использовать алгоритм AES и включение режима FIPS 140-1 будет давать удивительный побочный эффект – возврат с AES на менее стойкий 3DES. Это получается, потому что реализация криптоалгоритма AES, используемого в EFS в NT 5.1 и 5.2, вбита отдельным модулем в ядро Windows, а не реализуется через обычную схему модулей CryptoAPI. То есть это явный “костыль”, добавленный “сбоку” и не прошедший гос.сертификацию. В NT 6.x это уже поправлено и AES работает штатно и для всей системы и ПО – эта “интеграция” всей криптографии в CNG является одним из тех моментов, благодаря которым Vista стала использоваться в американских гос.структурах.

FIPS 140-1 и Bitlocker

В NT 6.0 фирма Microsoft реализует, в добавление к существующему EFS, механизм шифрования целых разделов – BitLocker.

Из-за того, что один из способов аварийного восстановления доступа к зашифрованному диску – в частности, схема “у нас компьютер входит в домен Active Directory, включаем BitLocker и храним пароль восстановления раздела диска в объекте AD DS, поэтому можем разблокировать в случае любых проблем с данной машиной” – не являлся сертифицированным FIPS (потому что сертификация такого метода влечёт за собой по сути сертификацию всего кода Active Directory), был распространён слух “Microsoft’овский BitLocker небезопасен, потому что раз когда FIPS правительственный включаешь, то битлокер глючит – а значит правительство США не доверяет Microsoft”.

Это не так – BitLocker официально сертифицирован по FIPS 140, просто реализация механизма отправки ключа “наружу” не подпадала под FIPS. Что, в скором времени, было исправлено – поэтому пользуясь ОС NT 6.2 и выше данная тема не особо интересна; BitLocker работает и хранит ключи в Active Directory и без FIPS 140, и с FIPS 140.

Различия в работе BitLocker, впрочем, будут:

  • BitLocker на обычной системе может использовать AES-128 и AES-256 (оба варианта в CBC-режиме), плюс дополнительно включать diffuser – подробнее про всё это можно почитать здесь);
  • BitLocker на системе с включённой FIPS 140-совместимостью может использовать только AES-256 без diffuser (т.к. алгоритм Elephant, который используется в diffuser’е, не сертифицирован FIPS);

FIPS 140-1 и SSL/TLS

Всё просто – FIPS 140-1 исключает использование SSL 2.0 / 3.0, и минимальным используемым протоколом будет TLS. На данный момент это ограничение ничем не чревато, т.к. не-поддерживающих даже TLS 1.0 систем по сути не осталось. Но если где-то всё же есть что-то, к чему надо подключаться по SSL 3.0 – включение FIPS 140-1 сделает работу невозможной.

Для понимания причин, почему включение FIPS 140-1 исключает SSL, нужно просто посмотреть состав cipher suites в SSL:

  • SSL_RC4_128_WITH_MD5
  • SSL_DES_192_EDE3_CBC_WITH_MD5
  • SSL_RC2_CBC_128_CBC_WITH_MD5
  • SSL_DES_64_CBC_WITH_MD5
  • SSL_RC4_128_EXPORT40_WITH_MD5
  • SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA

Т.е. нигде в самом стандарте FIPS 140 не указывается “Нельзя использовать SSL” – просто использование для MAC алгоритмов класса Secure Hash исключает возможность согласовать что-либо из вышеприведённого комплекта, кроме последнего пункта. А он не может использоваться из-за отсутствия в FIPS 140 указаний на использование Fortezza. В результате – ничего из SSL согласовать просто не получится.

FIPS 140-1 и RDP

В ранних версиях протокола RDP был выбор – использовать “родной” Microsoft’овский протокол защиты, или работать поверх TLS 1.0 (после – TLS 1.2). Если точнее, то для подключения к RDP-серверу по TLS нужен как минимум NT 5.2 со стороны сервера и RDP 5.2 со стороны клиента (это Windows Server 2003 и Windows XP).

При включении на уровне системы режима “разрешены только FIPS-совместимые алгоритмы”, равно как и указании в настройках RDP “использовать FIPS-шифрование”, можно будет использовать только вариант защиты RDP over TLS.

FIPS-безопасность RDP также предсказуемо будет обозначать то, что для всех задач вычисления MAC будет использоваться SHA-1, т.к. FIPS 140-1 исключает использование хэш-функций семейства Message Digest (MD2, MD4, MD5), а для шифрования с секретным ключом – 3DES. Поэтому как и в предыдущем случае с cipher suites, подмножество оных, доступное для RDP over TLS, будет сокращено из-за FIPS-ограничений на криптоалгоритмы.

Неочевидные побочные проблемы от включения FIPS-140

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

Пример такого ПО среди продуктов Microsoft – это Sharepoint. В Sharepoint, начиная с самых ранних версий, GUID создаются путём обработки функцией MD5 псевдослучайных чисел; в результате, включение FIPS-совместимости приводит к невозможности выполнения задачи по созданию GUID’ов. Также MD5 используется в механизме индексирования данных Sharepoint, и для работы с SPFile.

Впрочем, уровень американской коррупции позволил выпустить специальную фетву, которая объясняла, что если на хосте с Windows Server работает Sharepoint, то включать FIPS необязательно – даже если речь идёт о хосте внутри сети АНБ или правительственной структуры; мысль акцентировалась на том, что Sharepoint не использует MD5 для шифрования данных (даже интересно, а кто использует MD5 для ШИФРОВАНИЯ, лол) и для передачи оных. Доказав, что Sharepoint не использует небезопасную функцию в данных двух применениях, эксперты при правительстве США (кстати, по удивительному совпадению, получающие зарплату от фирмы, являющейся партнёром Microsoft), сделали заключение, что не-включение FIPS на отдельно взятых хостах не влияет на безопасность всей системы в целом. Риторический вопрос “ну давайте тогда смасштабируем этот тезис на остальные хосты и спросим, зачем тогда вообще вся эта канитель с сертификациями и стандартами” ни у кого не возник, т.к. не был оплачен спонсором исследования.

Если вы думаете, что всё это касается только “старых версий продуктов, надо просто обновиться и всё” – то будет интересным узнать то, что, например, Microsoft SQL Server Integration Service (SSIS) для SQL Server 2016, имеют проблемы с развёртыванием в случае включения FIPS-совместимости. То есть через 17 лет после появления опции “отключить разные криптоалгоритмы, например MD5” в продукте из комплекта SQL Server 2016 используется функция MD5.

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

FIPS 140 и сетевое оборудование

Сетевого оборудования – тьма, и сертификация на FIPS 140 охватывает как само оборудование, так и отдельные модули для него, а также ПО. У целевой системы всё это должно соответствовать нужным требованиям и работать друг с другом по предсказуемым алгоритмам.

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

С примером официального документа, описывающего, как правильно использовать FIPS 140-совместимые алгоритмы на сертифицированном оборудовании Cisco – в частности, на роутерах Cisco 1905, Cisco 1921, Cisco 1941, Cisco 2901, Cisco 2911, Cisco 2921 – можно ознакомиться здесь. Говоря кратко, никакой “специальной настройки включения FIPS 140”, как в Windows, там нет – надо просто выключить лишнее и включить нужное (это вообще очень дельный подход). Общие сведения о деталях реализации FIPS 140 на оборудовании Cisco есть вот на этой странице.

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

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

Ничего подобного. Это – официальная мера безопасности у Cisco ISR 2901 в американских гос.структурах, состоящая в покупке фирменного скотча FIPS-SHIELD-2901= и применении оного на устройстве. Стоит эта штука – я про наклейки, да – несколько сотен долларов, и нанесение оной – часть реализации мер стандарта FIPS 140-2, выполняемой авторизованным персоналом, обладающим профильными сертификациями. Без этого система небезопасна. Можете представить себе, что бы было в российских “околоайтишных” и “хайтеховых” СМИ, если бы подобное – что по самому действию “массово заклеить порты на цисках”, что по стоимости “специального скотча” – было бы выставлено как часть мер IT-безопасности на гос.уровне.

FIPS 140 и СПО

Одним из частых заблуждений среди технически малограмотных адептов секты “свободного и открытого американского программного обеспечения” является что-то типа такого:

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

Хорошо что есть открытое ПО, где простые анонимные эксперты, к которым я отношусь ибо ощущаю сопричастность, постоянно вычитывают код и не допустят того, чтобы в нём были ошибки и закладки.

Поэтому достаточно вместо продукции американской фирмы A, заклеймлённой как “не-свободная и не-открытая”, купить продукцию американской фирмы B, которую кто-то из знаковых фигур нашей религии одобрил как религиозно верную и правильную, свободную и открытую (т.е. подпадающую под американскую лицензию Истинно Верной Свободы ПО, принадлежащую гражданам США и могущую быть изменённой ими в любой момент по своему усмотрению), и всё будет хорошо. Любые затраты на продукцию американской фирмы B не считаются таковыми, ведь это против Системы – никаких денег (не моих, а владельца бизнеса, которого разводят на эти затраты, конечно) не жалко.

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

Мы можем взять для примера, пожалуй, самую популярную открытую криптобиблиотеку OpenSSL и заметить, что у неё существует специальная FIPS-версия, часть которой прошла гос.сертификацию США и поэтому может быть использована в State/Fed/Gov/Mil целях.

Разрабатывает данное ПО не аморфная и анонимная группа тайных хакеров, а конкретный перечень физических лиц, сотрудничающих с правительством США и подписывающих от своего лица обязывающие документы. Реализация конкретных алгоритмов, а также тестирование и доработка, делается ими, а не неким “СПО-сообществом” – которое, в своей массе, не отличает хэширование от шифрования.

После реализации программного кода он отдаётся в американские гос.структуры на валидацию – по сути, идентичную российской сертификации криптосредств. И, будучи подтверждённым с формулировкой “всё правильно реализовали”, фиксируется и не может быть изменён без письменного разрешения американского АНБ. В случае нарушения – уголовное преследование.

Ещё раз – никакие статусы “открытости” и “свободы” не могут перекрыть законодательство конкретной страны США и подпадающую под регулирование деятельность конкретных физ.лиц и организаций на территории этой страны. Если вы хотите, чтобы ваше ПО вообще рассматривалось как кандидат на использование в инфраструктурных организациях государства, то вы выполняете то, что скажут регулирующие органы. Даже если они, как NIST, прикажут вам добавить признанные небезопасными эллиптические кривые. Потому что сказки про Свободу и Открытость – это одно, а невыполнение требований регулятора – это немного другое. С реальными сроками, вкупе с “организованным преступным сообществом” и “по предварительному сговору”.

Используя “открытую реализацию американского криптоалгоритма” вы используете то, что в явном виде разрешила американская гос.структура с названием АНБ. От факта теоретической доступности исходного кода никак автоматически не возникают практические навыки анализа существующих и разработки собственных криптоалгоритмов – что легко доказывается тем, что на практике в СПО ничего из не-одобренного АНБ не используется. Никакие байки про теоретическую возможность отредактировать исходный код не могут ставить под угрозу безопасность систем государства, поэтому теоретическая возможность этого – она отдельно от практической реализации.

Включать ли поддержку FIPS 140-1?

Сейчас, в 2018 году, это не имеет смысла, потому что проще отключить возможность согласования слабых криптоалгоритмов у определённых протоколов связи. Нет смысла включать FIPS 140-1, чтобы глобально убить функцию MD5 – проще, допустим, в рамках настройки SSL/TLS исключить те cipher suites, в которых она используется. Включая поддержку FIPS 140-1 вы разрешаете использовать только явно разрешённые реализации известных и протестированных на момент принятия этого стандарта (1994 год) криптоалгоритмов.

Впрочем, стандарт нельзя отнести к “вообще устарел” – в нём есть некоторые интересные до сих пор штуки – например, критерии проверки RNG на качество – известные как Monobit / Poker / Runs / Long Run тесты – до сих пор интересны для изучения и позволяют оценить качество работы RNG в до-NIST-SP-800-90B-времена.

FIPS 140-2

FIPS 140-2 – актуальная на момент написания статьи (февраль 2018 года) версия FIPS-140.

Стандарт состоит из нескольких документов:

Если вы сейчас решили, что дальше будет “Война и Миръ” по объёму, то это не так. Будет максимум такое:

Гарри Поттер и FIPS 140Гарри Поттер и FIPS 140
(кликните для увеличения до 520 px на 670 px)
Учебный центр Advanced Traininginfo@atraining.ru

(замечу, что одну из полезных книг про реализацию FIPS 140 для программистов действительно написал человек с фамилией Potter, поэтому картинка выше – не совсем шутка).

Различия между FIPS 140-1 и 140-2 можно посмотреть вот здесь.

Если совсем кратко, то начиная с ядра NT 6.0 в Windows появляется новая версия CryptoAPI – известная или как CAPI 3.0 или как CNG (криптография следующего поколения – Next Generation). И включение режима FIPS 140 уже обозначает совместимость с ней, а не с первым вариантом. То есть путаницы “включил не тот фипс140” у вас не возникнет – до NT 6.0 одна версия стандарта, с NT 6.0 – другая. Это нововведение, кстати – речь про CNG – стало одним из ключевых (вторым был новый сетевой стек с интегрированным IPv6, IPsec и Advanced Firewall’ом), благодаря которым Microsoft смогла продать Vista и Windows Server 2008 в американские гос.структуры – т.к. это были первые ОС с полноценной поддержкой всех-всех-всех новых требований АНБ. Конечно, появились слухи о том, что одни и те же лица и владели системными интеграторами, оказывающими консалтинговые услуги по внедрению в госы, и принимали участие в разработке стандартов, а следовательно где-то за год точно знали что попадёт в финальный вариант, но это, конечно, клевета – как можно представить, чтобы в США крупная корпорация, гос.структуры, системные интеграторы и ребята из АНБ пилили госбюджет? Уму непостижимо же.

Для нас ключевым будет то, что в стандарте FIPS 140-2 появляется поддержка криптографии с эллиптическими кривыми (ECDH, ECDSA) и MAC-алгоритмов семейства SHA-2 – полновесных SHA-2/256 и SHA-2/512 и их урезанных вариантов SHA-2/224 и SHA-2/384 – поэтому они могут применяться в FIPS-решениях. Старые алгоритмы, впрочем, не вычёркиваются – SHA-1 и TDEA (Triple DES Encryption Algorithm) остаются разрешёнными к применению.

Также появляется более строгий критерий оценки RNG – потом, впрочем, вносится корректировка, и его отменяют вообще как класс.

Есть ли какой-то особый переход между FIPS 140-1 и FIPS 140-2?

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

Приложение А к FIPS 140-2 обновляется, поэтому имеет смысл отслеживать актуальную версию – например, с 2015 года разрешёнными для FIPS-140 являются хэши семейства SHA-3 – это SHA3-224, SHA3-256, SHA3-384, SHA3-512, а также их XOF’ы – SHAKE128, SHAKE256.

Тонкость хранения настроек FIPS 140-1 и FIPS 140-2

Параметр “Включён ли FIPS-140 на уровне системы” хранится в реестре Windows NT. Однако, при переходе версий ОС с ядра NT 5.x на NT 6.0, где параллельно “совместимость с FIPS 140” стала обозначать не валидацию по FIPS 140-1, а FIPS 140-2, изменился ключ, в котором хранится этот параметр. Наша утилита ATcmd позволяет увидеть это наглядно, выводя оба значения ключа:

FIPS-140 в NT 5.x и NT 6.xFIPS-140 в NT 5.x и NT 6.x
(кликните для увеличения до 676 px на 557 px)
Учебный центр Advanced Traininginfo@atraining.ru

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

Это значит, что если у вас в сети и Windows XP, и Windows 7, то вы не сможете раздачей одного значения одного ключа реестра массово включить/выключить FIPS-140. Надо будет учитывать, что NT 5.x хранит параметр “Включён ли FIPS 140-1” в одном месте, а NT 6.x параметр “Включён ли FIPS 140-2” в другом.

FIPS 140 и Kerberos

Поддержка протокола Kerberos пятой версии появляется в NT 5.0 и считается одним из ключевых нововведений Active Directory. При этом Microsoft, в плане безопасности, сразу же делает шаг вперёд, и стандартным способом шифрования содержимого kerberos ticket’ов делает не DES, а RC4-128. То есть на момент выхода Windows 2000 в ней наиболее продвинутая реализация Kerberos, и для взаимодействия с *nix-системами нужно делать специальные шаги по снижению безопасности леса Active Directory.

На тот момент ситуация с поддержкой Kerberos’ом шифрования в NT 5.0 выглядит так – классический RFC 1510 плюс RC4. То есть это:

  • DES_CBC_CRC
  • DES_CBC_MD5
  • RC4_HMAC_MD5

Говоря проще, получается, что Kerberos вообще не может работать в режиме FIPS 140, т.к. из арсенала доступных способов шифрования ticket’ов у него просто нет ни одного варианта, подпадающего под FIPS 140. Выход предлагается простой – закрыть весь трафик Kerberos транспортным правилом IPsec, в котором для шифрования трафика будет использоваться 3DES, который разрешён FIPS 140. Притом это “костыль” чисто Windows-реализации Kerberos – потому что вообще в стандарте есть варианты:

  • DES3-CBC-SHA1
  • DES3-HMAC-SHA1

, которые позволяют работать в рамках FIPS 140-1. Но в Windows их реализации нет.

С появлением NT 6.0 ситуация упрощается, т.к. среди поддерживаемых для защиты данных Kerberos протоколов появляются ещё два:

  • AES128_HMAC_SHA1
  • AES256_HMAC_SHA1

С ними уже проще – AES разрешен в принятой на момент выхода NT 6.0 версии FIPS 140-2 – поэтому можно сделать всю работу Kerberos в лесу Active Directory FIPS-совместимой штатными способами, не прибегая к костылям.

Перейдём к FIPS-180 – там совсем чуть-чуть.

FIPS 180

Стандарты линейки FIPS 180 появляются аж с 1993 года и обновляются до сих пор. Текущая версия – FIPS 180-4.

Этот документ стандартизирует все SHS – Secure Hash Standard’ы, а говоря проще – описывает все функции хэширования, начинающиеся с аббревиатуры SHA. От самой первой SHA-1 до 64х битовой SHA-512/t.

Соответственно, какого-либо “тумблера, включающего FIPS 180 на системе” нет. Если ПО поддерживает новые варианты SHA-x – то они реализуются в соответствии с технической документацией FIPS 180. Если нет – то ПО не поддерживает новые варианты SHA-x.

Заметим, что SHA-3 стандартизируются в другом FIPS – 202м. Одна из причин этого в том, что используемый алгоритм “кеччак” достаточно ощутимо отличается от используемого в MD4-5-SHA-0-1-2 принципа работы хэш-функций.

Что ж, теперь к “Комплекту Б”.

NSA Suite B

Начнём с главного вопроса.

Что стало с NSA Suite A?

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

Дело в том, что “АНБшный комплект криптографии номер один” существует только для защиты американских данных категории, похожей на нашу “совершенно секретно”. Это значит, что использование входящих в Suite A алгоритмов в коммерческих продуктах – штучное исключение, и только в ситуации продукции двойного назначения. Несмотря на популяризируемый ложный тезис “ахаха зачем скрывать-то опубликуйте исходничек да там сто миллионов ребят набежит и сразу баги найдёт и безопасность только подымет” серьёзная безопасность – как и серьёзные деньги – любит тишину. Вы можете столкнуться с такими алгоритмами, входящими в Первый Комплект, как:

  • BATON – замечательный и быстрый алгоритм симметричного шифрования, с бронебойным ключом в 320 бит, половина из которых отдана на проверку целостности ключа (как у DES, только не 56/64, а 160/320); используется, например, в закрытой американской реализации IPsec, называемой HAIPE-IS и используемой для защиты сетей АНБ и Госдепа;
  • ACCORDION – который любит компания Harris, выпускающая тактическое оборудование;
  • Enhanced FIREFLY – интересный алгоритм генерации ключевого материала, относящийся к классу алгоритмов с открытым ключом и используемый, например, в гигабитном армейском роутере KG-245A, стоящем на вооружении НАТО;

Шучу, не можете. Чтобы столкнуться – надо будет действительно пересекаться с серьёзными решениями по безопасности, а не выискивать “в каком авторизованном УЦ подешевле купить цисковский серт по секурити, чтобы не морочиться с зазубриванием дампов”, обсуждая данную животрепещущую проблему в каком-нибудь “сообществе экспертных экспертов по корпоративной безопасности”, которые это уже сделали, и теперь обсуждают “как накатить конфигу на файрвол на лине через айпишник”. Выйти, так сказать, из зоны комфорта, не зайдя потоптать другую.

Говоря без стёба, все алгоритмы из Suite A – чисто армейские и для внутриамериканских задач. Смеющимся над импортозамещением – “ахаха тупая рашка зачем-то свои криптоалгоритмы делает ведь весь мир пользуется американскими широко распространёнными в массовых ОС алгоритмами и всё норм” будет неплохо узнать, что для публики в США используется одно, а для действительно серьёзных задач – другое. Серьёзных – это не защита платежей с пластиковых карт и шифрование данных от жены на флэшке с Bitlocker’ом, а, допустим, оперативное командование армейскими подразделениями. Сами себя т.е. импортозаместили первым делом, сделав варианты “для белых людей” и “для остальных”.

Зачем же тогда NSA Suite B?

NSA Suite B

“Второй Комплект” стандартизируется в 2005 году и проще всего описывается цитатой из первоисточника, АНБ:

The entire suite of cryptographic algorithms is intended to protect both classified and unclassified national security systems and information. Because Suite B is also a subset of the cryptographic algorithms approved by the National Institute of Standards and Technology, Suite B is also suitable for use throughout government. NSA’s goal in presenting Suite B is to provide industry with a common set of cryptographic algorithms that they can use to create products that meet the needs of the widest range of U.S. Government (USG) needs.

Это в общем для задач “попроще”, но государственных, а следовательно важных. Suite B явно задаёт планку настроек для ситуации “надо использовать какой-то из распространённых протоколов, но только закрутив гайки по максимуму”.

Что будет входить в NSA Suite B?

  • Шифрование с секретным ключом – это AES-128/256 (не 192! это, как ни странно, важный момент) в режимах CTR или Галуа;
  • ECDSA – для цифровой подписи;
  • ECDH – для совместной генерации ключевого материала;
  • SHA-2 не ниже 256 – для хэширования;

Всё остальное – выпадает. То есть это покруче FIPS 140, и ощутимо. Вообще выкидывается обычный DSA и весь DH – включая “толстые” группы с 4096 и 8192 битовыми ключами. Выкидывается SHA-1 и 3DES. Да, и иногда добавляемое “RSA – от 2048 бит” – неверно; фишка Suite B как раз в том, что NSA сказало, что RSA как таковой устарел и будущее – за эллиптическими кривыми.

Точные описания того, как именно настроить распространённые протоколы – например, IPsec или SSH – есть в соответствующих RFC, разработанных штатными сотрудниками АНБ (тут должна была быть шутка про сисадминствующих околоайтишных парней, которые свято уверены, что все RFC открыто пишутся и обсуждаются невидимыми анонимными любителями-экспертами, но мне лень её придумывать).

Вы можете натолкнуться на NSA Suite B, например, в Microsoft AD RMS – Active Directory Rights Management Services. Начиная с Windows Server 2008 R2 SP1, при развёртывании (да и в принципе после) доступен т.н. Cryptographic Mode 2, который использует для криптографических операций над документами алгоритмы, подходящие под NSA Suite B. Это очевидная штука, нужная чтобы можно было продавать продукцию Microsoft в гос.структуры и использовать встроенный IRM-механизм AD RMS без установки дополнительного ПО. Впрочем, точно так же как появляется возможность ставить это в американские гос.структуры, уходит возможность эксплуатации AD RMS в российских; ведь криптографический модуль у AD RMS, выходит, свой личный, а не “стандартный CryptoAPI’шный”, к которому можно прицепить стороннего криптопровайдера с нужным алгоритмом. Система получается не-модернизируемая и не-гибкая – впрочем, повторюсь – подходящая под критерии американских гос.структур.

Внедрять ли Suite B?

По сути, никаких отдельных и специальных процедур для этого нет. Вы можете громко назвать подъём нового CA с алгоритмами шифрования и хэширования у самоподписанного root-сертификата, подпадающими под критерии NSA Suite B как “внедрение Suite B”, но в общем-то вся эта тема – исключительно про подъём “нижней планки пригодных для использования алгоритмов”. Помните, что официально для работы с алгоритмами Suite B надо использовать как минимум Vista SP2 / Windows Server 2008 SP2 – с предыдущими ОС ничего не получится, Suite B – костылей для Windows XP банально нет и не будет.

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

Ну а мы пойдём дальше – к новым вершинам закручивания гаек.

Commercial National Security Algorithm Suite (CNSA Suite)

Домик для настоящих параноиков, которым страшно с Suite B – впрочем, учитывая, что в него входят ненадёжные NIST P256 и P384, это не параноики, а реалисты – находится на отдельном сайте Information Assurance Directorate, входящем в NSA. Не пугайтесь, что на него не захочет заходить браузер – там у парней свой самоподписанный армейский сертификат от DoD, который не входит в trusted root у Windows и других гражданских ОС. Все принципы открытости и прочего уже давно позади, так что такое в некоторых закоулках защищённых сетей скорее правило, чем исключение. Поставьте сертификат (вот отсюда, например) и сможете узнать некоторое новое и интересное.

Кратко задачи создания CNSA формулируются так – безопасная криптография в эру квантовых вычислений. Стандарт выходит через десяток лет после Suite B, поэтому неудивительно, что требования стали ещё жёстче.

Соответственно, CNSA – ещё большее усиление того, что есть в Suite B. В частности:

  • Шифрование с секретным ключом – AES-256;
  • Обмен и генерация ключевого материала – ECDH от P-384 и ECDSA от P-384;
  • MAC – SHA-2/384 и старше;
  • Классические, не-EC алгоритмы – DH и RSA – от 3072;

То есть это что-то типа Suite B с ещё большим завышением нижней планки – теперь нельзя использовать SHA-256, EC-кривые до 384 бит и у DH и RSA под запретом не только 1024 бита, но и 2048.

И – внимание! – CNSA не признаёт NIST P-521 как более стойкую, чем P384. То есть у всех трёх EC-кривых, добавленных NSA с десяток лет назад и появившихся в NT 6.0, проблемы – 256я и 384я недостаточно стойкие с точки зрения внешних исследователей, а 521я тихо перестала быть “самой безопасной из EC” с точки зрения родительской фирмы, АНБ.

CNSA – не умозрительный эксперимент по “максимальной безопасности”, а реальный уровень, на который структуры NSA и правительства США переходят с февраля 2016 года, считая Suite B недостаточным.

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

CNSA и WPA3

Грядущий вот-вот в 2018 году новый стандарт защиты беспроводных сетей – WPA3 – делается уже с учётом требований CNSA, что повлечёт за собой массу изменений буквально в каждом применении криптографии – от требований к алгоритмам с секретным ключом до использования нового Dragonfly при обмене ключевым материалом – впрочем, про это на отдельном вебинаре.

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

Удач!

Вернуться к полному списку статей Knowledge Base @ Advanced Training

Ruslan V. Karmanov

Зайдите на сайт под своей учётной записью, чтобы видеть комментарии под техническими статьями. Если учётной записи ещё нет - зарегистрируйтесь, это бесплатно.