Все_лекции_Горбенко

515

9.3.2.3 Формування ключа (В): Об’єкт В повинен перевірити, що маркер

КТА1 є дійсно точкою еліптичної кривої. Див. першу частину цього стандарту,

де описано як це робити. Використовуючи свій особистий ключ та маркер

KTA1 об’єкт В обчислює розділюваний ключ таким чином:

KAB ((dB (PB)dB) l)(h (KTA1 (KTA1)PA)).

9.3.3 Властивості

Цей механізм узгодження ключів маєтакі властивості:

а) Число проходів: 1.

b)Механізм забезпечує взаємну неявну автентифікацію ключа.

c)Механізм забезпечуєкриптографічну живучість ключа об’єкта А.

9.4 Узгодження ключів типу MQV за 2 проходи (KAMQV2P)

Цей механізм узгодження ключів установлює розділювану таємницю між об’єктами А і В за два проходи.

9.4.1 Налаштування

Перед процесом узгодження розділюваної таємниці, у додаток до

спільної інформації, повинно бути установлено:

-особистий ключ узгодження ключів dХ та відкритий ключ узгодження ключів PХ, який є точкою еліптичної кривої, і обчислений для кожного об’єкта

Хзгідно рівнянню PХ = dХ G. Див. першу частину цього стандарту, де описано як генерувати цю ключову пару;

-доступ до автентифікованої копії відкритого ключа для узгодження ключів іншої сторони для кожного об’єкту.

Кожен об’єкт повинен незалежно перевіряти, що відкритий ключ іншого об’єкта є дійсно точкою еліптичної кривої. Див. першу частину цього стандарту, де описано як це робити.

9.4.2Механізм

9.4.2.1Формування маркера ключа (А): Об’єкт А генерує випадково

таємне значення rA . що знаходиться у діапазоні 1,..., n 1 , обчислює rAG та

формує маркер ключа:

КТA1 = rAG

й посилає його об’єкту В.

516

9.4.2.2 Формування маркера ключа (В): Об’єкт В генерує випадково таємне значення rB , що знаходиться у діапазоні 1,..., n 1 , обчислює rBG та

формує маркер ключа:

КТВ1 = rBG

й посилає його об’єкту А.

9.4.2.3 Формування ключа (А): Об’єкт А повинен перевірити, що маркер

КТВ1 є дійсно точкою еліптичної кривої. Див. першу частину, де описано як це робити. Об’єкт А обчислює розділюваний ключ

KAB ((rA (KTA1)dA) l)(h (KTB1 (KTB1)PB )).

9.4.2.4 Формування ключа (В): Об’єкт В повинен перевірити, що маркер

КТА1 є дійсно точкою еліптичної кривої. Див. першу частину, де описано як це робити. Об’єкт В обчислюєрозділюваний ключ

KAB ((rB (KTB1)dB) l)(h (KTA1 (KTA1)PA)).

9.4.3 Властивості

Цей механізм узгодження ключів маєтакі властивості:

а) Число проходів: 2.

b)Механізм забезпечує взаємну неявну автентифікацію ключа.

c)Механізм забезпечуєвзаємну криптографічну живучість ключів.

10 МЕХАНІЗМИ ПЕРЕДАВАННЯ КЛЮЧІВ

У цьому стандарті ISO/IEC 15946-3 транспортування таємного ключа визначено як процес транспортування таємного ключа, що обраний одним об’єктом (або третьою довіреною стороною) для іншого об’єкта, з його захистом при транспортуванні за допомогою криптографічних перетворень в групі точок еліптичних кривих.

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

10.1 Спільна інформація

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

517

- параметри еліптичної кривої, з якими повинні пов’язані ключові пари,

повинні бути однаковими для ключових пар обох сторін. Вони включають

модулі p, pm або 2m, опис полів F(p), F(pm) або F(2m), базис, що використовується, криву E , порядок базової точки п та базову точку G;

-функцію вироблення ключа, kdf;

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

parameters;

- тип кофакторного множення, яке необхідно використовувати(якщо потрібно).

10.2 Передавання ключів типу Ель-Гамаля (KTEG)

Цей механізм транспортування ключів забезпечує передавання таємного ключа К від об’єкта А до об’єкта В за один прохід.

10.2.1 Налаштування

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

-особистий ключ транспортування ключів dВ та відкритий ключ транспортування ключів PВ, який є точкою еліптичної кривої, і обчислений для кожного об'єкту згідно рівнянню PВ = dВ G;

-доступ до автентифікованої копії відкритого ключа для транспортування ключів об’єкта В для об’єкта А;

-МАС алгоритм МАС;

-параметри для функції вироблення ключа, коли вона використовується для вироблення МАС ключа, MACparameters.

Об’єкт А повинен перевірити, що відкритий ключ об’єкта В є дійсно

точкою еліптичної кривої. Див. першу частину цього стандарту, де описано як

це робити.

10.2.2Механізм

10.2.2.1Формування маркера ключа (А): Об’єкт А генерує випадково

таємне значення r, що знаходиться у діапазоні 1,..., n 1 , обчислює точку кривої rG та шифрує К таким чином:

BE (A||K)XOR kdf ( ((r l)(hPB)), parameters).

ПотімА обчислює проміжний ключ

K kdf( ((r l)(hPB )),MACparameters),

формує маркер ключа

KTA1 BE ||rG || MAC(K ,BE)

518

і посилає його об’єкту В.

10.2.2.2 Розформування маркера ключа (В): Об’єкт В повинен перевірити,

що значення rG одержане з маркеру KTA1 є дійсно точкою еліптичної кривої.

Див. першу частину, де описано як це робити. Для відновлення ключа К об’єкт В використовує свій особистий ключ для узгодження ключів dB та rG

для визначення точки кривої (dB l)(h rG). Потім об’єкт В обчислює значення

((dB l)(h rG)).

Об’єкт В одержуєключ К, обчислюючи

A||K BE XORkdf( ((dB l)(h rG)), parameters).

Упідсумку об’єкт В обчислює проміжний ключ

K kdf( ((dB l)(h rG)),MACparameters),

перевіряє, що одержане значення MAC(K ,BE) дорівнює раніше обчисленому значенню MAC(K ,BE) та що ідентифікатор відправника А

відповідає тому який відтворили з ВЕ. Якщо всі перевірки пройшли успішно, В

приймаєключ К.

10.2.3 Властивості

Цей механізм транспортуванняключів має такі властивості:

а) Число проходів: 1.

b)Механізм забезпечує неявну автентифікацію ключа об’єктом А об’єкта В, так як тільки об’єкт В може, можливо, відтворити ключ К.

c)Механізм забезпечуєкриптографічну живучість ключа об’єкта А.

10.3Транспортування ключів типу Ель-Гамаля з підписом автора

(KTEGOS)

Цей механізм транспортування ключів передає таємний ключ К від об’єкта А об’єкту В за один прохід.

10.3.1 Налаштування

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

- особистий ключ транспортування ключів dВ та відкритий ключ транспортування ключів PВ, об’єкта В, який є точкою еліптичної кривої, і

519

обчислений для кожного об'єкту згідно рівнянню PВ = dВ G. Див. першу

частину цього стандарту, де описано як генерувати цю ключову пару;

-доступ до автентифікованої копії відкритого ключа для транспортування ключів об’єкта В для об’єкта А;

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

-доступ до автентифікованої копії відкритого ключа перевіряння об’єкта

Адля об’єкта В;

-будь-які параметри, що використовуються у перетвореннях електронного цифрового підпису.

Об’єкт А повинен перевірити, що відкритий ключ для транспортування ключів об’єкта В є дійсно точкою еліптичної кривої. Див. першу частину цього стандарту, де описано як це робити.

10.3.2 Механізм

