Электронная подпись (ЭП) в клиент-серверных приложениях | Сигнал-КОМ

Электронная подпись (ЭП) в клиент-серверных приложениях | Сигнал-КОМ Электронная цифровая подпись

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

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

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

«облачная» электронная подпись: путь технологии

20 ноября 2021

«Облачная» электронная подпись: путь технологии

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

Для начала обозначим суть фразы «выдана «облачная» электронная подпись» (ЭП или, более привычное для участников рынка, ЭЦП):

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

Справочно:

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


Предыстория

Непростой путь данной технологии начался еще в 2021 — 2021 годах, когда многие компании пытались реализовать решение, позволяющее работать с электронной подписью в «облаке». Данный период был ознаменован активным развитием проекта «электронного правительства». Специалисты и пользователи рассчитывали, что большинство сервисов в нем будет реализовано именно с помощью «облачных» технологий, что расширило бы возможности предоставления услуг. Тем не менее электронное правительство было запущено без электронной подписи в «облаке», и всем пользователям (корпоративным и частным) портала госуслуг все еще предлагаются привычные токены. Выдача этих носителей ключей ЭЦП наряду со смарт-картами осуществляется в соответствии с правилами и требованиями регуляторов отрасли, и они подлежат строгому учету.

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

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

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

Становление технологии

Одной из первых вывела «облачные» технологии на рынок ЭЦП компания КриптоПро еще в 2021 — 2021 году.

Решением, которое используется и сейчас, стал программно-аппаратный комплекс, состоящий из КриптоПро DSS и модуля КриптоПро HSM.

КриптоПро DSS (Digital Signature Server) — сервер электронной подписи (условно можно назвать программной надстройкой).

КриптоПро DSS

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

КриптоПро HSM (Hardware Security Module) — программно-аппаратный криптографический модуль (непосредственно в нем защищенно хранятся ключи электронной подписи).

КриптоПро HSM

Информация об алгоритмах, областях применения, вариантах комплектации и другом доступна по ссылке.

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

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

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

Итак, каким образом пользователи, обладающие ЭЦП, могли бы получать доступ к ключам, хранящимся в «облаке»?

Изначально было предложено несколько вариантов:

1 – многоразовый пароль. В этом случае для подписания чего-либо в «облаке» пользователь каждый раз должен был аутентифицироваться в нем с помощью фиксированной комбинации символов. Множество инцидентов, связанных с хищением или непреднамеренной утерей многоразовых паролей, сигнализировало о недостаточном уровне безопасности данного варианта.

2 – одноразовый пароль. В целях аутентификации в «облаке» способ предусматривал передачу каждый раз уникальной последовательности символов через SMS или ее генерацию ОТР-токеном (One Time Password). Брешь в безопасности данного метода пробивала невозможность привязки одноразового пароля к конкретной операции. Мошенникам было доступно множество вариантов хищения, начиная с фишинга (создание поддельных сайтов и приложений, которым пользователь сообщает пароль) и заканчивая социальной инженерией (манипуляция поведением людей, позволяющая преступникам получить код при личном общении). В качестве дополнительной защиты можно было использовать привязку к реквизитам при отправке аутентифицирующего кода посредством SMS, но злоумышленники разработали ряд способов, позволяющих перехватить и подобные сообщения.

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

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

Решение, продиктованное рынком

В целях нивелирования уязвимостей предложенных ранее вариантов по реализации доступа к «облачной» квалифицированной электронной подписи было разработано комплексное решение КриптоПро myDSS. Две главных компоненты — PayControl и КриптоПро DSS совместно с HSM.

PayControl является программным комплексом, предназначенным для подтверждения пользователем операций в системах ДБО и/или ЭДО без использования вспомогательных устройств (токены, смарт-карты, OTP-генераторы). Комплекс состоит из двух частей:

  1. серверная часть,
  2. клиентская часть —  приложение для мобильных платформ iOS (8.0 и выше) и Android (4.0 и выше).
Читайте также:  Как при помощи токена сделать Windows домен безопаснее? Часть 1 / Хабр

