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

 

Національна академія управління

Кафедра інтелектуальних систем

Факультет економіки та інформаційних технологій

Напрям підготовки 0804 - Компютерні науки

Спеціальність 7.080404 - Інтелектуальні системи прийняття рішень

ДИПЛОМНА робота

Тема:

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

Київ - 2013

ЗАВДАННЯ

На дипломний проект (роботу) студенту Іванову Петру Васильовичу

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

. Термін здачі студентом закінченого проекту - 5 червня 2013 р.

. Вихідні дані до проекту (роботи): Алгоритми криптографічних систем

. Зміст розрахунково-пояснювальної записки (перелік питань, що мають бути висвітлені):

. Криптографія

. Автентифікація по протоколу Kerberos

. Реалізація програмного продукту

. Перелік графічного (презентативного, ілюстраційного) матеріалу

В проекті представлено 13 слайдів

6. Консультант (із зазначенням відповідних частин проекту): Ніколайчук В.Й.

7. Дата видачі завдання 05 листопада 2012р.

КАЛЕНДАРНИЙ ПЛАН

№ п/пНазва етапу дипломного проекту (роботи)Термін виконання етапуПримітка1Отримання завдання на дипломний проект05.11.122Огляд літератури за темою роботи21.11.113Вивчення протоколу Kerberos29.11.114Огляд існуючих алгоритмів05.12.115Вибір алгоритму09.12.116Детальне вивчення вибраного алгоритму20.01.127Розробка программного продукту15.02.128Оформлення дипломного проекту01.04.129Підготовка до захисту дипломного проекту10.05.1210Захист дипломного проекту20.06.13

РЕФЕРАТ

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

this paper we developed a system based on authentication protocol Kerberos. For many years, cryptography has served only military targets. Today, ordinary users can turn to tools that allow them to protect themselves against unauthorized access to confidential information using the methods of computer cryptography.

РЕФЕРАТ

В данной работе разработана система аутентификации на базе протокола Kerberos. В течение многих лет криптография служила исключительно военным целям. Сегодня обычные пользователи получают возможность обращаться к средствам, позволяющим им обезопасить себя от несанкционированного доступа к конфиденциальной информации, применяя методы компьютерной криптографии.

ЗМІСТ

ПЕРЕЛІК ПРИЙНЯТИХ СКОРОЧЕНЬ

ВСТУП

ПОСТАНОВКА ЗАДАЧІ ТА ОГЛЯД ІСНУЮЧИХ МЕТОДІВ РОЗВЯЗКУ ЦІЄЇ ЗАДАЧІ

РОЗДІЛ 1. КРИПТОГРАФІЯ

.1 Криптографічні системи

.2 Симетричні криптографічні системи

.2.1 Алгоритм AES

.2.2 Алгоритм ГОСТ 28147-89

.2.3 Алгоритм 3DES

.2.4 Алгоритм RC6

.2.5 Алгоритм IDEA

.2.6 Алгоритм SEED

.2.7 Алгоритм Camellia

.2.8 Алгоритм XTEA

.3 Асиметричні криптографічні системи

.3.1 Алгоритм RSA

.3.2 Алгоритм DSA

.3.3 Алгоритм Elgamal

.3.4 Алгоритм Rabin

.3.5 Алгоритм McEliece

.4 Висновок до розділу 1

РОЗДІЛ 2. АВТЕНТИФІКАЦІЯ ПО ПРОТОКОЛУ KERBEROS

.1 Стандарти автентифікації по протоколу Kerberos

.2 Основна концепція

.3 Переваги автентифікації по протоколу Kerberos

.4 Робота протоколу

.4.1 Автентифікатори

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

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

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

.4.5 Автентифікація за межами домену

.5 Підпротоколи

.5.1 Підпротокол AS Exchange

.5.2 Підпротокол TGS Exchange

.5.3 Підпротокол CS Exchange

.6 Білети

.6.1 Дані з білета відомі клієнту

.6.2 Що відбувається після закінчення терміну дії білета

.6.3 Оновлюванні білети TGT

.6.4 Делегування автентифікації

.6.5 Представницькі білети

.6.6 Передані білети

.6.7 Центр розподілу ключів KDC

.6.8 База даних облікових записів

.7 Політика Kerberos

.8 Процес реєстрації

.8.1 Вхід в систему за паролем

.8.2 Вхід в систему за допомогою смарт-карти

.8.3 Віддалена реєстрація

.9 Безпека

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

Висновок до розділу 2

РОЗДІЛ 3. РЕАЛІЗАЦІЯ ПРОГРАМНОГО ПРОДУКТУ

.1 Алгоритм DES і його модифікації

.2 Програмний продукт

.3 Висновок до розділу 3

ВИСНОВОК

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

ДОДАТОК А. ІЛЮСТРАТИВНІ МАТЕРІАЛИ ДЛЯ ДОПОВІДІ

ДОДАТОК Б. КОД ПРОГРАМИ

ПЕРЕЛІК ПРИЙНЯТИХ СКОРОЧЕНЬ

AES - Advanced Encryption Standard;- Authentication Server;- Data Encryption Standard;- Digital Signature Algorithm;- International Data Encryption Algorithm;- Internet Engineering Task Force;- Key Distribution Center;- NT LAN Manager;- Rivest, Shamir и Adleman;- Secure Sockets Layer;- security support provider;- Tiny Encryption Algorithm;- Ticket Granting Server;- Ticket Granting Ticket;- Transport Layer Security;- eXtended TEA;

ЕЦП - Електронний цифровий підпис;

DES - Triple DES.

ВСТУП

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

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

Спочатку криптографія займалася виключно забезпеченням конфіденційності повідомлень (тобто шифруванням) - перетворенням повідомлень <#"justify">ПОСТАНОВКА ЗАДАЧІ ТА ОГЛЯД ІСНУЮЧИХ МЕТОДІВ РОЗВЯЗКУ ЦІЄЇ ЗАДАЧІ

1.Виконати аналіз протоколу Kerberos

2.Зробити огляд існуючих алгоритмів криптографічних систем

.Розробити програмний продукт на базі протоколу Kerberos

РОЗДІЛ 1. КРИПТОГРАФІЯ

1.1Криптографічні системи

З поширенням писемності в людському суспільстві зявилась потреба в обміні листами та повідомленнями, що викликало необхідність приховування вмісту письмових повідомлень від сторонніх.

Наука яка вивчає математичні методи захисту інформації шляхом її перетворення, називається криптологія. Криптологія має два направлення - криптографію та криптоаналіз [1].

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

Методи приховування вмісту письмових повідомлень можна розділити на три групи. До першої групи належать методи маскування або Стеганографії, які здійснюють приховування факту наявності повідомлення, другу групу складають різні методи тайнопису або криптографії (від грецьких слів ktyptos - таємний і grapho - пишу); методи третьої групи орієнтовані на створення спеціальних технічних пристроїв, засекречування інформації. Історія криптографії - ровесниця історії людської мови. Більш того, спочатку писемність сама по собі була своєрідною криптографічною системою, так як у стародавніх суспільствах нею володіли тільки обрані.

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

Комп'ютерна криптографія (з 1970-х рр..) забов'язана своєю появою обчислювальним засобам з продуктивністю, достатньою для реалізації криптосистем, що забезпечують при великій швидкості шифрування на кілька порядків вищу крипостійкість, ніж "ручні" та "механічні" шифри. Першим класом криптосистем, практичне застосування яких стало можливо з появою потужних і компактних обчислювальних коштів, стали блокові шифри. У 70-і рр. був розроблений американський стандарт шифрування DES (прийнятий у 1978 р.). Фейстель (співробітник IBM), описав модель блокових шифрів, на основі якої були побудовані інші, більш стійкі симетричні криптосистеми, в тому числі вітчизняний стандарт шифрування ГОСТ 28147-89.

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

У середині 70-х рр. ХХ століття стався справжній прорив у сучасній криптографії - поява асиметричних криптосистем, які не вимагали передачі особистого ключа між сторонами. Тут відправною точкою прийнято вважати роботу, опубліковану Уитфилда Діффі і Мартіном Хеллманом в 1976 р. під назвою "Нові напрямки в сучасній криптографії". У ній вперше сформульовані принципи обміну шифрованого інформацією без обміну секретним ключем. Незалежно до ідеї асиметричних криптосистем підійшов Ральф Меркле. Кількома роками пізніше Рон Ривест, Аді Шамір і Леонард Адлеман відкрили систему RSA, першу практичну асиметричну криптосистему, стійкість якої була заснована на проблемі факторизації великих простих чисел. Асиметрична криптографія відкрила відразу декілька нових прикладних напрямків, зокрема системи електронного цифрового підпису (ЕЦП) та електронних грошей.

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

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

Існує два види криптографічних систем:

Симетричні та асиметричні криптографічні системи

1.2Симетричні криптографічні системи

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

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

Рисунок 1.1 - Схема симетричної криптосистеми шифрування

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

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

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

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

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

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

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

1.2.1Алгоритм AES

Стандарт AES (Advanced Encryption Standard) є стандартом шифрування США, прийнятим у 2000-му році. Він специфікує алгоритм Rijndael. Цей алгоритм є симетричний блоковий шифр, який працює з блоками даних довжиною 128 біт і використовує ключі довжиною 128, 192 і 256 біт (версії AES-28; AES-192 і AES-256). Сам алгоритм може працювати і з іншими довжинами блоків даних і ключів, але ця можливість в стандарт не увійшла. При використанні 128-бітного ключа для злому шифрування за заявою уряду США буде потрібно 149 трильйонів років.

Біти даних нумеруються з нуля, починаючи зі старших. У AES основним є поліноміальне подання кодів. Так байт слід представляти як:

Алгоритм AES здійснює операції над двовимірними масивами байт, званими структурами (state). Структура складається з 4 рядів по байт. дорівнює довжині блоку, поділеній на 32 (у даному стандарті ). Це дозволяє позначати структуру як , або , де і .

Вхідний код (in), який є послідовністю 16 байт можна представити як:

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

Обчислення виразу М. байтів на виконується згідно з наступним алгоритмом:

У цьому випадку зворотна величина байта дорівнює:

для множення полу байта (коди довжиною 4 біта) використовується неприводимий поліном:

Обчислення виразу М. полу байта на виконується таким чином:

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

Довжини ключів (довжина, виміряна в 32 бітових словах) можуть приймати значення 4, 6 або 8 (для AES-128, -192 і -256, відповідно). Число ітерацій (round), що реалізуються в алгоритмі AES, складає відповідно 10, 12 і 14.

1.2.2Алгоритм ГОСТ 28147-89

