Тип: Наказ
№ 739
Дата: 18 грудня 2012 р.
Статус: Втратив чинність
АДМІНІСТРАЦІЯ ДЕРЖАВНОЇ СЛУЖБИ СПЕЦІАЛЬНОГО ЗВ'ЯЗКУ ТА ЗАХИСТУ ІНФОРМАЦІЇ УКРАЇНИ
НАКАЗ
18.12.2012
м. Київ
N 739
Зареєстровано в Міністерстві юстиції України
14 січня 2013 р. за N 108/22640
Про затвердження Вимог до форматів криптографічних повідомлень
Відповідно до підпункту 7 пункту 4 Положення про Адміністрацію Державної служби спеціального зв'язку та захисту інформації, затвердженого Указом Президента України від 30 червня 2011 року N 717, пункту 4 розпорядження Кабінету Міністрів України від 09 вересня 2009 року N 1087-р "Деякі питання організації електронного документообігу та звітності", з метою створення умов технологічної сумісності засобів криптографічного захисту інформації
НАКАЗУЮ:
1. Затвердити Вимоги до форматів криптографічних повідомлень (далі - Вимоги), що додаються.
2. Установити, що акредитовані центри сертифікації ключів, замовники, розробники, виробники та організації, які експлуатують засоби криптографічного захисту інформації та надійні засоби електронного цифрового підпису в системах електронного документообігу, забезпечують застосування положень Вимог з 01 січня 2014 року.
3. Установити, що акредитовані центри сертифікації ключів забезпечують обслуговування посилених сертифікатів відкритих ключів, сформованих до дати набрання чинності Вимогами, та їх використання у надійних засобах електронного цифрового підпису та засобах криптографічного захисту інформації як сертифікати шифрування до закінчення строку чинності посилених сертифікатів відкритих ключів за умови відповідності параметрів криптографічного алгоритму відповідної ключової пари вимогам, наведеним у наказі Міністерства юстиції України, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 20 серпня 2012 року N 1236/5/453 "Про затвердження вимог до форматів, структури та протоколів, що реалізуються у надійних засобах електронного цифрового підпису", зареєстрованому в Міністерстві юстиції України 20 серпня 2012 року за N 1398/21710.
4. Установити, що надійні засоби електронного цифрового підпису та криптографічного захисту інформації, створювані відповідно до цих Вимог, забезпечують розшифрування даних, шифрування яких здійснювалося до дати набрання чинності Вимогами.
5. Директору Департаменту криптографічного захисту інформації Адміністрації Державної служби спеціального зв'язку та захисту інформації України в установленому порядку забезпечити подання цього наказу на державну реєстрацію до Міністерства юстиції України.
6. Цей наказ набирає чинності з дня його офіційного опублікування.
7. Контроль за виконанням цього наказу покласти на першого заступника Голови Державної служби спеціального зв'язку та захисту інформації України.
Голова Служби
Г. А. Резніков
ПОГОДЖЕНО:
Голова Державної служби України
з питань регуляторної політики
та розвитку підприємництва
М. Ю. Бродський
ЗАТВЕРДЖЕНО
Наказ Адміністрації Державної служби спеціального зв'язку та захисту інформації України
18.12.2012 N 739
Зареєстровано
в Міністерстві юстиції України
14 січня 2013 р. за N 108/22640
ВИМОГИ ДО ФОРМАТІВ КРИПТОГРАФІЧНИХ ПОВІДОМЛЕНЬ
I. Загальні положення
1.1. Ці Вимоги визначають синтаксис (формат представлення) криптографічних повідомлень (зашифрованих даних) в електронній формі, а також протоколи, які повинні застосовуватися для цього синтаксису з метою узгодження ключів. Установлення єдиних форматів криптографічних повідомлень має на меті визначення технічних умов щодо забезпечення сумісності засобів криптографічного захисту інформації різних розробників.
1.2. Положення цих Вимог є обов'язковими для засобів криптографічного захисту інформації (далі - КЗІ) та надійних засобів електронного цифрового підпису (далі - ЕЦП), що використовуються в системах електронного документообігу. Правильність реалізації у засобах КЗІ та ЕЦП наведених у цих Вимогах форматів і протоколів повинна бути підтверджена позитивним експертним висновком за результатами державної експертизи у сфері криптографічного захисту інформації.
1.3. У цих Вимогах терміни вживаються у таких значеннях:
дані -
повідомлення або частина повідомлення, яке не обробляють чи не змінюють у процесі обробки;
механізм узгодження ключа - статичний (Static-Static mode) або динамічний (Ephemeral-Static mode) механізм узгодження ключа, що визначений у цих Вимогах;
повідомлення "захищені дані" - повідомлення, що містить цифровий конверт;
протокол узгодження ключа - протокол Діффі-Геллмана обчислення ключа шифрування ключа (КШК) у циклічній групі поля або в групі точок еліптичної кривої;
симетричний ключ сеансу або ключ шифрування даних (КШД) - ключ сеансу, на якому здійснюється шифрування даних за алгоритмом, визначеним у ДСТУ ГОСТ 28147-2009;
узгоджений ключ ("key agreement") або ключ шифрування ключа (КШК) - симетричний ключ, на якому здійснюється шифрування симетричного ключа сеансу;
цифровий конверт ("enveloped-data") - зашифровані дані типу "дані" ("data") або "підписані дані" ("signed-data") разом із зашифрованим симетричним ключем.
Інші терміни вживаються у значеннях, наведених у Законі України "Про електронний цифровий підпис", Порядку акредитації центру сертифікації ключів, затвердженому постановою Кабінету Міністрів України від 13 липня 2004 року N 903, Правилах посиленої сертифікації, затверджених наказом Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України від 13 січня 2005 року N 3, зареєстрованих у Міністерстві юстиції України 27 січня 2005 року за N 104/10384 (із змінами).
1.4. У цих Вимогах скорочення мають такі значення:
CMS - синтаксис криптографічного повідомлення (Cryptographic Message Syntax);
DH - протокол узгодження ключів Діффі-Геллмана (Diffie-Hellman), що базується на криптографічних перетвореннях у полі Галуа; може використовуватися також позначення FFC DH (Finite Field Cryptography Diffie-Hellman);
ECDH - протокол Діффі-Геллмана (Diffie-Hellman), що базується на криптографічних перетвореннях у групі точок еліптичної кривої; може використовуватися також позначення ECC DH (Elliptic Curve Cryptography Diffie-Hellman);
ДКЕ - довгостроковий ключовий елемент.
1.5. Ці Вимоги розроблено з урахуванням Інструкції про порядок постачання і використання ключів до засобів криптографічного захисту інформації, затвердженої наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 12 червня 2007 року N 114, зареєстрованої в Міністерстві юстиції України 25 червня 2007 року за N 729/13996 (далі - Інструкція N 114); Вимог до формату посиленого сертифіката відкритого ключа, затверджених наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 20 серпня 2012 року N 1236/5/453, зареєстрованих у Міністерстві юстиції України 20 серпня 2012 року за N 1398/21710 (далі - Вимоги до формату посиленого сертифіката відкритого ключа); Вимог до формату списку відкликаних сертифікатів, затверджених наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 20 серпня 2012 року N 1236/5/453, зареєстрованих у Міністерстві юстиції України 20 серпня 2012 року за N 1400/21712 (далі - Вимоги до формату списку відкликаних сертифікатів); Вимог до формату підписаних даних, затверджених наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 20 серпня 2012 року N 1236/5/453, зареєстрованих у Міністерстві юстиції України 20 серпня 2012 року за N 1401/21713 (далі - Вимоги до формату підписаних даних); ДСТУ 4145-2002 "Інформаційні технології. Криптографічний захист інформації. Цифровий підпис, що ґрунтується на еліптичних кривих. Формування та перевіряння" (далі - ДСТУ 4145-2002); ДСТУ ISO/IEC 11770-3:2002 "Інформаційні технології. Методи захисту. Керування ключами. Частина 3. Механізми із застосуванням асиметричних методів" (далі - ДСТУ ISO/IEC 11770-3:2002); ДСТУ ISO/IEC 15946-3:2006 "Інформаційні технології. Методи захисту. Криптографічні методи, що ґрунтуються на еліптичних кривих. Частина 3. Установлення ключів" (далі - ДСТУ ISO/IEC 15946-3:2006); ДСТУ ГОСТ 28147-2009
"Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования" (далі - ДСТУ ГОСТ 28147-2009); ДСТУ ISO/IEC 10118-3:2005 "Інформаційні технології. Методи захисту. Геш-функції. Частина 3. Спеціалізовані геш-функції" (далі - ДСТУ ISO/IEC 10118-3:2005); ГОСТ 34.310-95 "Информационные технологии. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе ассиметричного криптографического алгоритма" (далі - ГОСТ 34.310-95); ГОСТ 34.311-95 "Информационная технология. Криптографическая защита информации. Функция хеширования" (далі - ГОСТ 34.311-95); RFC 2631 "Diffie-Hellman Key Agreement Method", June 1999 (далі - RFC 2631); RFC 3370 "Cryptographic Message Syntax (CMS) Algorithms", August 2002 (далі - RFC 3370); RFC 3852 "Cryptographic Message Syntax (CMS)", July 2004 (далі - RFC 3852); RFC 5652 "Cryptographic Message Syntax (CMS)", September 2009 (далі - RFC 5652).
1.6. Якщо у Вимогах є розбіжності з нормативними документами, зазначеними у пункті 1.5 цього розділу, то застосовуються положення цих Вимог.
1.7. Обмеження та рекомендації щодо застосування довжин ключів у криптографічних повідомленнях "захищені дані" визначаються чинним законодавством.
II. Типи повідомлень
2.1. Ці Вимоги визначають тип повідомлення "ContentInfo", що містить тип даних "захищені дані".
2.2. Тип повідомлення "ContentInfo" подано в нотації ASN.1, яка визначена у ДСТУ ISO/IEC 8824-1:2009 "Інформаційні технології. Нотація абстрактного синтаксису 1 (ASN.1). Частина 1. Специфікація базової нотації", ДСТУ ISO/IEC 8824-2:2009 "Інформаційні технології. Нотація абстрактного синтаксису 1 (ASN.1). Частина 2. Специфікація інформаційного об'єкта", ДСТУ ISO/IEC 8824-3:2009 "Інформаційні технології. Нотація абстрактного синтаксису 1 (ASN.1). Частина 3. Специфікація обмежень", ДСТУ ISO/IEC 8824-4:2009 "Інформаційні технології. Нотація абстрактного синтаксису 1 (ASN.1). Частина 4. Параметризація специфікацій ASN.1" (далі - ISO/IEC 8824).
2.3. Усі структури даних кодуються за правилами DER згідно з міжнародними стандартами ISO/IEC 8825-1:2008 "Information technology - ASN.1 encoding Rules - Part 1: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)" та AMD1:2004 "Support for EX-TENDED-XER".
2.4. Формат повідомлення "ContentInfo".
На тип "ContentInfo" вказує такий об'єктний ідентифікатор:
id-ct-contentInfo OBJECT IDENTIFIER ::= {iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6}.
Інформаційне повідомлення "ContentInfo" має такий формат:
ContentInfo ::= SEQUENCE {
contentType
ContentType,
content
[0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER.
Поля структури "ContentInfo" мають такі значення:
"contentType" - об'єктний ідентифікатор, що вказує на тип пов'язаних з ним даних, наприклад, тип "захищені дані";
"Content" - пов'язані з об'єктним ідентифікатором дані. Тип даних однозначно визначається полем "contentType".
2.5. Повідомлення, що містить цифровий конверт, має тип даних "enveloped-data" ("захищені дані"). Повідомлення типу "захищені дані" входять у повідомлення типу "ContentInfo".
Об'єктний ідентифікатор
id-envelopedData OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3}
вказує на те, що структура "ContentInfo" містить дані типу "захищені дані".
Приклад ASN.1 структури "захищені дані" наведено в додатку 1 до цих Вимог.
2.6. Криптографічне повідомлення "захищені дані" містить у собі інші типи повідомлень, а саме: "дані" ("data") або "підписані дані" ("signed-data")".
При внесенні в криптографічне повідомлення "захищені дані" повідомлення типу "дані" автентифікація відправника цих даних не забезпечується, якщо використовується динамічний механізм узгодження ключів. Динамічний механізм узгодження ключів наведено у підпункті 3.2.2 пункту 3.2 глави 3 розділу III цих Вимог. При внесенні в повідомлення "захищені дані" повідомлення типу "підписані дані" завжди забезпечується автентифікація відправника цих
даних.
2.7. Формат повідомлення "підписані дані" ("signed-data") встановлюється Вимогами до формату підписаних даних.
На тип "signed-data" вказує такий об'єктний ідентифікатор:
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }.
2.8. Повідомлення типу "дані" призначено для представлення довільних рядків октетів, наприклад, текстових файлів ASCII. Інтерпретація таких даних покладається на програмний додаток.
На тип "data" вказує такий об'єктний ідентифікатор:
id-data OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1}.
III. Процедура формування та розкриття "захищених даних"
1. Процедура формування "захищених даних" відправником
1.1. Відправник за протоколом управління ключами за допомогою особистого ключа відправника та відкритого ключа одержувача формує узгоджений ключ, на якому шифрує симетричний ключ сеансу КШД.
1.2. Зашифрований симетричний ключ сеансу КШД та інша інформація для одержувача вводяться в структуру "RecipientInfo" (інформація одержувача). Структура "RecipientInfo" наводиться у підпункті 3.7.1 пункту 3.7 глави 3 розділу IV цих Вимог.
1.3. Дані зашифровуються на симетричному ключі сеансу КШД.
1.4. Структура "RecipientInfo" разом із зашифрованими даними вводяться у структуру "enveloped-data". Структура "enveloped-data" наводиться у пункті 1.1 глави 1 розділу IV цих Вимог.
1.5. Зашифровані дані розміщуються у полі "EnvelopedData encryptedContentInfo encryptedContent OCTET STRING" структури "envelopeddata".
2. Процедура розкриття "захищених даних" одержувачем
2.1. Одержувач згідно з протоколом узгодження ключа за допомогою відкритого ключа відправника та особистого ключа одержувача формує узгоджений ключ, на якому розшифровує симетричний ключ сеансу КШД. Інформація для одержувача, яка необхідна для реалізації протоколу управління ключами з боку одержувача, а також для розшифрування повідомлення, подається в структурі "RecipientInfo". Структура "RecipientInfo" наводиться у підпункті 3.7.1 пункту 3.7 глави 3 розділу IV цих Вимог.
2.2. Одержувач за допомогою симетричного ключа сеансу КШД розшифровує дані, використовуючи алгоритм шифрування, що визначений у структурі "RecipientInfo".
3. Особливості формування повідомлення "захищені дані"
3.1. Засоби криптографічного захисту інформації відправника та одержувача повинні підтримувати криптографічні алгоритми, визначені цими Вимогами.
3.2. При використанні криптографічних перетворень у циклічній групі поля та в групі точок еліптичної кривої застосовується статичний або динамічний механізм узгодження ключів.
3.2.1. Статичний механізм узгодження ключів ("Static-Static mode") - узгодження ключів за протоколом Діффі-Геллмана, при якому як відправник, так і одержувач мають статичну ключову пару, відкритий ключ якої засвідчено в акредитованому центрі сертифікації ключів. Тим самим цей статичний механізм забезпечує автентифікацію відправника повідомлення типу "захищені дані".
Статичний механізм узгодження ключів може використовуватися лише у випадку, коли параметри криптографічного алгоритму статичної ключової пари відправника еквівалентні параметрам криптографічного алгоритму статичної ключової пари одержувача. Якщо зазначені параметри не еквівалентні, повинен застосовуватися динамічний механізм узгодження ключів.
При статичному механізмі узгодження ключа для формування узгодженого ключа відправник повинен використовувати особистий ключ відправника та відкритий ключ одержувача. Одержувач повинен використовувати особистий ключ одержувача та відкритий ключ відправника.
Відкриті ключі відправника та одержувача обираються із посилених сертифікатів відкритих ключів (сертифікатів шифрування).
3.2.2. Динамічний механізм узгодження ключів ("Ephemeral-Static mode") - узгодження ключів за протоколом Діффі-Геллмана, при якому одержувач має статичну ключову пару, відкритий ключ якої зазначено у посиленому сертифікаті відкритого ключа, а відправник генерує нову (сеансову/динамічну) ключову пару для кожного повідомлення і посилає відкритий ключ цієї пари одержувачу,
використовуючи поле "originatorKey" структури "RecipientInfo".
При цьому параметри криптографічного алгоритму динамічної ключової пари відправника повинні бути еквівалентні параметрам криптографічного алгоритму статичної ключової пари одержувача.
При динамічному механізмі узгодження ключа для формування узгодженого ключа відправник повинен використовувати особистий ключ відправника і відкритий ключ одержувача. Одержувач повинен використовувати особистий ключ одержувача і відкритий ключ відправника, що отримується від відправника, при кожному сеансі у полі "originatorKey" структури "RecipientInfo".
Особливості кодування параметрів протоколу узгодження ключа визначено у главі 4 розділу V цих Вимог.
Протокол узгодження ключів Діффі-Геллмана в циклічній групі поля використовується для ключових пар (відправника та одержувача), що відповідають ГОСТ 34.310-95 (але тільки за умови використання в режимі з довжиною модуля Р 1024).
Протокол узгодження ключів Діффі-Геллмана в групі точок еліптичної кривої використовується для ключових пар (відправника та одержувача), що відповідають ДСТУ 4145-2002.
IV. Представлення структури "захищені дані"
1. Формат структури "захищені дані"
1.1. Структура "захищені дані" має такий формат (RFC 3852, RFC 5652):
EnvelopedData ::= SEQUENCE {
version
CMSVersion,
originatorInfo
[0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos
RecipientInfos,
encryptedContentInfo
EncryptedContentInfo,
unprotectedAttrs
[1] IMPLICIT UnprotectedAttributes OPTIONAL}
CMSVersion ::= INTEGER {v0(0), v1(1), v2(2), v3(3), v4(4), v5(5)},
OriginatorInfo ::= SEQUENCE {
certificates
[0] CertificateSet OPTIONAL,
crls
[1] CertificateRevocationLists OPTIONAL },
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo,
EncryptedContentInfo ::= SEQUENCE {
contentType
ContentType,
contentEncryptionAlgorithm
ContentEncryptionAlgorithmIdentifier,
encryptedContent
[0] IMPLICIT EncryptedContent OPTIONAL },
EncryptedContent ::= OCTET STRING,
UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute.
1.2. Тип даних "захищені дані" містить дані про одного або більше одержувачів цифрового конверта, який вміщує "дані" або "підписані дані".
2. Порядок формування "захищених даних"
2.1. Генерується випадково симетричний ключ сеансу КШД.
2.2. Використовуючи статичний чи динамічний механізм узгодження ключів, обчислюється ключ шифрування ключа (КШК) для кожного одержувача.
2.3. Симетричний ключ сеансу КШД шифрується на ключі шифрування ключа КШК для кожного одержувача.
2.4. Для кожного одержувача зашифрований ключ КШД та інша відповідна специфічна інформація розміщуються всередині значення "RecipientInfo".
2.5. Значення "RecipientInfo" для всіх одержувачів разом із зашифрованими даними розміщуються в "EnvelopedData".
3. Поля структури "EnvelopedData"
3.1. Поле "Version" визначає номер версії синтаксису, який повинен мати значення 2.
3.2. Поле "originatorInfo" містить сертифікати відкритих ключів і списки відкликаних сертифікатів відправника. Поле є необов'язковим.
3.3. Поле "certs".
3.3.1. Поле "certs" - ланцюжок (chain) сертифікатів відправника, пов'язаний із статичним механізмом узгодження ключів, який було застосовано. Ланцюжок "certs" може містити лише кінцевий сертифікат відправника або повний ланцюжок (chain) сертифікатів, достатній для побудови шляху сертифікації від довіреного "кореня", або може містити не повний ланцюжок (chain) сертифікатів, наприклад, кінцевий сертифікат відправника та сертифікат його центру сертифікації. Сертифікати розміщуються в такому порядку: першим (з найменшим індексом) розміщується сертифікат центру сертифікації вищого рівня (кореневий для повного ланцюга сертифікатів), останнім (з найбільшим індексом) розміщується сертифікат відправника, який було застосовано для статичного механізму.
Наявність сертифіката відправника робить структуру захищених даних "самодостатньою" у тому розумінні, що дає змогу одержувачу розшифрувати повідомлення, використовуючи відкритий ключ відправника з його сертифіката, який міститься в полі "originatorInfo",
без необхідності пошуку сертифіката відправника у сховищі сертифікатів.
3.3.2. Поле "certs" має такий формат (RFC 3852, RFC 5652):
CertificateSet ::= SET OF CertificateChoices
CertificateChoices ::= CHOICE {
certificate
Certificate,
v2AttrCert
[2] IMPLICIT AttributeCertificateV2,
other
[3] IMPLICIT OtherCertificateFormat },
OtherCertificateFormat ::= SEQUENCE {
otherCertFormat
OBJECT IDENTIFIER,
otherCert
ANY DEFINED BY otherCertFormat },
AttributeCertificateV2 ::= AttributeCertificate.
Поле "v2AttrCert" ("AttributeCertificate") має такий формат:
AttributeCertificate ::= SEQUENCE {
acinfo
AttributeCertificateInfo,
signatureAlgorithm
AlgorithmIdentifier,
signatureValue
BIT STRING },
AttributeCertificateInfo ::= SEQUENCE {
version
AttCertVersion -- version is v2,
holder
Holder,
issuer
AttCertIssuer,
signature
AlgorithmIdentifier,
serialNumber
CertificateSerialNumber,
attrCertValidityPeriod
AttCertValidityPeriod,
attributes
SEQUENCE OF Attribute,
issuerUniqueID
UniqueIdentifier OPTIONAL,
extensions
Extensions OPTIONAL },
AttCertVersion ::= INTEGER { v2(1) },
Holder ::= SEQUENCE {
baseCertificateID
[0] IssuerSerial OPTIONAL,
-- the issuer and serial number of the holder's Public Key Certificate
entityName
[1] GeneralNames OPTIONAL,
-- the name of the claimant or role
objectDigestInfo
[2] ObjectDigestInfo OPTIONAL
-- used to directly authenticate the holder, for example, an executable },
ObjectDigestInfo ::= SEQUENCE {
digestedObjectType
ENUMERATED {
publicKey (0),
publicKeyCert (1),
otherObjectTypes (2) },
-- otherObjectTypes MUST NOT be used in this profile
otherObjectTypeID
OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm
AlgorithmIdentifier,
objectDigest
BIT STRING },
AttCertIssuer ::= CHOICE {
v1Form
GeneralNames,
-- MUST NOT be used in this profile
v2Form
[0] V2Form -- v2 only },
V2Form ::= SEQUENCE {
issuerName
GeneralNames OPTIONAL,
baseCertificateID
[0] IssuerSerial OPTIONAL,
objectDigestInfo
[1] ObjectDigestInfo OPTIONAL
-- issuerName MUST be present in this profile baseCertificateID and
-- objectDigestInfo MUST NOT be present in this profile
},
IssuerSerial ::= SEQUENCE {
issuer
GeneralNames,
serial
CertificateSerialNumber,
issuerUID
UniqueIdentifier OPTIONAL
},
AttCertValidityPeriod ::= SEQUENCE {
notBeforeTime
GeneralizedTime,
notAfterTime
GeneralizedTime
}.
3.4. Поле "crls".
3.4.1. Поле "crls" - набір списків відкликаних сертифікатів (CRL). Набір CRL містить інформацію, достатню для того, щоб визначити, чи є сертифікати в полі "certs" чинними. Послідовність розміщення CRL у полі "crls" повинна відповідати послідовності розміщення сертифікатів у наборі "certs". Наявність списків відкликання дає змогу одержувачу визначити чинність сертифіката відправника на момент формування захищених даних без необхідності звернення до зовнішніх джерел розміщення CRL.
3.4.2. Поле "crls" має такий формат (RFC 3852, RFC 5652):
RevocationInfoChoices ::= SET OF RevocationInfoChoice
RevocationInfoChoice ::= CHOICE {
crl
CertificateList,
other
[1] IMPLICIT OtherRevocationInfoFormat },
OtherRevocationInfoFormat ::= SEQUENCE {
otherRevInfoFormat
OBJECT IDENTIFIER,
otherRevInfo
ANY DEFINED BY otherRevInfoFormat }.
"CertificateList" може містити повний (Full) CRL або частковий (Delta) CRL, формат якого відповідає Вимогам до формату списку відкликаних сертифікатів.
3.5. Поле "encryptedContentInfo".
Поле "encryptedContentInfo" містить зашифроване повідомлення.
Поля структури "encryptedContentInfo":
поле "contentType" вказує на тип даних;
поле "contentEncryptionAlgorithm" визначає криптографічний алгоритм шифрування даних. Для усіх одержувачів повідомлення повинні застосовуватися однаковий алгоритм, параметри алгоритму шифрування даних та однаковий ключ шифрування даних;
поле "encryptedContent" містить дані, які зашифровані з використанням ключа
шифрування даних КШД та алгоритму, що визначений у полі "contentEncryptionAlgorithm". Поле є необов'язковим. У разі відсутності поля "encryptedContent" вважається, що зашифровані дані подаються в інший спосіб.
3.6. Поле "Unprotected Attrs" містить набір атрибутів, що не зашифровуються разом з повідомленням.
3.7. Поле "recipientInfos" містить інформацію про одержувачів.
3.7.1. Структура "RecipientInfo" має такий формат:
RecipientInfo ::= CHOICE {
kari
[1] KeyAgreeRecipientInfo}.
3.7.2. Тип "KeyAgreeRecipientInfo" призначений для кодування даних, що використовуються одержувачем у протоколі управління ключами.
3.7.3. Структура "KeyAgreeRecipientInfo" має такий формат:
KeyAgreeRecipientInfo ::= SEQUENCE {
version
CMSVersion,
originator
[0] EXPLICIT OriginatorIdentifierOrKey,
ukm
[1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm
KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys
RecipientEncryptedKeys},
OriginatorIdentifierOrKey ::= CHOICE {
issuerAndSerialNumber
IssuerAndSerialNumber,
subjectKeyIdentifier
[0] SubjectKeyIdentifier,
originatorKey
[1] OriginatorPublicKey},
OriginatorPublicKey ::= SEQUENCE {
algorithm
AlgorithmIdentifier,
publicKey
BIT STRING},
UserKeyingMaterial ::= OCTET STRING,
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier,
AlgorithmIdentifier ::= SEQUENCE {
algorithm
OBJECT IDENTIFIER,
parameters
ANY DEFINED BY algorithm},
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey,
RecipientEncryptedKey ::= SEQUENCE {
rid
KeyAgreeRecipientIdentifier,
encryptedKey
EncryptedKey},
EncryptedKey ::= OCTET STRING,
KeyAgreeRecipientIdentifier ::= CHOICE {
issuerAndSerialNumber
IssuerAndSerialNumber,
rKeyId
[0] IMPLICIT RecipientKeyIdentifier},
IssuerAndSerialNumber ::= SEQUENCE {
issuer
Name,
serialNumber
CertificateSerialNumber},
CertificateSerialNumber ::= INTEGER.
3.7.4. Поля структури "KeyAgreeRecipientInfo":
1) поле "Version" визначає номер версії синтаксису, який повинен мати значення "3";
2) поле "originator" містить ідентифікаційні дані відправника. Тип цих даних залежить від механізму (протоколу) узгодження ключів;
3) ідентифікаційні дані відправника:
при застосуванні статичного механізму узгодження ключів Діффі-Геллмана як ідентифікатора відправника повинні використовуватися ім'я емітента сертифіката (центру сертифікації) та серійний номер сертифіката відкритого ключа відправника "issuerAndSerialNumber" або ідентифікатор відкритого ключа відправника "subjectKeyIdentifier";
при застосуванні динамічного механізму узгодження ключів Діффі-Геллмана як ідентифікаційних даних відправника застосовується його відкритий сеансовий ключ (маркер), що генерується відправником та міститься в полі "originatorKey";
при застосуванні динамічного механізму узгодження ключів у циклічній групі поля поле "algorithm" в "originatorKey" повинно мати таке значення:
Gost34310WithGost34311 OBJECT IDENTIFIER ::= { iso(1) member-body(2) Ukraine(804) root (2) security(1) cryptography(1) ua-pki (1) alg(1) asym(3) Gost34310WithGost34311(2)}.
Відповідно до RFC 3370 параметрів алгоритму поля "algorithm" в "originatorKey" не повинно бути.
Поле "originatorKey publicKey" повинно містити відкритий ключ відправника (маркер), що має такий формат:
PublicKey:: = INTEGER, що інкапсулюється в BIT STRING.
Відкритий ключ ГОСТ 34.310-95 кодується як ціле відповідно до Вимог до формату посиленого сертифіката відкритого ключа.
При застосуванні динамічного механізму узгодження ключів у групі точок еліптичної кривої поле "algorithm" поля "originatorKey" для алгоритму цифрового підпису ДСТУ 4145-2002 може мати такі значення:
для поліноміального базису:
Dstu4145PBAlgo OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root (2) security(1) cryptography(1) ua-pki (1) alg(1) asym (3) Dstu4145WithGost34311(1) pb(1)};
для оптимального нормального базису:
Dstu4145ONBAlgo OBJECT IDENTIFIER ::= { iso(1) member-body(2) Ukraine(804) root (2) security(1) cryptography(1) ua-pki (1) alg(1) asym (3)
Dstu4145WithGost34311(1) onb(2)}.
Параметри алгоритму поля "algorithm" в "originatorKey" повинні бути ASN.1 NULL.
Поле "originatorKey publicKey" повинно містити відкритий ключ відправника (маркер), що має такий формат:
PublicKey:: = OCTET STRING, що інкапсулюється в BIT STRING.
Відкритий ключ ДСТУ 4145-2002 - це послідовність байтів, яка є елементом основного поля (пункт 5.3 розділу 5 ДСТУ 4145-2002), який є стиснутим зображенням (пункт 6.9 розділу 6 ДСТУ 4145-2002) точки на еліптичній кривій. Розмір зображення в байтах дорівнює m/8, заокруглений до найближчого цілого у більшу сторону;
4) поле "ukm" (User Keying Material - матеріал щодо ключа користувача) містить додаткову інформацію, яку відправник надає одержувачу під час виконання протоколу узгодження ключа Діффі-Геллмана. Поле "ukm" використовується з метою забезпечення можливості формування різних значень узгоджених ключів у різний час суб'єктами, що використовують ті самі пари ключів (статичні ключі).
Реалізації цих Вимог повинні обробляти "KeyAgreeRecipientInfo", що містить поле "ukm".
У разі застосування механізму узгодження ключів у циклічній групі поля в поле "ukm" вноситься значення "partyAInfo" (кодоване як OCTET STRING), яке генерується відправником і використовується в структурі "OtherInfo". Якщо "partyAInfo" задано, то воно повинно мати довжину 512 бітів (64 байти). Параметр "partyAInfo" визначається у позиціях 4 та 6 пункту 6.3 глави 6 розділу V цих Вимог.
У разі застосування динамічного механізму узгодження ключів у групі точок еліптичної кривої (ECDH) у поле "ukm" вноситься значення "entityUInfo" (кодоване як OCTET STRING), яке генерується відправником і використовується в структурі "SharedInfo". Якщо "entityUInfo" задано, то воно повинно мати довжину 512 бітів (64 байти). Параметр "entityUInfo" визначається у позиції 6 пункту 6.4 глави 6 розділу V цих Вимог;
5) поле "keyEncryptionAlgorithm" визначає ідентифікатор протоколу узгодження ключа (Key Agreement Algorithm);
6) поле "recipientEncryptedKeys" містить ідентифікатор одержувача та зашифрований ключ КШД для одного або декількох одержувачів;
7) поле "KeyAgreeRecipientIdentifier" визначає ідентифікаційні дані сертифіката одержувача, який використовується відправником при обчисленні узгодженого ключа КШК. Поле може бути типу "issuerAndSerialNumber" або "RecipientKeyIdentifier".
"rKeyId" - альтернатива типу "RecipientKeyIdentifier", має таке значення:
RecipientKeyIdentifier ::= SEQUENCE {
subjectKeyIdentifier
SubjectKeyIdentifier,
date
GeneralizedTime OPTIONAL,
other
OtherKeyAttribute OPTIONAL };
SubjectKeyIdentifier ::= OCTET STRING;
"subjectKeyIdentifier" - ідентифікатор відкритого ключа одержувача;
"date" - необов'язкове поле. Зміст та використання цього поля не регламентується у межах цього документа;
"other" - необов'язкове поле. Зміст та використання цього поля не регламентується у межах цього документа.
Реалізації цих Вимог повинні підтримувати обидві вищевказані альтернативи для визначення сертифіката одержувача;
8) поле "encryptedKey" містить симетричний ключ КШД, зашифрований на узгодженому ключі КШК.
3.7.5. Особливості синтаксису структури "KeyAgreeRecipientInfo":
1) ідентифікатор протоколу узгодження ключа вказується в полі "EnvelopedData RecipientInfos KeyAgreeRecipientInfo":
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
AlgorithmIdentifier ::= SEQUENCE {
algorithm
OBJECT IDENTIFIER,
parameters
ANY DEFINED BY algorithm}.
Поле "algorithm" повинно містити об'єктний ідентифікатор одного з протоколів узгодження ключа, що зазначені нижче, а поле "parameters" повинно містити ідентифікатор алгоритму шифрування ключа КШК (KeyWrapAlgorithm):
parameters ::= KeyWrapAlgorithm;
KeyWrapAlgorithm ::= AlgorithmIdentifier;
2) об'єктний ідентифікатор протоколу узгодження ключа визначає:
ZZ-функцію обчислення спільного секрету (ZZ) для визначеного протоколу;
KDF-функцію (Key Derivation Function), функцію формування ключа шифрування ключа КШК (KM, KeyingMaterial) на основі спільного секрету та додаткової інформації для заданого алгоритму
"KeyWrapAlgorithm";
3) об'єктні ідентифікатори (OID) протоколу узгодження ключа у циклічній групі поля:
протокол узгодження ключа у циклічній групі поля з використанням геш-функції ГОСТ 34.311-95 позначається через ідентифікатор "id-DH-ua". Протокол узгодження ключа у циклічній групі поля з використанням геш-функції ГОСТ 34.311-95 є обов'язковим алгоритмом, який застосовується як для статичного, так і для динамічного механізму узгодження ключа; при цьому ознакою динамічного механізму є ненульове значення поля "originatorKey" (відповідно до абзацу третього позиції 3 підпункту 3.7.4 пункту 3.7 глави 3 розділу IV цих Вимог):
id-DH-ua OBJECT IDENTIFIER ::= { iso(1) member-body(2)
Ukraine(804) root(2) security(1) cryptography(1) ua-pki (1)
alg (1) asym (3) DH-ua(3) };
для протоколів узгодження ключа у циклічній групі поля з використанням геш-функції SHA-1 відповідно до ДСТУ ISO/IEC 10118-3:2005 та RFC 2631 (тільки для сумісності з реалізаціями засобів КЗІ, що були розроблені до прийняття цих Вимог) використовуються такі ідентифікатори:
"id-SSDH" - необов'язковий, застосовується для статичного механізму узгодження ключа;
"id-ESDH" - необов'язковий, застосовується для динамічного механізму узгодження ключа;
id-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 10 };
id-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) alg(3) 5 };
протоколи узгодження ключа, а саме: ZZ-функція та KDF-функція, у циклічній групі поля визначені у розділі V цих Вимог;
4) об'єктні ідентифікатори (OID) протоколу узгодження ключа в групі точок еліптичної кривої (ECDH):
з використанням геш-функції ГОСТ 34.311-95: алгоритм з кофакторним множенням "id-dhSinglePass-cofactorDH-gost34311kdf-scheme", алгоритм без кофакторного множення "id-dhSinglePass-stdDH-gost34311kdf-scheme":
id-dhSinglePass-cofactorDH-gost34311kdf-scheme OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) ua-pki (1) alg (1) asym (3) dhSinglePass-cofactorDH-gost34311kdf (4) };
id-dhSinglePass-stdDH-gost34311kdf-scheme OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) ua-pki (1) alg (1) asym (3) dhSinglePass- stdDH-gost34311kdf (5) };
з використанням відповідно до ДСТУ ISO/IEC 15946-3:2006, ДСТУ ISO/IEC 10118-3:2005 геш-функцій SHA-1 (тільки для розшифрування даних, шифрування яких здійснювалось до 01 січня 2014 року), SHA-224, SHA-256, SHA-384, SHA-512:
алгоритми з кофакторним множенням:
"id-dhSinglePass-cofactorDH-sha1kdf-scheme";
"id-dhSinglePass-cofactorDH-sha224kdf-scheme";
"id-dhSinglePass-cofactorDH-sha256kdf-scheme";
"id-dhSinglePass-cofactorDH-sha384kdf-scheme";
"id-dhSinglePass-cofactorDH-sha512kdf-scheme";
алгоритми без кофакторного множення:
"id-dhSinglePass-stdDH-sha1kdf-scheme";
"id-dhSinglePass-stdDH-sha224kdf-scheme";
"id-dhSinglePass-stdDH-sha256kdf-scheme";
"id-dhSinglePass-stdDH-sha384kdf-scheme";
"id-dhSinglePass-stdDH-sha512kdf-scheme";
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) tc68(133) country(16) x9(840) x9-63(63) chemes(0) 3};
dhSinglePass-cofactorDH-sha224kdf-scheme OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) certicom(132) schemes(1) 14 0 };
dhSinglePass-cofactorDH-sha256kdf-scheme OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) certicom(132) schemes(1) 14 1 };
dhSinglePass-cofactorDH-sha384kdf-scheme OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) certicom(132) schemes(1) 14 2 };
dhSinglePass-cofactorDH-sha512kdf-scheme OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) certicom(132) schemes(1) 14 3 };
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) tc68(133) country(16) x9(840) x9-63(63) chemes(0) 2};
dhSinglePass-stdDH-sha224kdf-scheme OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) certicom(132) schemes(1) 11 0 };
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {iso(1)
identified-organization(3) certicom(132) schemes(1) 11 1 };
dhSinglePass-stdDH-sha384kdf-scheme OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) certicom(132) schemes(1) 11 2 };
dhSinglePass-stdDH-sha512kdf-scheme OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) certicom(132) schemes(1) 11 3 };
протоколи узгодження ключа, визначені ідентифікаторами, згідно з абзацами першим та другим позиції 4 підпункту 3.7.5 пункту 3.7 глави 3 розділу IV цих Вимог, застосовуються як для статичного, так і для динамічного механізму узгодження ключа. При цьому ознакою динамічного механізму є не нульове значення поля "originatorKey" відповідно до абзацу третього позиції 3 підпункту 3.7.4 пункту 3.7 глави 3 розділу IV цих Вимог;
протоколи узгодження ключа, а саме: ZZ-функція та KDF-функція, у групі точок еліптичної кривої визначені у розділі V цих Вимог.
V. Протокол узгодження ключа Діффі-Геллмана
1. Призначення та порядок використання протоколу узгодження ключа
Протокол узгодження ключа призначений для установлення розділеної таємниці (обчислення узгоджувального ключа КШК) на основі використання особистого ключа відправника та відкритого ключа одержувача і навпаки.
У цих Вимогах визначено дві групи протоколів узгодження ключа Діффі-Геллмана: DH - у циклічній групі поля та ECDH - у групі точок еліптичної кривої.
2. Протокол узгодження ключа Діффі-Геллмана, що виконується відправником:
отримати параметри ключа відправника та ключа одержувача (із сертифікатів відкритих ключів);
порівняти параметри ключа відправника з параметрами ключа одержувача;
у разі еквівалентності параметрів установити статичний механізм узгодження ключа та перейти до кроку, зазначеного в абзаці шостому цього протоколу;
у разі нееквівалентності параметрів установити динамічний механізм узгодження ключа та відправнику виконати обчислення ключової пари, використовуючи алгоритм та відповідні параметри ключа одержувача;
виконати обчислення спільного секрету (ZZ) для визначеного протоколу в циклічній групі поля або в групі точок еліптичної кривої;
виконати обчислення ключа шифрування ключа КШК (KDF - Key Derivation Function).
3. Протокол узгодження ключа Діффі-Геллмана, що виконується одержувачем:
завантажити сертифікат і особистий ключ одержувача та отримати параметри ключової пари відправника;
отримати ASN.1 "EnvelopedData";
на основі аналізу "EnvelopedData" визначити механізм узгодження ключа. Ознакою динамічного механізму є ненульове значення поля "originatorKey" відповідно до позиції 3 підпункту 3.7.4 пункту 3.7 глави 3 розділу IV цих Вимог;
якщо механізм статичний, отримати сертифікат відправника. Сертифікат відправника може міститися у структурі "OriginatorInfo", в іншому випадку він має бути отриманий одержувачем із його сховища сертифікатів за даними з поля "OriginatorIdentifierOrKey";
отримати із сертифіката відправника відкритий ключ;
отримати параметри відкритого ключа відправника;
порівняти параметри ключа пари одержувача з параметрами відкритого ключа відправника;
нееквівалентність параметрів означає помилку. Необхідно припинити оброблення;
у разі еквівалентності параметрів перейти до наступного кроку цього протоколу;
якщо механізм динамічний, отримати динамічний відкритий ключ відправника зі структури "EnvelopedData";
виконати обчислення спільного секрету (ZZ) для визначеного протоколу в циклічній групі поля або в групі точок еліптичної кривої;
виконати обчислення ключа шифрування ключа КШК (KDF - Key Derivation Function).
4. Параметри протоколу узгодження ключа називають "загальносистемними параметрами" ("Domain Parameters"). У цих Вимогах загальносистемні параметри не є об'єктом ASN.1 структури "захищені дані" ("EnvelopedData"), а використовуються виключно у внутрішніх процедурах для визначення механізму узгодження ключів (динамічний або статичний) та обчислення спільного секрету (ZZ-функція). Тому наведені у цьому пункті ASN.1 структури мають рекомендаційний характер.
4.1. Параметри протоколу узгодження ключа у циклічній групі поля:
1) загальносистемні параметри протоколу id-ESDH-ua можуть визначатися як ASN.1
структура:
DHParameters ::= SEQUENCE {
p
INTEGER,
q
INTEGER,
a
INTEGER,
validationParms
GOST34310ValidationParms OPTIONAL,
-- параметри валідації,
dke
OCTET STRING OPTIONAL }
GOST34310ValidationParms ::= SEQUENCE {
x0
INTEGER,
c
INTEGER,
d
INTEGER OPTIONAL };
2) значення полів структури "DHParameters" наведено в таблиці.
Таблиця
p
характеристика основного поля, просте число (modulus)
q
порядок циклічної підгрупи (order of cyclic group)
a
твірний елемент циклічної підгрупи (generator)
dke
довгостроковий ключовий елемент (ДКЕ)
x0
початковий стан, що використовувався для генерації p, q (seed)
c
параметр датчика, що використовувався для генерації p, q
d
довільне число, що використовувалося для генерації а, 1
< d
< p - 1
3) операція порівняння загальносистемних параметрів "DHParameters".
При визначенні механізму узгодження ключів повинна виконуватися операція порівняння загальносистемних параметрів. Якщо загальносистемні параметри - еквівалентні, то застосовується статичний механізм узгодження ключів, в інших випадках - динамічний.
При виконанні операції порівняння параметрів повинні порівнюватися параметри p, a, q та додатково dke (у разі використання протоколу "id-ESDHua").
Параметри валідації "GOST34310ValidationParms" як необов'язкові не повинні використовуватися в операції порівняння.
4.2. Параметри протоколу узгодження ключа в групі точок еліптичної кривої:
1) параметри алгоритму в групі точок еліптичної кривої (ECDH) можуть бути визначені такою ASN.1 структурою: