1. мета лекції
2. текст лекції
3. SPNEGO
4. NTLM
5. Kerberos
6. короткі підсумки

Анотація: У даній лекції розглядаються протоколи аутентифікації, що використовуються в ОС Windows

мета лекції

В рамках лекції розглядаються протоколи аутентифікації:

текст лекції

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

SPNEGO

SPNEGO (скор. Від Simple and Protected GSS-API Negotiation Mechanism - простий і захищений механізм переговорів по GSS-API) - механізм, який використовується для аутентифікації клієнтського додатка на віддаленому сервері в тому випадку, коли жодна зі сторін не знає, який протокол аутентифікації підтримує інша сторона.

GSS-API (Generic Security Service Application Program Interface - Узагальнений прикладний програмний інтерфейс служби безпеки) [ 14.1 ] Призначений для захисту комунікацій між компонентами програмних систем, побудованих в архітектурі клієнт / сервер. Він надає послуги по взаємної аутентифікації здійснюють контакт партнерів і по контролю цілісності і забезпечення конфіденційності пересилаються.

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

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

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

SPNEGO - стандартний псевдо-механізм GSS-API. Псевдо-механізм визначає, які механізми GSS-API є доступними, вибирає один з них і передає йому "право" здійснювати в подальшому необхідні операції по забезпеченню безпечного взаємодії додатків.

Найбільш відомим застосуванням SPNEGO є розширення Microsoft "HTTP Negotiate". Вперше SPNEGO був реалізований в Internet Explorer 5.01 і IIS 5.0 з метою реалізації можливості SSO (Single Sign -On, "єдиний вхід", "принцип одноразової реєстрації"), пізніше перейменованої в Integrated Windows Authentication. SPNEGO міг вибирати між протоколами Kerberos і NTLM. Пізніше Firefox і Konqueror також стали підтримувати SPNEGO.

NTLM

Коли Microsoft почала роботу над створенням централізованих мереж масштабів підприємства при роботі над операційною системою Windows NT, перед розробниками була поставлена ​​дуже складна і нова на той час завдання - реалізувати технології SSO і "One user - one password". "One user - one password" - "один користувач - один пароль" означає, що у користувача повинен бути єдиний пароль, який використовується для доступу до всіх ресурсів і протоколам мережі. Дієві заходи захисту не повинні ускладнювати роботу користувачів. Наприклад, їх слід звільнити від необхідності окремо реєструватися на кожному ресурсі, використовуючи при цьому різні паролі. Крім того, процес реєстрації не повинен супроводжуватися тривалими затримками при отриманні доступу. Single sign -on, як зазначалося вище, має на увазі, що цей пароль вказується всього один раз - при вході користувача в мережу).

Необхідно було розробити таку схему аутентифікації, яка дозволила б будь-якого мережевого додатком передавати дані аутентифікації незалежно від мережевого протоколу. Це призвело до появи NTLM і NTLMSSP (NTLM Security Service Provider - підсистеми, що дозволяє будь-якому клієнт серверного додатку використовувати NTLM, нічого не знаючи про його внутрішню структуру). Протокол NTLM відноситься до сімейства challenge -response (запит-відповідь) протоколів. Це означає, що ні пароль, ні його хеш ніколи не передаються "як є": вони використовуються для генерації відповіді (response) на випадковий запит (challenge). Аутентифицирующей сторона порівнює отриману відповідь з обчисленим локально. Генерація та перевірка запиту і відповіді здійснюється не додатками, а провайдером NTLMSSP.

Протокол NTLM має багато прогалин в безпеці. Частина проблем викликана тим, що Microsoft необхідно було зберегти сумісність з існуючими мережами LanManager для MS-DOS і Windows for Workgroups. Інші є помилками проектування, треті - виключно криптографічні.

В даний час Microsoft рекомендує в якості протоколу аутентифікації використовувати Kerberos (див. Наступну главу). Проте, в нових версіях Windows він підтримується і все ще використовується, наприклад, на рівні робочих груп (при відсутності домену Active Directory).

Kerberos

Kerberos - протокол аутентифікації, розроблений в 1980-х рр. в Массачусетському технологічному інституті (MIT - Massachusetts Institute of Technology). Першою операційною системою сімейства Windows, що реалізує протокол Kerberos [ 14.2 ], Стала Windows 2000. Мережева служба Kerberos діє як довірена посередник, забезпечуючи безпечну мережеву перевірку справжності, яка дає користувачеві можливість працювати на декількох машинах мережі.

Kerberos використовує криптографію з секретним ключем: як правило, застосовуються шифри DES або Triple-DES (3DES), хоча в останній версії, Kerberos v5, описаної в документі RFC 1510 [ 14.4 ], Підтримуються і інші алгоритми: так, Windows Vista була випущена з покращеною версією протоколу Kerberos, що дозволяє використовувати криптоалгоритм AES.

Kerberos версії 5 використовує режим СВС (Cipher Block Chaining). CBC [ 14.3 ] - це режим шифрування зі зворотним зв'язком, при якому перед обчисленням чергового шифрованого блоку відкритий текст складається побитно по модулю 2 з попереднім шифртекст. У режимі СВС над відкритим текстом і попереднім шифртекст виконується операція XOR і тим самим кожен попередній шіфрблок використовується для модифікування чергового блоку відкритого тексту.

Для аутентифікації в службі Kerberos використовуються посвідчення. Розрізняють два види посвідчень (credentials): мандати (tickets) і аутентифікатор (authenticators). Детально структура різних повідомлень Kerberos описана в документі RFC 1510 [ 14.2 ], Ми обмежимося основною інформацією.

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

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

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

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

Схема роботи протоколу Kerberos представлена ​​на Мал. 14.1 [ 14.3 ]. Виділяється 3 основні стадії:

• Клієнт запитує у сервера аутентифікації мандат на звернення до Сервера видачі мандатів (Ticket- Granting Server, TGS). У ролі сервера аутентифікації виступає центр розподілу ключів (KDC, Key Distribution Center). KDC направляє клієнту мандат, що містить унікального сеансового ключа (session key) для майбутнього сеансу. Копія сеансового ключа, що пересилається на сервер, шифрується за допомогою довгострокового ключа цього сервера (кроки 1-2);
• Для підключення до конкретного сервера клієнт запитує у TGS мандат на звернення до сервера. У ролі TGS також виступає KDC. Якщо все в порядку, KDC відсилає мандат клієнту (кроки 3-4);
• Клієнт пред'являє сервера отриманий мандат разом з аутентифікатором. Якщо посвідчення клієнта правильно, сервер надає клієнту доступ до служби (кроки 5-6 *).

Схема роботи протоколу Kerberos

1. Запит мандата на виділення мандата сервера
2. Мандат на виділення мандата сервера
3. Запит мандата сервера
4. мандат сервера
5. запит послуги
6. Мітка часу, зашифрована сеансовим ключем *

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

короткі підсумки

Були розглянуті протоколи аутентифікації, що використовуються в ОС Windows: SPNEGO, NTLM, Kerberos. Описано принципи роботи і області застосування протоколів. Особливу увагу приділено використовуваним криптографічним механізмам.