Практическая проверка CMS-контейнеров в НАЙС.ОС¶

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

1. Сохранить оригинал¶

Не изменяйте исследуемый файл, не пересохраняйте его в текстовом редакторе и не меняйте переводы строк. Создайте рабочую копию и её хэш:

mkdir -p "$HOME/gost-cms-inspection"
chmod 700 "$HOME/gost-cms-inspection"
cp -- document.p7s "$HOME/gost-cms-inspection/original.p7s"
sha256sum "$HOME/gost-cms-inspection/original.p7s"

SHA-256 здесь служит контрольной суммой копирования, а не заявлением о том, какой криптографический алгоритм находится внутри CMS. Это разные функции.

2. Уточнить формат¶

file "$HOME/gost-cms-inspection/original.p7s"
head -c 64 "$HOME/gost-cms-inspection/original.p7s" | od -An -tx1

Если в файле находится текстовая обёртка -----BEGIN ...-----, потребуется корректно определить тип PEM; если это полноценное MIME-сообщение, сначала необходимо отделить MIME от вложенного CMS. Бинарный DER обычно начинается с ASN.1 SEQUENCE, но это только ориентир, а не криптографическая проверка.

3. Посмотреть ASN.1¶

openssl asn1parse -inform DER   -in "$HOME/gost-cms-inspection/original.p7s" -i | head -120

С помощью дерева тегов найдите внешний contentType, затем тип вложенного сообщения. Отдельно запишите обнаруженные OID; сопоставьте их с нашей таблицей. Если видите неизвестный OID, не подставляйте «похожий» алгоритм: нужна спецификация конкретного параметра.

4. Посмотреть семантическую структуру CMS¶

openssl cms -cmsout -print -inform DER   -in "$HOME/gost-cms-inspection/original.p7s" -noout

Если команда успешно распечатала SignedData, это означает, что выбранная версия OpenSSL разобрала структуру, а не что подпись уже проверена. При ошибке выясните, ожидает ли программа DER, PEM или S/MIME. Это частая причина, не связанная с ГОСТ.

5. Зафиксировать криптографический профиль¶

Для подписанного контейнера записываются: digestAlgorithm, signatureAlgorithm, SignerInfo, signedAttrs, наличие сертификатов, detached/attached. Для шифрованного — RecipientInfo, keyEncryptionAlgorithm, contentEncryptionAlgorithm, параметры iv, encryptionParamSet, UKM и key wrap.

Профиль лучше фиксировать в следующем виде:

Поле	Значение
Внешний CMS-тип	`SignedData` / `EnvelopedData` / другое
Исходное содержимое	Внутри контейнера / отдельно
Хэш	Полное имя и OID
Подпись	Алгоритм, параметры, размер значения
Шифрование	Алгоритм содержимого, IV, параметрический набор
Получатель	Вид RecipientInfo, VKO или transport, key wrap
Проверка доверия	Отдельный результат X.509

Не публикуйте в отчёте приватные ключи, пароли PFX, секреты PKCS#11 и расшифрованное конфиденциальное содержимое.

6. Проверить содержимое и доверие раздельно¶

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

[ ] Структура CMS распознана
[ ] Все обязательные OID и параметры известны
[ ] Хэш соответствует документу
[ ] Криптографическая подпись верна
[ ] Цепочка сертификатов проверена
[ ] Проверены сроки, назначение и отзыв по политике организации
[ ] Получатель успешно расшифровал документ (для EnvelopedData)

Для проверки совместимости с другим продуктом передавайте не только контейнер, но и описание криптопрофиля, контрольную сумму исходного содержимого и результат проверки каждого пункта.

7. Типовые причины отказа¶

Симптом	Первый диагностический шаг
`Error reading S/MIME message`	Не перепутаны ли DER и MIME
ASN.1 распознаётся, CMS-парсер отказывает	Правильный CMS-тип, поддержка конструкций и расширений
`unsupported algorithm`	OID, Provider/Engine и фактическая регистрация алгоритма
`digest failure`	Оригинальные байты, `signedAttrs`, detached-содержимое
`verification failure`	Публичный ключ, подпись, порядок компонент, параметры
`certificate verify error`	Доверие X.509, а не обязательно ГОСТ-криптография
Зашифрованный контейнер не открывается	CEK/KEK, RecipientInfo, VKO, UKM, Key Wrap

Здесь специально не предлагается «отключить проверку сертификатов», чтобы получить зелёный результат. Для отладки можно отдельно изучать математическую корректность подписи и политику доверия, но итоговая эксплуатационная проверка должна включать обе части.

