Как в hyper v настроить ключ криптопро

Как в hyper v настроить ключ криптопро

Сообщение cobion » 21 июн 2016 16:05

Re: USB для Крипто Про в виртуальную машину.

Сообщение cobion » 23 июн 2016 07:38

Бог с ним с «пробросом» , решается банальным присоединением физического диска в виртуалку, так как ЭЦП на обычной флэшке записано. а не на Токене. Можно просто копирнуть содержимое на диск в виртуалку и импортировать ключи.

Теперь вопрос в другом, как унифицировать импорт ЭЦП для каждого пользователя в реестр своего профиля, если ферма состоит из 4-рех серверов и каждый узел сеансов должен иметь соответствующую ЭЦП.
На данный момент есть старые терминалки, где и работают пользователи и там уже импортированы некоторые ЭЦП.
Возможно ли как то экспортировать данные сведения об ЭЦП из реестра на новые узлы сеансов, да и как в дальнейшем поступить, либо пользователю приедтся четыре раза аутентифицироваться на каждом из узлов сеансов для того что бы можно было импортировать новую ЭЦП ?
Спасибо!

Как пробросить эцп на виртуальную машину

Добрый день! Уважаемые читатели и гости блога pyatilistnik.org. Не так давно, я вам рассказывал, о том, как можно использовать usb по сети, показал это на своем примере и показал какое железо для этого подходит, советую ознакомиться. Сегодня, я бы хотел расписать все максимально подробно, о пробросе USB over IP в виртуальные машины Vmware и Hyper-V и пошаговой настройке digi anywhereusb, на стороне сервера и на стороне клиента. Думаю, эта небольшая инструкция будет очень полезна начинающим инженерам систем виртуализации.

Проблемы с пробросом USB устройств

Я думаю, сейчас уже выражением виртуальная машина, никого не удивишь, наверное подавляющее системных администраторов свои физические сервера отдали под гипервизоры Hyper-V или Vmware и это понятно, так как это более рациональная утилизация ресурсов. Все замечательно, можно создавать кластерные системы не привязанные к конкретному серверу, что дает очень хорошую отказоустойчивость, но есть небольшое но и это проблема с USB устройствами. Которые по умолчанию вы можете воткнуть, только в локальный сервер, а значит привязываете виртуальную машину, для которой необходим этот USB ключ, к данному серверу, и в случае его поломки, будет муторно перетыкать токен в другие сервера, на которых и USB портов то может и не быть.

Плюс есть проблемы, что Hyper-V и Vmware могут пробрасывать в себя не все устройства, а только поддерживаемые, которых не так уж и много, я вам показывал ситуацию, когда мне нужно было предоставить виртуальной машине USB-модем. Вот для таких ситуаций, чтобы все было надежно, и USB Токен всегда переезжал на любой хост за виртуальной машиной, была разработана технология USB over IP. По сути вы передаете ваш токен по локальной сети в вашей организации. Это очень применяется на терминальных фермах Windows Server, где очень часто установлен 1С. Подробнее о принципах работы USB over IP, читайте по ссылке слева.

Общий принцип проброса USB over IP в Vmware и Hyper-V

Вы покупаете специальное устройство, например Digi AnywhereUSB/14.

Производите его настройку, в которую входит:

После чего вы втыкаете в нее все свои токены, например, E-token или Рутокен, выглядит это вот так.

После чего осталось, только произвести манипуляции на стороне клиента.

Настройка клиента для USB over IP

Вся настройка заключается в установке специального программного обеспечения anywhereusb remote hub configuration utility. Она включает в себя драйвера и утилиту для мониторинга подключения USB Токенов.

Так как в моем примере у меня устройство AnywhereUSB-14, то драйвера я буду скачивать по данной ссылке:

Обратите внимание, что поддерживается только семейство операционных систем Windows от семерки до Windows 10 и все серверные релизы.

Я в примере выберу Windows 10 и постараюсь пробросить на нее Etoken по технологии USB over IP. Скачиваем драйвер для вашей разрядности системы. Как определить разрядность ОС Windows читайте по ссылке.

Запускаем установочный файл с драйверами. У вас появится мастер установки AnywhereUSB. На первом окне нажимаем next

Соглашаемся с лицензионным соглашением и нажимаем next

нажимаем install для установки anywhereusb remote hub configuration utility.

Оставляем галку «Lanch AnywhereUSB Configuration Utility» и нажимаем Finish. Установка драйверов для USB over IP закончена.

Настройка Anywhereusb Remote Hub Configuration Utility

В результате установки драйверов для вашего устройства USB over IP , на виртуальной машине Vmware или Hyper-V вы обнаружите две утилиты:

1. AnywhereUSB Configuration Utility — утилита управленияподключением
2. USB Device Viewer — утилита проверки подключения etoken по технологии USB over IP

Открываем AnywhereUSB Configuration Utility, чтобы обнаружить и подключить наш Etoken. Первым делом вы переходите в меню Edit-Discovery List. В поле Ip адрес указываете ip вашей железки DIGi и нажимаете кнопку Add. Теперь она будет присутствовать в списке обнаружения. Обратите внимание она сразу укажет какие группы доступны для подключения по технологии USB over IP, они будут помечены статусом Avaliable.

Далее в меню Edit-Connection list, теперь добавим тот же Ip для соединения сервера и клиента, тут же можно сразу задать группу к которой будет идти подключение (Group Number) и нажимаем Add.

Думаю вам понятна разница между Discovery List и Connection list. Первый просто показывает, что доступно на устройстве, а второй уже автоматически подключается к нему.

В результате вы увидите статус: Connection Successful to Remote Hub, а если не повезет, то Can not find Remote Hub. Если необходимо будет отключить USB Токен, то нажмите Disconnect.

Если необходимо будет переключить группу, то делается это на отключенном устройстве в Connection list, через правый клик по нему. Там будет пункт Configure. Обратите внимание, что тут есть пункты для шифрования трафика между клиентом и сервером USB over IP.

То, что у вас появился статус Connection Successful to Remote Hub, еще не говорит, что устройство работает и проброс на виртуальную машину Vmware или Hyper-V осуществлен. Чтобы удостовериться, что все хорошо, вам необходимо воспользоваться утилитой USB Device Viewer. В идеале у вас должен быть куст RealPortUSB с ip адресом вашего устройства и на порту должен отображаться ваш токен со статусом DeviceConnected. Вот теперь можно говорить, что подключение по USB over IP, работает.

Надеюсь, что вам стала более понятной технология USB over IP от Digi, будут вопросы пишите в комментариях.

Централизованный доступ к ЭЦП и прочим ключам электронной защиты с помощью аппаратных USB over IP

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

Итак, нам необходимо собрать в одном офисе все имеющиеся в нашей компании ключи банк клиентов, лицензий 1с (hasp), рутокены, ESMART Token USB 64K, и т.д. для последующей эксплуатации на удаленных физических и виртуальных машинах Hyper-V. Количество usb устройств – 50-60 и точно, что это не предел. Расположение серверов виртуализации вне офиса (датацентр). Расположение всех USB устройств в офисе.

Изучили существующие технологии централизованного доступа к USB устройствам и решили остановиться на технологии USB поверх IP (USB over IP). Оказывается, очень многие организации пользуются именно этим решением. На рынке есть как аппаратные средства проброса USB по IP, так и программные, но они нас не устраивали. По сему, далее речь пойдет только о выборе аппаратных USB over IP и в первую очередь о нашем выборе. Устройства из Китая (безымянные) мы тоже исключили из рассмотрения.

Наиболее описываемым на просторах интернета аппаратным решением USB over IP являются устройства производства США и Германии. Для детального изучения приобрели большой стоечный вариант этого USB over IP, рассчитанный на 14 портов USB, с возможностью монтажа в 19 дюймовую стойку и немецкий USB over IP, рассчитанный на 20 портов USB, так же с возможностью монтажа в 19 дюймовую стойку. К сожалению на большее количество портов устройств USB over IP у этих производителей не было.

Первое устройство весьма дорогое и интересное (в интернете полно обзоров), но есть очень большой минус — нет никаких систем авторизации для подключения USB устройств. Любой, кто установит приложение для подключения USB, получает доступ ко всем ключам. В дополнение, как показала практика, USB устройство «esmart token est64u-r1» непригодно для использования с устройством и, забегая вперед, с «немецким» на ОС Win7 – при подключении к нему перманентный BSOD.

Второе устройство USB over IP нам показалось интереснее. Устройство имеет большой набор настроек, связанных с сетевыми функциями. Интерфейс USB over IP логично разбит на разделы, так что первоначальная настройка была достаточно простой и быстрой. Но, как упоминалось ранее, возникли проблемы с подключением ряда ключей.

Изучая дальше аппаратные USB over IP натолкнулись на отечественных производителей. Модельный ряд включает 16, 32, 48 и 64 портовую версию с возможностью крепления в 19 дюймовую стойку. Описываемый производителем функционал был даже побогаче, чем у предыдущих приобретенных USB over IP. Изначально понравилось, что отечественный управляемый USB over IP концентратор обеспечивает двухступенчатую защиту USB устройств при совместном использовании USB по сети:

1. Удаленное физическое включение и выключение USB устройств;
2. Авторизацию для подключения USB устройств по логину, паролю и IP адресу.
3. Авторизацию для подключения USB портов по логину, паролю и IP адресу.
4. Журналирование как всех включений и подключений USB устройств клиентами, так и таких попыток (не правильный ввод пароля и т.д. ).
5. Шифрование трафика (с чем в принципе было неплохо и на немецкой модели).
6. Дополнительно подходило, что устройство, хоть и не дешевое, но в разы дешевле купленных ранее (особенно существенной становится разница при пересчете на порт, мы рассматривали 64-х портовый USB over IP).

Наименования и производителей USB over IP устройств не привожу (дабы не было рекламой), их достаточно просто найти в интернете.

Проброс eToken вовнутрь VirtualBox (Windows→Windows)

Имеем хост-систему (Windows XP) и виртуализированную гостевую систему (VirtualBox + Windows 7). К хосту подключен Aladdin eToken PRO (Java). Хотим работать с ним изнутри виртуалки.

Проблема: не работает. Симптомы выглядят как-то так (скриншот аладдиновского PKI-клиента внутри виртуализированной системы).

При этом забавно то, что более «тухлые» модели токенов типа вот такого заводятся внутри VirtualBox-а без каких-либо проблем и излишних телодвижений. По всей видимости, «затык» кроется в новых переработанных драйверах для последних версий токенов, которые почему-то не «зацепляются» корректно VirtualBox-овским перехватчиком USB-устройств на хосте.

В качестве решения можно порекомендовать вот такой костыль.

1. Физически выдёргиваем все имеющиеся токены из хост-машины.
2. На хосте идем в диспетчер устройств.
3. Логически отключаем все «устройства чтения смарт-карт», как показано на скриншоте. В результате должно получится что-то типа того (скриншот с системы на хост-машине).
4. Физически втыкаем нужные нам токены в хост-машину.
5. Пробрасываем токен вовнутрь виртуальной системы.
6. На этот раз всё должно заработать. Вот так выглядит «правильный» скриншот PKI-клиента изнутри виртуализированной системы.

Если не хочется / лениво каждый раз логически отключать-включать смарт-карты на хосте, то можно воспользоаться WorkAround-ом. Включить в виртуальной машине RDP-сервер (он же «удаленный рабочий стол») и зайти на него с хост-машины, предварительно включив редирект смарт-карт с клиента на сервер.

В таком случае всё также заработает без каких-либо дополнительных телодвижений.

Работа с закрытыми ключами на виртальной машине в Hyper-V « БЛОГ ЛИСА

ЭЦП

Как решить проблему, что криптопро не видит usb ключ?

Создали новую виртуальную машину и стали ставить софт все последовательно.

Перед установкой любого программного обеспечения работающего с USB носителями на которых находятся сертификаты и закрытые ключи. Нужно ОБЯЗАТЕЛЬНО
отключить токен, если воткнут локально, то отключаем его, если по сети, разрываем сессию

Описание окружения

Есть виртуальная машина на Vmware ESXi 6.5, в качестве операционной системы установлена Windows Server 2022 R2 . На сервере стоит КриптоПРО 4.0.9944, последней версии на текущий момент. С сетевого USB хаба, по технологии USB over ip , подключен ключ JaCarta. Ключ в системе видится
, а вот в КриптоПРО нет.

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

Код написан довольно дружелюбно для расширения, поэтому можно просто взять за основу класс 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

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

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

Алгоритм решения проблем с jacarta

КриптоПРО очень часто вызывает различные ошибки в Windows, простой пример (Windows installer service could not be accessed). Вот так вот выглядит ситуация, когда утилита КриптоПРО не видит сертификат в контейнере.

Как видно в утилите UTN Manager ключ подключен, он видится в системе в смарт картах в виде Microsoft Usbccid (WUDF) устройства, но вот CryptoPRO, этот контейнер не определяет и у вас нет возможности установить сертификат. Локально токен подключали, все было то же самое. Стали думать что сделать.

Возможные причины с определением контейнера

