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

Администрирование libksba с ГОСТ в НАЙС.ОС

Эта глава предназначена для системных администраторов, инженеров сопровождения и специалистов ИБ. Она описывает развёртывание, проверку и эксплуатацию на серверах и рабочих местах. Здесь нет необходимости компилировать библиотеку вручную или редактировать её исходный код.

1. Какие пакеты отвечают за процесс

Компонент Назначение
libksba Разбор X.509, CMS, алгоритмов и параметров подписи/шифрования
libgcrypt Криптографические вычисления, необходимые GnuPG
gnupg и gpgsm Пользовательские операции подписи, проверки, шифрования, импорта сертификатов
gpg-agent Доступ к закрытым ключам и запрос пароля/PIN в поддерживаемых конфигурациях
dirmngr Работа с сетевыми службами сертификатов, включая CRL/OCSP согласно конфигурации
p11-kit, OpenSC, вендорские компоненты Дополнительные средства для доверия или ключевых носителей, если используются
openssl Отдельный инструмент диагностики и отдельный криптографический стек

Принцип: наличие libksba само по себе не означает наличия команд gpgsm, настроенного GPG Agent или доступа к токену.

2. Проверка версии и происхождения пакета

rpm -q libksba libgcrypt gnupg
rpm -qi libksba
rpm -ql libksba | head -60

gpgsm --version

Команда gpgsm --version показывает версию GPGSM и часть сведений о криптографическом окружении, но не доказывает автоматически, что запущен именно ГОСТ-расширение НАЙС.ОС. Проверяйте метаданные RPM, журнал сборки, идентификатор пакета и документацию к поставке. Если рядом установлены несколько вариантов libksba, убедитесь, что приложение загружает системную библиотеку, а не копию из собственного каталога:

command -v gpgsm
ldd "$(command -v gpgsm)" | grep -E 'ksba|gcrypt|gpg-error' || true
ldconfig -p | grep -i libksba || true

В некоторых сборках GPGSM не связывается с библиотекой тем способом, который отображает ldd; при отсутствии строки в ldd исследуйте установленный состав пакетов, не делайте поспешных выводов.

3. Установка и обновление

tdnf install libksba libgcrypt gnupg

Если используется dnf, команды аналогичны. Установка только перечисленных пакетов не заменяет проверку соответствующей сборки libksba. Версия RPM и бинарный состав должны соответствовать выпуску НАЙС.ОС, содержащему расширения ГОСТ. Перед обновлением важных систем электронной подписи сохраняйте сведения о версии и результаты контрольных проверок.

rpm -q libksba libgcrypt gnupg > /root/crypto-packages-before.txt
rpm -V libksba

rpm -V выявляет расхождения с установленной RPM-базой; успешная проверка не является криптографическим тестом. Не подменяйте файлы библиотеки вручную и не собирайте её «поверх системы» на продуктивном сервере. После обновления проверяйте не только запуск GPGSM, но и известные тестовые сертификаты и подписанные документы.

4. Отдельный испытательный профиль GnuPG

Чтобы случайно не изменить рабочие цепочки доверия и закрытые ключи, создавайте временный пользовательский профиль:

TEST_HOME=$(mktemp -d)
chmod 700 "$TEST_HOME"
printf 'Испытательное хранилище: %s\n' "$TEST_HOME"

GNUPGHOME="$TEST_HOME" gpgsm --version
GNUPGHOME="$TEST_HOME" gpgsm --import /путь/к/test-ca.cer
GNUPGHOME="$TEST_HOME" gpgsm --list-keys

Импортируйте только открытые испытательные сертификаты. Не переносите туда рабочие закрытые ключи ради диагностики. Сначала сохраните протокол и убедитесь, что тестовый каталог не содержит важные данные. Удалять его можно лишь после этого.

5. Проверка ГОСТ-ключей разных поколений

