1. НОУ ІНТУЇТ | лекція | Методи захисту інформації в комп'ютерних системах і мережах 3.9. Методи...
2. 3.9.2. аутентифікація суб'єкта
3. 3.9.3. Симетричні методи аутентифікації суб'єкта
4. 3.9.4. схема Kerberos
5. 3.9.5. Несиметричні методи аутентифікації суб'єкта
6. 3.9.6. аутентифікація об'єкта
7. НОУ ІНТУЇТ | лекція | Методи захисту інформації в комп'ютерних системах і мережах
8. 3.9.2. аутентифікація суб'єкта
9. 3.9.3. Симетричні методи аутентифікації суб'єкта
10. 3.9.4. схема Kerberos
11. 3.9.5. Несиметричні методи аутентифікації суб'єкта
12. НОУ ІНТУЇТ | лекція | Методи захисту інформації в комп'ютерних системах і мережах
13. 3.9.2. аутентифікація суб'єкта
14. 3.9.3. Симетричні методи аутентифікації суб'єкта
15. 3.9.4. схема Kerberos
16. 3.9.5. Несиметричні методи аутентифікації суб'єкта
17. 3.9.6. аутентифікація об'єкта

НОУ ІНТУЇТ | лекція | Методи захисту інформації в комп'ютерних системах і мережах

3.9. Методи аутентифікації інформації

3.9.1. Ідентифікація, аутентифікація і авторизація

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

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

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

Процес розпізнавання законного користувача в схематичному вигляді представлений на Мал. 3.29 .

Процедури аутентифікації повинні бути стійкі до фальсифікації, підбору і підробці.

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

Існують різні механізми реалізації розмежування доступу. Наприклад, кожному ресурсу (або компоненту) системи може бути зіставлений список управління доступом ACL (Access Control List), в якому вказані ідентифікатори всіх користувачів, яким дозволений доступ до цього ресурсу, а також визначено, який саме доступ дозволений. При зверненні користувача до конкретного ресурсу система перевіряє наявність у даного ресурсу списку управління доступом і, якщо він існує, з'ясовує, чи дозволено цього користувачеві працювати з даними ресурсом в запрошенном режимі. Іншим прикладом реалізації механізму авторизації користувача є профіль користувача - список, що ставить у відповідність усім код користувача перелік об'єктів, до яких дозволений доступ цьому користувачеві із зазначенням типу доступу. Може бути організована системна структура даних, так звана матриця доступу, яка представляє собою таблицю, стовпці якої відповідають ідентифікаторів всіх системних ресурсів, а рядки - ідентифікаторів всіх зареєстрованих користувачів. На перетині i-го стовпця і j-го рядка таблиці адміністратор системи вказує дозволений тип доступу власника i-го ідентифікатора до j-му ресурсу.

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

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

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

3.9.2. аутентифікація суб'єкта

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

Класичним засобом аутентифікації суб'єкта є парольні схеми. При цьому для усунення наслідків несанкціонованого доступу противника до інформації, що зберігається в пам'яті комп'ютера верифікатори, зберігається не сам пароль PW (password), а його хеш-образ q = h (PW).

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

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

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

Перевірка справжності передбачає використання:

• неповторяющихся блоків даних, в якості яких виступають тимчасові мітки;
• механізму "запит-відповідь";
• процедури рукостискання (handshake).

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

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

3.9.3. Симетричні методи аутентифікації суб'єкта

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

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

Протокол Нідхема-Шредера:

1. суб'єкт А, який хоче взаємодіяти з суб'єктом В, посилає З повідомлення, що містить ідентифікатори суб'єктів запитуваної взаємодії

   ;

2. суб'єкт С, отримавши повідомлення, формує сеансовий ключ KAB для взаємодії суб'єктів А і В і посилає А зашифроване повідомлення

   ,

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

3. суб'єкт А, розшифрувавши отримане повідомлення, визначає ключ і дозвіл

   ,

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

   ,

   що містить зашифрований запит і дозвіл, отримане від С;

4. суб'єкт В, прочитавши шифровку

   ,

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

   ;

5. суб'єкт А, отримавши повідомлення, розшифровує його і перевіряє відповідь В; в разі позитивного результату перевірки, процес аутентифікації успішно завершується.

3.9.4. схема Kerberos

Рішення завдання аутентифікації в сучасних інформаційних системах, що представляють собою сукупність реалізованих на різних апаратно-програмних платформах, територіально рознесених компонентів, відповідно до технології клієнт / сервер полягає в використанні спеціального сервера аутентифікації. В даний час на роль фактичного стандарту сервера аутентифікації претендує Kerberos, продукт розроблений в Массачусетському технологічному інституті (MIT) в середині 1980-х рр. і хто витерпить з тих пір ряд принципових змін. Широкому поширенню Kerberos сприяло те, що його версія, реалізована в MIT, є вільно поширюваним продуктом. Програмні засоби, що виконують аутентифікацію за схемою Kerberos, розроблені для всіх популярних ОС. Підтримка служби Kerberos передбачена в деяких сучасних мережевих ОС. Схема Kerberos є типовим прикладом реалізації симетричних методів аутентифікації, вона приведена на Мал. 3.33 .

