Автор работы: Пользователь скрыл имя, 06 Июня 2013 в 23:25, дипломная работа
ПОСТАНОВКА ЗАДАЧІ ТА ОГЛЯД ІСНУЮЧИХ МЕТОДІВ РОЗВ’ЯЗКУ ЦІЄЇ ЗАДАЧІ
1.Виконати аналіз протоколу Kerberos.
2.Зробити огляд існуючих алгоритмів криптографічних систем.
3.Розробити програмний продукт на базі протоколу Kerberos.
ПЕРЕЛІК ПРИЙНЯТИХ СКОРОЧЕНЬ 8
ВСТУП 9
ПОСТАНОВКА ЗАДАЧІ ТА ОГЛЯД ІСНУЮЧИХ МЕТОДІВ РОЗВ’ЯЗКУ ЦІЄЇ ЗАДАЧІ 10
РОЗДІЛ 1. КРИПТОГРАФІЯ 11
1.1Криптографічні системи 11
1.2Симетричні криптографічні системи 13
1.2.1Алгоитм AES 15
1.2.2Алгоритм ГОСТ 28147-89 16
1.2.3Алгоритм 3DES 17
1.2.4Алгоритм RC6 17
1.2.5Алгоритм IDEA 18
1.2.6Алгоритм SEED 20
1.2.7Алгоритм Camellia 21
1.2.8Алгоритм XTEA 22
1.3Асимеричні криптографічні системи 23
1.3.1Алгоритм RSA 25
1.3.2Алгоритм DSA 25
1.3.3Алгоритм Elgamal 26
1.3.4Алгоритм Rabin 27
1.3.5Алгоритм McEliece 27
1.4Висновок до розділу 1 27
РОЗДІЛ 2. АВТЕНТИФІКАЦІЯ ПО ПРОТОКОЛУ KERBEROS 29
2.1Стандарти автентифікації по протоколу Kerberos 29
2.2Основна концепція 30
2.3Переваги автентифікації по протоколу Kerberos 31
2.4Робота протоколу 32
2.4.1Автентифікатори 32
2.4.2Управління ключами 35
2.4.3Сеансові білети 38
2.4.4Білети на видачу білетів 40
2.4.5Автентифікація за межами домену 42
2.5Підпротоколи 44
2.5.1Підпротокол AS Exchange 45
2.5.2Підпротокол TGS Exchange 46
2.5.3Підпротокол CS Exchange 47
2.6Білети 49
2.6.1Дані з білета відомі клієнту 51
2.6.2Що відбувається після закінчення терміну дії білета 52
2.6.3Оновлюванні білети TGT 52
2.6.4Делегування автентифікації 54
2.6.5Представницькі білети 54
2.6.6Передані білети 55
2.6.7Центр розподілу ключів KDC 55
2.6.8База даних облікових записів 57
2.7Політика Kerberos 59
2.8Процес реєстрації 70
2.8.1Вхід в систему за паролем 71
2.8.2Вхід в систему за допомогою смарт-карти 75
2.8.3Віддалена реєстрація 77
2.9Безпека 77
2.10Атаки на протоколи автентифікації 83
2.10Висновок до розділу 2 84
РОЗДІЛ 3 РЕАЛІЗАЦІЯ ПРОГРАМНОГО ПРОДУКТУ 85
3.1Алгоритм DES і його модифікації 85
3.2Програмний продукт 92
3.3Висновок до розділу 3 97
ВИСНОВОК 97
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 98
ДОДАТОК А. ІЛЮСТРАТИВНІ МАТЕРІАЛИ ДЛЯ ДОПОВІДІ 100
ДОДАТОК Б. КОД ПРОГРАМИ 107
Всі екземпляри служби KDC одного домену використовують єдиний обліковий запис абонента безпеки з ім'ям krbtgt. При зверненні до центру розподілу ключів домену клієнт повинен вказати як ім'я абонента безпеки krbtgt, так і ім'я домену. Ці відомості наводяться і у білетах, де ідентифікують службу, що видала даний білет.
База даних, яка необхідна службі 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 прийняті заходи
і проти можливого злому
У середовищі Windows політика Kerberos визначається на рівні домену та реалізується службою KDC домену. Вона зберігається в каталозі Active Directory як підмножина атрибутів політики безпеки домену. За замовчуванням вносити зміни в політику Kerberos мають право тільки члени групи адміністраторів домену.
У політиці Kerberos передбачаються:
Информация о работе Система автентифікації в інформаційній системі на базі протоколу Kerberos