8.10. Защита соединений

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

Следующие разделы посвящены защите соединений. Мы узнаем, как передавать биты от отправителя получателю конфиденциально и без изменений, при этом не пропуская посторонние биты. Это далеко не все проблемы сетевой безопасности, но определенно одни из самых важных.


8.10.1. IPsec

IETF в течение многих лет мирился с отсутствием безопасности в интернете. Обеспечить ее было непросто из-за жарких споров о том, в какой части системы располагать средства защиты. Большинство экспертов по вопросам безопасности уверены в том, что по-настоящему надежная система должна выполнять сквозное шифрование и сквозное обеспечение целостности данных (то есть все это должно быть сделано на прикладном уровне). Другими словами, процесс-источник шифрует и/или ставит защиту целостности данных и отправляет их процессу-получателю, который, в свою очередь, дешифрует данные и/или проверяет их целостность. Это позволит заметить любые попытки взлома (даже на уровне операционной системы на любой из сторон). Проблема в том, что для обеспечения безопасности требуется вносить изменения во все приложения. Из этого следует, что лучше перенести шифрование на транспортный уровень или организовать новый специализированный подуровень между прикладным и транспортным. Он должен быть сквозным, но в то же время не требующим внесения изменений в приложения.

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

Результатом всех этих споров было создание стандарта IPsec (IP security — IP-безопасность), описанного в ряде спецификаций RFC. Не всем пользователям требуется шифрование соединений (соответствующие процедуры могут занимать существенную долю вычислительных ресурсов). Однако вместо того чтобы делать шифрование необязательным, пользователю предлагается в случае необходимости выбирать нулевое шифрование. В RFC 2410 описаны такие достоинства нулевого шифрования, как простота, легкость реализации и высокая скорость.

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

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

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

Немного удивляет, что IPsec ориентирован на установление соединения, хотя расположен на уровне IP. На самом деле это не так странно, как кажется. Ведь безопасность можно обеспечить только созданием ключа и использованием его в течение какого-то времени. А это, по сути дела, разновидность соединения. К тому же все соединения нивелируют расходы на их установление за счет передачи большого количества пакетов. «Соединение» в контексте IPsec называется сопоставлением безопасности (Security Association, SA). Это симплексное соединение между двумя конечными точками, с которым связан специальный идентификатор защиты. Если требуется передача защищенных данных в обоих направлениях, нужны две SA. Идентификаторы защиты содержатся в пакетах, следующих по этим надежным соединениям, и по прибытии используются для поиска ключей и другой важной информации.

Технически IPsec состоит из двух основных частей. Первая часть описывает два новых заголовка, которые можно добавлять к пакету для передачи идентификатора защиты, данных контроля целостности и другой информации. Вторая, ISAKMP (Internet Security and Key Management Protocol — интернет-безопасность и протокол управления ключами), предназначена для создания ключей и является средой. Основным протоколом для выполнения работы является IKE (Internet Key Exchange — обмен ключами в интернете). Он прошел через множество модификаций, устранивших обнаруженные недостатки.

IPsec может работать в двух режимах. В транспортном режиме (transport mode) заголовок IPsec вставляется сразу после заголовка IP. Поле Protocol заголовка IP меняется так, чтобы было понятно, что далее следует заголовок IPsec (перед заголовком TCP). В заголовке IPsec содержится информация о безопасности, в частности идентификатор SA, новый порядковый номер и, возможно, проверка целостности пользовательских данных.

В режиме туннелирования (tunnel mode) весь IP-пакет вместе с заголовком вставляется внутрь нового IP-пакета с совершенно новым заголовком. Этот режим применяется, если туннель заканчивается не в пункте назначения. В некоторых случаях концом туннеля является шлюз безопасности, например корпоративный брандмауэр. Обычно это касается VPN. В этом режиме шлюз безопасности инкапсулирует и декапсулирует пакеты, проходящие через него. При такой организации компьютеры LAN компании не должны знать о стандарте IPsec. Об этом должен беспокоиться только шлюз безопасности.

