Перейти к содержанию

Следующий рубеж: CMS EnvelopedData между НАЙС.ОС и КриптоПро

После успешной локальной проверки GPGSM остаются два независимых испытания: КриптоПро на macOS шифрует, НАЙС.ОС расшифровывает; затем НАЙС.ОС шифрует, а КриптоПро расшифровывает. На 24 октября 2026 года результатов обоих опытов нет. Ниже — воспроизводимая методика, а не отчёт о якобы выполненном обмене.

Условия

Для каждого направления нужен свой закрытый ключ на стороне получателя. При этом отправитель получает только открытый X.509-сертификат адресата.

Направление Кто хранит закрытый ключ Что передаём отправителю
E-02: CryptCP → GPGSM НАЙС.ОС niceos-lab-public.cer
E-03: GPGSM → CryptCP Mac с тестовым CryptoPro CSP только открытый сертификат лабораторного получателя Mac

Не используйте действующий ключ КЭП на Рутокене в роли дешифратора тестового сообщения: он может не поддерживать требуемую операцию или использование для шифрования может противоречить назначению ключа. Отдельные лабораторные сертификаты должны быть пригодны для keyAgreement / keyEncipherment с учётом профиля CSP.

E-02. КриптоПро создаёт EnvelopedData для НАЙС.ОС

Шаг 1 — экспорт сертификата получателя на НАЙС.ОС:

LAB=/root/gost-cms-test/lab
openssl x509 -in "$LAB/niceos-lab.crt.pem" \
  -outform DER -out "$LAB/niceos-lab-public.cer"

Перенесите niceos-lab-public.cer на Mac. Не переносите .key или .p12.

Шаг 2 — выбор профиля в CryptCP:

На Mac CryptCP 5.0 предоставляет -encr и -encrf. Настройте шифрование на открытый сертификат НАЙС.ОС, а для первоначальной проверки выбирайте поддерживаемый данной версией исторический шифр содержимого ГОСТ 28147-89, OID 1.2.643.2.2.21, если конкретная сборка CryptCP допускает его выбор.

Вариант командной строки, который следует сначала подтвердить на установленной версии:

CRYPTCP=/opt/cprocsp/bin/cryptcp
"$CRYPTCP" -encrf \
  -f "$HOME/gost-interop/niceos-lab-public.cer" \
  -encryptionalg 1.2.643.2.2.21 \
  "$HOME/gost-interop/plain.txt"

Статус команды: это предлагаемый тест, не зафиксированный успешный запуск. Если CryptCP отвергает флаг или профиль, сохраните сообщение об ошибке и используйте «Инструменты КриптоПро» для выбора сертификата и режима, вместо подбора случайных опций.

Шаг 3 — расшифрование на НАЙС.ОС:

LAB=/root/gost-cms-test/lab
# Замените имя на фактическое имя полученного DER-CMS файла.
gpgsm --homedir "$LAB/gnupg" \
  --output "$LAB/decrypted-from-mac.txt" \
  --decrypt "$LAB/from-mac.p7e"

rc=$?
echo "Decrypt rc: $rc"
[ "$rc" -eq 0 ] && sha256sum "$LAB/decrypted-from-mac.txt"

Сравнивайте sha256sum с оригиналом на macOS через shasum -a 256, или побайтово после копирования тестового исходного текста.

E-03. НАЙС.ОС создаёт EnvelopedData для КриптоПро

Шаг 1 — лабораторный сертификат Mac: создайте отдельную тестовую пару с закрытым ключом, доступным CryptCP для расшифрования. Экспортируйте только открытый сертификат. Не используйте для этого действующую КЭП.

Шаг 2 — импорт открытого сертификата Mac в GPGSM:

LAB=/root/gost-cms-test/lab

gpgsm --homedir "$LAB/gnupg" \
  --import "$LAB/mac-lab-public.cer"

gpgsm --homedir "$LAB/gnupg" --list-keys

Шаг 3 — шифрование для получателя Mac:

MAC_FPR='ПОЛНЫЙ_ОТПЕЧАТОК_ТЕСТОВОГО_ПОЛУЧАТЕЛЯ_MAC'

gpgsm --homedir "$LAB/gnupg" \
  --always-trust --cipher-algo GOST28147 \
  --recipient "$MAC_FPR" \
  --output "$LAB/to-mac.p7e" \
  --encrypt "$LAB/plain.txt"

--always-trust применяется здесь только к искусственному получателю в изолированном стенде. Поставьте CryptCP на Mac расшифровать to-mac.p7e на соответствующий лабораторный закрытый ключ, затем сравните файл с исходным. Синтаксис команды cryptcp -decr или -decrf зависит от типа входного файла, способа установки ключа и версии CryptCP; точную команду следует закреплять после первого успешного запуска, а не выдавать непроверенный набор флагов за подтверждённый.

Что фиксировать при отказе

  1. Содержимое открытого X.509 (Signature Algorithm, Public Key Algorithm, Key Usage, OID кривой).
  2. Тип CMS EnvelopedData, число получателей, OID шифра содержимого, описание RecipientInfo, тип KeyTransport/KeyAgreement.
  3. Код завершения и первое существенное сообщение об ошибке без DN с персональными сведениями.
  4. Версии обеих сторон, пути к тестовым файлам и SHA-256 исходного текста. Не включайте пароль и приватные ключи.

Успешная расшифровка одного направления ещё не закрывает другое. Для общего заявления о взаимной совместимости надо завершить обе проверки, а затем выполнить отрицательные тесты повреждённого транспорта ключа. RFC 4490 описывает исторические KTRI/KARI и ГОСТ28147, но он не доказывает, что любая современная сборка автоматически поддерживает конкретный профиль.