Схема передбачає взаємодію між трьома програмними компонентами - клієнтом С, сервером Kerberos і прикладним сервером S. ПО сервера Kerberos розділене за своїми функціями на дві частини: сервер аутентифікації AS (Authentication Server) і сервер видачі дозволів (квитків) TGS (Ticket Granting Server). Клієнт С - це комп'ютер, на якому встановлено клієнтське ПЗ, здатне брати участь у взаємодії по протоколу Kerberos, і зареєстрований будь-якої користувач. У деяких випадках прикладної сервер може бути клієнтом деякого іншого сервера, наприклад сервер друку може користуватися послугами файлового сервера. Сервер S - суб'єкт, що надає ресурси мережевим клієнтам.

Клієнт С, який хоче звернутися до прикладного сервера для отримання його послуг, повинен отримати дозвіл від AS. Дозвіл - це зашифрована інформація, яку клієнт передає серверу S або сервера TGS. Дозвіл дозволяє серверу переконатися в достовірності клієнта. Всі дозволи, крім першого, клієнт отримує від сервера TGS. Перший дозвіл, дозвіл на доступ до самого TGS, клієнт отримує від сервера AS. Дозвіл - це шифровка, отримана на секретному ключі, відомому тільки серверу S і сервера Kerberos, тому перший, отримавши дозвіл, може бути впевнений, що воно надійшло саме від сервера Kerberos. Дозволи є багаторазовими, які мали певний термін життя (декілька годин). Коли цей термін закінчується, клієнт повинен знову пройти процедуру аутентифікації. При встановленні кожного з'єднання використовується тимчасова мітка, тому в мережі повинна діяти служба єдиного часу. Необхідність в сервері TGS пояснюється прагненням скоротити число повідомлень, зашифрованих з використанням секретного ключа клієнта, якому потрібні послуги декількох серверів. Саме тому сервер Kerberos "роздвоюється" на сервер AS, з яким клієнт взаємодіє за допомогою секретного ключа , І сервер TGS, з яким клієнт здійснює подальшу взаємодію за допомогою тільки сеансових ключів . Компрометація сеансового ключа, що має дуже короткий час життя, річ значно менш небезпечна, ніж розкриття секретного ключа.

Процес аутентифікації складається з п'яти (одностороння аутентифікація) або шести (взаємна аутентифікація) кроків.

1. Клієнт З посилає серверу аутентифікації повідомлення, що містить ідентифікатори клієнта і необхідного сервера видачі дозволів , Що відповідає за надання відповідної послуги, а також інформацію , Призначену для ідентифікації конкретного запиту: час, свій мережеву адресу і т.п.
2. Сервер аутентифікації здійснює пошук в базі даних Kerberos за ідентифікатором клієнта і ідентифікатором послуги, знаходить відповідні ключі і , Формує сеансовий ключ для взаємодії клієнта і сервера видачі дозволів. Після цього сервер AS посилає відповідь клієнту. Ця відповідь містить дві шифровки. Перша, отримана на секретному ключі клієнта , Містить сеансовий ключ для роботи з сервером видачі дозволів, ідентифікатор останнього і термін життя дозволу клієнта на роботу з сервером TGS. Друга шифровка, отримана на ключі , - це дозвіл (Ticket-granting ticket) клієнту на взаємодію з сервером TGS. До складу другої шифровки, яку клієнт прочитати не може, тому що не знає ключа , Входять ідентифікатори і , Сеансовий ключ і термін життя цього дозволу .
3. Отримавши повідомлення, клієнт розшифровує першу його половину на ключі , Перевіряє позначку , Дізнається сеансовий ключ і термін життя дозволу на роботу з сервером TGS. Таким чином, в результаті обміну повідомленнями з сервером AS клієнт отримує дозвіл на роботу з сервером TGS. Потім клієнт надсилає запит серверу видачі дозволів. Повідомлення для сервера TGS включає в себе дві шифровки. Перша, отримана на сеансовому ключі , Включає в себе ідентифікатори і , Ідентифікатор запиту і тимчасову мітку . Друга - це "запечатаний" ключем Дозвіл .
4. Сервер видачі дозволів розшифровує дозвіл , Дізнається сеансовий ключ , За допомогою якого читає першу частину прийшов повідомлення і перевіряє ідентифікатор і тимчасову мітку . Упевнившись в автентичності клієнта, сервер TGS виробляє сеансовий ключ для взаємодії клієнта С і сервера S. На знанні цього ключа і буде грунтуватися в майбутньому взаємна аутентифікація C і S. Після цього сервер відправляє повідомлення клієнту, що містить зашифровані на ключі сеансовий ключ і термін життя дозволу клієнта на роботу з сервером, а також саме це дозвіл , Зашифроване на секретному ключі .
5. Клієнт, отримавши повідомлення, розшифровує першу його частину, з якої витягує сеансовий ключ для роботи з сервером S і термін життя дозволу на взаємодію з сервером S. Саме "запечатаний" ключем Дозвіл клієнт прочитати не може. Таким чином, в результаті обміну з сервером видачі дозволів клієнт отримує дозвіл на подальшу взаємодію вже з прикладним сервером. Нарешті, клієнт посилає серверу S повідомлення, що містить зашифровані на сеансовому ключі свій ідентифікатор , ідентифікатор і тимчасову мітку , А також дозвіл , Отримане від сервера TGS.
6. Прийнявши повідомлення від клієнта і "роздрукувавши" дозвіл , Цільової сервер дізнається сеансовий ключ і з його допомогою проводить аутентифікацію клієнта, перевіряючи ідентифікатор і тимчасову мітку . Відповідь сервера клієнту надсилається в тому випадку, коли потрібно взаємна аутентифікація. Відповідь прикладного сервера в цьому випадку містить зашифрований на ключі результат перетворення мітки .

