Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

2 Страницы12>
Опции
К последнему сообщению К первому непрочитанному
Offline Андрей2100  
#1 Оставлено : 19 сентября 2019 г. 15:24:48(UTC)
Андрей2100

Статус: Участник

Группы: Участники
Зарегистрирован: 19.09.2019(UTC)
Сообщений: 14
Российская Федерация
Откуда: Москва

Здравствуйте. Подскажите пожалуйста следующее.
1. Можно ли чистый HSM (без дополнительного ПО в виде DSS и прочих прикладных ПО) использовать администратором HSM чтобы создавать там ключи пользователей, которые будут использоваться для формирования ЭП. Не будут ли такие ключи сразу скомпрометированы администратором при создании?
2. Возможно ли в стороннем аккредитованном удостоверяющем центре получить сертификаты созданные в HSM, который расположен в организации не являющейся УЦ? Или такая процедура невозможна?
3. В документации на HSM написано, что для работы с HSM у пользователя необходимо установить HSM Client. Но для доступа клиенту к HSM через HSM Client, как я понял, нужен ключ на смарт карте. Получается, если я хочу уйти от хранения ключей пользователей на носителях путем генерации этих ключей в HSM, то все равно не смогу уйти от хранения у пользователей смарт-карт?
4. Возможно ли загрузить в HSM ключи пользователей, полученные на отчуждаемых носителях (токенах) в аккредитованном УЦ, и чтобы такая процедура не привела к компрометации этих ключей? Иными словами ключи полностью создаются в аккредитованном УЦ, а потом владельцем загружаются в HSM через свою точку доступа, при этом ключи на отчуждаемом носителе уничтожаются после загрузки в HSM.
Offline Санчир Момолдаев  
#2 Оставлено : 25 сентября 2019 г. 10:40:35(UTC)
Санчир Момолдаев

Статус: Сотрудник

Группы: Модератор, Участники
Зарегистрирован: 03.12.2018(UTC)
Сообщений: 808
Российская Федерация

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

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

Техническую поддержку оказываем тут
Наша база знаний
Offline Андрей2100  
#3 Оставлено : 1 октября 2019 г. 0:01:18(UTC)
Андрей2100

Статус: Участник

Группы: Участники
Зарегистрирован: 19.09.2019(UTC)
Сообщений: 14
Российская Федерация
Откуда: Москва

Здравствуйте! Прошу сильно не ругаться за возможно глупые вопросы.

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

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

загрузить контейнеры из других носителей в HSM возможно - А не могли бы пояснить как это делается? В соответствии с 63-ФЗ пользователь должен обеспечивать конфиденциальность своих ключей, значит ключ должен загрузить сам пользователь. Как он это может сделать, если по сути доступ этого пользователя непосредственно к HSM должен быть ограничен.

Offline Санчир Момолдаев  
#4 Оставлено : 1 октября 2019 г. 0:24:18(UTC)
Санчир Момолдаев

Статус: Сотрудник

Группы: Модератор, Участники
Зарегистрирован: 03.12.2018(UTC)
Сообщений: 808
Российская Федерация

Сказал(а) «Спасибо»: 70 раз
Поблагодарили: 165 раз в 161 постах
Автор: Андрей2100 Перейти к цитате
Здравствуйте! Прошу сильно не ругаться за возможно глупые вопросы.

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

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

3. загрузить контейнеры из других носителей в HSM возможно - А не могли бы пояснить как это делается? В соответствии с 63-ФЗ пользователь должен обеспечивать конфиденциальность своих ключей, значит ключ должен загрузить сам пользователь. Как он это может сделать, если по сути доступ этого пользователя непосредственно к HSM должен быть ограничен.



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 нет.
Техническую поддержку оказываем тут
Наша база знаний
thanks 1 пользователь поблагодарил Санчир Момолдаев за этот пост.
Андрей * оставлено 01.10.2019(UTC)
Offline Андрей2100  
#5 Оставлено : 1 октября 2019 г. 21:46:47(UTC)
Андрей2100