Нехай особисте та відкрите перетворення електронного цифрового підпису об’єкта А визначають SA та VA

відповідно; (SA,VA) можуть визначати будь-яку систему електронного цифрового підпису, наприклад одну

із систем електронного цифрового підпису, що визначено у ISO/IEC 9796, ISO/IEC 14888 або ISO/IEC 15946-2.

10.3.2.1 Ключ зашифровування (А): Об’єкт А генерує випадкове таємне ціле r , що знаходиться у діапазоні 1,..., n 1 , обчислює точку кривої rG та

шифрує блок даних ключа A|| K такимчином:

BE (A||K)XOR kdf ( ((r l)(hPB)), parameters).

10.3.2.2 Формування маркера ключа (А): Об’єкт А формує маркер ключа,

що містить розрізнювальний ідентифікатор одержувача В, позначку часу або порядковий номер, за необхідністю, TVP, точку кривої rG та зашифрований

блок ВЕ. Таким чином

KTA1 B||TVP||rG ||BE.

Потім об’єкт А підписує маркер ключа і посилає маркер та

одержаний підпис

SA(KTA1)

об’єкту В.

520

10.3.2.3 Перевіряння маркеру ключа (В): Об’єкт В використовує відкрите перетворення перевіряння відправника VA для перевіряння електронного цифрового підпису одержаного маркера ключа KTA1. Потім об’єкт В перевіряє ідентифікатор одержувача В і, за необхідністю, TVP. Об’єкт В повинен перевірити, що значення rG одержане з маркера є дійсно точкою еліптичної кривої. Див. першу частину, де описано

як це робити.

10.3.2.4 Ключ розшифровування (В): Об’єкт В розшифровує блок ВЕ, використовуючи свій особистий ключ для транспортування ключів dB , обчислюючи

A||K BE XORkdf( ((dB l)(h rG)), parameters).

Потім об’єкт В перевіряє ідентифікатор відправника А. Якщо всі перевірки пройшли успішно, об’єкт В приймає ключ К.

10.3.3 Властивості

Цей механізм узгодження3 ключів маєтакі властивості:

а) Число проходів: 1.

b)Механізм забезпечує взаємну неявну автентифікацію ключів.

c)Метод4 забезпечує явну автентифікацію ключа об’єктом В об’єкта А;

d)Метод2 забезпечує криптографічну живучість ключа об’єкта А.

11 ПІДТВЕРДЖЕННЯ КЛЮЧІВ

– Явне підтвердження ключа є процесом включення до протоколу встановлення ключів, що забезпечує неявну автентифікацію ключа, додаткових повідомлень, і таким чином, забезпечують явну автентифікацію ключа та автентифікацію об’єкта. Явне підтвердження ключа може використовуватися в будь-якому методі, який, по суті, не забезпечує явне підтвердження ключа (наприклад, розділи 8.2, 8.3, 8.4, 9.2, 9.3 та 10.2).

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

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

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

Національна виноска

3) В даномумісці замість “узгодження ключів” повинно стояти “транспортування ключів”

4

521

Якщо об’єкт A є ініціатором, то об’єкт B виконує прийняту процедуру щодо установлення ключа та можливо виробляє розділювану таємницю MacKey і використовує встановлений ключ для обчислення MAC коду

над повідомленням MacData1.

1.Об’єкт B формує рядок октетів MacData1, що складається з октету ідентифікатора повідомлення

0х022, ідентифікатора об’єкта B, ідентифікатора об’єкта A, рядка октетів KTB , що відповідає маркеру

ключа об’єкта B (або нулів, якщо такого не існує), рядка октетів KTA , що відповідає маркеру ключа

об’єкта А (або нулів, якщо такого не існує), рядка октетів PB , що відповідає відкритому ключу для

установлення ключів об’єкта В (або нулів, якщо такого не існує), рядка октетів PA , що відповідає відкритому ключу для установлення ключів об’єкта А (або нулів, якщо такого не існує) і , якщо присутній,

