Обмен с кредитными организациями и другими клиентами банка России (стр. 18 )

7.3.2  Правила проверки ЗК

Процесс проверки ЗК на защищаемой части ЭС (ЭД/пакета ЭД) состоит из следующих этапов:

a)  получение XML-элемента, содержащего защищаемую ЗК часть ЭС (ЭД/пакета ЭД).

b)  выделение значения ЗК из элемента sig:SigValue.

c)  раскодирование значения ЗК, выделенного на предыдущем этапе, по алгоритму [base64].

d)  выделение из XML-элемента, полученного на этапе, описанном в перечислении a), данных, защищаемых ЗК в соответствии с 7.2.5.

e)  применение к XML-документу, полученному на предыдущем этапе, трансформаций, приведенных в профиле параметров защиты ЭС (ЭД/пакета ЭД) с помощью ЗК: преобразование XML-документа к нормализованному виду и канонизация. В результате канонизации будет получен массив байт.

f)  проверка ЗК: вызов функции СКЗИ по проверке ЗК с передачей ей массивов байтов, полученных на этапах, описанных в перечислениях e) и c).

8  Защита электронных сообщений (ЭД/пакетов ЭД) с помощью ЭЦП (КА)

ЭС должны быть защищены с использованием ЭЦП (КА). При этом необходимым требованием является передача сообщения получателю в том виде, в котором оно было подписано отправителем.

В данном разделе приводятся правила оформления ЭЦП (КА) в ЭС, определены подписываемые части XML-документа.

8.1  Область применения

В настоящем разделе приведено описание правил оформления, формирования и проверки ЭЦП (КА), применяемого в рамках УФЭБС для обмена электронными сообщениями учреждений Банка России с кредитными организациями и другими клиентами Банка России, расположенными на территории Российской Федерации, при осуществлении безналичных расчетов в валюте Российской Федерации.

Обмен документами в формате XML приводит к возможности несанкционированного доступа к информации. Для предотвращения несанкционированного доступа к информации вводится поддержка шифрования данных на прикладном уровне. Для экономии затрат на передачу и хранение данных вводится поддержка сжатия данных на прикладном уровне.

Процедура разрешения разногласий при обмене электронными сообщениями состоит в доказательстве неизменности отправленного сообщения при доставке до получателя, основанном на применении средств контроля целостности и подтверждения авторства сообщений, представленных отправляющей и получающей сторонами в установленном порядке. В связи с этим необходимым требованием при использовании УФЭБС является передача сообщения получателю в том виде, в котором оно было подписано отправителем. То есть проверяемое ЭС (ЭД/пакет ЭД) должен в точности (до байта) совпадать с подписанным ЭС (ЭД/пакетом ЭД). Таким образом, подписанное ЭС (ЭД/пакет ЭД) должено быть передано в конверте ЭЦП (КА) в своем двоичном представлении. Для передачи двоичных данных в XML-документе спецификация [XML-schema] рекомендует использовать алгоритм кодирования [base64].

Данные, преобразованные по алгоритму [deflate], можно однозначно восстановить из сжатой последовательности, а выбранный алгоритм шифрования, также, должен однозначно восстанавливать данные при дешифровании. Использование алгоритмов [base64] и [deflate] гарантирует идентичность двоичного представления подписанного и проверяемого ЭС (ЭД/пакета ЭД).

Ниже (см. рисунок 16,рисунок 17) представлены схемы обработки ЭЦП (КА). При построении схем использовались условные обозначения (см. таблица 53).

Таблица 53 – Условные обозначения, используемые при построении схем обработки ЭЦП (КА)

Обозначение	Описание	Обозначение	Описание
	Обязательный процесс		Объект
	Опциональный процесс		Движение между состояниями объекта
	XML-документ, отвечающий требованиям [XML]		Передача объекта процессу

8.2  Требования по защите ЭС (ЭД/пакета ЭД) с помощью ЭЦП (КА)

8.2.1  Пространства имен

Для данной версии настоящего документа используются пространства имен:

"urn:cbr-ru:dsig:v1.1” (префикс dsig)

”urn:cbr-ru:dsig:env:v1.1” (префикс sen)

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

Рисунок 16 – Схема формирования ЭЦП (КА)

Рисунок 17 – Схема формирования ЭЦП (КА)

8.2.2  Структура и синтаксис конверта ЭЦП (КА)

Конверт ЭЦП (КА) содержит значения ЭЦП (КА), а также подписанное ЭС (ЭД/пакет ЭД). Конверт ЭЦП (КА) представлен в виде элемента sen:SigEnvelope.

Конверт ЭЦП (КА) состоит из:

–  контейнера для значения ЭЦП (КА), который представлен в виде элемента sen:SigContainer. Контейнер (элемент sen:SigContainer) содержит элемент из пространства имен ”urn:cbr-ru:dsig:v1.1” со значением ЭЦП (КА);

–  элемента sen:Object, который содержит подписанное ЭС (ЭД/пакет ЭД), закодированное по алгоритму [base64]. Перед кодированием по алгоритму [base64] ЭС (ЭД/пакет ЭД) может быть сжато и/или зашифровано.

Описание реквизитов конверта ЭЦП (КА) (элемента sen:SigEnvelope) представлено в таблице ниже (см. таблица 54).

Пространство имен
”urn:cbr-ru:dsig:env:v1.1” (префикс sen)

Таблица 54 – Реквизиты конверта ЭЦП (КА)

Описание реквизита	Тип реквизита	Крат-ность
1 Контейнер для ЭЦП (КА) (sen:SigContainer)		[1]
1.1 Значение ЭЦП (КА) (any namespace=”urn:cbr-ru:dsig:v1.1”)	Элемент, содержащий значение ЭЦП (КА)	[1]
2 Контейнер для подписываемого объекта. (sen:Object)	Элемент, содержащий подписанное ЭС (ЭД/пакет ЭД), закодированный по алгоритму [base64]	[1]

Примечание – данная нотация не описывает структуру реквизита со значением ЭЦП (КА).

Структурно реквизит со значением ЭЦП (КА) представлен элементом dsig:MACValue, в который помещается значение ЭЦП (КА), рассчитываемое по алгоритму, указанному в профиле параметров защиты ЭС (ЭД/пакета ЭД) с помощью ЭЦП (КА) (см. таблица 56). Значение ЭЦП (КА) приводится в формате, с которым работает используемое СКЗИ, отдельно значение ЭЦП (КА) не выделяется. Перед помещением в элемент dsig:MacValue значение ЭЦП (КА) кодируется по алгоритму [base64]. Структура элемента со значением ЭЦП (КА) представлена в таблице ниже (см. таблица 55).

Пространства имен
“urn:cbr-ru:dsig:v1.1” (префикс dsig)
“http://www. w3.org/2001/XMLSchema” (префикс xsd)

Таблица 55 – Реквизиты элемента со значением ЭЦП (КА)

Описание реквизита	Тип реквизита	Крат-ность
1 Значение ЭЦП (КА) (dsig:MACValue)	xsd:base64Binary	[1]

Пример – оформление значения ЭЦП (КА):

<dsig:MACValue xmlns:dsig="urn:cbr-ru:dsig:v1.1"> RpxoZ6vnUXn9/nTSC9rkqeWtlNYTc+RxWZ5JbdFW6Vlg+ULhx7uDJFPRIdqxXJnIugF2xzlpgjCtmh4hz9tLAg==</dsig:MACValue>

8.2.3  Профиль параметров защиты ЭС (ЭД/пакета ЭД) с помощью ЭЦП (КА)

Защита ЭС (ЭД/пакета ЭД) с помощью ЭЦП (КА) применяется в соответствии с профилем параметров защиты ЭС (ЭД/пакета ЭД) с помощью ЭЦП (КА) (см. таблица 56). Профиль защиты ЭС (ЭД/пакета ЭД) с помощью ЭЦП (КА) содержит перечень спецификаций и алгоритмов, применяемых для приведения ЭС (ЭД/пакета ЭД) к виду, обеспечивающему его защиту системой криптографической защиты информации путем простановки и проверки ЭЦП (КА).

Таблица 56 – Профиль параметров защиты ЭС (ЭД/пакета ЭД) с помощью ЭЦП (КА)

Алгоритм	Идентификатор
Трансформации ЭС (ЭД/пакета ЭД)
Преобразование ЭС (ЭД/пакета ЭД) для приведения к нормализованному виду	не используется
Канонизация XML без комментариев [XML-c14n]	не используется
Кодирование ЭС (ЭД/пакета ЭД)
Алгоритм сжатия (необязательный)	http://www. ietf. org/rfc/rfc1951
Алгоритм шифрования (необязательный)	определяется Договором обмена
Алгоритм кодирования Base64	http://www. ietf. org/rfc/rfc2045#base64
Кодирование значения ЭЦП (КА)
Алгоритм кодирования Base64	http://www. ietf. org/rfc/rfc2045#base64

