Криптографические протоколы

· Обеспечение надежности соединения. Пересылка включает в себя контроль целостности сообщений с применением кода аутентификации MAC (Message Autentification Code) и хэш функций (SHA или MD5).

Рассмотрим базовые принципы, на которых основан протокол ssl. Первая проблема, которую решает данный протокол, - идентификация клиента. Это делается с использованием алгоритма RSA, использующего схему двух ключей. Если необходимо идентифицировать клиента А, он посылает серверу свой открытый ключ. Сервер пересылает клиенту некоторое сообщение, которое клиент шифрует с помощью своего секретного ключа и посылает серверу. Сервер дешифрует это сообщение с помощью открытого ключа клиента и сравнивает с исходным текстом. При совпадении клиент однозначно идентифицирован. Действительно ведь только он владеет секретным ключем. Перехват и любая попытка фальсификации сообщения здесь не пройдут. Но еще большую надежность достигается, когда клиент шифрует не само сообщение, а дайджест этого сообщения. Так как по дайджесту практически невозможно восстановить исходное сообщение. Такая система называется электронной подписью. Но для решения проблемы идентификации серверу необязательно присылать сообщение, текст сообщения может послать вместе с зашифрованной копией и сам клиент. Но в этом случае злоумышленнику нетрудно имитировать обмен и выдать себя за соответствующего клиента. Чтобы исключить такую возможность, разработана система сертификации. Сертификат включает в себя идентификатор эмитента сертификата, объект, для которого сформирован сертификат, общедоступный ключ объекта и временные метки. Сертификат представляет собой стандартное средство установления связи между открытым ключем и именем его владельца. Сертификат подписывается секретным ключем субъекта, сформировавшего сертификат (эмитентом). Открытый ключ эмитента сертификата общеизвестен. Злоумышленник может узнать сертификат клиента, но не его секретный ключ. В рамках данного протокола можно пересылать и специальный секретный ключ, который может использоваться в симметричных алгоритмах DES, RC4 или IDEA.

Злоумышленник, расположившийся между отправителем и получателем не может прочесть зашифрованные сообщения, но может их исказить. Чтобы противодействовать этому вводится код аутентификации сообщения (MAC). В качестве MAC используется фрагмент сообщения, зашифрованный с помощью специального секретного ключа. При этом может использоваться также технология MD5, что дает 128-битовый дайджест. Применение такого дайджеста делает вероятность случайного подбора равной ~1/[20*10¹⁸].

В рамках протокола SSL определены четыре вида шифрования:

· digitally-signed (шифрование электронной подписи)

· stream-ciphered (поточное шифрование)

· block-ciphered (блочное шифрование)

· publick-key-encrypted (шифрование с помощью открытого ключа)

Электронная подпись предполагает использование хэширования до шифрования. В RSA-подписи 36-байтовая структура двух хэш-функций SHA и MD5 шифруется с помощью закрытого ключа. В DSS 20-байтовый блок хэш-функции SHA непосредственно передается на обработку алгоритму цифровой подписи без дополнительного хэширования.

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

В блочном шифровании каждый блок исходного текста преобразуется в равный ему по размеру шифрованный текст. Обычно размер блока равен 64 байтам. Если необходимо исходный текст дополняется до требуемого размера блока нулями.

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

Протокол SSL предполагает последовательный переход клиента и сервера из одного состояние в другое. Каждая процедура реализуема в строго определенном состоянии объекта. Диалоговая часть протокола SSL позволяет координировать работу машин состояний клиента и сервера. Логически любое состояние представляется дважды, в качестве рабочего (operating) состояния и рассматриваемого состояния (pending). Предусмотрены, кроме того, состояния чтения и записи. Когда клиент или сервер получает сообщение change cipher spec, он копирует рассматриваемое состояние в текущее состояние чтения. При посылке сообщения change cipher spec клиент или сервер копирует рассматриваемое состояние в текущее состояние записи. Когда диалог согласования завершен, клиент и сервер обмениваются сообщениями change cipher spec, после чего взаимодействуют друг с другом, используя согласованную спецификацию шифрования. Протокол SSL допускает любое число соединений между клиентом и сервером в рамках одной сессии. Разрешена также реализация произвольного числа сессий параллельно.

