Файл: Основыинформационнойбезопасности.pdf

96
Альтернативой S/MIME является PGP (англ. «Pretty Good Priva- cy») — компьютерная программа, созданная Филиппом Циммерман- ном (Philip Zimmermann) в 1991 году. Данная программа положила основу работе над стандартом OpenPGP, последняя версия которого описана в RFC 4880. По функциональности S/MIME и PGP во многом сходны.
3.2. ПРОТОКОЛЫ 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;

97
- алгоритмы симметричного шифрования RC2, RC4, DES, Tri- pleDES, IDEA.
В протоколе SSL v 3.0 и TLS перечень поддерживаемых алго- ритмов является расширяемым. Для подтверждения подлинности от- крытых ключей используются цифровые сертификаты формата X.509.
Протокол SSL позволяет проводить следующие варианты аутен- тификации сторон взаимодействия:
- аутентификация сервера без аутентификации клиента (одно- сторонняя аутентификация) — это наиболее часто используемый ре- жим, позволяющий установить подлинность сервера, но не проводя- щий проверки клиента (ведь подобная проверка требует и от клиента наличия сертификата);
- взаимная аутентификация сторон (проверяется подлинность как клиента, так и сервера);
- отказ от аутентификации — полная анонимность; в данном случае SSL обеспечивает шифрование канала и проверку целостно- сти, но не может защитить от атаки путем подмены участников взаи- модействия.
Рассмотрим более подробно процедуру рукопожатия в режиме аутентификации сервера без аутентификации клиента. Она включает следующие шаги [13].
1. Клиент посылает серверу запрос на установление защищенно- го соединения, в котором передает, в частности, следующие парамет- ры:
- дату и текущее время;
- сгенерированную клиентом случайную последовательность
(RAND_CL);
- перечень поддерживаемых клиентом алгоритмов шифрования, хеширования и сжатия (если сжатие используется).
2. Сервер обрабатывает запрос от клиента и передает ему согла- сованный набор параметров:
- идентификатор SSL-сессии;

98
- идентификаторы криптографических алгоритмов из числа предложенных клиентом, которые будут использоваться в данной сессии (если по какой-либо причине предложенные алгоритмы или их параметры не удовлетворяют требованиям сервера, сессия закрывает- ся);
- цифровой сертификат сервера формата X.509;
- случайную последовательность (RAND_SERV).
3. Клиент проверяет полученный сертификат и соответствие ро- ли ключа его назначению, описанному в сертификате. При отрица- тельном результате проверки сессия закрывается, а при положитель- ном клиент выполняет следующие действия:
- генерирует случайную 48-байтную последовательность, назы- ваемую Pre_MasterSecret, предназначенную для расчета общего сек- ретного ключа;
- шифрует значение Pre_MasterSecret с использованием откры- того ключа сервера, взятого из сертификата, и посылает криптограм- му серверу;
- с помощью согласованной с сервером хэш-функции формирует общий секретный ключ (MasterSecret), используя в качестве парамет- ров последовательность Pre_MasterSecret, посланную ранее серверу случайную последовательность RAND_CL и полученную от него слу- чайную последовательность RAND_SERV;
- используя значение MasterSecret, вычисляет криптографиче- ские параметры SSL-сессии: формирует общие с сервером сеансовые секретные ключи для симметричного шифрования и вычисления хэш- функций;
- переходит в режим защищенного взаимодействия.
4. Сервер, используя свой секретный ключ, расшифровывает по- лученное значение Pre_MasterSecret и выполняет те же операции, что и клиент:
- с помощью согласованной с клиентом хэш-функции формиру- ет общий секретный мастер-ключ (MasterSecret), используя в качестве

99 параметров значение Pre_MasterSecret, а также посланную клиенту случайную последовательность RAND_SERV и полученную от него случайную последовательность RAND_CL;
- используя значение MasterSecret, вычисляет криптографиче- ские параметры SSL-сессии: формирует общие с клиентом сеансовые секретные ключи для симметричного шифрования и вычисления хэш- функций;
- переходит в режим защищенного взаимодействия.
Так как при формировании параметров SSL-сессии и клиент, и сервер пользовались одними и теми же исходными данными (согла- сованными алгоритмами, общей секретной последовательностью
Pre_MasterSecret и случайными последовательностями RAND_CL и
RAND_SERV), то очевидно, что в результате описанных выше дей- ствий они выработали одинаковые сеансовые секретные ключи. Для проверки идентичности параметров SSL-сессии клиент и сервер по- сылают друг другу тестовые сообщения, содержание которых извест- но каждой из сторон:
- клиент формирует сообщение из собственных посылок в адрес сервера на шаге 1 и посылок, полученных от сервера на шаге 2, внося элемент случайности в виде последовательности MasterSecret, уни- кальной для данной сессии; формирует код для проверки целостности сообщения (MAC), шифрует сообщение на общем сеансовом секрет- ном ключе и отправляет серверу;
- сервер, в свою очередь, формирует сообщение из собственных посылок в адрес клиента на шаге 2, посылок, полученных от клиента на шаге 1, и последовательности MasterSecret; формирует код для проверки целостности сообщения (MAC), шифрует сообщение на об- щем сеансовом секретном ключе и отправляет клиенту;
- в случае успешной расшифровки и проверки каждой из сторон целостности полученных тестовых сообщений SSL-сессия считается установленной, и стороны переходят в штатный режим защищенного взаимодействия.

