- PVSM.RU - https://www.pvsm.ru -
Почти год назад я рассказал [1] о новых библиотеках PKIjs [2] и ASN1js [3]. Пришло время рассказать о развитии этих библиотек. Для ASN1js за это время были сделаны в основном «косметические» изменения. Из существенных изменений можно заметить только возможность конвертации любых объектов ASN.1 в JSON формат. А вот с PKIjs произошли более существенные перемены.
Итак, текущие основные особенности PKIjs:
Для начала о реализации подписей. Все используемые алгоритмы я уже перечислил, однако необходимо отметить, что PKIjs позволяет создавать самые различные виды криптографических объектов, которые будут использовать все эти алгоритмы:
Для всех этих видов криптографических объектов существуют удобные «помощники» (helpers), позволяющие получить внутреннюю структуру ранее закодированных объектов, создать новую структуру объектов или подписать внутренние данные, а также проверить существующую подпись. Также для каждого вида существует отдельный пример его использования с применением всех возможных алгоритмов подписей.
Теперь перейдём к описанию реализации работы с шифрованием. Создатели Web Cryptography API основывали стандарт на новейшей информации о криптографических алгоритмах. Учитывая это можно сказать, что Web Cryptography API постаралось отсечь всё устаревшее из мира криптографии. Так как PKIjs основывается исключительно на Web Cryptography API, то, следовательно, в PKIjs пришлось реализовать новейшие алгоритмы формирования шифрованных данных (CMS Enveloped Data) и отсечь старые, уже привычные всем, алгоритмы.
В PKIjs реализована возможность работы со всеми типами получателей зашифрованных сообщений CMS:
Общее для всех типов получателей зашифрованных сообщений 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, находящемся в каталогах примеров шифрования с помощью сертификата [7], а также с помощью пароля [8].
В заключение скажу, что данная библиотека продолжает развиваться, но уже с помощью компании «Peculiar Ventures» [9]. Возможности библиотеки будут только расширяться, следите за новостями. Буду благодарен за конструктивные замечания, а также описание проектов, выполненных с применением PKIjs. За консультациями по работе с библиотекой можете обращаться непосредственно ко мне, её автору.
Автор: ystr
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/javascript/88653
Ссылки в тексте:
[1] рассказал: http://habrahabr.ru/post/221857/
[2] PKIjs: https://github.com/GlobalSign/PKI.js
[3] ASN1js: https://github.com/GlobalSign/ASN1.js
[4] Web Cryptography API: http://www.w3.org/TR/WebCryptoAPI/
[5] количество примеров: https://github.com/GlobalSign/PKI.js/tree/master/examples
[6] «Suite B»: https://www.nsa.gov/ia/programs/suiteb_cryptography/
[7] помощью сертификата: https://github.com/GlobalSign/PKI.js/tree/master/examples/How%20To%20Encrypt%20CMS%20via%20certificate
[8] помощью пароля: https://github.com/GlobalSign/PKI.js/tree/master/examples/How%20To%20Encrypt%20CMS%20via%20password
[9] «Peculiar Ventures»: http://peculiarventures.com/
[10] Источник: http://habrahabr.ru/post/255565/
Нажмите здесь для печати.