Поддержка pkcs#12 Крипто-Про

[vGimly]

Добавьте, пожалуйста, поддержку контейнеров секретных ключей от крипто-про, получаемых при экспорте секретных ключей средствами системы в PFX (pkcs#12).

В asn1 структуре таких контейнеров на уровне pkcs#8 (контейнера закрытого ключа) содержится недокументированный oid 1.2.840.113549.1.12.1.80 который не даёт загружать сертификат в openssl.

Если это возможно средствами openssl engine - было бы идеально читать такие контейнеры без использования сторонних утилит.

Если нет - то можно сделать open-source конвертер в поддерживаемый формат взамен платной закрытой утилиты от lissi (P12FromGostCSP/P12FromGostCSP_2016).

Снял уже транспортную кодировку, но упёрся в экспортное шифрование ключа.
Вижу в расшифрованной структуре asn1 что-то похожее на CEK_ENC, UKM, CEK_MAC (из "рекомендаций" от ТК26) но не вижу как из них получить приватный ключ K средствами gost_engine несмотря на обилие профильных функций явно уже решающих эту задачу.

[beldmit]

В отсутствие документации не могу.

[vGimly]

Документацию официальную думаю не дождаться. Сколько лет уже этому транспортному шифрованию - а упоминаний этого oid всё нет. Уже даже расшифровали сами контейнеры приватных ключей (статьи на хабре с кодом на C и реализация на яваскрипте на gostcrypto.com).
Правда, это было до алгоритмов 2012 госта - с новыми уже не работают.

123-try3.pfx.gz

Если "угадывать" то алгоритм генерации ключа для транспортного шифрования:
(данные из asn1 структуры - количество раундов и соль, + пароль от пользователя)

$ROUNDS=2000;
$SALT=pack 'H*','C16E378ABE17ADBC7C29E4F5EA4EEED9';
$KEY=encode('UCS-2LE', $PASS);

use Digest::GOST::CryptoPro qw(gost);

for (my $i=1;$i<=$ROUNDS;$i++){
$KEY=gost($KEY.$SALT.pack('n',$i))}

Там ещё проверка sha1_hmac/sha256_hmac имеется - но она вроде уже проходит для pfx.
(А у Лисов в их pfx используется какой-то гост_hmac и солят они пароль как-то нестандартно).

Раунды для пароля 123 и соли в примере:

$ echo 310032003300 c16e378abe17adbc7c29e4f5ea4eeed9 0001 | xxd -r -p > round1
$ openssl dgst -engine gost -md_gost94 -hex round1
md_gost94(round1)= fb76e01671ac07908c159f59a0442815acaccc2e77fc25958b99a4626fc738fe

310032003300c16e378abe17adbc7c29e4f5ea4eeed90001
fb76e01671ac07908c159f59a0442815acaccc2e77fc25958b99a4626fc738fec16e378abe17adbc7c29e4f5ea4eeed90002
cdae166434edddd770cbc0d7294f4031d83309206bc15a3089cbde622fba0ce7c16e378abe17adbc7c29e4f5ea4eeed90003
7afa30b660dd6a0d22a79058be2d3408165079ca5576e474a0b3578cd0ea78b1c16e378abe17adbc7c29e4f5ea4eeed90004
b986e00e01ba349fcae0b0626c4c0ac35c05e9ce50d42fc8141f29c66c080635c16e378abe17adbc7c29e4f5ea4eeed90005

финальный раунд:
9350e6ec445712728c6d7c6c02efb9068f295a3f451af8df33613bfc42412d71c16e378abe17adbc7c29e4f5ea4eeed907d0
итоговый ключ:
c2bb428f981f30d8e623db786d9bd780e7d9f785a950211530142ae46fab8dce

расшифровка транспортной "сумки" - ключ из алгоритма выше, IV обрезанная до 8 байт соль:
$ openssl enc -v -engine gost -gost89 -d -out KEY.out -in KEY.in -nosalt -K $KEY -iv $SALT

KEY.in:
C4A7BE9F5DEC55369A1E0B357B2D052256F2052E10642B47CC8A567351E81584FFD7DCB7D2384EEC4566A02A67F9EF7504D7A8FA4CCC51722D53770F2B4B4D0667F030E9060A6C0F4ED3D73342C0C1C86FD9669E9808B98A372BC0AF8919CC502F9C74351C60B43AD89D6F4155035CDA5EBE92C36D3D2C8EA562F0F5584529552258AAC84CC4

должна получиться asn1 структура, в которой содержится структура, начинающаяся с байтов 20 07 и asn1 со смещения в 16 байт. В заголовке имеются упоминания алгоритмов CALG которые указывают на тип приватного ключа.
Идентичную структуру уже выдаёт функция exportkey при экспорте приватного ключа через windows crypto api.

UKM=FEF0268E68E6A7EA
CEK_ENC=7987275594A59F491E62F636F794BDD49A5CD547E0D901DF3AD58DA9EFFC2657
CEK_MAC=68369E8A или B30785AA ( в структуре 2 бинарных величины каждая длинной 4 байта)

Транспортное шифрование не зависит от типа ключа - и гост2001 ключи и 2012 256/512 расшифровываются идентично.

Реализации же алгоритмов экспортного шифрования у Вас имеются - даже примеры из документации взяты. Как их применять к полученной структуре вот в чём вопрос.

В итоге должен получиться такой ключ GOST R 34.10-2001:
public_key=
3271B0ABC9CC92142384D0B10ADCBC4124A1D5A9AFD440F6A99AADDD882E70CF
DB9AED1682A945DF956E04F8C97E8333CF839B461353BED1A04CD99304372B71
private_key=042031967658C0647ACDBD2C8A8D55CC031803208D94292C16221F68D9D7CAA5D73E

Примеров могу ещё наделать.

[beldmit]

Не, код для 2001-го года с Хабра я видел. А адаптации под 2012-й нет, и простая замена алгоритмов по OID-ам не работает.

[vGimly]

Чужие контейнеры ключей вскрывать - не очень штатная задача для openssl.
Приватный ключ можно выгрузить через системный certmgr в pfx файл (если экспорт приватного ключа разрешён). А это уже обычный pkcs12 - но его не может прочитать openssl из-за недокументированного oid.

Транспортную кодировку снимаем - получаем приватный ключ зашифрованный CALG_PRO_EXPORT/CALG_PRO12_EXPORT который уже как-то документирован.
И в рекомендациях TC26 - и в rfc4357 - и многие функции оттуда уже реализованы в Вашем коде.

В утилитах p12fromgost (есть версия которая работает и с 2012 ключами) - получают через winapi как раз ключи в экспортной кодировке, снимают её (есть место, где ключ в открытом виде) - а дальше снова шифруют уже в свой опять недокументированный формат. И уже с таким форматом работают. Благо их версия XCA умеет импортировать этот формат но также и экспортировать приватные ключи в открытом виде (PEM без шифрования).

[beldmit]

Это красивая высокая теория, но идей, как её сконвертировать в практику, я пока не видел.

[beldmit]

Закрываю.

[s-sokolko]

Есть утилита для извлечения сертификата и ключа из контейнера КриптоПРО. Проверял сам, работает:

https://github.com/kov-serg/get-cpcert

Собрал для неё докер-контейнер, если кому-то потребуется подобное:

https://github.com/s-sokolko/export-cryptopro-cert-docker

[li0ard]

Тема до сих пор актуальна. Хотелось бы все таки чтобы разработчик посодействовал

[beldmit]

Если вы добавите pull request, который будет собирать утилиту для работы с криптопрошным контейнером как отдельную цель в CMake, я это приму. Как ещё я могу посодействовать, я не очень понимаю.

[li0ard]

Помочь дореализовать снятие экспортного шифрования, как сказал @vGimly многие функции из рекомендаций тк-26 и rfc у вас уже реализованы, та же KDF, KEKe(UKM) и сам враппинг ключей

[beldmit]

Так не хватает-то чего, именно в engine?

[li0ard]

Функции расшифровки ключа по Ke, CEK_ENC, UKM, CEK_MAC как для 2001 так и для 2012 госта

[li0ard]

Ну что, доковырял этот ваш CALG_PRO12_EXPORT, написал простенькую программу на Go, которая позволяет получить ключи для снятия как транспортной так и экспортной (CALG_PRO12_EXPORT) кодировки. Если говорить в двух словах то хэшированный ключ прогоняется через KDF_GOSTR3411_2012_256 (не путать с KDF_TREE_GOSTR3411_2012_256) и уже результат функции используется для unwrap ключа.

Программа на Go

[ilya-maltsev]

В отсутствие документации не могу.

@chipitsine
Приветствую.
Официальная дока по этой теме исходит от ТК 26:
МР 26.2.001-2012 «Парольная защита с использованием алгоритма ГОСТ Р»
МР 26.2.002-2012 «Транспортный ключевой контейнер»
МР 26.2.03-2012 «Ключевой контейнер»

Доки в виде национальных стандартов:
Р 50.1.110-2016
Р 50.1.111-2016
Р 50.1.112-2016

Доки в виде RFC:
RFC 9337 Generating Password-Based Keys Using the GOST Algorithms
RFC 9548 Generating Transport Key Containers (PFX) Using the GOST Algorithms

Готовы ли вы рассмотреть PR по данной теме?