Матрица совместимости ГОСТ: алгоритм, формат, протокол и испытание¶
Почему одного перечня шифров недостаточно¶
Вопрос «поддерживает ли система ГОСТ?» не является технически достаточным. Нужно уточнить, какую операцию, в каком формате, через какую библиотеку или ядро, с каким контрагентом и на какой версии. При этом результат одного теста нельзя автоматически переносить на все протоколы.
| Уровень | Пример НАЙС.ОС | Как доказать |
|---|---|---|
| Криптопримитив | kuznyechik, streebog256 |
Тестовый вектор, обнаружение алгоритма, операция |
| Режим | xts(kuznyechik) |
Encrypt→decrypt, тестовые векторы/границы |
| Подсистема ядра | dm-crypt | Открытие устройства, записи и чтение |
| Формат контейнера | LUKS2 | luksDump, сохранение доступа после закрытия |
| Формат документа | CMS SignedData | Проверка конкретного DER и подписи |
| Протокол связи | TLS 1.3 по RFC 9367 | Реально согласован ГОСТ-набор и сертификаты |
| VPN | IKEv2/ESP по RFC 9227/9385 | Обоюдный туннель, rekey, анти-replay |
| Сертифицированная система | СКЗИ партнёра | Конкретный профиль и результаты испытаний; отдельный регуляторный анализ |
Образец паспорта испытания¶
Для каждого проверенного сценария публикуют: цель, источник требований, версии систем, платформы/архитектуры, библиотек и ядра, конфигурацию, тестовые входные данные, ожидаемый результат, фактический результат, контрольные суммы и ограничения. Закрытые ключи, пароли и производственные сертификаты не публикуют.
Пример подтверждённого ранее испытания:
Функция: шифрованный тестовый LUKS2-том
Шифр данных: kuznyechik-xts-plain64
Ключевой материал XTS: 512 бит (два ключа по 256)
Операции: форматирование, открытие, ext4, запись, закрытие,
повторное открытие, контроль содержимого
Контрольный SHA-256 test.txt:
29b35eaf576cf79c37ca772ecf807de5bff93344fb8a0db65c361ca31fc53f49
Ограничение: испытан конкретный серверный стенд, не каждый
алгоритмический режим и не зашифрованный корень.
У испытанного LUKS2 шифр данных — ГОСТ-«Кузнечик» XTS, а алгоритмы защиты ключевого слота включали AES-XTS, Argon2id и SHA-256. Нельзя подменять это выводом о полностью ГОСТ-реализации всех компонентов контейнера.
Проверка нормативно-технической основы¶
Каждой функции сопоставляются: 1) профиль, 2) официальный документ, 3) его статус, 4) реализация, 5) тест. Например, документ о DEC не подтверждает реализацию XTS; документ о ГОСТ-TLS 1.3 не подтверждает работу Nginx; RFC о CMC не доказывает поддержку ГОСТ-выдачи сертификатов конкретным УЦ.
Что публиковать на docs.niceos.ru¶
Необходимо отделить страницы «Стандарт и теория» от страниц «Как настроить НАЙС.ОС», а экспериментальные интеграционные результаты — от общих возможностей поставки. Тогда справочник останется точным даже при смене ядра, криптобиблиотеки и версии клиента.
Полезные страницы: ГОСТ в ядре, ГОСТ и LUKS2, CMS и сертификаты, GOСТ-TLS 1.3, современный ГОСТ в IPsec.
Матрица: от заявления к факту¶
| Публичное заявление | Минимальная проверка | Недопустимый вывод |
|---|---|---|
| «Поддерживает Кузнечик» | Тестовый вектор/операция в указанной библиотеке | «Все протоколы используют ГОСТ» |
| «Поддерживает ГОСТ X.509» | Подпись, цепочка и параметры, CRL/OCSP по политике | «Поддерживает ГОСТ OCSP и CMC» |
| «Поддерживает ГОСТ IKEv2» | Полная IKE и CHILD SA, ESP, трафик, rekey, отказ | «Совместим с любым российским VPN» |
| «Поддерживает ГОСТ TLS 1.3» | Wire-level согласование RFC 9367, проверки имени и сертификата | «Есть gost-engine, значит TLS готов» |
| «Поддерживает ГОСТ DNSSEC» | DNSKEY/DS/RRSIG и цепочка доверия на тестовой зоне | «Любой DNS-запрос шифруется» |
| «Поддерживает ГОСТ LUKS2» | Реальный секторный шифр и повторное открытие | «Реализован режим DEC и ГОСТ-слот» |
| «Совместим с CMS партнёра» | Передача и проверка SignedData/EnvelopedData в обе стороны | «Любой ГОСТ CMS совместим» |
План испытаний каждого стандарта¶
- Зафиксировать первичный нормативный источник: номер документа, редакция, статус, обязательные параметры.
- Составить соглашение о профиле: шифры, режимы, группы, идентификаторы, OID, размеры ключей и теги, кодировки, цепочки, обработку исключений.
- Проверить наличие реализации в установленном ПО: RPM, зависимости, plugins/modules, конфигурация, служба.
- Провести положительный тест: совместимые стороны, успешная криптографическая операция, контроль ожидаемого результата.
- Провести отрицательные тесты: неправильный ключ/сертификат, порча подписи, истёкший CRL, несовместимая группа, отсутствие доверия, недоступный источник.
- Проверить жизненный цикл: повторные подключения, rekey/ротацию, восстановление, отказоустойчивость, обновления RPM и откат.
- Оформить свидетельство с датой и контрольными суммами артефактов; отделить PASS от
not-tested.
Измерения важнее общего статуса¶
Иногда общий профиль работает, но лишь на одном направлении. Поэтому обязательны тест обеих сторон, проверка входящих/исходящих счётчиков, вариации размеров пакетов/контейнеров, конфигурации с несколькими получателями/ключами, исчерпание лимитов и сетевые отказы. Сертификация СКЗИ требует отдельной процедуры и её нельзя заменить лабораторной матрицей.
Канонические справочники: ГОСТ в установленном RPM, протокольные профили, правила политики, ГОСТ IKEv2, CMS.