Магпро криптотуннель ошибка 816

С помощью данного сертифицированного криптографического средства Вы сможете с наименьшими затратами времени и средств обеспечить защиту обмена конфиденциальной информацией между Вашим Интернет-сервисом и его пользователями.

Основным назначением МагПро КриптоТуннель является защита соединений по протоколу HTTP, терминального доступа по протоколу RDP, электронной почты и т.п. МагПро КриптоТуннель поддерживает электронную подпись данных и документов при передаче их через Web-форму.

МагПро КриптоТуннель удобен тем, что:

• не требует установки на пользовательских местах;
• не требует специального обучения пользователей;
• позволяет работать непосредственно со съемного носителя (например, USB-Flash) на любом компьютере;
• позволяет использовать любой Интернет-браузер для защищенного web-соединения;
• имеет минималистичный и интуитивно-понятный пользовательский интерфейс;
• может устанавливать соединение с любым сервером, защищенным с помощью алгоритмов ГОСТ;
• может подписывать данные и документы, переданные пользователем через Web-форму, юридически значимой электронной подписью;
• позволяет пользователю не вводить URL сайта, что защищает от интернет-мошенничества в виде фишинга, DNS-спуфинга и т.п.

ПК «МагПро КриптоТуннель» позволяет:

1. установить соединение с сервером, защищенное по протоколу TLS (HTTPS-соединение), с использованием алгоритмов GOST, не меняя содержания файлов, содержащихся на компьютере пользователя;
2. установить защищенное RDP-соединение с удаленным компьютером;
3. выработать электронную цифровую подпись под текстовыми данными или файлом, которые передаются пользователем через веб-форму;
4. выработать метку времени для подписи, заверенную в службе временных меток.

СКЗИ МагПро КриптоПакет

Настройка автоматического обмена через API программных продуктов Инфокрафт: Формула ЖКХ и Инфокрафт: Формула ЖКХ + Бухгалтерия с государственным порталом ГИС ЖКХ

picture_as_pdf

Важно!

Эта инструкция подойдет в следующих случаях:

• ключ выпущен до 2022 года;
• ключ экспортируемый, то есть с возможностью копирования;
• ключ должен быть класса защиты КС2.

Если ключ выпущен после 01.01.2022, обратитесь, пожалуйста, в клиентский отдел по телефону: 8-800-200-1-365. 

С помощью автоматического обмена через API с порталом ГИС ЖКХ предусмотрена загрузка /выгрузка объектов жилищного фонда, лицевых счетов, показаний приборов учета. Также есть возможность выгрузки приборов учета, оплаты и платежных документов.

Основные шаги для настройки автоматического обмена

Шаг 1: Получение электронно-цифровой подписи для организации.

Для этого требуется обратиться в удостоверяющий центр в Вашем городе. Список удостоверяющих центров Вы можете посмотреть на сайте по адресу https://e-trust.gosuslugi.ru/CA, выбрав в поиске требуемый город, «Класс средств электронной подписи» — КС2. Сертификат требуется установить в раздел Личное для пользователя, от имени которого будет выполняться взаимодействие с ГИС ЖКХ. Требования к электронно-цифровой подписи:

• Алгоритм подписи должен быть ГОСТ Р 34.11/34.10-2001 (Signature Algorithm: GOST R 34.11-94 with GOST R 34.10-2001). Поддержка ГОСТ Р 34.10-2001 будет осуществляться до 31.12.2019;
• Алгоритм подписи должен быть ГОСТ Р 34.11/34.10-2012 (Signature Algorithm: GOST R 34.11-2012 with GOST R 34.10-2012). Поддержка ГОСТ Р 34.10-2012 осуществляется с 01.01.2019;
• Класс средств ЭП владельца квалифицированного сертификата (Certificate Policies): КС.2 и выше (должен содержать хотя бы 1.2.643.100.113.2);
• Использование ключа (Key Usage): Цифровая подпись (Digital Signature), Неотрекаемость (Non Repudiation/Сontent Commitment), Шифрование ключей (Key Encipherment), Шифрование данных (Data Encipherment);
• Система выполняет проверку Extended Key Usage (EKU) на наличие расширений: Проверка подлинности клиента (1.3.6.1.5.5.7.3.2);
• Состав имени субъекта зависит от вида сертификата:
• Для сертификата, выданного на ФЛ: SNILS.
• Для сертификата, выданного на должностное лицо ЮЛ: SNILS, INN, OGRN, O. INN (без учета лидирующих 00) и OGRN должны совпадать с ИНН и ОГРН Оператора ИС из заявки.
• Для сертификата, выданного на ЮЛ: OGRN, INN. INN (без учета лидирующих 00) и OGRN должны совпадать с ИНН и ОГРН организации.
• Для сертификата, выданного ИП: OGRNIP и INN. INN и OGRNIP должны совпадать с ИНН и ОГРНИП ИП.

Форматы и OID полей:

• OGRN ::= NUMERIC STRING SIZE 13 1.2.643.100.1
• OGRNIP ::= NUMERIC STRING SIZE 15 1.2.643.100.5
• SNILS ::= NUMERIC STRING SIZE 11 1.2.643.100.3
• INN ::= NUMERIC STRING SIZE 12 1.2.643.3.131.1.1

Шаг 2: Регистрация на государственном портале ГИС ЖКХ.

Организация (РСО, УО, ЖСК, ТСЖ) должна быть зарегистрирована в ГИС ЖКХ по адресу https://dom.gosuslugi.ru/#!/main. У организации должны быть определены функции в системе в соответствии с ее полномочиями, а также выбрана функция «Оператор информационной системы» (меню «Администрирование» — «Функции»).

1. Формирование заявки на добавление информационной системы в ГИС ЖКХ.
2. Установка КриптоПро CSP.

Используется для подписи передаваемых в ГИС ЖКХ данных ЭЦП пользователя. Для корректной работы через API c порталом ГИС ЖКХ рекомендован данный криптопровайдер. С подробной инструкцией по установке вы можете ознакомиться здесь.

Шаг 3: Установка КриптоПро ЭЦП Browser plug-in версии не ниже 2.0.12438.

Плагин для поддержки работы через браузер Internet Explorer c   электронно-цифровой подписью, если он не установлен, то портал автоматически предложит ссылку на его установку. Плагин требуется не только для работы с порталом через браузер, но и для обмена данными из 1С:Предприятия.

Шаг 4: Приобретение и установка «МагПро КриптоТуннель».

Использование данного программного продукта для шифрования данных определено требованиями системы ГИС ЖКХ.

Необходимо приобрести СКЗИ «МагПро КриптоПакет» в.3.0 — Исполнение «КриптоТуннель» — клиентскую лицензию. По требованиям ФСБ России поставка СКЗИ может осуществляться только на материальном носителе информации, электронная поставка невозможна. Стоимость каждого дистрибутива на компакт-диске с формуляром — 450 рублей.

Шаг 5: Приобретение и установка «P12FromGostCSP».

Данный программный продукт предназначен для создания резервной копии личного сертификата пользователя вместе с ключом ЭП, хранящихся в контейнере криптопровайдера. Резервная копия создаётся в защищенном контейнере PKCS#12 и предназначена для установления защищенного соединения с ГИС ЖКХ.

Порядок подключения внешних информационных систем

Перед тем, как начать работу по обмену данными в автоматическом режиме с порталом ГИС ЖКХ, требуется указать в личном кабинете портала с какой информационной системой будет осуществлена интеграция, для этого требуется сформировать заявку на добавление новой информационной системы.

К  основному стенду интеграции https://dom.gosuslugi.ru/#!/main можно подключиться без этапа тестирования, для этого при формировании заявки на регистрацию информационной системы требуется указать тип ИС:  «Собственная ИС», «Коммерческая ИС» и не устанавливать признак «По результатам рассмотрения заявки на предоставление права доступа оператору ИС необходимо предоставить информационной системе доступ к стенду интеграционного тестирования ГИС ЖКХ для проведения тестирования согласно «Регламенту информационного взаимодействия внешних информационных систем с ГИС ЖКХ».

Формирование заявки:

1. В личном кабинете ГИС ЖКХ перейдите в меню «Администрирование» – «Информационные системы».
2. Для формирования заявки на новую информационную систему нажмите на кнопку «Сформировать заявку на новую ИС» на странице «Информационные системы».
3. Выберите соответствующий вид ИС – «Собственная ИС».
4. Заполните все обязательные поля со знаком «*».
5. Загрузите квалифицированный сертификат ключа проверки электронной подписи ИС. Для этого нажмите кнопку «Добавить файл». Сам файл будет получен Вами после выполнения шага 5 инструкции раздела «Создание защищенного соединения», представленного ниже.
6. Установите флажки в полях «Подтверждаю соответствие ИС установленным законодательством Российской Федерации требованиям о защите информации об информационной безопасности» и «Принимаю условия «Соглашения об информационном взаимодействии».
7. Для отправки заявки на проверку оператором ГИС ЖКХ нажмите кнопку «Принять заявку». После проверки она будет утверждена или отклонена с указанием причины отказа. Проверка согласно регламенту ГИС ЖКХ не должна занимать более 3 рабочих дней.
8. В случае изменения регистрационных данных, в том числе при смене оператора ИС, реквизитов организаций, перечня контактных лиц, тестовых поставщиков информации и транспортного сертификата, Оператор ИС обязан в срок не более 5 рабочих дней отправить уведомление Оператору ГИС ЖКХ с темой «Заявка на изменение регистрационных данных участника информационного обмена»с описанием изменений. Оператор ГИС ЖКХ в срок не более 5 рабочих дней высылает уведомление по электронной почте о результате внесения изменений.
9. Решение о прекращении информационного взаимодействия принимается на основании заявки на отключение от Оператора ИС с темой «Заявка на отключение от информационного взаимодействия».

Более подробно с формированием заявки вы можете ознакомиться в инструкции портала ГИС ЖКХ «Руководство пользователя работа в личном  кабинете оператора информационной системы».

