Розділ: Комп'ютерні науки ipsecurity

Вид материала

Подобный материал:

1 2 3 4

Заголовок AH містить у собі п'ять полів (мал. 2):

наступний заголовок — поле, що вказує той протокол (наприклад, ESP або TCP), чий заголовок випливає за AH;

довжина заголовка — восьмиразрядное поле зі значенням, рівним довжині заголовка AH у четырехбайтных словах мінус два слова (для сумісності з більш ранньою специфікацією AH);

зарезервоване поле, встановлюване в нульове значення;

індекс параметра захисту (SPI). Це і наступне поле цілком аналогічні однойменним полям у заголовку ESP;

дані аутентификации — поле, що містить цифровий підпис ICV і, можливо, заповнювач для вирівнювання довжини заголовка до цілого значення, кратного 32 (IPv4) або 64 (IPv6) биткам.

Подібно ESP, протокол AH може застосовуватися для туннелирования пакетів.

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

6. Заголовок ESP

У разі|в разі| використання інкапсуляції зашифрованих даних заголовок ESP є|з'являється,являється| останнім у ряді|серед| опціональних| заголовків, "видимих" в пакеті. Оскільки основною метою|ціллю| ESP є|з'являється,являється| забезпечення конфіденційності даних, різні види інформації можуть вимагати застосування|вживання| істотно|суттєво| різних алгоритмів шифрування. Отже, формат ESP може зазнавати значні зміни залежно від використовуваних криптографічних алгоритмів. Проте|тим не менше|, можна виділити наступні|слідуючі| обов'язкові поля: SPI, вказуюче|показуюче| на контекст безпеки і Sequence Number Field, що містить|утримує| послідовний номер пакету. Поле "ESP Authentication Data" (контрольна сума), не є|з'являється,являється| обов'язковим в заголовку ESP. Одержувач пакету ESP розшифровує ESP заголовок і використовує параметри і дані вживаного алгоритму шифрування для декодування інформації транспортного рівня.

Мал. 4 – Формат заголовка ESP.

Розрізняють два режими застосування|вживання| ESP і AH (а також їх комбінації) - транспортний і тунельний.

6.1 Транспортний режим

Транспортний режим використовується для шифрування поля даних IP пакету, що містить|утримує| протоколи транспортного рівня (TCP, UDP, ICMP), яке, у свою чергу|своєю чергою|, містить|утримує| інформацію прикладних служб. Прикладом|зразком| застосування|вживання| транспортного режиму є|з'являється,являється| передача електронної пошти. Всі проміжні вузли на маршруті пакету від відправника до одержувача використовують тільки|лише| відкриту|відчинену| інформацію мережевого|мережного| рівня і, можливо, деякі опциональные| заголовки пакету (у IPv6). Недоліком|нестачею| транспортного режиму є|з'являється,являється| відсутність механізмів утаєння|приховання| конкретних відправника і одержувача пакету, а також можливість|спроможність| проведення аналізу трафіку. Результатом такого аналізу може стати інформація про об'єми|обсяги| і напрями|направлення| передачі інформації, області інтересів а бонентів, розташування керівників.

6.2 Тунельний режим

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

7. Шифрування.

Протокол ESP допускає застосування практично будь-якого симетричного алгоритму для шифрування окремих пакетів. Більш того, в одному додатку можна використовувати різні методи шифрування в різних з'єднаннях. Разом з тим для спеціальних цілей, наприклад обміну ключами, призначеними для наступного шифрування переданих пакетів, служать асиметричні алгоритми. За замовчуванням як алгоритм шифрування стандартом передбачений симетричний метод DES-CBC (Cipher Block Chaining) з 56-розрядним ключем.

З

аголовок ESP міститься в переданий пакет між заголовками протоколів четвертого (наприклад, TCP) і третього (IP) рівнів (мал. 1,а). Пакет рівня ESP включає шість полів (мал. 1,б), з яких зашифровуються тільки чотири останніх:

індекс параметра захисту (Security Parameter Index, SPI) — 32-розрядне число, що повідомляє одержувача про те, яку групу протоколів і алгоритмів захисту використовує відправник;

