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

НАКАЗ

18.12.2012

м. Київ

N 739


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

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

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

НАКАЗУЮ:

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

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

3. Установити, що акредитовані центри сертифікації ключів забезпечують обслуговування посилених сертифікатів відкритих ключів, сформованих до дати набрання чинності Вимогами, та їх використання у надійних засобах електронного цифрового підпису та засобах криптографічного захисту інформації як сертифікати шифрування до закінчення строку чинності посилених сертифікатів відкритих ключів за умови відповідності параметрів криптографічного алгоритму відповідної ключової пари вимогам, наведеним у наказі Міністерства юстиції України, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 20 серпня 2012 року N 1236/5/453 "Про затвердження вимог до форматів, структури та протоколів, що реалізуються у надійних засобах електронного цифрового підпису" (Наказ N 1236/5/453), зареєстрованому в Міністерстві юстиції України 20 серпня 2012 року за N 1398/21710.

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

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

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

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

 

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

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

ПОГОДЖЕНО:

 

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

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


 

ЗАТВЕРДЖЕНО
Наказ Адміністрації Державної служби спеціального зв'язку та захисту інформації України
18.12.2012 N 739

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


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

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

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

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

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

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

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

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

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

симетричний ключ сеансу або ключ шифрування даних (КШД) - ключ сеансу, на якому здійснюється шифрування даних за алгоритмом, визначеним у ДСТУ ГОСТ 28147-2009;

узгоджений ключ ("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. Ці Вимоги розроблено з урахуванням Інструкції про порядок постачання і використання ключів до засобів криптографічного захисту інформації, затвердженої наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 12 червня 2007 року N 114, зареєстрованої в Міністерстві юстиції України 25 червня 2007 року за N 729/13996 (далі - Інструкція N 114); Вимог до формату посиленого сертифіката відкритого ключа, затверджених наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 20 серпня 2012 року N 1236/5/453 (Наказ N 1236/5/453), зареєстрованих у Міністерстві юстиції України 20 серпня 2012 року за N 1398/21710 (далі - Вимоги до формату посиленого сертифіката відкритого ключа); Вимог до формату списку відкликаних сертифікатів (Наказ N 1236/5/453), затверджених наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 20 серпня 2012 року N 1236/5/453, зареєстрованих у Міністерстві юстиції України 20 серпня 2012 року за N 1400/21712 (далі - Вимоги до формату списку відкликаних сертифікатів); Вимог до формату підписаних даних (Наказ N 1236/5/453), затверджених наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 20 серпня 2012 року N 1236/5/453, зареєстрованих у Міністерстві юстиції України 20 серпня 2012 року за N 1401/21713 (далі - Вимоги до формату підписаних даних); ДСТУ 4145-2002 "Інформаційні технології. Криптографічний захист інформації. Цифровий підпис, що ґрунтується на еліптичних кривих. Формування та перевіряння" (далі - ДСТУ 4145-2002); ДСТУ ISO/IEC 11770-3:2002 "Інформаційні технології. Методи захисту. Керування ключами. Частина 3. Механізми із застосуванням асиметричних методів" (далі - ДСТУ ISO/IEC 11770-3:2002); ДСТУ ISO/IEC 15946-3:2006 "Інформаційні технології. Методи захисту. Криптографічні методи, що ґрунтуються на еліптичних кривих. Частина 3. Установлення ключів" (далі - ДСТУ ISO/IEC 15946-3:2006); ДСТУ ГОСТ 28147-2009 "Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования" (далі - ДСТУ ГОСТ 28147-2009); ДСТУ ISO/IEC 10118-3:2005 "Інформаційні технології. Методи захисту. Геш-функції. Частина 3. Спеціалізовані геш-функції" (далі - ДСТУ ISO/IEC 10118-3:2005); ГОСТ 34.310-95 "Информационные технологии. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе ассиметричного криптографического алгоритма" (далі - ГОСТ 34.310-95); ГОСТ 34.311-95 "Информационная технология. Криптографическая защита информации. Функция хеширования" (далі - ГОСТ 34.311-95); RFC 2631 "Diffie-Hellman Key Agreement Method", June 1999 (далі - RFC 2631); 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).

1.6. Якщо у Вимогах є розбіжності з нормативними документами, зазначеними у пункті 1.5 цього розділу, то застосовуються положення цих Вимог.

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

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

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

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

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 структури "захищені дані" наведено в додатку 1 до цих Вимог.

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

При внесенні в криптографічне повідомлення "захищені дані" повідомлення типу "дані" автентифікація відправника цих даних не забезпечується, якщо використовується динамічний механізм узгодження ключів. Динамічний механізм узгодження ключів наведено у підпункті 3.2.2 пункту 3.2 глави 3 розділу III цих Вимог. При внесенні в повідомлення "захищені дані" повідомлення типу "підписані дані" завжди забезпечується автентифікація відправника цих даних.

2.7. Формат повідомлення "підписані дані" ("signed-data") встановлюється Вимогами до формату підписаних даних (Наказ N 1236/5/453).

На тип "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. Динамічний механізм узгодження ключів ("Ephemeral-Static mode") - узгодження ключів за протоколом Діффі-Геллмана, при якому одержувач має статичну ключову пару, відкритий ключ якої зазначено у посиленому сертифікаті відкритого ключа, а відправник генерує нову (сеансову/динамічну) ключову пару для кожного повідомлення і посилає відкритий ключ цієї пари одержувачу, використовуючи поле "originatorKey" структури "RecipientInfo".

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

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

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

Протокол узгодження ключів Діффі-Геллмана в циклічній групі поля використовується для ключових пар (відправника та одержувача), що відповідають ГОСТ 34.310-95 (але тільки за умови використання в режимі з довжиною модуля Р 1024).

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

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.3. Поле "certs".

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

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

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.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, формат якого відповідає Вимогам до формату списку відкликаних сертифікатів (Наказ N 1236/5/453).

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";

при застосуванні динамічного механізму узгодження ключів Діффі-Геллмана як ідентифікаційних даних відправника застосовується його відкритий сеансовий ключ (маркер), що генерується відправником та міститься в полі "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 кодується як ціле відповідно до Вимог до формату посиленого сертифіката відкритого ключа (Наказ N 1236/5/453).

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

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

Dstu4145PBAlgo 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)};

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

Dstu4145ONBAlgo 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, заокруглений до найближчого цілого у більшу сторону;

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

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

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

У разі застосування динамічного механізму узгодження ключів у групі точок еліптичної кривої (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) об'єктні ідентифікатори (OID) протоколу узгодження ключа у циклічній групі поля:

протокол узгодження ключа у циклічній групі поля з використанням геш-функції ГОСТ 34.311-95 позначається через ідентифікатор "id-DH-ua". Протокол узгодження ключа у циклічній групі поля з використанням геш-функції ГОСТ 34.311-95 є обов'язковим алгоритмом, який застосовується як для статичного, так і для динамічного механізму узгодження ключа; при цьому ознакою динамічного механізму є ненульове значення поля "originatorKey" (відповідно до абзацу третього позиції 3 підпункту 3.7.4 пункту 3.7 глави 3 розділу IV цих Вимог):

id-DH-ua OBJECT IDENTIFIER ::= { iso(1) member-body(2)

 

Ukraine(804) root(2) security(1) cryptography(1) ua-pki (1)

 

alg (1) asym (3) DH-ua(3) };