Также режим туннелирования применяется, если несколько TCP-соединений объединяются вместе и обрабатываются в виде единого зашифрованного потока, поскольку в этом случае взломщик не может узнать, кто передает пакеты, в каком количестве и кому. А ведь иногда даже объем и назначение передаваемого трафика является ценной информацией. Например, если во время военного кризиса трафик между Пентагоном и Белым домом резко снижается, а трафик между Пентагоном и какой-нибудь военной базой в Колорадо так же резко возрастает, перехватчик может сделать из этого далеко идущие выводы. Изучение структуры потока пакетов (даже если они зашифрованы) называется анализом трафика. Режим туннелирования в некоторой степени усложняет такой анализ. Недостаток этого режима состоит в добавлении дополнительного IP-заголовка, что заметно увеличивает пакет. Транспортный режим, напротив, не так сильно влияет на размер пакетов.

Один из новых заголовков называется заголовком аутентификации (Authentication Header, AH). С его помощью проверяется целостность данных и выполняется защита от взлома путем повторной передачи. Однако он не имеет никакого отношения к секретности (то есть к шифрованию данных). Применение AH в транспортном режиме показано на илл. 8.41. В стандарте IPv4 он располагается между заголовком IP (вместе со всеми необязательными полями) и заголовком TCP. В IPv6 он рассматривается просто как еще один заголовок расширения. Формат АН действительно очень близок к формату заголовка расширения стандарта IPv6. Иногда к полю Payload (Пользовательские данные) добавляют заполнение (padding), чтобы достичь определенной длины, необходимой алгоритму аутентификации (см. илл. 8.41).

Илл. 8.41. Заголовок аутентификации IPsec в транспортном режиме для IPv4

Рассмотрим заголовок АН. В поле Next header (Следующий заголовок) хранится значение, которое раньше находилось в поле Protocol (Протокол) заголовка IP (до того, как было заменено на 51, чтобы показать, что далее следует заголовок АН). Обычно здесь встречается код для TCP (6). Поле Payload length (Длина полезной нагрузки) хранит количество 32-разрядных слов заголовка АН минус 2.

Поле Security parameters index (Указатель параметров безопасности) — это идентификатор соединения, который вставляется отправителем. Он ссылается на конкретную запись в базе данных получателя. В этой записи содержится общий ключ и другая информация о соединении. Если бы данный протокол был придуман МСЭ, а не IETF, это поле называлось бы Virtual circuit number (Номер виртуального канала).

Поле Sequence number (Порядковый номер) применяется для нумерации всех пакетов, отправляемых по SA. Все пакеты получают уникальные номера, даже если они отсылаются повторно. Другими словами, повторно передаваемый пакет имеет номер, отличный от номера оригинального пакета (даже если у них одинаковый порядковый номер TCP). Это поле служит для предотвращения взлома путем повторной передачи. Порядковые номера никогда не повторяются. Если же будут использованы все 232 номера, для продолжения коммуникации устанавливается новая SA.

Наконец, поле переменной длины Authentication data (Данные аутентификации) содержит цифровую подпись пользовательских данных. При установлении SA стороны договариваются, какой алгоритм генерации подпи­сей использовать. Обычно здесь не применяется шифрование с открытыми ключами, так как все известные алгоритмы этого типа слишком медленные, а пакеты нужно обрабатывать с очень большой скоростью. Протокол IPsec основан на шифровании с симметричными ключами, поэтому перед установлением SA отправитель и получатель должны договориться о значении общего ключа, применяемого при вычислении подписи. То есть IPsec использует код HMAC, который мало чем отличается от того кода, о котором мы говорили в разделе, посвященном аутентификации с использованием общего ключа. Вычисление этого кода выполняется гораздо быстрее, чем последовательный запуск SHA-2 и RSA.