Статус: Участник

Группы: Участники
Зарегистрирован: 19.09.2019(UTC)
Сообщений: 14
Российская Федерация
Откуда: Москва

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

Раз уж зашел к вам, то прошу подсказать еще пару моментов связанных непосредственно с DSS. Вопрос такой. Когда клиент подписывает документ с использованием ключа ЭП на своем отчуждаемом носителе, то подписание происходит непосредственно на его машине с использованием СКЗИ КриптоПро. После этого, документ направляется к примеру в ДБО по закрытому каналу и этот документ уже содержит подпись клиента, что обеспечивает авторство и целостность. Но когда мы говорим про DSS, то клиент инициируя подписание отправляет документ или его хэш на сторону DSS, то есть в этот отрезок пути от клиента до DSS сам документ или хэш не защищен. Теоретически его можно исказить или подменить?

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

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

Offline Андрей Писарев  
#6 Оставлено : 1 октября 2019 г. 22:20:43(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 10,663
Мужчина
Российская Федерация

Сказал «Спасибо»: 393 раз
Поблагодарили: 1611 раз в 1238 постах
Здравствуйте.

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

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

У Вас же не возникло вопроса, если сертификат публичен - то, "значит и подписывать им сможет любой".
Техническую поддержку оказываем тут
Наша база знаний
Offline Санчир Момолдаев  
#7 Оставлено : 3 октября 2019 г. 9:14:38(UTC)
Санчир Момолдаев

Статус: Сотрудник

Группы: Модератор, Участники
Зарегистрирован: 03.12.2018(UTC)
Сообщений: 808
Российская Федерация

Сказал(а) «Спасибо»: 70 раз
Поблагодарили: 165 раз в 161 постах
при использовании tls трафик шифруется, при использовании двухстороннего tls, трафик тоже шифруется, просто клиент аутентифицирует себя с помощью приватного закрытого ключа.
после подписания на сервере dss, подпись можно проверить.

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

на DSS можно комбинировать и настраивать, на какие операции нужна двухфакторная аутентификация. в зависимости от настроек это делает или сам пользователь или оператор.
Техническую поддержку оказываем тут
Наша база знаний
Offline Андрей2100  
#8 Оставлено : 16 октября 2019 г. 14:53:18(UTC)
Андрей2100

Статус: Участник

Группы: Участники
Зарегистрирован: 19.09.2019(UTC)
Сообщений: 14
Российская Федерация
Откуда: Москва

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


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

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

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

Offline Константин Гаинцев  
#9 Оставлено : 16 октября 2019 г. 15:49:37(UTC)
Константин Гаинцев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 17.01.2014(UTC)
Сообщений: 26

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 6 раз в 6 постах
Добрый день!
Загрузка ключа КЭП в HSM является ничем иным, как копированием и возможно только если ключ был помечен как экспортируемый при создании. С юридической стороны будет несоответствие расширения сертификата средства ЭП владельца, в котором указывается наименование СКЗИ, т.е. при использовании HSM нужно указывать это в расширении.

"На сколько я понимаю, даже если такое и можно осуществить, то это является копированием ключа, что в соответствии с требованиями многих аккредитованных УЦ является недопустимым"
В идеале ключ должен сразу генерироваться на HSM, при создании запроса. Запрос передаётся в УЦ, по которому выдают сертификат с правильным расширением средств ЭП.

"Вся это деятельность настроена на то, чтобы загрузить ключи УКЭП пользователей, полученные на стороне, в HSM с целью избавить пользователей от необходимости вставлять ключевые носители при подписании потока документов"
Подключение к HSM осуществляется с двухсторонней аутентификацией, т.е. пользователям нужно будет иметь индивидуальный ключ доступа на каком-нибудь ключевом носителе...
Offline Андрей2100  
#10 Оставлено : 17 октября 2019 г. 10:37:31(UTC)
Андрей2100

Статус: Участник

Группы: Участники
Зарегистрирован: 19.09.2019(UTC)
Сообщений: 14
Российская Федерация
Откуда: Москва

Здравствуйте. Спасибо за ответ.
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)  | Причина: Не указана

Offline Константин Гаинцев  
#11 Оставлено : 17 октября 2019 г. 14:21:21(UTC)
Константин Гаинцев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 17.01.2014(UTC)
Сообщений: 26

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 6 раз в 6 постах
1. Запись ключа ЭП на HSM предусмотрена разработчиками, что обусловлено сроками действия закрытых ключей - экспортируемые ключи созданные на HSM или загруженные на него имеют срок действия 1 год и 3 месяца. Т.е. технически записать ключ на HSM можно, если он экспортируемый, но юридически квалифицированную ЭП копировать в HSM не стоит.

2. С точки зрения защиты - ключ сделанный на HSM скомпрометировать сложнее, чем ключ созданный на каком-нибудь носителе и загруженном в ПАКМ. У импортированного ключа будет такой же статус, как и у экспортируемого ключа сделанного в HSM, определяющий срок его действия.

3. Нет, закрытые ключи принципиально ни чем не отличаются, отличие заключается в расширении сертификатов.

4. Ключевой материал - это случайная бинарная последовательность, которая расходуется на создание любого ключа. Т.е. на HSM можно создать ограниченное количество ключей, для дальнейшего использования необходимо производить загрузку гаммы. Штатного способа загрузки гаммы не существует, загрузка производится исключительно сотрудниками Крипто Про в рамках сервисного обслуживания.
Импорт секретного ключа в контейнер ПАКМ - копирование ключа с внешнего носителя в HSM, но с точки зрения типа события журнала аудита TYPE_CRYPT_IMPORT_KEY - пишет в журнал при импорте с карты, через LCD панель, при входе в меню под привилегированным пользователем "Администратор HSM". Этот функционал устаревший и сценариев его использования сейчас практически нету.

5. Актуальные. При сертификации DSS ФСБ определило перечень методов аутентификации, которые можно использовать в том числе для УКЭП. Аналогий в использовании DSS и загрузкой ключа УКЭП в HSM - не вижу.
Offline Андрей2100  
#12 Оставлено : 18 октября 2019 г. 12:32:23(UTC)
Андрей2100

Статус: Участник

Группы: Участники
Зарегистрирован: 19.09.2019(UTC)
Сообщений: 14
Российская Федерация
Откуда: Москва

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

2. Нет, закрытые ключи принципиально ни чем не отличаются, отличие заключается в расширении сертификатов.- Я так понимаю нет какого-то требования запрещающего на HSM использовать ключи, чьи сертификаты не содержат необходимых расширений в сертификате? Или там технические нюансы?

3. Почему все-же в документации на HSM отсутствует описание возможности загрузки ключа ЭП с носителя? Если подходить к вопросу с юридической точки зрения, то скажем ПКЗ-2005 указывает "46. СКЗИ эксплуатируются в соответствии с правилами пользования ими". То есть если что-то не указано в документации, то вроде как и использовать такое нельзя.
Offline Константин Гаинцев  
#13 Оставлено : 18 октября 2019 г. 17:54:40(UTC)
Константин Гаинцев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 17.01.2014(UTC)
Сообщений: 26

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 6 раз в 6 постах
1. В соответствии с требованиями к полям квалифицированного сертификата, в нём должно быть поле "Средства ЭП владельца" в которое записывается используемое владельцем СКЗИ. И если в этом поле указано Крипто Про CSP, то эта ЭП должна использоваться с Крипто Про CSP. Также, на мой взгляд, идея избавить сотрудников от использования ключевых носителей, путём переноса ключей в HSM не имеет смысла, т.к. для подключения к HSM будет нужен ключ доступа созданный на HSM, который также нужно будет менять каждый год. А если рассматривать, что все ключи будут копироваться под одним пользователем, на каком-нибудь сервере, к которому сотрудники будут подключаться для создания подписи, то встаёт вопрос безопасности личных ключей, т.к. каждому подключившемуся будут видны все ключи других сотрудников с возможностью подобрать к ним пароли.

