В сфере вычислений безопасность интернет-протокола ( IPsec ) — это набор безопасных сетевых протоколов , который аутентифицирует и шифрует пакеты данных для обеспечения безопасной зашифрованной связи между двумя компьютерами по сети интернет-протокола . Он используется в виртуальных частных сетях (VPN).
IPsec включает протоколы для установления взаимной аутентификации между агентами в начале сеанса и согласования криптографических ключей для использования во время сеанса. IPsec может защитить потоки данных между парой хостов ( хост-хост ), между парой шлюзов безопасности ( сеть-сеть ) или между шлюзом безопасности и хостом ( сеть-хост ). [1] IPsec использует службы криптографической безопасности для защиты коммуникаций в сетях Интернет-протокола (IP). Он поддерживает одноранговую аутентификацию на уровне сети, аутентификацию источника данных , целостность данных , конфиденциальность данных ( шифрование ) и защиту воспроизведения (защиту от атак повторного воспроизведения ).
Начиная с начала 1970-х годов, Агентство перспективных исследовательских проектов спонсировало серию экспериментальных устройств шифрования ARPANET , сначала для собственного шифрования пакетов ARPANET , а затем для шифрования пакетов TCP/IP ; некоторые из них были сертифицированы и внедрены. С 1986 по 1991 год АНБ спонсировало разработку протоколов безопасности для Интернета в рамках своей программы Secure Data Network Systems (SDNS). [2] Это объединило различных поставщиков, включая Motorola , которая выпустила устройство сетевого шифрования в 1988 году. Работа была открыто опубликована примерно с 1988 года NIST , и из них протокол безопасности на уровне 3 (SP3) в конечном итоге превратился в стандарт сети ISO. Протокол уровня безопасности (NLSP). [3]
В 1992 году DARPA CSTO финансировала Исследовательскую лабораторию ВМС США (NRL) для внедрения IPv6, а также для исследования и внедрения IP-шифрования в 4.4 BSD , поддерживающего архитектуры процессоров SPARC и x86. DARPA предоставило бесплатный доступ к своей реализации через MIT. В рамках исследовательской работы NRL, финансируемой DARPA , NRL разработала спецификации стандартов IETF (RFC 1825–RFC 1827) для IPsec. [4] Реализация IPsec компании NRL была описана в их статье в материалах конференции USENIX 1996 года . [5] Реализация IPsec с открытым исходным кодом NRL была размещена в Интернете MIT и стала основой для большинства первоначальных коммерческих реализаций. [6]
Инженерная группа Интернета (IETF) сформировала Рабочую группу по IP-безопасности в 1992 году [7] для стандартизации открыто определенных расширений безопасности IP, называемых IPsec . [8] В 1995 году рабочая группа организовала несколько семинаров с участием представителей пяти компаний (TIS, Cisco , FTP, Checkpoint и т. д.). В ходе семинаров по IPsec стандарты NRL, а также программное обеспечение Cisco и TIS стандартизируются как общедоступные ссылки и публикуются как RFC-1825–RFC-1827. [9]
Первоначальный пакет IPv4 был разработан с небольшим количеством мер безопасности. В рамках усовершенствования IPv4 IPsec представляет собой модель OSI уровня 3 или схему сквозной безопасности интернет-уровня . Напротив, в то время как некоторые другие широко используемые системы интернет-безопасности работают выше сетевого уровня , такие как Transport Layer Security (TLS), который работает над транспортным уровнем , и Secure Shell (SSH), который работает на уровне приложений , IPsec может автоматически защищать приложения. на уровне Интернета .
IPsec — это открытый стандарт , являющийся частью пакета IPv4, который использует следующие протоколы для выполнения различных функций: [10] [11]
Заголовок аутентификации безопасности (AH) был разработан в Исследовательской лаборатории ВМС США в начале 1990-х годов и частично основан на предыдущих разработках стандартов IETF для аутентификации протокола простого сетевого управления (SNMP) версии 2. Заголовок аутентификации (AH) член набора протоколов IPsec. AH обеспечивает целостность без установления соединения с помощью хэш-функции и секретного общего ключа в алгоритме AH. AH также гарантирует происхождение данных путем аутентификации IP- пакетов . При желании порядковый номер может защитить содержимое пакета IPsec от атак повторного воспроизведения , [19] [20] с использованием техники скользящего окна и отбрасывания старых пакетов.
AH работает непосредственно поверх IP, используя IP-протокол номер 51 . [21]
Следующая диаграмма пакета AH показывает, как создается и интерпретируется пакет AH: [12] [13]
Полезная нагрузка IP-инкапсуляции безопасности (ESP) [22] была разработана в Военно-морской исследовательской лаборатории в 1992 году в рамках исследовательского проекта, спонсируемого DARPA , и была открыто опубликована рабочей группой IETF SIPP [23] , разработанной в декабре 1993 года в качестве средства обеспечения безопасности. расширение для SIPP. Этот ESP изначально был основан на протоколе SP3D Министерства обороны США, а не на основе протокола безопасности сетевого уровня ISO (NLSP). Спецификация протокола SP3D была опубликована NIST в конце 1980-х годов, но разработана в рамках проекта Secure Data Network System Министерства обороны США . Инкапсуляция полезных данных безопасности (ESP) является членом набора протоколов IPsec. Он обеспечивает подлинность источника посредством аутентификации источника , целостность данных посредством хэш-функций и конфиденциальность посредством шифрования IP- пакетов . ESP также поддерживает конфигурации «только шифрование» и «только аутентификация », но использование шифрования без аутентификации настоятельно не рекомендуется, поскольку оно небезопасно. [24] [25] [26]
В отличие от заголовка аутентификации (AH) , ESP в транспортном режиме не обеспечивает целостность и аутентификацию всего IP-пакета . Однако в туннельном режиме , когда весь исходный IP-пакет инкапсулируется с добавлением нового заголовка пакета, защита ESP предоставляется всему внутреннему IP-пакету (включая внутренний заголовок), а внешний заголовок (включая любые внешние параметры IPv4 или расширения IPv6) заголовки) остается незащищенным.
ESP работает непосредственно поверх IP, используя протокол IP номер 50. [21]
Следующая диаграмма пакета ESP показывает, как создается и интерпретируется пакет ESP: [1] [27]
Протоколы IPsec используют ассоциацию безопасности , при которой взаимодействующие стороны устанавливают общие атрибуты безопасности, такие как алгоритмы и ключи. Таким образом, IPsec предоставляет ряд возможностей после определения того, используется ли AH или ESP. Перед обменом данными два хоста согласовывают, какой алгоритм симметричного шифрования используется для шифрования IP-пакета, например AES или ChaCha20 , и какая хэш-функция используется для обеспечения целостности данных, например BLAKE2 или SHA256 . Эти параметры согласовываются для конкретного сеанса, для которого необходимо согласовать время жизни и ключ сеанса . [28]
Алгоритм аутентификации также согласовывается до начала передачи данных, и IPsec поддерживает ряд методов. Аутентификация возможна с помощью предварительного общего ключа , когда симметричный ключ уже имеется у обоих хостов, и хосты отправляют друг другу хэши общего ключа, чтобы доказать, что они владеют одним и тем же ключом. IPsec также поддерживает шифрование с открытым ключом , при котором каждый хост имеет открытый и закрытый ключи, они обмениваются своими открытыми ключами, и каждый хост отправляет другому одноразовый номер, зашифрованный открытым ключом другого хоста. Альтернативно, если оба хоста имеют сертификат открытого ключа от центра сертификации , его можно использовать для аутентификации IPsec. [29]
Ассоциации безопасности IPsec устанавливаются с использованием ассоциации безопасности Интернета и протокола управления ключами (ISAKMP). ISAKMP реализуется путем ручной настройки с использованием предварительно общих секретов, Интернет-обмена ключами (IKE и IKEv2), Kerberized Интернет-согласования ключей (KINK) и использования DNS-записей IPSECKEY . [18] [30] [31] RFC 5386 определяет безопасность «лучше, чем ничего» (BTNS) как неаутентифицированный режим IPsec с использованием расширенного протокола IKE. К. Медоуз, К. Кремерс и другие использовали формальные методы для выявления различных аномалий, существующих в IKEv1, а также в IKEv2. [32]
Чтобы решить, какую защиту необходимо обеспечить для исходящего пакета, IPsec использует индекс параметров безопасности (SPI), индекс базы данных ассоциаций безопасности (SADB), а также адрес назначения в заголовке пакета, которые вместе однозначно идентифицируют ассоциация безопасности для этого пакета. Аналогичная процедура выполняется для входящего пакета, где IPsec собирает ключи дешифрования и проверки из базы данных ассоциаций безопасности.
Для многоадресной IP-адресации для группы предоставляется ассоциация безопасности, которая дублируется на всех авторизованных получателях группы. Для группы может существовать более одной ассоциации безопасности с использованием разных SPI, что позволяет использовать несколько уровней и наборов безопасности внутри группы. Действительно, каждый отправитель может иметь несколько ассоциаций безопасности, что позволяет осуществлять аутентификацию, поскольку получатель может знать только, что кто-то, знающий ключи, отправил данные. Обратите внимание, что соответствующий стандарт не описывает, как ассоциация выбирается и дублируется в группе; предполагается, что ответственная сторона сделает выбор.
Чтобы гарантировать, что соединение между двумя конечными точками не было прервано, конечные точки через регулярные промежутки времени обмениваются сообщениями поддержки активности , которые также можно использовать для автоматического восстановления туннеля, потерянного из-за прерывания соединения.
Обнаружение мертвого узла (DPD) — это метод обнаружения неработающего узла обмена ключами в Интернете (IKE). Этот метод использует шаблоны трафика IPsec, чтобы минимизировать количество сообщений, необходимых для подтверждения доступности узла. DPD используется для восстановления потерянных ресурсов в случае, если одноранговый узел оказывается неработающим, а также для выполнения аварийного переключения однорангового узла IKE.
Поддержка активности UDP является альтернативой DPD.
Протоколы IPsec AH и ESP могут быть реализованы в режиме транспорта между хостами, а также в режиме сетевого туннелирования.
В транспортном режиме обычно шифруется или аутентифицируется только полезная нагрузка IP-пакета . Маршрутизация не повреждена, поскольку заголовок IP не изменяется и не шифруется; однако, когда используется заголовок аутентификации , IP-адреса не могут быть изменены путем преобразования сетевых адресов , поскольку это всегда делает недействительным значение хеш-функции . Транспортный и прикладной уровни всегда защищены хешем, поэтому их нельзя каким-либо образом изменить, например, путем перевода номеров портов .
Средство инкапсуляции сообщений IPsec для прохождения NAT {NAT-T} определено в документах RFC , описывающих механизм NAT-T.
В туннельном режиме весь IP-пакет шифруется и аутентифицируется. Затем он инкапсулируется в новый IP-пакет с новым IP-заголовком. Туннельный режим используется для создания виртуальных частных сетей для связи между сетями (например, между маршрутизаторами для связи сайтов), связи между хостами и сетями (например, удаленный доступ пользователей) и связи между хостами (например, приватный чат). [33]
Туннельный режим поддерживает обход NAT.
Криптографические алгоритмы, определенные для использования с IPsec, включают:
Подробности см. в RFC 8221.
IPsec может быть реализован в стеке IP операционной системы . Этот метод реализации применяется для хостов и шлюзов безопасности. Различные IP-стеки с поддержкой IPsec доступны от таких компаний, как HP или IBM. [34] Альтернативой является так называемая реализация «bump-in-the-stack» (BITS), при которой исходный код операционной системы не требует изменения. Здесь IPsec устанавливается между стеком IP и сетевыми драйверами . Таким образом, операционные системы могут быть оснащены IPsec. Этот метод реализации также используется как для хостов, так и для шлюзов. Однако при модернизации IPsec инкапсуляция IP-пакетов может вызвать проблемы при автоматическом обнаружении MTU пути , где устанавливается максимальный размер единицы передачи (MTU) на сетевом пути между двумя IP-узлами. Если хост или шлюз имеет отдельный криптопроцессор , который распространен в армии, а также может быть найден в коммерческих системах, возможна так называемая реализация IPsec по схеме «bump-in-the-wire» (BITW). [35]
Когда в ядре реализован IPsec , управление ключами и согласование ISAKMP / IKE осуществляется из пространства пользователя. Разработанный NRL и открыто указанный «API управления ключами PF_KEY, версия 2» часто используется, чтобы позволить приложению управления ключами в пространстве приложения обновлять ассоциации безопасности IPsec, хранящиеся в реализации IPsec в пространстве ядра. [36] Существующие реализации IPsec обычно включают ESP, AH и IKE версии 2. Существующие реализации IPsec в Unix-подобных операционных системах , например, Solaris или Linux , обычно включают PF_KEY версии 2.
Встроенный IPsec можно использовать для обеспечения безопасной связи между приложениями, работающими в системах с ограниченными ресурсами, с небольшими накладными расходами. [37]
IPsec был разработан совместно с IPv6 и изначально должен был поддерживаться всеми соответствующими стандартам реализациями IPv6 , прежде чем RFC 6434 сделал его только рекомендацией. [38] IPsec также является необязательным для реализаций IPv4 . IPsec чаще всего используется для защиты трафика IPv4. [ нужна цитата ]
Первоначально протоколы IPsec были определены в RFC 1825–RFC 1829, которые были опубликованы в 1995 году. В 1998 году эти документы были заменены RFC 2401 и RFC 2412 с некоторыми несовместимыми техническими деталями, хотя концептуально они были идентичны. Кроме того, был определен протокол взаимной аутентификации и обмена ключами Internet Key Exchange (IKE) для создания ассоциаций безопасности и управления ими. В декабре 2005 года новые стандарты были определены в RFC 4301 и RFC 4309, которые в значительной степени представляют собой расширенный набор предыдущих редакций со второй версией стандарта обмена ключами в Интернете IKEv2 . Эти документы третьего поколения стандартизировали сокращение IPsec на прописные буквы «IP» и строчные буквы «sec». «ESP» обычно относится к RFC 4303, который является самой последней версией спецификации.
С середины 2008 года в IETF действует рабочая группа по обслуживанию и расширению IPsec (ipsecme). [39] [40]
В 2013 году в рамках утечек Сноудена выяснилось, что Агентство национальной безопасности США активно работало над «вставкой уязвимостей в коммерческие системы шифрования, ИТ-системы, сети и конечные коммуникационные устройства, используемые целями» в рамках программы Bullrun . . [41] Есть утверждения, что IPsec был целевой системой шифрования. [42]
Стек OpenBSD IPsec появился позже и также широко копировался. В письме, которое ведущий разработчик OpenBSD Тео де Раадт получил 11 декабря 2010 года от Грегори Перри, утверждается, что Джейсон Райт и другие, работающие на ФБР, внедрили «ряд бэкдоров и механизмов утечки ключей по побочным каналам » в криптографическую систему OpenBSD. код. В пересланном электронном письме от 2010 года Тео де Раадт сначала не выразил официальную позицию относительно обоснованности претензий, за исключением неявного одобрения пересылки электронного письма. [43] Ответ Джейсона Райта на обвинения: «Каждая городская легенда становится более реальной благодаря включению реальных имен, дат и времени. Электронная почта Грегори Перри попадает в эту категорию. … Я четко заявлю, что я не добавлял бэкдоры в операционная система OpenBSD или криптографическая платформа OpenBSD (OCF)». [44] Несколько дней спустя де Раадт прокомментировал: «Я считаю, что NETSEC, вероятно, заключила контракт на написание бэкдоров, как утверждается. … Если они были написаны, я не верю, что они попали в наше дерево». [45] Это было опубликовано до утечки информации о Сноудене.
Альтернативное объяснение, выдвинутое авторами атаки Logjam, предполагает, что АНБ скомпрометировало IPsec VPN, подорвав алгоритм Диффи-Хеллмана , используемый при обмене ключами. В своей статье [46] они утверждают, что АНБ специально создало вычислительный кластер для предварительного вычисления мультипликативных подгрупп для конкретных простых чисел и генераторов, например, для второй группы Окли, определенной в RFC 2409. По состоянию на май 2015 года 90% адресных IPsec VPN поддерживали вторая группа Oakley в составе IKE. Если бы организация заранее вычислила эту группу, она могла бы получить ключи, которыми обмениваются, и расшифровать трафик без использования каких-либо программных бэкдоров.
Второе альтернативное объяснение, которое было выдвинуто, заключалось в том, что Equation Group использовала эксплойты нулевого дня против VPN-оборудования нескольких производителей, которые были проверены « Лабораторией Касперского» как связанные с Equation Group [47] и проверены этими производителями как настоящие эксплойты. некоторые из них на момент раскрытия представляли собой эксплойты нулевого дня. [48] [ 49] [ 50 ] Межсетевые экраны Cisco PIX и ASA имели уязвимости, которые использовались АНБ для прослушивания телефонных разговоров .
Кроме того, сети IPsec VPN, использующие настройки «агрессивного режима», отправляют хэш PSK в открытом виде. Это может быть целью АНБ, которая, по всей видимости, нацелена на использование автономных атак по словарю . [46] [51] [52]
{{cite book}}: CS1 maint: дата и год ( ссылка )Написание «IPsec» является предпочтительным и используется в этом и всех связанных стандартах IPsec. Все другие варианты написания IPsec [...] с заглавной буквы устарели.