для протоколів узгодження ключа у циклічній групі поля з використанням геш-функції SHA-1 відповідно до ДСТУ ISO/IEC 10118-3:2005 та RFC 2631 (тільки для сумісності з реалізаціями засобів КЗІ, що були розроблені до прийняття цих Вимог) використовуються такі ідентифікатори:

"id-SSDH" - необов'язковий, застосовується для статичного механізму узгодження ключа;

"id-ESDH" - необов'язковий, застосовується для динамічного механізму узгодження ключа;

id-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 10 };

id-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 5 };

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

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

з використанням геш-функції ГОСТ 34.311-95: алгоритм з кофакторним множенням "id-dhSinglePass-cofactorDH-gost34311kdf-scheme", алгоритм без кофакторного множення "id-dhSinglePass-stdDH-gost34311kdf-scheme":

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 15946-3:2006, ДСТУ ISO/IEC 10118-3:2005 геш-функцій 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 цих Вимог.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) загальносистемні параметри протоколу id-ESDH-ua можуть визначатися як ASN.1 структура:

DHParameters ::= SEQUENCE {

 

p

INTEGER,

 

q

INTEGER,

 

a

INTEGER,

 

validationParms

GOST34310ValidationParms OPTIONAL,

 

 

-- параметри валідації,

 

dke

OCTET STRING OPTIONAL }

GOST34310ValidationParms ::= SEQUENCE {

 

x0

INTEGER,

 

c

INTEGER,

 

d

INTEGER OPTIONAL };


2) значення полів структури "DHParameters" наведено в таблиці.

Таблиця

p

характеристика основного поля, просте число (modulus)

q

порядок циклічної підгрупи (order of cyclic group)

a

твірний елемент циклічної підгрупи (generator)

dke

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

x0

початковий стан, що використовувався для генерації p, q (seed)

c

параметр датчика, що використовувався для генерації p, q

d

довільне число, що використовувалося для генерації а, 1 < d < p - 1


3) операція порівняння загальносистемних параметрів "DHParameters".

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

При виконанні операції порівняння параметрів повинні порівнюватися параметри p, a, q та додатково dke (у разі використання протоколу "id-ESDHua").

Параметри валідації "GOST34310ValidationParms" як необов'язкові не повинні використовуватися в операції порівняння.

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

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.3. Кодування ДКЕ виконується як:

dke OCTET STRING.

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

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

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

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

Спосіб представлення ДКЕ N 1 повинен відповідати вимогам пункту 3.12 розділу III Вимог до формату посиленого сертифіката відкритого ключа (Наказ N 1236/5/453).

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

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

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

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

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

5.1. Обчислення спільного секрету у циклічній групі поля (DH) ґрунтується на RFC 2631 та ДСТУ ISO/IEC 11770-3:2002 і виконується таким чином:

Z = (yb ^ xa) mod p = (ya ^ xb) mod p,

де Z - спільний секрет як елемент поля, в якому виконується обчислення;

"^" - означає операцію піднесення до ступеня;

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

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

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

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

"p" - характеристика поля, непарне просте число (odd prime);

"a" - твірний елемент циклічної підгрупи, генератор (generator).

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

Z = (yb ^ xa) mod p.

Одержувачем виконується обчислення за формулою

Z = (ya ^ xb) mod p.

Алгоритм DH не повинен застосовуватися, якщо:

a ^ x = a (mod p) або a ^ y = a (mod p),

де x - особистий ключ;

y - відкритий ключ.

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

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

Відправником обчислюється значення точки 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.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); якщо Z є елементом поля F(2m), то воно є двійковим (бітовим) рядком довжини m, що є зображенням додатного цілого числа у системі числення за основою 2. Позначимо ціле число від Z як ZI.

Виконати перетворення цілого ZI на рядок байтів ZZ у форматі Big-Endian. Перетворення цілого ZI на рядок байтів ZZ у форматі Little-Endian наведено у підпункті 3.14.2 пункту 3.14 розділу III Вимог до формату посиленого сертифіката відкритого ключа (Наказ N 1236/5/453). Формат Big-Endian має зворотний порядок байтів щодо формату Little-Endian.

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

Приклади перетворення елемента поля на рядок байтів у форматі Big-Endian наведено в додатку 2 до цих Вимог.

Приклад обчислення спільного секрету ZZ у циклічній групі простого поля (FFC DH, ГОСТ 34.310-95, 1024 біти) наведено в додатку 3 до цих Вимог.

Приклади обчислення спільного секрету ZZ у групі точок еліптичної кривої (ECDH) наведено в додатку 4 до цих Вимог.

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

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

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

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

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

6.3. KDF-функція у циклічній групі поля:

1) функція формування ключа (KDF-функція) у циклічній групі поля (DHKDF) ґрунтується на RFC 2631 та ДСТУ ISO/IEC 15946-3:2006 (додаток А.2. Функція формування ключа ANSI X9.42);

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

KM = H (ZZ || OtherInfo),

де:

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

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

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

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

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

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

OtherInfo ::= SEQUENCE {

 

keyInfo

KeySpecificInfo,

 

partyAInfo

[0] EXPLICIT OCTET STRING OPTIONAL,

 

suppPubInfo

[2] EXPLICIT OCTET STRING},

KeySpecificInfo ::= SEQUENCE {

 

algorithm

OBJECT IDENTIFIER,

 

counter

OCTET STRING SIZE (4..4) };


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

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

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

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

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

5) алгоритм формування ключа КШК:

якщо довжина KM більша, ніж довжина КШК, то за КШК приймають перші N байтів KM, де N - довжина КШК;

якщо довжина KM дорівнює довжині КШК, то за КШК приймають KM;

якщо довжина KM менша, ніж довжина КШК, то встановлюється значення counter = 1 і формується KM1; встановлюється значення counter = 2 та виконується KM2; ... (кількість кроків формування KMі визначається необхідною довжиною ключа КШК).

Блоки ключового матеріалу об'єднуються до отримання необхідної довжини (останні байти останнього блока KMі відкидаються):

KM = KM1 || KM2 || ...

Таким чином, довжина KM повинна бути рівною довжині ключа КШК;

6) якщо параметр "partyAInfo" як необов'язковий не буде використовуватися, то у випадках, зазначених у першому та другому кроках алгоритму, зазначеного у позиції 4 пункту 6.3 глави 6 розділу V цих Вимог, для різних повідомлень буде формуватися один і той самий ключ шифрування КШК. Для уникнення цього у разі статичного механізму вимагається (а у разі динамічного - рекомендується) генерувати випадкове значення "partyAInfo" для кожного повідомлення та використовувати під час формування КШК;

7) приклади обчислення ключа КШК у циклічній групі поля:

приклади узгодження ключа з використанням геш-функції ГОСТ34.311-95 наведено у додатку 5 до цих Вимог. ДКЕ позначено через sBox (SBOX-1 - це ДКЕ N 1 Переліку ДКЕ, які рекомендуються до застосування у засобах КЗІ, наведеному у додатку 1 до Інструкції N 114);

у наведених прикладах як KeyWrapAlgorithm ("algorithm") використовується ДСТУ ГОСТ 28147-2009 у режимі гамування ("id-gost28147-ofb", розділ VII цих Вимог) чи гамування зі зворотним зв'язком ("id-gost28147-сfb", розділ VII цих Вимог). Ці алгоритми не є Wrap-алгоритмами, що викладені у розділі VI цих Вимог, і використовуються тут лише для наведення прикладів.