номер у послідовності — лічильник кількості відправлених пакетів з даним SPI; забезпечує захист від ретрансляційних атак (коли хакер посилає копію пакета з порушенням порядку проходження);

власне дані;

заповнювач — поле перемінного розміру (0—255 байт), що маскує щиру довжину переданих даних;

довжина попереднього поля;

новий заголовок — поле, аналогічне полю Next у заголовку IP-пакета й указывающее тип переданих даних і використовуваний протокол. У випадку застосування протоколу IPv6 у цьому місці можуть розташовуватися деякі додаткові поля заголовка.

Помітимо, що полючи протоколу ESP випливають після стандартного IP-заголовка, а це означає, що такий пакет може маршрутизироваться в мережі за допомогою звичайного устаткування, що підтримує IP.

7.1 Тунелювання.

Цей тип сервісу VPN також забезпечується засобами ESP. Туннелирование полягає в приміщенні первісного IP-пакета усередину пакета ESP і в наступному додаванні нового IP-заголовка, що містить адресу шлюзу.

7.2 Аутентификация.

Функціями шифрування і туннелирования призначення протоколу ESP не обмежується. Поле аутентификации, що може бути присутнім у його заголовку, містить параметр перевірки цілісності пакета (Integrity Check Value, ICV), що дозволяє реалізувати симетричну схему аутентификации. По суті, він являє собою цифровий підпис, що поміщається в поле аутентификации і позволяющую відправникові підписати результат попереднього хеширования змістовної частини пакета ESP (якщо відправник не хеширует її самостійно). Аналіз умісту цього полючи дає можливість одержувачеві ідентифікувати джерело даних і переконатися в тім, що вони не були змінені в процесі передачі.

У поточній версії стандарту IPSec у якості обов'язкової симетричної схеми використання цифрового підпису обрана HMAC і функції хеширования SHA-1 і MD5 із застосуванням ключів.

Якщо для протоколу ESP функції аутентификации є факультативними, то основна діюча особа в цій області — протокол AH. У IP-мережі він може використовуватися самостійно, разом з ESP або у виді «вкладеного» сервісу (за умови вибору режиму туннелирования).

8. Security Associations

Security Association (SA) – це з'єднання|сполучення,сполука|, яке надає служби забезпечення безпеки трафіку, який передається через нього. Два комп'ютери на кожній стороні SA зберігають режим, протокол, алгоритми і ключі|джерела|, використовувані в SA. Кожен SA використовується тільки|лише| в одному напрямі|направленні|. Для двонаправленого зв'язку потрібно два SA. Кожен SA реалізує один режим і протокол; таким чином, якщо для одного пакету необхідно використовувати два протоколи (як наприклад AH і ESP), то потрібно два SA.

9. Політика безпеки

Політика безпеки зберігається в SPD (База даних політики безпеки). SPD може вказати для пакету даних одна з трьох дій: відкинути пакет, не обробляти пакет за допомогою IPSec, обробити пакет за допомогою IPSec. У останньому випадку SPD також указує|вказує|, якої SA необхідно використовувати (якщо, звичайно, відповідний|придатний| SA вже був створений) або указує|вказує|, з|із| якими параметрами повинен бути створений новий SA.

SPD є|з'являється,являється| дуже гнучким механізмом управління, який допускає дуже хороше|добре| управління обробкою кожного пакету. Пакети класифікуються по великому числу полів, і SPD може перевіряти деякі або всі поля для того, щоб визначити відповідну дію. Це може привести до того, що весь трафік між двома машинами передаватиметься за допомогою одного SA, або окреміS використовуватимуться для кожного додатку застосування, або навіть для кожногоTCP з'єднання сполучення,сполуки.

10. Узгодження протоколів і керування ключами

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

