EnvelopedData: шифрование, получатели и VKO

Почему недостаточно зашифровать документ один раз

При шифровании большого файла проще использовать быстрый симметричный алгоритм и свежий ключ шифрования содержимого (CEK). Далее CEK защищают отдельно для каждого получателя. Так получатель может открыть контейнер своим закрытым ключом, не требуя пересылки общего секретного ключа вместе с документом.

Исходный документ
       │
       ├── случайный CEK ──► шифрование содержимого ──► encryptedContent
       │
       ├── получатель А: параметры / ключевой обмен ──► защита CEK для А
       └── получатель Б: параметры / ключевой обмен ──► защита CEK для Б

CMS EnvelopedData
├── RecipientInfo для А
├── RecipientInfo для Б
└── EncryptedContentInfo: алгоритм, параметры, encryptedContent

Такой способ называется гибридным шифрованием. В реальном CMS возможны разные способы управления ключами; приведённая схема объясняет типичный случай, а не каждую ветвь спецификации.

CEK, KEK, UKM: три разных сущности

• CEK (Content Encryption Key) — ключ, которым шифруются байты документа. В примерах старых профилей ГОСТ это 256-битный сеансовый ключ.
• KEK (Key Encryption Key) — ключ, предназначенный для защиты CEK. Его получают из ключевого соглашения или другого механизма доставки ключей.
• UKM (User Keying Material) — дополнительный параметр протокола, учитываемый при выработке ключей. Его нельзя считать секретным паролем или самим CEK. Точный формат и место хранения UKM зависят от профиля.

Эти сущности нельзя путать: использование одного и того же слова «ключ» для них часто приводит к неправильной реализации интеграции.

Согласование и транспорт ключа

И RFC 4490, и проект ТК26 2014 года рассматривают два соответствующих типа RecipientInfo:

Вариант	Структура	Смысл
Согласование ключа	KeyAgreeRecipientInfo	Стороны получают общий ключевой материал, включая применение VKO
Транспорт ключа	KeyTransRecipientInfo	В контейнере передаётся защищённое представление CEK для получателя

В варианте с VKO криптографическая операция связывает секретную часть одной стороны, открытый ключ другой стороны и согласованные параметры. Полученный материал используется в дальнейшем механизме защиты CEK. Нельзя подменить VKO обычным ECDH и ожидать совместимости: правила вывода ключа и обработки UKM должны совпадать.

Почему key wrap столь важен

Даже если два продукта поддерживают ГОСТ 28147-89, они могут по-разному защищать CEK: разные KeyWrapAlgorithm, способы диверсификации ключей, контрольная имитовставка, параметры подстановки. В проектах указаны GOST 28147-89 Key Wrap и CryptoPro Key Wrap.

Упрощённо операция выглядит так:

1. Формируется CEK для шифрования содержимого.
2. Для адресата выводится KEK по заданному профилю.
3. CEK шифруется по алгоритму упаковки ключа.
4. Добавляется контроль подлинности упакованного ключа, где это требует профиль.
5. В RecipientInfo записываются результат и параметры, нужные адресату.

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

Шифрование содержимого

В RFC 4490, раздел 5, и в проекте ТК26, раздел 7, используется ГОСТ 28147-89. Для его описания нужен не только OID 1.2.643.2.2.21, но и параметры iv и encryptionParamSet. Проект ТК26 описывает режим гаммирования с обратной связью и дополнительное преобразование ключей для содержимого; здесь нельзя произвольно заменить профиль на CBC из OpenSSL или XTS из dm-crypt.

«Кузнечик» XTS для диска и ГОСТ 28147 для CMS — разные сферы применения. Даже если оба алгоритма доступны в НАЙС.ОС, это не делает зашифрованный LUKS2 том CMS-сообщением и наоборот.

Безопасность содержимого

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

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

Как разбирать ошибки совместимости

1. Найти contentEncryptionAlgorithm и его параметры.
2. Выяснить тип RecipientInfo, который сформирован для вашего сертификата.
3. Проверить OID keyEncryptionAlgorithm и вложенный KeyWrapAlgorithm.
4. Сравнить наборы параметров, кривые, UKM и форматы шифрованного ключа.
5. Только затем проверять работу криптобиблиотеки и закрытого ключа адресата.

