Цитата:Но по вашим словам КриптоПро не использует 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)
| Причина: Не указана
