Шифрование по алгоритму AES

Известно, что шифрование и аутентификация, проводимые в соответствии со стандартом 802.11, имеют слабые стороны. IEEE и WPA усилили алгоритм WEP протоколом TKIP и предлагают сильный механизм аутентификации по стандарту 802.11i, обеспечивающий защиту беспроводных LAN стандарта 802.11. В то же время IEEE рассматривает возможность усиления механизма шифрования. С этой целью IEEE адаптировал алгоритм AES для применения его по отношению к разделу, касающемуся защищаемых данных предлагаемого стандарта 802.11i. Компоненты WPA не обеспечивают поддержку шифрования по алгоритму AES. Однако последние версии WPA, возможно, будут реализованы в соответствии со стандартом 802.11i и для обеспечения взаимодействия будут поддерживать шифрование по алгоритму AES.

Алгоритм AES представляет собой следующее поколение средств шифрования, одобренное Национальным институтом стандартов и технологий (NIST) США. Названный институт предложил сообществу криптологов разработать новые алгоритмы шифрования. Эти алгоритмы должны быть полностью открыты и использоваться бесплатно.

Кандидаты были проверены на предмет "криптографической прочности" и практической применимости. Финалистом и принятым методом стал так называемый алгоритм Рийндэла (Rijndael algorithm). Как и многие другие шифры, AES требует режима обратной связи во избежание риска, связанного с режимом ECB (напомним, это - режим шифрования с помощью книги электронных кодов). IEEE разработал режим AES, предназначенный специально для применения в беспроводных LAN.

Этот режим называется режим счета сцеплений блоков шифра (Cipher Block Chaining Counter Mode, CBC-CTR) с контролем аутентичности сообщений о сцеплениях блоков шифра (Cipher Block Chaining Message Authenticity Check, CBC-MAC), все вместе это обозначается аббревиатурой AES-CCM. Режим CCM представляет собой комбинацию режима шифрования CBC-CTR и алгоритма контроля аутентичности сообщений CBC-MAC. Эти функции скомбинированы для обеспечения шифрования и проверки целостности сообщений в одном решении.

Алгоритм шифрования CBC-CTR работает с использованием счетчика для пополнения ключевого потока. Значение этого счетчика увеличивается на единицу после шифрования каждого блока. Такой процесс обеспечивает получение уникального ключевого потока для каждого блока. Фрейм с открытым текстом делится на 16-байтовые блоки. После шифрования каждого блока значение счетчика увеличивается на единицу, и так до тех пор, пока не будут зашифрованы все блоки. Для каждого нового фрейма счетчик переустанавливается.

Алгоритм шифрования CBC-MAC выполняется с использованием результата шифрования CBC по отношению ко всему фрейму, к адресу назначения, адресу источника и данным. Результирующий 128-разрядный выход усекается до 64 бит для использования в передаваемом фрейме.

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

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

Приложение. Описание протокола EAP

Протокол EAP предназначен для обеспечения расширенной аутентификации, когда IP протокол недоступен. Будучи изначально предназначенным для использования вместе с PPP(Point-to-Point Protocol) протоколом, протокол EAP нашёл также широкое применение в беспроводных сетях (IEEE-802.1X). Главной особенностью данного протокола является то, что механизм аутентификации определяется на более поздней фазе, уже после установления непосредственного соединения. Это позволяет аутентификатору получить некую дополнительную информацию о клиенте, который хочет быть авторизован. Основные термины:

• Аутентификатор(authenticator) - один из концов соединения, требующий аутентификацию.

• Клиент(peer) – другой конец соединения, который будет проходить процедуру аутентификации на аутентификаторе.

• AAA– аутентификация (Authentication), авторизация (Authorization) и учёт (Accounting). Наиболее известные AAA-протоколы с поддержкой EAP это RADIUS [RFC3579] and Diameter [I-D.ietf-aaa-eap].

Итак, как же происходит аутентификация с помощью протокола EAP?

1. После процедуры установления соединения аутентификатор посылает запрос клиенту, в котором содержится поле «тип», оно показывает, что именно запрашивает аутентификатор. Запрос может посылаться несколько раз.

2. Затем клиент посылает пакет с ответом аутентификатору, причем на каждый из запросов. В ответе также содержится поле «тип», отвечающее за то, на какой именно запрос делается ответ.

3. Аутентификатор заканчивает процедуру аутентификации, посылая пакет, сигнализирующий об успешной аутентификации(Success packet) или о неудавшейся аутентификации(Failure packet).

Последовательность пунктов 1-2 может повторяться необходимое число раз, определяемое реализацией. Причём EAP протокол пошаговый(lock-step), т.е. каждый последующий пакет с запросом посылается только после получения ответа на предыдущий запрос.

3. Формат пакетов протокола EAP

Пакет в протоколе EAP состоит из следующих полей

код

идентификатор

длина

тип

тип данных

1. Код – равен 1 для пакета с запросом, 2 - для пакета с ответом, 3 – для пакета, сигнализирующего об успешной аутентификации(success-пакет), 4 – аутентификацию не прошла(failure-пакет)

2. Идентификатор – поле, длиной в 8 бит, в ответе идентификатор должен быть таким же, что и в запросе. Во время сессии для каждого из запросов идентификатор выбирается уникальным в пределах одной сессии, однако при ретрансляции запроса по таймауту, идентификатор не должен меняться. Если клиент получает запросы с одинаковым идентификатором (например, ожидается ввод с консоли) то все дублирующиеся запросы он просто отбрасывает, оставляя один.

