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

Уведомление

Icon
Error

5 Страницы<12345>
Опции
К последнему сообщению К первому непрочитанному
Offline two_oceans  
#21 Оставлено : 27 июля 2020 г. 8:53:15(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Действительно интересная ссылка, хотя тут наверно не совсем правильное место для обсуждения. По предлагаемым решениям: идентификация

государственные УЦ

ограничения и т.д.
Offline Агафьин Сергей  
#22 Оставлено : 27 июля 2020 г. 11:56:24(UTC)
Grey

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

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

Сказал «Спасибо»: 5 раз
Поблагодарили: 215 раз в 174 постах
Цитата:
Но по вашим словам КриптоПро не использует PKCS11? С моей точки зрения, получается какое-то логическое противоречие между вашими словами и поддержкой Диадок?

Там же прямо написано в сообщении, зачем нужен CSP. У людей просто в плагине есть явная зависимость от CSP, который используется для поддержки JaCarta. Видимо, без разрешения этой зависимости он не стартует.

Цитата:
то в каком формате должны быть ключи, чтобы они были совместимы одновременно с Диадок, с КриптоПро 4/5, с аппаратным крипто Рутокен ЭЦП 2.0, с PKCS11 и APDU? Такое вообще возможно?

Протокол PKCS11 вообще подразумевает какой-то свой некий формат хранения закрытых ключей?

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

Сначала чуть подробнее опишу то, чем является PKCS#11 и где тут CSP.
PKCS#11 - это интерфейс, а не протокол. Он призван унифицировать работу с криптографическими устройствами или провайдерами. Вашему прикладному софту может быть не интересно, где именно выполняется функция "подписать": на токене, на HSM или вообще в тестовом приложении, написанном junior-ом. Если разработчик СКЗИ хочет, чтобы прикладной софт, использующий PKCS#11 (чаще всего уже написанный!), работал и с ними, то он создает библиотеку, которая реализует этот интерфейс каким-то ей одной известным образом.
Выглядит логика работы так:
софт -> [PKCS#11-интерфейс] -> pkcs11-библиотека (например, pkcs11rutoken.dll. - я не помню настоящее название) -> [APDU-интерфейс] -> токен.

Мы же в CSP работаем напрямую с APDU. Во многом это связано с ограничениями PKCS#11, да и с тем, что наша поддержка неизвлекаемых ключей появилась до развития этих библиотек.

софт -> [CryptoAPI] -> КриптоПро CSP -> модуль поддержки токена (rutoken.dll) -> [APDU-интерфейс] -> токен.

Если человек хочет использовать PKCS#11 и наш CSP: например для того, чтобы можно было работать через тот самый единый PKCS#11-интерфейс с ключами на всех считывателях, поддерживаемых CSP: реестр, таблетки, пассивные носители, ФКН, то можно взять нашу реализацию PKCS#11 - cppkcs11.dll:

софт -> [PKCS#11-интерфейс] -> cppkcs11.dll -> [CryptoAPI] -> КриптоПро CSP -> модули поддержки

Теперь к вашему вопросу про работу с ключами на Рутокен ЭЦП 2.0.
Как видите из моих пояснений, в итоге при работе с токеном всё равно всё сводится к APDU. Если бы CSP знал команды, которые используются pkcs#11-библиотекой Рутокен, он мог бы использовать ключи, которые через неё созданы. Для CSP 5.0 мы как раз этому и научили провайдер. Если кто-то создал через любой софт, использующий pkcs11-библиотеку, ключ на Рутокен ЭЦП 2.0, CSP этот ключ увидит и сможет использовать. Речь только об этом конкретном токене! Для других производителей формата APDU, используемых pkcs11-библиотеками, у нас нет, но призрачные планы поддержать pkcs11-ключи мы от случая к случаю обсуждаем и с Аладдином и с Мультисофтом. Пока это не интересно производителям токенов, мы реализовать ничего не можем.

Есть два ограничения:
1) Для ключа должен быть сертификат. Ограничение искусственное, но неизбежное: мы должны знать про ключ много служебной информации, которая недоступна просто так.
2) Ключи нельзя создавать. По тем же причинам, что и в п.1 требуется сертификат. CSP работает в рамках интерфейса CryptoAPI, который имеет функцию генерации ключа, но не имеет функции "создать сертификат", поэтому было бы странно давать возможность генерацию ключа, а потом из-за требований п.1 запрещать с ним работать.