Криптографическая защита файлов с ЭД должна обеспечиваться на основе использования СКЗИ, имеющих сертификат или временное разрешение ФСБ, либо временное разрешение Банка России.

8.2.4  Ссылка на подписываемые данные

ЭЦП (КА) всегда защищает содержимое элемента sen:Object. Содержимое элемента sen:Object представляет собой XML-документ, содержащий подписываемое ЭС (ЭД/пакет ЭД), закодированный по алгоритму [base64]. XML-документ, содержащий подписываемое ЭС (ЭД/пакет ЭД), должен быть сформирован с учетом требований, предъявляемых к оформлению XML-документов (см. глава 10).

Ниже (см. рисунок 18) представлена иллюстрация, показывающая подписываемые данные при формировании ЭЦП (КА).

Рисунок 18 – Иллюстрация оформления ЭЦП (КА), показывающая подписываемые данные

Подписываемое ЭС (ЭД/пакет ЭД) может содержать ЗК в качестве реквизитов. В этом случае ЭЦП (КА) все равно защищает весь XML-документ, содержащий ЭС (ЭД/пакет ЭД) вместе со всеми реквизитами (в том числе и со всеми ЗК). Ниже (см. рисунок 19) представлена иллюстрация, показывающая подписываемые данные при формировании ЭЦП (КА).

Рисунок 19 – Иллюстрация оформления ЭЦП (КА) для пакета ЭД с защитой каждого ЭД собственным ЗК

8.3  Правила формирования и проверки ЭЦП (КА)

Настоящий раздел описывает порядок необходимых преобразований ЭС (ЭД/пакета ЭД) для формирования и проверки значения ЭЦП (КА).

Правила оформления значения ЭЦП (КА) и определения набора подписываемых данных внутри ЭС (ЭД/пакета ЭД) приведено в описании форматов ЭД.

8.3.1  Правила формирования ЭЦП (КА)

Процесс формирования конверта ЭЦП (КА) состоит из следующих этапов:

a)  формирование XML-документа, содержащего ЭС (ЭД/пакет ЭД), которое должно быть защищено с помощью ЭЦП (КА). XML-документ должен быть сформирован с учетом требований, предъявляемых к оформлению XML-документов в соответствии с подразделом 10.1 Альбома форматов;

b)  сериализация (согласно [XML]) сформированного на предыдущем этапе XML-документа в массив байтов, для которого будет рассчитываться ЭЦП (КА);

c)  формирование (вычисление значения) ЭЦП (КА): вызов функции СКЗИ по формированию ЭЦП (КА) с передачей ей массива байтов, полученного на предыдущем этапе;

d)  сжатие массива данных, полученного на этапе b), если это предусмотрено Договором обмена;

e)  шифрование масива данных, полученного на этапе b), с учетом возможного сжатия на этапе d), если это предусмотрено Договором обмена;

f)  кодирование полученного на этапе c) значения ЭЦП (КА) (в формате библиотеки ЭЦП (КА), без выделения самого значения ЭЦП (КА) по алгоритму [base64];

g)  помещение закодированного на предыдущем этапе значения ЭЦП (КА) в элемент sig:MACValue;

h)  кодирование массива байтов, полученного на этапе b), с учетом возможного сжатия на этапе d) и/или возможного шифрования на этапе e) по алгоритму [base64];

i)  помещение закодированного на предыдущем этапе массива байтов в элемент sen:Object.

j)  оформление конверта ЭЦП (КА) в соответствии с пунктом 8.2.2 Альбома форматов.

8.3.2  Правила проверки ЭЦП (КА)

Процесс проверки ЭЦП (КА) на XML-документе состоит из следующих этапов:

a)  получение XML-документа, содержащего ЭС (ЭД/пакет ЭД), защищенное ЭЦП (КА);

b)  выделение значения ЭЦП (КА) из элемента sig:MACValue;

c)  раскодирование значения ЭЦП (КА), выделенного на предыдущем этапе, по алгоритму [base64];

d)  выделение ЭС (ЭД/пакета ЭД), защищенного ЭЦП (КА), из элемента sen:Object;

e)  раскодирование ЭС (ЭД/пакета ЭД), выделенного на предыдущем этапе, по алгоритму [base64];

f)  дешифрование масива байтов, полученного на предыдущем этапе, если это предусмотрено Договором обмена;

g)  разжатие массива байтов, полученного на предыдущем этапе, если это предусмотрено Договором обмена;

h)  проверка ЭЦП (КА): вызов функции СКЗИ по проверке ЭЦП (КА) с передачей ей массивов байтов, полученных на этапах c), и e), с учетом возможного дешифрования на этапе f) и/или возможного расжатия на этапе g).