2. Да, таких требований нет. Если ЭП не квалифицированная, то можете копировать и использовать на HSM.

3. В документации ЖТЯИ.00096-01 90 01 КриптоПро HSM. Инструкция по использованию, пункт 11.2.10. Управление пользователями есть описание импорта ключа в HSM через LCD панель, как я писал ранее - сценариев использования данного функционала практически нет.
Offline Андрей2100  
#14 Оставлено : 21 октября 2019 г. 10:10:14(UTC)
Андрей2100

Статус: Участник

Группы: Участники
Зарегистрирован: 19.09.2019(UTC)
Сообщений: 14
Российская Федерация
Откуда: Москва

Константин, спасибо.
Ознакомился с документом ЖТЯИ.00096-01 90 01 КриптоПро HSM. Инструкция по использованию, пункт 11.2.10.
В документе действительно указано о возможности загрузки ключа, но при этом там написано "Для этого необходимо, чтобы сохраняемый ключ подписи хранился на смарт карте" - Судя по всему обязательным условием является наличие ключа именно на смарт карте.
Offline Андрей2100  
#15 Оставлено : 29 октября 2019 г. 9:56:42(UTC)
Андрей2100

Статус: Участник

Группы: Участники
Зарегистрирован: 19.09.2019(UTC)
Сообщений: 14
Российская Федерация
Откуда: Москва

Здравствуйте. В документации Общее описание DSS в разделе про способы аутентификации указан способ про аутентификацию по сертификату.
4.2.4.2.4.2.4.2. Аутентификация по сертификату
Данный метод требует установки защищенного TLS-соединения с двусторонней аутентификацией (просмотр и подтверждение операции с загруженным на сервер документом производятся в рамках взаимодействия по защищенному каналу). Аутентификация производится с использованием пары ключей, закрытая часть которой хранится у Пользователя, а сертификат открытого ключа должен быть доверенным для СЭП.

Тут под хранением закрытого ключа у Пользователя имеется ввиду непосредственное хранение у пользователя (на носителе) или под хранением имеется ввиду хранение в HSM/DSS, со знанием пользователем пин-кода от этого контейнера?
Если на имеется в виду хранение на носителе, то подразумевается DSSlite? В противном случае не понимаю смысла использования DSS если ключ пользователя находится у пользователя.

Offline Александр Лавник  
#16 Оставлено : 29 октября 2019 г. 10:11:04(UTC)
Александр Лавник

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 30.06.2016(UTC)
Сообщений: 2,677
Мужчина
Российская Федерация

Сказал «Спасибо»: 44 раз
Поблагодарили: 602 раз в 567 постах
Автор: Андрей2100 Перейти к цитате
Здравствуйте. В документации Общее описание DSS в разделе про способы аутентификации указан способ про аутентификацию по сертификату.
4.2.4.2.4.2.4.2. Аутентификация по сертификату
Данный метод требует установки защищенного TLS-соединения с двусторонней аутентификацией (просмотр и подтверждение операции с загруженным на сервер документом производятся в рамках взаимодействия по защищенному каналу). Аутентификация производится с использованием пары ключей, закрытая часть которой хранится у Пользователя, а сертификат открытого ключа должен быть доверенным для СЭП.

Тут под хранением закрытого ключа у Пользователя имеется ввиду непосредственное хранение у пользователя (на носителе) или под хранением имеется ввиду хранение в HSM/DSS, со знанием пользователем пин-кода от этого контейнера?
Если на имеется в виду хранение на носителе, то подразумевается DSSlite? В противном случае не понимаю смысла использования DSS если ключ пользователя находится у пользователя.


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