Сервер Kerberos має доступ до бази даних, що містить ідентифікатори і секретні ключі суб'єктів. Запис кожного користувача і кожного прикладного сервера в базі даних Kerberos містить наступні компоненти:

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

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

Крім серверів AS і TGS в системі є об'єкт, який відповідає за управління базою даних, званий диспетчером бази даних Kerberos DBM (Database Manager), а також сервер поширення ключів Kerberos KDS (Key Distribution Server).

3.9.5. Несиметричні методи аутентифікації суб'єкта

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

Протокол Діффі-Хеллмана. Несіметрічні методи аутентіфікації могут буті засновані на вікорістанні механізму електронного підпісу. Класичним прикладом несіметрічною аутентіфікації может служити схема Діффі-Хеллмана, что представляет собою сукупність процедури Вироблення Загальна секретного ключа и взаємної аутентіфікації суб'єктів взаємодії. Припустимо, w - примітивний елемент поля Галуа GF (p), де p - просте число. Абонент А володіє парою ключів: - відкритим і - закритим. Абонент В володіє парою ключів: - відкритим і - закритим. Тоді послідовність взаємної аутентифікації складається з трьох кроків.

Схема аутентифікації Діффі-Хеллмана.

1. Абонент А виробляє випадкове число і надсилає абоненту В повідомлення

   (Тут і далі передбачається, що всі операції виконуються за модулем p).

2. Абонент В виробляє випадкове число , обчислює , На своєму секретному ключі створює підпис

   ПОВІДОМЛЕННЯ

   Потім В обчислює сеансовий ключ

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

   , ,

   де

3. Абонент А обчислює сеансовий ключ

   за допомогою свого секретного ключа створює підпис

   ПОВІДОМЛЕННЯ

   зашифровує її на ключі і відправляє В повідомлення

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

   він може бути впевнений в достовірності абонента В.

5. Якщо перевірка підпису А абонентом В завершилася успішно, тобто У переконався в справедливості рівності він в свою чергу може бути впевнений в достовірності абонента А.

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

Для реалізації схеми необхідний центр довіри, який вибирає і публікує ціле число виду N = pq, де p і q - прості числа, які тримаються в секреті. Припустимо, абонент А є доводить, абонент В - перевіряючим. Абонент А (або центр довіри) формує відкритий і секретний ключі:

і оголошує їх відкритим ключем .

Протокол аутентифікації Е. Фіата і А. Шаміра складається в t-кратному повторенні таких кроків.

Схема Фіата-Шаміра.

1. Абонент А вибирає випадкове число , обчислює

   і посилає його В.

2. Абонент В вибирає випадкову двійкову послідовність

   {0, 1}, j = 1, ..., m

   і посилає її А.

3. Абонент А обчислює

   і посилає його В.

4. Абонент В перевіряє рівність

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

3.9.6. аутентифікація об'єкта

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

Процедури аутентифікації повинні бути стійкі до фальсифікації, підбору і підробці.

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

Існують різні механізми реалізації розмежування доступу. Наприклад, кожному ресурсу (або компоненту) системи може бути зіставлений список управління доступом ACL (Access Control List), в якому вказані ідентифікатори всіх користувачів, яким дозволений доступ до цього ресурсу, а також визначено, який саме доступ дозволений. При зверненні користувача до конкретного ресурсу система перевіряє наявність у даного ресурсу списку управління доступом і, якщо він існує, з'ясовує, чи дозволено цього користувачеві працювати з даними ресурсом в запрошенном режимі. Іншим прикладом реалізації механізму авторизації користувача є профіль користувача - список, що ставить у відповідність усім код користувача перелік об'єктів, до яких дозволений доступ цьому користувачеві із зазначенням типу доступу. Може бути організована системна структура даних, так звана матриця доступу, яка представляє собою таблицю, стовпці якої відповідають ідентифікаторів всіх системних ресурсів, а рядки - ідентифікаторів всіх зареєстрованих користувачів. На перетині i-го стовпця і j-го рядка таблиці адміністратор системи вказує дозволений тип доступу власника i-го ідентифікатора до j-му ресурсу.

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

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

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

