Топалов

MD5 і SHA (варіант НМАС). Алгоритми гешування, використовуються для автентифікації пакетів даних у процесі обміну IKE;

підписи RSA і шифровані оказії. Підписи RSA забезпечують неможливість створення помилкової інформації, а шифровані оказії RSA (випадкові числа, використовувані в алгоритмах шифрування) гарантують виявлення помилкової інформації. Вони використовуються в рамках IKE для автентифікації сторін;

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

У рамках IKE узгоджуються параметри SA як для IKE, так і для IPSec і відповідних процесів формують дві фази, для яких допускаються різні режими.

Уході першої фази IKE ведуться переговори про параметри SA IKE. У ході другої фази IKE ведуться переговори про параметри SA IPSec.

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

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

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

81

яка сторона, що бере участь в обміні, має можливість згодом заперечувати свою долю в обміні;

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

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

ААА).

Двохфакторна автентифікація і схеми виклик/відповідь типу

RADIUS(Remote Authentication Dial-In User Service - служба віддаленої автен-

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

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

Параметри XAuth узгоджуються між першою і другою фазами IKE одночасно з виконанням процедури mode config. Автентифікація виконується за допомогою доступної системи автентифікації, наприклад, RADIUS. Можливість XAuth активізується за допомогою команди crypto mар.

Конфігурація режиму IKE (mode config) є властивістю IPSec, що дозволяє шлюзу завантажити IP-адреси (інші параметри конфігурації мережного рівня) для клієнта в рамках переговорної процедури IKE. При цьому шлюз надає IPадреси клієнтові IPSec багато в чому подібно до того, як сервер DHCP (Dynamic Host Configuration Protocol – протокол динамічної конфігурації хоста) привласнює IP-адреси віддаленому клієнтові. Адреса, що надається процедурою конфігурації режиму, називається внутрішньою IP-адресою і використовується в заголовках пакетів (TCP (Transmission Control Protocol – протокол управління передачею) або UDP (User Datagram Protocol – протокол призначених для користувача датаграм)) до шифрування. Наступні кроки описують процедуру привласнення IP-адреси клієнтові IPSec у вказаному режимі (рис. 6.3):

1. віддалений користувач з'єднується з мережею свого постачальника послуг Internet (ISP). Адаптер віддаленого доступу (або мережна інтерфейсна

82

карта) привласнює IP-адресу за допомогою засобів DHCP постачальника послуг

Internet (на рис. 6.3 це адреси 172.16.2.121);

2.клієнт IPSec визначає трафік для шифрування і починає першу фазу обміну IKE зі шлюзом IPSec;

3.шлюз IPSec використовує режим mode config, аби привласнити внутрішню адресу IP10.1.1.82 з пулу IP-адреса для клієнтів. Внутрішня адреса використовується для пакетів до початку шифрування;

4.клієнт IPSec шифрує пакет за допомогою ESP. У заголовку ESP використовується адреса джерела 172.16.2.121. Адресатом пакета ESP є хост 172.16.1.2, шлюз IPSec або кінцева точка тунелю;

5.шлюз IPSec отримує пакет, дешифрує його і використовує внутрішню адресу для заголовка IP дешифрованого пакета. Дешифрований пакет прямує в корпоративну мережу сервера додатків 10.1.1.100.

	Віддалений	Сервер
	клієнт
		доступу	Шлюз
	IPSec
		ISP	IPSec

Корпоративна

мережа

			Пакет ESP
IP-адреса мережного					IP-адреса
			172.16.2.121
адаптера
			172.16.1.2		шлюза IPSec
172.16.2.121
			ESP	172.16.1.2
						Сервер додатків
IP-адреса клієнта			10.1.1.82
						10.1.1.100
10.1.1.82			10.1.1.100
			ДАНІ

Рисунок 6.3 – Дія режиму mode config

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

Режим mode config має статус проекту стандарту IETF.

6.5. Узгодження ключів за схемою Діффі-Хеллмана. Опція PFS

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

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

83

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

Наступний покроковий опис пояснює, як працює алгоритм ДіффіХеллмана:

1. процес Діффі-Хеллмана починається з генерування кожною стороною

великого простого цілого числа або . Кожна сторона посилає своє просте число другій стороні незахищеним каналом. Наприклад, сторона А посилає

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

обчислити первісний корінь числа р; 2. кожна сторона генерує особистий ключ Діффі-Хеллмана (сторона А

генерує а сторона В – ), використовуючи для цього значення і g;

3. кожна сторона генерує відкритий ключ Діффі-Хеллмана. Локальний особистий ключ комбінується з простим числом і його первісним коренем

