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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3. Скорочення та позначення:

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.4. Технічні специфікації засновані на міжнародних рекомендаціях:

RFC 2631 "Diffie-Hellman Key Agreement Method", June 1999;

RFC 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement for S/MIME, March 2000;

RFC 3279 "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", April 2002;

RFC 3281 "An Internet Attribute Certificate Profile for Authorization", April 2002;

RFC 3370 "Cryptographic Message Syntax (CMS) Algorithms", August 2002;

RFC 3394 "Encryption Standard (AES) Key Wrap Algorithm", September 2002;

RFC 3852 "Cryptographic Message Syntax (CMS) ", July 2004;

RFC 4490 - Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS), May 2006;

RFC 5008 "Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) ", September 2007;

RFC 5480 "Elliptic Curve Cryptography Subject Public Key", March 2009;

RFC 5652 "Cryptographic Message Syntax (CMS) ", September 2009.

національних стандартах України:

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

ДСТУ ISO/IEC 11770-3:2002 "Інформаційні технології. Методи захисту. Управління ключовими даними. Частина 3. Протоколи, що ґрунтуються на асиметричних криптографічних перетвореннях";

ДСТУ ISO/IEC 15946-3:2002 "Інформаційні технології. Методи захисту. Криптографічні методи, що ґрунтуються на еліптичних кривих. Частина 3. Установлення ключів";

ДСТУ ГОСТ 28147-2009 "Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования";

ДСТУ ISO/IEC 10118-3:2005 "Інформаційні технології. Методи захисту. Геш-функції. Частина 3. Спеціалізовані геш-функції".

міждержавних стандартах:

ГОСТ 34.310-95 "Информационные технологии. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе ассиметричного криптографического алгоритма";

ГОСТ 34.311-95 "Информационная технология. Криптографическая защита информации. Функция хеширования".

нормативно-правових актах:

Інструкції про порядок постачання і використання ключів до засобів криптографічного захисту інформації, затвердженої наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 12.06.2007 N 114 та зареєстрованої в Міністерстві юстиції України від 25.06.2007 за N 729/13996 (далі - Інструкція N 114);

Технічних специфікаціях форматів представлення базових об'єктів національної системи електронного цифрового підпису, затверджених наказом Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України, Державного департаменту з питань зв'язку та інформатизації Міністерства транспорту та зв'язку України від 11.09.2006 N 99/166 (надалі - "Формати представлення базових об'єктів").

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

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

2.1. Технічні специфікації визначають тип інформаційного повідомлення "ContentInfo", що містить тип даних "захищені дані".

2.2. Тип повідомлення "ContentInfo" представлено у нотації ASN.1, які визначені у міжнародному стандарті ISO/IEC 8824 "Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1) ".

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

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" мають такі значення:

"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.3.2.2) Технічних специфікацій. При включенні в повідомлення "захищені дані" повідомлення типу "підписані дані" завжди забезпечується автентифікація відправника цих даних.

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

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

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

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

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

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

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

3.1.2. Зашифрований симетричний ключ сеансу КШД та інша інформація для одержувача включається в структуру "RecipientInfo" (інформація одержувача). Структура "RecipientInfo" наводиться у пункті 4.4.7.2) Технічних специфікацій.

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

3.1.4. Структура "RecipientInfo" разом із зашифрованими даними вкладається у структуру "enveloped-data". Структура "enveloped-data" наводиться у пункті 4.1 Технічних специфікацій.

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

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

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

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

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

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

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

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

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

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

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

2) Динамічний механізм узгодження ключів ("Ephemeral-Static mode") - узгодження ключів типу Діффі-Геллмана, при якому одержувач має статичну, засвідчену сертифікатом Х.509 ключову пару, а відправник генерує нову (сеансову/динамічну) ключову пару для кожного повідомлення і посилає відкритий ключ цієї пари одержувачу, використовуючи "originatorKey" структури "RecipientInfo".

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

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

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

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

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

4.1. Формат структури "захищені дані" ("EnvelopedData")

Структура "захищені дані" має такий формат [RFC 3852/ RFC 5652]:

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

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

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

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

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

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

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

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

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

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

4.4.3. Поле "certs"

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

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

2) Поле "certs" має такий формат [RFC 3852/ RFC 5652]:

4.4.4. Поле "crls"

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

2) Поле "crls" має такий формат [RFC 3852/ RFC 5652]:

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

4.4.5. Поле "encryptedContentInfo"

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

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

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

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

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

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

4.4.7. Поле "recipientInfos"

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

2) Структура "RecipientInfo" має такий формат:

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

