Криптование в сетях Ethernet

• Номер по порядку. 32-битовый код, используемый для формирования поля порядковый номер в заголовках АН и ESP.
• Переполнение счетчика порядкового номера. Флаг, индицирующий переполнение счетчика порядкового номера. При его установке дальнейшая посылка пакетов для заданной SA должна быть прекращена.
• Окно для подавления попыток атак воспроизведения. Используется для определения того, является ли входящий АН- или ESP-пакет воспроизведением. Задача решается путем контроля того, попадает ли номер пакета в скользящее окно номеров.
• Информация AH. алгоритм аутентификации, ключи, время жизни ключей и другие параметры.
• Информация ESP: алгоритмы шифрования и аутентификации, ключи, параметры инициализации (IV), времена жизни ключей и другие параметры.
• Окно для подавления попыток атак воспроизведения. Используется для определения того, является ли входящий АН- или ESP-пакет воспроизведением. Задача решается путем контроля того, попадает ли номер пакета в скользящее окно номеров.
• Информация AH. алгоритм аутентификации, ключи, время жизни ключей и другие параметры.
• Информация ESP: алгоритмы шифрования и аутентификации, ключи, параметры инициализации (IV), времена жизни ключей и другие параметры.
• Режим работы IPsec. Туннельный, транспортный или любой.
• MTU пути. Максимальный размер пакета, который может быть передан через виртуальный канал без фрагментации.

При создании новой SA в  счетчик номера по порядку заносится  нуль, далее он инкрементируется при  посылке каждого пакета. Когда  содержимое счетчика достигает значения 232-1, текущая SA аннулируется и должна быть согласована новая ассоциация безопасности и новый ключ.

Так как IP работает без  установления соединения и доставка пакетов по порядку не гарантируется, протокол требует, чтобы получатель сформировал скользящее окно с шириной W, например, W=64 пакета. Правый край окна соответствует наибольшему номеру по порядку N для благополучно принятых пакетов. Любой пакет с номером в диапазоне от N-W+1 до N считается принятым корректно. Если полученный пакет оказался по левую границу окна, или его аутентификация потерпела неудачу, то такой пакет отбрасывается. Ниже приведен пример из [1], где длина W=7 (реально это число может достигать 232). Первые две строки показывают состояние окна с началом в позиции 1 и концом в позиции 7, пакет с номером 9 получен, но его подлинность не подтверждена. Буквами П обозначены полученные пакеты с подтвержденной подлинностью, буквами Н – неполученные пакеты; а буквой О, полученный пакет, подлинность которого не подтверждена. Серым цветом отмечено окно W.

 

П	Н	П	П	П	H	П	П	Н	O	H	H	H
0	1	2	3	4	5	6	7	8	9	10	11	.....
П	Н	П	П	П	H	П	П	Н	П	H	H	H
0	1	2	3	4	5	6	7	8	9	10	11	.....

 

Когда подлинность полученного  пакета с номером 9 оказалась подтвержденной, правая граница окна смещается на эту позицию и занимает положение, показанное на вторых строках данного примера. В этом состоянии, если придет пакет с номером 1 или 2, они будут отвергнуты. Если же придут пакеты с номерами 5 или 8 они будут подвергнуты обработке, так как находятся в пределах окна W.

Ассоциации безопасности сопрягаются с однонаправленными  соединениями, так что для двунаправленной  связи требуется как минимум  две такие ассоциации. Кроме того, каждый протокол (ESP/AH) имеет свою собственную SA, для каждого из направлений обмена, таким образом, полномасштабная VPN AH+ESP требует наличия четырех ассоциаций безопасности. Все эти данные хранятся в базе данных SADB.

В базе данных SADB содержится:

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

Некоторые реализации поддерживают SPD (Security Policy Database) со средствами работы из командной строки, другие с GUI, в то время как прочие предоставляют WEB-интерфейс для работы через сеть. Каждая запись в SPD определяется набором значений полей IP и протокола верхнего уровня, называемых селекторами. Эти селекторы используются для фильтрации исходящего трафика, для того чтобы поставить его в соответствие с определенной SA. Обработка исходящих IP-пакетов производится в следующей последовательности.

• сравниваются значения соответствующих полей в пакете (селекторные поля) с SPD и находится нуль или более SA.
• Определяется SA (если таковая имеется) для пакета и сопряженный с ней SPI.
• Выполняются необходимые операции IPsec (AH или ESP).

SPD запись определяется  следующими селекторами:

• IP-адрес места назначения. Это может быть один IP-адрес (обязательно уникастный!), нумерованный список адресов или адресная маска (префикс). Последние два варианта нужны для работы группами адресов, имеющими идентичную SA (например, за firewall).
• IP-адрес отправителя. Это может быть один IP-адрес, нумерованный список адресов или адресная маска (префикс). Последние два варианта нужны для поддержки нескольких отправителей, имеющих идентичную SA, (например, за firewall).
• UserID. Идентификатор пользователя служит для идентификации политики, соответствующей имени пользователя или системы.
• Уровень чувствительности данных. Уровень чувствительности данных используется для определения характера данных (например, “Секретно” или “Unclassified”).
• Протокол транспортного уровня. Это значение извлекается из поля следующий заголовок пакета IPv4 или IPv6. Это может быть индивидуальный код протокола, список кодов протокола или диапазон таких кодов.
• Протокол IPsec (AH, ESP или AH/ESP). Извлекается (если присутствует) из поля следующий заголовок пакета IPv4 или IPv6.
• Порты отправителя и получателя. Это могут быть индивидуальные номера портов ТСР или UDP, список портов или произвольный порт.
• Класс IPv6. Значение класса получается из заголовка IPv6. Это может быть специфическое значение и код произвольного класса.
• Метка потока IPv6. Значение метки потока получается из заголовка IPv6. Это может быть специфическое значение метки потока или код произвольной метки.
• Тип сервиса IPv4. Значение ToS получается из заголовка IPv4. Это может быть специфическое значение ToS или указатель произвольного значения.

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

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

Наиболее простым способом задания этих секретных ключей является ручная конфигурация: один партер генерирует набор ключей и передает ключи другим партерам.

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

Система IKE (Internet Key Exchange) позволяет двум партнерам динамически аутентифицировать друг друга, согласовать использование ассоциации безопасности (Security Association), включая секретные ключи, и генерировать сами ключи. Система IKE использует ISAKMP (Internet Security Association Key Management Protocol – протокол управления ключами ассоциации безопасности Интернет, разработан Национальным агентством безопасности США - NSA). Протокол ISAKMP сам по себе не регламентирует какой-либо конкретный алгоритм обмена ключами, он содержит в себе описание ряда сообщений, которые позволяют согласовать использование алгоритмов обмена ключами. Согласование осуществляется в два этапа:

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

Механизм обмена ключами  в IKE берется из протокола Oakley (RFC-2412). Основой протокола обмен ключами Oakley является алгоритм Диффи-Хелмана (см. http://book.itep.ru/6/difi_646.htm), дополненный некоторыми усовершенствованиями. В частности в каноническом алгоритме Диффи-Хелмана отсутствует аутентификация партнеров, что допускает возможность атаки с подменом ключей. В IPsec версии алгоритма, аутентификация партнеров является обязательной процедурой.

Заметим, что IPsec осуществляет пересылку ключей через порт 500/udp. В IPsec при обмене ключами предусмотрено  использование сертификатов. Для получения сертификата посылается запрос в сертификационный центр СА (Certificate Authority). Сертификация включает в себя следующие операции:

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

Клиенты могут пользоваться одним и тем же СА или быть клиентами  разных СА. На практике обычно реализуется  иерархическая структура СА.

В Интернет имеется огромное количество материалов по проблематике IPsec, но начинать всегда лучше с документов RFC (Requests for Comment), которые со временем обретают статус стандартов.

В декабре 2005, весь набор  документов RFC по IPsec был обновлен IETF, а серия RFC 43xx по большей части  заменила серию RFC 24xx.

 

 

 

 

 

 

 

Ссылки

 

 

RFC 4301 Security Architecture for the Internet Protocol, S. Kent, K. Seo, December 2005. (обзор протокола IPsec в целом).

RFC 4302 IP Authentication Header, S. Kent. December 2005

RFC 4303 IP Encapsulating Security Payload (ESP). S. Kent. December 2005

RFC 4304 Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP). S. Kent. December 2005

RFC 2104 HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997

RFC 2405 The Use of HMAC-SHA-1-96 within ESP and AH. C. Madson, R. Glenn. November 1998

RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP. D. Piper. November 1998

RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP). D. Maughan, M. Schertler, M. Schneider, J. Turner. November 1998

RFC 4306 Internet Key Exchange (IKEv2) Protocol. C. Kaufman, Ed.. December 2005

RFC 2410 The NULL Encryption Algorithm and Its Use With IPsec. R. Glenn, S. Kent. November 1998

RFC 2411 IP Security Document Roadmap. R. Thayer, N. Doraswamy, R. Glenn. November 1998

RFC 2412 The OAKLEY Key Determination Protocol. H. Orman. November 1998

RFC 3884 Use of IPsec Transport Mode for Dynamic Routing. J. Touch, L. Eggert, Y. Wang. September 2004

1 У.Блэк, Интернет. Протоколы безопасности, “Питер”, Санкт-Петербург, 2001

2 Терри Оглтри, Firewalls. Практическое применение межсетевых экранов, Москва, ДМК, 2001

3 http://www.yars.free.net/CiscoCD/cc/td/doc/product/ software/ios113ed/113t/ 113t_3/ipsec.htm#xtocid25940

4 http://www.schneier.com/paper-ipsec.pdf, by Bruce Schneier and Niels Ferguson

5 C.Г.Баричев, В.В.Гончаров, Р.Е.Серов, Основы современной криптографии, Горячая линия-Телеком, 2002