Алгоритмы защиты информации в беспроводных сетях стандарта IEEE 802.11 (стр. 4 из 8)

Рис.2.2 Алгоритм шифрования по протоколу ССМР

В стандарте IEEE 802.Hi определено, что размер ключа AES равен 128 бит. Как и в TKIP, в ССМР используются 48-разрядные IV (здесь они называются номерами пакетов, PN) (рис. 2.3) и несколько видоизмененный алгоритм MIC. В ССМР функции порождения пакетных ключей не реализованы, поскольку сильный шифр AES делает их излишними.

2.3 Пакет после шифрования по ССМР.

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

Таблица 1 Возможности протоколов шифрования, используемых в беспроводных сетях.

Отметим, что уже созданы микросхемы с аппаратной реализацией AES, что снижает вычислительную нагрузку на аппаратуру сетевых устройств. Это, а также выход на рынок продуктов, поддерживающих протокол ССМР, влечет полный пересмотр архитектуры оборудования для сетей IEEE 802.11. Кроме того, еще остается несколько вопросов, не решенных в стандарте IEEE 802.Hi. В частности, речь идет о безопасности независимых сетей, быстрой передаче пользователя от одной точки доступа к другой, а также о процедурах прекращения сеанса и отсоединения.

Модель AAA.

Протокол RADIUS AAA (Authentication, Authorization, Accounting — аутентификация, авторизация и учет) считается краеугольным камнем службы удаленной аутентификации пользователей RADIUS (Remote Authentication Dial-In User Service). Она предназначена для управления доступом к компьютерным ресурсам, проведения определенных политик, анализа использования ресурсов и предоставления информации, необходимой для взимания платы за пользование ими. Все эти процедуры жизненно важны для эффективного и рационального управления сетью.

В основе модели AAA лежат три понятия — аутентификация, авторизация и учет.

Аутентификация — это способ идентификации пользователя путем запроса его «верительных грамот» и проверки их правильности. Предполагается, что у каждого пользователя имеется уникальный набор характеристик для получения доступа. Сервер, удовлетворяющий требованиям AAA, сравнивает эти характеристики с теми, которые хранятся в базе данных. Если «верительные грамоты» совпадают, то пользователю предоставляется доступ к запрошенным сетевым ресурсам, в противном случае в доступе будет отказано. По завершении процедуры аутентификации следует авторизация, т. е. принятие решения о том, разрешено ли пользователю выполнять определенные задачи и пользоваться теми или иными сетевыми ресурсами. Обычно авторизация производится одновременно с аутентификацией; если разрешение получено, то пользователь будет иметь доступ к ресурсам. Таким образом, авторизация — необходимая составная часть разумной политики администрирования. Последняя составляющая модели AAA — это учет. Под учетом понимается процесс измерения и протоколирования используемых сетевых ресурсов. Сюда включается мониторинг и фиксация событий для различных целей, в том числе биллинга, анализа трендов, учета потребления ресурсов, планирования вычислительных мощностей и текущего сопровождения.

Несмотря на то, что протокол RADIUS был разработан еще до оформления модели AAA, он может служить хорошим примером ее практической реализации. Протокол RADIUS широко применяется во многих сетях. Его можно определить как протокол безопасности, в котором для аутентификации удаленных пользователей используется модель клиент-сервер. Реализуется он в виде серии запросов и ответов, которые клиент передает от сервера доступа к сети (Network Access Server — NAS) до конечного пользователя. Протокол RADIUS был разработан в ответ на настоятельную необходимость иметь некий метод аутентификации, авторизации и учета действий пользователей, которым необходим доступ к разнородным вычислительным ресурсам.

Основные особенности протокола RADIUS:

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

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

- Гибкие механизмы аутентификации. RADIUS-сервер допускает различные методы аутентификации пользователей. Получив имя пользователя и его пароль, он может поддержать процедуры аутентификации по протоколу PAP, CHAP или ОС UNIX, а также поискать информацию в иных хранилищах, например РАМ, LDAP, SQL и т. д..

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

Рис. 2.4 Структура пакета протокола RADIUS.

Пакеты протокола RADIUS (рис. 2.4) инкапсулированы в поток данных протокола UDP. Поле кода определяет тип пакета.

Получив пакет с некорректным значением кода, сервер игнорирует его без каких-либо уведомлений. Идентификатор позволяет клиенту RADIUS сопоставить полученный от сервера ответ с ранее посланным запросом. В поле «длина» указывается длина пакета сообщения в байтах (от 20 до 4096), включая заголовок. Аутентификатор используется для аутентификации и верификации ответа от RADIUS-сервера, а также как механизм сокрытия паролей. В этом поле могут передаваться значения двух типов: идентификаторы запроса и ответа.

Аутентификатор запроса может встречаться в пакетах типа Access (Доступ) и Accounting Request (Запрос учетной информации), его значение должно быть случайно и уникально. Ответ передается в пакетах типа Access-Accept (Доступ разрешен), Access-Reject (Доступ запрещен) и Access-Challenge (Запрос). Аутентификатор ответа должен содержать значение хеш-функции (по алгоритму MD5), вычисленное по значениям полей кода, идентификатора, длины, аутентификатора, атрибутов и по общему секретному коду.

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

Уязвимости протокола RADIUS.

Известен целый ряд слабостей RADIUS, причиной которых является как сам протокол, так и неудачная реализация клиентов. Перечислим некоторые уязвимости, далеко не исчерпав весь список проблем протокола. Отметим, что сам по себе протокол UDP позволяет подделывать пакеты. Атаки можно отнести к следующим категориям:

· подбор «верительных грамот» пользователя методом полного перебора;

· DoS-атака;

· повтор сеанса;

· внедрение поддельных пакетов.

Различные виды атак многократно описаны в литературе, отметим лишь некоторые наиболее общие типы.

Атака на аутентификатор ответа.

Аутентификатор ответа (Response Authenticate) — это, по существу, MD5-свертка. Если злоумышленник сумел перехватить корректную последовательность пакетов типа Access-Request, Access-Accept или Access-Reject, то он может, уже не находясь в сети, попробовать вскрыть общий секретный код методом полного перебора, поскольку остальные параметры, на основе которых вычисляется свертка, известны (код + идентификатор + длина + аутентификатор + атрибуты). Затем возможно повторять эту свертку при каждой попытке угадать общий секретный код.

Атака на общий секретный код на основе атрибута Password.

Мандат, содержащий пару имя-пароль, является защищенным, но противник может получить информацию об общем секретном коде, если будет следить за попытками аутентификации. Если взломщик предпримет попытку аутентифи-цироваться с известным паролем, а затем перехватит отправляемый в результате пакет Accept-Request, то он сможет сравнить защищенную часть атрибута User-Password с паролем, который он сообщил клиенту ранее. Поскольку аутентификатор ответа известен (его можно увидеть в пакете Accept-Request), то противник получает возможность провести атаку методом полного перебора на общий секретный код, уже не находясь в сети.

Атака на пароль пользователя.

Эта атака аналогична предыдущей: зная общий секретный код, противник может пробовать различные пароли путем модификации и воспроизведения пакетов типа Access-Request. Если сервер не ограничивает число безуспешных попыток аутентификации одного пользователя, то атакующий сумеет выполнить полный перебор всех паролей, пока не отыщет правильный. Следует отметить, что применение стойкой схемы аутентификации в пакете Access-Request сделает такую атаку почти невозможной.

Атака на аутентификатор запроса.