Совместная разработка компаний SafeTech и КриптоПро — КриптоПро myDSS — обеспечивает удобный, мобильный и безопасный доступ к функциям подписания и построена с помощью передовых технологий «облачного» управления ключами и функциями ЭЦП.

В комплексном решении для того, чтобы «облако» (серверная часть) выполнило подписание, ему необходима санкция на выполнение этого действия, которая зависит от четырех составляющих:

  1. времени,
  2. содержания подписываемого документа,
  3. уникальных признаков гаджета,
  4. уникального ключа, который хранится в защищенной области смартфона, планшета, либо другого устройства пользователя.

Главные преимущества системы:

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

Все комплексное решение КриптоПро myDSS, включая:

– серверную часть, в которой в HSM хранятся ключи электронной подписи,

– систему, управляющую процессами формирования подписи на стороне сервера,

– приложение для смартфона, которое визуализирует пользователю подписываемый документ и вырабатывает санкции на подписание,

– защищенные каналы взаимодействия клиентской и серверной частей,

является полноценным средством электронной подписи. Условно его можно назвать «большим токеном».

«Облачная» электронная подпись: квалифицированная или неквалифицированная?

КриптоПро myDSS уже отправлено на рассмотрение в ФСБ России. На данный момент получен сертификат на КриптоПро DSS (серверную часть), на очереди сертификация комплексного решения в целом. А значит рынок находится в одном шаге от «облачной» квалифицированной ЭЦП. «Новинка» позволит в любое время, в любом месте и на любом устройстве безопасно подписывать документы, наделяя их юридической значимостью.

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


Если вы заинтересованы в данном продукте и хотели бы приобрести его сразу после получения сертификата ФСБ на все решение, который позволит ставить «облачную» квалифицированную электронную подпись, то отправляйте предварительные заявки на почту iecp@aetp.ru Сразу после завершения процедуры сертификации вам будет направлено предложение приобрести КриптоПро myDSS. В теле письма укажите: ФИО, физическое или юридическое лицо вы представляете, ИНН, контактный телефон, назначение ЭЦП, электронный адрес.


Статья подготовлена редакцией Единого портала Электронной подписи ecpexpert.ru с использованием материалов компании SafeTech.

При полном или частичном использовании материала гиперссылка на www.ecpexpert.ru обязательна.

1с-эдо

В случае, если Вы используете программу 1С в серверном режиме, у Вас есть возможность настроить и серверное подписание электронных документов, т.е. когда и криптопровайдер, и электронные подписи установлены только на сервере (на “клиентах” их нет).
Принципиальное значение в реализации данного варианта имеет то, от имени какого пользователя осуществляется настройка криптографии на сервере.
Настройка должна быть выполнена от имени того пользователя, под которым запускается служба “Агент сервера 1С:Предприятия”.
По умолчанию данный пользователь именуется “USR1CV8”, см. Рис. 1.

Электронная подпись (ЭП) в клиент-серверных приложениях | Сигнал-КОМ

Рис. 1.

Эта служба может быть запущена и от имени другого пользователя (например, “Administrator”) – данное правило задается системным администратором на свое усмотрение.
Поэтому, перед началом настройки серверной криптографии, обязательно нужно уточнить вышеописанный момент.
Определившись с пользователем, можно начинать.

1. Проходим на сервере аутентификацию под пользователем, под которым запускается служба “Агент сервера 1С:Предприятия”.
2. Устанавливаем криптопровайдер.
3. Месторасположение контейнеров с закрытыми ключами (реестр, жесткий диск, внешний носитель) может быть любым, с условием, что они доступны пользователю, под которым запускается служба “Агент сервера 1С:Предприятия”.
4. Устанавливаем личные сертификаты, корневые сертификаты, списки отозванных сертификатов. При этом установку можно проводить “для текущего пользователя” – нет необходимости устанавливать их “для локального компьютера”.
5. Помечаем в программе 1С галочками пункты “Проверять подписи и сертификаты на сервере” и “Подписывать на сервере” (Администрирование – Обмен электронными документами – Электронная подпись и шифрование – Настройки электронной подписи и шифрования – закладка “Программы”).

