УПРАВЛІННЯ КРИПТОГРАФІЧНИМИ КЛЮЧАМИ ДЛЯ СИМЕТРИЧНИХ ШИФРІВ

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

  • - генерація ключів;
  • - зберігання ключів;
  • - розподіл ключів.

Генерація ключів повинна проводитися таким чином, щоб передбачити значення ключа (навіть знаючи, як він буде генеруватися) було практично неможливо. В ідеальному випадку, ймовірність вибору конкретного ключа з безлічі допустимих дорівнює 1 / N, де N - потужність ключового безлічі (число його елементів).

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

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

Рекомендується регулярно проводити заміну ключів, що використовуються в системі. У деяких випадках замість заміни допустимо використовувати процедуру модифікації. Модифікація кчюча - генерація нового ключа з попереднього значення за допомогою односторонньої функції (т. Е. Такої функції, для якої зворотне перетворення обчислити практично неможливо, детальніше див. Розділ 2.5). Але в цьому випадку треба враховувати, що новий ключ безпечний в тій же мерс, що і колишній, т. К. Противник може повторити весь ланцюжок модифікацій.

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

  • - головний ключ;
  • - ключ шифрування ключів;
  • - ключ шифрування даних (сеансовий ключ).

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

При розподілі ключів необхідно виконати наступні вимоги:

  • - забезпечити оперативність і точність розподілу ключів;
  • - забезпечити секретність розподілу ключів.

Розподіл ключів може здійснюватися:

  • - з використанням одного або декількох центрів розподілу ключів (централізований розподіл);
  • - прямим обміном сеансовими ключами між користувачами мережі (децентралізоване розподіл ключів).

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

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

Протокол Kerberos був розроблений в Массачусетському технологічному інституті в середині 1980-х років і зараз являегся фактичним стандартом системи централізованої аутентифікації і розподілу ключів симетричного шифрування. Підтримується операційними системами сімейства Unix, Windows (починаючи з Win- dows'2000), тобто реалізації для Mac OS.

Протокол Kerberos забезпечує розподіл ключів симетричного шифрування і перевірку автентичності користувачів, що працюють в незахищеній мережі. Реалізація Kerberos - це програмна система, побудована по архітектурі «клієнт-сервер». Клієнтська частина встановлюється на всі комп'ютери мережі, що захищається, крім тих, на які встановлюються компоненти сервера Kerberos. У ролі клієнтів Kerberos можуть, зокрема, виступати і мережеві сервери (файлові сервери, сервери друку і т. Д.).

Серверна частина Kerberos називається центром розподілу ключів (англ. «Key Distribution Center», скор. KDC) і складається з двох компонент:

- сервер аутентифікації (англ. «Authentication Server», скор.

AS);

- сервер видачі дозволів (англ. «Ticket Granting Server», скор. TGS).

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

протокол Kerberos

Мал. 2.14. протокол Kerberos

Нехай клієнт З збирається почати взаємодію з сервером SS (від англ. «Service Server» - сервер, що надає мережеві сервіси). В дещо спрощеному вигляді протокол передбачає наступні кроки [10,111-

1). C-> AS: {з}.

Клієнт З посилає серверу аутентифікації AS свій ідентифікатор з (ідентифікатор передається відкритим текстом).

2). AS-> C: (TGT} K as _ TC s, K c _ tgs } K 0 де К з - основний ключ С;

Kc_tgs - ключ, що видається С для доступу до сервера видачі дозволів TGS ;

(TGTj -білет на доступ до сервера видачі дозволів (англ.

«Ticket Granting Ticket»); {TGT) = {c, tgs, t, p, K c _tgsЛ де tgs - ідентифікатор сервера видачі дозволів, ц - відмітка часу, р - період дії квитка. Запис {...} До Х у цій Угоді означає, що вміст фігурних дужок зашифровано на ключі К х .

На цьому кроці сервер аутентифікації AS, перевіривши, що клієнт З мається на його базі, повертає йому квиток для доступу до сервера видачі дозволів і ключ для взаємодії з сервером видачі дозволів. Вся посилка зашифрована на ключі клієнта С. Таким чином, навіть якщо на першому кроці взаємодії ідентифікатор з послав не клієнт С, а порушник X, то отриману від AS посилку X розшифрувати не зможе.

Отримати доступ до вмісту квитка TGT не може не тільки порушник, але і клієнт С, так як квиток зашифрований на ключі, який розподілили між собою сервер аутентифікації і сервер видачі дозволів.

3). C-> TGS: {TGT) K A s_t G s, IAut j Kc_tcs> HD),

де {Aut} - аутентифікаційний блок - Aut = {c, b}, h - мітка часу; ID - ідентифікатор запитуваного сервісу (зокрема, це може бути ідентифікатор сервера SS).

Клієнт З цього разу звертається до сервера видачі дозволів TGS. Він пересилає отриманий від AS квиток, зашифрований на ключі K as _tgs, і аутентифікаційний блок, що містить ідентифікатор з і мітку часу, яка показує, коли була сформована посилка.

Сервер видачі дозволів розшифровує квиток TGT і отримує з нього інформацію про те, кому був виданий квиток, коли і на який термін, ключ шифрування, згенерований сервером AS для взаємодії між клієнтом С і сервером TGS. За допомогою цього ключа розшифровується аутентифікаційний блок. Якщо мітка в блоці збігається з міткою в квитку, це доводить, що посилку згенерував насправді С (адже тільки він знав ключ K c _tgs і міг правильно зашифрувати свій ідентифікатор). Далі робиться перевірка часу дії квитка та часу оправления посилки 3. Якщо перевірка проходить, і діюча в системі політика дозволяє клієнту З звертатися до клієнта SS, тоді виконується крок 4.

4). TGS-> C: / {TGS} Ktgs_ss

де K c _ss - ключ для взаємодії С і 55, {TGS} - від англ. «Ticket Granting Service» - квиток для доступу до 55 (зверніть увагу, що такий же абревіатурою в описі протоколу позначається і сервер видачі дозволів). {TGSj - {c, ss, t 2 , p 2 , K c _ss}?

Зараз сервер видачі дозволів TGS посилає клієнту З ключ шифрування і квиток, необхідні для доступу до сервера 55. Структура квитка така ж, як на кроці 2: ідентифікатор того, кому видали квиток; ідентифікатор того, для кого видали квиток; відмітка часу; період дії; ключ шифрування.

5). С-> 55: (TGS} K TG s_ss, (Ам 2 ) K c _ss, де Aut 2 - (c, t 4 }.

Клієнт З посилає квиток, отриманий від сервера видачі дозволів, і свій аутентифікаційний блок сервера 55, з яким хоче встановити сеанс захищеного взаємодії. Передбачається, що 55 вже зареєструвався в системі і розподілив з сервером TGS ключ шифрування K T cs_ss? Маючи цей ключ, він може розшифрувати квиток, отримати ключ шифрування K C _SS і перевірити справжність відправника повідомлення.

6). SS-> C: / t 4 + l} Kcjs

Сенс останнього кроку полягає в тому, що тепер уже 55 повинен довести З свою справжність. Він може зробити це, показавши, що правильно розшифрував попереднє повідомлення. Ось тому 55 бере позначку часу з аутентификационного блоку С, змінює її заздалегідь певним чином (збільшує на 1), шифрує на ключі Kc ss і повертає С.

Якщо всі кроки виконані правильно, і всі перевірки пройшли успішно, то сторони взаємодії С і 55, по-перше, переконалися в справжності один одного, а по-друге, отримали ключ шифрування для захисту сеансу зв'язку - ключ K c _ss-

Потрібно відзначити, що в процесі сеансу роботи клієнт проходить кроки 1 і 2 тільки один раз. Коли потрібно отримати квиток на доступ до іншого сервера (назвемо його 551), клієнт З звертається до сервера видачі дозволів TGS з уже наявними у нього квитком, т. Е. Протокол виконується починаючи з кроку 3.

При використанні протоколу Kerberos комп'ютерна мережа логічно ділиться на області дії серверів Kerberos. Kerberos- область - це ділянка мережі, користувачі і сервери якого зареєстровані в базі даних одного сервера Kerberos (або в одній базі, що розділяється декількома серверами). Одна область може охоплювати сегмент локальної мережі, всю локальну мережу або об'єднувати кілька пов'язаних локальних мереж. Схема взаємодії між Kerberos-областями представлена на рис. 2.15.

Взаємодія між Kerberos-областями

Мал. 2.15. Взаємодія між Kerberos-областями

Для взаємодії між областями повинна бути здійснена взаємна реєстрація серверів Kerberos, в процесі якої сервер видачі дозволів однієї області реєструється в якості клієнта в іншій області (т. Е. Заноситься в базу сервера аутентифікації і розділяє з ним ключ).

Після установки взаємних угод, клієнт з області 1 (нехай це буде А) 0 може встановити сеанс взаємодії з клієнтом з області 2 (наприклад, К 2 ). Дш цього До і повинен отримати у свого сервера видачі дозволів квиток на доступ до Kerberos- сервсру, з клієнтом якого він хоче встановити взаємодію (на рис. 2.15 це сервер KDC2). Отриманий квиток містить позначку про те, в якій області зареєстрований власник квитка. Квиток шифрується на ключі, розділеному між серверами KDC 1 і KDC2. При успішну розшифровку квитка віддалений Kerberos-сервер може бути впевнений, що квиток виданий клієнту Kerberos-області, з якої встановлено довірчі відносини. Далі протокол працює, як зазвичай.

Крім розглянутих, Kerberos надає ще ряд додаткових можливостей. Наприклад, зазначений в структурі квитка параметр р (період часу) задається парою значень «час початку дії» - «час закінчення дії», що дозволяє отримувати квитки відкладеного дії.

Імеегся тип білега «з правом передачі», що дозволяє, наприклад, серверу виконувати дії від імені який звернувся до нього клієнта.

 
Переглянути оригінал
< Попер   ЗМІСТ   ОРИГІНАЛ   Наст >