Сформований ключ КШК позначається у прикладах через KEK, його довжина в бітах - через keyLen.

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

1) функція формування ключа (KDF-функція) у циклічній групі поля ґрунтується на ДСТУ ISO/IEC 15946-3:2002 (додаток А.3. Функція формування ключа ANSI X9.63);

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

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

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

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

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,

 

entityInfo

[0] EXPLICIT OCTET STRING OPTIONAL,

 

suppPubInfo

[2] EXPLICIT OCTET STRING };


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

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

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

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

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

6) приклади обчислення ключа КШК наведено у додатку 6 до цих Вимог. У наведених прикладах як KeyWrapAlgorithm (у прикладах "wrapAlgorithm") використовується ДСТУ ГОСТ 28147-2009 у режимі гамування ("id-gost28147-ofb", розділ VII цих Вимог) чи гамування зі зворотним зв'язком ("id-gost28147-cfb", розділ VII цих Вимог). Ці алгоритми не є Wrap-алгоритмами (які викладені у розділі VI цих Вимог) і використовуються лише для наведення прикладів.

У прикладах використовується протокол узгодження з кофакторним множенням "id-dhSinglePass-cofactorDH-gost34311kdf-scheme".

Сформований ключ КШК позначається у прикладах через KEK, його довжина в бітах - через keyLen.

ДКЕ для геш-функції ГОСТ 34.311-95 позначено через sBox (SBOX-1 - це ДКЕ N 1 Переліку ДКЕ, які рекомендуються до застосування у засобах КЗІ, наведеному у додатку 1 до Інструкції N 114).

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

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

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

Алгоритм GOST28147Wrap призначений для шифрування ключових даних чи інших даних, що підлягають захисту (далі - "ключові дані"), використовуючи стандарт ДСТУ ГОСТ 28147-2009 у режимі CFB (гамування із зворотним зв'язком, відповідно до розділу 4 ДСТУ ГОСТ 28147-2009) (далі - GOST28147-CFB).

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

Алгоритм захисту "GOST28147Wrap" є обов'язковим для використання.

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

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

KeyWrapAlgorithm ::= AlgorithmIdentifier.

5. Синтаксис "KeyWrapAlgorithm" алгоритму GOST28147Wrap:

GOST28147WrapParameters ::= CHOICE {

 

NULL,

 

 

parameters

GOST28147Parameters

},

 

 

GOST28147Parameters ::= SEQUENCE {

 

iv

OCTET STRING (SIZE (8)),

 

dke

OCTET STRING (SIZE (64)) },


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

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

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

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

7. Для алгоритму GOST28147Wrap поле "algorithm" повинно містити об'єктний ідентифікатор "id-gost28147-wrap":

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

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

8.2. Процес зашифрування (Key Wrap)

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

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

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

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

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

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

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

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

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

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

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

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

CEKICV = CEK || ICV;

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

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

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

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

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

TEMP2 = IV || TEMP1;

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

8) зашифрувати 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)

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

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

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

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

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

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

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

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

2) виконати розшифрування "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);

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

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

TEMP2 = IV || TEMP1;

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

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

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

CEKICV = CEK || ICV;

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

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

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

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

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

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

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

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

9. Приклади обчислення імітовставки ДСТУ ГОСТ 28147-2009 наведено в додатку 7 до цих Вимог.

10. Приклади обчислення за алгоритмом "GOST28147Wrap" наведено в додатку 8 до цих Вимог.

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

7.1. Об'єктні ідентифікатори алгоритмів ДСТУ ГОСТ 28147-2009

Як алгоритм захисту (шифрування) даних "contentEncryptionAlgorithm" структури "EncryptedContentInfo" можуть використовуватися алгоритми ДСТУ ГОСТ 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.

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

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

8.2. Сертифікат шифрування, призначений для протоколу узгодження ключа Діффі-Геллмана в циклічній групі простого поля, повинен бути посиленим сертифікатом відкритого ключа алгоритму ГОСТ 34.310-95 з довжиною 1024 біти.

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

8.4. Формат сертифіката шифрування повинен відповідати Вимогам до формату посиленого сертифіката відкритого ключа (Наказ N 1236/5/453).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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


 

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


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

Приклад 1. Статичний механізм узгодження ключа (Static-Static mode).


SEQUENCE : contentInfo

    OBJECT IDENTIFIER : envelopedData [1.2.840.113549.1.7.3]

    CONTEXT SPECIFIC (0) : content [0] 

       SEQUENCE : envelopedData 

          INTEGER : version 2

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

             CONTEXT SPECIFIC (1) : kari [1] KeyAgreeRecipientInfo

                INTEGER : version 3

                CONTEXT SPECIFIC (0) : originator [0] EXPLICIT
OriginatorIdentifierOrKey

                   SEQUENCE : issuerAndSerialNumber

                      SEQUENCE : issuer Name

                         SET : 

                            SEQUENCE : 

                               OBJECT IDENTIFIER : organizationName [2.5.4.10]

                               UTF8 STRING : 'Організація'

                         SET : 

                            SEQUENCE : 

                               OBJECT IDENTIFIER : organizationalUnitName [2.5.4.11]

                               UTF8 STRING : 'Підрозділ'

                         SET : 

                            SEQUENCE : 

                               OBJECT IDENTIFIER : commonName [2.5.4.3]

                               UTF8 STRING : 'ЦСК'

                         SET : 

                            SEQUENCE : 

                               OBJECT IDENTIFIER : serialNumber [2.5.4.5]

                               UTF8 STRING : 'UA-00000001'

                         SET : 

                            SEQUENCE : 

                               OBJECT IDENTIFIER : countryName [2.5.4.6]

                               PRINTABLE STRING : 'UA'

                         SET : 

                            SEQUENCE : 

                               OBJECT IDENTIFIER : localityName [2.5.4.7]

                               UTF8 STRING : 'Київ'

                      INTEGER : serialNumber 

5DF6640F7A5FA47A04000000030000000C000000

                CONTEXT SPECIFIC (1) : ukm

                   OCTET STRING : 

C88BA4578B122866032AAE1E3BE26B86F322135

                      68DEFA7F987A21DB511B39C5E95C049D1704B76

                      1FE754059FEF87B346337B3DC1951BD97AF6B8A

                      9506A0344EF

                SEQUENCE : keyEncryptionAlgorithm 

OBJECT IDENTIFIER : id-dhSinglePass-cofactorDH-gost34311kdf-scheme
[1.2.804.2.1.1.1.1.3.4]

                   SEQUENCE : id-dstu4145PB algorithm parameters

                      OBJECT IDENTIFIER : id-gost28147-wrap [1.2.804.2.1.1.1.1.1.1.5]

                      NULL : id-gost28147-wrap algorithm parameters ''

                SEQUENCE : recipientEncryptedKeys ::= SEQUENCE OF