НОУ ІНТУЇТ | лекція | Методи захисту інформації в комп'ютерних системах і мережах

3.9. Методи аутентифікації інформації

3.9.1. Ідентифікація, аутентифікація і авторизація

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

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

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

Процес розпізнавання законного користувача в схематичному вигляді представлений на Рис. 3.29 .

Процедури аутентифікації повинні бути стійкі до фальсифікації, підбору і підробці.

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

Існують різні механізми реалізації розмежування доступу. Наприклад, кожному ресурсу (або компоненту) системи може бути зіставлений список управління доступом ACL (Access Control List), в якому вказані ідентифікатори всіх користувачів, яким дозволений доступ до цього ресурсу, а також визначено, який саме доступ дозволений. При зверненні користувача до конкретного ресурсу система перевіряє наявність у даного ресурсу списку управління доступом і, якщо він існує, з'ясовує, чи дозволено цього користувачеві працювати з даними ресурсом в запрошенном режимі. Іншим прикладом реалізації механізму авторизації користувача є профіль користувача - список, що ставить у відповідність усім код користувача перелік об'єктів, до яких дозволений доступ цьому користувачеві із зазначенням типу доступу. Може бути організована системна структура даних, так звана матриця доступу, яка представляє собою таблицю, стовпці якої відповідають ідентифікаторів всіх системних ресурсів, а рядки - ідентифікаторів всіх зареєстрованих користувачів. На перетині i-го стовпця і j-го рядка таблиці адміністратор системи вказує дозволений тип доступу власника i-го ідентифікатора до j-му ресурсу.

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

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

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

3.9.2. аутентифікація суб'єкта

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

Класичним засобом аутентифікації суб'єкта є парольні схеми. При цьому для усунення наслідків несанкціонованого доступу противника до інформації, що зберігається в пам'яті комп'ютера верифікатори, зберігається не сам пароль PW (password), а його хеш-образ q = h (PW).

Для усунення наслідків перехоплення інформації, переданої претендентом, або несанкціонованого доступу противника до інформації, що зберігається в пам'яті комп'ютера верифікатори, може бути рекомендована схема, показана на Рис. 3.30 .

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

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

Перевірка справжності передбачає використання:

• неповторяющихся блоків даних, в якості яких виступають тимчасові мітки;
• механізму "запит-відповідь";
• процедури рукостискання (handshake).

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

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

3.9.3. Симетричні методи аутентифікації суб'єкта

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

на Рис. 3.32 показана схема процедури взаємної аутентифікації суб'єктів А і В з використанням довіреної третьої сторони - суб'єкта С, що володіє секретними ключами і відповідно для взаємодії з А і В.

Протокол Нідхема-Шредера:

1. суб'єкт А, який хоче взаємодіяти з суб'єктом В, посилає З повідомлення, що містить ідентифікатори суб'єктів запитуваної взаємодії

   ;

2. суб'єкт С, отримавши повідомлення, формує сеансовий ключ KAB для взаємодії суб'єктів А і В і посилає А зашифроване повідомлення

   ,

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

3. суб'єкт А, розшифрувавши отримане повідомлення, визначає ключ і дозвіл

   ,

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

   ,

   що містить зашифрований запит і дозвіл, отримане від С;

4. суб'єкт В, прочитавши шифровку

   ,

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

   ;

5. суб'єкт А, отримавши повідомлення, розшифровує його і перевіряє відповідь В; в разі позитивного результату перевірки, процес аутентифікації успішно завершується.

3.9.4. схема Kerberos

Рішення завдання аутентифікації в сучасних інформаційних системах, що представляють собою сукупність реалізованих на різних апаратно-програмних платформах, територіально рознесених компонентів, відповідно до технології клієнт / сервер полягає в використанні спеціального сервера аутентифікації. В даний час на роль фактичного стандарту сервера аутентифікації претендує Kerberos, продукт розроблений в Массачусетському технологічному інституті (MIT) в середині 1980-х рр. і хто витерпить з тих пір ряд принципових змін. Широкому поширенню Kerberos сприяло те, що його версія, реалізована в MIT, є вільно поширюваним продуктом. Програмні засоби, що виконують аутентифікацію за схемою Kerberos, розроблені для всіх популярних ОС. Підтримка служби Kerberos передбачена в деяких сучасних мережевих ОС. Схема Kerberos є типовим прикладом реалізації симетричних методів аутентифікації, вона приведена на Рис. 3.33 .

Схема передбачає взаємодію між трьома програмними компонентами - клієнтом С, сервером Kerberos і прикладним сервером S. ПО сервера Kerberos розділене за своїми функціями на дві частини: сервер аутентифікації AS (Authentication Server) і сервер видачі дозволів (квитків) TGS (Ticket Granting Server). Клієнт С - це комп'ютер, на якому встановлено клієнтське ПЗ, здатне брати участь у взаємодії по протоколу Kerberos, і зареєстрований будь-якої користувач. У деяких випадках прикладної сервер може бути клієнтом деякого іншого сервера, наприклад сервер друку може користуватися послугами файлового сервера. Сервер S - суб'єкт, що надає ресурси мережевим клієнтам.

