Keygen for CSP 5.0 and CSP 1.0, InfoCrypt VPN-Kein

Добрый день,
использовался КриптоПРО CSP 4.0.9963 с настройками при установке по умолчанию. Истекло 3 месяца, перестал работать, ввожу лицензионный ключ, но выдает сообщение: “Ошибка проверки серийного номера. Введён серийный номер от клиентской версии продукта.”. Установка других дистрибутивов тоже приводит к этому сообщению. Мне клиентская версия лицензии подходит.
Видимо, где-то осталась конфигурация и он теперь при установке видит её только как серверную. Как установить её как клиентскую?

Upd: насколько я понял для Windows Server автоматически устанавливается версия CSP серверная и ожидает соответствующую лицензию.

Отредактировано пользователем 21 декабря 2021 г. 16:01:02(UTC)
 | Причина: Не указана

Здравствуйте.

Да, на Windows Server можно активировать только серверную лицензию КриптоПро CSP.

Добрый день.
Возникли проблемы с InfoCrypt VPN-Key-TLS. КриптоПРО CSP не видит контейнера ключей на носителе. В списке установленных ключевых носителей присутствует InfoCrypt VPN-Key-TLS. Сам токен работает на компьютере без сбоев.
Подскажите пожалуйста возможные шаги для исправления ситуации.
Подскажите, можно ли вообще использовать сертификаты на указанном токене для работы через КриптоПРО, что для этого требуется?
Используется КриптоПРО CSP 5.0.12266 KC1. Прошивка токена – 5.0 build 505.23 / devcfg: “IC0_T32S0000L_C1_VT505NT5”

Добрый день.
Совместимость с КриптоПро CSP появилась только в прошивке 550 (у вас – 505).

С уважением,
Сергей Агафьин,
Начальник отдела разработки ФКН.
Техническую поддержку оказываем здесь.
Наша база знаний.

Спасибо большое.
Нашел обновление прошивки, все заработало как надо.

Здравствуйте! Та же самая проблема с совместимостью КриптоПРО и InfoCrypt VPN-Key-TLS. Версии обоих ПО актуальные (Криптопро 5.0.11455 КС1; Инфокрипт 550.257). Тем не менее Криптопро не видит подпись, записанную на токен Инфокрипт. Настройку считывателей в Криптопро делать пытались.

/Ссылки были удалены администратором/

Отредактировано модератором 14 апреля 2022 г. 15:19:55(UTC)
 | Причина: Не указана

Добрый день.
5.0.11455 умеет работать с VPN-Key-TLS, но для создания своих ключей. “Чужие” он читать и использовать не может.
5.0.12000 умеет работать с совместимостью в обе стороны.

С уважением,
Сергей Агафьин,
Начальник отдела разработки ФКН.
Техническую поддержку оказываем здесь.
Наша база знаний.

оставлено 12.11.2021(UTC),

nickm

оставлено 16.11.2021(UTC)

То есть есть смысл обновиться до версии 5.0.12000?

Попробуйте – хуже точно не будет. Эта версия сертифицирована ФСБ.

С уважением,
Сергей Агафьин,
Начальник отдела разработки ФКН.
Техническую поддержку оказываем здесь.
Наша база знаний.

Большое спасибо Вам за оперативный ответ! Попробуем.

Апргейд версии КриптоПро помог, но в силу того, что он несертифицированный, он не поддерживается сервисом, через который мы сдаём отчетность (СБИС). Подскажите, пожалуйста, есть ли варианты версий КриптоПро, которые мы можем задействовать, чтобы была совместимость и с прошивкой подписи и с сертифицированностью?

Версия CSP 5.0.12000, которую я советовал, сертифицирована ФСБ:
https://www.cryptopro.ru…downloads#latest_csp50r2

С уважением,
Сергей Агафьин,
Начальник отдела разработки ФКН.
Техническую поддержку оказываем здесь.
Наша база знаний.

Спасибо, разобрались. Всё настроили, всё получилось. Огромное Вам спасибо ещё раз!

Использование сертифицированной версии КриптоПРО является обязательным, чтобы СБИС увидел контейнеры на токене Infocrypt HWDSSL? С несертифицированной версией работать не получится?

С любой версией, которая имеет поддержку токена, получится работать. Это либо сертифицированный CSP 5.0 R2, либо любая сборка CSP 5.0 R3.

