Система автентифікації в інформаційній системі на базі протоколу Kerberos

 

4. Робота протоколу
1. Автентифікатори

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

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

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

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

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

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

3. Сергій шифрує час з повідомлення Олени з допомогою їх загального

ключа і включає його у власне повідомлення, яке спрямовує Олені.

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

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

 

Рисунок 2.1 - Взаємна автентифікація (Олена-Сергій)

 

1. Управління ключами

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

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

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

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

Рисунок 2.2 - Управління ключами (в теорії)

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

 

1. Сеансові білети

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

Рисунок 2.3 - Управління ключами (на практиці)

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

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

Рисунок 2.4 - Взаємна автентифікація (клієнт-сервер)

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

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

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

 

1. Білети на видачу білетів

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

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

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

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

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