Криптопро dss руководство разработчика

Catch__The___Wave	#1 Оставлено : 18 января 2021 г. 0:50:26(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 18.01.2021(UTC) Сообщений: 7 Сказал(а) «Спасибо»: 2 раз	Добрый день! В руководстве для разработчиков на 145 странице: Примеры взаимодействия с КриптоПро DSS находятся на дистрибутивном диске в папке DssSamples, либо доступны для скачивания по ссылке Примеры встраивания для разработчиков. Я скачиваю с этой страницы Дистрибутив ПАК «КриптоПро DSS» версии 2.0 (сборка 2.0.3284). Но внутри нет папки, на которую ссылаются в руководстве. Подскажите, пожалуйста, где можно найти эти примеры с папки DssSamples. Отредактировано пользователем 18 января 2021 г. 0:51:18(UTC)  | Причина: Не указана

Андрей Солдатов	#2 Оставлено : 18 января 2021 г. 9:11:43(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 12.03.2019(UTC) Сообщений: 314 Откуда: Москва Сказал «Спасибо»: 4 раз Поблагодарили: 66 раз в 62 постах	Добрый день. Руководство, доступное по указанной Вами ссылке, не является актуальным. Ранее распространялись примеры интеграции на Java через SOAP API DSS. SOAP API более не развивается и оставлен для обратной совместимости. Все новые интеграции должны быть выполнены через REST API DSS. Описание REST API доступно в руководстве разработчика в комплекте документации, а также в Online документации.
Техническую поддержку оказываем тут. Наша база знаний.

Catch__The___Wave	#3 Оставлено : 19 января 2021 г. 18:46:03(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 18.01.2021(UTC) Сообщений: 7 Сказал(а) «Спасибо»: 2 раз	Спасибо за ответ! А если интеграция планируется через SOAP все-таки? Какое руководство актуальное?

Андрей Солдатов	#4 Оставлено : 19 января 2021 г. 18:51:45(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 12.03.2019(UTC) Сообщений: 314 Откуда: Москва Сказал «Спасибо»: 4 раз Поблагодарили: 66 раз в 62 постах	Автор: Catch__The___Wave Спасибо за ответ! А если интеграция планируется через SOAP все-таки? Какое руководство актуальное? Добрый день. Используйте вот это: https://file.cryptopro.r…odstvo_razrabotchika.pdf Свежее руководства нет по ранее озвученным причинам — развиваться SOAP в DSS не будет. Настоятельно рекомендую сразу использовать REST — избежите большого числа проблем + сможете использовать api DSS v2.
Техническую поддержку оказываем тут. Наша база знаний.
2 пользователей поблагодарили Андрей Солдатов за этот пост.	Андрей * оставлено 19.01.2021(UTC), Catch__The___Wave оставлено 19.01.2021(UTC)

Catch__The___Wave	#5 Оставлено : 19 января 2021 г. 21:01:38(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 18.01.2021(UTC) Сообщений: 7 Сказал(а) «Спасибо»: 2 раз	Спасибо, ознакомилась с документацией и возникло два вопроса. 1. тут задавали вопрос, но ответа нет. Так что же возвращает функция SignDocument. В документации написано лишь «подписанный документ в виде массива байт». Если это документ+подпись, то можно от нее отделить подпись(например, подпись в конце) как в вебе, где можно скачивать подпись документа? 2. В веб клиента dss можно проверять действительность подписи. Если такая возможность через rest и soap api?

Андрей Солдатов	#6 Оставлено : 20 января 2021 г. 0:21:41(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 12.03.2019(UTC) Сообщений: 314 Откуда: Москва Сказал «Спасибо»: 4 раз Поблагодарили: 66 раз в 62 постах	Автор: Catch__The___Wave Спасибо, ознакомилась с документацией и возникло два вопроса. 1. тут задавали вопрос, но ответа нет. Так что же возвращает функция SignDocument. В документации написано лишь «подписанный документ в виде массива байт». Если это документ+подпись, то можно от нее отделить подпись(например, подпись в конце) как в вебе, где можно скачивать подпись документа? 2. В веб клиента dss можно проверять действительность подписи. Если такая возможность через rest и soap api? 1. При создании открепленной подписи в ответе на запрос возвращается массив байт подписи, не исходный документ. 2. Для проверки подписи и сертификатов можете использовать продукт КриптоПро SVS, у которого есть собственное API. Руководство разработчика для SVS доступно здесь.
Техническую поддержку оказываем тут. Наша база знаний.
1 пользователь поблагодарил Андрей Солдатов за этот пост.	Catch__The___Wave оставлено 20.01.2021(UTC)

