Электронная подпись CMS с ГОСТ: чтение, проверка, доверие¶
Для чего предназначен CMS¶
CMS — общепринятый формат защищённых сообщений. Для электронной подписи используется структура SignedData: она может содержать сам подписанный документ, описание алгоритмов, данные подписанта, его сертификат, один или несколько наборов подписанных атрибутов и саму подпись. CMS также используется для защищённой почты S/MIME. Общее устройство определено RFC 5652; применение традиционного ГОСТ в CMS описано RFC 4490.
В НАЙС.ОС libksba разбирает структурные поля CMS и ГОСТ-подписи. Проверку математической правильности подписи выполняет криптографический компонент, а определение доверия к подписанту — отдельная часть GnuPG и корпоративной PKI.
Два типа документов, которые часто путают¶
| Вариант | Что передаёт партнёр | Что нужно для проверки |
|---|---|---|
| Присоединённая подпись | Один CMS-файл с подписью и содержимым | CMS-файл, сертификаты и доступная инфраструктура доверия |
| Отсоединённая подпись | Исходный документ + отдельный файл подписи .sig, .p7s |
Обе части, именно те байты, которые подписывались |
Для отсоединённой подписи изменённая кодировка, изменение переносов строк, добавление BOM или пересохранение PDF/Office-документа может нарушить проверку. Не открывайте документ в редакторе с последующим автосохранением перед тестом. Не пытайтесь проверять подпись по скриншоту или визуально идентичной копии.
Что изменяет libksba НАЙС.ОС¶
В российских CMS-профилях встречаются ГОСТ-подписи длиной 64 или 128 байт. Для математической проверки их нужно превратить в отдельные значения r и s. Обычная ECDSA-подпись хранит эти значения иначе, и простая перестановка названия алгоритма недостаточна. Расширение НАЙС.ОС обеспечивает требуемое представление ГОСТ-подписи для вычислительного механизма.
Дополнительно обрабатываются стандартные ГОСТ-OID и некоторые варианты, где производитель записывает в CMS OID открытого ключа в поле алгоритма подписи, а алгоритм хэширования указывает отдельно. Встречающееся значение параметров NULL также учтено как профиль совместимости. Это повышает вероятность корректного чтения документов, но не заменяет криптографическую проверку и не распространяется на каждый вариант CMS.
Проверка подписи на рабочем месте¶
Получив от партнёра contract.pdf и contract.sig, сначала сохраните оригиналы в защищённый каталог и зафиксируйте контрольные суммы:
mkdir -p "$HOME/signature-review"
chmod 700 "$HOME/signature-review"
cp /путь/к/contract.pdf /путь/к/contract.sig "$HOME/signature-review/"
cd "$HOME/signature-review"
sha256sum contract.pdf contract.sig
Команда sha256sum здесь применяется только для инвентаризации переданных файлов. Она не определяет криптографический алгоритм CMS и не заменяет проверку ГОСТ-подписи.
Проверьте, что используется именно GPGSM:
Проверка отделённой подписи:
Если подпись присоединённая, проверьте контейнер непосредственно:
Не придумывайте успешный результат заранее: в зависимости от версии GnuPG и установленного криптографического механизма возможны ошибки неподдерживаемого алгоритма, отсутствующего сертификата, статуса УЦ или невозможности проверить подпись. Подлинный результат необходимо оценивать по сообщению GPGSM и журналу операции.
Как понимать результат¶
Корректно разобран CMS — библиотека поняла формат документа. Это самый первый этап.
Криптографическая подпись верна — данные соответствуют подписи при указанном открытом ключе и алгоритме. Но этого недостаточно для признания подписанта доверенным.
Цепочка доверия корректна — удостоверяющие центры, назначение сертификата, сроки действия, отзыв и локальная политика удовлетворяют требованиям организации. Лишь совокупность проверок даёт основание для принятия документа в процессе ЭДО.
Юридическая значимость — дополнительный вопрос: важны вид электронной подписи, полномочия, нормативные требования, применяемая система и условия использования СКЗИ. Поддержка ГОСТ в libksba не делает программу автоматически сертифицированным средством проверки квалифицированной электронной подписи.
Как исследовать неизвестный CMS¶
Проверка ASN.1 помогает увидеть OID и структуру. Но она не выполняет криптографическую проверку; openssl cms -verify тоже зависит от собственной поддержки ГОСТ и его провайдеров. Если результаты OpenSSL и GPGSM различаются, не следует автоматически объявлять одну программу неправильной: они используют разные криптографические маршруты и политики доверия.
Создание подписи своими средствами¶
После настройки GPGSM и наличия собственного ключа подписи:
gpgsm --list-secret-keys
gpgsm --local-user 'ОТПЕЧАТОК_СВОЕГО_СЕРТИФИКАТА' \
--output agreement.p7m --sign agreement.pdf
Это общий сценарий GPGSM, а не обещание, что любое сочетание ГОСТ-ключа, libgcrypt и GPGSM готово подписывать документы. Важно выполнить полный цикл: создать файл, проверить его на другом доверенном рабочем месте, а при обмене с КриптоПро — выполнить отдельное межпрограммное испытание. Для внешнего документооборота проверяйте требования к присоединённости подписи, атрибутам CMS, сертификатам и штампам времени.
Самые частые неисправности¶
- Не найден сертификат подписанта. Запросите сертификат и промежуточные сертификаты УЦ; не путайте их с закрытым ключом.
- Неизвестный алгоритм или набор параметров. Проверьте наличие адаптированной libksba, libgcrypt и соответствующего набора кривых.
- Неверная подпись. Сначала сравните исходные байты документа и исключите передачу неправильного файла.
- Подпись верна, но УЦ недоверенный. Настройте доверие по политике организации; не отключайте проверки глобально.
- Ошибка CMS-парсера. Проверьте контейнер и исходный формат; возможно, производитель использует неподдерживаемый вариант CMS.
- Контейнер открылся, но отсутствует исходный файл. Уточните, не является ли подпись отсоединённой.
Пример журнала испытания: сохраните исходные SHA-256, вывод gpgsm --version, имя и формат контейнера, результат gpgsm --verify, сертификат подписанта и конечное решение по доверию.
См. руководство пользователя и диагностику. Источники: RFC 5652, RFC 4490, документация GPGSM.