Идет загрузка документа (166 kByte)
Главный правовой
портал Украины
Главный правовой
портал Украины
Остаться Попробовать

Об утверждении Требований к форматам криптографических сообщений

Администрация Государственной службы специальной связи и защиты информации Украины
Приказ от 18.12.2012 № 739
редакция действует с 02.06.2020

АДМІНІСТРАЦІЯ ДЕРЖАВНОЇ СЛУЖБИ СПЕЦІАЛЬНОГО ЗВ'ЯЗКУ ТА ЗАХИСТУ ІНФОРМАЦІЇ УКРАЇНИ

НАКАЗ

18.12.2012

м. Київ

N 739

Зареєстровано в Міністерстві юстиції України
14 січня 2013 р. за N 108/22640

Про затвердження Вимог до форматів криптографічних повідомлень

Із змінами і доповненнями, внесеними
 
наказами Адміністрації Державної служби спеціального зв'язку та захисту інформації України
 від 21 грудня 2017 року N 712
,
від 4 березня 2020 року N 129

Відповідно до підпункту 7 пункту 4 Положення про Адміністрацію Державної служби спеціального зв'язку та захисту інформації, затвердженого Указом Президента України від 30 червня 2011 року N 717, пункту 4 розпорядження Кабінету Міністрів України від 09 вересня 2009 року N 1087-р "Деякі питання організації електронного документообігу та звітності", з метою створення умов технологічної сумісності засобів криптографічного захисту інформації

НАКАЗУЮ:

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

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

(пункт 2 у редакції наказу Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 04.03.2020 р. N 129)

3. Установити, що кваліфіковані надавачі електронних довірчих послуг мають право надавати послуги з обслуговування сертифікатів шифрування та у разі фактичного їх надання інформують про це Адміністрацію Держспецзв'язку.

(пункт 3 у редакції наказу Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 04.03.2020 р. N 129)

4. Пункт 4 виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129,
у зв'язку з цим пункти 5 - 7 вважати відповідно пунктами 4 - 6)

4. Директору Департаменту криптографічного захисту інформації Адміністрації Державної служби спеціального зв'язку та захисту інформації України в установленому порядку забезпечити подання цього наказу на державну реєстрацію до Міністерства юстиції України.

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

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

 

Голова Служби

Г. А. Резніков

ПОГОДЖЕНО:

 

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

М. Ю. Бродський

 

ВИМОГИ ДО ФОРМАТІВ КРИПТОГРАФІЧНИХ ПОВІДОМЛЕНЬ

(У тексті Вимог слова та цифри "ДСТУ ГОСТ 28147-2009" замінено словами та цифрами "ДСТУ ГОСТ 28147:2009"; абревіатури та цифри "ДСТУ ISO/IEC 11770-3:2002" замінено абревіатурами та цифрами "ДСТУ ISO/IEC 11770-3:2015"; абревіатури та цифри "ДСТУ ISO/IEC 15946-3:2006" замінено абревіатурами та цифрами "ДСТУ ISO/IEC 11770-3:2015" згідно з наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації  України від 21 грудня 2017 року N 712)

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

1.1. Ці Вимоги визначають синтаксис (формат представлення) криптографічних повідомлень (зашифрованих даних) в електронній формі, а також протоколи узгодження ключів для засобів криптографічного захисту інформації (далі - КЗІ).

(пункт 1.1 розділу I із змінами, внесеними згідно з наказом
 Адміністрації Державної служби спеціального зв'язку та
 захисту інформації України від 04.03.2020 р. N 129)

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

Державна експертиза у сфері КЗІ проводиться в порядку, визначеному відповідними нормативно-правовими актами.

(пункт 1.2 розділу I у редакції наказу Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 04.03.2020 р. N 129)

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

дані - повідомлення або частина повідомлення, яке не обробляють чи не змінюють у процесі обробки;

механізм узгодження ключа - статичний (Static-Static mode) або динамічний (Ephemeral-Static mode) механізм узгодження ключа, що визначений у цих Вимогах;

повідомлення "захищені дані" - повідомлення, що містить цифровий конверт;

протокол узгодження ключа - протокол Діффі-Геллмана обчислення ключа шифрування ключа (КШК) в групі точок еліптичної кривої;

(абзац п'ятий пункту 1.3 розділу I із змінами, внесеними згідно з
 наказом Адміністрації Державної служби спеціального зв'язку та захисту
 інформації України від 04.03.2020 р. N 129)

сертифікат шифрування - сертифікат відкритого ключа, виданий надавачем електронних довірчих послуг і призначений для використання у протоколі узгодження ключа;

(пункт 1.3 розділу I доповнено новим абзацом шостим згідно з
 наказом Адміністрації Державної служби спеціального зв'язку та захисту
 інформації України від 04.03.2020 р. N 129,
у зв'язку з цим абзаци шостий - дев'ятий
 вважати відповідно абзацами сьомим - десятим)

симетричний ключ сеансу або ключ шифрування даних (КШД) - ключ сеансу, на якому здійснюється шифрування даних за визначеним у цих Вимогах алгоритмом криптографічного перетворення;

узгоджений ключ ("key agreement") або ключ шифрування ключа (КШК) - симетричний ключ, на якому здійснюється шифрування симетричного ключа сеансу;

цифровий конверт ("enveloped-data") - зашифровані дані типу "дані" ("data") або "підписані дані" ("signed-data") разом із зашифрованим симетричним ключем.

Інші терміни вживаються у значеннях, наведених у Законі України "Про електронні довірчі послуги" та нормативно-правових актах у сфері електронних довірчих послуг.

(абзац десятий пункту 1.3 розділу I у редакції наказу
Адміністрації Державної служби спеціального зв'язку та
 захисту інформації України від 04.03.2020 р. N 129)

1.4. У цих Вимогах скорочення мають такі значення:

CMS - синтаксис криптографічного повідомлення (Cryptographic Message Syntax);

абзац третій пункту 1.4 розділу I виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129,
у зв'язку з цим абзаци четвертий та п'ятий
 вважати відповідно абзацами третім та четвертим)

ECDH - протокол узгодження ключів Діффі-Геллмана (Diffie-Hellman), що базується на криптографічних перетвореннях у групі точок еліптичної кривої; може використовуватися також позначення ECC DH (Elliptic Curve Cryptography Diffie-Hellman);

(абзац третій пункту 1.4 розділу I із змінами, внесеними згідно з
 наказом Адміністрації Державної служби спеціального зв'язку та захисту
 інформації України від 04.03.2020 р. N 129)

ДКЕ - довгостроковий ключовий елемент.

1.5. Ці Вимоги базуються на рекомендаціях Комітету із інженерних питань Інтернету RFC 3370 "Cryptographic Message Syntax (CMS) Algorithms", August 2002 (далі - RFC 3370); RFC 3852 "Cryptographic Message Syntax (CMS)", July 2004 (далі - RFC 3852); RFC 5652 "Cryptographic Message Syntax (CMS)", September 2009 (далі - RFC 5652), національному стандарті України ДСТУ ISO/IEC 11770-3:2015 "Інформаційні технології. Методи захисту. Керування ключами. Частина 3. Механізми з використанням асиметричних методів" (далі - ДСТУ ISO/IEC 11770-3:2015) та встановлюють особливості застосування в них криптографічних алгоритмів, визначених стандартами ДСТУ 4145-2002 "Інформаційні технології. Криптографічний захист інформації. Цифровий підпис, що ґрунтується на еліптичних кривих. Формування та перевіряння" (далі - ДСТУ 4145-2002), ДСТУ ГОСТ 28147:2009 "Системы обработки информации. Защита криптографическая. Алгоритмы криптографического преобразования" (далі - ДСТУ ГОСТ 28147:2009), ДСТУ 7624:2014 "Інформаційні технології. Криптографічний захист інформації. Алгоритм симетричного блокового перетворення" (далі - ДСТУ 7624:2014), ДСТУ ISO/IEC 10118-3:2005 "Інформаційні технології. Методи захисту. Геш-функції. Частина 3. Спеціалізовані геш-функції" (далі - ДСТУ ISO/IEC 10118-3:2005).

(абзац перший пункту 1.5 розділу I із змінами, внесеними згідно з
 наказом Адміністрації Державної служби спеціального зв'язку та захисту
 інформації України від 04.03.2020 р. N 129)

Під час застосування міжнародних алгоритмів цифрового підпису застосовуються вимоги RFC 3370, RFC 3852, RFC 5652, ISO/IEC 11770-3, ISO/IEC 10118-3.

(абзац другий пункту 1.5 розділу I із змінами, внесеними згідно з
 наказом Адміністрації Державної служби спеціального зв'язку та захисту
 інформації України від 04.03.2020 р. N 129)

1.6. Якщо у Вимогах є розбіжності з RFC 3370, RFC 3852, RFC 5652 та ДСТУ ISO/IEC 11770-3:2015, застосовуються положення цих Вимог.

1.7. Обмеження та рекомендації щодо застосування довжин ключів у криптографічних повідомленнях "захищені дані" визначаються чинним законодавством.

1.8. Ці Вимоги розроблено з урахуванням Інструкції про порядок постачання і використання ключів до засобів криптографічного захисту інформації, затвердженої наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 12 червня 2007 року N 114, зареєстрованої в Міністерстві юстиції України 25 червня 2007 року за N 729/13996 (далі - Інструкція N 114), Вимог до електронних довірчих послуг, затверджених постановою Кабінету Міністрів України від 07 листопада 2018 року N 992 (далі - Вимоги до електронних довірчих послуг).

(пункт 1.8 розділу I у редакції наказу Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 04.03.2020 р. N 129)

1.9. У цих Вимогах повинні застосовуватися криптографічні алгоритми, встановленні пунктом 3 наказу Міністерства юстиції України, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 18 листопада 2019 року N 3563/5/610 "Про встановлення вимог до технічних засобів, процесів їх створення, використання та функціонування у складі інформаційно-телекомунікаційних систем під час надання електронних довірчих послуг", зареєстрованого в Міністерстві юстиції України 20 листопада 2019 року за N 1172/34143.

(пункт 1.9 розділу I у редакції наказу Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 04.03.2020 р. N 129)

(розділ I у редакції наказу Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 21.12.2017 р. N 712)

II. Типи повідомлень

2.1. Ці Вимоги визначають тип повідомлення "ContentInfo", що містить тип даних "захищені дані".

2.2. Тип повідомлення "ContentInfo" подано в нотації ASN.1, яка визначена ДСТУ ISO/IEC 8824-1:2017 (ISO/IEC 8824-1:2015, IDT) "Інформаційні технології. Нотація абстрактного синтаксису 1 (ASN.1). Частина 1. Специфікація базової нотації", ДСТУ ISO/IEC 8824-2:2017 (ISO/IEC 8824-2:2015, IDT) "Інформаційні технології. Нотація абстрактного синтаксису 1 (ASN.1). Частина 2. Специфікація інформаційного об'єкта", ДСТУ ISO/IEC 8824-3:2008 (ISO/IEC 8824-3:2002, IDT) "Інформаційні технології. Нотація абстрактного синтаксису 1 (ASN.1). Частина 3. Специфікація обмежень", ДСТУ ISO/IEC 8824-4:2017 (ISO/IEC 8824-4:2015, IDT) "Інформаційні технології. Нотація абстрактного синтаксису 1 (ASN.1). Частина 4. Параметризація специфікацій ASN.1.

(пункт 2.2 розділу II у редакції наказу Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 04.03.2020 р. N 129)

2.3. Усі структури даних кодуються за правилами DER згідно з міжнародними стандартами ISO/IEC 8825-1:2008 "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".

2.4. Формат повідомлення "ContentInfo".

На тип "ContentInfo" вказує такий об'єктний ідентифікатор:

id-ct-contentInfo OBJECT IDENTIFIER ::= {iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6}.

Інформаційне повідомлення "ContentInfo" має такий формат:

ContentInfo ::= SEQUENCE {

contentType

ContentType,

content

[0] EXPLICIT ANY DEFINED BY contentType }

ContentType ::= OBJECT IDENTIFIER.

Поля структури "ContentInfo" мають такі значення:

"contentType" - об'єктний ідентифікатор, що вказує на тип пов'язаних з ним даних, наприклад, тип "захищені дані";

"Content" - пов'язані з об'єктним ідентифікатором дані. Тип даних однозначно визначається полем "contentType".

2.5. Повідомлення, що містить цифровий конверт, має тип даних "enveloped-data" ("захищені дані"). Повідомлення типу "захищені дані" входять до повідомлення типу "ContentInfo".

Об'єктний ідентифікатор

id-envelopedData OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3}

вказує на те, що структура "ContentInfo" містить дані типу "захищені дані".

Приклади ASN.1 структури "захищені дані" розміщуються на офіційному веб-сайті Державної служби спеціального зв'язку та захисту інформації України.

(пункт 2.5 розділу II у редакції наказу Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 21.12.2017 р. N 712)

2.6. Криптографічне повідомлення "захищені дані" містить у собі інші типи повідомлень, а саме: "дані" ("data") або "підписані дані" ("signed-data")".

Абзац другий пункту 2.6 розділу II виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 21.12.2017 р. N 712)

2.7. Формат повідомлення "підписані дані" ("signed-data") встановлюється Вимогами до електронних довірчих послуг.

(абзац перший пункту 2.7 розділу II із змінами, внесеними згідно з
 наказом Адміністрації Державної служби спеціального зв'язку та захисту
 інформації України від 04.03.2020 р. N 129)

На тип "signed-data" вказує такий об'єктний ідентифікатор:

id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }.

2.8. Повідомлення типу "дані" призначено для представлення довільних рядків октетів, наприклад, текстових файлів ASCII. Інтерпретація таких даних покладається на програмний додаток.

На тип "data" вказує такий об'єктний ідентифікатор:

id-data OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1}.

III. Процедура формування та розкриття "захищених даних"

1. Процедура формування "захищених даних" відправником

1.1. Відправник за протоколом управління ключами за допомогою особистого ключа відправника та відкритого ключа одержувача формує узгоджений ключ, на якому шифрує симетричний ключ сеансу КШД.

1.2. Зашифрований симетричний ключ сеансу КШД та інша інформація для одержувача вводяться в структуру "RecipientInfo" (інформація одержувача). Структура "RecipientInfo" наводиться у підпункті 3.7.1 пункту 3.7 глави 3 розділу IV цих Вимог.

1.3. Дані зашифровуються на симетричному ключі сеансу КШД.

1.4. Структура "RecipientInfo" разом із зашифрованими даними вводяться у структуру "enveloped-data". Структура "enveloped-data" наводиться у пункті 1.1 глави 1 розділу IV цих Вимог.

1.5. Зашифровані дані розміщуються у полі "EnvelopedData encryptedContentInfo encryptedContent OCTET STRING" структури "envelopeddata".

2. Процедура розкриття "захищених даних" одержувачем

2.1. Одержувач згідно з протоколом узгодження ключа за допомогою відкритого ключа відправника та особистого ключа одержувача формує узгоджений ключ, на якому розшифровує симетричний ключ сеансу КШД. Інформація для одержувача, яка необхідна для реалізації протоколу управління ключами з боку одержувача, а також для розшифрування повідомлення, подається в структурі "RecipientInfo". Структура "RecipientInfo" наводиться у підпункті 3.7.1 пункту 3.7 глави 3 розділу IV цих Вимог.

2.2. Одержувач за допомогою симетричного ключа сеансу КШД розшифровує дані, використовуючи алгоритм шифрування, що визначений у структурі "RecipientInfo".

3. Особливості формування повідомлення "захищені дані"

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

3.2. Для формування повідомлення "захищені дані" застосовується статичний або динамічний механізм узгодження ключів за протоколом Діффі-Геллмана.

3.2.1. Статичний механізм узгодження ключів ("Static-Static mode") - узгодження ключів за протоколом Діффі-Геллмана, за якого як відправник, так і одержувач мають статичну ключову пару, відкритий ключ якої засвідчено кваліфікованим надавачем електронних довірчих послуг.

Статичний механізм узгодження ключів може використовуватися лише у випадку, коли параметри криптографічного алгоритму статичної ключової пари відправника еквівалентні параметрам криптографічного алгоритму статичної ключової пари одержувача. Якщо зазначені параметри не еквівалентні, повинен застосовуватися динамічний механізм узгодження ключів.

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

Відкриті ключі відправника та одержувача обираються із сертифікатів шифрування.

3.2.2. Під час динамічного механізму узгодження ключа для формування узгодженого ключа відправник повинен використовувати особистий сеансовий ключ відправника і відкритий ключ одержувача. Одержувач повинен використовувати особистий ключ одержувача і відкритий сеансовий ключ відправника, що отримує від відправника, під час кожного сеансу в полі "originatorKey" структури "RecipientInfo".

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

При динамічному механізмі узгодження ключа для формування узгодженого ключа відправник повинен використовувати особистий ключ відправника і відкритий ключ одержувача. Одержувач повинен використовувати особистий ключ одержувача і відкритий ключ відправника, що отримується від відправника, при кожному сеансі у полі "originatorKey" структури "RecipientInfo".

Особливості кодування параметрів протоколу узгодження ключа визначено у главі 4 розділу V цих Вимог.

Протокол узгодження ключів Діффі-Геллмана в групі точок еліптичної кривої використовується для ключових пар (відправника та одержувача), що відповідають ДСТУ 4145-2002.

(пункт 3.2 глави 3 розділу III із змінами, внесеними згідно з
 наказом Адміністрації Державної служби спеціального зв'язку та захисту
 інформації України від 21.12.2017 р. N 712,
у редакції наказу Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129)

IV. Представлення структури "захищені дані"

1. Формат структури "захищені дані"

1.1. Структура "захищені дані" має такий формат (RFC 3852, RFC 5652):

EnvelopedData ::= SEQUENCE {

 

version

CMSVersion,

 

originatorInfo

[0] IMPLICIT OriginatorInfo OPTIONAL,

 

recipientInfos

RecipientInfos,

 

encryptedContentInfo

EncryptedContentInfo,

 

unprotectedAttrs

[1] IMPLICIT UnprotectedAttributes OPTIONAL}

CMSVersion ::= INTEGER {v0(0), v1(1), v2(2), v3(3), v4(4), v5(5)},

OriginatorInfo ::= SEQUENCE {

 

certificates

[0] CertificateSet OPTIONAL,

 

crls

[1] CertificateRevocationLists OPTIONAL },

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo,

EncryptedContentInfo ::= SEQUENCE {

 

contentType

ContentType,

 

contentEncryptionAlgorithm

ContentEncryptionAlgorithmIdentifier,

 

encryptedContent

[0] IMPLICIT EncryptedContent OPTIONAL },

EncryptedContent ::= OCTET STRING,

UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute.

1.2. Тип даних "захищені дані" містить дані про одного або більше одержувачів цифрового конверта, який вміщує "дані" або "підписані дані".

2. Порядок формування "захищених даних"

2.1. Генерується випадково симетричний ключ сеансу КШД.

2.2. Використовуючи статичний чи динамічний механізм узгодження ключів, обчислюється ключ шифрування ключа (КШК) для кожного одержувача.

2.3. Симетричний ключ сеансу КШД шифрується на ключі шифрування ключа КШК для кожного одержувача.

2.4. Для кожного одержувача зашифрований ключ КШД та інша відповідна специфічна інформація розміщуються всередині значення "RecipientInfo".

2.5. Значення "RecipientInfo" для всіх одержувачів разом із зашифрованими даними розміщуються в "EnvelopedData".

3. Поля структури "EnvelopedData"

3.1. Поле "Version" визначає номер версії синтаксису, який повинен мати значення 2.

3.2. Поле "originatorInfo" містить сертифікат шифрування відправника та додатково може містити пов'язані з ним кваліфіковані сертифікати відкритих ключів і списки відкликаних сертифікатів. Поле є необов'язковим.

(пункт 3.2 глави 3 розділу IV у редакції наказу Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 04.03.2020 р. N 129)

3.3. Поле "certs".

3.3.1. Поле "certs" містить сертифікат шифрування відправника та додатково може містити пов'язані з ним кваліфіковані сертифікати відкритих ключів для побудови шляху сертифікації від довіреного "кореня". Сертифікати розміщуються в такому порядку: першим (з найменшим індексом) розміщується кваліфікований сертифікат відкритого ключа вищого рівня (кореневий), останнім (з найбільшим індексом) розміщується сертифікат шифрування відправника, який було застосовано для статичного механізму.

(підпункт 3.3.1 пункту 3.3 глави 3 розділу IV у редакції наказу
 Адміністрації Державної служби спеціального зв'язку та захисту
 інформації України від 04.03.2020 р. N 129)

3.3.2. Поле "certs" має такий формат (RFC 3852, RFC 5652):

CertificateSet ::= SET OF CertificateChoices

CertificateChoices ::= CHOICE {

 

certificate

Certificate,

 

v2AttrCert

[2] IMPLICIT AttributeCertificateV2,

 

other

[3] IMPLICIT OtherCertificateFormat },

OtherCertificateFormat ::= SEQUENCE {

 

otherCertFormat

OBJECT IDENTIFIER,

 

otherCert

ANY DEFINED BY otherCertFormat },

AttributeCertificateV2 ::= AttributeCertificate.

Поле "v2AttrCert" ("AttributeCertificate") має такий формат:

AttributeCertificate ::= SEQUENCE {

 

acinfo

AttributeCertificateInfo,

 

signatureAlgorithm

AlgorithmIdentifier,

 

signatureValue

BIT STRING },

AttributeCertificateInfo ::= SEQUENCE {

 

version

AttCertVersion -- version is v2,

 

holder

Holder,

 

issuer

AttCertIssuer,

 

signature

AlgorithmIdentifier,

 

serialNumber

CertificateSerialNumber,

 

attrCertValidityPeriod

AttCertValidityPeriod,

 

attributes

SEQUENCE OF Attribute,

 

issuerUniqueID

UniqueIdentifier OPTIONAL,

 

extensions

Extensions OPTIONAL },

AttCertVersion ::= INTEGER { v2(1) },

Holder ::= SEQUENCE {

 

baseCertificateID

[0] IssuerSerial OPTIONAL,

 

-- the issuer and serial number of the holder's Public Key Certificate

 

entityName

[1] GeneralNames OPTIONAL,

 

-- the name of the claimant or role

 

objectDigestInfo

[2] ObjectDigestInfo OPTIONAL

 

-- used to directly authenticate the holder, for example, an executable },

ObjectDigestInfo ::= SEQUENCE {

 

digestedObjectType

ENUMERATED {

 

 

publicKey (0),

 

 

 

publicKeyCert (1),

 

 

 

otherObjectTypes (2) },

 

 

-- otherObjectTypes MUST NOT be used in this profile

 

otherObjectTypeID

OBJECT IDENTIFIER OPTIONAL,

 

digestAlgorithm

AlgorithmIdentifier,

 

objectDigest

BIT STRING },

AttCertIssuer ::= CHOICE {

 

v1Form

GeneralNames,

 

-- MUST NOT be used in this profile

 

v2Form

[0] V2Form -- v2 only },

V2Form ::= SEQUENCE {

 

issuerName

GeneralNames OPTIONAL,

 

baseCertificateID

[0] IssuerSerial OPTIONAL,

 

objectDigestInfo

[1] ObjectDigestInfo OPTIONAL

 

-- issuerName MUST be present in this profile baseCertificateID and

 

-- objectDigestInfo MUST NOT be present in this profile

},

 

 

IssuerSerial ::= SEQUENCE {

 

issuer

GeneralNames,

 

serial

CertificateSerialNumber,

 

issuerUID

UniqueIdentifier OPTIONAL

},

 

 

AttCertValidityPeriod ::= SEQUENCE {

 

notBeforeTime

GeneralizedTime,

 

notAfterTime

GeneralizedTime

}.

 

 

3.4. Поле "crls".

3.4.1. Поле "crls" містить набір списків відкликаних сертифікатів (CRL). Набір CRL містить інформацію, достатню для того, щоб визначити, чи є сертифікати в полі "certs" чинними. Послідовність розміщення CRL у полі "crls" повинна відповідати послідовності розміщення сертифікатів у наборі "certs". Наявність списків відкликаних сертифікатів дає змогу одержувачу визначити чинність сертифіката шифрування відправника на момент формування захищених даних без необхідності звернення до зовнішніх джерел розміщення CRL.

(підпункт 3.4.1 пункту 3.4 глави 3 розділу IV у редакції наказу
 Адміністрації Державної служби спеціального зв'язку та захисту
 інформації України від 04.03.2020 р. N 129)

3.4.2. Поле "crls" має такий формат (RFC 3852, RFC 5652):

RevocationInfoChoices ::= SET OF RevocationInfoChoice

RevocationInfoChoice ::= CHOICE {

 

crl

CertificateList,

 

other

[1] IMPLICIT OtherRevocationInfoFormat },

OtherRevocationInfoFormat ::= SEQUENCE {

 

otherRevInfoFormat

OBJECT IDENTIFIER,

 

otherRevInfo

ANY DEFINED BY otherRevInfoFormat }.

"CertificateList" може містити повний (Full) CRL або частковий (Delta) CRL, формат якого відповідає Вимогам до формату списку відкликаних сертифікатів.

3.5. Поле "encryptedContentInfo".

Поле "encryptedContentInfo" містить зашифроване повідомлення.

Поля структури "encryptedContentInfo":

поле "contentType" вказує на тип даних;

поле "contentEncryptionAlgorithm" визначає криптографічний алгоритм шифрування даних. Для усіх одержувачів повідомлення повинні застосовуватися однаковий алгоритм, параметри алгоритму шифрування даних та однаковий ключ шифрування даних;

поле "encryptedContent" містить дані, які зашифровані з використанням ключа шифрування даних КШД та алгоритму, що визначений у полі "contentEncryptionAlgorithm". Поле є необов'язковим. У разі відсутності поля "encryptedContent" вважається, що зашифровані дані подаються в інший спосіб.

3.6. Поле "Unprotected Attrs" містить набір атрибутів, що не зашифровуються разом з повідомленням.

3.7. Поле "recipientInfos" містить інформацію про одержувачів.

3.7.1. Структура "RecipientInfo" має такий формат:

RecipientInfo ::= CHOICE {

 

kari

[1] KeyAgreeRecipientInfo}.

3.7.2. Тип "KeyAgreeRecipientInfo" призначений для кодування даних, що використовуються одержувачем у протоколі управління ключами.

3.7.3. Структура "KeyAgreeRecipientInfo" має такий формат:

KeyAgreeRecipientInfo ::= SEQUENCE {

 

version

CMSVersion,

 

originator

[0] EXPLICIT OriginatorIdentifierOrKey,

 

ukm

[1] EXPLICIT UserKeyingMaterial OPTIONAL,

 

keyEncryptionAlgorithm

KeyEncryptionAlgorithmIdentifier,

 

recipientEncryptedKeys

RecipientEncryptedKeys},

OriginatorIdentifierOrKey ::= CHOICE {

 

issuerAndSerialNumber

IssuerAndSerialNumber,

 

subjectKeyIdentifier

[0] SubjectKeyIdentifier,

 

originatorKey

[1] OriginatorPublicKey},

OriginatorPublicKey ::= SEQUENCE {

 

algorithm

AlgorithmIdentifier,

 

publicKey

BIT STRING},

UserKeyingMaterial ::= OCTET STRING,

KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier,

AlgorithmIdentifier ::= SEQUENCE {

 

algorithm

OBJECT IDENTIFIER,

 

parameters

ANY DEFINED BY algorithm},

RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey,

RecipientEncryptedKey ::= SEQUENCE {

 

rid

KeyAgreeRecipientIdentifier,

 

encryptedKey

EncryptedKey},

EncryptedKey ::= OCTET STRING,

KeyAgreeRecipientIdentifier ::= CHOICE {

 

issuerAndSerialNumber

IssuerAndSerialNumber,

 

rKeyId

[0] IMPLICIT RecipientKeyIdentifier},

IssuerAndSerialNumber ::= SEQUENCE {

 

issuer

Name,

 

serialNumber

CertificateSerialNumber},

CertificateSerialNumber ::= INTEGER.

3.7.4. Поля структури "KeyAgreeRecipientInfo":

1) поле "Version" визначає номер версії синтаксису, який повинен мати значення "3";

2) поле "originator" містить ідентифікаційні дані відправника. Тип цих даних залежить від механізму (протоколу) узгодження ключів;

3) ідентифікаційні дані відправника:

під час застосування статичного механізму узгодження ключів Діффі-Геллмана як ідентифікатора відправника повинні використовуватися ім'я емітента сертифіката (надавача електронних довірчих послуг) та серійний номер сертифіката відкритого ключа відправника "issuerAndSerialNumber" або ідентифікатор відкритого ключа відправника "subjectKeyIdentifier";

(абзац другий підпункту 3 підпункту 3.7.4 пункту 3.7 глави 3 розділу IV
 із змінами, внесеними згідно з наказом Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 04.03.2020 р. N 129)

під час застосування динамічного механізму узгодження ключів Діффі-Геллмана як ідентифікаційних даних відправника застосовується його відкритий сеансовий ключ (маркер), що генерується відправником та міститься в полі "originatorKey".

абзац четвертий підпункту 3 підпункту 3.7.4 пункту 3.7 глави 3 розділу IV виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129)

абзац п'ятий підпункту 3 підпункту 3.7.4 пункту 3.7 глави 3 розділу IV виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129)

Абзац шостий підпункту 3 підпункту 3.7.4 пункту 3.7 глави 3 розділу IV виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129)

Абзац сьомий підпункту 3 підпункту 3.7.4 пункту 3.7 глави 3 розділу IV виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129)

абзац восьмий підпункту 3 підпункту 3.7.4 пункту 3.7 глави 3 розділу IV виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129)

Абзац дев'ятий підпункту 3 підпункту 3.7.4 пункту 3.7 глави 3 розділу IV виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129,
у зв'язку з цим абзаци десятий - двадцятий вважати
 відповідно абзацами четвертим - чотирнадцятим)

Під час застосування динамічного механізму узгодження ключів у групі точок еліптичної кривої поле "algorithm" поля "originatorKey" для алгоритму цифрового підпису ДСТУ 4145-2002 може мати такі значення:

для поліноміального базису:

Dstu4145WithDstu7564(256)pb OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root (2) security(1) cryptography(1) ua-pki (1) alg(1) asym (3) Dstu4145WithDstu7564(6) 256(1) pb(1)};

Dstu4145WithGost34311(pb) OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) ua-pki (1) alg(1) asym (3) Dstu4145WithGost34311(1) pb(1)};

для оптимального нормального базису:

Dstu4145WithDstu7564(256)onb OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root (2) security(1) cryptography(1) ua-pki (1) alg(1) asym (3) Dstu4145WithDstu7564(6) 256(1) оnb(2)};

Dstu4145WithGost34311onb OBJECT IDENTIFIER ::= { iso(1) member-body(2) Ukraine(804) root (2) security(1) cryptography(1) ua-pki (1) alg(1) asym (3) Dstu4145WithGost34311(1) onb(2)}.

Параметри алгоритму поля "algorithm" в "originatorKey" повинні бути ASN.1 NULL.

Поле "originatorKey publicKey" повинно містити відкритий ключ відправника (маркер), що має такий формат:

PublicKey:: = OCTET STRING, що інкапсулюється в BIT STRING.

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

(позиція 3 підпункту 3.7.4 пункту 3.7 глави 3 розділу IV у редакції
 наказу Адміністрації Державної служби спеціального зв'язку та захисту
 інформації України від 21.12.2017 р. N 712)

4) поле "ukm" (User Keying Material - матеріал щодо ключа користувача) містить додаткову інформацію, яку відправник надає одержувачу під час виконання протоколу узгодження ключа Діффі-Геллмана. Поле "ukm" використовується з метою забезпечення можливості формування різних значень узгоджених ключів у різний час суб'єктами, що використовують ті самі пари ключів (статичні ключі).

Реалізації цих Вимог повинні обробляти "KeyAgreeRecipientInfo", що містить поле "ukm".

Абзац третій підпункту 4 підпункту 3.7.4 пункту 3.7 глави 3 розділу IV виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129,
у зв'язку з цим абзац четвертий вважати відповідно абзацом третім)

У разі застосування динамічного механізму узгодження ключів у групі точок еліптичної кривої (ECDH) у поле "ukm" вноситься значення "entityUInfo" (кодоване як OCTET STRING), яке генерується відправником і використовується в структурі "SharedInfo". Якщо "entityUInfo" задано, то воно повинно мати довжину 512 бітів (64 байти). Параметр "entityUInfo" визначається у позиції 6 пункту 6.4 глави 6 розділу V цих Вимог;

5) поле "keyEncryptionAlgorithm" визначає ідентифікатор протоколу узгодження ключа (Key Agreement Algorithm);

6) поле "recipientEncryptedKeys" містить ідентифікатор одержувача та зашифрований ключ КШД для одного або декількох одержувачів;

7) поле "KeyAgreeRecipientIdentifier" визначає ідентифікаційні дані сертифіката одержувача, який використовується відправником при обчисленні узгодженого ключа КШК. Поле може бути типу "issuerAndSerialNumber" або "RecipientKeyIdentifier".

"rKeyId" - альтернатива типу "RecipientKeyIdentifier", має таке значення:

RecipientKeyIdentifier ::= SEQUENCE {

 

subjectKeyIdentifier

SubjectKeyIdentifier,

 

date

GeneralizedTime OPTIONAL,

 

other

OtherKeyAttribute OPTIONAL };

SubjectKeyIdentifier ::= OCTET STRING;

"subjectKeyIdentifier" - ідентифікатор відкритого ключа одержувача;

"date" - необов'язкове поле. Зміст та використання цього поля не регламентується у межах цього документа;

"other" - необов'язкове поле. Зміст та використання цього поля не регламентується у межах цього документа.

Реалізації цих Вимог повинні підтримувати обидві вищевказані альтернативи для визначення сертифіката одержувача;

8) поле "encryptedKey" містить симетричний ключ КШД, зашифрований на узгодженому ключі КШК.

3.7.5. Особливості синтаксису структури "KeyAgreeRecipientInfo":

1) ідентифікатор протоколу узгодження ключа вказується в полі "EnvelopedData RecipientInfos KeyAgreeRecipientInfo":

KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

AlgorithmIdentifier ::= SEQUENCE {

algorithm

OBJECT IDENTIFIER,

parameters

ANY DEFINED BY algorithm}.

Поле "algorithm" повинно містити об'єктний ідентифікатор одного з протоколів узгодження ключа, що зазначені нижче, а поле "parameters" повинно містити ідентифікатор алгоритму шифрування ключа КШК (KeyWrapAlgorithm):

parameters ::= KeyWrapAlgorithm;

KeyWrapAlgorithm ::= AlgorithmIdentifier;

2) об'єктний ідентифікатор протоколу узгодження ключа визначає:

ZZ-функцію обчислення спільного секрету (ZZ) для визначеного протоколу;

KDF-функцію (Key Derivation Function), функцію формування ключа шифрування ключа КШК (KM, KeyingMaterial) на основі спільного секрету та додаткової інформації для заданого алгоритму "KeyWrapAlgorithm";

3) підпункт 3 підпункту 3.7.5 пункту 3.7 глави 3 розділу IV виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129,
у зв'язку з цим підпункт 4 вважати підпунктом 3)

3) об'єктні ідентифікатори (OID) протоколу узгодження ключа в групі точок еліптичної кривої (ECDH):

з використанням геш-функції ДСТУ 7564:2014 "Інформаційні технології. Криптографічний захист інформації. Функція гешування" (далі - ДСТУ 7564:2014):

алгоритм з кофакторним множенням:

id-dhSinglePass-cofactorDH- Dstu7564kdf-scheme OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) ua-pki (1) alg (1) asym (3) dhSinglePass-cofactorDH- Dstu7564kdf (7) };

алгоритм без кофакторного множення:

id-dhSinglePass-stdDH- Dstu7564kdf-scheme OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) ua-pki (1) alg (1) asym (3) dhSinglePass- stdDH- Dstu7564kdf (8) };

з використанням геш-функції ГОСТ 34.311-95:

алгоритм з кофакторним множенням:

id-dhSinglePass-cofactorDH-gost34311kdf-scheme OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) ua-pki (1) alg (1) asym (3) dhSinglePass-cofactorDH-gost34311kdf (4) };

алгоритм без кофакторного множення:

id-dhSinglePass-stdDH-gost34311kdf-scheme OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) ua-pki (1) alg (1) asym (3) dhSinglePass- stdDH-gost34311kdf (5) };

з використанням відповідно до ДСТУ ISO/IEC 10118-3:2005, ISO/IEC 10118-3 геш-функцій SHA-1 (тільки для розшифрування даних, шифрування яких здійснювалось до 01 січня 2014 року), SHA-224, SHA-256, SHA-384, SHA-512:

алгоритми з кофакторним множенням:

"id-dhSinglePass-cofactorDH-sha1kdf-scheme";

"id-dhSinglePass-cofactorDH-sha224kdf-scheme";

"id-dhSinglePass-cofactorDH-sha256kdf-scheme";

"id-dhSinglePass-cofactorDH-sha384kdf-scheme";

"id-dhSinglePass-cofactorDH-sha512kdf-scheme";

алгоритми без кофакторного множення:

"id-dhSinglePass-stdDH-sha1kdf-scheme";

"id-dhSinglePass-stdDH-sha224kdf-scheme";

"id-dhSinglePass-stdDH-sha256kdf-scheme";

"id-dhSinglePass-stdDH-sha384kdf-scheme";

"id-dhSinglePass-stdDH-sha512kdf-scheme";

dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) tc68(133) country(16) x9(840) x9-63(63) chemes(0) 3};

dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) certicom(132) schemes(1) 14 0 };

dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) certicom(132) schemes(1) 14 1 };

dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) certicom(132) schemes(1) 14 2 };

dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) certicom(132) schemes(1) 14 3 };

dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) tc68(133) country(16) x9(840) x9-63(63) chemes(0) 2};

dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) certicom(132) schemes(1) 11 0 };

dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) certicom(132) schemes(1) 11 1 };

dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) certicom(132) schemes(1) 11 2 };

dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) certicom(132) schemes(1) 11 3 };

протоколи узгодження ключа, визначені ідентифікаторами згідно з позицією 3 підпункту 3.7.5 пункту 3.7 глави 3 розділу IV цих Вимог, застосовуються як для статичного, так і для динамічного механізму узгодження ключа. При цьому ознакою динамічного механізму є не нульове значення поля "originatorKey" відповідно до абзацу третього позиції 3 підпункту 3.7.4 пункту 3.7 глави 3 розділу IV цих Вимог;

(абзац тридцять п'ятий підпункту 3 підпункту 3.7.5 пункту 3.7 глави 3 розділу IV
 із змінами, внесеними згідно з наказом Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 04.03.2020 р. N 129)

протоколи узгодження ключа, а саме ZZ-функція та KDF-функція, у групі точок еліптичної кривої визначено у розділі V цих Вимог.

(позиція 3 підпункту 3.7.5 пункту 3.7 глави 3 розділу IV у редакції
 наказу Адміністрації Державної служби спеціального зв'язку та захисту
 інформації України від 21.12.2017 р. N 712)

V. Протокол узгодження ключа Діффі-Геллмана

1. Призначення та порядок використання протоколу узгодження ключа

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

У цих Вимогах визначено протокол узгодження ключа Діффі-Геллмана у групі точок еліптичної кривої (ECDH).

(абзац третій глави 1 розділу V у редакції наказу Адміністрації Державної
 служби спеціального зв'язку та захисту інформації України від 04.03.2020 р. N 129)

2. Протокол узгодження ключа Діффі-Геллмана, який виконує відправник:

отримати параметри відкритого ключа одержувача (із сертифіката відкритого ключа);

порівняти параметри відкритого ключа відправника з параметрами відкритого ключа одержувача у разі наявності сертифіката відкритого ключа відправника;

установити статичний механізм узгодження ключа у разі еквівалентності параметрів, в іншому випадку встановити динамічний механізм узгодження ключа та виконати обчислення ключової пари, використовуючи алгоритм та відповідні параметри ключа одержувача;

виконати обчислення спільного секрету (ZZ);

(абзац п'ятий глави 2 розділу V із змінами, внесеними згідно з
 наказом Адміністрації Державної служби спеціального зв'язку
 та захисту інформації України від 04.03.2020 р. N 129)

виконати обчислення ключа шифрування ключа КШК (KDF - Key Derivation Function).

(глава 2 розділу V у редакції наказу Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 21.12.2017 р. N 712)

3. Протокол узгодження ключа Діффі-Геллмана, що виконується одержувачем:

завантажити сертифікат і особистий ключ одержувача та отримати параметри ключової пари відправника;

отримати ASN.1 "EnvelopedData";

на основі аналізу "EnvelopedData" визначити механізм узгодження ключа. Ознакою динамічного механізму є ненульове значення поля "originatorKey" відповідно до позиції 3 підпункту 3.7.4 пункту 3.7 глави 3 розділу IV цих Вимог;

якщо механізм статичний, отримати сертифікат відправника. Сертифікат відправника може міститися у структурі "OriginatorInfo", в іншому випадку він має бути отриманий одержувачем із його сховища сертифікатів за даними з поля "OriginatorIdentifierOrKey";

отримати із сертифіката відправника відкритий ключ;

отримати параметри відкритого ключа відправника;

порівняти параметри ключа пари одержувача з параметрами відкритого ключа відправника;

нееквівалентність параметрів означає помилку. Необхідно припинити оброблення;

у разі еквівалентності параметрів перейти до наступного кроку цього протоколу;

якщо механізм динамічний, отримати динамічний відкритий ключ відправника зі структури "EnvelopedData";

виконати обчислення спільного секрету (ZZ);

(абзац дванадцятий глави 3 розділу V із змінами, внесеними
 згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129)

виконати обчислення ключа шифрування ключа КШК (KDF - Key Derivation Function).

4. Параметри протоколу узгодження ключа називають "загальносистемними параметрами" ("Domain Parameters"). У цих Вимогах загальносистемні параметри не є об'єктом ASN.1 структури "захищені дані" ("EnvelopedData"), а використовуються виключно у внутрішніх процедурах для визначення механізму узгодження ключів (динамічний або статичний) та обчислення спільного секрету (ZZ-функція). Тому наведені у цьому пункті ASN.1 структури мають рекомендаційний характер.

4.1. Пункт 4.1 глави 4 розділу V виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129,
у зв'язку з цим пункти 4.2, 4.3 вважати відповідно пунктами 4.1, 4.2)

4.1. Параметри протоколу узгодження ключа в групі точок еліптичної кривої:

1) параметри алгоритму в групі точок еліптичної кривої (ECDH) можуть бути визначені такою ASN.1 структурою:

ECDHParameters ::= SEQUENCE {

q

INTEGER,

FR

INTEGER,

a

INTEGER,

b

INTEGER,

G

ECPoint,

n

INTEGER,

h

INTEGER,

dke

OCTET STRING OPTIONAL},

де q - довжина поля (field size) у бітах, що дорівнює степеню основного поля (m);

FR - індикатор представлення поля або зведений поліном (reduction polynomial) (алгоритм обчислення наведено у позиції 4 пункту 4.2 глави 4 розділу V цих Вимог);

a та b - два елементи поля, які визначають криву (коефіцієнти рівняння еліптичної кривої);

G - базова точка еліптичної кривої (Base Point) з координатами (xG, yG);

n - порядок базової точки (order of the point) G;

h - кофактор, що еквівалентний порядку кривої, поділеному на n (для еліптичних кривих з ДСТУ 4145-2002 h = 2 (якщо параметр еліптичної кривої а = 1) або h = 4 (якщо параметр еліптичної кривої а = 0));

2) зображення точки еліптичної кривої ECPoint.

Значенням ECPoint повинен бути рядок байтів, який є закодованою точкою еліптичної кривої:

ECPoint ::= OCTET STRING;

3) процедура кодування точки (Point-to-Octet-String Conversion):

вхідними даними є точка еліптичної кривої P = (Xp, Yp), яка не є нульовою;

вихідними даними є рядок байтів РО - зображення у нестисненому форматі (uncompressed form) точки Р як рядка байтів;

байт РС = 0 х 04 (ознака нестисненого формату);

результуючий рядок байтів РО повинен бути об'єднанням (конкатенацією): PO = PC || Xp || Yp.

Рядком байтів для представлення нульового елемента групи точок еліптичної кривої O = (0, 0) (infinity) повинен бути один нульовий байт: PO = 0 х 00;

4) процедура обчислення FR:

поліномом є примітивний многочлен, що наведений у таблиці 1 ДСТУ 4145-2002. Значенням зведеного полінома є ціле число як рядок бітів;

для оптимального нормального базису FR = 0;

обчислення значення FR для поліноміального базису, де: m - ступінь основного поля, ks[len] - масив цілих чисел ks[0] = k3, ks[1] = k2, ks[2] = k1, що є ступенями примітивного многочлена. Поліном має вигляд x ^ m + x ^ k3 + x ^ k2 + x ^ k1 + 1, де: m > k3 > k2 > k1 >= 1, len - довжина масиву ks, для тричлена (trinomial) len = 1 та для п'ятичлена (pentanomial) len = 3, якщо len = 1, то k2 = k1 = 0;

для визначення FR як рядка бітів необхідно:

встановити FR = 1 (встановити біт 0);

встановити у FR біт m та відповідно біти k1, k2, k3;

5) при визначенні механізму узгодження ключів повинна виконуватися операція порівняння загальносистемних параметрів "ECDHParameters". Якщо загальносистемні параметри еквівалентні, то застосовується статичний механізм узгодження ключів, в інших випадках - динамічний.

Порівнюватися повинні параметри структури "ECDHParameters", яка наведена у позиції 1 пункту 4.2 глави 4 розділу V цих Вимог. Порівняння повинно виконуватися покомпонентно (еквівалентність параметрів q, FR) або як порівняння масивів байтів DER-кодованої структури "ECDHParameters".

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

dke OCTET STRING.

Для ДСТУ 4145-2002 ДКЕ кодується в упакованому форматі.

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

Спосіб представлення ДКЕ N 1 повинен відповідати вимогам до технічних засобів, процесів їх створення, використання та функціонування у складі інформаційно-телекомунікаційних систем під час надання кваліфікованих електронних довірчих послуг, встановлених у нормативно-правових актах Мін'юсту та Адміністрації Держспецзв'язку.

(пункт 4.2 глави 4 розділу V у редакції наказу Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України України від 04.03.2020 р. N 129)

5. Обчислення спільного секрету

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

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

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

Процедура обчислення спільного секрету у цих Вимогах називається ZZ-функцією. Результатом обчислення спільного секрету є елемент базового поля (ZZ).

5.1. Пункт 5.1 глави 5 розділу V виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129,
у зв'язку з цим пункти 5.2, 5.3 вважати відповідно пунктами 5.1, 5.2)

5.1. Обчислення спільного секрету в групі точок еліптичної кривої (ECDH).

Обчислення спільного секрету з кофакторним множенням у групі точок еліптичної кривої ґрунтується на ДСТУ ISO/IEC 11770-3:2015.