В случае нарушения положений настоящего Регламента (с Регламентом можно ознакомиться на портале ГИС ЖКХ, раздел «Регламенты и инструкции» — Регламент и форматы информационного взаимодействия внешних информационных систем с ГИС ЖКХ (текущие форматы) Оператор ГИС ЖКХ может принять решение о принудительном отключении ИС от информационного взаимодействия с ППАК. В случае принятия такого решения Оператору ИС направляется уведомление о принятии решения о принудительном отключении. В срок не позднее 5 рабочих дней после принятия решения об отключении ИС от информационного взаимодействия Оператор ГИС ЖКХ осуществляет блокировку приема и отправки пакетов данных отключаемой ИС. Уведомление о завершении процедуры отключения направляется Оператору ИС по электронной почте.



Для успешного дальнейшего обмена требуется скачать файлы CA-SIT.pem. и CA-PPAK.pem с портала ГИС ЖКХ. Файлы размещены в разделе «Регламенты и Инструкции» — «Регламент и форматы информационного взаимодействия внешних информационных систем с ГИС ЖКХ (текущие форматы v.11.7.0.10.1)».

Настройка «МагПро КриптоТуннель»

Более подробную информацию можно просмотреть на официальном сайте продукта http://www.cryptocom.ru/products/cryptotunnel.html. Перед покупкой данной программы обратите внимание на совместимость программы с версией операционной системы, которая стоит у вас на сервере/компьютере.

(Если у вас возникнут трудности в настройке данного программного обеспечения, то вы можете воспользоваться услугами Отдела Сервисного сопровождения компании Инфокрафт, подав заявку по телефону 8-800-200-1-365).

Создание защищенного соединения:

1. Приобрести «МагПро КриптоПакет» в исполнении «КриптоТуннель», клиентскую лицензию (официальный сайт:http://www.cryptocom.ru) — использовать полноценную (не демо) лицензионную версию КриптоТуннеля.Установить МагПро КриптоТуннель.
2. С дистрибутивного диска КриптоТуннеля скопировать на жесткий диск компьютера каталог CryptoTunnel.
3. Приобрести утилиту P12FromGostCSP (официальный сайт: http://www.lissi.ru/ls_product/utils/p12fromcsp/), для экспорта сертификата, полученного для установления защищенного соединения с ГИС ЖКХ, в формат pfx. Использовать полноценную (не демо) лицензионную версию P12FromGostCSP.
4. С помощью встроенной в Windows утилиты «Сертификаты» экспортировать сертификат, полученный для установления защищенного соединения с ГИС ЖКХ (без закрытого ключа) в формат DER.
5. Из командной строки cmd находясь в директории CryptoTunnel выполнить команду:

vars.bat
   Далее в этой же командной строке выполнить:

1. Внести изменения в конфигурационный файл …CryptoTunnelstunnelstunnel.conf :
   — для параметра cert указать значение в виде имени файла, полученного в п.5 (cert= ..cryptotest.pem).
   — для параметра key указать значение в виде имени файла, полученного в п.5 (key= ..cryptotest.key).
   — для параметра connect указать значение api.dom.gosuslugi.ru:443.
   — для параметра CAFile указать значение ..cryptoCA-PPAK.pem.
2. Проверить доступность порта 8080, запустив из командной строки cmd: netstat -an
3. Запустить программу …CryptoTunnelstarter.exe. В дальнейшем работу с сервером интеграции осуществлять по адресу:
   http://127.0.0.1:8080/<адрес_интеграционного_сервиса>.
4. Для реализации защищенного соединения с промышленным стендом ГИС ЖКХ необходимо:
   openssl pkcs12 -in C:test.pfx -out C:test.key -nodes

— для генерации key и pem использовать сертификат, выданный аккредитованным, не тестовым УЦ. Список аккредитованных УЦ распространяется через портал http://e-trust.gosuslugi.ru/, сертификат должен проходить проверку подлинности ИС ГУЦ (http://www.gosuslugi.ru/pgu/eds/);

Полную документацию по автоматическому обмену можно просмотреть по адресу: https://dom.gosuslugi.ru/#!/main, раздел «Регламенты и инструкции» — Регламент и форматы информационного взаимодействия внешних информационных систем с ГИС ЖКХ (текущие форматы).

После выполненных настроек можно переходить к подготовке программы к автоматическому режиму обмена данными между Инфокрафт: Формула ЖКХ/ Инфокрафт: Формула ЖКХ + Бухгалтерия и порталом ГИС ЖКХ, для этого вы можете обратиться к  инструкции №462.

Настройка stunnel криптопро windows

Клиент Stunnel (Linux) принимает трафик на указанном порте 1500 по адресу 192.168.69.180, шифрует все поступившие на него данные и передает их на Stunnel Сервер (Windows) с IP адресом 192.168.69.61 на порт 1502. Сервер расшифровывает все поступившие на этот порт данные и передает на указанный в настройках порт и адрес (google.ru, порт 80).

Если требуется проверка сертификата клиента, нужно назначить параметр «Verify=2».

Установка на ОС Linux

Дополнительный пакет (входит в состав дистрибутива):

Установка пакета Stunnel

Для дистрибутивов Linux, основанных на rpm, это утилита rpm:

Для дистрибутивов, основанных на deb, это утилита alien:

После установки пакета бинарные файлы, предназначенные для запуска Stunnel, будут помещёны в /opt/cprocsp/sbin/ /. Существует две реализации службы Stunnel: с использованием библиотеки thread и с использованием fork; бинарные файлы называются stunnel_thread и stunnel_fork соответственно. Stunnel с использованием fork возможно использовать только с КриптоПро CSP исполнение КС2.

Установка сертификата

Требуется установить необходимые сертификаты:

а) сертификат корневого Центра Сертификации (ЦС) – в хранилище «Доверенные корневые Центры Сертификации» локального компьютера

Запуск службы

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

Установка на ОС Windows

Для работы необходимо установить:

Установка службы Stunnel

Установка делается путём запуска stunnel.exe – install

В дальнейшем служба для старта будет использовать файл stunnel.exe из той папки, откуда была проведена установка.

Перед установкой нужно выбрать режим работы службы, установить сертификаты и сформировать файл конфигурации.

Установка сертификата

Требуется установить необходимые сертификаты:

а) сертификат корневого Центра Сертификации (ЦС) – в хранилище «Доверенные корневые Центры Сертификации» локального компьютера;

Запуск службы по умолчанию выполняется от пользователя «SYSTEM»

Получается следующая цепочка:

Данная программа позволяет создавать TLS-«туннель», обеспечивающий шифрование трафика от клиента до сервера с использованием сертифицированного СКЗИ произвольного TCP-соединения.

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

Источник

Шифрование TLS-трафика по алгоритмам ГОСТ-2012 c Stunnel

В этой статье я хочу показать, как настроить Stunnel на использование российских криптографических алгоритмов в протоколе TLS. В качестве бонуса покажу, как шифровать TLS-канал, используя алгоритмы ГОСТ, реализованные в криптоядре Рутокен ЭЦП 2.0.

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

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

Стоит заметить, что на сервере не обязательно должен стоять именно Stunnel, для работы с криптографическими алгоритмами. Здорово, что есть готовые демонстрационные стенды, которые поддерживают российскую криптографию, список которых есть в презентации с РусКрипто’2019.

Нам нужны стабильно работающие серверы, осуществляющие двухстороннюю аутентификацию.
Мы выбрали серверы КриптоПро как наиболее надёжные с полной реализацией стандарта ГОСТ TLS. Спасибо им за это 🙂

Звучит достаточно просто, давайте попробуем организовать этот процесс.

Подготовительный шаг

OpenSSL для Windows можно взять отсюда, а для пользователей линукса — из репозиториев или собрать самому, скачав свежую версию отсюда. Также его можно взять из Rutoken SDK, из директории opensslopenssl-tool-1.1, этот архив нам будет полезен и дальше, т.к. в нём находится интересующий нас rtengine. Stunnel можно найти здесь. Для работы необходима версия >= 5.56.

Скачать rtengine можно из Rutoken SDK, он лежит в директории opensslrtenginebin. Закинуть его нужно туда, где хранятся все движки openssl. Узнать путь до них можно с помощью

Но просто переместить движок в нужную папку — мало, нужно ещё сконфигурировать сам openssl для работы с ним. Узнаём где лежит файл с конфигурацией openssl.cnf с помощью той же команды, что указана выше (под виндой stunnel идёт с собственной версией openssl, поэтому файл с конфигурацией лежит в pathtostunnelconfigopenssl.cnf

Давайте проверим, что rtengine подключился, для этого подключим токен и выведем список всех алгоритмов шифрования:

Напомню, что в Windows нужно проверять на openssl, который лежит рядом с stunnel
Если среди них будут присутствовать наши ГОСТы, значит всё настроено верно.

Настало время самого интересного: проверка установки соединения по ГОСТу с тестовыми серверами КриптоПро. Список данных серверов описан здесь (https://www.cryptopro.ru/products/csp/tc26tls). Каждый из этих серверов работает со своими алгоритмами для аутентификации и шифрования. Более того на портах 443, 1443, 2443,… запущены сервисы, которые воспринимают только определённые парамсеты. Так, например, по адресу http://tlsgost-256auth.cryptopro.ru происходит шифрование с аутентификацией с использованием алгоритмов GOST2012-GOST8912-GOST8912 и 256-битным ключом. Так же на порту 443 используется XchA-ParamSet, на порту 1443 — XchB-ParamSet, на порту 2443 — A-ParamSet и т.д.

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

Простой способ (работает под Windows и Linux)

Через командную строку

Для того, чтобы получить корневой сертификат, зайдём на сайт тестового УЦ ООО «КРИПТО-ПРО». И нажмём на кнопку для получения сертификата. Отобразится новая вкладка, в которой нужно будет выбрать метод шифрования Base64 и нажать на кнопку «Загрузка сертификата ЦС». Полученный файл certnew.cer сохраняем.

Теперь генерируем ключи.

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

Создадим запрос на сертификат:

Опять открываем сайт тестового УЦ, но на этот раз нажимаем на кнопку «Отправить готовый запрос PKCS#10 или PKCS#7 в кодировке Base64». Вставляем в поле содержимое нашего запроса, нажимаем на кнопку Выдать и загружаем сертификат user.crt в формате Base64. Полученный файл сохраняем

Остался последний вопрос: Для чего всё это. Зачем мы получали все эти сертификаты, ключи и запросы?

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

У нас есть сертификат сервера, и мы считаем его доверенным.

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

Мы отправили этот запрос и сервер подписал её своей ЭЦП. Теперь мы можем каждый раз предъявлять этот сертификат, подписанный корневым УЦ, тем самым подтверждая, что мы — это мы.

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

Осталось только правильно настроить наш туннель. Для этого создадим файл stunnel.conf с настройками Stunnel по умолчанию и напишем туда следующее:

Теперь, если всё сделано правильно, можно запустить Stunnel с нашей конфигурацией и подключиться к серверу:

Откроем браузер и зайдём по адресу localhost:8080. Если всё верно, то отобразится следующее:

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

Если у вас остались какие-то вопросы, то милости просим в комментарии 🙂

Источник

Настройка stunnel криптопро windows

Клиент Stunnel (Linux) принимает трафик на указанном порте 1500 по адресу 192.168.69.180, шифрует все поступившие на него данные и передает их на Stunnel Сервер (Windows) с IP адресом 192.168.69.61 на порт 1502. Сервер расшифровывает все поступившие на этот порт данные и передает на указанный в настройках порт и адрес (google.ru, порт 80).

Если требуется проверка сертификата клиента, нужно назначить параметр «Verify=2».

Установка на ОС Linux

Дополнительный пакет (входит в состав дистрибутива):

Установка пакета Stunnel

Для дистрибутивов Linux, основанных на rpm, это утилита rpm:

Для дистрибутивов, основанных на deb, это утилита alien:

После установки пакета бинарные файлы, предназначенные для запуска Stunnel, будут помещёны в /opt/cprocsp/sbin/ /. Существует две реализации службы Stunnel: с использованием библиотеки thread и с использованием fork; бинарные файлы называются stunnel_thread и stunnel_fork соответственно. Stunnel с использованием fork возможно использовать только с КриптоПро CSP исполнение КС2.

Установка сертификата

Требуется установить необходимые сертификаты:

а) сертификат корневого Центра Сертификации (ЦС) – в хранилище «Доверенные корневые Центры Сертификации» локального компьютера

Запуск службы

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

Установка на ОС Windows

Для работы необходимо установить:

Установка службы Stunnel

Установка делается путём запуска stunnel.exe – install

В дальнейшем служба для старта будет использовать файл stunnel.exe из той папки, откуда была проведена установка.

Перед установкой нужно выбрать режим работы службы, установить сертификаты и сформировать файл конфигурации.

Установка сертификата

Требуется установить необходимые сертификаты:

а) сертификат корневого Центра Сертификации (ЦС) – в хранилище «Доверенные корневые Центры Сертификации» локального компьютера;

Запуск службы по умолчанию выполняется от пользователя «SYSTEM»

Получается следующая цепочка:

Данная программа позволяет создавать TLS-«туннель», обеспечивающий шифрование трафика от клиента до сервера с использованием сертифицированного СКЗИ произвольного TCP-соединения.

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

Источник

Экономим бюджет компании, или как построить криптотуннель по ГОСТу с минимальными затратами

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

Введение

Для любого системного администратора или DevOps построить VPN или «пробросить» нестандартный метод инкапсуляции пакетов (туннелирование) — не очень сложная задача. Часто для этого применяют OpenVPN, если планируется постоянное использование, либо SSH-туннелирование, если защищённое соединение нужно на один-два раза. Однако есть предприятия и ведомства, которые должны соблюдать строгие условия передачи данных, установленные законодательством. Под такие требования подпадают, например, многие структуры, которые так или иначе имеют отношение к денежным операциям: банки, микрофинансовые организации и т.п. Персональные данные тоже являются «защищаемой информацией» во всех законах и положениях.

В результате оказывается, что при шифровании необходимо использовать СКЗИ со всеми необходимыми сертификатами и лицензиями, соответствующие нормативным требованиям. Одним из примеров таких программных средств является «КриптоПро CSP». В данной статье мы будем разбирать задачу о том, как «прокинуть» средствами stunnel сетевой туннель, который будет шифроваться «КриптоПро CSP», заодно получив хоть и тестовый (на 3 месяца), но полностью валидный сертификат по ГОСТ Р 34.10-2012.

Задача

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

К примеру, есть две машины. Для демонстрации настройки двух операционных систем одна из них будет работать под управлением ОС семейства Linux (Ubuntu, версия не важна, но желательно — не ниже 16), вторая — под Windows 10. На win-системе будет запускаться Netcat на прослушивание какого-то определённого порта, а с nix-системы будут передаваться пакеты. Таким образом, Windows-машина будет сервером (в том числе — в отношении настроек stunnel).

Что должно получиться в итоге? При подключении с Linux к Windows через программу Netcat все пакеты будут шифроваться сертификатом GOST_2012 и сертифицированным программным обеспечением. Задача тривиальна и ставится для того, чтобы показать возможность такого манёвра. Поскольку stunnel передаёт любой протокол внутри себя, можно, к примеру, подписывать XML-файлы секретной подписью другой организации или передавать персональные данные в хранилище через интернет.

Тестовый стенд

Linux

Начнём с того, что система готова к настройке. Как работает «КриптоПро CSP», читатели, скорее всего, уже знают. Небольшое уточнение относительно stunnel: эта программа изначально создавалась как прокси-сервер с функцией шифрования трафика. Другими словами, она берёт, к примеру, HTTP и превращает его в своего рода HTTPS (если не вдаваться в подробности протоколирования).

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

Рисунок 1. Схема работы stunnel

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

Рисунок 2. «КриптоПро CSP» на Linux

Для установки необходимо запустить install.sh. Этот скрипт добавит нужные компоненты: certmgr, cpverify, cryptcp, csptest, csptestf, curl, der2xer, genkpim, inittst, wipefile. У каждой из этих программ — своя зона ответственности, свои ключи и задачи. Для нашего сценария нужны будут только certmgr и cryptcp.

Сама по себе stunnel шифрует трафик с помощью OpenSSL, но в компании «КриптоПро» её переписали под свои нужды, так что теперь она использует утилиты для un- и de- шифрования и называется stunnel-msspi. Поставляется она в архиве вместе с CSP; также её можно скачать отдельно. Для старых версий «КриптоПро CSP» есть вероятность, что программа уже установлена, но это необходимо проверить.

Как было сказано выше, для stunnel Linux-система будет клиентом, а Windows — сервером. IP-адреса: Linux – 172.22.1.65, Windows – 172.22.1.121.

Следующий шаг — ключи и сертификаты. Для сервера нам необходимо и то, и другое, причём все это — в контейнере «КриптоПро». Для клиента требуется только сертификат, нужный для того, чтобы к туннелю не мог подключиться любой желающий. Забегая немного вперёд, отметим, что в конфигурационном файле stunnel есть опция verify, и вот её параметры:

0. Не проверять сертификат сервера

1. Проверять сертификат при его наличии

2. Проверять сертификат всегда

3. Проверять наличие данного сертификата в хранилище TrustedUsers

Начиная с параметра 1, собственно, и нужен сертификат клиента для защиты подключения.

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

Интересные моменты относительно ключей:

Рисунок 3. Вывод программы cpconfig

На скриншоте выше видно, что значение 75 устарело и соответствует ГОСТу версии 2001. ГОСТ версии 2012 на 256 и 512 бит задаётся значениями 80 и 81 соответственно.

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

Переходим к генерации сертификата для клиента. Команда аналогична, меняется только имя контейнера и идентификатор назначения сертификата.

Теперь с ключами и сертификатами всё готово. На всякий случай приведём команду экспорта из контейнера:

Таким образом можно получить «на руки» сертификат в формате DER.

Далее нужно приниматься за настройку stunnel, а именно — его конфигурационного файла. Создаём в удобном месте файл stunnel.conf. Содержимое будет следующим:

Прокомментируем содержание секции TestStunnel:

Рисунок 4. Отпечаток в Linux

На этом настройка Linux закончена, можно запускать stunnel с указанием соответствующего файла конфигурации stunnel.conf.

Windows

После установки «КриптоПро CSP» необходимо скопировать контейнер с серверным ключом и сертификатом с nix-машины.

Для этого необходимо скачать и установить ImDisk. Затем при помощи ImDisk Virtual Disk Driver следует создать эмулятор токена (именно так его и увидит CSP, по-русски это — просто контейнер HDD) и подключить его к системе.

Рисунок 5. Псевдотокен

В итоге рядом с жёстким диском должен появиться ещё один носитель — это и есть токен. Туда понадобится скопировать папку с контейнером. После этих манипуляций сертификат нормально установится в «КриптоПро CSP».

Дополнительно стоит скопировать клиентский сертификат на сервер и тоже его установить.

Конфигурационный файл для stunnel-msspi:

Здесь всё устроено по аналогии с конфигурационным файлом клиента: accept — порт, к которому подключается клиентская копия stunnel (должен быть разблокирован в брандмауэре и «проброшен» во все места до наружного выхода), connect — порт для приложения (в данном случае — Netcat).

Повторяется история и в отношении сертификата: либо импорт из контейнера, что совсем не рекомендуется, либо указание отпечатка. Отпечаток можно найти в составе сертификата.

Рисунок 6. Отпечаток сертификата в Windows

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

Теперь пора скачать Netcat для Windows.

Следующий шаг — запустить сервер stunnel, заодно перезапустив и клиент. Для отладки и тестирования в Windows лучше делать это из командной строки.

В командной строке сервера побежит протокол, который расскажет, что кто-то успешно подключился. Пишем в одном окне набор символов; он появляется в другом окне. Всё настроено верно.

Рисунок 7. Результат

Выводы

В статье мы разобрали задачу о том, как получить криптотуннель с валидным ключом, подписанным самим «КриптоПро», и с алгоритмом шифрования GOST_2012, 512 бит. Сделано это с минимальными затратами — две лицензии на «КриптоПро CSP».

Можно, конечно, написать что-то своё, но лицензии JСP, к примеру, стоят намного больше. Готовые решения тоже будут значительно дороже.

Источник

Stunnel на сервере и клиенте

Задача

Обеспечить доступ из «везде где есть интернет» к некоему ПО. Шифровать траффик между клиентской и серверной частью приложения, которое не умеет работать через SSL. Так же нужно иметь возможность ограничивать доступ некоторым пользователям при необходимости. По различным причинам основные реализации VPN отпали. В процессе поиска решения наткнулся на Stunnel, который идеально подошел. В данной статье постараюсь детально описать процесс настройки.

Статья по большей части составлена из рабочих заметок в довесок с претензиями на туториал, поэтому прошу спокойно относится к капитанству вида — «Первое, что мы сделаем — обновим систему».

Общее представление схемы работы:

ПО клиент (windows) > Stunnel > Интернет > Stunnel > ПО Сервер (linux)

Система: свежеустановленная ubuntu server 14.04 x64.

Приложение трафик которого нужно шифровать я называть не буду. Вместо него буду указывать ssh. Для теста подходит идеально, на мой взгляд.

Приступим

Первое, что мы сделаем — обновим систему:

Настроим и включим ufw:

Проведем некоторые подготовительные мероприятия.

Разрешим автозапуск. В файле /etc/default/stunnel4 заменим ENABLED=0 на ENABLED=1:

Создадим папки для клиентских сертификатов. certs — разрешенные, crls — запрещенные (отозванные). О самих сертификатах чуть позже.

Создадим лог-файл и сменим владельца.

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

Я буду использовать свой конфиг, но если он вам не подходит можно взять пример в /usr/share/doc/stunnel4/examples

Создадим конфигурационный файл:

Со следующим содержимым:

Ключи и сертификаты

Не большое отступление. В нашем случае stunnel проверяет только корректность пары сертификат/ключ и наличие сертификата в разрешенных или запрещенных. Самоподписанного сертификата более чем достаточно, и с технической стороны (stunnel) и со стороны поставленной задачи. Нет никакого смысла заморачиваться с собственным CA или с присутствием корневого сертификата в списке доверенных на клиенте или сервере.

Нам нужны пары сертификат/ключ для сервера и каждого клиента.

C помощью openssl создадим пару для сервера:

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

И переместим их по назначению:

Как и где хранить клиентские сертификаты с ключами (за исключением каталогов certs и crls созданных ранее) решать вам. Я просто создам каталог clients в домашней директории своего пользователя и буду хранить их там на первых порах.

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

Создадим пару для клиента:

Как и при создании сертификата для сервера отвечаем на вопросы. Common Name будет другим например client.

Создадим еще одну пару:

Предположим, что clientcert.pem сертификат клиента которому доступ разрешен, а dnclientcert.pem сертификат клиента которому доступ запрещен. Скопируем сертификаты по нужным директориям.

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

Со следующим содержимым:

Возможно будет более целесообразным разместить certlink.sh где нибудь в /usr/bin. Я пока не стал этого делать. Но выбор за вами.
Дадим права:

В результате в каталогах у нас должны появится ссылки вида 7469493f.0.

Stunnel на клиенте

На клиенте будем использовать версию stunnel аналогичную серверной. На сервере у нас 4.53. Забираем с одного из зеркал.

Если прямая ссылка перестанет работать, найти нужную версию можно так:

Редактируем файл stunnel.conf. У меня он имеет следующий вид:

Здесь debug = 7 только на момент отладки, потом можно понизить до 3 или 4. Также есть опции для «тихого режима» и сокрытия значка в трее все есть в man’e.

Запускаем stunnel.exe, и пробуем с помощью putty подключится к 127.0.0.1. Тестируем. Можно попробовать подключится с запрещенным сертификатом.

Полезные материалы

Приведенные здесь инструкции полностью работоспособны. Проверено 26.12.2014 ubuntu 14.04.01, stunnel 4.53.

В данный момент работаю над парсингом логов stunnel с выводом отчетов и автоматизацией создания/управления сертификатами. Так как в последнее время мне интересен golang, реализовано будет с помощью него. Если материал на эту тему интересен — дайте знать.

Источник

1. Подготовка
2. Криптотуннель по ГОСТу
3. Формирование XMLDSig
4. Ссылки

Подготовка

Взаимодействие состоит из следующих частей:

• Установка по ГОСТу шифрованного туннеля до серверов ГИС ЖКХ.
• Формирование и отправка подписанного XML запроса.
• Получение и проверка ответа.

Для работы используется сервер CentOS 6, Python 2.7.11, OpenSSL + GOST engine, stunnel. Краткая инструкция установки openssl с поддержкой ГОСТ

# wget https://www.openssl.org/source/openssl-1.0.2g.tar.gz
# tar -xvf openssl-1.0.2g.tar.gz
# cd openssl-1.0.2g/
# yum groupinstall "Development Tools"
# yum install zlib zlib-devel
# ./config shared zlib enable-rfc3779
# make && make install
# echo "/usr/local/ssl/lib/" > /etc/ld.so.conf.d/openssl.conf
# ldconfig
# /usr/local/ssl/bin/openssl ciphers | tr ":" "n" | grep -i gost
GOST2001-GOST89-GOST89
GOST94-GOST89-GOST89

# cat /usr/local/ssl/openssl.cnf
…………
openssl_conf = openssl_def

[openssl_def]
engines = engine_section

[engine_section]
gost = gost_section

[gost_section]
engine_id = gost
default_algorithms = ALL
…………

Думаю, ничего сложного быть не должно и всё уже сотни раз описано. А в более свежих дистрибутивах модуль gost есть из коробки.

OpenSSL используется двояко: с ним собран stunnel, что-бы работал по ГОСТу; и утилита openssl вызывается из кода python-а для формирования и проверки подписей. Вызов openssl обусловлен тем, что не удалось из кода python-на задавать используемый крипто-модуль. Всё необходимое ПО есть как на Linux, так и на Windows платформах, потому методику можно назвать мультиплатформенной.

Для python-а сервера CentOS 6 нужно будет обновить библиотеку lxml, а для этого поставить несколько дополнительных пакетов:

# yum install libxml2 libxml2-devel libxslt libxslt-devel python-devel
# pip install lxml --upgrade

Так же нам потребуются файлы сертификата и закрытого ключа в формате PKCS12 (.pem). Получить их из eToken-а можно с помощью утилит вроде P12FromGostCSP или вручную. Если сделать это по каким-либо причинам не получается, то есть вариант работы с ключом «Рутокен ЭЦП» напрямую. На сайте есть подробные инструкции, как обучить этому OpenSSL и stunnel. Таким образом, задача сводится к предыдущей. У меня под рукой такого ключа не оказалось, потому проверить не удалось.

Криптотуннель по ГОСТу

Туннель поднимается с помощью Stunnel, который работает в режиме прокси. Нужно только научить его использовать модуль gost. Но тут есть момент — чтобы модуль инициализировался правильно, нужно слегка исправить исходники. Проблема, как я понял, связана с порядком инициализации модуля и методов. Итак:

# wget https://www.stunnel.org/downloads/stunnel-5.31.tar.gz
# tar -xvf stunnel-5.31.tar.gz
# cd stunnel-5.31

Правим файл src/options.c и в конце функции «NOEXPORT char *engine_init(void)» добавляем вызов SSL_library_init();.

NOEXPORT char *engine_init(void) {
    if(engine_initialized) /* either first or already initialized */
        return NULL; /* OK */
    s_log(LOG_DEBUG, "Initializing engine #%d (%s)",
        current_engine+1, ENGINE_get_id(engines[current_engine]));
    if(!ENGINE_init(engines[current_engine])) {
        if(ERR_peek_last_error()) /* really an error */
            sslerror("ENGINE_init");
        else
            s_log(LOG_ERR, "Engine #%d (%s) not initialized",
                current_engine+1, ENGINE_get_id(engines[current_engine]));
        return "Engine initialization failed";
    }
#if 0
    /* it is a bad idea to set the engine as default for all sections */
    /* the "engine=auto" or "engineDefault" options should be used instead */
    if(!ENGINE_set_default(engines[current_engine], ENGINE_METHOD_ALL)) {
        sslerror("ENGINE_set_default");
        return "Selecting default engine failed";
    }
#endif
    s_log(LOG_INFO, "Engine #%d (%s) initialized",
        current_engine+1, ENGINE_get_id(engines[current_engine]));
    SSL_library_init();
    engine_initialized=1;
    return NULL; /* OK */
}

Решение было найдено тут.
Собираем с подключением ранее собранного OpenSSL:

# ./configure --with-ssl=/usr/local/ssl  --disable-libwrap
# make && make install

Файл конфигурации /etc/stunnel.conf:

client=yes
# сертификат ГИС ЖКХ (тестовый).
CAFile=/etc/crypto/CA-SIT.pem
engine=gost
sslVersion=TLSv1
engineDefault = ALL

output=/var/log/stunnel.log
DEBUG=4

# извлечённые с eToken-а.
cert=/etc/crypto/public.pem
key=/etc/crypto/private.key

[pseudo-https]
# адрес и порт сервера, который будет принимать запросы.
accept = 10.1.5.133:8080
# адрес сервера ГИС ЖКХ, куда прокладываем туннель (тестовый).
connect = 54.76.42.99:60045
ciphers = GOST2001-GOST89-GOST89

Файлы сертификатов кладём в директорию /etc/crypto/. В общем случае, stunnel может работать под любым пользователем, но у нас пусть будет root.

#! /bin/bash
#
# stunnel          Start/Stop Stunnel
#
# chkconfig: 2345 90 60
# description: launches Stunnel
# processname: stunnel
# config: /etc/stunnel.conf

# Source function library.
. /etc/init.d/functions

# See how we were called.

prog="Stunnel CryptoTunnel"
RNG=PROGRAM
export RNG

start() {
    echo -n $"Starting $prog: "
    /usr/local/bin/stunnel  /etc/stunnel.conf
    RETVAL=$?
    [ $RETVAL -eq 0 ] && success
    [ $RETVAL -ne 0 ] && failure
    echo
    return $RETVAL
}

stop() {
    echo -n $"Stopping $prog: "
    /usr/bin/killall /usr/local/bin/stunnel >/dev/null 2>&1
    RETVAL=$?
        [ $RETVAL -eq 0 ] && success
        [ $RETVAL -ne 0 ] && failure
        echo
        return $RETVAL
}

restart() {
    stop
    start
}

case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  restart)
    restart
    ;;
  *)
    echo $"Usage: $0 {start|stop|status|restart}"
    exit 1
