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

Вона складається зтаких кроків:

1)користувач-відправник А посилає свої розпізнавальне ім’я та пароль користувачу-одержувачу В;

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

Каталогу, де пароль порівнюється з паролем, що міститься в атрибуті

UserPassword у записі Каталогу для користувача А (використовуючи

операцію зіставлення Каталогу);

3)Каталог підтверджує (або заперечує) для користувача В дійсність посвідчення особи;

4)результат автентифікації (успіх або невдача) може передаватися користувачу А.

Базова форма простої автентифікації містить лише крок 1, а після

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

виконуватисякрок 4.

18.1.1 Генерація захищеної ідентифікуючої інформації

На рисунку 6 наведено два підходи до генерації захищеної ідентифікуючої інформації. f1 та f2 - це односпрямовані функції (однакові

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

A – розпізнавальне ім’якористувача tA – відмітки часу

парольA –пароль користувача А

qA – випадкові числа, які, у разі необхідості, можуть вироблятися в

режимі лічильника Рисунок 6 – Захищена проста автентифікація

18.1.2 Процедура захищеної простої автентифікації

На рисунку 7 зображено процедуру захищеної простої автентифікації.

Рисунок 7 – Процедура захищеної простої автентифікації

Процедура простої захищеної автентифікації містить в собі такі кроки

(спочатку використовуєтьсялише f1):

1)користувач–відправник А пересилає свою захищену ідентифікуючу інформацію (Автентифікатор1) користувачу В. Захист здійснюється за

допомогою застосування односпрямованої функції ( f1), як наведено на

рисунку 6, де позначка часу та/або випадкове число (якщо

використовується) використовуються, для того щоб зменшити

кількість повторів та сховати пароль.

Захист пароля користувача А має вигляд:

Захист1 f1 t1A,q1A ,A,парольA

Інформація, що передається користувачу В, має вигляд:

Автентифікатор1 t1A ,q1A ,A,Захист1;

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

користувача та необов’язкову позначку часу та/або випадкове число,

що надається користувачем А) локальної захищеної копії пароля користувача А (у вигляді Захист1). Користувач В порівнює ідентифікуючу інформацію (Захист1) з локально згенерованим значенням;

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

Для того, щоб надати більший рівень захисту ця процедура може бути змінена шляхом використання функцій f1 та f2 . Основні відмінності

полягають у такому:

1)користувач А пересилає користувачу В додатково захищену ідентифікуючу інформацію (Автентифікатор2). Додатковий захист

досягається при застосуванні додаткової односпрямованої функції f2 ,

як показано на рисунку 6. Додатковий захист має вигляд:

Захист2 f2 t2A ,q2A ,Захист1 .

Інформація, що передається користувачу В, має вигляд:

Автентифікатор2 t1A ,t2A ,q1A ,q2A ,A,Захист2;

Під час виконання операції зіставлення користувач В генерує локальне

значення додатково захищеного пароля та порівнює його зі значенням

Захист2 .

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

ПРИМІТКА. Процедури, які визначено в цих підрозділах, позначені в термінах користувачів А та В. Стосовно Каталогу (визначеного в ITU-T Rec. X.511 | ISO/IEC 9594-3 та ITU-T Rec. X.518 | ISO/IEC 9594-4),

користувач А може бути АКК пов’язаний з АСК; альтернативно, А може бути АСК пов’язаний з іншим АСК користувача В.

18.1.3 Тип атрибута „Пароль користувача”

Цей тип атрибута містить пароль об’єкта. Значення атрибута для пароля користувача – це рядок визначений об’єктом.

Атрибут визначено таким способом:

18.2 Строга автентифікація

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

репозиторій. Якщо ці процедури використовують Каталог, то термін

„користувач” у таких процедурах може мати відношення як до АКК, так і до АСК.

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

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

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

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

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

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

Автентифікація розрахована на будь-якого користувача, що має унікальне розпізнавальне ім’я. За розподіл розпізнавальних імен несуть відповідальність органи, уповноважені на присвоєння імен. Ось чому кожен користувач має довіряти, що орган, уповноважений на присвоєння імен, не буде випускати дублікати розпізнавальних імен.

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

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

Для того, щоб користувач міг визначити, що партнер по обміну володіє особистим ключем іншого користувача, він має володіти відкритим ключем цього користувача. Якщо процедура отримання значення відкритого ключа безпосередньо із запису користувача в Каталозі є достатньо простою, то процедура перевірки його дійсності більш складна. Існує кілька способів вирішення цієї проблеми: у 18.2.1 описано процес, за допомогою якого можна перевірити відкритий ключ шляхом звернення до Каталогу. Такий процес можна використовувати тільки в тому випадку, якщо між користувачами, що потребують автентифікації, існує безперервний ланцюжок точок довіри в Каталозі. Такий ланцюжок можна побудувати шляхом встановлення спільної точки довіри. Ця спільна точка має бути пов’язана з кожним користувачем безперервного ланцюжка точок довіри.

