ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 08.11.2023
Просмотров: 299
Скачиваний: 4
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
3.3.2. Протокол ESP
Если AH обеспечивает защиту от угроз целостности передавае- мых данных, то ESP также может обеспечивать и конфиденциаль- ность.
Так же как и AH, ESP может работать в транспортном и тун- нельном режимах. На рис. 3.5 изображены варианты его использова- ния (штриховкой выделены фрагменты пакета, которые защищаются с помощью шифрования). Для ESP определен следующий перечень обязательных алгоритмов, которые должны поддерживаться во всех реализациях:
- для формирования имитовставки — HMAC-MD5-96 (исполь- зуется по умолчанию) и HMAC-SHA-1-96;
- для шифрования — DES (в режиме CBC; используется по умолчанию) и NULL (отсутствие шифрования).
Рис. 3.5. а) исходный IP-пакет, б) ESP в транспортном режиме,
в) ESP в туннельном режиме
а)
IP header new IP header
IP header
ULP
Data
ESP ULP
Data
ESP trailer ESP auth
ESP
IP header
ULP
Data
ESP trailer ESP auth
б)
в)
106
Кроме того, зарегистрированы и могут быть реализованы еще ряд алгоритмов шифрования — Triple DES, CAST-128, RC5, IDEA,
Blowfish, ARCFour (общедоступная версия RC4) [13].
Рассмотрим формат заголовка ESP (рис. 3.6). Он начинается с двух 32-разрядных значений — SPI и SN. Роль их такая же, как в про- токоле AH — SPI идентифицирует контекст защиты, использующий- ся для создания данного туннеля; SN позволяет защититься от повто- ров пакетов. SN и SPI не шифруются. Следующим идет поле, содер- жащее зашифрованные данные. После них — поле заполнителя, кото- рый нужен для того, чтобы выровнять длину шифруемых полей до значения кратного размеру блока алгоритма шифрования.
Рис. 3.6. Структура заголовка ESP
После заполнителя идут поля, содержащие значение длины за- полнителя и указание на протокол более высокого уровня. Четыре пе- речисленных поля (данные, заполнитель, длина, следующий прото- кол) защищаются шифрованием.
Если ESP используется и для аутентификации данных, то за- вершает пакет поле переменной длины, содержащее ICV. В отличие от AH, в ESP при расчете значения имитовставки, поля IP-заголовка
(нового — для туннельного режима, модифицированного старого — для транспортного) не учитываются.
Security Parameters Index (SPI)
0 8
16 31
Sequence Number (SN)
Зашифрованные данные (переменная длина)
Заполнитель (0-255 байт)
Next Header
Authentication Data (переменная длина)
Длина заполн.
107
При совместном использовании протоколов AH и ESP, после IP- заголовка идет AH, после него — ESP. В этом случае ESP решает за- дачи обеспечения конфиденциальности, AH — обеспечения целост- ности и аутентификации источника соединения.
Рассмотрим ряд дополнительных вопросов, связанных с исполь- зованием IPSec. Начнем с того, откуда берется информация о пара- метрах соединения — контекстах защиты или SA. Создание базы SA может производиться различными путями. В частности, она может создаваться администратором безопасности вручную или формиро- ваться с использованием специальных протоколов — SKIP, ISAKMP
(Internet Security Association and Key Management Protocol) и IKE (In- ternet Key Exchange).
3.3.3. Протокол SKIP
Протокол SKIP (Simple Key management for Internet Protocol) был разработан корпорацией SUN Microsystems в 1994 году. Он со- здавался как IP-совместимый протокол, обеспечивающий управление ключами и криптозащиту передаваемых данных на сетевом уровне модели OSI [13]. По нумерации IANA этому протоколу присвоен но- мер 57.
Первоначально SKIP выглядел следующим образом. Устанавли- вающие защищенное взаимодействие абоненты должны иметь аутен- тифицированные открытые ключи. По алгоритму Диффи–Хеллмана они вычисляют общий секретный ключ K
ij
. Он используется для за- щиты ключевой информации.
Отправитель генерирует временный ключ K
p
, используемый для шифрования данных одного пакета или небольшой их группы. На нем зашифровывается исходный IP-пакет и инкапсулируется в SKIP-пакет
(рис. 3.7). Шифрование данных на временном ключе, а не на общем секретном ключе K
ij
, повышает надежность, так как в этом случае нарушителю труднее набрать нужный для реализации атаки на K
ij объем шифрованных данных.
108
Рис. 3.7. Пакет до (а) и после (б) применения протокола SKIP
Ключ K
p зашифровывается на ключе K
ij
, и криптограмма поме- щается в SKIP-заголовок, там же резервируется место под ими- товставку.
Формируется новый IP-заголовок, и с помощью хэш-функции с ключом для всего пакета рассчитывается значение имитовставки, ко- торое помещается в SKIP-заголовок.
Впоследствии протокол SKIP был усовершенствован. В частно- сти, были внесены изменения, позволяющие использовать SKIP сов- местно с ESP. Тогда SKIP отвечает за передачу ключевой информа- ции и описание параметров соединения, а ESP решает задачи крипто- графической защиты данных. Рассмотрим теперь эту версию [14].
Итак, стороны распределили общий секретный ключ K
ij
, и от- правитель сгенерировал временный ключ K
p
. На его основе с помо- щью хэш-функции H будут выработаны ключ для шифрования пакета
E_K
p и ключ для аутентификации A_K
p
. В отличие от первоначально- го варианта, при передаче ключ K
p шифруется не на K
ij
, а на модифи- цированном при помощи счетчика n и хеш-фукнции ключе K
ijn
. Рас- чет производится в соответствии с формулой:
E_Kp=H(K
p
|Crypt Alg|02h)|H(K
p
|Crypt Alg|00h),
A_Kp= H(K
p
|MAC Alg|03h)|H(K
p
|MAC Alg|01h),
(3.1)
K
ijn
= H(K’
ij
|n|01h)|H(K’
ij
|n|00h), где K’
ij
— младшие 256 бит K
ij
, Crypt Alg и MAC Alg — значения со- ответствующих полей заголовка SKIP (рис. 3.8).
Рассмотрим поля заголовка (рис. 3.8). Ver — номер версии про- токола. Следующие за ним 4 бита зарезервированы (Rsvd). Далее — идентификаторы пространств имен источника и получателя
Source
IP-заголовок Данные
Исходный пакет, зашифр. на K
p
К
p зашифр. на K
ij
; имитовст.
SKIP-заголовок
Новый IP- заголовок
а)
б)
109
NSID и Dest NSID
. Если они равны 0, то в полях Source MKID и Dest
MKID ставятся IP-адреса источника и получателя соответственно. По- сле поля Dest NSID идет поле Next Header, содержащее номер прото- кола, следующего за SKIP. Далее идет 32-разрядное поле счетчика
Counter n. Как отмечается в описаниях, правила для работы со счет- чиком n отнесены на усмотрение разработчика, но для обеспечения совместимости версий предлагается считать, что n — время в часах, отсчитанное от 00:00 01.01.95. Как правило, если значение счетчика n пришедшего пакета отличается более чем на 1 от текущего, то пакет отбрасывается.
Рис. 3.8. Формат заголовка SKIP
Далее в заголовке идут байтовые идентификаторы алгоритмов: шифрования ключа K
p
— K
ij
Alg, шифрования данных в пакете—
Crypt Alg, аутентификации данных — MAC Alg, сжатия (если исполь- зуется)— Comp Alg. После идентификаторов в SKIP-заголовок поме- щается ключ K
p
, зашифрованный на ключе K
ijn
(размер этого поля за- висит от используемых алгоритмов шифрования ключа и данных).
Далее идут идентификаторы отправителя и получателя в выбранном пространстве имен — Source MKID и Dest MKID. Наличие нескольких идентификаторов позволяет более гибко настраивать использование протоколов безопасности. Например, если на одном компьютере ра- ботают различные приложения, можно описать политику, указываю-
Source NSID
Dest NSID
Next Header
Ver
Rsvd
Counter n
K
ij
Alg
Crypt Alg
MAC Alg
Comp Alg
K
p
зашифрованный на K
ijn
(перем.длина)
Source MKID (если Source NSID<>0)
Dest MKID (если Dest NSID<>0)
0 8
16 31
110 щую, какие алгоритмы и ключи использовать для защиты данных каждого из них.
В случае совместного использования протоколов SKIP и ESP за- головок SKIP размещается после IP-заголовка перед заголовком ESP
(рис. 3.9).
Рис. 3.9. Совместное использование SKIP и ESP
В этом случае протокол ESP использует параметры соединения, определяемые протоколом SKIP, а указывает на это значение SPI в за- головке ESP: SKIP_SPI=1.
3.3.4. Протоколы ISAKMP и IKE
Протокол ISAKMP (Internet Security Association Key Management
Protocol — протокол управления ключами и контекстами безопасно- сти в Internet) был разработан IETF для решения задач согласования параметров и управления ключами при формировании защищенного канала. ISAKMP описывает общую схему взаимодействия, но не со- держит конкретных криптоалгоритмов распределения ключей. По- этому он используется совместно с протоколом OAKLEY, основан- ном на алгоритме Диффи–Хеллмана [13]. Протокол IKE (англ. «Inter- net Key Exchange» — обмен ключами в Internet) определяет совмест- ное использование протоколов ISAKMP с OAKLEY и SKEMI (англ.
«Secure Key Exchange Mechanism for Internet» — безопасный меха- низм обмена ключами в Интернет) для решения данной задачи. Срав- нивая протоколы SKIP и IKE, надо отметить, что последний более сложен в реализации, но считается более надежным и гибким.
Протокол ISAKMP определяет две фазы согласования парамет- ров взаимодействия:
IP-заголовок SKIP-заголовок
ESP
111
- согласование глобальных параметров защищенного канала (в терминах IPSec такие параметры называются управляющим контек- стом);
- согласование параметров каждого защищенного соединения
(они образуют контекст защиты — SA).
С точки зрения модели стека TCP/IP, протокол ISAKMP являет- ся протоколом прикладного уровня. В случае его использования сов- местно с IPSec спецификация устанавливает использование в качестве протокола нижнего уровня UDP с номером порта 500.
Протокол ISAKMP определяет следующую последовательность действий по формированию управляющего контекста (стороны взаи- модействия, например, это могут быть два шлюза безопасности, называются «Инициатор» и «Партнер»):
1) «Инициатор» «Партнер»: заявка на контекст, включаю- щая предлагаемые алгоритмы и их параметры;
2) «Партнер» «Инициатор»: принимаемые алгоритмы и па- раметры (из списка, полученного на шаге 1; для каждой функции за- щиты — генерация и распределение ключей, шифрование, аутенти- фикация — используется один алгоритм и его параметры);
3) «Инициатор» «Партнер»: ключевой материал и одноразо- вый номер инициатора;
4) «Партнер» «Инициатор»: ключевой материал и одноразо- вый номер партнера;
5) «Инициатор» «Партнер»: подписанное инициатором за- шифрованное сообщение, содержащее его идентификатор;
6) «Партнер» «Инициатор»: подписанное партнером зашиф- рованное сообщение, содержащее его идентификатор.
Если используется протокол OAKLEY, на шаге 3 и 4 стороны отправляют друг другу свои открытые ключи вместе со случайными числами, служащими для защиты от повтора. Для обеспечения кон- троля подлинности открытых ключей могут быть использованы сер- тификаты X.509. В соответствии со схемой Диффи–Хеллмана рассчи-
112 тывается общий секретный ключ. На его основе вырабатываются зна- чения:
SKEYID_d — ключевой материал, используемый для генерации временных ключей для защищенных соединений;
SKEYID_a — сеансовые ключи, используемые для аутентифика- ции сторон и согласовываемых параметров;
SKEYID_e — сеансовые ключи, используемые для шифрования согласовываемых параметров.
Пятый и шестой шаги служат для обмена идентификационной информацией, защищенной и заверенной на ключах SKEYID_e и
SKEYID_a.
Такой порядок взаимодействия реализуется при использовании основного или базового режима (англ. «Main Mode»). Он более мед- ленный, но и более безопасный. Существует также «агрессивный» режим (англ. «Aggressive Mode») при котором для увеличения скоро- сти взаимодействия ряд параметров передается в открытом виде, и уменьшено число шагов взаимодействия (с 6 до 3 за счет того, что на первом и втором шаге сразу передается больше параметров) [11].
Сообщение ISAKMP состоит из заголовка и следующих за ним полей данных. Формат заголовка приведен на рис. 3.10.
Рис. 3.10. Заголовок ISAKMP
Исходя из значения текущего времени, стороны формируют идентификаторы (cookie), которые включают в заголовок пакета (на
Начальная cookie
Ответная cookie
Следующ. данные
Версия
Тип обмена
Флаги
Идентификатор сообщения
Длина
31 16 0
113 шаге 1 присутствует только идентификатор стороны-инициатора со- единения, на последующих — идентификаторы обеих сторон). При- сутствие этих идентификаторов позволяет защититься от атак путем повторных посылок перехваченных сообщений.
Поле «Следующие данные» содержит идентификатор, указыва- ющий на тип содержимого области данных. Например, 1 — контекст защиты (SA), 2 — предложение (используется при согласовании па- раметров); 6 — сертификат, 7 — запрос сертификата и т. д.
Тип обмена указывает на тип информационного обмена (режим, в котором работает протокол). Например, 0 — нет обмена, 1 — базо- вый, 4 — агрессивный и т. д.
Флаги позволяют указать дополнительные настройки. Напри- мер, один из флагов указывает на то, что все данные, идущие за заго- ловком, зашифрованы.
Идентификатор сообщения — уникальный идентификатор со- общения.
Длина — длина сообщения (заголовка и данных).
Итак, описанная фаза протокола позволяет сформировать общий защищенный канал и согласовать его параметры.
После создания общего защищенного канала параметры каждо- го защищенного соединения, создаваемого в рамках этого канала, со- гласуются на основе сформированных глобальных параметров канала и образуют контекст защиты. Каждое защищенное соединение явля- ется однонаправленным, и в нем может использоваться один из двух протоколов — ESP или AH (кроме того, на базе общего защищенного канала могут быть созданы защищенные соединения, использующие отличный от IPSec протокол). Если предполагается организовать за- щищаемое ESP двустороннее взаимодействие, понадобятся два со- единения (и два SA), если использовать и протокол AH, и ESP, то нужны четыре SA.
В состав согласуемых параметров, образующих SA, входят [13]:
- номер протокола криптозащиты (AH, ESP, другой);
114
- номера алгоритмов криптозащиты и их параметры;
- режим протокола (транспортный или туннельный);
- сеансовые ключи (действующие для текущего соединения);
- срок существования защищенного соединения (может зада- ваться временем или объемом переданного трафика; например, срок существования канала — 6 часов, соединения в рамках этого канала
— 1 час);
- максимальный размер пакетов;
- дополнительные параметры (параметры счетчика и т. д.) для защиты от повтора, задержки, удаления пакетов сообщения.
Пользователями защищенных соединений, как правило, являют- ся прикладные процессы. И между двумя узлами сети может суще- ствовать произвольное число соединений, сформированных в рамках одного защищенного канала.
Защищенное соединение, соответствующее спецификациям протокола IPSec, идентифицируется целевым IP-адресом, используе- мым протоколом криптозащиты (ESP или AH) и индексом SPI.
Для выработки параметров «Инициатор» и «Партнер» обмени- ваются следующими сообщениями.
1) «Инициатор» «Партнер» (защищенное сообщение):
- заявка на создание защищенного соединения (предлагаемые алгоритмы и их параметры);
- одноразовый номер инициатора.
2) «Партнер» «Инициатор» (защищенное сообщение):
- принимаемые алгоритмы и параметры;
- одноразовый номер партнера.
3) «Инициатор» «Партнер» (защищенное сообщение):
- одноразовый номер инициатора;
- одноразовый номер партнера.
Для защиты передаваемых сообщений используются ключи, вы- работанные при формировании защищенного канала: SKEYID_a — для аутентификации, SKEYID_e — для шифрования. Для аутентифи-
115 кации используется хэш-функция, в качестве аргументов которой вы- ступают аутентифицируемое сообщение и ключ SKEYID_a.
Временные ключи защищенного соединения генерируются пу- тем применения хэш-функции к значению SKEYID_d с дополнитель- ными параметрами, в число которых входят одноразовые идентифи- каторы инициатора и партнера.
Принимающая сторона соединения задает для формируемого SA номер SPI, по которому он будет идентифицироваться.
3.3.5. Протоколы IPSec и трансляция сетевых адресов
При подключении сетей организаций к Интернет часто исполь- зуется механизм трансляции сетевых адресов — NAT (от англ. «Net- work Address Translation»). Это позволяет уменьшить число зареги- стрированных IP-адресов, используемых в данной сети. Внутри сети используются незарегистрированные «частные» адреса (как правило, из диапазонов, специально выделенных для этой цели, например, ад- реса вида 192.168.x.y для сетей класса C). Если пакет из такой сети передается в Интернет, то маршрутизатор, внешнему интерфейсу ко- торого назначен по крайней мере один зарегистрированный ip-адрес, модифицирует ip-заголовки сетевых пакетов, подставляя вместо част- ных адресов зарегистрированный адрес. Порядок, по которому произ- водится подстановка, описывается в специальной таблице. При полу- чении ответа в соответствии с таблицей делается обратная замена, и пакет переправляется во внутреннюю сеть.
Рассмотрим пример использования NAT (рис. 3.11). В данном случае во внутренней сети используются частные адреса 192.168.0.x.
С компьютера с адресом 192.168.0.2 обращаются во внешнюю сеть к компьютеру с адресом 195.242.2.2. Пусть это будет подключение к web-серверу (протокол HTTP, который использует TCP порт 80).
При прохождении пакета через маршрутизатор, выполняющий трансляцию адресов, ip-адрес отправителя (192.168.0.2) будет заменен на адрес внешнего интерфейса маршрутизатора (195.201.82.146), а в
Если AH обеспечивает защиту от угроз целостности передавае- мых данных, то ESP также может обеспечивать и конфиденциаль- ность.
Так же как и AH, ESP может работать в транспортном и тун- нельном режимах. На рис. 3.5 изображены варианты его использова- ния (штриховкой выделены фрагменты пакета, которые защищаются с помощью шифрования). Для ESP определен следующий перечень обязательных алгоритмов, которые должны поддерживаться во всех реализациях:
- для формирования имитовставки — HMAC-MD5-96 (исполь- зуется по умолчанию) и HMAC-SHA-1-96;
- для шифрования — DES (в режиме CBC; используется по умолчанию) и NULL (отсутствие шифрования).
Рис. 3.5. а) исходный IP-пакет, б) ESP в транспортном режиме,
в) ESP в туннельном режиме
а)
IP header new IP header
IP header
ULP
Data
ESP ULP
Data
ESP trailer ESP auth
ESP
IP header
ULP
Data
ESP trailer ESP auth
б)
в)
106
Кроме того, зарегистрированы и могут быть реализованы еще ряд алгоритмов шифрования — Triple DES, CAST-128, RC5, IDEA,
Blowfish, ARCFour (общедоступная версия RC4) [13].
Рассмотрим формат заголовка ESP (рис. 3.6). Он начинается с двух 32-разрядных значений — SPI и SN. Роль их такая же, как в про- токоле AH — SPI идентифицирует контекст защиты, использующий- ся для создания данного туннеля; SN позволяет защититься от повто- ров пакетов. SN и SPI не шифруются. Следующим идет поле, содер- жащее зашифрованные данные. После них — поле заполнителя, кото- рый нужен для того, чтобы выровнять длину шифруемых полей до значения кратного размеру блока алгоритма шифрования.
Рис. 3.6. Структура заголовка ESP
После заполнителя идут поля, содержащие значение длины за- полнителя и указание на протокол более высокого уровня. Четыре пе- речисленных поля (данные, заполнитель, длина, следующий прото- кол) защищаются шифрованием.
Если ESP используется и для аутентификации данных, то за- вершает пакет поле переменной длины, содержащее ICV. В отличие от AH, в ESP при расчете значения имитовставки, поля IP-заголовка
(нового — для туннельного режима, модифицированного старого — для транспортного) не учитываются.
Security Parameters Index (SPI)
0 8
16 31
Sequence Number (SN)
Зашифрованные данные (переменная длина)
Заполнитель (0-255 байт)
Next Header
Authentication Data (переменная длина)
Длина заполн.
107
При совместном использовании протоколов AH и ESP, после IP- заголовка идет AH, после него — ESP. В этом случае ESP решает за- дачи обеспечения конфиденциальности, AH — обеспечения целост- ности и аутентификации источника соединения.
Рассмотрим ряд дополнительных вопросов, связанных с исполь- зованием IPSec. Начнем с того, откуда берется информация о пара- метрах соединения — контекстах защиты или SA. Создание базы SA может производиться различными путями. В частности, она может создаваться администратором безопасности вручную или формиро- ваться с использованием специальных протоколов — SKIP, ISAKMP
(Internet Security Association and Key Management Protocol) и IKE (In- ternet Key Exchange).
3.3.3. Протокол SKIP
Протокол SKIP (Simple Key management for Internet Protocol) был разработан корпорацией SUN Microsystems в 1994 году. Он со- здавался как IP-совместимый протокол, обеспечивающий управление ключами и криптозащиту передаваемых данных на сетевом уровне модели OSI [13]. По нумерации IANA этому протоколу присвоен но- мер 57.
Первоначально SKIP выглядел следующим образом. Устанавли- вающие защищенное взаимодействие абоненты должны иметь аутен- тифицированные открытые ключи. По алгоритму Диффи–Хеллмана они вычисляют общий секретный ключ K
ij
. Он используется для за- щиты ключевой информации.
Отправитель генерирует временный ключ K
p
, используемый для шифрования данных одного пакета или небольшой их группы. На нем зашифровывается исходный IP-пакет и инкапсулируется в SKIP-пакет
(рис. 3.7). Шифрование данных на временном ключе, а не на общем секретном ключе K
ij
, повышает надежность, так как в этом случае нарушителю труднее набрать нужный для реализации атаки на K
ij объем шифрованных данных.
108
Рис. 3.7. Пакет до (а) и после (б) применения протокола SKIP
Ключ K
p зашифровывается на ключе K
ij
, и криптограмма поме- щается в SKIP-заголовок, там же резервируется место под ими- товставку.
Формируется новый IP-заголовок, и с помощью хэш-функции с ключом для всего пакета рассчитывается значение имитовставки, ко- торое помещается в SKIP-заголовок.
Впоследствии протокол SKIP был усовершенствован. В частно- сти, были внесены изменения, позволяющие использовать SKIP сов- местно с ESP. Тогда SKIP отвечает за передачу ключевой информа- ции и описание параметров соединения, а ESP решает задачи крипто- графической защиты данных. Рассмотрим теперь эту версию [14].
Итак, стороны распределили общий секретный ключ K
ij
, и от- правитель сгенерировал временный ключ K
p
. На его основе с помо- щью хэш-функции H будут выработаны ключ для шифрования пакета
E_K
p и ключ для аутентификации A_K
p
. В отличие от первоначально- го варианта, при передаче ключ K
p шифруется не на K
ij
, а на модифи- цированном при помощи счетчика n и хеш-фукнции ключе K
ijn
. Рас- чет производится в соответствии с формулой:
E_Kp=H(K
p
|Crypt Alg|02h)|H(K
p
|Crypt Alg|00h),
A_Kp= H(K
p
|MAC Alg|03h)|H(K
p
|MAC Alg|01h),
(3.1)
K
ijn
= H(K’
ij
|n|01h)|H(K’
ij
|n|00h), где K’
ij
— младшие 256 бит K
ij
, Crypt Alg и MAC Alg — значения со- ответствующих полей заголовка SKIP (рис. 3.8).
Рассмотрим поля заголовка (рис. 3.8). Ver — номер версии про- токола. Следующие за ним 4 бита зарезервированы (Rsvd). Далее — идентификаторы пространств имен источника и получателя
Source
IP-заголовок Данные
Исходный пакет, зашифр. на K
p
К
p зашифр. на K
ij
; имитовст.
SKIP-заголовок
Новый IP- заголовок
а)
б)
109
NSID и Dest NSID
. Если они равны 0, то в полях Source MKID и Dest
MKID ставятся IP-адреса источника и получателя соответственно. По- сле поля Dest NSID идет поле Next Header, содержащее номер прото- кола, следующего за SKIP. Далее идет 32-разрядное поле счетчика
Counter n. Как отмечается в описаниях, правила для работы со счет- чиком n отнесены на усмотрение разработчика, но для обеспечения совместимости версий предлагается считать, что n — время в часах, отсчитанное от 00:00 01.01.95. Как правило, если значение счетчика n пришедшего пакета отличается более чем на 1 от текущего, то пакет отбрасывается.
Рис. 3.8. Формат заголовка SKIP
Далее в заголовке идут байтовые идентификаторы алгоритмов: шифрования ключа K
p
— K
ij
Alg, шифрования данных в пакете—
Crypt Alg, аутентификации данных — MAC Alg, сжатия (если исполь- зуется)— Comp Alg. После идентификаторов в SKIP-заголовок поме- щается ключ K
p
, зашифрованный на ключе K
ijn
(размер этого поля за- висит от используемых алгоритмов шифрования ключа и данных).
Далее идут идентификаторы отправителя и получателя в выбранном пространстве имен — Source MKID и Dest MKID. Наличие нескольких идентификаторов позволяет более гибко настраивать использование протоколов безопасности. Например, если на одном компьютере ра- ботают различные приложения, можно описать политику, указываю-
Source NSID
Dest NSID
Next Header
Ver
Rsvd
Counter n
K
ij
Alg
Crypt Alg
MAC Alg
Comp Alg
K
p
зашифрованный на K
ijn
(перем.длина)
Source MKID (если Source NSID<>0)
Dest MKID (если Dest NSID<>0)
0 8
16 31
110 щую, какие алгоритмы и ключи использовать для защиты данных каждого из них.
В случае совместного использования протоколов SKIP и ESP за- головок SKIP размещается после IP-заголовка перед заголовком ESP
(рис. 3.9).
Рис. 3.9. Совместное использование SKIP и ESP
В этом случае протокол ESP использует параметры соединения, определяемые протоколом SKIP, а указывает на это значение SPI в за- головке ESP: SKIP_SPI=1.
3.3.4. Протоколы ISAKMP и IKE
Протокол ISAKMP (Internet Security Association Key Management
Protocol — протокол управления ключами и контекстами безопасно- сти в Internet) был разработан IETF для решения задач согласования параметров и управления ключами при формировании защищенного канала. ISAKMP описывает общую схему взаимодействия, но не со- держит конкретных криптоалгоритмов распределения ключей. По- этому он используется совместно с протоколом OAKLEY, основан- ном на алгоритме Диффи–Хеллмана [13]. Протокол IKE (англ. «Inter- net Key Exchange» — обмен ключами в Internet) определяет совмест- ное использование протоколов ISAKMP с OAKLEY и SKEMI (англ.
«Secure Key Exchange Mechanism for Internet» — безопасный меха- низм обмена ключами в Интернет) для решения данной задачи. Срав- нивая протоколы SKIP и IKE, надо отметить, что последний более сложен в реализации, но считается более надежным и гибким.
Протокол ISAKMP определяет две фазы согласования парамет- ров взаимодействия:
IP-заголовок SKIP-заголовок
ESP
111
- согласование глобальных параметров защищенного канала (в терминах IPSec такие параметры называются управляющим контек- стом);
- согласование параметров каждого защищенного соединения
(они образуют контекст защиты — SA).
С точки зрения модели стека TCP/IP, протокол ISAKMP являет- ся протоколом прикладного уровня. В случае его использования сов- местно с IPSec спецификация устанавливает использование в качестве протокола нижнего уровня UDP с номером порта 500.
Протокол ISAKMP определяет следующую последовательность действий по формированию управляющего контекста (стороны взаи- модействия, например, это могут быть два шлюза безопасности, называются «Инициатор» и «Партнер»):
1) «Инициатор» «Партнер»: заявка на контекст, включаю- щая предлагаемые алгоритмы и их параметры;
2) «Партнер» «Инициатор»: принимаемые алгоритмы и па- раметры (из списка, полученного на шаге 1; для каждой функции за- щиты — генерация и распределение ключей, шифрование, аутенти- фикация — используется один алгоритм и его параметры);
3) «Инициатор» «Партнер»: ключевой материал и одноразо- вый номер инициатора;
4) «Партнер» «Инициатор»: ключевой материал и одноразо- вый номер партнера;
5) «Инициатор» «Партнер»: подписанное инициатором за- шифрованное сообщение, содержащее его идентификатор;
6) «Партнер» «Инициатор»: подписанное партнером зашиф- рованное сообщение, содержащее его идентификатор.
Если используется протокол OAKLEY, на шаге 3 и 4 стороны отправляют друг другу свои открытые ключи вместе со случайными числами, служащими для защиты от повтора. Для обеспечения кон- троля подлинности открытых ключей могут быть использованы сер- тификаты X.509. В соответствии со схемой Диффи–Хеллмана рассчи-
112 тывается общий секретный ключ. На его основе вырабатываются зна- чения:
SKEYID_d — ключевой материал, используемый для генерации временных ключей для защищенных соединений;
SKEYID_a — сеансовые ключи, используемые для аутентифика- ции сторон и согласовываемых параметров;
SKEYID_e — сеансовые ключи, используемые для шифрования согласовываемых параметров.
Пятый и шестой шаги служат для обмена идентификационной информацией, защищенной и заверенной на ключах SKEYID_e и
SKEYID_a.
Такой порядок взаимодействия реализуется при использовании основного или базового режима (англ. «Main Mode»). Он более мед- ленный, но и более безопасный. Существует также «агрессивный» режим (англ. «Aggressive Mode») при котором для увеличения скоро- сти взаимодействия ряд параметров передается в открытом виде, и уменьшено число шагов взаимодействия (с 6 до 3 за счет того, что на первом и втором шаге сразу передается больше параметров) [11].
Сообщение ISAKMP состоит из заголовка и следующих за ним полей данных. Формат заголовка приведен на рис. 3.10.
Рис. 3.10. Заголовок ISAKMP
Исходя из значения текущего времени, стороны формируют идентификаторы (cookie), которые включают в заголовок пакета (на
Начальная cookie
Ответная cookie
Следующ. данные
Версия
Тип обмена
Флаги
Идентификатор сообщения
Длина
31 16 0
113 шаге 1 присутствует только идентификатор стороны-инициатора со- единения, на последующих — идентификаторы обеих сторон). При- сутствие этих идентификаторов позволяет защититься от атак путем повторных посылок перехваченных сообщений.
Поле «Следующие данные» содержит идентификатор, указыва- ющий на тип содержимого области данных. Например, 1 — контекст защиты (SA), 2 — предложение (используется при согласовании па- раметров); 6 — сертификат, 7 — запрос сертификата и т. д.
Тип обмена указывает на тип информационного обмена (режим, в котором работает протокол). Например, 0 — нет обмена, 1 — базо- вый, 4 — агрессивный и т. д.
Флаги позволяют указать дополнительные настройки. Напри- мер, один из флагов указывает на то, что все данные, идущие за заго- ловком, зашифрованы.
Идентификатор сообщения — уникальный идентификатор со- общения.
Длина — длина сообщения (заголовка и данных).
Итак, описанная фаза протокола позволяет сформировать общий защищенный канал и согласовать его параметры.
После создания общего защищенного канала параметры каждо- го защищенного соединения, создаваемого в рамках этого канала, со- гласуются на основе сформированных глобальных параметров канала и образуют контекст защиты. Каждое защищенное соединение явля- ется однонаправленным, и в нем может использоваться один из двух протоколов — ESP или AH (кроме того, на базе общего защищенного канала могут быть созданы защищенные соединения, использующие отличный от IPSec протокол). Если предполагается организовать за- щищаемое ESP двустороннее взаимодействие, понадобятся два со- единения (и два SA), если использовать и протокол AH, и ESP, то нужны четыре SA.
В состав согласуемых параметров, образующих SA, входят [13]:
- номер протокола криптозащиты (AH, ESP, другой);
114
- номера алгоритмов криптозащиты и их параметры;
- режим протокола (транспортный или туннельный);
- сеансовые ключи (действующие для текущего соединения);
- срок существования защищенного соединения (может зада- ваться временем или объемом переданного трафика; например, срок существования канала — 6 часов, соединения в рамках этого канала
— 1 час);
- максимальный размер пакетов;
- дополнительные параметры (параметры счетчика и т. д.) для защиты от повтора, задержки, удаления пакетов сообщения.
Пользователями защищенных соединений, как правило, являют- ся прикладные процессы. И между двумя узлами сети может суще- ствовать произвольное число соединений, сформированных в рамках одного защищенного канала.
Защищенное соединение, соответствующее спецификациям протокола IPSec, идентифицируется целевым IP-адресом, используе- мым протоколом криптозащиты (ESP или AH) и индексом SPI.
Для выработки параметров «Инициатор» и «Партнер» обмени- ваются следующими сообщениями.
1) «Инициатор» «Партнер» (защищенное сообщение):
- заявка на создание защищенного соединения (предлагаемые алгоритмы и их параметры);
- одноразовый номер инициатора.
2) «Партнер» «Инициатор» (защищенное сообщение):
- принимаемые алгоритмы и параметры;
- одноразовый номер партнера.
3) «Инициатор» «Партнер» (защищенное сообщение):
- одноразовый номер инициатора;
- одноразовый номер партнера.
Для защиты передаваемых сообщений используются ключи, вы- работанные при формировании защищенного канала: SKEYID_a — для аутентификации, SKEYID_e — для шифрования. Для аутентифи-
115 кации используется хэш-функция, в качестве аргументов которой вы- ступают аутентифицируемое сообщение и ключ SKEYID_a.
Временные ключи защищенного соединения генерируются пу- тем применения хэш-функции к значению SKEYID_d с дополнитель- ными параметрами, в число которых входят одноразовые идентифи- каторы инициатора и партнера.
Принимающая сторона соединения задает для формируемого SA номер SPI, по которому он будет идентифицироваться.
3.3.5. Протоколы IPSec и трансляция сетевых адресов
При подключении сетей организаций к Интернет часто исполь- зуется механизм трансляции сетевых адресов — NAT (от англ. «Net- work Address Translation»). Это позволяет уменьшить число зареги- стрированных IP-адресов, используемых в данной сети. Внутри сети используются незарегистрированные «частные» адреса (как правило, из диапазонов, специально выделенных для этой цели, например, ад- реса вида 192.168.x.y для сетей класса C). Если пакет из такой сети передается в Интернет, то маршрутизатор, внешнему интерфейсу ко- торого назначен по крайней мере один зарегистрированный ip-адрес, модифицирует ip-заголовки сетевых пакетов, подставляя вместо част- ных адресов зарегистрированный адрес. Порядок, по которому произ- водится подстановка, описывается в специальной таблице. При полу- чении ответа в соответствии с таблицей делается обратная замена, и пакет переправляется во внутреннюю сеть.
Рассмотрим пример использования NAT (рис. 3.11). В данном случае во внутренней сети используются частные адреса 192.168.0.x.
С компьютера с адресом 192.168.0.2 обращаются во внешнюю сеть к компьютеру с адресом 195.242.2.2. Пусть это будет подключение к web-серверу (протокол HTTP, который использует TCP порт 80).
При прохождении пакета через маршрутизатор, выполняющий трансляцию адресов, ip-адрес отправителя (192.168.0.2) будет заменен на адрес внешнего интерфейса маршрутизатора (195.201.82.146), а в