Пошук

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


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

(проект)

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

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

 

НАКАЗ

м. Київ

 

 

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

 

 

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

 

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

 

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

 

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

 

 

 

 

 

 

 


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

 

 

 

 

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

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

 

 

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

 

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

Вимоги цих Технічних специфікацій є обов’язковими для надійних засобів електронного цифрового підпису, програмно-технічних комплексів акредитованих центрів сертифікації ключів. Правильність реалізації наведених форматів у засобах ЕЦП повинна бути підтверджена сертифікатом відповідності або позитивним експертним висновком за результатами державної експертизи у сфері криптографічного захисту інформації.

 

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

 

Технічні специфікації засновані на міжнародних рекомендаціях:

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 № 114 та зареєстрованої в Міністерстві юстиції України від 25.06.2007 за № 729/13996 (далі - Інструкція №114);

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

 

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

 

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

 

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

 

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

 

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

 

Усі структури даних кодуються за правилами 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”.

 

Формат повідомлення “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”.

 

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

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

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

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

Приклад ASN.1 структури “захищені дані” наведений в додатку 1.

 

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

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

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

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

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

 

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

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

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

 

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

 

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

 

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.1. Одержувач згідно протоколу узгодження ключа за допомогою відкритого ключа відправника та особистого ключа одержувача формує узгоджений ключ, на якому розшифровує симетричний ключ сеансу КШД. Інформація для одержувача, яка необхідна для реалізації протоколу управління ключами з боку одержувача, а також для розшифрування повідомлення подається в структурі “RecipientInfo”. Структура “RecipientInfo” наводиться у пункті 4.4.7.2) Технічних специфікацій.

 

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

 

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

 

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

 

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

 

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

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

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

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

 

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

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

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

 

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

 

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

 

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

 

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

 

Формат структури “захищені дані”

Структура “захищені дані” має такий формат [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

 

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

 

Порядок формування “захищених даних”

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Поле “certs”

 

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

 

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

 

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”) має такий формат [RFC 3281]:

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
}

 

Поле “crls”

 

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

 

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, формат яких визначено у Технічній специфікації “Формат представлення базових об’єктів”.

 

Поле “encryptedContentInfo”

 

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

 

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

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

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

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

 

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

 

Поле “recipientInfos”

 

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

 

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

RecipientInfo ::= CHOICE {
         kari              [1] KeyAgreeRecipientInfo}

 

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

 

4) Структура “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

 

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

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

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

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

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

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

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

id-gost34310 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ukraine(804) root(2) security(1) cryptography(1) pki(1) pki-alg(1) pki-alg-asym (3) gost34310 (2) }

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

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

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

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

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

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

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

id-dstu4145PB OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         ukraine(804) root(2) security(1) cryptography(1) pki(1)
         pki-al(1) pki-alg-asym(3) dstu4145(1) PB(1) }

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

id-dstu4145ONB OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         ukraine(804) root(2) security(1) cryptography(1) pki(1)
         pki-alg(1) pki-alg-asym(3) dstu4145 (1) ONB (2) }

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

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

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

Відкритий ключ ДСТУ 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” має таке значення:

RecipientKeyIdentifier ::= SEQUENCE {
         subjectKeyIdentifier  SubjectKeyIdentifier,
         date                                GeneralizedTime OPTIONAL,
         other                               OtherKeyAttribute OPTIONAL }

SubjectKeyIdentifier ::= OCTET STRING

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

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

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

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

 

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

 

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

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

KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

AlgorithmIdentifier ::= SEQUENCE {
         algorithm                OBJECT IDENTIFIER,
         parameters             ANY DEFINED BY algorithm}

Поле “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” – не обов’язковий, застосовується для динамічного механізму узгодження ключа;

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

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

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

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

з використанням геш-функції ГОСТ 34.311: алгоритм з кофакторним множенням “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) pki(1) pkialg(1) pki-alg-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) 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 цих Технічних специфікацій.

 

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

 

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Отримати ASN.1 “EnvelopedData”

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

DHParameters ::= SEQUENCE {
         р                           INTEGER,
         q                           INTEGER,
         a                           INTEGER,
         validationParms        GOST34310ValidationParms OPTIONAL,
                                      -- параметри валідації
         dke                        OCTET STRING OPTIONAL }