100
Необязательная вторая фаза рукопожатия позволяет аутентифи- цировать клиента. Она заключается в том, что сервер шлет запрос клиенту, клиент аутентифицирует себя, возвращая подписанное со- общение (запрос сервера) и свой цифровой сертификат.
В процессе защищенного взаимодействия с установленными криптографическими параметрами SSL-сессии выполняются следу- ющие действия:
- каждая сторона при передаче сообщения формирует ими- товставку (MAC) для последующей проверки целостности сообщения и затем зашифровывает исходное сообщение вместе с MAC по сеан- совому секретному ключу;
- каждая сторона при приеме сообщения расшифровывает его и проверяет на целостность (вычисляется текущее значение МАС и сверяется со значением, полученным вместе с сообщением); в случае обнаружения нарушения целостности сообщения, SSL-сессия закры- вается.
Протоколы SSL и TLS получили широкое распространение, прежде всего благодаря их использованию для защиты трафика, пере- даваемого по протоколу HTTP в сети Интернет. В то же время предо- ставляемые SSL услуги не являются прозрачными для приложений, т. е. сетевые приложения, которые хотят воспользоваться возможно- стями SSL, должны включать в себя реализацию протокола (или под- ключать ее в виде каких-то внешних модулей).
3.3. ПРОТОКОЛЫ IPSEC И РАСПРЕДЕЛЕНИЕ КЛЮЧЕЙ
Протокол IPSec или, если точнее, набор протоколов, разработан организацией IETF как базовый протокол обеспечения безопасности на уровне IP-соединения. Он является дополнением к использующе- муся сейчас протоколу IP ver.4 и составной частью IP ver.6. Возмож- ности, предоставляемые протоколами IPSec:
- контроль доступа;
- контроль целостности данных;
- аутентификация данных;

101
- защита от повторений;
- обеспечение конфиденциальности.
Основная задача IPSec — создание между двумя компьютерами, связанными через общедоступную (небезопасную) IP-сеть, безопас- ного туннеля (рис. 3.2), по которому передаются конфиденциальные или чувствительные к несанкционированному изменению данные.
Подобный туннель создается с использованием криптографических методов защиты информации. Протокол работает на сетевом уровне модели OSI, и, соответственно, он «прозрачен» для приложений.
Иными словами, на работу приложений (таких как web-сервер, брау- зер, СУБД и т. д.) не влияет, используется ли защита передаваемых данных с помощью IPSec или нет.
Рис. 3.2. Туннель безопасности
Архитектура IPSec является открытой, что позволяет использо- вать для защиты передаваемых данных новые криптографические ал- горитмы, например, соответствующие национальным стандартам. Для этого необходимо, чтобы взаимодействующие стороны поддерживали эти алгоритмы, и они были бы стандартным образом зарегистрирова- ны в описании параметров соединения.
Процесс защищенной передачи данных регулируется правилами безопасности, принятыми в системе. Параметры создаваемого тунне- ля описывает информационная структура, называемая контекст защи- ты или ассоциация безопасности (от англ. «Security Association», сокр.
Хост
A
Хост
B
Защищенные данные

102
SA). Как уже отмечалось выше, IPSec является набором протоколов, и состав контекста защиты может различаться. В зависимости от кон- кретного протокола в него входит:
- IP-адрес получателя;
- указание на протоколы безопасности, используемые при пере- даче данных;
- ключи, необходимые для шифрования и формирования ими- товставки (если это требуется);
- указание на метод форматирования, определяющий, каким об- разом создаются заголовки;
- индекс параметров защиты (от англ. «Security Parameter Index», сокр. SPI) — идентификатор, позволяющий найти нужный SA.
Обычно контекст защиты является однонаправленным, а для пе- редачи данных по туннелю в обе стороны задействуются два SA.
Каждый хост имеет свою базу контекстов защиты, из которой выби- рается нужный элемент либо на основании значения SPI, либо по IP- адресу получателя.
Два протокола, входящие в состав IPSec, это:
1) протокол аутентифицирующего заголовка — AH (от англ.
«Authentication Header»), обеспечивающий проверку целостности и аутентификацию передаваемых данных; последняя версия протокола описана в документе RFC 4302 (предыдущие — RFC 1826, 2402);
2) протокол инкапсулирующей защиты данных — ESP (от англ.
«Encapsulating Security Payload»), обеспечивающий конфиденциаль- ность и, опционально, проверку целостности и аутентификацию; опи- сан в RFC 4303 (предыдущие версии — RFC 1827, 2406).
Оба эти протокола имеют два режима работы — транспортный и туннельный, последний определен в качестве основного. Туннельный режим используется, если хотя бы один из соединяющихся узлов яв- ляется шлюзом безопасности. В этом случае создается новый IP- заголовок, а исходный IP-пакет полностью инкапсулируется в новый.

