ПРАВЛІННЯ НАЦІОНАЛЬНОГО БАНКУ УКРАЇНИ

Зареєстровано в Міністерстві юстиції України 17 вересня 2012 р. за № 1594/21906

Про затвердження Правил електронної взаємодії між респондентами та Національним банком України

Відповідно до статті 7 Закону України "Про Національний банк України"( 679-14 ), з метою підвищення рівня захисту інформації та встановлення єдиних правил обміну захищеними електронними документами між Національним банком України та його респондентами Правління Національного банку України ПОСТАНОВЛЯЄ:

1. Затвердити Правила електронної взаємодії між респондентами та Національним банком України, що додаються.

2. Контроль за виконанням цієї постанови покласти на заступника Голови Національного банку України Прохоренка В. П.

3. Ця постанова набирає чинності з дня її офіційного опублікування.

Голова

C.Г. Арбузов

ПОГОДЖЕНО: Державна служба спеціального зв’язку та захисту інформації України

ЗАТВЕРДЖЕНО Постанова Правління Національного банку України 11.07.2012  № 290

Зареєстровано в Міністерстві юстиції України 17 вересня 2012 р. за № 1594/21906

ПРАВИЛА електронної взаємодії між респондентами та Національним банком України

І. Загальні положення

1.1. Ці Правила регламентують обмін захищеними електронними документами між респондентами та Національним банком України (далі — Національний банк) через мережу Інтернет та розроблені згідно із Законами України "Про Національний банк України"( 679-14 ), "Про банки і банківську діяльність"( 2121-14 ), "Про електронний цифровий підпис"( 852-15 ) та "Про електронні документи та електронний документообіг"( 851-15 ).

1.2. У цих Правилах терміни вживаються в такому значенні:

електронна печатка — електронний цифровий підпис (далі — ЕЦП), який за правовим статусом прирівнюється до печатки з урахуванням вимог статті 3 Закону України "Про електронний цифровий підпис"( 852-15 );

захищений електронний документ — електронний документ, зашифрований за допомогою засобу криптографічного захисту інформації (далі — КЗІ), що має сертифікат відповідності або позитивний експертний висновок за результатами державної експертизи у сфері криптографічного захисту інформації;

портал електронної взаємодії Національного банку (далі — портал Національного банку) — програмно-технічний засіб, розроблений з урахуванням цих Правил для обміну захищеними електронними документами між респондентами та Національним банком за допомогою електронної пошти (e-mail);

респондент Національного банку (далі — респондент) — особа — відправник захищеного електронного документа до Національного банку;

статус сертифіката — cтан посиленого сертифіката ключа (чинний, блокований, скасований) на конкретний момент.

У цих Правилах інші терміни вживаються в значеннях, визначених у Законах України "Про електронний цифровий підпис" ( 852-15 ), "Про електронні документи та електронний документообіг"( 851-15 ), Порядку засвідчення наявності електронного документа (електронних даних) на певний момент часу( 680-2004-п ), затвердженому постановою Кабінету Міністрів України від 26.05.2004 № 680, Порядку акредитації центру сертифікації ключів( 903-2004-п ), затвердженому постановою Кабінету Міністрів України від 13.07.2004 № 903.

ІІ. Загальні вимоги до обміну даними

2.1. Національний банк визначає адресу електронної скриньки (e-mail) порталу Національного банку, телефони технічної підтримки та поширює цю інформацію через сторінки Офіційного інтернет-представництва Національного банку України (www.bank.gov.ua) у розділі "Портал електронної взаємодії".

2.2. Цикл обміну захищеними електронними документами (далі — файл обміну) складається з файла, який відправляється ініціатором обміну адресату (далі — файл повідомлення), повідомлення про доставку та двох квитанцій, які свідчать про результат отримання файла повідомлення.

Повідомлення про доставку свідчить про дату та час отримання файла повідомлення адресатом.

Перша квитанція (далі — квитанція № 1) свідчить про результат перевірки проходження автоматичного вхідного контролю файла повідомлення.

Друга квитанція (далі — квитанція № 2) свідчить про результат оброблення інформації з файла повідомлення.

2.3. Респонденту для обміну даними з Національним банком необхідно мати:

доступ до мережі Інтернет та можливість відправлення та приймання файлів обміну у форматі транспортного повідомлення (далі — ТП) згідно з розділом V цих Правил;

програмне забезпечення, призначене для створення і оброблення файлів обміну респондентом згідно з розділом ІІІ цих Правил;

засіб КЗІ, що має сертифікат відповідності або позитивний експертний висновок за результатами державної експертизи у сфері криптографічного захисту інформації.

ІІІ. Формат файла обміну

3.1. Усі файли обміну мають формуватися як XML-документи відповідно до відкритого стандарту W3C (http://www.w3.org/TR/REC-xml) та кодуються у форматі "Windows 1251".

3.2. Для контролю за цілісністю структури та правильністю заповнення XML-документа використовується файл (далі — XML-схема), що відповідає стандарту W3C "XML Schema" (http://www.w3.org/2001/XMLSchema-instance) та має розширення XSD (XML Schema definition).

Кодування реквізитів у XML-схемі визначається шаблоном відображення кожного типу файла повідомлення. Усі шаблони надаються Національним банком у форматі Adobe Portable Document Format (PDF) і мають аналогічне до XML-схеми ім’я файла з розширенням PDF.

Порядок елементів у XML-документі повинен точно відповідати порядку, описаному XML-схемою.

3.3. Опис форматів файлів обміну наведено в додатку 1 до цих Правил.

Детальний опис та зміст файлів обміну, XML-схеми та шаблони відображення встановлюються Національним банком та поширюються через сторінки Офіційного інтернет-представництва Національного банку України в розділі "Портал електронної взаємодії".

IV. Вимоги до криптографічного захисту інформації

4.1. Створення файла обміну завершується накладанням електронного цифрового підпису з використанням надійного засобу електронного цифрового підпису (далі — ЕЦП).

4.2. Для перевірки ЕЦП використовується посилений сертифікат відкритого ключа (далі — сертифікат ключа), сформований акредитованим центром сертифікації ключів.

Статус сертифіката ключа перевіряється на момент, визначений позначкою часу, яка накладається на електронний документ, а у разі відсутності позначки часу — на момент отримання електронного документа.

4.3. Усі криптографічні перетворення виконуються засобами криптографічного захисту інформації, які повинні відповідати таким вимогам:

реалізовувати процедури формування й перевірки ЕЦП відповідно до національного стандарту України ДСТУ 4145-2002 "Інформаційні технології. Криптографічний захист інформації. Цифровий підпис, що ґрунтується на еліптичних кривих. Формування та перевірка", затвердженого наказом Державного комітету України з питань технічного регулювання та споживчої політики від 28.12.2002 № 31;

реалізовувати процедури відкритого розподілу ключів відповідно до національного стандарту України ДСТУ ISO IEC 15946-3:2006 "Інформаційні технології. Методи захисту. Криптографічні методи, що ґрунтуються на еліптичних кривих", затвердженого наказом Державного комітету України з питань технічного регулювання та споживчої політики від 03.10.2006 № 294 ( v0294609-06 );

реалізовувати процедури симетричного шифрування відповідно до міждержавного стандарту ДСТУ ГОСТ 28147:2009 "Системы обработки информации. Защита криптографическая. Алгоритмы криптографического преобразования", затвердженого наказом Державного комітету України з питань технічного регулювання та споживчої політики від 22.12.2008 № 495 ( v0495609-08 );

реалізовувати процедуру накладання позначки часу згідно з національним стандартом України ДСТУ ISO/IEC 18014-1:2006 "Інформаційні технології. Методи захисту. Послуги штемпелювання часу. Частина 1. Основні положення" (ISO/IEC 18014-1:2002, IDT), затвердженим наказом Державного комітету України з питань технічного регулювання та споживчої політики від 27.12.2006 № 375( v0375609-06 );

мати сертифікат відповідності або позитивний експертний висновок за результатами державної експертизи у сфері криптографічного захисту інформації.

Функції бібліотек криптографічних перетворень для сумісності з порталом Національного банку повинні відповідати специфікаціям криптографічних функцій, зазначеним у додатку 2 до цих Правил.

V. Формат ТП

5.1. ТП відповідає формату електронної пошти (МІМЕ) згідно з міжнародним стандартом RFC-1521. Заголовки ТП кодуються у форматі "Windows 1251".

ТП складається з реквізитів ТП та транспортного контейнера (далі — ТК).

ТК входить у ТП як файл укладення.

ТК складається із заголовка та блока зашифрованих даних (реквізитів шифрування даних та зашифрованих даних).

Зашифровані дані містять зашифрований XML-файл з накладеними ЕЦП, а також набір додаткових даних, необхідних для перевірки ЕЦП та визнання його дійсності.

Перед зашифровуванням дані упаковуються архіватором ZIP, який у кореневому каталозі містить один підписаний XML-файл. Ім’я файла архіву збігається з ім’ям XML-файла.

Ім’я файла ТК збігається з ім’ям XML-файла та зазначається в полі "FILENAME" заголовка.

5.2. ТП може мати тільки одного одержувача.

Одне ТП повинно містити тільки один укладений у нього ТК. У разі прийняття ТП до оброблення ТК з тим самим ім’ям не може бути переданий вдруге.

Опис ТП наведено в додатку 3 до цих Правил.

VI. Найменування файлів обміну

6.1. Найменування файла обміну складається з назви файла та його розширення. Загальна довжина імені файла не може перевищувати 128 символів.

6.2. Назва файла обміну має таку структуру:

<код задачі (3 символи)><код підзадачі (5 символів)><унікальний ідентифікатор респондента><ggmmddNNN>, де:

ggmmdd — дата формування файла повідомлень (gg — дві останні цифри року та mmdd — місяць, день у 10-знаковій системі числення);

NNN — порядковий номер файла повідомлення протягом дня (3 символи).

Коди задачі і підзадачі доповнюються до потрібної довжини символом "0".

Назва файла повідомлення про доставку та назва файлів квитанції збігаються з назвою файла повідомлення, що квитується.

6.3. Розширення для відповідного файла обміну має значення:

XML — для файла повідомлення;

RPL — для повідомлення про доставку;

RP1 — для квитанції № 1;

RP2 — для квитанції № 2.

VII. Порядок подання файла повідомлення засобами телекомунікаційного зв’язку

7.1. Файл обміну на початку приймання перевіряється на допустиму назву і

розширення (XML, RPL, RP1, RP2) файла та на коректність заповнення заголовка ТК. Якщо файл обміну не проходить перевірку, то він відхиляється, а на файл повідомлення адресат жодної відповіді не відсилає.

7.2. Файл обміну розшифровується, розпаковується з архіву, на нього накладається позначка часу адресатом, статус сертифіката ключа якого на момент накладання позначки часу має бути чинним, після чого він подається на зберігання до архіву. Структуру файла, який зберігається в архіві, зазначено в пункті 2.2 глави 2 додатка 3 до цих Правил. На файл повідомлення у відповідь адресат відсилає повідомлення про доставку.

7.3. Служба автоматичного вхідного контролю перевіряє ЕЦП електронного документа, у тому числі шляхом перевірки чинності відповідних посилених сертифікатів відкритих ключів, та відповідність електронного документа XML-схемі. На файл повідомлення адресат відсилає відправнику файла повідомлення квитанцію № 1.

7.4. Функціональна підсистема Національного банку відповідної задачі перевіряє зміст електронного документа. За результатами перевірки відправнику файла повідомлення формується квитанція № 2.

7.5. На файл повідомлення респондента до Національного банку накладається ЕЦП двох відповідальних осіб та електронна печатка респондента. Файл шифрується з використанням відкритого ключа порталу Національного банку.

На повідомлення про доставку та квитанції від Національного банку накладається ЕЦП порталу Національного банку. Файл шифрується з використанням відкритого ключа електронної печатки респондента.

Відкритий ключ електронної печатки респондента надається у сертифікаті ключа відповідного файла повідомлень, надісланого до Національного банку.

7.6. На файл повідомлення від Національного банку накладається ЕЦП відповідальної особи та порталу Національного банку. Файл шифрується з використанням відкритого ключа електронної печатки респондента.

На повідомлення про доставку та квитанції від респондента накладається електронна печатка респондента. Файл шифрується з використанням відкритого ключа порталу Національного банку.

Сертифікат ключа порталу Національного банку поширюється Національним банком через сторінки Офіційного інтернет-представництва Національного банку в розділі "Портал електронної взаємодії".

7.7. Національний банк надає повідомлення про доставку та квитанції респонденту на електронну поштову адресу, з якої надійшов файл повідомлення.

7.8. Дані приймаються до оброблення, якщо квитанції не містять кодів помилок. Дату та час надання файла повідомлення засвідчує отримане респондентом повідомлення про доставку, якщо всі квитанції на відповідний файл повідомлення не містять помилок.

7.9. Файли обміну зберігаються Національним банком та респондентом у розшифрованому вигляді з накладеними на них ЕЦП протягом п’яти років.

Заступник начальника Управління захисту інформації

С. П. Гавриш

Додаток 1 до Правил електронної взаємодії між респондентами та Національним банком України

1. Загальний опис формата файлів обміну

Структура файлів є уніфікованою та складається із елементів "DECLARHEAD" та "DECLARBODY".

Кореневим елементом є елемент з іменем "DECLAR", у якому зазначається посилання на схему контролю даних (XML-схему). У елементі "DECLARHEAD" розміщується інформація, що ідентифікує респондента, який надає звіт Національному банку. Зміст елемента "DECLARBODY" визначається окремими вимогами щодо надання інформації респондентами Національному банку.

Загальний вигляд схеми XML-файла:

<xs:element name="DECLAR" type="DeclarContent"/> <xs:complexType name="DeclarContent"> <xs:sequence> <xs:element name="DECLARHEAD" type="DHead"/> <xs:element name="DECLARBODY" type="DBody"/> </xs:sequence> </xs:complexType>

2. Загальний опис файла повідомлення

2.1. Елемент "DECLARHEAD" містить ідентичний для всіх файлів повідомлень набір елементів. Опис елемента "DECLARHEAD" надано в таблиці 1:

Таблиця 1

Назва елемента

Зміст

1

2

FNAME

ім’я файла повідомлення

EDRPOU

код за ЄДРПОУ [реєстраційний номер облікової картки платника податків або серія та номер паспорта (для фізичних осіб, які через свої релігійні переконання відмовляються від прийняття реєстраційного номера облікової картки платника податків та повідомили про це відповідний орган державної податкової служби і мають відмітку у паспорті)];

IDBANK

ідентифікатор банку або фінансової установи

MFO

CDTASK

CDSUB

CDFORM

FILL_DATE

дата формування файла у форматі "ДД. ММ. РРРР", де ДД — день, ММ — місяць, РРРР — рік надання файла повідомлення

FILL_TIME

2.2. XML-cхема файла повідомлення, яка повинна включатися до всіх схем опису:

<?xml version = "1.0" ?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="DECLAR" type="DeclarContent"/> <xs:simpleType name="DGDate"> <xs:restriction base="xs:string"> <xs:length value="10" /> <xs:pattern value="( ( ( ( 0[1-9] | [1-2][0-9]).( 0(1 | [3-9]) | 1[0-2])) | (30.(0(1 | [3-9]) | 1 [0-2] ) ) | ( 31.( 01 | 03 | 05 | 07 | 08 | 10 | 12) ) ).(19 | 20)d{2}) | ( (0 [1-9] | [1-2][0-9]).02.(19|20)( ([0 | 2 | 4 | 6 | 8][0 | 4 | 8]) | ([1 | 3 | 5 | 7 | 9][2 | 6]) ) | (0[1-9] | [1-2][0-8] | 19).02.(19 | 20) (([0|2|4|6|8][1-3|5-7|9]) | ([1|3|5|7|9][0-1 | 3-5 | 7-9])))"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="DGTime"> <xs:restriction base="xs:string"> <xs:length value="4"/> <xs:pattern value="((([0-1][0-9])|(2[0-3]))[0-5][0-9])"/> </xs:restriction> </xs:simpleType> <!--Загальний тип "код за ЄДРПОУ [реєстраційний номер облікової картки платника податків або серія та номер паспорта (для фізичних осіб, які через свої релігійні переконання відмовляються від прийняття реєстраційного номера облікової картки платника податків та повідомили про це відповідний орган державної податкової служби і мають відмітку у паспорті)]"--> <xs:simpleType name="DGLong"> <xs:restriction base="xs:string"> <xs:maxLength value="10"/> <xs:pattern value="([0-9] {5,10} | [АБВГДЕЄЖЗИ_КЛМНОПРСТУФХЦЧШЩЮЯ] {2} [0-9] {6})"/> </xs:restriction> </xs:simpleType> <xs:complexType name="DeclarContent"> <xs:sequence> <xs:element name="HEAD" type="DHEAD" minOccurs="1" maxOccurs="1"/> </xs:sequence> </xs:complexType> <xs:complexType name="DHEAD"> <xs:sequence> <xs:element name="FNAME" minOccurs="1" maxOccurs="1"/> <xs:simpleType> <xs:restriction base="xs:string"> <xs:length value="23"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="EDRPOU" type="DGLong" minOccurs="1" maxOccurs="1"/> <xs:element name="IDBANK" minOccurs="1" maxOccurs="1" nillable="true"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:length value="3"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="MFO" type="xs:integer" minOccurs="1" maxOccurs="1" nillable="true"/> <!-- Код задачі --> <xs:element name="CDTASK" minOccurs="1" maxOccurs="1"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:length value="3"/> </xs:restriction> </xs:simpleType> </xs:element> <!-- Код під задачі --> <xs:element name="CDSUB" minOccurs="1" maxOccurs="1" nillable="true"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="5"/> </xs:restriction> </xs:simpleType> </xs:element> <!-- Код шаблону документа --> <xs:element name="CDFORM" minOccurs="1" maxOccurs="1"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:length value="8"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="FILL_DATE" type="DGDate" minOccurs="1" maxOccurs="1"/> <xs:element name="FILL_TIME" type="DGTime" minOccurs="1" maxOccurs="1"/> <xs:element name="EI" nillable="true"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="2"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> </xs:schema>

3. Загальний опис повідомлення про доставку квитанцій № 1 та № 2:

3.1. XML структура повідомлення про доставку квитанцій № 1 та № 2:

<?xml version="1.0" encoding="windows-1251"?> <DECLAR xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DECLARHEAD> <FNAME>

Ім’я файла квитанції

</FNAME> <DOCFNAME> Ім’я файла повідомлення, на який створено квитанцію </DOCFNAME> <RESULT> Результат приймання файла повідомлення: 1 — успішно; 2 — виявлено помилки (документ не прийнятий); 3 — документ прийнятий із зауваженнями. </RESULT> <KVTDATE> Дата створення квитанції у форматі "DD.MM.YYYY" </KVTDATE> <KVTTIME> Час створення квитанції у форматі "HHMM" </KVTTIME> <KVTNUM> Номер квитанції: 1 — повідомлення про доставку файла повідомлення; 2 — квитанція № 1; 3 — квитанція № 2. </KVTNUM> <DOCHEAD> Дублюється зміст елемента "DECLARHEAD" прийнятого файла повідомлення </DOCHEAD> <TEXT> Містить текст квитанції </TEXT> </DECLARHEAD> <DECLARBODY> Зміст елемента визначається розробником функціональної підсистеми відповідної задачі </DECLARBODY> </DECLAR>

3.2. XML cхема повідомлення про доставку квитанцій № 1 та № 2, яка повинна включатись до всіх схем опису:

<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="DECLAR"> <xs:complexType> <xs:sequence> <xs:element name="DECLARHEAD"> <xs:complexType> <xs:sequence> <xs:element name="FNAME" minOccurs="1" maxOccurs="1"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:length value="23"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="DOCFNAME" type="xs:string"/> <xs:element name="RESULT" type="xs:integer"/> <xs:element name="KVTDATE" type="xs:string"/> <xs:element name="KVTTIME" type="xs:string"/> <xs:element name="KVTNUM" type="xs:integer"/> <xs:element name="DOCHEAD" type="xs:string"/> <xs:element name="TEXT" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="DECLARBODY" type="xs:string" nillable="true"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

Додаток 2 до Правил електронної взаємодії між респондентами та Національним банком України

СПЕЦИФІКАЦІЯ криптографічних функцій

1. Загальні вимоги

Загальні вимоги до бібліотеки криптографічних функцій:

передача параметрів за угодою "__stdcall" згідно з описом функцій бібліотеки (пункт 3 додатка 3);

пам’ять під блоки з результатом роботи функцій надається прикладною програмою, яка використовує бібліотеку.

2. Вимоги до використання бібліотеки

Бібліотека надається у вигляді "dll" для "Windows"-середовищ та "so" для "Linux"-середовищ. Ім’я "dll" та "so": Crypt_XXX.dll та Crypt_XXX.so, де XXX — ім’я постачальника бібліотеки.

Доступ до функцій "dll" та "so" виконується функцією "GetProcAddress".

Бібліотека постачається разом із заголовними файлами з розширенням (*.h), що містять вичерпний опис функцій бібліотеки.

3. Функції бібліотеки

3.1. Функція накладання підпису:

а) без передачі сертифіката ключа:

int __stdcall MakeSign (const void* pkbuf, int pklen, const char* pwd, const void* docbuf, int doclen, void* outbuf, int* outlen), де:

Параметр

Опис

1

2

const void* pkbuf

int pklen

const char* pwd

const void* docbuf

int doclen

Void* outbuf

int* outlen

Функція зберігає в "outbuf" блок документа з підписом.

Функція повертає символ "", коли успішно виконано, або код помилки;

б) з передачею сертифіката ключа:

int __stdcall MakeSignC (const void* certbuf, int certlen, const void* pkbuf, int pklen, const char* pwd, const void* docbuf, int doclen, void* outbuf, int* outlen), де:

Параметр

Опис

const void* certbuf

int certlen

const void* pkbuf

int pklen

const char* pwd

const void* docbuf

int doclen

Void* outbuf

int* outlen

Функція зберігає в "outbuf" блок документа з підписом.

Функція повертає символ "", коли успішно виконано, або код помилки.

3.2. Функція перевірки підпису:

int __stdcall VerifySign (const void* docbuf, int doclen, void* outbuf, int* outlen, void* certuf, int* certlen), де:

Параметр

Опис

const void* docbuf

int doclen

Void* outbuf

int* outlen

Void* certbuf

буфер з сертифікатом ключа, якщо "NULL" — в "certlen" повертається розмір буфера з сертифікатом ключа

int* certlen

Функція зберігає в "outbuf" блок документа без підпису.

Функція зберігає в "certbuf" блок сертифіката ключа підписувача.

Функція повертає символ "", якщо підпис вірний, або код помилки.

3.3. Функція перевірки сертифіката ключа:

int __stdcall VerifyCert (const void* certbuf, int certlen, const void* rootcbuf, int rootclen), де:

Параметр