Клієнт С, який хоче звернутися до прикладного сервера для отримання його послуг, повинен отримати дозвіл від AS. Дозвіл - це зашифрована інформація, яку клієнт передає серверу S або сервера TGS. Дозвіл дозволяє серверу переконатися в достовірності клієнта. Всі дозволи, крім першого, клієнт отримує від сервера TGS. Перший дозвіл, дозвіл на доступ до самого TGS, клієнт отримує від сервера AS. Дозвіл - це шифровка, отримана на секретному ключі, відомому тільки серверу S і сервера Kerberos, тому перший, отримавши дозвіл, може бути впевнений, що воно надійшло саме від сервера Kerberos. Дозволи є багаторазовими, які мали певний термін життя (декілька годин). Коли цей термін закінчується, клієнт повинен знову пройти процедуру аутентифікації. При встановленні кожного з'єднання використовується тимчасова мітка, тому в мережі повинна діяти служба єдиного часу. Необхідність в сервері TGS пояснюється прагненням скоротити число повідомлень, зашифрованих з використанням секретного ключа клієнта, якому потрібні послуги декількох серверів. Саме тому сервер Kerberos "роздвоюється" на сервер AS, з яким клієнт взаємодіє за допомогою секретного ключа , І сервер TGS, з яким клієнт здійснює подальшу взаємодію за допомогою тільки сеансових ключів . Компрометація сеансового ключа, що має дуже короткий час життя, річ значно менш небезпечна, ніж розкриття секретного ключа.

Процес аутентифікації складається з п'яти (одностороння аутентифікація) або шести (взаємна аутентифікація) кроків.

1. Клієнт З посилає серверу аутентифікації повідомлення, що містить ідентифікатори клієнта і необхідного сервера видачі дозволів , Що відповідає за надання відповідної послуги, а також інформацію , Призначену для ідентифікації конкретного запиту: час, свій мережеву адресу і т.п.
2. Сервер аутентифікації здійснює пошук в базі даних Kerberos за ідентифікатором клієнта і ідентифікатором послуги, знаходить відповідні ключі і , Формує сеансовий ключ для взаємодії клієнта і сервера видачі дозволів. Після цього сервер AS посилає відповідь клієнту. Ця відповідь містить дві шифровки. Перша, отримана на секретному ключі клієнта , Містить сеансовий ключ для роботи з сервером видачі дозволів, ідентифікатор останнього і термін життя дозволу клієнта на роботу з сервером TGS. Друга шифровка, отримана на ключі , - це дозвіл (Ticket-granting ticket) клієнту на взаємодію з сервером TGS. До складу другої шифровки, яку клієнт прочитати не може, тому що не знає ключа , Входять ідентифікатори і , Сеансовий ключ і термін життя цього дозволу .
3. Отримавши повідомлення, клієнт розшифровує першу його половину на ключі , Перевіряє позначку , Дізнається сеансовий ключ і термін життя дозволу на роботу з сервером TGS. Таким чином, в результаті обміну повідомленнями з сервером AS клієнт отримує дозвіл на роботу з сервером TGS. Потім клієнт надсилає запит серверу видачі дозволів. Повідомлення для сервера TGS включає в себе дві шифровки. Перша, отримана на сеансовому ключі , Включає в себе ідентифікатори і , Ідентифікатор запиту і тимчасову мітку . Друга - це "запечатаний" ключем Дозвіл .
4. Сервер видачі дозволів розшифровує дозвіл , Дізнається сеансовий ключ , За допомогою якого читає першу частину прийшов повідомлення і перевіряє ідентифікатор і тимчасову мітку . Упевнившись в автентичності клієнта, сервер TGS виробляє сеансовий ключ для взаємодії клієнта С і сервера S. На знанні цього ключа і буде грунтуватися в майбутньому взаємна аутентифікація C і S. Після цього сервер відправляє повідомлення клієнту, що містить зашифровані на ключі сеансовий ключ і термін життя дозволу клієнта на роботу з сервером, а також саме це дозвіл , Зашифроване на секретному ключі .
5. Клієнт, отримавши повідомлення, розшифровує першу його частину, з якої витягує сеансовий ключ для роботи з сервером S і термін життя дозволу на взаємодію з сервером S. Саме "запечатаний" ключем Дозвіл клієнт прочитати не може. Таким чином, в результаті обміну з сервером видачі дозволів клієнт отримує дозвіл на подальшу взаємодію вже з прикладним сервером. Нарешті, клієнт посилає серверу S повідомлення, що містить зашифровані на сеансовому ключі свій ідентифікатор , ідентифікатор і тимчасову мітку , А також дозвіл , Отримане від сервера TGS.
6. Прийнявши повідомлення від клієнта і "роздрукувавши" дозвіл , Цільової сервер дізнається сеансовий ключ і з його допомогою проводить аутентифікацію клієнта, перевіряючи ідентифікатор і тимчасову мітку . Відповідь сервера клієнту надсилається в тому випадку, коли потрібно взаємна аутентифікація. Відповідь прикладного сервера в цьому випадку містить зашифрований на ключі результат перетворення мітки .

