Меню Рубрики

Установка cryptopro на виртуальный сервер

Возможно ли пробросить в терминальную сессию

Повторю еще раз, у контура новая система генерации ключей. Если ты все это хранишь в реестре то внешний носитель будет нужен лишь для копии (и то копию всегда можно получить с сайта контура).

>На практике обновлять ключи приходится каждые 2-3 месяца.
Трудно раз в месяц флешку в порт воткнуть?

Ты про Рутокен говоришь? Это далеко не флешка.

>Есть некая программа (Крипто Про, если имеет значение)
Задача какая? Поди в терминалке использовать крипто-про?

Нет, мне надо ключи в сервер подсунуть > Это далеко не флешка.

Они на простой флешке, как файлы, без заморочек.

> >Есть некая программа (Крипто Про, если имеет значение)
> Задача какая? Поди в терминалке использовать крипто-про?

Угу. Контур, если точнее. Он без крипто про не работает.
В первом приближении все поставилось, теперь ищу способ как закачать туда ключи.

Цепляешь локально и делаешь копию в регистр.

>теперь ищу способ как закачать туда ключи.
Ну вообще-то новые ключи вообще делаются сразу онлайн, только в качестве хранилища выбирай регистр.

Ну а те что уже есть — цеплять носитель локально и копировать туда-же.

RDP? «Локальные устройства» все подключены? которые по кнопке «подробнее»
насколько я помню крипто-про там надо в панели управления (на сервере) подключать хранилище и настраивать расположение контейнеров. После этого они видятся.
А вообще можно им в поддержку позвонить — раньше вполне толково помогали все делать.

Ну и есть универсальный способ — USB over IP

Да, все > которые по кнопке «подробнее»
> насколько я помню крипто-про там надо в панели управления (на сервере) подключать хранилище и настраивать расположение контейнеров. После этого они видятся.

Ну вот пока что ничего кроме съемных дисков он воспринимать не хочет.

> Ну и есть универсальный способ — USB over IP

Это уж на крайний случай, если ничего иное не поможет. Проблема-то дурацкая, криптопро от флешки ничего кроме файловой структуры не надо совершенно.

как сказали выше, создать новый ключ, но в качестве хранилища выбрать реестр
это был бы лучший вариант

если это накладно (рабочий сертификат уже выдали, а новый стоит денег и времени), то можно просто скопировать контейнер, если контейнер позволяет себя копировать (есть у него такой параметр)
делается это стандартными методами через панель управления Крипто-ПРО (надо учесть, что сертификат может быть как в контейнере ключа, так и нет, поэтому тут возможна и последующая установка сертификата)

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

вообще, КриптоПРО такая штука — все действия лучше заранее оттренировать на тестовых ключах, чтобы потом не натыкаться на проблемы

источник

Как установить сертификат в реестр через КриптоПРО

Как установить сертификат в реестр через КриптоПРО

Добрый день! Уважаемые читатели и гости крупного IT блога рунета pyatilistnik.org. Продолжаем нашу с вами тему с сертификатами и работе с ними. В прошлый раз я вам подробно рассказал, как получить тестовый сертификат криптопро, посмотрите очень интересная заметка. Согласитесь, что для тестирования вам может потребоваться не один сертификат, а гораздо больше, и очень удобно иметь возможность работать с ними, без привязки к физическим токенам, например, на виртуальных машинах Vmware. Для таких задач, есть возможность поместить сертификаты КриптоПРО в реестр Windows, чем мы с вами и займемся.

Когда нужно копировать сертификаты КриптоПРО в реестр

Существует ряд задач, когда удобно иметь вашу ЭЦП подпись в реестре Windows:

1. При тестировании настроенного окружения для торговых площадок, для входа на которые используется ЭЦП подпись.
2. Когда у вас виртуальная инфраструктура и нет возможности, произвести проброс USB устройств по локальной сети
3. Ситуации, когда КриптоПРО не видит USB токена
4. Ситуации, когда USB ключей очень много и нужно работать одновременно с 5-ю и более ключами, примером может служить программа по сдачи отчетности СБИС