18.2.1 Отримання сертифікатів відкритого ключа із

Каталогу (валідація)

Сертифікати зберігаються в записах Каталогу у вигляді атрибутів

UserCertificate, CACertificate та CrossCertificatePair. Ці типи атрибутів відомі Каталогу. Вони можуть використовуватися у тих же операціях Каталогу, що використовують інші атрибути. Визначення цих типів наведено у 3.3.

Специфікацію цих типів атрибутів визначено в 11.2.

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

a)якщо два користувачі, що бажають виконати автентифікацію,

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

b)якщо органи, уповноважені на сертифікацію користувачів,

розташовані ієрархічно, тоді користувач має зберігати відкриті ключі,

сертифікати та зворотні сертифікати усіх органів, уповноважених на сертифікацію, між користувачем та коренем ІДК. Звичайно, це потребує від користувача знання відкритих ключів та сертифікатів тільки трьох або чотирьох органів, уповноважених на сертифікацію,

при цьому користувачу необхідно лише отримати шлях сертифікації від спільної точки довіри;

c)якщо користувач часто взаємодіє з іншими користувачами, які отримали сертифікати від іншого УС, то такий користувач уже міг отримати шлях сертифікації до цього УС та зворотний шлях від УС,

тому йому потрібно лише отримати сертифікат іншого користувача із

Каталогу;

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

Результатом є більш короткий шлях сертифікації;

e)якщо два користувача взаємодіяли до цього та мають сертифікати один одного, то вони можуть виконати автентифікацію без звернення до Каталогу.

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

18.2.1.1 Приклад

На рисунку 8 наведено гіпотетичний приклад фрагменту ІДК, де УС складають ієрархію. Крім інформації, яка наведена на рисунку для УС, кожен користувач знає відкритий ключ свого органу, уповноваженого на сертифікацію, свій власний відкритий та особистий ключ.

Рисунок 8 – Ієрархія УС. Гіпотетичний приклад

Якщо УС користувачів розташовані ієрархічно, користувач А для встановлення шляху сертифікації до користувача В може отримувати із Каталогу такі сертифікати:

X W ,W V ,V Y ,Y Z ,Z B

Користувач А, отримавши такі сертифікати, може розгорнути шлях сертифікації в такій послідовності, що надає зміст сертифіката користувача B ,

разом з тим BP :

BP XP X W W V V Y Y Z Z B

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

Z Y ,Y V ,V W ,W X ,X A

При отриманні таких сертифікатів від А користувач В, для того щоб отримати зміст сертифіката користувача A , а разом з тим AP , може

розгорнути зворотний шлях сертифікації у такій послідовності:

AP ZP Z Y Y V V W W X X A

Застосуємо оптимізацію відповідно до 18.2.1:

a)наприклад, візьмемо А та С: обидва знають XP тому А має просто отримати сертифікат С. Розгорнутий шлях сертифікації зводиться до

CP XP X C ,

арозгортання зворотного шляху сертифікації зводиться до

АP XP X А ;

користувач А має отримати із Каталогу для формування шляху

сертифікації, зводиться до:

V Y ,Y Z ,Z B .

Інформація, яку А повинен отримати із Каталогу для формування

зворотного шляху сертифікації, зводиться до

Z Y ,Y V ;

c) припускаючи, що користувач А часто взаємодіє з користувачами, що

ключів, які були отримані на b)). Для того, щоб зв’язатися з В, йому потрібно лише отримати із Каталогу Z B ;

d)припускаючи, що користувачі, які отримали сертифікати від X та Z,

часто взаємодіють між собою, то X Z має зберігатися в записі Каталогу для Х, і навпаки (як показано на рисунку 8). Якщо А бажає

автентифікувати В, йому необхідно лише отримати:

X Z ,Z B

для формування шляху автентифікації та

Z X

для формування зворотного шляху автентифікації;

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

CP XP X C

та

АP XP X А .

Убільш загальному випадку органи, уповноважені на сертифікацію,

ієрархічно не взаємозв’язані. Звертаючись до гіпотетичного прикладу на рисунку 9, припустимо, що користувач D, який отримав сертифікат від U,

бажає виконати автентифікацію з користувачем Е, який отримав сертифікат від W. Запис користувача D в Каталозі має містити сертифікат U D , а

запискористувача Е– сертифікат W E .