Протокол esp что это такое
Загадочный IPsec
IPsec — сложный стек протоколов. На клиентской стороне он обычно автоматизирован, что в сочетании с его названием легко может вызвать у пользователя ощущение полной безопасности. Однако не всегда оправданное. Только IPsec из протоколов, пригодных для организации VPN, поддерживают все сетевые ОС, поэтому у тебя есть неплохой шанс с ним столкнуться. И чтобы быстро настраивать соединения и правильно оценивать их безопасность, нужно понимать, как работает протокол.
Из чего состоит IPsec?
IPsec — это не один протокол, а три или четыре, смотря как считать. В OpenVPN и других решениях на основе TLS все просто: устанавливается соединение по TCP или UDP, согласовываются параметры, а затем передаются данные.
В IPsec за согласование параметров и собственно передачу данных отве‐ чают разные протоколы. В Linux, BSD и многих специализированных ОС маршрутизаторов туннель можно настроить вручную, без помощи управляющего протокола.
AH и ESP
Три основных компонента безопасности — доступность, аутентичность и конфиденциальность. IPsec может обеспечивать аутентичность, при этом ничего не делая для конфиденциальности.
Протокол AH (Authentication Header) добавляет в пакет специальный заголовок с контрольной суммой. На практике он используется редко, поскольку никак не способствует конфиденциальности.
Тем не менее его можно встретить в приложениях, где важна только аутентичность. К примеру, протокол маршрутизации OSPFv2 использовал пароли и суммы MD5 для защиты от поддельных анонсов, а его наследник OSPFv3 не включает никакой функциональности для защиты — вместо этого предлагается использовать IPsec в транспортном (прозрачном) режиме и с одной подписью AH без шифрования.
ESP (Encapsulated Security Payload) шифрует содержимое пакета и добавляет хеши. Его можно использовать в двух режимах — транспортном и туннельном. Это сейчас в сетях IPv4 любой VPN немыслим без маршрутизации частных (серых) адресов через туннель, поскольку со внешним миром хосты общаются через NAT. Но IPsec старше NAT и изначально шифровал только полезную нагрузку пакетов, не трогая заголовки, — это и есть транспортный режим.
В туннельном режиме ESP шифрует весь пакет и передает его как полезную нагрузку, на другой стороне он извлекается, расшифровывается и маршрутизируется дальше.
Что интересно, оба они не работают поверх TCP или UDP, а используют отдельные номера протоколов IP. Во всяком случае, по умолчанию — ESP может быть инкапсулирован в UDP для работы через NAT, но об этом позже.
Фреймворк для управляющих протоколов — ISAKMP
Общие принципы согласования настроек безопасности описывает ISAKMP (Internet Security Association and Key Management Protocol). Он описан в RFC 2408.
ISAKMP не является законченным сетевым протоколом. Это фреймворк, который описывает требования к безопасной работе протоколов обмена настройками безопасных соединений, терминологию и общий формат пакетов, но ничего не говорит о конкретных протоколах обмена ключами, шифрования и прочего — это остается на совести реализаций.
Именно из ISAKMP происходят термины Phase 1 и Phase 2, которые часто можно встретить в интерфейсе настройки маршрутизаторов и в описаниях настроек для подключения. Phase 1 — согласование параметров безопасного обмена данными о настройках. Phase 2 — согласование параметров собственно защиты передаваемого трафика хостов или приложений.
Самая популярная и практически единственная реализация ISAKMP — IKE.
Управляющий протокол — IKE
IKE (Internet Key Exchange) — реальный управляющий протокол IPsec на основе ISAKMP. На практике можно сказать, что Phase 1 — согласование настроек IKE, а Phase 2 — согласование настроек ESP.
В UNIX‐подобных системах IKE — это единственная часть стека IPsec, которая работает в виде обычного процесса. Само шифрование реализовано в ядре, и демон IKE передает ему параметры после согласования со второй стороной. В Linux это происходит через netlink или команды ip xfrm.
Подсистема XFRM в Linux обычно ассоциируется с IPsec, но может выполнять и другие преобразования, например сжатие полезной нагрузки.
Популярные пакеты «для IPsec» вроде StrongSWAN и LibreSWAN реализуют именно IKE.
Согласование настроек шифрования
В IKE есть возможность предложить второй стороне несколько вариантов на выбор, и соединение будет установлено, если у обеих сторон найдется хотя бы один совпадающий вариант. Это общий принцип работы протоколов обмена ключами, TLS работает так же, но в TLS периодически удаляют поддержку устаревших алгоритмов. В IKE безопасность выбора алгоритмов остается на совести пользователя. Заведомо уязвимые DES и MD5 из протокола официально не исключены и до сих пор поддерживаются многими реализациями.
С каждым туннелем ассоциировано одно или несколько «предложений» (proposals). Предложения обрабатываются до первого совпадения. Отсюда следствие: вполне возможна ситуация, когда зловредный (или безответственно настроенный) сервер предложит клиенту устаревшие алгоритмы, а неаккуратно настроенный клиент согласится. У некоторых клиентов вообще может не быть возможности выбрать алгоритмы вручную, а особо ленивые админы любят делать для всех клиентов один большой proposal со всеми мыслимыми алгоритмами. Сортировать алгоритмы по надежности стандарт не обязывает, и стороны вполне могут договориться на шифр полувековой давности.
Более того, официально поддерживается null cipher — опция не шифровать трафик вообще.
Чтобы убедиться в безопасности настроек, в идеале нужно немного понимать принципы криптографии и следить за новостями. Тем не менее можно привести ряд рецептов.
В IKE вполне можно использовать разные наборы алгоритмов для Phase 1 и Phase 2. Смысла в этом немного, но возможность имеется.
Diffie-Hellman и PFS
Параметр PFS ранее я оставил без внимания, так как эта штука была мне не совсем понятна, когда рассказывал про объединение сетей с помощью L2TP/IPsec на Mikrotik и Keenetic Ultra II. Восполним недостающие знания.
PFS (Perfect Forward Secrecy) — рекомендуемая опция, которую многие оставляют выключенной, а зря, особенно если используется pre‐shared key.
В этом режиме из ключей обеих сторон генерируется периодически обновляемый сессионный ключ и согласуется с помощью алгоритма Диффи-Хеллмана (DH). В предельно упрощенной формулировке он основан на том, что возвести число в степень просто, а вычислить логарифм гораздо сложнее. При использовании PFS, если кто‐то получит доступ к общему ключу, он не сможет расшифровать им перехваченный трафик, в этом и суть forward secrecy. Подобранный ключ от одной сессии также не поможет рас‐ шифровать последующие, при условии, что числа достаточно большие, именно поэтому DH1024 и DH1536 стали небезопасны — современное железо уже достаточно быстрое для их взлома.
Параметр Phase2 lifetime (ESP lifetime) указывает, как часто должен меняться ключ. Время жизни ключа — чисто локальный параметр, который не согласуется через IKE и может оказаться разным на разных сторонах. Если твои туннели IPsec сначала передают трафик, а потом вдруг перестают работать, проверь, совпадает ли время жизни ключа на обеих сторонах.
Security Associations (SA)
В отличие от OpenVPN или wireguard, IPsec сам по себе не создает никаких виртуальных интерфейсов. Во времена его зарождения у каждого хоста в интернете был публичный адрес и никакой потребности в виртуальных сетях с отдельной адресацией просто не было. Виртуальными интерфейсами занимаются отдельные протоколы, например L2TP или GRE, а IPsec только шифрует их трафик. Многие платформы поддерживают VTI — ассоциированный с соединением IPsec виртуальный интерфейс, но на деле это всего лишь автоматизированная настройка IPIP поверх IPsec.
Вместо туннелей IPsec оперирует еще более абстрактными сущностями — security associations. Они не являются сетевыми соединениями, это просто наборы параметров, которые указывают, какой трафик и как шифровать. К примеру, «трафик из 192.168.1.0/24 в 10.1.0.0/24 зашифровать AES‐128 и добавить сумму SHA1».
Security associations существуют на обеих сторонах независимо и не могут оборваться сами по себе, в отличие от сетевых соединений. Если ты видишь на своей стороне живую SA, это еще не значит, что трафик нормально пойдет на вторую сторону туннеля. Не забывай проверять, что все на самом деле работает. Чтобы вторая сторона могла узнать, что у тебя происходит, нужно настроить dead peer detection (для IKEv1) или использовать IKEv2, где есть liveness check.
В случае с dead peer detection не забывай проверять, что параметры на обеих сторонах совпадают, иначе можно надолго остаться с туннелем, который только выглядит как живой.
NAT TRAVERSAL
IPsec появился до NAT и в своем чистом виде работать за NAT не может. Эту возможность к нему прикрутили позже. Сам ESP — отдельный протокол IP с номером 50. Для работы за NAT его инкапсулируют в UDP. В этом случае IKE и инкапсулированный ESP используют один порт — UDP/4500.
Изначально от NAT страдали пользователи клиентских соединений вроде L2TP и IPsec. Популярность облачных платформ, где вместо присвоения хостам публичных адресов эти адреса раздают через 1:1, NAT сделала эту проблему актуальной и для соединений между маршрутизаторами.
При этом может возникнуть неожиданная проблема: если на другой стороне туннель настроен на фиксированный адрес, даже если NAT traversal поддерживается, соединение не заработает.
Дело в том, что в пакетах IKE присутствует идентификатор хоста. По умолчанию большинство реализаций используют в качестве идентификатора адрес интерфейса, с которого отправляются пакеты, и в случае с NAT он перестает совпадать с адресом источника, когда пакеты доходят до второй стороны.
Решение простое: никто не обязывает использовать идентификатор по умолчанию. В него можно прописать вообще любую строку, иногда даже необходимо, к примеру если у второй стороны нет фиксированного адреса или используется x.509.
Например, в StrongSWAN:
IKEv1 vs IKEv2
У IKE есть две версии — IKEv1 и IKEv2. IKEv2 получила сколько‐нибудь широкое распространение только в последние несколько лет, и то не везде, но у нее есть ряд ощутимых преимуществ.
В IKEv1 на каждую пару локальных и удаленных адресов нужна была отдельная SA. К примеру, если хостам 192.168.1.1 и 192.168.1.2 нужен доступ через туннель к 10.1.0.1 и 10.1.0.2, демон IKE создаст четыре отдельные SA. IKEv2 в этом смысле более гибкая.
В IKEv2 также окончательно удален aggressive mode, в котором параметры Phase 1 и Phase 2 передавались одновременно. Значительная часть реализаций, впрочем, давно перестала его поддерживать и в IKEv1 из‐за очевидных проблем с безопасностью такого подхода.
Если обе стороны поддерживают IKEv2, лучше использовать именно ее. Если интересно почитать стандарт, она описана в RFC 5996.
Заключение
Надеюсь, если IPsec был для тебя загадочным, теперь принципы его работы стали понятнее. Не забывай, что безопасность параметров шифрования на твоей совести и что не все конфликты настроек обнаружатся автоматически.
Если тебе будет интересно, в следующий раз я напишу о типичных ошибках в настройке и способах определить, что пошло не так, даже если конфиг второй стороны недоступен, а админы некомпетентны.
/ статья из журнала ХАКЕР (06) 2019 /
Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.
IPSec — протокол защиты сетевого трафика на IP-уровне
Введение
Необходимость защиты данных
В конце шестидесятых годов американское агентство перспективных исследований в обороне DARPA приняло решение о создании экспериментальной сети под названием ARPANet. В семидесятых годах ARPANet стала считаться действующей сетью США, и через эту сеть можно было получить доступ к ведущим университетским и научным центрам США. В начале восьмидесятых годов началась стандартизация языков программирования, а затем и протоколов взаимодействия сетей. Результатом этой работы стала разработка семиуровневой модели сетевого взаимодействия ISO/OSI и семейства протоколов TCP/IP, которое стало основой для построения как локальных, так и глобальных сетей.
Базовые механизмы информационного обмена в сетях TCP/IP были в целом сформированы в начале восьмидесятых годов, и были направлены прежде всего на обеспечение доставки пакетов данных между различными операционными системами с использованием разнородных каналов связи. Несмотря на то, что идея создания сети ARPANet (впоследствии превратившейся в современный Интернет) принадлежала правительственной оборонной организации, фактически сеть зародилась в исследовательском мире, и наследовала традиции открытости академического сообщества. Ещё до коммерциализации Интернета (которая произошла в середине девяностых годов) многие авторитетные исследователи отмечали проблемы, связанные с безопасностью стека протоколов TCP/IP. Основные концепции протоколов TCP/IP не полностью удовлетворяют (а в ряде случаев и противоречат) современным представлениям о компьютерной безопасности.
До недавнего времени сеть Интернет использовалась в основном для обработки информации по относительно простым протоколам: электронная почта, передача файлов, удалённый доступ. Сегодня, благодаря широкому распространению технологий WWW, всё активнее применяются средства распределённой обработки мультимедийной информации. Одновременно с этим растёт объём данных, обрабатываемых в средах клиент/сервер и предназначенных для одновременного коллективного доступа большого числа абонентов. Разработано несколько протоколов прикладного уровня, обеспечивающих информационную безопасность таких приложений, как электронная почта (PEM, PGP и т.п.), WWW (Secure HTTP, SSL и т.п.), сетевое управление (SNMPv2 и т.п.). Однако наличие средств обеспечения безопасности в базовых протоколах семейства TCP/IP позволит осуществлять информационный обмен между широким спектром различных приложений и сервисных служб.
Краткая историческая справка появления протокола
В 1994 году Совет по архитектуре Интернет (IAB) выпустил отчет «Безопасность архитектуры Интернет». В этом документе описывались основные области применения дополнительных средств безопасности в сети Интернет, а именно защита от несанкционированного мониторинга, подмены пакетов и управления потоками данных. В числе первоочередных и наиболее важных защитных мер указывалась необходимость разработки концепции и основных механизмов обеспечения целостности и конфиденциальности потоков данных. Поскольку изменение базовых протоколов семейства TCP/IP вызвало бы полную перестройку сети Интернет, была поставлена задача обеспечения безопасности информационного обмена в открытых телекоммуникационных сетях на базе существующих протоколов. Таким образом, начала создаваться спецификация Secure IP, дополнительная по отношению к протоколам IPv4 и IPv6.
Архитектура IPSec
IP Security — это комплект протоколов, касающихся вопросов шифрования, аутентификации и обеспечения защиты при транспортировке IP-пакетов; в его состав сейчас входят почти 20 предложений по стандартам и 18 RFC.
Спецификация IP Security (известная сегодня как IPsec) разрабатывается Рабочей группой IP Security Protocol IETF. Первоначально IPsec включал в себя 3 алгоритмо-независимые базовые спецификации, опубликованные в качестве RFC-документов «Архитектура безопасности IP», «Аутентифицирующий заголовок (AH)», «Инкапсуляция зашифрованных данных (ESP)» (RFC1825, 1826 и 1827). Необходимо заметить, что в ноябре 1998 года Рабочая группа IP Security Protocol предложила новые версии этих спецификаций, имеющие в настоящее время статус предварительных стандартов, это RFC2401 — RFC2412. Отметим, что RFC1825-27 на протяжении уже нескольких лет считаются устаревшими и реально не используются. Кроме этого, существуют несколько алгоритмо-зависимых спецификаций, использующих протоколы MD5, SHA, DES.
Рабочая группа IP Security Protocol разрабатывает также и протоколы управления ключевой информацией. В задачу этой группы входит разработка Internet Key Management Protocol (IKMP), протокола управления ключами прикладного уровня, не зависящего от используемых протоколов обеспечения безопасности. В настоящее время рассматриваются концепции управления ключами с использованием спецификации Internet Security Association and Key Management Protocol (ISAKMP) и протокола Oakley Key Determination Protocol. Спецификация ISAKMP описывает механизмы согласования атрибутов используемых протоколов, в то время как протокол Oakley позволяет устанавливать сессионные ключи на компьютеры сети Интернет. Ранее рассматривались также возможности использования механизмов управления ключами протокола SKIP, однако сейчас такие возможности реально практически нигде не используются. Создаваемые стандарты управления ключевой информацией, возможно, будут поддерживать Центры распределения ключей, аналогичные используемым в системе Kerberos. Протоколами ключевого управления для IPSec на основе Kerberos сейчас занимается относительно новая рабочая группа KINK (Kerberized Internet Negotiation of Keys).
Гарантии целостности и конфиденциальности данных в спецификации IPsec обеспечиваются за счет использования механизмов аутентификации и шифрования соответственно. Последние, в свою очередь, основаны на предварительном согласовании сторонами информационного обмена т.н. «контекста безопасности» – применяемых криптографических алгоритмов, алгоритмов управления ключевой информацией и их параметров. Спецификация IPsec предусматривает возможность поддержки сторонами информационного обмена различных протоколов и параметров аутентификации и шифрования пакетов данных, а также различных схем распределения ключей. При этом результатом согласования контекста безопасности является установление индекса параметров безопасности (SPI), представляющего собой указатель на определенный элемент внутренней структуры стороны информационного обмена, описывающей возможные наборы параметров безопасности.
По сути, IPSec, который станет составной частью IPv6, работает на третьем уровне, т. е. на сетевом уровне. В результате передаваемые IP-пакеты будут защищены прозрачным для сетевых приложений и инфраструктуры образом. В отличие от SSL (Secure Socket Layer), который работает на четвертом (т. е. транспортном) уровне и теснее связан с более высокими уровнями модели OSI, IPSec призван обеспечить низкоуровневую защиту.
К IP-данным, готовым к передаче по виртуальной частной сети, IPSec добавляет заголовок для идентификации защищенных пакетов. Перед передачей по Internet эти пакеты инкапсулируются в другие IP-пакеты. IPSec поддерживает несколько типов шифрования, в том числе Data Encryption Standard (DES) и Message Digest 5 (MD5).
Чтобы установить защищенное соединение, оба участника сеанса должны иметь возможность быстро согласовать параметры защиты, такие как алгоритмы аутентификации и ключи. IPSec поддерживает два типа схем управления ключами, с помощью которых участники могут согласовать параметры сеанса. Эта двойная поддержка в свое время вызвала определенные трения в IETF Working Group.
С текущей версией IP, IPv4, могут быть использованы или Internet Secure Association Key Management Protocol (ISAKMP), или Simple Key Management for Internet Protocol. С новой версией IP, IPv6, придется использовать ISAKMP, известный сейчас как IKE, хотя не исключается возможность использования SKIP. Однако, следует иметь в виду, что SKIP уже давно не рассматривается как кандидат управления ключами, и был исключён из списка возможных кандидатов ещё в 1997 г.
Заголовок AH
Аутентифицирующий заголовок (AH) является обычным опциональным заголовком и, как правило, располагается между основным заголовком пакета IP и полем данных. Наличие AH никак не влияет на процесс передачи информации транспортного и более высокого уровней. Основным и единственным назначением AH является обеспечение защиты от атак, связанных с несанкционированным изменением содержимого пакета, и в том числе от подмены исходного адреса сетевого уровня. Протоколы более высокого уровня должны быть модифицированы в целях осуществления проверки аутентичности полученных данных.
Формат AH достаточно прост и состоит из 96-битового заголовка и данных переменной длины, состоящих из 32-битовых слов. Названия полей достаточно ясно отражают их содержимое: Next Header указывает на следующий заголовок, Payload Len представляет длину пакета, SPI является указателем на контекст безопасности и Sequence Number Field содержит последовательный номер пакета.
Последовательный номер пакета был введен в AH в 1997 году в ходе процесса пересмотра спецификации IPsec. Значение этого поля формируется отправителем и служит для защиты от атак, связанных с повторным использованием данных процесса аутентификации. Поскольку сеть Интернет не гарантирует порядок доставки пакетов, получатель должен хранить информацию о максимальном последовательном номере пакета, прошедшего успешную аутентификацию, и о получении некоторого числа пакетов, содержащих предыдущие последовательные номера (обычно это число равно 64).
В отличие от алгоритмов вычисления контрольной суммы, применяемых в протоколах передачи информации по коммутируемым линиям связи или по каналам локальных сетей и ориентированных на исправление случайных ошибок среды передачи, механизмы обеспечения целостности данных в открытых телекоммуникационных сетях должны иметь средства защиты от внесения целенаправленных изменений. Одним из таких механизмов является специальное применение алгоритма MD5: в процессе формирования AH последовательно вычисляется хэш-функция от объединения самого пакета и некоторого предварительно согласованного ключа, а затем от объединения полученного результата и преобразованного ключа. Данный механизм применяется по умолчанию в целях обеспечения всех реализаций IPv6, по крайней мере, одним общим алгоритмом, не подверженным экспортным ограничениям.
Заголовок ESP
В случае использования инкапсуляции зашифрованных данных заголовок ESP является последним в ряду опциональных заголовков, «видимых» в пакете. Поскольку основной целью ESP является обеспечение конфиденциальности данных, разные виды информации могут требовать применения существенно различных алгоритмов шифрования. Следовательно, формат ESP может претерпевать значительные изменения в зависимости от используемых криптографических алгоритмов. Тем не менее, можно выделить следующие обязательные поля: SPI, указывающее на контекст безопасности и Sequence Number Field, содержащее последовательный номер пакета. Поле «ESP Authentication Data» (контрольная сумма), не является обязательным в заголовке ESP. Получатель пакета ESP расшифровывает ESP заголовок и использует параметры и данные применяемого алгоритма шифрования для декодирования информации транспортного уровня.
Различают два режима применения ESP и AH (а также их комбинации) — транспортный и туннельный.
Транспортный режим
Транспортный режим используется для шифрования поля данных IP пакета, содержащего протоколы транспортного уровня (TCP, UDP, ICMP), которое, в свою очередь, содержит информацию прикладных служб. Примером применения транспортного режима является передача электронной почты. Все промежуточные узлы на маршруте пакета от отправителя к получателю используют только открытую информацию сетевого уровня и, возможно, некоторые опциональные заголовки пакета (в IPv6). Недостатком транспортного режима является отсутствие механизмов скрытия конкретных отправителя и получателя пакета, а также возможность проведения анализа трафика. Результатом такого анализа может стать информация об объемах и направлениях передачи информации, области интересов абонентов, расположение руководителей.
Туннельный режим
Туннельный режим предполагает шифрование всего пакета, включая заголовок сетевого уровня. Туннельный режим применяется в случае необходимости скрытия информационного обмена организации с внешним миром. При этом, адресные поля заголовка сетевого уровня пакета, использующего туннельный режим, заполняются межсетевым экраном организации и не содержат информации о конкретном отправителе пакета. При передаче информации из внешнего мира в локальную сеть организации в качестве адреса назначения используется сетевой адрес межсетевого экрана. После расшифровки межсетевым экраном начального заголовка сетевого уровня пакет направляется получателю.
Security Associations
Security Association (SA) — это соединение, которое предоставляет службы обеспечения безопасности трафика, который передаётся через него. Два компьютера на каждой стороне SA хранят режим, протокол, алгоритмы и ключи, используемые в SA. Каждый SA используется только в одном направлении. Для двунаправленной связи требуется два SA. Каждый SA реализует один режим и протокол; таким образом, если для одного пакета необходимо использовать два протокола (как например AH и ESP), то требуется два SA.
Политика безопасности
Политика безопасности хранится в SPD (База данных политики безопасности). SPD может указать для пакета данных одно из трёх действий: отбросить пакет, не обрабатывать пакет с помощью IPSec, обработать пакет с помощью IPSec. В последнем случае SPD также указывает, какой SA необходимо использовать (если, конечно, подходящий SA уже был создан) или указывает, с какими параметрами должен быть создан новый SA.
SPD является очень гибким механизмом управления, который допускает очень хорошее управление обработкой каждого пакета. Пакеты классифицируются по большому числу полей, и SPD может проверять некоторые или все поля для того, чтобы определить соответствующее действие. Это может привести к тому, что весь трафик между двумя машинами будет передаваться при помощи одного SA, либо отдельные SA будут использоваться для каждого приложения, или даже для каждого TCP соединения.
ISAKMP/Oakley
Протокол ISAKMP определяет общую структуру протоколов, которые используются для установления SA и для выполнения других функций управления ключами. ISAKMP поддерживает несколько Областей Интерпретации (DOI), одной из которых является IPSec-DOI. ISAKMP не определяет законченный протокол, а предоставляет «строительные блоки» для различных DOI и протоколов обмена ключами.
Протокол Oakley — это протокол определения ключа, использующий алгоритм замены ключа Диффи-Хеллмана. Протокол Oakley поддерживает идеальную прямую безопасность (Perfect Forward Secrecy — PFS). Наличие PFS означает невозможность расшифровки всего траффика при компрометации любого ключа в системе.
IKE — протокол обмена ключами по умолчанию для ISAKMP, на данный момент являющийся единственным. IKE находится на вершине ISAKMP и выполняет, собственно, установление как ISAKMP SA, так и IPSec SA. IKE поддерживает набор различных примитивных функций для использования в протоколах. Среди них можно выделить хэш-функцию и псевдослучайную функцию (PRF).
Хэш-функция — это функция, устойчивая к коллизиям. Под устойчивостью к коллизиям понимается тот факт, что невозможно найти два разных сообщения m1 и m2, таких, что H(m1)=H(m2), где H — хэш функция.
Что касается псеводслучайных функций, то в настоящее время вместо специальных PRF используется хэш функция в конструкции HMAC (HMAC — механизм аутентификации сообщений с использованием хэш функций). Для определения HMAC нам понадобится криптографическая хэш функция (обозначим её как H) и секретный ключ K. Мы предполагаем, что H является хэш функцией, где данные хэшируются с помощью процедуры сжатия, последовательно применяемой к последовательности блоков данных. Мы обозначим за B длину таких блоков в байтах, а длину блоков, полученных в результате хэширования — как L (L