Опис

const void* certbuf

int certlen

const void* rootcbuf

буфер з сертифікатом ключа Акредитованого центра сертифікації ключів (далі — АЦСК) для перевірки сертифіката ключа, яким підписано електронний документ

int rootclen

Функція повертає символ "", якщо перевірка успішна, або код помилки.

3.4. Функція шифрування блоку даних:

int __stdcall Encrypt (const void* certbuf, int certlen, const void* pkbuf, int pklen, const char* pwd, const void* docbuf, int doclen, void* outbuf, int* outlen), де:

Параметр

Опис

const void* certbuf

int certlen

const void* pkbuf

int pklen

const char* pwd

const void* docbuf

int doclen

void* outbuf

int* outlen

Функція зберігає в "outbuf" зашифрований блок документа.

Функція повертає символ "", коли успішно зашифровано, або код помилки.

3.5. Функція розшифрування блоку даних:

int __stdcall Decrypt (const void* pkbuf, int pklen, const char* pwd, const void* certbuf, int certlen, const void* docbuf, int doclen, void* outbuf, int* outlen), де:

Параметр

Опис

1

2

const void* pkbuf

int pklen

const char* pwd

const void* certbuf

int certlen

const void* docbuf

int doclen

void* outbuf

Int* outlen

Функція зберігає в "outbuf " розшифрований блок документа.

Функція повертає символ "", коли успішно виконано, або код помилки.

3.6. Функція звірки сертифіката ключа із секретним ключем:

int __stdcall VerifyCertPKMatch (const void* certbuf, int certlen, const void* pkbuf, int pklen, const char* pwd), де:

Параметр

Опис

const void* certbuf

int certlen

const void* pkbuf

int pklen

const char* pwd

Функція повертає символ "", коли сертифікат та секретний ключ є відповідними, або код помилки.

3.7. Функція отримання інформації із сертифіката ключа:

int __stdcall GetCertInfo (const void* certbuf, int certlen, UACertInfo* info), де:

Параметр

Опис

const void* certbuf

int certlen

UACertInfo* info

Функція повертає символ "", коли успішно виконано, або код помилки.

Структура "UACertInfo":

Поле

Опис

1

2

char Serial[64]

char EDRPOU[11]

char DRFO[11]

реєстраційний номер облікової картки платника податків або серія та номер паспорта (для фізичних осіб, які через свої релігійні переконання відмовляються від прийняття реєстраційного номера облікової картки платника податків та повідомили про це відповідний орган державної податкової служби і мають відмітку у паспорті)

char Name[64]

char Email[64]

char Title[64]

char PostalCode[7]

char Obl[64]

char Rayon[64]

