Зміст.


Введення 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 - протокол захисту електронних транзакцій). HTTP
FTP
SMTP

HTTP
FTP
SMTP


S/MIME
PGP
SET
TCP

SSL
або TLS

Kerberos
SMTP
HTTP


TCP

UDP
TCP
IP/IPSec

IP

IP
Мережевий
рівень Транспортний рівень Рівень програми Розміщення
засобів захисту в стеку протоколів TCP/IP.2. Захист на рівні додатків.
2. 1. Система PGP.Сервіс PGP, якщо не розглядати управління ключами, складається
з п'яти функцій: аутентифікація, конфіденційності, стиску, сумісності
на рівні електронної пошти і сегментаціі.Рассмотрім коротку характеристику
функцій PGP.Функція
Використані алгоритми
Опис
Цифровий підпис
DSS/SHA
або RSA/SHA
За допомогою SHA-1 створюється хеш-код повідомлення. Отриманий таким чином
профіль повідомлення шифрується за допомогою DSS або RSA з використанням особистого ключа
відправника і включається в повідомлення.
Шифрування повідомлення
CAST або IDEA,
або «потрійний» DES c трьома ключами та алгоритмом Діффі-Хеллмана або RSA.
Повідомлення
шифрується за допомогою CAST-128 або IDEA, або 3DES з одноразовим сеансовий ключем,
генеруються відправником. Сеансовий ключ шифрується за допомогою алгоритму Діффі-Хеллмана
або RSA c використанням відкритого ключа одержувача і включається до
повідомлення.
Стиснення
ZIP
Повідомлення можна стиснути для зберігання або передачі, використовую
zip.
Совместімостьна рівні електронної пошти
Перетворення в формат radix-64
Щоб
забезпечити прозорість для усіх програм електронної пошти, шифрування
повідомлення можна перетворити в рядок ASCII, використовуючи перетворення у формат
radix-64.
Сегментація

Щоб задовольнити обмеженням максимального розміру
повідомлень, PGP виконує сегментацію і зворотну складання повідомлення.
Схема аутентіфікаціі.Обозначенія: Ка
- Сеансовий ключ, що використовується у схемі традиційного шифрування, KRа
- Особистий ключ А, що використовується в схемі шифрування з відкритим ключем, KUа
- Відкритий ключ А, що використовується в схемі шифрування з відкритим ключем, EP -
шифрування в схемі з відкритим ключем, DP - дешифрування в схемі з відкритим ключем, EC
- Шифрування у схемі традиційного шифрування, DC - дешифрування у схемі
традиційного шифрування, H - функція хешування, | | - конкатенація, Z - стиснення
за допомогою алгоритму zip, R64 - перетворення у формат radix-64 ASCII.Шагі: 1. Відправник
створює сообщеніе.2. Використовується алгоритм SHA-1, в результаті чого виходить
160-бітовий хеш-вектор сообщенія3. Отриманий хеш-вектор шифрується з
допомогою алгоритму RSA c використанням особистого ключа відправника, і результат додається
на початок сообщенія.4. Одержувач використовує RSA з відкритим ключем відправника,
щоб дешифрувати і відновити хеш-код.5. Одержувач генерує новий
хеш-код отриманого повідомлення і порівнює його з дешифрованими хеш-кодом. Якщо
хеш-коди збігаються, повідомлення вважається подлінним.Схема шифрування сообщенія.Шагі: 1.
Відправник генерує повідомлення та випадкове 128-бітове число, яке
виступає як сеансового ключа тільки для цього сообщенія.2. Повідомлення
шифрується за допомогою алгоритму CAST-128 (або IDEA, або 3DES) та даного сеансового
ключа.3. Сеансовий ключ шифрується за допомогою алгоритму RSA і відкритого ключа
одержувача і приєднаються до початку сообщенія.4. Одержувач використовує RSA c особистим
ключем, щоб дешифрувати і тим самим відновити сеансовий ключ.5. Сеансовий
ключ застосовується для дешифрування сообщенія.Схема використання обох служб
(підписи повідомлення за допомогою особистого ключа та його шифрування за допомогою сеансового
ключа). Відправник повідомлення: 1. Для повідомлення генерується підпис (hash-вектор,
зашифрований особистим ключем відправника об'єднується з відкритим текстом повідомлення) .2.
Підпис та відкритий текст повідомлення стискаються zip-ом3. Стислий відкритий
текст повідомлення і підпис шифруються за допомогою алгоритму CAST -128 (або IDEA,
або 3DES), а сеансовий ключ шифрується за допомогою RSA (або алгоритму Ель-Гамаля)
при цьому використовується відкритий ключ получателя.Получатель сообщенія1. Cеансовий
ключ дешифрується за допомогою особистого ключа получателя.2. За допомогою отриманого
сеансового ключа дешифрує сообщеніе3. Розпакування сообщенія4. Відкритим ключем відправника
дешифрує хеш-вектор і генерує новий хеш-вектор.5. Порівнює їх.
Якщо збігаються -> повідомлення не було ізменено.Ідентіфікатори ключей.Так як одержувач
повідомлення має можливість отримувати зашифровані та підписані повідомлення
від багатьох учасників листування, отже він повинен мати кілька пар
особистий/відкритий ключів. Для того, щоб одержувачу визначити який особистий ключ
(алгоритму RSA) треба використовувати для розшифровки сеансового ключа (алгоритму
CAST-128) він отримує ідентифікатор відкритого ключа (замість самого ключа пересилається
його ідентифікатор, так як сам відкритий ключ для RSA може мати довжину
в сотні десяткових розрядів). Ідентифікатор, що пов'язується з кожним відкритим ключем,
розміщується в молодших 64 розрядах ключа.Ідентіфікатор ключа потрібно і для
цифрового підпису PGP. Через те що відправник може скористатися одним
з декількох особистих ключів для шифрування профілю повідомлення, одержувач повинен
знати, який відкритий ключ йому слід використовувати. Тому розділ цифрового підпису
повідомлення включає 64-бітовий ідентифікатор відповідного відкритого ключа.
При отриманні повідомлення одержувач перевіряє, що ідентифікатор відповідає
відомому йому відкритого ключа відправника, а потім продовжує перевірку подпісі.Формат
переданого сообщенія.Сообщеніе
Підпис
Компонент сеансового ключа
Вміст




Дані
Мітка
дати-часу
Файл
Профіль повідомлення
Провідні
два октету профілю повідомлення
Ідентифікатор відкритого ключа відправника (KUa)
Мітка
дати-часу
Сеансовий ключ (Ks)
Ідентифікатор відкритого ключа одержувача
(Rub)


EkRa

EkUa

Операція
ZIP


Eкs


R64

ERUb - шифрування з використанням
особистого ключа користувача BEKRa - шифрування з використанням відкритого ключа
користувача АEКs - шифрування з використанням сеансового ключаZIP - функція
стиснення ZIPR64 - функція перетворення у формат 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
(опис вмісту). Текстові опису об'єкту в тексті листа; корисно тоді,
коли об'єкт має форму, недоступну для прочитання (наприклад, звукові дані). Будь-яка
реалізація, як мінімум, повинна підтримувати обробку полів MIME-Version,
Content-Type і Сontent-Transfer-Encoding. У S/MIME захист об'єкту MIME
забезпечується підписом, шифруванням або і тим, і іншим одночасно. Об'єктом
MIME може бути як усі повідомлення (за винятком його заголовків RFC 822) або,
у разі багатокомпонентного вмісту MIME, одне або декілька частин повідомлення.
Об'єкт MIME готується відповідно до звичайних правил підготовки повідомлень
MIME. Потім об'єкт MIME разом з деякими пов'язаними з ним даними захисту
(наприклад, ідентифікаторами алгоритму і сертифікатів) обробляється S/MIME,
щоб в результаті отримати те, що зазвичай називають об'єктом PKCS (Public-Key Cryptography
Specification - специфікація криптографії з відкритим ключем). З об'єктом
PKCS потім поводяться як з вмістом повідомлення, яке упаковують в MIME
(додаючи відповідні заголовки MIME). Крім типів вмісту стандарту
MIME, в стандарті S/MIME використовуються ряд нових типів вмісту, перераховані
в таблиці. Всі ці типи вмісту використовують позначення PKCS, опубліковані
RSA Laboratories і доступні для S/MIME.Тіп
Підтип
Параметр S/MIME
Опис
Multipart
(багатокомпонентний)
Signed (підписаний)

Відкрите підписане повідомлення
з двох частин: повідомлення і його підпису
Application (додаток)
 pkcs7-mime
signedData
Підписані
об'єкт S/MIME

pkcs7-mime
 envelopedData
Шифрувальний
об'єкт S/MIME

pkcs7-mime
 Degenerate signedData
Об'єкт, який містить лише сертифікати
відкритих ключів

pkcs7-signature
 -
Тип підпису, що є частиною повідомлення
типу multipart/signed

 pkcs10-mime
-
Повідомлення запиту реєстрації сертифіката.
Формування
об'єкта 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.p7mContent-Transfer-Encoding:
base64Content-Disposition: attachment; filename = smime.p7mRfvbn765BghyHhUjfewqwnvdCDC7Формірованіе
об'єкта signedData (підписані
дані) .1. Вибирається алгоритм створення профілю повідомлення (або SHA MD5) .2.
Обчислюється профіль повідомлення (значення хеш-функції) для вмісту, який
повинно бути подпісано.3. Профіль повідомлення шифрується за допомогою особистого ключа
сторони, що підписала документ.4. Готується блок, званий SignedInfo
(інформація підписала боку), що містить сертифікат відкритого ключа підписала
документ боку, ідентифікатор алгоритму, що використовувався для шифрування
профілю повідомлення та шифрованого профілю повідомлення. Об'єкт signedData формується
з ряду блоків, що включають ідентифікатор алгоритму створення профілю повідомлення,
саме підписується повідомлення і блок SignerInfo. Вся ця інформація кодується
в base64. Приклад такого повідомлення (з виключеними заголовками RFC 822): Content-Type:
application/pkcs7-mime; smime-type = signed-data; name = smime.p7mContent-Transfer-Encoding:
base64Content-Disposition: attachment; filename = smime.p7mRfvbn765BghyHhUjfewqwnvdCDC7
Відкрите підписане повідомлення. Відкрите підписана
повідомлення виходить тоді, коли для вмісту використовується тип 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 - boundary42Content-Type: text/plainЕто
відкритий текст підписаної повідомлення .-- boundary42Content-Type: application/pkcs7-
signature; name = smime.p7mContent-Transfer-Encoding: base64Content-Disposition:
attachment; filename = smime.p7mRfvbn765BghyHhUjfewqwnvdCDC7-- 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 c трьома ключами
(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
Протокол зміни параметрів шифрування SSL
Протокол
сповіщення SSL
FTP, SMTP, HTTP.
Протокол запису SSL
TCP
IP
Стек протоколів 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 ^ 14 + 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 байти). Параметри, що асоціюються з повідомленням даного тіпа.В вмісті
може знаходиться кілька полів, в кожному з яких знаходяться елементи.
Етапи встановлення сеансу (session) між клієнтом і сервером. № етапу
Типи повідомлень
Характеристика
етапу
1

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

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

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

4

Зміна комплекту шифрів і завершення роботи протоколу квітірованія
1-ий
етап - визначення характеристик