Catch__The___Wave	#7 Оставлено : 20 января 2021 г. 22:45:25(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 18.01.2021(UTC) Сообщений: 7 Сказал(а) «Спасибо»: 2 раз	Большое спасибо

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

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

Интеграция посредством HTTP API

1. Пользователь отправляет сформированный платежный документ в систему ДБО.
2. Система ДБО, используя штатные документированные механизмы КриптоПро DSS (HTTP API), перенаправляет пользователя на веб-интерфейс КриптоПро DSS, передавая в этом перенаправлении подписанный маркер доступа (SAML-токен), содержащий информацию о пользователе (имя пользователя, номер мобильного телефона и т.п.), и подписываемый документ.
3. Для подтверждения подписания документа КриптоПро DSS направляет пользователю SMS-сообщение, содержащее код подтверждения подписания и значимые поля документа (например, получатель, сумма и т.п.), на номер мобильного телефона полученный в маркере доступа.
4. Пользователь вводит полученный код подтверждения в поле формы веб-интерфейса КриптоПро DSS.
5. КриптоПро DSS, используя документированные функции ПАКМ «КриптоПро HSM», отправляет запрос на подписание документа с использованием закрытого ключа пользователя и получает подписанный документ.
6. КриптоПро DSS перенаправляет пользователя на веб-интерфейс системы ДБО, передавая в перенаправлении подписанный документ.

Интеграция посредством SOAP

1. Пользователь отправляет сформированный платежный документ в систему ДБО.
2. Система ДБО, используя штатные документированные механизмы КриптоПро DSS (SOAP), передает подписываемый документ и подписанный маркер доступа (SAML-токен), содержащий информацию о пользователе (имя пользователя, номер мобильного телефона и т.п.).
3. Для подтверждения подписания документа КриптоПро DSS направляет пользователю SMS-сообщение, содержащее код подтверждения подписания и значимые поля документа (например, получатель, сумма и т.п.), на номер мобильного телефона полученный в маркере доступа.
4. Пользователь вводит полученный код подтверждения в поле формы веб-интерфейса системы ДБО.
5. Система ДБО передает полученный код подтверждения КриптоПро DSS.
6. КриптоПро DSS, используя документированные функции ПАКМ «КриптоПро HSM», отправляет запрос на подписание документа с использованием закрытого ключа пользователя и получает подписанный документ.
7. КриптоПро DSS передает подписанный документ в систему ДБО.

Масштабируемость и отказоустойчивость

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

ПАК «КриптоПро DSS» предназначен для защищенного хранения закрытых ключей пользователей, а также для удаленного выполнения операций по созданию электронной подписи. Интеграция c Рутокен KeyBox позволяет осуществлять выпуск и централизованный учёт средств облачной аутентификации. Для работы с электронной подписью не требуется устройство (USB-токен или смарт-карта), ключи генерируются и хранятся в хранилище КриптоПро DSS, для доступа и использования электронной подписи применяется облачный криптопровайдер КриптоПро Cloud CSP.

Предварительные условия

Для интеграции Рутокен KeyBox c КриптоПро DSS в окружении компании должны быть развернуты:

• Сервер RutokenKeyBox версии 5.1 и выше;
• ПАК «КриптоПро УЦ» 2.0;
• ПАК «КриптоПро DSS»;
• ПАКМ «КриптоПро HSM»;
• КриптоПро CSP 5.0;
• Настроенная интеграция КриптоПро УЦ 2.0 с КриптоПро DSS.