8. Контрольные вопросы¶

Можно ли по расширению .p7s уверенно определить профиль ГОСТ?
Может ли математически правильная подпись иметь недоверенный сертификат?
Почему ГОСТ 28147-89 на обеих сторонах не гарантирует совместимый EnvelopedData?
Чем отличается SignerInfo.signatureAlgorithm от EncryptedContentInfo.contentEncryptionAlgorithm?
Что изменится, если к detached-подписи приложить тот же текст, но с другими переводами строк?

Ответы следуют из основ CMS, разбора подписи, ключевого управления и ASN.1.

Диагностика по слоям: не сводить всё к одному слову «ошибка ГОСТ»¶

Непонятный файл
   │
   ├── MIME/PEM/DER не распознан? ──> формат, кодировка, ASN.1
   │
   ├── CMS разобран, но OID неизвестен? ──> профиль алгоритма/провайдер
   │
   ├── Подпись криптографически неверна? ──> байты, signedAttrs, ключ, endian
   │
   ├── Подпись верна, доверия нет? ──> CA, KU/EKU, время, CRL/OCSP
   │
   ├── CEK не получен? ──> RecipientInfo, VKO, UKM, key wrap
   │
   └── Сообщение отклонено политикой? ──> профиль организации и регуляторика

Шесть безопасных этапов проверки¶

Сохранить оригинал: зафиксировать SHA-256 байтов файла и отдельно переданного документа; не редактировать исследуемый образец.
Распознать оболочку: MIME/DER/PEM; не доверять одному лишь расширению имени файла.
Разобрать структуру: ContentInfo и вложенные типы, алгоритмы, подписантов/получателей, сертификаты и параметры.
Проверить криптографию: подпись и связь с точным содержимым либо правильное получение CEK и контроль тега, если профиль его предусматривает.
Проверить доверие: CA, идентичность, KU/EKU, время, отзыв, алгоритмическую политику; при недоступной CRL/OCSP действовать по заданной политике, не подразумевая успех.
Сформировать отчёт: результаты каждого слоя и версию программы/пакета; не заменять диагностику строкой «успешно/неуспешно».

Команды исследования структуры (не являются проверкой подписи)¶

# Оригинал сохраняем отдельно; команды ниже не меняют файл.
sha256sum document.p7s
file document.p7s
openssl asn1parse -inform DER -in document.p7s -i | head -n 60
openssl cms -cmsout -print -inform DER -in document.p7s -noout

Указывайте -inform PEM или -inform SMIME только если реально установлен соответствующий формат. При отсоединённой подписи необходимо предоставить исходное содержимое согласно RFC 5652 §5; отсутствие исходного документа — это ошибка входных данных, а не доказательство неверной ГОСТ-подписи.

Отдельные негативные сценарии¶

Подпись при изменении одного байта документа должна отклоняться.
Подпись корректным ключом неизвестного CA может быть математически верна, но не должна автоматически считаться доверенной.
При искажении DER-атрибутов проверка должна обнаружить некорректное представление либо отвергнуть подпись.
При выборе чужого ключа получателя EnvelopedData не должен расшифровываться как успешный.
Для аутентифицированных режимов изменение тега, nonce, AAD или шифротекста требует отказа.
Недоступность проверки отзыва должна обрабатываться согласно настроенной политике; «soft-fail» и «strict» не равнозначны.

Подробнее см. модель угроз, политику доверия, матрицу совместимости, практику OpenSSL, GPGSM. ГОСТ-CRL в strongSwan — другая подсистема: см. IKEv2 CRL и HTTPS CRL.

Источники¶

Маршрут чтения: Политика проверки → Модель угроз → Совместимость

Группа	Поля
Система	НАЙС.ОС 5.2, версии RPM и библиотек, конфигурация ГОСТ Engine/Provider
Данные	тип контейнера, размер, SHA-256, detached-content
Разбор	`ContentInfo`, OID, наборы параметров, число подписантов/получателей
Подпись	исходный документ, алгоритм хэша, `signedAttrs`, проверка подписи
Ключи	сертификат, OID ключа, curve, `RecipientInfo`, VKO/KEK/CEK
Доверие	CA, политика, CRL/OCSP, временная привязка
Совместимость	другая программа и её версия, направление обмена, журнал ошибок
Вердикт	`PASS`, `FAIL` или `NOT TESTED` для каждого утверждения