FAQ про облачную [электронную] подпись / Хабр

FAQ про облачную [электронную] подпись / Хабр ЭЦП
Содержание
  1. Отдельные почтовые клиенты с российской криптографией
  2. Что такое квалифицированная электронная подпись в облаке
  3. Использование облачного токена для организации безопасной почтовой переписки
  4. Faq про облачную [электронную] подпись
  5. Javascript
  6. Java-апплеты
  7. Европейский путь
  8. Как работает оэп?
  9. Как стали использовать облачные электронные подписи (оэп)?
  10. Как установить оэп и начать работать?
  11. Криптопро csp 5.0: «облачный» провайдер
  12. На базе nss
  13. Настольные криптографические приложения
  14. Начнём с главного
  15. Наше будущее
  16. Облачная подпись
  17. Ответы на самые распространенные вопросы
  18. Отдельные библиотеки
  19. Отдельные браузеры с российской криптографией
  20. Предисловие
  21. Преимущества
  22. Расширения классов
  23. Создание запроса через dss
  24. Создание тестового пользователя
  25. Средства формирования доверенной среды
  26. Установка первого личного сертификата в облачный токен
  27. Заключение

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

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

ПлатформыСемейство Windows, GNULinux, OS X, iOS, Android
Алгоритмы и криптографические протоколыЭЦП, шифрование, хэш-функция, имитозащита, HMAC, VKO, TLS
Интеграция с PKIX.509, PKCS#10, CMS, CRL
Механизмы ЭЦПВызов из JavaScript встроенных в браузер функций
TLS-ГОСТВстроен в библиотеку и поддерживается браузером
Форматы защищенных сообщенийPKCS#7, CMS
Интеграция с браузером100%
Мобильные платформыiOS, Android
Хранилища ключейБраузерное хранилище, USB-токены
Взаимодействие с USB-токенамиХранилище ключей и сертификатов
Использование аппаратной реализации алгоритмов
ИнсталляцияПрограмма установки, в целом, не требуются права системного администратор
Portable. Например, запуск браузера с FLASH-памяти USB-токена
Примеры (ГОСТ)Mozilla ThunderBird от Лисси
DiPost от Фактор ТС

Что такое квалифицированная электронная подпись в облаке

Для целей данной статьи, а также других научно-популярных и практических дискурсов об облачной электронной подписи предлагается использовать следующее определение.

Электронная подпись в облаке (облачная электронная подпись) – это вычислительная система, предоставляющая через сеть доступ к возможностям создания, проверки ЭП и интеграции этих функций в бизнес-процессы других систем.

В соответствии с данным определением, для облачной электронной подписи может использоваться в том числе и локальное средство ЭП. Например, используя КриптоПро DSS Lite, пользователь через веб-браузер может подписывать электронный документ с помощью средства ЭП, установленного на его оконечном устройстве (персональный компьютер или планшет).

В подобной системе ключ подписи остаётся у владельца и вопросы безопасности решаются с помощью стандартного набора средств, известного в мире «традиционной ЭП». Если хотите, можно назвать это облачной ЭП с локальным средством ЭП.

Другой вариант облачной ЭП получается при использовании средства ЭП, размещённого в облаке. Для удобства дальнейшего изложения назовём такую схему полностью облачной ЭП, чтобы отличать её от предыдущей. Эта схема регулярно вызывает жаркие дискуссии среди специалистов, поскольку подразумевает передачу самого ключа подписи «в облако». Данная же статья призвана прояснить ряд вопросов, связанных с безопасностью полностью облачной ЭП.

Использование облачного токена для организации безопасной почтовой переписки


Теперь посмотрим, как работает облачный токен в почтовом клиенте

Faq про облачную [электронную] подпись

Наша площадка стала первым федеральным оператором электронных торгов, внедрившим новую технологию облачной электронной подписи. Если обычная ЭП вызывала кучу вопросов, то эта услуга, с одной стороны, пока ещё больше непонятна бизнесу, а с другой — всё стало сильно проще.

