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

Отредактировано пользователем 25 сентября 2019 г. 10:42:23(UTC)  | Причина: Не указана

1. пример с помощью cryptcp можно посмотреть здесь

2. установка описано в указанной статье.

3. примерно так csptest.exe -keycopy -provsrc "Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider" -provdest "Crypto-Pro GOST R 34.10-2012 HSM Svc CSP" -typesrc 80 -typedest 80 -contsrc "\\.\FAT12_D\test1" -contdest "\\.\HSMDB\test2 -pinsrc 111 -pindest 11111111

уточните какая ваша конечная цель?
хсм обычно используется в следующих схемах:
hsm - service (CA, DSS, JCSP, ...) - user
hsm - service (т.е. сервис явлется конечным клиентом)

схемы hsm - user нет.

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

Обмен выполняется по https.
Подразумеваете MITM?

При аутентификации по клиентскому сертификату - необходим доступ к закрытому ключу (как и при подписании\расшифровании данных).

У Вас же не возникло вопроса, если сертификат публичен - то, "значит и подписывать им сможет любой".

Здравствуйте.
Мне все-таки не понятно. Читаю документацию "ЖТЯИ.00096-01 93 01 Руководство пользователя" где говорится, что ключи подписи создаются на самом HSM и ничего не говорится о том, что туда эти ключи, сгенерированные к примеру в стороннем аккредитованном УЦ, можно загрузить используя HSM Client. В документе говорится только про возможность загрузки ключа и сертификата доступа.
В этой связи прошу все-же подсказать, разрешено ли загружать ключи квалифицрованной электронной подписи пользователя в HSM через HSM Client и не является ли такая загрузка нештатной процедурой, которая ведет к понижению уровня защиты HSM и самого ключа подписи. Не могли бы подсказать, где такое регламентировано.


На сколько я понимаю, даже если такое и можно осуществить, то это является копированием ключа, что в соответствии с требованиями многих аккредитованных УЦ является недопустимым. Или это нельзя назвать копированием?

Вся это деятельность настроена на то, чтобы загрузить ключи УКЭП пользователей, полученные на стороне, в HSM с целью избавить пользователей от необходимости вставлять ключевые носители при подписании потока документов

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

Здравствуйте. Спасибо за ответ.
1. Правильно ли я понимаю, что если в эксплуатационной документации не описана возможность загрузки ключей электронной подписи в HSM, и везде говорится, что ключ должен создаваться непосредственно в HSM, то попытки записать ключ ЭП с токена на HSM через ПО HSM Client являются по сути использованием HSM в непредусмотренных разработчиком режиме.

2. Созданный ключ ЭП в HSM зашифровывается на ключах шифрования и мастер ключе. Правомерно ли то же самое для ключей закруженных в HSM? То есть статус и степень защиты загруженного и созданного ключа в HSM идентичны?

3. "юридической стороны будет несоответствие расширения сертификата средства ЭП владельца, в котором указывается наименование СКЗИ, т.е. при использовании HSM нужно указывать это в расширении" - то есть ключевая пара созданная в HSM и ключевая пара созданная на токене отличаются какими-то параметрами (например расширенными областями использования)?

4.Не могли бы пояснить, что означают функции:
TYPE_LOAD_GAMMA - загрузка ключевого материала уполномоченной организации - что понимается под загрузкой ключевого материала? Это случайно не материал передаваемый удостоверяющим центром, необходимый для создания в HSM запросов на выдачу СКП ЭП с полями, которые может одобрить УЦ?
TYPE_CRYPT_IMPORT_KEY - импорт секретного ключа в контейнер ПАКМ - тут имеется ввиду предусмотренная возможность загрузки ключа ЭП или это идет речь только про ключи доступа пользователя к HSM?

5. В видео-презентации про DSS на сайте КриптоПро, на одном слайде указано, что способы построения взаимодействия и аутентификации при использовании УКЭП и УНЭП различаются. То есть если используется УКЭП, то к примеру нельзя использовать OTP-токены и т д, а нужно использовать myDSS или к примеру апплет на сим-карте. Эти требования еще актуальны? Они вызваны отсутствием ГОСТ алгоритмов на некоторых предлагаемых способах взаимодействия с клиентской частью или чем-то иным? Не является ли по аналогии загрузка ключа УКЭП в HSM, что является недекларированным способом, тоже запрещенным способом для УКЭП?

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