ASN1js и PKIjs — год после создания

    Почти год назад я рассказал о новых библиотеках PKIjs и ASN1js. Пришло время рассказать о развитии этих библиотек. Для ASN1js за это время были сделаны в основном «косметические» изменения. Из существенных изменений можно заметить только возможность конвертации любых объектов ASN.1 в JSON формат. А вот с PKIjs произошли более существенные перемены.

    Итак, текущие основные особенности PKIjs:
    • Полная поддержка Web Cryptography API;
    • Ограниченная возможность использования как в iPhone (через использование Safari), так и в Android приложениях (Google Chrome);
    • Расширилось количество примеров. В частности, добавились примеры использования PKIjs для проверки подписей в PDF файлах и для проверки подписей в S/MIME;
    • Использование всех алгоритмов подписи из Web Cryptography API:
      • RSASSA-PKCS1-v1_5 (PKCS#1 v1.5);
      • RSA-PSS (PKCS#1 v2);
      • ECDSA (подпись на ECC, Elliptic Curve Cryptography);
    • Первая реализация «certificate chain verification engine» (верификация цепочки сертификатов) на чистом JavaScript и проходящая основные тесты NIST;
    • Первая и пока единственная реализация «Suite B» для подписи и шифрования данных в виде CMS (Cryptographic Message Syntax) в «open-source» на чистом JavaScript;
      • Подпись CMS с помощью ECDSA;
      • Шифрование с применением схем «ephemeral-static» ECDH;
      • Использование AES-CBC и AES-GCM;
      • Использование расширенного списка алгоритмов хеширования: от SHA-1 до SHA-512;
      • Возможность создания зашифрованных сообщений на основе использования пароля с использованием алгоритмов серии AES;


    Для начала о реализации подписей. Все используемые алгоритмы я уже перечислил, однако необходимо отметить, что PKIjs позволяет создавать самые различные виды криптографических объектов, которые будут использовать все эти алгоритмы:
    • X.509 сертификаты;
    • X.509 CRL (Certificate Revocation List);
    • Запросы на создание сертификатов формата PKCS#10;
    • OCSP запросы;
    • OCSP ответы;
    • TSP запросы;
    • TSP ответы;
    • CMS Signed Data;

    Для всех этих видов криптографических объектов существуют удобные «помощники» (helpers), позволяющие получить внутреннюю структуру ранее закодированных объектов, создать новую структуру объектов или подписать внутренние данные, а также проверить существующую подпись. Также для каждого вида существует отдельный пример его использования с применением всех возможных алгоритмов подписей.

    Теперь перейдём к описанию реализации работы с шифрованием. Создатели Web Cryptography API основывали стандарт на новейшей информации о криптографических алгоритмах. Учитывая это можно сказать, что Web Cryptography API постаралось отсечь всё устаревшее из мира криптографии. Так как PKIjs основывается исключительно на Web Cryptography API, то, следовательно, в PKIjs пришлось реализовать новейшие алгоритмы формирования шифрованных данных (CMS Enveloped Data) и отсечь старые, уже привычные всем, алгоритмы.

    В PKIjs реализована возможность работы со всеми типами получателей зашифрованных сообщений CMS:
    • KeyTransRecipientInfo (шифрование сессионного ключа асимметричным алгоритмом);
    • KeyAgreeRecipientInfo (шифрование сессионного ключа на основании «разделяемого секрета»);
    • KEKRecipientInfo (шифрование сессионного ключа на основании заранее известного значения «key encryption key»);
    • PasswordRecipientInfo (шифрование сессионного ключа на основании данных, производных от заданного пароля);

    Общее для всех типов получателей зашифрованных сообщений CMS: в PKIjs в качестве основного алгоритма шифрования данных возможно использовать два алгоритма — AES-CBC и AES-GCM. Технически возможно использовать также и AES-CTR, однако для данного алгоритма отсутствуют общепринятые OID и параметры алгоритма, которые могут быть использованы в CMS сообщениях.

    Для начала расскажу об основных типах получателей зашифрованных сообщений — «KeyTransRecipientInfo» и «KeyAgreeRecipientInfo». Тип «KeyTransRecipientInfo» в настоящий момент возможет только для получателей, для которых существуют X.509 сертификаты с подписью на алгоритмах RSA (RSASSA-PKCS1-v1_5 и RSA-PSS). При реализации шифрования для получателя с типом «KeyTransRecipientInfo» используется алгоритм асимметричного шифрования RSA-OAEP (RSASSA-OAEP). Для RSA-OAEP применяется строго только MGF1, однако существует возможность задания алгоритма хеширования от SHA-1 до SHA-512. Для получателей, сертификаты которых содержат подписи на ECC (Elliptic Curve Cryptography) доступен только тип получателя «KeyAgreeRecipientInfo». В данном типе применяется более усложнённая схема формирования KEK (key encryption key): генерируется эфемерный ключ на алгоритме ECDH, а затем выполняется специальная «key derivation function» (KDF), в основе которой лежит использование алгоритмов хеширования. Здесь пользователь может задать как вид используемой эллиптической кривой (secp256r1, secp384r1 или secp521r1), а также вид алгоритма хеширования, используемого в KDF.

    С типом «KEKRecipientInfo» всё достаточно просто: пользователь передаёт в функцию выбранный алгоритм шифрования сессионного ключа, а также буфер с сохранённым ключом для данного алгоритма. PKIjs в дальнейшем остаётся только использовать ранее переданные данные. С типом получателя «PasswordRecipientInfo» работа производится чуть-чуть сложнее: «key encryption key» формируется как результат алгоритма PBKDF2, и на этих данных уже шифруется сессионный ключ. Также здесь технически возможно использование алгоритма HKDF, однако здесь существует такая же проблема, что и с AES-CTR: отсутствуют общепринятые OID для использования в CMS Enveloped Data.

    Также скажу, что в настоящее время PKIjs может формировать виды криптографических сообщений, поддержка которых отсутствует, например, в последних релизах OpenSSL, а также в Microsoft CryptoAPI (и CNG). Например, в OpenSSL нет возможности (через стандартное консольное приложение) расшифровать данные, в которых используется PBKDF2 + AES-KW, а в Microsoft CryptoAPI нет поддержки схем «dhSinglePass-stdDH-sha1kdf-scheme» и «dhSinglePass-stdDH-sha512kdf-scheme», а также типов получателей «KEKRecipientInfo» и «PasswordRecipientInfo».

    Более подробное описание возможностей шифрования приведено в файле README, находящемся в каталогах примеров шифрования с помощью сертификата, а также с помощью пароля.

    В заключение скажу, что данная библиотека продолжает развиваться, но уже с помощью компании «Peculiar Ventures». Возможности библиотеки будут только расширяться, следите за новостями. Буду благодарен за конструктивные замечания, а также описание проектов, выполненных с применением PKIjs. За консультациями по работе с библиотекой можете обращаться непосредственно ко мне, её автору.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 6

      0
      Заранее скажу также, что работа с паролями с CMS Enveloped пока возможна исключительно только из-под последних «development» версий Google Chrome.
        0
        Интерактивные примеры использования Web Cryptography API u PKIjs теперь на сайте pkijs.org.
          0
          Возможно ли использовать российскую криптографию или планируется ли?
            +1
            Планируется.
            0
            Спасибо за библиотеку. А можете что-нибудь сказать, насколько большие ресурсы будут вкладываться в развитие библиотеки в будущем? Наличие globalsign'а как-то успокаивало (хотя и сейчас pki.js в их github-репозитарии).
              0
              В работе сейчас следующие части:
              • Работа с CAdES (создание всех версий, вплоть до архивных);
              • Работа с PAdES (подпись и шифрование). То есть PKIjs используется как вспомогательная в дополнение к нашему собственному парсеру/мейкеру PDF (всё на чистом JavaScript);
              • Создание собственных серверов OCSP, TSP, CA, RA (на Node.js);
              • Создание «polyfills» для возможности работы PKIjs с помощью сторонних библиотек таких как эта, а также для работы внутри Node.js, для работы с алгоритмами ГОСТ и прочая без изменения исходного кода PKijs;
              • Реализация полноценной «verification engine», способной проверять подписи CAdES и PAdES;
              • Реализация поддержки PKCS#12 (когда у меня будет время);
              • И ещё кое-что;

              Также скажу что понятие «в работе» фактически можно свести к «в работе на финальной стадии», то есть процентов 90 всего кода уже готово. Скорее всего весь код будет публично доступен, но часть его будет «только для некоммерческого использования». Следите за анонсами.

              Так что ресурсы вкладываются большие, библиотека активно совершенствуется, пусть пока и несколько скрытно.

            Only users with full accounts can post comments. Log in, please.