Реферат: Аналіз актуальних проблем захисту користувачів у загальних мережах
На рис.1 показана структура ЕАР кадра. Протокол РРР засвітився там тому, що ізначально ЕАР планувався до використання поверх РРР тунелей. Але так як використання цього протоколу тільки для аутентифікації по локальній мережі – зайва збитковість, ЕАР – повідомлення упаковуються в „ЕАР overLAN” (EAPOL) пакети, які і використовуються для обміну інформацією між клієнтом і аутентифікатором ( точкою доступу ).
Рис.1 структура ЕАР кадра
Рис.2. 802.1 в дії
4. Варіант застосування аутентифікації в безпроводових комп”ютерних мережах
Схема аутентифікації складається з трьох компонентів:
- Supplicant– софт, запущений на клієнтській машині, який намагається підключитись до мережі;
- Autentificator – вузол доступу, аутентифікатор ( безпроводова точка доступу чи провідний комутатор з підтримкою протоколу 802.1х );
- AutentificationServer – сервер аутентифікації ( звичайно це RADIUS – сервер ).
Розглянемо сам процес аутентифікації. Він складається з наступних стадій:
1. Клієнт може відправити запит на аутентифікацію ( EAP-startmessage) в напрямку точки доступу.
2. Точка доступу ( аутентифікатор ) у відповідь посилає клієнту запит на ідентифікацію клієнта ( EAP-request/identitymessage ). Аутентифікатор може відіслати EAP-request самостійно, якщо побачить, що який-небудь з його портів перейшов в активний стан.
3. Клієнт у відповідь посилає EAP-responsepacket з необхідними даними, які точка доступу ( аутентифікатор ) перенаправляє в бік RADIUS – сервера ( сервера аутентифікації ).
4. Сервер аутентифікації посилає аутентифікатору challenge-пакет (запит інформації про справжність клієнта ). Аутентифікатор пересилає його клієнту.
5. Далі здійснюється процес взаємної ідентифікації сервера і клієнта. Кількість стадій пересилки пакетів туди-сюди варіює в залежності від метода ЕАР, але для безпроводових мереж підходить лише “strong” аутентифікація зі взаємною аутентифікацією клієнта і сервера ( EAP-TLS, EAP-TTLS, EAP-PEAP ) і попереднім шифруванням каналу зв”язку.
6. На наступній стадії, сервер аутентифікації, отримавши від клієнта необхідну інформацію, дозволяє ( accept ) чи забороняє ( reject ) тому доступ, з пересилкою даного повідомлення аутентифікатору. Аутентифікатор відкриває порт для Supplicant-a, якщо зі сторони RADIUS – сервера прийшла позитивна відповідь ( accept ).
7. Порт відкривається, аутентифікатор пересилає клієнту повідомлення про успішне завершення процесу і клієнт отримує доступ в мережу.
8. Після відключення клієнта, порт на точці доступа знову переходить у стан „закрито”.
Описаний процес проілюстровано на рис.3 ( один з найпростіших методів ЕАР ):
Рис.3. Процес аутентифікації
Як видно з рисунка, для комунікації між клієнтом ( supplicant ) і точкою доступу ( autentificator ) використовуються пакети EAPOL. Протокол RADIUS використовується для обміну інформацією між точкою доступу і RADIUS-сервером. При транзитній пересилці інформації між клієнтом і сервером аутентифікації пакети ЕАР переупаковуються з одного формата в інший на аутентифікаторі.
Першочергова аутентифікація здійснюється на основі загальних даних, про які знають і клієнт, і сервер аутентифікації ( логін-пароль, сертифікат тощо ) – на цьому етапі генерується MasterKey. Використовуючи MasterKey, сервер аутентифікації і клієнт генерують парний майстер-ключ ( PairwiseMasterKey ), який передається аутентифікатору зі сторони сервера аутентифікації. А вже на основі PairwiseMasterKey і генеруються всі інші динамічні ключі, яким і закривається передаваємий трафік. Необхідно відмітити, що сам PairwiseMasterKey теж динамічно змінюється.
Кілька слів про цифрові сертифікати, а точніше про РКІ.
PublicKeyInfrastructure ( PKI ) – інфраструктура відкритих ключів. РКІ забезпечує створення цифрових сертифікатів (по заздалегідь заданим правилам), управління ними, видача їх суб”єктам і відклик (анулювання). Крім того, РКІ забезпечує можливість перевірки валідності сертифікатів. Інфраструктура базується на криптографії з відкритим ключем. А вона, в свою чергу, дає можливість, маючи на руках пари ключів ( відкритий і особистий ), шифрувати інформацію одним з цих ключів так, щоб розшифрувати її можна було тільки іншим ключем.
Наприклад, зашифрувавши інформацію особистим ключем ( який є тільки у власника і нікому не передається ), її можна розшифрувати відкритим, загальнодоступним ключем ( це називається асиметричним шифруванням ). Тим самим засвідчується, що інформація прийшла саме до власника закритого ключа і ні від кого іншого. І навпаки, можна зашифрувати інформацію відкритим ключем власника і відіслати її отримувачу. Навіть якщо хтось по дорозі перехопить повідомлення, він не зможе його прочитати, так як не володіє особистим ключем отримувача.
Для посвідчення особи власника відкритого ключа використовують цифрові сертифікати, що тягнуть за собою всю інфраструктуру РКІ. Сертифікати складають певну інформацію, що дозволяє однозначно засвідчити особу власника ( точніше, підтвердження особи власника приходить від третьої сторони ).
Кожен суб”єкт РКІ ( будь-то звичайний користувач, веб-сервер, інший сервер чи мережений пристрій ) має особистий сертифікат ( чи кілька ), в якому міститься інформація, по якій його можна однозначно ідентифікувати і відкритий ключ власника.
Над усим цим стоїть сертифікаційний центр, CertificateAutority ( CA ), який підписує сертифікати суб”єктів, а також підтверджує валідність виданих сертифікатів тобто посвідчення особи власника. СА довіряють усі суб”єсти РКІ, тому корневий сертифікат (сертифікат CA ) має бути у списку довіри всіх суб”єстів РКІ.