С уважением,
Сергей Агафьин,
Начальник отдела разработки ФКН.
Техническую поддержку оказываем здесь.
Наша база знаний.

оставлено 10.01.2022(UTC)

Спасибо Вам за быстрый ответ!

Прошу прощения, если вопрос не по адресу – но нужно ли что-то доустанавливать для КриптоПРО, чтобы СБИС начал видеть контейнеры на этом токене? КриптоПРО все контейнеры видит, без проблем входим в Контур.Диадок используя их, а вот СБИС ни онлайн версия, ни десктопная “Электронная отчетность” их не видят совсем.

Никакой настройки КриптоПРО не выполняли.

Версия встроенного ПО (токена) : 550.257 (IC0_T32S0000L_C1_VT550HT5)
Версия КриптоПРО: 5.0.12330 КС1
Версия КриптоПРО ЭЦП Browser plug-in: 2.0.14459

Отредактировано пользователем 10 января 2022 г. 17:30:30(UTC)
 | Причина: Не указана

Если провайдер видит контейнеры, то для провайдера ничего доставлять не нужно. Возможно, у СБИС есть фильтр на поддерживаемые носители.

С уважением,
Сергей Агафьин,
Начальник отдела разработки ФКН.
Техническую поддержку оказываем здесь.
Наша база знаний.

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

Добрый вечер.
КриптоПРО CSP не видит контейнера ключей на носителе.
КриптоПРО CSP 5.0 (демо версия)
“ESMART Token ГОСТ”
Может это быть из-за демо версии?

Спасибо! По сути так и оказалось.

С решением помогла техподдержка СБИС. Если кому-то пригодится, то вот оно:
1) закрыть СБИС Плагин
2) в файл %LocalAppData%\Sbis3Plugin\user-config.ini добавить строки

3) запустить СБИС Плагин

Отредактировано пользователем 11 января 2022 г. 17:14:11(UTC)
 | Причина: Не указана

Аналогичная история, сервер тестирования (cvs.sbis.ru) выдавал ошибку:

После создания файла ~/.Sbis3Plugin/user-config.ini с указанными строчками все заработало.

Здравствуйте!

Помогите разобраться с вопросом импорта закрытого ключа из файла по ГОСТ Р 34.11-2012/34.10-2012 256 бит.
Искал на форуме решения, но всё равно не понятно, почему ключ не читается?

Использую следующее окружение:

Debian GNU/Linux 11
openjdk version "1.8.0_302"
OpenJDK Runtime Environment (build 1.8.0_302-b08)
OpenJDK 64-Bit Server VM (build 25.302-b08, mixed mode)
jcp-2.0.41789

Например, получил ключ с помощью openssl, который настроен на ГОСТ.

# openssl ciphers | tr ':' '\n' | grep GOST
GOST2012-GOST8912-GOST8912
GOST2001-GOST89-GOST89
// Создание ключей по алгоритму подписи 1.2.643.7.1.1.3.2 (ГОСТ Р 34.11-2012/34.10-2012 256 бит)
# openssl req -x509 -newkey gost2012_256 -pkeyopt paramset:A -nodes -keyout keyA.pem -out certA.pem
# openssl x509 -outform der -in certA.pem -out certA.crt

Пытаюсь прочитать закрытый ключ keyA.pem из файла по алгоритму подписи ГОСТ Р 34.10-2012 с ключом 256 (1.2.643.7.1.1.1.1) с помощью провайдера BouncyCastle Security Provider v1.60.

# java -cp .:dependencies/* PKeyReader /distrib/cert/test/keyA.pem 1.2.643.7.1.1.1.1 BC certA.zip (2kb) загружен 0 раз(а).
+ key factory: java.security.KeyFactory@340f438e
 algorithm: 1.2.643.7.1.1.1.1
 provider: BC version 1.6
+ pkcs8 encoded key spec: java.security.spec.PKCS8EncodedKeySpec@30c7da1e
 format: PKCS#8