Как скопировать сертификат в реестр КриптоПРО

CryptoPRo позволяет производить установку с копирование закрытого ключа (сертификата) в реестр Windows.

И так, у меня есть USB токен SafeNet, на который я выпустил тестовую ЭЦП, ее я буду переносить вместе с закрытым ключом в реестр Windows. Открываем утилиту CryptoPRO с правами администратора.

Переходите на вкладку «Сервис» и нажимаете «скопировать»

У вас откроется окно «Контейнер закрытого ключа», тут вам нужно нажать кнопку «Обзор», что бы выбрать ваш сертификат, который вы хотите скопировать в реестр.

В итоге у вас в поле «Имя ключевого контейнера» отобразиться абракадабровое имя.

У вас появится окно с вводом пин-кода от вашего USB токена.

Теперь вам необходимо задать имя для копируемого сертификата в реестр Windows, КриптоПРО благо, это позволяет. Я назвал его «Копия сертификата в реестре (Семин Иван)»

Теперь вам необходимо положить сертификаты КриптоПРО в реестр, для этого выбираем соответствующий пункт и нажимаем «Ок».

На следующем шаге вам предложат установить новый пароль на ваш контейнер с закрытым ключом, советую установить его и желательно посложнее.

Установка закрытого ключа в реестр

Теперь когда ваш закрытый ключ находится в реестре, давайте установим личный сертификат. Для этого откройте на вкладке «Сервис» кнопку «Посмотреть сертификат в контейнере»

Далее в окне «онтейнер закрытого ключа» нажмите кнопку «Обзор».

И выберите сертификат из реестра, он будет с тем именем, что вы ему задавали.

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

Видим, что сертификат был установлен в хранилище «Личные» текущего пользователя.Как видите, было очень просто скопировать закрытый ключ в реестр операционной системы.

Где хранится закрытый ключ в реестре Windows

После процедуры добавления сертификата в реестр КриптоПРО, я бы хотел показать, где вы все это дело можете посмотреть. Ранее я вам рассказывал, о том как добавить оснастку сертификаты. Нас будет интересовать раздел «Сертификаты пользователя — Личное».

Либо вы можете зайти в свойства Internet Explorer на вкладку «Содержание’. Потом перейти в пункт «Сертификаты», где у вас будут отображаться все ваши SSL сертификаты, и те, что КриптоПРО скопировал в реестр операционной системы.

Если нужно найти ветку реестра с закрытым ключом, то я вам приводил уже пример в статье, когда я переносил ЭЦП с компьютера на компьютер.

Про копирование ЭЦП с закрытыми ключами мы разобрали, теперь ситуация обратная.

Как скопировать эцп из реестра на флешку

Предположим, что у вас стоит задача скопировать контейнер из реестра, так как он уже там, то он экспортируемый, для этого открываем криптопро, «Сервис-Скопировать»

Выбираете «Обзор» и ваш сертификат из реестра.

Задаете ему новое имя, удобное для себя.

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

Обязательно задайте новый пароль.

Ну и собственно теперь открывайте вашу флешку и лицезрейте перенесенный на него контейнер, он будет состоять из файликов с форматом key.

Как видите КриптоПРО, это конвейер, который позволяет легко скопировать сертификат из реестра на флешку или даже дискету, если они еще используются.

источник

Побег из Крипто Про. Режиссерская версия, СМЭВ-edition

Эта статья посвящена тому, как перестать использовать Крипто Про и перейти на Bouncy Castle в девелоперском/тестовом окружении.
В начале статьи будет больше про СМЭВ и его клиент, в конце — больше про конвертирование ключей с готовой копипастой, чтобы можно было начать прямо сейчас.

Картинка для привлечения внимания:

Disclamer

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

Недавно мне нужно было разобраться, как написать сервис, работающий с Системой Межведомственного Электронного Взаимодействия.
Все написанное представляет собой просто результат небольшого исследования, максимально абстрагированный от выполненной работы. И даже приблизительно угадать что-то о реально принятых решениях невозможно, я проверял.

Обоснование нужности готового клиента