esac

Можно запускать и проверять, например,

# curl http://10.1.5.133:8080/ext-bus-nsi-service/services/Nsi?wsdl
<?xml version='1.0' encoding='UTF-8'?><wsdl:definitions xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://dom.gosuslugi.ru/schema/integration/8.7.0.7/nsi-service/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:nsi-common="http://dom.gosuslugi.ru/schema/integration/8.7.0.7/nsi-common/" xmlns:nsi="http://dom.gosuslugi.ru/schema/integration/8.7.0.7/nsi/" xmlns:ns="http://www.w3.org/2000/09/xmldsig#" xmlns:base="http://dom.gosuslugi.ru/schema/integration/8.7.0.7/" targetNamespace="http://dom.gosuslugi.ru/schema/integration/8.7.0.7/nsi-service/">
  <wsdl:types>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://dom.gosuslugi.ru/schema/integration/8.7.0.7/nsi-service/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:nsi-common="http://dom.gosuslugi.ru/schema/integration/8.7.0.7/nsi-common/" xmlns:nsi="http://dom.gosuslugi.ru/schema/integration/8.7.0.7/nsi/" xmlns:ns="http://www.w3.org/2000/09/xmldsig#" xmlns:base="http://dom.gosuslugi.ru/schema/integration/8.7.0.7/">

  <xs:import namespace="http://dom.gosuslugi.ru/schema/integration/8.7.0.7/" schemaLocation="http://54.76.42.99:60046//ext-bus-nsi-service/services/Nsi?xsd=hcs-basetypes-8.7.0.7.xsd"/>

  <xs:import namespace="http://dom.gosuslugi.ru/schema/integration/8.7.0.7/nsi/" schemaLocation="http://54.76.42.99:60046//ext-bus-nsi-service/services/Nsi?xsd=hcs-nsi-types-8.7.0.7.xsd"/>