Exception in thread "main" java.security.spec.InvalidKeySpecException: encoded key spec not recognized: DEF length 39 object truncated by 9
        at org.bouncycastle.jcajce.provider.asymmetric.util.BaseKeyFactorySpi.engineGeneratePrivate(Unknown Source)
        at org.bouncycastle.jcajce.provider.asymmetric.ecgost12.KeyFactorySpi.engineGeneratePrivate(Unknown Source)
        at java.security.KeyFactory.generatePrivate(KeyFactory.java:366)
        at PKeyReader.main(PKeyReader.java:62)

Возможно ли прочитать ключ в PrivateKey таким образом?

import org.bouncycastle.jce.provider.BouncyCastleProvider;

import java.io.IOException;
import java.net.URISyntaxException;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.security.Security;
import java.security.KeyFactory;
import java.security.NoSuchAlgorithmException;
import java.security.PrivateKey;
import java.security.interfaces.RSAPublicKey;
import java.security.spec.InvalidKeySpecException;
import java.security.spec.PKCS8EncodedKeySpec;
import java.security.spec.X509EncodedKeySpec;
import java.util.Base64;

/**
 * Чтение закрытого ключа из файла.
 */
public class PKeyReader {

    /**
    * Попытка прочитать закрытый ключ из файла
    * @param 	путь к ключу
    * @param	алгоритм
    * @param	провайдер (опциональный)
    */
  public static void main(String[] args) throws Exception {
    if (args.length < 2) {
      System.out.println("input error: skipped required parameters.");
      System.out.println("  java .:dependences/* Main [key path] [algorithm] {provider}");
      return;
    }

    Security.addProvider(new BouncyCastleProvider());

    String privateKeyPath = args[0];
    String algorithm = args[1];
    String provider = args.length > 2 ? args[2] : "";

    String privateKeyContent = new String(Files.readAllBytes(Paths.get(privateKeyPath)));

    privateKeyContent = privateKeyContent.replace("-----BEGIN PRIVATE KEY-----", "").replace("-----END PRIVATE KEY-----", "").replaceAll("\\s", "");

    System.out.println(privateKeyContent);

    KeyFactory kf = null;
    if (provider.isEmpty())
      kf = KeyFactory.getInstance(algorithm);
    else
      kf = KeyFactory.getInstance(algorithm, provider);

    System.out.println("+ key factory: " + kf);
    System.out.println(" algorithm: " + kf.getAlgorithm());
    System.out.println(" provider: " + kf.getProvider());

    byte[] privData = Base64.getDecoder().decode(privateKeyContent);
    PKCS8EncodedKeySpec keySpecPKCS8 = new PKCS8EncodedKeySpec(privData);
    System.out.println("+ pkcs8 encoded key spec: " + keySpecPKCS8);
    System.out.println(" format: " + keySpecPKCS8.getFormat());

    PrivateKey privKey = kf.generatePrivate(keySpecPKCS8);

    System.out.println("+ private key: " + privKey);
  }
}

Добрый день.
Что-то эту тему проглядел. Импорта куда? Опишите какую задачу решаете.

Как я понимаю, импортировать таким способом ключ в КриптоПро невозможно. КриптоПро CSP не выпускает реальный ключ “наружу” (и через большинство интерфейсов не принимает реальный ключ “извне”) – при поиске контейнера КриптоПро по сертификату в результате в классе PrivateKey находится идентификатор закрытого ключа вместо реального закрытого ключа. Аналог как в раздевалке берется пальто с прилавка и дается в руки номерок вместо пальто. Соответственно при использовании класса PrivateKey для подписания/шифрования также расчет на то, что там идентификатор, а не сам ключ. По идентификатору КриптоПро находит у себя закрытый ключ (по номерку находится пальто). Импорт ключа из PrivateKey просто не поддерживается: выходит что вместо номерка пихаете еще одно пальто.

В теории способ перенести ключ openssl в КриптоПро есть: средствами openssl нужно зашифровать ключ в формат P12/PFX, с алгоритмом шифрования гост-89 и маками гост-2012 512 бит (согласно рекомендациям ТК26), затем использовать p12utility для переноса ключа из pfx в контейнер КриптоПро. Один из JCP/JCSP к слову умеет читать PFX с ключами гост-2012, но мне сложно подсказать какие там алгоритмы обертки ключа принимаются.

Спасибо за ответ!

Отличный пример с раздевалкой, сразу становится всё на свои места. )))
Сразу было понятно, что импорт не поддерживается штатными средствами.

