Каналы защищенной передачи данных

From CryptoWiki
Jump to: navigation, search

Каналы защищенной передачи данных - виртуальные защищенные каналы связи, называемые криптозащищенными туннелями, или туннелями VPN.

Contents

Постановка задачи

Изначально сеть Интернет рассматривалась как безопасная среда передачи данных между военными. Безопасность организовывалась на уровне физической изоляции объектов от посторонних лиц, и это было оправдано, когда к сети имело доступ ограниченное число машин. Однако, когда Интернет стал открытой информационной средой, не только в плане «свободы информации», но и с точки зрения несанкционированного доступа к этой информации, потребность в обеспечении безопасности передачи данных появилась.

Защита данных в процессе передачи по открытым каналам основана на построении виртуальных защищенных каналов связи - криптозащищенные туннели. Туннель представляет собой соединение, проведенное через открытую сеть, по которому передаются криптографически защищённые пакеты сообщений.

Построение защищенного канала передачи информации может быть реализовано на разных уровнях модели OSI. Наиболее распространенные технологии реализации защищенных каналов передачи информации: SSL-протокол, SSH работает на прикладном уровне, IPsec на сетевом уровне, Протокол PPTP на канальном уровне

В вопросе выбора уровня реализации защищенного канала несколько противоречивых аргументов: с одной стороны, за выбор верхних уровней говорит их независимость от вида транспортировки (выбора протокола сетевого и канального уровней), с другой стороны для каждого приложения необходима отдельная настройка и конфигурация. Плюсом в выборе нижних уровней является их универсальность и наглядность для приложений, минусом — зависимость от выбора конкретного протокола (например, PPP или Ethernet).  

Защита на канальном уровне

Общие сведения

К протоколом построения защищённого канала передачи данных на канальном уровне относятся:

  • протокол PPTP (Point-to-Point Tunneling Protocol), разработанный Microsoft совместно с компаниями Ascend Communications, 3Com/Primary Access, Ecl-Telematics и US Robotics;
  • протокол L2TP (Layer-2 Tunneling Protocol), объединивший протокол L2F (Layer-2 Forwarding) и PPTP.

Вышеназванные протоколы объединяет то, что они являются протоколами туннелирования канального уровня. Определению защищенного канала соответствует лишь протокол PPTP, который обеспечивает туннелирование и шифрование данных. Протокол L2TP, по сути, является только протоколом туннелирования, а функции защиты в них не поддерживаются. Существует вероятность использования данного протокола совместно с протоколом IPSec.

Протокол PPTP

Протокол PPTP предполагает создание криптозащищенного туннеля на канальном уровне модели OSI для случаев как прямого соединения удалённого компьютера с открытой сетью, так и подсоединения его к открытой сети по телефонной линии через провайдера. В основе протокола PPTP лежит протокол канального уровня PPP(Point-to-Point). Первоначально протокол PPP, расположенный на канальном уровне, был разработан для инкапсуляции данных и их доставки по соединеним типа точка-точка. Этот протокол служит также для организации асинхронных соединений.

Для доставки конфиденциальных данных из одной точки в другую через сети общего пользования сначала производится инкапсуляция данных с помощью протокола PPP, затем протокол PPTP выполняет шифрование данных и собственную инкапсуляцию. После того как туннельный протокол доставляет пакеты из начальной точки туннеля в конечную, выполняется деинкапсуляция. Протокол РРТР позволяет создавать защищенные каналы для обмена данными по протоколам IP, IPX или NetBEUI. Данные этих протоколов упаковываются в кадры РРР и затем инкапсулируются посредством протокола РРТР в пакеты протокола IR с помощью которого переносятся в зашифрованном виде через любую сеть TCP/IP

Рис 1 Структура пакета для пересылки по туннелю PPTP

Пакеты, передаваемые в рамках сессии РРТР, имеют следующую структуру (рис. 1):

  • заголовок канального уровня, используемый внутри Интернета, например заголовок кадра Ethernet;
  • заголовок IP, содержащий адреса отправителя и получателя пакета;
  • заголовок общего метода инкапсуляции для маршрутизации GRE (Generic Routing Encapsulation);
  • исходный пакет РРР, включающий пакет IP, IPX или NetBEUI.

Принимающий узел сети извлекает из пакетов IP кадры PPP а затем извлекает из кадра РРР исходный пакет IP, IPX или NetBEUI и отправляет его но локальной сети конкретному адресату. Многопротокольность инкапсулирующих протоколов канального уровня, к которым относится протокол РРТР, является их важным преимуществом перед протоколами защищенного канала более высоких уровней. Например, если в корпоративной сети используются IPX или NetBEUI, применение протоколов IPSec или SSL просто невозможно, поскольку они ориентированы только на один протокол сетевого уровня IP.

Данный способ инкапсуляции обеспечивает независимость от протоколов сетевого уровня модели OSI и позволяет осуществлять защищенный удаленный доступ через открытые IP-сети к любым локальным сетям (IP, IPX или NetBEUI). Согласно протоколу РРТР при создании защищенного виртуального канала производится аутентификация удаленного пользователя и шифрование передаваемых данных (рис. 2).

Рис 2 Архитектура протокола PPTP

Для аутентификации удаленного пользователя могут использоваться различные протоколы, применяемые для РРР. В реализации РРТР включенной компанией Microsoft в Windows NT/2000, поддерживаются следующие протоколы аутентификации: протокол аутентификации по паролю PAP (Password Authentication Protocol), протокол аутентификации при рукопожатии MSCHAP (Microsoft Challenge-Handshaking Authentication Protocol) и протокол аутентификации ЕАР-TLS (Extensible Authentication Protocol-Transport Layer Security). При использовании протокола PAP идентификаторы и пароли передаются по линии связи в незашифрованном виде, при этом только сервер проводит аутентификацию клиента. У данного протокола есть существенный недостаток: любой злоумышленник, способный перехватить сетевые пакеты, способен получить пароль с помощью анализатора пакетов - sniffer. При использовании протоколов MSCHAP и EAP-TLS обеспечиваются защита от повторного использования злоумышленником перехваченных пакетов с зашифрованным паролем и взаимная аутентификация клиента и VPN-сервера.

Шифрование с помощью РРТР гарантирует, что никто не сможет получить доступ к данным при пересылке через Интернет. Шифрование МРРЕ (Microsoft Point-to-Point Encryption) совместимо только с MSCHAP (версии 1 и 2) и EAP- TLS и умеет автоматически выбирать длину ключа шифрования при согласовании параметров между клиентом и сервером. Шифрование МРРЕ поддерживает работу с ключами длиной 40,56 или 128 бит. Протокол РРТР изменяет значение ключа шифрования после каждого принятого пакета. В качестве алгоритмов шифрования используются алгоритмы RC-4 или DES.

Протокол РРТР применяется в схеме туннелирования при прямом подсоединении компьютера удаленного пользователя к Интернету. На рис.3 представлена реализация этой схемы туннелирования .

Рис 3 Схема туннелирования при прямом подсоединении компьютера удаленного пользователя к Интернету


Удаленный пользователь устанавливает удаленное соединение с локальной сетью с помощью клиентской части сервиса удаленного доступа RAS (Remote Access Service), входящего в состав Windows. Затем пользователь обращается к серверу удаленного доступа локальной сети, указывая его IP-адрес, и устанавливает с ним связь по протоколу PPTR. Функции сервера удаленного доступа может выполнять пограничный маршрутизатор локальной сети. На компьютере удаленного пользователя должны быть установлены клиентская часть сервиса RAS и драйвер РРТР, которые входят в состав Windows 98/NT, а на сервере удаленного доступа локальной сети - сервер RAS и драйвер РРТР, входящие в состав Windows NT Server. Протокол РРТР определяет несколько служебных сообщений, которыми обмениваются взаимодействующие стороны. Служебные сообщения передаются по протоколу TCP. После успешной аутентификации начинается процесс защищенного информационного обмена. Внутренние серверы локальной сети могут не поддерживать протокол РРТР, поскольку пограничный маршрутизатор извлекает кадры РРР из пакетов IP и посылает их по локальной сети в необходимом формате - IP, IPX или NetBIOS.

Протокол "точка-точка"

Обмен ключами Диффи-Хеллмана чувствителен к всркытию "человек в середине". Решением является необходимость подписи сообщений. Эти сертификаты подписаны заслуживающим доверия органом власти.

Пусть у А есть сертифицированный открытый ключ B, а у B есть сертифицированный открытый ключ А.

Генерация ключа k выглядит следующем образом:

1. А генерирует случайное число х и посылает его В;

2. В генерирует случайное число у. Используя протокол Диффи-Хеллмана, он вычисляет общий ключ k на базе х и у. Он подписывает х и у и шифрует подпись ключом k. Затем он посылает получившееся вместе с у А.

Dhy.png

3. А также вычисляет k. А расшифровывает оставшуюся часть сообщения В и проверяет его подпись. Затем она посылает В подписанное сообщение, состоящее из х и у, зашифрованных общим ключом k.

DhA.png

4. В расшифровывает сообщение и проверяет подпись А.

Протокол L2TP

Протокол L2F был разработан компанией Cisco Systems для построения защищенных виртуальных сетей на канальном уровне модели OSI в качестве замены протоколу РРТР. От РРТР протокол L2F отличается поддержкой разных сетевых протоколов.

Для протокол L2F характерны следующие свойства:

  • гибкость процедур аутентификации, предполагающая отсутствие жесткой привязки к конкретным протоколам проверки подлинности;
  • прозрачность для конечных систем - рабочим станциям локальной сети и удаленной системе не требуется специального программного обеспечения для использования защитного сервиса;
  • прозрачность для посредников - авторизация удаленных пользователей выполняется аналогично случаю непосредственного подключения пользователей к серверу удаленного доступа локальной сети;
  • полнота аудита - регистрация событий доступа к серверу локальной сети осуществляется не только сервером удаленного доступа этой сети, но и сервером провайдера.

У протокола L2F можно выделить следующие недостатки:

  • в протоколе L2F не предусмотрено создание для текущей версии протокола IP криптозащищенного туннеля между конечными точками информационного взаимодействия;
  • виртуальный защищенный канал может быть создан только между сервером удаленного доступа провайдера и пограничным маршрутизатором локальной сети, при этом участок между компьютером удаленного пользователя и сервером провайдера остается открытым.

В настоящее время протокол L2F фактически поглощен протоколом L2TP, имеющим статус проекта стандарта Интернет. Протокол L2TP был разработан как протокол защищенного туннелирования РРР- трафика через сети общего назначения.

Протокол L2TP отличается от протокола PPTP тем, что не привязан к протоколу IP, поэтому он может быть использован в сетях с коммутацией пакетов, например в сетях ATM (Asynchronous Transfer Mode) или в сетях с ретрансляцией кадров (Frame Relay). Протокол L2TP вобрал в себя лучшие свойства протоколов РРТР и L2F, а также и добавлены новые функции. В протокол L2TP добавлен ряд отсутствующих в спецификации протокола РРТР функций защиты, в частности включена возможность работы с протоколами АН и ESP стека протоколов IPSec. Архитектура протокола L2TP представлена на рис.4.

Рис.4 Архитектура протокола L2TP

Протоколы АН и ESP являются основными компонентами стека протоколов IPSec. Эти протоколы допускают использование пользователями по их согласованному выбору различных криптографических алгоритмов шифрования и аутенификации. Домен интерпретации DOI (Domain of Interpretation) отвечает за обеспечения совместной работы используемых протоколов и алгоритмов.

По сути, гибридный протокол L2TP есть расширение протокола РРР функциями аутентификации удаленных пользователей, создания защищенного виртуального соединения и управления потоками данных.

Протокол L2TP применяет в качестве транспорта протокол UDP и использует одинаковый формат сообщений как для управления туннелем, так и для пересылки данных. Надежность доставки гарантирует контроль последовательности пакетов. Аналогично протоколу PPTP, протокол L2TP начинает сборку пакета для передачи в туннель с того, что к полю информационных данных РРР добавляется сначала заголовок РРР, затем заголовок L2TP. Полученный таким образом пакет инкапсулируется протоколом UDP.

В зависимости от выбранного типа политики безопасности стека протоколов IPSec, протокол L2TP может шифровать UDP-сообщения и добавлять к ним заголовок и окончание ESP (Encapsulating Security Payload), а также окончание IPSec ESP Authentication. Далее производится инкапсуляция в IP. Добавляется IP-заголовок, содержащий адреса отправителя и получателя. В завершение L2TP выполняет вторую РРР-инкапсуляцию для подготовки данных к передаче. Компьютер-получатель принимает данные, обрабатывает заголовок и окончание РРР, убирает заголовок IP. При помощи IPSec ESP Authentication проводится аутентификация информационного поля IP, а протокол ESP IPSec помогает расшифровать пакет. Далее компьютер обрабатывает заголовок UDP и использует заголовок L2TP для идентификации туннеля.

Протокол L2TP обеспечивает аутентификацию на уровнях «пользователь» и «компьютер», а также выполняет аутентификацию и шифрование данных. На первом этапе аутентификации клиентов и серверов VPN протокол L2TP использует локальные сертификаты, полученные от службы сертификации. Клиент и сервер обмениваются сертификатами и создают защищенное соединение ESP SA (Security Association). Затем, после того как протокол завершает процесс аутентификации компьютера, выполняется аутентификация на уровне пользователя. Для этой аутентификации можно задействовать любой протокол, PAP например, передающий имя пользователя и пароль в открытом виде. Это вполне безопасно, так как L2TP шифрует всю сессию. Однако проведение аутентификации пользователя при помощи MSCHAP, применяющего различные ключи шифрования для аутентификации компьютера и пользователя, может повысить безопасность.

Аналогично протоколу PPTP, формирование защищенного канала в протоколе L2TP осуществляется в три этапа:

  • установление соединения с сервером удаленного доступа локальной сети;
  • аутентификация пользователя;
  • конфигурирование защищенного туннеля.

На первом этапе - удаленный пользователь инициирует РРР-соединение с провайдером. Концентратор доступа принимает данное соединение и устанавливает канал РРР. Затем выполняется частичная аутентификацию конечного узла и его пользователя. Используя только имя пользователя, провайдер решает, нужен ли пользователю сервис туннелирования L2TP. Если такой сервис необходим, то следующим шагом будет выяснение адреса сетевого сервера LNS, с которым нужно установить туннельное соединение. После выяснения IP-адреса сервера LNS производится проверка, не существует ли уже туннель L2TP с этим сервером. Если такого туннеля нет, то он устанавливается.

Вторым этапом сетевой сервер LNS локальной сети выполняет процесс аутентификации пользователя. Для этого необходимо использовать один из стандартных протоколов аутентификации, например протокол CHAP. В случае применения протокола аутентификации CHAP пакет уведомления включает слово-вызов, имя пользователя и его ответ. Для протокола РАР эта информация состоит из имени пользователя и незашифрованного пароля. При отправке результата аутентификации сетевой сервер LNS передаёт сведения об IP-адресе узла пользователя.

На третьем этапе, в случае успешной аутентификации пользователя, создается защищенный туннель между концентратором доступа провайдера и сервером LNS локальной сети. В результате инкапсулированные кадры РРР могут передаваться по туннелю между концентратором и сетевым сервером LNS в обоих направлениях.

Протокол L2TP имеет ряд недостатков туннельной передачи данных на канальном уровне:

  • для реализации протокола L2TP необходима поддержка провайдеров ISP;
  • протокол L2TP ограничивает трафик рамками выбранного туннеля и лишает пользователей доступа к другим частям Интернета;
  • в протоколе L2TP не предусмотрено создание для текущей версии протокола IP криптозащищенного туннеля между конечными точками информационного взаимодействия;
  • предложенная спецификация L2TP обеспечивает стандартное шифрование только в IP-сетях с помощью протокола IPSec.

Резюме

Протокол L2TP не определяет конкретных методов криптозащиты и предполагает возможность применения различных стандартов шифрования. Если защищенный туннель формируется в IP-сетях, тогда для реализация криптозащиты используется протокол IPSec. Протокол L2TP поверх IPSec обеспечивает наиболее высокую степень защиты данных, чем РРТР, так как использует алгоритм шифрования 3-DES (Triple Data Encryption Standard). Если такой высокий уровень защиты не нужен, то достаточно использовать алгоритм DES с одним 56-разрядным ключом. Кроме того, при помощи алгоритма НМАС (Hash Message Authentication Code) протокол L2TP обеспечивает аутентификацию данных. Для аутентификации данных этот алгоритм создает хэш длиной 128 разрядов.

Подводя черту, функциональные возможности протоколов РРТР и L2TP различны. Протокол РРТР может применяться только в IP-сетях, и для этого ему необходимо отдельное соединение TCP для создания и использования туннеля. Протокол L2TP может использоваться не только в IP-сетях, служебные сообщения для создания туннеля и пересылки по нему данных используют одинаковый формат и протоколы. Протокол L2TP поверх IPSec предлагает больше уровней безопасности, чем РРТР, и может гарантировать почти 100-процентную безопасность важных для организации данных. Положительные качества протокола L2TP делают его весьма перспективным для построения виртуальных защищенных сетей.

Защита на сетевом уровне

Общие сведения

Устранение уязвимостей компьютерных сетей возможно при создании системы защиты не для отдельных классов приложений, а для сети в целом. Применительно к IP-сетям это означает, что системы защиты должны действовать на сетевом уровне модели OSI. Реализация защиты сети на третьем уровне гарантирует как минимум такую же степень защиты всех сетевых приложений, причем без какой-либо модификации последних.

IPSec - определенный IETF стандарт достоверной/конфиденциальной передачи данных по сетям IP.

IPSec является неотъемлемой частью IPv6 - Интернет-протокола следующего поколения, и расширением существующие версии Интернет-протокола IPv4. IPSec определён в RFC с 2401 по 2412.

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

Средства безопасности для IP описываются семейством спецификаций IPSec, разработанных рабочей группой IP Security.

Протоколы IPSec обеспечивают управление доступом, целостность вне соединения, аутентификацию источника данных, защиту от воспроизведения, конфиденциальность и частичную защиту от анализа трафика.

Основополагающими понятиями IPSec являются:

  • аутентификационный заголовок (АН);
  • безопасное сокрытие данных (ESP);
  • режимы работы: туннельный и транспортный;
  • контексты (ассоциации) безопасности (SA);
  • управление ключами (IKE);


Архитектура IPSec

Стек протоколов IPsec (Internet Protocol Security) применяется для аутентификации участников обмена, туннелирования трафика и шифрования IP-пакеты.

Главное задача протоколов IPsec – обеспечить безопасную передачу данных по сетям IP. Применение IPSec гарантирует:

  • целостность передаваемых данных, то есть данные при передаче не искажены, не потеряны и не продублированы;
  • аутентичность отправителя, то есть данные переданы именно тем отправителем, который доказал, что он тот, за кого себя выдаст;
  • конфиденциальность передаваемых данных, то есть данные передаются в форме, предотвращающей их несанкционированный просмотр.

Фундаментальной единицей коммуникации в IP-сетях является IР-пакет. Структура IP-пакета представлена на рис. 5. IP-пакет содержит S-адрсс источника и D-адрес получателя сообщения, транспортный заголовок, информацию о типе данных, переносимых в этом пакете, и сами данные.

Рисунок 5 Структура IP-пакета

Для того чтобы обеспечить аутентификацию, конфиденциальность и целостность передаваемых данных, стек протоколов IPSec построен на базе ряда стандартизованных криптографических технологий:

  • обмены ключами согласно алгоритму Диффи-Хеллмана для распределения секретных ключей между пользователями в открытой сети;
  • криптография открытых ключей для подписывания обменов Диффи-Хеллмана, чтобы гарантировать подлинность двух сторон и избежать атак типа «человек-в-середине»;
  • цифровые сертификаты для подтверждения подлинности открытых ключей; О блочные симметричные алгоритмы шифрования данных;
  • алгоритмы аутентификации сообщений на базе функций хэширования.

Протокол IPSec определяет стандартные способы защиты информационного обмена на сетевом уровне модели OSI для IP-сети, валяющейся основным видом открытых сетей. Данный протокол входит в состав новой версии протокола IP (IPv6) и применим также к его текущей версии (IPv4). Для протокола IPv4 поддержка IPSec является желательной, а для IPv6 - обязательной. Протокол IPSec представляет собой систему открытых стандартов, которая имеет четко очерченное ядро и которую можно дополнять новыми протоколами, алгоритмами и функциями. Стандартизованными функциями IPSec-защиты могут пользоваться протоколы более высоких уровней, в частности управляющие протоколы, протоколы конфигурирования, а также протоколы маршрутизации.

Основными задачами установления и поддержания защищенного канала являются следующие:

  • аутентификация пользователей или компьютеров при инициации защищенного канала;
  • шифрование и аутентификация передаваемых данных между конечными точками защищенного канала;
  • обеспечение конечных точек канала секретными ключами, необходимыми для работы протоколов аутентификации и шифрования данных.

Протокол IPsec имеет следующие компоненты:

  • основной протокол IPsec. Этот компонент реализует ESP и AH. Обрабатываются заголовки, происходит взаимодействие с базами данных SPD и SAD для определения политики безопасности, применяемой к пакету;
  • протокол управления обменом ключевой информации IKE (Internet Key Exchange). IKE обычно представляется как процесс пользовательского уровня;
  • базу данных политик безопасности SPD (Security Policy Database);
  • базу данных безопасных ассоциаций SAD (Security Association Database). База данных SAD хранит список безопасных ассоциаций SA (Security Association) для обработки входящей и исходящей информации. Исходящие SA используются для защиты исходящих пакетов, а входящие SA - для обработки пакетов с заголовками IPSec. База данных SAD заполняется SA вручную или с помощью протокола управления ключами IKE;
  • управление политикой безопасности и безопасными ассоциациями SA. Это приложения, которые управляют политикой безопасности и SА.

Основной протокол IPSec (реализующий ESP и АН) тесно взаимодействует с транспортным и сетевым уровнями стека протоколов TCP/IP. Фактически протокол IPSec является частью сетевого уровня. Основной модуль протокола IPSec обеспечивает два интерфейса: входной и выходной. Входной интерфейс используется входящими пакетами, а выходной - исходящими. Реализация IPSec не должна зависеть от интерфейса между транспортным и сетевым уровнями стека протоколов TCP/IP.

Базы данных SPD и SAD существенно влияют па эффективность работы IPSec. Выбор структуры данных для хранения SPD и SAD является критическим моментом, от которого зависит производительность IPSec. Особенности реализации SPD и SAD зависят от требований производительности и совместимости системы. Ядро IPSec составляют три протокола: протокол аутентифицирующего заголовка АН (Authentication Header), протокол инкапсулирующей защиты ESP (Encapsulating Security Payload) и протокол согласования параметров виртуального канала и управления ключами IKE (Internet Key Exchange). Архитектура стека протокола IPSec представлена на рис.6.

Рис. 6 Архитектура стека протоколов IPsec

Протоколы IKE, AH и ESP взаимодействуют между собой следующим образом.

1. С помощью протокола IKE между двумя точками устанавливается логического соединение. В случае установления этого соединения выполняется аутентификация конечных точек канала, а также выбираются параметры защиты данных.

2. В рамках установленной безопасной ассоциации SA начинает работать протокол АН или ESP, с помощью которого и выполняется требуемая защита передаваемых данных с использованием выбранных параметров.

Средний уровень архитектуры IPSec образуют алгоритмы согласования параметров и управления ключами, применяемые в протоколе IKE, а также алгоритмы аутентификации и шифрования, используемые в протоколах аутентифицирующего заголовка АН и инкапсулирующей защиты содержимого ESP. Протоколы защиты виртуального канала верхнего уровня архитектуры IPSec (АН и ESP) не зависят от конкретных криптографических алгоритмов.

Нижний уровень архитектуры IPSec образует домен интерпретации DOI. Необходимость применения домена интерпретации DOI обусловлена следующими причинами. Протоколы АН и ESP имеют модульную структуру, допуская применение пользователями по их согласованному выбору различных криптографических алгоритмов шифрования и аутентификации. Поэтому необходим модуль, который мог бы обеспечить совместную работу всех применяемых и вновь включаемых протоколов и алгоритмов. Именно такие функции возложены на домен интерпретации DOI. Домен интерпретации DOI в качестве базы данных хранит сведения об используемых в IPSec протоколах и алгоритмах, их параметрах, протокольных идентификаторах. По существу, домен интерпретации DOI выполняет роль фундамента в архитектуре IPSec. Для того чтобы использовать алгоритмы, соответствующие национальным стандартам, в качестве алгоритмов аутентификации и шифрования в протоколах АН и ESP, необходимо зарегистрировать эти алгоритмы в домене интерпретации DOI.

Функционирование IPSec предусмотрено в двух режимах:

  • туннельный;
  • транспортный.

Туннельный режим предполагает шифрование всего пакета, включая заголовок сетевого уровня. В данном режиме применяется в случае необходимости скрытия информационного обмена организации с внешним миром. При этом, адресные поля заголовка сетевого уровня пакета, использующего туннельный режим, заполняются межсетевым экраном организации и не содержат информации о конкретном отправителе пакета. При передаче информации из внешнего мира в локальную сеть организации в качестве адреса назначения используется сетевой адрес межсетевого экрана. После расшифровки межсетевым экраном начального заголовка сетевого уровня пакет направляется получателю.

Транспортный режим используется для шифрования поля данных IP пакета, содержащего протоколы транспортного уровня (TCP, UDP, ICMP), которое, в свою очередь, содержит информацию прикладных служб. Примером применения транспортного режима является передача электронной почты. Все промежуточные узлы на маршруте пакета от отправителя к получателю используют только открытую информацию сетевого уровня и, возможно, некоторые опциональные заголовки пакета (в IPv6). Недостатком транспортного режима является отсутствие механизмов скрытия конкретных отправителя и получателя пакета, а также возможность проведения анализа трафика. Результатом такого анализа может стать информация об объемах и направлениях передачи информации, области интересов абонентов, расположение руководителей.

Аутентификационный заголовок

Протокол AH является опциональным заголовком и расположен между основным заголовком пакета IP и полем данных. AH отвечает за обеспечение целостности и аутентификации данных

Формат заголовка AH состоит из 96-битового заголовка и данных переменной длины, состоящих из 32-битовых слов. Названия полей:

  • Next Header указывает на следующий заголовок;
  • Payload Len представляет длину пакета;
  • SPI является указателем на контекст безопасности;
  • Sequence Number Field содержит последовательный номер пакета.
Рис. 7 Формат заголовка АН

Последовательный номер пакета введен в AH в 1997 году в ходе процесса пересмотра спецификации IPsec. Значение этого поля формируется отправителем и служит для защиты от атак, связанных с повторным использованием данных процесса аутентификации. Так как сеть Интернет не гарантирует порядок доставки пакетов, получатель должен хранить информацию о максимальном последовательном номере пакета, прошедшего успешную аутентификацию, и о получении некоторого числа пакетов, содержащих предыдущие последовательные номера (чаще всего это число равно 64).

В процессе формирования AH, с помощью алгоритма MD5, последовательно вычисляется хэш-функция от объединения самого пакета и некоторого предварительно согласованного ключа, а затем от объединения полученного результата и преобразованного ключа. Данный механизм применяется по умолчанию в целях обеспечения всех реализаций IPv6, по крайней мере, одним общим алгоритмом, не подверженным экспортным ограничениям.


Безопасное сокрытие данных

Протокол ESP способен шифровать данные, а также способен выполнять функции протокола AH.

Рис. 8 Формат заголовка ESP

ESP может поддерживать функции шифрования и аутентификации/обеспечения целостности в любых комбинациях, то есть либо и ту и другую группу функций, либо только аутентификацию/обеспечение целостности, либо только шифрование. Для шифрования данных существует возможность применения любого симметричного алгоритма шифрования с секретным ключом. Для обеспечение целостности и аутентификации данных применяется шифрование с помощью односторонней функцией.Следовательно, формат ESP может претерпевать значительные изменения в зависимости от используемых криптографических алгоритмов. Тем не менее, можно выделить следующие обязательные поля:

  • SPI, указывающее на контекст безопасности;
  • Sequence Number Field, содержащее последовательный номер пакета;
  • ESP Authentication Data (контрольная сумма), не является обязательным в заголовке ESP.


Получатель пакета ESP расшифровывает ESP заголовок и использует параметры и данные применяемого алгоритма шифрования для декодирования информации транспортного уровня.

Управление ключами

Протоколы ESP и AH способствуют реализации конфиденциальности связи, аутентификацию сторон и целостность данных. Но не смотря на это, их функции теряют ценность в отсутствии мощной инфраструктуры, которая обеспечивает распределение ключей и согласование протоколов между участниками обмена.В качестве такой инфраструктуры выступает протокол IKE.

IKE — протокол обмена ключами по умолчанию для ISAKMP, на данный момент являющийся единственным.

Протокол ISAKMP (Internet Security Association and Key Management Protocol), описанный в документе RFC 2408, необходим для согласования алгоритмов и математических структур для процедуры обмена ключами Диффи - Хелмана, а также процессов аутентификации.

Протокол Oakley, описанный в RFC 2412, предназначен определения ключа, использующий алгоритм замены ключа Диффи-Хеллмана. Протокол Oakley поддерживает идеальную прямую безопасность (Perfect Forward Secrecy — PFS). Наличие PFS означает невозможность расшифровки всего траффика при компрометации любого ключа в системе.

IKE находится на вершине ISAKMP и выполняет установление как ISAKMP SA, так и IPSec SA. IKE поддерживает набор различных примитивных функций для использования в протоколах. Среди них можно выделить хэш-функцию и псевдослучайную функцию (PRF).

Хэш-функция — это функция, устойчивая к коллизиям. Под устойчивостью к коллизиям понимается тот факт, что невозможно найти два разных сообщения Безымянный.png и M2.png, таких, что Равенств.png, где H — хэш функция.

Что касается псеводслучайных функций, то вместо специальных PRF используется хэш функция в конструкции HMAC (HMAC — механизм аутентификации сообщений с использованием хэш функций). Для определения HMAC необходима криптографическая хэш функция (далее - H) и секретный ключ K. Предполагаем, что H является хэш функцией, где данные хэшируются с помощью процедуры сжатия, последовательно применяемой к последовательности блоков данных. Обозначим за B длину таких блоков в байтах, а длину блоков, полученных в результате хэширования — как L (L<B). Ключ K может иметь длину, меньшую или равную B. Если приложение использует ключи большей длины, сначала необходимо хэшировать сам ключ с использованием H, и только после этого использовать полученную строку длиной L байт, как ключ в HMAC. В обоих случаях рекомендуемая минимальная длина для K составляет L байт. Определим две следующие различные строки фиксированной длины:

ipad = байт 0x36, повторённый B раз

opad = байт 0x5C, повторённый B раз

Для вычисления HMAC от данных 'text' необходимо выполнить следующую операцию:

Xor.png

Протоколы IKE решают три задачи:

  • осуществляют аутентификацию взаимодействующих сторон, согласовывают алгоритмы шифрования и характеристики ключей, которые будут использоваться в защищенном сеансе обмена информацией;
  • обеспечивают создание ключевой информации соединения и управление ею, непосредственный обмен ключами (в том числе возможность их частой смены);
  • управляют параметрами соединения и защитой от некоторых типов атак, контролируют выполнение всех достигнутых соглашений.

В результате решения третий задачи появилась концепция безопасных ассоциаций SA.

Концепция безопасных ассоциаций

Security Association (SA) — это соединение, которое предоставляет службы обеспечения безопасности трафика, который передаётся через него. Два компьютера на каждой стороне SA хранят режим, протокол, алгоритмы и ключи, используемые в SA. Каждый SA используется только в одном направлении. Для двунаправленной связи требуется два SA. Каждый SA реализует один режим и протокол; таким образом, если для одного пакета необходимо использовать два протокола (как например AH и ESP), то требуется два SA.

Для выполнения аутентификации сторон в IKE применяются два основных способа.

Первый способ заключается в использовании разделяемого секрета. Перед инициализацией IPSec-устройств, образующих безопасные ассоциации, в их БД помещается предварительно распределенный разделяемый секрет. Цифровая подпись на основе односторонней функции, например, MD5, использующей в качестве аргумента этот предварительно распределенный секрет, доказывает аутентичность противоположной стороны.

Второй способ основан на использовании технологии цифровой подписи и цифровых сертификатов стандарта Х.509. Каждая из сторон подписывает свой цифровой сертификат своим закрытым ключом и передает эти данные противоположной стороне. Если подписанный сертификат расшифровывается открытым ключом отправителя, то это удостоверяет тот факт, что отправитель, предоставивший данные, действительно обладает ответной частью данного открытого ключа — соответствующим закрытым ключом.

После проведения взаимной аутентификации взаимодействующие стороны переходят к согласованию параметров защищенного канала. Выбираемые параметры SA определяют:

  • протокол, используемый для обеспечения безопасности передачи данных;
  • алгоритм аутентификации протокола АН и его ключи; алгоритм шифрования, используемый протоколом ESP, и его ключи;
  • наличие или отсутствие криптографической синхронизации;
  • способы защиты сеанса обмена; частоту смены ключей и ряд других параметров.

Важным параметром SA является так называемый криптографический материал, т. е. секретные ключи, используемые в работе протоколов АН и ESP.

Параметры SA должны устраивать обе конечные точки защищенного канала. Поэтому при использовании автоматической процедуры установления SA протоколы IKE, работающие по разные стороны канала, выбирают параметры в ходе переговорного процесса. Безопасная ассоциация SA представляет собой в IPSec однонаправленное логическое соединение, поэтому при двустороннем обмене данными необходимо установить две ассоциации SA. В рамках одной ассоциации SA может работать только один из протоколов защиты данных — либо АН, либо ESP, но не оба вместе.

Система IPSec допускает применение ручного и автоматического способа установления SA.

Базы данных SAD и SPD

IPSec имеет возможность реализовать различные методы защиты трафика. В каждом узле, поддерживающем IPSec, используются БД двух типов:

• база данных безопасных ассоциаций SAD (Security Associations Database);

• база данных политики безопасности SPD (Security Policy Database).

При установлении SA две вступающие в обмен стороны принимают ряд соглашений, регламентирующих процесс передачи потока данных между ними. Соглашения представляются в виде набора параметров. Для SA такими параметрами являются, в частности, тип и режим работы протокола защиты (АН или ESP), методы шифрования, секретные ключи, значение текущего номера пакета в ассоциации и другая информация.

Наборы текущих параметров, определяющих все активные ассоциации, хранятся на обоих оконечных узлах защищенного канала в виде SAD. Каждый узел IPSec поддерживает две базы SAD — одну для исходящих ассоциаций, другую — для входящих.

В SAD содержатся:

  • AH: алгоритм аутентификации.
  • AH: секретный ключ для аутентификации
  • ESP: алгоритм шифрования.
  • ESP: секретный ключ шифрования.
  • ESP: использование аутентификации (да/нет).
  • Параметры для обмена ключами
  • Ограничения маршрутизации
  • Политика IP-фильтрации

SPD задает соответствие между IP-пакетами и установленными для них правилами обработки. При обработке пакетов БД SPD используются совместно с БД SAD. SPD представляет собой упорядоченный набор правил, каждое из которых включает совокупность селекторов и допустимых политик безопасности. Селекторы служат для отбора пакетов, а политики безопасности задают требуемую обработку. Такая БД формируется и поддерживается на каждом узле, где установлено ПО IPSec. Пример селекторов SPD:

  • IP-адрес места назначения
  • IP-адрес отправителя
  • Имя пользователя в формате DNS или X.500
  • Порты отправителя и получателя

Когда поступает пакет, сравниваются значения соответствующих полей в пакете (селекторные поля) с теми, которые содержатся в SPD. При нахождении совпадении в поле политики защиты содержится информация о том, как поступать с данным пакетом: передать без изменений, отбросить или обработать. В случае обработки, в этом же поле содержится ссылка на соответствующую запись в SAD. Затем определяется SA для пакета и сопряженный с ней индекс параметров безопасности(SPI). После чего выполняются операции IPsec(операции протокола AH или ESP). Если пакет входящий, то в нем сразу содержится SPI — проводится соответствующая обработка.

Создание соединения IPsec

Создание соединения IPsec осуществляется в два этапа:

  • ISAKMP SA
  • IPsec SA

Этап 1

На данном этапе выполняется взаимная аутентификация и создаются ключи шифрования необходимые для защиты 2 этапа. Этап включает в себя 2 режима: основной и рискованный. Разницей между этими двумя режимами являются количество сообщений, которыми они обмениваются и способы защиты ключей.

Основной режим:

Mainphase.png

Рискованный режим:

Agressivephase.png

Этап 2

Этап определения шифра и алгоритма аутентификации, необходимый для защиты дальнейших операций. Этап 2 имеет один режим - Быстрый режим.

Быстрый режим:

Quickmod.png

Пояснение к этапам

HDR: ASAKMP заголовок;

SA: безопасные ассоциации;

KE: обмен открытыми ключами по алгоритму Диффи-Хеллмана

Ni, Nr: одноразовые ключи;

ID_I, ID_R: ключи отправителя и получателя;

CERT: сертификат;

SIG_I, SIG_R: подпись отправителя и получателя;

[x]: х не является обязательным.

*: шифрование должно начинаться после заголовка.


Обмен ключами и аутентификация

В протоколе IPSec поддерживаются различные протоколы обмена ключами и аутентификации:

Протоколы обмена ключами:

1. Диффи-Хеллмана;

2. Протокол Kerberos (далее KINK)

Протокол Kerberos

Kerberosipsec.png

Протоколы аутентификации:

1. Pre-Shared‎ key (PSK)

2. Цифровая подпись, в частности применяются алгоритмы RSA и DSA

3. Аутентификация с помощью открытого ключа

4. KINK

Описание DSA

p = простое число длинной L битов, где L принимает значение, кратное 64, в диапазоне от 512 до 1024.

q= 160-битовой простое число - множитель p-1

g = Dsaq.png, где h - любое число, меньшее p-1, для которого Dsaq.png больше 1

x = число, меньшее q

Dsay.png

Используется однонаправленная хэш-функция: Н(m).

Первые три параметра, p, q, g, открыты и могут быть общими для пользователей сети. Закрытым ключом является х, а открытым - у. Чтобы подписать сообщение, m:

1. А генерирует случайное число k, меньше q

2. А генерирует

Dsagen.png

Его подписью служат параметры r и s, он посылает их В

3. В проверяет подпись, вычисляя

Dsaprov.png

Если v=r, то подпись правильна.

Резюме

Система стандартов IPSec вобрала в себя прогрессивные методики и достижения в области сетевой безопасности. Система IPSec прочно занимает лидирующие позиции в наборе стандартов для создания VPN. Этому способствует ее открытое построение, способное включать все новые достижения в области криптографии. IPsec позволяет защитить сеть от большинства сетевых атак, «сбрасывая» чужие пакеты еще до того, как они достигнут уровня IP на принимающем компьютере. В защищаемый компьютер или сеть могут войти только пакеты от зарегистрированных партнеров по взаимодействию.

IPsec обеспечивает:

  • аутентификацию - доказательство отправки пакетов вашим партнером по взаимодействию, то есть обладателем разделяемого секрета;
  • целостность - невозможность изменения данных в пакете;
  • конфиденциальность - невозможность раскрытия передаваемых данных;
  • надежное управление ключами - протокол IKE вычисляет разделяемый секрет, известный только получателю и отправителю пакета;
  • туннелирование - полную маскировку топологии локальной сети предприятия

Работа в рамках стандартов IPSec обеспечивает полную защиту информационного потока данных от отправителя до получателя, закрывая трафик для наблюдателей на промежуточных узлах сети. VPN-решения на основе стека протоколов IPSec обеспечивают построение виртуальных защищенных сетей, их безопасную эксплуатацию и интеграцию с открытыми коммуникационными системами.

Защита на прикладном уровне

Протокол SSL

Протокол SSL (Secure Socket Layer - уровень защищенных сокетов), разработанный Netscape Communications при участии RSA Data Security, предназначен для реализации защищенного обмена информацией в клиент/серверных приложениях. На практике SSL широко реализуется только совместно с протоколом прикладного уровня HHTP.

Функции безопасности, предоставляемые протоколом SSL:

  • шифрование данных с целью предотвратить раскрытие конфиденциальных данных во время передачи;
  • подписывание данных с целью предотвратить раскрытие конфиденциальных данных во время передачи;
  • аутентификация клиента и сервера.

Протокол SSL использует криптографические методы защиты информации для обеспечения безопасности информационного обмена. Данный протокол выполняет взаимную аутентификацию, обеспечивает конфиденциальность и аутентичность передаваемых данных. Ядро протокола SSL - технология комплексного использования симметричных и асимметричных криптосистем. Взаимная аутентификация сторон выполняется при помощи обмена цифровыми сертификатами открытых ключей клиента и сервера, заверенными цифровой подписью специальных сертификационных центров. Конфиденциальность обеспечивается шифрованием передаваемых данных с использованием симметричных сессионных ключей, которыми стороны обмениваются при установлении соединения. Подлинность и целостность информации обеспечиваются за счет формирования и проверки цифровой подписи. В качестве алгоритмов асимметричного шифрования применяются алгоритм RSA и алгоритм Диффи-Хеллмана.

Рисунок 9 Криптозащищенные туннели, сформированные на основе протокола SSL

Согласно протоколу SSL криптозащищенные туннели создаются между конечными точками виртуальной сети. Клиент и сервер функционируют на компьютерах в конечных точках туннеля (рис. 9)

Протокол диалога SSL имеет два основных этапа формирования и поддержки защищаемого соединения:

  • установление SSL-сессии;
  • защищенное взаимодействие.

Первый этап отрабатывается перед непосредственной защитой информационного обмена и выполняется по протоколу начального приветствия (Handshake Protocol), входящему в состав протокола SSL. При установлении повторного соединения, возможно сформировать новые сеансовые ключи на основе старого общего секрета.

В процессе установления SSL - сессии решаются следующие задачи:

  • аутентификация сторон;
  • согласование криптографических алгоритмов и алгоритмов сжатия, которые будут использоваться при защищенном информационном обмене;
  • формирование общего секретного мастер-ключа;
  • генерация на основе сформированного мастер-ключа общих секретных сеансовых ключей для криптозащиты информационного обмена.
Рисунок 10 Процесс аутентификации клиента сервером

В протоколе SSL предусмотрено два типа аутентификации:

  • аутентификация сервера клиентом;
  • аутентификация клиента сервером.

Клиентское/серверное ПО, поддерживающее SSL, может с помощью стандартных приемов криптографии с открытым ключом проверить, что сертификат сервера/клиента и открытый ключ действительны и были выданы источником сертификатов из списка доверенных источников. Пример процесса аутентификации клиента сервером представлен на рисунке 10.

Схема применения протокола

До передачи сообщение по линии передачи данных, сообщение проходит следующие этапы обработки:

1.Сообщение фрагментируется на блоки, пригодные для обработки;

2.Данные сжимаются (опционально);

3.Генерируется MAC ключ SP1.JPG;

4.Данные зашифровываются с помощью ключа SP2.JPG;

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

1.Используя ключ SP2.JPG, данные расшифровываются;

2.Проверяется MAC ключ SP1.JPG;

3.Происходит декомпрессия данных (если использовалось сжатие);

4.Сообщение собирается из блоков и получатель читает сообщение.

Аутентичное распределение ключей

A, Клиент CA Удостоверяющий центр B, Сервер
Генерация пары ключей цифровой подписи: S3.JPG. Передача S4.JPG в УЦ S5.JPG - симметричная схема шифрования; S6.JPG - схема открытого шифрования; S7.JPG - схема ЦП; S8.JPG - любые функции (лучше ОНФ) Генерация пары ключей схемы открытого шифрования: S9.JPG. Передача S10.JPG в УЦ
K - случайный сеансовый ключ. S11.JPG S12.JPG S13.JPG
S14.JPG S15.JPG

S16.JPG

S17.JPG S18.JPG S19.JPG

Если S19 1.JPG, то K принимается как аутентичный общий секретный ключ

S20.JPG S21.JPG

Рабочий этап

A B
Rs1.JPG Rs2.JPG

S5.JPG - симметричная схема шифрования

Rs1.JPG
Rs3.JPG Rs4.JPG Rs5.JPG
Rs6.JPG Rs7.JPG Rs8.JPG
. . . и т.д. . . .

Атаки на протокол SSL

Как и другие протоколы, SSL подвержен атакам, связанным с не доверенной программной средой, внедрение программ-закладок и др.:

  • Атака отклика. Заключается в записи злоумышленником успешной коммуникационной сессии между клиентом и сервером. Позднее, он устанавливает соединение с сервером, используя записанные сообщения клиента. Но при помощи уникального идентификатора соединения "nonce" SSL отбивает эту атаку. Коды этих идентификаторов имеют длину 128 бит, в связи с чем злоумышленнику необходимо записать 2^64 идентификаторов, чтобы вероятность угадывания была 50%. Количество необходимых записей и низкую вероятность угадывания делают эту атаку бессмысленной.
  • Атака протокола рукопожатия.Злоумышленник может попытаться повлиять на процесс обмена рукопожатиями для того, чтобы стороны выбрали разные алгоритмы шифрования. Из-за того, что многие реализации поддерживают экспортированное шифрование, а некоторые даже 0-шифрование или MAC-алгоритм, эти атаки представляют большой интерес. Для реализации такой атаки злоумышленнику необходимо подменить одно или более сообщений рукопожатия. Если это происходит, то клиент и сервер вычислят различные значения хэшей сообщения рукопожатия. В результате чего стороны не примут друг от друга сообщения "finished". Без знания секрета злоумышленник не сможет исправить сообщение "finished", поэтому атака может быть обнаружена.
  • Раскрытие шифров.SSL зависит от нескольких криптографических технологий. Шифрование с общедоступным ключом RSA используется для пересылки ключей сессии и аутентификации клиента/сервера. В качестве шифра сессии применяются различные криптографические алгоритмы. Если осуществлена успешная атака на эти алгоритмы, SSL не может уже считаться безопасным. Атаки против определенных коммуникационных сессий могут производиться путем записи сессии, и затем предпринимается попытка подобрать ключ сессии или ключ RSA. В случае успеха открывается возможность прочесть переданную информацию.
  • Злоумышленник посередине. Man-in-the-Middle атака предполагает наличие трех сторон: клиента, сервера и злоумышленника. Злоумышленник, находясь между ними, может перехватывать обмен сообщениями между клиентом и сервером. Атака является эффективной только если для обмена ключами применяется алгоритм Диффи-Хэлмана, так как целостность принимаемой информации и ее источник проверить невозможно. В случае SSL такая атака невозможна из-за использования сервером сертификатов, заверенных центром сертификации.

Протокол TLS

TLS (англ. Transport Layer Security) — это стандартный протокол, предназначенный для создания безопасных веб-соединений в Интернете или интрасетях. Он позволяет клиентам выполнять проверку подлинности серверов, а серверам — проверку подлинности клиентов (при необходимости). Этот протокол также обеспечивает защищенный канал путем шифрования передаваемых данных. Протокол TLS версии 1.0, основанный на SSL версии 3.0, является первым отраслевым стандартом SSL. Его спецификация определена рабочей группой IETF в документе RFC 2246, Протокол TLS. Последняя вышедшая спецификация протокола описана в документе RFC 5246.

Цель создания и преимущества

Цель создания TLS - повышение защиты SSL и более точное и полное определение протокола:

  • Более надежный алгоритм MAC
  • Более детальные предупреждения
  • Более четкие определения спецификаций "серой области"

TLS предоставляет следующие усовершенствованные способы защиты:

  • Хэширование ключей для идентификации с помощью сообщений - TLS применяет в коде идентификации сообщения (HMAC) хэширование, предотвращающее от изменения записи при передаче по незащищенной сети, например в Internet. SSL версии 3.0 также поддерживает идентификацию сообщений с помощью ключей, но HMAC считается более надежным, чем функция MAC, применяемая в SSL версии 3.0.
  • Улучшенная псевдослучайная функция (PRF) С помощью PRF создаются данные ключа. В TLS функция PRF определена с помощью HMAC. PRF применяет два алгоритма хэширования, обеспечивающих ее защиту. Если один из алгоритмов будет взломан, данные будут защищены вторым алгоритмом.
  • Улучшенная проверка сообщения "Готово" - Протоколы TLS версии 1.0 и SSL версии 3.0 отправляют обеим конечным системам сообщение "Готово", означающее, что доставленное сообщение не было изменено. Однако в TLS эта проверка основана на значениях PRF и HMAC, что обеспечивает более высокий уровень защиты по сравнению с SSL версии 3.0.
  • Согласованная обработка сертификатов - В отличие от SSL версии 3.0, TLS пытается указать тип сертификата, который может применяться различными реализациями TLS.
  • Особые предупреждающие сообщения - TLS предоставляет более точные и полные предупреждения о неполадках, обнаруженных одной из конечных систем. TLS также содержит информацию о том, когда какие сообщения с предупреждениями следует отправлять.

Протокол SSH

Протокол SSH (Secure Shell-оболочка безопасности) - это набор протоколов аутентификации с открытым ключом, позволяющий пользователю на стороне клиента безопасно регистрироваться на удалённом сервере.

Главная идея протокола заключается в том, что пользователь на стороне клиента, должен загрузить с удаленного сервера открытый ключ и установить с его помощью защищённый канал, используя криптографический мандат. Криптографическим мандатом пользователя является его пароль: его можно зашифровать с помощью полученного открытого ключа и передать на сервер.

Все сообщения шифруются с помощью IDEA .

Архитектура протокола SSH

SSH выполняется между двумя ненадёжными компьютерами, работающими в незащищенной сети( клиент - сервер).

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

  • Протокол транспортного уровня SSH (SSH Transport Layer Protocol), обеспечивает аутентификацию сервера. Для этого используется открытый ключ. Исходной информацией для этого протокола как со стороны сервера, так и со стороны клиента, является пара открытых ключей - "ключи головного компьютера". Итогом протоколом является взаимно аутентифицированный защищённый канал, который гарантирует секретность и целостность данных.
  • Протокол аутентификации пользователя SSH (SSH User Authentication Protocol). Выполняется по каналу односторонней аутентификации, установленному протоколом транспортного уровня SSH. Для выполнения аутентификации от клиента к серверу, поддерживаются различные протоколы односторонней аутентификации. Эти протоколы могут применять либо открытый ключ, либо пароль. Например, они могут быть созданы на основе протокола аутентификации с помощью простого пароля. Результатом протокола является взаимно аутентифицированный защищённый канал между сервером и пользователем. Применяются следующие методы:

publickey - клиент высылается ЭЦП Scauth.png, сервер проверяет доверие открытому ключу клиента Kcpub.png по имеющейся на сервере копии ключа, затем проверяет аутентичность клиента по Sc.

password - клиент подтверждает свою аутентичность паролем.

hostbased - аналогично publickey, только используется пара ключей для клиентского хоста; подтвердив аутентичность хоста, сервер доверяет имени пользователя.

  • Протокол связи SSH (SSH Connection Protocol) выполняется по взаимно аутентифицированному защищённому каналу, установленному предыдущими протоколами. Протокол обеспечивает работу защищённого канала при этом разделяя его на несколько защищённых логических каналов.


Протокол распределения ключами

Протокол включает в себя 3 этапа. Первый этап - "Hello" phase, где первый идентификатор это строка, I, отправляется, чтобы начать протокол, за которым следует список поддерживаемых алгоритмов - X.

На 2-й стадии стороны согласуют секретный ключ, s. Для этого применяется алгоритм Диффи-Хеллмана. Сервер подтверждает свою идентичность , отправляя клиенты свой открытый ключ, Pks.png, верифицированный цифровой подписью, Sigca.png, и подпись дайджеста, h. В качестве идентификатора sid устанавливается значение h.

На стадии 3 секретный ключ, идентификатор сессии и дайджест используются для создании 6 "apllication keys", вычисленных с помощью Kepk.png.

Keprus.png


Резюме

К преимуществам протокола относится:

  • возможность действий на сквозной основе (end - to - end) с осуществляющими стеками TCP/IP, существующими интерфейсами прикладного программирования;
  • повышенная эффективность по сравнению с медленными каналами;
  • отсутствие каких-либо проблем с фрагментацией, определением максимального объёма блоков, передаваемых по данному маршруту;
  • сочетание компрессии с шифрованием.

Глоссарий

Tуннель

OSI

SSH

SSL-протокол

IPsec

Протокол PPTP

Хеширование

ЕАР-TLS

Диффи-Хеллмана

IDEA

RSA

DSA

Функции хэширования

TLS

Библиографический указатель

Перейти к списку литературы

Вернуться на главную страницу

Вернуться к оглавлению

Практическое задание

Реализация слепой электронной цифровой подписи на основе ГОСТ 34.10-2012

Описание и реализация


Составители


Рогозин А.Д. / Сагиров Р.А. 2014 г.


Назад