Крипто-Про JCP — купить лицензию Крипто-Про JCP по выгодной цене в Ростове-на-Дону на официальном сайте

Содержание

Что нужно допилить в готовом клиенте, чтобы сбежать с крипто про
Почему крипто про jcp зло
Обоснование нужности готового клиента
Disclamer
Выдача контейнера pkcs12
Инициализация xml-подписи в santuario
Как мы можем попросить крипто про отдать ключи (на самом деле, нет)
Крипто-про дистрибутив скзи криптопро jcp, версии 2.0 на cd. формуляр — купить лицензию крипто-про jcp, цена в ростове-на-дону на официальном сайте
Купить лицензию криптопро jcp 2.0 онлайн по выгодной цене
Подготовка 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»).

Крипто-про дистрибутив скзи криптопро jcp, версии 2.0 на cd. формуляр — купить лицензию крипто-про jcp, цена в ростове-на-дону на официальном сайте

КриптоПро JCP – средство криптографической защиты информации, разработанное в соответствии со спецификацией JCA (Java Cryptography Architecture) и реализующее российские криптографические стандарты

Интеграция КриптоПро JCP с архитектурой Java позволяет использовать стандартные процедуры, такие как создание и проверка ЭЦП (в том числе XMLdsig, CAdES, XAdE), шифрование, генерацию ключей, вычисление кодов аутентификации в JavaTM Cryptography Extension в соответствии со спецификациями Java Cryptography Extension (JCE) на различных операционных системах и аппаратных платформах

Лицензии поставляются только в бумажном виде! Установочный комплект включает диск и бумажный формуляр.

✅ Купите Крипто-Про Дистрибутив СКЗИ КриптоПро JCP, версии 2.0 на CD. Формуляр на официальном сайте

✅ Лицензия Крипто-Про Дистрибутив СКЗИ КриптоПро JCP, версии 2.0 на CD. Формуляр по выгодной цене

✅ Крипто-Про Дистрибутив СКЗИ КриптоПро JCP, версии 2.0 на CD. Формуляр, лицензионное программное обеспечение купите в Ростове-на-Дону и других городах России

Предлагаем также:

Купить лицензию криптопро jcp 2.0 онлайн по выгодной цене

Описание товара

Основные характеристики

КриптоПро JCP / JCP 2.0

КриптоПро JCP — средство криптографической защиты информации, реализующее российские криптографические стандарты, разработанное в соответствии со спецификацией JCA (Java Cryptography Architecture).

Интеграция КриптоПро JCP с архитектурой Java позволяет использовать стандартные процедуры, такие как создание и проверка ЭЦП (в том числе XMLdsig, CAdES, XAdES) , шифрование, генерацию ключей, вычисление кодов аутентификации (Message Authentication Code — MAC) в JavaTM Cryptography Extension (JCE) в соответствии со спецификациями Java^TM Cryptography Extension (JCE) на различных операционных системах и аппаратных платформах.

Реализация КриптоПро JCP совместима с КриптоПро CSP.

Средство криптографической защиты КриптоПро JCP распространяется в двух комплектациях:

генерация ключей, формирование и проверка ЭЦП, хэширование данных;
генерация ключей, формирование и проверка ЭЦП, хэширование данных, шифрование.

Назначение:

КриптоПро JCP предназначен для:

авторизации и обеспечения юридической значимости электронных документов при обмене ими между пользователями, посредством использования процедур формирования и проверки электронной цифровой подписи (ЭЦП) в соответствии с отечественными стандартами ГОСТ Р 34.11-94/ГОСТ Р 34.11-2022 и ГОСТ Р 34.10-2001/ГОСТ Р 34.10-2022;
обеспечения конфиденциальности и контроля целостности информации посредством ее шифрования и имитозащиты, в соответствии с ГОСТ 28147-89;
обеспечение аутентичности, конфиденциальности и имитозащиты соединений TLS;
контроля целостности, системного и прикладного программного обеспечения для его защиты от несанкционированного изменения или от нарушения правильности функционирования;
управления ключевыми элементами системы в соответствии с регламентом средств защиты.

Реализуемые алгоритмы:

