Використання ключа КриптоПро з криптопровайдером Bouncy Castle для створення ЕЦП

Завдання: реалізувати протокол обміну даними з контрагентом на основі SOAP за підписом ГОСТ та ключем КриптоПро. Java, Linux.

Завантажую КриптоПро CSP. Встановлюю. Перезавантажуючись у чорний екран, розумію, що КриптоПро вбив мою робочу Win7. Дрібниці, справа життєва. Поки відновлюється система розглядаю зображеного на їхньому логотипі проколотого наскрізь Пакмена, що вивергає кривавий фонтан. Вставляю VirtualBox з XP, на нього КриптоПро CSP - працює. Але мені перспектива переносити розробку на віртуальну машину, потім встановити КриптоПро якимось чином на бойовий linux і спробувати з цим злетіти, здалася зовсім не райдужною. Благо є чудова бібліотека BouncyCastle, яка підтримує ГОСТ. Залишилася справа за малим — дістати ключ із контейнера КріптоПро.

використання
Експорт засобами Windows дає файл, який можна відразу викинути, т.к. перевести його в потрібний формат не вдасться. Пошук виводить на утиліту P12FromGostCSP, яка вміє експортувати сертифікат та ключ у контейнер PKCS#12. Начебто те, що потрібно. Але не тут було. BouncyCastle відмовився працювати з таким контейнером. Добре,— думаю. Отже, треба дістати з PKCS#12 ключ і перевести його в потрібний формат. Для цього якнайкраще підходить OpenSSL з підтримкою ГОСТ.

До конфігураційного файлу openssl.cfg необхідно додати

змінивши шлях до gost.dll на свій.

Експортую приватний ключ

Намагаюся згодувати його BouncyCastle (BC), котрий радісно повідомляє, що я йому знову якусь фігню підсовую, а зовсім навіть і не гостьовий ключ.

Добре Добре.

bouncy

Створюю приватний ключ засобами BC, щоб зрозуміти, чого вінхоче.

криптопровайдером

використання

З структури test.key копіюю параметри ключа в template.key, а також сам ключ. Тут на мене чекав ще один сюрприз. На початок ключа КриптоПро додано ще один байт. Копіювати потрібно лише 32 байти, без першого.

Розшифровка параметрів ключа

1.2.643.2.2.35.1— szOID_GostR3410_2001_CryptoPro_A_ParamSet Параметри a, b, p,q, (x,y) цифрового підпису та алгоритму Діффі-Хеллмана на базі алгоритму ГОСТ Р 301.2.643.2.2.35.2— szOID_GostR3410_2001_CryptoPro_B_ParamSet Параметри a, b, p,q, (x,y) цифрового підпису та алгоритму Діффі-Хеллмана на базі алгоритму00 Г00. , варіант карти КриптоРІК1.2.643.2.2.35.2— szOID_GostR3410_2001_CryptoPro_C_ParamSet Параметри a, b, p,q, (x,y) цифрового підпису та алгоритму Діффі-Хе Р 34.10-2001, варіант 11.2.643.2.2.36.0— szOID_GostR3410_2001_CryptoPro_XchA_ParamSet Параметри a, b, p,q, (x,y) алгоритму Діфф Р 34.10-2001, варіант криптопровайдера. Використовуються ті ж параметри, що і з ідентифікатором szOID_GostR3410_2001_CryptoPro_A_ParamSet1.2.643.2.2.35.3- szOID_GostR3410_2001_Crypto x,y) цифрового підпису та алгоритму Діффі -Хеллмана з урахуванням алгоритму ГОСТ Р 34.10-2001, варіант 1

Зберігаю ключ template.key під іншим ім'ям. Тепер BC не лається і створює ЕЦП. Але ЕЦП не проходить перевірку. Та що це таке?!

криптопровайдером

З'ясувалося, що ЕЦП треба ще й розгорнути!

Цікаво, з чим пов'язані всі ці відмінності у структурі ключів та алгоритмі формування ЕЦП?