Электронная подпись ГОСТ: CMS SignedData и GPGSM¶
Для чего нужна¶
CMS SignedData — контейнер для проверки происхождения и неизменности документа, который часто встречается в электронном документообороте, защищённой почте и архивных материалах. Он может содержать документ целиком либо существовать отдельно от исходного файла. Графические приложения иногда называют такие файлы .p7s, .sgn, .p7m; расширение не заменяет проверку фактического содержимого.
В НАЙС.ОС роль GPGSM — прочитать структуру через libksba, определить подписанта и алгоритмы, выполнить проверку через libgcrypt, затем отдельно оценить доверие к цепочке сертификатов. При ошибке доверия математически правильная подпись может сопровождаться предупреждением. Не путайте эти результаты.
Что доказано на практике¶
КриптоПро CSP 5.0 на macOS создал отсоединённую подпись ГОСТ Р 34.10-2012/256 со «Стрибогом»-256; НАЙС.ОС подтвердил GOODSIG, VALIDSIG. Подмена оригинального файла дала BADSIG, код завершения 2. После настройки среды штатный запуск дал TRUST_FULLY, код 0. Это сильное свидетельство совместимости проверки конкретного SignedData-профиля, но не подтверждение всех CAdES-форматов.
Проверка отсоединённой подписи¶
Для промышленного сценария важно анализировать одновременно: процесс успешно завершился ($? равен 0), есть GOODSIG/VALIDSIG, установлен ожидаемый сертификат подписанта, полная цепочка доверия валидна, назначение сертификата разрешает подпись, срок/отзыв проверены. Команды нельзя считать успешными только по наличию подстроки GOODSIG.
Проверка изменённого файла¶
cp test.txt test-modified.txt
printf 'CHANGE\n' >> test-modified.txt
gpgsm --status-fd 2 --verify test.txt.sgn test-modified.txt
Ожидается BADSIG и ненулевой код. Такой тест следует включить в регрессию после обновлений GnuPG, libksba и libgcrypt.
Создание подписи в НАЙС.ОС¶
Для подписания нужен закрытый ключ с правом электронной подписи и связанный с ним сертификат. Лабораторный ключ, созданный с keyAgreement,keyEncipherment, предназначен для тестов шифрования, а не для проверки сценария подписи. Для подписи создайте отдельную лабораторную пару с digitalSignature и соответствующим EKU/политикой:
umask 077
mkdir -p /root/gost-cms-test/sign-lab
cd /root/gost-cms-test/sign-lab
openssl genpkey -algorithm gost2012_256 \
-pkeyopt paramset:XA -out signer.key.pem
openssl req -new -x509 -key signer.key.pem -days 7 \
-subj '/C=RU/O=NiceOS Lab/CN=Test Signer' \
-addext 'keyUsage=critical,digitalSignature' \
-addext 'extendedKeyUsage=emailProtection' \
-out signer.crt.pem
Импорт соответствующего P12 в изолированное хранилище выполняется по руководству PFX. После появления ключа в gpgsm --list-secret-keys типовой синтаксис подписи выглядит так:
gpgsm --homedir /root/gost-cms-test/sign-lab/gnupg \
--local-user 'ОТПЕЧАТОК_СЕРТИФИКАТА_ПОДПИСАНТА' \
--output message.p7m --sign message.txt
Здесь и далее команды, не выполненные на пользовательской системе, даны как программа испытаний. Не описывайте их результат словом «проверено» до реального запуска. У gpgsm работа с S/MIME/CMS документирована проектом GnuPG: https://gnupg.org/documentation/manuals/gnupg/Invoking-GPGSM.html.
Практика документооборота¶
Подписи бывают присоединёнными и отсоединёнными, с включённым сертификатом или без него. Архив должен содержать исходный файл, подпись, использованные сертификаты, сведения о проверке статуса и времени (если необходимы). Встроенное поле signingTime в CMS не равно доверенной временной метке. Штатная проверка GPGSM не заменяет процедуры правовой проверки статуса КЭП.
Если вывод содержит GOST2001-CryptoPro-A, проверяйте OID сертификата отдельно: это может быть отображаемое имя эквивалентной эллиптической кривой, а фактический алгоритм сертификата — ГОСТ-2012/256.