char Adres[64]

char Tel[64]

time_t DtBeg

time_t DtEnd

char Issuer[64]

Вирівнювання членів структури — 1 байт.

Розмір кожного строкового поля містить заключний символ "".

4. Коди помилок

Додаток 3 до Правил електронної взаємодії між респондентами та Національним банком України

ОПИС транспортного повідомлення

Схему уніфікованого транспортного повідомлення (далі — ТП) представлено на рисунку 1:

Рисунок 1. Схема уніфікованого ТП.

1. Опис ТК

1.1. Заголовок ТК.

Заголовок ТК містить інформацію про відправника та використовувану ним бібліотеку криптозахисту:

Елемент

Значення

Сигнатура

"TRANSPORTABLE"

CR/LF

Рядки <CR/LF>

Кожне значення тега заголовка ТК надається в кодуванні "Windows1251" та закінчується символом CHR(13) та CHR(10).

Перелік тегів заголовка ТК:

Найменування

Значення

Обов’язковість заповнення

FILENAME

ім’я файла контейнера у верхньому регістрі

EDRPOU

PRG_TYPE

назва програмного забезпечення для накладання та перевірки ЕЦП відправника довжиною не більше десяти символів

PRG_VER

версія програмного забезпечення для накладання та перевірки ЕЦП відправника довжиною не більше десяти символів