Интеграция УЦ и DSS необходима для управления пользователями и их сертификатами в удостоверяющем центре. КриптоПро DSS выступает в роли привилегированного пользователя по отношению к КриптоПро УЦ 2.0. Создание и обновление пользователей, запрос сертификатов и прочие действия на УЦ в этом случае выполняются от имени Оператора DSS. Подробная инструкция по интеграции входит комплект поставки ПАК «КриптоПро DSS».

Настройка интеграции в Рутокен KeyBox

Для работы с DSS сервер используется учётная запись Оператор DSS, сертификат которой должен хранится на сервере RutokenKeyBox. Для установки сертификата Оператора DSS выполните следующие действия:

1. Добавьте сертификат Оператора DSS в локальное хранилище компьютера (Local Computer) на сервере RutokenKeyBox.
2. Добавьте корневой сертификат КриптоПро УЦ 2.0 и корневой сертификат DSS в Доверенные корневые центры сертификации (Trusted Root Certification Authorities) на сервере RutokenKeyBox.
3. Выдайте системе Рутокен KeyBox права на чтение закрытого ключа сертификата Оператора DSS.

• • В оснастке Сертификаты (Certificates) компьютера, на котором установлен сервер RutokenKeyBox.
  • Кликните правой кнопкой мыши на сертификате, выберите Все задачи (All tasks) > Управление закрытыми ключами…(Manage Private Keys…).
  • Нажмите Добавить (Add), укажите локальную группу IIS_IUSRS (если используется IIS 7.0) или локальную учетную запись IIS AppPoolRutokenKeyBox (если используется IIS 7.5 и более поздние версии).
  • Выставите права Полный доступ (FullControl).
  • Нажмите Применить (Apply).

Выдайте права на папку с пользователями в КриптоПро УЦ 2.0 для учётной записи Оператор DSS:

1. Создайте группу безопасности, например DSS Operators и включите в неё учётную запись Оператор DSS.
2. Откройте свойства папки, в которой будут располагаться пользователи DSS, перейдите на вкладку безопасность и добавьте созданную группу DSS Operators.
3. Выдайте группе разрешения (таблица 2).

Таблица 2 —Набор прав для сервисной группы пользователей DSS Operators.

Время на прочтение
6 мин

Количество просмотров 3.4K

Всем привет! Я Максим, бэкенд-разработчик команды MSB (корпоративная сервисная шина), занимаюсь интеграциями систем для внутренних нужд компании Tele2, и в этом посте хочу поделиться опытом интеграции с “КриптоПро DSS” поверх ГОСТ TLS.

Введение

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

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

Мы встроили данный SDK в наше корпоративное мобильное приложение, о котором писала моя коллега в своей статье на Хабре.

Но мой рассказ связан с опытом решения задачи со стороны бэкенда, и мы рассмотрим эту задачу подробнее.

Описание проблемы и её решение

В нашей схеме подключение к серверу электронной подписи осуществляется по ГОСТ TLS с аутентификацией клиента по сертификату.

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

В качестве эксперимента пробовал подключить rtengine, но он не завёлся, и, помимо прочего, он не является сертифицированным средством защиты информации. В таких случаях “КриптоПро” советует использовать «КриптоПро Stunnel».

Изначально, stunnel – это open-source приложение, выступающее в роли шлюза, который принимает незашифрованный трафик и пересылает его на целевой сервер поверх TLS. Часто используется, когда клиент сам не поддерживает TLS-шифрование.

А Stunnel от “КриптоПро” – это практически тот же stunnel, но с поддержкой ГОСТ TLS, а значит, он замечательно подходит для решения нашей проблемы.

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

Чтобы обойти это ограничение, в схему было решено добавить еще одно известное Linux-администраторам приложение socat (еще один шлюз, в своем роде), который умеет делать подключения через HTTP-прокси. Важное условие – HTTP-прокси должен разрешать подключения через метод CONNECT.

В итоге схема станет такой:

Docker

