О перспективах поддержки российских шифрсьютов в браузерах Chrome от Google

в 9:37, , рубрики: chromium, Google, Google Chrome, браузеры, информационная безопасность

О перспективах поддержки российских шифрсьютов в браузерах Chrome от Google - 1
Сегодня поддержка защищенного протокола HTTPS с использованием российских шифрсьютов, рекомендованных к использованию на территории Российской Федерации, так или иначе реализована и в браузере Internet Explorer (IE) и в браузере Mozilla Firefox. В случае браузера IE достаточно установить КриптоПро CSP или другое CSP с поддержкой российской криптографии и российские шифрсьюты доступны для использования.

Уже сегодня можно использовать российские шифрсьюты для доступа, например, в личный кабинет налогоплательщика на сайте ФНС:

О перспективах поддержки российских шифрсьютов в браузерах Chrome от Google - 2

Почему не наступила Золотая эра NSS

Будем надеяться, что и сайт Госуслуг и другие государственные сайты все перейдут на российские шифрсьюты.

До середины 2014 года поддержку защищенного протокола https в браузерах 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/.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:

О перспективах поддержки российских шифрсьютов в браузерах Chrome от Google - 3

В это же время браузер 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 для подключенного токена с ГОСТ-алгоритмами:

image
Рис. Ввод PIN-кода к токену с российской криптографией

После корректного ввода PIN-кода можно импортировать корневые сертификаты X509 с алгоритмами электронной подписи ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012 с длиной открытого ключа как 512, так и 1024 бита:

image
Рис. Верификация корневого сертификата и его назначение

image
Рис. OID алгоритма подписи ключа

Личные сертификаты пользователя естественно хранятся на подключенном токене. Есть определенная проблема: как сертификаты и ключи появятся на токене. Формально в браузерах Chrome от Google можно импортировать личные сертификаты из контейнеров PKCS#12. Но где взять эти PKCS#12, а если токен с неизвлекаемым ключом и самое главное сейчас механизм PKCS#12 в браузерах Chrome от Google не понимает ГОСТ-овых сертификатов и ключей, необходимо модификация модуля nsPKCS12Blob.cpp. Есть простой и элегантный путь – положить личные сертификаты на токен, скажем, с использованием браузера Redfox. И так токен подключен и мы просматриваем личные сертификаты:

image
Рис. Верификация личного сертификата и его назначение

image
Рис. OID алгоритма ключа (1.2.643.7.1.1.1- ГОСТ Р 34.10-2012 длина открытого ключа 512 бит).

Однако попытка связаться по HTTPS с ГОСТ-овым Web-сервером как в анонимном, так и авторизованном режимах заканчивается неудачей.

И все это несмотря на то, что российская криптография для работы подключена.

Как говорилось выше, за реализацию собственно протокола 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. Это прежде всего ООО «Криптоком» и ООО «ЛИССИ-Софт», более того они имеют и опыт совместной работы.

Остается надеяться, что либо эти компании, либо кто-то третий проделает эту работу. Но еще лучше, чтобы эту работу в свете поручения Президента России «Поручение об обеспечении разработки и реализации комплекса мероприятий, необходимых для перехода органов власти на использование российских криптографических алгоритмов и средств шифрования» кому-либо поручило и взяло под свой контроль Государство Российское, скажем в лице Минкомсвязи.

Автор: V2008

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js