Состояние сессии характеризуется рядом параметров.

Параметр	Описание параметра
session identifier	Произвольная последовательность байтов, выбранная сервером чтобы идентифицировать активную сессию
peer sertificate	Сертификат партнера - X509.v3. Этот элемент может быть равен нулю
compression method	Алгоритм, используемый для сжатия информации перед шифрованием
cipher spec	Спецификация алгоритма шифрования данных (например, нуль или DES) и алгоритм MAC (например MD5 или SHA). Она определяет криптографические атрибуты, такие как hash_size.
master secret	48-байтовый секретный код, общий для клиента и сервера
is resumable	Флаг, указывающий, что сессия может использоваться для формирования новых соединений

Состояние соединения характеризуется следующими параметрами.

Параметр	Описание параметра
server and client random	Последовательность байтов, выбираемая сервером и клиентом для каждого соединения
server write mac secret	Секретный код, используемый в MAC-операциях с данными, записанными сервером
client write MAC secret	Секретный код, используемый в MAC-операциях с данными, записанными клиентом
server write key	Ключ шифрования данных шифруемых сервером и дешифруемых клиентом
client write key	Ключ шифрования данных шифруемых клиентом и дешифруемых сервером
initialization vectors	Когда используется блочный шифр в режиме CBC, для каждого ключа поддерживается инициализационный вектор (IV). Это поле устанавливается первым в процессе стартового диалога.
sequence numbers	Каждая из сторон поддерживает свои номера по порядку для переданных и полученных сообщений для каждого из соединений. Когда партнер посылает или получает сообщение change cipher spec, соотвествующее число, характеризующее номер обнуляется. Значение номера не может превышать 264-1.

Уровень записей протокола ssl осуществляет фрагментацию сообщений, разбивая их на блоки 2¹² байт или короче. Все записи сжимаются с использованием согласованного для данной сессии алгоритма архивации. Сжатие всегда должно производиться без потерь и не может увеличивать длину содержимого более чем на 1024 байта. Все записи защищаются с помощью шифрования и алгоритма МАС, заданного в текущей спецификации cipherspec.

В процессе диалога (handshake protocol) фиксируются следующие атрибуты: версия протокола, идентификатор сессии, шифровой набор и метод сжатия информации. Когда диалог согласования завершен, партнеры имеют общий секретный код, который используется для шифрования записей и для вычисления аутентификационных кодов МАС. Методики шифрования и вычисления МАС заданы в спецификации cipherspec. mac вычисляется до шифрования основных данных. Протокол диалога является одним из клиентов высокого уровня протокола записей SSL.

Для блочных шифров (RC2 или DES) шифрование и МАС-функции преобразуют структуры sslcompressed.fragment в структуры sslciphertext.fragment.

SSL использует симметричную модель для шифрования (DESв режиме CBC, тройной DES, RC2 или RC4). Для формирования дайджеста сообщения применяется стандарт MD5 или алгоритм хэширования SHA. Для аутентификации здесь используется система с общедоступным ключом RSA или алгоритм транспортировки закрытых ключей Диффи-Хелмана.

Конфигурации этих средств безопасности стандартизованы (см. табл. 1).

Таблица 1

Набор	Уровень безопасности	Описание
DES-CBC3-MD5	Очень высокий	Тройной DES в режиме CBC, хэш MD5, 168-битный ключ сессии
DES-CBC3-SHA	Очень высокий	Тройной DES в режиме CBC, хэш SHA, 168-битный ключ сессии
RC4-MD5	Высокий	RC4, хэш MD5, 128-битный ключ
rc4-sha	Высокий	RC4, хэш SHA, 128-битный ключ
RC2-CBC-MD5	Высокий	RC2 в режиме CBC, хэш MD5, 128-битный ключ
DES-CBC-MD5	Средний	DES в режиме CBC, хэш MD5, 56-битный ключ
DES-CBC-SHA	Средний	DES в режиме CBC, хэш SHA, 56-битный ключ
EXp-DES-CBC-SHA	Низкий	DES в режиме CBC, хэш SHA, 40-битный ключ
EXP-RC4-MD5	Низкий	Экспортное качество RC4, хэш MD5, 40-битный ключ
EXP-RC2-CBC-MD5	Низкий	Экспортное качество RC2, хэш MD5, 40-битный ключ
null-MD5	-	Без шифрования, хэш MD5, только аутентификация
null-SHA	-	Без шифрования, хэш SHA, только аутентификация