Сервер Kerberos має доступ до бази даних, що містить ідентифікатори і секретні ключі суб'єктів. Запис кожного користувача і кожного прикладного сервера в базі даних Kerberos містить наступні компоненти:

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

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

Крім серверів AS і TGS в системі є об'єкт, який відповідає за управління базою даних, званий диспетчером бази даних Kerberos DBM (Database Manager), а також сервер поширення ключів Kerberos KDS (Key Distribution Server).

3.9.5. Несиметричні методи аутентифікації суб'єкта

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

НОУ ІНТУЇТ | лекція | Методи захисту інформації в комп'ютерних системах і мережах

3.9. Методи аутентифікації інформації

3.9.1. Ідентифікація, аутентифікація і авторизація

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

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

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

Процес розпізнавання законного користувача в схематичному вигляді представлений на Рис. 3.29 .

Процедури аутентифікації повинні бути стійкі до фальсифікації, підбору і підробці.

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

Існують різні механізми реалізації розмежування доступу. Наприклад, кожному ресурсу (або компоненту) системи може бути зіставлений список управління доступом ACL (Access Control List), в якому вказані ідентифікатори всіх користувачів, яким дозволений доступ до цього ресурсу, а також визначено, який саме доступ дозволений. При зверненні користувача до конкретного ресурсу система перевіряє наявність у даного ресурсу списку управління доступом і, якщо він існує, з'ясовує, чи дозволено цього користувачеві працювати з даними ресурсом в запрошенном режимі. Іншим прикладом реалізації механізму авторизації користувача є профіль користувача - список, що ставить у відповідність усім код користувача перелік об'єктів, до яких дозволений доступ цьому користувачеві із зазначенням типу доступу. Може бути організована системна структура даних, так звана матриця доступу, яка представляє собою таблицю, стовпці якої відповідають ідентифікаторів всіх системних ресурсів, а рядки - ідентифікаторів всіх зареєстрованих користувачів. На перетині i-го стовпця і j-го рядка таблиці адміністратор системи вказує дозволений тип доступу власника i-го ідентифікатора до j-му ресурсу.

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

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

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

3.9.2. аутентифікація суб'єкта

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

Класичним засобом аутентифікації суб'єкта є парольні схеми. При цьому для усунення наслідків несанкціонованого доступу противника до інформації, що зберігається в пам'яті комп'ютера верифікатори, зберігається не сам пароль PW (password), а його хеш-образ q = h (PW).

Для усунення наслідків перехоплення інформації, переданої претендентом, або несанкціонованого доступу противника до інформації, що зберігається в пам'яті комп'ютера верифікатори, може бути рекомендована схема, показана на Рис. 3.30 .

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

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

Перевірка справжності передбачає використання:

• неповторяющихся блоків даних, в якості яких виступають тимчасові мітки;
• механізму "запит-відповідь";
• процедури рукостискання (handshake).

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

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

3.9.3. Симетричні методи аутентифікації суб'єкта

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

на Рис. 3.32 показана схема процедури взаємної аутентифікації суб'єктів А і В з використанням довіреної третьої сторони - суб'єкта С, що володіє секретними ключами і відповідно для взаємодії з А і В.

Протокол Нідхема-Шредера:

1. суб'єкт А, який хоче взаємодіяти з суб'єктом В, посилає З повідомлення, що містить ідентифікатори суб'єктів запитуваної взаємодії

   ;

2. суб'єкт С, отримавши повідомлення, формує сеансовий ключ KAB для взаємодії суб'єктів А і В і посилає А зашифроване повідомлення

   ,

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

3. суб'єкт А, розшифрувавши отримане повідомлення, визначає ключ і дозвіл

   ,

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

   ,

   що містить зашифрований запит і дозвіл, отримане від С;

4. суб'єкт В, прочитавши шифровку

   ,

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

   ;

5. суб'єкт А, отримавши повідомлення, розшифровує його і перевіряє відповідь В; в разі позитивного результату перевірки, процес аутентифікації успішно завершується.

3.9.4. схема Kerberos

Рішення завдання аутентифікації в сучасних інформаційних системах, що представляють собою сукупність реалізованих на різних апаратно-програмних платформах, територіально рознесених компонентів, відповідно до технології клієнт / сервер полягає в використанні спеціального сервера аутентифікації. В даний час на роль фактичного стандарту сервера аутентифікації претендує Kerberos, продукт розроблений в Массачусетському технологічному інституті (MIT) в середині 1980-х рр. і хто витерпить з тих пір ряд принципових змін. Широкому поширенню Kerberos сприяло те, що його версія, реалізована в MIT, є вільно поширюваним продуктом. Програмні засоби, що виконують аутентифікацію за схемою Kerberos, розроблені для всіх популярних ОС. Підтримка служби Kerberos передбачена в деяких сучасних мережевих ОС. Схема Kerberos є типовим прикладом реалізації симетричних методів аутентифікації, вона приведена на Рис. 3.33 .