Відправником обчислюється значення точки K еліптичної кривої з координатами (xk, yk): K = da * h * Pb, далі - формула (1), а одержувачем K = db * h * Pa, далі - формула (2),

де:

da - особистий ключ відправника;

Pa - відкритий ключ відправника;

db - особистий ключ одержувача;

Pb - відкритий ключ одержувача;

h - кофактор (для еліптичних кривих з ДСТУ 4145-2002 h = 2 або h = 4).

Спільним секретом є координата xk точки K : Z = xk, де Z - спільний секрет як елемент поля, в якому виконується обчислення.

У разі обчислення спільного секрету без кофакторного множення значення кофактора у формулах (1) та (2) приймають рівним одиниці (h = 1).

Виконання операцій над точками еліптичної кривої, зображення даних, перевірка правильності загальних параметрів алгоритму та правильності ключів здійснюються згідно з ДСТУ 4145-2002.

Вибір основного поля повинен здійснюватися згідно з пунктом 7.1 розділу 7 ДСТУ 4145-2002 або за узгодженням з Адміністрацією Держспецзв'язку України.

5.2. Перетворення елемента поля Z на рядок байтів ZZ.

Для використання у функціях формування ключа (KDF-функціях) спільного секрету Z, отриманого згідно з пунктом 5.1 глави 5 розділу V та абзацом четвертим пункту 5.2 глави 5 розділу V цих Вимог, необхідно перетворити елемент поля Z на рядок байтів ZZ (Field-Element-to-Octet-String Conversion). Таке перетворення повинно виконуватися так.

Нехай Z є елементом поля Fq чи поля F(2m). Результатом перетворення є рядок байтів ZZ довжини L.

Якщо Z є елементом поля Fq, воно є додатним цілим числом, тобто двійковим (бітовим) рядком (bit string). У цьому випадку L дорівнює значенню log(q)/8, заокругленому в більшу сторону до найближчого цілого числа, де log - логарифм за основою 2. Якщо Z є елементом поля F(2m), воно є двійковим (бітовим) рядком довжини m, що є зображенням додатного цілого числа у системі числення за основою 2. У цьому випадку L дорівнює значенню m/8, заокругленому в більшу сторону до найближчого цілого числа. Позначимо ціле число від Z як ZI.

Виконати перетворення цілого ZI на рядок байтів ZZ у форматі Big-Endian. Одержаний рядок ZZ повинен мати довжину L байтів; під час перетворення старші нульові байти числа ZI не повинні відкидатися. Перетворення цілого ZI на рядок байтів ZZ у форматі Little-Endian наведено у підпункті 3.14.2 пункту 3.14 розділу III Вимог до формату посиленого сертифіката відкритого ключа. Формат Big-Endian має зворотний порядок байтів щодо формату Little-Endian.

У разі прямого розміщення байтів (Big-Endian) старший повинен зберігатися за найменшою адресою (як байт з найменшим індексом байт-масиву), у разі зворотного розміщення (Little-Endian) - за найбільшою, тобто за найменшою адресою повинен розміщуватися молодший байт.

Приклади перетворення елемента поля на рядок байтів у форматі Big-Endian, обчислення спільного секрету ZZ розміщуються на офіційному веб-сайті Державної служби спеціального зв'язку та захисту інформації України.

(абзац сьомий пункту 5.2 глави 5 розділу IV із змінами, внесеними
 згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129)

(пункт 5.2 глави 5 розділу V у редакції наказу
 Адміністрації Державної служби спеціального зв'язку та захисту
 інформації України від 21.12.2017 р. N 712)

6. Використання функції формування ключа КШК (KDF-функція)

6.1. KDF-функція призначена для формування ключа шифрування ключа (КШК) на основі спільного секрету ZZ та іншої інформації.

6.2. Кроки виконання KDF-функції:

на основі спільного секрету ZZ та іншої інформації сформувати ключовий матеріал (КМ);

на основі ключового матеріалу створити ключ шифрування ключа КШК для заданого алгоритму шифрування.

6.3. Пункт 6.3 глави 6 розділу V виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129,
у зв'язку з цим пункт 6.4 вважати пунктом 6.3)

6.3. Використання KDF-функції в групі точок еліптичної кривої (ECDH):

1) KDF-функція в групі точок еліптичної кривої (ECDH) ґрунтується на ДСТУ ISO/IEC 11770-3:2015;

(підпункт 1 пункту 6.3 глави 6 розділу V із змінами, внесеними
 згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 21.12.2017 р. N 712
,
у редакції наказу Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129)

2) формування ключового матеріалу KM:

KM = H (ZZ || counter || SharedInfo),

де KM - ключовий матеріал (рядок байтів), довжина якого залежить від алгоритму H;

H - геш-функція, яка визначається ідентифікаторами протоколу узгодження, що визначені у позиції 3 підпункту 3.7.5 пункту 3.7 глави 3 розділу IV цих Вимог;

(абзац четвертий підпункту 2 пункту 6.3 глави 6 розділу V із змінами,
 внесеними згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129)

ZZ - спільний секрет, обчислений відповідно до пункту 5.3 глави 5 розділу V цих Вимог;

"counter" - 32-бітне число, яке представлено як бітовий вектор (чотири байти), записаний у зворотному порядку. Початковим значенням "counter" є 1 (одиниця) для будь-якого ZZ, а його бітовий вектор є "00 00 00 01" (hex); значення counter збільшується на одиницю з кожним циклом виконання функції формування ключового матеріалу KM під час обчислення ключа КШК згідно з позицією 4 пункту 6.3 глави 6 розділу V цих Вимог;

SharedInfo - DER-кодована ASN.1 структура;

|| - означає операцію конкатенації;

3) структура "SharedInfo":

SharedInfo ::= SEQUENCE {

 

keyInfo

AlgorithmIdentifier,

 

entityUInfo

[0] EXPLICIT OCTET STRING OPTIONAL,

 

suppPubInfo

[2] EXPLICIT OCTET STRING};

(підпункт 3 пункту 6.3 глави 6 розділу V у редакції наказу
 Адміністрації Державної служби спеціального зв'язку та захисту
 інформації України від 21.12.2017 р. N 712)

4) поля структури "SharedInfo":

"algorithm" - ідентифікатор алгоритму ключа шифрування ключа (KeyWrapAlgorithm), на якому повинен бути зашифрований ключ шифрування повідомлення (даних). Параметри алгоритму повинні бути NULL (ASN.1 NULL);

"entityUInfo" - випадковий рядок, який генерує відправник. У CMS це значення розміщується в полі "ukm" ("UserKeyingMaterial") (закодоване як OCTET STRING) структури "KeyAgreeRecipientInfo". Довжина "entityUInfo повинна бути 512 бітів (64 байти);

(абзац третій підпункту 4 пункту 6.3 глави 6 розділу V із змінами,
 внесеними згідно з
наказами Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 21.12.2017 р. N 712
,
від 04.03.2020 р. N 129)

"suppPubInfo" - довжина сформованого ключа КШК у бітах, представлена як бітовий вектор (чотири байти) 32-бітного числа. Наприклад, ключ 192 біти повинен бути представлений як бітовий вектор "00 00 00 C0" (hex);

(абзац четвертий підпункту 4 пункту 6.3 глави 6 розділу V із змінами,
 внесеними згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129)

5) якщо параметр "entityUInfo" як необов'язковий не буде використовуватися, то у випадках А та Б для різних повідомлень буде формуватися один і той самий ключ шифрування КШК. Для уникнення цього у разі статичного механізму вимагається (а у разі динамічного - рекомендується) генерувати випадкове значення entityUInfo для кожного повідомлення та використовувати під час формування КШК;

(підпункт 5 пункту 6.3 глави 6 розділу V із змінами, внесеними
 згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 21.12.2017 р. N 712)

6) приклади обчислення ключа КШК в групі точок еліптичної кривої розміщуються на офіційному веб-сайті Державної служби спеціального зв'язку та захисту інформації України.

(підпункт 6 пункту 6.3 глави 6 розділу V у редакції наказу
 Адміністрації Державної служби спеціального зв'язку та захисту
 інформації України від 21.12.2017 р. N 712)

VI. Алгоритм захисту ключа шифрування даних "KeyWrapAlgorithm"

1. Алгоритм захисту ключа шифрування даних "KeyWrapAlgorithm" ґрунтується на стандарті ДСТУ 7624:2014, що позначається як "Dstu7624Wrap", або ДСТУ ГОСТ 28147:2009, що позначається як "GOST28147Wrap".