FAQ про облачную [электронную] подпись / Хабр

— Что это такое?

Раньше была бумажная подпись на документе. Она не очень удобна, не очень безопасна и требует физического наличия бумаги. Потом появилась флешка с сертификатом и обвесом вокруг (вплоть до антивируса). Её сначала назвали ЭЦП — электронная цифровая подпись. Потом она стала просто ЭП. Теперь эту флешку положили в облако, и она стала ОЭП.

— Как работает ОЭП?

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

— А можно без софта на локальной машине?

Да, если на площадке есть промежуточный сервер, который фактически проксирует запросы и представляется этим самым локальным компьютером, то всё можно сделать из любого браузера. Но это требует переработки бэкенда площадки (в нашем случае мы сделали отдельный сервер для проведения торгов с мобильных телефонов). Если этот путь не работает — выбирается стандартный. Предполагается, что в будущем этот вариант будет наиболее распространённым. Как пример одной из подобных реализаций — площадка МСП «Росэлторг» (Закупки среди субъектов малого и среднего предпринимательства).

FAQ про облачную [электронную] подпись / Хабр

— ОЭП и ЭП — это одно и то же, но лежит в разных местах, так?

У подписей общее ядро с сертификатом и защитой. Функционально это одно и то же, просто меняется метод внутреннего API для шифрования транзакции. Один метод берёт ключ из локального устройства, другой — с удалённого.

— Погодите, но ведь всё равно нужна авторизация?

Да. Но теперь она двухфакторная и без привязки к устройству. Обычная схема: установить приложение на телефон или плагин браузера на десктоп, затем ввести логин и пароль для начала работы, потом при совершении транзакции — отправляемый с сервера авторизации ПИН-код. То есть, чтобы подписать документ за вас, нужно будет украсть пароль логин и перехватить SMS или push-уведомление с кодом.

— В чём тогда профит?

  1. Если вы потеряете флешку, то надо получать новый ключ. В случае с ОЭП — достаточно поменять пароль к подписи.
  2. Нет привязки к рабочему месту: раньше ЭП ставилась на один конкретный компьютер.
  3. Нет привязки к браузеру: раньше это был IE. Что вызывало ряд проблем ещё на уровне выбора ОС: Linux-админы обходили это, а вот на Mac-устройствах было сложнее.
  4. Нет привязки к географии: авторизация работает из любой страны (в силу особенностей защиты ЭП на флешках часто работали только в российских сетях).
  5. Предполагается, что всё стало безопаснее из-за двухфакторной идентификации по умолчанию без возможности «упростить себе жизнь».
  6. Уничтожение флешки с подписью не ставит под угрозу текущие сделки.
  7. В целом всё это более правильно, особенно из-за возможности быстро подписывать с мобильных телефонов.

— Где хранится сертификат на стороне удостоверяющего центра?

Есть специальная железка, называется HSM (hardware security module). Технически, это хранилище, разбитое на закрытые ячейки без возможности массового доступа ко всем сразу.

Несколько упрощая: вы авторизуетесь, создаёте транзакцию, она отправляется в HSM подписываться, оттуда на выходе — защищённый объект. Закрытый ключ наружу не выдаётся.

То есть HSM выступает в роли третьей стороны, вроде нотариуса, подтверждающей в сделке, что вы — это вы. Точнее, что вы имеете право подписывать документ.

В каждом удостоверяющем центре свой HSM.

Каждое решение лицензируется ФСБ. Железка снабжена большим количеством уровней безопасности, в частности, датчиками антивзлома. Терминал физически встроен в сам сервер, никаких внешних подключений для управления не поддерживается, веб-интерфейса нет. Нужно что-то настроить — свитер, машзал, большой железный ящик с маленьким LCD-экраном.

FAQ про облачную [электронную] подпись / Хабр

— Как с обратной совместимостью?

Опять же, упрощая, новые версии ПО для работы с ЭП теперь умеют делать что-то вроде эмуляции этой самой флешки для всего старого софта. То есть не важно, что вы используете: токен на физическом носителе или доступ к HSM. Обновлённый софт подпишет всё, как в старые добрые времена.

— Как выглядит первое подключение?

При настройке на устройстве конечного пользователя указываются два адреса DSS-сервера. Это, собственно, вся настройка и есть. После этого нужно будет авторизоваться на сервере. Пользователь вводит уникальный логин и пароль, которые выдаются ему в удостоверяющем центре. После ввода логина и пароля нужно пройти двухфакторную авторизацию. Обычно пользователь сканирует выданный ему QR-код и устанавливает приложение. Это одно общее приложение вендора подписей, которое кастомизируется под конкретный удостоверяющий центр. Сканируется второй код со ссылкой на свою ячейку в HSM. Отправляется ПИН-код на конкретную транзакцию на телефон абонента, он его использует и подтверждает себя. После этого нужно сменить пароль доступа.

FAQ про облачную [электронную] подпись / Хабр

Следующие транзакции могут быть проще: ПИН отправляется push-уведомлением. Предполагается, что если телефон защищён FaceID или распознаванием отпечатка пальца, то этого второго фактора (в сочетании с вводом логина и пароля) достаточно.

Если телефон утерян, нужно проходить процедуру с QR-кодами заново.

Заблокированный телефон без ПИНа бесполезен.

ПИН без пароля-логина бесполезен.

Если вы потеряли разблокированный телефон с фотографией логина и пароля, записанных на бумажке (реальный случай в нашем УЦ), то можно запросить блокировку доступа до выяснения.

— Как получить конверт с доступами к ОЭП?

Простой случай: заявитель (гендиректор юрлица) приходит лично с паспортом в удостоверяющий центр и получает конверт.

Сложный случай: приходит сотрудник с заверенной доверенностью, соответствующей требованиям 63-ФЗ (Об электронной подписи) и требованиям службы безопасности удостоверяющего центра.

— Это уже массовое явление?

Да. За первый месяц работы УЦ «ЕЭТП» было выпущено около тысячи сертификатов по новой технологии ОЭП. Около 70 % пользователей, оформивших электронные подписи, — это юридические лица, ещё 23 % — ИП. Более 60 % пользователей новой услуги — компании из Москвы. Есть сертификаты и в Санкт-Петербурге, Новосибирске, Хабаровске, Ростове-на-Дону.

Javascript

Некоторое время назад на Хабре появилась статья, автор которой реализовал многие криптографические форматы непосредственно на JavaScript

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

Java-апплеты


Одним из вариантов использования СКЗИ в браузере является их интеграция в Java-апплеты.

В ряде случаев СКЗИ и криптографические библиотеки не требуют установки и представляют собой нативную библиотеку. В этом случае возможна ее интеграция непосредственно «внутрь» апплета и вызов функций СКЗИ через механизм JNI. При этой схеме библиотека будет инсталлирована в профайл пользователя при первой загрузке Java-апплета в браузере и ее отдельной инсталляции не потребуется.

Другим вариантом является написание Java-апплета, который вызывает предустановленное в системе СКЗИ (CSP, JCP и др.)

Более подробно пример подобной реализации, основанный на использовании Рутокен ЭЦП и OpenSSL, описан в статье

Европейский путь

В октябре 2022 года Европейский Комитет по Стандартизации (CEN) одобрил техническую спецификацию CEN/TS 419241 «Security Requirements for Trustworthy Systems Supporting Server Signing». В этом документе приводятся требования и рекомендации к серверу электронной подписи, предназначенному для создания, в том числе, квалифицированных подписей.

Хочется отметить, что уже сейчас КриптоПро DSS в полном объёме соответствует требованиям данной спецификации в наиболее сильном варианте: требованиям Уровня 2, предъявляемым для формирования квалифицированной электронной подписи (в терминах европейского законодательства).

Одним из основных требований Уровня 2 является поддержка строгих вариантов аутентификации. В этих случаях аутентификация пользователя происходит напрямую на сервере подписи – в противоположность допустимой для Уровня 1 аутентификации в приложении, которое от своего имени обращается к серверу подписи. Все методы аутентификации, поддерживаемые КриптоПро DSS, удовлетворяют данному требованию Уровня 2.

В соответствии с этой спецификацией, пользовательские ключи подписи для формирования квалифицированной ЭП должны храниться в памяти специализированного защищенного устройства (криптографический токен, HSM). В случае КриптоПро DSS таковым устройством является программно-аппаратный криптографический модуль КриптоПро HSM – сертифицированный ФСБ России по уровню KB2 как средство ЭП.

Аутентификация пользователя на сервере электронной подписи для выполнения требований Уровня 2 обязана быть как минимум двухфакторной. КриптоПро DSS поддерживает широкий, постоянно пополняемый спектр методов аутентификации, в том числе и двухфакторных.

Помимо привычных криптографических токенов в качестве средства аутентификации может использоваться и специализированное приложение на смартфоне, такое как КриптоПро AirKey, и генераторы одноразовых паролей (OTP-токены). В документе CEN эти методы также упомянуты.

Ещё одним перспективным способом аутентификации по Уровню 2 может стать использование криптографического приложения на SIM-карте в телефоне. По нашему мнению, данный вариант использования SIM-карт с криптографией наиболее реален, поскольку построение функционально законченного СКЗИ (или средства ЭП) по новым требованиям ФСБ на базе только лишь SIM-карты вряд ли возможно.

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

В документе CEN содержится также ряд требований к формированию, обработке, использованию и удалению пользовательского ключевого материала, а также к свойствам внутренней ключевой системы сервера электронной подписи и к аудиту. Эти требования полностью и даже «с запасом» покрываются требованиями, предъявляемыми к средствам ЭП класса KB2, по которому сертифицирован отвечающий за данные вопросы ПАКМ «КриптоПро HSM».

Как работает оэп?

Рассмотрим пример, характерный для участников торгов. Допустим, поставщик направляет свое предложение на участие в тендере. До появления ОЭП подписать документ невозможно было без установленного на компьютер пользователя плагина. Этот плагин и софт локального средства сообщались друг с другом и работали в неразрывной связке.

Теперь вытащим из этой схемы флеш-накопитель: софт подключается к облачному хранилищу по защищенному каналу.

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

Как стали использовать облачные электронные подписи (оэп)?

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

В своей работе применяют ЭП онлайн-специалисты и фрилансеры, которые ведут свою деятельность легально и заключают договора с заказчиками. Физические лица могут приобрести ЭП и пользоваться услугами государственных учреждений: записываться на прием в ФНС, к врачу районной больницы, подавать заявления, справки, заходить на «Госуслуги».

Наши читатели – это, в основном, участники торгов и заказчики, которые такие торги организовывают. Они тоже пользуются ЭП для входа в личный кабинет ЕИС, на электронную торговую площадку, при непосредственном участии в торгах.

Мы уже привыкли к электронной цифровой подписи (ЭЦП), которая записана на рутокен (флеш-накопитель), принадлежит одному конкретному владельцу и обеспечивает безопасность данных о нем. Сегодня аббревиатура ЭЦП уже не используется, так говорить неправильно.

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

Для ЭП на носителе необходима установка специальных программ на компьютер пользователя (СКЗИ) и дополнительных надстроек. В связи с тем, что на смену таким приложениям пришли облачные приложения, у IT-разработчиков появилось желание внедрить их в работу с ОЭП.

Как установить оэп и начать работать?

Для работы на локальном компьютере потребуется:

Чтобы пользоваться ОЭП на мобильном устройстве, оно должно работать на базе операционных систем не ниже Android 7.0 или iOS 8/9/10/11. Кроме этого, нужно установить приложение MyDss

Установка и настройка на смартфоне приложения MyDss

  1. Зайдите в приложение Play Market или Apple Store (зависит от устройства, которое Вы используете).
  2. В поисковую строку вбейте «MyDss» и запустите установку приложения.
  3. После завершения скачивания нажмите кнопку «Открыть».

4. Для начала работы система уведомит вас о необходимости сканирования QR-кода. Предоставьте камере доступ к этому действию.

5. Считайте QR-код с сертификата, который получили в УЦ.

6. Придумайте имя для сохраняемого ключа, например, «ОЭП для торгов».

7. Выберите способ авторизации (с паролем, без пароля, отпечаток пальца, Face ID).

8. Программа готова к использованию.

Установка СКЗИ КриптоПро CSP 5

Чтобы пользоваться облачной ЭП потребуется наличие операционной системы Windows 7, 8, 8.1 или 10. Проверьте, что Ваша ОС подходит для работы с ОЭП. Для этого откройте «Центр обновлений Windows» и запустите поиск и обновления компонентов Windows.

Криптопро csp 5.0: «облачный» провайдер

Криптопровайдер КриптоПро CSP 5.0 обладает довольно широкой функциональностью, поэтому мы решили выпустить статью-инструкцию, которая покажет, как можно протестировать наиболее существенные нововведения.

Начнём с самой крупной инновации — работы с «облачными» токенами: удалёнными хранилищами неизвлекаемых ключей. В качестве непосредственного хранилища ключей выступает защищённый сервер КриптоПро HSM, к которому подключён сервер удалённой подписи КриптоПро DSS. Использование КриптоПро CSP 5.0 позволяет получить доступ к ключам HSM через использование стандартного интерфейса CryptoAPI.

Данная инструкция покажет, как за пару кликов научить CSP видеть ваши ключи. В качестве примера мы будем пользоваться тестовым сервером dss.ecp64.ru. Заранее заметим, что данный тестовый сервис поддерживает только ключи алгоритма ГОСТ Р 34.10-2001.

Создание тестового пользователя

Первым делом заведём пользователя на тестовом сервере. Для этого зайдём в его веб-интерфейс и нажмём кнопку Регистрация (рис. 1).

Заполним форму регистрации и подтвердим создание пользователя
(рис. 2).

После регистрации мы попадаем на основной экран пользователя, где перечислены сертификаты, соответствующие хранящимся на сервере закрытым ключам. У нового пользователя, разумеется, сертификатов нет. Есть два пути, как их добавить: скопировать существующий контейнер и создать новый. Рассмотрим оба.

Копирование пользовательского контейнера

Прежде всего, у вас должен быть ключевой контейнер формата КриптоПро, а сертификат для него должен быть установлен в системное хранилище. Если сертификата нет, его можно выпустить на нашем тестовом сервисе (открывать через Internet Explorer). При генерации не забудьте пометить ключ как экспортируемый.

Для переноса ключа открываем системное хранилище сертификатов (Win R > certmgr.msc > ОК), выбираем сертификат, нажимаем правой кнопкой >Все задачи > Экспорт (рис. 3).

В мастере экспорта сертификатов указываем, что хотим экспортировать сертификат с закрытым ключом и выполняем экспорт в формат PFX, установив произвольный пароль.

Возвращаемся на экран управления DSS и нажимаем кнопку Установить сертификат (рис. 4).

Здесь выбираем экспортированный PFX-контейнер и нажимаем кнопку Загрузить сертификат. В результате в списке сертификатов должен появиться ваш скопированный сертификат, который можно просмотреть.

Создание запроса через DSS

Второй путь получения сертификата — это создание запроса на удовтоверяющий центр (УЦ), который непосредственно подключён к DSS.