8.4  Шифрование

Шифрование и дешифрование сообщений выполняется средствами СКЗИ, имеющими сертификат или временное разрешение ФСБ, либо временное разрешение Банка России. Обмен и доступ к информации, необходимой для шифрования и дешифрования определяется Договором обмена.

8.5  Сжатие

Сжатие и разжатие данных осуществляется с использованием алгоритма [deflate]. Использование сжатия данных определяется Договором обмена.

Сторона, принимающая сжатое сообщение, должна обеспечивать полную поддержку форматов [deflate] и [zlib].

8.5.1  Структура формата сжатых данных в составе элемента sen:Object

Формат сжатых данных представляет собой последовательность двух блоков, первый из которых состоит из четырех байт и содержит длину данных до сжатия, а второй блок в формате [zlib] содержит данные, сжатые по алгоритму [deflate] (см. таблица 57).

Таблица 57 – Структура формата сжатых данных

Название блока	Описание блока	Длиннаблока (байт)
Размер данных до сжатия	Четырехбайтовое беззнаковое целое (32 бита) в формате little-endian (первым - младший байт).	4
Сжатый блок данных	Блок данных в формате [zlib], сжатых в соответствии с алгоритмом [deflate].	9-n

9  Правила оформления и обработки служебного конверта для унификации взаимодействия приложений с транспортным уровнем

9.1  Область применения

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

9.2  Архитектура взаимодействия приложений с транспортным уровнем

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

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

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

Служебный конверт не защищается ЭЦП (КА).

9.3  Структура и синтаксис служебного конверта и заголовков

9.3.1  Пространства имен

Для данной версии настоящего документа используются пространства имен:

"http://www. w3.org/2003/05/soap-envelope” (префикс env)

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

9.3.2  Служебный конверт

Служебный конверт создается в соответствии с рекомендацией [SOAP12].

Пространство имен
“http://www. w3.org/2003/05/soap-envelope” (префикс env)

Таблица 58 – Служебный конверт (env:Envelope)

Описание реквизита	Тип реквизита	Крат-ность
1 Заголовок конверта (env:Header)		[0..1]
1.1 Содержание заголовка (any)	Элементы заголовка	[0..n]
2 Тело конверта (env:Body)		[1]
2.1 Содержание тела конверта (any)	Элемент, содержащий ЭС (ЭД/пакет ЭД)	[0..n]

Служебный конверт может содержать в заголовке env:Header различные информационные блоки. На транспортном уровне могут быть добавлены дополнительные блоки заголовка.

Служебный конверт содержит в элементе env:Body ЭС (ЭД/пакет ЭД) (см. рисунок 20). В УФЭБС в теле служебного конверта передается не более одного ЭС (ЭД/пакета ЭД).

Примечание – Если ЭС (ЭД/пакет ЭД) оформлен в конверт ЭЦП (КА), элемент env:Body содержит конверт ЭЦП (КА).

Рисунок 20 – Структура служебного конверта в соответствии с рекомендацией [SOAP12]

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

Детальное описание правил оформления и использования служебного конверта, а также квитанций приведено в документе «Унифицированные форматы электронных банковских сообщений. Структура и правила заполнения заголовков служебного конверта».

10  Технические сведения об УФЭБС

УФЭБС разработаны в соответствии со следующими спецификациями:

–  "Extensible Markup Language (XML) 1.0" – «Расширяемый язык разметки XML 1.0» [XML];

–  "Namespaces in XML" – «Пространства имен в XML» [XML-ns];

–  "XML Schema Part 1: Structures" и "XML Schema Part 2: Datatypes" – «XML схема. Часть 1 – структуры» и «XML схема. Часть 2 – типы данных» [XML-schema].

10.1  Оформление XML-документа

Электронные сообщения оформляются согласно [XML]. XML-документы передаются в кодировке WINDOWS-1251 или UTF-8.

XML-документы должны начинаться с декларации XML, которая определяет версию XML и применяемую кодировку согласно [XML].

<?xml version="1.0" encoding="WINDOWS-1251"?>

<?xml version="1.0" encoding="UTF-8"?>

Примечание – Декларация XML с указанием версии XML в XML-документе обязательна. В случае, если не указана применяемая кодировка, считается, что XML-документ составлен в кодировке UTF-8.

Для XML-документов объявляются описанные пространства имен и их префиксы (возможно применение пространства имен по умолчанию). Для элементов, содержащих значение ЭЦП (КА) или ЗК, возможно определение необходимых пространств имен непосредственно в самом элементе.