CMS без загадок: SignedData, EnvelopedData, RecipientInfo¶

Структуры защищённых сообщений и пошаговая диагностика маршрута от документа до получателя.

Документация ПО — НАЙС.ОС CLOUD. Это самостоятельная учебно-справочная статья. Команды приведены для изучения и диагностики; операции с ключами, дисками и действующими сервисами выполняют только после резервного копирования и проверки назначения.

CMS — это контейнер, а не алгоритм¶

Cryptographic Message Syntax (CMS) описывает способ представить подписанные, зашифрованные и иные криптографически обработанные данные. В самом контейнере можно встретить различные поколения ГОСТ-алгоритмов. Поэтому расширение .p7m, .p7s или .der ещё не говорит о том, какими ГОСТ-примитивами защищён документ.

Подпись: примерный маршрут обработки¶

исходные байты ──► messageDigest ──► signedAttrs
                                      │
ключ подписанта ─────────────────► signature
                                      │
сертификаты ──────────────────► SignedData ──► CMS ContentInfo

Если присутствуют подписанные атрибуты, именно над их DER-представлением выполняется криптографическая подпись по правилам CMS, а не просто над текстом файла. Хэш исходного содержимого помещается в messageDigest и затем связывается с подписью. Из-за этого изменение кодировки или концов строк в документе может нарушить проверку.

Шифрование: разные задачи разных ключей¶

документ ──► шифрование CEK ──► encryptedContentInfo
                │
CEK ──► защита для получателя через KEK/VKO ──► RecipientInfo
                                             │
                                      EnvelopedData

У CMS может быть несколько получателей. Один зашифрованный текст сопровождается разными RecipientInfo, каждый из которых описывает способ доставить/восстановить ключ содержимого определённому получателю. В этом и состоит отличие от прямого шифрования файла паролем.

Что смотреть внутри контейнера¶

Поле	Вопрос диагностики
`contentType`	Это `signedData`, `envelopedData` или другой тип?
`digestAlgorithms`	Какими хэшами можно вычислять digest?
`encapContentInfo`	Содержимое вложено или передаётся отдельно?
`SignerInfo`	Каким сертификатом и каким алгоритмом подписано?
`signedAttrs`	Какие атрибуты реально подписаны?
`RecipientInfo`	Для кого зашифрован CEK и как именно?
`encryptedContentInfo`	Как зашифровано само содержимое?

Три разновидности ошибок¶

Ошибка кодирования. ASN.1 не декодируется, неизвестен OID, неправильная длина октетной строки или параметров алгоритма. Ошибка криптографии. Формат понятен, но не найден алгоритм или криптографическая проверка не совпала. Ошибка доверия. Подпись корректна, но нет доверенного УЦ, истёк срок сертификата или не пройдена проверка отзыва.

Используйте эту последовательность и в интерфейсе сервисной диагностики. Пользователь должен видеть «не удалось прочитать CMS», «отсутствует криптопровайдер» и «цепочка сертификатов недоверенная» как разные сообщения.

Особенность ГОСТ-источников¶

Для старых CMS с ГОСТ 28147-89 полезен RFC 4490 и RFC 4357. Для современных сообщений ориентируйтесь на действующие российские рекомендации CMS и профиль сертификатов ГОСТ-2012; нельзя переносить алгоритмические параметры 2006 года на новые сообщения без указания схемы совместимости.

Первоисточники и дополнительное чтение¶

RFC 5652 — базовая структура CMS и типы содержимого.
Р 1323565.1.025-2019 — российские рекомендации по CMS.
RFC 4490 — исторические профили CMS.
RFC 4357 — старые наборы параметров CryptoPro и перенос ключей.
RFC 9215 — ГОСТ-2012 в сертификатах и списках отзыва.