ГОСТ 28147-89 - радянський і російський стандарт симетричного шифрування, введений в 1990 році, також є стандартом СНД. Повна назва - «ГОСТ 28147-89 Системи обробки інформації. Захист криптографічний. Алгоритм криптографічного перетворення ». Блоковий шифроалгоритм. При використанні методу шифрування з гаммированием, може виконувати функції потокового шифроалгоритму.

1.2.3Алгоритм 3DES

3DES (Triple DES, TDES) - потрійний DES. Вдосконалений блочний алгоритм DES. Симетричний блоковий криптографічний алгоритм, створений на основі алгоритму DES з метою усунення головного недоліку - малої довжини ключа (56 біт), який може бути зламаний методом перебору ключа. Принцип роботи 3DES не відрізняється від застосовуваного в DES; нарощування криптостійкості було досягнуто завдяки трикратному (triple) шифруванню одного блоку алгоритмом DES. Три 56-розрядних ключа, що використовуються в даному процесі, об'єднуються алгоритмом в один 168-розрядний ключ. Хоча час атаки перебором при звичайних ресурсах комп'ютера становить кілька мільярдів машиноліт, що говорить про хорошу стійкості алгоритму. Таким чином, довжина ключа алгоритму 3DES дорівнює 156 бітам (3-x ключів DES). Сьогодні також існують варіанти Triple DES з «подвійним» DES ключем розміром 112 біт, «потрійним» DES-ключем, які стали застосовуватися частіше (3DES, TDES, TDEA, 2TDEA, 3TDEA і т.д.).

1.2.4Алгоритм RC6

Алгоритм RC6 був розроблений в 1998 р. поруч фахівців наукового підрозділу відомої фірми RSA Data Security - RSA Laboratories: Рональдом Рівестом (Ronald Rivest, засновник RSA Data Security), Меттом Робшоу , Реєм Сідні і Іква Лайзою Ін спеціально для участі в конкурсі AES. Алгоритм багато в чому успадкував риси попереднього алгоритму Рональда Ривеста - 64-бітного блокового шифру RC5, розробленого в 1997 р. Фактично, алгоритм зазнав дві принципові зміни:

-на відміну від RC5, в алгоритмі використовується множення за модулем ;

-для збереження 32-бітових обчислень замість розбиття шифруємого блоку даних (128 біт згідно принциповому вимогу конкурсу AES) на два 64-бітових суб блока виконується його розбиття на 4 32-бітових суб блока та їх обробка по трохи зміненій схемі.

Структура алгоритму

Як і алгоритм RC5, RC6 має гнучку структуру: крім секретного ключа, параметрами алгоритму є наступне:

-розмір слова ; RC6 шифрує блоками по 4 слова;

-кількість раундів алгоритму R;

-розмір секретного ключа в байтах b.

Аналогічно RC5, для уточнення параметрів алгоритму, що використовуються в його конкретної реалізації, застосовується позначення . Оскільки в конкурсі AES 128-бітний блок є обов'язковим, значення w фіксоване і дорівнює 32. У специфікації алгоритму фіксується також кількість раундів: R = 20.

1.2.5Алгоритм IDEA

IDEA є блоковим алгоритмом шифрування даних, запатентованим швейцарською фірмою Ascom. Фірма, дозволила безкоштовне некомерційне використання свого алгоритму (застосовується в загальнодоступному пакеті конфіденційної версії електронної пошти PGP). Тут на відміну від алгоритму DES не використовуються S-блоки або таблиці перегляду. У IDEA застосовуються 52 суб ключ, кожен довжиною 16 біт. Оригінальний текст в IDEA ділиться на чотири групи по 16 біт. Для того щоб комбінувати 16 бітні коди, використовується три операції: додавання, множення і виключає АБО. Додавання являє собою звичайну операцію по модулю 65536 з переносом. При складанні таблиці множення приймаються спеціальні заходи для того, щоб операція була оборотною. З цієї причини замість нуля використовується код 65536.

Нехай чотири чверті вихідного тексту мають імена A, B, C і D, а 52 суб ключа - . Перед реалізацією алгоритму виконуються операція:

;

;

;

Перший цикл обчислень:

Міняємо місцями В і С.

Повторюємо це все 8 разів, використовуючи - для другого разу і, відповідно, - - для восьмого. Після восьмого разу В і С місцями не змінюються. Після цього виконуються операції:

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

Схема реалізації алгоритму шифрування IDEA показано на рисунку 1.2

Рисунок 1.2 - Схема реалізації алгоритму шифрування IDEA

1.2.6Алгоритм SEED

SEED - в криптографії симетричний блоковий криптоалгоритм на основі Мережі Фейстеля, розроблений Корейським агентством інформаційної безпеки в 1998 році. В алгоритмі використовується 128-бітний блок і ключ довжиною 128 біт. Алгоритм широко використовується фінансовими і банківськими структурами, виробничими підприємствами і бюджетними установами Південної Кореї, отримавши широке поширення, оскільки 40-бітний SSL не забезпечує на даний момент мінімально необхідного рівня безпеки. Агентством із захисту інформації специфікована використання шифру SEED в протоколах TLS і S / MIME. У той же час, алгоритм SEED не реалізований в більшості сучасних браузерів і Інтернет - додатків, що ускладнює його використання в даній сфері поза межами Південної Кореї.

SEED являє собою Мережа Фейстеля з 16 раундами, 128-бітовими блоками і 128-бітовим ключем. Алгоритм використовує два 8 Ч 8 таблиці підстановки, які, як такі з Safer, виведені з дискретного піднесення до степеня( та ). Це є деяким подібністю c MISTY1 в рекурсивность його структури: 128-бітовий повний шифр - мережа Фейстеля з F-функцією, що впливає на 64-бітові половини, в той час як сама F-функція - Мережа Фейстеля, складена з G-Функції, що впливає на 32-розрядні половини. Однак рекурсія не простягається далі, тому що G-Функція - не Мережа Фейстеля. До G-Функції 32-розрядне слово розглядають як чотири 8-бітових байтів, кожен з яких проходить через одну або іншу таблицю підстановки, потім об'єднується в помірно комплексному наборі булевих функцій таким чином, що кожен біт виведення залежить від 3 з 4 вхідних байтів.має складну ключове розклад, генеруючи тридцять два 32-розрядних додаткових символу використовуючи G-Функції на серіях обертань вихідного необробленого ключа, комбінованого зі спеціальними раундовим константами (як у TEA) від «Золотого співвідношення» (англ. Golden ratio).

1.2.7Алгоритм Camellia

Camellia - алгоритм симетричного блокового шифрування (розмір блока 128 біт, ключ 128, 192, 256 біт), один з фіналістів європейського конкурсу NESSIE (поряд з AES і Shacal-2), розробка японських компаній Nippon Telegraph and Telephone Corporation і Mitsubishi Electric Corporation (представлений 10 березня 2000 р.). Сертифікований японською організацією CRYPTREC як рекомендований для промислового та державного використання алгоритм.є подальшим розвитком алгоритму шифрування E2, одного з алгоритмів, представлених на конкурсі AES і з використанням елементів алгоритму MISTY1.

Структура алгоритму заснована на класичній ланцюга Фейстеля з попереднім і фінальним забеліваніем. Циклова функція використовує нелінійне перетворення (S-блоки), блок лінійного розсіювання кожні 16 циклів (побайтова операція XOR) і байтове перестановку.

У залежності від довжини ключа має 18 циклів (128 розрядний ключ), або 24 циклу (192 і 256 розрядний ключ).

Підтримка алгоритму Camellia введена в 2008 році в браузері Mozilla Firefox 3. Алгоритм патентований, проте поширюється під вільними ліцензіями, зокрема, є частиною проекту OpenSSL.

1.2.8Алгоритм XTEA

