Защита електронної пошти в Internet

РефератДопомога в написанніДізнатися вартістьмоєї роботи

Защита електронної пошти в Internet (реферат, курсова, диплом, контрольна)

Запровадження 2 1. Способи захисту потоку даних в Web 3 2. Захист лише на рівні додатків 4 2. 1. Система PGP 4 2. 2. Система S/MIME 7 3. Протоколи SSL і TLS 11 3. 1. Архітектура SSL 11 3. 2. Протокол записи SSL 11 3. 3. Протокол зміни параметрів шифрування 12 3. 4. Протокол сповіщення 12 3. 5. Протокол квитирования 12 3. 6. Створення головного секретного ключа 15 3. 7. Генерування криптографічних параметрів 15 3. 8. Що таке TLS та її на відміну від SSL 16 4. Захист лише на рівні IP (мережевий рівень) 16 4. 1. Архітектура захисту лише на рівні IP 16 4. 2. Заголовок аутентифікації (AH). 18 4. 2. 1. Структура заголовка 18 4. 2. 2. Використання AH у транспортній і туннельном режимі 18 4. 3. Протокол ESP 19 4. 3. 1. Формат пакета ESP 19 4. 3. 2. Шифрування і алгоритми аутентифікації 20 4. 3. 3. Транспортний режим ESP 20 4. 3. 4. Тунельний режим ESP 21 4. 4. Комбінація защищённых зв’язків 22 Укладання 24 Джерела інформації 25.

Більшість проблем, із якими стикаються користувачі електронної пошти (спам, віруси, різноманітні атаки на конфіденційність листів тощо. буд.), пов’язані з недостатньою захистом сучасних поштових систем.

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

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

. Жоден зі стандартних поштових протоколів (SMTP, POP3, IMAP4) не включає механізмів захисту, які гарантували б конфіденційність переписки.

. Відсутність надійний захист протоколів дозволяє створювати листи з фальшивими адресами. Не можна бути впевненим на 100% у цьому, хто є дійсним автором письма.

. Електронні листи легко змінити. Стандартне лист зовсім позбавлений коштів перевірки власної цілісності і за передачі через безліч серверів, то, можливо читано і змінено; електронного листа від схоже сьогодні на открытку.

. Зазвичай, у роботі електронної пошти немає гарантій доставки письма.

Попри наявність одержати повідомлення про доставці, часто це лише, що сягнуло поштового серверу получателя.

(але впритул до адресата).

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

Наведемо короткий приклад даних засобів і методов:

1-ый спосіб. Використання снифферов. Сниффер — є програми, перехватывающие все мережні пакети, що передаються через певний вузол. Снифферы використовують у мережах в цілком законному підставі для діагностики несправностей та виваженості аналізу потоку переданих даних. Через те, деякі мережні докладання, зокрема поштові, передають дані в текстовому форматі (SMTP, POP3 та інших.), з допомогою сниффера можна почути текст листи, імена користувачів і пароли.

2-ой спосіб. IP-спуфинг (spoofing) — може бути, коли зловмисник, які перебувають всередині організації, або за її межами дається взнаки за санкціонованого користувача. Атаки IP-спуфинга часто є відправною точкою й інших атак, наприклад, DoS (Denial of Service — «відмову у обслуговуванні»). Зазвичай IPспуфинг обмежується вставкою удаваної інформації, або шкідливих команд в звичайний потік переданих через мережу даних. Це відбувається у разі, якщо головне завдання полягає отриманні важливого файла. Проте зловмисник, помінявши таблиці маршрутизації даних, і спрямувавши трафік на помилковий IP-адрес, може сприйматися системою як санкціонований користувач і, отже, мати доступом до файлам, додатків, у тому числі до електронної почте.

3-й спосіб — отримання пароля на пошту. Атаки щоб одержати паролів робити з допомогою цілого ряду методів, і було вхідний ім'я і пароль можна отримати роботу з допомогою IP-спуфинга і перехоплення пакетів, їх часто намагаються підібрати шляхом простого перебору з допомогою спеціальної программы.

4-й спосіб порушення конфіденційності - Man-in-the-Middle («людина у середині») — полягає у перехоплення всіх пакетів, переданих маршрутом від провайдера до будь-якої іншої частина Мережі. Такі атаки з допомогою снифферов пакетів, транспортних протоколів і протоколів маршрутизації проводяться із єдиною метою перехоплення інформації, отримання доступу до приватним мережним ресурсів, спотворення переданих даних. Вони цілком може використовуватися для перехоплення повідомлень електронної пошти та його змін, а також і перехоплення паролів імен пользователей.

5-ї спосіб. Атаки лише на рівні додатків використовують добре відомі слабкості серверного програмного забезпечення (sendmail, HTTP, FTP). Можна, наприклад, одержати доступ комп’ютера від імені користувача, котрий з додатком тієї ж електронної почты.

Для захисту мережевий інфраструктури необхідно использовать:

1. Насамперед сильні кошти аутентифікації, наприклад, технологія двухфакторной аутентификации.

2. Ефективне колег і адміністрування мережі. Йдеться побудові коммутируемой інфраструктури, заходи контролю доступу і фільтрації вихідного трафіку, закритті «дір» в програмне забезпечення з допомогою модулів «латок» і регулярному його відновленні, установці антивірусних програм, тож що свідчить ином.

3. Криптографія, яка запобігає перехоплення інформації та не розпізнає роботу програм цієї мети, але робить роботу непотрібної. Криптографія також допомагає від IP-спуфинга, якщо використовується при аутентификации.

1. Способи захисту потоку даних в Web.

Є кілька підходів до захисту даних в Web. Усі схожі з погляду наданих можливостей та у певній ступеня з погляду використовуваних механізмів захисту, але різняться по областям застосування та розміщення відповідних засобів захисту в стеці протоколів TCP/IP.

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

Іншим рішенням є проживання коштів забезпечення безпеки відразу над протоколом TCP. Прикладом сучасної реалізації такої підходу є стандарт SSL (Secure Socket Layer — протокол захищених сокетов) і його нова версія — стандарт TLS (Transport Layer Security — протокол захисту транспортного рівня) безпечної передачі в Internet. У цьому рівні для практичної реалізації цього підходу є дві можливості. Найбільш загальним рішенням є коштів SSL (чи TLS) в набір відповідних протоколів, що забезпечує прозорість засобів захисту для додатків. У той самий час кошти SSL можна вбудовувати й у прикладні програми. На приклад, броузеры Netscape і Microsoft Internet Explorer, а також більшість Web-серверов мають вмонтовану підтримку SSL.

Різні засоби захисту можуть вбудовуватися й у докладання. Перевага такого підходу у тому, що відповідні кошти захисту може бути налаштовані оптимальним чином у залежність від вимог конкретного докладання. У безпеки Web важливим прикладом реалізації такої підходу протокол SET (Secure Electronic Transaction — протокол захисту електронних транзакций).

|IP/IPSec | |IP | |IP |.

Мережний рівень Транспортний рівень Рівень приложения.

Розміщення засобів захисту в стеці протоколів TCP/IP.

2. Захист лише на рівні приложений.

Схема аутентифікації. [pic] позначення: Ка — сеансовый ключ, вживаний у схемою традиційного шифрування, KRа — особистий ключ А, вживаний у схемою шифрування з відкритою ключем, KUа — відкритий ключ А, вживаний у схемою шифрування з відкритою ключем, EР — шифрування у схемі з відкритою ключем, DP — дешифрування у схемі з відкритою ключем, EC — шифрування у схемі традиційного шифрування, DC — дешифрування у схемі традиційного шифрування, H — функція хэширования, || - конкатенація, Z — стиснення з допомогою алгоритму zip, R64 — перетворення на формат radix-64 ASCII.

Шаги:

1. Відправник створює сообщение.

2. Використовується алгоритм SHA-1, у результаті виходить 160-битовый хэш-вектор сообщения.

3. Отриманий хэш-вектор шифрується з допомогою алгоритму RSA з використанням особистого ключа відправника, і результати додається на початок сообщения.

4. Одержувач використовує RSA з відкритою ключем відправника, щоб дешифрувати й відновити хэш-код.

5. Одержувач генерує новий хэш-код отриманого повідомлення й порівнює його з дешифрованным хэш-кодом. Якщо хэш-коды збігаються, повідомлення вважається подлинным.

Схема шифрування повідомлення. [pic] Шаги:

1. Відправник генерує повідомлення випадкове 128-битовое число, яке у ролі сеансового ключа лише цього сообщения.

2. Повідомлення шифрується з допомогою алгоритму CAST-128 (чи IDEA, чи 3DES) і даного сеансового ключа.

3. Сеансовый ключ шифрується з допомогою алгоритму RSA і відкритого ключа одержувача і приєднаються до початку сообщения.

4. Одержувач використовує RSA з особистим ключем, щоб дешифрувати і тим самим відновити сеансовый ключ.

5. Сеансовый ключ застосовується для дешифрування сообщения.

Схема використання обох служб (підписи повідомлення з допомогою особистого ключа та її шифровки з допомогою сеансового ключа). [pic] Відправник сообщения:

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

2. Підпис і щирий текст повідомлення стискуються zip-ом.

3. Стиснутий відкритий текст повідомлення й підпис шифруються з допомогою алгоритму CAST -128 (чи IDEA, чи 3DES), а сеансовый ключ шифрується з допомогою RSA (чи алгоритму Эль-Гамаля) у своїй використовується відкритий ключ одержувача. Одержувач сообщения.

1. Cеансовый ключ дешифрується з допомогою особистого ключа получателя.

2. З допомогою отриманого сеансового ключа дешифрує сообщение.

3. Розпакування сообщения.

4. Відкритим ключем відправника дешифрує хэш-вектор і генерує новий хэш-вектор.

