Модель угроз ГОСТ CMS и безопасная обработка контейнеров

В криптографическом документообороте атакуют не только шифр. Уязвимостями становятся доверие к сертификату, ошибки ASN.1, неканонические атрибуты, выбор профиля, доступность CRL, организация ключей и логика приложения. Эта глава связывает алгоритмы с проверяемой защитой документов.

Поверхности атаки

Где возникает риск	Пример атаки или ошибки	Требуемая защита
Входной ASN.1	Глубокая вложенность, некорректные длины	Ограничения ресурсов, отказ без побочных эффектов
Detached-документ	Подмена внешнего файла или нормализация байтов	Строгое сравнение messageDigest и signedAttrs
Набор подписантов	Удаление одной из сильных подписей	Политика все/некоторые + RFC 5752 при применимости
Сертификаты внутри CMS	Подложенный CA или сертификат с чужой цепочкой	Явный trust store, PKIX, KU/EKU, политики
CRL/OCSP	Недоступность, устаревший ответ, неизвестный статус	Проверка подписей, актуальности, строгая политика отказа
Выбор алгоритма	Подмена OID, неявный downgrade	Белый список профилей и параметров
Key management	Неподходящий UKM/кривая, повтор ключей	Выполнение правил RFC 7836 и установленного профиля
AEAD	Повтор nonce, выдача данных до проверки тега	Управление nonce, отказ до публикации plaintext
S/MIME	Перекодировка и смена MIME-структуры	Каноникализация согласно почтовому профилю

Границы доверия

[Внешний файл/письмо]  ── НЕДОВЕРЕННЫЕ БАЙТЫ
          │
          ▼
[Декодер MIME/ASN.1]  ── НЕ ПРОИСХОЖДЕНИЕ
          │
          ▼
[Криптографическая библиотека] ── ПРОВЕРКА ПОДПИСИ/ТЕГА
          │
          ▼
[Trust store + CRL/OCSP]  ── ДОПУЩЕН ЛИ КЛЮЧ?
          │
          ▼
[Бизнес-правила]  ── ДОПУЩЕН ЛИ ДОКУМЕНТ?

Ни один слой не должен объявлять успешной работу последующего. Разделяйте parse PASS, crypto PASS, trust PASS, policy PASS. Для системы с отложенной обработкой фиксируйте также версию криптобиблиотеки и политику на момент проверки.

Подписанное — не всегда конфиденциальное

SignedData может содержать открытые данные вместе с подписью. ГОСТ Р 34.10 обеспечивает проверяемую подпись, но не шифрует документ. EnvelopedData создаёт конфиденциальность, но без дополнительной подписи сам по себе не доказывает автора. Для одновременных целей используйте правильно согласованную вложенную композицию, а при AEAD — соответствующий профиль хранения тега: RFC 5652, RFC 5083, MGM.

Логика принятия документа

Объявите в политике, что делать с: несколькими подписями, неизвестным SignerInfo, истёкшим сертификатом, недоступной CRL, устаревшим алгоритмом, неподдерживаемым OID, локальной подписью неизвестного CA, недопустимым MIME-типом и недоверенной отметкой времени. Не используйте «прошло у одного клиента» как замену перечню правил.

Для разработчиков: при парсинге сторонних ASN.1-структур вводите лимиты размера файла, числа подписей/получателей, глубины вложенности и времени операции. Сохраняйте оригинальные байты, чтобы диагностическое извлечение не изменяло проверяемый объект.

Практическая стратегия тестирования

1. Положительный образец от второй независимой реализации.
2. По одному отрицательному образцу на каждый класс угроз: документ, подпись, параметры, цепочка, отзыв, формат.
3. Два направления: НАЙС.ОС → другая система, другая система → НАЙС.ОС.
4. Фиксация конечных байтов, OID, версии RPM, режима чтения и журналов.
5. Повторение тестов после обновления OpenSSL, libksba, gpgsm, системного trust store.

См. проверку доверия, SignedData, матрицу интеграции, приёмку, руководство по совместимости.

Источники

• RFC 5652 — CMS
• RFC 5280 — X.509/CRL
• RFC 5752 — multiple signatures
• RFC 8551 — S/MIME

Далее: диагностика → план межоперабельности.

Пределы AEAD и защита от повторного использования параметров

При шифровании MGM или другим аутентифицированным режимом необходимо соблюдать требования к nonce, ключам и тегу. Повтор использования nonce с тем же ключом может серьёзно нарушить защищённость режима. Само наличие AEAD не означает защиту от повторного целого корректного сообщения: против replay могут потребоваться счётчики, идентификаторы сообщений или прикладные правила. Указанные механизмы относятся к внешнему протоколу, а не возникают автоматически из формата CMS.

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

Невозможность доказать доверие из одного контейнера

Злоумышленник может сформировать синтаксически правильный SignedData и подписать его собственным ключом. Криптографическая операция будет математически корректна, но подпись не станет доверенной без необходимой цепочки и политики. Аналогично, подписанный сертификат внутри certificates может быть полезен декодеру, но не должен добавляться в список доверенных CA только потому, что получен вместе с документом.

Что учесть при реализации API проверки

Программный интерфейс должен сообщать четыре независимых статуса: формат входных данных, криптографический результат, доверие к ключу и результат бизнес-политики. Недопустима архитектура, где openssl cms -cmsout -print трактуется как подтверждение подписи или где ошибка сети при получении CRL автоматически превращается в успешный ответ. Для каждой операции нужны лимиты размера и времени, а пользовательские имена файлов должны нормализоваться перед записью на диск.

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

Связанные разделы: политика ключей, практика ротации, RFC 5083 для AEAD CMS, RFC 5752 о нескольких подписях.