аби отримати відкритий ключ	для сторони А й відкритий ключ	для
сторони В. Відповідною формулою для сторони А є		.

Формулою для сторони В є . Де mod означає – порівняння за модулем або ділення. Піднесення до ступеня з точки зору обчислень є дорогою операцією;

4.	відбувається відкритий обмін відкритими ключами і	;
5.	кожна сторона генерує загальне секретне значення (	), комбінуючи

відкритий ключ, отриманий від другої сторони, зі своїм особистим.

Відповідною формулою для сторони А є		. Формулою для
сторони В є	. Значення	ідентичні для обох сторін. Якщо
хтось знає значення або	або відкриті ключі Діффі-Хеллмана, він не зможе

вгадати або з легкістю обчислити загальне секретне значення; головним чином через те, що важким є завдання розкладання на множники великих простих чисел;

6. загальні секретні ключі генеруються із загального секретного значення

для використання з алгоритмами DES або НМАС.

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

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

84

рованих оказій або підписів RSA), що забезпечує ідентифікацію обміну ДіффіХеллмана.

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

6.6. Коди НМАС

Коди НМАС (Hashed Message Authentication Code – гешований код пові-

домлення) використовуються в IPSec для того, щоб гарантувати цілісність і автентифікацію даних у ході обох фаз обміну IKE і для AH-Пакетів IPSec. НМАС забезпечує механізм ідентифікації повідомлень на основі використання криптографічних функцій гешування і особистих ключів. Алгоритм або функція гешування „стискує“ повідомлення змінної довжини, яке поступає на вхід, видаючи на виході геш-код фіксованої довжини. Геш-Код повідомлення може потім використовуватися як „профіль“, що ідентифікує дане повідомлення. Вважається практично за неможливе обернути гешування, тобто відновити вихідне повідомлення за його геш-кодом. Функції гешування виконуються швидко, отримані в результаті геш-коди виявляються надійно захищеними, оскільки однобічні функції дуже важко (якщо взагалі можливо) обернути. Основними алгоритмами гешування, використовуваними в IPSec, є криптографічні захищені функції гешування MD5 і SHA-1.

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

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

85

правильним, то можна бути упевненим, що отримане повідомлення дійсно було відправлене вказаним відправником.

Специфікації IPSec передбачають використання HMAC-MD5 і HMAC- SHA-1 як коди НМАС для IKE і IPSec:

1)HMAC-MD5-96. Протокол IPSec використовує технологію шифрування HMAC-MD5-96 (НМАСMD5), аби не допустити зміни повідомлень у дорозі. В HMAC-MD5 використовується функція гешування MD5, розроблена Рональдом Райвестом (Ronald Rivest) з Масачусетського технологічного інституту (MIT). Ця функція гешування описана в документі RFC 1321.

HMAC-MD5 використовує 128-бітовий секретний ключ і дає на виході 128-бітове значення-автентифікатор. Це 128-бітове значення зрізається до перших 96 біт. Зрізане значення зберігається в полі автентифікатора АН або ESPHMAC. Одержувач обчислює повне 128-бітове значення, і перші 96 біт порівнюються із значенням, збереженим у полі автентифікатора.

Як було нещодавно з'ясовано, сам алгоритм MD5 вразливий відносно атак пошуку колізій. Але виявлена атака і інші відомі зараз недоліки MD5 не компрометують захищеність HMAC-MD5, оскільки сценарії атак проти HMAC-MD5 поки не відомі. HMAC-MD5 рекомендується застосовувати тоді, коли важливою виявляється швидкість роботи MD5 у порівнянні з SHA-1;

2)HMAC-SHA-1-96 Протокол IPSec використовує технологію шифрування HMAC-SHA-1-96 (HMAC-SHA- 1), аби не допустити зміни повідомлень у дорозі. В HMAC-SHA-1 використовується функція SHA-1 (описана в документі FIPS-190-1) у комбінації з алгоритмом НМАС (описаним у документі RFC 2104). Відповідні специфікації знаходяться в документі RFC 2404.

HMAC-SHA-1 використовує 160-бітовий секретний ключ і дає на виході 160-бітове значення-автентифікатор. Це 160-бітове значення зрізається до перших 96 біт. Зрізане значення зберігається в полі автентифікатора АН або ESPHMAC. Одержувач обчислює повне 160-бітове значення, і перші 96 біт порівнюються із значенням, збереженим у полі автентифікатора.

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

6.7. Захист RSA. Підписи RSA

IPSec використовує криптосистему RSA з відкритим ключем для автентифікації в першій фазі IKE. Систему RSA створили в 1977 році Рон Райвест

