О перспективах встраивания российской криптографии в браузеры Chrome от Google
 Для поддержки защищенного протокола https до середины 2014 года в браузерах Chrome от Google (Google Chrome/Chromium) использовалась библиотека NSS (Network Security Socket),
которая имеет как встроенное криптографическое ядро, так и позволяет
подключать сторонние средства криптографической защиты информации (СКЗИ)
с интерфейсом PKCS#11. Встроенное
ядро не поддерживает российские криптоалгоритмы.
 Именно библиотека NSS отвечала в браузерах Chrome от Google за реализацию как протокола https, так и работу с хранилищем сертификатов.
База данных NSS (хранилище сертификатов) для браузерах Chrome от Google хранится в каталоге /$HOME/.pki и включает в себя базу данных cert9.db,
в которой хранятся сертификаты, включая корневые, и key4.db, в которой
хранятся закрытые ключи, поддерживаемые встроенным криптоядром. В
каталоге /home/$HOME/.pki хранится еще файл pkcs11.txt, в котором
прописываются библиотеки PKCS#11, для подключаемых устройств PKCS#11.
Именно в этот файл надо добавить путь к библиотеке PKCS#11 токена,
реализующего российские криптографические стандарты ГОСТ Р
34.10-2012, ГОСТ Р 34.11-2012, ГОСТ Р 34.12-2015 и ГОСТ Р 34.13-2015, а
также ГОСТ Р 34.10-2001, ГОСТ Р 34.11-94 и ГОСТ 28147-89:
#путь к библиотеке ГОСТ-ового токена
library=/usr/local/lib64/libls11usb2016.so
#Произвольное имя устройства
name=TOKEN_LS11USB2016
И вот до середины 2014 года достаточно было собрать Google Chromium с доработанной библиотекой NSS, подключить токен PKCS11,
разработанный в соответствие с выпущенным Техническим комитетом по
стандартизации «Криптографическая защита информации» (ТК 26) дополнением
к стандарту PKCS#11 — "Расширение PKCS#11 для использования российских криптографических алгоритмов" (версия 2.30) и можно было смело работать по ГОСТ-ому TLS:
Рис. Доступ по HTTPS с российской криптографией
В это же время браузер Google Chrome на платформе Аndroid использовал для реализации протоколов https библиотеку OpenSSL.
Но вот в начале 2014 года в OpenSSL была обнаружена уязвимость HeartBleed.
В этом момент многим показалось, что может наступить золотая эра NSS в
проектах Google. Но Google не был бы Google, если бы не принял совсем
неожиданное решение: разработать опираясь на опыт OpenSSL и LibreSSL
собственный криптографический движок для поддержки HTTPS – BoringSSL.
Были также предложения полностью отказаться от использования NSS в
браузерах Chrome от Google и для хранения личных сертификатов. Однако,
развернувшаяся дискуссия не позволила это сделать. Звучали такие
заявления, что отсутствие поддержки smartcard с интерфейсом PKCS#11
станет позором для Google, что, например, граждане Бельгии, которые
получают электронные идентификаторы PKCS, вынуждены будут использовать другие браузеры. В итоге, сегодня в браузерах Chrome от Google используется две библиотеки, а именно NSS и BoringSSL.
Библиотека NSS используется для организации хранения и проверки
сертификатов и ключей, импорта и экспорта сертификатов, в том числе
корневых, а также для импорта и экспорта личных сертификатов в формате
PKCS#12. Для реализации механизмов HTTPS/TLS используется уже библиотека
BoringSSL.
Вот бы и нам в России добиться использования, хотя бы наравне с Microsoft
CSP, стандарта PKCS#11 (ТК-26 постоянно выпускает по нему рекомендации) и
чтобы портал госуслуг был доступен не только через Internet Explorer с
КриптоПро-CSP, а с любого браузера, где есть поддержка российской
криптографии, включая браузеры Chrome от Google.
Соответственно, если говорить об использовании в браузерах Chrome от
Google российской криптографии, то необходима модернизация обеих
библиотек и наличие токенов PKCS#11, реализованных с учетом рекомендаций ТК26. И если опыт встраивания поддержки механизмов PKCS#11 для российских криптоалгоритмов в библиотеку NSS уже имеется и токены, реализующие российскую криптографии
и имеющие интерфейс PKCS#11, также имеются и их подключение в браузер
Chrome от Google уже сегодня позволяет импортировать и хранить в
хранилище сертификатов cert9.db сертификаты X509 с алгоритмами
электронной подписи ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012 с длиной открытого ключа как 512, так и 1024 бита, то про библиотеку BoringSSL этого не скажешь.
И так, если после подключения токена (добавления соответствующих директив в файл pkcs11.txt) запустить браузер GoogleChrome и в адресной строке ввести:
chrome://settings/certificates,
то браузер GoogleChrome запросит ввод PIN для подключенного токена с ГОСТ-алгоритмами:
Рис. Ввод PIN-кода к токену с российской криптографией
После корректного ввода PIN-кода можно импортировать корневые
сертификаты X509 с алгоритмами электронной подписи ГОСТ Р 34.10-2001 и
ГОСТ Р 34.10-2012 с длиной открытого ключа как 512, так и 1024 бита:
Рис. Верификация корневого сертификата и его назначение
 Рис. OID алгоритма подписи ключа
