Скачать Конвертер ЭЦП для ГИИС Электронный бюджет | Яндекс.Дзен: каналы, советы, продвижение

Скачать Конвертер ЭЦП для ГИИС Электронный бюджет | Яндекс.Дзен: каналы, советы, продвижение ЭЦП

Что нужно допилить в готовом клиенте, чтобы сбежать с крипто про

Код написан довольно дружелюбно для расширения, поэтому можно просто взять за основу класс 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 символов в поле «название», но сертификаты всё-равно не видны. Как видите, «временное решение» стало постоянным. Потому что прошло полтора года, и воз ныне там.

Резюме

В результате всех вышеописанных действий мы получили относительно легий способ избавиться от тяжкой ноши Крипто Про.

В дальнейшем хотелось бы продолжить борьбу за выпил до финальной победы: оформить все утилиты, генераторы ключей, самописные смэв-клиенты итп в виде одного репозитория на Гитхабе. Еще, очень хотелось бы получить права на модификацию и распространение под пермиссивной лицензией официального клиента СМЭВ. Тогда половина этой статьи была бы просто не нужна, и проблема решалась бы скачиванием нужного кода с Гитхаба.

Тестовые самоподписанные ключи

Так как мы деламем все это в тестовых целях, теперь мы подходим к кульминации и начинаем сами себе выдавать ключи.

Оцените статью
ЭЦП64
Добавить комментарий