Протокол Kerberos

Размещено на http://www.Allbest.ru/

Міністерство освіти і науки України

Національний університет «Львівська політехніка»

Кафедра «Електронних обчислювальних машин»

Реферат

з дисципліни

Проектування засобів захисту інформації в комп'ютерних системах та мережах

на тему:

Протокол Kerberos

Виконала: Хоміць В.М.

студентка групи КІКС-11

Перевірив: Морозов Ю.В.

Львів - 2017

Вступ

Протокол Kerberos був створений більше десяти років тому в Массачусетському технологічному інституті в рамках проекту Athena. Однак загальнодоступним цей протокол став, починаючи з версії 4. Після того, як фахівці вивчили новий протокол, автори розробили і запропонували чергову версію - Kerberos 5, яка була прийнята в якості стандарту IETF. Вимоги реалізації протоколу викладені в документі RFC 1510, крім того, в специфікації RFC 1964 описується механізм і формат передачі жетонів безпеки в повідомленнях Kerberos.

Kerberos 5 є розвитком четвертої версії, включає всю попередню функціональність і містить безліч розширень. Однак з точки зору реалізації Kerberos 5 є абсолютно новим протоколом.

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

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

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

Щоб ускладнити проведення даної атаки, в Kerberos 5 було введено попереднє встановлення автентичності. На даному етапі KDC вимагає, щоб користувач засвідчив свою особистість перш, ніж йому буде виданий мандат.

За попередню аутентифікацію відповідає політика KDC, якщо вона потрібна, то користувач при першому запиті до СА отримає повідомлення KRB_ERROR. Це повідомлення скаже клієнтові, що необхідно відправляти AS_REQ запит зі своїми даними для встановлення автентичності. Якщо KDC не впізнав їх, то користувач отримає ще одне повідомлення KRB_ERROR, що повідомляє про помилку, і TGT не буде виданий.

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

Використання і поширення

Поширення реалізації Kerberos відбувається в рамках авторського права аналогічного прав для BSD.

В даний час безліч ОС підтримують даний протокол, в число яких входять:

* Windows 2000 і більш пізні версії, які використовують Kerberos як метод аутентифікації в домені між учасниками. Деякі доповнення до цього протоколу відображені в RFC 3244 «Microsoft Windows 2000, Kerberos Change Password and Set Password Protocols». Документ RFC 4757 описує використання RC4 Kerberos в Windows;

* різні UNIX і UNIX подібні ОС (Apple Mac OS X, Red Hat Enterprise Linux 4, FreeBSD, Solaris, AIX, OpenVMS). При цьому існує дві найбільш використовувані реалізації з відкритим вихідним кодом - MIT Kerberos і Heimdal, остання з яких була спочатку створена в Швеції через обмеження на експорт криптографічного ПО з США (англ.).

Основні концепції

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

Сама назва протоколу Kerberos говорить про те, як тут вирішена проблема управління ключами. Кербер (або Цербер) - персонаж класичної грецької міфології. Цей лютий пес про трьох головах, за повір'ями греків, охороняє врата підземного царства мертвих. Трьом головам Кербера в протоколі Kerberos відповідають три учасники безпечної зв'язку: клієнт, сервер і довірений посередник між ними. Роль посередника тут грає так званий центр розподілу ключів Key Distribution Center, KDC.

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

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

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

Сеансові мандати

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

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

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

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

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

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

Мандати на видачу мандатів

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

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

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

На запит користувача KDC відповідає спеціальним сеансовим мандатом для самого себе, так званий мандат на видачу мандатів (ticket-granting ticket), або мандат TGT. Як і звичайний сеансовий мандат, мандат TGT містить копію сеансового ключа для зв'язку служби (в даному випадку - центру KDC) з клієнтом. У повідомлення з мандатом TGT також включається копія сеансового ключа, за допомогою якої клієнт може зв'язатися з KDC. Мандат TGT шифрується за допомогою довгострокового ключа служби KDC, а клієнтська копія сеансового ключа - за допомогою довгострокового ключа користувача.

Отримавши відповідь служби KDC на свій первісний запит, клієнт дешифрує свою копію сеансового ключа, використовуючи для цього копію довготривалого ключа користувача зі свого кеш-пам'яті. Після цього довготривалий ключ, отриманий з призначеного для користувача пароля, можна видалити з пам'яті, оскільки він більше не знадобиться: вся подальша зв'язок з KDC шифруватиметься за допомогою отриманого сеансового ключа. Як і всі інші сеансові ключі, він має тимчасовий характер і дійсний до закінчення терміну дії мандата TGT, або до виходу користувача з системи. З цієї причини такої ключ називають сеансовим ключем реєстрації (logon session key).

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

Схема роботи Kerberos 5

Схема роботи Kerberos 5 в даний час відбувається наступним чином:

Вхід користувача в систему:

1. Користувач вводить ім'я і пароль на клієнтській машині.