Личные сертификаты пользователя естественно хранятся на подключенном
токене. Есть определенная проблема: как сертификаты и ключи появятся на
токене. Формально в браузерах Chrome от Google можно импортировать
личные сертификаты из контейнеров PKCS#12. Но где взять эти PKCS#12, а
если токен с неизвлекаемым ключом и самое главное сейчас механизм
PKCS#12 в браузерах Chrome от Google не понимает ГОСТ-овых сертификатов и
ключей, необходимо модификация модуля nsPKCS12Blob.cpp. Есть простой и
элегантный путь – положить личные сертификаты на токен, скажем, с
использованием браузера Redfox. И так токен подключен и мы просматриваем личные сертификаты:
Рис. Верификация личного сертификата и его назначение
Рис. OID алгоритма ключа (1.2.643.7.1.1.1- ГОСТ Р 34.10-2012 длина открытого ключа 512 бит).
Однако попытка связаться по HTTPS с ГОСТ-овым Web-сервером как в анонимном, так и авторизованном режимах заканчивается неудачей:
Рис. Доступ по HTTPS с российской криптографией не возможен: отсутствует ее поддержка в
BoringSSL И все это несмотря на то, что российская криптография для работы подключена.
Как говорилось выше, за реализацию собственно протокола HTTPS в
браузерах Chrome от Google отвечает библиотека BoringSSL. А библиотека
BoringSSL сегодня поддерживает только ключи типа RSA и ECDSA и тем более
ничего не знает про российские шифрсьюты TLS_GOSTR341001_WITH_28147_CNT_IMIT и TLS_GOSTR341112_256_WITH_28147_CNT_IMIT (GOST2001-GOST89-GOST89, GOST2012-GOST8912-GOST8912 — в терминологии OpenSSL ).
Таким образом, для появления в браузерах Chrome от Google полноценной
поддержки отечественных шифрсьютов требуется сделать еще один шаг –
провести доработку библиотеки BoringSSL. Сегодня есть компании, которые
имеют большой опыт по встраиванию российской криптографии в OpenSSL. Это
прежде всего ООО «Криптоком» и ООО «ЛИССИ-Софт», более того они имеют и опыт совместной работы.
Остается надеяться, что либо эти компании, либо кто-то третий проделает эту работу.
Но еще лучше, чтобы эту работу в свете поручения Президента России
«Поручение об обеспечении разработки и реализации комплекса
мероприятий, необходимых для перехода органов власти на использование
российских криптографических алгоритмов и средств шифрования» кому-либо
поручило и взяло под свой контроль Государство Российское, скажем, в лице
Минкомсвязи.
| 
)
)
)
)
)
)
)