Отредактировано пользователем 27 июля 2020 г. 12:19:00(UTC)  | Причина: Не указана

С уважением,
Сергей
Техническую поддержку оказываем здесь.
Наша база знаний.
thanks 2 пользователей поблагодарили Grey за этот пост.
sanyo оставлено 27.07.2020(UTC), Андрей * оставлено 27.07.2020(UTC)
Offline Агафьин Сергей  
#23 Оставлено : 27 июля 2020 г. 12:05:27(UTC)
Grey

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

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

Сказал «Спасибо»: 5 раз
Поблагодарили: 215 раз в 174 постах
Цитата:
Зачем тогда вообще нужен формат неизвлекаемых ключей КриптоПро 5?
Для неизвлекаемых ключей в формате КриптоПро 5 вообще сертификаты выпускает хоть один УЦ?

На данный момент сертифицированного УЦ с CSP 5.0 еще нет, так что если кто и выпускает, то только для усиленной неквалифицированной подписи.
С уважением,
Сергей
Техническую поддержку оказываем здесь.
Наша база знаний.
thanks 1 пользователь поблагодарил Grey за этот пост.
sanyo оставлено 27.07.2020(UTC)
Offline Агафьин Сергей  
#24 Оставлено : 27 июля 2020 г. 12:13:23(UTC)
Grey

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

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

Сказал «Спасибо»: 5 раз
Поблагодарили: 215 раз в 174 постах
Цитата:
Ключ в формате совместимости Rutoken S на смарткарте Rutoken MIK51.
Подключить его через SoftTouch PRO к КриптоАРМ стандарт.

Кнопка авторизации SoftTouch PRO будет работать для извлекаемого ключа в формате совместимости Rutoken S?

Суть SafeTouch в том, что он анализирует APDU-команды и ищет команду подписи. Если подписывается известный устройству хэш, то подпись пропускается, если нет - выводится запрос "вы уверены?". Проблема в том, что у Рутокен S нет никакой функции подписи. Соответственно, вы можете, конечно, использовать с ним SafeTouch. Если ему правильно "скармливать" данные, то он будет показывать документы и спрашивать "хотите подписать?", но если данные не "скармливать", то никакого запрета на исполнение не произойдет, так что толку с точки зрения безопасности ноль.

Цитата:
Можно ли настроить КриптоПро CSP, чтобы он не кэшировал такой ключ в оперативке, а каждый раз подгружал его с токена, чтобы нужно было нажатие кнопки авторизации на считывателе SoftTouch PRO?

1) SafeTouch не умеет перехватывать команду чтения ключей.
2) В следующей релизной сборке КриптоПро CSP 5.0 R2 появятся расширенные возможности по контролю операции подписи на пассивных ключах. Следите за новостями :)
С уважением,
Сергей
Техническую поддержку оказываем здесь.
Наша база знаний.
thanks 1 пользователь поблагодарил Grey за этот пост.
sanyo оставлено 27.07.2020(UTC)
Offline sanyo  
#25 Оставлено : 27 июля 2020 г. 12:20:09(UTC)
sanyo

Статус: Активный участник

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

Сказал(а) «Спасибо»: 11 раз
Автор: Агафьин Сергей Перейти к цитате

Теперь к вашему вопросу про работу с ключами на Рутокен ЭЦП 2.0.
Как видите из моих пояснений, в итоге при работе с токеном всё равно всё сводится к APDU. Если бы CSP знал команды, которые используются pkcs#11-библиотекой Рутокен, он мог бы использовать ключи, которые через неё созданы. Для CSP 5.0 мы как раз этому и научили провайдер. Если кто-то создал через любой софт, использующий pkcs11-библиотеку, ключ на Рутокен ЭЦП 2.0, CSP этот ключ увидит и сможет использовать. Речь только об этом конкретном токене! Для других производителей формата APDU, используемых pkcs11-библиотеками, у нас нет, но призрачные планы поддержать pkcs11-ключи мы от случая к случаю обсуждаем и с Аладдином и с Мультисофтом. Пока это не интересно производителям токенов, мы реализовать ничего не можем.