Когда клиент пытается установить связь с сервером, возникает диалог, во время которого определяется конфигурация набора средств безопасности. Обычно это наиболее эффективный набор, поддерживаемый каждым из партнеров. Некоторые WEB-сервера позволяют администратору произвести дополнительную настройку этого переговорного процесса. Например, разрешить доступ к некоторым секциям каталога только клиентам, поддерживающим высокий уровень безопасности. SSL имеет встроенный модуль сжатия исходной информации. При обмене шифруются URL запрошенного документа и сам документ, заполняемые формы и бланки, HTTP-заголовок и некоторая другая информация. Схема работы ssl пояснена на рис. 1.

Рис. 1. Алгоритм работы SSL

Сообщение ClientHello содержит в себе информацию о клиенте, включая номер поддерживаемой версии SSL. Сообщение ServerHello несет в себе идентификатор сессии и информацию о том, какой набор средств безопасности и метод сжатия данных выбрал сервер. Сертификат сервера решает проблему аутентификации. Запрос сертификата клиента является опционным (и пока используется достаточно редко). В ответ на такой запрос клиент должен прислать сертификат или уведомление о его отсутствии. Сообщение ClientKeyExchange служит для выбора симметричного ключа. Для разных наборов средств безопасности процедура, разумеется, варьируется. Ключ шифруется перед отправкой с помощью общедоступного RSA-ключа, извлеченного из сертификата сервера. Сообщение CertificateVerify является опционным и посылается лишь в случае аутентификации клиента (если клиент посылал свой сертификат). Обмен сообщениями ChangeCipherSpec между клиентом и сервером свидетельствует о том, что они оба готовы к обмену информацией с использованием оговоренных шифров и ключа сессии. Обмен сообщениями Finished, содержащими хэш-функции MD5 и SHA, позволяет убедиться партнерам, что вся информация дошла до них неповрежденной. Сообщение Finished посылается сразу после отправки сообщения change cipher specs, подтверждая, что обмен ключами и аутентификация завершились успешно. Подтверждение получения самого сообщения Finished не нужно. После этого обмена система клиент-сервер готова к шифрованному обмену и может его начать немедленно. Рассмотренный сценарий может несколько варьироваться. Так сервер вместо посылки своего сертификата (X.509v3) может послать сообщение ServerKeyExchange. Такая модификация может произойти, если, например, планируется применение обмена ключами по методу Диффи-Хелмана. Заметим, что в этом случае взаимная идентификация не производится и, вообще говоря, сессия может подвергнуться атаке со стороны посредника, находящегося между клиентом и сервером.

Пример работы протокола

На рисунке описаны основные сообщения, которыми обмениваются пользователь (Боб) и веб-сервер (Элис). Пользователь, использует браузер для доступа к серверу, который поддерживает SSL. Такая ситуация может возникать, например, при заказе товара по Интернет.



Прежде чем веб-сервер начнет взаимодействовать с клиентом, на веб-сервере должен быть установлен сертификат подписанный центром сертификатов (CA). Браузер клиента должен знать этот центр сертификатов (доверять ему). Это значит, что сертификат этого центра сертификатов уже установлен в браузере и срок действия сертификата не истек. Если сертификат не установлен, то при доступе клиента к веб-серверу, у него высветится сообщение предлагающее принять или отклонить сертификат веб-сервера, так как он подписан неизвестным центром сертификатов.

Для получения сертификата Элис необходимо:

1. Подготовить запрос на получение сертификата для отправки его CA:

o Сгенерировать пару открытый/закрытый ключ (с помощью утилиты генерации ключей, которая обычно есть в веб-сервере).

