Как устроена криптография ГОСТ в электронных документах¶

Электронная подпись и зашифрованный документ — это не просто байты, обработанные алгоритмом ГОСТ. Для обмена между разными программами необходим согласованный формат криптографического сообщения. В нём записано, что именно подписано, каким алгоритмом вычислялся хэш, чей сертификат следует использовать, как получателю получить сеансовый ключ и как восстановить исходный документ.

Таким форматом является CMS (Cryptographic Message Syntax). Он используется при обмене подписанными файлами, в электронной почте S/MIME, в системах электронного документооборота и в некоторых архивных форматах. CMS определяет структуру сообщения; ГОСТ определяет применяемые криптографические операции и идентификаторы алгоритмов.

Маршрут чтения¶

Статья	Что станет понятно
Что такое CMS и как устроен контейнер	Чем отличаются подпись, шифрование, MAC и отсоединённое содержимое
Исторический профиль ГОСТ — RFC 4490	Как описывались ГОСТ 2001, ГОСТ94, ГОСТ 28147 и CryptoPro-профили
ГОСТ 2012 и проект рекомендаций ТК26	Как появились «Стрибог», ГОСТ Р 34.10-2012 и новые параметры CMS
Подписанные сообщения	Что реально проверяет электронная подпись, как читать `SignerInfo`
Зашифрованные сообщения и управление ключами	Что такое CEK, KEK, VKO, UKM и почему важно шифрование ключей
ASN.1, DER, OID и диагностика	Как прочитать структуру `.p7s`/`.p7m` без знания внутреннего двоичного формата
S/MIME и совместимость	Почему одинаковый ГОСТ ещё не означает совместимость приложений
Практическая проверка и типовые ошибки	Как безопасно исследовать полученный контейнер в НАЙС.ОС

Какие документы изучаем¶

RFC 4490 — опубликованный в мае 2006 года профиль использования ГОСТ 28147-89, ГОСТ Р 34.11-94 и ГОСТ Р 34.10-94/2001 в CMS. Он особенно важен для разбора исторических форматов.

Проект рекомендаций ТК26 «Использование алгоритмов ГОСТ … в криптографических сообщениях формата CMS» — первая редакция, апрель 2014 года, 37 страниц. В ней подробно рассматриваются ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012, VKO и S/MIME. Это именно проект, а не подтверждённая действующая окончательная редакция рекомендаций: в тексте указан предел актуальности проекта — январь 2015 года.

Для понимания самого формата полезен RFC 5652, а для современных ГОСТ-сертификатов — RFC 9215. Это разные уровни спецификации: общий синтаксис CMS, криптографический профиль и формат сертификатов.

Связь с НАЙС.ОС¶

В НАЙС.ОС CMS обрабатывается на уровне пользовательских криптографических библиотек и программ: OpenSSL, GnuPG/GPGSM, libksba и связанной с ними криптографии. Встроенные ГОСТ-алгоритмы ядра и LUKS2 — другая подсистема. Наличие «Кузнечика» в Kernel Crypto API само по себе не означает поддержку любого CMS-профиля в openssl cms.

Практические команды создания CMS находятся в разделе OpenSSL: CMS и S/MIME, разбор структур и сертификатов — в libksba: CMS, работа с gpgsm — в GnuPG: X.509 и CMS. В этой главе сосредоточены теория, чтение стандарта и понимание совместимости, чтобы не дублировать практические руководства.

Карта знаний: от математического алгоритма к защищённому документу¶

[Кузнечик / Магма] ──────┐
                        ├── [режим + ключ] ──> EnvelopedData ──> .p7m / письмо
[Стрибог] ──> [ГОСТ Р 34.10] ──────────────> SignedData ─────> .p7s / подпись
      │                       ↑                      │
      └──> [KDF / VKO] ───────┘                      ├── X.509 + цепочка + CRL/OCSP
                │                                   └── атрибуты + OID + DER
                └──> [обёртывание CEK]

ASN.1 / DER ──> байтовая совместимость;
S/MIME ───────> почтовая оболочка CMS;
RFC и Р 1323565.1.025-2019 ──> правила профиля;
ПО НАЙС.ОС ──> реализация и испытания, а не источник математического определения.

Что не следует считать эквивалентными понятиями

Одинаковое название «ГОСТ» ещё не означает одинаковый AlgorithmIdentifier, набор параметров, порядок байтов, профиль сертификата и способ создания RecipientInfo. Работающий шифр в Crypto API ядра не даёт автоматической поддержки CMS в OpenSSL. Наличие SignedData не доказывает юридической значимости подписи.

Выберите цель¶

Задача читателя	Теоретический материал	Практика НАЙС.ОС
Проверить подпись `.p7s`	SignedData, проверка доверия	OpenSSL CMS, GPGSM
Расшифровать документ `.p7m`	EnvelopedData, согласование ключей	OpenSSL CMS, libksba
Сопоставить две реализации	OID и DER, матрица совместимости	Обмен с КриптоПро
Понять риск подмены документа	модель угроз, SignedData	сценарии контроля
Разобрать почтовое письмо	S/MIME, CMS	OpenSSL S/MIME
Выбрать нормативную базу	история RFC 4490, ТК26 2014	Рекомендации 2019

Алгоритмы, форматы и протоколы — три плоскости¶

Математика. Стрибог формирует хэш, ГОСТ Р 34.10-2012 — подпись, Кузнечик — блочное шифрование, VKO — общий секрет. Каждый примитив имеет отдельный набор параметров и собственный первоисточник.

Контейнер. CMS хранит идентификаторы, получателей, подписантов и байтовое представление объектов. Его базовый синтаксис закреплён в RFC 5652, дополнительный authenticated-envelope — в RFC 5083.

Прикладной профиль. RFC 4490 описывает исторические комбинации ГОСТ в CMS (документ Standards Track). Р 1323565.1.025-2019 является действующими российскими рекомендациями по форматам защищённых сообщений. RFC 9215 определяет форматные правила ГОСТ-2012 для X.509, а не общую схему CMS.

Два маршрута изучения¶

Администратору: CMS → ASN.1 и OID → диагностика → проверка доверия → руководство OpenSSL.

Разработчику и интегратору: источники профилей → SignedData → EnvelopedData → S/MIME → матрица совместимости → модель угроз.

Правила сопровождения этой главы¶

Описание формата и его требований хранится здесь, описание шифра — на странице самого алгоритма, а команды — в руководстве программы.
Каждая спецификация сопровождается номером RFC или обозначением ГОСТ/рекомендаций; для проекта документа всегда явно указывается статус «проект».
В примерах различаются синтаксический разбор, криптографическая проверка, проверка цепочки доверия и организационное признание подписи.
Возможность конкретного установленного пакета следует брать из матрицы испытаний НАЙС.ОС, а не выводить из наличия OID.

Маршрут чтения: Устройство CMS → Подписи → Шифрование → Матрица интеграции