RecipientEncryptedKey

                   SEQUENCE : RecipientEncryptedKey

                      SEQUENCE : rid KeyAgreeRecipientIdentifier 

                         SEQUENCE : issuerAndSerialNumber 

                            SET : issuer Name

                               SEQUENCE : 

                                  OBJECT IDENTIFIER : organizationName [2.5.4.10]

                                  UTF8 STRING : 'Організація'

                            SET : 

                               SEQUENCE : 

                                  OBJECT IDENTIFIER : organizationalUnitName [2.5.4.11]

                                  UTF8 STRING : 'Підрозділ'

                            SET : 

                               SEQUENCE : 

                                  OBJECT IDENTIFIER : commonName [2.5.4.3]

                                  UTF8 STRING : 'ЦСК'

                            SET : 

                               SEQUENCE : 

                                  OBJECT IDENTIFIER : serialNumber [2.5.4.5]

                                  UTF8 STRING : 'UA-01'

                            SET : 

                               SEQUENCE : 

                                  OBJECT IDENTIFIER : countryName [2.5.4.6]

                                  PRINTABLE STRING : 'UA'

                            SET : 

                               SEQUENCE : 

                                  OBJECT IDENTIFIER : localityName [2.5.4.7]

                                  UTF8 STRING : 'Київ'

                         INTEGER : serialNumber

                            5DF6640F7A5FA47A04000000040000000F000000

                      OCTET STRING : encryptedKey

89B8435E8122283769A53C4C9921DEC78759

                         114C7F99B9438F1FECE33B5AA64E2E28ED14

                         66AEB70F6ACDE4A7

          SEQUENCE : encryptedContentInfo

             OBJECT IDENTIFIER : data [1.2.840.113549.1.7.1]

             SEQUENCE : contentEncryptionAlgorithm

                OBJECT IDENTIFIER : id-gost28147-cfb [1.2.804.2.1.1.1.1.1.1.3]

                SEQUENCE : GOST28147Parameters

                   OCTET STRING : iv

                      BF539DB005E9EEB2

                   OCTET STRING : dke

                      A9D6EB45F13C708280C4967B231F5EADF658EBA

                      4C037291D38D96BF025CA4E17F8E9720DC615B4

                      3A28975F0BC1DEA36438B564EA2C179FD0123E6

                      DB8FAC57904

             CONTEXT SPECIFIC (0) : encryptedContent

                9D450A3DBB96ED17351FDBEECA76BFA326BC2B300DB925AF2A


Приклад 2. Динамічний механізм узгодження ключа (Ephemeral-Static mode).


SEQUENCE : contentInfo

    OBJECT IDENTIFIER : envelopedData [1.2.840.113549.1.7.3]

    CONTEXT SPECIFIC (0) : content [0]

       SEQUENCE : envelopedData

          INTEGER : version 2

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

             CONTEXT SPECIFIC (1) : kari [1] KeyAgreeRecipientInfo

                INTEGER : version 3

                CONTEXT SPECIFIC (0) : originator [0] EXPLICIT
OriginatorIdentifierOrKey

                   CONTEXT SPECIFIC (1) : originatorKey [1] OriginatorPublicKey

                      SEQUENCE : OriginatorPublicKey

                         OBJECT IDENTIFIER :  id-dstu4145PB [1.2.804.2.1.1.1.1.3.1.1]

                         NULL : ''

                      BIT STRING UnusedBits:0 : publicKey 

                         BBBF02E28D29A72FDD14C19D24CCF231109E

                         72E2925BAFA70280666D2304DF9B4B59BE68

                         16D7955546424357A6660691A0E13B039349

 

                CONTEXT SPECIFIC (1) : ukm

                   OCTET STRING : 

                      0A891E693BA51999711766C694E9D53E00E4C34

AF7F1412DB49F37B40D7F13214E9B40CB05882F

                      CA3F9FB8048C321F92E1855F51CBBFC512F0D2F

                      48E44083D61

                SEQUENCE : keyEncryptionAlgorithm 

OBJECT IDENTIFIER : id-dhSinglePass-cofactorDH-gost34311kdf-scheme
[1.2.804.2.1.1.1.1.3.4]

                   SEQUENCE : id-dstu4145PB algorithm parameters

                      OBJECT IDENTIFIER : id-gost28147-wrap [1.2.804.2.1.1.1.1.1.1.5]

                      NULL : id-gost28147-wrap algorithm parameters ''

                SEQUENCE : recipientEncryptedKeys ::= SEQUENCE OF
RecipientEncryptedKey

                   SEQUENCE : RecipientEncryptedKey 

                      SEQUENCE : issuerAndSerialNumber

                         SEQUENCE : issuer Name

                            SET : 

                               SEQUENCE : 

                                  OBJECT IDENTIFIER : organizationName [2.5.4.10]

                                  UTF8 STRING : 'Організація'

                            SET : 

                               SEQUENCE : 

                                  OBJECT IDENTIFIER : organizationalUnitName [2.5.4.11]

                                  UTF8 STRING : 'Підрозділ'

                            SET : 

                               SEQUENCE : 

                                  OBJECT IDENTIFIER : commonName [2.5.4.3]

                                  UTF8 STRING : 'ЦСК'

                            SET : 

                               SEQUENCE : 

                                  OBJECT IDENTIFIER : serialNumber [2.5.4.5]

                                  UTF8 STRING : 'UA-01'

                            SET : 

                               SEQUENCE : 

                                  OBJECT IDENTIFIER : countryName [2.5.4.6]

                                  PRINTABLE STRING : 'UA'

                            SET : 

                               SEQUENCE : 

                                  OBJECT IDENTIFIER : localityName [2.5.4.7]

                                  UTF8 STRING : 'Київ'

                         INTEGER : serialNumber

                            5DF6640F7A5FA47A040000000500000012000000

                      OCTET STRING : encryptedKey

                         BC51B084FD807B4CB12A2C82CE08C187684A

AD4F3FF13B04B8A1479297B7209BC73FFAAE

                         9201B2736A3006CD

          SEQUENCE : encryptedContentInfo

             OBJECT IDENTIFIER : data [1.2.840.113549.1.7.1]

             SEQUENCE : contentEncryptionAlgorithm

                OBJECT IDENTIFIER : id-gost28147-cfb [1.2.804.2.1.1.1.1.1.1.3]

                SEQUENCE : GOST28147Parameters

                   OCTET STRING : iv

                      68E728E617153147

                   OCTET STRING : dke

                      A9D6EB45F13C708280C4967B231F5EADF658EBA

                      4C037291D38D96BF025CA4E17F8E9720DC615B4

                      3A28975F0BC1DEA36438B564EA2C179FD0123E6

                      DB8FAC57904

             CONTEXT SPECIFIC (0) : encryptedContent 

                D33D9DB8F2B90D2D6119B58D3804DB5696634A1E698781BF0E


 

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


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

Приклад 1.

Z = 1 1110 0011 0111

ZI = 7735

ZZ = 1E 37

Примітка. У форматі Little-Endian кодується як послідовність байтів "37 1E".

Приклад 2.

ZI = 65048

ZZ = FE 18

Приклад 3.

ZI = 1450621147818416422260325141022141529263703331843

ZZ = FE 18 1A 1B 1C 17 19 16 10 13 0F 17 08 1B 02 18 16 14 14 03


 

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


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

p = E4 C6 F8 34 11 B1 55 9B 99 5D 5E 15 30 84 50 98 C3 0D CB 3E 2A A1 C2 BD
BE ED 4B EF 7D 92 2F DF 04 E1 A7 55 08 8F 46 39 85 19 20 51 DE 7A 06 03 0D
B6 36 2F 5F C3 2A 99 88 02 96 27 66 7C BC B1 26 9A A2 11 11 56 3D A2 47 13
31 A2 88 9F 35 C7 52 CB E6 FF 02 25 61 43 DB 9A CA 45 87 C9 3E B6 F9 D0 51
78 54 7F F8 43 9C FA AB E2 37 9A 7D 9E 14 C5 EA 84 10 17 BB CA CA 9C 35
9C A6 B3 8A 6F