1. Во первых, это проблема с драйверами, например, в Windows Server 2022 R2, JaCarta в идеале должна определяться в списке смарт карт как JaCarta Usbccid Smartcard, а не Microsoft Usbccid (WUDF)
2. Во вторых если устройство видится как Microsoft Usbccid (WUDF), то версия драйверов может быть устаревшей, и из-за чего ваши утилиты будут не определять защищенный USB носитель.
3. Устарелая версия CryptoPRO

Выдача контейнера 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, когда-нибудь он точно выстрелит.Так что да, это важный момент, необходимый для осуществления дальнейшего текста.

Работа с закрытыми ключами на виртальной машине в hyper-v « блог лиса

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeCrypto ProSettingsUsersS-2-9-21-2883657810-1528702820-1102151106-1001KeysИванов Иван Иванович 01 01 2022]

криптопро hyper v

Электронная цифровая подпись

Как решить проблему, что криптопро не видит USB ключ?

Создали новую виртуальную машину и стали ставить софт все последовательно.

Перед установкой любого программного обеспечения работающего с USB носителями на которых находятся сертификаты и закрытые ключи. Нужно ОБЯЗАТЕЛЬНО
отключить токен, если воткнут локально, то отключаем его, если по сети, разрываем сессию

• Первым делом обновляем вашу операционную систему , всеми доступными обновлениями, так как Microsoft исправляет много ошибок и багов, в том числе и драйверами.
• Вторым пунктом является, в случае с физическим сервером, установить все свежие драйвера на материнскую плату и все периферийное оборудование.
• Далее устанавливаете Единый Клиент JaCarta.
• Устанавливаете свежую версию КриптоПРО

Работа с «КриптоПро NGate»

Предварительные комментарии

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

Подготовка к эксплуатации связана с первоначальным развёртыванием и настройкой программного обеспечения криптошлюза на аппаратной или виртуальной платформе. Этот этап является наиболее трудоёмким и ответственным. Он требует наличия практических навыков работы с операционной системой семейства Linux, знаний о сети организации и инфраструктуре открытых ключей (Public Key Infrastructure, PKI).

Затем с использованием веб-интерфейса администрирования осуществляется настройка криптошлюза для решения задач связанных с организацией доступа пользователей к ресурсам. Сюда входят настройка порталов, серверных мандатов, пользовательских ролей и политик доступа к защищаемым ресурсам, а также конфигурирование взаимодействия со внешними службами (Microsoft AD или другими LDAP-серверами, системами мониторинга, SIEM, средствами аутентификации, включая RADIUS-серверы, и др.).

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

Доступ к интерфейсу администрирования

В рамках подготовки этого обзора разработчик предоставил нам пользовательский сертификат и учётную запись типа «Аудитор» для доступа к тестовому стенду NGate. Эта пользовательская роль является одной из штатных функций продукта и предоставляет возможность просматривать большую часть разделов и возможностей веб-интерфейса без права что-либо изменять. Кроме того, для доступа использовались «Яндекс.Браузер», поскольку он поддерживает шифрование по ГОСТ, и «КриптоПро CSP» в качестве вспомогательного программного обеспечения (установочный файл доступен на основной странице после регистрации).

Рисунок 4. Вход в веб-интерфейс администрирования «КриптоПро NGate»

Панель управления

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

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

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

Рисунок 5. Вкладка «Системная информация» панели управления «КриптоПро NGate»

Новая вкладка и функция панели управления — «Сессии» — позволяет осуществлять поиск сеансов пользователей по различным критериям с расширенными возможностями фильтрации. Список параметров поиска включает кластер, портал, данные пользователя (имя или логин), IP-адрес клиента, состояние пользователя (активный или аутентифицированный), номер сертификата и используемый метод аутентификации. Администратор может останавливать выбранные сессии при необходимости.

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

Рисунок 6. Поиск сессий пользователей в веб-интерфейсе «КриптоПро NGate»

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

Рисунок 7. Информация о системе управления в составе «КриптоПро NGate»

Также в панели управления веб-интерфейса администрирования добавлена информация о статистике IP-адресов, которая показывает количество свободных адресов в выделенном сетевом диапазоне VPN для каждого кластера. Здесь же можно посмотреть их разбиение по узлам.

Рисунок 8. Информация о системе управления в составе «КриптоПро NGate»

Настройка конфигураций кластеров

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

Рисунок 9. Информация о конфигурации кластера в веб-интерфейсе «КриптоПро NGate»

Кроме того, на этой вкладке появилась функция по добавлению Stream-портала, то есть портала для доступа к ресурсам по произвольному протоколу на базе TCP поверх TLS. Ранее можно было добавлять порталы только для тех ресурсов, которые работают по HTTP.

Рисунок 10. Добавление портала для доступа пользователей к ресурсам по произвольному TCP-протоколу в веб-интерфейсе «КриптоПро NGate»

На другой вкладке этого же раздела можно смотреть детальную информацию о защищаемых ресурсах, настраивать их, добавлять новые, копировать или удалять уже существующие. Можно добавить веб-ресурс, динамический туннель, ресурс для перенаправления пользователей и gRPC-сервисы. По протоколу gRPC работают различные веб-приложения, а в целом он реализует удалённые программные интерфейсы (API).

Рисунок 11. Информация о ресурсах, связанных с кластером, в веб-интерфейсе «КриптоПро NGate»

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

Рисунок 12. Создание веб-ресурса в интерфейсе «КриптоПро NGate»

Список доступных внешних служб можно увидеть (и настроить) как в особом разделе веб-интерфейса, так и на вкладке выбранной конфигурации кластера. Но во втором случае будут отображены только те системы и серверы, которые настроены для конкретного кластера.

Рисунок 13. Внешние службы, настроенные для кластера, в веб-интерфейсе «КриптоПро NGate»

Также в разделах конфигурации кластера администратор осуществляет настройку правил и политик доступа к ресурсам (ACL) на основе групп пользователей на каком-либо сервере LDAP (к примеру, Microsoft AD) либо сертификатов (новая функциональность). Сертификатный ACL — это способ задать правила доступа на основе содержимого полей пользовательских сертификатов. В актуальной версии шлюза стало возможно создавать правила с запретительным доступом (в предыдущей версии он был только разрешительным), а также существенно расширился набор полей. Теперь анализируются не только поля с названием организации (Organization / Organization Unit), но и другие, в том числе нестандартные.

Рисунок 14. Настройка сертификатного ACL в веб-интерфейсе «КриптоПро NGate»

Настройка порталов

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

Рисунок 15. Общая информация о настройках портала в веб-интерфейсе «КриптоПро NGate»

Рисунок 16. Создание правила для динамического туннелирования в веб-интерфейсе «КриптоПро NGate»

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

Рисунок 17. Информация о сертификатах портала в веб-интерфейсе «КриптоПро NGate»

