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

Рисунок 9 – Неієрархічний шлях сертифікації. Приклад

Нехай V – це УС, з яким органи, уповноважені на сертифікацію, U та W в

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

Користувач D повинен знайти шлях сертифікації до Е. Можуть бути використані різні стратегії. Одна з таких стратегій – розглядати користувачів та УС як вузли, а сертифікати як дуги у спрямованій графі. У таких умовах D має виконати пошук у графі для зходження шляху від U до E, яким у даному випадку є шлях U V ,V W ,W E . Після того як цей шлях буде

18.2.2 Процедури строгої автентифікації

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

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

цьому пункті описуються три конкретні процедури автентифікації, що можуть

бути корисні у всьому діапазоні застосунків.

ПРИМІТКА. Ця Специфікація Каталогу не визначає детально процедури, необхідні для реалізації. Однак можуть бути передбачені додаткові стандарти, які могли б виконувати це універсальним або специфічним для застосування способом.

Три наведені процедури використовують різне число сеансів обміну

інформацією автентифікації, отже, забезпечують різні ступені гарантій своїм

учасникам, а саме:

a)однопрохідна автентифікація, яку описано в 18.2.2.1, використовує одну передачу інформації від користувача (А), призначену для іншого користувача (В), і встановлює таке:

особу користувача А та підтвердження того, що маркер автентифікації був дійсно згенерований користувачем А;

особу користувача А та підтвердження того, що маркер автентифікації дійсно призначався для передачі користувачу В;

цілісність та „оригінальність” (передані не більше одного разу)

маркера автентифікації, що передається.

Останні властивості можуть також установлюватися для довільних

додаткових даних, що супроводжують процедуру;

b)двопрохідна автентифікація, описана в 18.2.2.2, додатково містить відповідь від В до А. Вона додатково встановлює:

що маркер автентифікації у відповіді був дійсно згенерований користувачем В та призначався для передачі користувачу А;

цілісність та „оригінальність” маркера автентифікації, що передається, у відповіді;

(необов’язково) взаємну таємність маркерів;

c)трипрохідна автентифікація, описана в 18.2.2.3, додатково використовує передачу від користувача А до користувача В та

встановлює ті ж властивості, що й двопрохідна автентифікація, але

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

У всіх випадках використання строгої автентифікації користувач А повинен отримати відкритий ключ користувача В та зворотний шлях сертифікації від користувача В до користувача А. Це може обумовити звернення до Каталогу, як описано в 18.2. Такий доступ не згадується знов під час опису процедур.

Перевірка позначок часу, що згадується в наступних підпунктах,

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

Для кожної з трьох процедур, що описуються нижче, припускається, що сторона Авже перевірила чинність усіх сертифікатів на шляху сертифікації.

18.2.2.1 Однопрохідна автентифікація

При однопрохідній автентифікації (рисунок 10) виконуються такі кроки:

1)користувач А генерує rA (номер, що не повторюється), який використовується для виявлення атак типу повтор та попередження підробок;

2)користувач А пересилає користувачу В таке повідомлення:

BA,A tA ,rA ,B

де tA – позначка часу, що складається з однієї або двох дат: дати

створення маркера (що є необов’язковим) та дати завершення строку дії. Як варіант, якщо автентифікація джерела даних „sgnData” має забезпечуватися цифровим підписом, тоді повідомлення матиме вигляд:

BA,A tA ,rA ,B,sgnData .

У тих випадках, коли інформація, що передається, має потім використовуватися як особистий ключ (ця інформація позначається

„encData”), повідомлення матиме вигляд:

BA,A tA ,rA ,B,sgnData,BP encData .

Використання „encData” як особистого ключа передбачає, що його треба обирати уважно, наприклад, він має бути сильним ключем для будь-якої криптосистеми, що використовується, як зазначено в полі

„sgnData” маркера.

3)користувач В виконує такі дії:

a)отримує AP від ВА, перевіряючи, що строк чинності сертифіката користувача А, не закінчився;

b)перевіряє цифровий підпис і тим самим цілісність підписаної інформації;

c)перевіряє, що він сам є зазначеним одержувачем;

d)перевіряє, що позначка часу має значення „поточна”;

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

Значення rA має силу до завершення дати, позначеної tA . Значення tA

завжди супроводжується послідовною частиною, яка вказує, що А не повинен повторювати маркер протягом інтервалу часу tA , і тому не потрібна перевірка значення самого rA .

У будь-якому випадку для сторони В доцільно зберігати протягом інтервалу часу tA послідовну частину разом з позначкою часу tA у

відкритому стані та разом з гешованою частиною маркера.

a)перевіряє цифровий підпис і тим самим цілісність підписаної інформації;

b)перевіряє, що він сам є зазначеним одержувачем;

c)перевіряє, що позначка часу має значення „поточна”;

d)перевіряє необов’язково, що rB повторно не використаний (див. 18.2.2.1, крок 3), d).

