Структура ГОСТ CMS, OID и типовые несовместимости¶

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

Типы CMS¶

CMS ContentType	Назначение	Что делал наш стенд
`SignedData`	Подпись содержимого, присоединённая или отсоединённая	Подписывал и проверял через GPGSM/CryptCP в обе стороны
`EnvelopedData`	Шифрование на открытый ключ одного или нескольких адресатов	Локальный цикл GPGSM ГОСТ28147
`AuthenticatedData`	Проверка целостности с разделяемым ключевым материалом	Не испытывалось
`DigestedData`	Дайджест без подписи	Не испытывалось

message.txt.sgn и .p7e в примерах — условные имена; реальный формат определяется ASN.1/ContentType, а не суффиксом файла.

Что происходит при EnvelopedData¶

Программа создаёт случайный CEK — ключ шифрования содержимого.
Документ шифруется CEK, в нашем локальном тесте явно выбран ГОСТ 28147-89.
Для каждого получателя используется публичный ГОСТ-ключ и алгоритм согласования/транспорта; по VKO и контексту UKM получается KEK.
CEK защищается с помощью KEK; формат содержит необходимую служебную информацию и значение имитовставки транспорта ключа.
Получатель использует собственный закрытый ключ, восстанавливает CEK и расшифровывает содержимое.

Важно: MAC защищённого транспорта CEK не тождествен подписи или аутентификации всего документа. Для подтверждения авторства необходимо проверить CMS SignedData (или иной согласованный профиль аутентифицированных данных).

Идентификаторы, встречавшиеся в испытаниях¶

OID или название	Значение
`1.2.643.7.1.1.1.1`	Открытый ключ ГОСТ Р 34.10-2012/256
`1.2.643.7.1.1.3.2`	Подпись ГОСТ-2012/256 + Стрибог-256
`1.2.643.7.1.1.2.2`	ГОСТ Р 34.11-2012/256 (Стрибог-256)
`1.2.643.2.2.21`	Шифрование ГОСТ 28147-89 в описанном старом профиле
CryptoPro-XchA / CryptoPro-A	Исторические именования наборов параметров; математически эквивалентные кривые могут носить разные обозначения

В сертификате российского УЦ алгоритм открытого ключа был 2012/256, а набор параметров назывался id-GostR3410-2001-CryptoPro-XchA-ParamSet. Отображение GPGSM GOST2001-CryptoPro-A не доказывает, что сертификат подписан или выпущен по алгоритму 2001. Сверяйте точные числовые OID в DER. Дополнительные подробности — в RFC 9215.

Осмотр контейнеров, не раскрывая ключи¶

Для публичного сертификата:

openssl x509 -inform DER -in recipient.cer \
  -noout -text | grep -E 'Signature Algorithm:|Public Key Algorithm:'

Для стандартного DER CMS на тестовых данных:

openssl asn1parse -inform DER -in message.p7e -i | head -80

При необходимости можно использовать openssl cms -cmsout -print -inform DER -in message.p7e для чтения структуры, если эта команда поддерживает созданный профиль. Это диагностический просмотр без расшифрования; его успех не подтверждает поддержку всех ГОСТ-алгоритмов в GPGSM.

Границы RFC 4490¶

RFC 4490 описывает исторические профили ГОСТ 28147-89, ГОСТ-94/2001, включая перенос ключей и UKM. При реализации ГОСТ-2012 возможны уточнения из последующих российских рекомендаций и реализаций. Не переносите без анализа параметры старого профиля на современные KARI/KExp15: их поддержка в нативном GPGSM НАЙС.ОС этими испытаниями не доказана.

Почему контейнер может не открыться¶

При одинаковом имени алгоритма ГОСТ системы могут отличаться:

схемой размещения RecipientInfo — KTRI против KARI;
OID и параметрами эллиптической кривой;
длиной, порядком байтов и расположением UKM;
набором замен шифра ГОСТ28147;
форматом защищённого ключа CEK и его MAC;
настройкой доверия и отсутствием соответствующего закрытого ключа;
внешним форматом кодирования CMS: DER или PEM/Base64.

Поэтому каждый обмен следует завершать побайтовым сравнением расшифрованных данных и самостоятельной фиксацией алгоритмов из структуры контейнера.