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

Уведомление

Icon
Error

3 Страницы123>
Опции
К последнему сообщению К первому непрочитанному
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)
Сообщений: 979
Российская Федерация

Сказал(а) «Спасибо»: 77 раз
Поблагодарили: 206 раз в 200 постах
Добрый день!
насколько я понял, у вас имеется некая подмена понятий.
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)
Сообщений: 979
Российская Федерация

Сказал(а) «Спасибо»: 77 раз
Поблагодарили: 206 раз в 200 постах
Автор: Андрей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)
Сообщений: 11,607
Мужчина
Российская Федерация

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

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

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

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

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

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

Сказал(а) «Спасибо»: 77 раз
Поблагодарили: 206 раз в 200 постах
при использовании 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)
Сообщений: 28

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

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

"Вся это деятельность настроена на то, чтобы загрузить ключи УКЭП пользователей, полученные на стороне, в HSM с целью избавить пользователей от необходимости вставлять ключевые носители при подписании потока документов"
Подключение к HSM осуществляется с двухсторонней аутентификацией, т.е. пользователям нужно будет иметь индивидуальный ключ доступа на каком-нибудь ключевом носителе...
Техническую поддержку оказываем тут.
Наша база знаний.
Наша страничка в Instagram.
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)  | Причина: Не указана

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