q = D0 BD 51 FB 45 F3 E4 A6 C8 16 97 D4 63 16 3B 03 1D F0 46 DF 19 05 4F BF
D2 50 56 87 86 71 BF 91

a = BD A6 75 95 BC 18 A3 E5 27 13 A9 D4 E1 08 6E C3 E0 99 08 50 70 B0 28 57
59 57 E4 5B 28 DD 72 D8 2D 41 D2 B7 93 06 91 B5 BC 6C 79 81 86 39 6F 53 48
53 97 F0 F2 70 73 56 3A 79 56 0D 93 76 00 9C 9F 4B 63 CA 6C 9E E0 7D 12 B1 85
62 A8 CE 19 2E F9 1C 33 2F C4 1A AF 8A 59 E6 97 E8 D9 AE 0F 7E E5 07 D7 B4
3F 60 F4 A6 D0 8E 71 BE 08 8A E3 82 8B EC 91 BC 3D C6 B8 19 97 5D B3 E2 2D
98 AB A8

xa = 00 93 49 C5 03 C3 09 FC 95 B0 6E 81 CB F5 0C 7E 8D 54 E4 1B 1A 3B F8 70
43 2A FC 14 A6 FA 80 A7 D5

ya = 76 39 EF E2 1B 30 8D C4 6B F3 3F C6 9B AB 2F 12 EF 2E D5 18 E9 89 BB 3A
D1 09 4C 9F F7 27 0C D2 C4 01 9A D8 2B 46 63 EA 77 24 E7 0F EF E2 A8 B1 B1
12 9E 2F 2A B0 A7 A5 50 B8 F1 A7 D4 06 07 E2 EE 95 52 3A F1 6C 07 DC C5 57
24 FD E7 9D EC 72 66 FD 6C DE 70 6C D4 BA C1 70 E3 C6 D8 56 01 12 E8 9F
C3 2C A5 0F D2 74 1F 59 CF 41 98 CD 17 CC 88 DF 42 24 81 3A 5E E0 93 00 B8
2C 91 E2 B2 BD

xb = 30 18 1A 92 B5 E0 54 42 97 E5 10 AF 20 51 FB C8 56 26 20 97 AD A7 47 5A
5B 70 15 67 5E 08 9D F9

yb = 00 C0 6B DD D0 A4 0F CD 55 BA 79 54 A3 E7 9C DF F9 24 0C C0 48 B4 EA
FA A5 91 AA 7E 75 6E 57 27 A1 98 4F 4D BC 01 3A C7 7A B8 16 A6 7C EA 53
75 8C 7E 2D A8 8F C1 25 30 C8 73 C6 CD F2 DD 1A FD 27 0F 14 7F 1F 49 BD 9B
E7 68 04 3E B8 FC 95 A4 3A 0D 68 72 6B 8A C2 96 CD D1 05 88 89 CE 4D CA
B9 BD CE 6B 3A E2 D7 96 34 FC AA 07 85 8B A4 3F 54 B4 CD E8 01 36 DD 1E
83 49 DE AE 0F 5E CE 8E DA

ZZ = BD 7F 88 9E 48 B7 D6 2A 37 1A 6C 52 B9 2F 90 24 A2 D6 B5 05 82 04 5E 31
E2 94 95 99 01 54 7D BF 6D 90 50 B0 A0 AC D0 50 FE 96 9A AE EF B8 51 85 15
4D 9E 1D F7 D7 F4 86 DB 00 13 31 86 C6 B7 F8 4D 66 93 F4 F0 83 C6 3C A7 79
B9 02 C5 B8 9D 7F 74 16 CD AF CA 69 55 55 61 C5 F4 2F 53 B4 89 B4 7A A0 F5
31 21 91 42 1F 57 01 C6 60 54 3B B7 22 2D F6 58 6A E8 61 74 75 E7 52 86 6B 84
51 5D BF


 

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


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

Приклад 1. ECC DH, ДСТУ4145-2002 ПБ, m = 163

curveOID = 1.2.804.2.1.1.1.1.3.1.1.2.0

dA = 00 00 03 04 99 1F 9A C1 A8 09 4F 6F BF A0 09 25 0D 4A 80 99 32 0D 55

QAx = 30 01 C5 6A 32 99 13 07 62 6D 09 B5 FF 06 9C 6C B8 0B 79 4D 39 BD

QAy = 00 01 B9 85 8C 28 B9 BC DC A1 7B A3 5E 6D 5F 03 4B 23 AA 74 33 C7

dB = 00 01 FC 86 17 11 60 74 A8 FF 81 B4 2F 85 CA 25 16 CF 11 CE 2E 13

QBx = 00 01 F3 36 B1 E8 02 4B E4 AB E9 2D 26 CA 7F 30 22 0E 16 50 BC 1A

QBy = 00 02 F8 75 7B 1E 7E 72 E3 E5 46 B2 60 41 77 46 3D 3F C3 BE 63 C9

ZZ = 07 F8 4A DB A6 24 57 C5 DA 5D 95 94 47 C4 F6 C1 86 4C 9B 28 8E

Приклад 2. ECC DH, ДСТУ4145-2002 ПБ, m=431

curveOID = 1.2.804.2.1.1.1.1.3.1.1.2.9

dA = 4B 3A 17 07 F8 70 D0 C1 D4 CE 43 8E 88 AA 2B 36 15 06 91 62 86 F3 6F F3
5F 9C BE 9C 0F BD BE 1F 77 6B B5 C2 58 78 BA E1 C5 49 58 D1 B0 39 B1 2F F5
47 E0 08 63

QAx = 12 21 63 2E 63 D9 0A EB 4D B4 31 B9 9D E5 A8 7B 74 18 02 3D D7 12 B5
01 15 64 14 A0 F8 4C 07 41 B1 27 87 65 E6 3E A7 14 B3 D4 B6 8E A6 A1 04 53 08
B6 79 AD 96 69

QAy = 40 3D 64 C6 F5 15 62 B7 00 AC CD 27 AB CA 66 2F 87 97 74 4E 11 21 68
01 5E 0A 14 3A D0 29 62 7A 13 78 EB BA 93 48 70 D1 64 12 16 A4 8A 3F 10 17
FA 22 11 49 F6 83

dB = 06 FE 21 1C 55 5C B9 D3 A2 7B 7E C2 E2 FF BB 4C B1 67 EE 86 BB 7F 11
1E 7B CD 8F 65 64 E8 83 5B 09 E0 47 B9 28 6F BA 7F 83 50 78 79 BF EE 4C 33
EC BA 41 C5 DA B5

QBx = 50 B0 73 73 CF EE 5B 3F 7C 28 70 99 E3 B3 06 AE B1 69 0C 7E 66 92 6D
C5 02 D1 88 D8 81 FC 17 DC 75 AF D6 CE 2B 1E 9C ED 7C 16 FF D3 29 CF 41
1A 4B 0A BC 98 53 F5

QBy = 56 9F F5 92 E5 8A 9A 4F C8 EF 7E B9 97 A1 AA AC 46 10 5D 90 32 F7 89
D7 7C 6B 3F 7C 7B AE D2 BE F4 C2 AE 10 42 E2 B2 5A 98 AD 00 74 9A 43 63
91CC 98 F2 7C 43 5A

ZZ = 4B CA 28 D6 48 A5 0D EE F8 5F 8A 34 73 5B AE 5C 1A FE A7 2D 35 15 E1
66 39 E5 F1 66 DD 0A 47 ED E3 33 EA 5A B3 41 5D BC 4F DB B7 B6 8B E2 49
FF 3C 5B 75 F8 2B 55

Приклад 3. ECC DH, ДСТУ4145-2002 ОНБ, m=173

curveOID = 1.2.804.2.1.1.1.1.3.1.2.2.0

dA = 02 4D D6 E9 66 40 D1 67 F3 41 6B 77 C6 21 1B 86 20 0C 10 CF A6 60

QAx = 12 BC 80 94 27 D6 11 D7 AE 2F 5A 2C EE 2C A5 8A D9 C3 CF 27 1D 9C

QAy = 15 D4 28 1B B8 12 E5 A5 C2 16 BE DB B6 70 30 3C 34 0B 0A E4 CD 7F

dB = 02 B1 63 9B 21 01 3E 34 E6 0A 3F 98 D3 04 A4 57 12 EB 10 18 EF 6B

QBx = 00 D3 C3 C6 32 76 EE 77 38 BA E5 D0 6D 01 F3 F5 2D B1 D2 F8 C3 CF

QBy = 06 CB 9C 6D BC 22 A2 D0 83 C0 A4 38 27 83 F5 29 6F D3 CF 7F 3B 14

ZZ = 1C E3 D0 85 F5 93 BF 26 64 25 35 BB 16 A7 F7 DD 53 10 46 A7 3D 2A


 

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


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

Приклад 1. ГОСТ 34.310-95 1024 біт, "id-gost28147-ofb" KeyWrapAlgorithm

algorithm = 1.2.804.2.1.1.1.1.1.1.2

sBox = SBOX-3

keyLen = 256

partyAInfo = 0123456789abcdeffedcba98765432010123456789abcdeffedcba9876543
2010123456789abcdeffedcba98765432010123456789abcdeffedcba9876543201

p = E4 C6 F8 34 11 B1 55 9B 99 5D 5E 15 30 84 50 98 C3 0D CB 3E 2A A1 C2 BD
BE ED 4B EF 7D 92 2F DF 04 E1 A7 55 08 8F 46 39 85 19 20 51 DE 7A 06 03 0D
B6 36 2F 5F C3 2A 99 88 02 96 27 66 7C BC B1 26 9A A2 11 11 56 3D A2 47 13
31 A2 88 9F 35 C7 52 CB E6 FF 02 25 61 43 DB 9A CA 45 87 C9 3E B6 F9 D0 51
78 54 7F F8 43 9C FA AB E2 37 9A 7D 9E 14 C5 EA 84 10 17 BB CA CA 9C 35
9C A6 B3 8A 6F

q = D0 BD 51 FB 45 F3 E4 A6 C8 16 97 D4 63 16 3B 03 1D F0 46 DF 19 05 4F BF
D2 50 56 87 86 71 BF 91

a = BD A6 75 95 BC 18 A3 E5 27 13 A9 D4 E1 08 6E C3 E0 99 08 50 70 B0 28 57 59
57 E4 5B 28 DD 72 D8 2D 41 D2 B7 93 06 91 B5 BC 6C 79 81 86 39 6F 53 48 53
97 F0 F2 70 73 56 3A 79 56 0D 93 76 00 9C 9F 4B 63 CA 6C 9E E0 7D 12 B1 85 62
A8 CE 19 2E F9 1C 33 2F C4 1A AF 8A 59 E6 97 E8 D9 AE 0F 7E E5 07 D7 B4 3F
60 F4 A6 D0 8E 71 BE 08 8A E3 82 8B EC 91 BC 3D C6 B8 19 97 5D B3 E2 2D 98
AB A8

xa = 00 93 49 C5 03 C3 09 FC 95 B0 6E 81 CB F5 0C 7E 8D 54 E4 1B 1A 3B F8 70
43 2A FC 14 A6 FA 80 A7 D5

ya = 76 39 EF E2 1B 30 8D C4 6B F3 3F C6 9B AB 2F 12 EF 2E D5 18 E9 89 BB 3A
D1 09 4C 9F F7 27 0C D2 C4 01 9A D8 2B 46 63 EA 77 24 E7 0F EF E2 A8 B1 B1
12 9E 2F 2A B0 A7 A5 50 B8 F1 A7 D4 06 07 E2 EE 95 52 3A F1 6C 07 DC C5 57
24 FD E7 9D EC 72 66 FD 6C DE 70 6C D4 BA C1 70 E3 C6 D8 56 01 12 E8 9F
C3 2C A5 0F D2 74 1F 59 CF 41 98 CD 17 CC 88 DF 42 24 81 3A 5E E0 93 00 B8
2C 91 E2 B2 BD

xb = 03 84 40 38 A3 69 BA 43 15 BB 3B 64 27 15 9C CE AC 37 E7 63 07 B5 B6 F5
23 EA 01 0A 0F 7A 04 BD

yb = 00 D1 1F 56 A1 40 34 9A DC 48 F0 BD C5 5B BF B6 4E BC 59 5C 62 5A AB
93 EB E6 B6 49 C4 88 B2 E3 AB 51 76 58 BC 38 E7 EC 6A 2B A3 DF 03 2B 62 64
0E C0 92 B7 1B 61 EB FD 17 A3 CD 68 75 B8 14 C9 51 B8 36 D2 0C 32 CD 7D 6E
79 54 E7 06 4A 37 8E 77 88 2C 7A 09 BE 01 27 81 8C FF 88 53 9A C9 0E D3 FD
BF 3E 76 65 13 D0 EA FA AF AB 17 01 58 92 70 7C 1D D5 60 8E 63 7D 4D 8E 5A
3F 47 ED E3 FC 10

Z = 27 1C 54 DE AA AD 82 99 C1 7A C2 95 DE 74 0A 04 60 57 CD D2 A8 3E A4
27 A6 D1 AF 53 CC 0C 71 E7 8E B7 7B 1F 41 D3 97 45 9F EF 39 83 C9 7E 3F 53
74 BD 2B 82 F2 B8 E6 FF 0A 08 F2 E0 1E F5 4C BB EE DE FA 7E 23 D6 A4 66
E1 DF 8E E6 D8 DB 6D C9 2F 7D 67 9A 9F 23 F5 BE 16 5A 26 D6 1D 7D B2 0C
C8 8F F7 E0 C1 CA E0 E6 1C BF EE 06 AD 52 16 F8 68 AC D3 16 FF B0 30 E6
BF 49 3E F8 9D 18 DA FD

KEK = 36 C0 9A A8 83 A4 B5 83 EB C8 ED 28 17 7E 6C 35 BF A7 F4 57 8A 25 8E
4E 5C AE 35 05 82 FB D2 A7

Приклад 2. ГОСТ 34.310-95 1024 біт, "id-gost28147-ofb"KeyWrapAlgorithm

algorithm = 1.2.804.2.1.1.1.1.1.1.2

sBox = SBOX-4

keyLen = 256

partyAInfo=

p = E4 C6 F8 34 11 B1 55 9B 99 5D 5E 15 30 84 50 98 C3 0D CB 3E 2A A1 C2 BD
BE ED 4B EF 7D 92 2F DF 04 E1 A7 55 08 8F 46 39 85 19 20 51 DE 7A 06 03 0D
B6 36 2F 5F C3 2A 99 88 02 96 27 66 7C BC B1 26 9A A2 11 11 56 3D A2 47 13
31 A2 88 9F 35 C7 52 CB E6 FF 02 25 61 43 DB 9A CA 45 87 C9 3E B6 F9 D0 51
78 54 7F F8 43 9C FA AB E2 37 9A 7D 9E 14 C5 EA 84 10 17 BB CA CA 9C 35
9C A6 B3 8A 6F

