Добрый день, уважаемые господа (и дамы). Извиняюсь, быть может подобный вопрос уже всплывал - беглый поиск результатов не дал, в основном все вопросы про обратное. Суть вопроса:
Требуетя привести в порядок зоопарк из множества гостовских ключевых пар (.cer + .key) openssl. Рассматривается вариант импорта добра в cryptopro csp через CryptImportKeys.
Примерный план действий:
1. Из .key грузим закрытый ключ. Получаем OIDы наборов параметров и массив байт закрытого ключа pKey (кажется, big-endian)
2. Генерируем ukm (8 байт)
3. Для PBKDF2 генерируем соль salt (16 байт), придумываем строковый пароль password. Полагаем количество раундов count = 2000
4. Согласно примерам криптопро создается сессионный ключ импорта sKey (CALG_PRO12_EXPORT через CALG_PBKDF2_94_256 на основе salt, password, count). Начальный вектор ключа задаем равным ukm (проверено - при экспорте ключей вы именно начальный вектор ключа экспорта помещаете в ukm экспортированного ключа)
5. Сформированный sKey не получить (вы везде так заявляете - поправьте, если ошибаюсь) в открытом виде. Формируем его самостоятельно (все необходимое у нас имеется). Пусть это будет массив байт mKey
6. Для диверсификации ключа шифрования закрытого ключа CALG_PRO12_EXPORT использует KDF_GR3411_12_256. Диверсивицируем mKey - получаем массив байт dKey
7. Без использования cryptopro csp шифруем закрытый ключ по ГОСТ 28147-89 в режиме ECB на полученном dKey. Получаем массив eKey
8. Считаем MAC от pKey по имеющемуся ukm, получаем mac
В описанном алгоритме абсолютно уверен т.к. тренировался на обратной процедуре - получал закрытый в открытом виде через CryptExportKey (отсюда утверждение про начальный вектор sKey и ukm), получал sKey и dKey, расшифровывал экспортированный закрытый ключ, восстанавливал по нему открытый ключ и сравнивал с открытым ключом сертификата - сходилось.
9. Приступаем к формированию BLOBа для импорта ключа в криптопровайдер. Потребуются ukm, eKey, mac и полученные на ш.1 OIDы. И вот тут проблема. Заголовок BLOBа, как вы понимаете, проблем не представляет. Проблема - его тело.
При экспорте ключей стал понятен формат тела - ASN1 sequence (OS) из 2-х узлов - вложенной sequence (IS) и 4-х байтной octetstring (CS).
Структура IS вполне прозрачна, сформировать ее не сложно, все необходимое (ukm, eKey, mac и полученные на ш.1 OIDы) есть.
Далее, как я предполагаю, на основе IS каким-то образом считаетя какая-то 4-х байтная контрольная сумма CS, после чего IS и CS помещаются в OS.
В том же процессе экспорта пробовал считать MAC в разумных сочетаниях ключа и iv - не сходится.
И вот теперь сам вопрос. Будьте добры, подскажите, пожалуйста, каким образом правильно посчитать контрольную сумму CS внутренней sequence IS тела BLOBа?
Спасибо.
PS: Я уже видел массу сообщений про то, что вы думаете насчет экспорта, нормативов и рекомендаций ТК26 и прочее. Пожалуйста, не повторяйтесь. Интересует конкретный ответ на конкретный вопрос. К тому же речь не про получение закрытого ключа в открытом виде, а, наоборот, про корректное его помещение в ваш криптопровайдер. Еще раз спасибо.