Минимальный набор открытых примеров: сертификат ГОСТ 2001 CryptoPro-A, сертификат ГОСТ 2012/256 и сертификат ГОСТ 2012/512. Для каждого необходимо получить: корректный разбор структуры, отображение субъекта/издателя/срока, корректный открытый ключ и затем отдельный положительный и отрицательный сценарий проверки подписи. Нельзя ограничиваться только тем, что команда не упала.

Если в организации одновременно хранятся старые и новые сертификаты, храните эталонные тестовые файлы и протоколы в системе контроля версий без закрытых ключей. Перед каждым крупным обновлением повторяйте одну и ту же матрицу.

6. Проверка и учёт CMS

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

  1. CMS распознан как нужный тип.
  2. Сертификат нужного лица идентифицирован.
  3. Использован корректный алгоритм и набор параметров.
  4. Для SignedData проверена математическая подпись.
  5. Отдельно проверена цепочка доверия и статус отзыва.
  6. Для EnvelopedData файл расшифрован тем, кому он адресован.
  7. Данные после расшифрования побайтно совпадают с исходником.
  8. Повреждённый документ или изменённая подпись отвергаются.

Сами файлы испытаний должны быть обезличены и разрешены к хранению; настоящие личные документы и рабочие закрытые ключи в публичный репозиторий помещать нельзя.

7. Корневые сертификаты и политика доверия

Системное хранилище доверенных УЦ, настройки GnuPG/GPGSM и встроенные хранилища приложений могут различаться. Даже после установки сертификата в системный каталог приложение не обязательно начнёт автоматически ему доверять. Не превращайте технический тест разбора файла в безусловное доверие всем сертификатам, выданным определённым центром.

При диагностике цепочки проверяйте: наличие промежуточного УЦ, назначение ключа, сроки, CRL/OCSP, время сервера, сетевую доступность служб УЦ и правила GPGSM/dirmngr. При необходимости запускайте временную проверку в отдельном GNUPGHOME, а не меняйте глобальные доверенные корни.

8. Миграция с обычной сборки Linux

При переносе рабочих процессов с другой системы не копируйте закрытые ключи «наугад». Сначала инвентаризируйте:

  • форматы сертификатов и документов;
  • алгоритмы и их OID;
  • наборы параметров кривых CryptoPro/ТК26;
  • используемые программы (gpgsm, офисные приложения, ЭДО, криптопровайдеры);
  • способы хранения секретных ключей и PIN;
  • статус сертификатов в системе доверия;
  • потребность в старых ГОСТ 2001 документах;
  • процедуры архивной проверки подписей.

Затем переносите публичные сертификаты, тестируйте существующие подписи, и только после этого проектируйте доступ к закрытым ключам и промышленный обмен. Если производитель требует собственный CSP или ключевой контейнер, само наличие libksba НАЙС.ОС не устраняет это требование.

9. Обновление без ухудшения совместимости

Один из рисков — ситуация, когда после обновления криптографического пакета сертификат по-прежнему импортируется, но перестаёт подтверждаться подпись CMS или перестаёт открываться старый конверт. Используйте последовательность: зафиксировать версии → проверить эталонные сертификаты → проверить старый и новый CMS → обновить пакеты → повторить те же тесты → принять решение по результатам. Не считайте отсутствие ошибок установки признаком отсутствия регрессий.

10. Безопасность эксплуатации

  • Никогда не отправляйте закрытые ключи, PFX или оригиналы конфиденциальных документов в общедоступные анализаторы ASN.1.
  • Ограничьте права на каталоги испытаний и журналы, содержащие персональные данные.
  • Не записывайте пароли и PIN в истории shell, CI-логи или URL.
  • Отдельно защищайте архивы документов и копии сертификатов.
  • Учитывайте отзыв, время и доверие; успешная математика ещё не доказывает право подписанта.
  • Не выключайте проверку ошибок разбора, MAC или подписи ради совместимости.
  • Пробуйте новые ГОСТ-профили сперва в изолированном окружении.
  • Для юридически значимого документооборота применяйте подходящее сертифицированное ПО и процедуры, если того требует регламент.

См. диагностику и вопросы. Первоисточники: libksba, GPGSM, RFC 9215, RFC 5652.