Задача решалась в рамках интеграции с адаптером СМЭВ, импорт ключей в JCP контейнер.
Проблема решилась путём копирования Rutoken в HDImageStore в контрольной панели, для получения псевдонима подписи.

Ещё пару вопросов:

– p12utility есть ли аналоги этой утилиты в Linux?

– ошибка тестирования подписи закрытого ключа в настройках информационной системы (ИС) адаптера СМЭВ.
Ситуация такая, скопировал каталог HDImageStore с 6 файлами в другой каталог docker контейнера, где настроил адаптер СМЭВ и Крипто Про JCP. Когда проверяю подпись в настройках ИС, получаю сообщение,
Провайдер JCP – OK
Открытый ключ – OK
Тестирование подписи закрытого ключа – FAIL.
При этом подпись работает на виртуалке, где есть Rutoken (который скопирован в HDImageStore).
Копировал в каталог /var/opt/cprocsp/keys/root/TEST.000
Это тоже связано с тем, что копируется ид закрытого ключа?

Мне не попадались на глаза. По внешнему анализу под Windows утилита самодостаточная (КриптоПро CSP не требуется), но запрашивает у Майкрософт КриптоАпи случайные данные, поэтому для портирования в Linux явно понадобится другой надежный источник случайных чисел. Скорее всего с этим проблем – к чему ее привязать на разномастных Linux тот еще вопросик.

Про ид закрытого ключа скорее речи нет – в папке в файле name.key указывается дружественное имя контейнера и может фигурировать контрольная сумма от него, так что при копировании папки это должно сохранится. Для флешек может фигурировать метка флешки и volumeid. Для токена его серийный номер. Для двух HDIMAGE не припомню чтобы были какие отличия, но могу ошибаться.

Можно сравнить какие fqcn у контейнера в одном месте и в другом. Если отличаются, то связка сертификата и контейнера после копирования стала неверна и нужно по-новой связать сертификат и контейнер. Правда, как это выглядит в JCP подсказать не смогу, другой alias это станет или что еще.

Если вообще не видно контейнера… На первый взгляд путь правдоподобный. Может еще быть пользователь не тот (путь для root, а приложение от чьего имени выполняется? ), либо нет прав у пользователя на этот каталог.

Приложение адаптера запускаю под root, и криптоконтейнер настраивал для root.

Спасибо большое за развёрнутый ответ!

Стало понятно, что подпись можно настроить в докер контейнере независимо от rutoken.

Появилось несколько аладин ключей с не извлекаемой частью. Необходимо для начала пробросить их на виртуальный сервер со службой удаленных рабочих столов на которых крутится 1с. Которой и нужны эти клоючи. Через что это реализуется?

Вопрос номер два.Ключ один.Нужно вести учет доступа .. кто и что подписывал им в разных программах. А это через что реализовать?

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

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

А если про режим с токенами в сервере — то это техническое решение мы только проектируем.

Добрый день.

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

Доступ к токену осуществляется по конкретному протоколу, который не является большим секретом. По сути, если у нарушителя есть задача “распродать всю фирму”, ничто не мешаеn ему написать на коленке свой простой клиент, который будет делать те же вызовы, что и CSP.

Очень похоже, что вы пытаетесь решить свою задачу немного не тем средством. Если вам нужен механизм, в котором будет гарантированное подтверждение подписи конкретным человеком, а доступ к ключу при этом будет журналироваться и может быть в теории организован с удаленных систем, рассмотрите “КриптоПро DSS”: http://dss.cryptopro.ru/

С уважением,
Сергей Агафьин,
Начальник отдела разработки ФКН.
Техническую поддержку оказываем здесь.
Наша база знаний.

оставлено 18.01.2022(UTC)

Добрый день. Подскажите, статья в базе знаний [КриптоПро CSP c доступом к локальным смарт-картам по RDP],
там есть фраза

а как создать эту группу????? Какие права выдавать? Выдававать “локального администратора” вообще не хочется.

ЗЫ Проброс физических ключей на сервера отлично решается через [USB Redirector], тем более, что существует и прекрасно работает как для Win, так и для *nix систем.

Группу создавать стандартными средствами ОС:
Control Panel > Administrative Tools > Computer Management. Navigate to Local Users and Groups under Computer Management on the left panel. Click on Groups. Right-click on the middle panel and click on New Group… when the right-click menu appears.
Или net localgroup

Спасибо за развернутый ответ, можете уточнить, вы группу “ловите” только по названию?

Хочу заметить что сдача отчетности на разных площадках и в разных программах ведется от имени директора. Половина известных мне порталов .. тоже директор. Подписант на торговые площадки .. тоже директор. И вообще у нас в России только директор имеет право подписывать документы от лица фирмы. Поэтому директор должен решать кому и где дать подпись, а кому запретить.

В идеале директор должен сам подписывать. Еще вариант – завести заместителя. Не понимаю – на бумаге значит сам подписывает, а электронно подписать “не начальническое дело”?

Если уж доверяет кому-то право подписи, то это и документально должно быть оформлено. Ничего не мешает на половине порталов (в том числе для отчетности Контур-Экстерне, приемки на госзакупках и торговых площадках) назначить ответственным другого и сделать на него отдельную подпись. Много случаев, где обязателен руководитель только для первого входа. Однако настроив первый вход перенастраивать уже часто становится лень. Из настаивающих на руководителе могу назвать только Росреестр (но там можно еще заместителя) и ФНС (с ними кое-где проходит и сертификат без ФИО, лишь бы был ОГРН).

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

Разве этим, всем перечисленным, должно заниматься СКЗИ?

Этим занимается прикладное программное обеспечение, например, вышесказанное реализовано в различных СЭДО, например, в том же “СБИС-онлайн”.

Ну может и не само СКЗИ, а, например, плагины.
Заметьте, что про подписание документов по удаленной схеме я не особо идею поддерживаю – директор может и прогуляться к рабочему месту, скажем, бухгалтера. Не так много документов в день подписывается у малой или средней организации, а крупные наверняка назначат ответственных на каждый участок. Другое дело вход на порталы, с ними реально не набегаешься, некоторые выкидывают минут через 15. С порталами, возможно как раз бы пригодилось на уровне плагина.

Подскажите мне – ведь в теории плагин и расширение браузера не обязательно должны быть на одном компьютере? Если бы можно было, скажем, установить соединение расширения с плагином на другом компьютере, на стороне плагина – отображение подписываемых данных и подтверждение (и сам контейнер там же), это было бы весьма интересное решение. Хотя… это уже на 90% смахивает на токен в активном режиме с кнопкой.

Отредактировано пользователем 21 января 2022 г. 8:12:50(UTC)
 | Причина: Не указана

Именно так и работает функционал вышеупомянутого Мною СБИС’а.

На одном из АРМ плагин и носитель подписи – пусть будет АРМ начальника, все настройки в системе СБИС – например, отложенная подпись по доверенности, а отправлять документы на подпись можно с любого АРМ с доступом к сети “Интернет”.

я рад что в вашем мире пони какают радугой. а в моем мире 13 .. и еще 4 на согласовании разнородных платформ для подписи. часть из них прикрываются “вы должны купить наш ключ для подписи в футляре от порше иначе вы не сможете тут ничего сделать”. на опрос почему мы это так должны .. получаем ответ “что так есть гарантия что подписывает только тот у кого есть физический ключ”. и сбис с порталами это еще цветочки. самописные программы от госорганов, банки, торговые площадки … мы уже в год вываливаем больше 100 тысяч за весь этот разовый шлак.

Для того чтоб четко понимать что было не сделано в сбисе
– отсутствует считыватель “сетевое хранилище с запросом на подпись”
– отсутствует протокол передачи данных к этому хранилищу
– отсуствует гуи надстройка для подписанта в сети у которого и находится сетевое хранилище на компьютере … о Боже! да тут любой студент такое за неделю накатает.

Особенно за 100 тысяч. Вперед!

Т.е. Вам хочется видеть универсальный софт для “удалённой”/ многопользовательской работы со СКЗИ с которым умели бы работать все возможные программы/ системы?

Возможно такое и можно реализовать, только если это будет гос.заказ.

А что это тут у людей начинает подгорать?) Вроде должны радоваться что идея нужная. Все начать требовать чтоб ее реализовали. Это ж какая экноомия и удобство по работе с ключами у пользователя. Ан нет … бомбит люд. Причину бомбежа услышать можно?)

sad-cat-1.png (148kb) загружен 5 раз(а).