Для упрощения было решено пренебречь правилом “один контейнер – один процесс” и запускать “КриптоПро Stunnel” и socat в одном контейнере. Данный контейнер поднимается в виде sidecar рядом с основным контейнером микросервиса. Это позволяет нашему микросервису общаться с “КриптоПро DSS” так, как будто бы они общались по http-протоколу, а вопросы шифрования трафика по ГОСТ TLS отдаются на откуп контейнеру с stunnel и socat.

Чтобы подготовить образ контейнера, нужно скачать deb-пакет с “КриптоПро CSP” (именно в составе этого дистрибутива и состоит “КриптоПро Stunnel”). К сожалению, скачать пакет нельзя по прямой ссылке, которую можно было бы прописать в Dockerfile (иначе бы статья получилась в два раза короче). Для скачивания нужно пройти регистрацию на сайте “КриптоПро”, и только потом будет дана возможность скачать пакет.

Ниже приведен пример Dockerfile, скриптов инициализации и конфига для “КриптоПро Stunnel”. 

Рабочий пример можно также посмотреть здесь.

Dockerfile

FROM debian:buster-slim

EXPOSE 80/tcp

ARG TZ=Europe/Moscow
ENV PATH="/opt/cprocsp/bin/amd64:/opt/cprocsp/sbin/amd64:${PATH}"

# stunnel settings
ENV STUNNEL_HOST="example.cryptopro.ru:4430"
ENV STUNNEL_HTTP_PROXY=
ENV STUNNEL_HTTP_PROXY_PORT=80
ENV STUNNEL_HTTP_PROXY_CREDENTIALS=
ENV STUNNEL_DEBUG_LEVEL=5
ENV STUNNEL_CERTIFICATE_PFX_FILE=/etc/stunnel/certificate.pfx
ENV STUNNEL_CERTIFICATE_PIN_CODE=