GOST34310ValidationParms ::= SEQUENCE {
         x0                         INTEGER,
         c                           INTEGER,
         d                           INTEGER OPTIONAL }

 

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

Таблиця 1.

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”, як не обов’язкові, не повинні використовуватися в операції порівняння.

 

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

 

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

EСDHParameters ::= SEQUENCE {
         q                 INTEGER,
         FR                INTEGER,
         а                 INTEGER,
         b                 INTEGER,
         G                 ECPoint,
         n                 INTEGER,
         h                 INTEGER,
         dke              OCTET STRING OPTIONAL
}

де

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.

 

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

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

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

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

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

 

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

 

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 – відкритий ключ.

 

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

 

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

 

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

де:

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

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

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

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

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

 

3) Спільним секретом є координата хk точки K: Z = xk,

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

 

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

 

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

 

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

 

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

 

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

 

3) Якщо Z є елементом поля Fq, то воно є додатнім цілим числом, тобто двійковим (бітовим) рядком (bit string), якщо Z є елементом поля F(2m), то виконати перетворення елемента поля Z на додатне ціле число, як визначено у пункті 5.8 ДСТУ 4145-2002. Позначимо ціле число від Z як ZI.

 

 4) Виконати перетворення цілого ZI на рядок байтів ZZ у форматі Big-Endian. Перетворення цілого ZI на рядок байтів ZZ у форматі Little-Endian наведено у пункті 1.3.14.2 Технічних специфікацій “Формати представлення базових об’єктів”. Формат Big-Endian має зворотній порядок байтів щодо формату Little-Endian.

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

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

Приклад обчислення спільного секрету ZZ у циклічній групі поля наведений в додатку 3.

Приклади обчислення спільного секрету ZZ в групі точок еліптичної кривої наведені в додатку 4.

 

Функція формування ключа КШК (KDF-функція)

 

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

 

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

 

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

 

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

 

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

 

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

 

2) Формування ключового матеріалу КМ:

KM = H (ZZ || OtherInfo),

де:

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

H – геш-функція, визначається ідентифікаторами алгоритму узгодження ключів, що визначені у пункті 4.4.7.6) г) Технічних специфікацій;

ZZ – спільний секрет, обчислений відповідно до пункту 5.5.3 Технічних специфікацій;

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” збільшується на одиницю з кожним циклом виконання функції формування ключового матеріалу КМ (пункт 5.6.3.2) Технічних специфікацій) під час генерації глюча КШК;

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

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

 

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

 

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

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

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

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

КМ = КМ1 || KM2 || …

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

 

6) Параметр “partyAInfo”

Якщо параметр “partyAInfo”, як не обов’язковий, не буде використовуватися, то у випадках зазначених у пунктах 5.6.3.4) а) та  5.6.3.4) б) Технічних специфікацій для різних повідомлень буде формуватися один і той же ключ шифрування КШК. Для того щоб уникнути цього, у разі статичного механізму вимагається (а уразі динамічного – рекомендується) генерувати випадкове значення “partyAInfo” для кожного повідомлення, та використовувати під час формування КШК.

 

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

В додатку 5 Технічних специфікацій наведені приклади для алгоритму узгодження ключа “id-ESDH-ua”, тобто з використанням геш-функції ГОСТ 34.311. ДКЕ позначено через sBox (SBOX-1 – це ДКЕ №1 із переліку рекомендованих Інструкцією №114).

В наведених прикладах у якості KeyWrapAlgorithm (“algorithm”) використовується ГОСТ 28147-87 у режимі гамування (“id-gost28147-ofb”, розділ 7 Технічних специфікацій) чи гамування із зворотнім зв’язком (“id-gost28147-сfb”, розділ 7 Технічних специфікацій). Ці алгоритми не є Wrap-алгоритмами, що викладені у розділі 6 Технічних специфікацій, і використовуються тут лише для цілей наведення прикладів.

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

 

KDF-функція в групі точок еліптичної кривої (ECDH)

 

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

 

2) Формування ключового матеріалу КМ

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

де:

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

