Тема от sanyo (2020-07-27 06:07:28 отредактировано sanyo)

  • sanyo
  • Посетитель
  • Неактивен

Формат хранения неизвлекаемых ключей на аппаратном крипто Rutoken ECP2

По мнению поддержки Аладдин:

КриптоАРМ Плюс работает и с PKI и с ГОСТ. А вот Диадок и МИГ24 вероятнее всего используют КриптоПро CSP. В случае если там поддерживается КриптоПро CSP 5.0, могут применяться в том числе неизвлекаемые ГОСТ-ключи.
К сожалению, формат работы КриптоПро CSP 5.0 с неизвлекаемыми ключами несовместим с pkcs#11.
Для контроля транзакций рекомендуем посмотреть SafeToch PRO, он поддерживает JaCarta-2 ГОСТ.

Все таки непонятно, для чего Диадоку нужен КриптоПро? Однако упоминание того, что для Диадок достаточно КриптоПро4 даже в случае, когда используются неизвлекаемые ключи, намекает на то, что КриптоПро сам не используется непосредственно для работы с ключами, потому что неизвлекаемые ключи поддерживает только КриптоПро 5?

Кроме того поддержка Диадок упоминает об установке плагина для PKCS11:

Используется плагин, все верно. Во вложении пример установки плагина на Chromium. Можно загрузить на все системы Linux, что были описаны ранее.
На счет https://devuan.org/ - эксперт установил, все работает. Раз на ней работает, то и на более свежей версии 3.0 тоже будет работать.  Несколько моментов:
В инструкциях устарела ссылка на Плагин. Там https://h.kontur.ru/plugin/linux , а актуальная https://h.kontur.ru/plugin/beta
Для работы смарт-карт:
1) Надо установить необходимые пакеты через терминал командой sudo apt-get install libccid pcscd libpcsclite1 pcsc-tools
2) Для работы аппаратного токена необходимо установить PKCS#11 библиотеку по ссылке https://www.rutoken.ru/support/download/pkcs/#linux
Плагин пока не умеет работать напрямую с этой библиотекой, есть прямая зависимость от КриптоПро, поэтому ее тоже надо установить. Подойдёте и КриптоПро 4. КриптоПро CSP 5.0 и выше нужен для работы носителей Etoken и Jacarta.


Тогда возникает еще один вопрос, существуют ли УЦ, которые могут выдать сертификат неизвлекаемого ключа, сгенерированного с помощью КриптоПро 5?
Например, СКБ Контур может выдать сертификат как извлекаемого ключа на Rutoken S, так и для неизвлекаемого ключа в формате PKCS11 внутри Рутокен ЭЦП 2.0, а может ли СКБ Контур создать сертификат неизвлекаемого ключа для КриптоПро 5, который якобы несовместим с PKCS11 по словам поддержки Аладдин? Будет ли такой ключ работать в Диадок?

И наверно, есть вероятность, что такой неизвлекаемый ключ для КриптоПро5 будет работать в КриптоАрм стандарт (не плюс)?

Ответ от sanyo

  • sanyo
  • Посетитель
  • Неактивен

Re: Формат хранения неизвлекаемых ключей на аппаратном крипто Rutoken ECP2

По словам УЦ НТС Софт они делают только сертификаты PKCS 11 и МИГ 24 работает именно с ними.

А сертификаты для неизвлекаемого ключа, сгенерированного КриптоПро5, они никогда не делали и не хотят даже пытаться.

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

Для PKCS11 то и то мало кто выпускает, а с КриптоПро5 наверно вообще глухо?

По идее же ФКН2 подразумевает неизвлекаемый ключ и именно в формате КриптоПРО 5, а не PKCS11? А где взять сертификат для такого ключа, в каком УЦ?

Ответ от Антон Тихиенко

  • Антон Тихиенко
  • Администратор
  • Неактивен

Re: Формат хранения неизвлекаемых ключей на аппаратном крипто Rutoken ECP2

sanyo пишет:

По идее же ФКН2 подразумевает неизвлекаемый ключ и именно в формате КриптоПРО 5, а не PKCS11?

Да, там свой формат, зато дополнительно используется "SESPAKE" для защиты канала https://dev.rutoken.ru/x/7YX7Aw

sanyo пишет:

А где взять сертификат для такого ключа, в каком УЦ?

Рискну предположить что в аккредитованном УЦ ООО «КРИПТО-ПРО» такое могут сделать.

Ответ от Vladimir Ivanov

  • Vladimir Ivanov
  • Администратор
  • Неактивен

Re: Формат хранения неизвлекаемых ключей на аппаратном крипто Rutoken ECP2

sanyo пишет:

По словам УЦ НТС Софт они делают только сертификаты PKCS 11 и МИГ 24 работает именно с ними.

А сертификаты для неизвлекаемого ключа, сгенерированного КриптоПро5, они никогда не делали и не хотят даже пытаться.

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

Для PKCS11 то и то мало кто выпускает, а с КриптоПро5 наверно вообще глухо?

По идее же ФКН2 подразумевает неизвлекаемый ключ и именно в формате КриптоПРО 5, а не PKCS11? А где взять сертификат для такого ключа, в каком УЦ?

Сертификат совершенно не зависит от наличия ФКН2 или чего-то еще в таком роде. Для выпуска сертификата нужен только ключ проверки подписи (публичный ключ) и содержащий его CSR (запрос на сертификат). Если УЦ может выпускать сертификаты по запросам PKCS#10, технически проблем никаких не должно быть. Все остальное - бизнес и оргвопросы.

Ответ от socketpair

  • socketpair
  • Посетитель
  • Неактивен

Re: Формат хранения неизвлекаемых ключей на аппаратном крипто Rutoken ECP2

> Тогда возникает еще один вопрос, существуют ли УЦ, которые могут выдать сертификат неизвлекаемого ключа, сгенерированного с помощью КриптоПро 5?

Да, существуют. Это СКБ-Контур как минимум. Я с ними знатно пободался. и ТАКИ ПОЛУЧИЛ такие сертификаты. на Рутокен ЭЦП 2.0. Причём вначале по ошибке они мне сделали с извлекаемым но поместили на этот токен.


Я долго бодался с ними и они мне перевыпустили. Крипто-ПРО-шники подтвердили что теперь ключ неизвлекаемый судя по диагностике.

Ответ от sanyo

  • sanyo
  • Посетитель
  • Неактивен

Re: Формат хранения неизвлекаемых ключей на аппаратном крипто Rutoken ECP2

Судя по:
https://www.cryptopro.ru/forum2/default … post117509

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

Ответ от sanyo (2020-07-29 06:33:06 отредактировано sanyo)

  • sanyo
  • Посетитель
  • Неактивен

Re: Формат хранения неизвлекаемых ключей на аппаратном крипто Rutoken ECP2

socketpair пишет:

> Тогда возникает еще один вопрос, существуют ли УЦ, которые могут выдать сертификат неизвлекаемого ключа, сгенерированного с помощью КриптоПро 5?

Да, существуют. Это СКБ-Контур как минимум. Я с ними знатно пободался. и ТАКИ ПОЛУЧИЛ такие сертификаты. на Рутокен ЭЦП 2.0. Причём вначале по ошибке они мне сделали с извлекаемым но поместили на этот токен.

Я долго бодался с ними и они мне перевыпустили. Крипто-ПРО-шники подтвердили что теперь ключ неизвлекаемый судя по диагностике.

Вот еще полюбуйтесь:
https://www.cryptopro.ru/forum2/default … post117557

Вероятно, вам сделали ключ PKCS11 и то со второго раза :)

Если бы у вас был другой носитель (не Рутокен ЭЦП 2.0), то КриптоПро 5 не смог бы увидеть и использовать эти ключи, тогда бы пришлось вместо КриптоПРО CSP ставить Infotecs CSP, вот он бы смог даже на другом носителе с аппаратным крипто, например на JaCarta ГОСТ.

Ответ от sanyo (2020-07-29 06:43:47 отредактировано sanyo)

  • sanyo
  • Посетитель
  • Неактивен

Re: Формат хранения неизвлекаемых ключей на аппаратном крипто Rutoken ECP2

Vladimir Ivanov пишет:
sanyo пишет:

По словам УЦ НТС Софт они делают только сертификаты PKCS 11 и МИГ 24 работает именно с ними.

А сертификаты для неизвлекаемого ключа, сгенерированного КриптоПро5, они никогда не делали и не хотят даже пытаться.

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

