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

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

{% hint style="info" %}
&#x20;Для формирования ЭЦП БВУ-участники должны использовать регистрационные свидетельства, выпускаемые УЦ АО «НПК». Подробная информация по выпуску регистрационных свидетельств, описания технических аспектов алгоритмов подписания, а также корневые сертификаты УЦ АО «НПК» доступны по ссылке <https://npck.kz/udostoveryayushhij-tsentr/>
{% endhint %}

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

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

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

*<mark style="color:red;">**Важно:**</mark>*

* *<mark style="color:red;">**Предоставляемые примеры кода и сервисы (в Docker-контейнере) являются вспомогательными (необязательными к использованию). Они предназначены для ознакомления и упрощения начала работы с ЭЦП, АО «НПК» не несет ответственности за их корректную работу, эффективность и производительность. Не рекомендуем использовать данный сервис в production среде.**</mark>*
  \
  *<mark style="color:red;">**Рекомендуется самостоятельно реализовать полноценную работу с ЭЦП на стороне банка.**</mark>*
* ***При сборке и запуске проекта npck-transfers-adapter необходимо учитывать архитектуру системы.***
  \
  ***На устройствах с процессорами Apple Silicon (ARM, macOS) возможны ошибки при подписании или несовместимости зависимостей.***
  \
  ***Рекомендуется выполнять сборку и запуск на системах x86\_64 (Intel / AMD) либо использовать контейнер с образом, собранным под x86.***
  \
  ***Если работа ведётся на macOS с архитектурой ARM, убедитесь, что контейнер запускается с правильной архитектурой.***
  {% endhint %}

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

{% hint style="warning" %}
Бизнес-часть всех сообщений подписывается в обязательном порядке.&#x20;

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

{% hint style="warning" %}
После выполнения подписи xml файла - его **НЕЛЬЗЯ** форматировать, нужно отправлять неизмененным.&#x20;

Иначе подпись будет невалидна и будет возвращен HTTP-статус 401&#x20;
{% endhint %}

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

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

<table><thead><tr><th width="330">Поле</th><th>Описание</th></tr></thead><tbody><tr><td>Signature</td><td>Подпись сообщения</td></tr><tr><td><br>   SignedInfo</td><td>Сведения о подписи: включает в себя алгоритм канонизации, алгоритм подписи и один или несколько элементов Reference</td></tr><tr><td><br>         CanonicalizationMethod</td><td>Метод канонизации (определяет конкретный набор правил для упрощения и структурирования экземпляра XML до подписания)</td></tr><tr><td>         SignatureMethod<br></td><td><p>Алгоритм, используемый для создания подписи.</p><p>Данные подписываются, применяя алгоритм подписания СТ РК ГОСТ Р 34.10-2015 (512)</p></td></tr><tr><td>         Reference<br></td><td><p>Определяет данные, которые подписываются, и содержит информацию о них, такую как URI (или хэш) подписываемых данных и информацию о применяемом алгоритме хэширования </p><p>Содержит алгоритм формирования цифровой подписи, список преобразований, может содержать идентификатор подписываемого объект</p></td></tr><tr><td><br>               Transforms</td><td>Представляет список элементов преобразования</td></tr><tr><td>               DigestMethod<br></td><td>Определяет алгоритм хэширования, который используется для создания хэш-значения для данных, подлежащих подписи</td></tr><tr><td><br>               DigestValue</td><td>Элемент содержит само значение хэша, которое было вычислено для данных, указанных в элементе Reference. Значение хэша представляет собой результат применения алгоритма хэширования (определенного в элементе DigestMethod) к подписываемым данным</td></tr><tr><td><br>   SignatureValue</td><td>Это значение, полученное путем применения алгоритма подписи к канонизированным данным, подписанным закрытым ключом. Это элемент, содержащий фактическое значение подписи</td></tr><tr><td><br>   KeyInfo</td><td>Этот элемент содержит информацию о ключе, используемом для создания подписи. </td></tr><tr><td>         X509Data<br></td><td>Идентификатор ключа или сертификат X509 (идентификатор сертификата или список отозванных сертификатов)</td></tr><tr><td>               X509Certificate<br></td><td>Сертификат, закодированный в base64.</td></tr></tbody></table>

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

```xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Document
	xmlns:ns0="urn:iso:std:iso:20022:tech:xsd:xxx.nnn.nnn.nn">
	<!-- Содержимое сообщения -->
	<ds:Signature
		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="urn:ietf:params:xml:ns:pkigovkz:xmlsec:algorithms:gostr34102015-gostr34112015-512"/>
			<ds:Reference URI="">
				<ds:Transforms>
					<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
					<ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/>
				</ds:Transforms>
				<ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:pkigovkz:xmlsec:algorithms:gostr34112015-512"/>
				<ds:DigestValue>5Db4igpZm5S0qUWJIta7W6T8YBOa8r...
</ds:DigestValue>
			</ds:Reference>
		</ds:SignedInfo>
		<ds:SignatureValue>ZvbD3pMlj9H2RXCxcV9/pcQ7Iayxgmz...
        </ds:SignatureValue>
		<ds:KeyInfo>
			<ds:X509Data>
				<ds:X509Certificate>MIIEtjCCBB6gAwIBAgIUYEeZfcJ...
</ds:X509Certificate>
			</ds:X509Data>
		</ds:KeyInfo>
	</ds:Signature>
</Document>
```

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

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

1. Извлекается регистрационное свидетельство из структуры заголовка бизнес-сообщения (из тега \<Document> → \<Signature> → \<KeyInfo> → \<X509Data> → \<X509Certificate>).
2. Извлеченное регистрационное свидетельство проверяется на то, что оно действительно выпущено промышленным УЦ АО «НПК».&#x20;

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

3. Проверяется срок действия регистрационного свидетельства.&#x20;
4. Проверяется отозванность регистрационного свидетельства – должно быть не отозвано на момент подписи.

{% hint style="warning" %}

Важно:
\
В качестве альтернативного механизма, при недоступности сервиса OCSP (порт 62255), проверка статуса сертификата (отозван/не отозван) может выполняться с использованием списка отозванных сертификатов (CRL, Certificate Revocation List).

CRL периодически загружается из удостоверяющего центра по адресу <http://ca.kisc.kz/cgi/RevListGOST.crl> и хранится локально.
{% endhint %}

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

{% hint style="info" %}
Для ЭЦП должны присутствовать области использования ключа Digital Signature, Non-Repudiation
{% endhint %}

6. Проверяются политики применения ключа OID policy. OID policy=1.2.398.3.5.2.23.1
7. Проверяется алгоритм формирования подписи (подпись сформирована с применением алгоритма СТ РК ГОСТ Р 34.10-2015 (512), OID алгоритма = `1.2.398.3.10.1.1.2.3.2`).
8. Проверяется корректность электронной подписи.

{% hint style="info" %}
Используемый для подписания сертификат должен быть выдан той организации, которая подписывает сообщения (проверка по полю subject (по БИН)).&#x20;

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/podpisanie-i-proverka-elektronnoi-cifrovoi-podpisi-biznes-soobshenii.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.