o Сгенерировать запрос на получение сертификата, который включает в себя идентифицирующую информацию о компании Элис (Distinguished Name) и открытый ключ.

o Отправить запрос на получение сертификата выбранному CA (например, запрос может быть отправлен почтой).

2. В ответ на запрос CA отправляет Элис цифровой сертификат, в котором содержится открытый ключ Элис, подписанный CA.

3. После получения ответа от CA, Элис помещает цифровой сертификат в базу сертификатов веб-сервера.

После того как Элис установила цифровой сертификат подписанный CA, она может начинать работу с клиентами. Когда Боб обращается к веб-серверу Элис, выполняются такие действия:

4. Боб обращается с веб-серверу Элис. При этом броузер Боба автоматически скачает цифровой сертификат с веб-сервера Элис.

5. Браузер Боба определит доверяет ли он CA, который подписал цифровой сертификат Элис:

§ Сертификат CA дожен быть уже установлен в браузере Боба.

§ Если сертификат установлен и срок его действия не истек, то дальнейший процесс будет прозрачным для Боба.

§ Браузер дешифрует цифровой сертификат Элис с помощью открытого ключа CA, который получен из цифрового сертификата CA.

§ Теперь у браузера Боба есть открытый ключ Элис.

6. Боб отправляет Элис сообщение в котором содержится сессионный ключ и шифрует его с помощью открытого ключа Элис:

§ Сессионный ключ используется для шифрования трафика между Бобом и Элис.

§ Этот ключ симметричный и будет использоваться для шифрования и дешифрования данных передаваемых между Бобом и Элис.

§ Так как сообщение можно расшифровать только закрытым ключем Элис, то сессионный ключ безопасно доставляется на веб-сервер Элис.

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

§ Все дальнейшие сообщения шифруются с помощью сессионного ключа (может передаваться информация о адресе, телефоне, кредитной карточке Боба).

§ В зависимости от длительности соединения с веб-сервером, может использоваться несколько сессионных ключей, которые будут меняться после истечения их срока жизни.



Практическая работа № 7. Socks протокол

На сегодняшний день SOCKS прокси (иногда ошибочно называют Socs, Sox, Soks) самый прогрессивный протокол передачи информации. Он разработан Дейвом Кобласом (Dave Koblas). Данный протокол пережил множество изменений и на данный момент используются две версии протокола - Socks4 и Socks5. Протокол представляет собой транслятор, но по сравнению с другими прокси Socks-клиент находится между прикладным и транспортным уровнем в сети. Socks-сервер располагается на прикладном уровне. Из этого можно сделать вывод, что такой сервер никоим образом не привязан к протоколам высокого уровня. Протокол Socks разрабатывался для того, чтобы программы, которые работают на основе TCP и UDP, смогли воспользоваться ресурсами сети, доступ к которым был ограничен настройками сети или архитектурой приложения (например, для приложений, которые не поддерживают использование прокси: TheBat, Opera и другие приложения, у которых отсутствует поддержка использования прокси).

Существует несколько различий между версиями протокола. Socks4 поддерживает TCP. Socks5 (RFC 1928) - это развитие четвертой версии протокола и включает в себя поддержку UDP. Socks 5 расширяет общую структуру, позволяя использовать обобщенные схемы идентификации, и систему адресации с именем домена и адреса IPv6. Простыми словами, Socks 4 поддерживает только TCP. Socks 5 поддерживает TCP, UDP, авторизацию по логину и паролю и возможность удаленного DNS-запроса.

Socks обеспечивает полную анонимность в Интернете. Например, все браузеры используют протокол HTTP (данный протокол работает на TCP), и нам нет никакой разницы какую версию Socks использовать. Socks не имеет никакого отношения к HTTP и не занимается модерацией HTTP-заголовков. Поэтому Socks-сервер будет передавать информацию через себя в чистом виде. Таким образом, все Socks-серверы являются анонимными. Socks прокси не передает информацию о вашем IP адресе. Благодаря этому посещаемый вами Web сервер никоим образом не сможет определить, что вы используете Socks прокси. Для него ваше соединение будет абсолютно прозрачным, также как если бы вы работали с ним напрямую. Кроме того, что Web сервер будет видеть IP адрес сокса, а не ваш. Еще одно удобство при работе с Socks связано с тем, что он может работать со многими протоколами, такими как HTTP, HTTPS, FTP и другими, поэтому достаточно одного Socks для работы.

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

Существует несколько методов использования Socks. Процесс использования Socks называется соксификацией (Socksify) приложения. Вы можете соксифицировать браузер напрямую, поискав в настройках браузера поле Socks. Или, что гораздо удобнее использовать программы-соксификаторы. В большинстве ОС этот процесс уже встроен в систему. Например, в Linux SOCKSифицировать приложение можно с помощью: runsocks-приложение. Для ОС Windows существует множество программ-соксификаторов, такие как FreeCap, SocksCap, Sockschain, Proxifier и Proxy Helper. После регистрации на нашем сайте, внутри вашего аккаунта (раздел FAQ) вы можете найти подробные инструкции по настройке разных приложений.

Плюсы и минусы Socks прокси с точки зрения вашей безопасности и анонимности:

+ работает со многими протоколами: HTTP, HTTPS, FTP и другими;

+ НЕ передает ваш реальный IP адрес в запросах, является абсолютно анонимным;

+ цепочка из соксов многократно увеличивает вашу анонимность;

- действительно хороший Socks сервер стоит денег.

Как работает Socks (Socks4, Socks5)

Socks5 и Socks4 позволяют создать цепь из нескольких серверов, тем самым достигается наивысшая анонимность в сети

На данное время существует две самые распространённые версии протокола - Socks4 и Socks5. А также есть и подверсия протокола Socks4a.

Socks4 - решает вопрос незащищенного пересечения межсетевых экранов приложениями клиент/сервер, основанными на протоколе TCP.

Socks5, [RFC 1928], является дальнейшим расширением четвертой версии протокола SOCKS. Он включает в себя UDP, и намного расширяет общую рамочную структуру, придавая ей возможность использования мощных и обобщенных схем идентификации, а так же расширяет систему адресации, включая в нее имя домена и адреса IP v.6. Что является более улучшенной модификацией этой линейки.

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

Socks4 создавался для решения вопроса незащищенного перемещения через межсетевые экраны всеми программами клиент/сервер, разработанных на основе протокола TCP.

Socks5 (или RFC 1928) дальнейшая разработка предыдущей версии, включающая в себя UDF. Он дополняет общую структуру (в частности, предоставляя возможность использования различных схем идентификации) и адресную систему (путем включения в неё IP-адреса v.6 и имени домена).

То есть, 4-я версия поддерживает TCP, а 5-я, помимо этого, авторизацию, dns-запрос и UDF.

Так как Socks работает напрямую с TCP, он не имеет никакого отношения к модернизации заголовков http-запросов.

Socks-сервер будет передавать все данные в чистом виде от первого лица - только от себя. А значит в таком случае, можно сказать, что все Socks-серверы "Анонимные".

Socks4/5 не передает информацию о вашем IP-адресе, потому, что это никак не предусмотрено его технологией.

Соответственно, отпадает множество проблем. Кроме того, что он не передает IP-адрес, он естественно, как было написано выше, не модернизирует http-заголовки, а это означает, что web-сервер никаким образом не может определить, что вы используете proxy-сервер. Для него работа с вами будет абсолютно аналогичной, как если бы вы работали непосредственно с web-сервером, с той лишь разницей, что он будет видеть совсем другой IP-адрес, а точнее, IP-адрес Socks-сервера.

Технологии Socks4/5 легко поддерживают построение в цепь нескольких серверов.

Цепь из Socks Серверов

Как уже было сказано выше, технология Socks4/5 поддерживает построение в цепь нескольких серверов. Здесь можно отметить, что некоторые HTTP(S) proxy-серверы так же могут выстраиваться в цепь, но в этом случае есть много проблем.

Во-первых, из 100% работающих Прокси серверов Анонимными могут оказаться 10-35%, из них, возможно, 1% будет поддерживать возможность перенаправлять запросы, то есть выстраиваться в цепь.

Во-вторых, использование такой возможности HTTP Proxy браузером прямо не предусмотрена, но если все же использовать некоторые методы, то останется множество поблем, главной из которых будет потенциальная возможность передачи данных напрямую, минуя прокси.

Для решения этой задачи и есть новое лучшее средство - это технология Socks4 и Socks5.

Так что же дает возможность выстраивания в цепь Socks-серверов?

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

Данные, которые "ходят" между браузером и web-сервером, будут передаваться через все серверы, которые вы выстроили в цепь, возможно не раз обойдя земной шар, пока не достигнут цели. Как понимаете, возможность того что вас могут вычислить в данной ситуации является маловероятной и на практике не выполнимой.



Практическая работа № 8. Использование стека IPSEC в защиты канала

IPSec (сокращение от IP Security) - определенный IETF стандарт достоверной/конфиденциальной передачи данных по сетям IP. Чаще всего IPSec используется для создания VPN (Virtual Private Network).

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

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

Рисунок 1 - Модель OSI/ISO

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

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

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

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

- аутентификационный заголовок (АН);

- безопасное сокрытие данных (ESP);

- режимы работы: туннельный и транспортный;

- контексты (ассоциации) безопасности (SA);

- управление ключами (IKE);

Основные составляющие архитектуры и их особенности

Архитектура средств безопасности для IP-уровня специфицирована в документе Security Architecture for the Internet Protocol. Ее основные составляющие представлены в соответствии с рисунком 2.1. Это, прежде всего протоколы обеспечения аутентичности (протокол аутентифицирующего заголовка - Authentication Header, AH) и конфиденциальности (протокол инкапсулирующей защиты содержимого - Encapsulating Security payload, ESP), а также механизмы управления криптографическими ключами. На более низком архитектурном уровне располагаются конкретные алгоритмы шифрования, контроля целостности и аутентичности. Наконец, роль фундамента выполняет так называемый домен интерпретации (Domain of Interpretation, DOI), являющийся, по сути, базой данных, хранящей сведения об алгоритмах, их параметрах, протокольных идентификаторах.



Рисунок 2 - Основные элементы архитектуры средств безопасности IP-уровня

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

IPSec поддерживает две формы целостности: целостность соединения и частичную целостность последовательности. Целостность соединения является сервисом безопасности, который определяет модификацию конкретной IP датаграммы, безотносительно последовательности датаграмм в потоке трафика. Частичная целостность последовательности является anti-reply сервисом, с помощью которого определяется получение дубликатов IP датаграм.

Эти сервисы как раз и реализуются с использованием двух протоколов обеспечения безопасного трафика, Authentication Header (AH) и Encapsulating Security Payload (ESP), и с помощью процедур и протоколов управления криптографическим ключом. Множество применяемых IPSec протоколов и метод их использования определяются требованиями безопасности.

Когда данные механизмы установлены корректно, они не мешают пользователям, хостам и другим компонентам Internet, которые не применяют данные механизмы безопасности для защиты своего трафика. Протоколы обеспечения аутентичности и конфиденциальности в IPSec не зависят от конкретных криптографических алгоритмов. (Более того, само деление на аутентичность и конфиденциальность предоставляет и разработчикам, и пользователям дополнительную степень свободы в ситуации, когда к криптографическим относят только шифровальные средства.) В каждой стране могут применяться свои алгоритмы, соответствующие национальным стандартам, но для этого, как минимум, нужно позаботиться об их регистрации в домене интерпретации. Это означает возможность выбора различного набора алгоритмов без воздействия на другие части реализации. Например, различные группы пользователей могут выбрать при необходимости различные наборы алгоритмов.

Определен стандартный набор алгоритмов по умолчанию для обеспечения интероперабельности. Использование этих алгоритмов совместно с защитой трафика на основе IPSec и протоколами управления ключа позволяет обеспечить высокую степень криптографической безопасности.

