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

Коли клієнт надсилає запит на підключення та представляє свій сеансовий білет, служба викликає метод 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 домену «Захід».

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

Рисунок 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).

MSGINA викликає метод LsaLogonUser і з його допомогою пересилає реєстраційні дані користувача в підсистему LSA точно так само, як і при парольного реєстрації. Ця підсистема використовує PIN користувача для доступу до смарт-картки, де зберігаються секретний ключ користувача і сертифікат Х.509 v3, що містить відкритий ключ пари. Надалі всі криптографічні операції з використанням даної пари будуть проводитися через смарт-карту.

Kerberos 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).

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

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

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

- Electronic Code Book (ECB);

- Cipher Block Chaining (CBC).

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

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

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

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

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

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

61, 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-боксу, подаються на вхід блоку дротяної комутації (Р-боксу):

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

2, 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 - розрядного ключа користувача :

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

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

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

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

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

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

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

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

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

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

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

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

Таблиця 3.3

	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16
	1	1	2	2	2	2	2	2	1	2	2	2	2	2	2	1

Для отримання чергового ключа використовуємо КР-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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



ДОДАТОК Б

КОД ПРОГРАМИ

unit Unit1;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, DES, StdCtrls;

type

TForm1 = class(TForm)

Label1: TLabel;

Edit1: TEdit;

Label2: TLabel;

Memo1: TMemo;

Button1: TButton;

Label3: TLabel;

Memo2: TMemo;

Button2: TButton;

Memo3: TMemo;

Label4: TLabel;

Memo4: TMemo;

procedure Button1Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

procedure Memo1Change(Sender: TObject);

procedure FormCreate(Sender: TObject);

procedure Edit1Change(Sender: TObject);

procedure Memo2Change(Sender: TObject);

private

{ Private declarations }

public

Data:TBitString;

end;

var

Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);

Var

I:Integer;

S:String;

begin

IF ((Length(Memo1.Text)mod 8 <> 0) OR (Length(Edit1.Text)mod 8 <> 0))

Then

Begin

MessageBox(Handle,

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

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

#10#13'Ключ должен состоять из 8 символов',

Nil,MB_ICONSTOP);

Exit;

End;

SetLength(Data,0);

I:=1;

While I<=Length(Memo1.Text) Do

Begin

S:=Copy(Memo1.Text,I,8);

Data:=ConcatBits([Data,DESEncode(S,Edit1.Text)]);

I:=I+8;

End;

Memo2.Text:=BinToAnsiStr(Data);

end;

procedure TForm1.Button2Click(Sender: TObject);

var

I:Integer;

begin

IF ((Length(Memo2.Text)mod 8 <> 0) OR (Length(Edit1.Text)mod 8 <> 0))

Then

Begin

MessageBox(Handle,

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

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

#10#13'Ключ должен состоять из 8 символов',

Nil,MB_ICONSTOP);

Exit;

End;

SetLength(Data,0);

I:=1;

While I<=Length(Memo2.Text) Do

Begin

Data:=ConcatBits([Data,DESDecode(Copy(Memo2.Text,I,8),Edit1.Text)]);

I:=I+8;

End;

Memo1.Text:=BinToAnsiStr(Data);

end;

procedure TForm1.Memo1Change(Sender: TObject);

begin

IF Memo1.Text<>'' Then

Memo3.Text:=BinToStr(AnsiStrToBin(Memo1.Text))

Else Memo3.Clear;

Label2.Caption:='Message - ('+IntToStr(Length(Memo1.Text))+'

characters)';

end;

procedure TForm1.FormCreate(Sender: TObject);

begin

Memo1.OnChange(Self);

Edit1.OnChange(Self);

end;

procedure TForm1.Edit1Change(Sender: TObject);

begin

Label4.Caption:=IntToStr(Length(Edit1.Text))+' characters';

end;

procedure TForm1.Memo2Change(Sender: TObject);

begin

IF Memo2.Text<>'' Then

Memo4.Text:=BinToStr(AnsiStrToBin(Memo2.Text))

Else Memo4.Clear;

Label3.Caption:='Encoded message - ('+IntToStr(Length(Memo2.Text))+'

characters)';

end;

end.

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