необов’язковий додатковий

MacData1 02|| B || A|| KTB || KTA || PB || PA [|| Text1],

де 0х02 є номером повідомлення. 2. Об’єкт В обчислює

MacKeyB kdf (KAB ).

Об’єкт В обчислює MacTag1 над даними MacData1 виходячи можливо з розділюваної таємниці

MacKeyB відповіднодо визначеної MAC схеми.

3.Об’єкт В посилає MacData1, MacTag1 стороні А.

4.Об’єкт А обчислює

MacKeyA kdf (KAB )

і перевіряє MacTag1 згідно з повідомленням MacData1.

5.Якщо MAC перевіряється, то сторона A одержала підтвердження ключа від сторони В (тобто,

522

8.Сторона B використовує MacKeyB для перевіряння MAC згідно з повідомленням MacData2.

Якщо MAC перевіряється, то сторона B одержала підтвердження ключа від сторони А (тобто сторона В

знає, що MacKeyA дорівнює MacKeyB ).

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

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

ДОДАТОК А

(довідковий)

ПРИКЛАДИ ФУНКЦІЙ ВИРОБЛЕННЯ КЛЮЧІВ

A.1 Функція вироблення ключа IEEE P1363

У цьому пункті описується функція вироблення ключа, що наведена у стандарті IEEE P1363 [3].

A.1.1 Передумови

Перед використанням цієї функції вироблення ключа, користувачі повинні узгодити спільну функцію гешування hash. Користувачі, які використовують різні функції гешування одержать різні результати. Вимогами цього стандарту є те, що функція гешування повинна бути описана у стандарті ISO/IEC 10118. Розділюваний ключ, який виробляють, буде мати довжину, що дорівнює довжині вихідних данихфункції гешування.

A.1.2 Вхідні дані

Вхідними даними цієї функції вироблення ключа є

1. Розділювана таємниця z, що є цілим числом та представлена рядком октетів.

Примітка. Механізми, що вказані у розділах 8, 9 та 10, виробляють розділюваний ключ KAB або як точки еліптичної кривої, або як конкатенацію двох точок еліптичної

кривої. У першому випадку для одержання розділюваної таємниці, що представлена цілим числом z , для вхідних даних функції вироблення ключа необхідно до точки застосовувати функцію . У другому випадку для одержання двох цілих чисел z1 та

z2 функцію необхідно застосовувати до двох точок. Два цілих числа, які були

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

Національна примітка

Ціле число z є вихідним значенням функції , що застосовується до

точки еліптичної кривої.

2. Параметри вироблення ключів, parameters, також представлено рядком октетів.

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

523

A.1.3 Дії

Якщо загальна довжина розділюваної таємниці z та параметри перевищують будь-які обмеження, що можуть існувати для узгодженої функції гешування hash, тоді у якості вихідних даних виводиться повідомлення “помилка” та зупиняється дія.

Інакше обчислюється значення K hash(z || parameters).

A.1.4 Вихідні дані

Вихідними даними є розділювана таємниця (ключ) K .

A.2 Функція вироблення ключа ANSI X9.42

У цьому розділі наведенофункцію вироблення ключа, що грунтується на функції вироблення ключа, яка описана у стандарті ANSI X9.42 [1].

A.2.1 Передумови

У якості функції гешування hash необхідно обирати функцію що визначена у стандарті ISO/IEC 10118. Нехай

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

A.2.2 Вхідні дані

Вхідними даними для цієї функції вироблення ключа є

1. ZZ : Таємниця що розділюється, яка визначається рядком бітів.

Два цілих числа, які були точками, потім необхідно перетворити у рядки октетів та для одержання відповідного рядка октетів з’єднати їх (операція конкатенації) або об’єднати їх, використовуючи будь-які методи безпрефіксного кодування

Примітка. Механізми, що вказані у розділах 8, 9 та 10, виробляють розділюваний ключ KAB або як точки еліптичної кривої, або як конкатенацію двох точок еліптичної кривої. У першому випадку для одержання значення розділюваної таємниці ZZ , до вхідних даних функції вироблення ключа необхідно застосовувати функцію до точки і результуюче ціле число перетворити на рядок бітів. У другому випадку для одержання двох цілих чисел z1 та z2 функцію необхідно застосовувати до двох

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

2. keydatalen : Ціле число представляє довжину ключових даних в бітах , що генерують. Це ціле число має

бути менше ніж (hashlen (232 1)).

3. OtherInfo: Бітовий рядок, який визначено у ASN.1 DER кодування, містить інформацію, яка визначена у

розділі A.2.5.

3.1 Інформація зі специфікації ключа складається з:

3.1.1AlgorithmID: унікальний ідентифікатор об’єкта (OID) симетричного алгоритму(ів) з якими будуть використовуватись ключові дані.

3.1.2Counter: 32-бітовий рядок октетів з початковим значенням 0000000116.

3.2(Необов’язково) PartyUInfo: Рядок бітів, що складається з відкритої інформації, що надана ініціатором.

3.3(Необов’язково) PartyVInfo: Рядок бітів, що складається з відкритої інформації, що надана

відповідачем.

3.4(Необов’язково) SuppPrivInfo: Рядок бітів, що складається з деякої додаткової взаємно відомої особистої інформації, наприклад, симетричний ключ, що є розділюваною таємницею, який переданий через окремий канал.

3.5(Необов’язково) SuppPubInfo: Рядок бітів, що складається з деякої додаткової взаємно відомої відкритої інформації.

524

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

A.2.3 Дії

Функцію вироблення ключа обчислюють таким чином:

1.Нехай d keydatalen/hashlen .

2.Виконати ініціалізацію Counter 0000000116.

3.Для i 1до d виконувати такі дії:

3.1 Обчислити hi hash(ZZ || OtherInfo), де hi визначає геш значення, що обчислено з застосуванням функції гешування.

3.2Збільшити Counter.

3.3Збільшити i.

4.Вибрати у якості ключа K з рядка h1 || h2 ||...|| hd . крайні зліва keydatalen бітів.

A.2.4 Вихідні дані

Ключовими даними К є рядок бітів довжини keydatalen біт.

Зазначимо, що ця функція вироблення ключа грунтується на ASN.1 DER кодуванні і виробляє ключові дані, довжина якихменша, ніж hashlen (232 1) бітів. Допускається, що всі звертання до функції вироблення

ключа є дійсними для рядків бітів, довжина яких менша, ніж hashlen (232 1) бітів. Будь-яка спроба

викликати функцію вироблення ключа, використовуючи рядок бітів, що більше або дорівнює hashlen (232 1) бітів, повинен видати повідомлення “неправильний параметр” та зупинитися.

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

A.2.5 Синтаксис ASN.1

Вхідними даними для функції вироблення ключа є розділювала таємниця ZZ та інша інформація

OtherInfo.

Інша інформація включає інформацію ініціатора PartyUInfo, інформацію відповідача PartyVInfo,

SuppPubInfo та SuppPrivInfo .

OtherInfo ::= SEQUENCE {

}

Counter ::= INTEGER (1..32767)

Поля suppPubInfo та suppPrivInfo , що використовуються у виробленні ключа, є необов’язковими. Ці поля можуть використовуватися для зберігання додаткової, допоміжної відкритої та особистої інформації, що є взаємно відомою для взаємодіючих сторін, але, яка не є відомою для іншої сторони.

Зміст suppPubInfo та suppPrivInfo визначають за допомогою протоколу управління ключами. Визначення, синтаксис та правила кодування полів suppPubInfo та suppPrivInfo покладаються на протокол управління ключами і виходять за межі сфери застосування цього стандарту.

Довжина всіх вхіднихданих для функції гешування, що виробляє ключ, повинна бути цілим числом октетів. suppPrivInfo може містити ZZ .