103
Транспортный режим ориентирован на соединение хост-хост.
При использовании ESP в транспортном режиме защищаются только данные IP-пакета, заголовок не затрагивается. При использовании AH защита распространяется на данные и часть полей заголовка. Более подробно режимы работы описаны ниже.
3.3.1. Протокол AH
В IP ver.4 аутентифицирующий заголовок располагается после
IP-заголовка. Представим исходный IP-пакет как совокупность IP- заголовка, заголовка протокола следующего уровня (как правило, это
TCP или UDP, на рис. 3.3 он обозначен как ULP — от англ. «Upper-
Level Protocol») и данных.
Рис. 3.3. а) исходный IP-пакет, б) IP-пакет при использовании
AH в транспортном режиме, в) IP-пакет при использовании
AH в туннельном режиме
На рис. 3.3 представлен исходный пакет и варианты его измене- ния при использовании протокола AH в разных режимах. В транс- портном режиме заголовок исходного IP-пакета остается на своем ме- сте, но в нем модифицируются некоторые поля. Например, меняется поле Next Header, указывающее на то, заголовок какого протокола следует за IP-заголовком. В туннельном режиме создается новый IP- заголовок, после которого идет заголовок AH, а за ним — полностью исходный IP-пакет.
Аутентификация производится путем создания имитовставки
(MAC) для чего используется хэш-функция и секретный ключ. Во всех реализациях AH обязательно должно поддерживаться использо-
а)
б)
в)
IP header
IP header
New IP header
ULP
Data
ULP
AH
AH
IP header
ULP
Data
Data

104 вание алгоритмов HMAC-MD5-96 (используется по умолчанию) и
HMAC-SHA-1-96, представляющих собой хэш-функции с ключом, основанные на хэш-функциях MD5 и SHA-1, соответственно. Но мо- гут использоваться и другие, «факультативные» алгоритмы хэширо- вания. Полученное значение, называемое в описании протокола ICV
(от англ. «Integrity Check Value» — значение контроля целостности), помещается в поле Authentication Data (рис. 3.4). Это поле перемен- ной длины, так как разные алгоритмы хеширования формируют раз- ные по длине дайджесты.
Рис. 3.4. Структура заголовка протокола AH
При использовании AH в транспортном режиме ICV рассчиты- вается для ULP, данных и неизменяемых полей IP-заголовка. Изменя- емые поля, такие как поле TTL, указывающее на время жизни пакета и изменяемое при прохождении маршрутизаторов, при расчете значе- ния хэш-функции принимаются равными 0. В туннельном режиме аутентифицируется весь исходный IP-пакет и неизменяемые поля но- вого заголовка. Рассмотрим формат заголовка AH (рис. 3.4).
Первые 8 бит заголовка (поле Next Header) содержат номер, со- ответствующий протоколу следующего уровня. Номер для каждого протокола назначает организация IANA (Internet Assigned Numbers
Authority). Например, номер TCP — 6, ESP — 50, AH — 51 и т. д.
Поле Payload Len указывает длину заголовка AH в 32-битных словах. Далее 16 бит зарезервировано.
Поле SPI содержит значение индекса параметров защиты, по ко- торому получатель сможет найти нужный контекст защиты (SA).
Next Header
Payload Len
Зарезервировано
Security Parameters Index (SPI)
0 8
16 31
Sequence Number (SN)
Authentication Data (переменная длина)

105
Поле Sequence Number было введено в RFC 2402. Значение счет- чика, содержащееся в этом поле, может использоваться для защиты от атак путем повторных посылок перехваченных пакетов. Если функ- ция защиты от повторов активирована (а это указывается в SA), от- правитель последовательно наращивает значение поля для каждого пакета, передаваемого в рамках данной ассоциации (соединения, ис- пользующего единый SA).
Поле Authentication Data, как уже указывалось ранее, хранит значение ICV.