История ГОСТ-профилей и безопасная миграция между поколениями¶

Многие системы хранят подписи, ключи и сертификаты годами. Поэтому устаревающий алгоритм нельзя просто «выключить в одном RPM»: он может быть необходим для проверки исторического архива. В то же время поддержка старого алгоритма для чтения или проверки не означает разрешения создавать новые защищённые объекты с ним.

Основные поколения¶

Поколение	Примеры документов	Что менялось	Где применяется
Ранние ГОСТ	ГОСТ 28147-89, ГОСТ Р 34.11-94, ГОСТ Р 34.10-2001	Параметры старых шифров/подписей и идентификаторы	Архивные CMS, X.509, исторические протоколы
Современные алгоритмы	ГОСТ Р 34.10-2012, 34.11-2012, 34.12-2015	Новые подписи, хэши, «Кузнечик»/«Магма»	Новые протокольные профили и системы
Расширенные режимы	MGM, ACPKM, KDF, VKO	Аутентификация сообщений и управление ключами	TLS, IPsec, CMS, специальные сети
Специализированные публикации	RFC 9558, 9906, 9846; Р/МР 2024–2026	Вывод старых профилей, обновление форматов и требований	DNSSEC, TLS, промышленность, CMC

RFC 9906 — конкретный пример deprecation: старый ECC-GOST DNSSEC выводится из применения; отдельный ГОСТ-2012 RFC 9558 не отменяется. Для CMS RFC 4490 следует рассматривать в историческом контексте и сверять с Р 1323565.1.025-2019. Для TLS 1.3 RFC 9846 заменил RFC 8446, сохранив номер версии протокола; это не означает автоматического появления ГОСТ-профиля во всех TLS-серверах.

Как проводить миграцию¶

Инвентаризация архивов и клиентов
         |
         v
Карта: ключи, OID, режимы, протоколы, версии ПО
         |
         v
Новые ключи и сертификаты / допустимый переходный режим
         |
         v
Двусторонние положительные и отрицательные тесты
         |
         v
Публикация нового профиля и постепенное отключение записи в старом
         |
         v
Сохранение средств чтения исторических данных по политике

Миграция подписи и сертификатов¶

Новый ключ ГОСТ Р 34.10-2012 должен генерироваться в нужном параметрическом профиле; старую подпись нельзя преобразовать заменой OID. Для подписанных CMS-архивов важно сохранить исходные байты подписанного документа, сертификаты, свидетельства статуса на релевантный момент и, где требуется, доказательства времени. Удаление старого crypto-backend до архивации этих свидетельств создаёт риск невозможности верификации.

Миграция зашифрованных дисков¶

Смена XTS на DEC или одного шифра на другой не производится редактированием crypttab либо заголовка LUKS2. Требуется отдельное безопасное создание/миграция данных и проверенная резервная копия. Для корневого тома добавляется проверка поддержки алгоритма в initramfs и сценария восстановления. Руководство хранения.

Миграция VPN¶

Смена PSK на X.509 требует CA, выдачи сертификатов, проверки CRL/OCSP и политики отказа; простая замена аутентификации в конфиге недостаточна. При переходе ГОСТ IKEv2 нужно зафиксировать точные transforms, время rekey, маршруты, firewall и безопасное восстановление. Подтверждённый профиль системного strongswan-6.1.0-1.niceosc5 описан в руководстве IKEv2.

Что считать завершением¶

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

Источники¶

Каталог ТК26 · RFC 4490 · RFC 9215 · RFC 9558 · RFC 9906 · RFC 9846 · матрица совместимости.