Алгоритм выработки значения хэш-функции реализован в соответствии с требованиями ГОСТ Р 34.11 94 «Информационная технология. Криптографическая защита информации. Функция хэширования» и ГОСТ Р 34.11 2022 «Информационная технология. Криптографическая защита информации. Функция хэширования».

Алгоритмы формирования и проверки ЭЦП реализованы в соответствии с требованиями:

ГОСТ Р 34.10-2001 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи»;
ГОСТ Р 34.10-2022 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи».

Алгоритм зашифрования/расшифрования данных и вычисление имитовставки реализованы в соответствии с требованиями ГОСТ 28147 89 «Системы обработки информации. Защита криптографическая».

При генерации закрытых и открытых ключей обеспечена возможность генерации с различными параметрами в соответствии с ГОСТ Р 34.10-2001/ГОСТ Р 34.10-2022.

При выработке значения хэш-функции и шифровании обеспечена возможность использования различных узлов замены в соответствии с ГОСТ Р 34.11-94/ГОСТ Р 34.11-2022 и ГОСТ 28147-89.

Системные требования:

КриптоПро JCP функционирует в следующем окружении:

виртуальной машина, удовлетворяющая спецификации Sun Java 2 ™ Virtual Machine;
требуется Java 2 Runtime Environment версии 1.7 и выше;

Основные характеристики:

Длина ключей электронной цифровой подписи (ГОСТ Р 34.10-2001):

закрытый ключ — 256 бит;
открытый ключ — 512 бит при использовании алгоритма ГОСТ Р 34.10-2001;

Длина ключей электронной цифровой подписи (ГОСТ Р 34.10-2022, 256 бит):

закрытый ключ — 256 бит;
открытый ключ — 512 бит при использовании алгоритма ГОСТ Р 34.10-2022, 256 бит;

Длина ключей электронной цифровой подписи (ГОСТ Р 34.10-2022, 512 бит):

закрытый ключ — 512 бит;
открытый ключ — 1024 бит при использовании алгоритма ГОСТ Р 34.10-2022, 512 бит;

Длина ключей, используемых при шифровании:

закрытый ключ — 256 бит на базе алгоритма ГОСТ Р 34.10-2001;
закрытый ключ — 256 бит на базе алгоритма ГОСТ Р 34.10-2022, 256 бит;
закрытый ключ — 512 бит на базе алгоритма ГОСТ Р 34.10-2022, 512 бит;
открытый ключ — 512 бит на базе алгоритма ГОСТ Р 34.10-2001;
открытый ключ — 512 бит на базе алгоритма ГОСТ Р 34.10-2022, 256 бит;
открытый ключ — 1024 бит на базе алгоритма ГОСТ Р 34.10-2022, 512 бит;
симметричный ключ — 256 бит;

Типы ключевых носителей:

дискеты 3,5″;
сменные носители с интерфейсом USB;
российские интеллектуальные карты (Оскар) с использованием считывателей смарт-карт, поддерживающих интерфейс OpenCard Framework (в том числе протокол PC/SC для Windows): GemPC Twin, Towitoko, Oberthur OCR126 и др.);
электронные ключи и смарт-карты eToken;
электронные ключи Rutoken;
смарт-карты ESMART;
директория жесткого диска.

Использование:

Криптографическая архитектура Java

Стандартные спецификации Java 7, предоставляют стройную систему криптографической защиты информации (ПКЗИ). Более подробно эта архитектура развёрнута по следующим ссылкам:

JDK 7.0 Security;
JavaTM Cryptography Architecture.

Как использовать

КриптоПро JCP разработан в соответствии с требованиями интерфейса JCA и позволяет создавать новые, надежно защищенные приложения с использованием богатейшего и проверенного временем инструментария Java такого, как Apache XML Security для ЭЦП XML-документов стандарта XMLdsig.

Подготовка openssl для работы с гост

Если у вас в начале статьи на стене висит OpenSSL, когда-нибудь он точно выстрелит.Так что да, это важный момент, необходимый для осуществления дальнейшего текста.

Резюме

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

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

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

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

Установка и настройка криптопровайдера

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

Первым делом создадим локального пользователя, под которым будет работать ПО, использующее подпись документов.