Заголовок AH не позволяет шифровать данные, так что в основном он применяется в случаях, когда нужна проверка целостности, но не требуется секретность. Стоит отметить, что проверка целостности при помощи AH охватывает некоторые поля заголовка IP, которые не меняются при прохождении пакета между маршрутизаторами. К примеру, поле TtL (Время жизни) изменяется на каждом переходе, и проверка его не затрагивает. А вот IP-адрес источника проверяется, что делает невозможной его подмену.

Альтернативным заголовком IPsec является ESP (Encapsulating Security Payload — безопасная инкапсуляция пользовательских данных). Как показано на илл. 8.42, он может применяться как в транспортном режиме, так и в режиме туннелирования.

Илл. 8.42. (а) ESP в транспортном режиме. (б) ESP в режиме туннелирования

Заголовок ESP состоит из двух 32-разрядных слов: Security parameters index (Указатель параметров безопасности) и Sequence number (Порядковый номер). Мы их уже встречали в заголовке AH. Третье слово, которое обычно следует за ними, при этом технически не являясь частью заголовка, это Initialization vector (Вектор инициализации); но если используется пустой алгоритм шифро­вания, это поле опускается.

ESP, как и АН, обеспечивает проверку целостности при помощи кода HMAC, однако вместо того чтобы включать хеш в заголовок, он вставляется после поля пользовательских данных (см. илл. 8.24). Такое расположение полей дает преимущество при аппаратной реализации метода: HMAC может подсчитываться во время передачи битов пользовательских данных по сети и добавляться в конце. Именно поэтому в Ethernet и других стандартах LAN CRC вставляется в трейлер, а не в заголовок. При использовании заголовка АН пакет нужно буферизовать и вычислять подпись, только после этого его можно отправлять. Это потенциально снижает число пакетов, которые можно передать за единицу времени.

Казалось бы, если ESP умеет делать все то же, что и АН (даже больше и при этом гораздо эффективнее), зачем вообще нужен АН? Причина скорее историческая. Изначально заголовок АН обеспечивал только проверку целостности, а ESP — только секретность. Позднее ESP стали использовать для проверки целостности, но разработчики АН не хотели, чтобы он канул в Лету после всей проделанной ими работы. Единственный (и довольно слабый) аргумент в пользу АН заключается в том, что с его помощью можно частично проверять заголовок IP, чего не умеет ESP. Еще один сомнительный довод состоит в том, что система, поддерживающая АН, но не поддерживающая ESP, может легче получить лицензию на экспорт, поскольку с помощью АН нельзя шифровать данные. Похоже, что этот заголовок все-таки исчезнет.


8.10.2. Виртуальные частные сети

У многих компаний имеются филиалы, расположенные в разных городах или даже в разных странах. До появления сетей общего доступа обычным делом было арендовать выделенную телефонную линию для организации связи между некоторыми (или всеми) парами подразделений. В некоторых компаниях такой подход применяется до сих пор. Сеть, состоящая из принадлежащих компании компьютеров и выделенных телефонных линий, называется частной сетью (private network).

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

В качестве ответа на этот запрос появились виртуальные частные сети (Virtual Private Networks, VPN). Это оверлейные сети, которые работают поверх обычных общедоступных сетей, но обладают свойствами частных. Они называются виртуальными, поскольку это не более чем иллюзия, так же как виртуальные каналы — это не реальные каналы, а виртуальная память — не реальная память.

Часто VPN развертывают напрямую в интернете. Как правило, в каждом офисе устанавливается брандмауэр и создаются туннели через интернет между всеми парами офисов (илл. 8.43 (а)). Интернет удобен тем, что туннели можно устанавливать по требованию и, к примеру, подключать компьютер сотрудника, который находится дома или путешествует (при условии, что он имеет соединение с интернетом). Такая топология обеспечивает более высокую гибкость по сравнению с реальными выделенными линиями, но с точки зрения компьютеров внутри VPN она выглядит точно так же, как частная сеть (илл. 8.43 (б)). При запуске системы каждая пара брандмауэров должна договориться о параметрах SA, таких как набор услуг, режимов, алгоритмов и ключей. Если используется IPsec в режиме туннелирования, можно собрать весь трафик между любыми двумя парами офисов в один надежный поток и установить SA, обеспечив тем самым контроль целостности, секретности и даже определенную устойчивость к анализу трафика. Возможности VPN встроены во многие брандмауэры.

Илл. 8.43. (а) VPN. (б) Топология, видимая изнутри сети

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

Таким образом, естественная и наиболее распространенная комбинация — это брандмауэры, VPN и IPsec с ESP в режиме туннелирования.

После установления SA начинается передача данных. С точки зрения маршрутизатора, работающего в интернете, пакет, проходящий по туннелю VPN, — самый обычный пакет. Единственное, что его отличает от остальных, — это наличие заголовка IPsec после заголовка IP. Но поскольку дополнительные заголовки на процесс пересылки никак не влияют, заголовок IPsec маршрутизатору безразличен.

Другой подход, набирающий популярность, — реализация VPN с помощью интернет-провайдера. За счет использования MPLS (как обсуждалось в главе 5) пути для трафика VPN между офисами компании могут быть установлены через сеть интернет-провайдера. Эти пути отделяют трафик VPN от другого интернет-трафика и могут гарантировать определенную пропускную способность или другой уровень QoS.

Основное преимущество VPN состоит в том, что она совершенно прозрачна для любого пользовательского ПО. Установкой и управлением SA занимается брандмауэр. Единственный человек, знающий об устройстве сети, — системный администратор, который должен конфигурировать и поддерживать шлюзы безопасности (или администратор интернет-провайдера, настраивающий пути MPLS). Для всех остальных VPN мало чем отличается от частной сети на основе выделенной линии. Более подробную информацию об этих сетях вы можете найти в работе Ашрафа (Ashraf, 2018).


8.10.3. Безопасность в беспроводных сетях

Как ни парадоксально, с помощью VPN и брандмауэров очень просто создать систему, которая по логике абсолютно надежна, но на практике протекает, как решето. Такая ситуация может возникнуть, если в сети есть беспроводные устройства, передающие данные с помощью радиосигнала, который проходит прямо через брандмауэр в обоих направлениях. Радиус действия сетей 802.11 может составлять до 100 м, поэтому для перехвата информации шпион может просто приехать на автостоянку перед зданием фирмы, оставить в машине ноутбук с приемопередатчиком 802.11, записывающим все, что слышно в эфире, и пойти гулять по городу. Вернувшись под вечер, он обнаружит на диске ноутбука массу интересных сведений. Теоретически так быть не должно. Правда, теоретически ограбления банков тоже не должны происходить.

За многие проблемы безопасности стоит «поблагодарить» производителей беспроводных базовых станций (точек доступа), которые пытаются сделать свою продукцию удобной для пользователя. Обычно, как только пользователь вынимает устройство из коробки и подключает его к розетке, оно сразу начинает работать. И почти всегда без каких-либо мер безопасности — люди в зоне действия радиопередатчика могут услышать секреты, о которых пользователь проболтается. Если же устройство подключить к Ethernet, весь трафик может оказаться на ноутбуке в припаркованной неподалеку машине. Беспроводная связь — это мечта шпиона, ставшая реальностью: информация сама идет в руки, только успевай ее ловить. Очевидно, что вопрос безопасности в таких сетях стоит куда острее, чем в проводных. В этом разделе мы рассмотрим некоторые методы, позволяющие обезопасить системы такого рода, уделив особое внимание Wi-Fi. Дополнительную информацию можно найти в книге Остерхаге (Osterhage, 2018).

