- Что нужно допилить в готовом клиенте, чтобы сбежать с крипто про
- Почему крипто про jcp зло
- Обоснование нужности готового клиента
- Disclamer
- Выдача контейнера pkcs12
- Инициализация xml-подписи в santuario
- Как мы можем попросить крипто про отдать ключи (на самом деле, нет)
- Подготовка openssl для работы с гост
- Проблема с отображением контейнеров эцп в гиис эб
- Резюме
- Тестовые самоподписанные ключи
Что нужно допилить в готовом клиенте, чтобы сбежать с крипто про
Код написан довольно дружелюбно для расширения, поэтому можно просто взять за основу класс KeyStoreWrapperJCP, и аналогично написать KeyStoreWrapperBouncyCastlePKCS12, KeyStoreWrapperBouncyCastleJKS.
Переписать DigitalSignatureFactory, так, чтобы он на вход начал принимать путь до криптоконтейнера на файловой системе и пароль от него (для КриптоПро это просто не нужно). Там есть свич, который проверяет тип криптопровайдера, в него надо дописать дополнительно два кейса, для имен типа BOUNCY_JKS и BOUNCY_PKCS12 и навешать использование соответсвующих KeyWrapper и вызов initXmlSec.
В initXmlSec нужно дописать1) возможность принимать вообще любой провайдер, а не только криптопро (это просто удобно)2) Security.addProvider(new BouncyCastleProvider());3) для XMLDSIG_SIGN_METHOD сделать свич: если КриптоПро, то алгоритм называется «GOST3411withGOST3410EL», а если BouncyCastle алгоритм называется «GOST3411WITHECGOST3410».
Ну вроде как и все. Если бы была известна лицензия на этот смэв-клиент, я бы приложил конкретный код под Apache License 2, а так это просто список идей.
Почему крипто про jcp зло
- Если у вас много разработчиков и виртуальных машин, покупать лицензию не очень хочется
- Проприетарщина, поэтому все описанные ниже баги исправить нельзя. Точнее можно (дизассемблер стреляет без промаха), но незаконно и с потерей всех гарантий — не вариант
- На Java 8 под OSX завести не удалось (никакую версию КП JCP). Скорей всего это исправят довольно скоро, т.к. представители отреагировали на мой пост в Фейсбуке
- Вообще, на OSX завести не удалось. Гуй админки — полурабочий, сыпет ошибками, куски гуя не работают.
- На линуксе тоже есть баги в интерфейсе
- Когда-то давно установщик на Windows писал в консоли крокозябры (не проверял на новых версиях — может, пофиксили)
- Установка патчингом дистрибутива джавы. Ящетаю, что установка софта методом патчинга джавы — это зло в последней инстанции, за это суд по правам человека должен назначать шестикратный расстрел с повешанием
- Не каждую джаву можно пропатчить, для выяснения магической комбинации нужно серьезно упороться. Тут важно, что мы стараемся разрабатывать на самых новых версиях джавы, с пылу-с жару, и тестируем на новых версия (на момент написания статьи — JDK9), так что ограничения на версию джавы — это безумие как оно есть
- Способы инсталляции и запуска админки — лютый треш (это надо видеть)
В качестве альтернативы в тестовом окружении я предалагю использовать Bouncy Castle с контейнером PKCS12 или JKS. Это открытое, свободное и бесплатное ПО.К чести разработчиков Крипто Про, похоже, они принимали участие в его разработке.
Обоснование нужности готового клиента
На технологическом портале СМЭВ3 лежат исходники клиента, но вот незадача — они гвоздями прибиты к КриптоПро. Вордовский файл с инструкцией, приложенный к исходникам, утверждает это самым прямым образом. Да и все равно, исходные ключи у нас тоже в формате КриптоПро. Исходя из production это нормально, а вот для тестового окружения жутко неудобно. Хотелось бы от этого избавиться.
На сайте есть две версии — «актуальная» и «рекомендуемая». Почему они так, и почему актуальная версия не рекомендуется, а рекомендуемая не актуальна — какая-то дилемма копирайтера 🙂 Дальше речь о том клиенте который «актуальный».
Строго говоря, использовать его нельзя, потому что в архиве исходников нету текста лицензии, и поэтому непонятно, под какой лицензией должна распространяться производная работа. Я позвонил по телефону поддержки, написанному на портале, написал на почту, пару недель наблюдал как моя заявка летает между уровнями техподдержки и исполняющими организациями, и в результате воз и ныне там:
Задача не выполнена, но выполнена и закрыта, изумительно. Ладно, черт с ними…
Несмотря на невозможность использовать его у себя непосредственно в коде, это отличный тестовый пример. Дело в том, что в методических рекомендациях СМЭВа без поллитры не разобраться, и готовый живой код дает отличный буст к пониманию.
Основная претензия к документации — это канцеляризмы и скудное описание в интернете.Помните мем про копирайтера, который из абзаца сделал одно предложение в несколько слов? Для документации СМЭВа это имеет место быть, например вот цепочка рефакторинов для одной произовльно взятой фразы:
«2. ИС потребителя направляет в СМЭВ межведомственный запрос;»»2. ИС потребителя направляет в СМЭВ запрос;»»2. ИС потребителя направляет запрос;»»2. потребитель направляет запрос;»»2. запрос потребителя;»
Короче, наличие готовой реализации — это добро.
Disclamer
Конечно, сбежать с Крипто Про невозможно, потому что это оплот российской криптографии. Он удовлетовряет требованиям компетентных органов, он прописан в договоры и контракты, ему доверяет вся страна, и так далее. Поэтому все нижеописанное относится девелоперскому или тестовому окружению, где мы сами себе хозяева.
Недавно мне нужно было разобраться, как написать сервис, работающий с Системой Межведомственного Электронного Взаимодействия.Все написанное представляет собой просто результат небольшого исследования, максимально абстрагированный от выполненной работы. И даже приблизительно угадать что-то о реально принятых решениях невозможно, я проверял.
Выдача контейнера pkcs12
В принципе, это не особо нужно, потому что у нас уже есть простой и удобный способ выдавать JKS, а JKS для Java это самое что ни на есть родное решение. Но для полноты картины, пусть будет.
Инициализация xml-подписи в santuario
Ах да, тут есть один интересный момент. В сети множество советов, касающихся СМЭВа, заключающихся в ручном парсинге кусков XMLек, и прочим закатом солнца вручную, но это не наш метод (и не метод, который использовали создатели клиента)
Замес в том, что сгенерить самоподписанные ключи по госту легко (копипаста на SO ищется за секунды). А вот подписать — нет, ибо по мнению интернет-школьников якобы Bouncycastle не поддерживает xml-подпись. Конкретней, при работе с Apache Santuario, XMLSignature из santuario-xmlsec не понимает что использовать для обработки метода «xmldsig-more#gostr34102001-gostr3411» при вызове xmlSignature.sign(privateKey).
Отдельная хохма в том, что IntelliJ IDEA Community глючит при попытке отдебажить xmlsec, бросая step in отладчика в неверное место верных исходников. Я попробовал все разумные версии Идеи, поэтому понимать как это работает надо вслепую, написуя тактические письма в Спортлото. Это не в укор Идее, не существует идеальных инструментов, просто фактор повлиявший на скорость понимания вопроса.
Чтобы это заработало, нужно:
Как мы можем попросить крипто про отдать ключи (на самом деле, нет)
Если у нас уже есть настоящие (не самоподписанные) ключи, то совершенно некисло было бы проверить их в действии. Да, мы говорим о тестовых целях, но таки доверяй — но проверяй!
Если поставить винду в виртуальную машину, накатить туда Крипто Про, установить ключи и попробовать их экспортировать, то обнаруживаем удивительную вещь: в экспортере не работает экспорт в PKCS12, а все остальные направления в экспортере заблокированы (англ. «grayed out»).
Подготовка openssl для работы с гост
Если у вас в начале статьи на стене висит OpenSSL, когда-нибудь он точно выстрелит.Так что да, это важный момент, необходимый для осуществления дальнейшего текста.
Проблема с отображением контейнеров эцп в гиис эб
В частности, коль уж вы пришли сюда за конвертером ЭЦП, то до сих пор УФК ничего не сделало с тем, что во многих организациях Jinn-client просто не видит сертификаты при подписании документов в ГИИС ЭБ. Официальные лица УФК поясняют:
Установлена проблема с отображением контейнеров ГОСТ-2022 при
подписании в Электронном бюджете, в сертификатах которых поле
«Организация» превышает 127 символов.Чтобы при подписании электронной подписью Jinn Client отобразил
сертификат по ГОСТ-2022, необходимо иметь ключ на носителе
в контейнере PKCS#15.
Но в настоящий момент ключи создаются в контейнере PKCS#12.Внимание: В качестве временного решения предлагается
выполнить конвертацию контейнеров КриптоПро PKCS#12 в PKCS#15
специальной утилитой. "Конвертер ЭЦП".
Ну, вот наша организация, к примеру, имеет длину менее 127 символов в поле «название», но сертификаты всё-равно не видны. Как видите, «временное решение» стало постоянным. Потому что прошло полтора года, и воз ныне там.
Резюме
В результате всех вышеописанных действий мы получили относительно легий способ избавиться от тяжкой ноши Крипто Про.
В дальнейшем хотелось бы продолжить борьбу за выпил до финальной победы: оформить все утилиты, генераторы ключей, самописные смэв-клиенты итп в виде одного репозитория на Гитхабе. Еще, очень хотелось бы получить права на модификацию и распространение под пермиссивной лицензией официального клиента СМЭВ. Тогда половина этой статьи была бы просто не нужна, и проблема решалась бы скачиванием нужного кода с Гитхаба.
Тестовые самоподписанные ключи
Так как мы деламем все это в тестовых целях, теперь мы подходим к кульминации и начинаем сами себе выдавать ключи.