Защита информации в ip-сетях

На сегодняшний день стек сетевых протоколов TCP/IP является наиболее широко используемым как в глобальных, так и в локальных компьютерных сетях. Именно поэтому методы и средства защиты передаваемых данных в IP-сетях представляют особый интерес.

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

3.1 ПРОТОКОЛ ЗАЩИТЫ ЭЛЕКТРОННОЙ ПОЧТЫ S/MIME

Протокол Secure Multipurpose Internet Mail Extensions (S/MIME)

предназначен для защиты данных, передаваемых в формате MIME, в основном – электронной почты. Он был предложен в 1995 году компанией RSA Data Security Inc. Дальнейшие работы над протоколом велись рабочей группой организации Internet Engineering Task Force (IETF), разрабатывающей стандарты сети Интернет. На данный момент, последней является версия 3.1 этого протокола, описываемая в документах RFC 3850, 3851, 3852. Протокол S/MIME предоставляет следующие криптографические услуги безопасности (криптографические сервисы):

- проверка целостности сообщения;

- установление подлинности отправителя (аутентификация);

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

- различный типов и т. д.). При использовании S/MIME добавляются новые типы (например, application/pkcs7-mime и application/pkcs7-signature). Это позволяет указать на то, что данные в этом разделе являются зашифрованными, подписанными и т. д. Протокол позволяет обычным почтовым клиентам защищать исходящую почту и интерпретировать криптографические сервисы, добавленные во входящую почту (расшифровывать сообщения, проверять их целостность и т. д.).

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

- Протокол S/MIME позволяет использовать различные криптоалгоритмы, причем их список может расширяться. Изначально, из симметричных шифров могли использоваться RC2, DES или TripleDES. Для формирования дайджестов – алгоритмы MD5 и SHA1, причем версия 3 стандарта рекомендует использовать именно последний алгоритм (из-за того, что он формирует более длинный дайджест и считается более надежным). Защита симметричного ключа шифрования и ЭЦП в версии 2 осуществляется с помощью алгоритма RSA с ключом от 512 до 1024 бит. Версия 3 добавляет возможность использовать другие алгоритмы, например алгоритм Диффи-Хеллмана с ключом длиной до 2048 бит. Распределение и аутентификация открытых ключей производится с помощью цифровых сертификатов формата X.509. Таким образом, чтобы защищать переписку с помощью этого протокола, оба абонента должны сгенерировать ключевые пары и удостоверить открытые ключи с помощью сертификатов. На Рисунок 3.1 приведен фрагмент письма, содержащий открытый текст «This is a clearsigned message.» и подпись к нему.

S/MIME поддерживается многими почтовыми клиентами: Mi-crosoft Outlook, Mozilla, The Bat! и т. д. Более широкое применение протокола сдерживается необходимостью наличия сертификатов у абонентов и плохой совместимостью с системами Web-почты.

Рисунок 3.1 - Фрагмент электронного письма с подписью

Альтернативой S/MIME является PGP (англ. «Pretty Good Priva-cy») – компьютерная программа созданная Филиппом Циммерманном (Philip Zimmermann) в 1991 году. Данная программа положила основу работе над стандартом OpenPGP, последняя версия которого описана в RFC 4880. По функциональности S/MIME и PGP во многом сходны.

ПРОТОКОЛЫ SSL И TLS

Протокол Secure Sockets Layer (SSL) был разработан корпорацией Netscape Communications для обеспечения аутентификации, целостности и секретности трафика на сеансовом уровне модели OSI (с точки зрения четырехуровневой модели стека протоколов TCP/IP – на прикладном уровне). В январе 1999 года на смену SSL v3.0 пришел протокол TLS v1.0 (Transport Layer Security) последняя версия TLS v.1.2 описывается в RFC 5246. С точки зрения выполняемых действий, различия между этими протоколами SSL и TLS весьма невелики, в то же время, они несовместимы друг с другом [11]. SSL обеспечивает защищенное соединение, которое могут ис-пользовать протоколы более высокого уровня – HTTP, FTP, SMTP и т. д. Наиболее широко он используется для защиты данных переда-ваемых по HTTP (режим HTTPS). Для этого должны использоваться SSL-совместимые web-сервер и браузер.

