ПЕРЕЛІК ДИСЦИПЛІН:
  • Адміністративне право
  • Арбітражний процес
  • Архітектура
  • Астрологія
  • Астрономія
  • Банківська справа
  • Безпека життєдіяльності
  • Біографії
  • Біологія
  • Біологія і хімія
  • Ботаніка та сільське гос-во
  • Бухгалтерський облік і аудит
  • Валютні відносини
  • Ветеринарія
  • Військова кафедра
  • Географія
  • Геодезія
  • Геологія
  • Етика
  • Держава і право
  • Цивільне право і процес
  • Діловодство
  • Гроші та кредит
  • Природничі науки
  • Журналістика
  • Екологія
  • Видавнича справа та поліграфія
  • Інвестиції
  • Іноземна мова
  • Інформатика
  • Інформатика, програмування
  • Юрист по наследству
  • Історичні особистості
  • Історія
  • Історія техніки
  • Кибернетика
  • Комунікації і зв'язок
  • Комп'ютерні науки
  • Косметологія
  • Короткий зміст творів
  • Криміналістика
  • Кримінологія
  • Криптология
  • Кулінарія
  • Культура і мистецтво
  • Культурологія
  • Російська література
  • Література і російська мова
  • Логіка
  • Логістика
  • Маркетинг
  • Математика
  • Медицина, здоров'я
  • Медичні науки
  • Міжнародне публічне право
  • Міжнародне приватне право
  • Міжнародні відносини
  • Менеджмент
  • Металургія
  • Москвоведение
  • Мовознавство
  • Музика
  • Муніципальне право
  • Податки, оподаткування
  •  
    Бесплатные рефераты
     

     

     

     

     

     

         
     
    Захист електронної пошти в 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 - протокол захисту електронних транзакцій). 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-ий
    етап - визначення характеристик
         
     
         
    Реферат Банк
     
    Рефераты
     
    Бесплатные рефераты
     

     

     

     

     

     

     

     
     
     
      Все права защищены. Reff.net.ua - українські реферати ! DMCA.com Protection Status