На технологическом портале СМЭВ3 лежат исходники клиента, но вот незадача — они гвоздями прибиты к КриптоПро. Вордовский файл с инструкцией, приложенный к исходникам, утверждает это самым прямым образом. Да и все равно, исходные ключи у нас тоже в формате КриптоПро. Исходя из production это нормально, а вот для тестового окружения жутко неудобно. Хотелось бы от этого избавиться.

Читайте также:  Установка водяных счетчиков с полипропиленом

На сайте есть две версии — «актуальная» и «рекомендуемая». Почему они так, и почему актуальная версия не рекомендуется, а рекомендуемая не актуальна — какая-то дилемма копирайтера 🙂 Дальше речь о том клиенте который «актуальный».

Строго говоря, использовать его нельзя, потому что в архиве исходников нету текста лицензии, и поэтому непонятно, под какой лицензией должна распространяться производная работа. Я позвонил по телефону поддержки, написанному на портале, написал на почту, пару недель наблюдал как моя заявка летает между уровнями техподдержки и исполняющими организациями, и в результате воз и ныне там:

Задача не выполнена, но выполнена и закрыта, изумительно. Ладно, черт с ними.

Несмотря на невозможность использовать его у себя непосредственно в коде, это отличный тестовый пример. Дело в том, что в методических рекомендациях СМЭВа без поллитры не разобраться, и готовый живой код дает отличный буст к пониманию.

Основная претензия к документации — это канцеляризмы и скудное описание в интернете.
Помните мем про копирайтера, который из абзаца сделал одно предложение в несколько слов? Для документации СМЭВа это имеет место быть, например вот цепочка рефакторинов для одной произовльно взятой фразы:

«2. ИС потребителя направляет в СМЭВ межведомственный запрос;»
«2. ИС потребителя направляет в СМЭВ запрос;»
«2. ИС потребителя направляет запрос;»
«2. потребитель направляет запрос;»
«2. запрос потребителя;»

Короче, наличие готовой реализации — это добро.

Почему Крипто Про JCP добро

Почему Крипто Про JCP зло

В качестве альтернативы в тестовом окружении я предалагю использовать 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-подписи в Santuario

Ах да, тут есть один интересный момент. В сети множество советов, касающихся СМЭВа, заключающихся в ручном парсинге кусков 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» (или что там у вас). Это ключевая магия. Совершенно ничего умного этот класс делать не должен.

Инициализация раз за всю жизнь приложения (н-р в синглтон-бине спринга):

2) Загрузить провайдер, чтобы не патчить JDK:

3) Впердолить в рантайм только что написанный класс:

4) Достучаться до маппингов алгоритмов JCE:

5) Замапить метод на алгоритм:

6) PROFIT!
После этого XMLSignature резко начинает понимать этот метод, и начнет делать xmlSignature.sign.

Подготовка OpenSSL для работы с ГОСТ

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

  • Так как у нас Крипто Про, и на Маке оно не взлетает, нам понадобится виртуальная машина с Windows (можно даже Windows XP), и установленной Криптой
  • Установить как можно более актуальную версию OpenSSL (так, чтобы в ней уже была поддержка ГОСТ):
    https://wiki.openssl.org/index.php/Binaries
    https://slproweb.com/products/Win32OpenSSL.html
  • Проверить, что в установленной версии есть файл gost.dll
  • В установленном OpenSSL найти файл openssl.cfg
  • В самое начало файла добавить строчку:

В самый конец файла добавить строчки:

Как мы можем попросить Крипто Про отдать ключи (на самом деле, нет)

Если у нас уже есть настоящие (не самоподписанные) ключи, то совершенно некисло было бы проверить их в действии. Да, мы говорим о тестовых целях, но таки доверяй — но проверяй!

Если поставить винду в виртуальную машину, накатить туда Крипто Про, установить ключи и попробовать их экспортировать, то обнаруживаем удивительную вещь: в экспортере не работает экспорт в PKCS12, а все остальные направления в экспортере заблокированы (англ. «grayed out»).