H – геш-функція, визначається ідентифікаторами алгоритму узгодження, що визначені у пункті 4.4.7.6) г) Технічних специфікацій;

ZZ – спільний секрет, обчислений відповідно пункту 5.5.3 Технічних специфікацій;

“counter” – це 32-х бітне число, яке представлено як бітовий вектор (чотири байти), записаного у зворотному порядку. Початковим значенням “counter” є 1 (одиниця) для будь-якого ZZ, а його бітовий вектор є “00 00 00 01” (hex); значення counter збільшується на одиницю з кожним циклом виконання функції формування ключового матеріалу КМ під час генерації глюча КШК, згідно з пунктом 5.6.3.5) Технічних специфікацій;

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”, наведеної у пункті 5.6.3.3) Технічних специфікацій), який генерує відправник. В CMS це значення розміщується в полі “ukm” (“UserKeyingMaterial”) (закодоване як OCTET STRING) структури “KeyAgreeRecipientInfo”. Довжина “partyAInfo” повинна бути 512 біт (64 байти);

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

 

5) Параметр “entityUInfo”

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

 

6) Приклади обчислення ключа КШК

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

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

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

ДКЕ для геш-функції ГОСТ 34.311 позначено через sBox (SBOX-1 – це ДКЕ №1 із переліку рекомендованих Інструкцією №114).

 

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

 

Алгоритм захисту ключа шифрування даних “KeyWrapAlgorithm”, що ґрунтується на стандарті ДСТУ ГОСТ 28147:2009 і міжнародних рекомендаціях RFC 3217, та позначається як “GOST28147Wrap”.

 

Призначення алгоритму “GOST28147Wrap”

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

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

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

 

Ідентифікатор алгоритму захисту “GOST28147Wrap”

Ідентифікатор алгоритму захисту ключа шифрування даних
“KeyWrapAlgorithm” вказується як параметр поля “EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm” згідно з пунктом 4.4.7.6) а) Технічних специфікацій.

 

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

KeyWrapAlgorithm ::= AlgorithmIdentifier

 

Синтаксис “KeyWrapAlgorithm” алгоритму GOST28147Wrap

GOST28147WrapParameters ::= CHOICE {
         NULL,
         parameters             GOST28147Parameters
},

GOST28147Parameters ::= SEQUENCE {
         iv                          OCTET STRING (SIZE (8)),
         dke                        OCTET STRING (SIZE (64)) }

де

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

“dke” – довготривалий ключовий елемент (ДКЕ), відповідно до міждержавного стандарту ДСТУ ГОСТ 28147:2009.

 

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

Використання “GOST28147Wrap” з параметрами алгоритму, що не є NULL, не є предметом цих Технічних специфікацій.

 

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

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

 

Алгоритм GOST28147Wrap

 

Усі структури, які задіяні в процесах зашифрування (визначається пунктом 6.8.2 Технічних специфікацій) та розшифрування (визначається пунктом 6.8.3 Технічних специфікацій), повинні бути представлені у форматі Little-Endian.

 

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

 

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

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

“dke” – довготривалий ключовий елемент (ДКЕ);

“KEK” – ключ шифрування ключа (КШК);

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

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

“result” – зашифровані ключові дані.

 

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

а) виконати ініціалізацію алгоритму вхідними даними “dke” та “КЕК”. Особливості ініціалізації щодо “dke” наведено у пункті 6.8.4 Технічних специфікацій;

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

Значення “dke” та ключ при обчисленні “KEK” беруться ті, що встановлені що встановлені під час виконання пункту 6.8.2.2) а) Технічних специфікацій.

ICV = МАС32(CEK, dke, КЕК) [4 байти].

Ймовірність “нав’язування невірних даних” (помилки при оцінюванні цілісності ключових даних) відповідно до ДСТУ ГОСТ 28147:2009 становить 2^(-32) = 0,0000000002;

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

CEKICV = CEK || ICV;

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

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

TEMP1 = GOST28147-CFB_encrypt(CEKICV, IV, dke, КЕК);

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

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

TEMP2 = IV || TEMP1;

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

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

IV1 = 0x4adda22c79e82105.

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

result = GOST28147-CFB_encrypt(TEMP3, IV1, dke, КЕК)

 

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

 

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

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