Есть два ограничения:
1) Для ключа должен быть сертификат. Ограничение искусственное, но неизбежное: мы должны знать про ключ много служебной информации, которая недоступна просто так.
2) Ключи нельзя создавать. По тем же причинам, что и в п.1 требуется сертификат. CSP работает в рамках интерфейса CryptoAPI, который имеет функцию генерации ключа, но не имеет функции "создать сертификат", поэтому было бы странно давать возможность генерацию ключа, а потом из-за требований п.1 запрещать с ним работать.


Сергей, огромное спасибо за ваши объяснения принципов работы КриптоПРО.

В пункте 2) имеется ввиду, что нельзя создавать ключи сверх одного ключа, который создан при содействии УЦ и для которого получен сертификат в УЦ?
Т.е. все же один ключ с сертификатом создать можно?

Под Linux это работает?

В поддержке Аладдин мне недавно сообщили, что Infotecs CSP видит ключи, созданные в формате PKCS 11.
То, что вы писали про Рутокен ЭЦП 2.0 работает аналогично именно для этого носителя с точки зрения пользователя, не вдаваясь в технические подробности?

Сможет КриптоАРМ Стандарт (не плюс) работать с неизвлекаемым ключом, не догадываясь о том, что он неизвлекаемый, и что ваш CSP будет работать с ключом через PKCS11?
Т.е. КриптоАРМ Стандарт (не плюс) будет казаться, что он работает с извлекаемым ключом, а на самом деле с неизвлекаемым? Так возможно?

Знаю, что есть другая редакция КриптоАРМ Плюс, рассчитанная на работу именно с ключами PKCS 11, но мне интересно попытаться добиться работы КриптоАРМ Стандарт (не плюс) с ключами PKCS 11 неявно косвенно через CSP, который это умеет.
Потому что версия КриптоАРМ Плюс не может генерировать усовершенствованную подпись Cades, а КриптоАРМ Стандарт может.

Автор: Агафьин Сергей Перейти к цитате

Если человек хочет использовать PKCS#11 и наш CSP: например для того, чтобы можно было работать через тот самый единый PKCS#11-интерфейс с ключами на всех считывателях, поддерживаемых CSP: реестр, таблетки, пассивные носители, ФКН, то можно взять нашу реализацию PKCS#11 - cppkcs11.dll:

софт -> [PKCS#11-интерфейс] -> cppkcs11.dll -> [CryptoAPI] -> КриптоПро CSP -> модули поддержки

Это какой-то другой work around для Windows?

Отредактировано пользователем 27 июля 2020 г. 12:36:33(UTC)  | Причина: Не указана

Offline sanyo  
#26 Оставлено : 27 июля 2020 г. 12:23:32(UTC)
sanyo

Статус: Активный участник

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

Сказал(а) «Спасибо»: 11 раз
.

Отредактировано пользователем 27 июля 2020 г. 12:29:11(UTC)  | Причина: Не указана

Offline Агафьин Сергей  
#27 Оставлено : 27 июля 2020 г. 15:18:34(UTC)
Grey

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

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

Сказал «Спасибо»: 5 раз
Поблагодарили: 215 раз в 174 постах
Цитата:
В пункте 2) имеется ввиду, что нельзя создавать ключи сверх одного ключа, который создан при содействии УЦ и для которого получен сертификат в УЦ?
Т.е. все же один ключ с сертификатом создать можно?

Нельзя создавать pkcs11-ключи через КриптоПро CSP. Через другой ПО создавайте сколько угодно - мы все увидим и сможем использовать.

Цитата:
Под Linux это работает?

Да, и под macOS.