Роль такої інфраструктури в IPSec виконує група протоколів Internet Key Exchange (IKE). Це назва в 1998 р. прийшло на зміну більш ранньому — ISAKMP/Oakley, що безпосередньо вказувало на походження засобів керування ключами в складі IPSec. Протокол Internet Security Association and Key Management Protocol (ISAKMP), описаний у документі RFC 2408, був розроблений у 1997 р. у Керуванні національної безпеки США. Він дозволяє погодити алгоритми і математичні структури (так називані мультиплікативні групи, визначені на кінцевому полі) для процедури обміну ключами Диффи — Хеллмана (див. нижче), а також процесів аутентификации. Протокол Oakley (RFC 2412) був запропонований у тому ж році співробітниками Університету штату Аризона і служить для безпосереднього обміну ключами.

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

Історично розроблювачі 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 активно використовується протоколами IKE, що функціонують у два етапи. На першому обидва IKE-вузли (у їхній ролі виступають настільні комп'ютери, що підтримують IPSec або шлюзи безпеки) установлюють захищене «з'єднання» для процедури обміну (IKE SA). На другому етапі по цьому «каналі» здійснюється узгодження всіх параметрів, асоційованих із загальним «каналом» SA.

Перед тим як установити «канал» IKE SA, що ініціює сторона повинна запропонувати для узгодження шість пунктів: алгоритми шифрування, алгоритми хеширования, метод аутентификации, інформацію про групу вузлів, на которые буде поширюватися алгоритм Диффи — Хеллмана, псевдослучайную функцію, за допомогою якої має бути хешировать величини, використовувані при обміні ключами (утім, допускається безпосереднє використання алгоритму хеширования), і тип протоколу захисту (ESP або AH).

Схемою Oakley передбачені три режими обміну інформацією про алгоритми і параметри захисту і встановлення «каналу» SA. Два з них (основної й агресивний) відносяться до першої фази функціонування протоколів IKE і один (швидкий) — до другого.

Основний режим (Main mode) реалізує стандартний механізм установлення «каналу» IKE SA. Він містить у собі три процедури двунаправленного обміну (мал. 3,а). Спочатку сторони домовляються про базові алгоритми і використовувані методи хеширования. Потім здійснюється обмін відкритими ключами в рамках алгоритму Диффи — Хеллмана і випадковими числами (nonce), що підписуються приймаючими сторонами і відправляються назад для ідентифікації. Нарешті, у ході третього обміну по пришедшим назад підписаних значеннях nonce перевіряється дійсність сторін.

В

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

Агресивний режим (Aggressive mode) призначений для тій же цілей, що й основний, однак він простіше в реалізації й одночасно продуктивніше. Плата за ці переваги полягає в тім, що агресивний режим не забезпечує захист інформації, що служить для ідентифікації сторін, оскільки така інформація передається по мережі до узгодження параметрів захищеного «каналу» SA, тобто в незашифрованому виді.Даний режим вимагає тільки двох операцій обміну, а кількість переданих по мережі пакетів удається зменшити із шести до трьох (мал. 3,б). Ініціатор обміну намагається включити в перший же пакет максимум необхідної від нього інформації: пропонований ідентифікатор SA, відкритий ключ алгоритму Диффи — Хеллмана, значення nonce для підпису іншою стороною і навіть пакет із власним ідентифікатором, що дозволяє протилежній стороні «пізнати» свого співрозмовника. Одержувач у відповідь також відправляє всі ті параметри, що необхідні для завершення першої фази IKE і в основному режимі розбилися б по трьох пакетах. У результаті ініціаторові залишається тільки відправити повідомлення про те, що обмін успішно зроблений.

Швидкий режим (Quick mode) забезпечує узгодження параметрів основного «каналу» SA і генерацію нових ключів. Оскільки у швидкому режимі всі передачі здійснюються по захищеному тунельному з'єднанню, у реалізації він простіше двох попередніх. Пакет, переданий у даному режимі, обов'язково починається з хеша, що містить ключ аутентификации, отриманий в основному режимі для IKE SA, і служить для аутентификации іншої частини пакета. Один цикл у швидкому режимі містить у собі передачу трьох пакетів і багато в чому аналогічний процедурі обміну, реалізованої в агресивному режимі.

Якщо при генерації нових ключів необхідно забезпечити їхню повну незалежність від попередніх, по встановленому «каналі» SA здійснюється додатковий обмін відповідно до алгоритму Диффи — Хеллмана. Однак у тому випадку, коли зазначене вимога не є таким твердим, вже існуючі ключі можна обновити за допомогою додаткового хеширования, обмінявши випадковими числами nonce по захищеному з'єднанню.

Узгодження параметрів SA. Після процедур обміну, описаних вище, встановлення основного «каналу» SA являє собою порівняно просту задачу. Сторона, зацікавлена у встановленні нового SA, направляє своєму партнерові повідомлення-запит швидкого режиму, що повинне містити пропонований індекс SPI і захищений засобами IKE SA. Одержувач відповідає на запит власним індексом SPI. Кожний з індексів, відповідно до IP-адреси одержувача і протоколом захисту, визначає окремий «канал» SA. Іншими словами, одна процедура узгодження завершується формуванням двох каналів, один із яких для даної сторони є вхідної, а іншої — вихідної. Усі параметри цих двох каналів (крім ідентифікаторів SPI) цілком ідентичні.

Така пара «каналів» SA установлюється для кожного протоколу захисту. Тому якщо для цілей аутентификации використовуються два протоколи (AH і ESP), кожному з них будуть відповідати два «канали». Більш того, навіть у рамках одного протоколу між двома фіксованими вузлами можна сформувати безліч «каналів» SA. Усе визначається тим, чи орієнтовані ці «канали» на використання хост-компьютером у цілому, індивідуальними користувачами або призначені для окремих комунікаційних сеансів.

Первинна ідентифікація сторін. В описаних вище процедурах установлення «каналу» IKE SA і наступного узгодження алгоритмів і параметрів захищеного обміну є одне «але»: усі вони оправданны лише в тому випадку, якщо в кожної зі сторін мається повна впевненість у тім, що її партнер — саме той, за кого він себе видає.

При здійсненні первинної ідентифікації не обійтися без залучення третього учасника; в архітектурі IPSec він іменується органом сертифікації (Certification Authority, CA). Цей орган покликаний засвідчити дійсність обох сторін і, мабуть, повинний користуватися їхньою повною довірою. Для підтвердження дійсності служать цифрові сертифікати, що включають три частини: унікальний ідентифікатор, що дозволяє однозначно пізнати учасника майбутнього обміну, відкритий ключ, використовуваний під час ідписання електронних документів, і відкритий ключ CA, що дає можливість підписати, а потім ідентифікувати весь сертифікат.

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

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

12. ISAKMP/Oakley

Протокол ISAKMP визначає загальну|спільну| структуру протоколів, які використовуються для встановлення SA і для виконання інших функцій управління ключами|джерелами|. ISAKMP підтримує декілька Областей Інтерпретації (DOI), однією з яких є|з'являється,являється| IPSec-DOI. ISAKMP не визначає закінчений протокол, а надає "будівельні блоки" для різних DOI і протоколів обміну ключами|джерелами|.

Протокол Oakley – це протокол визначення ключа|джерела|, що використовує алгоритм заміни ключа|джерела| Діффі-Хеллмана. Протокол Oakley підтримує ідеальну пряму безпеку (Perfect Forward Secrecy – PFS). Наявність PFS означає неможливість розшифровки всього трафіку при компрометації будь-якого ключа|джерела| в системі.

13. IKE

IKE – протокол обміну ключами|джерелами| за умовчанням для ISAKMP, що на даний момент є|з'являється,являється| єдиним. IKE знаходиться|перебуває| на вершині ISAKMP і виконує, власне, встановлення як ISAKMP SA, так і IPSec SA. IKE підтримує набір різних примітивних функцій для використання в протоколах. Серед них можна виділити хэш-функцію і псевдовипадкову функцію (PRF).

Хэш-функція – це функція, стійка до колізій. Під стійкістю до колізій розуміється той факт, що неможливо знайти два різні повідомлення|сполучення| m1 і m2, таких, що H(m1)=H(m2), де H – хэш| функція.

Що стосується псевдовипадковихх| функцій, то в даний час|нині| замість спеціальних PRF використовується хэш| функція в конструкції HMAC (HMAC - механізм аутентифікації повідомлень|сполучень| з використанням хэш| функцій). Для визначення HMAC нам знадобиться криптографічна хэш| функція (позначимо її як H) і секретний ключ|джерело| K. Ми припускаємо|передбачаємо|, що H є|з'являється,являється| хэш| функцією, де дані хэшируются| за допомогою процедури стиснення|стискування|, послідовно вживаної до послідовності блоків даних. Ми позначимо за B довжину таких блоків в байтах, а довжину блоків, одержаних|отриманих| в результаті|унаслідок,внаслідок| хешування| - як L (L
ipad = байт 0x36, повторений B раз;
opad = байт 0x5C, повторений B раз.

Для обчислення|підрахунку| HMAC від даних 'text' необхідно виконати наступну|слідуючу| операцію:

H(K XOR opad, H(K XOR ipad, text))

З|із| опису виходить, що IKE використовує для аутентифікації сторін HASH величини. Відзначимо, що під HASH в даному випадку мається на увазі виключно|винятково| назва Payload в ISAKMP, і ця назва не має нічого спільного з|із| своїм вмістом.

14. Атаки на AH, ESP і IKE.

Всі види атак на компоненти IPSec можна розділити на наступні|слідуючі| групи:

атаки, що експлуатують кінцівку|скінченність| ресурсів системи (типовий приклад|зразок| - атака "Відмова в обслуговуванні", Denial-of-service або DOS-атака);

атаки, що використовують особливості і помилки конкретної реалізації IPSec ;

і, нарешті|урешті|, атаки, засновані на слабкостях самих протоколів. AH і ESP.

Чисто криптографічні атаки можна не розглядати|розглядувати| - обидва протоколи визначають поняття "трансформ|", куди приховують всю криптографію. Якщо використовуваний криптоалгоритм стійок|стойок|, а визначений з|із| ним трансформ| не вносить додаткових слабкостів (це не завжди так, тому правильніше розглядати|розглядувати| стійкість всієї системи - Протокол-Трансформ-алгоритм), то з цієї сторони все нормально. Що залишається? Replay Attack - нівелюється за рахунок використання Sequence Number (у одному єдиному випадку це не працює - при використанні ESP без аутентифікації і без AH).

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

Залишається Denial-Of-Service атака. Як відомо, це атака, від якої не існує повного|цілковитого| захисту. Проте|тим не менше|, швидка відбір| поганих пакетів і відсутність якої-небудь зовнішньої реакції на них (згідно RFC) дозволяють більш-менш добре справлятися з|із| цією атакою. У принципі|в принципі|, більшості (якщо не всім) відомим мережевим|мережним| атакам (sniffing, spoofing, hijacking і т.п.) AH і ESP при правильному їх застосуванні|вживанні| успішно протистоять. З|із| IKE дещо складніше. Протокол дуже складний, важкий|тяжкий| для аналізу. Крім того, через друкарські помилки (у формулі обчислення|підрахунку| HASH_R) при його написанні і не зовсім вдалих|успішних| рішень|розв'язань,вирішень,розв'язувань| (той же HASH_R і HASH_I) він містить|утримує| декілька потенційних "дірок|діри|" (зокрема, в першій фазі не все Payload в повідомленні|сполученні| аутентифицируются|), втім, вони не дуже серйозні і ведуть, максимум, до відмови у встановленні з'єднання|сполучення,сполуки|.Від атак типу replay, spoofing, sniffing, hijacking IKE більш-менш успішно захищається. З|із| криптографією дещо складніше, - вона не винесена, як в AH і ESP, окремо, а реалізована в самому протоколі. Проте|тим не менше|, при використанні стійких алгоритмів і примітивів (PRF), проблем бути не повинно.

Якоюсь мірою можна розглядати|розглядувати| як слабкість IPsec те, що як єдиний обов'язковий до реалізації криптоалгоритма в нинішніх специфікаціях |вказується| DES (це справедливо і для ESP, і для IKE), 56 біт ключа|джерела| якого вже не вважаються|лічаться| достатніми. Проте|тим не менше|, це чисто формальна слабкість - самі специфікації є|з'являються,являються| не-залежними, і практично всі відомі вендоры| давно реалізували 3DES (а деякі вже і AES) .Таким чином, при правильній реалізації, наиболее| "небезпечною" атакою залишається Denial-Of-Service.

15. Системи захисту інформації

IPSec (Security Architecture for IP, протокол безпеки для IP) — основний протокол для побудови|шикування| віртуальних приватних мереж|сітей| (VPN, Virtual Private Network), які були детально розглянуті|розгледіти| раніше. IPSec забезпечує безпечну передачу даних в IP-мережах|сітях| шляхом створення|створіння| захищених тунелів. З|із| його допомогою розв'язуються|вирішуються| наступні|слідуючі| завдання|задачі|:

аутентифікація користувачів (або комп'ютерів) при створенні|створінні| тунеля;

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

автоматичний розподіл ключів|джерел| в рамках|у рамках| тунелів.

У IPSec передбачене ведення бази даних політики безпеки, яка, по суті, є набір критеріїв для створення|створіння| тунелів і фільтрації IP-пакетів. У цьому протоколі передбачене все необхідне, і для розробки, наприклад, програмного VPN-агента досить лише грамотно реалізувати IPSec і передбачити інтерфейс для його адміністрування.

Основа IPSec — протоколи AH, ESP і IKE. Перший їх їх (Authentication Header, заголовок аутентифікації) призначений для аутентифікації і контролю цілісності; ESP (Encapsulation Security Payload, що інкапсулює захищене вкладення) — для шифрування даних і захисту цілісності; IKE (Internet Key Exchange, обмін ключами|джерелами| в Інтернеті) — для обміну ключами|джерелами|, використовується він на етапі створення|створіння| тунеля.

До речі, оскільки IPSec реалізується на рівні протоколу IP, створеними з|із| його допомогою тунелями можуть користуватися і протоколи вищих рівнів, наприклад TCP або UDP. А основний недолік|нестача| IPSec — здатність|здібність| працювати тільки|лише| в IP-мережах|сітях| — нейтралізується шляхом його застосування|вживання| в комбінації з|із| протоколами L2F (Layer 2 Forwarding, переадресація на рівні 2) і L2TP (Layer 2 Tunneling Protocol, протокол тунелюванняя| на рівні 2), які здійснюють інкапсуляцію пакетів іншої архітектури в IP-пакети.

Зрозуміло, що інформацію захищають зовсім не алгоритми шифрування і електронного цифрового підпису (ЕЦП|), а системи, в яких ці алгоритми реалізовані. Їх можна умовно розділити на

системи автоматичного захисту інформації ;

системи захисту інформації прикладного рівня.

15.1 Системи для уважних і неледачих|лінивих|

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

Аналогічна ситуація і з|із| ЕЦП|: припустимо, ви хочете підписати файл і вкласти його в лист. Легко! Даєте команду програмі, вона цей підпис обчислює|обчисляє,вичисляє| і записує|занотовує| у файл, а адресат при отриманні|здобутті| перевіряє її достовірність|справжність|. Природно, можна використовувати шифрування і ЕЦП| в комплексі — все залежить тільки|лише| від вашого бажання|воління|.

Оскільки такі системи передбачають вибір об'єктів, що захищаються, вручну|вручну|, їх інтерфейс повинен надавати можливість|спроможність| «бродити» по файловій системі, щоб знайти потрібні. Оптимальним варіантом є|з'являється,являється| вбудованість| програми безпосередньо в Windows Explorer, як, наприклад, WinZip в контекстне меню (див. малюнок).

Приклад|зразок| вбудовування інтерфейсу програми електронного підпису в контекстне меню Windows Explorer

Blog

Розділ: Комп'ютерні науки ipsecurity