“result” – зашифровані ключові дані,

“dke” – довготривалий ключовий елемент (ДКЕ),

“KEK” – ключ шифрування ключа (КШК).

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

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

 

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

а) виконати ініціалізацію алгоритму вхідними даними “dke” та “КЕК”. Особливості ініціалізації щодо “dke” наведено у пункті 6.8.4 Технічних специфікацій;

б) виконати розшифрування “result” на алгоритмі ДСТУ ГОСТ 28147:2009 в режимі гамування із зворотнім зв’язком (GOST28147-CFB), використовуючи  “dke” та ключ “KEK”, що встановлені під час виконання пункту 6.8.3.2) а) Технічних специфікацій, та вектор ініціалізації “IV1”:

IV1 = 0x4adda22c79e82105,

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

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

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

TEMP2 = IV || TEMP1;

є) виконати розшифрування TEMP1 алгоритмом ГОСТ 28147 в режимі гамування із зворотнім зв’язком (GOST28147-CFB), використовуючи  “dke” та ключ “KEK”, що встановлені під час виконання пункту 6.8.3.2) а) Технічних специфікацій, та вектор ініціалізації “IV”, отриманий за результатами виконання пункту 6.8.3.2) в) Технічних специфікацій:

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

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

CEKICV = CEK || ICV;

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

Значення “dke” та ключ при обчисленні “KEK” беруться ті, що встановлені під час виконання пункту 6.8.3.2) а) Технічних специфікацій

ICV1 = МАС32(CEK, dke, КЕК) [4 байти];

 

є) Порівняти отриману за результатами виконання пункту  6.8.3.2) ж) контрольну суму “ICV” з обчисленою у пункті 6.8.3.2) з) Технічних специфікацій  “ ICV1”.

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

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

 

Особливості ініціалізаційних даних для “EnvelopedData”

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

Якщо значення “dke” відсутнє в параметрах алгоритму відритого ключа, то повинно братися за умовчанням значення ДКЕ №1 (SBOX-1), визначеного Інструкцією №114.

 

Приклади

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

Приклади обчислення за алгоритмом GOST28147Wrap наведені в додатку 8.

 

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

 

Об’єктні ідентифікатори алгоритмів національного стандарту ДСТУ ГОСТ 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) pki(1)
         pki-alg(1) pki-alg-sym(1) gost24147(1) ofb(2) };

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

 

Параметри алгоритмів ДСТУ ГОСТ 28147-2009

GOST28147Parameters ::= SEQUENCE {
         iv                          OCTET STRING (SIZE (8)),
         dke                        OCTET STRING (SIZE (64)) },

де:

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

“dke” – довготривалий ключовий елемент (ДКЕ), відповідно до національного стандарту ДСТУ ГОСТ 28147:2009 .

 

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

 

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

 

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

 

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

 

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

 

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

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

Якщо в розширенні “Використання ключа” (“KeyUsage”) встановлено значення “Узгодження ключа” (“keyAgreement”), то додатково може бути встановлено значення:

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

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

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

“незречення” (“nonRepudiation”);

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 


Додаток 1

до пункту 2.5

Технічних специфікацій

Форматів криптографічних

повідомлень. Захищені дані

 

Приклад ASN.1 структури “захищені дані”

 

SEQUENCE { -- contentInfo

    OBJECTIDENTIFIER = 1 2 840 113549 1 7 3  -- contentType = envelopedData

    CONTEXT_0 { -- content [0]

        SEQUENCE { -- envelopedData                

            INTEGER = 2 – version

                   -- originatorInfo  [0] absent

 

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

                CONTEXT_1 { -- kari [1] KeyAgreeRecipientInfo

                    INTEGER = 3 -- version

                    CONTEXT_0 { -- originator [0] EXPLICIT OriginatorIdentifierOrKey

                        CONTEXT_1 { -- originatorKey  [1] OriginatorPublicKey

                            SEQUENCE { -- OriginatorPublicKey

                                OBJECTIDENTIFIER = 1 2 840 10046 2 1 -- dhPublicNumber algorithm

                            -- parameters absent

                            }

                            BIT_STRING = 44 B9 26 32 13 77 AD 88 CD F5 9F 4B 4D A9 6C FF

38 60 EB 84 AB 45 E6 A3 F4 E2 94 27 97 F0 8D 29

A5 EB 1F 21 91 68 58 39 C8 F2 49 D8 99 DB 48 A8

9E 47 A5 9E 06 BE B4 F4 A0 86 01 10 C4 50 FB B1

F5 31 88 12 7B 15 18 70 F8 72 08 65 4F 51 A7 A3

96 18 E8 79 B4 A6 6C F1 B7 7A 61 26 F6 AF 4D 34

42 22 DD 80 F3 C7 42 CE 6A 1C 8C A6 24 E9 54 6A

A0 67 B1 80 DE BB B0 C4 FE BC 45 4C D2 EC 35 74

                                               -- publicKey

                        } -- end CONTEXT_1 -- originatorKey 

                    } -- end originator [0] EXPLICIT OriginatorIdentifierOrKey

 

                    CONTEXT_1 { -- ukm

                        OCTET_STRING = A974C4E9AA79D3CE5C74A4EDA5DB65F5C037D681F10A935F24A1DB9796EE878B79DBE9071123CE70248430720283D57D60D3D4F6A74D4CC2E089FACD5920A293

                    } -- end ukm

 

                    SEQUENCE { -- keyEncryptionAlgorithm

                        OBJECTIDENTIFIER = 1 2 840 113549 1 9 16 3 5 -- id-alg-ESDH

                        SEQUENCE { -- ESDH algorithm parameters

                            OBJECTIDENTIFIER = 1 2 840 113549 1 9 16 3 6 -- id_alg_CMS3DESwrap

                            NULL =                   -- CMS3DESwrap algorithm parameters

                        }

                    } -- end keyEncryptionAlgorithm

 

SEQUENCE { -- recipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey

                        SEQUENCE { -- RecipientEncryptedKey

                            SEQUENCE { -- rid KeyAgreeRecipientIdentifier

                                SEQUENCE { -- issuerAndSerialNumber

                                    SET { -- issuer Name

                                        SEQUENCE {

                                            OBJECTIDENTIFIER = 2 5 4 3

                                            PRINTABLESTRING = CarlDSS

                                        }

                                    } -- end issuer  Name

                                }

                                INTEGER = 201 -- serialNumber

                            } -- end rid KeyAgreeRecipientIdentifier

 

                            OCTET_STRING = 97A21C9B1D72034CFA1FCEDAAE8549E10D3204978043CB00496036A7DD4B0EE5D6A87BBA669497A7

                                      -- encryptedKey

                        } -- end RecipientEncryptedKey

 

                    } -- end recipientEncryptedKeys 

                } -- end  kari KeyAgreeRecipientInfo

            } -- end RecipientInfos

 

            SEQUENCE { -- encryptedContentInfo

                OBJECTIDENTIFIER = 1 2 840 113549 1 7 1 -- contentType = Data

                SEQUENCE { --contentEncryptionAlgorithm

                    OBJECTIDENTIFIER = 1 2 840 113549 3 7 -- DES-EDE3-CBC

                    OCTET_STRING = 37E77ED71617C8AC -- IV

                } -- end contentEncryptionAlgorithm

                CONTEXT_0 =  -- encryptedContent

6AF2B89A5865B2ADF43AA031B2BDF7527AEB2BFB04770FE259C633BB05FD0CEA

            } -- end encryptedContentInfo

                   -- absent: unprotectedAttrs

        } -- end EnvelopedData

    } -- end content [0]

} -- end contentInfo


 

 

 

Додаток 2

до пункту 5.5.3.4)

Технічних специфікацій

Форматів криптографічних

повідомлень. Захищені дані

 

 

Приклади перетворення елемента поля на рядок байтів у форматі Big-Endian

 

Приклад 1 (пункт 1.3.14.2 Технічних специфікацій “Формати

представлення базових об’єктів”).

Z = 1 1110 0011 0111

ZI = 7735

ZZ = 1E 37

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

 

Приклад 2.

ZI = 65048

ZZ = 00 FE 18

 

Приклад 3.