Часть стандарта 802.11, изначально названная 802.11i, описывает протокол безопасности канального уровня, не позволяющий беспроводному узлу читать или другим образом вмешиваться в сообщения, отправленные другой парой беспроводных узлов. Этот протокол также известен под коммерческим названием WPA2 (Wi-Fi Protected Access 2 — защищенный доступ к Wi-Fi, версия 2). Простой WPA — это промежуточная схема, реализующая подмножество стандарта 802.11i. На смену ему пришел WPA2. В январе 2018 года была анонсирована следующая после WPA2 версия с оригинальным названием WPA3. Она использует 128-битное шифрование для личного пользования и 192-битное — для корпоративной версии. Протокол WPA3 отличается целым рядом улучшений по сравнению с WPA2. Вероятно, главным из них является переработанный механизм «рукопожатия» под названием «Dragonfly». Он предотвращает некоторые виды атак подбора пароля, которые создавали массу проблем в протоколе WPA2. На момент написания книги WPA3 применяется еще не так широко, как WPA2. Кроме того, в апреле 2019 года исследователи выявили вектор атаки, получивший название «DragonBlood», который сводит на нет многие из преимуществ WPA3 по обеспечению безопасности. В силу этого основное внимание в данном разделе будет уделено WPA2.

Мы кратко опишем протокол 802.11i, но сначала отметим, что он заменяет WEP (Wired Equivalent Privacy — конфиденциальность на уровне проводных сетей), первое поколение протоколов безопасности 802.11. Протокол WEP был создан комитетом по сетевым стандартам. Его подход к разработке кардинально отличался от стратегии, например, института NIST, который выбрал дизайн алгоритма AES на открытом международном конкурсе. Это привело к удручающим результатам. Что же было не так? Как оказалось, с точки зрения безопасности практически все. Например, WEP зашифровывал конфиденциальные данные с помощью XOR с выходом поточного шифра. К сожалению, слабые механизмы ключей приводили к использованию данных несколько раз, поэтому их было просто расшифровать. В качестве еще одного примера можно привести проверку целостности, основанную на 32-битном CRC. Этот код эффективен для определения ошибок передачи, но он не является криптографически сильным механизмом борьбы со взломщиками.

Эти и другие недостатки сделали WEP легкой мишенью. Первая практическая демонстрация взлома WEP была проведена Адамом Стабблфилдом (Adam Stubblefield), когда он стажировался в компании AT&T (Stubblefield и др., 2002). Он смог реализовать и проверить атаку, описанную Флюрером и др. (Fluhrer et al., 2001), за одну неделю, потратив большую часть времени на убеждение менеджеров предоставить ему Wi-Fi-карту для эксперимента. Программы, взламывающие пароли WEP за одну минуту, теперь находятся в свободном доступе, поэтому использовать WEP не рекомендуется. Он запрещает открытый доступ, но не обеспечивает никакой реальной защиты. Когда стало ясно, что WEP взломан, группа 802.11i поспешно собралась для решения этой проблемы. В результате в июне 2004 года был выпущен формальный стандарт.

Теперь мы опишем 802.11i, который обеспечивает реальную безопасность, если он правильно настроен и применяется корректно. Существует два стандартных сценария, в которых задействован WPA2. Первый — это корпоративное использование, когда у компании есть отдельный сервер для аутентификации, хранящий имена пользователей и пароли. С помощью этих данных система определяет, может ли беспроводной клиент получить доступ к сети. В этом случае клиенты используют стандартные протоколы для того, чтобы аутентифицировать себя и войти в сеть. Основные стандарты — это 802.1X, где точка доступа позволяет клиенту вести диалог с сервером аутентификации и наблюдать результат, а также расширенный протокол аутентификации (Extendable Authentication Protocol, EAP). EAP (RFC 3748) описывает взаимодействие клиента и сервера аутентификации. По сути, он является средой, а другие стандарты определяют сообщения протокола. Мы не будем подробно изучать эти сообщения, для крат­кого обзора это не имеет значения.

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

Ключи для шифрования трафика вычисляются как часть аутентификационного «рукопожатия». Эта процедура происходит сразу после того, как клиент связывается с беспроводной сетью и подтверждает подлинность на сервере аутентификации (если есть такой сервер). В начале «рукопожатия» у клиента есть либо общий пароль сети, либо пароль для сервера аутентификации. Пароль нужен для получения главного ключа. Однако этот ключ не используется напрямую для шифрования пакетов. Существует стандартная криптографическая практика: новый ключ сеанса создается для каждого периода использования и меняется для разных сеансов, а главный ключ держится в секрете. Во время «рукопожатия» вычисляется именно ключ сеанса.

Ключ сеанса рассчитывается четырехпакетным «рукопожатием» (илл. 8.44). Прежде всего AP (Access Point — точка доступа) отправляет случайное число для идентификации. Клиент также выбирает свой собственный нонс. Чтобы вычислить ключ сеанса Ks, клиент использует нонсы, свой MAC- и AP-адрес, а также главный ключ. Ключ сеанса разбивается на части, каждая из которых применяется для различных целей (мы опустим эти детали). Теперь у клиента есть ключи сеанса, а у AP нет. Клиент отправляет свой нонс AP, и AP производит тот же самый расчет, чтобы получить те же ключи сеанса. Нонсы могут передаваться открыто, так как вычислить ключи на их основе невозможно без дополнительной, секретной информации. Сообщение клиента защищено проверкой целостности сообщения (Message Integrity Check, MIC), которая проводится на основе ключа сеанса. После вычисления ключей сеанса AP может установить, что MIC верна и сообщение действительно пришло от клиента. MIC — это просто еще одно название кода аутентификации сообщения, подобного HMAC. Название «MIC» часто используется вместо «HMAC» в случае протоколов безопасности, чтобы не возникало путаницы с MAC-адресами.

Илл. 8.44. Генерация сеансового ключа «рукопожатием» в 802.11i

В последних двух сообщениях AP выдает клиенту общий ключ KG, и клиент подтверждает его получение. Это позволяет AP удостовериться, что у клиента есть верные ключи сеанса, а клиенту — что они есть у AP. Общий ключ используется для передачи трафика по 802.11 LAN. Поскольку в результате «рукопожатия» оказывается, что у каждого клиента есть свои ключи шифрования, ни один из этих ключей не может быть использован AP для передачи пакетов всем клиентам беспроводной сети. Можно было бы отправить отдельную копию со своим ключом каждому клиенту. Вместо этого используется общий ключ, так что широковещательный трафик может быть передан один раз и получен всеми клиентами. Этот ключ должен обновляться по мере того, как клиенты уходят из сети и присоединяются к ней.

Наконец, мы подходим к той части, где ключи действительно применяются для обеспечения безопасности. Чтобы добиться конфиденциальности, целостности и аутентификации, в 802.11i могут использоваться два протокола. Один из них, протокол целостности временного ключа (Temporary Key Integrity Protocol, TKIP) был временным решением (как и WPA). Он был разработан для повышения безопасности старых и медленных карт 802.11, это была хоть какая-то защита (лучше, чем WEP), доступная после обновления прошивки. Однако TKIP тоже был взломан, поэтому сегодня рекомендуется использовать протокол CCMP. Эта аббревиатура означает «Counter mode with Cipher block chaining message authentification code protocol» — «режим счетчика с протоколом аутентификации в режиме сцепления обратной связи». Мы будем использовать сокращение CCMP, а вы называйте его как угодно.

Принцип действия CCMP достаточно прост. Он использует шифрование AES с помощью ключа и блоков размером 128 бит. Ключ выводится из ключа сеанса. Чтобы обеспечить конфиденциальность, сообщения зашифровываются с помощью AES в режиме счетчика. Режимы шифров (см. раздел 8.2.3) предотвращают шифрование одних и тех же сообщений в одинаковые наборы битов. Режим счетчика внедряет счетчик в процесс шифрования сообщения. Чтобы обеспечить целостность, сообщение (включая поля заголовков) кодируется шифром в режиме обратной связи, и последний блок из 128 бит сохраняется как MIC. Затем и сообщение (закодированное в режиме счетчика), и MIC отсылаются. Как клиент, так и AP могут выполнять это шифрование или проверять его при получении беспроводного пакета. В случае многоадресных или широковещательных сообщений применяется групповой ключ.

Загрузка...