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

ДКЕ в упакованому форматі (масив 64 байт) має вигляд:

3.12.2. Розгорнутий формат ДКЕ (масив 128 байт).

Формат розташування елементів ДКЕ - масив фіксованої довжини в 128 байт. ДКЕ - це матриця стовпців К1…К8 (р1…р8) по 16 елементів (0…15) у кожному. При зберіганні кожний елемент ДКЕ подано 1 байтом, які розташовані в такому порядку (від молодших байтів до старших):

К1.0, К1.1 … К1.15, К2.0, К2.1 … К2.15, …… К8.0, К8.1 … К8.15

Приклад кодування ДКЕ №1, що наведено в додатку 1 до Інструкції № 114 , в розгорнутому форматі (масив 128 байт) для блоку підстановки:

3.13. Порядок використання геш-функцій при обчисленні значення електронного цифрового підпису.

3.13.1. Геш-функція може бути обчислена одним з криптоалгоритмів:

ГОСТ 34.311-95;

ДСТУ 7564:2014.

3.13.2. При використанні функції гешування за ГОСТ 34.311-95 під час обчислення електронного цифрового підпису значення стартового вектора H встановлюється рівним 256 нульовим бітам.

3.13.3. При використанні функції гешування за ДСТУ 7564-2014 під час обчислення електронного цифрового підпису рекомендовано застосовувати режими обчислення геш-значення, що визначаються бітовою довжиною порядку базової точки еліптичної кривої та наведені в таблиці 4. Як стартовий вектор геш-функції використовується нульовий вектор. Приклади обчислень електронного цифрового підпису з використанням функції гешування за ДСТУ 7564-2014 розміщуються на офіційному веб-сайті Державної служби спеціального зв’язку та захисту інформації України.

3.14. Порядок кодування окремих параметрів криптографічних алгоритмів.

При кодуванні реквізитів криптографічного алгоритму за ДСТУ 4145-2002 застосовуються такі правила:

3.14.1. Значення типу "INTEGER".

Всі значення типу "INTEGER" для алгоритмів ДСТУ 4145-2002 кодуються як цілі числа >=0.

Наприклад, значення для типу "INTEGER" кодуються такою послідовністю байтів:

а) позитивне число 18А3h кодується в DER як послідовність байтів 02 02 18 А3;

б) позитивне число FA10h кодується як послідовність байтів 02 03 00 FA 10 (додається 00 як додатковий старший байт, оскільки старший біт старшого байта FAh дорівнює 1);

в) число 0 кодується в DER як послідовність байтів 02 01 00.

3.14.2. Кодування двійкових рядків в складі ASN.1-типу OCTET STRING у форматі Little-Endian.

Математичне кодування двійкових рядків (бітових послідовностей) виконується за схемою - молодший байт (що містить менші за номерами біти) за молодшою адресою (ближче до початку потоку).

Біти в байті нумеруються від 0 до 7 за вагою розряду: біт i має вагу 2-i.

Наприклад: біт 0 має вагу 1 (01h), біт 1 має вагу 2 (02h), біт 7 має вагу 128 (80h).

Біт n двійкового рядка кодується як біт i байта j, де i та j обчислюються за формулами:

Якщо кількість бітів у двійковому рядку не кратна 8, біти останнього байта, які не використовуються, мають містити нульове значення.

Наприклад:

бітовий рядок 11100011 кодується як байт E3h;

бітовий рядок 1111000110111 кодується як послідовність байт 37h 1Eh.

3.15. Під час формування електронного цифрового підпису за ДСТУ 4145-2002 з функцією гешування за ДСТУ 7564-2014 як генератор випадкових двійкових послідовностей необхідно застосовувати алгоритм криптографічного перетворення відповідно до національного стандарту України ДСТУ 7624:2014 "Інформаційні технології. Криптографічний захист інформації. Алгоритм симетричного блокового перетворення", затвердженого наказом Міністерства економічного розвитку і торгівлі України від 29 грудня 2014 року № 1484, у режимі "Калина-256/256-ECB".

4.1. Формат розширень сертифіката має такий вигляд:

Базовий об’єктний ідентифікатор розширень сертифіката має такий вигляд:

Сертифікат може містити будь-які додаткові розширення, які не визначені в цьому документі, за умови, що вони визначені як некритичні. Об’єктні ідентифікатори таких розширень повинні бути зареєстровані у встановленому порядку.

4.2. Розширення сертифіката наведені у таблиці 5.

4.3. Розширення "Ідентифікатор відкритого ключа Центру" ("authorityKeyIdentifier") використовується для ідентифікації відкритого ключа, що відповідає особистому ключу, яким підписано сертифікат або список відкликаних сертифікатів.

Об’єктний ідентифікатор даного розширення має такий вигляд:

Атрибут "KeyIdentifier" повинен обов’язково бути присутнім.

Поле "authorityKeyIdentifier" не повинно визначатися як критичне.

4.4. Розширення "Ідентифікатор відкритого ключа підписувача" ("subjectKeyIdentifier") використовується для ідентифікації відкритого ключа, що відповідає особистому ключу, за допомогою якого підписувач здійснює накладання електронного цифрового підпису.

Об’єктний ідентифікатор даного розширення має такий вигляд:

Поле "Ідентифікатор відкритого ключа підписувача" ("subjectKeyIdentifier") не повинно визначатися як критичне.

4.5. Обчислення "keyIdentifier" для алгоритмів ДСТУ 4145-2002.

Значення "keyIdentifier" в розширеннях "subjectKeyIdentifier" та "authorityKeyIdentifier" обчислюються відповідно засобами ЕЦП підписувача та Центром під час генерації та обробки запиту на формування сертифіката таким чином.

Із кодованого як BIT STRING зображення відкритого ключа вилучаються байт, що містить ознаку типу даних, байти, що містять довжину блоку даних, та байт, що містить число невикористаних бітів.

Обчислюється значення геш-функції згідно з пунктом 3.13 розділу ІІІ цих Вимог.

Якщо параметри криптоалгоритму у полі "Інформація про відкритий ключ підписувача" ("subjectPublicKeyInfo") містять таблицю заповнення вузлів заміни блоку підстановки (ДКЕ), то при обчисленні геш-функції використовується саме цей ДКЕ, інакше використовується ДКЕ № 1, що наведений у додатку 1 до Інструкції № 114.

4.6. Розширення "Призначення відкритого ключа" ("keyUsage") визначає призначення відкритого ключа, що міститься в сертифікаті та повинно визначатися як критичне.

Об’єктний ідентифікатор даного розширення має такий вигляд:

Для сертифіката, що формується підписувачу, повинні бути встановлені біти "digitalSignature" (0) та "nonRepudiation" (1).

Для сертифіката Центру повинні бути встановлені біти "keyCertSign" (5) та "crlSign" (6).

4.7. Розширення "Уточнене призначення відкритого ключа" ("extendedKeyUsage") може бути визначено як критичне.

Об’єктний ідентифікатор даного розширення має такий вигляд:

Для сертифіката Центру, що використовується для перевірки підпису OCSP-відповідей та позначок часу, повинні бути зазначені об’єктні ідентифікатори ( id-kp 8 ) або ( id-kp 9 ).

Для сертифіката підписувача, якщо ЕЦП застосовується як електронна печатка, розширення "Уточнене призначення відкритого ключа" ("extendedKeyUsage") повинно містити об’єктний ідентифікатор 1.2.804.2.1.1.1.3.9.

Для сертифікатів підписувача, які використовуються для перевірки ЕЦП у визначених інформаційно-телекомунікаційних системах, в розширенні "Уточнене призначення відкритого ключа" ("extendedKeyUsage") можуть використовуватись відповідні об’єктні ідентифікатори за умови, що ці об’єктні ідентифікатори зареєстровані у встановленому порядку.

4.8. Розширення "Політика сертифікації" ("certificatePolicies") містить посилання на політику сертифікації, відповідно до якої Центр сформував сертифікат. Розширення повинно визначатися як критичне.

Об’єктний ідентифікатор даного розширення має такий вигляд:

4.9. Розширення "Додаткові дані підписувача" ("subjectAlternativeName") використовується для розширення межі ідентифікації підписувача (адреса електронної пошти, DNS, IP-адреса, URL).

