| Назва: | IPSecurity |
| Тип: | Реферати |
| Мова: | Українська |
| Розмiр: | 2,24 MB |
| Скачувань: | 23 |
Історично розроблювачі IPSec почали свою діяльність з рішення останньої задачі. У результаті на світло з'явилася концепція виділених захищених віртуальних «каналів» (або «з'єднань») і відповідних їм структур даних, в англійській мові получивших назва, що не цілком адекватне, Security Association (SA). Саме в рамках SA визначаються алгоритм аутентификации протоколу AH і його ключі, алгоритм шифрування, використовуваний протоколом ESP, і його ключі, наявність або відсутність криптографічної синхронізації, способи аутентификации партнерів і захисти сеансу обміну, частота зміни ключів і ряд інших параметрів. Об'єднання настільки великої службової інформації в рамках SA надає користувачеві можливість сформувати різні класи захисту, призначені, наприклад, для електронного спілкування з різними «співрозмовниками». Іншими словами, застосування структур SA відкриває шлях до побудови безлічі віртуальних приватних мереж, що розрізняються своїми параметрами.
«Канал» SA цілком визначається трьома величинами: уже згадуваним 32-розрядним індексом SPI, IP-адресою вузла призначення й ідентифікатором протоколу захисту (AH або ESP). Вузол-одержувач вибирає значення індексу SPI з числа не використовуваних у даний момент (і бажано що не фігурували раніше) і повідомляє його відправникові. Якщо той погоджується на запропоноване значення індексу, даний SPI стає ідентифікатором «каналу» SA між двома сторонами і саме по ньому надалі будуть вибиратися службові дані, необхідні для захисту інформаційного обміну між учасниками сеансу.
З метою роботи з параметрами SA на кожній стороні створюється база даних таких «каналів» (Security Association Database). Кожному погодженому «каналові» у ній відповідає окремий запис.
Що стосується способів використання протоколів IPSec окремими додатками, то вони визначаються в записах бази даних, що містить набори правил, або стратегії, інформаційної безпеки (Security Policy Database). Така БД формується і підтримується на кожнім вузлі, де встановлене програмне забезпечення IPSec. Вибираючи той або інший запис з цієї БД, додаток визначає спосіб захисту генерируемых IP-пакетів, що потім реалізується в рамках погодженого «каналу» SA.
11. Генерація ключів.
Використання ключів спрямоване на зменшення ризику перехоплення переданих даних. Зрозуміло, що операція обміну зашифрованими ключами, що передує обмінові власне даними, також може стати об'єктом мережної атаки. Імовірність перехоплення і, головне, успішної розшифровки ключів, мабуть, падає з ростом їхньої довжини. У той же час надмірне збільшення розміру ключів здатно негативно позначитися на загальній продуктивності процедур обміну.
Компромісне рішення могло б складатися в частій зміні ключів, що мають помірну довжину. Однак тут виникає ще одна проблема. Необхідно, щоб знову сгенерированный ключ був сприйнятий іншою стороною, тоді як його генерація ніяк не повинна базуватися на попередніх ключах або на тих числових масивах, по яких вони генерувалися. Обійти ці труднощі допомагає комбінаційний алгоритм Диффи — Хеллмана (Diffie-Hellman), узятий на озброєння творцями IPSec.
Процедура обміну ключами виглядає в такий спосіб. Сторони направляють один одному запису cookies, що надалі дозволяють запобігти атаці типу перевантаження ресурсів (коли атакує намагається створити надлишкове навантаження на обчислювальні ресурси своєї жертви, наприклад ініціюючи відразу кілька сеансів обміну ключами по алгоритму Диффи — Хеллмана). Потім кожна зі сторін незалежно від іншої випадковим образом генерує пари значень, що є аналогами відкритого і секретного ключів. Сгенерированные відкриті ключі сторони передають один одному через мережу, після чого кожна сторона комбінує прийнятий відкритий ключ із власним секретним, використовуючи алгоритм Диффи — Хеллмана. Не вдаючись у математичні деталі, відзначимо, що основна ізюминка даного алгоритму полягає в тому, що в результаті зазначеної процедури обидві сторони одержать той самий комбінований ключ. Іншими словами, цей алгоритм дає можливість перейти від традиційних асиметричних процедур шифрування на основі пари ключів до симетричної схеми з застосуванням комбінованого ключа, що характеризується більшою продуктивністю. Комбінований ключ можна використовувати при наступних обмінах даними або для шифрування нових ключів, сгенерированных незалежно від попередніх.
11.1 Алгоритм Диффи — Хелмана, мабуть, має сенс застосовувати тільки в сполученні з процедурою аутентификации сторін з метою запобігти атаці типу посередництва при обміні незашифрованими ключами. Така аутентификация звичайно виробляється відразу після обміну відкритими ключами з використанням цифрових підписів.
«Канал» SA цілком визначається трьома величинами: уже згадуваним 32-розрядним індексом SPI, IP-адресою вузла призначення й ідентифікатором протоколу захисту (AH або ESP). Вузол-одержувач вибирає значення індексу SPI з числа не використовуваних у даний момент (і бажано що не фігурували раніше) і повідомляє його відправникові. Якщо той погоджується на запропоноване значення індексу, даний SPI стає ідентифікатором «каналу» SA між двома сторонами і саме по ньому надалі будуть вибиратися службові дані, необхідні для захисту інформаційного обміну між учасниками сеансу.
З метою роботи з параметрами SA на кожній стороні створюється база даних таких «каналів» (Security Association Database). Кожному погодженому «каналові» у ній відповідає окремий запис.
Що стосується способів використання протоколів IPSec окремими додатками, то вони визначаються в записах бази даних, що містить набори правил, або стратегії, інформаційної безпеки (Security Policy Database). Така БД формується і підтримується на кожнім вузлі, де встановлене програмне забезпечення IPSec. Вибираючи той або інший запис з цієї БД, додаток визначає спосіб захисту генерируемых IP-пакетів, що потім реалізується в рамках погодженого «каналу» SA.
11. Генерація ключів.
Використання ключів спрямоване на зменшення ризику перехоплення переданих даних. Зрозуміло, що операція обміну зашифрованими ключами, що передує обмінові власне даними, також може стати об'єктом мережної атаки. Імовірність перехоплення і, головне, успішної розшифровки ключів, мабуть, падає з ростом їхньої довжини. У той же час надмірне збільшення розміру ключів здатно негативно позначитися на загальній продуктивності процедур обміну.
Компромісне рішення могло б складатися в частій зміні ключів, що мають помірну довжину. Однак тут виникає ще одна проблема. Необхідно, щоб знову сгенерированный ключ був сприйнятий іншою стороною, тоді як його генерація ніяк не повинна базуватися на попередніх ключах або на тих числових масивах, по яких вони генерувалися. Обійти ці труднощі допомагає комбінаційний алгоритм Диффи — Хеллмана (Diffie-Hellman), узятий на озброєння творцями IPSec.
Процедура обміну ключами виглядає в такий спосіб. Сторони направляють один одному запису cookies, що надалі дозволяють запобігти атаці типу перевантаження ресурсів (коли атакує намагається створити надлишкове навантаження на обчислювальні ресурси своєї жертви, наприклад ініціюючи відразу кілька сеансів обміну ключами по алгоритму Диффи — Хеллмана). Потім кожна зі сторін незалежно від іншої випадковим образом генерує пари значень, що є аналогами відкритого і секретного ключів. Сгенерированные відкриті ключі сторони передають один одному через мережу, після чого кожна сторона комбінує прийнятий відкритий ключ із власним секретним, використовуючи алгоритм Диффи — Хеллмана. Не вдаючись у математичні деталі, відзначимо, що основна ізюминка даного алгоритму полягає в тому, що в результаті зазначеної процедури обидві сторони одержать той самий комбінований ключ. Іншими словами, цей алгоритм дає можливість перейти від традиційних асиметричних процедур шифрування на основі пари ключів до симетричної схеми з застосуванням комбінованого ключа, що характеризується більшою продуктивністю. Комбінований ключ можна використовувати при наступних обмінах даними або для шифрування нових ключів, сгенерированных незалежно від попередніх.
11.1 Алгоритм Диффи — Хелмана, мабуть, має сенс застосовувати тільки в сполученні з процедурою аутентификации сторін з метою запобігти атаці типу посередництва при обміні незашифрованими ключами. Така аутентификация звичайно виробляється відразу після обміну відкритими ключами з використанням цифрових підписів.