Аутентификационный заголовок

Протокол AH является опциональным заголовком и расположен между основным заголовком пакета IP и полем данных. AH отвечает за обеспечение целостности и аутентификации данных

Формат заголовка AH состоит из 96-битового заголовка и данных переменной длины, состоящих из 32-битовых слов. Названия полей:

• Next Header указывает на следующий заголовок;

• Payload Len представляет длину пакета;

• SPI является указателем на контекст безопасности;

• Sequence Number Field содержит последовательный номер пакета.

Рис. 7 Формат заголовка АН

Последовательный номер пакета введен в AH в 1997 году в ходе процесса пересмотра спецификации IPsec. Значение этого поля формируется отправителем и служит для защиты от атак, связанных с повторным использованием данных процесса аутентификации. Так как сеть Интернет не гарантирует порядок доставки пакетов, получатель должен хранить информацию о максимальном последовательном номере пакета, прошедшего успешную аутентификацию, и о получении некоторого числа пакетов, содержащих предыдущие последовательные номера (чаще всего это число равно 64).

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

Безопасное сокрытие данных

Протокол ESP способен шифровать данные, а также способен выполнять функции протокола AH.

Рис. 8 Формат заголовка ESP

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

• SPI, указывающее на контекст безопасности;

• Sequence Number Field, содержащее последовательный номер пакета;

• ESP Authentication Data (контрольная сумма), не является обязательным в заголовке ESP.

Получатель пакета ESP расшифровывает ESP заголовок и использует параметры и данные применяемого алгоритма шифрования для декодирования информации транспортного уровня.

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

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

IKE — протокол обмена ключами по умолчанию для ISAKMP, на данный момент являющийся единственным.

Протокол ISAKMP (Internet Security Association and Key Management Protocol), описанный в документе RFC 2408, необходим для согласования алгоритмов и математических структур для процедуры обмена ключами Диффи - Хелмана, а также процессов аутентификации.

Протокол Oakley, описанный в RFC 2412, предназначен определения ключа, использующий алгоритм замены ключа Диффи-Хеллмана. Протокол Oakley поддерживает идеальную прямую безопасность (Perfect Forward Secrecy — PFS). Наличие PFS означает невозможность расшифровки всего траффика при компрометации любого ключа в системе.

IKE находится на вершине ISAKMP и выполняет установление как ISAKMP SA, так и IPSec SA. IKE поддерживает набор различных примитивных функций для использования в протоколах. Среди них можно выделить хэш-функцию и псевдослучайную функцию (PRF).

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

Что касается псеводслучайных функций, то вместо специальных PRF используется хэш функция в конструкции HMAC (HMAC — механизм аутентификации сообщений с использованием хэш функций). Для определения HMAC необходима криптографическая хэш функция (далее - H) и секретный ключ K. Предполагаем, что H является хэш функцией, где данные хэшируются с помощью процедуры сжатия, последовательно применяемой к последовательности блоков данных. Обозначим за B длину таких блоков в байтах, а длину блоков, полученных в результате хэширования — как L (L<B). Ключ K может иметь длину, меньшую или равную B. Если приложение использует ключи большей длины, сначала необходимо хэшировать сам ключ с использованием H, и только после этого использовать полученную строку длиной L байт, как ключ в HMAC. В обоих случаях рекомендуемая минимальная длина для K составляет L байт. Определим две следующие различные строки фиксированной длины:

ipad = байт 0x36, повторённый B раз

opad = байт 0x5C, повторённый B раз

Для вычисления HMAC от данных 'text' необходимо выполнить следующую операцию:

Протоколы IKE решают три задачи:

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

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

• управляют параметрами соединения и защитой от некоторых типов атак, контролируют выполнение всех достигнутых соглашений.

В результате решения третий задачи появилась концепция безопасных ассоциаций SA.