Нажимаем Создать запрос на сертификат, вводим данные (обязательно только поле CN) и создаём запрос. Во всплывающем окне PIN-код можно оставить пустым (рис. 5). Выпущенный сертификат сразу попадает в список и также доступен для просмотра.

Подключение к CSP

Через эту же веб-форму можно напрямую подписывать и зашифровывать документы, проверять данные и т. д., но если вам нужно использовать ключи во внешних приложениях, нужно зарегистрировать эти сертификаты в CSP. Самый простой способ — воспользоваться утилитой CryptoPro Tools (Инструменты КриптоПро), входящей в состав КриптоПро CSP 5.0.

Запускаем её из меню Пуск и выбираем пункт Облачный провайдер (рис. 6).

В появившемся окне вбиваем адреса используемых сервисов авторизации и доступа к DSS. Для тестового сервиса пользуемся адресами по умолчанию.

Нажимаем кнопку Установить сертификаты. Если вы правильно указали адреса, должно появиться браузерное окно аутентификации на DSS. Вводим учётные данные, указанные при регистрации (рис. 7).

В процессе установки сертификатов с сервера будут скачаны и установлены цепочки сертификатов, что может приводить к окнам с предупреждениями.

Если всё настроено корректно, приложение сообщит об успешной установке сертификатов и их можно будет просмотреть на вкладке Контейнеры или в любом приложении, использующем CryptoAPI (рис. 8).

Теперь данные контейнеры можно использовать в любых приложениях. Если, например, установленный сертификат является квалифицированным, то с его помощью можно подключиться к сайту gosuslugi.ru или nalog.ru.

На базе nss

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

СпецификацияNSS c использованием PKCS#11-токенов, программных и аппаратных
ПлатформыСемейство Windows, GNULinux, OS X, iOS, Android
Алгоритмы и криптографические протоколыЭЦП, шифрование, хэш-функция, имитозащита, HMAC, VKO, TLS
Интеграция с PKIX.509, PKCS#10, CMS, CRL
Механизмы ЭЦПВызов из JavaScript встроенных в браузер функций
TLS-ГОСТВстроен в библиотеку и поддерживается браузером
Форматы защищенных сообщенийPKCS#7, CMS
Интеграция с браузером100%
Мобильные платформыiOS, Android
Хранилища ключейБраузерное хранилище, USB-токены
Взаимодействие с USB-токенамиХранилище ключей и сертификатов
Использование аппаратной реализации алгоритмов
ИнсталляцияПрограмма установки, в целом, не требуются права системного администратор
Portable. Например, запуск браузера с FLASH-памяти USB-токена
Примеры (ГОСТ)Mozilla FireFox, Chromium от Лисси
Проект atoken от R-Альфа (Mozilla FireFox)
КриптоFox (PKCS11-токен на базе КриптоПро CSP)

Проблемы:

Плюсы:

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

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

Операции:

Примеры:

Начнём с главного

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

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

То же самое происходит и с ключом ЭП, передаваемым в облако. Более того, ключ ЭП – это не просто конфиденциальная информация. Ключ должен быть доступен только одному лицу – его владельцу. Таким образом, доверие к облачной подписи определяется не только личной ответственностью пользователя, но и безопасностью хранения и использования ключа на сервере и надежностью механизмов аутентификации.

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

Оба упомянутых выше аспекта безопасности облачной ЭП в частности являются предметом исследований, проводимых в ходе испытаний КриптоПро DSS. В то же время, стоит отметить, что существенная часть этих вопросов уже рассмотрена в рамках тематических исследований СКЗИ «ПАКМ КриптоПро HSM», на котором основывается КриптоПро DSS.

В нашей стране пока слабо проработаны организационно-правовые аспекты применения облачной ЭП, поэтому в данной статье мы рассмотрим КриптоПро DSS с точки зрения требований к серверу подписи, разработанных Европейским Комитетом по Стандартизации (CEN).

Наше будущее