«От Алексея Писинина был получен ответ:
Добрый день. PKCS12 не соответствует требованиям безопасности ФСБ в части хранения закрытых ключей. В теории, закрытые ключи должны храниться на так называемых «съемных» носителях. Собственно, по этой причине и не работает экспорт.»

Я правильно это читаю как, что у них гуй для экспорта есть, но бизнес-логики к нему нету?!
Ппоэтому каких галочек ни нащелкай — всегда будет выпадать ошибка на последнем шаге гуевого мастера?!

Dear God,
Please kill them all.
Love, Greg.

Как мы можем грубо заставить Крипто Про отдать ключи

Можно очень долго мучиться, пытаясь засучив C++ вычитать ключ из контейнера с помощью OpenSSL и такой-то матери. Я честно пытался, и разбился об задачу как корабль об скалы (по крайней мере, это задачка больше чем на 1 день для человека, который давно таким не занимался). На просторе интернетов мы не единственные, кто разбился об те же скалы: http://gigamir.net/techno/pub903517

Вот тут наступает момент «это радость со слезами на глазах». Некая контора под названием Лисси Софт, всего за 2 тыщи рублей отдает нам гениальную утилиту P12FromGostCSP. Ее создатели таки победили ту проблему, которую не осилило сообщество, и она выдирает ключи в PFX. Радость — потому что она работает.

Со слезами — потому что это проприетарщина, и она фиг знает как работает.
На картинке Ричард Столлман как бы удивляется и спрашивает: «неужели вы боретесь с проприетарщиной с помощью другой проприетарщины?»

Так что целиком инструкция по перегону ключей выглядит как-то так:

  • Все действия производить на Windows (подойдет виртуальная машина) с установленным Крипто Про CSP;
  • Подготовить OpenSSL с ГОСТом по инструкции (есть в этой статье).
  • Купить P12FromGostCSP. Поплакать.
  • Установить исходный ключ в КриптоПро (это заслуживает отдельной инструкции, но она гуглится).
  • Запустить P12FromGostCSP (перед этим спрятать икону Ричарда Столлмана под стол, чтобы он не проклял тебя за запуск проприетарщины)
  • Выбрать установленный сертификат, указать пароль сертификата КриптоПро
  • Указать произвольный новый пароль (парольную фразу) для ключевой пары PFX
  • Указать местоположение для сохранения файла. Файл лучше именовать в формате p12.pfx (это название по-умолчанию, лучше не трогать — говорят, есть баги, если переименовать)
  • Получить pem файл:
  • (-name «alias» — эта опция поменяет имя ключа внутри контейнера. Это нужно потому, что P12FromGostCSP именует ключи как попало (на самом деле, по порядку, цифрами), без сохранения исходного алиаса.
  • Получить pkcs12 файл:
  • Готово

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

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

Как выдать ключи в формате Крипто Про, я особо не заморачивался, потому что это просто не нужно в рамках текущей задачи. Но на всякий случай, существует сервис выдачи таких ключей: http://www.cryptopro.ru/certsrv/

  • Все действия производить на Windows (подойдет виртуальная машина) с установленным Крипто Про CSP;
  • Открыть сайт и перейти к выдаче ключа;
  • Нужно выбрать пункт «Сформировать ключи и отправить запрос на сертификат» и нажать кнопку «Дальше»;
  • Щелкнуть по ссылке «Создать и выдать запрос к этому ЦС»;
  • Заполнить необходимые поля;
  • Нажат кнопку «Выдать»;
  • Установить сертификат.

Выдача контейнера JKS

Идея в том, что раз уж мы все равно используем Bouncy Castle, то им же можем и сгенерить ключ.
Этот код не самый идеальный, но дает реально работающую реализацию (на практике у меня в результате получилось несколько объемных классов, чтобы сделать удобный интерфейс)

Выдача контейнера PKCS12

В принципе, это не особо нужно, потому что у нас уже есть простой и удобный способ выдавать JKS, а JKS для Java это самое что ни на есть родное решение. Но для полноты картины, пусть будет.

  • Подготовить OpenSSL с ГОСТом по инструкции (есть в этой статье).
  • Сделать Cerificate Signing Request + приватный ключ (вписать нужные данные о ключе!):
  • Подписать приватным ключом (на Windows эту операцию нужно делать с правами Administrator, иначе свалится с ошибкой «unable to write ‘random state'»):
  • Получить публичный ключ:
  • GOST2001-md_gost94 hex (если надо):
  • MIME application/x-pkcs7-signature (если надо):
  • Превратить pem в pkcs12:

Резюме

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

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

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

Сравнительный анализ некоторых Java-декомпиляторов

Вопросы к собеседованию Java-backend, Java core (60 вопросов)

Побег из Крипто Про. ГОСТ 34.10-2012 edition

Вакансии

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Комментарии 52

Тем не менее, закрытый ключ не экспортируется сейчас, в 2016 году. Это факт.

Импорта не проверял — цель ведь сбежать с крипты, а не прибежать в неё.

Ну то есть иногда экспортируется, иногда — нет. Какой-то баг, наверное. Как всегда 🙂

Если уж на то пошло, то на Linux через админку КриптоПро JCP нету вообще никаких опций экспорта кроме одной — «Экспорт» без описания. Оно экспортит в неназванный формат без расширения имени файла, который содержит в себе только открытый ключ. А на OSX даже эта админка либо не запускается, либо сыпет багами. А если захочешь установить ключи, устанавливать их надо копированием в магическую директорию, путь который ищется на форуме, и из интефрейса админки JCP это не делается. Думаю, если тут «кто-то делает не так», искать надо начинать не с меня, а например, с самой Крипты.

Как мы можем грубо заставить Крипто Про отдать ключи

Требовать, чтобы ключи по-честному генерировались на токенах PKCS#11 с ГОСТ-ами, а не использовали токен как флешкуЙ. Тогда не будет проблем ни с чем. А уж OpenSSL умеет работать с токенами PKCS#11.

Не все так просто. jailbreak 4.0/3.5 не экспортируют неэкспортируемый ГОСТ Р 34.11/34.10-2001-ГОСТ Р 34.11-94 ключ, ни через jbcert

mimikatz 2.1.1-20170409 же не может экспортировать ключ, так как crypto::capi и crypto::cng не поддерживают нужные криптопровайдеры.
Обе программы сертификат видят.

Тем не менее, если ключ хранится в реестре, то он может быть извлечен из веток HKLM\SOFTWARE\CryptoPro\Settings\Users\\Keys\ или HKLM\SOFTWARE\Wow6432Node\CryptoPro\Settings\Users\\Keys\ , а затем, например, сконвертирован утилитой privkey для использования в OpenSSL (прежде нужно удалить пароль с криптоконтейнера через CSP > Сервис > Изменить пароль. > Выбрать контейнер > Не вводить пароль ).

Избавиться от Крипто-Про в тестовых целях конечно можно, но на проде у вас могут следующие грабли:
1. Поддержка ключевых носителей eToken, Соболь, и т.д.
2. Поддержка параметров алгоритмов.
3. Работа с аппаратными генераторами случайных чисел.
4. Экзотические грабли, но тем не менее — переход на новые шифры «Кузнечик», «Стрибог» и т.д. не факт что в Bounty Castle оперативна появится их поддержка.

Хотя если делать замену КП на BC как черного ящика, то есть нечто что шифрует, то такой способ имеет место быть.

Не в качестве рекламы, а в качестве учебника по работе с надфилем XML-Security Java and MS CryptoIAPI for CXF WS-Security signature. Меня умиляют эти слова о Apache Santuario и код работы с DOM деревом. Apache Santuario — это для XML SAX разбора. Для DOM дерева используется JSR105.
Да, проект опубликован давно, но отнюдь не означает, что он не работает. Там идут JUnit тесты и работаю. Заметьте, работают под Linux и под Windows.

Зачем сражаться с контейнерами закрытых ключей? Покупка КриптоПро CSP по цене соизмерима со стоимостью некой утилиты. И не факт, что она сможет извлечь ключи с аналогов eToken.
Посмотрите на недавно сертифицированную CSP 4.0. Там есть куча компонентов с полюбившимся OpenSSL.

Я предлагаю всё же разобраться в том, что написано другим человеком.

На самом деле, я хочу вам показать пример реализации с Apache CXF. Здесь нет надобности вообще каким-то образом обрабатывать XML документ. JAXB и JaxWS делают много вещей для вас. Вы используете обычные классы. Далее, поднимаем SOAP клиента на основе WSDL и вкладываем в качестве параметра нужный Java класс.
Вся работа с криптографией, прописывание подписей в XML, извлечение и проверка подписей, это удел Apache CXF. Ваш код должен быть «мягким и пушистым», а не вызывать сложные рефлексы.

Самое основное понимание XML подписи — не надо стремится сохранить текстовое представление документа. В подписи указывается алгоритм нормализации. Он убирает все отступы и упорядочивает названия атрибутов в тегах. Полученная каша, в кодировке UTF-8 поступает в хеш функцию. Значение функции находится в разделе digest. Подпись собирает все эти дайджесты вместе и уже подписывает.

Я извиняюсь, если не совсем доходчиво объясняю.

Покупка КриптоПро CSP по цене соизмерима со стоимостью

«Лицензия на право использования СКЗИ „
КриптоПро JCP“ версии 2.0 на одном
сервере с одним ядром процессора (или с 2 ядрами с отключенным Hyper
Threading)»

То есть, если я, в тестовых целях, энсиблом пачкой зафигачу свою софтину в сотню-другую докеров, на покупку лицензий мне придется продать на черном рынке машину, кваритру, собаку, жену, и все свои внутренние органы?

> соизмерима со стоимостью некой утилиты

если когда-нибудь у меня случится отпуск, таки напишу эту утилиту прямо на гитхаб, и это будет стоить вообще ничего никому

Вы считаете, что ваше ПО выступает в качестве автономных сервисов. Поймите, что слово сервис — это клиент шины. Сервер — это средство хранения и обмена в вашей шине. По аналогии, это SMTP/POP сервера электронной почты. У вас всего лишь почтовый клиент.
То же самое в MQ или JMS. Есть один или несколько серверов, на которые поступают сообщения и они передают их клиентам. Клиент может публиковать сообщения, может забирать корреспонденцию. Но при этом, он остается для шины клиентом.
С точки зрения, вы делаете клиента. Сервер у вас пассивный.

В рамках Java программ, мы создаем сокеты. Для понимания, о чем я говорю, можно посмотреть статью Создаем клиент-сервер на сокетах.
Если вы создаете ServerSocket, это сервер. Если создаете Socket, это клиент.

Теперь представим такую ситуацию. У нас есть SOAP сообщение от клиента. Он подписывает сообщение и отправляет на сервер. Сервер отправляет ответ. Если ответ сервера должен быть подписан, ему нужна серверная лицензия.

Еще раз повторю, что сервис в шине — это клиент.
Он спрашивает у сервера наличие сообщений и получает сообщения в ответ. То что ваш сервис, это клиент, понятно?
После получения ответа, ваше ПО отключается от сервера и может не спеша подготовить ответ на полученное сообщение. После этого, ваш сервис подключается к серверу обмена и передает туда свое сообщение для отправителя исходного сообщения. Получает ответ от сервера, что он получил сообщение. То что ваш сервис — это клиент, понятно?
В чем же главное отличие сервера от клиента? Сервер не может самостоятельно установить соединение с клиентом. А вот, клиент может установить соединение с сервером.

Вам хватит клиентской лицензии на средства криптографии.

>> Некая контора под названием Лисси Софт
>> Со слезами — потому что это проприетарщина, и она фиг знает как работает.

Эти «Лисси» умудрились даже исходники Firefox и Thunderbird спиратить. Оправдываются тем, что «У микрософта исходники тоже закрыты».

И после этого еще кто-то смеет жаловаться на проблемы безопасности! Да если для того, чтобы вся эта криптография хоть как-то заработала, нужно гуглить днями и вставлять спагетти непонятно как и почему работающего кода — неудивительно, что статьи об уязвимостях просто прут пачками.

Асимметричная криптография в основе своей проста, как два пальца, почему же ее использование сопряжено с такими трудностями? Где внятные мануалы? Примеры кода? Вот, например, у меня как раз стоит задача прочитать приходящий PKCS#7 сертификат (в виде массива байт) и проверить подписи в нем, так даже для такой элементарной задачи (если не пользоваться классом PCKS7 из пакета sun.* ) нужно наворотить такую кучу кода, что волосы дыбом встают. Причем у всех кода разный и у меня впечатление, что никто не знает, как же это делать правильно. Во всяком случае, понимания того, что происходит, я ни в одном из ответов на stackoverflow не вижу. О генерации ответа в таком же формате (отдать свой подписанный публичный ключ) я пока даже боюсь думать, настолько все запутанно и неочевидно.

PKCS#7 — это контейнер, используемый в криптографии. Сертификат, обычно, передается в контейнере PKCS#7, вместе с подписью.
В контейнер можно положить несколько сертификатов. И будет у нас хранилище сертификатов.
Можно положить CRL файлы. Можно положить подписываемое сообщение. Можно положить зашифрованное сообщение.
Отсюда и идут все сложности в понимании.

Да, в самом сертификате есть подпись издателя и сведения о сертификате издателя. Но сам сертификат не является контейнером формата PKCS#7.

Для чтения и записи сертификата и контейнера используется стандарт ASN1.
Отсюда и все сложности на этапе освоения всего этого нагромождения.

PKCS#7 это не контейнер для сертификата. Это запрос на сертификат, содержащий subject, публичный ключ и, возможно, дополнительные поля. Все это подписано приватным ключем, который никуда не передается.
СА получает запрос, извлекает публичный ключ и используя его проверяет подпись всего запроса. Если да — добавить поля Issuer, поменять/заменить/добавить дополнительный полей и подписать все это своим приватным ключом CA. Так получается сертификат.
Далее его можно отдать как есть (bin или base64), можно спрятать в контейнер PKCS#12 под пароль и отдать в нем.

О криках про шифрование и ключи. Основная задача криптографии не в алгоритмах. Основные трудности (основной упор всех разработок) — создание ключей (надежный непредсказуемый ДСЧ, от чего и появляются аппаратные прибамбасы) и надежный/стойкий метод хранения ключей (приватных в том числе).

О какой надежности системы можно говорить, если ПРИВАТНЫЕ ключи «ходят по рукам», перекладываются и «светятся» чуть ли не в открытом виде? Алгоритмы описаны на каждом втором вебсайте — приватность именно в хранении ключей. Любой СКЗИ работает по принципу «мы вам сделаем внутри ключ, вы можете использовать его для шифрования/подписи, но сам ключ (его содержимое) будет тайной за семью печатями и для вас тоже».

Посмотрите как устроены токены? Посмотрите как сделана ваша СИМ-карта в телефоне наконец — она свой ключ Ki не светит нигде и никогда.
Но использует вовсю.

Вы бы заглянули на сайт wiki статью PKCS. Запрос на сертификат — это PKCS#10. Разные устройства, типа eToken, это стандарт PKCS#11.

Что смотреть в этой карточке или USB token? Микроконтроллер. Разве, что, на специальном оборудовании снимать с него стружку. Эти устройства хороши, но очень медленные. Вот, вы, пишите ответ в данной статье. Обмен с сервером идет в зашифрованном протоколе TLS. Теперь, ваш поток мыслей должен пройти через эту карточку / USBToken. После этого, данные уйдут на сервер. Данных не много. А теперь представьте, что этот сервер так же, весь трафик, все HTML статьи, будет гонять через USB Token. Данная технология имеет право на жизнь в некоторых областях применения.

ОК, я был не совсем прав. Да, запрос это PKCS#10.
Проблема в том, что PKCS#7 && PKCS#12 не могут выступать в роли хранилищ сертификатов и ключей. Эти протоколы разрабатывались только как транспортные.
Для хранения — токены (и связанный с ними протокол обмена (!!) PKCS#11), или новый PKCS#15

Основной вопрос был в попытке оправдать идеологию СКЗИ хранить свою приватную информацию в закрытом ото всех виде. В том числе и от владельца ключа. Обращаться к СКЗИ для использования этого ключа можно, экспортировать и унести ключ — должно быть запрещено.

Токены я упомянул (равно как и SIM) — пример того, что ключ создан, но пользователь его не видит и не может получить. Он скрыт внутри микросхемы контроллера. Вы можете его использовать, выдавая запросы на операции с этим ключом, микроконтроллер будет отвечать.

И… давайте не будем меряться скоростями? Есть много решений, почему вы думаете что все токены работают на USB? Но я вовсе не склоняю всех использовать токены как СКЗИ, это скорее пример реализации закрытых ключей. Закрытых «совсем».

Спасибо за статью, в своё весёлое прошлое нырнул на ночь глядя. В 2014-м году использовал разные криптовайдеры. И сравнивал скорость работы КриптоПро 3.6 и Bouncy Castle .NET. КриптоПро 3.6 работал существенно быстрее. Задача — формирование отсоединённой подписи для файла в нагрузочных тестах. Другая задача — формирование ключевой пары и сертификата, для тестовых пользователей формировал 10 000 ключевых пар и сертификатов (или около того).

В результате поступил так. Ключевую пару формировал в КриптоПро, а вот сертификат со всеми нужными атрибутами и свойствами мастерил в Bouncy Castle, там полная свобода. И с помощью Bouncy Castle сделал малый УЦ — выпуск сертификатов, CRL-ответчик, OCSP-ответчик. При подписании документов, получается, снова работал КриптоПро, так как закрытый ключ в нём хранился, а Bouncy Castle трудился только чтобы CRL и OCSP отдавать для формирования усовершенствованной подписи. Никакой из действующих УЦ мне бы никогда не выдал 10 000 ключей бесплатно, и не стал бы мне OCSP-ответы с дикой скоростью отдавать. OCSP-ответчики действующих УЦ умирали от нагрузки реальных клиентов. Тут Bouncy Castle помог.

Была задумка сделать масштабное сравнение скорости работы. Так как в .NET очень удобный CryptoAPI, который для простых задач, таких как формирование и проверка подписи скрывает детали взаимодействия с криптопровайдером до 0-ля. Нужно немного смекалки и умения обходить баги, чтобы водрузить на одну машину несколько криптопровайдеров сразу, а потом можно их тестировать одним и тем же кодом, лишь используя сертификаты, ключи к которым хранятся в разных криптопровайдерах. При условии, что на ключах нет пароля и есть лишь одно хранилище, всё проходит быстро и просто, без лишних диалогов от КриптоПро или VipNet.

Скоро ожидаю, что на работе будет проект с криптографией, тогда осуществлю задуманное. Сравню, VipNet, Lissy CSP, Crypto Pro, BounsyCastle. Их можно параллельно использовать. А вот, например, белорусский ГОСТ-криптопровайдер Avest CSP использовать вместе с КриптоПро было нельзя в 2014-м году. Предполагаю, они используют один и тот же идентификатор криптопровайдера или алгоритмов, и тот что установился последним, считался криптовайдером, реализующим ГОСТ-алгоритмы первого — это частично недостаток CryptoAPI для .NET, где нельзя тонко настроить этот момент, CryptoAPI считывает из реестра кто и что реализует, и в случае, если два провайдера реализуют одно и то же, сам принимает решение, какой из них использовать.

Примечание по скорости тестовых CRL и OCSP. Ответчики, сделанные на базе Bouncy Castle, работали быстро под натиском нагрузочных тестов, во многом, потому, что всегда отвечали, что с тестовыми сертификатами всё хорошо — были заглушками. CRL генерировался нечасто и грамотно кешировался, но тут реализовал всё полностью, можно было сделать сертификат отозванным. А OCSP-ответ всегда был положительным для любых сертификатов — заглушка. Вот всё и летало, как пуля.

источник

Добавить комментарий

Adblock
detector