Подписание и проверка электронной цифровой подписи бизнес-сообщений

Формирование и проверка ЭЦП осуществляется в порядке, установленном законодательством Республики Казахстан.

Для формирования ЭЦП БВУ-участники должны использовать регистрационные свидетельства, выпускаемые УЦ АО «НПК». Подробная информация по выпуску регистрационных свидетельств, описания технических аспектов алгоритмов подписания, а также корневые сертификаты УЦ АО «НПК» доступны по ссылке https://npck.kz/udostoveryayushhij-tsentr/

Для работы с регистрационными свидетельствами УЦ АО «НПК» БВУ-участнику необходимо использовать программное средство криптографической защиты информации «ТУМАР-CSP». При необходимости, сотрудниками АО «НПК» обеспечивается консультационная поддержка по вопросам выпуска и применения регистрационных свидетельств, а также инструкции по установке и настройке ПО «ТУМАР-CSP».

По запросу может быть предоставлен проект (пример) подписания и проверки подписи на Kotlin, а также docker-контейнер с реализованным подписанием и проверкой подписи для запуска, что позволит упростить процесс реализации работы с ЭЦП.

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

Важно:

  • Предоставляемые примеры кода и сервисы (в Docker-контейнере) являются вспомогательными (необязательными к использованию). Они предназначены для ознакомления и упрощения начала работы с ЭЦП, АО «НПК» не несет ответственности за их корректную работу, эффективность и производительность. Не рекомендуем использовать данный сервис в production среде. Рекомендуется самостоятельно реализовать полноценную работу с ЭЦП на стороне банка.

  • При сборке и запуске проекта npck-transfers-adapter необходимо учитывать архитектуру системы. На устройствах с процессорами Apple Silicon (ARM, macOS) возможны ошибки при подписании или несовместимости зависимостей. Рекомендуется выполнять сборку и запуск на системах x86_64 (Intel / AMD) либо использовать контейнер с образом, собранным под x86. Если работа ведётся на macOS с архитектурой ARM, убедитесь, что контейнер запускается с правильной архитектурой.

Подписание сообщения

Бизнес-часть всех сообщений подписывается в обязательном порядке.

Данные подписываются, применяя алгоритм подписания СТ РК ГОСТ Р 34.10-2015 (512).

После выполнения подписи xml файла - его НЕЛЬЗЯ форматировать, нужно отправлять неизмененным.

Иначе подпись будет невалидна и будет возвращен HTTP-статус 401

Подписание бизнес части сообщения осуществляется посредством XML-подписи (XML-Signature) по спецификации консорциума W3C XMLDSIG (XML-Signature Syntax and Processing). Полученный результат помещается в теге <Document> → <Signature>.

Структуру подписи сообщения описывает таблица ниже.

Поле
Описание

Signature

Подпись сообщения

SignedInfo

Сведения о подписи: включает в себя алгоритм канонизации, алгоритм подписи и один или несколько элементов Reference

CanonicalizationMethod

Метод канонизации (определяет конкретный набор правил для упрощения и структурирования экземпляра XML до подписания)

SignatureMethod

Алгоритм, используемый для создания подписи.

Данные подписываются, применяя алгоритм подписания СТ РК ГОСТ Р 34.10-2015 (512)

Reference

Определяет данные, которые подписываются, и содержит информацию о них, такую как URI (или хэш) подписываемых данных и информацию о применяемом алгоритме хэширования

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

Transforms

Представляет список элементов преобразования

DigestMethod

Определяет алгоритм хэширования, который используется для создания хэш-значения для данных, подлежащих подписи

DigestValue

Элемент содержит само значение хэша, которое было вычислено для данных, указанных в элементе Reference. Значение хэша представляет собой результат применения алгоритма хэширования (определенного в элементе DigestMethod) к подписываемым данным

SignatureValue

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

KeyInfo

Этот элемент содержит информацию о ключе, используемом для создания подписи.

X509Data

Идентификатор ключа или сертификат X509 (идентификатор сертификата или список отозванных сертификатов)

X509Certificate

Сертификат, закодированный в base64.

Пример подписи:

Проверка ЭЦП сообщений

Проверка подлинности ЭЦП сообщения осуществляется следующим образом:

  1. Извлекается регистрационное свидетельство из структуры заголовка бизнес-сообщения (из тега <Document> → <Signature> → <KeyInfo> → <X509Data> → <X509Certificate>).

  2. Извлеченное регистрационное свидетельство проверяется на то, что оно действительно выпущено промышленным УЦ АО «НПК».

Корневые регистрационные свидетельства УЦ доступны по ссылке https://npck.kz/registratsionnye-svidetelstva-uts-i-spiski-otozvannyh-sertifikatov/ (Алгоритм ГОСТ 34.310-2015)

  1. Проверяется срок действия регистрационного свидетельства.

  2. Проверяется отозванность регистрационного свидетельства – должно быть не отозвано на момент подписи.

  3. Проверяются области использования ключа.

Для ЭЦП должны присутствовать области использования ключа Digital Signature, Non-Repudiation

  1. Проверяются политики применения ключа OID policy. OID policy=1.2.398.3.5.2.23.1

  2. Проверяется алгоритм формирования подписи (подпись сформирована с применением алгоритма СТ РК ГОСТ Р 34.10-2015 (512), OID алгоритма = 1.2.398.3.10.1.1.2.3.2).

  3. Проверяется корректность электронной подписи.

Используемый для подписания сертификат должен быть выдан той организации, которая подписывает сообщения (проверка по полю subject (по БИН)).

В сообщениях, полученных от Платформы, должен быть указан БИН АО «НПК» (960440000151).

PreviousГенерация уникальных идентификаторов для сообщенийNextИспользование QR-кода для совершения платежей

Last updated