Алгоритм криптографічного перетворення за ДСТУ 7624:2014 застосовується у режимі "Калина-256/256-CFB-256" (гамування зі зворотним зв'язком за шифртекстом відповідно до розділу 8 ДСТУ 7624:2014).

Алгоритм криптографічного перетворення за ДСТУ ГОСТ 28147:2009 застосовується у режимі CFB (гамування зі зворотним зв'язком відповідно до розділу 4 ДСТУ ГОСТ 28147:2009).

2. Призначення алгоритму "KeyWrapAlgorithm"

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

3. Ідентифікатор алгоритму захисту ключа шифрування даних "KeyWrapAlgorithm" вказується як параметр поля "EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm" згідно з позицією 1 підпункту 3.7.5 пункту 3.7 глави 3 розділу IV цих Вимог.

4. Ключ узгодження КШК формується за алгоритмом ECDH:

(абзац перший глави 4 розділу VI із змінами, внесеними
 згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129)

KeyWrapAlgorithm ::= AlgorithmIdentifier.

5. Синтаксис "KeyWrapAlgorithm"

5.1. Алгоритм "KeyWrapAlgorithm", що ґрунтується на стандарті ДСТУ 7624:2014, має такий синтаксис:

Dstu7624WrapParameters ::= CHOICE {

 

NULL,

 

 

parameters

Dstu7624Parameters},

Dstu7624Parameters::= SEQUENCE {

 

iv

OCTET STRING (SIZE (32))},

де "iv" - вектор ініціалізації, що обирається випадково.

5.2. Алгоритм "KeyWrapAlgorithm", що ґрунтується на стандарті ДСТУ ГОСТ 28147:2009, має такий синтаксис:

GOST28147WrapParameters ::= CHOICE {

 

NULL,

 

 

parameters

GOST28147Parameters},

GOST28147Parameters ::= SEQUENCE {

 

iv

OCTET STRING (SIZE (8)),

 

dke

OCTET STRING (SIZE (64)) },

де "iv" - вектор ініціалізації, що обирається випадково;

"dke" - довгостроковий ключовий елемент (ДКЕ) відповідно до ДСТУ ГОСТ 28147:2009.

6. Під час використання "Dstu7624Wrap" або "GOST28147Wrap" як алгоритму захисту ключа шифрування ключів КШК у структурі "захищені дані" ("EnvelopedData") параметри алгоритму повинні бути NULL.

Значення ДКЕ для алгоритму "GOST28147Wrap" повинно братися з відкритого ключа одержувача.

Використання "Dstu7624Wrap" або "GOST28147Wrap" з параметрами алгоритму, що не є NULL, не є предметом цих Вимог.

7. Поле "algorithm" повинно містити об'єктний ідентифікатор:

для алгоритму "Dstu7624Wrap":

id-dstu7624-wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) ua-pki (1) alg (1) sym (1) dstu7624 (3) wrap(11) };

для алгоритму "GOST28147Wrap":

id-gost28147-wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) ua-pki (1) alg (1) sym (1) gost28147(1) wrap(5) }.

8. Алгоритми "GOST28147Wrap" та "Dstu7624Wrap"

8.1. Усі структури, задіяні в процесах зашифрування (пункти 8.2, 8.5 глави 8 розділу VI цих Вимог) і розшифрування (пункти 8.3, 8.6 глави 8 розділу VI цих Вимог), повинні бути представлені у форматі Little-Endian.

8.2. Процес зашифрування (Key Wrap) алгоритму "GOST28147Wrap"

Вхідними даними процесу зашифрування є:

"dke" - довгостроковий ключовий елемент (ДКЕ);

"KEK" - ключ шифрування ключа (КШК);

"CEK" - ключові дані для зашифрування (в операції формування "захищені дані" - це ключ шифрування даних КШД).

Вихідними даними процесу зашифрування є "result" - зашифровані ключові дані.

Процес зашифрування виконується за такими етапами:

виконати ініціалізацію алгоритму вхідними даними "dke" та "KEK". Особливості ініціалізації щодо "dke" наведено у пункті 8.4 глави 8 розділу VI цих Вимог;

обчислити контрольну суму ключових даних "CEK". Контрольна сума ключових даних (позначена як "ICV") призначена для контролю правильності розшифрування зашифрованих ключових даних та обчислюється як імітовставка довжини 32 біти ("MAC32") згідно з розділом 5 ДСТУ ГОСТ 28147:2009.

Значення "dke" та ключ під час обчислення "KEK" беруться ті, що встановлені під час виконання етапів процесу зашифрування:

ICV = MAC32(CEK, dke, KEK) [4 байти];

виконати конкатенацію ключових даних з отриманою контрольною сумою:

CEKICV = CEK || ICV;

згенерувати випадкові 8 байтів як вектор ініціалізації (синхропосилка, позначено як "IV");

виконати зашифрування даних "CEKICV" алгоритмом ДСТУ ГОСТ 28147:2009 у режимі гамування зі зворотним зв'язком (GOST28147-CFB), використовуючи "dke" та ключ "KEK", встановлені на кроці 1, і вектор ініціалізації "IV", отриманий за результатами виконання позиції 4 цього пункту:

TEMP1 = GOST28147-CFB_encrypt(CEKICV, IV, dke, KEK).

Довжина вихідних даних "TEMP1" дорівнює довжині "CEKICV";

виконати конкатенацію:

TEMP2 = IV || TEMP1;

виконати реверсне перетворення порядку байтів TEMP2 так, що перший байт TEMP2 стає останнім байтом. Результат перетворення позначимо TEMP3;

зашифрувати TEMP3 алгоритмом ДСТУ ГОСТ 28147:2009 у режимі гамування зі зворотним зв'язком (GOST28147-CFB), використовуючи "dke" та ключ "KEK", встановлені під час виконання позиції 1 цього пункту, та вектор ініціалізації "IV1":

IV1 = 4a dd a2 2c 79 e8 21 05 (4a - молодший байт).

Результатом зашифрування алгоритмом GOST28147Wrap є:

result = GOST28147-CFB_encrypt(TEMP3, IV1, dke, KEK).

8.3. Процес розшифрування (Key Unwrap) алгоритму GOST28147Wrap

Вхідними даними процесу розшифрування є:

"result" - зашифровані ключові дані;

"dke" - довгостроковий ключовий елемент (ДКЕ);

"KEK" - ключ шифрування ключа (КШК).

Вихідними даними процесу розшифрування є:

"CEK" - ключові дані (в операції формування "захищені дані" - ключ шифрування даних КШД).

Процес розшифрування виконується за такими етапами:

виконати ініціалізацію алгоритму вхідними даними "dke" та "KEK". Особливості ініціалізації щодо "dke" наведено у пункті 8.4 глави 8 розділу VI цих Вимог;

виконати розшифрування "result" на алгоритмі ДСТУ ГОСТ 28147:2009 у режимі гамування зі зворотним зв'язком (GOST28147-CFB), використовуючи "dke" та ключ "KEK", встановлені під час виконання етапу, зазначеного у позиції 1 цього пункту, та вектор ініціалізації "IV1":

IV1 = 4a dd a2 2c 79 e8 21 05 (4a - молодший байт);

TEMP3 = GOST28147-CFB_decrypt(result, IV1, dke, KEK);

виконати реверсне перетворення порядку байтів TEMP3 так, що перший байт TEMP3 стає останнім байтом. Результат перетворення позначимо TEMP2;

відокремити складові у TEMP2 (перші 8 байтів - IV, усі інші - TEMP1):

TEMP2 = IV || TEMP1;

виконати розшифрування TEMP1 алгоритмом ДСТУ ГОСТ 28147:2009 у режимі гамування зі зворотним зв'язком (GOST28147-CFB), використовуючи "dke" та ключ "KEK", встановлені під час виконання етапу, зазначеного у позиції 1 цього пункту, та вектор ініціалізації "IV", отриманий за результатами виконання етапу, зазначеного у позиції 3 цього пункту:

CEKICV = GOST28147-CFB_decrypt(TEMP1, IV, dke, KEK);

відокремити складові у CEKICV (останні 4 байти - контрольна сума ICV, усі інші перші - ключові дані CEK):

CEKICV = CEK || ICV;

обчислити контрольну суму ("ICV1") отриманих ключових даних "CEK" як імітовставку довжини 32 біти ("МАС32") згідно з розділом 5 ДСТУ ГОСТ 28147:2009.

Значення "dke" та ключ під час обчислення "KEK" беруться ті, що встановлені під час виконання етапу, зазначеного у позиції 1 цього пункту:

ICV1 = MAC32(CEK, dke, KEK) [4 байти];

порівняти контрольну суму "ICV", отриману за результатами виконання етапу, зазначеного у позиції 6 цього пункту, з контрольною сумою "ICV1", отриманою за результатами виконання етапу, зазначеного у позиції 7 цього пункту.

У разі нееквівалентності зазначених контрольних сум припинити подальше оброблення з результатом "помилка розшифрування ключа".

У разі еквівалентності зазначених контрольних сум повернути як результат розшифрування алгоритму "GOST28147Wrap" отримане значення ключового матеріалу "CEK".

8.4. Під час використання "GOST28147Wrap" як алгоритму захисту ключа шифрування ключів КШК у структурі "захищені дані" ("EnvelopedData") "dke" (довгостроковий ключовий елемент) визначається з параметрів алгоритму відкритого ключа одержувача.

Якщо значення "dke" немає в параметрах алгоритму відкритого ключа, слід брати за умовчанням значення ДКЕ N 1 з Переліку ДКЕ, які рекомендуються до застосування у засобах КЗІ, наведеного у додатку 1 до Інструкції N 114.

8.5. Процес зашифрування (Key Wrap) алгоритму Dstu7624Wrap

Умовні позначення:

CMAC(T,K) - функція обчислення імітовставки (контрольної суми) за алгоритмом "Калина-256/256-CMAC-256" (розділ 9 ДСТУ 7624:2014) повідомлення T на основі ключа K;

E(T,K,S) - функція шифрування повідомлення T на основі ключа K та синхропосилки S;

D(T,K,S) - функція розшифрування повідомлення T на основі ключа K та синхропосилки S;

REV(T) - функція реверсного перетворення порядку байтів повідомлення T таким чином, що останній байт стає першим;

X||Y - операція конкатенації блоків X та Y;

L(T,N) - функція отримання молодших N-двійкових розрядів повідомлення T;

R(T,N) - функція отримання старших N-двійкових розрядів повідомлення T;

l(T) - функція отримання довжини повідомлення T.

Вхідні параметри:

KEK - ключ шифрування ключа (КШК), двійковий рядок довжиною 256;

CEK - ключові дані для шифрування (в операції формування "захищені дані" - ключ шифрування даних КШД);

