Кстати на всякий случай предостерегу от использования PolyCrypt: данный продукт, похоже, более не поддерживается — по моим сведениям автора переманили в Mozilla. Кроме того в данном продукте существуют ошибки при реализации работы с криптографическими преобразованиями: иногда у меня случались ошибки при верификации заведомо корректных подписей. Также в PolyCrypt используется часть библиотеки от Kenji Urushima. Так что я реально не советую использовать PolyCrypt в перспективных проектах (к сожалению сам потратил примерно месяц приводя её в порядок). Кроме того текущая версия PolyCrypt не поддерживает последний стандарт WebCrypto.
Есть такие реализации уже сейчас. Но они реально бесперспективны. WebCrypto раз и навсегда вытеснит такие решения и будет это происходить уже в этом году, очень-очень скоро.
Кстати весь код ASN1js и большинство кода PKIjs работает во всех современных браузерах. Зависимости от WebCrypto только в части создания и проверки подписей.
Кстати насколько мне известно в течение нескольких недель должна также появится и реализация WebCrypto от Mozilla, которую также автоматически поддержит код PKIjs.
Собственно PKIjs использует WebCrypto в реализации от Google (которая уже присутствует в «nightly build of Google Chrome»). Так что никаких противопоставлений тут нет: PKIjs использует WebCrypto, реальное, сделанное в соответствие с последним стандартом.
Спасибо! А вопросы «патентной чистоты» (предварительный поиск возможных ранее зарегистрированных патентов с таким же изобретением) у вас как-то решается? И если «да», то сколько стоит такой этап?
Если вы обрабатываете PKCS#10 с помощью загрузки BASE-64 кодированного сообщения с заголовками (BEGIN CERTIFICATE REQUEST etc.) и обрабатываете его с помощью OpenSSL, то ничего не мешает добавить отдельные разделы «BEGIN PUBLIC KEY» и «BEGIN PRIVATE KEY».
Формально запрос на сертификат может также содержать отдельные поля как для публичного, так и для приватного ключа. Как я уже упомянул ранее, я ошибочно посчитал, что ключи первично генерируются вне устройства.
Пользователь сам генерирует ключ, потом формируется подписанный запрос PKCS#10 (устройство умеет «парсить» PKCS#10), потом в устройство импортируется выданный в УЦ сертификат.
Ключевая пара формируется самим устройством, а не вне его?
То есть возможно, что имеющий доступ к устройству может:
1. Удалить существующий сертификат и связанный с ним ключевой контейнер с типом «с визуализацией»;
2. Повторно загрузить тот же PKCS#10 и сертификат, однако указав тип ключа «без визуализации»;
3. Выполнить какие-то не санкционированные действия с помощью этого изменённого ключа;
4. Вернуть всё на место (заново присвоив тип «с визуализацией»);
1. То есть если при первом парсинге PKCS#10 пользователь ошибься и указал другой тип ключевой пары то никакого выхода у него нет? Только стирать существующую ключевую пару и загружать PKCS#10 заново?
2. Я имею в виду: есть ли пароль на доступ к этому устройству? Или оно просто лежит на столе и любой сотрудник может им воспользоваться?
1. Возможно ли поменять тип ключевой пары с «с визуализацией» на «без визуализации»?
2. Есть ли разграничение доступа к устройству? Пароль или может быть (а вдруг?) считывание биометрии?
Ключевая пара формируется самим устройством, а не вне его?
1. Удалить существующий сертификат и связанный с ним ключевой контейнер с типом «с визуализацией»;
2. Повторно загрузить тот же PKCS#10 и сертификат, однако указав тип ключа «без визуализации»;
3. Выполнить какие-то не санкционированные действия с помощью этого изменённого ключа;
4. Вернуть всё на место (заново присвоив тип «с визуализацией»);
2. Я имею в виду: есть ли пароль на доступ к этому устройству? Или оно просто лежит на столе и любой сотрудник может им воспользоваться?
2. Есть ли разграничение доступа к устройству? Пароль или может быть (а вдруг?) считывание биометрии?
В любом случае, при любых операциях?