SUBJECT

RESULT

KVTNUM

FINKVT

Теги заголовка ТК "PRG_VER", "SUBJECT", "RESULT", "KVTNUM", "FINKVT" надані для сумісності заголовка ТК портала Національного банку з порталами надання звітності інших державних установ.

1.2. Блок зашифрованих даних.

Формат блока зашифрованих даних:

Елемент

Значення

Сигнатура

"XXX_ CRYPT", де XXX — код Центру сертифікації ключів *

Зашифровані дані

__________ * Код Центру сертифікації ключів — послідовність із трьох прописних літер латинського алфавіту, яка однозначно ідентифікує Центр сертифікації ключів.

1.2.1. ЕЦП.

Формат підпису:

Елемент

Значення

Сигнатура

"XXX_SIGN", де XXX — код Центру сертифікації ключів

Службовий символ

Буфер підпису та підписаних даних

ЕЦП формуються послідовно, накладаючись один на одний.

Послідовність накладення ЕЦП секції "XXX_SIGN" для респондента:

а) накладання ЕЦП першої відповідальної особи;

б) накладання ЕЦП другої відповідальної особи;

в) накладання електронної печатки респондента.

Послідовність накладення ЕЦП для Національного банку:

а) накладання ЕЦП відповідальної особи;

б) накладання ЕЦП порталу Національного банку.

Розташування сертифікатів у блоці ЕЦП визначається постачальником криптографічної бібліотеки.

1.2.2. Позначка часу.

Позначка часу отримується з Акредитованого центру сертифікації ключів за протоколом TSP (Timestamp Protocol RFC 3161).

Формат позначки часу:

Елемент

Значення

Сигнатура

"XXX_STAMP", е XXX — код Центру сертифікації ключів

Буфер позначки часу

Блок даних, на які накладено позначку часу

2. Формати повідомлень, які надсилаються в ТК

2.1. Формат повідомлення "Документ".

Повідомлення передається від респондента до порталу Національного банку.

Структура повідомлення:

2.2. Структура повідомлення "Документ з позначкою часу":

2.3. Формат повідомлення "Документ від Національного банку".

Повідомлення передається від порталу Національного банку до респондента.

Структура повідомлення: