Протоколи забезпечення автентичності та конфіденційності можуть використовуватися в двох режимах: транспортному і тунельний. У першому випадку захищається тільки вміст пакетів і, бути може, деякі поля заголовків. Як правило, транспортний режим використовується хостами. У тунельному режимі захищається весь пакет - він инкапсулируется в інший IP-пакет. На транспортному рівні автентичність, конфіденційність і цілісність потоків даних забезпечується протоколом TLS (Transport Layer Security, RFC 2246). Об'єктом захисту є не окремі мережні пакети, а потоки даних (послідовності пакетів). Зловмисник не зможе Переупорядкований пакети, видалити деякі з них або вставити свої. На основі TLS можуть будуватися захищені протоколи прикладного рівня.

TLS - подальший розвиток протоколу SSLTLS - це протокол, який був введений в дію на основі протоколу SSL організацією IETT, що підготувала відповідний стандарт. Він забезпечує можливість повторного підключення без повторної аутентифікації і узгодження ключів сеансу. Забезпечується узгодження допустимих алгоритмів генерування ключів (DH), шифрування (3DES-CBC, RC2, RC4, IDEA, DES, Triple-DES, AES, Blowfish), цифрового підпису та аутентифікації (DSS, RSA, анонімний доступ з наступною додатковою аутентифікацією), хешування (SHA-1, MD5).

Протокол має два рівні: протокол записів TLS і протокол діалогу TLS. На нижньому рівні, працюючому поверх надійного транспортного протоколу (наприклад, TCP [TCP]), розміщується протокол записів TLS. Цей протокол забезпечує безпеку з'єднань, які мають дві основні властивості:

  • З'єднання є конфіденційним. Для шифрування даних використовується симетрична криптографія (наприклад, DES [DES], RC4 [RC4] і так далі). Ключі для шифрування генеруються незалежно для кожного з'єднання і базуються на таємному коді, одержуваному за допомогою іншого протоколу (такого, як протокол діалогу TLS). Протокол записів може використовуватися і без шифрування.
  • З'єднання є надійним. Процедура передачі повідомлення включає в себе перевірку цілісності за допомогою обчислення MAC. Для розрахунку>MAC використовуються хеш-функції (наприклад, SHA, MD5 і так далі). Протокол записів може працювати і без MAC, але в цьому режимі він застосовується тільки у випадку, коли інший протокол використовує протокол записів в якості транспортного при з'ясуванні параметрів безпеки.

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

Стандартний TLS не передбачає підтримки російських алгорітмовВ відповідності зі стандартом RFC 2246, протокол TLS підтримує різні алгоритми шифрування, широко розповсюджені в світі. Але не підтримує російські алгоритми. У зв'язку з цим виникають проблеми використання цього протоколу в ситуаціях, коли потрібне виконання регламентуючих документів ФАПСИ по використанню сертифікованих алгоритмів. У числі таких документів наступні:

  • ГОСТ 28147-89 - "Системи обробки інформації. Захист криптографічний".
  • ГОСТ Р 34.11 - "Інформаційна технологія. Криптографічний захист інформації. Функція хешування" .
  • ГОСТ Р 34.10-94 - "Інформаційна технологія. Криптографічний захист інформації. Система електронного цифрового підпису на базі асиметричного криптографічного алгоритму".
  • ГОСТ Р34.10-2001 - " Інформаційна технологія. Криптографічний захист інформації. Процеси формування та перевірки електронного цифрового підпису ".

Для вирішення питань підтримки протоколом TLS російських алгоритмів в 2002-му році ряд компаній, що займаються розробкою систем захисту інформації, електронного цифрового підпису, об'єднали свої зусилля і подпісалісоглашеніе про співпрацю. У числі цих компаній були ФГУП НТЦ "Атлас", ТОВ "Крипто-Про", ТОВ "Фактор-ТС", ЗАТ "МО ПНІЕІ" і ВАТ "Інфотекс", ЗАТ "Санкт-Петербурзький регіональний центр захисту інформації", ТОВ "Кріптоком ", ТОВ" Р-Альфа "," КріптоПро ". Компанії домовилися про об'єднання зусиль з метою досягнення сумісності криптографічних продуктів, розробки рекомендацій по стандартизації форматів сертифікатів відкритих ключів, списків відкликаних сертифікатів, криптографічних повідомлень з урахуванням використання російських алгоритмів.

В рамках "Угоди про сумісність СКЗІ" були розроблені п'ять проектів інформаційних документів. Перші версії трьох з них були представлені співробітником компанії "Крипто-Про" в липні 2003 року на 57-ій конференції IETF у Відні і з цікавістю зустрінуті інтернет-спільнотою. Два документи вже отримали статус документів робочих груп IETF.

Рішення по підтримці російських криптоалгоритмів стало доповненням до RFC 2246Одін з них представляє інтерес в рамках розглянутого питання.

Це - проект "Addition of GOST Ciphersuites to Transport Layer Security (TLS)", який є доповненням до специфікації RFC 2246 в частині опису застосування російських алгоритмів. Документ описує чотири механізму, що реалізують ключові протоколи при використанні відкритих ключів ГОСТ Р 34.10-94 і ГОСТ Р 34.10-2001. Перша пара використовує шифрування ГОСТ 28147-89 та контроль цілісності за допомогою імітовставки, друга пара не використовує шифрування і контролює цілісність за допомогою ключового хешу (MAC) на основі алгоритму ГОСТ Р 34.11-94.

Виробивши єдині пропозиції щодо розширення можливостей протоколу TLS, компанії, що займаються розробкою СКЗІ, приступили до їх реалізації. В результаті такої діяльності з'явилося декілька рішень.

Одне з рішень запропоновано компанією "Новий Адам", що випустила "Засвідчувальний центр сертифікатів цифрового підпису Інега УЦ". Створювані в ньому сертифікати можуть брати участь в організації захищеного з'єднання по протоколу Transport Layer Security (TLS) (RFC 2246 The TLS Protocol Version 1.0.) З російськими криптографічними алгоритмами (хеш-функція - ГОСТ Р34.11-94, підпис - ГОСТ Р34 .10-94, шифрування та вироблення імітовставки - ГОСТ 28147-89).

Своє рішення пропонує і компанія "КріптоПро". Модуль підтримки мережевої аутентифікації "КріптоПро TLS", що входить до складу СКЗІ "КріптоПро CSP", реалізує протокол Transport Layer Security (TLS v. 1.0, RFC 2246) з використанням російських криптографічних стандартів. Протокол TLS призначений для забезпечення криптографічними засобами аутентифікації відправника (клієнта) - адресата (сервера), контролю цілісності та шифрування даних інформаційного обміну. У механізмі захисту реалізації протоколу TLS (аутентифікація клієнта і сервера, шифрування інформації, контроль цілісності інформації) застосовуються криптографічні алгоритми шифрування відповідно до ГОСТ 28147-89, обміну ключів за алгоритмом Діффі-Хеллмана, хешування відповідно до ГОСТ Р 34.11-94.

Модуль підтримки мережевої аутентифікації "Крипто-Про TLS" функціонує спільно із засобом криптографічного захисту інформації (СКЗІ) "КріптоПро CSP" в операційних середовищах Windows 95, Windows 95 OSR2, Windows 98. Windows 98 SE, Windows ME, Windows NT 4.0, Windows 2000/XP. А для операційних систем Linux, FreeBSD, а також Windows аналогічний продукт, повністю сумісний з "Крипто-Про TLS", розробила компанія "Цифрові технології". Він називаетсяTrusted TLSі є доопрацьованим програмне рішення ModSSL, що дозволяє використовувати російські стандарти криптографічного захисту інформації в веб-сервері Apache. В якості сертифікованих ГОСТ алгоритмів використовуються російські стандарти шифрування.

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

І хотілося б торкнутися ще один момент, пов'язаний з використанням захищених протоколів. Чи завжди можна довіряти сервісів, які їх застосовують? Компанія Microsoft попереджає, що вірити можна далеко не в кожному випадку. З цього приводу нею був випущений спеціальний документ - "Як виявляти небезпечні веб-вузли і гіперпосилання і захищатися від них". У ньому, зокрема, говориться наступне.

"Щоб захиститися від підроблених веб-вузлів, необхідно виконувати наступні інструкції:

  • перед відправкою важливої ??інформації переконайтеся, що веб-сайт використовує протокол SSL/TLS (Secure Sockets Layer/Transport Layer Security), і перевірте ім'я сервера. Як правило, протокол SSL/TLS застосовується для шифрування даних при пересиланні через Інтернет. Крім того, з його допомогою можна перевірити, що дані передаються на потрібний сервер. Ім'я сервера, на якому розміщується поточна сторінка, можна перевірити за відповідним імені користувача цифрового сертифіката SSL/TLS. Для цього необхідно, щоб у правому нижньому куті вікна браузера Internet Explorer з'явився значок у вигляді замка.
  • щоб перевірити ім'я сервера на цифровому сертифікаті, двічі клацніть значок замка і запам'ятайте ім'я поруч з написом "Кому виданий". Не відправляйте важливі дані або дані, що містять особисті відомості, на веб-вузли, які не використовують протокол SSL/TLS. Якщо ім'я в поле "Кому виданий "відрізняється від імені веб-вузла, на якому ймовірно повинна розміщуватися переглядається веб-сторінка, закрийте вікно браузера і покиньте даний вузол".

Який з цього можна зробити висновок? Довіряйте тим веб-вузлів, що використовують доступ по протоколу TLS, які ви знаєте. Не передавайте конфіденційну інформацію на ті вузли, в яких ви сумніваєтеся. І, звичайно, перевіряйте підпис на сертифікаті вузла, щоб упевнитися в його справжності.

Посилання по темі

  • Сумісність засобів криптографічного захисту інформації різних виробників
  • TLS протокол

Статьяполучена: hostinfo.ru

Детальніше »