ZI = 1450621147818416422260325141022141529263703331843

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


 

 

Додаток 3

до пункту 5.5.3.4)

Технічних специфікацій

Форматів криптографічних

повідомлень. Захищені дані

 

Приклад обчислення спільного секрету ZZ у циклічній групі простого поля ( FFC DH, ГОСТ 34.310, 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

до пункту 5.5.3.4)

Технічних специфікацій

Форматів криптографічних

повідомлень. Захищені дані

 

 

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

 

Приклад 1. ECC DH, ДСТУ4145 ПБ, 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 ПБ, 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 ОНБ, m=173

curveOID=1.2.804.2.1.1.1.1.3.1.2.2.0

 

dA = 03 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 = 2C 1C E3 D0 85 F5 93 BF 26 64 25 35 BB 16 A7 F7 DD 53 10 46 A7 3D 2A


 

 

 

 

Додаток 5

до пункту 5.6.3.7)

Технічних специфікацій

Форматів криптографічних

повідомлень. Захищені дані

 

Приклади узгодження ключа з використанням геш-функції ГОСТ 34.311

 

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

algorithm=1.2.804.2.1.1.1.1.1.1.2

sBox=SBOX-3

keyLen=256

partyAInfo=0123456789abcdeffedcba98765432010123456789abcdeffedcba98765432010123456789abcdeffedcba98765432010123456789abcdeffedcba9876543201

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

до пункту 5.6.4.6)

Технічних специфікацій

Форматів криптографічних

повідомлень. Захищені дані

 

Приклади обчислення КШК

 

Приклад 1. ДСТУ 4145 ПБ, m=163, “id-gost28147-оfb” 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=0123456789abcdeffedcba98765432010123456789abcdeffedcba98765432010123456789abcdeffedcba98765432010123456789abcdeffedcba9876543201

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 ПБ, m=163, “id-gost28147-сfb” 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 ОНБ, m=173, “id-gost28147-сfb” 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=0123456789abcdeffedcba98765432010123456789abcdeffedcba98765432010123456789abcdeffedcba98765432010123456789abcdeffedcba9876543201

dA=12 A2 1B B4 69 32 46 54 43 58 0E 76 BD 13 DC EF 00 BA 4F 98 6A B9

QAx=17 58 84 26 EB 79 F8 C6 FA 82 2D D3 0A 9E 21 A7 7B 7D AE 5E CD 8D

QAy=0A D3 C9 C4 83 74 9D 9B 52 F0 89 63 00 7F 21 31 A6 91 17 40 96 A6

dB=12 A2 1B B4 69 32 46 54 43 58 0E 76 BD 13 DC EF 00 BA 4F 98 6A B9

QBx=17 58 84 26 EB 79 F8 C6 FA 82 2D D3 0A 9E 21 A7 7B 7D AE 5E CD 8D

QBy=0A D3 C9 C4 83 74 9D 9B 52 F0 89 63 00 7F 21 31 A6 91 17 40 96 A6

ZZ=03 AC 78 AD A3 0F C2 CB C8 F8 4E 64 F4 09 0F 81 6A F6 B6 B0 68 F0

KEK=4D 0A EE 86 1B 17 C2 5E AD 82 AA 16 54 44 95 BC 79 DE C9 8C 3D 7B 85 BF 3C 3B DD 2F DC C9 B9 ED

 


 

 

Додаток 7

до пункту 6.9

Технічних специфікацій

Форматів криптографічних

повідомлень. Захищені дані

 

Обчислення імітовставки ДСТУ ГОСТ 28147-2009

 

Вхідні дані:

ДКЕ - значення ДКЕ №1 (SBOX-1), визначеного Інструкцією №114;

key – ключ, на якому здійснюється шифрування (“КЕК”);

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

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

МАС32 – імітовставка, 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

до пункту 6.9

Технічних специфікацій

Форматів криптографічних

повідомлень. Захищені дані

 

Приклади обчислення за алгоритмом GOST28147Wrap

 

 

Вхідні дані:

ДКЕ – значення ДКЕ №1 (SBOX-1), визначеного Інструкцією №114;

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

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

 

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

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

 

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

 

 

 

 


Держава турбується про тебе

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

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

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



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