5. Порівнює їх. Якщо збігаються (повідомлення був изменено.

Идентификаторы ключів. Оскільки одержувач повідомлення має можливість отримувати зашифровані і підписані повідомлення багатьох учасників листування, отже він повинен мати кілька пар личный/открытый ключів. А, щоб одержувачу визначити який особистий ключ (алгоритму RSA) треба використовувати для розшифровки сеансового ключа (алгоритму CAST-128) то здобуває ідентифікатор відкритого ключа (замість самого ключа пересилається його ідентифікатор, оскільки відкритий ключ для RSA може довжина його становитиме на сотні десяткових розрядів). Ідентифікатор, його із кожним відкритим ключем, розміщається в молодших 64 розрядах ключа. Ідентифікатор ключа потрібне і для цифрового електронного підпису PGP. Тому, що відправник може скористатися однією з кількох особистих ключів для шифрування профілю повідомлення, одержувач повинен знати, який відкритий ключ йому варто використовувати. Тому розділ цифрового електронного підпису повідомлення включає 64-битовый ідентифікатор відповідного відкритого ключа. При отриманні повідомлення одержувач перевіряє, що ідентифікатор відповідає відомому йому відкритого ключу відправника, та був продовжує перевірку подписи.

Формат переданого повідомлення. |Повідомлення |Підпис |Компонент |Вміст | | | |сеансового | | | | |ключа | | | | |[pic] | | |ZIP | | | |Eкs | | | |R64 | |.

ERUb — шифрування з допомогою особистого ключа користувача B EKRa — шифрування з допомогою відкритого ключа користувача, А EКs — шифрування з допомогою сеансового ключа ZIP — функція стискування ZIP R64 — функція перетворення на формат radix-64.

Компонент підписи входять такі елементи: 1. Мітка даты-времени. Час створення підписи 2. Профіль повідомлення. 160-битоавый профіль повідомлення, створений з допомогою SHA-1 і шифрований з допомогою особистого ключа підписи відправника (KRа). Профіль обчислюється для мітки даты-времени підписи, пов’язаної конкатенацией з порцією даних компонента повідомлення. Включення мітки датичасу підписи на профіль забезпечує захисту від атак відтворення повідомлення. Виняток імені файла і мітки даты-времени компонента повідомлення гарантує, що отделённая підпис буде зацікавлений у точності збігатися за підписом, доданої в префікс повідомлення. Відокремлені підписи обчислюються для файла, у якому ніяких полів заголовка повідомлення. 3. Провідні два октету профілю повідомлення. Щоб якось забезпечити одержувачу можливість визначити, відповідний чи відкритий ключ використовувався для шифрування профілю повідомлення з єдиною метою аутентифікації, проводиться порівняння цих двох октетів відкритого тексту вихідного профілю з першими двома октетами дешифрованного профілю. Ці октети також служать 16-битовой послідовністю, використовуваної для перевірки повідомлення. 4. Ідентифікатор відкритого ключа відправника. Ідентифікує відкритий ключ, який має для дешифрування профілю повідомлення й, отже, ідентифікує особистий ключ, який використовували для шифрування профілю сообщения.

Компонент повідомлення й необов’язковий компонент підписи може бути стиснуті з допомогою ZIP і може бути зашифровані з допомогою сеансового ключа.

Компонент сеансового ключа включає сеансовый ключ і ідентифікатор відкритого ключа одержувача, використовуваний відправником для шифрування даного сеансового ключа. Весь блок зазвичай перекладатися в формат radix-64. Переклад в формат radix-64 використовується для сумісності лише на рівні електронної пошти. Сервіс аутентифікації передбачає, що ми шифруем лише профіль повідомлення (цифрова підпис), сервіс конфіденційності передбачає, що ми шифруем саме повідомлення (сеансовым ключем) та підпис (за наявності останньої), таким чином частину або весь вихідний блок повідомлення є потік довільних 8-битовых байтів. Проте багато хто системи електронної пошти використовувати лише блоки, які з символів тексту ASCII. Щоб задовольнити такому обмеження, PGP забезпечує сервіс конвертування сирого 8-битового двоичного потоку в потік друкованих символів ASCII. І тому використовується схема конвертування radix-64.

2. 2. Система S/MIME.

Система S/MIME (Secure/Multipurpose Internet Mail Extension — захищені багатоцільові розширення електронної пошти) є удосконаленням з погляду захисту стандарту формату MIME електронної пошти в Internet, побудованим на використанні технології RSA Data Security. Существуют підстави вважати, що S/MIME стане стандартом комерційного і промислового використання, тоді як PGP залишиться альтернативою за захистом особистої електронної пошти більшості індивідуальних пользователей.

Стандарт MIME є розширенням базового стандарту RFC 822, покликаним вирішити певні проблеми були котрі прагнуть перебороти обмеження протоколу SMTP чи деякого іншого протоколу передачі пошти, і RFC 822. Обмеженнями протоколу SMTP, які вирішує MIME являются:

1. SMTP Демшевського не дозволяє передавати виконувані файли та інші об'єкти у двоичном форматі. Є низка схем перетворення двійкових файлів в текстові (до них належить Uuencode/Uudecode для UNIX), які потім можна використовувати різними поштовими системами SMTP/ Одначе жодна з цих схем перестав бути стандартом.

2. SMTP Демшевського не дозволяє зраджувати текстові дані, які включають символи національних языков.

3. Шлюзи SMTP, виконують трансляцію кодів ASCII в коди EBCDIC і навпаки, може мати різні таблиці перекладу, що обертається проблеми трансляції. За таких недоліків технічні специфікації MIME включають такі элементы:

1. Визначається п’ять нових полів заголовка повідомлення, що потенційно можуть входитимуть у заготовок RFC 822. Ці поля несуть у собі інформацію про тілі сообщения.

2. Визначається кілька форматів вмісту, котрі задають стандарти уявлення документів мультимедіа в повідомленнях електронної почты.

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

Стандарт MIME визначає п’ять полів заголовка повідомлення, будь-які або всі у тому числі можна включати в заголовок RFC 822: MIME-Version (версія MIME). Відповідний параметр повинен мати значення 1.0. Це полі вказує, що відповідає стандартам RFC 2045 і 2046. Content-Type (тип вмісту). Описує дані, помещённые в тіло повідомлення, досить докладно у тому, щоб агент одержувача зміг вибрати відповідний агент чи механізм, дозволяє уявити отримані дані користувачеві чи обробити їх якимось іншим відповідним чином. Content-Transfer-Encoding (кодування переданого змісту). Вказується тип перетворення, який використовувався у тому, аби уявити тіло сполучення вигляді, прийнятному для пересилки поштою. Сontent-ID (ідентифікатор вмісту). Служить у тому, щоб унікальним чином ідентифікувати об'єкти MIME серед безлічі контекстів. Content-description (опис вмісту). Текстові описи об'єкта в тілі повідомлення; корисно тоді, щоб має форму, недоступну для прочитання (наприклад, звукові дані). Будь-яка реалізація, принаймні, повинна підтримувати обробку полів MIMEVersion, Content-Type і Сontent-Transfer-Encoding.

Формирование об'єкта envelopedData (упаковані дані). Під час підготовки об'єкта envelopedData MIME потрібно виконати такі действия:

1. Генерується псевдослучайный сеансовый ключ конкретної алгоритму симетричній схеми шифрування (RC2/40 чи 3DES).

2. До кожного одержувача сеансовый ключ шифрується з допомогою відкритого ключа одержувача і RSA.

3. До кожного одержувача готується блок даних, званий RecipientInfo.

(інформація для одержувача), у якому сертифікат відкритого ключа відправника, ідентифікатор алгоритму, який використовувався для шифрування сеансового ключа, і шифрований сеансовый ключ.

4. Вміст повідомлення шифрується з допомогою сеансового ключа.

Блоки RecipientInfo, що їх слід шифроване вміст повідомлення, разом становлять блок envelopedData. Цю інформацію потім кодується в форматі base64 (radix-64). Приклад такого файла:

Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m.

Rfvbn765BghyHhUjfewqwnvdCDC7.

Формирование об'єкта signedData (підписані данные).

1. Вибирається алгоритм створення профілю повідомлення (SHA чи MD5).

2. Обчислюється профіль повідомлення (значення хэш-функции) для вмісту, що має бути подписано.

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

4. Готується блок, званий SignedInfo (інформація що підписала боку), у якому сертифікат відкритого ключа що підписала документ боку, ідентифікатор алгоритму, який використовувався для шифрування профілю повідомлення й шифрованого профілю сообщения.

Об'єкт signedData формується з низки блоків, які включають ідентифікатор алгоритму створення профілю повідомлення, саме подписываемое повідомлення блок SignerInfo. Усе це інформація кодується в base64. Приклад такого повідомлення (з исключёнными заголовками RFC 822):

Content-Type: application/pkcs7-mime; smime-type=signed-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m.

Rfvbn765BghyHhUjfewqwnvdCDC7.

Открытое підписаний сообщение.

Відкрите підписаний повідомлення виходить тоді, коли для вмісту використовується тип multipart і підтип signed. Повідомлення типу multipart/signed включає дві части.

Перша частина то, можливо будь-якого типу MIME, але мусить бути підготовлена те щоб вона змінено їсти дорогою прямування джерела до адресата. Це означає, що й перша частина не представленій у 7-битовой кодуванні, то дані треба кодувати в формат base64. У першій частині розташовується відкритий текст сообщения.

Друга частина є отделённую підпис. Вона формується за алгоритмом об'єкта signedData. Через війну створюється об'єкт в форматі signedData, полі вмісту якого виявляється порожнім. Далі ця об'єкт кодується в формат base64, щоб стати рештою многокомпонентного повідомлення. Для типу MIME цієї другої частини вибирається значення application, а підтипу — pkcs7-signature. Приклад такого сообщения:

Content-Type: multipart/signed;

Protocol="application/pkcs7- signature";

Micalg=shal; boundary=boundary42.

— boundary42 Content-Type: text/plain.

Это відкритий текст підписаного сообщения.

— boundary42.

Content-Type: application/pkcs7- signature; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m.

Rfvbn765BghyHhUjfewqwnvdCDC7.

— boundary42 -;

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

Криптографические алгоритми. У таблиці подано писав криптографічні алгоритми, використовувані у системі S/MIME. У S/MIME прийнята термінологія, запропонована у документі RFC 2119 і що дозволяє вказати рівня вимог. ОБОВ’ЯЗКОВО (MUST). Визначення є абсолютною вимогою специфікації. Будь-яка реалізація повинна мати це властивість чи функцію, аби відповідати даної специфікації. РЕКОМЕНДУЄТЬСЯ (SHOULD). У конкретному оточенні можуть існувати причини ігнорувати це властивість чи функцію, але рекомендується, щоб реалізація усе ж таки мала відповідне властивість чи функцію. |Функція |Вимога | |Створення профілю |ОБОВ'ЯЗКОВА підтримка SHA-1 і MD5 | |повідомлення, | | |використовуваного при |РЕКОМЕНДУЄТЬСЯ використання SHA-1 | |формуванні | | |цифрового електронного підпису. | | |Шифрування профілю |Для агентів посилання і прийому ОБОВ’ЯЗКОВА підтримка DSS | |повідомлення для |Для агента посилання РЕКОМЕНДУЄТЬСЯ підтримка шифрування RSA | |формування |Для агента прийому РЕКОМЕНДУЄТЬСЯ підтримка верифікації | |цифрового електронного підпису |підписів RSA із довжиною ключа від 512 до 1024 бітов. | | |Для агентів посилання і прийому ОБОВ’ЯЗКОВО підтримка | |Шифрування |алгоритму Диффи-Хеллмана. | |сеансового ключа для|Для агента посилання РЕКОМЕНДУЄТЬСЯ підтримка шифрування RSA | |передачі з |із довжиною ключа від 512 до 1024 бітов. | |повідомленням |Для агента прийому РЕКОМЕНДУЄТЬСЯ підтримка дешифрування RSA| |Шифрування сообщения|Для агента посилання РЕКОМЕНДУЄТЬСЯ підтримка шифрування | |передачі з |tripleDES і RC2/40. | |використанням |Для агента прийому ОБОВ’ЯЗКОВА підтримка дешифрування | |сеансового ключа |tripleDES і РЕКОМЕНДУЄТЬСЯ підтримка дешифрування RC2/40. |.

S/MIME об'єднує три алгоритму, використовують відкриті ключ. Стандарт цифрового електронного підпису (алгоритм DSS) є кращим алгоритмом створення цифрового електронного підпису. Кращим алгоритмом шифрування сеансовых ключів в S/MIME називається алгоритм Диффи-Хеллмана, але вони в S/MIME використовується варіант алгоритму Диффи-Хеллмана, який би шифрование/дешифрование і знаний як алгоритм Эль-Гамаля. Як альтернативи як підписів, так шифрування сеансовых ключів може використовуватися алгоритм RSA. Для шифрування повідомлень рекомендується «потрійний» DES з трьома ключами (tripleDES), але будь-яка гнучка реалізація повинна підтримувати 40-битовую версію алгоритму RC2. Останній є дуже слабким алгоритмом шифрування, зате відповідає експортним вимогам США.

3. Протоколи SSL і TLS.

3.1. Архітектура SSL.

Протокол SSL покликаний забезпечити можливість надійний захист наскрізний передачі з допомогою протоколу TCP. SSL є не один протокол, а через два рівня протоколів. Протокол записи SSL (SSL Record Protocol) забезпечує базовий набір засобів захисту, застосовуваних протоколами вищих рівнів. Ці цифри, зокрема, може використовувати протокол передачі гіпертекстових файлів (HTTP), покликаний забезпечити обмін даними при взаємодії клієнтів — і серверів Web. Частиною SSL не рахуються й три протоколу вищого рівня: протокол квитирования встановлення зв’язку (Handshake Protocol), протокол зміни параметрів шифрування (Change Cipher Spec Protocol) і протокол сповіщення (Alert Protocol). Ці протоколи служать керувати обміном даними SSL.

Стік протоколів SSL.

Між будь-який парою які обмінюються інформацією сторін (наприклад, додатків типу HTTP імені клієнта й серверу) можна встановити багато захищених сполук. Теоретично між сторонами можна встановити і кілька одночасно існуючих сеансів, але практично таку можливість не використовується. Поєднання (connection) — транспорт, який би сервіс деякого підходящого типу (SMTP, HTTP тощо.) Кожне з'єднання асоціюється лише з однією сеансом. Сеанс (session). Сеанс SSL — це зв’язок між клієнтом і сервером. Сеанси створюються протоколом квитирования SSL (SSL Handshake Protocol). Сеанс визначає набір параметрів криптографічного захисту, які можуть опинитися використовуватися кількома сполуками. Сеанси дозволяють уникнути необхідності ведення переговорів встановити параметрів захисту кожному за нового соединения.

3.2. Протокол записи SSL.

Протокол записи SSL (SSL Record Protocol) забезпечує підтримку двох наступних сервісів для сполук SSL. • Конфіденційність. Протокол квитирования SSL (SSL Handshake Protocol) визначає загальний клієнтові і серверу секретний ключ, використовуваний алгоритмом традиційної схеми для шифрування даних, переданих за протоколом SSL. • Цілісність повідомлень. Крім забезпечення конфіденційності, протокол квитирования SSL визначає загальний секретний ключ для обчислення значень MAC (Message Authentication Code — код автентичності сообщения).

Порядок відправки данных:

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

2. За необхідності виконує стиснення данных;

3. Застосовує алгоритм обчислення MAC;

4. Шифрує дані (MAC +стислий сообщение);

5. Додає заголовок.

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

При обчисленні коду автентичності повідомлення використовується спеціальна схема обчислення MAC, у якій використовується алгоритм хэширования MD5 чи SHA-1.

Стислий повідомлення разом із доданим щодо нього значенням MAC шифрується. Використовувані алгоритми шифрування: |Блокове шифрування |Поточное шифрування | |Алгоритм |Розмір ключа |Алгоритм |Розмір ключа | |IDEA |128 |RC4−40 |40 | |RC2−40 |40 |RC4−128 |128 | |DES-40 |40 | | |DES |56 | | |3DES |168 | | |Fortezza |80 | |.

Що стосується застосування алгоритмів поточного шифрування шифруються лише стислий повідомлення доданий щодо нього значення MAC.

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

Завершальним кроком у роботі протоколу записи SSL є створення заголовка, що складається з наступних полей.

• Тип вмісту (8 бітов). Визначає протокол лежачого вище рівня, з допомогою якого має оброблятися даний фрагмент.

• Головний номер версії (8 бітов). Вказує головний номер версії використовуваного протоколу SSL. Для SSLv3 це полі містить значення 3.

• Додатковий номер версії (8 бітов). Вказує додатковий номер версії застосовуваного протоколу SSL. Для SSLv3 це полі містить значення 0.

• Довжина стиснутого фрагмента (16 бітов). Довжина в байтах даного фрагмента відкритого тексту (чи стиснутого фрагмента при стисканні). Максимально дозволене значення одно 2¹⁴ + 2048.

Для типу вмісту визначено значення change_cipher_spec, alert, handshake і application_data. Перші три значення позначають протоколи стека SSL.

3. 3. Протокол зміни параметрів шифрования.

Протокол зміни параметрів шифрування (Change Cipher Spec Protocol) генерує однобайтовое повідомлення, що містить значення 1. Єдиною завданням цих слів є вказівку розпочати копіювання параметрів стану очікування в поточний стан, що зумовлює оновленню комплекту шифрів, що використовуються даного соединения.

3. 4. Протокол извещения.

Протокол сповіщення (Alert Protocol) призначений передачі інший що у обміні даними боці сповіщень, що стосуються роботи SSL. Як і такі іншого докладання, котрий використовує SSL, повідомлення протоколу сповіщення точно як і стискуються і шифруються відповідно до параметрами поточного состояния.

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

У протоколі сповіщення існує 5 сповіщень, вказують на неустранимую помилку і наявність 7 сповіщень не вказують на неустранимую ошибку.

3. 5. Протокол квитирования.

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

Що стосується протоколом квитирования генерується кілька повідомлень, якими обмінюються клієнт і сервер. Будь-яке таке повідомлення містить три наступних поля.

• Тип (1 байт). Вказує одне із 10 допустимих типів сообщения.

• Довжина (3 байта). Довжина сполучення байтах.

• Вміст (> 1 байта). Параметри, які з повідомленням такого типу. У вмісті може перебуває по кілька полів, у кожному з яких перебувають элементы.

1-ый етап — визначення характеристик захисту. Процес ініціюється клієнтом, що повідомлення серверу client_hello, сервер відповідає повідомленням server_hello з обраними параметрами, доступними клієнту. Тип повідомлення: client-hello. |Назва поля|Характеристика поля | |Версія |Найвищий номер версії SSL, підтримуваний клієнтом. | |Випадкове |Генерируемая клієнтом випадкова структура, яка містить 32-битовую | |значення |мітку даты/времени і 28 байтів, отриманих з допомогою захищеного | | |генератора випадкових чисел. Ці значення використовують як | | |оказій під час обміну ключами з метою захисту від атак | | |відтворення. | |Комплект |Список, у якому набори криптографічних алгоритмів, | |шифрів |підтримуваних клієнтом, перелічені у порядку спаду їх | | |пріоритету. Кожен елемент списку (кожен комплект шифрів) | | |визначає алгоритм обміну ключами для схем традиційного | | |шифрування, обчислень значень MAC та інші параметри | | |шифрування. Сервер в server_hello має визначити будь-якої | | |комплект шифрів. | |Метод стискування |Список методів стискування, підтримуваних клієнтом. Сервер в | | |server_hello має визначити метод стискуванні з доступних по | | |списку. | |Идентификатор|Идентификатор перемінної довжини для даного сеансу. Ненульове | |сеансу |значення говорить про намір клієнта оновити параметри | | |наявного сполуки або створити нове з'єднання у межах того | | |ж сеансу. Нульове значення вводиться тоді, коли клієнт має наміру | | |створити нове з'єднання з нового сеансі. |.

2-й етап — Аутентификация серверу та обмін ключами сервера.

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

Потім за необхідності можна відправити повідомлення server_key_exchange (обмін ключами серверу). Відправлення такого повідомлення не потрібно у разі: (1) коли сервер відправив сертифікат для методу Диффи-Хеллмана з фіксованими параметрами чи (2) коли пропонується використовувати схему обміну ключами RSA. Повідомлення server_key_exchange необхідна за випадках, коли використовуються такі схеми. • Анонімне метод Диффи-Хеллмана. • Метод Диффи-Хеллмана з одноразовими параметрами. Повідомлення містить таку ж три параметра, як у разі анонімного методу Диффи-Хеллмана, і ще підпис тих параметрів. • Обмін ключами за схемою RSA, коли використовує RSA сервер має ключ RSA лише підписи. • Fortezza.

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

Останнім (і єдиним обов’язковим) повідомленням другого етапу є повідомлення server_done, яким сервер сповіщає про завершення фази вітання серверу через відправки ним усіх відповідних повідомлень. Це немає параметрів. Після відправки цих слів сервер перетворюється на режим очікування відповіді клиента.

3-й етап — Аутентификация імені клієнта й обмін ключами клиента.

Отримавши повідомлення server_done, клієнт повинен переконатися, що сервер надав дійсний сертифікат (якщо це потрібно) І що параметри повідомлення server_hello прийнятні. Якщо перевірка завершується успішно, клієнт оправляє серверу такі повідомлення. 1. Якщо сервер запросив сертифікат, клієнт починає даний етап з виходу серверу повідомлення certificate. Якщо в клієнта підходящого сертифіката немає, клієнт відправляє замість нього повідомлення no_certificate (немає сертифіката). 2. Наступним йде повідомлення client_key_exchange (обмін ключами клієнта), Вміст цих слів залежить вибраного методу обміну ключами і може бути таким. • RSA. Клієнт генерує 48-байтовый попередній головний ключ і шифрує його з допомогою відкритого ключа з сертифіката серверу чи з допомогою тимчасового ключа RSA з повідомлення server_key_exchange. Цей попередній ключ дозволяє обчислити головний ключ. • Метод Диффи-Хеллмана з одноразовими параметрами, чи анонімний метод Диффи-Хеллмана. Вирушають відкриті параметри клієнта для методу ДиффиХеллмана. • Метод Диффи-Хеллмана з фіксованими параметрами. У разі відкриті параметри клієнта для методу Диффи-Хеллмана вже були у повідомленні certificate, тому зміст цього повідомлення виявляється порожнім. • Fortezza. Вирушають параметри клієнта для алгоритму Fortezza. Насамкінець цього етапу клієнт може відправити повідомлення certificate_verify (перевірка сертифіката), щоб забезпечити засоби прямої верифікації сертифіката клієнта. Це вирушає за сертифікатом клієнта, які підтримують підпис (тобто. за будь-яким сертифікатом клієнта, крім, які містять параметри Диффи-Хеллмана з фіксованими параметрами). Повідомлення включає підпис хэш-кода попереднього сообщения.

4-ый етап — завершення створення защищённого соединения.

Клієнт відправляє повідомлення change_cipher_spec (зміна параметрів шифрування) і копіює параметри шифрування з поля «комплект шифрів «стану очікування на полі поточного стану. Зверніть увагу, що це повідомлення не вважається частиною протоколу квитирования, а відсилається в рамках протоколу зміни параметрів шифрування (Change Cipher Spec Protocol). У відповідь клієнт негайно відправляє повідомлення finished, шифроване новим алгоритмом з новими ключами і секретними значеннями. Повідомлення finished підтверджує, що згадані процеси обміну ключами і аутентифікації завершилися успішно. Вміст повідомлення finished є результат конкатенації наступних двох значень хэш-кода. MD5 (master_secret || pad₂ || MD5 (handshake_messages || Sender || master_secret || pad_l)), SHA (master_secret || pad₂ || SHA (handshake_messages || Sender || master_secret || pad_l)), де Sender — код, який би те що, що відправником є клієнт, handshake_messages — всі дані повідомлень квитирования, крім даного повідомлення. master_secret — спільно застосовуваний головний секретний ключ, представляє собою одноразово що використовується 48-байтовое занчение (384 біта), генеровану для даного сеансу під час защищённого обміну данными.

У у відповідь ці дві повідомлення сервер посилає своє повідомлення change_cipher_spec, переводить параметри шифрування стану очікування в поточний стан і посилає своє повідомлення finished. У цьому процес квитирования завершується, і тепер клієнт і сервер можуть почати обмін даними лише на рівні приложения.

3. 6. Створення головного секретного ключа.

Створення головного ключа і двох етапів. У першому етапі узгоджується значення попереднього головного ключа (pre_master_secret), а другою обидві сторони обчислюють значення головного ключа (master_secret). Для передачі одна одній значення pre_master_secret в сторін є два варіанта. • RSA. Генерований клієнтом 48-байтовый ключ pre_master_secret шифрується з допомогою відкритого ключа RSA серверу та вирушає клієнтом серверу. Сервер дешифрує отриманий шифрований текст з допомогою свого особистого ключа і відновлює значення pre_master_secret. • Метод Диффи-Хеллмана. І клієнт, і сервер генерують відкриті ключі для алгоритму Диффи-Хеллмана. Обмінявшись цими ключами кожна сторона виконує певні обчислення методом Диффи-Хеллмана, у яких виходить спільно що використовується значення pre_master_secret. Тепер обидві сторони можуть обчислити значення master_secret за схемою: master_secret = MD5 (pre_master_secret ||.

SHA («A «|| pre_master_secret || ClientHello. random || ServerHello. random)) ||.

MD5 (pre_master_secret ||.

SHA («BB «|| pre_master_secret || ClientHello. random || Server.

Hello.random)) ||.

MD5 (pre_master_secret ||.

SHA («CCC «|| pre_master_secret || ClientHello. random ||.

ServerHello.random)), де ClientHello. random і ServerHello. random є значеннями оказій, які входять у оригінальні повідомлення вітання сторін (полі «випадкове значение»).

3. 7. Генерування криптографічних параметров.

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

key_block = MD5 (master_secret ||.

SHA («A «|| master_secret || ServerHello. random || ClientHello. random)) ||.

MD5 (master_secret ||.

SHA («BB «|| master_secret || Server Hello, random || ClientHello. random)) ||.

MD5 (master_secret ||SHA («CCC «|| master_secret || ServerHello. random || ClientHello. random)) || … Процедура виконується до того часу, поки що не сгенерирована послідовність достатньої довжини. Ця алгоритмічна структура є псевдослучайную функцію. Значення master_secret можна розглядати, як инициализирующее значення з цією функції. Згенеровані клієнтом і сервером випадкові числа можна як значення модифікаторів (salt values), використовуваних із єдиною метою ускладнення криптоанализа.

3. 8. Що таке TLS та її на відміну від SSL. Протокол TLS є результат ініціативи IETF (Internet Engineering Task Force — проблемна група проектування Internet), метою якої є розробка стандарту SSL для Internet. Поточна версія проекту стандарту TLS дуже справляє враження SSLv3. Розглянемо різницю між TLS і SSLv3.

1. Схеми обчислень значень MAC цих протоколів відрізняються з двох параметрами: застосовуваному алгоритму й області даних, котрим обчислюється значення коду автентичності сообщения.

2. У TLS застосовується PRF функція. PRF функція служить щоб одержати невеликого за довжиною секретного значення, що слугує для генерування більш довгих блоків даних (використовуючи спеціальну схему розширення даних де використаний алгоритм HMAC), защищённых від атак на функції хэширования і обчислення значень коду автентичності повідомлення. Секретне значення виходить шляхом використання ж схеми розширення даних, але з алгоритмом MD5 чи SHA.

3. У TLS не сповіщення no_certificate, але визначено ряд додаткових кодів сповіщення (їх лише 12, 9 у тому числі означають неустранимую ошибку).

4. У TLS внесено всіх алгоритми симетричній схеми шифрування, крім Fortezza.

5. Повідомлення finished в TLS є хэш-код, розрахована з допомогою master_secret, попередніх повідомлень і мітки, идентифицирующей клієнт і сервер. Схема обчислення повідомлення finished відрізняється від схеми, яка у SSLv3. У TLS схеми така: PRF.

(master_secret, finished_label, MD5 (handshake_meassages) || SHA-1.

(handshake_messages)), де finished_label — рядок «client finished» клієнтові і «server_finished» для сервера.

6. Схема обчислення master_secret для TLS інша ніж у SSLv3.

7. У SSL байти заполнителя додаються до даних користувача, підлягає шифруванню, мінімально достатній кількості, достатньому у тому, щоб отримати загальну довжину даних для шифрування, кратну довжині блоку шифру. Що стосується TLS дозволяється додавати будь-яке число заповнювачів (до.

255 байтів включно), аби внаслідок довжина блоку даних вийшла кратною довжині блоку шифра.

4. Захист лише на рівні IP (мережевий уровень).

4. 1. Архітектура захисту лише на рівні IP IPSec забезпечує сервіс захисту лише на рівні IP, дозволяючи системі вибрати необхідні протоколи захисту, визначити алгоритм (алгоритми) для відповідного сервісу (сервісів) і значення будь-яких криптографічних ключів, необхідних запитаного сервісу. Для захисту використовується два протоколу: протокол аутентифікації, зазначений заголовком даного протоколу (заголовком аутентифікації АН), і комбінований протокол шифрования/аутентификации, певний форматом пакета при цьому протоколу (протоколу ESP). У разі забезпечуються такі види сервісу: • контроль доступу; • цілісність без встановлення сполук; • аутентификация джерела даних; • відторгнення відтворених пакетів (форма цілісності послідовностей); • конфіденційність (шифрування); • обмежена конфіденційність транспортного потоку. Що стосується ESP є дві варіанта: з і без використання опції аутентифікації. Як АН, і ESP мають можливість контролю доступу, заснованого на розподілі криптографічних ключів і потребу керувати транспортними потоками, що відносяться до цим протоколів защиты.

|Вид сервісу |AH |ESP (лише |ESP (шифрування і | | | |шифрування) |аутентификация) | |Контроль доступу |(|(|(| |Цілісність без встановлення |(| |(| |сполук | | | | |Аутентификация джерела даних |(| |(| |Сила відторгнення відтворених пакетів |(|(|(| |Конфіденційність | |(|(| |Обмежена конфіденційність | |(|(| |транспортного потоку | | | |.

Ключовим об'єктом у механізмах аутентифікації і конфіденційності для IP є захищена зв’язок (Security Association). Зв’язок є одностороннє ставлення між відправником і одержувачем, применяющим сервіс захисту до транспортному потоку. Сервіс захисту дає можливість для захищеного виділеного зв’язку використовувати або АН, або ESP, але ще не обидві ці можливості так одновременно.

У кожному пакеті IP захищена зв’язок однозначно ідентифікується адресою пункту призначення до заголовку IPv4 чи IPv6 і індексом параметрів захисту (дає возможност ьвыбрать захищеним зв’язок якою повинен оброблятися отриманий пакет) у вкладеному заголовку розширення (АН чи ESP).

Заголовки АН і ESP підтримують два режиму використання: транспортний і тунельний. Дамо короткий оглядом цих режимів. Транспортний режим. Транспортний режим забезпечує захист передусім на протоколів вищого рівня. Це означає, що захист транспортного режиму поширюється на корисний вантаж пакета IP. Приклади включають сегмент TCP чи UDP, чи пакет протоколу ICMP, які безпосередньо над IP в стеці головного протоколу. Коли система використовує заголовки АН чи ESP над IPv4, корисним вантажем є дані, зазвичай що міститимуться відразу після заголовка IP. Для IPv6 корисним вантажем є дані, зазвичай такі після заголовка IP і розвитком усіх наявних заголовків розширень IPv6, за можливим винятком заголовка параметрів адресата, що теж може підлягати захисту. ESP у транспортній режимі шифрує і, коли потрібно, ідентифікує корисний вантаж IP, але з заголовок IP. АН у транспортній режимі ідентифікує корисний вантаж IP і пояснюються деякі частини заголовка IP. Тунельний режим. Тунельний режим забезпечує захист всього пакета IP. Після додавання до пакету IP полів АН чи ESP весь пакет, разом із полями захисту, сприймається як корисний вантаж деякого нового «зовнішнього «пакета IP з новим зовнішнім заголовком IP. Весь оригінальний, чи внутрішній, пакет при цьому пересилається через «тунель «від однієї точки мережі IP в іншу, і одне із маршрутизаторів по дорозі неспроможна перевірити внутрішній заголовок IP. Оскільки оригінальний пакет инкапсулирован у новий, більший пакет може мати зовсім інші адреси джерела і адресата, що посилює захист. Тунельний режим використовується тоді, коли той чи обидва кінці захищеного виділеного зв’язку є шлюзами захисту, наприклад брандмауэрами чи маршрутизаторами, що базуються на IPSec. З використанням тунельного режиму системи у мережах за брандмауэрами можуть здійснювати захищений обмін даними не залучаючи IPSec. Незахищені пакети, які генеруються такими системами, зв’язуються по тунелям, прокладеними через зовнішні мережі з допомогою тунельного режиму захищеного виділеного зв’язку, встановленого програмним забезпеченням IPSec в брандмауэре чи захищеному маршрутизаторе за українсько-словацьким кордоном локальної сети.

4. 2. Заголовок аутентифікації (AH). 4. 2. 1. Структура заголовка. Заголовок аутентифікації (АН) забезпечує підтримку цілісності даних, і аутентифікації пакетів IP. Властивість цілісності даних гарантує неможливість непомітної модифікації вмісту пакета їсти дорогою прямування. Функція аутентифікації дає можливість кінцевої системі чи мережному влаштуванню ідентифікувати користувача чи додаток і відфільтрувати трафік, і навіть захисту від найпоширеніших сьогодні в Internet атак із заміною мережевих адрес. Заголовок АН також захищає від атак відтворення повідомлень. Заголовок аутентифікації складається з таких полів |Наступний заголовок |Довжина корисного вантажу |Зарезервоване | |Індекс параметрів захисту | |Порядковий номер | |Дані аутентифікації (зміною довжини) |.

Заголовок аутентифікації IPSec.

. Наступний заголовок. Ідентифікує тип заголовка, наступного безпосередньо за даним заголовком.

. Довжина корисного вантажу (8 бітов). Довжина заголовка аутентифікації в 32- бітових словах, зменшена на 2.

. Зарезервоване (16 бітов). Для майбутнього использования.

. Індекс параметрів захисту (32 біта). Ідентифікує захищену связь.

. Порядковий номер (32 біта). Значення лічильника, для сервісу захисту від воспроизведения.

. Дані аутентифікації (перемінної довжини). Поле перемінної довжини, що містить MAC для даного пакета. Атаки відтворення повідомлень полягають у тому, що супротивник може отримати примірник посвідченого пакета і потім пред’явити його гаданому адресата. Повторне отримання однакових засвідчених пакетів IP може якимось чином порушити сервіс чи мати вже інакші небажані последствия.

4. 2. 2. Використання AH у транспортній і туннельном режиме.

У цьому вся підрозділі ми розглянемо сферу застосування аутентифікації, забезпечувана з допомогою протоколу АН, і розміщення заголовка аутентифікації у кожному з цих двох режимів. У цьому випадки IPv4 і IPv6 кілька различаются.

Для транспортного режиму АН із застосуванням IPv4 дані АН розміщуються одразу після оригінального заголовка IP і для корисним вантажем IP (наприклад, сегментом TCP). Аутентифікації підлягає весь пакет, за винятком змінюваних полів в заголовку IPv4, які обнуляются для обчислення значення MAC. | | |Оригінальний |AH |TCP |Дані | |заголовок IP | | | |.

У IPv6 дані АН розглядаються як корисний вантаж наскрізний передачі; тобто. перевірка та обробка цих даних проміжними маршрутизаторами не передбачається. Тому дані АН розміщуються після базового заголовка IPv6 і заголовків розширень транзиту, маршрутизації і фрагментації. Заголовок розширення параметрів адресації може розміщатися до або ж після заголовка АН — залежно від вимог семантики. Знову ж, аутентификация передбачається для пакета, крім змінюваних полів, які обнуляются для обчислення значення MAC. | | |Оригинальный|Транзит, |AH |Адресація |TCP |Дані | |заголовок IP|адресация, | | | | | | |маршрутизаци| | | | | | |я, | | | | | | |фрагментація| | | | |.

Для тунельного режиму АН засвідчується весь оригінальний пакет IP, a заголовок АН вставляється між оригінальним заголовком IP і новим зовнішнім заголовком IP. Внутрішній заголовок IP несе адреси оригінальних джерела і адресата, тоді як зовнішній заголовок IP може містити цілком інші адреси IP (наприклад, адреси брандмауэров чи інших шлюзів захисту). У туннельном режимі весь внутрішній пакет IP, включаючи весь внутрішній заголовок IP, захищається засобами АН. Зовнішній заголовок IP (а разі IPv6 і його зовнішні заголовки розширень IP) захищається з виключенням змінюваних і непрогнозованих за значенням полей.

| | |Новий заголовок|AH |Оригінальний |TCP |Дані | |IP | |заголовок IP | | |.

IPv6.

4. 3. Протокол ESP.

4. 3. 1. Формат пакета ESP Поля пакета ESP. • Індекс параметрів захисту (32 біта). Ідентифікує захищену зв’язок. • Порядковий номер (32 біта). Значення лічильника, що забезпечує функцію захисту від відтворення, як у разі для АН. • Корисний вантаж (перемінної довжини). Це сегмент транспортного рівня (в транспортному режимі) чи пакет IP (в туннельном режимі), який захищається шифруванням. • Заповнювач (0−255 байтів). • Довжина заполнителя (8 бітов). Вказує число байтів заполнителя, безпосередньо попереднього даному полю. • Наступний заголовок (8 бітов). Ідентифікує тип даних, що є на полі даних корисного вантажу, з допомогою ідентифікації першого заголовка цього корисного вантажу (наприклад, заголовка розширення IPv6 чи протоколу верхнього рівня, такого як TCP). • Дані аутентифікації (перемінної довжини). Поле перемінної довжини, що містить код ICV (Integrity Check Value — код контролю цілісності), який вираховується для пакета ESP без поля даних аутентификации.

Поле заполнителя призначено до таких цілей. • Якщо алгоритм шифрування вимагає, щоб довжина відкритого тексту була кратна деякому цілому числу байтів (наприклад, довжині одного блоку блокового шифру), полі заполнителя служить у тому, щоб доповнити відкритий текст (складаний з полів корисного вантажу, заполнителя, довжини заполнителя і наступного заголовка) до потрібної довжини. • Формат ESP вимагає, щоб поля довжини заполнителя і наступного заголовка були выровнены по правому краю в 32-битовом слові. Це еквівалентно вимозі, щоб шифрований текст мав довжину, кратну 32 бітам. Поле заполнителя призначено у тому, щоб зробити таке вирівнювання. • Додаткове заповнення можна використовувати тоді, коли потрібно забезпечити часткову конфіденційність для транспортного потоку, щоб приховати справжню довжину корисного груза.

4. 3. 2. Шифрування і алгоритми аутентификации.

Сервіс ESP передбачає шифрування полів корисного вантажу, заполнителя, довжини заполнителя і наступного заголовка.

Наявні сьогодні специфікації вимагають, щоб будь-яка реалізація підтримувала використання алгоритму DES як СВС (режим зчеплення шифрованих блоків. Інші алгоритм які можуть застосовуватися для сервісу ESP: • «потрійний «DES із трьома ключами, • RC5, • IDEA, • «потрійний «IDEA із трьома ключами, • CAST, • Blowfish.

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

4. 3. 3. Транспортний режим ESP.

Транспортний режим ESP служить для шифрування і, коли потрібно, аутентифікації даних, пересланих за протоколом IP (наприклад, сегмента TCP). І тому режиму на випадку з IPv4 заголовок ESP розміщається у пакеті IP безпосередньо перед заголовком транспортного рівня (наприклад, TCP, UDP, ICMP), а концевик (trailer) пакета ESP (у якому поля заполнителя, довжини заполнителя і наступного заголовка) розміщається після пакета IP; якщо ж, використовується функція аутентифікації, то полі даних аутентифікації ESP додається після концевика ESP. Весь сегмент транспортного рівня разом із концевиком ESP шифруються. Аутентификация охоплює весь шифрований текст і заголовок ESP. | | | | |Оригинальный|Заголовок |TCP |Дані |Концевик ESP|Аутентификат| |заголовок IP|ESP | | | |репетування ESP |.

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

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

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

4. 3. 4. Тунельний режим ESP.

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

IPv4.

| | | |.

|Аутентификатор ESP | |IPv6.

Тоді як транспортний режим адресований захисту сполук між вузлами, підтримують сервіс ESP, тунельний режим виявляється корисним в конфігурації, яка припускає наявність брандмауэра чи іншого шлюзу захисту, покликаного забезпечити захисту надійної внутрішньої мережі від зовнішніх мереж. Що стосується туннельным режимом шифрування використовується обмінюватись тільки між зовнішнім вузлом і шлюзом захисту чи торгівлі між двома шлюзами захисту. Це розвантажує вузли внутрішньої мережі, позбавляючи їх потреби шифрування даних, і спрощує процедуру розподілу ключів, зменшуючи число необхідних ключів. З іншого боку, такий ускладнює проблему аналізу потоку повідомлень, спрямованих конкретному адресата. Розглянемо випадок, коли зовнішній вузол сполучається з вузлом внутрішньої мережі, захищеної брандмауэром, і коли ESP використовується зовнішнім вузлом і брандмауэром. Тоді при пересилання сегмента транспортного рівня від зовнішнього вузла до вузлу внутрішньої мережі обіцяє такі дії. 1. Джерело готує внутрішній пакет IP із зазначенням адреси пункту призначення, що є вузлом внутрішньої мережі. До цього пакету як префікса додається заголовок ESP. Потім пакет і концевик ESP шифруються і до результату може бути додано дані аутентифікації. Отриманий блок полягає в зовнішній пакет IP з новими заголовком IP (базовий заголовок плюс необов’язкові розширення, наприклад параметрів маршрутизації і транзиту для IPv6), у якому адресою пункту призначення є адресу брандмауэра. 2. Зовнішній пакет вирушає брандмауэру. Кожен проміжний маршрутизатор потрібно перевірити достовірність і обробити зовнішній заголовок IP і всі зовнішні заголовки розширень IP, залишивши шифрований текст незмінним. 3. Брандмауэр-адресат перевіряє і опрацьовує зовнішній заголовок IP і всі зовнішні заголовки розширень IP. Потім з урахуванням інформації індексу параметрів захисту у заголовку ESP брандмауэр дешифрує в інших частинах пакета, в результаті чого стає доступним внутрішній пакет IP як відкритого тексту. Цей пакет потім передається по внутрішньої мережі. 4. Внутрішній пакет іде через маршрутизатори внутрішньої сіті або безпосередньо до узлу-адресату.

4. 4. Комбінація защищённых связей.

Окрема захищена зв’язок може використовувати або протокол АН, або ESP, але ще не обидві ці протоколу одночасно. Проте, іноді конкретний потік обміну даними може вимагати і сервісу АН, і сервісу ESP. З іншого боку, конкретному потоку обміну даними може знадобитися сервіс IPSec для зв’язок між головними вузлами і той сервіс для зв’язку між шлюзами захисту, наприклад брандмауэрами. В усіх цих випадках одному потоку щоб одержати відновлення всього комплексу послуг IPSec потрібно кілька захищених зв’язків. Тут вводиться поняття пучка захищених зв’язків (security association bundle), що означає набір захищених зв’язків, у вигляді яких потоку має надаватися необхідне безліч послуг IPSec. У цьому захищені зв’язку в пучку можуть завершуватися у різних кінцевих точках.

Захищені зв’язку можуть бути в пучки такими двома способами.

. Транспортна суміжність. Застосування більше протоколу захисту одного пакету IP без тунелювання. Такий підхід до створення комбінації АН і ESP виявляється ефективним тільки одному рівня вкладення: подальші вкладення не дають додаткового виграшу, оскільки обробка виконується лише у інстанції —.

IPsec (кінцевого) получателя.

. Повторне туннелирование. Застосування кількох рівнів протоколів захисту з допомогою тунелювання IP. Такий підхід допускає безліч рівнів вкладення, оскільки тунелі можуть починатися і завершуватися у різних використовують IPsec вузлах мережі вздовж маршруту передачі данных.

Ці дві підходу можна поєднати (наприклад, організувавши частини туннельной захищеного виділеного зв’язку між шлюзами захисту транспортну захищену зв’язок між які перебувають по дорозі узлами).

Заключение

З розглянутих рівнів захисту потоку даних в Web і архітектури побудови мережі з урахуванням стека TCP/IP був зроблений огляд стандартів, що у час і забезпечувальних надёжную передачу даних (по e-mail), якщо що використовується нами програмне і апаратне забезпечення підтримує комплекс вимог, викладені у цих стандартах.

Отже, рекомендовані міри і кошти на захисту електронної переписки:

1. Сильні кошти аутентифікації, наприклад, технологія двухфакторной аутентификации.

2. Ефективне колег і адміністрування мережі. Йдеться побудові коммутируемой інфраструктури, заходи контролю доступу і фільтрації вихідного трафіку, закритті «дір» в програмне забезпечення з допомогою модулів- «латок» і регулярному його відновленні, установці антивірусних програм, тож що свідчить ином.

3. Криптографію, засновану на сильних криптоалгоритмах (Симетричні ;

RC4, RC5, CAST, DES, AES, оптимальна довжина ключа яких = 128 розрядів, асиметричні - RSA, Diffie-Hellman і El-Gamal, оптимальна довжина яких 2048 разряда.

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

5. Якщо вдалося поліпшити генератор, але осередки комп’ютера незахищеними, коли у яких побував сгенерированный ключ, гріш ціна такий безопасности.

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

7. Цей захід, яка складалася переважно використовується посилення захисту електронних комерційних операцій, може бути для захисту звичайній e-mail. Це побудова багаторівневої ешелонованої системи оборони, що полягає у реалізації захисту на кількох рівнях моделі OSI. Наприклад, якщо якісь докладання Web мають вбудовані протоколи захисту даних (для e-mail що можуть бути PGP чи S/MIME), використання IPSec дозволяє посилити цю защиту.

8. Слід зазначити, що SSL захищає листи тільки під час передачі і а то й використовуються інші засоби криптозахисту, то листи при зберіганні у скриньках і проміжних серверах перебувають у відкритому виде.

В цьому випадку треба використовувати наявні кошти шифрування прикладного рівня (S/MIME) чи сеансового рівня (IPSec), у якому реалізується шифрування всього пакета IP (чи TCP залежно від режима).

Источники информации:

1. Вільям Столингс, Криптографія і захист мереж: принципи і практика, 2-ге видання: перекл. з англійської - М,: Видавничий будинок «Вільямс», 2001. 2. Матеріали електронної бібліотеки InfoCity. (internet 3. Матеріали серверу internet.

———————————- Client_hello.

Server_hello.

certificate.

server_key_exchange.

certificate_request.

server_hello_done.

Change_cipher_spec.

finished.

Change_cipher_spec.

finished.

certificate.

client_key_exchange.

Sertificate_verify.

Удостоверяется крім змінюваних полей Удостоверяется крім змінюваних полей Удостоверяется крім змінюваних полів з нового заголовку IP.

Удостоверяется крім змінюваних полів з нового заголовку IP та її заголовках расширений Шифруется Удостоверяется Шифруется Удостоверяется Шифруется Шифруется Удостоверяется Удостоверяется.

Показати весь текст

Заповнити форму поточною роботою