Решение КриптоПро DSS поддерживает широкий набор методов аутентификации, среди которых для каждой задачи возможно подобрать подходящий. Надёжность наиболее безопасных из них соответствует самым строгим критериям европейских требований CEN/TS 419241 и, как мы рассчитываем, в недалёком будущем будет подтверждена сертификатом соответствия ФСБ России.

Алексей Голдбергс,

 заместитель технического директора

ООО «КРИПТО-ПРО»

Станислав Смышляев, к.ф.-м.н.,

начальник отдела защиты информации

ООО «КРИПТО-ПРО»

Павел Смирнов, к.т.н.,

заместитель начальника отдела разработок

ООО «КРИПТО-ПРО»

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

Концепция облачной подпись предполагает хранение закрытого ключа и выполнение процедуры подписи/шифрования данных непосредственно на сервере.

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

Ответы на самые распространенные вопросы

А можно без софта на локальном компьютере?

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

В чем отличие стандартной ЭП от облачной?

Оба эти варианта имеют общее ядро с сертификатом и уровнем безопасности. По своей сути, они аналогичны, просто меняется схема внутреннего API-шифрования при кодировке информации. В первом случае ключ извлекается из локального средства, а во втором – с виртуального (удаленного).

Для использования облачной ЭП тоже нужна авторизация?

Да. Однако теперь авторизация имеет два уровня защиты, и нет привязки к компьютеру. При этом авторизация для пользователя не вызовет никаких сложностей:

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

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

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

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

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

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

Предисловие

Напомним, что PKCS#11 (Cryptoki) является стандартом, разработанным RSA Laboratories, для взаимодействия программ с криптографическими токенами, смарт-картами и другими аналогичными устройствами с помощью унифицированного программного интерфейса, который реализуется через библиотеки.

Криптографические токены обеспечивают как хранение сертификатов и ключевых пар (открытого и закрытого ключа), так и выполнение криптографических операций в соответствии со стандартом PKCS#11.

imagePKCS#11 v.2.40, дополненного поддержкой российских криптографических алгоритмов в соответствии со спецификациями, выработанными Техническим комитетом по стандартизации (ТК 26) «Криптографическая защита информации». Облачный сервис LS11CLOUD поддерживает алгоритмы ГОСТ Р 34.10-2022, ГОСТ Р 34.11-2022, ГОСТ Р 34.12-2022 и ГОСТ Р 34.13-2022, а также сопутствующие алгоритмы и параметры, определенные руководящими документами ТК 26.

Безусловным преимуществом облачного токена является то, что теперь пользователю не нужно носить с собой токен/смарткарту, заботиться о его сохранности. Имея личный токен в облаке, пользователь может иметь к нему доступ к нему и с домашнего компьютера, и с ноутбука, и с мобильного устройства.

Обеспечение безопасного удаленного взаимодействия с защищенным личным контейнером криптографических объектов (токеном) по шифрованному сетевому каналу осуществляется с применением протокола аутентификации SESPAKE (Security Evaluated Standardized Password-Authenticated Key Exchange), рекомендованного ТК 26.

На стороне пользователя основная функциональность обеспечивается динамической библиотекой ls11cloud со стандартным программным интерфейсом pkcs#11. Для получения личного облачного токена пользователю необходимо зарегистрироваться на облачном сервисе LS11CLOUD, после чего провести инициализацию и конфигурирование личного токена на облачном сервисе.

Преимущества

  1. Владелец стандартной ЭП на USB-носителе при утере флешки должен будет получить новый ключ. Владелец облачной ЭП просто поменяет пароль.
  2. Мобильность пользователя. Раньше нужно было находиться поблизости к компьютеру, на который установлены все программы и надстройки. Теперь при использовании ОЭП привязка к рабочему месту не нужна.
  3. Нет привязки к браузеру: раньше это был IE, а это вызывало трудности еще на этапе выбора ОС: Linux-админы находили пути обхода, а вот на Mac-устройствах это невозможно.
  4. Нет территориальной привязки. Пользователь не обязательно должен находиться в РФ. Раньше владельцы должны были находиться внутри страны, ввиду особенностей защиты подписей на носителях.
  5. Двухуровневая защита обеспечивает более надежную сохранность информации о пользователе.
  6. Возможность подписывать документы через приложение на смартфоне.

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

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

