Криптографические решения. От облачной подписи к доверенной среде

Данная статья является продолжением статьи «Криптографические решения. От криптопровайдеров до браузерных плагинов» и охватывает криптографические решения:

• облачная подпись
• отдельные браузеры с российской криптографией
• отдельные почтовые клиенты с российской криптографией
• российская криптография в фреймворках, платформах, интерпретаторах
• настольные криптографические приложения
• средства формирования доверенной среды

Облачная подпись

Концепция облачной подпись предполагает хранение закрытого ключа и выполнение процедуры подписи/шифрования данных непосредственно на сервере.
Для безопасного применения облачной подписи требуется решить задачу строгой аутентификации клиента при доступе к его закрытому ключу и задачу надежного хранения закрытого ключа на сервере. Примером подобного решения может служить КриптоПро DSS, который в качестве одного из вариантов аутентификации поддерживает Рутокен WEB (строгая двухфакторная аутентификация), а для хранения закрытого ключа использует HSM.

Проблемы:

• строгая аутентификация в сервисе
• гарантии защиты закрытого ключа от НСД
• снижение безопасности системы -> ограничение применения

Плюсы:

• кроссплатформенность, кроссбраузерность
• удобство для конечного пользователя — вообще ничего не надо устанавливать и настраивать
• удобная интеграция в информационные системы (WEB API)

Отдельные браузеры с российской криптографией

Браузеры, созданные на базе open source проектов Mozilla FireFox и Chromium, используют в качестве криптоядра NSS или OpenSSL. OpenSSL поддерживает российские криптоалгоритмы. Для NSS также существуют разработки, которые обеспечивают поддержку российских криптоалгоритмов. Некоторое время назад на рынке появились полнофункциональные браузеры с поддержкой российской криптографии.

Подобное решение обладает большим, на данный момент невостребованным, потенциалом, так как позволяет создавать защищенные стандартные WEB-клиенты для систем с высокими требованиями к безопасности. Еще одним плюсом подобного браузера является его «портабельность». С учетом существования USB-токенов с защищенной FLASH-памятью созданы безопасные решения, в котором наиболее критические операции с закрытом ключом осуществляются на «борту» USB-токена, а сам браузер хранится в его защищенной от модификации FLASH-памяти. Подобное решение кроме высокого уровня безопасности является очень удобным в применении.

На базе NSS

На картинке представлена архитектура решения, реализованная в проекте по расширению NSS aToken.

Проблемы:

• только одно приложение с российской криптографией — сам браузер
• обновление браузера
• переучивать пользователя на использование кастомного браузера
• сертификация (нет прецедентов)

Плюсы:

• кроссплатформенность
• прозрачность использования для пользователя
• нет ограничений для разработчиков серверной части
• не требуется инсталляция, запуск с FLASH-памяти USB-токена

Отдельные почтовые клиенты с российской криптографией

Отдельные почтовые клиенты с российской криптографией позволяют реализовать защиту переписки, используя электронную подпись и шифрование письма для абонента/группы абонентов (S/MIME). Данное решение удобно использовать в системах, построенных по принцу «точка-точка», в которых обмен информацией происходит непосредственно между абонентами, а сервер при этом используется только для маршрутизации сообщений.

Российская криптография в фреймворках, платформах, интерпретаторах

Microsoft.NET

Расширения классов

В платформе существует набор криптографических классов, в которых предусмотрены механизмы расширения сторонними алгоритмами. Наиболее известным на рынке решением по расширению платформы Microsoft.NET российскими криптоалгоритмами является продукт КриптоПро. NET, представляющий собой надстройку над КриптоПро CSP.
Установка КриптоПро.NET позволяет использовать российские криптоалгоритмы, например,
в WEB-сервисах на базе ASP.NET, SOAP-сервисах, в клиентских браузерных приложениях MS.Silverlight.

Отдельные библиотеки

BouncyCastle — это open source библиотека, в которой реализована своя система криптографических классов для платформы Microsoft.NET. В библиотеке поддерживаются как базовые криптографические алгоритмы ГОСТ 28147-89, ГОСТ Р 34.10-2001, ГОСТ Р 34.11-94, так и криптографические форматы PKCS#7/CMS, PKCS#10, X.509 с учетом специфики, описанной в RFC российских производителей СКЗИ. Кроме того, по утверждениям разработчиков библиотека поддерживает формат CADES с российскими криптоалгоритмами.

Java

Архитектура криптографической системы платформы Java (Java ™ Cryptography Architecture) позволяет расширять набор поддерживаемых в платформе криптоалгоритмов. С учетом большой распространенности Java многие из российских разработчиков криптосредств предлагают сертифицированные JCP-провайдеры.

JCP

Java-апплеты

Одним из вариантов использования СКЗИ в браузере является их интеграция в Java-апплеты.
В ряде случаев СКЗИ и криптографические библиотеки не требуют установки и представляют собой нативную библиотеку. В этом случае возможна ее интеграция непосредственно «внутрь» апплета и вызов функций СКЗИ через механизм JNI. При этой схеме библиотека будет инсталлирована в профайл пользователя при первой загрузке Java-апплета в браузере и ее отдельной инсталляции не потребуется.
Другим вариантом является написание Java-апплета, который вызывает предустановленное в системе СКЗИ (CSP, JCP и др.)
Более подробно пример подобной реализации, основанный на использовании Рутокен ЭЦП и OpenSSL, описан в статье habrahabr.ru/company/aktiv-company/blog/134890/.

Примеры:

• Апплет ЭТП «Стройторги» (реализован в соответствии с приведенной на схеме архитектурой)
• Система ДБО Бифит

PHP

PHP является одним из наиболее распространенных языков WEB-разработки. Криптографическая подсистема PHP построена на базе OpenSSL, в котором есть поддержка российских криптоалгоритмов. Но при этом в самом PHP поддержки российских криптоалгоритмов нет. Некоторые российские производители СКЗИ приступали к формированию патча к PHP, который позволял бы использовать российскую криптографию, но до конца эти работы доведены не были.
Бинарная совместимость таких СКЗИ, как МагПро КриптоПакет, с OpenSSL позволила бы придать данному решению легитимность.
В настоящее время многие разработчики инфосистем на базе PHP используют непосредственный вызов командно-строчной утилиты OpenSSL для проведения криптоопераций с использованием российских алгоритмов.

Экзотическое решение реализовано в рамках проекта Рутокен WEB. В серверной компоненте решения проверка подписи ГОСТ Р 34.10-2001 реализована непосредственно на PHP с использованием математических примитивов из нативной библиотеки.

Perl

Еще одним экзотическим примером является реализация шифрования по ГОСТ 28147-89 непосредственно на Perl http://search.cpan.org/~ams/Crypt-GOST-1.00/GOST.pm.
При этом в реальных проектах на Perl разработчики обычно используют вызовы командно-строчной утилиты из OpenSSL или какого-нибудь Linux-совместимого СКЗИ.

Ruby

Ruby использует в качестве криптоядра openssl, что позволило автору данной статьи habrahabr.ru/post/231261/ пропатчить его для поддержки российской криптографии.

JavaScript

Некоторое время назад на Хабре появилась статья, автор которой реализовал многие криптографические форматы непосредственно на JavaScript
При этом криптоалгоритмы используются из унифицированного ядра WebCrypto, которое уже сейчас поддерживается большинством современных браузеров.
habrahabr.ru/post/221857/

Проблемы:

• Нет ГОСТов
• Закрытый ключ находится в «хранилище браузеру», а не в отчуждаемом носителе
• Как подключать PKCS#11-совместимые устройства?

Плюсы:

• кроссплатформенное, кроссбраузерное решение
• подпись на клиенте
• Поддержка PKI
• не требуется установка вообще ничего на клиент

Настольные криптографические приложения

Класс приложений, которые предоставляют законченный оконный пользовательский интерфейс для проведения клиентских криптоопераций. Как правило, используют некоторое СКЗИ в качестве криптоядра.

Операции:

• подпись файла
• проверка подписи под файлом, в том числе построение цепочки и проверка списка отзыва, OCSP, проверка таймштампа
• зашифрование файла, в том числе для нескольких респондентов
• расшифрование файла
• поиск и выбор сертификата пользователя
• просмотр сертификата
• ведение базы сертификатов респондентов, интеграция со службой каталога (по протоколу LDAP) для поиска сертификата респондента
• генерация ключевой пары, формирование запроса на сертификат
• удаление ключевой пары
• импорт/экспорт сертификатов (корневых, пользовательских, респондентов)
• удаление сертификата

Примеры:

• КриптоАРМ
• КриптоНУЦ
• File-PRO, Admin PKI
• Блокхост ЭЦП
• Sign Maker
• ViPNet Crypto File

Средства формирования доверенной среды

Проблема формирования доверенной среды для выполнения криптоопераций, в частности ЭЦП, является отдельной большой темой. В данной статье не планируется ее подробно рассматривать, но хочется отметить, что концептуально разработчики идут следующими путями:

• отдельное устройство, на котором визуализируются данные, предназначенные для подписи и сама подпись производится после подтверждения пользователя (trustscreen)
• установка на компьютер и клиентскую ОС комплекса средств защиты информации (МДЗ, антивирусы и т.п.), с целью минимизации возможности заражения компьютера вредоносным ПО
• загрузка отдельной доверенной ОС в режиме USB-live
• параллельная работа клиентской ОС и доверенной среды на различных ядрах одного компьютера

На последнем способе формирования ДС хотелось бы остановиться подробнее.

Компанией «Код безопасности» предложен интересный продукт Jinn, который позволяет эмулировать доверенную среду как на многоядерном, так и на одноядерном компьютере. Основной идеей данного решения является то, что доверенная среда выполняется на логических ядрах, на которых не выполняется сама клиентская ОС. В случае одноядерного компьютера now-how решения позволяет реализовать эмуляцию отдельного физического вычислительного устройства, которое не видно ОС (или, вернее, доступ к нему из ОС сильно затруднен).

Для случая многоядерного компьютера доверенная среда функционирует на 2 ядрах, на остальных ядрах функционирует клиентская ОС. Доверенная среда загружается перед загрузкой клиентской ОС либо с флешки, либо с электронного замка Соболь. Решение гарантирует, что клиентская ОС (а следовательно и потенциальное вредоносное ПО) не управляет поведением доверенной среды.
По сути, в решении две ОС разнесены по различным ядрам одного компьютера и между ними настроен канал передачи данных. При этом одна из ОС (доверенная среда), спроектирована таким образом, что варианты ее заражения минимизированы и ее функционал служит исключительно цели безопасной визуализации данных и их пописи.

Для доступа к доверенной среде из клиентской ОС используется специальная библиотека (COM-объект). При подписи платежки через данную библиотеку Jinn перехватывает управление графическим адаптером и визуализирует на нем платежку. Если представленная информация верна, то после подтверждения пользователя Jinn подписывает платежку и возвращает управление клиентской ОС.

Автор: cryptoman

Источник