Также для каждого портала отдельно настраиваются методы аутентификации пользователей, включая RADIUS-протокол и форматы одноразовых паролей. Администратор может настроить многофакторную аутентификацию и определить перечень требуемых от пользователя данных, который, к примеру, одновременно может включать необходимость предоставить клиентский сертификат, логин и пароль из LDAP, затем PIN-код для доступа к OTP и сам OTP, полученный из SMS-сообщения или специализированного ПО 2FA (Google Authenticator, «Яндекс.Ключ» и т. д).

Рисунок 18. Настройка портала в веб-интерфейсе «КриптоПро NGate»

Настройки узлов

Новой функциональностью в разделе веб-интерфейса «Кластеры» стали возможности создания VLAN- и агрегированных сетевых интерфейсов (Bond-интерфейсов).

Рисунок 19. Общая информация об узлах кластера в веб-интерфейсе «КриптоПро NGate»

Рисунок 20. Сетевые интерфейсы узла кластера в веб-интерфейсе «КриптоПро NGate»

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

Рисунок 21. Создание Bond-интерфейса в «КриптоПро NGate»

Архитектура «КриптоПро NGate»

С точки зрения архитектуры NGate состоит из следующих компонентов: клиента (в виде VPN-клиента или браузера), сервера (самого шлюза) и системы управления (центра управления сетью, ЦУС). Дополнительно потребуется организовать автоматизированное рабочее место (АРМ) для администратора.

Основой серверной части NGate является криптопровайдер «КриптоПро CSP». В новой версии шлюза используется обновлённая его редакция — 5.0 R2. В ней помимо прочего реализована работа с алгоритмами «Кузнечик» (ГОСТ 34.12-2015) и «Магма» (ГОСТ 28147-89), добавлена и расширена поддержка отечественных операционных систем («Аврора», Astra Linux, ALT Linux). Кроме того, появились возможности по построению решений на базе отечественных процессоров «Байкал». Таким образом, стало возможным полноценное импортозамещение при внедрении криптографического шлюза для организации защищённого удалённого доступа ко критическим ресурсам.

В зависимости от размера конкретной организации, её сетевой инфраструктуры, предполагаемого количества клиентов, одновременных подключений и других параметров возможны два варианта конфигурации.

Минимальная — единое решение из одного криптошлюза, объединённого с центром управления на одной аппаратной или же виртуальной платформе. Такой вариант подойдёт для использования небольшими организациями, у которых нет филиалов или сетевая инфраструктура которых не разнесена по разным центрам обработки данных (ЦОДам). Эта конфигурация является самой простой в установке и настройке, однако не может обеспечить высокую отказоустойчивость и производительность при доступе к ресурсам, системам и приложениям.

Рисунок 1. Схема внедрения «КриптоПро NGate» в минимальной конфигурации

Кластерная конфигурация позволяет построить распределённую, отказоустойчивую и хорошо масштабируемую в части производительности систему. В этом варианте предусматривается объединение нескольких криптошлюзов (до 32 узлов единовременно) в один кластер. При этом центр управления сетью устанавливается отдельно и образует единую (централизованную) систему для настройки, мониторинга работы всех криптошлюзов и управления доступом к требуемым ресурсам и системам организации. Возможности центра управления по автоматизированной загрузке настроек и конфигураций на новые криптошлюзы в кластерах существенно облегчают и ускоряют процессы связанные как с вертикальной, так и с горизонтальной масштабируемостью системы. При этом выход из строя какого-либо узла кластера не приводит к разрыву соединений, поскольку балансировщик синхронизирует данные о сессии между устройствами и соединение перераспределяется на свободные узлы кластера. Может использоваться любой балансировщик, способный распределять TCP-соединения по узлам кластера, в том числе бесплатный HAProxy.

Рисунок 2. Схема внедрения «КриптоПро NGate» в виде кластера

Рисунок 3. Реализация технологии TLS VPN с помощью «КриптоПро NGate» в виде кластера

Инициализация 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) Применить маппинги:

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

Алгоритм решения проблем с JaCarta

КриптоПРО очень часто вызывает различные ошибки в Windows, простой пример (Windows installer service could not be accessed). Вот так вот выглядит ситуация, когда утилита КриптоПРО не видит сертификат в контейнере.

Как видно в утилите UTN Manager ключ подключен, он видится в системе в смарт картах в виде Microsoft Usbccid (WUDF) устройства, но вот CryptoPRO, этот контейнер не определяет и у вас нет возможности установить сертификат. Локально токен подключали, все было то же самое. Стали думать что сделать.

Disclamer

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

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

Windows Hyper-V + КриптоПро

Отзывы фрилансеров:
+ 13
– 0

Зарегистрирован на сайте 14 лет и 1 месяц

Требуется реализовать схему с разворачиванием некого временного виртуального Windows окружения с КриптоПро для создания ключа ЭЦП для пользователя и обратным сворачиванием.

Коротко, выглядит оно вот так: 1. на локальном ноутбуке с Windows делается ряд манипуляций и формируются документы или контейнер документов; 2. через запрос разворачивается виртуальное пространство, на котором развернуты рабочие стол(ы) и на этом столе запускается КриптоПро и наш софт, в который из пункта 1 передаются документы или контейнер документов 3. ботом на виртуальной машине выполняются стандартные действия и документы прокидываются далее.

08.06.2018 | 18:08 [последние изменения: 08.06.2018 | 18:50]

Функциональные возможности «КриптоПро NGate»

Режимы работы

Подробное описание основных режимов работы шлюза приведено на основной странице, посвящённой его особенностям. Мы дадим краткое определение этих режимов, достаточное для формирования чёткого представления о них.

Режим TLS-терминатора (TLS offload) или TLS-сервера для доступа к информационным ресурсам. При реализации такого формата функционирования шлюз становится промежуточным звеном между защищаемым публичным ресурсом и пользователем, который пытается получить доступ к нему используя веб-браузер (при этом установка VPN-клиента не требуется). NGate в режиме терминатора не осуществляет аутентификацию пользователей, но обеспечивает криптографическую защиту данных, передаваемых не только по HTTP, но и по HTTP/2, REST, gRPC, WebSockets и произвольным TCP-протоколам. Наиболее распространёнными и понятными примерами систем, для доступа к которым можно использовать криптографический шлюз в режиме терминатора, могут выступать различные государственные порталы (например, Единый портал государственных услуг), электронные торговые площадки, сайты дистанционного банковского обслуживания, видео-конференц-связи и телемедицины.

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

Режим VPN-сервера предназначен для реализации безопасного удалённого доступа сотрудников организации (на их устройства устанавливается VPN-клиент) к произвольным корпоративным ресурсам (файловым хранилищам, доступ по RDP и т. д.) с использованием технологии динамического туннелирования VPN TLS.

Методы аутентификации

NGate поддерживает разнообразные способы аутентификации, а также возможность их комбинировать:

• по логину и паролю (Microsoft Active Directory, AD);
• по сертификату (реализована не только простая проверка на валидность, но и аутентификация по различным полям сертификата: Organization, Organizational Unit (O / OU), Enhanced Key Usage, а также по дополнительным наборам полей, например СНИЛС, ИНН и т. д., в том числе при пустых полях O / OU);
• по имени участника-пользователя (User Principal Name, UPN) в Microsoft AD;
• с использованием сертификата присутствующего во внешней службе каталогов (Microsoft AD, LDAP);
• по одноразовому паролю (One-Time Password, OTP) при интеграции с RADIUS-сервером;
• с использованием сертификатов расположенных на различных токенах и смарт-картах (Aladdin, «Рутокен», Esmart и др.).

Возможности интеграции

Для расширения функциональных возможностей и формирования комплексных решений по защите сети, а также различных систем и ресурсов организации в соответствии с существующими потребностями бизнеса NGate можно гибко интегрировать с различными системами.

Таблица 5. Примеры сторонних систем, с которыми возможна интеграция «КриптоПро NGate»

Тип

Системы

Решения по обеспечению безопасности ЕБС

Типовые решения «Ростелекома», «Центра Финансовых Технологий» (ЦФТ) и IDSystems по обеспечению безопасности при взаимодействии банков с ЕБС

Специализированные аппаратные платформы

Промышленные планшеты MIG T10 и MIG T8, планшет «ПКЗ 2020», тонкие клиенты Dell Wyse и ТОНК, аппаратные платформы Getac

Системы видео-конференц-связи

Межсетевые экраны для веб-приложений

Сервис защиты веб-приложений Wallarm

Межсетевые экраны

Межсетевые экраны компаний Check Point, Fortinet, Ideco, UserGate

Системы класса Mobile Device Management (MDM)

SafePhone MDM, Microsoft Intune

Системы мониторинга и SIEM

«КриптоПро Центр Мониторинга» и любые сторонние системы, поддерживающие стандартные протоколы SNMP и Syslog

Системы аутентификации

Внешние службы каталогов (Microsoft AD, LDAP, FreeIPA, OpenLDAP, ApacheDS и др), RADIUS-серверы (Windows Server NPS, FreeRADIUS и т. д.)

Системы аутентификации на основе OTP

Продукт JaCarta Authentication Server (JAS) компании «Аладдин Р.Д.», решения компании Indeed-ID

Новые функции и улучшения

С момента выхода первой версии NGate было добавлено множество новых функций и возможностей, доработан пользовательский интерфейс консоли управления. Большое количество изменений связано с повышением удобства и упрощением взаимодействия с программным комплексом и оптимизацией его работы и быстродействия в целом. Это касается процессов связанных с его настройкой, контролем доступа пользователей к защищаемым ресурсам и системам, аутентификацией и управлением сертификатами.

Далее мы кратко перечислим новые функции и возможности или улучшения NGate версии 1.0 R2:

• Произошёл переход на новую базовую систему Debian 11.
• Выполнен переход на новую версию программного кода Python 3 в связи с окончанием поддержки Python 2.x.
• Произведено обновление криптопровайдера «КриптоПро CSP», составляющего основу серверной части шлюза, до версии 5.0 R2. В разделе с описанием архитектуры криптошлюза мы уже указали основные изменения, произошедшие в новой версии, поэтому дублировать их не будем.
• Расширена поддержка RADIUS-серверов для многофакторной аутентификации: теперь можно получать одноразовые пароли не только через SMS, появилась возможность одновременного ввода различных комбинаций OTP, кода OTP PIN и пароля пользователя из AD или LDAP, а также совместно с пользовательским сертификатом.
• Расширены возможности аутентификации по сертификату (Certificate Access Control List, ACL) на портале. Под порталом понимается сайт или группа сайтов, то есть совокупность ресурсов защищаемых криптошлюзом. Напомним, что теперь аутентификация возможна не только по полям Organization или Organizational Unit (O / OU), но и по дополнительным наборам полей.
• Добавлена возможность разграничения доступа к защищаемым ресурсам в зависимости от поддержки (или её отсутствия) клиентским устройством криптографических алгоритмов ГОСТ.
• Доработан и оптимизирован веб-интерфейс администратора. В частности, появилась панель для просмотра сессий подключённых пользователей и управления ими, добавлен способ быстрого копирования портала со всеми конфигурациями, расширен перечень вариантов фильтрации сертификатов, реализована функция создания резервной копии сразу из веб-интерфейса. Кроме того, были значительно дополнены комментарии к различным полям, упрощающие процессы взаимодействия с интерфейсом.
• Добавлена возможность криптографической защиты трафика передаваемого по HTTP/2, REST, gRPC, WebSockets и произвольным TCP-протоколам. Последнее выступает аналогом инструмента Stunnel и используется в основном для реализации доступа к ресурсам управления промышленными устройствами, защиты почтового трафика, передачи файлов (например, по FTP), удалённого доступа к устройствам по SSH и т. д.
• Реализована функция смены пароля пользователя в каталоге AD / LDAP при использовании клиента NGate.
• Добавлены возможности более тонкой настройки маршрутизации, а также управления приоритетом опроса — в том числе DNS-серверов — при разрешении имён через туннель (путём настройки метрики туннельного интерфейса).
• Значительно расширен перечень динамических HTTP-заголовков с информацией о клиенте, которые шлюз может отправлять защищаемым ресурсам. Кроме того, добавлена функция реализующая криптографическую защиту целостности передаваемых заголовков таким образом, чтобы ресурс мог проверить, кто является источником (или автором) конкретных заголовков и можно ли ему доверять. Отметим, что в случае передачи информации о паролях пользователей в HTTP-запросах она всегда шифруется с помощью специального алгоритма, построенного на базе симметричных шифров ГОСТ.
• Расширены функции по контролю соединений пользователей и управлению ими: добавлены возможности по настройке задержки синхронизации, таймаута для постоянных (keep-alive) HTTP-соединений, ограничения количества одновременных сессий пользователя, а также автоматического отключения при отзыве пользовательского сертификата. Кроме того, появилась функция принудительного разрыва соединений администратором.
• Добавлена поддержка TLS 1.3.

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

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

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

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

Сертификация шлюза «КриптоПро NGate» и выполнение требований законодательства

NGate был включён в Единый реестр российских программ для электронных вычислительных машин и баз данных Минцифры России в 2017 году (запись № 305680). В декабре 2019 года все компоненты шлюза (и серверные, и клиентские) прошли проверку на соответствие требованиям ФСБ России к средствам криптографической защиты информации по классам защиты КС1, КС2 и КС3 (получены сертификаты № СФ/124-3629, СФ/124-3630 и СФ/124-3631 для NGate в различных исполнениях). Кроме того, компоненты шлюза удалённого доступа используют в своём составе собственный криптопровайдер «КриптоПро CSP», который также сертифицирован ФСБ России для защиты информации по тем же классам.

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

Выше уже упоминалось, но повторим явно в текущем разделе следующее важное замечание. В среде виртуализации можно использовать NGate без ограничений функциональности и производительности (кроме тех, что связаны с характеристиками виртуальных машин), но только с пониженным классом сертификации. Криптошлюз NGate в виде виртуальной платформы отвечает требованиям ФСБ России по классу КС1.

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

Таблица 4. Требования законодательства РФ в области обеспечения информационной безопасности, которым отвечает «КриптоПро NGate»

Сфера ИБ

Законы

Дополнительная информация

Единая биометрическая система (ЕБС)

149-ФЗ (с изменениями 482-ФЗ) и 4-МР ЦБ РФ

NGate удовлетворяет требованиям указанных законов и методических рекомендаций в части удалённой идентификации в ЕБС, поскольку криптошлюз имеет необходимые сертификаты ФСБ России и поддерживает одновременно и ГОСТ TLS, и зарубежные криптонаборы TLS

Персональные данные (ПД) и государственные информационные системы (ГИС)

21-й / 17-й приказы ФСТЭК России

NGate реализует меры защиты информации в различных категориях:

• управление доступом в части УПД.13,
• защита информационных систем и передачи данных в части меры ЗИС.3,
• идентификация и аутентификация в части мер ИАФ.1, ИАФ.5 и ИАФ.6

Критическая информационная инфраструктура

239-й приказ ФСТЭК России

NGate реализует меры защиты информации в различных категориях:

• управление доступом в части мер УПД.13, УПД.14,
• защита информационных систем и их компонентов в части ЗИС.19,
• идентификация и аутентификация в части мер ИАФ.1, ИАФ.5, ИАФ.6 и ИАФ.7.

Кроме этого, криптошлюз отвечает следующим требованиям приказа (п. 31):

• не допускается наличия удалённого доступа напрямую к защищаемым объектам критической информационной инфраструктуры (КИИ) со стороны третьих лиц, т. е. не работников объекта КИИ (такой доступ через NGate допускается, поскольку VPN-доступ не считается доступом «напрямую»),
• должна обеспечиваться стойкость к санкциям (выполняется, поскольку NGate — полностью отечественный криптошлюз),
• реализуется полная поддержка со стороны производителя.

Защита информации финансовых организаций

ГОСТ Р 57580.1-2017

NGate реализует большинство требований в категории защиты информации от раскрытия и модификации при осуществлении удаленного доступа (ЗУД)

Удалённый мониторинг энергооборудования

1015-й приказ Министерства энергетики РФ

NGate реализует следующие требования к информационной безопасности объектов электроэнергетики:

• обеспечение криптографической защиты удалённого соединения и обмена данными,
• применение сертифицированных средств защиты информации.

Системные требования «КриптоПро NGate»

NGate сертифицирован ФСБ России по классам защиты КС1, КС2 и КС3 и может поставляться как в виде программно-аппаратного комплекса, с предустановкой программного обеспечения на специализированные сетевые аппаратные платформы в различных конфигурациях в зависимости от необходимых технических параметров, вычислительных мощностей и требований инфраструктуры каждой конкретной организации, так и в виде программного обеспечения для развёртывания в среде виртуализации.

В первом случае компания приобретает оборудование для системы управления NGate (две модели) и каждого из узлов кластера (шесть вариантов). В следующих двух таблицах мы собрали основные технические характеристики и показатели производительности аппаратных платформ NGate.

Таблица 1. Основные характеристики аппаратных платформ «КриптоПро NGate» (центр управления сетью)

Параметр

«NGate ЦУС 100»

«NGate ЦУС 200»

Формфактор

Параметры блока питания

300 Вт ATX, резервный БП (PSU)

Сетевые интерфейсы

RJ-45 1GbE × 6 шт.

RJ-45 1GbE × 8 шт.
SFP+ LAN 10 GbE × 4 шт.

Таблица 2. Основные характеристики аппаратных платформ «КриптоПро NGate» (узел кластера)

Параметр

NGate 3000

NGate 2000

NGate 1500

NGate 1000

NGate 600

NGate 320

TLS Proxy

До 45 000 подключений,
до 20 Гбит/c

До 15 000 подключений,
до 8 Гбит/c

До 8 000 подключений,
до 4 Гбит/c

До 4 000 подключений,
до 2,3 Гбит/c

До 2 000 подключений,
до 1 Гбит/c

До 500 подключений,
до 0,6 Гбит/c

TLS VPN

До 12 000 подключений,
до 8 Гбит/c

До 8 000 подключений,
до 5 Гбит/c

До 4 000 подключений,
до 2 Гбит/c

До 2 000 подключений,
до 1 Гбит/c

До 700 подключений,
до 0,5 Гбит/c

До 150 подключений,
до 0,14 Гбит/c

Формфактор

Параметры блока питания

650 Вт АТХ, резервный БП (PSU)

300 Вт АТХ, резервный БП (PSU)

300 Вт АТХ, резервный БП (PSU)

36 Вт, адаптер питания 12В 3А

Сетевые интерфейсы

RJ-45 1GbE × 4 шт.
SFP+ LAN 10GbE × 4 шт.

RJ-45 1GbE × 8 шт.
SFP+ LAN 10GbE × 4 шт.

RJ-45 1GbE × 6 шт.
SFP LAN 1 GbE × 2 шт.

RJ-45 1GbE × 6 шт.

RJ-45 1GbE × 3 шт.

Для развёртывания NGate в виде виртуальной программной платформы виртуальные машины должны удовлетворять определённым системным требованиям. Мы перечислили их в таблице далее.

Таблица 3. Системные требования для установки системы управления «КриптоПро NGate» в среде виртуализации

Параметр

ЦУС NGate

Узел NGate

Среда виртуализации

VMware Workstation (версии 11–16),
VMware ESXi (версии 5.5–7.0),
Hyper-V (версии 8, 8.1, 10, 2008, 2008 R2, 2012, 2012 R2, 2016),
Xen (Citrix Hypervisor) (версии 7.1–8.2),
Virtual Box (версии 3.2–6.1)

Гостевая операционная система

Debian Linux 11 x64

Оперативная память

Жёсткий диск

Не менее 100 ГБ (в том числе для журналирования событий и другой информации)

Виртуальные сетевые интерфейсы

Не менее 1 шт.
(тип сетевого адаптера — E1000, тип сетевого взаимодействия — Bridged Networking)

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