Установка КриптоПро.NET позволяет использовать российские криптоалгоритмы, например,

в WEB-сервисах на базе ASP.NET, SOAP-сервисах, в клиентских браузерных приложениях MS.Silverlight.

ПлатформыMicrosoft.NET 2.0 и старше
Алгоритмы и криптографические протоколыЭЦП, шифрование, хэш-функция, имитозащита, HMAC, VKO, TLS, SOAP
Интеграция с PKIX.509, PKCS#10, CMS, CRL
Механизмы ЭЦПНабор классов. Есть полностью “управляемые” реализации. Есть реализации на базе Crypto API 2.0 и CNG
Механизмы аутентификацииклиентская аутентификация в рамках TLS
аутентификация в SOAP-сервисах
собственные механизмы аутентификации на базе ЭЦП случайных данных
TLS-ГОСТВстраивание
Форматы защищенных сообщенийPKCS#7, CMS, XMLSec, SOAP (OASIS Standard 200401), S/MIME
Интеграция с браузеромЭЦП и шифрование через MS Silverlight
Хранилища ключейРеестр, UBS-токены
Взаимодействие с USB-токенамиХранилище ключей и сертификатов
Использование аппаратной реализации алгоритмов
Через Crypto API 2.0
ПриложенияMicrosoft Lync 2022, Microsoft Office Forms Server 2007 и Microsoft SharePoint 2022, Microsoft XPS Viewer
ИнсталляцияMicrosoft. NET включен в состав Windows, начиная с Windows Vista. Поддержка российских криптоалгоритмов требует установки дополнительного ПО
Примеры (ГОСТ)КриптоПро. NET (на базе КриптоПро CSP)

Создание запроса через dss

Второй путь получения сертификата — это создание запроса на УЦ, который непосредственно подключен к DSS.

Нажимаем «Создать запрос на сертификат», вводим данные (обязательно только поле CN) и создаём запрос. Во всплывающем окне ПИН-код можно оставить пустым. 

Выпущенный сертификат сразу попадает в список и также доступен для просмотра.

Создание тестового пользователя

Первым делом, заведем пользователя на тестовом сервере. Для этого зайдем в его веб-интерфейс и нажмем кнопку «Регистрация»:

Заполним форму регистрации и подтвердим создание пользователя:

После регистрации мы попадаем на основной экран пользователя, где перечислены сертификаты, соответствующие хранящимся на сервере закрытым ключам. У нового пользователя, разумеется, сертификатов нет. Есть два пути, как их добавить: скопировать существующий контейнер и создать новый. Рассмотрим оба.

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

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

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

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

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

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

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

Установка первого личного сертификата в облачный токен

Теперь, когда мы зарегистрировались в облаке и создали в нем свой личный облачный токен, можно приступать к его использованию. Для тестирования возьмем браузер

и почтового клиента Redfoxmail-52, которые созданы на базе Mozilla Firefox и Mozilla Thunderbird, с поддержкой российской криптографии на токенах/смарткартах PKCS#11.

Тестирование будем проводить на платформе WIN32.

Заключение

Итак, можно говорить о том, что миф становится реальностью. Основной сферой применения облачного токена LS11CLOUD может стать внутрикорпоративный документооборот, защищенная почта, банковская сфера.

Облачный сервис LS11CLOUD с его облачными токенами может оказаться очень полезным разработчикам приложений с использованием токенов/смарткарт PKCS#11.

imageпортал ГОСУСЛУГ. OC — Linux.

Оцените статью
ЭЦП64
Добавить комментарий