2. Клієнтська машина виконує над паролем односторонню функцію (зазвичай хеш), і результат стає секретним ключем клієнта / користувача.

Аутентифікація клієнта:

1. Клієнт відсилає запит (AS_REQ) на СА для отримання аутентифікаційних вірчих даних і подальшого їх надання TGS сервера (згодом він буде їх використовувати для отримання мандатів без додаткових запитів на застосування секретного ключа користувача.) Даний запит містить:

* Ідентифікатор клієнта, його мітка часу і ідентифікатор сервера.

2. Якщо політика KDC вимагає попередньої аутентифікації, то користувач отримує повідомлення KRB_ERROR, у відповідь на яке посилає повторний запит, але вже c даними для встановлення автентичності.

3. СА перевіряє, чи є такий клієнт в базі. Якщо є, то назад СА відправляє повідомлення (AS_REP), що включає:

* Сесійна ключ Клієнт / TGS, ідентифікатор TGS та час життя мандата, зашифровані секретним ключем клієнта.

* TGT (який включає ідентифікатор і мережеву адресу клієнта, мітку часу KDC, період дії мандата і сесійний ключ Клієнт / TGS), зашифрований секретним ключем TGS.

Якщо ж ні, то клієнт отримує нове повідомлення, яке говорить про виникнення помилки.

Отримавши повідомлення, клієнт розшифровує свою частину для отримання сесійної Ключа Клієнт / TGS. Цей сесійний ключ використовується для подальшого обміну з сервером TGS. (Важливо: Клієнт не може розшифрувати TGT, так як воно зашифровано секретним ключем TGS) У цей момент у користувача достатньо даних, щоб авторизуватися на TGS.

Авторизація клієнта на TGS:

1. Для запиту сервісу клієнт формує запит на TGS (TGS_REQ) містить наступні дані:

* TGT, отриманий раніше і ідентифікатор сервісу.

* Аутентифікатор (складений з ID клієнта і тимчасового штампа), зашифрований на Сесійній Ключі Клієнт/TGS.

2. Після отримання TGS_REQ, TGS витягує з нього TGT і розшифровує його використовуючи секретний ключ TGS. Це дає йому Сесійна Ключ Клієнт/TGS. Їм він розшифровує аутентифікатор. Потім він генерує сесійний ключ клієнт/сервіс і посилає відповідь (TGS_REP) включає:

* мандат сервісу (який містить ID клієнта, мережеву адресу клієнта, мітку часу KDC, час дії мандата і Сесійна Ключ клієнт/сервіс) зашифрований секретним ключем сервісу.

* Сесійна ключ клієнт/сервіс, ідентифікатор сервісу і час життя мандата, зашифровані на Сесійній Ключі Client/TGS.

Запит сервісу клієнтом:

1. Після отримання TGS_REP, у клієнта достатньо інформації для авторизації на сервісі. Клієнт з'єднується з ним і посилає повідомлення містить:

* Зашифрований мандат сервісу отриманий раніше.

* Новий аутентифікатор, зашифрований на сесійному ключі клієнт/ сервіс, і включає ID клієнта і мітку часу.

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

* мітку часу, зазначену клієнтом + 1, зашифровану на сесійному ключі клієнт/сервіс.

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

4. Сервер надає клієнту необхідний сервіс

Недоліки та обмеження

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

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

Протокол адміністрування не стандартизований і залежить від конкретної реалізації сервера. Зміна пароля описана в RFC 3244.

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

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

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

Список використаної літератури

1. Шнайер Б. Глава 3. Основні протоколи. Протокол Kerberos // Прикладна криптографія. Протоколи, алгоритми, вихідні тексти на мові Сі = Applied Cryptography. Protocols, Algorithms and Source Code in C. - М.: Тріумф, 2002. - С. 81. - 816 с. - 3000 екз.

2. Шнайер Б. Глава 24. Приклади практичних реалізацій. Протокол KERBEROS // Прикладна криптографія. Протоколи, алгоритми, вихідні тексти на мові Сі = Applied Cryptography. Protocols, Algorithms and Source Code in C. - М.: Тріумф, 2002. - С. 627-633. - 816 с. - 3000 екз.

3. Jason Garman. 1-3 // Kerberos: The Definitive Guide. - 2003.

4. Шнайер Б. глава 24.5 Kerberos Брюс Шнайер // Прикладна криптографія. Протоколи, алгоритми, вихідні тексти на мові Сі = Applied Cryptography. Protocols, Algorithms and Source Code in C. - М.: Тріумф, 2002. - 816 с. - 3000 екз.

5. B. Clifford Neuman and Theodore T'so, Kerberos: An Authentication Service for Computer Networks, IEEE Communications, 32(9) pp. 33-38. September 1994.

6. John T. Kohl, B. Clifford Neuman, and Theodore Y. T'so, The Evolution of the Kerberos Authentication System. Distributed Open Systems, pp78-94. IEEE Computer Society Press, 1994.

Размещено на Allbest.ru