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

На виконання пункту 3 Плану заходів щодо реалізації Концепції розвитку електронного урядування в Україні , затвердженого розпорядженням Кабінету Міністрів України від 26 вересня 2011 року № 1014-р, відповідно до Закону України "Про електронний цифровий підпис" , підпунктів 65 і 66 пункту 4 Положення про Міністерство юстиції України , затвердженого Указом Президента України від 06 квітня 2011 року № 395, підпунктів 7 і 11 пункту 4 Положення про Адміністрацію Державної служби спеціального зв’язку та захисту інформації України , затвердженого Указом Президента України від 30 червня 2011 року № 717, та з метою створення умов технологічної сумісності програмно-технічних комплексів акредитованих центрів сертифікації ключів та надійних засобів електронного цифрового підпису

1. Затвердити такі, що додаються, вимоги до форматів, структури та протоколів, що реалізуються у надійних засобах електронного цифрового підпису (далі - Вимоги):

1.1. Вимоги до формату посиленого сертифіката відкритого ключа.

1.2. Вимоги до структури об’єктних ідентифікаторів для криптоалгоритмів, що є державними стандартами .

1.3. Вимоги до формату списку відкликаних сертифікатів .

1.4. Вимоги до формату підписаних даних .

1.5. Вимоги до протоколу фіксування часу .

1.6. Вимоги до протоколу визначення статусу сертифіката .

2. Установити, що:

2.1. Акредитовані центри сертифікації ключів, замовники, розробники, виробники та організації, які експлуатують надійні засоби електронного цифрового підпису в системах електронного документообігу, що створюються на виконання Плану заходів щодо реалізації Концепції розвитку електронного урядування в Україні , затвердженого розпорядженням Кабінету Міністрів України від 26 вересня 2011 року № 1014-р, забезпечують застосування положень Вимог у програмно-технічних комплексах акредитованих центрів сертифікації ключів та надійних засобах електронного цифрового підпису з 31 грудня 2012 року.

2.2. Акредитовані центри сертифікації ключів, замовники, розробники, виробники та організації, які експлуатують надійні засоби електронного цифрового підпису, крім визначених у підпункті 2.1 пункту 2 цього наказу, забезпечують застосування у програмно-технічних комплексах акредитованих центрів сертифікації ключів та надійних засобах електронного цифрового підпису положень Вимог з 01 червня 2013 року.

2.3. Акредитовані центри сертифікації ключів, які здійснили заходи, визначені у підпунктах 2.1, 2.2 пункту 2 цього наказу, надають послуги електронного цифрового підпису з моменту проходження повторної акредитації відповідно до пункту 13 Порядку акредитації центру сертифікації ключів , затвердженого постановою Кабінету Міністрів України від 13 липня 2004 року № 903.

3. Адміністрації Державної служби спеціального зв’язку та захисту інформації України вжити заходів для впровадження Вимог у програмно-технічних комплексах акредитованих центрів сертифікації ключів та надійних засобах електронного цифрового підпису в строки, визначені у підпунктах 2.1, 2.2 пункту 2 цього наказу.

4. Департаменту нотаріату, банкрутства та функціонування центрального засвідчувального органу Міністерства юстиції України (Чижмарь К.І.) розмістити цей наказ на офіційному веб-сайті Міністерства юстиції України.

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

6. Контроль за виконанням цього наказу покласти на заступника Міністра юстиції України Ворону М.Д. та першого заступника Голови Державної служби спеціального зв’язку та захисту інформації України Цуркана О.Г.

1.1. Ці Вимоги визначають формат посиленого сертифіката відкритого ключа (далі - сертифікат).

1.2. Формати даних представлено у нотації ASN.1, визначеній у міжнародному стандарті ISO/IEC 8824 "Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)" / ДСТУ ISO/ІЕС 8824-3:2008 "Інформаційні технології. Нотація абстрактного синтаксису 1 (ASN.1)" - частина 3. Специфікація обмежень (ISO/IEC 8824-3:2002, IDT), затвердженому наказом Державного комітету України з питань технічного регулювання та споживчої політики від 26 грудня 2008 року № 508 (із змінами).

1.3. Усі структури даних кодують за правилами DER згідно з міжнародним стандартом ISO/IEC 8825-1:2002 "Information technology - ASN.1 encoding Rules - Part 1: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)" & AMD1:2004 "Support for EX-TENDED-XER".

