Пошук

Розширений пошук




















Головна » Регуляторна діяльність » Повідомлення про оприлюднення та проекти


версія для друку

Проект


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

ТА ЗАХИСТУ ІНФОРМАЦІЇ УКРАЇНИ

 

НАКАЗ

м. Київ

 

__.__.2009                                                                                                                  № _________

 

 

 

 

 

 

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

 

 

Відповідно до статті 7 Закону України Про Державну службу спеціального зв‘язку та захисту інформації України”, пункту 3 Положення про Адміністрацію Державної служби спеціального зв'язку та захисту інформації, затвердженого постановою Кабінету Міністрів України від 24.06.2006 № 868, пункту 4 розпорядження  Кабінету Міністрів України від 09.09.2009 № 1087-р “Деякі питання організації електронного документообігу та звітності” з метою створення умов технологічної сумісності засобів криптографічного захисту інформації, НАКАЗУЮ:

 

1. Затвердити Технічні специфікації форматів криптографічних повідомлень.

 

2. Департаменту регулювання діяльності у сфері криптографічного захисту інформації Адміністрації Держспецзв’язку подати наказ на державну реєстрацію відповідно до Указу Президента України від 03.10.1992 № 493 “Про державну реєстрацію нормативно-правових актів міністерств та інших органів виконавчої влади” (із змінами).

 

3. Департаменту забезпечення діяльності Голови Служби Адміністрації Держспецзв’язку розмістити наказ на офіційному веб-сайті Держспецзв’язку.

 

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

 

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

 

Голова Служби                                                                             Ю.Б.Чеботаренко


 

 

 

ЗатверджЕно

 

 

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

___.___.2010 №______________

 

 

 

 

 

ТЕХНІЧНІ СПЕЦИФІКАЦІЇ

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

 

I. Загальні положення та визначення термінів

 

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

 

1.2. У цих Технічних специфікаціях терміни вживаються у такому значені:

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

цифровий конверт – зашифровані дані будь-якого типу (наприклад, „дані” („data”), „підписані дані” („signed-data”) тощо) разом із зашифрованим симетричним ключем;

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

узгоджений ключ („key agreement”) (KШK) – симетричний ключ на якому здійснюється шифрування симетричного ключа сеансу за алгоритмом, визначеним у національному стандарті України ДСТУ ГОСТ 28147-2009;

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

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

Інші терміни вживаються у значенні, наведеному у Законі України “Про електронний цифровий підпис”, Порядку акредитації центру сертифікації ключів, затвердженому постановою Кабінету Міністрів України від 13 липня 2004 року № 903, Правилах посиленої сертифікації, затверджених наказом Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України № 3 від 13.01.2005, зареєстрованих в Міністерстві юстиції України 27.01.2005 за № 104/10384, інших нормативно-правових актах з питань криптографічного та технічного захисту інформації.

 

1.3. Технічні специфікації засновані на міжнародних рекомендаціях RFC 3852 “Cryptographic Message Syntax (CMS)”, національних стандартах України ДСТУ 4145-2002 “Інформаційні технології. Криптографічний захист інформації. Цифровий підпис, що ґрунтується на еліптичних кривих. Формування та перевіряння”, ДСТУ ISO/IEC 11770-3 “Інформаційні технології. Методи захисту. Управління ключовими даними. Частина 3. Протоколи, що ґрунтуються на асиметричних криптографічних перетвореннях”, ДСТУ ISO/IEC 15946-3 “Інформаційні технології. Методи захисту. Ккриптографічні методи, що ґрунтуються на еліптичних кривих. Частина 3. Установлення ключів”, ДСТУ ГОСТ 28147-2009 “Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования” міждержавних стандартах ГОСТ 34.310-95 “Информационные технологии. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асиметричного криптографического алгоритма  та  ГОСТ 34.311-95 “Информационная технология.  Криптографическая защита информации. Функция хеширования” та Технічних специфікаціях форматів представлення базових об’єктів національної системи електронного цифрового підпису, затверджених наказом Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України, Державного департаменту з питань зв’язку та інформатизації Міністерства транспорту та зв’язку України від 11.09.2006 №  99 /166.

 

1.4. Якщо в Технічних специфікаціях існують розходження із нормативно-правовими актами та нормативними документами, зазначеними у пункті 1.3 Технічних специфікацій, то використовуються положення цих Технічних специфікацій.

 

1.5. Технічні специфікації визначають тип інформаційного повідомлення “ContentInfo”, що включає в себе один певний тип даних, який в свою чергу може також включати дані певного типу.

 

1.6. Тип повідомлення “ContentInfo” представлено у нотації ASN.1, визначеній у міжнародному стандарті ISO/IEC 8824 “Information technologyOpen Systems InterconnectionSpecification of Abstract Syntax Notation One (ASN.1)”.

 

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

 

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

 

1.8.1. На тип “ContentInfo” вказує такий об’єктний ідентифікатор:

 

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

 

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

 

ContentInfo ::= SEQUENCE {

         contentType               ContentType,

         content                      [0] EXPLICIT ANY DEFINED BY contentType }

 

ContentType ::= OBJECT IDENTIFIER

 

1.8.3. Поля структури “ContentInfo” мають наступні значення:

 

contentType” – об’єктний ідентифікатор, що вказує на тип пов’язаних з ним даних, наприклад тип “захищені дані”;

Content” – пов’язані з об’єктним ідентифікатором дані. Тип даних однозначно визначається полем “contentType”.

 

1.9. Повідомлення, що містить цифровий конверт має тип даних “еnveloped-data” (“захищені дані”). Повідомлення “захищені дані” включається в повідомлення інформаційного типу “ContentInfo”.

Обєктний ідентифікатор, який вказує на те, що структура “ContentInfo” містить дані типу “захищені дані”:

 

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

 

1.10. При формуванні цифрового конверта застосовується протокол управління ключами. Для шифрування даних застосовується криптографічний алгоритм, визначений у національному стандарті України ДСТУ ГОСТ 28147-2009.

 

1.11. Повідомлення “захищені дані” може включати в себе інші типи повідомлень, наприклад “дані” (“data”), “підписані дані” (“signed-data”)”. При включенні в повідомлення “захищені дані” повідомлення типу “дані” автентифікація відправника цих даних не забезпечується. При включенні в повідомлення “захищені дані” повідомлення типу “підписані дані” забезпечується автентифікація відправника цих даних.

 

1.12. Формат повідомлення “підписані дані” (“signed-data”) встановлюється технічними специфікаціями форматів підписаних електронних даних.

 

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

 

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

 

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

 

 

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

 

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

 

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

 

2.1.2. Зашифрований симетричний ключ сеансу та інша інформація для одержувача включається в структуру “RecipientInfo”. Структура  RecipientInfo” наводиться у пункті 3.4 Технічних специфікацій.

 

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

 

2.1.4. Структура “RecipientInfo” разом із зашифрованими даними вкладається у структуру “Enveloped-data”. Структура “Enveloped-data” наводиться у пункті 3.1 Технічних специфікацій.

 

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

 

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

 

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

Інформація для одержувача, яка необхідна для реалізації протоколу управління ключами з боку одержувача, а також розшифрування  повідомлення подається в структурі “RecipientInfo”. Структура  RecipientInfo” наводиться  у пункті 3.4 Технічних специфікацій.

 

2.2.2. Одержувач за допомогою симетричного ключа сеансу розшифровує дані.

 

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

 

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

 

2.3.2. Механізми узгодження ключів повинні використовувати криптографічні перетворення в групі точок еліптичної кривої згідно з національним стандартом України ДСТУ ISO/IEC 15946-3 та/або криптографічні перетворення в простому полі Галуа згідно з національним стандартом України ДСТУ ISO/IEC 11770-3.

 

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

 

2.3.3.1. Статичний механізм узгодження ключів – автономне узгодження ключів типу Діффі-Геллмана згідно з пунктом 8.2 національного стандарту України ДСТУ ISO/IEC 15946-3.

 

2.3.3.2. Динамічний механізм узгодження ключів – узгодження ключів типу Ель-Гамаля згідно з пунктом 8.3 національного стандарту України ДСТУ ISO/IEC 15946-3.

 

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

 

2.3.4.1. Статичний механізм узгодження ключів – протокол узгодження ключів згідно з пунктом 6.1 національного стандарту України ДСТУ ISO/IEC 11770-3.

 

2.3.4.2. Динамічний механізм узгодження ключів – протокол узгодження ключів згідно з пунктом 6.2 національного стандарту України ДСТУ ISO/IEC 11770-3.

 

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

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

 

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

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

 

2.3.7. Особливості кодування параметрів криптографічного алгоритму визначено у пункті 3.5.4.4 Технічних специфікацій.

 

ІІІ. Представлення структури “захищені дані”

 

3.1. Структура “захищені дані” має такий формат:

 

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

 

3.2. Поля структури “EnvelopedData

 

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

 

3.2.2. Поле “originatorInfo” містить сертифікати відкритих ключів та списки відкликаних сертифікатів. Поле є необов’язковим.

 

3.2.3. Поле “recipientInfos” містить набір інформації для одержувача.

 

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

 

3.2.5. Поле “Unprotected Attrs” містить набір атрибутів, що не шифруються разом з повідомленням. Зазначене поле не використовується.

 

3.3. Поля структури “EncryptedContentInfo

 

3.3.1. Поле “contentType” вказує на тип даних.

 

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

 

3.3.4. Поле “encryptedContent” містить зашифровані дані. Поле є необов’язковим. У разі відсутності поля “encryptedContent” вважається, що зашифровані дані представляються у інший спосіб.

 

3.4. Структура “RecipientInfo” має такий формат:

 

RecipientInfo ::= CHOICE  {

kari             [1] KeyAgreeRecipientInfo}

 

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

 

3.4.1. Структура “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.4.2. Поля структури “KeyAgreeRecipientInfo

 

3.4.2.1. Поле “Version” визначає номер версії синтаксису, який повинен мати значення 3.

 

3.4.2.2. Поле “originator” містить ідентифікаційні дані відправника. Тип цих даних залежить від використаного механізму (протоколу) узгодження симетричного ключа КШК.

 

3.4.2.2.1. При застосувані механізму автономного узгодження ключів типу Діффі-Геллмана, то в якості ідентифікатра відправника повинні викристовуватися ім’я відправника та серійний номер сертифікату відкритого ключа відправника “issuerAndSerialNumber” або ключ шифрування відправника “subjectKeyIdentifier”.

 

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

 

3.4.2.2.3. При використанні динамічного механізму  узгодження ключа  Ель-Гамаля згідно з пунктом 8.3 національного стандарту України ДСТУ ISO/IEC 15946-3, поле “originatorKey publicKey” повинно містити відкритий ключ відправника (маркер), що має такий формат:

 

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

 

3.4.2.2.4. При використанні статичного механізму узгодження ключа, поле “originator” повинно містити ідентифікаційні дані відправника (ім’я видавника сертифікату та серійний номер чи ідентифікатор відкритого ключа видавника).

 

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

 

3.4.2.4. Поле “keyEncryptionAlgorithm” вказує на алгоритм шифрування симетричного ключа КШД та пов’язані з ним параметри, що застосовується для шифрування симетричного ключа КШД на узгоджувальному ключі КШК.

 

3.4.2.5. Поле “recipientEncryptedKeys” містить ідентифікатор одержувача та зашифрований ключ КШД.

 

3.4.2.6. Поле “KeyAgreeRecipientIdentifier” є структурою з вибором альтернативи “issuerAndSerialNumber”, що вказує за розпізнавальним ім’ям на центр сертифікації ключів та серійний номер сертифікату відкритого ключа одержувача, що використовується відправником при генерації узгодженого ключа КШК в протоколі Діффі-Геллмана узгодження ключа.

 

3.4.2.7. Поле “encryptedKey” містить симетричний ключ КШД, зашифрований на узгодженому ключі КШК.

 

3.4.3. Особливості синтаксису структури “KeyAgreeRecipientInfo

 

3.4.3.1. Ідентифікатор протоколу (алгоритму) узгодження ключа вказується в полі “EnvelopedData RecipientInfos KeyAgreeRecipientInfo Originator originatorKey algorithm”.

 

3.4.3.2. У Технічних специфікаціях визначаються алгоритми узгодження ключа “id-ESDH-ua” (у циклічній групі простого поля) та “id-EСDH-ua” (в групі точок еліптичної кривої). Алгоритм узгодження ключа ESDH визначається у пункті 4.4 Технічних специфікацій. Алгоритм узгодження ключа EСDH визначається у пункті 4.4 Технічних специфікацій.

 

3.4.4.3. На використання алгоритму узгодження ключа “id-ESDH-ua” вказує такий об’єктний ідентифікатор:

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

 

3.4.4.4. На використання алгоритму узгодження ключа “id-EСDH-ua” вказує такий об’єктний ідентифікатор:

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

 

3.4.4.5 Параметри алгоритму ESDH:

 

ESDHParams::=SEQUENCE  {

P                      INTEGER,

Q(q)               INTEGER,                                

A(a)               INTEGER

x0                  INTEGER OPTIONAL,

c                      INTEGER OPTIONAL,

d                      INTEGER OPTIONAL}

 

3.4.4.6. Значення полів структури “ESDHParams” наведено у таблиці 3.

 

Таблиця 3.

 

Р

характеристика основного поля

Q

порядок циклічної підгрупи

A

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

x0

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

С

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

D

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

 

3.4.4.7. При використанні (динамічного) механізму узгодження ключа (згідно з пунктом 6.2 національного стандарту України ДСТУ ISO/IEC 11770-3), поле “originatorKey publicKey” повинно містити відкритий ключ відправника (маркер), що має такий формат:

 

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

 

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

 

3.4.4.9. При використанні статичного механізму узгодження ключа згідно з пунктом 6.1 національного стандарту України ДСТУ ISO/IEC 11770-3, поле “originator” повинно містити ідентифікаційні дані відправника (ім’я видавника, тобто хто виготовив сертифікат) та серійний номер чи ідентифікатор відкритого ключа видавника.

 

3.5. Особливості кодування параметрів криптографічного алгоритму у сертифікаті відкритого ключа одержувача, що застосовується у протоколі узгодження ключа КШК.

 

3.5.1. Формат сертифікату шифрування повинен відповідати формату сертифіката відкритого ключа, визначеному в розділі 1 Технічних специфікацій форматів представлення базових об’єктів національної системи електронного цифрового підпису, затверджених наказом Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України та Державного департаменту з питань зв’язку та інформатизації Міністерства транспорту та зв’язку України від 11.09.2006 № 99/166, за виключенням полів “subjectPublicKeyInfo”.

В сертифікаті шифрування додатково від сертифікату відкритого ключа повинно бути в розширенні “Використання ключа” (“KeyUsage”) встановлено значення “Узгодження ключа” (“keyAgreement”).

 

3.5.2. Відкритий ключ та параметри криптографічних алгоритмів розміщуються в полі “subjectPublicKeyInfo”.

 

3.5.3.  Параметри та об’єктний ідентифікатор алгоритму “ESDH

 

3.5.3.1. На алгоритм “ESDH” вказує такий об’єктний ідентифікатор:

 

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

 

3.5.3.2.  Параметри алгоритму “ESDH” повинні бути представлені такою структурою:

 

ESDHParameters ::=  SEQUENCE {

p                                   INTEGER,

q                                   INTEGER,

a                                   INTEGER,

x0                                  INTEGER OPTIONAL,

c                                    INTEGER OPTIONAL,

d                                   INTEGER OPTIONAL }

 

3.5.3.3.  Значення полів структури “ESDHParameters” наведено у таблиці 1.

 

Таблиця 1.

 

p

модуль, просте число 21020 < p < 21024

q

порядок циклічної групи, просте число 2254 < q < 2256, є дільником для (р – 1)

а

твірний елемент циклічної групи, 1< a < p – 1, при цьому аq(mod p) = 1

x0

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

с

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

d

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

 

3.5.4.  Параметри та об’єктний ідентифікатор алгоритму “EСDH

 

3.5.4.1. На алгоритм “EСDH” вказує такий об’єктний ідентифікатор:

 

id-EСDH-ua OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804 ) root (2) security(1) cryptography(1) pki(1) pki-alg(1) pki-alg-asym (3) asym-eсdh (3)}

 

