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