3. Длина – поле с длиной всего EAP-пакета.

4. Тип – поле, описывающее тип запроса или ответа. Обычно тип ответа такой же, как и тип запроса, но у ответа есть один тип Nak – который говорит, что клиенту не подходит тип запроса от аутентификатора.

Теперь стоит рассмотреть каждый из пакетов более подробно.

Назначение пакетов, сигнализирующих об успешной или неуспешной аутентификации, интуитивно понятно, поэтому стоит более детально рассмотреть пакеты с запросом и ответом. И более подробно следует остановиться на различных типах пакетов (определяемых полем «тип»). Поле «тип» имеет длину 8 бит. Первые четыре типа зарезервированы стандартом RFC 3748 как особые:

0 – reserved;

1 – identity;

2 – notification;

3 – Nak(reponse only).

Помимо этих типов, стандарт обязывает все реализации EAP протокола поддерживать ещё тип 4 – MD5-Challenge. Поддержка остальных типов опциональна. Однако очень широкое применение имеют также типы 5 – OTP (One-Time Password) и 6 – GTC (Generic Token Card). Типы с 9 по 45 уже определены, с 46 по 191 – свободны, с 192 по 253 – зарезервированы для дальнейшей стандартизации, 254 – Expanded type, 255 – экспериментальный тип. Типы с номерами 7 и 8 не определены.

Теперь рассмотрим более подробно каждый из основных типов.

Тип Identity.

Запрос с таким типом аутентификатором посылается в самую первую очередь во время процедуры аутентификации. Запрос служит для идентификации клиента и начала фазы аутентификации. В основном этот тип пакетов используется для определения, какой метод EAP использовать. Ответом на запрос с типом 1, должен быть пакет только с типом 1.

Тип Notification

Данный тип запросов применяется для передачи отображаемого сообщения от аутентификатора клиенту. Клиент может отображать сообщение пользователю, а может вести лог сообщений, если его нельзя по каким-либо причинам отобразить. Запросы с таким типом могут отсылаться в любое время процедуры аутентификации, ответом на такой пакет могут служить пакеты с таким же типом, ответы с типом Nak запрещены. Очень часто пакеты с таким типом не требуются, и в реализации можно запретить такие пакеты, тогда клиент будет просто удалять их.

Тип Nak

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

клиента. В ответе может быть 0, это говорит о том, что клиент не поддерживает другие типы аутентификации. После получения ответа типа Nak с кодом 0, аутентификатору следует прекратить слать пакеты с запросами на тип аутентификации. Данный тип Nak ответа называется legacy Nak(с кодом равным 3), помимо него существует также expanded Nak, он также используется только в ответах. Ответ с таким типом отсылается только на запросы с кодом 254 (expanded type), сам ответ с типом expanded Nak имеет также код 254. Предназначение у него такое же, как и у legacy Nak.

Тип MD5-Challenge

Когда передаются пакеты с таким типом, то это означает что периодически во время сессии проходит подтверждение идентичности клиента посредством «троекратного рукопожатия» (3-way handshake). Первое «рукопожатие» происходит сразу после установления связи.

1. Аутентификатор отправляет клиенту запрос содержащее «сообщение-вопрос»(challenge-message);

2. Клиент отвечает на этот запрос ответом либо с кодом 4, где в ответе содержится хэш-функция от определённой комбинации «сообщения-запроса» и секретного пароля (хэширование происходит по алгоритму MD-5), либо с кодом 3(Nak), где в ответе описан желаемый способ аутентификации. В этом случае обмен пакетами с типом 4 прекращается.

3. В противном случае при получении ответа с типом 4, аутентификатор проверяет полученный ответ и сверяет присланную хэш-функцию со своей, которую он посчитал сам (секретный пароль также хранится и на сервере аутентификации). Если хэш-функции разные то, аутентификатор прекращает сеанс связи, в противном случае сессия продолжается.

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

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

Тип OTP (One-Time Password)

Данный тип пакетов используется для обеспечения аутентификации на основе последовательности «одноразовых паролей» (one-time password). Суть этого метода заключается в следующем. Аутентификатор и клиент имеют «секретный ключ» (или секретный пароль). В самом начале процедуры аутентификации аутентификатор отсылает клиенту «начальное сообщение» (seed). Это «начальное сообщение» каким-то образом соединяется с секретным паролем и преобразуется неким образом (алгоритмы разные). После этого результат этих преобразований, назовём его S, прогоняется N раз через хэш-функцию у клиента и аутентификатора. Таким образом, получается последовательность из N одноразовых паролей. Первый раз посылается N раз прохэшированное S, и аутентификатор сверяет свой и присланный результаты. Затем, когда аутентификатор присылает очередной запрос на подтверждение аутентификации, пусть в i-ый раз, в качестве пароля используется (N-i) раз прохэшированное S. При достижении N единицы, аутентификатор вновь инициирует передачу «начального сообщения» и далее всё повторяется по циклу. Основным преимуществом данного метода является то, что аутентификация повторяется во время сеанса связи, но пароль не передаётся по сети, а иницируется передача лишь последовательности одноразовых паролей. Безопасноть данного метода в основном определяется устойчивостью к коллизиям выбранного алгоритма хэширования.

Дата добавления: 2014-01-14