</xs:schema>
………

Если вывод совсем не похож, то внимательно смотрим в лог файл /var/log/stunnel.log.

Формирование XMLDSig

Когда туннель до сервера ГИС ЖКХ настроен и работает, можно слать туда всякие запросы и получать нужные ответы. Запрос отправляется в виде XMLDSig, в котором содержится сам запрос, хеш этого запроса, хеш сертификата, сам сертификат, подпись хеша запроса с хешем сертификата и куча полей, всё это описывающих. Самое сложное как раз было раскрутить всю цепочку и получить XML, который успешно проходит проверку со стороны ГИС ЖКХ. Все подписываемые блоки берутся в каноническом виде, а получаемые подписи и хеш-суммы кодируются в BASE64.

Алгоритм формирования XMLDSig можно реализовать используя любой удобный язык программирования. Мы использовали python 2.7.11, демонстрационный код прилагается. Как пример, буду так же приводить консольный аналог.

0. Из сертификата достаются серийный номер и данные о выпустившем, генерируются необходимые id и запоминается текущее время.
1. С помощью любого soap клиента (например, suds на Python) формируется SOAP-запрос к серверу ГИС ЖКХ.

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
        xmlns:ns0="http://dom.gosuslugi.ru/schema/integration/8.7.0.3/nsi/" xmlns:ns1="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<RequestHeader
        xmlns="http://dom.gosuslugi.ru/schema/integration/8.7.0.4/"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Date>2016-04-11T14:28:28</Date>