Для PKCS11 то и то мало кто выпускает, а с КриптоПро5 наверно вообще глухо?

По идее же ФКН2 подразумевает неизвлекаемый ключ и именно в формате КриптоПРО 5, а не PKCS11? А где взять сертификат для такого ключа, в каком УЦ?

Сертификат совершенно не зависит от наличия ФКН2 или чего-то еще в таком роде. Для выпуска сертификата нужен только ключ проверки подписи (публичный ключ) и содержащий его CSR (запрос на сертификат). Если УЦ может выпускать сертификаты по запросам PKCS#10, технически проблем никаких не должно быть. Все остальное - бизнес и оргвопросы.


Судя по:
https://www.cryptopro.ru/forum2/default … post117509

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

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

Для ключа, созданного в PKCS11 и ключа, созданного в КриптоПРО5, формат хранения разный. В общем случае КриптоПРО5 не видит ключи PKCS11, а API PKCS11 не видит ключи КриптоПРО5, но для Рутокен ЭЦП 2.0 сделано исключение, когда КриптоПРО видит ключи PKCS11, но вероятно не наоборот.

1) Неизвлекаемые ключи могут храниться как минимум в двух разных несовместимых форматах PKCS11 и КриптоПРО5?
Но для носителя Рутокен ЭЦП 2.0 есть readonly исключение из этого правила, когда КриптоПРО5 хотя бы может использовать готовые ключи PKCS11.
И есть непроверенная вероятность работы КриптоАРМ 5 Стандарт как раз через такое исключение из правил.

2) Infotecs CSP может работать с ключами PKCS11 на любом совместимом носителе с аппаратным крипто (не только одной модели Рутокен ЭПЦ 2.0)

3) Онлайн сервисы Диадок и МИГ24 могут работать с ключами PKCS11 без явного участия КриптоПРО.
Причем могут генерировать усовершенствованные подписи в отличии от КриптоАРМ Плюс.

Ответ от sanyo

  • sanyo
  • Посетитель
  • Неактивен

Re: Формат хранения неизвлекаемых ключей на аппаратном крипто Rutoken ECP2

Антон Тихиенко пишет:
sanyo пишет:

По идее же ФКН2 подразумевает неизвлекаемый ключ и именно в формате КриптоПРО 5, а не PKCS11?

Да, там свой формат, зато дополнительно используется "SESPAKE" для защиты канала https://dev.rutoken.ru/x/7YX7Aw

А в случае использования готового ключа PKCS11 через КриптоПРО5 возможно задействовать протокол ФКН2?

Ответ от Антон Тихиенко

  • Антон Тихиенко
  • Администратор
  • Неактивен

Re: Формат хранения неизвлекаемых ключей на аппаратном крипто Rutoken ECP2

Антон Тихиенко пишет:

Да, там свой формат, зато дополнительно используется "SESPAKE" для защиты канала https://dev.rutoken.ru/x/7YX7Aw

Вот по ссылке отсюда явно видно, что при генерации ключей нужно выбирать режим "С поддержкой ФКН" или "БЕЗ ФКН".

Чтобы точнее понимать почему сделано именно так, вероятно лучше поизучать материалы по "КриптоПРО CSP", например, начать отсюда https://www.cryptopro.ru/news/2017/04/v … n-v-csp-50

Ответ от Vladimir Ivanov

  • Vladimir Ivanov
  • Администратор
  • Неактивен

Re: Формат хранения неизвлекаемых ключей на аппаратном крипто Rutoken ECP2

sanyo пишет:
Антон Тихиенко пишет:
sanyo пишет:

По идее же ФКН2 подразумевает неизвлекаемый ключ и именно в формате КриптоПРО 5, а не PKCS11?

Да, там свой формат, зато дополнительно используется "SESPAKE" для защиты канала https://dev.rutoken.ru/x/7YX7Aw

А в случае использования готового ключа PKCS11 через КриптоПРО5 возможно задействовать протокол ФКН2?

Нет, нельзя. Для ФКН2 нужно генерировать ключи через КриптоПро CSP 5.0 в режиме "ФКН с защитой канала (rutoken_fkc_xxxxxxxx)". См. https://dev.rutoken.ru/x/7YX7Aw