Почти год назад я рассказал о новых библиотеках 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. За консультациями по работе с библиотекой можете обращаться непосредственно ко мне, её автору.