СПОСОБ АУТЕНТИФИКАЦИИ ДОСТУПА, ПРИМЕНЯЕМЫЙ К IBSS-СЕТИ
METHOD OF ACCESS AUTHENTICATION APPLIED TO IBSS-NETWORK

Настоящая заявка претендует на привилегии заявки на патент Китая № 200710018976.1, поданной в Патентное ведомство Китая 30 октября 2007 г. и озаглавленной «An access authentication method applying to IBSS network», которая таким образом включена в материалы настоящей заявки во всей своей полноте.
Область техники, к которой относится изобретение
Настоящее изобретение относится к способу аутентификации доступа, применяемому к IBSS-сети.
Уровень техники
Чтобы принять меры в отношении бреши в защите, представленной в механизме защиты эквивалента конфиденциальности проводной сети (WEP), определенном в международном стандарте ISO/IEC (Международной организации стандартизации/Международной электротехнической комиссии) 8802-11 беспроводной локальной сети (WLAN), в Китае был опубликован национальный стандарт WLAN и его первая версия для принятия инфраструктуры аутентификации и обеспечения конфиденциальности WLAN (WAPI) вместо WEP для принятия мер по решению проблем защиты WLAN. Почти одновременно организация Института инженеров по электротехнике и радиоэлектронике (IEEE) также опубликовала стандарт IEEE 802.11i, в котором было предложено надежно защищенное сетевое соединение (RSNA), основанное на обратной совместимости, для исправления бреши в защите, представленной в WEP.
WAPI использует протоколы аутентификации и управления ключами сертификатов открытого ключа или предварительно совместно используемого ключа, и RSNA выполняет функции аутентификации и распределения ключей соответственно, согласно IEEE 802.1x, основываясь на расширяемом протоколе аутентификации (EAP) и четырехэтапном протоколе передачи данных. WAPI может обеспечивать защиту WLAN, и RSNA также частично решает вопрос защиты, представленный в исходном механизме защиты WLAN, но имеет следующие недостатки:
1. Работа в режиме IBSS-сети вызывает слишком сложное исполнение протоколов, кроме того, ресурсы узлов (источник питания, центральный процессор (CPU), возможности запоминающего устройства и т.д.) по сети в таком режиме обычно ограничены;
2. Не выполняются меры защиты первых сообщений протокола согласования одноадресного ключа WAPI и четырехэтапного протокола передачи данных RSNA, и злоумышленник может выполнить атаку на отказ в обслуживании (DoS), например блокирование протокола, исчерпание запоминающего устройства и т.д., посредством подделки сообщения 1.
Эти два недостатка подробно анализируются и описываются ниже.
Для удобства описания сначала совместно определим функционально подобные или идентичные термины в WAPI и RSNA следующим образом:
1. Запросчик (S). Объект запросчика аутентификации (ASUE) в WAPI и запросчик в RSNA совместно упоминаются как запросчик.
2. Аутентификатор (А). Объект аутентификатора (AE) в WAPI и аутентификатор в RSNA совместно упоминаются как аутентификатор.
3. Сервер аутентификации (AS). Объект службы аутентификации (ASE) в WAPI и сервер аутентификации (AS) в RSNA совместно упоминаются как сервер аутентификации.
4. Главный ключ (MK). Базовый ключ (BK) протокола WAPI и парный главный ключ (PMK) протокола RSNA совместно упоминаются как главный ключ.
5. Одноадресный ключ (UK). Ключ одноадресного сеанса (USK) протокола WAPI и парный временный ключ (PTK) протокола RSNA совместно упоминаются как одноадресный ключ.
6. Групповой ключ (GK). Многоадресный главный ключ (MMK) протокола WAPI и групповой главный ключ (GMK) протокола RSNA совместно упоминаются как групповой ключ.
Два сетевых режима, т.е. базовый набор услуг (BSS) и независимый BSS (IBSS), обеспечиваются для WLAN. В режиме BSS аутентификатор А располагается на беспроводной точке доступа (AP), и запросчик S располагается на пользовательском терминале, и, после того как будет выполнена функция аутентификации посредством сервера аутентификации AS, выполняются согласование одноадресного ключа между аутентификатором А и запросчиком S и объявление группового (включая многоадресный и широковещательный) ключа аутентификатора А. В режиме IBSS соответствующие пользователи терминалов, присоединяющиеся к сети, представляют собой одноранговые узлы, и соответствующим станциям также необходимо передавать их собственные многоадресные/широковещательные данные в дополнение к одноадресным данным между каждыми двумя из них, т.е. соответствующие станции действуют в качестве аутентификатора А и выполняют объявление группового ключа с другими станциями, действующими в качестве запросчика S соответственно.
Один и тот же сетевой элемент, действующий в качестве как аутентификатора А, так и запросчика S, может вызвать атаку на отражение протокола управления ключами, и с учетом этого такая атака может предотвращаться таким образом, что один и тот же объект действует в качестве двух ролей аутентификации, основываясь на разных предварительно совместно используемых ключах, т.е. протокол управления ключами, исполняемый одним и тем же объектом, действующим в качестве аутентификатора А и запросчика S, будет зависеть от разных главных ключей MK и одноадресных ключей UK. Поэтому в режиме IBSS соответствующие сайты будут действовать в качестве аутентификатора А для исполнения полных протоколов аутентификации и управления ключами с другими соответствующими сайтами.
Как показано на фиг.1, полные протоколы аутентификации и управления ключами должны исполняться N(N-1) раз для IBSS-сети с N узлами, и такие очень сложные вычисления могут сделать эти протоколы трудными для применения на практике, когда узел часто перемещается, или существуют ограниченные ресурсы.
Не только протоколы сложно выполняются в режиме IBSS, но также протокол управления ключами подвержен DoS-атаке. Протокол согласования одноадресного ключа WAPI и четырехэтапный протокол передачи данных RSNA представляют собой очень важные компоненты в механизме защиты для целей верификации, имеется ли главный ключ MK между аутентификатором А и запросчиком S, являющийся результатом успешной аутентификации и согласования и извлечения нового одноадресного ключа UK для использования в последующей передаче данных. В протоколе согласования одноадресного ключа WAPI и четырехэтапном протоколе передачи данных RSNA любое другое сообщение, кроме сообщения 1, аутентифицируется и защищается посредством UK, являющегося результатом самого последнего согласования, и только одно сообщение 1 может использоваться злоумышленником. Злоумышленник может подделать сообщение 1, так что UK, являющийся результатом согласования между аутентификатором А и запросчиком S, не является совместимым, тем самым вызывая блокирование протокола, или злоумышленник может подделать большое количество сообщений 1, тем самым осуществляя DoS-атаку, например исчерпание запоминающего устройства, и т.д. на запросчике S. Такую атаку с подделкой легко реализовать с серьезным риском, и одна успешная атака может нейтрализовать различные предыдущие усилия по аутентификации.
Сущность изобретения
Чтобы принять меры в отношении вышеизложенной технической проблемы, представленной в известном уровне техники, варианты осуществления изобретения обеспечивают способ аутентификации доступа, применимый к IBSS-сети, для гарантирования улучшенной защиты и эффективности исполнения аутентификации доступа IBSS-сети.
Техническим решением изобретения является способ аутентификации доступа, применимый к IBSS-сети, в котором способ включает в себя:
этап 1): конфигурирование ролей аутентификации сетевых объектов;
этап 2): аутентификацию аутентификатора и запросчика после конфигурирования ролей аутентификации в соответствии с протоколом аутентификации; и
этап 3): выполнение согласования ключа между аутентификатором и запросчиком после завершения аутентификации, причем поля контроля целостности сообщений и захвата синхронизации протокола добавляются в сообщение согласования ключа.
Предпочтительно, что конфигурирование ролей включает в себя статическое, адаптивное или динамическое конфигурирование.
Предпочтительно, что статическое конфигурирование включает в себя конфигурирование одного из пары сетевых объектов в качестве аутентификатора и другого одного в качестве запросчика.
Предпочтительно, что адаптивное конфигурирование включает в себя: если один из пары сетевых объектов определяет, что противоположный сетевой объект является аутентификатором, адаптивное конфигурирование сетевого объекта в качестве запросчика, или, если один из пары сетевых объектов определяет, что противоположный сетевой объект является запросчиком, адаптивное конфигурирование сетевого объекта в качестве аутентификатора.
Предпочтительно, что динамическое конфигурирование включает в себя: конфигурирование сетевых объектов в соответствии с приоритетом или физическим адресом.
Предпочтительно, что конфигурирование сетевых объектов в соответствии с приоритетом включает в себя: конфигурирование одного из пары сетевых объектов, который имеет высокий приоритет, в качестве аутентификатора и другого одного в качестве запросчика.
A
S
S
S
S
A
S
S
S
A
A
A
A
A
Предпочтительно, что выполнение согласования ключа между аутентификатором и запросчиком включает в себя: передачу аутентификатором на запросчик пакета запроса согласования ключа, причем пакет запроса согласования ключа включает в себя идентификатор согласования ключа KNID, одноразовое случайное число Nonce, генерируемое аутентификатором, и контроль целостности сообщений MIC1, где MIC1 представляет собой хэш-значение, вычисленное на других чем MIC1 полях в пакете запроса согласования ключа аутентификатором, используя главный ключ MK, являющийся результатом процесса аутентификации между аутентификатором и запросчиком; верификацию запросчиком при приеме пакета запроса согласования ключа, пакета запроса согласования ключа, и, если верификация прошла успешно, ответ запросчику пакетом ответа согласования ключа; в противном случае, отбрасывание пакета запроса согласования ключа. Где пакет ответа согласования ключа включает в себя идентификатор согласования ключа KNID, одноразовое случайное число Nonce, генерируемого запросчиком, информацию о групповом ключе E(UK,GK) запросчика и контроль целостности сообщений MIC2, где E(UK,GK) представляет информацию, являющуюся результатом шифрования группового ключа GK запросчика, используя одноадресный ключ UK, причем UK представляет собой значение, вычисленное из MK, Nonce и Nonce, и MIC2 представляет собой хэш-значение, вычисленное на других чем MIC2 полях в пакете ответа согласования ключа запросчиком, используя UK, являющийся результатом согласования; верификацию аутентификатором, при приеме пакета ответа согласования ключа, пакета ответа согласования ключа, и, если верификация прошла успешно, расшифрование поля E(UK,GK), получение GK и ответ запросчику пакетом подтверждения согласования ключа; в противном случае, отбрасывание пакета ответа согласования ключа. Где пакет подтверждения согласования ключа включает в себя идентификатор согласования ключа KNID, информацию о групповом ключе E(UK,GK) аутентификатора и контроль целостности сообщений MIC3, где E(UK,GK) представляет информацию, являющуюся результатом шифрования группового ключа GK аутентификатора, используя одноадресный ключ UK, и MIC3 представляет собой хэш-значение, вычисленное на других чем MIC3 полях в пакете подтверждения согласования ключа аутентификатором, используя UK; и верификацию запросчиком, при приеме пакета подтверждения согласования ключа, пакета подтверждения согласования ключа, и, если верификация прошла успешно, расшифрование поля E(UK,GK) и получение GK; в противном случае, отбрасывание пакета подтверждения согласования ключа.
Предпочтительно, что верификация пакета запроса согласования ключа во время процесса согласования исходного ключа включает в себя: верификацию, является ли корректным MIC1 в пакете запроса согласования ключа, и, если да, успешное выполнение верификации; в противном случае, неуспешное выполнение верификации.
Предпочтительно, что верификация пакета запроса согласования ключа во время процесса обновления ключа включает в себя: верификацию, являются ли корректными KNID и MIC1 в пакете запроса согласования ключа, и, если да, успешное выполнение верификации; в противном случае, неуспешное выполнение верификации.
Предпочтительно, что верификация пакета ответа согласования ключа включает в себя: верификацию, являются ли корректными KNID и MIC2 в пакете ответа согласования ключа, и, если да, успешное выполнение верификации; в противном случае, неуспешное выполнение верификации.
Предпочтительно, что верификация пакета подтверждения согласования ключа включает в себя: верификацию, являются ли корректными KNID и MIC3 в пакете подтверждения согласования ключа, и, если да, успешное выполнение верификации; в противном случае, неуспешное выполнение верификации.
Предпочтительно, что протокол аутентификации включает в себя протокол аутентификации WAPI или протокол IEEE 802.1x в RSNA.
Изобретение имеет следующие преимущества:
1. Очень эффективное исполнение. Чтобы уменьшить сложность исполнения протоколов в режиме IBSS, изобретение предлагает способ конфигурирования ролей сетевых объектов, т.е. статическое конфигурирование ролей соответствующей станции или адаптивное или динамическое конфигурирование ролей соответствующей станции в соответствии с рабочим состоянием сети. После того как будет принята адаптивная политика роли для сетевых объектов, соответствующие одни из пары станций, выполняющие функции аутентификации и управления ключами, играют относительно определенную роль или аутентификатора, или запросчика, т.е. весь процесс протоколов исполняется только один раз между парой станций, таким образом выполняя двунаправленную аутентификацию идентичности и распределение ключей, как требуется. Для сети с N узлами функция аутентификации выполняется между каждыми двумя станциями, таким образом уменьшая на половину количество раз, когда исполняются протоколы, как N(N-1).
2. Улучшенная защита. С учетом проблемы DoS-атаки, представленной в протоколе управления ключами, изобретение улучшает структуру протоколов принятием модульного и объединяемого способа и добавляет поля контроля целостности сообщений и захвата синхронизации протокола в сообщении, таким образом улучшая защиту и надежность протоколов и принимая меры в отношении проблемы DoS-атаки, представленной в протоколе управления ключами в существующем механизме защиты WAPI и RSNA беспроводной локальной сети.
Краткое описание чертежей
Фиг.1 представляет собой схематическое представление исполнения протокола по IBSS-сети, состоящей из трех сайтов u1, u2 и u3 в известном уровне техники; и
фиг.2 представляет собой схематическое представление исполнения протокола аутентификации доступа по IBSS-сети, состоящей из трех сайтов u1, u2 и u3 согласно изобретению.
Подробное описание изобретения
Чтобы сделать вышеприведенную задачу, признаки и преимущества изобретения более очевидными, варианты осуществления изобретения ниже подробно описываются со ссылкой на чертежи.
Изобретение конфигурирует роли сетевых объектов для уменьшения сложности исполнения протоколов WAPI и RSNA в режиме IBSS и с учетом проблемы DoS-атаки, представленной в протоколе управления ключами, изобретение улучшает структуру протоколов посредством принятия модульного и объединяемого способа. Улучшенные протоколы состоят из двух частей: первая часть представляет собой исходный протокол аутентификации WAPI или основанный на EAP протокол IEEE 802.1x для выполнения аутентификации идентичности и согласования главного ключа MK между аутентификатором А и запросчиком S, и вторая часть представляет собой вновь разработанный протокол управления ключами вместо протокола управления ключами WAPI или четырехэтапного протокола передачи данных RSNA для выполнения согласования одноадресного ключа UK и объявление группового ключа GK. Улучшенный протокол, основанный на протоколе WAPI, упоминается как WAPI', и улучшенный протокол, основанный на протоколе RSNA, упоминается как RSNA'.
Конкретная последовательность операций способа аутентификации доступа следующая:
1) Конфигурируются роли аутентификации сетевых объектов.
Конфигурирование ролей может быть статическим, адаптивным или динамическим конфигурированием.
В случае статического конфигурирования конфигурирование включает в себя конфигурирование одного из пары сетевых объектов в качестве аутентификатора А и другого одного в качестве запросчика S.
В случае адаптивного конфигурирования конфигурирование включает в себя адаптирование роли аутентификации объекта, принимающего политику адаптивного конфигурирования роли противоположного объекта, так что объект конфигурируется адаптивно в качестве запросчика S, если противоположным объектом является аутентификатор А, или в качестве аутентификатора А, если противоположным объектом является запросчик S.
В случае динамического конфигурирования конфигурирование включает в себя конфигурирование в соответствии с приоритетом и физическим адресом, т.е. объект с высоким приоритетом конфигурируется в качестве аутентификатора А, и другой объект конфигурируется в качестве запросчика S; если приоритеты двух объектов идентичные, один из объектов с большим физическим адресом конфигурируется в качестве аутентификатора А, и другой объект с меньшим физическим адресом конфигурируется в качестве запросчика S. Изобретение может альтернативно принимать другие политики динамического конфигурирования.
2) Аутентификатор А и запросчик S после конфигурирования ролей аутентифицируются в соответствии с протоколом аутентификации.
Протокол аутентификации ссылается на протокол аутентификации WAPI или протокол IEEE 802.1x RSNA.
3) Аутентификатор А и запросчик S выполняют согласование ключа после исполнения протокола аутентификации, причем в сообщение согласования ключа добавляются поля контроля целостности сообщений и захвата синхронизации протокола. Конкретные этапы согласования ключа следующие:
A
3.1) После успешной аутентификации объекта аутентификатор А передает на запросчик S пакет запроса согласования ключа, включающий в себя идентификатор согласования ключа KNID, Nonce, генерируемый аутентификатором А, и контроль целостности сообщений MIC1, где MIC1 представляет собой хэш-значение, вычисленное по другим чем MIC1 полям в пакете запроса согласования ключа аутентификатором А, используя главный ключ MK, являющийся результатом процесса аутентификации.
S
S
A
S
S
S
3.2) При приеме пакета запроса согласования ключа запросчик S верифицирует пакет запроса согласования ключа в отношении корректности в нем MIC1, и, если MIC1 не является корректным, запросчик S немедленно отбрасывает пакет запроса согласования ключа; в противном случае запросчик S отвечает аутентификатору А пакетом ответа согласования ключа, включающим в себя идентификатор согласования ключа KNID, одноразовое случайное число Nonce, генерируемое запросчиком S, информацию о групповом ключе E(UK,GK) на запросчике S и контроль целостности сообщений MIC2, где MIC2 представляет собой хэш-значение, вычисленное на других чем MIC2 полях в пакете ответа согласования ключа запросчиком S, используя UK, при этом UK представляет собой значение, вычисленное из MK, Nonce и Nonce, и E(UK,GK) представляет информацию, являющуюся результатом шифрования группового ключа GK запросчика S, используя одноадресный ключ UK.
A
S
S
S
A
A
A
3.3) При приеме пакета ответа согласования ключа аутентификатор А верифицирует пакет ответа согласования ключа в отношении корректности в нем идентификатора согласования ключа KNID, и если KNID не является корректным, аутентификатор А немедленно отбрасывает пакет ответа согласования ключа; в противном случае аутентификатор А вычисляет UK из MK, Nonce и Nonce и верифицирует MIC2 в отношении корректности посредством UK, и, если MIC2 не является корректным, аутентификатор А немедленно отбрасывает пакет ответа согласования ключа; в противном случае аутентификатор А расшифровывает поле E(UK,GK) и получает GK, и отвечает запросчику S пакетом подтверждения согласования ключа, включающим в себя идентификатор согласования ключа KNID, информацию о групповом ключе E(UK,GK) аутентификатора А и контроль целостности сообщений MIC3, где E(UK,GK) представляет информацию, являющуюся результатом шифрования группового ключа GK аутентификатора А, используя одноадресный ключ UK, и MIC3 представляет собой хэш-значение, вычисленное на других чем MIC3 полях в пакете подтверждения согласования ключа аутентификатором А, используя UK.
A
A
3.4) При приеме пакета подтверждения согласования ключа запросчик S верифицирует пакет подтверждения согласования ключа и верифицирует в нем идентификатор согласования ключа KNID и MIC3 в отношении корректности, и если они не являются корректными, запросчик S немедленно отбрасывает пакет; в противном случае запросчик S расшифровывает поле E(UK,GK) и получает GK.
A
S
A
S
Необходимо отметить, что идентификатор согласования ключа KNID функционирует в качестве захвата синхронизации протокола в протоколе согласования ключа. KNID в протоколе согласования исходного ключа при успешной аутентификации представляет собой случайное число, генерируемое аутентификатором А, и KNID в процессах обновления ключа представляют собой значения, вычисленные соответственно аутентификатором А и запросчиком S локально из UK, Nonce, Nonce, GK и GK, после успешного выполнения последнего протокола согласования ключа. Поэтому во время процесса обновления ключа верификация пакета запроса согласования ключа запросчиком S должна дополнительно включать в себя верификацию KNID. Такая структура KNID позволяет аутентификатору А и запросчику S выполнять функцию синхронизации и предотвращать подделку и повторную передачу злоумышленником пакета запроса согласования ключа.
Фиг.2 представляет собой схематическое представление исполнения улучшенного протокола по IBSS-сети, состоящей из трех сайтов. Предполагается, что каждый из трех сайтов принимает адаптивное конфигурирование роли аутентификации, и трем сайтам присвоены одинаковые приоритеты и им назначены соответствующие адреса управления доступом к среде (MAC-адреса) 00:90:4b:00:90:01, 00:90:4b:00:90:02 и 00:90:4b:00:90:03, так что аутентификация между тремя сайтами может выполняться посредством выполнения аутентификации три раза, используя МАС-адреса трех сайтов согласно изобретению.