Система настроена. Подписание на “клиентах” должно проходить успешно.

При тестировании сертификата на “клиенте” нужно обращать внимание только на корректность прохождения этапов теста на сервере, см. Рис. 2.

Электронная подпись (ЭП) в клиент-серверных приложениях | Сигнал-КОМ

Рис. 2.

Генерирование открытого и секретного ключей

Итак, вы решили самостоятельно изготовить усиленную неквалифицированную электронную подпись и научиться подписывать ею свои документы. Начать необходимо, конечно, с генерирования пары ключей, открытого (public key) и секретного (private key).

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

Одной из таких свободных библиотек является выпущенная в 1999 году GNU Privacy Guard (GnuPG, или GPG). Утилита GPG традиционно входит в состав почти всех дистрибутивов Линукса; для работы из-под Windows необходимо установить, например, gpg4win. Ниже будет описана работа из-под Линукса.

Сначала сгенерируем собственно ключи, подав (из-под обычного юзера, не из-под root’а) команду

gpg --full-generate-key

В процессе генерирования вам будет предложено ответить на ряд вопросов:

  • тип ключей можно оставить «RSA и RSA (по умолчанию)»;
  • длину ключа можно оставить по умолчанию, но вполне достаточно и 2048 бит;
  • в качестве срока действия ключа для личного использования можно выбрать «не ограничен»;
  • в качестве идентификатора пользователя можно указать свои фамилию, имя и отчество, например, Иван Иванович Иванов; адрес электронной почты можно не указывать;
  • в качестве примечания можно указать город, либо иную дополнительную информацию.

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

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

gpg --export -a "Иван Иванович Иванов" > public.key
gpg --export-secret-key -a "Иван Иванович Иванов" > private.key

Понятно, что private.key вы должны хранить в секрете, а вот public.key вы можете открыто публиковать и рассылать всем желающим.

Комплект «облачная электронная подпись»

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

Где применяется: более двухсот сфер, в том числе государственные и коммерческие торги.

Читайте также:  Вопросы и ответы по взаимодействию с Рофинмониторинг

Кто может применять: заказчики и участники электронных торгов.

Где получить: процедура занимает около 30 минут . Присутствие в одной из точек выдачи Удостоверяющего центра АО «ЕЭТП» необходимо только для подтверждения личности и получения доступов к подписи.

Конфигурирование openssl

Openssl поддерживает российские криптоалгоритмы, начиная с версии 1.0. Для того, чтобы их использовать, в openssl требуется подгружать engine gost. В большинстве дистрибутивов openssl эта библиотека присутствует. Чтобы engine подгружалась, можно прописать ее в конфигурационном файле openssl:

[openssl_def]
engines = engine_section

[engine_section]
gost  = gost_section

[gost_section]
engine_id  = gost
default_algorithms = ALL

Если конфигурационный файл openssl не расположен в стандартном месте, то путь к нему можно задать через переменную окружения OPENSSL_CONF.

Другим вариантом подгрузки engine gost является ее передача в параметрах командной строки утилиты openssl.

Если engine gost не расположена в стандартном месте, то через переменную окружения OPENSSL_ENGINES можно задать путь к директории, в которой openssl будет ее искать.

Для получения информации о том, успешен ли был вызов утилиты openssl или нет, с возможностью уточнения ошибки, требуется парсить stdout и stderror. В конце статьи приведена ссылка на PHP-скрипт, который использует данную утилиту.

Теперь перейдем к реализации законченных пользовательских сценариев.

Подписание документа

Нет ничего проще, чем создать отсоединенную ЭЦП в текстовом (ASCII) формате:

gpg -ba имя_подписываемого_файла

Файл с подписью будет создан в той же папке, где находится подписываемый файл и будет иметь расширение asc. Если, например, вы подписали файл privet.doc, то файл подписи будет иметь имя privet.doc.asc. Можно, следуя традиции, переименовать его в privet.sig, хотя это непринципиально.

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

#!/usr/bin/python
# -*- coding: utf-8 -*-
from Tkinter import *
from tkFileDialog import *
import os, sys, tkMessageBox

def die(event):
    sys.exit(0)

root = Tk()
w = root.winfo_screenwidth()//2 - 400
h = root.winfo_screenheight()//2 - 300
root.geometry("800x600 {} {}".format(w, h))
root.title("Подписать документ")

flName = askopenfilename(title="Что подписываем?")

if flName:
    os.system("gpg -ba "   flName)
    button = Button(text="ЭЦП создана")
    button.bind("<Button-1>", die)
    button.pack(expand=YES, anchor=CENTER)
else:
    die()

root.mainloop()

Поиск подключенных устройств

Любой клиентский сценарий начинается с поиска подключенных к компьютеру USB-устройств Рутокен. В контексте данной статьи акцент делается на устройство Рутокен ЭЦП.

var devices = Array();

try 
{
    devices = plugin.enumerateDevices();
}
catch (error) 
{
    console.log(error);
}

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

Рутокен Плагин определяет все подключенные к компьютеру USВ-устройства Рутокен ЭЦП, Рутокен PINPad, Рутокен WEB. Поэтому следующим шагом следует определить тип устройства.

Полезные ссылки

Данные ссылки могут быть полезны разработчикам инфосистем с поддержкой ЭЦП на базе Рутокен Плагин и openssl:

Демосистема Рутокен ПлагинWEB-сервис генерации ключей, формирования запросов, управления сертификатами, формирования шаблонов запросов на сертификаты Документация на Рутокен ПлагинДокументация по использованию утилиты openssl с российскими крипталгоритмамиПример скрипта на PHP, использующего утилиту openssl

Получение информации об устройстве

Для определения типа устройства следует использовать функцию

с параметром TOKEN_INFO_DEVICE_TYPE. Значение этой константы содержится в объекте плагина.

var type;

try
{  
  type = plugin.getDeviceInfo(deviceId, plugin.TOKEN_INFO_DEVICE_TYPE);
}
catch (error) 
{
    console.log(error);
}

switch (type) 
{
    case plugin.TOKEN_TYPE_UNKNOWN:
        message = "Неизвестное устройство";
        break;
    case plugin.TOKEN_TYPE_RUTOKEN_ECP:
        message = "Рутокен ЭЦП";
        break;
    case plugin.TOKEN_TYPE_RUTOKEN_WEB:
        message = "Рутокен Web";
        break;
    case plugin.TOKEN_TYPE_RUTOKEN_PINPAD_2:
        message = "Рутокен PINPad";
        break;
}

Также с помощью функции getDeviceInfo можно получить:

Примеры криптоплагинов

Криптоплагины с использованием библиотеки Message-PRO:

SC Signature Plug-in– обеспечивает формирование ЭП для файлов и строковых данных;

SC BCO Plug-in (частное решение для одного из банков)  — предназначен для использования в системе БКО (Банк-Клиент Онлайн) для генерации ключей и запросов на сертификаты, управления ключевой информацией, формирования ЭП для файлов и строковых данных; 

SC KeyGen Plug-in – предназначен для использования в составе Web-приложения Notary-PRO Web Pages для генерации ключей и запросов на сертификаты.

Основные особенности:

    • библиотека Message-PRO входит в состав криптоплагинов;
    • решения являются кроссплатформенными и  мультибраузерными;

Плагин с использованием криптопровайдеров:

SC Signature CSP Plug-in — предназначен для формирования ЭП с использованием криптопровайдеров различных разработчиков, в том числе Signal-COM CSP.

Основные особенности:

    • требует предустановки криптопровайдера;
    • решение мультибраузерное для платформ на базе ОС Windows;
    • плагин распространяется бесплатно.

Все, указанные выше программные продукты, предполагают использование различных типов ключевых носителей (Рутокен, eToken PRO (Java), USB Flash-накопителей и др.) и криптографических токенов (Рутокен ЭЦП, JaCarta ГОСТ, eToken ГОСТ, MS_Key и др.).

Проверка подписи

Вряд ли, конечно, вам самому придется проверять достоверность собственной электронной подписи, но если вдруг (на всякий случай) вам захочется это сделать, то нет ничего проще:

gpg --verify имя_файла_подписи имя_файла_документа

В реальности гораздо полезнее опубликовать где-нибудь в открытом доступе (например, на вашем персональном сайте или на сайте вашей организации):

  • открытый ключ public.key для того, чтобы все желающие могли проверить (верифицировать) вашу подпись с использованием, например, той же GPG;
  • веб-интерфейс для проверки вашей подписи всеми желающими, не являющимися специалистами.

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

К счастью для нас, имеется свободная библиотека OpenPGP.js; скачиваем самый маленький по размеру (на момент написания данного туториала — 506 КБ) файл dist/lightweight/openpgp.min.js и пишем несложную html-страничку (для упрощения восприятия я удалил все описания стилей и очевидные meta-тэги):

Работа с ключевыми парами гост р 34.10-2001

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

var keys = Array();

try
{   
    plugin.login(deviceId, "12345678");
    keys = plugin.enumerateKeys(deviceId, null);
}
catch (error) 
{
    console.log(error);
}

2. Для генерации ключевой пары требуется ввод PIN-кода. При генерации ключа параметры могут быть выбраны из набора:

  • A: id-GostR3410-2001-CryptoPro-A-ParamSet
  • B: id-GostR3410-2001-CryptoPro-B-ParamSet
  • C: id-GostR3410-2001-CryptoPro-C-ParamSet
  • XA: id-GostR3410-2001-CryptoPro-XchA-ParamSet
  • XB: id-GostR3410-2001-CryptoPro-XchB-ParamSet

Пример генерации ключевой пары ГОСТ Р 34.10-2001:

var options = {};
var keyId;

try 
{
    keyId = plugin.generateKeyPair(deviceId, "A",  null, options);
}
catch (error) 
{
    console.log(error);
}

3. С помощью функции deleteKeyPair ключевая пара может быть удалена с токена.

Работа с сертификатами

1. На токене могут храниться 3 категории сертификатов:

Расшифрование данных, полученных с сервера, на клиенте

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

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

Читайте также:  12.08.2021 Минцифры разъяснило порядок работы с электронными подписями после 1 января 2022 года :: Разъяснения государственных органов

Шифрование данных на сервере для клиента:

Сертификат выдается при регистрации в системе

  • Получаем список подключенных к компьютеру устройств Рутокен ЭЦП
  • Генерируем ключевую пару ГОСТ Р 34.10-2001 на выбранном Рутокен ЭЦП
  • Cоздаем запрос PKCS#10 на сертификат для сгенерированной ключевой пары
  • Отправляем запрос на сервер
  • На сервере создаем сертификат, привязываем к аккаунту (сам сертификат или его дескриптор). Следует отметить, что дескрипторы сертификатов, полученные при вызове функции enumerateCertificates, являются уникальными и неизменными
  • Отправляем сертификат на клиент
  • На клиенте визуализируем полученный сертификат
  • Импортируем полученный сертификат в Рутокен ЭЦП

Последовательность вызовов в клиентском скрипте будет следующей:

Далее запрос отправляется на сервер, где на его основе выдается сертификат.Для этого на сервере должен быть установлен и правильно сконфигурирован openssl версии от 1.0 и развернут функционал УЦ.

1. Генерация улюча УЦ:

openssl genpkey -engine gost -algorithm GOST2001 -pkeyopt paramset:A -out ca.key


После этого в файле ca.key будет создан закрытый ключ

2. Создание самоподписанного сертификата УЦ:

openssl req -engine gost -x509 -new -key ca.key -out ca.crt

После ввода необходимой информации об издателе в файле ca.crt будет создан сертификат УЦ.

Сертификат уже имеется на токене, выдан внешним уц


Ключевая пара при этом должна быть создана в формате, совместимом с библиотекой rtPKCS11ECP для Рутокен ЭЦП.

Последовательность вызовов на клиенте:
Электронная подпись (ЭП) в клиент-серверных приложениях | Сигнал-КОМ

Подпись получается в base64-формате. При проверке ее на сервере с помощью openssl подпись следует обрамить заголовками, чтобы сделать из нее PEM. Выглядеть подобная подпись будет примерно так:

-----BEGIN CMS-----
MIIDUQYJKoZIhvcNAQcCoIIDQjCCAz4CAQExDDAKBgYqhQMCAgkFADCBygYJKoZI
hvcNAQcBoIG8BIG5PCFQSU5QQURGSUxFIFVURjg PFY 0JLRi9C/0L7Qu9C90LjR
gtGMINCw0YPRgtC10L3RgtC40YTQuNC60LDRhtC40Y4/PCE c2VydmVyLXJhbmRv
bS1kYXRhZTI6ZGE6MmM6MDU6MGI6MzY6MjU6MzQ6YzM6NDk6Nzk6Mzk6YmI6MmY6
YzU6Mzc6ZGI6MzA6MTQ6NDQ6ODM6NjY6Njk6NmI6OWY6YTU6MDk6MzQ6YmY6YzQ6
NzY6YzmgggGeMIIBmjCCAUegAwIBAgIBATAKBgYqhQMCAgMFADBUMQswCQYDVQQG
EwJSVTEPMA0GA1UEBxMGTW9zY293MSIwIAYDVQQKFBlPT08gIkdhcmFudC1QYXJr
LVRlbGVjb20iMRAwDgYDVQQDEwdUZXN0IENBMB4XDTE0MTIyMjE2NTEyNVoXDTE1
MTIyMjE2NTEyNVowEDEOMAwGA1UEAxMFZmZmZmYwYzAcBgYqhQMCAhMwEgYHKoUD
AgIjAQYHKoUDAgIeAQNDAARADKA/O1Zw50PzMpcNkWnW39mAJcTehAhkQ2Vg7bHk
IwIdf7zPe2PxHyAr6lH stqdACK6sFYmkZ58cBjzL0WBwaNEMEIwJQYDVR0lBB4w
HAYIKwYBBQUHAwIGCCsGAQUFBwMEBgYpAQEBAQIwCwYDVR0PBAQDAgKkMAwGA1Ud
EwEB/wQCMAAwCgYGKoUDAgIDBQADQQD5TY55KbwADGKJRK bwCGZw24sdIyayIX5
dn9hrKkNrZsWdetWY3KJFylSulykS/dfJ871IT 8dXPU5A7WqG4 MYG7MIG4AgEB
MFkwVDELMAkGA1UEBhMCUlUxDzANBgNVBAcTBk1vc2NvdzEiMCAGA1UEChQZT09P
ICJHYXJhbnQtUGFyay1UZWxlY29tIjEQMA4GA1UEAxMHVGVzdCBDQQIBATAKBgYq
hQMCAgkFADAKBgYqhQMCAhMFAARAco5PumEfUYVcLMb1cnzETNOuWC8Goda8pdUL
W5ASK tztCwM7wpXgAy Y6/sLtClO9sh8dKnAaEY2Yavg3altQ==
-----END CMS-----

Проверка подписи на сервере:

Скзи на стороне  сервера

Решения для формирования и проверки ЭП на сервере:

2.1 Криптографическая библиотека Message-PRO

Основные особенности:

  • поставляется на основе серверной лицензии;
  • встраивается в серверные приложения;
  • поддержка платформ на базе ОС Windows, Linux, FreeBSD, Solaris;

Примечание: для поддержки протокола SSL/TLS на стороне сервера дополнительно может быть использована криптобиблиотека SSL-PRO, поставляемая на основе серверной лицензии.

Основные особенности:

  • поставляется на основе серверной лицензии;
  • встраивается в серверные приложения с поддержкой интерфейса CryptoAPI 2.0;
  • поддерживает протокол SSL/TLS;
  • поддержка платформ на базе ОС Windows Server.

Основные особенности:

  • автономное, серверное, высокопроизводительное и масштабируемое решение;
  • поддержка взаимодействия с серверными приложениями на основе стандарта OASIS Digital Signature Service (по протоколу SOAP);
  • сфера применения: серверные решения с высокой нагрузочной способностью в части формирования и проверки ЭП.
  1. ШТАМПЫ ВРЕМЕНИ

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

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