Протокол предусматривает два этапа взаимодействия клиента и сервера:

1) установление SSL-сессии (процедура «рукопожатия», от англ. «handshake») на этом этапе может производиться аутентификация сторон соединения, распределение ключей сессии, определяются настраиваемые параметры соединения;

2) защищенное взаимодействие.

Протоколом SSL используются следующие криптоалгоритмы:

- асимметричные алгоритмы RSA и Диффи-Хеллмана;

- алгоритмы вычисления хэш-функций MD5 и SHA1;

- алгоритмы симметричного шифрования RC2,RC4, DES, TripleDES, IDEA.

В протоколе SSL v 3.0 и TLS перечень поддерживаемых алгоритмов является расширяемым. Для подтверждения подлинности от-крытых ключей используются цифровые сертификаты формата X.509.

Протокол SSL позволяет проводить следующие варианты аутентификации сторон взаимодействия:

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

- взаимная аутентификация сторон (проверяется подлинность как клиента, так и сервера);

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

Рассмотрим более подробно процедуру рукопожатия в режиме аутентификации сервера без аутентификации клиента. Она включает следующие шаги [13].

1. Клиент посылает серверу запрос на установление защищенного соединения, в котором передает, в частности, следующие параметры:

- дату и текущее время; - сгенерированную клиентом случайную последовательность

(RAND_CL);

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

2. Сервер обрабатывает запрос от клиента и передает ему согласованный набор параметров:

- идентификатор SSL-сессии;

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

- цифровой сертификат сервера формата X.509;

- случайную последовательность (RAND_SERV).

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

- генерирует случайную 48-байтную последовательность, называемую PreMasterSecret, предназначенную для расчета общего секретного ключа;

- шифрует значение PreMasterSecret с использованием открытого ключа сервера, взятого из сертификата, и посылает криптограмму серверу;

- с помощью согласованной с сервером хэш-функции формирует общий секретный ключ (MasterSecret), используя в качестве параметров последовательность PreMasterSecret, посланную ранее серверу случайную последовательность RAND_CL и полученную от него случайную последовательность RAND_SERV;

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

- переходит в режим защищенного взаимодействия.

4. Сервер, используя свой секретный ключ, расшифровывает полученное значение PreMasterSecret и выполняет те же операции, что

и клиент:

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

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

- переходит в режим защищенного взаимодействия.

Так как при формировании параметров SSL-сессии и клиент, и сервер пользовались одними и теми же исходными данными (согласованными алгоритмами, общей секретной последовательностью PreMasterSecret и случайными последовательностями RAND_CL и RAND_SERV), то очевидно, что в результате описанных выше действий они выработали одинаковые сеансовые секретные ключи. Для

проверки идентичности параметров SSL-сессии клиент и сервер посылают друг другу тестовые сообщения, содержание которых известно каждой из сторон:

- клиент формирует сообщение из собственных посылок в адрес сервера на шаге 1 и посылок, полученных от сервера на шаге 2, внося элемент случайности в виде последовательности MasterSecret, уникальной для данной сессии; формирует код для проверки целостности сообщения (MAC), шифрует сообщение на общем сеансовом секрет-ном ключе и отправляет серверу;

- сервер, в свою очередь, формирует сообщение из собственных посылок в адрес клиента на шаге 2, посылок, полученных от клиента на шаге 1, и последовательности MasterSecret; формирует код для проверки целостности сообщения (MAC), шифрует сообщение на общем сеансовом секретном ключе и отправляет клиенту;

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

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

В процессе защищенного взаимодействия с установленными криптографическими параметрами SSL-сессии выполняются следующие действия:

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

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

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