Рисунок 11– Двопрохідна автентифікація

18.2.2.3 Трипрохідна автентифікація

При трипрохідній автентифікації (рисунок 12) виконуються такі кроки:

1) як і в 18.2.2.2;

2) як і в 18.2.2.2. Позначка часу tA може бути нульовою;

3)як і в 18.2.2.2 за винятком того, що не має перевірятися позначка часу;

4)як і в 18.2.2.2;

5)як і в 18.2.2.2. Позначка часу tB може бути нульовою;

6)як і в 18.2.2.2 за винятком того, що відмітка часу не має перевірятися;

7)перевіряє, чи ідентичний отриманий rA переданому rA ;

8)користувач А надсилає користувачу В такий маркер автентифікації:

A rB,B ;

9)користувач В виконує такі дії:

a)перевіряє цифровий підпис і тим самим цілісність підписаної інформації;

b)перевіряє, щоб отриманий rB був ідентичним rB , який передано стороною В.

7.4 Аналіз крипто протоколів автентифікаціїавтентифікації

та встановлення ключів ДСТУ ISO/IEC 15946 - 3

7.4.1 Загальна постановка та аналіз задач

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

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

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

При виконанні протоколів треба реалізовувати:

-узгодження спільної інформації та параметрів;

-налаштування параметрів.

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

При проективному представленні XPi ,YPi ,ZPi

Qi diG modq .

Якщо ключ є викривлений, то він може не входити в циклічну групу порядку n і тому гарантії того що порядок теж n немає.

Перевіряння належності Qi ,Pi ,G еліптичній кривій: y2 x3 ax b mod p .

Для проективного базису ЕК над полем GF(2m )

Y2 XYZ X3 aX2Z2 bZ6(mod(x),2).

Для поля GF(2m ), q 2m , еліптична крива у афінному базисі задається у вигляді:

y2 xy x3 ax2 b(mod f (x),2).

Для захисту від таких загроз запропоновано використовувати кофакторне множення, де кофактор h – це коефіцієнт, що зв’язує порядок кривої з порядком базової точки G.

U h n.

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

7.4.2 Аналіз крипто протоколів встановлення ключів (узгодження ключів)

Протокол з нульовим проходом та кофакторним множенням.

Суб’єкти А та В формують особисті ключі dA та dB відповідно. Потім формують відкриті ключі:

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

Пропонується ввести:

- кофактор h U ; n

- деяке значення l.

Коли не ставиться задача узгодженості з іншим протоколом:

h U , l 1 n .

Коли вимагається узгодженість:

h U , l h 1 modn n .

Коли кофакторне множення не використовується: h 1, l 1.

7.4.4 Опис та аналіз протоколів передавання ключів

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

автентифікація передавання ключа; захист від раніше переданих повідомлень; конфіденційність ключа.

Реалізація протоколу.

Нехай суб’єкт А генерує таємний ключ К та формує блок відкритих даних:

BS A|| K ||TVP||Text1,

де А – ідентифікатор суб’єкта А;

TVP – позначка часу (порядковий номер повідомлення); К – таємний ключ.

TVP дозволяє відрізнити повтор повідомлення.

Направлений шифр EB ,DB , де DB – особисте перетворення, а EB – відкрите перетворення суб’єкта В.

EB BS EB A|| K ||TVP||Text1 .

Якщо використовується RSA, то:

BSiEB mod Nj .

Далі, суб’єкт А передає EB суб’єкту В.

DB EB BS DB EB A|| K ||TVP||Text1 .

Характеристики протоколу: протокол однопрохідний; автентифікація суб’єкта В; не забезпечує крипто живучості.

7.4.5 Особливості протоколів розподілу ключів через третю сторону

Загальна задача: необхідно виробити спільний секрет або ключ, забезпечивши:

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

захист від раніше переданих повідомлень; модифікування.

Суб’єкти А та В мають узгодженні з третьою стороною Т ключі. Нехай суб’єкт В – ініціатор.

1. Суб’єкт В формує та передає запит RB .

2. Суб’єкт А одержує RB , шифрує його на ключі KAT :

KAT RA || RB || B|| F ||Text1

і передає третій стороні Т. F – функція ключа (ключова інформація). 3. Сторона Т шифрує:

KAT RA || B||Text2

і передає суб’єкту А, а також сторона Т шифрує і передає А:

KBT RB || F || A||Text3 . 4. Суб’єкт А шифрує:

K R || R ||Text4 ;

A B

KBT RB || F || A||Text3

та передає суб’єкту В. Суб’єкт В шифрує:

K RА || RB ||Text5 .

5. Суб’єкт А виділяє RA , яке посилав раніше, що підтверджує цілісність з’єднання.

Характеристики протоколу: протокол багато раундовий;

якість ключа залежить від кількості раундів; краще взаємодіяти через довірену сторону.