1.4. Ці Вимоги засновані на національному стандарті України ДСТУ ISO/IEC 9594-8:2006 "Інформаційні технології. Взаємозв'язок відкритих систем. Каталог. Частина 8. Основні положення щодо сертифікації відкритих ключів та атрибутів", затвердженому наказом Державного комітету України з питань технічного регулювання та споживчої політики від 27 грудня 2006 року № 374 (із змінами) (далі - ДСТУ ISO/IEC 9594-8:2006), з урахуванням визначених у статті 6 Закону України "Про електронний цифровий підпис" вимог до змісту сертифіката ключа.

1.5. Ці Вимоги не дублюють стандарт ДСТУ ISO/IEC 9594-8:2006, а описують положення цього стандарту та формати полів. У разі виникнення розбіжностей між положеннями зазначеного стандарту та положеннями цих Вимог застосовуються положення цих Вимог.

1.6. Положення цих Вимог є обов’язковими для програмно-технічних комплексів акредитованих центрів сертифікації ключів та надійних засобів електронного цифрового підпису. Правильність реалізації формату посиленого сертифіката відкритого ключа у надійних засобах електронного цифрового підпису підтверджується сертифікатом відповідності або позитивним експертним висновком за результатами державної експертизи у сфері криптографічного захисту інформації.

Сертифікат ключа подається в такому вигляді:

Поле "TBSCertificate" - це частина сертифіката, на яку за допомогою особистого ключа центрального засвідчувального органу, засвідчувального центру, акредитованого центру сертифікації ключів (далі - Центр) накладається електронний цифровий підпис (далі - ЕЦП) за криптографічним алгоритмом (далі - криптоалгоритм), об’єктний ідентифікатор якого міститься у полі "signatureAlgorithm". Значення ЕЦП містить поле "signatureValue".

Для усіх строкових даних та полів сертифіката, що мають універсальний тип "DirectoryString", використовується кодування UTF-8. Для набору символів ASCII може використовуватися кодування PrintableString. Символ ";" використовується як роздільник даних у полі сертифіката.

3.1. Основні поля сертифіката наведено в таблиці 1.

3.2. Поле "Номер версії сертифіката" ("version") повинно містити значення "2" (1 байт), яке означає, що формат сертифіката відповідає версії 3 згідно з національним стандартом ДСТУ ISO/IEC 9594-8:2006.

3.3. Значення поля “Унікальний реєстраційний номер сертифіката” (“serialNumber”) повинно бути додатним цілим числом, розмір якого не перевищує 20 байт (0<serialNumber<2-160).

Унікальність реєстраційного номера сертифіката повинна дотримуватися у рамках всіх сертифікатів, сформованих Центром.

3.4. Поле "Найменування та реквізити Центру" ("issuer") повинно містити найменування та реквізити Центру.

3.5. У полі "Найменування та реквізити Центру" ("issuer") повинні міститися реквізити Центру, що наведені у таблиці 2.

3.5.1. Поля "Найменування та реквізити Центру" ("issuer") та "Унікальний реєстраційний номер сертифіката" ("serialNumber") у структурі "TBSCertificate" разом ідентифікують унікальний сертифікат.

3.5.2. Реквізит "Унікальний реєстраційний номер сертифіката" ("serialNumber") у таблиці 2 містить унікальний реєстраційний номер Центру.

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

Реквізит містить цифри "0"-"9", великі латинські літери "А"-"Z" та символ "-";

Код Установи - 8, 9 або 10 цифр, що містять код за ЄДРПОУ організації - юридичної особи або реєстраційний номер облікової картки платника податку - фізичної особи, яка є суб'єктом підприємницької діяльності за установчими документами або відомостями про державну реєстрацію;

Додаток - необов’язкова послідовність від 1 до 4 цифр, що містить додаткову частину ідентифікатора. У разі використання Додатка він відокремлюється від реквізиту [Код Установи] символом "-".

Вищезазначений реквізит шляхом його додавання до розпізнавального імені Центру забезпечує унікальність його розпізнавального імені в межах України. Унікальність цього розпізнавального імені забезпечується центральним засвідчувальним органом.

3.6. Поле "Алгоритм ЕЦП" ("signature") повинно містити тільки об’єктний ідентифікатор криптоалгоритму, що використовується Центром для накладання електронного цифрового підпису на сертифікат ключа.

Значення поля "Алгоритм ЕЦП" ("signature") повинно співпадати із значенням, що міститься у полі "Найменування криптоалгоритму, що використовується Центром" ("signatureAlgorithm").

Поле "parameters" повинно бути відсутнє.

3.7. Поле "Строк чинності сертифіката" ("validity") повинно містити значення дати і часу початку та закінчення строку чинності сертифіката.

Поле "Time" зі значенням до 31 грудня 2049 року (включно) кодується у форматі "UTCTime"; починаючи з 01 січня 2050 року - у форматі "GeneralizedTime".

3.8. Поле "Підписувач" ("subject") повинно містити реквізити підписувача, що наведені у таблиці 3.

3.8.1. Реквізити юридичної особи-підписувача визначаються в таких атрибутах поля "Підписувач" ("subject"):

3.8.2. Реквізити фізичної особи - підписувача (прізвище, ім’я та по батькові за паспортними даними) визначаються в таких атрибутах поля “Підписувач” (“subject”):

Обов’язково повинні бути визначені дані в атрибутах "countryName" та "serialNumber" (унікальний реєстраційний номер підписувача).

3.8.3. Реквізити фізичної особи - підписувача, що представляє юридичну особу (або фізичну особу - суб’єкта підприємницької діяльності), визначаються в таких атрибутах поля “Підписувач” (“subject”):

Обов’язково повинні бути визначені дані в атрибутах "countryName" та "serialNumber" (унікальний реєстраційний номер підписувача).

3.8.4. Інші реквізити підписувача можуть бути зазначені у розширеннях (extensions) "Додаткові дані підписувача" ("subjectAltName") або "Персональні дані підписувача" ("subjectDirectoryAttributes") залежно від типу реквізиту.

3.9. Додаткові дані про підписувача можуть бути зазначені в інших полях згідно з форматом, визначеним у національному стандарті ДСТУ ISO/IEC 9594-8:2006.

3.10. Поле "Інформація про відкритий ключ підписувача" ("subjectPublicKeyInfo") повинно містити ідентифікатор криптоалгоритму, що використовується підписувачем, а також відкритий ключ, який відповідає особистому ключу підписувача у DER-кодуванні.

Ідентифікатор криптоалгоритму (поле "AlgorithmIdentifier") містить об’єктний ідентифікатор (поле "algorithm") та відповідні параметри криптоалгоритму.

Об’єктний ідентифікатор (поле "algorithm") повинен вказувати на один з криптоалгоритмів:

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

ГОСТ 34.310-95 "Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма", затвердженого наказом Державного комітету України з питань технічного регулювання та споживчої політики від 21 жовтня 1997 року № 640 (далі - ГОСТ 34.310-95).

Структура параметрів криптоалгоритму (поле "parameters") та структура відкритого ключа (поле "subjectPublicKey") визначаються об’єктним ідентифікатором криптоалгоритму.

3.11. Параметри криптоалгоритмів

3.11.1. Параметри криптоалгоритму ДСТУ 4145-2002

Значення довгострокового ключового елемента (далі - ДКЕ) повинні відповідати правилам постачання ДКЕ, які визначаються Інструкцією про порядок постачання і використання ключів до засобів криптографічного захисту інформації , затвердженою наказом Адміністрації Державної служби спеціального зв’язку та захисту інформації України від 12 червня 2007 року № 114, зареєстрованою в Міністерстві юстиції України 25 червня 2007 року за № 729/13996 (із змінами) (далі - Інструкція № 114). У разі відсутності ДКЕ як необов’язкового параметра криптоалгоритму повинен використовуватися ДКЕ № 1 із додатка 1 до Інструкції № 114.

3.11.1.1. Допускається кодування полів (розташування внутрішньої послідовності байтів) параметрів еліптичної кривої, що мають тип OCTET STRING, зокрема коефіцієнта В еліптичної кривої, базової точки еліптичної кривої bp, а також відкритого ключа "subjectPublicKey" за двома форматами:

Little-Endian - прямий порядок представлення байтів;

Big-Endian - зворотний порядок представлення байтів (відповідно до правил кодування, визначених в ДСТУ 4145-2002).

3.11.1.2. Об’єктні ідентифікатори для ДСТУ 4145-2002.

Для формату Little-Endian (при визначенні параметрів еліптичної кривої у сертифікаті):

Для формату Big-Endian:

3.11.1.3. Базова точка ДСТУ 4145-2002.

Для зображення базової точки використовується формат:

Базова точка ДСТУ 4145-2002 - це послідовність байтів, яка являє собою елемент основного поля (згідно з пунктом 5.3 ДСТУ 4145-2002), який є стиснутим зображенням (згідно з пунктом 6.9 ДСТУ 4145-2002) точки на еліптичній кривій (залежить від базису, що використовується). Розмір зображення в байтах дорівнює m/8, заокругленому до найближчого цілого у більшу сторону.

3.11.1.4. Коефіцієнт В еліптичної кривої.

Для зображення коефіцієнта B еліптичної кривої згідно з ДСТУ 4145-2002 використовується формат:

Коефіцієнт B еліптичної кривої ДСТУ 4145-2002 - це послідовність байтів, яка являє собою елемент основного поля (згідно з пунктом 5.3 ДСТУ 4145-2002). Розмір зображення в байтах дорівнює m/8, заокругленому до найближчого цілого у більшу сторону.

3.11.1.5. Відкритий ключ ДСТУ 4145-2002.

Для зображення відкритого ключа згідно з ДСТУ 4145-2002 використовується формат (інкапсульовано у поле "subjectPublicKey"):

Відкритий ключ ДСТУ 4145-2002 - це послідовність байтів, яка являє собою елемент основного поля (згідно з пунктом 5.3 ДСТУ 4145-2002), який є стиснутим зображенням (згідно з пунктом 6.9 ДСТУ 4145-2002) точки на еліптичній кривій, що відображає відкритий ключ ЕЦП. Розмір зображення в байтах дорівнює значенню m/8, заокругленому до найближчого цілого у більшу сторону.

3.11.1.6. ЕЦП за ДСТУ 4145-2002.

ЕЦП за ДСТУ 4145-2002 - це рядок октетів OCTET STRING (інкапсульовано у поле "signatureValue"), що містить цифровий підпис, зображений згідно з пунктами 5.7 та 5.10 ДСТУ 4145-2002:

Для зберігання зображення ЕЦП використовується мінімально можлива довжина зображення для відповідного ступеня m.

3.11.2. Параметри криптоалгоритму ГОСТ 34.310-95.

3.11.2.1. Об’єктний ідентифікатор для ГОСТ 34.310-95.

Об’єктний ідентифікатор для ГОСТ 34.310-95: 1.2.804.2.1.1.1.1.3.2.

3.11.2.2. Відкритий ключ ГОСТ 34.310-95.

Для зображення відкритого ключа згідно з ГОСТ 34.310-95 використовується формат (інкапсульовано у поле "subjectPublicKey"):

3.11.2.3. ЕЦП за ГОСТ 34.310-95.

ЕЦП згідно з ГОСТ 34.310-95 має вигляд (інкапсульовано у поле "signatureValue"):

де r та s обчислюються згідно з ГОСТ 34.310-95.

3.12. ДКЕ - таблиці заповнення вузлів заміни блоків підстановки для алгоритму ДСТУ ГОСТ 28147:2009 "Системы обработки информации. Защита криптографическая. Алгоритмы криптографического преобразования", затвердженого наказом Державного комітету України з питань технічного регулювання та споживчої політики від 22 грудня 2008 року № 495 , який використовується під час генерування псевдовипадкових послідовностей (ДСТУ 4145-2002, Додаток А) та обчислення геш-функції ГОСТ 34.311-95 "Информационная технология. Криптографическая защита информации. Функция хэширования", затвердженого наказом Державного комітету України з питань технічного регулювання та споживчої політики від 21 жовтня 1997 року № 640 (далі - ГОСТ 34.311-95).

Кодування ДКЕ виконується як:

ДКЕ може кодуватися в розгорнутому або упакованому форматі залежно від алгоритму:

для ДСТУ 4145-2002 - упакований формат;

для ГОСТ 34.310-95 - розгорнутий формат.

У разі відсутності ДКЕ в параметрах криптоалгоритму використовується ДКЕ № 1, що наведено у додатку 1 до Інструкції № 114 .

Упакований формат ДКЕ (масив 64 байт).

Формат розташування елементів ДКЕ - масив фіксованої довжини розміром 64 байт.

ДКЕ - це матриця, що має стовпці К1…К8 (р-1…р-8) по 16 елементів (0…15) у кожному. Порядок розташування елементів:

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

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

ДКЕ в упакованому форматі (масив 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. Стартовий вектор для обчислення значення геш-функції ГОСТ 34.311-95.

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

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

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

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

Всі значення типу “INTEGER” для алгоритмів ДСТУ 4145-2002 та ГОСТ 34.310-95 кодуються як цілі числа >=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.

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

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

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

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

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

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

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

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

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

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