О Российской ГОСТ-криптографии в браузере
В последнее время, видимо на волне импортозамещения, ко мне обратилось несколько совершенно не связанных человек за консультацией по проектам, которые в конечном итоге сводились к реализации ГОСТ-ового алгоритма шифрования или электронной подписи на JavaScript для использования в браузере. Ниже я попытаюсь объяснить, почему такая реализация не имеет смысла.
Итак, классический пример асимметричного шифрования: Алиса и Боб сначала обмениваются открытыми ключами, которые созданы на основе закрытых ключей и пригодны только для шифрования данных, но бесполезны при расшифровке. Здесь все строится на том, что закрытый ключ безопасно хранится только у владельца и никому более не доступен, и никуда не передается. Само обеспечение этой безопасности остается за скобками.
В случае реализации алгоритма шифрования в браузере есть две зияющие дыры в безопасности.
С технической точки зрения
Когда мы храним закрытый ключ у клиента, а точнее в его браузере, поскольку у браузера нет доступа никуда, кроме самого себя, то это хранилище никак нельзя назвать безопасным.
А когда ключ хранится на сервере, который можно назвать безопасным, то для выполнения криптографических операций он должен быть передан в клиентский браузер по открытым каналам связи, где он может быть перехвачен и прочее.
Плюс, в любом случае, поскольку шифрование реализовано в браузере, закрытый ключ попадает в среду выполнения производства 3-й стороны, которая совсем не отвечает требованиям безопасности для криптографических операций, тем более по ГОСТ. На этом все рушится.
Что бы такого не происходило, в реальности за безопасность приватного ключа отвечает СКЗИ, сертифицированный для работы с ГОСТ алгоритмами. СКЗИ хранит ключ в безопасном хранилище, которое не доступно никому, кроме СКЗИ и осуществляет контроль доступа к нему (пароль или пин и тд). Работа с ключом (шифрование и прочая криптография) происходит так же внутри СКЗИ, куда на вход предаются данные, а на выход получается результат криптографической операции.
Для работы с данными из браузера СКЗИ имеют специальные "мостики", плагины, которые обеспечивают доступ из браузера к функциям СКЗИ. К плагинам не применяются такие жесткие требования безопасности, поскольку они занимаются лишь передачей данных, а вся криптография все равно происходит внутри СКЗИ. Из-за этого реализованы они у разных СКЗИ по-разному и для унифицированного взаимодействия с популярными СКЗИ, занимающими подавляющую часть рынка криптографии в РФ, есть моя разработка RusCryptoJS.
В условно-хороших СКЗИ для хранения ключей применяются аппаратные токены с неизвлекаемым ключевым носителем (не путать с обычной флекой), такие носители обеспечивают изоляцию ключа от ПО на аппаратном уровне и реализуют принцип, описанный выше, когда на вход передаются данные, на выход получается результат. Плюс позволяют физически изолировать ключ (отключить токен от компьютера) при необходимости. Благодаря этим устройствам обеспечивается уникальность ключа, его нельзя клонировать (по крайней мере без вмешательства в аппаратную составляющую), и в один момент времени ключ можно использовать только в одном месте.
В не очень хороших СКЗИ ключевой контейнер хранится в файловой системе пользователя (ну или на обычной флешке), это позволяет контролировать доступ к использованию ключа средствами СКЗИ, но не защищает от клонирования. Ключевой контейнер можно легко скопировать и в другом месте спокойно заниматься подбором пароля к нему, а затем использовать как оригинальный ключ.
С гуманитарной
Использование ГОСТ-овых алгоритмов применяется тогда, когда нужна юридическая значимость с точки зрения законодательства РФ, например, в системах электронного документооборота (ЭДО) применяются ГОСТ алгоритмы формирования электронной подписи (ЭП) для того, чтоб обмен документами считался законным, а подписание приравнивалось к подписанию бумажных документов.
Для этого используются СКЗИ сертифицированные и аттестованные ФСБ и ФСТЭК. Наличие соответствующих документов у этого ПО позволяет гарантировать правильную и безопасную работу с криптографией с точки зрения закона.
Производителей таких СКЗИ в РФ сейчас можно пересчитать по пальцам одной руки, и попасть в их ряды будет крайне непросто, какой бы хорошей ни была ваша реализация.
Кроме того, для получения документов на JavaScript решение по ГОСТ шифрованию придется аттестовать браузер, в котором оно выполняется, как "криптосредство". Вдумайтесь, браузер, продукт 3-й стороны, коих великое множество и у каждого еще и множество версий, и все это не из РФ. Плюс получить сертификацию на ПО с открытым исходным кодом, как ни крути, JavaScript - это скриптовой язык, а не комплилируемый. Тоже самое касается и TypeScript. В общем, это из области фантастики.
Эпилог
Если после всего прочитанного, вас так и не отпускает жгучее желание сделать ГОСТ шифрование на JavaScript, посмотрите хотя бы на то, что уже сделали другие, вот например, этой штуке уже более 7 лет, а последняя активность кончилась 6 лет назад. Или вот реинкарнация, но уже для node.js, последняя активность 4 года назад. О судьбе проектов можно только гадать, но что-то мне подсказывает, что все разбилось о несбыточность и проблемы описанные выше.