Захист електронної пошти в 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. Протокол сповіщення
123. 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. Захист на рівні додатків.

Схема аутентифікації.

Розташування:
Ка - сеансовий ключ, що використовується у схемі традиційного шифрування,
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-бітовий ідентифікатор відповідного відкритого ключа. Приотриманні повідомлення одержувач перевіряє, що ідентифікатор відповідаєвідомому йому відкритого ключа відправника, а потім продовжує перевіркупідпису.

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 (опис вмісту). Текстові опису об'єкту втілі повідомлення; корисно тоді, коли об'єкт має форму, недоступну дляпрочитання (наприклад, звукові дані).
Будь-яка реалізація, як мінімум, повинна підтримувати обробку полів 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-signatur | - | Тип підпису, що є частиною |
| | E | | повідомлення типу 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.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 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.

Між будь-який парою обмінюються інформацією сторін (наприклад,додатків типу 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 байти). Параметри, що асоціюються з повідомленнямданого типу.
У вмісті може знаходиться кілька полів, в кожному з яких знаходятьсяелементи.

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