Об’єктний ідентифікатор даного розширення має такий вигляд:

4.10. Розширення "Додаткові дані Центру" ("issuerAlternativeName") дозволяє розширити межі ідентифікації Центру (адреса електронної пошти, DNS, IP-адреса, URL). Розширення повинно бути визначено як некритичне.

Об’єктний ідентифікатор даного розширення має такий вигляд:

4.11. Розширення "Основні обмеження" ("basicConstraints") дозволяє визначити, що сертифікат сформований для Центру або підписувача. Розширення повинно визначатися як критичне.

Об’єктний ідентифікатор даного розширення має такий вигляд:

Поле "pathLenConstraint" використовується, якщо поле сA встановлено в TRUE. У цьому разі воно визначає максимально допустиму кількість проміжних сертифікатів, що знаходяться між цим сертифікатом та сертифікатом підписувача.

У сертифікаті акредитованого центру сертифікації ключів розширення "pathLenConstraint" повинно мати значення "0".

У сертифікаті засвідчувального центру розширення "pathLenConstraint" повинно мати значення "1".

У сертифікаті центрального засвідчувального органу розширення "pathLenConstraint" повинно мати значення "2".

4.12. Розширення "Персональні дані підписувача" ("subjectDirectoryAttributes") має містити додаткові персональні дані підписувача та бути визначено як некритичне. Поле не використовується для зберігання даних про підписувача, що визначені в полі "subject".

Об’єктний ідентифікатор цього розширення має такий вигляд:

Кодування національних реквізитів у розширенні "Персональні дані підписувача" ("SubjectDirectoryAttributes") виконується за такими правилами:

Для кодування цього реквізиту використовується об’єктний ідентифікатор 1.2.804.2.1.1.1.11.1.4.2.1. Формат реквізиту - "PrintableString", що містить 8, 9 або 10 цифр;

Для кодування цього реквізиту використовується об’єктний ідентифікатор 1.2.804.2.1.1.1.11.1.4.2.1. Формат реквізиту - "PrintableString", що містить 8, 9 або 10 цифр;

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

Для кодування цього реквізиту використовується об’єктний ідентифікатор 1.2.804.2.1.1.1.11.1.4.1.1. Формат реквізиту - "PrintableString", що містить 10 цифр;

3) для фізичних осіб - резидентів, які через свої релігійні переконання відмовились від прийняття реєстраційного номера облікової картки платника податків та повідомили про це відповідний контролюючий орган і мають відмітку у паспорті, до реквізитів, яким відповідають об’єктні ідентифікатори 1.2.804.2.1.1.1.11.1.4.1.1 та 1.2.804.2.1.1.1.11.1.4.2.1, вносяться серія (за наявності) та номер паспорта громадянина України. Формат реквізиту - "PrintableString", що містить від 2 до 8 літер серії паспорта (за наявності) та 6 або 9 цифр номера паспорта.

Кодування літерної частини реквізиту здійснюється відповідно до таблиці транслітерації українського алфавіту латиницею, затвердженої постановою Кабінету Міністрів України від 27 січня 2010 року № 55;

4) реквізит унікального номера запису в Єдиному державному демографічному реєстрі використовується для сертифікатів, підписувачами у яких є фізичні особи - резиденти, у тому числі посадові особи. У цьому реквізиті вказується унікальний номер запису в Єдиному державному демографічному реєстрі фізичної особи - підписувача. Для кодування цього реквізиту використовується об’єктний ідентифікатор 1.2.804.2.1.1.1.11.1.4.11.1. Формат реквізиту - "PrintableString", що містить послідовність з 8 цифр, символу "-" та 5 цифр.

Кодування реквізитів у розширенні "Персональні дані підписувача" ("SubjectDirectoryAttributes") для юридичних осіб - нерезидентів та фізичних осіб - нерезидентів здійснюється за тими самими правилами з урахуванням особливостей форматів ідентифікаційних даних юридичних осіб та фізичних осіб, прийнятих у державі нерезидента, які підтверджено офіційними документами, наданими підписувачем.

4.13. У розширенні "Точки доступу до списків відкликаних сертифікатів" ("CRL Distribution Points") повинна зазначатися принаймні одна загальнодоступна точка розповсюдження списків відкликаних сертифікатів (CRL), яка визначається http (http://) або ldap (ldap://). Розширення не повинно визначатися як критичне.

Об’єктний ідентифікатор даного розширення має такий вигляд:

Дозволяється використання лише атрибута "distributionPoint" і тільки у форматі URI, який вказує на відповідний CRL.

4.14. Якщо Центр разом із базовим CRL формує і частковий CRL, то посилання на нього вказується у розширенні "Точка доступу до часткового списку відкликаних сертифікатів" ("Freshest CRL"). Розширення не повинно визначатися як критичне.

Об’єктний ідентифікатор даного розширення має такий вигляд:

Формування цього розширення здійснюється за правилами формування розширення "Точки доступу до списків відкликаних сертифікатів" ("CRL Distribution Points").

Це розширення не є обов’язковим. Якщо посилання на частковий CRL не вказується в сертифікаті, то воно обов’язково вказується у відповідному розширенні в структурі базового CRL.

Вимоги щодо формату CRL визначені у Вимогах до формату списку відкликаних сертифікатів, затверджених наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв’язку та захисту інформації України від 20 серпня 2012 року № 1236/5/453, зареєстрованих у Міністерстві юстиції України 20 серпня 2012 року за № 1400/21712.

4.15. Розширення "Ознаки посиленого сертифіката" ("qualified certificate statement") повинно бути визначено як критичне.

Об’єктний ідентифікатор даного розширення має такий вигляд:

4.15.1. Ознака того, що сертифікат сформований як посилений (обов’язкова):

Для зазначення того, що сертифікат є посиленим, використовується таке заповнення реквізитів сертифіката підписувача:

обов’язково: в розширенні "Політика сертифікації" ("certificate policies") вказується об’єктний ідентифікатор політики посиленої сертифікації 1.2.804.2.1.1.1.2.2, який визначає, що сертифікат сформовано як посилений згідно із Законом України "Про електронний цифровий підпис" . Якщо сертифікат підписувача відповідає вимогам додаткових політик сертифікації Центру, у ньому можуть бути вказані додатково об’єктні ідентифікатори цих політик сертифікації;

додатково: може бути присутнім розширення "qualified certificate statement", у якому за допомогою стандартного об’єктного ідентифікатора 1.2.804.2.1.1.1.2.1 ("Qualified certificate statement id-ua-diglow-qcs-QcCompliance") позначено відповідність Закону України "Про електронний цифровий підпис" .

14.15.2. Ознака наявності обмеження максимальної суми, на яку вчиняється правочин з використанням електронного цифрового підпису (необов’язкова):

4.15.3. Ознака того, що генерація особистого ключа відбулася з використанням захищеного носія особистого ключа (обов’язкова у випадку використання захищеного носія особистого ключа):

esi4-qcStatement-4 QC-STATEMENT ::= ( IDENTIFIED BY id-etsi-qcs-QcSSCD )

id-etsi-qcs-QcSSCD OBJECT IDENTIFIER::= ( id-etsi-qcs 4 ).

Під час формування сертифікатів відкритих ключів підписувачів повинні використовуватись алгоритми електронного цифрового підпису ECDSA відповідно до національного стандарту ДСТУ ISO/IEC 14888-3:2015 "Інформаційні технології. Методи захисту. Цифрові підписи з доповненням. Частина 3. Механізми, що ґрунтуються на дискретному логарифмуванні", затвердженого наказом державного підприємства "Український науково-дослідний і навчальний центр проблем стандартизації, сертифікації та якості" від 18 грудня 2015 року № 193, зі ступенем розширення основного поля еліптичної кривої не менше 256 бітів або RSA відповідно до рекомендацій RFC 3447 "Public-Key Cryptography Standards (PKCS) № 1: RSA Cryptography Specifications Version 2.1".

Для обчислення значення геш-функції під час формування сертифікатів відкритих ключів підписувачів повинен використовуватись алгоритм SHA-256 або SHA-512 відповідно до FIPS PUB 180-4 "Secure Hash Standard".

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