4) Структура "KeyAgreeRecipientInfo" має такий формат:

5) Поля структури "KeyAgreeRecipientInfo":

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

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

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

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

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

при застосуванні динамічного механізму узгодження ключів в циклічній групі поля поле "algorithm" в "originatorKey" повинно містити ідентифікатор відкритого ключа ГОСТ 34.310 -95:

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

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

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

Відкритий ключ ГОСТ 34.310-95 кодується як ціле, відповідно до "Форматів представлення базових об'єктів".

Стандарт ГОСТ 34.310-94 може використовуватись тільки з довжиною відкритого ключа 1024 бітів і тільки до 31.12. 2010;

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

поліноміальний базис:

оптимальний нормальний базис:

Відповідно до RFC 5008, параметри алгоритму поля "algorithm" в "originatorKey" повинні бути ASN.1 NULL.

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

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

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

Реалізації цієї Специфікації повинні обробляти "KeyAgreeRecipientInfo", що містить поле "ukm".

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

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

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

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

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

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

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

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

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

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

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

6) особливості синтаксису структури "KeyAgreeRecipientInfo":

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

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

parameters ::= KeyWrapAlgorithm

KeyWrapAlgorithm ::= AlgorithmIdentifier;

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

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

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

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

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

id-alg-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) DH-ua(3) );

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

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

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

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

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

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

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

з використанням, відповідно до національних стандартів України ДСТУ ISO/IEC 15946-3:2005, ДСТУ ISO/IEC 10118-3:2005 та міжнародних рекомендацій RFC 5008, геш-функцій SHA-1 (використання обмежено до 31.12.2010), 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-hSinglePass-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.4.7.6) г) Технічних специфікацій, застосовується як для статичного, так і для динамічного механізму узгодження ключа; при цьому ознакою динамічного механізму є не нульове значення поля "originatorKey", відповідно до абзацу третього пункту 4.4.7.5) в) Технічних специфікацій;

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

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

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

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

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

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

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

5.2.3. У разі еквівалентності параметрів встановлюється статичний механізм узгодження ключа, та перехід до кроку 5.

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

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

5.2.6. Виконати генерацію ключа шифрування ключа КШК (KDF - Key Derivation Function).

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

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

5.3.2. Отримати ASN.1 "EnvelopedData"

5.3.3. На основі аналізу "EnvelopedData" визначити механізм узгодження ключа. Ознакою динамічного механізму є ненульове значення поля "originatorKey", відповідно до пункту 4.4.7. 5) Технічних специфікацій.

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

5.3.5. Отримати із сертифіката відправника відкритий ключ.

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

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

5.3.8. У разі не еквівалентності параметрів - помилка, та припинити оброблення.

5.3.9. У разі еквівалентності параметрів перейти до пункту 5.3.10 Технічних специфікацій.

5.3.10. Якщо механізм динамічний - отримати динамічний відкритий ключ відправника із структури "EnvelopedData".

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

5.3.12. Виконати генерацію ключа шифрування ключа КШК (KDF - Key Derivation Function).

5.4. Параметри алгоритму узгодження ключа

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

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

1) Базуючись на міжнародних рекомендаціях RFC 3370 та Технічних специфікаціях "Формати представлення базових об'єктів", загальносистемні параметри алгоритму id-ESDH-ua можуть визначатися як ASN.1 структура:

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

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

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

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

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

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

1) Базуючись на міжнародних рекомендаціях RFC 5008, RFC 5480 та Технічних специфікаціях "Формати представлення базових об'єктів", параметри алгоритму в групі точок еліптичної кривої (ECDH) можуть бути визначені як така ASN.1 структура:

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

FR - індикатор представлення поля або зведений поліном (reduction polynomial) (алгоритм обчислення наведено у пункті 5.2.2.4));

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

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

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

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

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

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

ECPoint ::= OCTET STRING

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

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

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

в) байт РС встановлюється рівним 0х04 (ознака не стисненого формату): РС = 0х04.

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

Рядок байтів для представлення нульового елемента групи точок еліптичної кривої О = (0, 0) (infinity) повинен бути один нульовий байт: PО = 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"

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

Порівнюватися повинні параметри структури EСDHParameters, яка наведена у пункті 5.4.2.1) Технічних специфікацій. Порівняння повинно виконуватися покомпонентно (еквівалентність параметрів q, FR і т.д.) або як порівняння масивів байт DER-кодованої структури EСDHParameters.

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

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

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

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

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

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

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.

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

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

де:

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

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

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

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

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

де:

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