# dependencies
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime 
	&& echo $TZ > /etc/timezone 
	&& apt-get update 
	&& apt-get -y install lsb-base curl socat 
	&& rm -rf /var/lib/apt/lists/*
	
# install cryptopro csp
WORKDIR /dist
COPY dist/csp_deb.tgz csp_deb.tgz
RUN tar -zxvf csp_deb.tgz --strip-components=1 
	&& ./install.sh cprocsp-stunnel
	
WORKDIR /

COPY conf/ /etc/stunnel
COPY bin/docker-entrypoint.sh docker-entrypoint.sh
COPY bin/stunnel-socat.sh stunnel-socat.sh

RUN chmod +x /docker-entrypoint.sh /stunnel-socat.sh
	
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["stunnel_thread", "/etc/stunnel/stunnel.conf"]

docker-entrypoint.sh

#!/bin/bash
# скрипт инициализации

# ---------------------------------
# настройка csp
echo "Configuring CryptoPro CSP..."

# импорт сертификата с закрытым ключом
if [[ ! -f "$STUNNEL_CERTIFICATE_PFX_FILE" ]]; then
    echo "Client certificate not found in ${STUNNEL_CERTIFICATE_PFX_FILE}"
    exit 1
fi

certmgr -install -pfx -file "${STUNNEL_CERTIFICATE_PFX_FILE}" -pin "${STUNNEL_CERTIFICATE_PIN_CODE}" -silent || exit 1
echo "Certificate was imported."
echo

# определение контейнера-хранилища закрытых ключей
containerName=$(csptest -keys -enum -verifyc -fqcn -un | grep 'HDIMAGE' | awk -F'|' '{print $2}' | head -1)
if [[ -z "$containerName" ]]; then
    echo "Keys container not found"
    exit 1
fi

# установка сертификата клиента
certmgr -inst -cont "${containerName}" -silent || exit 1

# экспорт сертификата для stunnel
exportResult=$(certmgr -export -dest /etc/stunnel/client.crt -container "${containerName}")
if [[ ! -f "/etc/stunnel/client.crt" ]]; then
    echo "Error on export client certificate"
    echo "$result"
    exit 1
fi

echo "CSP configured."
echo

# ---------------------------------
# запуск socat
echo "Starting socat..."
nohup bash /stunnel-socat.sh </dev/null >&1 2>&1 &

# ---------------------------------
# запуск stunnel
echo "Configuring stunnel..."
sed -i "s/^debug=.*$/debug=$STUNNEL_DEBUG_LEVEL/g" /etc/stunnel/stunnel.conf

echo "Starting stunnel"
exec "$@"

stunnel-socat.sh

#!/bin/bash
echo Configuring socat...

socatParameters="TCP:${STUNNEL_HOST}"

if [[ -n "$STUNNEL_HTTP_PROXY" ]]; then
    # если указан http-прокси, подключение будет происходить через него
    socatParameters="PROXY:${STUNNEL_HTTP_PROXY}:${STUNNEL_HOST},proxyport=${STUNNEL_HTTP_PROXY_PORT}"

    if [[ -n "$STUNNEL_HTTP_PROXY_CREDENTIALS" ]]; then
        socatParameters="${socatParameters},proxyauth=${STUNNEL_HTTP_PROXY_CREDENTIALS}"
    fi
fi

socatCmd="socat UNIX-LISTEN:/var/run/socat.sock,reuseaddr,fork ${socatParameters}"

while true; do
    rm -f /var/run/socat.sock
    echo $(date) "Start socat instance."
    ${socatCmd}
    sleep 1
done

stunnel.conf

foreground=yes
pid=/var/opt/cprocsp/tmp/stunnel_cli.pid
output=/dev/stdout
debug=5

[https]
client=yes
accept=80
cert=/etc/stunnel/client.crt
verify=0
connect=/var/run/socat.sock

Про Dockerfile рассказывать не буду, он достаточно тривиален, а вот скрипт инициализации docker-entrypoint.sh интереснее. Первым делом скрипт импортирует сертификат с закрытым ключом в хранилище ключей, так как “КриптоПро Stunnel” для работы необходим закрытый ключ. Затем из хранилища экспортируется сертификат с открытым ключом в формате DER. В дальнейшем по этому сертификату “КриптоПро Stunnel” будет получать закрытый ключ из хранилища ключей.

После инициализации хранилища ключей происходит настройка и запуск socat. Для конфигурирования socat добавлены переменные окружения, которые позволяют указать, через какой HTTP-прокси необходимо выполнять запросы. Не буду останавливаться на этих переменных – их описание есть в репозитории. Однако не лишним будет уточнить, что, если переменные не указаны, socat будет самостоятельно выполнять TCP-запросы до целевого сервера. Для получения входящих запросов socat открывает unix-сокет, на который и будет обращаться “КриптоПро Stunnel”.

Финальным шагом в скрипте являются конфигурирование Stunnel и его последующий запуск. 

“КриптоПро Stunnel” при запуске начинает прослушивать порт 80, то есть принимать голый HTTP-трафик. HTTP-трафик будет шифроваться по ГОСТу и пересылаться на unix-сокет, который слушает socat. Socat, в свою очередь, откроет соединение с целевым сервером, напрямую или через HTTP-прокси, и отправит уже шифрованный запрос. 

Шифрованный ответ от целевого сервера пройдет ту же цепочку, только обратном порядке, и вызывающему приложению будет возвращен ответ в виде plain text, что позволит не реализовывать ГОСТ TLS внутри приложений (если такая реализация вообще возможна).

Вместо заключения

К сожалению, документация по отечественным решениям зачастую достаточно скромна. К примеру, на попытки заставить работать “КриптоПро Stunnel” через HTTP-прокси ушло много времени, пока не пришло понимание, что “КриптоПро Stunnel” прокси не поддерживает и что без еще одного инструмента не обойтись.
Данная статья призвана помочь сберечь ваше время, надеюсь, описанное окажется полезным.

Бонус

Список ресурсов

• stunnel TLS Proxy

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

• КриптоПро. Форум

• man socat

Нашли ошибку? Выделите
текст с ошибкой и нажмите кнопку «Сообщить об ошибке»
или CTRL+ENTER.

Справочная
система на версию 22.04 от 20/04/2023,
© ООО «ФОРСАЙТ»,