<MessageGUID>29f93de1-25b6-21e5-24ae-2c6f65dfe2b2</MessageGUID>
<SenderID>4eb0a7d6-6317-45cf-8974-10e75cbb0cbc</SenderID>
</RequestHeader>
</SOAP-ENV:Header>
<ns1:Body>
<ns0:exportDataProviderNsiItemRequest Id="signed-element">
<ns0:RegistryNumber>51</ns0:RegistryNumber></ns0:exportDataProviderNsiItemRequest>
</ns1:Body>
</SOAP-ENV:Envelope>

2. Берётся содержимое тега <ns1:Body>(точнее часть с Id и без первого и последнего символа перевода строки), канонизируется алгоритмом C14N (exclusive=True), считается от неё хеш-сумма по ГОСТу и выводится в виде BASE64. Получаем digest1. Консольный аналог:

# cat in.xml ; echo
<ns0:exportDataProviderNsiItemRequest Id="signed-element">
<ns0:RegistryNumber>51</ns0:RegistryNumber></ns0:exportDataProviderNsiItemRequest>
# cat in.xml | openssl dgst -engine gost -md_gost94  -binary | base64

* openssl с поддержкой ГОСТ. Engine указан явно, но, настроив openssl.cnf, можно этого и не делать.

3. Берётся сертификат в x509, декодируется из BASE64, считается от него хеш-сумма и вывод кодируется в BASE64. Получаем digest2.

