Парольная защита, транспортные ключевые контейнеры и PFX ГОСТ¶

Разделяем пароль, ключ и контейнер¶

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

Р 1323565.1.040-2022 — действующие рекомендации по парольной защите ключевой информации; введены 1 мая 2023 года. RFC 9337 (декабрь 2022 года) описывает получение ключей из пароля через PKCS#5/PBKDF2 и HMAC на «Стрибоге».

Р 1323565.1.041-2022 — рекомендации по транспортному ключевому контейнеру, действующие с мая 2023 года. RFC 9548 (май 2024 года) описывает применение PKCS#12/PFX с ГОСТ: структуры безопасного содержимого, закрытых ключей, сертификатов и защиты паролем; имеется приложение с тестовыми примерами.

Важно: формат PFX сам по себе не означает, что внутри применяются ГОСТ-алгоритмы. Стандартный PKCS#12 и ГОСТ-профиль PKCS#12 могут требовать разных PRF, OID и механизмов защиты содержимого.

Что изучать в PFX¶

Объект	Назначение
PFX / AuthenticatedSafe	Контейнер и способ защиты безопасных областей
SafeContents / SafeBag	Представление ключей, сертификатов и служебных атрибутов
`EncryptedPrivateKeyInfo`	Защита закрытого ключа
Параметры PBKDF	Соль, число итераций и используемая PRF
OID алгоритма	Способ шифрования и формат данных
MAC / проверка целостности	Выявление модификации контейнера

Диагностика в НАЙС.ОС¶

openssl version
openssl list -providers
openssl pkcs12 -info -in test.pfx -noout

Команда -info показывает структуру и криптографические параметры, но для чтения зашифрованных областей потребуется корректный пароль и поддержка алгоритмов. Запускайте её только на своём тестовом контейнере. Не добавляйте реальные закрытые ключи и пароли в логи, репозитории или диагностические архивы. Для тестов на совместимость можно использовать открытые тестовые данные из приложения A RFC 9548, учитывая условия использования документа.

В чём разница с ГОСТ-LUKS2¶

Испытанный том НАЙС.ОС kuznyechik-xts-plain64 использовал ГОСТ для шифрования сектора данных, но luksDump показал отдельные алгоритмы защиты ключевого слота: aes-xts-plain64, Argon2id и SHA-256. Это не является реализацией ГОСТ-PFX из RFC 9548 или PBKDF2-ГОСТ из RFC 9337.

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

Полный путь закрытого ключа при переносе¶

Закрытый ключ ГОСТ + сертификат + доверенная цепочка
              |
     пароль → KDF / salt / iterations
              |
              v
     PFX / AuthenticatedSafe / SafeBag
              |
     MAC / защита целостности / OID
              |
              v
     перенос → импорт → проверка параметров
              |
              v
     операция подписи новым приложением

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

Контрольный список импорта PFX¶

Что проверить	Почему это критично
Открытие самого PFX без ошибок ASN.1	Корректность контейнера, но не его ГОСТ-профиля
Соль, число итераций, PRF/KDF	Стоимость перебора пароля и совместимость реализации
OID симметричного шифра и обёртки	Выбор реального алгоритма для защиты ключа
Присутствие сертификата и цепочки	Возможность привязать закрытый ключ к субъекту
Проба подписи/проверки на тестовом сообщении	Доказательство соответствия ключа сертификату
Политика резервного копирования	Избежание утраты ключа или его несанкционированного копирования

Нюансы пароля¶

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

Отличие трёх механизмов¶

PFX/PKCS#12: перенос закрытых ключей/сертификатов между программами (RFC 7292, ГОСТ-профиль RFC 9548).
CMS EnvelopedData: передача зашифрованного сообщения получателю (RFC 5652, теория).
LUKS2: долговременное шифрование дискового устройства и управление ключевыми слотами (практика); алгоритмы ключевого слота не обязаны совпадать с алгоритмами данных.

В НАЙС.ОС команды openssl pkcs12 и операции с ключами зависят от сборки OpenSSL и включённых ГОСТ-компонентов. Не заявляйте совместимость с RFC 9548 только на основании openssl pkcs12 -info: требуется успешный двусторонний обмен с проверкой всей криптографии. Руководство PKCS#12 и матрица совместимости.