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