Цитата:
В поддержке Аладдин мне недавно сообщили, что Infotecs CSP видит ключи, созданные в формате PKCS 11.
То, что вы писали про Рутокен ЭЦП 2.0 работает аналогично именно для этого носителя с точки зрения пользователя, не вдаваясь в технические подробности?

Да, мы видим те же ключи.

Цитата:
Сможет КриптоАРМ Стандарт (не плюс) работать с неизвлекаемым ключом, не догадываясь о том, что он неизвлекаемый, и что ваш CSP будет работать с ключом через PKCS11?
Т.е. КриптоАРМ Стандарт (не плюс) будет казаться, что он работает с извлекаемым ключом, а на самом деле с неизвлекаемым? Так возможно?

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

Цитата:
Это какой-то другой work around для Windows?

Разработчики приложений могут изначально заложить поддержку только PKCS#11, но не CryptoAPI, тогда наш модуль cppkcs11 - единственный путь использовать CSP. Если я не ошибаюсь, таким образом работает плагин от Госуслуг, например.
С уважением,
Сергей
Техническую поддержку оказываем здесь.
Наша база знаний.
thanks 1 пользователь поблагодарил Grey за этот пост.
sanyo оставлено 27.07.2020(UTC)
Offline sanyo  
#28 Оставлено : 27 июля 2020 г. 20:07:05(UTC)
sanyo

Статус: Активный участник

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

Сказал(а) «Спасибо»: 11 раз
Автор: Агафьин Сергей Перейти к цитате

Цитата:
Это какой-то другой work around для Windows?

Разработчики приложений могут изначально заложить поддержку только PKCS#11, но не CryptoAPI, тогда наш модуль cppkcs11 - единственный путь использовать CSP. Если я не ошибаюсь, таким образом работает плагин от Госуслуг, например.


Большинство площадок, поддерживающих неизвлекаемые ключи, работает через плагин браузера PKCS11? Госуслуги как-то иначе?

Зачем им дополнительно КриптоПРО через CryptoAPI, если можно напрямую работать с токеном по PKCS11?

Или это для эмуляции PKCS11 там, где его на самом деле (аппаратно) нет, например, на пассивных токенах?

Отредактировано пользователем 27 июля 2020 г. 21:25:00(UTC)  | Причина: Не указана

Offline sanyo  
#29 Оставлено : 27 июля 2020 г. 20:10:36(UTC)
sanyo

Статус: Активный участник

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

Сказал(а) «Спасибо»: 11 раз
Автор: Агафьин Сергей Перейти к цитате
Цитата:
В пункте 2) имеется ввиду, что нельзя создавать ключи сверх одного ключа, который создан при содействии УЦ и для которого получен сертификат в УЦ?
Т.е. все же один ключ с сертификатом создать можно?

Нельзя создавать pkcs11-ключи через КриптоПро CSP. Через другой ПО создавайте сколько угодно - мы все увидим и сможем использовать.


Это работает на таких моделях Rutoken:

Смарт-карта Рутокен 2151
ПАК: Смарт-карта Рутокен ЭЦП 2.0 2100, серт. ФСБ

? На обоих (на каждой из них в отдельности)?

Автор: Агафьин Сергей Перейти к цитате

Если кто-то создал через любой софт, использующий pkcs11-библиотеку, ключ на Рутокен ЭЦП 2.0, CSP этот ключ увидит и сможет использовать. Речь только об этом конкретном токене!


Рутокен 2151 является разновидностью "Рутокен ЭЦП 2.0" в контексте нашего обсуждения совместимости КриптоПРО5 с ключами в формате PKCS11?

Тем более им является и ПАК: Смарт-карта Рутокен ЭЦП 2.0 2100, серт. ФСБ ?

Отредактировано пользователем 27 июля 2020 г. 21:38:16(UTC)  | Причина: Не указана

Offline sanyo  
#30 Оставлено : 27 июля 2020 г. 22:41:23(UTC)
sanyo

Статус: Активный участник

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

Сказал(а) «Спасибо»: 11 раз
.

Отредактировано пользователем 27 июля 2020 г. 22:56:22(UTC)  | Причина: Не указана

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