IV - синхропосилка, двійковий рядок довжиною 256, генерація здійснюється перед використанням алгоритму;

IV1 - фіксована синхропосилка, двійковий рядок довжиною 256 із значенням "6973271D6E611D06616715046C65504C2020004F6D68011F65610C0C73734714".

Вихідні параметри:

RES - зашифровані ключові дані.

Алгоритм:

виконати такі обчислення:

ICV = CMAC(CEK,KEK)

CEKICV = CEK||ICV

TEMP1 = E(CEKIV,KEK,IV)

TEMP2 = IV||TEMP1

TEMP3 = REV(TEMP2)

RES = E(TEMP3, KEK,IV1).

8.6. Процес розшифрування (Key Unwrap) алгоритму Dstu7624Wrap

Вхідні параметри:

KEK - ключ шифрування ключа (КШК), двійковий рядок довжиною 256;

RES - зашифровані ключові дані;

IV1 - фіксована синхропосилка, двійковий рядок довжиною 256 із значенням "6973271D6E611D06616715046C65504C2020004F6D68011F65610C0C73734714".

Вихідні параметри:

CEK - ключові дані для шифрування (в операції формування "захищені дані" - ключ шифрування даних КШД).

Алгоритм:

виконати такі обчислення:

TEMP3 = E(RES,KEK,IV1)

TEMP2 = REV(TEMP3)

IV = L(TEMP2,256)

TEMP1 = R(TEMP2,l(TEMP2)-256)

CEKICV = E(TEMP1,KEK,IV)

CEK = L(CEKICV,l(CEKICV)-256)

ICV = R(CEKICV, 256)

ICV1 = CMAC(CEK,KEK).

Порівняти контрольні суми ICV, ICV1. У разі нееквівалентності зазначених контрольних сум припинити подальше оброблення з результатом "помилка розшифрування ключа".

У разі еквівалентності зазначених контрольних сум повернути як результат розшифрування алгоритму Dstu7624Wrap отримане значення ключового матеріалу CEK.

9. Приклади обчислення імітовставки за ДСТУ 7624:2014 та за ДСТУ ГОСТ 28147:2009 розміщуються на офіційному веб-сайті Державної служби спеціального зв'язку та захисту інформації України.

10. Приклади обчислення GOST28147Wrap та Dstu7624Wrap розміщуються на офіційному веб-сайті Державної служби спеціального зв'язку та захисту інформації України.

(розділ VI у редакції наказу Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 21.12.2017 р. N 712)

VII. Алгоритм захисту даних (повідомлення) "contentEncryptionAlgorithm"

7.1. Об'єктні ідентифікатори алгоритмів шифрування даних

Як алгоритм шифрування даних "contentEncryptionAlgorithm" структури "EncryptedContentInfo" можуть використовуватися алгоритми:

ДСТУ 7624:2014 у режимах "Калина-256/256-OFB" (режим гамування зі зворотним зв'язком за шифротекстом відповідно до розділу 8 ДСТУ 7624:2014) та "Калина-256/256-CFB" (режим гамування зі зворотним зв'язком за шифрограмою відповідно до розділу 11 ДСТУ 7624:2014), які мають такі об'єктні ідентифікатори:

id-Dstu7624ofb(256) OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) ua-pki (1) alg (1) sym (1) dstu7624 (3) ofb (6) 256(2)};

id-Dstu7624cfb(256) OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) ua-pki (1) alg (1) sym (1) dstu7624 (3) cfb (3) 256(2)};

ДСТУ ГОСТ 28147:2009 в режимах "id-gost28147-ofb" (режим гамування, розділ 3 ДСТУ ГОСТ 28147:2009) та "id-gost28147-cfb" (режим гамування зі зворотним зв'язком, розділ 4 ДСТУ ГОСТ 28147:2009), які мають такі об'єктні ідентифікатори:

id-gost28147-ofb OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) ua-pki(1) alg(1) sym(1) gost28147(1) ofb(2)};

id-gost28147-cfb OBJECT IDENTIFIER ::= {iso(1)member-body(2) Ukraine(804) root(2) security(1) cryptography(1) ua-pki(1) alg(1) sym(1) gost28147(1) cfb(3)}.

7.2. Параметри алгоритму ДСТУ ГОСТ 28147:2009

GOST28147Parameters ::= SEQUENCE {

 

iv

OCTET STRING (SIZE (8)),

 

dke

OCTET STRING (SIZE (64)) },

де "iv" - вектор ініціалізації, що обирається випадково;

"dke" - довгостроковий ключовий елемент (ДКЕ) для ДСТУ ГОСТ 28147:2009, що відповідає вимогам Інструкції N 114.

7.3. Параметри алгоритму ДСТУ 7624:2014

Dstu7624Parameters::= SEQUENCE {

 

iv

OCTET STRING (SIZE (32))},

де "iv" - вектор ініціалізації, що обирається випадково.

(розділ VII у редакції наказу Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 21.12.2017 р. N 712)

VIII. Сертифікат шифрування

8.1. Сертифікат шифрування у цих Вимогах призначається для використання у протоколі узгодження ключа Діффі-Геллмана в групі точок еліптичної кривої.

(пункт 8.1 розділу VIII у редакції наказу Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 04.03.2020 р. N 129)

8.2. Пункт 8.2 розділу VIII виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 21.12.2017 р. N 712)

8.3. Пункт 8.3 розділу VIII виключено

(згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 21.12.2017 р. N 712,
у зв'язку з цим пункти 8.4, 8.5 вважати відповідно пунктами 8.2, 8.3)

8.2. Формат сертифіката шифрування повинен відповідати формату кваліфікованого сертифіката відкритого ключа, встановленого у Вимогах до електронних довірчих послуг.

(пункт 8.2 розділу VIII у редакції наказу Адміністрації Державної служби
 спеціального зв'язку та захисту інформації України від 04.03.2020 р. N 129)

8.3. Розширення сертифіката шифрування "Використання ключа".

Розширення "Використання ключа" має такий об'єктний ідентифікатор:

id-ce-keyUsage OBJECT IDENTIFIER::= {id-ce 15}.

У розширенні "Використання ключа" ("keyUsage") повинно бути встановлено значення "узгодження ключа" ("keyAgreement"). Додатково можуть бути встановлені значення:

"тільки зашифрування" ("encipherOnly");

"тільки розшифрування" ("decipherOnly").

У розширенні "Використання ключа" ("keyUsage") не повинні бути встановлені значення:

"цифровий підпис" ("digitalSignature");

(абзац восьмий пункту 8.3 розділу VIII із змінами, внесеними
 згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129)

"цифровий підпис у сертифікаті" ("keyCertSign");

(абзац дев'ятий пункту 8.3 розділу VIII із змінами, внесеними
 згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129)

"цифровий підпис у списку відкликаних сертифікатів" ("crlSign");

(абзац десятий пункту 8.3 розділу VIII із змінами, внесеними
 згідно з наказом Адміністрації Державної служби спеціального
 зв'язку та захисту інформації України від 04.03.2020 р. N 129)

"неспростовність" ("nonRepudiation");

"шифрування ключа" ("keyEncipherment");

"підписування сертифікатів" ("keyCertSign");

"підписування списків відкликаних сертифікатів" ("cRLSign").

 

Директор Департаменту
криптографічного захисту інформації
Адміністрації Державної служби
спеціального зв'язку та
захисту інформації України

А. І. Пушкарьов

 

ПРИКЛАДИ ASN.1 СТРУКТУРИ "ЗАХИЩЕНІ ДАНІ"

Додаток 1 виключено
(згідно з наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України
 від 21 грудня 2017 року N 712)

 

ПРИКЛАДИ ПЕРЕТВОРЕННЯ ЕЛЕМЕНТА ПОЛЯ НА РЯДОК БАЙТІВ У ФОРМАТІ BIG-ENDIAN

Додаток 2 виключено
(згідно з наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України
 від 21 грудня 2017 року N 712)

 

ПРИКЛАД ОБЧИСЛЕННЯ СПІЛЬНОГО СЕКРЕТУ ZZ У ЦИКЛІЧНІЙ ГРУПІ ПРОСТОГО ПОЛЯ
(FFC DH, ГОСТ 34.310-95, 1024 біти)

Додаток 3 виключено
(згідно з наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України
 від 21 грудня 2017 року N 712)

 

ПРИКЛАДИ ОБЧИСЛЕННЯ СПІЛЬНОГО СЕКРЕТУ ZZ У ГРУПІ ТОЧОК ЕЛІПТИЧНОЇ КРИВОЇ (ECDH)

Додаток 4 виключено
(згідно з наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України
 від 21 грудня 2017 року N 712)

 

ПРИКЛАДИ УЗГОДЖЕННЯ КЛЮЧА З ВИКОРИСТАННЯМ ГЕШ-ФУНКЦІЇ ГОСТ 34.311-95

Додаток 5 виключено
(згідно з наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України
 від 21 грудня 2017 року N 712)

 

ПРИКЛАДИ ОБЧИСЛЕННЯ КШК

Додаток 6 виключено
(згідно з наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України
 від 21 грудня 2017 року N 712)

 

ПРИКЛАДИ ОБЧИСЛЕННЯ ІМІТОВСТАВКИ ДСТУ ГОСТ 28147:2009

Додаток 7 виключено
(згідно з наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України
 від 21 грудня 2017 року N 712)

 

ПРИКЛАДИ ОБЧИСЛЕННЯ ЗА АЛГОРИТМОМ "GOST28147WRAP"

Додаток 8 виключено
(згідно з наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України
 від 21 грудня 2017 року N 712)

____________

Опрос