1) Имеется ввиду хранение ключа у пользователя (в реестре, на жестком диске, на внешнем носителе).

Этот ключ (и соответствующий сертификат) в данном случае необходим для доступа к КриптоПро DSS.

Ключи (и соответствующие сертификаты) для использования в web-интерфейсе КриптоПро DSS находятся в HSM/DSS.

2) DSSLite предполагает, что ключи пользователя, которые он использует в web-интерфейсе КриптоПро DSS, хранятся у пользователя.
Техническую поддержку оказываем тут
Наша база знаний
Offline Андрей2100  
#17 Оставлено : 29 октября 2019 г. 16:56:18(UTC)
Андрей2100

Статус: Участник

Группы: Участники
Зарегистрирован: 19.09.2019(UTC)
Сообщений: 14
Российская Федерация
Откуда: Москва

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

1) Имеется ввиду хранение ключа у пользователя (в реестре, на жестком диске, на внешнем носителе).

Этот ключ (и соответствующий сертификат) в данном случае необходим для доступа к КриптоПро DSS. - То есть имеется ввиду ключ аутентификации? (некий криптографический ключ используемый только для доступа к веб-сервису DSS, отличный от ключа электронной подписи, хранящийся в HSM). Я верно понял?



Offline Александр Лавник  
#18 Оставлено : 29 октября 2019 г. 17:00:02(UTC)
Александр Лавник

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 30.06.2016(UTC)
Сообщений: 2,677
Мужчина
Российская Федерация

Сказал «Спасибо»: 44 раз
Поблагодарили: 602 раз в 567 постах
Автор: Андрей2100 Перейти к цитате
Здравствуйте.

1) Имеется ввиду хранение ключа у пользователя (в реестре, на жестком диске, на внешнем носителе).

Этот ключ (и соответствующий сертификат) в данном случае необходим для доступа к КриптоПро DSS. - То есть имеется ввиду ключ аутентификации? (некий криптографический ключ используемый только для доступа к веб-сервису DSS, отличный от ключа электронной подписи, хранящийся в HSM). Я верно понял?




Да, совершенно верно.
Техническую поддержку оказываем тут
Наша база знаний
Offline Андрей2100  
#19 Оставлено : 13 ноября 2019 г. 16:33:25(UTC)
Андрей2100

Статус: Участник

Группы: Участники
Зарегистрирован: 19.09.2019(UTC)
Сообщений: 14
Российская Федерация
Откуда: Москва

Здравствуйте.
Подскажите пожалуйста еще один момент.

В качестве сертифицированного решения, для применения УКЭП можно использовать клиенту один лишь myDSS или обязательно также наличие веб-интерфейса (ЛК) DSS либо доступа к личному кабинету автоматизированной системы которую подружили с DSS посредством API?

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

Offline Александр Лавник  
#20 Оставлено : 13 ноября 2019 г. 17:05:09(UTC)
Александр Лавник

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 30.06.2016(UTC)
Сообщений: 2,677
Мужчина
Российская Федерация

Сказал «Спасибо»: 44 раз
Поблагодарили: 602 раз в 567 постах
Автор: Андрей2100 Перейти к цитате
Здравствуйте.
Подскажите пожалуйста еще один момент.

В качестве сертифицированного решения, для применения УКЭП можно использовать клиенту один лишь myDSS или обязательно также наличие веб-интерфейса (ЛК) DSS либо доступа к личному кабинету автоматизированной системы которую подружили с DSS посредством API?

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

Требования по наличию web-интерфейса пользователя нет.

Вот этот сертификат соответствует использованию в качестве средства вторичной аутентификации (и подтверждения операций) приложения myDSS.

Следует учитывать, что myDSS не используется для подписи документов.

То есть в любом случае необходимо использовать некоторое приложение для подписи, например, с использованием облачного токена в КриптоПро CSP 5.0.
Техническую поддержку оказываем тут
Наша база знаний
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
2 Страницы12>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.