Схема передбачає взаємодію між трьома програмними компонентами - клієнтом С, сервером Kerberos і прикладним сервером S. ПО сервера Kerberos розділене за своїми функціями на дві частини: сервер аутентифікації AS (Authentication Server) і сервер видачі дозволів (квитків) TGS (Ticket Granting Server). Клієнт С - це комп'ютер, на якому встановлено клієнтське ПЗ, здатне брати участь у взаємодії по протоколу Kerberos, і зареєстрований будь-якої користувач. У деяких випадках прикладної сервер може бути клієнтом деякого іншого сервера, наприклад сервер друку може користуватися послугами файлового сервера. Сервер S - суб'єкт, що надає ресурси мережевим клієнтам.

Клієнт С, який хоче звернутися до прикладного сервера для отримання його послуг, повинен отримати дозвіл від AS. Дозвіл - це зашифрована інформація, яку клієнт передає серверу S або сервера TGS. Дозвіл дозволяє серверу переконатися в достовірності клієнта. Всі дозволи, крім першого, клієнт отримує від сервера TGS. Перший дозвіл, дозвіл на доступ до самого TGS, клієнт отримує від сервера AS. Дозвіл - це шифровка, отримана на секретному ключі, відомому тільки серверу S і сервера Kerberos, тому перший, отримавши дозвіл, може бути впевнений, що воно надійшло саме від сервера Kerberos. Дозволи є багаторазовими, які мали певний термін життя (декілька годин). Коли цей термін закінчується, клієнт повинен знову пройти процедуру аутентифікації. При встановленні кожного з'єднання використовується тимчасова мітка, тому в мережі повинна діяти служба єдиного часу. Необхідність в сервері TGS пояснюється прагненням скоротити число повідомлень, зашифрованих з використанням секретного ключа клієнта, якому потрібні послуги декількох серверів. Саме тому сервер Kerberos "роздвоюється" на сервер AS, з яким клієнт взаємодіє за допомогою секретного ключа , І сервер TGS, з яким клієнт здійснює подальшу взаємодію за допомогою тільки сеансових ключів . Компрометація сеансового ключа, що має дуже короткий час життя, річ значно менш небезпечна, ніж розкриття секретного ключа.

Процес аутентифікації складається з п'яти (одностороння аутентифікація) або шести (взаємна аутентифікація) кроків.

1. Клієнт З посилає серверу аутентифікації повідомлення, що містить ідентифікатори клієнта і необхідного сервера видачі дозволів , Що відповідає за надання відповідної послуги, а також інформацію , Призначену для ідентифікації конкретного запиту: час, свій мережеву адресу і т.п.
2. Сервер аутентифікації здійснює пошук в базі даних Kerberos за ідентифікатором клієнта і ідентифікатором послуги, знаходить відповідні ключі і , Формує сеансовий ключ для взаємодії клієнта і сервера видачі дозволів. Після цього сервер AS посилає відповідь клієнту. Ця відповідь містить дві шифровки. Перша, отримана на секретному ключі клієнта , Містить сеансовий ключ для роботи з сервером видачі дозволів, ідентифікатор останнього і термін життя дозволу клієнта на роботу з сервером TGS. Друга шифровка, отримана на ключі , - це дозвіл (Ticket-granting ticket) клієнту на взаємодію з сервером TGS. До складу другої шифровки, яку клієнт прочитати не може, тому що не знає ключа , Входять ідентифікатори і , Сеансовий ключ і термін життя цього дозволу .
3. Отримавши повідомлення, клієнт розшифровує першу його половину на ключі , Перевіряє позначку , Дізнається сеансовий ключ і термін життя дозволу на роботу з сервером TGS. Таким чином, в результаті обміну повідомленнями з сервером AS клієнт отримує дозвіл на роботу з сервером TGS. Потім клієнт надсилає запит серверу видачі дозволів. Повідомлення для сервера TGS включає в себе дві шифровки. Перша, отримана на сеансовому ключі , Включає в себе ідентифікатори і , Ідентифікатор запиту і тимчасову мітку . Друга - це "запечатаний" ключем Дозвіл .
4. Сервер видачі дозволів розшифровує дозвіл , Дізнається сеансовий ключ , За допомогою якого читає першу частину прийшов повідомлення і перевіряє ідентифікатор і тимчасову мітку . Упевнившись в автентичності клієнта, сервер TGS виробляє сеансовий ключ для взаємодії клієнта С і сервера S. На знанні цього ключа і буде грунтуватися в майбутньому взаємна аутентифікація C і S. Після цього сервер відправляє повідомлення клієнту, що містить зашифровані на ключі сеансовий ключ і термін життя дозволу клієнта на роботу з сервером, а також саме це дозвіл , Зашифроване на секретному ключі .
5. Клієнт, отримавши повідомлення, розшифровує першу його частину, з якої витягує сеансовий ключ для роботи з сервером S і термін життя дозволу на взаємодію з сервером S. Саме "запечатаний" ключем Дозвіл клієнт прочитати не може. Таким чином, в результаті обміну з сервером видачі дозволів клієнт отримує дозвіл на подальшу взаємодію вже з прикладним сервером. Нарешті, клієнт посилає серверу S повідомлення, що містить зашифровані на сеансовому ключі свій ідентифікатор , ідентифікатор і тимчасову мітку , А також дозвіл , Отримане від сервера TGS.
6. Прийнявши повідомлення від клієнта і "роздрукувавши" дозвіл , Цільової сервер дізнається сеансовий ключ і з його допомогою проводить аутентифікацію клієнта, перевіряючи ідентифікатор і тимчасову мітку . Відповідь сервера клієнту надсилається в тому випадку, коли потрібно взаємна аутентифікація. Відповідь прикладного сервера в цьому випадку містить зашифрований на ключі результат перетворення мітки .

