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

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

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

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

НАКАЗ

21.12.2017

м. Київ

N 712

Зареєстровано в Міністерстві юстиції України
17 січня 2018 р. за N 72/31524

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

Відповідно до підпункту 2 пункту 3 Положення про Адміністрацію Державної служби спеціального зв'язку та захисту інформації України, затвердженого постановою Кабінету Міністрів України від 03 вересня 2014 року N 411, та з метою удосконалення законодавства у сфері електронного цифрового підпису

НАКАЗУЮ:

1. Затвердити Зміни до Вимог до форматів криптографічних повідомлень, затверджених наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 18 грудня 2012 року N 739, зареєстрованих у Міністерстві юстиції України 14 січня 2013 року за N 108/22640, що додаються.

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

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

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

 

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

Л. О. Євдоченко

ПОГОДЖЕНО:

 

Виконувач обов'язків Міністра
економічного розвитку
і торгівлі України

Ю. П. Бровченко

Голова Державної регуляторної
служби України

К. Ляпіна

 

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

1. Розділ I викласти в такій редакції:

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

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

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

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

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

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

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

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

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

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

Інші терміни вживаються у значеннях, наведених у Законі України "Про електронний цифровий підпис", Порядку акредитації центру сертифікації ключів, затвердженому постановою Кабінету Міністрів України від 13 липня 2004 року N 903, Правилах посиленої сертифікації, затверджених наказом Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України від 13 січня 2005 року N 3, зареєстрованих у Міністерстві юстиції України 27 січня 2005 року за N 104/10384 (із змінами).

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

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

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

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

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

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) та встановлюють особливості застосування в них криптографічних алгоритмів, визначених стандартами ГОСТ 34.310-95 "Информационная технология. Криптографическая защита информации. Процессы выработки и проверки электронной цифровой подписи на базе ассиметричного криптографического алгоритма" (далі - ГОСТ 34.310-95), ДСТУ 4145-2002 "Інформаційні технології. Криптографічний захист інформації. Цифровий підпис, що ґрунтується на еліптичних кривих. Формування та перевіряння" (далі - ДСТУ 4145-2002), ДСТУ ГОСТ 28147:2009 "Системы обработки информации. Защита криптографическая. Алгоритмы криптографического преобразования" (далі - ДСТУ ГОСТ 28147:2009), ДСТУ 7624:2014 "Інформаційні технології. Криптографічний захист інформації. Алгоритм симетричного блокового перетворення" (далі - ДСТУ 7624:2014), ДСТУ ISO/IEC 10118-3:2005 "Інформаційні технології. Методи захисту. Геш-функції. Частина 3. Спеціалізовані геш-функції" (далі - ДСТУ ISO/IEC 10118-3:2005).

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

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), Вимог до формату посиленого сертифіката відкритого ключа, затверджених наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 20 серпня 2012 року N 1236/5/453, зареєстрованих у Міністерстві юстиції України 20 серпня 2012 року за N 1398/21710 (далі - Вимоги до формату посиленого сертифіката відкритого ключа), Вимог до формату списку відкликаних сертифікатів, затверджених наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 20 серпня 2012 року N 1236/5/453, зареєстрованих у Міністерстві юстиції України 20 серпня 2012 року за N 1400/21712 (далі - Вимоги до формату списку відкликаних сертифікатів), Вимог до формату підписаних даних, затверджених наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 20 серпня 2012 року N 1236/5/453, зареєстрованих у Міністерстві юстиції України 20 серпня 2012 року за N 1401/21713 (далі - Вимоги до формату підписаних даних).

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

2. У розділі II:

пункт 2.5 викласти в такій редакції:

"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.6 виключити.

3. У пункті 3.2 глави 3 розділу III:

абзац перший підпункту 3.2.1 викласти в такій редакції:

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

абзац перший підпункту 3.2.2 викласти в такій редакції:

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

4. У пункті 3.7 глави 3 розділу IV:

позицію 3 підпункту 3.7.4 викласти в такій редакції:

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

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

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

під час застосування динамічного механізму узгодження ключів у циклічній групі поля поле "algorithm" в "originatorKey" повинно мати таке значення:

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

Відповідно до RFC 3370 параметрів алгоритму поля "algorithm" в "originatorKey" не повинно бути.

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

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

Відкритий ключ ГОСТ 34.310-95 кодується як ціле відповідно до Вимог до формату посиленого сертифіката відкритого ключа.

Під час застосування динамічного механізму узгодження ключів у групі точок еліптичної кривої поле "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.7.5:

абзац другий позиції 3 після цифр "34.311-95" доповнити словами та цифрами "Информационная технология. Криптографическая защита информации. Функция хеширования" (далі - ГОСТ 34.311-95)";

позицію 4 викласти в такій редакції:

"4) об'єктні ідентифікатори (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 };

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

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

5. У розділі V:

1) главу 2 викласти в такій редакції:

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

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

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

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

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

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

2) пункт 5.3 глави 5 викласти в такій редакції:

"5.3. Перетворення елемента поля 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 у циклічній групі простого поля та у групі точок еліптичної кривої розміщуються на офіційному веб-сайті Державної служби спеціального зв'язку та захисту інформації України.";

3) у главі 6:

у пункті 6.3:

у позиції 1 слова та цифри "(додаток А.2. Функція формування ключа ANSI X9.42)" виключити;

позицію 7 викласти у такій редакції:

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

у пункті 6.4:

у позиції 1 слова та цифри "(додаток А.3. Функція формування ключа ANSI X9.63)" виключити;

позицію 3 викласти в такій редакції:

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

SharedInfo ::= SEQUENCE {

 

keyInfo

AlgorithmIdentifier,

 

entityUInfo

[0] EXPLICIT OCTET STRING OPTIONAL,

 

suppPubInfo

[2] EXPLICIT OCTET STRING};";

в абзаці третьому позиції 4 слова "довжина "partyAInfo" замінити словами "довжина "entityUInfo";

у позиції 5 слово "partyAInfo" замінити словом "entityUInfo";

позицію 6 викласти у такій редакції:

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

6. Розділ VI викласти в такій редакції:

"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. Ключ узгодження КШК формується за алгоритмами узгодження ключа DH або ECDH:

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 розміщуються на офіційному веб-сайті Державної служби спеціального зв'язку та захисту інформації України.".

7. Розділ VII викласти в такій редакції:

"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" - вектор ініціалізації, що обирається випадково.".

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

У зв'язку з цим пункти 8.4, 8.5 вважати відповідно пунктами 8.2, 8.3.

9. У тексті Вимог до форматів криптографічних повідомлень (далі - Вимоги) слова та цифри "ДСТУ ГОСТ 28147-2009" замінити словами та цифрами "ДСТУ ГОСТ 28147:2009".

10. У тексті Вимог абревіатури та цифри "ДСТУ ISO/IEC 11770-3:2002" замінити абревіатурами та цифрами "ДСТУ ISO/IEC 11770-3:2015".

11. У тексті Вимог абревіатури та цифри "ДСТУ ISO/IEC 15946-3:2006" замінити абревіатурами та цифрами "ДСТУ ISO/IEC 11770-3:2015".

12. Додатки 1 - 8 виключити.

 

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

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

Опрос