Зашифрованные CMS-документы: ГОСТ 28147, ключи и параметры¶

Что получает адресат зашифрованного документа¶

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

Исходный документ
       |
       | Шифрование одноразовым ключом содержимого (CEK)
       v
 Зашифрованное содержимое
       +
 Сведения для конкретного получателя:
       | - алгоритм переноса ключа
       | - временный открытый ключ отправителя
       | - UKM и параметры ГОСТ
       | - защищённый CEK и контрольная величина
       v
       Файл CMS (например, .p7m)

CEK — ключ шифрования самого документа. KEK — ключ, используемый для защиты CEK при доставке адресату. UKM — дополнительные открытые параметры формирования ключей. Закрытый ключ адресата в файле CMS не содержится.

Одна из типовых последовательностей описана в RFC 4490, разделах о переносе ключей и шифровании содержимого. Общие структуры CMS определены RFC 5652.

Что именно добавлено в libksba НАЙС.ОС¶

Реализация НАЙС.ОС расширяет чтение и запись нескольких структур CMS, необходимых для традиционных ГОСТ-профилей. В адаптации учитываются:

идентификаторы открытых ключей ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012/256/512;
передача сведений о временном открытом ключе отправителя для предусмотренного формата KeyTransRecipientInfo;
набор параметров замены (S-box), представленный числовым OID;
восьмибайтовый UKM — дополнительные данные согласования ключей;
структура защищённого ключа содержимого: 32 байта данных и 4 байта контрольного значения в рассматриваемом формате;
восьмибайтовый вектор инициализации для шифрования содержимого ГОСТ 28147-89;
обратная запись указанных структур в CMS, если вызывающее приложение предоставляет необходимые сведения.

Библиотека распознаёт ограниченный перечень наборов замен: несколько традиционных CryptoPro и параметр ТК26 1.2.643.7.1.2.5.1.1. Это не универсальная поддержка всех возможных вариантов ГОСТ-шифрования.

Почему просто «поддержки Кузнечика» недостаточно¶

Сертификат ГОСТ, файл CMS и шифр содержимого — разные слои системы. Зашифрованный CMS-файл может использовать ГОСТ Р 34.10-2012 для операции с ключом, но ГОСТ 28147-89 для шифрования содержимого. Даже если в НАЙС.ОС работает kuznyechik-xts-plain64 для дисков, это не значит, что им можно открыть CMS-документ КриптоПро: XTS-диск и CMS-конверт используют разные форматы и процессы.

libksba отвечает за структурную совместимость. Для фактического открытия документа требуются GPGSM, доступ к закрытому ключу, правильная криптографическая операция, поддержка выбранных параметров и корректное доверие к сторонам обмена.

Как прочитать параметры неизвестного конверта¶

Сначала изучайте копию файла, не изменяя исходник:

mkdir -p "$HOME/cms-check"
chmod 700 "$HOME/cms-check"
cp /путь/к/encrypted.p7m "$HOME/cms-check/"
cd "$HOME/cms-check"
file encrypted.p7m
sha256sum encrypted.p7m

Для двоичного DER-контейнера можно посмотреть структуру:

openssl asn1parse -inform DER -in encrypted.p7m -i | head -120

Вы можете увидеть OID 1.2.643.2.2.21 (ГОСТ 28147-89), OID выбранного набора замен и структуру EnvelopedData. Их наличие ещё не гарантирует, что расшифрование получится. Если ASN.1-инструмент не прочитал файл, сначала выясните его реальный формат: CMS может быть закодирован BER, а файл иногда содержит PEM-обёртку.

Расшифрование через GPGSM¶

При наличии своего закрытого ключа и настроенного GPGSM можно выполнить:

gpgsm --list-secret-keys

gpgsm --output recovered-document.bin \
  --decrypt encrypted.p7m

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

Важно о патче r4: он содержит механизмы разбора и формирования ГОСТ-контейнеров, но в предоставленном файле нет отчёта о сквозном испытании «КриптоПро → GPGSM → расшифрованный файл» для каждого профиля. До такого испытания это следует считать предусмотренной возможностью, а не гарантированной межвендорной совместимостью.

Создание зашифрованного документа¶

Общий пользовательский сценарий GPGSM:

# Сначала импортируйте сертификат получателя:
gpgsm --import recipient.cer

# Определите его отпечаток и убедитесь, что выбран нужный получатель:
gpgsm --list-keys

# Пример общей команды GPGSM:
gpgsm --recipient 'ОТПЕЧАТОК_ПОЛУЧАТЕЛЯ' \
  --output encrypted.p7m --encrypt document.pdf

Команда показана как интерфейс приложения. Она не фиксирует ГОСТ-профиль шифрования сама по себе: используемый криптонабор зависит от возможностей и настроек приложения. Для передачи партнёру проверьте фактические алгоритмы в результате и выполнение полного цикла на принимающей стороне.

Ограничения и важные нюансы¶

Ситуация	Как поступить
Получен CMS с неизвестным набором замен	Не подменяйте OID на знакомый; запросите сведения о профиле у отправителя.
UKM имеет неожиданный размер	Это может быть неподдерживаемый вариант переноса ключа; проверьте исходный формат.
Файл содержит несколько получателей	Убедитесь, что программа выбирает нужный `RecipientInfo`; тестируйте на конкретном документе.
Использован `KeyAgreeRecipientInfo`, а не `KeyTransRecipientInfo`	Нельзя считать его автоматически поддержанным: расширение НАЙС.ОС обрабатывает определённую транспортную ветвь.
Нужен `maskKey` или иной вариант упаковки ключа	Ряд вариантов специально отклоняется библиотекой, а не игнорируется.
Ключи на USB-токене	Нужен соответствующий агент и PKCS#11/драйвер; libksba сама с устройством не взаимодействует.
В документе ГОСТ 2012	Это не означает автоматически, что шифрование содержимого выполнено «Кузнечиком»: проверяйте отдельные поля CMS.
При расшифровании ошибка проверки MAC	Не отключайте проверку; проверьте правильность ключа, набор параметров и повреждение данных.

Минимальный протокол испытания с партнёром¶

Зафиксируйте 1) версию пакета и GPGSM; 2) сертификат адресата; 3) список OID алгоритмов; 4) число получателей; 5) способ хранения закрытого ключа; 6) результат чтения и расшифрования; 7) хэш полученного файла; 8) обратное направление обмена. Если партнёр использует КриптоПро, обязательно тестируйте оба направления, а не только файлы, созданные в НАЙС.ОС.

См. матрицу совместимости и администрирование.