4. Используя полученные данные, формируется содержимое тега <xades:SignedProperties>(см. Шаблон), канонизируется алгоритмом C14N (exclusive=False) и от содержимого считается digest3 (BASE64).

5. Формируется блок <ds:SignedInfo>, канонизируется алгоритмом C14N (exclusive=False), подписывается и кодируется в BASE64. Получается значение блока <ds:SignatureValue>. Консольный аналог:

cat SignedInfo.xml | openssl dgst -sign private.key -engine gost -md_gost94 -binary | base64 

где SignedInfo.xml – уже канонизированный блок, без последнего перевода строки.

6. Все полученные значения вносятся в

<ds:Signature Id="xmldsig-{signature_id}" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411"/>
<ds:Reference Id="xmldsig-{signature_id}-ref0" URI="#{signed_id}">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411"/>
<ds:DigestValue>{digest1}</ds:DigestValue>
</ds:Reference>
<ds:Reference Type="http://uri.etsi.org/01903#SignedProperties" URI="#xmldsig-{signature_id}-signedprops">
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411"/>
<ds:DigestValue>{digest3}</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue Id="xmldsig-{signature_id}-sigvalue">
{signature_value}
</ds:SignatureValue>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
{x590_cert}
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
<ds:Object><xades:QualifyingProperties Target="#xmldsig-{signature_id}" xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" xmlns:xades141="http://uri.etsi.org/01903/v1.4.1#"><xades:SignedProperties Id="xmldsig-{signature_id}-signedprops"><xades:SignedSignatureProperties><xades:SigningTime>{signing_time}</xades:SigningTime><xades:SigningCertificate><xades:Cert><xades:CertDigest><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411"/><ds:DigestValue>{digest2}</ds:DigestValue></xades:CertDigest><xades:IssuerSerial><ds:X509IssuerName>{x509_issuer_name}</ds:X509IssuerName><ds:X509SerialNumber>{x509_sn}</ds:X509SerialNumber></xades:IssuerSerial></xades:Cert></xades:SigningCertificate></xades:SignedSignatureProperties></xades:SignedProperties></xades:QualifyingProperties></ds:Object>
</ds:Signature>