Об ошибке «не удалось открыть CMS» нельзя делать вывод, что ГОСТ вообще не поддерживается: отказ может быть на уровне ASN.1, key wrap, политики сертификата или внутреннего формата контейнера.

Разделяем ключи и роли: CEK, KEK, VKO, UKM

Отправитель                                  Получатель
[случайный CEK] ──> шифрование содержимого ──> [EncryptedContentInfo]
       │                                                │
       ▼                                                │
[RecipientInfo] ────────────────────────────────────────┤
       │                                                ▼
[VKO + UKM + параметры] → общий материал → KEK → защита CEK
                                               │
                                               ▼
                                    получатель получает CEK
                                               │
                                               ▼
                                         расшифровка

CEK (content-encryption key) — сеансовый ключ содержимого. KEK (key-encryption key) — ключ для защиты самого CEK. VKO — механизм выработки общего секретного материала на основе пары ключей и параметров. UKM — передаваемый параметр, участвующий в конкретной схеме согласования; его кодировка и размер задаются выбранным профилем. Нельзя считать UKM «ещё одним секретным ключом» и нельзя заменять криптографическую случайность простой строкой без требований профиля.

См. RFC 5652 §6, RFC 7836, страницы VKO, KDF, обёртывание/экспорт.

Почему получателей может быть много

EnvelopedData.recipientInfos представляет набор способов доставить CEK различным получателям. Обычно содержимое шифруется один раз, а для каждого получателя защищается один и тот же CEK подходящим ему способом управления ключами. Это эффективнее, чем создавать отдельный шифротекст для каждого адресата. Но изменение состава получателей требует новой обработки набора RecipientInfo, а не простого редактирования OID.

Разновидность RecipientInfo (RFC 5652)	Концепция	Важная проверка
KeyTransRecipientInfo	Передача ключа через механизм транспорта	Совместимость алгоритма и ключа получателя
KeyAgreeRecipientInfo	Согласование общего материала	Параметры стороны, UKM, согласование/обёртывание
KEKRecipientInfo	Уже разделяемый ключ защиты CEK	Идентификатор KEK и его хранение
PasswordRecipientInfo	Защита по паролю через KDF	Параметры KDF, ограничения перебора
OtherRecipientInfo	Расширяемое семейство	Наличие реализованного расширения

Это варианты общего CMS; поддержка каждого ГОСТ-профиля RecipientInfo зависит от конкретной реализации и не следует из распознавания имени алгоритма.

Шифрование содержимого не равно аутентифицированному шифрованию

Традиционный EnvelopedData может использовать режим, который обеспечивает конфиденциальность, но не предоставляет полноценной аутентификации всего сообщения. Если используются современные AEAD-режимы (например, MGM), нужен корректный формат хранения тега, AAD, nonce и выбранный профиль. Дополнительный CMS-тип AuthEnvelopedData описан в RFC 5083; нельзя произвольно упаковывать AEAD в старое поле и считать результат межоперабельным.

Ошибки, которые нельзя скрывать

• Неверный приватный ключ: не удалось получить CEK; это не обязательно означает повреждение самого шифротекста.
• Неверная точка/кривая/параметры VKO: ошибка согласования ключа, а не целостности документа.
• Неподдерживаемый OID обёртки: библиотека понимает CMS, но не умеет конкретный профиль.
• Порча содержимого: режим без аутентификации может не дать надёжного сигнала ошибки; если предусмотрен тег, он должен проверяться до возврата данных.
• Доверие к сертификату получателя: оно должно проверяться политикой отправителя до выдачи зашифрованного документа, иначе файл можно адресовать чужому ключу.

Практическая цепочка: структура CMS → ASN.1/OID → профили ГОСТ → OpenSSL CMS → межвендорный план испытаний.

Источники

• RFC 5652, раздел 6: EnvelopedData.
• RFC 4490, разделы 4–5: старый VKO, key transport и ГОСТ 28147.
• Проект ТК26, разделы 6–7 и приложения А–Б.
• RFC 7836: VKO и алгоритмы вывода ключей.

---

Маршрут чтения: VKO → Защита ключей → Модель угроз