3.1.1 Линейка продуктов Signal-COM TSP

Особенности:

3.1.2 Signal-COM Java TSP

Особенности:

3.2 Решения на стороне сервера.

3.2.1  Signal-COM TSP Server

Особенности:

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

3.2.2 Служба штампов времени (time stamping authority, TSA)

Особенности:

  • предоставление услуг формирования штампов времени для корпоративных информационных систем и приложений;
  • в качестве источника точного времени используется NTP-сервер АО «Центр взаимодействия компьютерных сетей «МСК-IX»;

Скзи на стороне клиента

  • Толстый клиент (автономные клиентские приложения)

Формирование ЭП в клиентских приложениях может быть реализовано с помощью следующих продуктов:

Основные особенности:

  • поставляется в составе приложения (не требует предварительной установки);

поддержка платформ на базе ОС Windows, Linux, macOS, FreeBSD, Solaris;

  • оптимальное решение с т.з. цена/качество;

Примечание: для поддержки протокола SSL/TLS на стороне клиента может быть дополнительно использована криптобиблиотека SSL-PRO

Основные особенности:

  • требует предустановки при наличии прав администратора;
  • обеспечивает формирование ЭП в любых приложениях, работающих через интерфейс CryptoAPI 2.0;
  • поддерживает протокол SSL/TLS;
  • работает на  платформах на базе ОС Windows;

Основные особенности:

  • используется с Java 2 Platform Standard Edition;
  • поддержка платформ на базе ОС Windows, Linux, macOS, Solaris, AIX, z/OS.

Примечание: для поддержки протокола SSL/TLS на стороне клиента может быть дополнительно использована криптобиблиотека Signal-COM Java TLS

  • Тонкий клиент (работа через браузер)

Формирование ЭП может быть реализовано путем скачивания через Интернет и установки криптоплагинов, поддерживающих работу в современных Web-браузерах:  Internet Explorer, Google Chrome, Mozilla Firefox, Opera, Яндекс.Браузер, Safari и др.

Обычно разработка криптоплагинов производится под заказ исходя из требуемого функционала Заказчика, но иногда могут быть использованы и универсальные решения.

Смена pin-кода

Пример смены PIN-кода на устройстве:

var options = {};

try
{   
    plugin.changePin(deviceId, "12345678", "12345671", options);
}
catch (error) 
{
    console.log(error);
}

Здесь первым параметром выступает старый PIN-код, а вторым новый PIN-код.

Строгая аутентификация на портале

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


Реализация данной схемы ничем принципиально не отличается от «Регистрация, сертификат уже имеется, выдан внешним УЦ».

Шифрование данных на клиенте для сервера

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

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

Для этого следует использовать функцию importCertificate, при этом в качестве параметра category следует передать CERT_CATEGORY_OTHER. Для использования в функции cmsEncrypt нужно получить тело сертификата по его дескриптору с помощью функции getCertificate.

При этом дескриптор является уникальным и неизменным и может быть сохранен в учетной записи пользователя на сервере при импорте сертификата сервера. Для того, чтобы использовалось аппаратное шифрование по ГОСТ 28147-89, требуется установить опцию useHardwareEncryption в true. В противном случае будет использована быстрая программная реализация ГОСТ 28147-89.

Последовательность вызовов приведена на картинке:

Шифрование данных на клиенте:

try
{
    var recipientCert = plugin.getCertificate(deviceId, certRecId);        
}
catch (error) 
{
    console.log(error);
}

var options = {};
options.useHardwareEncryption = true;
var cms;

try
{
    cms = plugin.cmsEncrypt(deviceId, certSenderId, recipientCert, data, options);
}
catch (error) 
{
    console.log(error);
}

Расшифрование данных на сервере, перед расшифрованием сообщение нужно обрамить PEM-заголовками “—–BEGIN PKCS7—–” и “—–END PKCS7—–“:

openssl smime -engine gost -decrypt -in message.cms -inform PEM -recip recipient.crt -inkey recipient.key

recipient.crt — сертификат того, для кого зашифровано сообщение, recipient.key — ключ того, для кого зашифровано сообщение.

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

Adblock
detector