Этот шаблон удалось сформировать расковыряв и проанализировав комплекс, который рекомендует использовать ГИС ЖКХ. Сам он находится в свободном доступе, но для работы требует СКЗИ КриптоПро CSP и СКЗИ Trusted Java 2.0.

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

# cat SignedInfo.xml | openssl dgst -engine gost -md_gost94 -verify <(openssl x509 -engine gost -in public.pem -pubkey -noout) -signature signature.sig

где signature.sig – раскодированная из BASE64 подпись, а SignedInfo.xml проверяемый блок <ds:SignedInfo>...</ds:SignedInfo> целиком. Значения хеш-сумм просто сравниваются.

Демонстрационный код на python-е можно взять и использовать (на свой страх и риск) отсюда. Автор кода — Вячеслав ( slavam, RO). Подобный алгоритм можно реализовать средствами любого удобного языка, без необходимости покупки каких-либо дополнительных средств и компонентов. Вызов утилит OpenSSL из кода хоть и выглядит топорным, зато работает как на Linux так и на Windows платформе и позволяет отказаться от использования КриптоПро и дополнительных компонентов.
Система взаимодействия с ГИС ЖКХ у нас ещё на стадии создания, но получаемый XMLDSig проходит необходимые проверки.
Надеемся, эта статья облегчит кому-нибудь задачу по реализации подобного велосипеда.

Спасибо за внимание.

Cсылки

• Регламент и форматы информационного взаимодействия внешних информационных систем с ГИС ЖКХ (текущие форматы v.8.7.0.7)
• Good-Samaritan/signature-demo
• HOWTO use Stunnel with GOST
• «Почему всем можно, а мне нельзя?» или реверсим API и получаем данные с eToken
• XMLDSig: формат подписи XML