q = D0 BD 51 FB 45 F3 E4 A6 C8 16 97 D4 63 16 3B 03 1D F0 46 DF 19 05 4F BF
D2 50 56 87 86 71 BF 91

a = BD A6 75 95 BC 18 A3 E5 27 13 A9 D4 E1 08 6E C3 E0 99 08 50 70 B0 28 57 59
57 E4 5B 28 DD 72 D8 2D 41 D2 B7 93 06 91 B5 BC 6C 79 81 86 39 6F 53 48 53
97 F0 F2 70 73 56 3A 79 56 0D 93 76 00 9C 9F 4B 63 CA 6C 9E E0 7D 12 B1 85 62
A8 CE 19 2E F9 1C 33 2F C4 1A AF 8A 59 E6 97 E8 D9 AE 0F 7E E5 07 D7 B4 3F
60 F4 A6 D0 8E 71 BE 08 8A E3 82 8B EC 91 BC 3D C6 B8 19 97 5D B3 E2 2D 98
AB A8

xa = 00 93 49 C5 03 C3 09 FC 95 B0 6E 81 CB F5 0C 7E 8D 54 E4 1B 1A 3B F8 70
43 2A FC 14 A6 FA 80 A7 D5

ya = 76 39 EF E2 1B 30 8D C4 6B F3 3F C6 9B AB 2F 12 EF 2E D5 18 E9 89 BB 3A
D1 09 4C 9F F7 27 0C D2 C4 01 9A D8 2B 46 63 EA 77 24 E7 0F EF E2 A8 B1 B1
12 9E 2F 2A B0 A7 A5 50 B8 F1 A7 D4 06 07 E2 EE 95 52 3A F1 6C 07 DC C5 57
24 FD E7 9D EC 72 66 FD 6C DE 70 6C D4 BA C1 70 E3 C6 D8 56 01 12 E8 9F
C3 2C A5 0F D2 74 1F 59 CF 41 98 CD 17 CC 88 DF 42 24 81 3A 5E E0 93 00 B8
2C 91 E2 B2 BD

xb = 03 84 40 38 A3 69 BA 43 15 BB 3B 64 27 15 9C CE AC 37 E7 63 07 B5 B6 F5
23 EA 01 0A 0F 7A 04 BD

yb = 00 D1 1F 56 A1 40 34 9A DC 48 F0 BD C5 5B BF B6 4E BC 59 5C 62 5A AB
93 EB E6 B6 49 C4 88 B2 E3 AB 51 76 58 BC 38 E7 EC 6A 2B A3 DF 03 2B 62 64
0E C0 92 B7 1B 61 EB FD 17 A3 CD 68 75 B8 14 C9 51 B8 36 D2 0C 32 CD 7D 6E
79 54 E7 06 4A 37 8E 77 88 2C 7A 09 BE 01 27 81 8C FF 88 53 9A C9 0E D3 FD
BF 3E 76 65 13 D0 EA FA AF AB 17 01 58 92 70 7C 1D D5 60 8E 63 7D 4D 8E 5A
3F 47 ED E3 FC 10

Z = 27 1C 54 DE AA AD 82 99 C1 7A C2 95 DE 74 0A 04 60 57 CD D2 A8 3E A4
27 A6 D1 AF 53 CC 0C 71 E7 8E B7 7B 1F 41 D3 97 45 9F EF 39 83 C9 7E 3F 53
74 BD 2B 82 F2 B8 E6 FF 0A 08 F2 E0 1E F5 4C BB EE DE FA 7E 23 D6 A4 66
E1 DF 8E E6 D8 DB 6D C9 2F 7D 67 9A 9F 23 F5 BE 16 5A 26 D6 1D 7D B2 0C
C8 8F F7 E0 C1 CA E0 E6 1C BF EE 06 AD 52 16 F8 68 AC D3 16 FF B0 30 E6
BF 49 3E F8 9D 18 DA FD KEK = BA 3A 06 B2 C0 03 97 B1 02 DF 67 9E 5B 0C 9E
97 57 AB 34 8C 38 50 82 E8 7D EF 86 21 A5 21 93 E3


 

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


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

Приклад 1. ДСТУ 4145-2002 ПБ, m = 163, "id-gost28147-ofb" KeyWrapAlgorithm

sBox = SBOX-1

curveOID = 1.2.804.2.1.1.1.1.3.1.1.2.0

wrapAlgorithm = 1.2.804.2.1.1.1.1.1.1.2

keyLen = 256

entityUInfo = 0123456789abcdeffedcba98765432010123456789abcdeffedcba9876543
2010123456789abcdeffedcba98765432010123456789abcdeffedcba9876543201

dA = 00 03 04 99 1F 9A C1 A8 09 4F 6F BF A0 09 25 0D 4A 80 99 32 0D 55

QAx = 00 01 C5 6A 32 99 13 07 62 6D 09 B5 FF 06 9C 6C B8 0B 79 4D 39 BD

QAy = 00 01 B9 85 8C 28 B9 BC DC A1 7B A3 5E 6D 5F 03 4B 23 AA 74 33 C7

dB = 00 01 FC 86 17 11 60 74 A8 FF 81 B4 2F 85 CA 25 16 CF 11 CE 2E 13

QBx = 00 01 F3 36 B1 E8 02 4B E4 AB E9 2D 26 CA 7F 30 22 0E 16 50 BC 1A

QBy = 00 02 F8 75 7B 1E 7E 72 E3 E5 46 B2 60 41 77 46 3D 3F C3 BE 63 C9

ZZ = 07 F8 4A DB A6 24 57 C5 DA 5D 95 94 47 C4 F6 C1 86 4C 9B 28 8E

KEK = 9F 61 94 11 BB 8D 53 C6 9C A7 C0 03 69 10 70 EF 31 C7 B7 2B 63 68

31 10 33 AB EF B8 A0 C1 2C 9D

Приклад 2. ДСТУ 4145-2002 ПБ, m = 163, "id-gost28147-cfb" KeyWrapAlgorithm

sBox = SBOX-1

curveOID = 1.2.804.2.1.1.1.1.3.1.1.2.0

wrapAlgorithm = 1.2.804.2.1.1.1.1.1.1.3

keyLen = 256

partyAInfo=

dA = 01 E7 C0 CE 88 C8 D4 44 E8 BA 58 70 90 F2 72 6D B1 BB 27 FB 58".

QAx = 06 A7 1C 9B 54 16 05 BA AD 2A 32 5A 2C 63 E3 90 F6 52 A1 B9 B4

QAy = 07 6D B8 D2 1D 01 41 D0 A9 E5 E5 BA 0C 66 A4 4A 23 A5 81 17 DB

dB = 03 04 99 1F 9A C1 A8 09 4F 6F BF A0 09 25 0D 4A 80 99 32 0D 55

QBx = 01 C5 6A 32 99 13 07 62 6D 09 B5 FF 06 9C 6C B8 0B 79 4D 39 BD

QBy = 01 B9 85 8C 28 B9 BC DC A1 7B A3 5E 6D 5F 03 4B 23 AA 74 33 C7

ZZ = 05 34 19 06 74 D9 3B 3D 23 27 D6 B0 65 20 7F 9D E7 80 63 65 CC