(Ron Rivest), Аді Шамір (Adi Shamir) і Леонард Адлеман (Leonard Adleman). У

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

86

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

Система RSA працює таким чином (рис. 6.4):

1)відкритий текст повідомлення, яке необхідно зашифрувати, і відкритий ключ одержувача подаються на вхід алгоритму шифрування RSA;

2)на виході алгоритму виходить шифрований текст, який передається стороні В;

3)сторона В отримує шифрований текст і подає його разом зі своїм особистим ключем RSA на вхід алгоритму дешифрування RSA;

4)на виході виходить відкритий текст, який повинен відповідати відкритому тексту, введеному стороною А.

			Сторона А				Сторона В
Джерело						Зашифроване				Одержувач
						повідомлення
Відкритий										Відкритий
			Шифрування					Дешифрування
текст										текст
			Відкритий					Особистий
			ключ					ключ
			одержувача					одержувача

Рисунок 6.4 – Дія RSA

Протокол IKE використовує алгоритм RSA для того, щоб ідентифікувати сторони, які беруть участь в обміні, за допомогою підписів RSA і шифрування

RSA.

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

87

шими даними (наприклад, значеннями оказій), необхідними для обміну, а в останніх двох повідомленнях використовується RSA для автентифікації обміну Діффі-Хеллмана. Метод автентифікації задається в конфігурації пристроїв заздалегідь і є предметом переговорів у процесі початкового обміну IKE.

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

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

2)сторона А посилає свій ідентифікатор IKE і підписаний цифровий сертифікат стороні В у ході першої фази IKE. Сторона В посилає аналогічні дані стороні А. Підписаний цифровий сертифікат автентифікує обмін IKE.

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

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

RSA:

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

2)сторона А шифрує своє значення оказії й ідентифікатор IKE за допомогою RSA, використовуючи відкритий ключ RSA сторони В, аби передати їй шифровані дані;

3)сторона В шифрує своє значення оказії й ідентифікатор IKE за допомогою RSA, використовуючи відкритий ключ RSA сторони А;

4)обидві сторони обмінюються шифрованими значеннями;

5)сторона А дешифрує отриманий шифрований текст, використовуючи особистий ключ RSA, і витягує значення оказії та ідентифікатор сторони В. Пі-

88

сля того сторона А обчислює геш-код для цих значень оказії й ідентифікатора і передає його стороні В;

6)сторона В дешифрує отриманий шифрований текст, використовуючи особистий ключ RSA, і витягує значення оказії й ідентифікатор сторони А. Після цього сторона В обчислює геш-код для цих значень оказії й ідентифікатора і передає його стороні А;

7)сторона А виконує гешування свого значення оказії й ідентифікатора, аби порівняти набутого значення з геш-кодом, переданим стороною В. Якщо геш-коди збігаються, сторона У вважається автентифікованою;

8)сторона У виконує гешування свого значення оказії й ідентифікатора, аби порівняти набутого значення з геш-кодом, переданим стороною А. Якщо геш-коди збігаються, сторона А вважається автентифікованою.

Шифрування RSA є дуже надійним, оскільки воно автентифікує не лише обмін IKE, але й обмін Діффі-Хеллмана.

6.8. Центри сертифікації

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

Багато організацій у даний час використовують PKI (Public Кеу Infrastructure – інфраструктуру відкритих ключів) для управління цифровими сертифікатами для безлічі додатків, включаючи додатки VPN, захисту електронної пошти, захищеного Web-Доступу і багато інших додатків захисту.

СА (Certification Authority – центри сертифікації) дозволяють здійснювати масштабування захищених за допомогою IPSec мереж, забезпечуючи кожному мережному пристрою щось подібне цифровій ідентифікаційній карті. Коли дві сторони IPSec мають намір налагодити зв'язок, вони обмінюються цифровими сертифікатами аби ідентифікувати себе. Цифрові сертифікати можна отримати від СА.

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

Сервери сертифікації (сервери СА) управляють запитами на здобуття сертифікатів і видачу сертифікатів для тих, що беруть участь в обміні даними сторін IPSec. Сервери сертифікації спрощують процес адміністрування вузлів IPSec за допомогою централізації системи управління ключами. Можна вико-

89

ристовувати сервер СА в мережі, що включає безліч пристроїв, які підтримують, IPSec, таких як брандмауери PIX Frewall, маршрутизатори, клієнти VPN і IPSec продукти інших виробників, що підтримують.

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

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

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

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

6.9. Перетворення IPSec

Перетворення IPSec задає один протокол захисту IPSec (АН або ESP) з відповідними алгоритмами і режимом. Перетворення АН пропонує механізм ав-

90