К программной и аппаратной частям пользовательских устройств для работы VPN-клиента NGate особых требований не предъявляется. Работа VPN-клиента возможна практически на всех популярных настольных и мобильных операционных системах, включая отечественные программные и аппаратные разработки:

• Microsoft Windows версий 7, 8, 8.1, 10, 11,
• macOS версий 10.10–10.15, 11,
• Linux (RHEL, CentOS, Debian, Ubuntu, ROSA, Astra, ALTLinux и другие),
• iOS,
• Android,
• «Аврора».

Для получения доступа к защищаемым ресурсам пользователь может применять VPN-клиент NGate, веб-браузер либо собственное мобильное приложение после встраивания в него криптопровайдера «КриптоПро CSP 5.0 R2» (реализует поддержку TLS с ГОСТ для операционных систем iOS, Android и «Аврора» без дополнительных тематических исследований).

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

Код написан довольно дружелюбно для расширения, поэтому можно просто взять за основу класс 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, а так это просто список идей.

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

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

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

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

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

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

3 Comments

держу на ESXi 5.5 Windows 2012 R2
стоит крипто про 3.9
почему то после закрытия сбиса иногда процесс остается висеть в памяти, не сталкивались с такой проблемой?
при этом можно запустить еще раз сбис и он откроется нормально, никакие файлы не будут заблокированы предыдущей версией.
не могу понять в чем дело, отъедает память сильно если несколько копий останутся запущенные весеть..

На Windows 7 x64 были совместно установлены Virtual Box (версии 4 и 5) с расширением Extension Pack и CryptoPro CSP (КриптоПро CSP 3.6 R4 для Windows).

При запуске виртуальной машины через Virtual Box система падала в синий экран. Причина в невозможности совместной работы КриптоПро CSP и Virtual Box.

Чтобы не было синего экрана при запуске виртуальной машины VirtualBox удалил КриптоПро CSP и перезагрузил компьютер. Решение временное, не сумел разобраться как подружить два продукта, а VirtualBox был нужнее, чем КриптоПро.

Помогло выйти на связь VirtualBox + КриптоПро == BSOD сообщение на форуме:
На форуме Крипто Про также есть обсуждение:
Отчёты из программы blueScreenView :

Bug Check String	SYSTEM_SERVICE_EXCEPTION
Bug Check Code	0x0000003b
Parameter 1	00000000`c0000005
Parameter 2	fffff800`032735af
Parameter 3	fffff880`0412eb90
Parameter 4	00000000`00000000
Caused By Driver	ntoskrnl.exe
Caused By Address	ntoskrnl.exe+73c40
File Description	NT Kernel & System
File Version
Major Version	15
Minor Version	7601

A problem has been detected and Windows has been shut down to prevent damage
to your computer.
The problem seems to be caused by the following file: ntoskrnl.exe
SYSTEM_SERVICE_EXCEPTION
Technical Information:
*** STOP: 0x0000003b (0x00000000c0000005, 0xfffff800032735af, 0xfffff8800412eb90,
0x0000000000000000)
*** ntoskrnl.exe – Address 0xfffff80003292c40 base at 0xfffff8000321f000 DateStamp
0x5625815c
Вывод – Virtual Box (версии 4 и 5) и CryptoPro CSP (КриптоПро CSP 3.6 R4 для Windows) пока несовместимы на Windows 7 x64 SP1.

Подключил к первому монитору второй монитор, используя USB 3.0 VGA Adapter. Модель устройства – Fresco Logic FL200 USB Display Adapter. Если подключить адаптер до включения виртуальной машины, то порядок. А если подключать адаптер во время работы виртуальной машины Virtual Box, то будет снова синий экран.

Bug Check String	IRQL_NOT_LESS_OR_EQUAL
Bug Check Code	0x0000000a
Parameter 1	00000000`00000088
Parameter 2	00000000`00000002
Parameter 3	00000000`00000001
Parameter 4	fffff800`032579e6
Caused By Driver	ntoskrnl.exe
Caused By Address	ntoskrnl.exe+73c00
File Description	NT Kernel & System
File Version	6.1.7601.19110 (win7sp1_gdr.151230-0600)
Major Version	15
Minor Version	7601

A problem has been detected and Windows has been shut down to prevent damage
to your computer.
The problem seems to be caused by the following file: ntoskrnl.exe
IRQL_NOT_LESS_OR_EQUAL
Technical Information:
*** STOP: 0x0000000a (0x0000000000000088, 0x0000000000000002, 0x0000000000000001,
0xfffff800032579e6)
*** ntoskrnl.exe – Address 0xfffff80003276c00 base at 0xfffff80003203000 DateStamp
0x5684191c

Из того, что видно перед ошибкой – диспетчер устройств (HAL) сообщает, что подключено новое USB 2.0 устройство, а затем система падает. Диспетчер устройств не прав, так как подключается USB 3.0 устройство в USB 3.0 порт.

Возможно, просто совпадение, два BSOD-а подряд. И причина BSOD в реализации драйверов для Fresco Logic FL200 USB Display Adapter.

Но есть предположение, что причина ошибок в реализации поддержки USB 2.0 / USB 3.0 в VirtualBox. А особые возможности поддержки USB появляются при установке Oracle VM VirtualBox Extension Pack.

Удалить VirtualBox не хотелось бы, иногда бывает нужен. А удалить Extension Pack могу запросто. Надеюсь, что после удаления VirtualBox Extension Pack синих экранов больше не будет. И можно будет повторно установить КриптоПро CSP 3.6 R4 для Windows и пользоваться двумя мониторами.

Добрый день!. Последние два дня у меня была интересная задача по поиску решения на вот такую ситуацию, есть физический или виртуальный сервер, на нем установлена наверняка многим известная КриптоПРО. На сервер подключен , который используется для подписи документов для ВТБ24 ДБО
. Локально на Windows 10 все работает, а вот на серверной платформе Windows Server 2016 и 2012 R2, Криптопро не видит ключ JaCarta
. Давайте разбираться в чем проблема и как ее поправить.

Описание окружения

Есть виртуальная машина на Vmware ESXi 6.5, в качестве операционной системы установлена Windows Server 2012 R2 . На сервере стоит КриптоПРО 4.0.9944, последней версии на текущий момент. С сетевого USB хаба, по технологии USB over ip , подключен ключ JaCarta. Ключ в системе видится
, а вот в КриптоПРО нет.

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

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

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

Гуглю ошибку, и что же мы видим на официальном форуме?
https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=2425

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

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

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

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

Этот вопрос широко представлен в интернете, поэтому можно сразу смотреть Stackoverflow:
http://stackoverflow.com/questions/14580340/generate-gost-34-10-2001-keypair-and-save-it-to-some-keystore

Идея в том, что раз уж мы все равно используем 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:

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

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

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

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

Установка единого клиента JaCarta PKI

Единый Клиент JaCarta
– это специальная утилита от компании “Аладдин”, для правильной работы с токенами JaCarta. Загрузить последнюю версию, данного программного продукта, вы можете с официального сайта, или у меня с облака, если вдруг, не получиться с сайта производителя.

Далее полученный архив вы распаковываете и запускаете установочный файл, под свою архитектуру Windows , у меня это 64-х битная. Приступаем к установке Jacarta драйвера. Единый клиент Jacarta, ставится очень просто (НАПОМИНАЮ ваш токен в момент инсталляции, должен быть отключен). На первом окне мастера установки, просто нажимаем далее.

Принимаем лицензионное соглашение и нажимаем “Далее”

Чтобы драйвера токенов JaCarta у вас работали корректно, достаточно выполнить стандартную установку.

Если выберете “Выборочную установку”, то обязательно установите галки:

• Драйверы JaCarta
• Модули поддержки
• Модуль поддержки для КриптоПРО

Через пару секунд, Единый клиент Jacarta, успешно установлен.

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

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

На текущий момент самая последняя версия КриптоПро CSP 4.0.9944. Запускаем установщик, оставляем галку “Установить корневые сертификаты” и нажимаем “Установить (Рекомендуется)”

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

После перезагрузки подключайте ваш USB токен JaCarta. У меня подключение идет по сети, с устройства DIGI, через . В клиенте Anywhere View, мой USB носитель Jacarta, успешно определен, но как Microsoft Usbccid (WUDF), а в идеале должен определиться как JaCarta Usbccid Smartcard, но нужно в любом случае проверить, так как все может работать и так.

Открыв утилиту “Единый клиент Jacarta PKI”, подключенного токена обнаружено не было, значит, что-то с драйверами.

Microsoft Usbccid (WUDF) – это стандартный драйвер Microsoft, который по умолчанию устанавливается на различные токены, и бывает, что все работает, но не всегда. Операционная система Windows по умолчанию, ставит их в виду своей архитектуры и настройки, мне вот лично в данный момент такое не нужно. Что делаем, нам нужно удалить драйвера Microsoft Usbccid (WUDF) и установить драйвера для носителя Jacarta.

Откройте диспетчер устройств Windows, найдите пункт “Считыватели устройств смарт-карт (Smart card readers)” щелкните по Microsoft Usbccid (WUDF) и выберите пункт “Свойства”. Перейдите на вкладку “Драйвера” и нажмите удалить (Uninstall)

Согласитесь с удалением драйвера Microsoft Usbccid (WUDF).

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

После перезагрузки системы, вы можете увидеть установку устройства и драйверов ARDS Jacarta.

Откройте диспетчер устройств, вы должны увидеть, что теперь ваше устройство определено, как JaCarta Usbccid Smartcar и если зайти в его свойства, то вы увидите, что смарт карта jacarta, теперь использует драйвер версии 6.1.7601 от ALADDIN R.D.ZAO, так и должно быть.

Если открыть единый клиент Jacarta, то вы увидите свою электронную подпись, это означает, что смарт карта нормально определилась.

Открываем CryptoPRO, и видим, что криптопро не видит сертификат в контейнере, хотя все драйвера определились как нужно. Есть еще одна фишка.

1. В RDP сессии вы не увидите свой токен, только локально, уж такая работа токена, либо я не нашел как это поправить. Вы можете попробовать выполнить рекомендации по устранению ошибки “Не возможно подключиться к службе управления смарт-картами”.
2. Нужно снять одну галку в CryptoPRO

ОБЯЗАТЕЛЬНО снимите галку “Не использовать устаревшие cipher suite-ы” и перезагрузитесь
.

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

Еще можете в устройствах и принтерах, увидеть ваше устройство JaCarta,

Если у вас как и у меня, токен jacarta установлен в виртуальной машине, то вам придется устанавливать сертификат, через console виртуальной машины, и так же дать на нее права ответственному человеку. Если это физический сервер, то там придется давать права на порт управления , в котором так же есть виртуальная консоль.

Когда вы установили все драйвера для токенов Jacarta, вы можете увидеть при подключении по RDP и открытии утилиты “Единый клиент Jacarta PKI” вот такое сообщение с ошибкой:

1. Не запущена служба смарт-карт на локальной машине. Архитектурой RDP-сессии, разработанной Microsoft, не предусмотрено использование ключевых носителей, подключенных к удалённому компьютеру, поэтому в RDP-сессии удалённый компьютер использует службу смарт-карт локального компьютера. Из этого следует что, запуска службы смарт-карт внутри RDP-сессии недостаточно для нормальной работы.
2. Служба управления смарт-картами на локальном компьютере запущена, но недоступна для программы внутри RDP-сессии из-за настроек Windows и/или RDP-клиента.\

Как исправить ошибку “Не возможно подключиться к службе управления смарт-картами”.

• Запустите службу смарт-карт на локальной машине, с которой вы инициируете сеанс удалённого доступа . Настройте её автоматический запуск при старте компьютера.
• Разрешите использование локальных устройств и ресурсов во время удалённого сеанса (в частности, смарт-карт). Для этого, в диалоге “Подключение к удалённому рабочему столу” в параметрах выберите вкладку “Локальные ресурсы”, далее в группе “Локальные устройства и ресурсы” нажмите кнопку “Подробнее…”, а в открывшемся диалоге выберите пункт “Смарт-карты” и нажмите “ОК”, затем “Подключить”.

• Убедитесь в сохранности настроек RDP-подключения. По умолчанию они сохраняются в файле Default.rdp в каталоге “Мои Документы” Проследите, чтобы в данном файле присутствовала строчка “redirectsmartcards:i:1”.
• Убедитесь в том, что на удалённом компьютере , к которому вы осуществляете RDP-подключение, не активирована групповая политика
  -[Конфигурация компьютера\административные шаблоны\компоненты windows\службы удалённых рабочих столов\узел сеансов удалённых рабочих столов\перенаправление устройств и ресурсов\Не разрешать перенаправление устройства чтения смарт-карт]. Если она включена (Enabled), то отключите её, и перегрузите компьютер.
• Если у вас установлена Windows 7 SP1 или Windows 2008 R2 SP1 и вы используете RDC 8.1 для соединения с компьютерами под управлением Windows 8 и выше, то вам необходимо установить обновление для операционной системы https://support.microsoft.com/en-us/kb/2913751

Вот такой вот был траблшутинг по настройке токена Jacarta, КриптоПРО на терминальном сервере, для подписи документов в ВТБ24 ДБО. Если есть замечания или поправки, то пишите их в комментариях.