3.5.4.2. Параметри алгоритму “EСDH” повинні бути представлені такою структурою:

 

EСDHParams::= SEQUENCE {

            version                             [0] EXPLICIT INTEGER    DEFAULT 0,

            f                                      BinaryField,

            a                                     INTEGER (0..1),

            b                                     OCTET STRING,

            n                                     INTEGER,

            bp                                    CHOICE {OCTET STRING, NULL}}

 

BinaryField ::= SEQUENCE {

           M                       INTEGER,

                                      CHOICE {

                                                                   Trinomial,

                                                                   Pentanomial}}

 

   Trinomial::= INTEGER  

 

    Pentanomial::= SEQUENCE {

             k                      INTEGER,

             j                       INTEGER,

             l                       INTEGER}

 

3.5.4.3. Значення полів структури “EСDHParams” наведено у таблиці 2.

 

Таблиця 2.

 

f

основне поле

a             

коефіцієнт A еліптичної кривої

b             

коефіцієнт B еліптичної кривої

n             

порядок базової точки (додатне ціле)

bp           

базова точка еліптичної кривої або ознака її відсутності

 

M  INTEGER,

ступінь розширення основного поля

 

Trinomial

примітивний тричлен

 

Pentanomial

примітивний п’ятичлен

 

3.5.4.4.  Поля параметрів еліптичної кривої, що мають тип “OCTET STRING” мають наступне кодування.

 

3.5.4.4.1. Кодування коефіцієнту В еліптичної кривої, базової точки еліптичної кривої “bp”, а також відкритого ключа, здійснюється за форматом “Little-Endian”. Представлення байтів повинно здійснюватися у прямому порядку.

 

3.5.4.4.2. На застосування алгоритму “EСDH” у поліноміальному базисі вказує такий об’єктний ідентифікатор:

 

id-EСDH-ua PB(1)

 

3.5.4.4.3. На застосування алгоритму “EСDH” у оптимальному нормальному базисі вказує такий об’єктний ідентифікатор:

 

id-EСDH-ua ONB(2)

 

3.5.4.4.4. Для зображення базової точки еліптичної кривої “bp” використовується такий формат:

 

bp OCTET STRING

 

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

 

3.5.4.4.6. Для зображення коефіцієнта “B” еліптичної кривої використовується такий формат:

 

b OCTET STRING

 

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

 

3.5.4.4.9. Для зображення відкритого ключа використовується формат:

 

PublicKey:: = OCTET STRING

 

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

 

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

 

3.5.4.5. Параметри алгоритму EСDH:

 

EСDHParams::= SEQUENCE {

version              [0] EXPLICIT INTEGER    DEFAULT 0,

f                        BinaryField,

a                       INTEGER (0..1),

b                       OCTET STRING,

n                       INTEGER,

bp                     CHOICE {OCTET STRING, NULL}}

 

BinaryField ::= SEQUENCE {

         M                      INTEGER,

         CHOICE {

                                 Trinomial,

                                 Pentanomial}

 

Trinomial::= INTEGER  

 

Pentanomial::= SEQUENCE {

K                      INTEGER,

j                       INTEGER,

l                       INTEGER }

 

Значення полів структури “ECDHParams” наведено у таблиці 4.

 

 

Таблиця 4.

 

f

основне поле

a             

коефіцієнт A еліптичної кривої

b             

коефіцієнт B еліптичної кривої

n             

порядок базової точки (додатне ціле)

bp           

базова точка еліптичної кривої або ознака її відсутності

M  INTEGER,

ступінь розширення основного поля

Trinomial

примітивний тричлен

Pentanomial

примітивний п’ятичлен

 

3.5.4.6. Кодування полів здійснюється відповідно до пункту 3.5.4.4  Технічних специфікацій.

 

3.6. Особливості кодування параметрів алгоритму захисту ключа шифрування даних “KeyWrapAlgorithm

 

3.6.1. Ідентифікатор алгоритму захисту ключа шифрування даних “KeyWrapAlgorithm та пов’язані з ним параметри вказується в полі “EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm”. Ключ узгодження КШК формується згідно механізмів ( протоколів)  узгодження ключа ESDH або EСDH:

 

KeyWrapAlgorithm ::= AlgorithmIdentifier

 

3.6.2. “KeyWrapAlgorithm algorithmповинен містити ідентифікатор алгоритму id-Key-Wrap-ua:

 

id-Key-Wrap-ua OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804 ) roo t (2)security(1) cryptography(1) pki(1) pki-alg(1) pki-alg-extra (4) key-wrap-algo (1) }

 

3.6.3. Синтаксис поля KeyWrapAlgorithm algorithm parameters наступний:

 

UAKeyWrapParameters ::= SEQUENCE {
            dke                              Gost28147-89-DKE,
           
shiftBits            INTEGER { gost28147-89-block(64) } }

Gost28147-89-DKE ::= OCTET STRING (SIZE (64))

 

3.6.4. Значення полів структури Gost28147-89-ParamSet наведено у таблиці 5.

 

Таблиця 5.

 

Dke

довгостроковий ключовий елемент

ShiftBits

Параметри шифрування

 

3.6.5. Довгостроковий ключовий елемент обирається з додатку 1 до Інструкції про порядок постачання і використання ключів до засобів криптографічного захисту інформації, затвердженої наказом Адміністрації Держспецзв’язку від 12.06.2007 № 114, зареєстрованого в Міністерстві юстиції України за № 729/13996 від 25.06.2007.

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

 

3.6.6. Зашифрований симетричний ключ КШД розміщується в полі “EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey”.

 

EncryptedKey ::= OCTET STRING

 

Поле “encryptedKey” повинно інкапсулювати “Gost28147-89-EncryptedKey”

 

Gost28147-89-EncryptedKey ::=   SEQUENCE {

encryptedKey               Gost28147-89-Key,
            macKey                                    Gost28147-89-MAC}

 

Gost28147-89-MAC ::= OCTET STRING (SIZE (1..4))

 

3.6.7. Узгоджувальний ключ КШК формується з використанням  особистого  ключ, що відповідає відкритому ключу в полі “originator” та відкритого ключа одержувача (обраного із сертифікату одержувача) по алгоритму ESDH або EСDH. Після формування КШК, за алгоритмом захисту ключа (“KeyWrapAlgorithm”), створюються CEK_ENC, CEK_MAC та UKM. Для шифрування\розшифрування використовуються параметри алгоритму, визначені в структурі “UAKeyWrapParameters”.

3.6.8. Зашифрований ключ CEK_ENC розміщується у полі “Gost28147-89-EncryptedKey encryptedKey”, його імітовставка CEK_MAC розміщується у полі “Gost28147-89-EncryptedKey macKey”. UKM розміщується в полі “KeyAgreeRecipientInfo ukm” (8 октетів).

 

3.7. Особливості кодування структури “EncryptedContentInfo” для алгоритму шифрування даних національного стандарту України ДСТУ ГОСТ 28147-2009

 

3.7.1. Ідентифікатор алгоритму шифрування даних розміщується в полі “EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm”. Алгоритм шифрування даних використовується для шифрування даних, що розміщуються в полі “EnvelopedData EncryptedContentInfo encryptedContent”.

На алгоритм шифрування даних національного стандарту України ДСТУ ГОСТ 28147-2009 вказує такий об’єктний ідентифікатор:

 

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

 

3.7.2. Параметри алгоритму шифрування даних національного стандарту України ДСТУ ГОСТ 28147-2009 мають таку структуру:

 

Gost28147-89- uaParameters ::=

SEQUENCE {

iv                                            Gost28147-89-IV,

dke                                          Gost28147-89-DKE }

 

Gost28147-89-IV ::= OCTET STRING (SIZE (8))

 

Поле “iv” містить вектор ініціалізації, що обирається випадково для кожного повідомлення. Не допускається використання однакового вектора ініціалізації для декількох різних повідомлень. 

 

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

 

 

ІV. Механізми  узгодження ключа EСDH та ESDH

 

 

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

 

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

 

4.3. Механізми узгодження ключа ESDH

 

4.3.1. Механізми узгодження ключа ESDH реалізовано з використанням протоколу узгодження ключів згідно з пунктом 6.1 (статичний механізм) або пунктом 6.2 (динамічний механізм) національного стандарту України ДСТУ ISO/IEC 11770-3.

 