KEK = 6B CC 82 B8 F7 A8 BC 9F C8 B9 BD 4C DE 18 FC FE 99 71 17 55 D9

AC 05 42 2C 33 32 F3 E9 6D 49 B8

Приклад 3. ДСТУ 4145-2002 ОНБ, m = 173, "id-gost28147-cfb" KeyWrapAlgorithm

algorithm = DSTU4145

sBox = SBOX-1

curveOID = 1.2.804.2.1.1.1.1.3.1.2.2.0

wrapAlgorithm = 1.2.804.2.1.1.1.1.1.1.3

keyLen = 256

entityUInfo = 0123456789abcdeffedcba98765432010123456789abcdeffedcba9876543
201
0123456789abcdeffedcba98765432010123456789abcdeffedcba9876543201

dA = 02 4D D6 E9 66 40 D1 67 F3 41 6B 77 C6 21 1B 86 20 0C 10 CF A6 60

QAx = 12 BC 80 94 27 D6 11 D7 AE 2F 5A 2C EE 2C A5 8A D9 C3 CF 27 1D 9C

QAy = 15 D4 28 1B B8 12 E5 A5 C2 16 BE DB B6 70 30 3C 34 0B 0A E4 CD 7F

dB = 02 B1 63 9B 21 01 3E 34 E6 0A 3F 98 D3 04 A4 57 12 EB 10 18 EF 6B

QBx = 00 D3 C3 C6 32 76 EE 77 38 BA E5 D0 6D 01 F3 F5 2D B1 D2 F8 C3 CF

QBy = 06 CB 9C 6D BC 22 A2 D0 83 C0 A4 38 27 83 F5 29 6F D3 CF 7F 3B 14

Z = 1C E3 D0 85 F5 93 BF 26 64 25 35 BB 16 A7 F7 DD 53 10 46 A7 3D 2A

KEK = AF 7C 82 3E 78 AE E6 40 F6 DC 50 7D 49 EE F3 EB 6C 30 79 FF 33 9D 8C
84 A3 1B 40 7D 31 9D 0C EC


 

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


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

Вхідні дані:

ДКЕ - значення ДКЕ N 1 Переліку ДКЕ, які рекомендуються до застосування у засобах КЗІ, наведеному у додатку 1 до Інструкції N 114 (SBOX-1);

key - ключ, на якому здійснюється шифрування ("KEK");

data - дані, від яких обчислюється імітовставка.

Вихідні дані:

MAC32 - імітовставка, 32 біти.

Приклад 1.

key = 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

data = 55 55 55 55 AA AA AA AA 55 55 55 55 CC CC CC CC

MAC32 = BA 94 82 CC

Приклад 2.

key = 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

data = 55 55 55 55 AA AA AA AA 55 55 55 55 CC CC CC CC
55 55 55 55 AA AA AA AA 55 55 55 55 CC CC CC CC

MAC32 = 17 D7 36 CB


 

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


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

Вхідні дані:

ДКЕ - значення ДКЕ N 1 Переліку ДКЕ, які рекомендуються до застосування у засобах КЗІ, наведеному у додатку 1 до Інструкції N 114 (SBOX-1);

KEK - ключ, на якому здійснюється шифрування ("KEK");

CEK - ключові дані, які захищаються GOST28147Wrap.

Вихідні дані:

wrapedCEK - захищені ключові дані.

Приклад 1.

KEK =
01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

CEK =
01 02 03 04 01 02 03 04 01 02 03 04 01 02 03 04
F1 F2 F3 F4 F5 F6 F7 F8 F1 F2 F3 F4 F5 F6 F7 F8

wCEK =
52 A5 13 F1 B4 17 2C A6 B5 F1 B8 A0 3C A9 A4 E0
AC B6 E0 0E 11 E5 E9 BC DD 44 62 22 EB 97 23 8D
C3 E4 E2 4D 2E C0 3E 05 A5 68 EC 51

Дані обчислень при зашифруванні (WRAP):

ICV = 0B 8A A1 29

CEKICV = 01 02 03 04 01 02 03 04 01 02 03 04 01 02 03 04
F1 F2 F3 F4 F5 F6 F7 F8 F1 F2 F3 F4 F5 F6 F7 F8 0B 8A A1 29

IV = F4 77 DA 7A A6 42 4A 88

TEMP1 = 7D 33 F5 AD CC 6E 8D BF BA A0 C2 86 5C 36 9D 0B
46 7B FB 6F BD 98 A8 E9 30 A4 11 DB 26 3E 86 03 23 07 5F 76

TEMP2 = F4 77 DA 7A A6 42 4A 88 7D 33 F5 AD CC 6E 8D BF
BA A0 C2 86 5C 36 9D 0B 46 7B FB 6F BD 98 A8 E9
30 A4 11 DB 26 3E 86 03 23 07 5F 76

TEMP3 = 76 5F 07 23 03 86 3E 26 DB 11 A4 30 E9 A8 98 BD
6F FB 7B 46 0B 9D 36 5C 86 C2 A0 BA BF 8D 6E CC
AD F5 33 7D 88 4A 42 A6 7A DA 77 F4

result = 52 A5 13 F1 B4 17 2C A6 B5 F1 B8 A0 3C A9 A4 E0
AC B6 E0 0E 11 E5 E9 BC DD 44 62 22 EB 97 23 8D
C3 E4 E2 4D 2E C0 3E 05 A5 68 EC 51

Приклад 2.

KEK = 01 02 03 04 01 02 03 04 01 02 03 04 01 02 03 04
F1 F2 F3 F4 F5 F6 F7 F8 F1 F2 F3 F4 F5 F6 F7 F8

CEK = 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

wCEK = 0E 89 69 20 66 1D 2E 1C 64 86 D3 0B A2 99 F3 0E
69 52 21 28 04 13 73 12 F9 7F 11 9D 24 4C F7 A9
6A 22 DA 81 A5 66 85 1A A9 36 0B F9

           Дані обчислень при зашифруванні (WRAP):

ICV = 32 83 01 5E

CEKICV = 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 32 83 01 5E

IV = 3C A7 21 15 C6 8C AB D0

TEMP1 = D3 C5 BE A3 B8 9D 43 44 C5 89 34 1F FE D1 EC B4
36 C7 15 BE 4B D7 61 15 A9 66 B2 81 78 81 02 0D 14 FE FA D6

TEMP2 = 3C A7 21 15 C6 8C AB D0 D3 C5 BE A3 B8 9D 43 44
C5 89 34 1F FE D1 EC B4 36 C7 15 BE 4B D7 61 15
A9 66 B2 81 78 81 02 0D 14 FE FA D6

TEMP3 = D6 FA FE 14 0D 02 81 78 81 B2 66 A9 15 61 D7 4B
BE 15 C7 36 B4 EC D1 FE 1F 34 89 C5 44 43 9D B8
A3 BE C5 D3 D0 AB 8C C6 15 21 A7 3C

result = 0E 89 69 20 66 1D 2E 1C 64 86 D3 0B A2 99 F3 0E
69 52 21 28 04 13 73 12 F9 7F 11 9D 24 4C F7 A9
6A 22 DA 81 A5 66 85 1A A9 36 0B F9





 
 
Copyright © 2003-2018 document.UA. All rights reserved. При використанні матеріалів сайту наявність активного посилання на document.UA обов'язково. Законодавство-mirror:epicentre.com.ua
RSS канали