Жилищный адвокат

Про затвердження Правил електронної взаємодії між респондентами та Національним банком України, Національний банк УкраїниПРАВЛІННЯ НАЦІОНАЛЬНОГО БАНКУ УКРАЇНИ

ПОСТАНОВА

  1. 11.07.2012  № 290
  2. Зареєстровано в Міністерстві юстиції України 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>, де:

  3. код задачі, код підзадачі, унікальний ідентифікатор респондента визначає Національний банк;
  4. 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

  5. код банку
  6. CDTASK

  7. код задачі
  8. CDSUB

  9. код підзадачі
  10. CDFORM

  11. код шаблону документа
  12. FILL_DATE

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

    FILL_TIME

  13. час формування файла у форматі "ЧЧХХ", де ЧЧ-час та ХХ- хвилини формування файла
  14. 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. Загальні вимоги

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

  15. робота в середовищі Microsoft Windows 98/2000/XP/Vista/7, Linux (RadHat, Suse);
  16. багатопоточність;
  17. бібліотека повинна поставлятися для апаратних платформ х86 та х64;
  18. передача параметрів за угодою "__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

  19. буфер із секретним ключем
  20. int pklen

  21. розмір буфера із секретним ключем
  22. const char* pwd

  23. пароль секретного ключа, повинен закінчуватися символом ""
  24. const void* docbuf

  25. буфер із документом
  26. int doclen

  27. розмір буфера з документом
  28. Void* outbuf

  29. вихідний буфер, якщо "NULL" — в "outlen" повертається розмір вихідного буфера
  30. int* outlen

  31. розмір вихідного буфера
  32. Функція зберігає в "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

  33. буфер із сертифікатом ключа
  34. int certlen

  35. розмір буфера із сертифікатом ключа
  36. const void* pkbuf

  37. буфер із секретним ключем
  38. int pklen

  39. розмір буфера із секретним ключем
  40. const char* pwd

  41. пароль секретного ключа, повинен закінчуватися символом ""
  42. const void* docbuf

  43. буфер із документом
  44. int doclen

  45. розмір буфера з документом
  46. Void* outbuf

  47. вихідний буфер, якщо "NULL" — в "outlen" повертається розмір вихідного буфера
  48. int* outlen

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

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

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

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

    Параметр

    Опис

    const void* docbuf

  51. буфер з документом
  52. int doclen

  53. розмір буфера з документом
  54. Void* outbuf

  55. вихідний буфер, якщо "NULL" — в "outlen" повертається розмір вихідного буфера
  56. int* outlen

  57. розмір вихідного буфера
  58. Void* certbuf

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

    int* certlen

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

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

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

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

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

    Параметр

    Опис

    const void* certbuf

  61. буфер із сертифікатом ключа
  62. int certlen

  63. розмір буфера із сертифікатом ключа
  64. const void* rootcbuf

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

    int rootclen

  65. розмір буфера сертифіката ключа АЦСК
  66. Функція повертає символ "", якщо перевірка успішна, або код помилки.

    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

  67. буфер із сертифікатом ключа
  68. int certlen

  69. розмір буфера із сертифікатом ключа
  70. const void* pkbuf

  71. буфер із секретним ключем
  72. int pklen

  73. довжина буфера із секретним ключем
  74. const char* pwd

  75. пароль секретного ключа повинен закінчуватися символом ""
  76. const void* docbuf

  77. буфер із документом
  78. int doclen

  79. розмір буфера з документом
  80. void* outbuf

  81. вихідний буфер, якщо "NULL" — в "outlen" повертається розмір вихідного буфера
  82. int* outlen

  83. розмір вихідного буфера
  84. Функція зберігає в "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

  85. буфер із секретним ключем
  86. int pklen

  87. довжина буфера із секретним ключем
  88. const char* pwd

  89. пароль секретного ключа повинен закінчуватись символом ""
  90. const void* certbuf

  91. буфер із сертифікатом ключа
  92. int certlen

  93. розмір буфера із сертифікатом ключа
  94. const void* docbuf

  95. буфер із документом
  96. int doclen

  97. розмір буфера з документом
  98. void* outbuf

  99. вихідний буфер, якщо "NULL" — в "outlen" повертається розмір вихідного буфера
  100. Int* outlen

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

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

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

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

    Параметр

    Опис

    const void* certbuf

  103. буфер із сертифікатом ключа
  104. int certlen

  105. розмір буфера із сертифікатом ключа
  106. const void* pkbuf

  107. буфер із секретним ключем
  108. int pklen

  109. розмір буфера із секретним ключем
  110. const char* pwd

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

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

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

    Параметр

    Опис

    const void* certbuf

  113. буфер із сертифікатом ключа
  114. int certlen

  115. довжина буфера із сертифікатом ключа
  116. UACertInfo* info

  117. структура з інформацією із сертифіката ключа (приведена нижче)
  118. Функція повертає символ "", коли успішно виконано, або код помилки.

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

    Поле

    Опис

    1

    2

    char Serial[64]

  119. серійний номер сертифіката ключа
  120. char EDRPOU[11]

  121. код за ЄДРПОУ установи
  122. char DRFO[11]

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

    char Name[64]

  123. прізвище, ім’я, по батькові особи або найменування установи
  124. char Email[64]

  125. електронна адреса
  126. char Title[64]

  127. посада
  128. char PostalCode[7]

  129. поштовий індекс
  130. char Obl[64]

  131. область
  132. char Rayon[64]

  133. район
  134. char Adres[64]

  135. адреса
  136. char Tel[64]

  137. телефон
  138. time_t DtBeg

  139. дата початку дії сертифіката ключа (4 байта)
  140. time_t DtEnd

  141. дата закінчення дії сертифіката ключа (4 байта)
  142. char Issuer[64]

  143. видавець (найменування)
  144. Вирівнювання членів структури — 1 байт.

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

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

  145. 0 — успішно;
  146. 1 — буфер порожній;
  147. 2 — DLL не ініціалізовано;
  148. 3 — помилка отримання інформації з сертифіката ключа;
  149. 4 — даний сертифікат ключа не може використовуватися для виконання операції;
  150. 5 — не збігається пара "сертифікат ключа — секретний ключ";
  151. 7 — некоректний формат секретного ключа;
  152. 8 — помилка підпису/шифрування, можливо вказано невірний пароль;
  153. 11- невірний підпис;
  154. 12 — внутрішня помилка перевірки підпису;
  155. 13 — помилка перевірки цілісності (пошкоджений буфер);
  156. 14 — функція не підтримується.
  157. Додаток 3 до Правил електронної взаємодії між респондентами та Національним банком України

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

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

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

    1. Опис ТК

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

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

    Елемент

    Значення

    Сигнатура

    "TRANSPORTABLE"

  158. 0-символ
  159. службовий символ
  160. 4-байтовий розмір заголовка контейнера
  161. без урахування довжини сигнатури і ""символа
  162. CR/LF

  163. символи повернення каретки (0D) і переводу рядка (0A)
  164. Рядки <CR/LF>

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

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

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

    Значення

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

    FILENAME

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

  167. так
  168. EDRPOU

  169. код респондента
  170. так
  171. PRG_TYPE

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

  172. так
  173. PRG_VER

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

  174. ні
  175. SUBJECT

  176. найменування документа звітності
  177. ні
  178. RESULT

  179. результат приймання повідомлення (0 успішно, 1 — помилка, 2 — попередження)
  180. ні
  181. KVTNUM

  182. номер квитанції (1, 2, 3…)
  183. ні
  184. FINKVT

  185. ознака фінальної квитанції (0/1)
  186. ні
  187. Теги заголовка ТК "PRG_VER", "SUBJECT", "RESULT", "KVTNUM", "FINKVT" надані для сумісності заголовка ТК портала Національного банку з порталами надання звітності інших державних установ.

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

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

    Елемент

    Значення

    Сигнатура

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

  188. 0-символ
  189. службовий символ
  190. 4 байти
  191. розмір зашифрованих даних
  192. Зашифровані дані

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

    1.2.1. ЕЦП.

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

    Елемент

    Значення

    Сигнатура

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

  193. 0-символ
  194. Службовий символ

  195. 4 байти
  196. розмір буфера підпису та підписаних даних
  197. Буфер підпису та підписаних даних

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

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

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

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

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

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

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

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

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

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

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

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

    Елемент

    Значення

    Сигнатура

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

  198. 0-символ
  199. службовий символ
  200. 4 байти
  201. розмір хешу оригінального документа
  202. хеш оригінального документа
  203. 4 байти
  204. розмір буфера позначки часу
  205. Буфер позначки часу

  206. 4 байти
  207. розмір даних, на які накладено позначку часу
  208. Блок даних, на які накладено позначку часу

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

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

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

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

  209. заголовок ТК документа;
  210. блок даних, зашифрований на одержувача, містить підписи респондента і документ у форматі XML.
  211. 2.2. Структура повідомлення "Документ з позначкою часу":

  212. позначка часу на момент отримання документа від респондента;
  213. підписи респондента;
  214. документ у форматі XML.
  215. 2.3. Формат повідомлення "Документ від Національного банку".

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

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

  216. транспортний заголовок документа;
  217. позначка часу;
  218. підпис порталу Національного банку;
  219. блок даних, зашифрований на респондента, який містить підписаний XML-файл Національного банку.
  220. Юридичний портал Справедливість

    Рейтинг: 4.5/5, основан на 25 голосах.


    Вам это будет интересно:

    Про офіційні курси гривні до іноземної валюти, Національний банк України

    Національний банк України 21.09.2012 встановлює такі офіційні курси гривні до іноземної валюти* Код цифровий Код літерний Кількість одиниць Назва валюти Офіційний курс

    Українського боксера Олександра Усика визнали найкращим боксером світу 2012 року

    Визначилися переможці найпрестижнішої церемонії нагородження найкращих боксерів року, яку щорічно проводить Міжнародна асоціація аматорського боксу (AIBA).

    Про стан проведення нормативної грошової оцінки земель населених пунктів, Державне агентство земельних ресурсів України

    Про стан проведення нормативної грошової оцінки земель населених пунктів {Рішення введено в дію Наказом Державного агентства земельних ресурсів № 297 від 18.07.2013 ( v0297821-13 )}

    Тринадцята зарплата і повний соцпакет

    За цей інвестпроект змагалися кілька обласних центрів Західного регіону, запрошуючи до себе транснаціональну компанію Sumitomo Electric Bordnetze Gmbh. Вона ж обрала Чернівці.

    Консультации по недвижимости
    Адвокат по ЖКХ
    Рекомендовано !
    Киевские судебные решения

    №910/22831/14

    Судья: Васильченко Т.В.
    07.01.2015

    №757/24024/14-ц

    Судья: Цокол Л. І.
    07.01.2015
    Новости жилищных адвокатов
    Упрощено таможенное оформление для товаров, которые ...

    Упрощено таможенное оформление для товаров, которые не содержат озоноразрушающих веществ Отныне для субъектов хозяйственной деятельности, импортирующих и экспортирующих товары, в которых отсутствуют озоноразрушающие вещества, их таможенное оформление осуществляется без лицензии. ...

    На Черкащині працівники ДАІ затримали автомобіль ...

    На Черкащині працівники ДАІ  затримали автомобіль з 170 літрами прозорої рідини невідомого походження Днями, близько восьмої години ранку, під час несення служби на стаціонарному посту Золотоноша, інспектори взводу із забезпечення супроводження відділу ДАІ з обслуговування міста Черкаси, зупинили ...

    На Київщині нетверезий водій збив пішоходів та ...

    На Київщині нетверезий водій збив пішоходів та зник з місця ДТП Днями, близько о 20-й годині, в місті Васильків, невстановлений водій, керуючи автомобілем МОСКВИЧ 412, допустив наїзд на 27-річну місцеву мешканку та з місця пригоди зник. Жінка переходила проїзну ...

    Об Адвокате
    Ваш сайт просто увлекательный.

    Для меня это была просто большая находка! Уже неделю сижу здесь на портале и уходить отсюда совсем не собираюсь.

    Этот интернет проект просто супер очень много чего здесь интересного и необходимого. Желаю вам держаться высоко и всего самого... в Вашей работе!
    Публикации о недвижимости
    О налогообложении операции с недвижимостью ...

    О налогообложении операции с недвижимостью в Украине Сегодня, как и после принятия нового налога на недвижимость, эта тема широко обсуждается среди всех заинтересованных в этом ...

    Что лучше агент по недвижимости или адвокат

    Что лучше агент по недвижимости или адвокат Разграничение полномочий риелтора (агента), нотариуса и адвоката по вопросам недвижимости.

    fd88152c669729fa70f5fe095f45fa66