Алгоритмическая независимость протоколов имеет и оборотную сторону, состоящую в необходимости предварительного согласования набора применяемых алгоритмов и их параметров, поддерживаемых общающимися сторонами. Иными словами, стороны должны выработать общий контекст безопасности (Security Association, SA) и затем использовать такие его элементы, как алгоритмы и их ключи. SA подробно рассматривается далее. За формирование контекстов безопасности в IPSec отвечает особое семейство протоколов ISAKMP, которое рассматривается также в отдельном разделе.

Безопасность, обеспечиваемая IPSec, зависит от многих факторов операционного окружения, в котором IPSec выполняется. Например, от безопасности ОС, источника случайных чисел, плохих протоколов управления системой.



Размещение и функционирование IPSEC

IPSec выполняется на хосте или шлюзе безопасности, обеспечивая защиту IP- трафика. Термин <шлюз безопасности> используется для обозначения промежуточной системы, которая реализует IPSec-протоколы. Защита основана на требованиях, определенных в Базе Данных Политики Безопасности (Security Policy Database- SPD), определяемой и поддерживаемой системным администратором. Пакеты обрабатываются одним из трех способов на основании соответствия информации заголовка IP или транспортного уровня записям в SPD. Каждый пакет либо отбрасывается сервисом безопасности IPSec, либо пропускается без изменения, либо обрабатывается сервисом IPSec на основе применения определенной политики.

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

IPSec использует два протокола для обеспечения безопасности трафика - Authentication Header (AH) и Encapsulating Security Payload (ESP). Хотя бы один из этих сервисов должен быть задействован при использовании ESP.

Эти протоколы могут применяться как по отдельности так и в комбинации с друг другом для обеспечения необходимого набора сервисов безопасности в IPv4 и IPv6. Каждый протокол поддерживает два режима использования: режим транспорта и режим туннелирования. В транспортном режиме протоколы обеспечивают защиту главным образом для протоколов более высокого уровня; в режиме туннелирования протоколы применяются для скрытия IP-заголовков исходных пакетов. Разница между двумя режимами рассматривается дальше.

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

а) какие сервисы используются, и в какой комбинации;

б) необходимый уровень детализации применяемой защиты;

в) алгоритмы, используемые для обеспечения безопасности на основе криптографии;

Существует несколько способов реализации IPSec на хосте или в соединении с роутером или firewall (для создания безопасного шлюза). Несколько общих примеров:

а) интеграция IPSec в конкретную реализацию IP, что требует доступа к исходному коду IP и применимо как к хостам, так и к шлюзам безопасности;

б) bump-in-the-stack (BITS) реализации, где IPSec действует <внизу> существующей реализации стека протоколов IP, между обычным IP и локальными сетевыми драйверами; доступа к исходному коду стека IP в данном контексте не требуется, что делает такой подход пригодным для встраивания в существующие системы, и реализации на хостах;

в) использование внешнего криптопроцессора (обычно в военных и в некоторых коммерческих системах), как правило, это является Bump-in-the-stack (BITS) реализацией, используется как на хостах, так и на шлюзах, обычно BITS-устройства являются IP-адресуемыми;

Транспортный режим работы

В этом варианте механизмы безопасности применяются только для протоколов, начиная с транспортного (TCP) уровня и выше, оставляя данные самого сетевого уровня (заголовок IP) без дополнительной защиты. Места размещения дополнительной информации, вставляемой протоколами в пакет, представлены в соответствии с рисунком 3.1.

Рисунок 3 - Транспортный режим

Туннельный режим работы

Этот режим интересен тем, что обеспечивает защиту также и данных сетевого уровня путем добавления нового IP-заголовка. После определения ассоциаций безопасности (например, между двумя шлюзами) истинные адреса хостов отправления и назначения (и другие служебные поля) полностью защищаются от модификаций для АН или вообще скрываются для ESP, а в новый заголовок выставляются адреса и другие данные для шлюзов (отправления/получения). В соответствии с рисунком 3.2 видны преимущества и недостатки обоих протоколов. ESP обеспечивает сокрытие данных, но не полную аутентификацию всего пакета. АН полностью аутентифицирует, но не скрывает данные. В этом причина того, что для обеспечения высокого уровня безопасности, применение протоколов совмещается.



Рисунок 4. - Туннельный режим

Размещено на Allbest.ru

...