- PVSM.RU - https://www.pvsm.ru -
Эта статья посвящена тому, как перестать использовать Крипто Про и перейти на Bouncy Castle в девелоперском/тестовом окружении.
В начале статьи будет больше про СМЭВ и его клиент, в конце — больше про конвертирование ключей с готовой копипастой, чтобы можно было начать прямо сейчас.
Картинка для привлечения внимания:
И сразу же ответ:
Коненчо, сбежать с Крипто Про невозможно, потому что это оплот российской криптографии. Он удовлетовряет требованиям компетентных органов, он прописан в договоры и контраты, ему доверяет вся страна, и так далее. Поэтому все нижеописанное относится девелоперскому или тестовому окружению, где мы сами себе хозяева.
Недавно мне нужно было разобраться, как написать сервис, работающий с Системой Межведомственного Электронного Взаимодействия.
Все написанное представляет собой просто результат небольшого исследования, максимально абстрагированный от выполненной работы. И даже приблизительно угадать что-то о реально принятых решениях невозможно, я проверял.
На технологическом портале СМЭВ3 лежат исходники клиента, но вот незадача — они гвоздями прибиты к КриптоПро. Вордовский файл с инструкцией, приложенный к исходникам, утверждает это самым прямым образом. Да и все равно, исходные ключи у нас тоже в формате КриптоПро. Исходя из production это нормально, а вот для тестового окружения жутко неудобно. Хотелось бы от этого избавиться.
На сайте есть две версии — "актуальная" и "рекомендуемая". Почему они так, и почему актуальная версия не рекомендуется, а рекомендуемая не актуальна — какая-то дилемма копирайтера :) Дальше речь о том клиенте который "актуальный".
Строго говоря, использовать его нельзя, потому что в архиве исходников нету текста лицензии, и поэтому непонятно, под какой лицензией должна распространяться производная работа. Я позвонил по телефону поддержки, написанному на портале, написал на почту, пару недель наблюдал как моя заявка летает между уровнями техподдержки и исполняющими организациями, и в результате воз и ныне там:
Задача не выполнена, но выполнена и закрыта, изумительно. Ладно, черт с ними...
Несмотря на невозможность использовать его у себя непосредственно в коде, это отличный тестовый пример. Дело в том, что в методических рекомендациях СМЭВа без поллитры не разобраться, и готовый живой код дает отличный буст к пониманию.
Основная претензия к документации — это канцеляризмы и скудное описание в интернете.
Помните мем про копирайтера, который из абзаца сделал одно предложение в несколько слов? Для документации СМЭВа это имеет место быть, например вот цепочка рефакторинов для одной произовльно взятой фразы:
"2. ИС потребителя направляет в СМЭВ межведомственный запрос;"
"2. ИС потребителя направляет в СМЭВ запрос;"
"2. ИС потребителя направляет запрос;"
"2. потребитель направляет запрос;"
"2. запрос потребителя;"
Короче, наличие готовой реализации — это добро.
В качестве альтернативы в тестовом окружении я предалагю использовать Bouncy Castle с контейнером PKCS12 или JKS. Это открытое, свободное и бесплатное ПО.
К чести разработчиков Крипто Про, похоже, они принимали участие в его разработке.
Код написан довольно дружелюбно для расширения, поэтому можно просто взять за основу класс 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, а так это просто список идей.
Ах да, тут есть один интересный момент. В сети множество советов, касающихся СМЭВа, заключающихся в ручном парсинге кусков XMLек, и прочим закатом солнца вручную, но это не наш метод (и не метод, который использовали создатели клиента)
Замес в том, что сгенерить самоподписанные ключи по госту легко (копипаста на SO ищется за секунды). А вот подписать — нет, ибо по мнению интернет-школьников якобы Bouncycastle не поддерживает xml-подпись. Конкретней, при работе с Apache Santuario, XMLSignature из santuario-xmlsec не понимает что использовать для обработки метода "xmldsig-more#gostr34102001-gostr3411" при вызове xmlSignature.sign(privateKey).
Отдельная хохма в том, что IntelliJ IDEA Community глючит при попытке отдебажить xmlsec, бросая step in отладчика в неверное место верных исходников. Я попробовал все разумные версии Идеи, поэтому понимать как это работает надо вслепую, написуя тактические письма в Спортлото. Это не в укор Идее, не существует идеальных инструментов, просто фактор повлиявший на скорость понимания вопроса.
Чтобы это заработало, нужно:
1) Заимплементить реализацию SignatureAlgorithmSpi из Apache Santuario. В GetEngineUri вернуть строку: "http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411 [1]" (или что там у вас). Это ключевая магия. Совершенно ничего умного этот класс делать не должен.
Инициализация раз за всю жизнь приложения (н-р в синглтон-бине спринга):
2) Загрузить провайдер, чтобы не патчить JDK:
Security.addProvider(new BouncyCastleProvider());
3) Впердолить в рантайм только что написанный класс:
String algorithmClassName = "fully qualified name класса реализующего SignatureAlgorithmSpi";
Class.forName(algorithmClassName);
SignatureAlgorithm.providerInit();
SignatureAlgorithm.register("http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411", algorithmClassName);
4) Достучаться до маппингов алгоритмов JCE:
String ns = "http://www.xmlsecurity.org/NS/#configuration";
Document document = DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
Element rootElement = document.createElementNS(ns, "JCEAlgorithmMappings");
Element algorithms = document.createElementNS(ns, "Algorithms");
5) Замапить метод на алгоритм:
Element aElem = document.createElementNS(NameSpace, "Algorithm");
aElem.setAttribute("URI", "http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411");
aElem.setAttribute("Description", "GOST R 34102001 Digital Signature Algorithm with GOST R 3411 Digest");
aElem.setAttribute("AlgorithmClass", "Signature");
aElem.setAttribute("RequirementLevel", "OPTIONAL");
aElem.setAttribute("JCEName", "GOST3411WITHECGOST3410");
algorithms.appendChild(aElem);
6) Применить маппинги:
org.apache.xml.security.Init.init();
JCEMapper.init(rootElement);
6) PROFIT!
После этого XMLSignature резко начинает понимать этот метод, и начнет делать xmlSignature.sign.
Если у вас в начале статьи на стене висит OpenSSL, когда-нибудь он точно выстрелит.
Так что да, это важный момент, необходимый для осуществления дальнейшего текста.
openssl_conf = openssl_def
В самый конец файла добавить строчки:
[openssl_def]
engines = engine_section
[engine_section]
gost = gost_section
[gost_section]
engine_id = gost
dynamic_path = ./gost.dll
default_algorithms = ALL
CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet
Если у нас уже есть настоящие (не самоподписанные) ключи, то совершенно некисло было бы проверить их в действии. Да, мы говорим о тестовых целях, но таки доверяй — но проверяй!
Если поставить винду в виртуальную машину, накатить туда Крипто Про, установить ключи и попробовать их экспортировать, то обнаруживаем удивительную вещь: в экспортере не работает экспорт в PKCS12, а все остальные направления в экспортере заблокированы (англ. "grayed out").
Гуглю ошибку, и что же мы видим на официальном форуме?
https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=2425 [4]
"От Алексея Писинина был получен ответ:
Добрый день. PKCS12 не соответствует требованиям безопасности ФСБ в части хранения закрытых ключей. В теории, закрытые ключи должны храниться на так называемых "съемных" носителях. Собственно, по этой причине и не работает экспорт."
Я правильно это читаю как, что у них гуй для экспорта есть, но бизнес-логики к нему нету?!
Ппоэтому каких галочек ни нащелкай — всегда будет выпадать ошибка на последнем шаге гуевого мастера?!
Какой же стыд.
Dear God,
Please kill them all.
Love, Greg.
Можно очень долго мучиться, пытаясь засучив C++ вычитать ключ из контейнера с помощью OpenSSL и такой-то матери. Я честно пытался, и разбился об задачу как корабль об скалы (по крайней мере, это задачка больше чем на 1 день для человека, который давно таким не занимался). На просторе интернетов мы не единственные, кто разбился об те же скалы: http://gigamir.net/techno/pub903517 [5]
Вот тут наступает момент "это радость со слезами на глазах". Некая контора под названием Лисси Софт, всего за 2 тыщи рублей отдает нам гениальную утилиту P12FromGostCSP. Ее создатели таки победили ту проблему, которую не осилило сообщество, и она выдирает ключи в PFX. Радость — потому что она работает.
Со слезами — потому что это проприетарщина, и она фиг знает как работает.
На картинке Ричард Столлман как бы удивляется и спрашивает: "неужели вы боретесь с проприетарщиной с помощью другой проприетарщины?"
Так что целиком инструкция по перегону ключей выглядит как-то так:
openssl pkcs12 -in p12.pfx -out private.key.pem -name "alias"
openssl pkcs12 -export -out private.key.pkcs12 -in private.key.pem -name "alias"
Так как мы деламем все это в тестовых целях, теперь мы подходим к кульминации и начинаем сами себе выдавать ключи.
Как выдать ключи в формате Крипто Про, я особо не заморачивался, потому что это просто не нужно в рамках текущей задачи. Но на всякий случай, существует сервис выдачи таких ключей: http://www.cryptopro.ru/certsrv/ [6]
Этот вопрос широко представлен в интернете, поэтому можно сразу смотреть Stackoverflow:
http://stackoverflow.com/questions/14580340/generate-gost-34-10-2001-keypair-and-save-it-to-some-keystore [7]
Идея в том, что раз уж мы все равно используем Bouncy Castle, то им же можем и сгенерить ключ.
Этот код не самый идеальный, но дает реально работающую реализацию (на практике у меня в результате получилось несколько объемных классов, чтобы сделать удобный интерфейс)
Security.addProvider( new org.bouncycastle.jce.provider.BouncyCastleProvider() );
KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance( "ECGOST3410", "BC" );
keyPairGenerator.initialize( new ECGenParameterSpec( "GostR3410-2001-CryptoPro-A" ) );
KeyPair keyPair = keyPairGenerator.generateKeyPair();
org.bouncycastle.asn1.x500.X500Name subject = new org.bouncycastle.asn1.x500.X500Name( "CN=Me" );
org.bouncycastle.asn1.x500.X500Name issuer = subject; // self-signed
BigInteger serial = BigInteger.ONE; // serial number for self-signed does not matter a lot
Date notBefore = new Date();
Date notAfter = new Date( notBefore.getTime() + TimeUnit.DAYS.toMillis( 365 ) );
org.bouncycastle.cert.X509v3CertificateBuilder certificateBuilder = new org.bouncycastle.cert.jcajce.JcaX509v3CertificateBuilder(
issuer, serial,
notBefore, notAfter,
subject, keyPair.getPublic()
);
org.bouncycastle.cert.X509CertificateHolder certificateHolder = certificateBuilder.build(
new org.bouncycastle.operator.jcajce.JcaContentSignerBuilder( "GOST3411withECGOST3410" )
.build( keyPair.getPrivate() )
);
org.bouncycastle.cert.jcajce.JcaX509CertificateConverter certificateConverter = new org.bouncycastle.cert.jcajce.JcaX509CertificateConverter();
X509Certificate certificate = certificateConverter.getCertificate( certificateHolder );
KeyStore keyStore = KeyStore.getInstance( "JKS" );
keyStore.load( null, null ); // initialize new keystore
keyStore.setEntry(
"alias",
new KeyStore.PrivateKeyEntry(
keyPair.getPrivate(),
new Certificate[] { certificate }
),
new KeyStore.PasswordProtection( "entryPassword".toCharArray() )
);
keyStore.store( new FileOutputStream( "test.jks" ), "keystorePassword".toCharArray()
В принципе, это не особо нужно, потому что у нас уже есть простой и удобный способ выдавать JKS, а JKS для Java это самое что ни на есть родное решение. Но для полноты картины, пусть будет.
openssl req -newkey gost2001 -pkeyopt paramset:A -passout pass:aofvlgzm -subj "/C=RU/ST=Moscow/L=Moscow/O=foo_bar/OU=foo_bar/CN=developer/emailAddress=olegchiruhin@gmail.com" -keyout private.key.pem -out csr.csr
openssl x509 -req -days 365 -in csr.csr -signkey private.key.pem -out crt.crt
openssl x509 -inform pem -in crt.crt -pubkey -noout > public.key.pem
openssl.exe dgst -hex -sign private.key.pem message.xml
openssl smime -sign -inkey private.key.pem -signer crt.crt -in message.xml
openssl pkcs12 -export -out private.key.pkcs12 -in private.key.pem -name "alias"
В результате всех вышеописанных действий мы получили относительно легий способ избавиться от тяжкой ноши Крипто Про.
В дальнейшем хотелось бы продолжить борьбу за выпил до финальной победы: оформить все утилиты, генераторы ключей, самописные смэв-клиенты итп в виде одного репозитория на Гитхабе. Еще, очень хотелось бы получить права на модификацию и распространение под пермиссивной лицензией официального клиента СМЭВ. Тогда половина этой статьи была бы просто не нужна, и проблема решалась бы скачиванием нужного кода с Гитхаба.
Автор: olegchir
Источник [8]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/java/118853
Ссылки в тексте:
[1] http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411: http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411
[2] https://wiki.openssl.org/index.php/Binaries: https://wiki.openssl.org/index.php/Binaries
[3] https://slproweb.com/products/Win32OpenSSL.html: https://slproweb.com/products/Win32OpenSSL.html
[4] https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=2425: https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=2425
[5] http://gigamir.net/techno/pub903517: http://gigamir.net/techno/pub903517
[6] http://www.cryptopro.ru/certsrv/: http://www.cryptopro.ru/certsrv/
[7] http://stackoverflow.com/questions/14580340/generate-gost-34-10-2001-keypair-and-save-it-to-some-keystore: http://stackoverflow.com/questions/14580340/generate-gost-34-10-2001-keypair-and-save-it-to-some-keystore
[8] Источник: https://habrahabr.ru/post/282225/
Нажмите здесь для печати.