Методика доказательства ГОСТ-совместимости и приёмки НАЙС.ОС¶
Документ нужен администратору, автору RPM, разработчику криптографического ПО и заказчику. Он превращает размытое заявление «ГОСТ поддерживается» в воспроизводимый технический паспорт, не подменяя официальную оценку соответствия и сертификацию.
Пять уровней доказательства¶
[1] Нормативный документ и профиль
|
[2] Реализация алгоритма и тест-векторы
|
[3] Протокольный обмен / формат данных
|
[4] Эксплуатация: ошибки, ротация, отзыв, сбои
|
[5] Конкретная версия, журнал и подпись результата
Наличие уровня 1 не доказывает уровни 2–5. Наличие работающей криптографической операции без проверки отзыва не доказывает корректность всей X.509-аутентификации. Наличие системного OpenSSL не доказывает поддержку ГОСТ-TLS 1.3 на проводе.
Паспорт испытания¶
| Поле | Что записать |
|---|---|
| Цель | Операция, профиль и сценарий эксплуатации |
| Нормативная база | ГОСТ, Р 1323565.1, RFC/раздел, версия документа |
| ОС | PRETTY_NAME, VERSION_ID, версия ядра, архитектура |
| Пакеты | Точные rpm -q версии и контрольные суммы конфигурации |
| Стороны | Идентичности и адреса испытания, независимые экземпляры клиента/сервера |
| Параметры | Кривая, ГОСТ-алгоритмы, OID, SA, nonce, формат ключа |
| Положительные проверки | Детальный результат, счётчики, TLS/IKE/CMS контекст |
| Отрицательные проверки | Подмена подписи, отзыв, сеть, несоответствие профилей |
| Восстановление | Ротация ключей/сертификатов, откат, перезапуск |
| Вывод | PASS/FAIL/NOT TESTED c датой и ограничениями |
Пример: системный ГОСТ IKEv2¶
Для испытанного НАЙС.ОС 5.2 на двух VM были подтверждены: IKE/ESP с ГОСТ, PSK и X.509, взаимная проверка CA, локальная подписанная CRL, успешный отзыв временного сертификата, отказ при отсутствии CRL и при недоступном HTTPS без кэша, восстановление туннеля. Использовался системный RPM strongswan-6.1.0-1.niceosc5, charon и swanctl, а не сборочная директория. Это не означает испытание всех реализаций VPN или протокола OCSP. Подробное руководство: ГОСТ IKEv2.
Пример: шифрование диска¶
Для kuznyechik-xts-plain64 показаны форматирование тестового LUKS2, запись, закрытие и повторное открытие. Это доказательство работы выбранного XTS-режима данных, но не DEC или полного ГОСТ-профиля метаданных. Проверки обсуждаются в дисковой главе и руководстве хранилищ.
Негативные проверки с реальным смыслом¶
Ошибка должна возникать по ожидаемой причине, а не потому, что упала служба, отсутствует маршрут или неверно указан путь к файлу. Например, отрицательный тест отзыва принимается только при журнале certificate was revoked, а не просто при initiate failed. Для HTTPS CRL нужны журналы сервера (время нового GET) и клиента (проверена CRL подписью CA). Для CMS нужна проверка ошибки подписи именно на испорченном содержимом и контроль корректного сертификата.
Воспроизводимость и разграничение¶
Не включайте закрытые ключи и реальные пароли в отчёты. Сохраняйте только открытые сертификаты, публичные тестовые ключи, обрезанные журналы, выходные счётчики и SHA-256 файлов, для которых публикация разрешена. Точные времена задаются с часовыми поясами. Если какой-либо блок не испытан (например, online OCSP), пишите NOT TESTED и пояснение вместо оптимистичного PASS.
Связанные главы: матрица совместимости, матрица поддержки алгоритмов, PKI, IPsec, проверка источников, векторы тестирования.