4.3.2. KШK становить собою 256-бітове геш-значення, що обчислюється від 1024-бітового значення розділеної таємниці згідно з пунктом 6.1 або пунктом 6.2 національного стандарту України ДСТУ ISO/IEC 11770-3) у наступній послідовності.

 

4.3.2.1. Обчислюється значення розділюваної таємниці K(x,y) = a^(x*y) (mod p), де

“x” – особистий ключ відправника,

a^x” – відкритий ключ відправника,

“y” – особистий ключ одержувача,

a^y” – відкритий ключ одержувача,

p – характеристика поля,

a – твірний елемент циклічної підгрупи.

 

4.3.2.2. Обчислюється 256-бітове геш-значення від розділюваної таємниці K(x,y).

 

4.3.2.2.1. При статичному механізмі узгодження ключа, КШК формується таким чином:

 

 KШK(x,y) = gost 34.311 (K(x,y) | UKM);

 

ДКЕ (заповнення S-Box) обирається з “KeyWrapAlgorithm KeyWrapParameters encryptionParamSet dke”;

 

UKM – 8 випадкових октетів.

 

4.3.2.2.1. При динамічному механізмі узгодження ключа, КШК формується таким чином:

 

KШK(x,y) = gost 34.311 (K(x,y) | UKM );

 

ключові пари (x,a^x) та (y,a^y) повинні відповідати ГОСТ 34.310-95 (для 1020< р<1024 біт).

 

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

 

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

 

4.4. Механізми  узгодження ключа EСDH

 

4.4.1. Механізм узгодження ключа EСDH заснований на протоколі автономного узгодження ключів типу Діффі-Гелмана (KANIDH) згідно з пунктом 8.2 (статичний механізм) або пунктом 8.3 (динамічний механізм) національного стандарту України ДСТУ ISO/IEC 15946-3 у групі точок еліптичної кривої над полем F(m^2) без кофакторного множення.

 

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

 

4.4.3. KШK становить 256-бітове геш-значення розділеної таємниці, що обчислюється згідно з протоколом встановлення ключа Діффі-Гелмана в групі точок еліптичної кривої над полем F(m^2).

 

4.4.4. При статичному механізмі узгодження ключа, КШК формується наступним чином.

 

4.4.4.1. Відправником обчислюється значення точки еліптичної кривої:

,

а отримувачем

= , де

 – особистий ключ відправника,  – відкритий ключ відправника (, G = bp базова точка еліптичної кривої).

 – особистий ключ одержувача,  – відкритий ключ одержувача (, Gбазова точка еліптичної кривої).

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

 

4.4.4.2. Обчислюється 256-бітове геш-значення від розділеної таємниці :

 

KШK(А,В) = gost3411 ( | UKM),

 

ДКЕ обирається з “KeyWrapAlgorithm KeyWrapParameters encryptionParamSet dke”.

 

UKM – 8 випадкових октетів.

 

4.4.5. При динамічному механізмі узгодження ключа, КШК формується наступним чином.

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

 

4.4.5.1.1. Відправник виконує такі дії:

генерує таємне значення r, що належить діапазону ;

обчислює ;

формує маркер ключа КТA1 = , й посилає його отримувачу;

обчислює розділювану таємницю KAB = r × PB.

 

4.4.5.1.2. Отримувач виконує такі дії:

перевіряє, що КТА1 є дійсно точкою еліптичної кривої

обчислює розділювану таємницю, використовуючи свій особистий ключ та маркер КТА1

KAB =dB  × КТА1.

 

4.4.5.2. Обчислюється 256-бітове геш-значення від розділеної таємниці

 

KШK(А,В) = gost34311 (| UKM),

 

ДКЕ обирається з “KeyWrapAlgorithm KeyWrapParameters encryptionParamSet dke”.

 


Рахунки для благодійних внесків Збройним силам України

Благодійна фінансова підтримка прикордонникам та членам їх родин

Благодійний внесок для забезпечення діяльності Національної гвардії України



  Розробник: Корпорація Софтлайн (Україна)         
© Державна служба спеціального зв'язку та захисту інформації України