Сервер Kerberos має доступ до бази даних, що містить ідентифікатори і секретні ключі суб'єктів. Запис кожного користувача і кожного прикладного сервера в базі даних Kerberos містить наступні компоненти:

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

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

Крім серверів AS і TGS в системі є об'єкт, який відповідає за управління базою даних, званий диспетчером бази даних Kerberos DBM (Database Manager), а також сервер поширення ключів Kerberos KDS (Key Distribution Server).

3.9.5. Несиметричні методи аутентифікації суб'єкта

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

Протокол Діффі-Хеллмана. Несіметрічні методи аутентіфікації могут буті засновані на вікорістанні механізму електронного підпісу. Класичним прикладом несиметричною аутентифікації може служити схема Діффі-Хеллмана, що представляє собою сукупність процедури вироблення загального секретного ключа і взаємної аутентифікації суб'єктів взаємодії. Припустимо, w - примітивний елемент поля Галуа GF (p), де p - просте число. Абонент А володіє парою ключів: - відкритим і - закритим. Абонент В володіє парою ключів: - відкритим і - закритим. Тоді послідовність взаємної аутентифікації складається з трьох кроків.

Схема аутентифікації Діффі-Хеллмана.

1. Абонент А виробляє випадкове число і надсилає абоненту В повідомлення

   (Тут і далі передбачається, що всі операції виконуються за модулем p).

2. Абонент В виробляє випадкове число , обчислює , На своєму секретному ключі створює підпис

   ПОВІДОМЛЕННЯ

   Потім В обчислює сеансовий ключ

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

   , ,

   де

3. Абонент А обчислює сеансовий ключ

   за допомогою свого секретного ключа створює підпис

   ПОВІДОМЛЕННЯ

   зашифровує її на ключі і відправляє В повідомлення

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

   він може бути впевнений в достовірності абонента В.

5. Якщо перевірка підпису А абонентом В завершилася успішно, тобто У переконався в справедливості рівності він в свою чергу може бути впевнений в достовірності абонента А.

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

Для реалізації схеми необхідний центр довіри, який вибирає і публікує ціле число виду N = pq, де p і q - прості числа, які тримаються в секреті. Припустимо, абонент А є доводить, абонент В - перевіряючим. Абонент А (або центр довіри) формує відкритий і секретний ключі:

і оголошує їх відкритим ключем .

Протокол аутентифікації Е. Фіата і А. Шаміра складається в t-кратному повторенні таких кроків.

Схема Фіата-Шаміра.

1. Абонент А вибирає випадкове число , обчислює

   і посилає його В.

2. Абонент В вибирає випадкову двійкову послідовність

   {0, 1}, j = 1, ..., m

   і посилає її А.

3. Абонент А обчислює

   і посилає його В.

4. Абонент В перевіряє рівність

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

3.9.6. аутентифікація об'єкта

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

Процедури аутентифікації повинні бути стійкі до фальсифікації, підбору і підробці.

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

Існують різні механізми реалізації розмежування доступу. Наприклад, кожному ресурсу (або компоненту) системи може бути зіставлений список управління доступом ACL (Access Control List), в якому вказані ідентифікатори всіх користувачів, яким дозволений доступ до цього ресурсу, а також визначено, який саме доступ дозволений. При зверненні користувача до конкретного ресурсу система перевіряє наявність у даного ресурсу списку управління доступом і, якщо він існує, з'ясовує, чи дозволено цього користувачеві працювати з даними ресурсом в запрошенном режимі. Іншим прикладом реалізації механізму авторизації користувача є профіль користувача - список, що ставить у відповідність усім код користувача перелік об'єктів, до яких дозволений доступ цьому користувачеві із зазначенням типу доступу. Може бути організована системна структура даних, так звана матриця доступу, яка представляє собою таблицю, стовпці якої відповідають ідентифікаторів всіх системних ресурсів, а рядки - ідентифікаторів всіх зареєстрованих користувачів. На перетині i-го стовпця і j-го рядка таблиці адміністратор системи вказує дозволений тип доступу власника i-го ідентифікатора до j-му ресурсу.

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

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

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