У криптографії, XTEA (eXtended TEA) - блочний шіфроалгоритм, покликаний усунути критичні помилки алгоритму TEA. Розробниками шифру є Девід Уілер і Роджер Нідхем (факультет комп'ютерних наук Кембриджського університету). Алгоритм був представлений в невиданому технічному звіті в 1997 році. Шифр не патентований, широко використовується в ряді криптографічних додатків і широкому спектрі апаратного забезпечення завдяки вкрай низьким вимогам до пам'яті і простоті реалізації.

Як і TEA, шифр заснований на операціях з 64-бітним блоком, має 32 повних цикли, в кожному повному циклі за два раунди Мережі Фейстеля, що означає 64 раунди мережі Фейстеля. Проте, число раундів для досягнення кращої дифузії може бути збільшено на шкоду продуктивності. Крім того в XTEA, як і в TEA, використовується 128-бітний ключ, що складається з чотирьох 32-бітових слів , , , . У XTEA немає алгоритму планування ключів у звичному розумінні. Для того, щоб визначити який з чотирьох слів ключа використовувати в кожному раунді, в алгоритмі використовується константа . У TEA ж такого розподілу немає. Ще однією відмінністю від TEA є перестановка бітових операцій, що використовуються в шифрі. Завдяки цим поліпшень XTEA не зазнав сильних ускладнень в порівнянні з TEA, але в той же час ліквідував два основних недоліки алгоритму TEA:

-кожен ключ в TEA еквівалентний трьом іншим, що означає, що ефективна довжина ключа становить 126 біт замість 128, як це було задумано розробниками;

-TEA сприйнятливий до атак на зв'язаних ключах. Така атака може зажадати всього лише вибраного відкритого тексту і мати часову складність рівну .

1.3Асиметричні криптографічні системи

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

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

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

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

Асиметричні системи називають також двох ключові криптографічні системи, або криптосистемами з відкритим ключем.

Узагальнена схема асиметричної криптосистеми шифрування з відкритим ключем показана на рисунку 1.3

Рисунок 1.3 - Схема асиметричної криптосистеми шифрування з відкритим ключем

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

В якості ключа зашифровування повинен використовуватися відкритий ключ одержувача, а в якості ключа розшифрування - його секретний ключ.

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

Процес передачі зашифрованої інформації в асиметричній криптосистемі здійснюється наступним чином.

Підготовчий етап:

-абонент генерує пару ключів: секретний ключ і відкритий ключ ;

-відкритий ключ надсилається абоненту.

-Використання - обмін інформацією між абонентами і :

-абонент зашифровує повідомлення за допомогою відкритого ключа абонента і відправляє шифртекст абоненту ;

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

1.3.1Алгоритм RSA

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

Крипостійкість алгоритму RSA ґрунтується на припущенні, що винятково важко визначити секретний ключ за відомим, оскільки для цього необхідно вирішити завдання про існування дільників цілого числа. Дане завдання є - повною і, як наслідок цього факту, не допускає в даний час ефективного (поліноміального) рішення. Більше того, саме питання існування ефективних алгоритмів рішення - повних задач є до теперішнього часу відкритим. У зв'язку з цим для чисел, що складаються з 200 цифр, традиційні методи вимагають виконання величезного числа операцій (близько 1023 ). Час виконання найкращих з відомих алгоритмів розкладання при на сьогоднішній день виходить за межі сучасних технологічних можливостей.

Існує варіант криптосистеми RSA, в якій замість функції Ейлера використовується функція Кармайкла , де - найменше ціле , таке що для будь-якого цілого , взаємно простого з , виконується . Якщо вибирається так, як описано вище, то .

1.3.2Алгоритм DSA

DSA (Digital Signature Algorithm) - алгоритм з використанням відкритого ключа для створення електронного підпису, але не для шифрування (на відміну від RSA і схеми Ель-Гамаля). Підпис створюється таємно, але може бути публічно перевірено. Це означає, що тільки один суб'єкт може створити підпис повідомлення, але будь-хто може перевірити його коректність. Алгоритм заснований на обчислювальній складності взяття логарифмів в кінцевих полях.

Алгоритм був запропонований Національним інститутом стандартів і технологій (США) у серпні 1991 і є запатентованим US Patent 5231668, але НІСТ зробив цей патент доступним для використання без ліцензійних відрахувань. Алгоритм разом з криптографічного хеш-функцією SHA-1 є частиною DSS (Digital Signature Standard), вперше опублікованого в 1994р. Пізніше були опубліковані 2 оновлені версії стандарту: FIPS 186-2 (27 січня 2000 року) і FIPS 186-3 (червень 2009).

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

1.3.3Алгоритм Elgamal

Схема Ель-Гамаля (Elgamal) - криптосистема з відкритим ключем, заснована на труднощі обчислення дискретних логарифмів в кінцевому полі. Криптосистема включає в себе алгоритм шифрування і алгоритм цифрового підпису. Схема Ель-Гамаля лежить в основі стандартів електронного цифрового підпису в США і Росії.

Схема була запропонована Тахер Ель-Гамалем в 1984 році. Ель-Гамаль удосконалив систему Діффі-Хеллмана і отримав два алгоритми, які використовувалися для шифрування і для забезпечення автентифікації. На відміну від RSA алгоритм Ель-Гамаля не був запатентований і, тому, став більш дешевою альтернативою, тому що не була потрібна оплата внесків за ліцензію.

Шифр система Ель-Гамаля є фактично одним із способів вироблення відкритих ключів Діффі - Хеллмана. Шифрування за схемою Ель-Гамаля не слід плутати з алгоритмом цифрового підпису за схемою Ель-Гамаля.

1.3.4Алгоритм Rabin

Криптосистема Rabin - криптографічний алгоритм з відкритим ключем. Її безпеку, як і у RSA, пов'язана з труднощами розкладання на множники.

Безпека схеми Rabin спирається на складність пошуку квадратних коренів по модулю складеного числа.

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

Як будь-яка асиметрична криптосистема, система Rabin використовує і відкритий і закритий ключі.

1.3.5Алгоритм McEliece

McEliece - криптосистема з відкритими ключами на основі теорії алгебраїчного кодування, розроблена в 1978 році Робертом Мак-Елісом. Цей алгоритм використовує існування певного класу виправляють помилки кодів, які називаються кодами Гоппе (Goppa). Він пропонував створити код Гоппе і замаскувати його як звичайний лінійний код.

Висновок до розділу 1

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

РОЗДІЛ 2. АВТЕНТИФІКАЦІЯ ПО ПРОТОКОЛУ KERBEROS

2.1Стандарти автентифікації по протоколу Kerberos

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

Протокол автентифікації Kerberos пропонує механізм взаємної ідентифікації клієнту та сервера (або двох серверів) перед встановлення звязку між ними.представляє собою набір методів ідентифікації і перевірки істинності партнерів по обміну інформацією (робочих станцій, користувачів або серверів) у відкритій (незахищеної) мережі. Процес ідентифікації не залежить від автентифікації, виконуваної мережевою операційною системою, не ґрунтується у прийнятті рішень на адреси хостів і не передбачає обов'язкову організацію фізичної безпеки всіх хостів мережі. Крім того, допускається, що пакети інформації, що передаються по мережі, можуть бути змінені, прочитані й передані в будь-який момент часу [16,17]. Слід, однак, відзначити, що більшість додатків використовує функції протоколу Kerberos тільки при створенні сеансів передачі потоків інформації. При цьому передбачається, що подальше несанкціоноване руйнування потоку даних неможливо. Тому використовується пряма довіра, заснована на адресі хоста. Kerberos виконує автентифікацію як довірена служба третьої сторони, використовуючи шифрування за допомогою загального секретного ключа (shared secret key).

Протокол призначений для автентифікації суб'єкта об'єктом (і навпаки), наприклад сервера клієнтом, у разі коли середовище передачі даних відкрита, а об'єкт спочатку нічого не знає про суб'єкта і не має з ним спільної таємниці, але обидва (і суб'єкт, і об'єкт) попередньо ідентифіковані третьою стороною - довіреною сервером і мають з ним спільні секрети (ніколи не передаються по мережі). Вимога наявності такого секрету і визначає схему захисту протоколу - симетричними криптографічними алгоритмами (DES). Відповідно до прийнятої термінології суб'єкт і об'єкт називаються принципалами (англ. principals), а довірений сервер називають центром розподілу ключів - ЦРК (англ. Key Distribution Center - KDС).

2.2Основна концепція

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

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

Тепер Сергію і Олені залишається тільки вирішити, яким чином показати своє знання пароля. Можна, скажімо, просто включити його в текст повідомлення, наприклад, після підпису: «Olena, Our $ ecret». Це було б дуже просто, зручно і надійно, якщо б Олена і Сергій були впевнені, що ніхто інший не читає їх повідомлень. Однак пошта передається по мережі, де працюють і інші користувачі, а серед них є Керол, яка дуже любить підключати до мережі свій аналізатор пакетів в надії вивідати чиї не будь секрети. І стає абсолютно ясно, що Олена не може просто назвати пароль в тексті листа. Щоб секрет залишався секретом, про нього не можна говорити відкрито, потрібно знайти спосіб тільки дати знати співрозмовнику, що він тобі відомий.

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

2.3Переваги автентифікації по протоколу Kerberos

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

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

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

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

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

-Сумісність. В основу своєї реалізації протоколу Kerberos корпорація Microsoft поклала стандартні специфікації, рекомендовані групою IETF. Завдяки такому підходу вдалося забезпечити автентифікацію клієнтів Windows у всіх мережах, які підтримують Kerberos 5.

2.4Робота протоколу

2.4.1Автентифікатори

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Як вже зазначалося, довготривалий ключ користувача створюється на основі його пароля. Щоб краще зрозуміти це, повернемося до нашого прикладу. Коли Олена проходить реєстрацію, клієнт 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 нічим не відрізняється від організації такого доступу до будь-якої іншої службі домену - вона вимагає сеансового ключа, автентифікатором та білета.

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

2.4.5Автентифікація за межами домену

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

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

А тепер розглянемо, що відбувається, коли користувач з обліковим записом в домені «Схід» запитує доступ до сервера з домену «Захід». Перш за все, клієнт Kerberos, встановлений на робочій станції користувача, надсилає запит до служби видачі білетів свого домену, в якому просить видати сеансовий білет для доступу на потрібний сервер. Служба видачі білетів домену «Схід» перевіряє список своїх абонентів безпеки і переконується, що такого сервера серед них немає. Тому вона направляє клієнтові так званий білет переадресації (referral ticket), який представляє собою TGT, зашифрований за допомогою міждоменного ключа, спільного для служб KDC доменів «Схід» і «Захід». Отримавши білет переадресації, клієнт використовує його для підготовки іншого запиту на сеансовий ключ. Однак на цей раз запит пересилається в службу видачі білетів того домену, де знаходиться обліковий запис потрібного сервера, тобто, домену «Захід». Його служба видачі білетів намагається розшифрувати білет переадресації за допомогою власної копії Міждомена ключа. Якщо спроба вдається, центр KDC направляє клієнтові сеансовий білет на доступ до відповідного серверу свого домену.

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

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

1.Клієнт запитує у служби KDC домену «Схід» білет на доступ до сервера домена «Захід».

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

2.Клієнт звертається до служби KDC домену «Штаб-квартира» з проханням про білет на доступ до сервера домена «Захід».

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

3.Клієнт звертається до служби KDC домену «Захід» з проханням про білет на доступ до сервера домена «Захід».

Служба KDC домену «Захід» спрямовує клієнту білет на доступ до потрібного сервера.

2.5Підпротоколи

Протокол Kerberos містить у собі три підпротоколи:

-Перший з них використовується службою KDC для передачі клієнту сеансового ключа реєстрації та білета TGT. Він називається Authentication Service Exchange (обмін зі службою автентифікації) або, скорочено AS Exchange.

-Другий подпротокол під назвою Ticket-Granting Service Exchange (обмін зі службою видачі білетів) або TGS Exchange служить для розсилки службових сеансових ключів і сеансових ключів самої служби KDC.

-Третій подпротокол, Client / Server Exchange (клієнт-серверний обмін) або CS Exchange, використовується клієнтом для пересилання сеансового білета доступу до служб.

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

2.5.1Підпротокол AS Exchange

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

Після цього клієнт посилає в службу автентифікації центру KDC запит KRB_AS_REQ (Kerberos Authentication Service Request - запит до служби автентифікації Kerberos). Перша частина його повідомлення містить ідентифікатор користувача, тобто Олени, а також ім'я служби, для якої їй потрібно посвідчення, тобто служби видачі білетів. У другій частині вказуються дані попередньої автентифікації (pre-authentication data), які підтверджують, що Олена знає пароль. Зазвичай в якості таких даних використовується мітка часу, зашифрована з довготривалим ключем Олени, хоча Kerberos допускає і інші види предавтентіфікаціонних даних (рисунок 2.5).

Рисунок 2.5 - Подпротокол AS Exchange

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

Після того, як перевірка особи Олени завершена, служба KDC генерує посвідчення, яке підтверджує, що клієнт Kerberos на її робочої станції має право звернутися до служби видачі білетів. Цей процес виконується в два етапи. По-перше, KDC створює сеансовий ключ реєстрації та шифрує його копію за допомогою довгострокового ключа Олени. По-друге, служба включає ще одну копію сеансового ключа реєстрації у білет TGT. Туди ж заноситься і інша інформація про Олену, наприклад, її дані авторизації. Потім KDC шифрує білет TGT з власним довготривалим ключем і, нарешті, включає зашифрований сеансовий ключ реєстрації разом з білетом TGT в пакет KRB_AS_REP (Kerberos Authentication Service Reply - відповідь служби автентифікації Kerberos), який направляє клієнту.

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

2.5.2Підпротокол TGS Exchange

Клієнт Kerberos, встановлений на робочій станції Олени, запитує посвідчення на доступ до служби Сергій, для чого посилає в службу KDC повідомлення KRB_TGS_REQ (Kerberos Ticket-Granting Service Request - запит до служби видачі білетів Kerberos). У нього включається ім'я користувача, автентифікатор, зашифрований за допомогою сеансового ключа реєстрації Олени, білет TGT, який був отриманий за допомогою подпротокола AS Exchange, а також ім'я служби, на доступ до якої потрібен білет (рисунок 2.6).

Рисунок 2.6 - Подпротокол TGS Exchange

Отримавши запит KRB_TGS_REQ, служба KDC за допомогою власного секретного ключа розшифровує білет TGT і витягує з нього сеансовий ключ реєстрації Олени, який тут же використовує для розшифровки автентифікатором. Якщо вміст автентифікатора витримує перевірку, служба KDC витягує з білета TGT реєстраційні дані Олени і генерує сеансовий ключ, загальний для клієнта Олени та служби Сергій. Одну копію цього ключа KDC шифрує за допомогою сеансового ключа реєстрації Олени, а іншу разом з даними авторизації Олени поміщає у білет, який шифрує за допомогою довгострокового ключа Сергія. Після цього посвідчення Олени включається в пакет KRB_TGS_REP (Kerberos Ticket-Granting Service Reply - відповідь служби видачі білетів Kerberos) і прямує на її робочу станцію.

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

2.5.3Підпротокол CS Exchange

Клієнт Kerberos, встановлений на робочій станції Олени, звертається до служби Сергій, для чого посилає на неї запит KRB_AP_REQ (Kerberos Application Request - Запит програми Kerberos). Це повідомлення містить автентифікатор Олени, зашифрований за допомогою сеансового ключа для служби Сергій, білет, отриманий за допомогою протоколу TGS Exchange, а також прапор, який вказує про бажання клієнта провести взаємну автентифікацію (рисунок 2.7).

Рисунок 2.7 - Подпротокол CS Exchange

Отримавши повідомлення KRB_AP_REQ, служба Сергій розшифровує білет, витягує з нього дані авторизації Олени і сеансовий ключ, за допомогою якого відразу ж розшифровує автентифікатор Олени. Якщо мітка часу, закладена в нього, витримує перевірку, Сергій шукає в запиті прапор взаємної автентифікації. Знайшовши його, Сергій шифрує мітку часу з автентифікатором Олени сеансовим ключем, включає отриманий результат в пакет KRB_AP_REP (Kerberos Application Reply - відповідь додатка Kerberos) і повертає його на робочу станцію Олени.

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

2.6Білети

Перерахування полів білета і описання яке міститься в них (таблиця 2.1).

Таблиця 2.1

Поля білета

Назва поляОписПерші три поля білета не шифруються. Інформація, що міститься тут інформація пересилається відкритим текстом, що дозволяє клієнту використовувати її для управління білетами, що зберігаються в кеш-пам'яті.tkt-vnoНомер версії формату білета.RealmІм'я області (домену), де згенеровано білет. Служба KDC може створювати білети тільки для серверів власної області, тому тут, по суті, вказується ім'я області, де розташований сервер.SnameІм'я сервера.Інші поля шифруються за допомогою секретного ключа сервера.FlagsПрапори білета.KeyСеансовий ключ.CrealmІм'я області (домену) клієнта.CnameІм'я клієнта.TransitedСписок областей Kerberos, які брали участь в автентифікації клієнта, якій видано даний білет.AuthtimeЧас первісної автентифікації клієнта. Служба KDC заповнює це поле в момент генерації білета TGT. При генерації білетів на основі білета TGT тимчасова мітка з поля authtime білета TGT копіюється в поле authtime генерується білета.StarttimeЧас вступу білета в силу.EndtimeЧас закінчення терміну дії білета.renew-tillНайбільше значення поля endtime, яке може бути задано за допомогою прапора RENEWABLE (поле необов'язкове).CaddrОдин або декілька адрес, з яких може використовуватися даний білет. Поле необов'язкове. Якщо воно не заповнено, білетом можна скористатися з будь-якої адреси.Authorization-dataАтрибути привілеїв клієнта. Поле необов'язкове. Його вміст Kerberos не обробляє - воно інтерпретується службою.

Вміст поля flags адресується по бітно. Включення і вимикання прапорів тут виробляється зміною значення (0 або 1) відповідного біта. Довжина поля - 32 розряду, проте для адміністратора Kerberos інтерес представляють тільки 9 прапорів білета (таблиця 2.2).

Таблиця 2.2

Прапори білета

ПрапорОписFORWARDABLEВказує, що на підставі даного білета TGT служба видачі білетів може генерувати новий білет TGT з іншим мережевим адресою (поле є тільки у білетах TGT).FORWARDEDВказує на те, що даний білет TGT був переадресований або згенерує на основі іншого білета TGT, що пройшов переадресацію.PROXIABLEВказує, що служба видачі білетів може генерувати білети, мережеву адресу яких буде відрізнятися від наведеного в даному білету TGT (поле є тільки у білетах TGT).PROXYВказує на те, що мережеву адресу в даному білету відрізняється від адреси, наведеного в білету TGT, на підставі якого він виданий.RENEWABLEВикористовується в поєднанні з полями endtime і renew-till, дозволяючи періодичне оновлення службою KDC білетів з підвищеним терміном діїINITIALВказує, що даний білет є білетом видачі білетів (поле є тільки у білетах TGT).

2.6.1Дані з білета відомі клієнту

Клієнту необхідно знати частину інформації, що міститься як у звичайних білетах, так і у білетах TGT, щоб управляти своєю кеш-пам'яттю посвідчень. Повертаючи білет і сеансовий ключ в рамках під протоколів AS Exchange або TGS Exchange, служба KDC упаковує клієнтську копію сеансового ключа до структури даних, де вже можуть бути заповнені поля flags, authtime, starttime, endtime і renew-till. Вся ця структура шифрується за допомогою ключа клієнта, включається в пакет KRB_AS_REP або KRB_TGS_REP і повертається на робочу станцію клієнта.

Служба KDC обмежує термін дії білета

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

Запитуючи в центрі KDC білет для доступу до служби, клієнт може вказати конкретний час початку його дії. Якщо цього не зроблено або заданий час вже минуло, центр KDC зазначає у полі starttime поточний час.

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

2.6.2Що відбувається після закінчення терміну дії білета

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

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

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

2.6.3Оновлюванні білети TGT

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

Поле endtime вказує, коли закінчується термін дії поточного екземпляра білета. Як і у випадку з неоновлюваної білетами, значення цього поля дорівнює сумі значення з поля starttime і найбільшого терміну дії білетів, визначеного політикою Kerberos. Клієнт, який використовує оновлюваний білет, повинен представити його в службу KDC для оновлення до часу, вказаного в полі endtime. Одночасно з білетом в центр розподілу ключів спрямовується і новий автентифікатор. Отримавши білет, який потрібно оновити, служба KDC, перш за все, перевіряє загальний строк його дії, зазначений в полі renew-till. Це час задається при первинній генерації білета. Воно визначається шляхом підсумовування значення з поля starttime з максимально допустимим політикою Kerberos терміном дії білета з урахуванням всіх оновлень. Якщо зазначена в полі renew-till час ще не настав, служба KDC генерує новий екземпляр білета, де зазначає більш пізній час endtime і замінює сеансовий ключ.

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

2.6.4Делегування автентифікації

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

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

Делегування автентифікації можливо двома способами. По-перше, клієнт може отримати білет на підключення до сервера вищого рівня, а потім передати його найближчому серверу. Білети, отримані таким способом - клієнтом для найближчого сервера - називаються представницькими (proxy tickets). Однак на цьому шляху є одна серйозна трудність: щоб отримати представницький білет, клієнтові потрібно знати ім'я сервера вищого рівня. Вирішити проблему допомагає другий спосіб делегування автентифікації. Тут клієнт передає на найближчий до нього сервер свій білет TGT, який той у міру необхідності використовує для запиту власних білетів. Білети TGT, отримані таким чином, тобто, за посвідченням клієнта, називаються переданими (forwarded tickets). Який з описаних способів застосовується службою KDC, залежить від політики Kerberos.

2.6.5Представницькі білети

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

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

криптографічний безпека протокол kerberos

2.6.6Передані білети

Клієнт, який має намір делегувати свої права на отримання білета для доступу до сервера вищого рівня, повинен запросити у служби KDC передаваємий білет TGT. Це робиться за допомогою під протоколу AS Exchange. У запит обов'язково включається ім'я сервера, який буде представляти клієнта. Якщо політика Kerberos допускає використання передаваємих білетів, служба KDC генерує білет TGT на доступ даного клієнта до сервера вищого рівня, виставляє в ньому прапор FORWARDABLE і в такому вигляді направляє клієнту. Клієнт, у свою чергу, пересилає отриманий білет TGT того сервера, з яким працює безпосередньо.

Цей сервер, направляючи білет на сервер вищого рівня, представляє в службу KDC білет TGT, отриманий від клієнта. Виявивши в ньому прапор FORWARDABLE, центр управління білетами виставляє в новому білету прапор FORWARDED і повертає його першому серверу.

2.6.7Центр розподілу ключів KDC

В операційній системі Windows KDC реалізований як служба домену. У якості бази даних облікових записів він використовує Active Directory. Крім того, деякі дані про користувачів надходять в нього з глобального каталогу (Global Catalog).

Як і в інших реалізаціях протоколу Kerberos, центр KDC Windows представляє собою єдиний процес, що поєднує дві служби:

-Служба автентифікації Authentication Service (AS). Ця служба видає білети на видачу білетів (білети TGT). Перш, ніж отримати білет на обслуговування, мережевий клієнт повинен запросити початковий білет TGT, звернувшись для цього до служби автентифікації того домену, де знаходиться обліковий запис користувача.

-Служба видачі білетів Ticket-Granting Service (TGS). Ця служба видає білети на доступ до інших служб свого домену або до служби видачі білетів довіреному домену. Щоб звернутися до служби TGS, клієнтові потрібно спочатку увійти в контакт зі службою видачі білетів того домену, де знаходиться обліковий запис служби, представити свій білет TGT і запитати потрібний білет. Якщо у клієнта немає білета TGT, який відкриває доступ до даної службі видачі білетів, він може скористатися процесом переадресації (referral process). Початковою точкою цього процесу є служба того домену, де знаходиться обліковий запис користувача, а кінцевою - служба видачі білетів домену, де знаходиться обліковий запис необхідної служби.

Центр KDC, як і служба каталогів Active Directory, є в кожному домені. Обидві служби автоматично запускаються підсистемою LSA (Local Security Authority - розпорядник локальної безпеки), яка встановлена на контролері домену. Вони працюють у просторі процесів цього розпорядника. Жодну з цих служб зупинити неможливо. Щоб гарантувати постійний доступ до KDC і Active Directory, в Windows є можливість розгортання в кожному домені кількох рівноправних контролерів домену. При цьому запити на автентифікацію і на видачу білета, адресовані службі KDC даного домену, може приймати будь який контролер домену.

У доменах Windows служба KDC є абонентом безпеки. В цій якості вона виступає під ім'ям krbtgt. Обліковий запис абонента безпеки для неї створюється автоматично при організації нового домену; цей запис не можна ні змінити, ні перейменувати. Пароль облікового запису KDC також присвоюється автоматично, а потім регулярно змінюється на плановій основі разом з паролями довірених облікових записів домену (domain trust account). Пароль облікового запису KDC використовується при обчисленні секретного ключа, необхідного для шифрування і розшифрування генеруючи цією службою білетів TGT. Пароль довіреного облікового запису домену необхідний для розрахунку Міждоменних (міжобласних) ключів, які використовуються для шифрування білетів переадресації.

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

2.6.8База даних облікових записів

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

Серверами служби каталогу Active Directory є тільки контролери доменів. На кожному з них зберігається копія каталогу, в яку можна вносити зміни. Це дозволяє створювати нові облікові записи, змінювати паролі і коригувати склад груп, звернувшись на будь-який контролер домену. Зміни, внесені в одну репліку каталогу, автоматично переносяться на всі інші його репліки. Правда, Windows не використовує для цієї мети протокол реплікації Kerberos. Копіювання та поширення інформації, що зберігається в Active Directory, проводиться за допомогою власного протоколу децентралізованої реплікації (multi-master replication protocol), розробленого корпорацією Microsoft, причому пересилання її здійснюється по захищених каналах між контролерами доменів.

Фізичним зберіганням інформації про облікові записи управляє агент DSA (Directory System Agent - агент системи каталогу). Цей захищений процес інтегрований з підсистемою LSA, що працює на контролері домену. Клієнти служби каталогу ніколи не отримують прямого доступу до сховища з даними про облікові записи. Будь-який клієнт, якому потрібна інформація з каталогу, повинен скористатися для підключення до DSA інтерфейсом ADSI (Active Directory Service Interface - інтерфейс служб Active Directory). Лише після цього він може шукати, читати і записувати об'єкти і їхні атрибути.

Запити на доступ до об'єктів чи атрибутів каталогу підлягають перевірці в системі управління доступом Windows . Подібно об'єктам файлів і папок у файловій системі NTFS, об'єкти Active Directory захищаються за допомогою ACL (Access Control List - список контролю доступу), де міститься інформація про те, хто і яким способом має право звертатися до об'єктів. Правда, в об'єктах Active Directory, на відміну від файлів і папок, список контролю доступу є для кожного атрибута. Самим секретним елементом будь-якого облікового запису, є пароль. В об'єкті облікового запису атрибут пароля зберігає не сам пароль, а криптографічний ключ, отриманий на його основі, однак цей ключ представляє для зловмисника не меншу цінність. З цієї причини доступ до атрибуту пароля надається виключно власнику облікового запису. Такого права не має ніхто інший, навіть адміністратор. Прочитати інформацію про пароль або змінити її можуть тільки процеси з привілеєм Trusted Computer Base, які працюють в контексті безпеки LSA.

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

2.7Політика Kerberos

У середовищі Windows політика Kerberos визначається на рівні домену та реалізується службою KDC домену. Вона зберігається в каталозі Active Directory як підмножина атрибутів політики безпеки домену. За замовчуванням вносити зміни в політику Kerberos мають право тільки члени групи адміністраторів домену.

У політиці Kerberos передбачаються:

-Максимальний термін дії користувальницького білета (Maximum user ticket lifetime). Під «користувальницьким білетом» тут мається на увазі білет на видачу білетів (білет TGT). Значення задається в годинах і за замовчуванням дорівнює 10 год.

-Максимальний час, протягом якого допускається оновлення користувацького білета (Maximum lifetime that a user ticket can be renewed). Задається в добі; за замовчуванням становить 7 діб.

-Максимальний термін дії службової білета (Maximum service ticket lifetime). Під «службовим білетом» тут мається на увазі сеансовий білет. Значення цього параметра має бути більше 10 хвилин, але менше значення Maximum user ticket lifetime. За замовчуванням воно дорівнює 10 год.

-Максимально допустиме відхилення в синхронізації комп'ютерних годин (Maximum tolerance for synchronization of computer clocks). Зазначається у хвилинах; за замовчуванням дорівнює 5 хв.

-Перевірка обмежень при вході користувача в систему (Enforce user logon restrictions). Якщо цей пункт позначено прапорцем, служба KDC аналізує кожен запит на сеансовий білет і перевіряє, чи має даний користувач право на локальний вхід в систему (привілей Log on Locally) чи на доступ до запитуваного комп'ютера через мережу (привілей Access this computer from network). Така перевірка займає додатковий час і може сповільнити надання мережевих послуг, тому адміністратору надається право її відключення. За умовчанням вона включена.

Делегування автентифікації

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

Попередня автентифікація

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

Постачальник підтримки безпеки Kerberos

Протокол автентифікації Kerberos реалізований у формі постачальника підтримки безпеки (security support provider, скорочено SSP) - динамічно підключає бібліотеки, що входить до складу операційної системи. У Windows передбачено також постачальника SSP для протоколу NTLM. За замовчуванням обидва ці компоненти завантажуються підсистемою LSA на комп'ютер Windows одночасно із завантаженням операційної системи. Кожен з цих постачальників дозволяє виробляти автентифікацію як входу в мережу, так і клієнт-серверних підключень. Який постачальник буде використаний у тому чи іншому конкретному випадку, залежить від можливостей комп'ютера, з яким встановлюється зв'язок, проте, в першу чергу система завжди намагається скористатися постачальником Kerberos SSP.

Після того, як підсистема LSA створить контекст безпеки для інтерактивного користувача, може знадобитися ще один примірник Kerberos SSP. Його завантаження виробляє процес, запущений в призначеному для користувача контексті безпеки, щоб забезпечити підтримку підпису та завірення повідомлень.

Системні служби і додатки транспортного рівня звертаються до SSP через інтерфейс SSPI (Security Support Provider Interface - інтерфейс постачальника підтримки безпеки). Він представляє собою інтерфейс Win32 ®, що дозволяє переглянути список доступних на системі постачальників, вибрати один з них і використовувати його для організації автентифікованим підключення. Виконання всіх цих функцій проводиться в SSPI стандартизованими методами, свого роду підпрограмами «чорного ящика», якими розробник може користуватися, навіть не розбираючись в тонкощах самого протоколу. Наприклад, при автентифікації клієнт-серверного підключення пересилання посвідчення клієнтського додатка на сервер проводиться за допомогою методу InitializeSecurityContext. Якщо постачальник Kerberos SSP, цей метод генерує на клієнтському комп'ютері повідомлення KRB_AP_REQ. У відповідь серверний додаток, використовуючи метод AcceptSecurityContext, направляє клієнтові повідомлення KRB_AP_REP. Коли автентифікація підключення завершена, серверна підсистема LSA генерує маркер доступу, заснований на інформації з клієнтського білета. Після цього сервер звертається до методу SSPI під назвою ImpersonateSecurityContext і з його допомогою прикріплює маркер доступу до потоку.

Кеш-пам'ять посвідчень

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

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

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

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

Дозвіл імен DNS

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

Служба KDC встановлюється на всіх контролерах домену Windows. Крім функцій серверів KDC ці контролери виконують ще й функції серверів LDAP (Lightweight Directory Access Protocol - полегшений протокол доступу до каталогів). Обидві ці служби реєструються в записах покажчика служб системи DNS (записах ресурсів SRV). Щоб знайти контролер домену, клієнтові досить запросити на DNS запис ресурсу SRV з ім'ям _ldap._tcp.dc._msdcs.ІмяДоменаDNS. А запросивши запис ресурсу SRV з ім'ям _kerberos._udp.ІмяДоменаDNS, клієнт отримає у відповідь адресу служби KDC. Комп'ютери під керуванням Windows можуть звертатися і в ті області Kerberos, які не входять в домени Windows. Тут служба KDC розміщується на доменних контролерах, що працюють під управлінням інших операційних систем, тому імена DNS для таких серверів KDC доводиться зберігати в реєстрі клієнтського комп'ютера. У цьому випадку Kerberos SSP спочатку знаходить в реєстрі доменне ім'я DNS області користувача, а потім запитує відповідний сервер DNS і перетворює це ім'я в IP-адресу.

У Windows є спеціальна інструментальна програма, яка допомагає налаштовувати клієнтів для роботи з областями Kerberos, які не входять в домени Windows. Вона запускається файлом ksetup.exe з каталогу Support на компакт-диску Windows.

Транспорт IP

Для підключення до служби KDC клієнт повинен надіслати дейтаграму UDP на порт 88 відповідного IP-адреси. Служба KDC відповідає дейтаграмою на той порт IP-адреси відправника, звідки надійшов запит.відноситься до транспортних протоколів, не встановлює логічного з'єднання, тому його застосування цілком виправдано в тих випадках, коли організація підключення передбачає попередній обмін службовими повідомленнями. Цей протокол добре підходить і там, де обмін обмежується єдиним запитом і єдиною відповіддю на нього, як це має місце в сеансах зв'язку між клієнтом і службою KDC. Важливо тільки, щоб кожне таке повідомлення повністю вміщувалося в одну дейтаграму. Але найкращі результати застосування протоколу UDP дає в тих випадках, коли дейтаграми передаються як єдине ціле, тобто, кожна з них повністю вписується в один кадр. Ємність ж кадру залежить від передавальної середовища. У кадрі Ethernet, наприклад, максимальний розмір передаваного блоку даних (MTU) дорівнює 1 500 октетів. Отже, у фізичних мережах Ethernet повідомлення Kerberos, що відправляються у вигляді дейтаграм, можуть містити до 1 500 октетів даних.

Повідомлення з білетами для комп'ютерів Windows часто перевищують межу в 1 500 байт, тому для їх передачі використовується протокол ТСР.

Дані авторизації

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

Контроль доступу в Windows

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

Кожному абонентові привласнюється унікальний ідентифікатор безпеки SID (Security Identifier) - алфавітно-цифрова послідовність, за структурою нагадує телефонний номер. Першу її частину можна порівняти з кодом міста, так як вона вказує на домен, який видав SID. Друга частина ідентифікатора визначає обліковий запис всередині домену, подібно до того, як остання група телефонного номера - номер конкретного телефону в місті. Код домену унікальний для підприємства, а код облікового запису не повторюється всередині домену. На відміну від телефонних номерів ідентифікатор безпеки ніколи не використовується повторно. Можливість отримати SID, вже належав раніше іншому користувачеві, повністю виключена.

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

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

Як і індивідуальні абоненти безпеки, кожна група безпеки Windows отримує власний ідентифікатор SID. Таким чином, права користувача на доступ до об'єктів, його контекст безпеки, визначаються кількома ідентифікаторами - одного його особистого плюс по одному на кожну групу, членом якої полягає даний користувач.

Як KDC готує дані авторизації

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

Отримавши від користувача запит на білет TGT, служба KDC того домену, де знаходиться обліковий запис користувача, звертається до Active Directory. Один з атрибутів облікового запису користувача містить його власний ідентифікатор SID, а інший - ідентифікатори всіх груп безпеки домену, в які цей користувач входить. Всі виявлені ідентифікатори передаються в KDC, де включаються до поля білета TGT, відведений під дані авторизації. У мережі з декількома доменами служба KDC, крім того, звертається в глобальний каталог Global Catalog за інформацією про універсальні групах, в які входить сам користувач або групи безпеки домену, членом яких він складається. Якщо такі універсальні групи знайдено, їх ідентифікатори SID включаються в те саме поле білета TGT.

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

Як дані авторизації використовуються службами

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

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

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

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

Обґрунтування підпису даних авторизації

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

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

При отриманні запиту на метод AcceptSecurityContext підсистема LSA довіряє тільки тим службам, які працюють в контексті облікового запису Local Systems. Справа в тому, що ця обліковий запис за замовчуванням доступна лише службам, які були встановлені разом із самою операційною системою, наприклад внутрішній службі «Сервер» (Server). Звичайно, використання цього облікового запису неважко передбачити в конфігурації та інших служб, однак зробити це може лише член групи Адміністраторів. Передбачається, що адміністратор, який встановив таку службу, повністю відповідає за її безпеку.

Службам, що працюють в контекстах інших облікових записів, підсистема LSA не довіряє. Отримавши сеансовий білет від будь-якої програми, яка не входить до числа локальних систем (група Local System), вона просить центр KDC свого домену перевірити підпис у поле з даними авторизації. Запит і відповідь на нього здійснюються за допомогою виклику віддаленої процедури по захищеному каналу (Netlogon) контролера домену. Такі запити ніколи не залишають меж локального домену, що пояснюється просто: сеансові білети завжди видаються, - а значить, і підписуються, - службою KDC того домену, де зберігається запитаний комп'ютер.

Інтерактивна реєстрація

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

Коли користувач входить в домен з комп'ютера під керуванням Windows, йому обов'язково потрібен хоча б один сеансовий білет для тієї машини, на якій він реєструється. Кожна машина Windows має в домені власний обліковий запис, яку для простоти можна представити як службову. Таким чином, щоб отримати доступ до ресурсів на комп'ютері Windows, віддаленому користувачеві потрібно представити запит у службу «Сервер» (Server) цього комп'ютера. Інтерактивні ж користувачі для цього направляють свої запити до служби «Робоча станція» (Workstation). Однак отримати доступ до будь-якої з цих служб, як і до будь-якої іншої службі групи «Локальна система» (Local System), можна лише після того, як буде представлений сеансовий білет для даного комп'ютера.

2.8Процес реєстрації

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

1.Користувач посилає заявку на підключення до служби видачі білетів домену.

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

2.Користувач запитує білет на комп'ютер.

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

3.Користувач посилає запит на доступ до служб «Локальної системи» комп'ютера.

При виконанні цієї операції Kerberos SSP на комп'ютері користувача являє сеансовий білет в підсистему LSA цього ж комп'ютера.

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

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

2.8.1Вхід в систему за паролем

Припустимо, що Олена має обліковий запис в домені «Захід». Там же знаходиться і обліковий запис сервера Сергій, з яким вона зазвичай працює. Вхід в мережу Олена починає з натискання клавіш CTRL + ALT + DEL, комбінація яких в стандартній конфігурації Windows генерує сигнал SAS (Secure Attention Sequence - послідовність звернення до системи безпеки).

У відповідь служба Winlogon комп'ютера перемикається на настільну систему, з якої надійшов сигнал SAS, і направляє на неї динамічно підключається бібліотеку GINA (Graphical Identification and Authentication - графічна ідентифікація та автентифікація) - компонент, що завантажується службою Winlogon. GINA служить для отримання від користувача даних реєстрації, їх упаковки в структуру даних і відправки в підсистему LSA на перевірку. На екрані з'являється стандартне діалогове вікно входу в систему. Олена вводить ім'я користувача та пароль, а у спадаючому списку доменів вибирає «Захід». Після клацання на кнопці ОК бібліотека MSGINA пересилає введені дані в службу Winlogon. Та, у свою чергу, викликає метод LsaLogonUser і з його допомогою направляє реєстраційну інформацію в підсистему LSA для перевірки.

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

Щоб перевірити реєстраційні дані Олени і почати сеанс її роботи на комп'ютері, підсистемі LSA необхідно отримати:

-білет TGT, який потрібно представити в службу видачі білетів;

-сеансовий білет, що відкриває доступ до сервера Сергій.

Підсистема LSA отримує ці білети через Kerberos SSP, що обмінюється повідомленнями безпосередньо зі службою KDC домену «Захід».

Рисунок 2.8 - Інтерактивна реєстрація в домені

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

1.Підсистема LSA направляє до служби KDC домену «Захід» повідомлення KRB_AS_REQ.

У повідомленні вказуються:

-для користувача ім'я Олени - Олени;

-ім'я домену з обліковим записом Олени - West.

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

2.Якщо дані попередньої автентифікації клієнта вірні, служба KDC відповідає повідомленням KRB_AS_REP.

У повідомлення включаються:

-сеансовий ключ для зв'язку Олени зі службою KDC, зашифрований за допомогою секретного ключа, який був створений на основі пароля Олени.

-білет TGT для служби KDC домену «Захід», зашифрований за допомогою секретного ключа служби KDC.

-У білету TGT зазначаються:

-сеансовий ключ для зв'язку Олени зі службою KDC;

-дані авторизації Олени.

-Дані авторизації включають в себе:

-ідентифікатор SID облікового запису Олени;

-ідентифікатори SID груп безпеки домена «Захід», членом яких складається Олена;

-ідентифікатори SID універсальних груп, в які входить або сама Олена, або одна з її груп домену.

3.Підсистема LSA направляє до служби KDC домену «Захід» повідомлення KRB_TGS_REQ.

У повідомлення включаються:

-ім'я комп'ютера, до якого потрібно підключитися, - Сергій;

-ім'я домену цього комп'ютера - West;

-білет TGT Олени;

-автентифікатор, зашифрований з сеансовим ключем, який використовується для зв'язку Олени з даною службою KDC.

4.Служба KDC відповідає повідомленням KRB_TGS_REP.

У повідомленні вказуються:

-сеансовий ключ Олени і Сергія, зашифрований за допомогою сеансового ключа, який Олена використовує для зв'язку зі службою KDC;

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

-Сеансовий білет містить:

-сеансовий ключ, загальний для Сергія і Олени;

-дані авторизації, скопійовані з білета TGT Олени.

Отримавши сеансовий білет Олени, підсистема LSA розшифровує його за допомогою секретного ключа цього комп'ютера і витягує дані авторизації Олени. Потім вона звертається в локальну базу даних диспетчера облікових записів безпеки SAM (Security Account Manager). Тут вона перевіряє, чи не є Олена членом якої-небудь групи безпеки, локальної для даного комп'ютера, і чи не має вона спеціальних привілеїв на цій машині. Якщо перевірка дає позитивний результат, підсистема LSA додає виявлені ідентифікатори SID у список даних авторизації, витягнутий з білета. Поповнена таким чином список використовується для генерації маркера доступу, описувач якого повертається в Winlogon разом з ідентифікатором сеансу реєстрації Олени і підтвердженням автентичності вжиті нею даних.

У відповідь Winlogon створює для Олени віконну станцію (windows station) і кілька об'єктів настільної системи, прикріплює її маркер доступу і запускає процес, який дозволить Олені взаємодіяти з комп'ютером Сергій. Маркер доступу Олени згодом буде включатися в усі прикладні процеси, що запускаються в ході поточного сеансу.

2.8.2Вхід в систему за допомогою смарт-карти

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

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

Реєстрація починається з того, що користувач вставляє свою смарт-карту в спеціальний зчитувальний пристрій, підключений до комп'ютера. При відповідній конфігурації Windows це рівносильно сигналом SAS, тобто, одночасного натискання клавіш CTRL + ALT + DEL. У відповідь Winlogon направляє на настільну систему, динамічно підключається бібліотеку MSGINA, яка виводить на екран стандартне діалогове вікно реєстрації. Щоправда, тепер користувачеві потрібно ввести тільки один параметр - персональний ідентифікаційний номер PIN (Personal Identification Number).викликає метод LsaLogonUser і з його допомогою пересилає реєстраційні дані користувача в підсистему LSA точно так само, як і при парольного реєстрації. Ця підсистема використовує PIN користувача для доступу до смарт-картки, де зберігаються секретний ключ користувача і сертифікат Х.509 v3, що містить відкритий ключ пари. Надалі всі криптографічні операції з використанням даної пари будуть проводитися через смарт-карту.SSP клієнтського комп'ютера направляє до служби KDC повідомлення KRB_AS_REQ - первинний запит на автентифікацію. У поле даних попередньої автентифікації цього запиту включається сертифікат відкритого ключа користувача. KDC перевіряє справжність сертифіката і витягує з нього відкритий ключ, яким шифрує ключ сеансу реєстрації. Після цього він включає цей ключ разом з білетом TGT до повідомлення KRB_AS_REP і направляє його клієнту. Розшифрувати сеансовий ключ зможе тільки той клієнт, у якого є секретна половина криптографічного пари, функції якої на цьому закінчуються. Вся подальша зв'язок між клієнтом і службою KDC підтримується на основі сеансового ключа. Ніяких інших відхилень від стандартного процесу реєстрації та входження в мережу не потрібно.

Про те, які типи смарт-карт і пристроїв їх читання підтримуються в середовищі Windows, можна дізнатися зі списку пристроїв, сумісних із цією операційною системою, «Windows Hardware Compatibility List».

Дані попередньої автентифікації

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

2.8.3Віддалена реєстрація

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

2.9Безпека

Інтерфейс постачальника підтримки безпеки

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

З деякою натяжкою можна сказати, що інтерфейс SSPI перетворює протокол автентифікації Kerberos в підтекст прикладного протоколу, організовуючи свого роду переговори всередині переговорів. На обох кінцях каналу зв'язку клієнта з сервером інтерфейс SSPI діє через постачальника підтримки безпеки, який володіє всіма кодами, необхідними для роботи конкретного протоколу автентифікації. SSP просто передає повідомлення автентифікації транспортному додатком. Для цього додатка, якщо не обумовлено іншого, передані дані залишаються невидимими. Воно не знає ні того, що міститься в повідомленні автентифікації, ні того, що відповідати при отриманні такого повідомлення. Функції та реагування на повідомлення автентифікації повністю покладено на SSP (рисунок 2.9).

Рисунок 2.9 - Протокол автентифікації як підтекст прикладного протоколу

Вибір постачальника підтримки безпеки

До складу Windows входить кілька постачальників підтримки безпеки, розроблених для проведення автентифікації по протоколах Kerberos, NTLM і SChannel. При зверненні до інтерфейсу SSPI додаток може вказати, який з постачальників йому потрібен, але передбачена й інша можливість: функція погодження, закладена в SSPI, дозволяє додатку вибрати з числа доступних той протокол, який забезпечить найвищу безпеку сеансу. Коли додаток запитує вхід в систему з погодженням, клієнт пропонує йому весь список наявних протоколів безпеки, починаючи з найбезпечніших. Сервер визначає, які з цих протоколів доступні йому, і вибирає з їх числа найбезпечніший. На системах Windows першим у списку завжди йде Kerberos, за ним слідує NTLM, а потім - SChannel. Якщо і клієнт, і сервер працюють під управлінням Windows, механізм узгодження завжди буде вибирати для автентифікації протокол Kerberos.

Приклад: відкриття файлу на приділення сервері

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

Щоб відкрити цей документ, Microsoft Word передає в операційну систему Windows, встановлену на робочій станції, запит вводу-виводу, для чого використовує виклик інтерфейсу прикладного програмування (API). Операційна система визначає, що документ належить до віддалених ресурсів, і передає запит редиректор файлової системи. Той, у свою чергу, за допомогою протоколу Server Message Block (SMB) зв'язується зі службою «Сервер» (Server) вилученого сервера файлів, відкриває файл і зчитує дані з нього. Всі ці дії виконуються поетапно, за допомогою послідовності повідомлень SMB. Перший - і єдиний, який нас цікавить, - етап полягає в організації автентифікованим з'єднання між редиректоров та віддаленої службою.

Процес узгодження з постачальником підтримки безпеки

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

Початок процесу автентифікації

Протокол автентифікації вступає в дію, коли редиректор робочої станції Олени звертається до SSPI і викликає метод AcquireCredentialsHandle, вказавши в якості абонента безпеки Олену. У відповідь він отримує описувач посвідчення, виданого Олені при її інтерактивної реєстрації на своїй робочій станції. Потім редиректор знову звертається до SSPI, але на цей раз викликає метод InitializeSecurityContext, за допомогою якого передає описувач до білета TGT Олени і вказує сервер, до якого потрібно підключитися, - у нашому випадку сервер файлів. У результаті такого виклику генерується повідомлення Kerberos KRB_TGS_REQ, що містить білет TGT Олени. Kerberos SSP направляє це повідомлення безпосередньо в службу KDC того домену, де зберігається облікова запис Олени, і отримує від неї білет на доступ до відповідного серверу файлів. Потім Kerberos SSP кешує отриманий білет і знову звертається до процесу, від якого було отримано виклик, тобто, до редиректор. Тим самим він вказує, що процес автентифікації ще не завершений.

У продовження попереднього виклику редиректор знову викликає метод InitializeSecurityContext. На цей раз Kerberos SSP генерує повідомлення Kerberos KRB_AP_REQ, що містить білет, зашифрований з секретним ключем запитуваної сервера. Сюди ж включається автентифікатор, зашифрований за допомогою сеансового ключа, який отримали Олена і цей сервер. Потім Kerberos SSP повертає створене повідомлення редиректор. Той, у свою чергу, перетворює отримане повідомлення в маркер автентифікації і його в повідомлення SMB, яке посилає службі «Сервер».

Отримавши від редиректора повідомлення SMB, служба «Сервер» створює локальний контекст безпеки для нового клієнта. З цією метою вона звертається в SSPI, викликає метод AcceptSecurityContext і виставляє покажчик на маркер автентифікації. Kerberos SSP, що працює на сервері файлів, відкриває повідомлення KRB_AP_REQ, дістає білет і витягує з нього сеансовий ключ, за допомогою якої перевіряє автентифікатор Олени. Якщо перевірка пройшла успішно, Kerberos SSP видаляє з сеансового білета дані авторизації Олени і передає його в підсистему LSA сервера. Та, у свою чергу, генерує маркер доступу Олени і створює контекст безпеки для її роботи на даній системі. Зробивши все це, Kerberos SSP готує повідомлення KRB_AP_REP і повертає його разом з описувачем контексту безпеки Олени тому процесу, від якого надійшов первинний запит.

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

Взаємна автентифікація

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

Сценарії

Корпорація Microsoft перевірила сумісність своєї реалізації Kerberos з еталонним протоколом Массачусетського технологічного інституту при взаємодії з наступними системами.

Служба KDC операційних систем Windows. Реалізації протоколу Kerberos для інших середовищ забезпечують автентифікацію в центрах розподілу ключів доменів Windows. Автентифікація користувачів таких реалізацій, а також хост-комп'ютерів, на яких вони розгорнуті, вимагає застосування утиліти kinit та шифрування за стандартами DES-CBC-MD5 або DES-CBC-CRC.

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

Клієнт Windows і служба Kerberos для іншої операційної системи. Клієнтський додаток, запущене в середовищі Windows, може пройти автентифікацію в службі Kerberos для іншої операційної системи, якщо ця служба підтримує інтерфейс прикладного програмування GSS-API (Generic Security Service Application Program Interface - інтерфейс прикладного програмування для служби загальної безпеки), описаний у документі RFC 1964.

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

Клієнт Kerberos для іншої операційної системи та служба Windows. Клієнтські додатки, що використовують протокол Kerberos для інших операційних систем, можуть пройти автентифікацію в службах, які працюють у середовищі Windows. Для цього вони повинні підтримувати інтерфейс прикладного програмування GSS-API.

Довірчі відносини. Домени Windows можуть довіряти областям Kerberos в мережах, які працюють під управлінням інших операційних систем. Такі області при відповідній конфігурації також можуть довіряти доменів Windows. Однак подібні довірчі відносини не такі всеосяжні, як довіра між доменами Windows. Зокрема, користувач області Kerberos не може уявити даних авторизації, необхідних для управління доступом до служб на Windows. Щоб включити такі дані у білет користувача, необхідний механізм відображення облікових записів. Для ідентифікації користувачів Kerberos з довіреної області виробляється відображення декількох обраних облікових записів цього домену, результати якого зберігаються у властивості altSecurityID об'єкта облікового запису користувача. Управління відображеними обліковими записами може проводитися за допомогою консолі Active Directory Users and Computers.

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

Основними атаками на протоколи автентифікації є:

-самозванство (impersonation). Полягає в тому, що один користувач намагається видати себе за іншого;

-повторна передача (replay attack). Полягає у повторній передачі автентифікаційних даних яким-небудь користувачем;

-підміна сторони автентификационного обміну (interleaving at-tack). Зловмисник під час даної атаки бере участь у процесі автентификационного обміну між двома сторонами і має можливість модифікації трафіку який проходить через нього;

2.10Висновок до розділу 2

В даному розділі було розглянуто протокол Kerberos. Проаналізувавши дані ми дійшли висновку, що протокол Kerberos є ефективним і має ряд переваг перед іншими протоколами.

-Більш ефективна автентифікація на серверах;

-Взаємна автентифікація;

-Делегована автентифікація;

-Спрощене керування довірчими відносинами;

-Сумісність.

РОЗДІЛ 3 РЕАЛІЗАЦІЯ ПРОГРАМНОГО ПРОДУКТУ

Після розгляду всіх алгоритмів було вирішено для реалізації ПП використати алгоритм DES. Так як цей алгоритм надійний та простий в реалізації.

3.1Алгоритм DES і його модифікації

Американський стандарт криптографічного закриття даних DES (Data Encryption Standard), прийнятий в 1978 р., є типовим представником сімейства блокових шифрів і одним з найбільш поширених криптографічних стандартів на шифрування даних, що застосовуються в США [17]. Цей шифр допускає ефективну апаратну і програмну реалізацію, причому можливе досягнення швидкостей шифрування до декількох мегабайт за секунду.

Спочатку метод, який лежить в основі даного стандарту, був розроблений фірмою IBM для своїх цілей. Він був перевірений Агентством Національної Безпеки США, яке не виявило в ньому статистичних або математичних вад.

Стандарт DES використовується федеральними департаментами і агентствами для захисту всіх досить важливих даних у комп'ютерах. Його застосовують багато недержавних інститутів, в тому числі більшість банків і служб обігу грошей. Обумовлений у стандарті алгоритм криптографічного захисту даних опублікований для того, щоб більшість користувачів могли використовувати перевірений алгоритм з хорошою криптостійкістю. Однак, з одного боку, публікація алгоритму небажана, оскільки може призвести до спроб дешифрування закритої інформації, але, з іншого боку, це не настільки суттєво оскільки стандартний алгоритм шифрування даних повинен володіти такими характеристиками, щоб його опублікування не позначилося на його криптостійкості.має блоки по 64 біт і заснований на 16-кратній перестановці даних, також для шифрування використовує ключ в 56 біт. Існує декілька режимів DES:

-Electronic Code Book (ECB);

-Cipher Block Chaining (CBC).

56 біт - це 8 семибітових ASCII символів, тобто пароль не може бути більше ніж 8 букв. Якщо додатково використовувати тільки букви і цифри, то кількість можливих варіантів буде істотно менше максимально можливих 256

Шифр DES представляє собою результат 33 відображень:

де IP (Initial Permutation - вихідна перестановка) являє собою дротяну комутацію з інверсією IP-1:

, 50, 42, 34, 26, 18, 10, 2, 60, 52, 44, 36, 28, 20, 12, 4,

, 54, 46, 38, 30, 22, 14, 6, 64, 56, 48, 40, 32, 24, 16, 8,

, 49, 41, 33, 25, 17, 9, 1, 59, 51, 43, 35, 27, 19, 11, 3,

, 53, 45, 37, 29, 21, 13, 5, 63, 55, 47, 39, 31, 23, 15, 7,

Композиція , де ? - перестановка місцями правої і лівої половин блоку даних, представляє собою одну ітерацію Фейстеля. В останньому циклі шифрування за алгоритмом DES перестановка місцями половин блоку не проводиться. Підстановки , 1 < < 16, описується так

Крок 1. На -му циклі вхідний блок довжиною 64 символи ділиться на два блоки по 32 символи: та .

Правий блок розбивається на вісім блоків по чотири символи (таблиця 3.1).

Таблиця 3.1

Рисунок 3.1 - Схема перестановки

Ці вісім блоків шляхом копіювання крайніх елементів перетворюються у вісім блоків з шести символів (таблиця 3.2):

Таблиця 3.2

Крок 2. На - циклічній ітерації 48 розрядів ключа

порозрядно підсумовуються (за модулем 2) з отриманими вище 48 розрядами даних.

Крок 3. -й блок з шести символів (0 < <8) подається на вхід блоку підстановки (S-бокс) , який має шести розрядний вхід і чотири розрядний вихід і являє собою чотири перетворення з у ; два крайні розряди вхідного блоку служать для вибірки одного з цих перетворень. Кожна з восьми підстановок здійснюється з використанням чотирьох рядків і шістнадцяти стовпців матриці з елементами . Кожен з масивів розмірністю визначає підстановку на множені наступним чином. Якщо входом є блок з шести символів , то дві крайні позиції інтерпретуються як двійкове подання цілих чисел з набору . Ці цілі визначають номер рядка (від 0 до 3). Решта чотири символи інтерпретуються як двійкове представлення цілих чисел з набору і служать для визначення стовпця в масиві (від 0 до 15). Таким чином, вхідний блок відповідає рядку 1 і стовпцю 5.

Крок 4. 32 розряди, які складають вихід S-боксу, подаються на вхід блоку дротяної комутації (Р-боксу):

, 7, 20, 21, 29, 12, 28, 17, 1, 15, 23, 26, 5, 18, 31, 10,

, 8, 24, 14, 32, 27, 3, 9, 19, 13, 30, 6, 22, 11, 4, 25

Крок 5. Компоненти правого вхідного 32-розрядного блоку, перетвореного в , порозрядно додаються по модулю 2 з компонентами лівого вхідного 32-розрядного блоку .

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

Які саме розряди ключа використовуються на - циклічної ітерації, визначається за наступним алгоритмом:

-спочатку 64 розряди ключа перетворюються в 56 шляхом викидання кожного восьмого біта;

-виробляється початкова перестановка КР-1 56 - розрядного ключа користувача :

, 49, 41, 33, 25, 17, 9, 1, 58, 50, 42, 34, 26, 18,

, 2, 59, 51, 43, 35, 27, 19, 11, 3, 60, 52, 44, 36,

, 55, 47, 39, 31, 23, 15, 7, 62, 54, 46, 38, 30, 22

, 6, 61, 53, 45, 37, 29, 21, 13, 5, 28, 20, 12, 4.

Отриманий в результаті 56-розрядний блок розглядається як два 28-розрядні блоки: лівий - і правий - ;

-виробляється лівий циклічний зсув блоків і раз для отримання блоків і ;

-з зчеплення блоків ( і ) вибираються 48 розрядів за допомогою перестановки КР-2. Ці розряди використовуються на першій ітерації;

, 17, 11, 24, 1, 5, 3, 28, 15, 6, 21, 10,

, 19, 12, 4, 26, 8, 16, 7, 27, 20, 13, 2,

, 52, 31, 37, 47, 55, 30, 40, 51, 45, 33, 48,

, 49, 39, 56, 34, 53, 46, 42, 50, 36, 29, 32.

Використані на -й циклічнії ітерації розряди ключа визначаються методом індукції. Для отримання блоків і проводимо лівий циклічний зсув блоків і на позицій (таблиця 3.3):

Таблиця 3.3

123456789101112131415161122222212222221

Для отримання чергового ключа використовуємо КР-2.

Інверсією DES (що забезпечує розшифрування зашифрованих за допомогою DES даних) є:

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

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

За час, що минув після створення DES, комп'ютерна техніка розвинулася настільки швидко, що виявилося можливим здійснювати вичерпний перебір ключів і тим самим розкривати шифр. Вартість цієї атаки постійно знижується. У 1998 р. була побудована машина вартістю близько 100 000 доларів, здатна по даній парі < вихідний текст, шифрований текст > відновити ключ за середній час на три доби.

3.2Програмний продукт

ПП було написано на мові програмування Delphi 7.

Після запуску програми зявляється головне вікно програми (рисунок 3.1).

Рисунок 3.1 - Головне вікно програми

В полі повідомлення пишемо повідомлення яке ми будемо шифрувати (рисунок 3.2).

Рисунок 3.2 - Поле для вводу повідомлення

Після цього визначаємо пароль який відомий нам та нашому співрозмовнику (рисунок 3.3) і натискаємо кнопку зашифрувати (рисунок 3.4).

Рисунок 3.3 - Поле пароль

Рисунок 3.4 - Шифрування файлу

Зашифроване повідомлення зявиться в нижній частині головного вікна (рисунок 3.5).

Рисунок 3.5 - Зашифроване повідомлення

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

Рисунок 3.6 - Поле імя файлу

Рисунок 3.7 - Кнопка зберегти

Після збереження файлу зявиться повідомлення (рисунок 3.8)

Рисунок 3.8 - Інформаційне повідомлення

Після передачі файлу інший користувач вводить пароль, вибирає імя файлу і натискає кнопку відкрити файл (рисунок 3.9) і натиснути кнопку розшифрувати (рисунок 3.10).

Рисунок 3.9 - Кнопка відкрити файл

Рисунок 3.10 - Кнопка розшифрувати

Висновок до розділу 3

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

ВИСНОВОК

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

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1.Бабаш А.В., Шанкин Г.П. История криптографии. Часть I. - М.: Гелиос АРВ, 2002. - 240 с. - 3000 экз. - ISBN 5-85438-043-9

2.Баричев С.Г., Гончаров В.В., Серов Р.Е. Основы современной криптографии. - М.: Горячая линия - Телеком, 2002. - 175 с. - (Специальность. Для высших учебных заведений). - 3000 экз. - ISBN 5-93517-075-2

.Герасименко В.А. Защита информации в автоматизированных системах обработки данных., кн. 1, 2. М.: Энергоатомиздат, 1994.

.Жельников В. Кpиптогpафия от папиpуса до компьютеpа. - М.: ABF, 1996. - 335 с. - ISBN 5-87484-054-0

.Основы криптозащиты АСУ. Под ред. Б. П. Козлова. М.: МО, 1996.

.Конхейм А.Г. Основы криптографии. М.: Радио и связь, 1987.

.Венбо Мао Современная криптография. Теория и практика = Modern Cryptography: Theory and Practice. - М.: Вильямс, 2005. - 768 с. - 2 000 экз. - ISBN 5-8459-0847-7, ISBN 0-13-066943-1

.Мафтик С. Механизмы защиты в сетях ЭВМ. М.: Мир, 1993.

.Мельников В. В. Защита информации в компьютерных системах. М.: Финансы и статистика, 1997.

.Молдовян А.А., Молдовян Н.А., Советов Б.Я. Криптография. СПб.: «Лань», 2000.

.Нечаев В.И. Элементы криптографии (Основы теории защиты информации). М.: Высшая школа, 1999.

.Романец Ю.В., Тимофеев П.А., Шаньгин В.Ф. Защита информации в компьютерных системах и сетях. М.: Радио и связь, 1999.

.Рябко Б.Я., Фионов А.Н. Основы современной криптографии для специалистов в информационных технологиях. М.: Научный мир, 2004. ISBN 5-89176-233-1.

.Вильям Столлингс. Криптография и защита сетей: принципы и практика. М.: Вильямс, 2001. ISBN 5-8459-0185-5.

.Ухлинов А.М. Управление безопасностью информации в автоматизированных системах. М.: МИФИ, 1996.

.Нильс Фергюсон, Брюс Шнайер Практическая криптография = Practical Cryptography: Designing and Implementing Secure Cryptographic Systems. - М.: «Диалектика», 2004. - 432 с. - 3 000 экз. - ISBN 5-8459-0733-0, ISBN 0-4712-2357-3

.Шнайер Б. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си = Applied Cryptography. Protocols, Algorithms and Source Code in C. - М.: Триумф, 2002. - 816 с. - 3000 экз. - ISBN 5-89392-055-4

.Ященко В.В. Введение в криптографию. СПб.: Питер, 2001. ISBN 5-318-00443-1.

ДОДАТОК Б

КОД ПРОГРАМИ

Unit1;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, DES, StdCtrls;= class(TForm): TLabel;: TEdit;: TLabel;: TMemo;: TButton;: TLabel;: TMemo;: TButton;: TMemo;: TLabel;: TMemo;Button1Click(Sender: TObject);Button2Click(Sender: TObject);Memo1Change(Sender: TObject);FormCreate(Sender: TObject);Edit1Change(Sender: TObject);Memo2Change(Sender: TObject);

{ Private declarations }:TBitString;;: TForm1;

{$R *.dfm}TForm1.Button1Click(Sender: TObject);:Integer;:String;((Length(Memo1.Text)mod 8 <> 0) OR (Length(Edit1.Text)mod 8 <> 0)) (Handle,

'Количество букв в сообщении должно быть кратоно 8 (перевод строки

считается за 2 буквы)'+

#10#13'Ключ должен состоять из 8 символов',,MB_ICONSTOP);;;(Data,0);:=1;I<=Length(Memo1.Text) Do:=Copy(Memo1.Text,I,8);:=ConcatBits([Data,DESEncode(S,Edit1.Text)]);:=I+8;;.Text:=BinToAnsiStr(Data);;TForm1.Button2Click(Sender: TObject);:Integer;((Length(Memo2.Text)mod 8 <> 0) OR (Length(Edit1.Text)mod 8 <> 0)) (Handle,

'Количество букв в сообщении должно быть кратоно 8 (перевод строки

считается за 2 буквы)'+

#10#13'Ключ должен состоять из 8 символов',,MB_ICONSTOP);;;(Data,0);:=1;I<=Length(Memo2.Text) Do:=ConcatBits([Data,DESDecode(Copy(Memo2.Text,I,8),Edit1.Text)]);:=I+8;;.Text:=BinToAnsiStr(Data);;TForm1.Memo1Change(Sender: TObject);Memo1.Text<>'' Then.Text:=BinToStr(AnsiStrToBin(Memo1.Text))Memo3.Clear;.Caption:='Message - ('+IntToStr(Length(Memo1.Text))+' )';;TForm1.FormCreate(Sender: TObject);.OnChange(Self);.OnChange(Self);;TForm1.Edit1Change(Sender: TObject);.Caption:=IntToStr(Length(Edit1.Text))+' characters';;TForm1.Memo2Change(Sender: TObject);Memo2.Text<>'' Then.Text:=BinToStr(AnsiStrToBin(Memo2.Text))Memo4.Clear;.Caption:='Encoded message - ('+IntToStr(Length(Memo2.Text))+' )';;.

Національна академія управління Кафедра інтелектуальних систем Факультет економіки та інформаційних технологій Напрям підготовки 0804 - Компютерні наук

Больше работ по теме: