способ аутентификации доступа, применяемый к ibss-сети

Формула изобретения

1. Способ аутентификации доступа, применимый к IBSS-сети, содержащий:

этап 1): конфигурирование ролей аутентификации сетевых объектов;

этап 2): аутентификацию аутентификатора и запросчика после конфигурирования роли аутентификации в соответствии с протоколом аутентификации; и

этап 3): выполнение согласования ключа между аутентификатором и запросчиком после завершения аутентификации, причем поля контроля целостности сообщений и захвата синхронизации протокола добавляются в сообщение согласования ключа;

причем выполнение согласования ключа между аутентификатором и запросчиком содержит:

передачу аутентификатором на запросчик пакета запроса согласования ключа, причем пакет запроса согласования ключа содержит идентификатор согласования ключа KNID, одноразовое случайное число Nonce_A, генерируемое аутентификатором, и контроль целостности сообщений MIC1, причем MIC1 представляет собой хэш-значение, вычисленное на других, чем MIC1, полях в пакете запроса согласования ключа аутентификатором, используя главный ключ МK, являющийся результатом согласования;

верификацию запросчиком, при приеме пакета запроса согласования ключа, пакета запроса согласования ключа и, если верификация прошла успешно, ответ запросчику пакетом ответа согласования ключа; в противном случае, отбрасывание пакета запроса согласования ключа, причем пакет ответа согласования ключа содержит идентификатор согласования ключа KNID, одноразовое случайное число Nonce _s, генерируемое запросчиком, информацию о групповом ключе E(UK,GK_S) запросчика и контроль целостности сообщений MIC2, где E(UK,GK_S) представляет информацию, являющуюся результатом шифрования группового ключа GK_S запросчика, используя одноадресный ключ UK, при этом UK представляет собой значение, вычисленное из МК, Nonce_A и Nonce_s , и MIC2 представляет собой хэш-значение, вычисленное на других, чем MIC2, полях в пакете ответа согласования ключа запросчиком, используя UK;

верификацию аутентификатором, при приеме пакета ответа согласования ключа, пакета ответа согласования ключа и, если верификация прошла успешно, расшифрование поля E(UK,GK_S), получение GK_S и ответ запросчику пакетом подтверждения согласования ключа; в противном случае, отбрасывание пакета ответа согласования ключа, причем пакет подтверждения согласования ключа содержит идентификатор согласования ключа KNID, информацию о групповом ключе Е(UK,GK_A) аутентификатора и контроль целостности сообщений MIC3, где Е(UK,GK_A ) представляет информацию, являющуюся результатом шифрования группового ключа GK_A аутентификатора, используя одноадресный ключ UK, и MIC3 представляет собой хэш-значение, вычисленное на других, чем MIC3, полях в пакете подтверждения согласования ключа аутентификатором, используя UK; и

верификацию запросчиком, при приеме пакета подтверждения согласования ключа, пакета подтверждения согласования ключа и, если верификация прошла успешно, расшифрование поля Е(UK,GK_A) и получение GK_A; в противном случае отбрасывание пакета подтверждения согласования ключа.

2. Способ по п.1, в котором конфигурирование ролей содержит статическое, адаптивное или динамическое конфигурирование.

3. Способ по п.2, в котором статическое конфигурирование содержит:

конфигурирование одного из пары сетевых объектов в качестве аутентификатора и другого одного в качестве запросчика.

4. Способ по п.2, в котором адаптивное конфигурирование содержит:

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

5. Способ по п.2, в котором динамическое конфигурирование содержит:

конфигурирование сетевых объектов в соответствии с приоритетом или физическим адресом.

6. Способ по п.5, в котором конфигурирование сетевых объектов в соответствии с приоритетом содержит:

конфигурирование одного из пары сетевых объектов, который имеет высокий приоритет, в качестве аутентификатора, а другого одного - в качестве запросчика.

7. Способ по п.5, в котором конфигурирование сетевых объектов в соответствии с физическим адресом содержит:

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

8. Способ по п.1, в котором верификация пакета запроса согласования ключа во время процесса согласования исходного ключа содержит:

верификацию того, является ли корректным MIC1 в пакете запроса согласования ключа, и, если да, успешное выполнение верификации; в противном случае неуспешное выполнение верификации.

9. Способ по п.1, в котором верификация пакета запроса согласования ключа во время процесса обновления ключа содержит:

верификацию того, являются ли корректными KNID и MIC1 в пакете запроса согласования ключа, и, если да, успешное выполнение верификации; в противном случае неуспешное выполнение верификации.

10. Способ по п.1, в котором верификация пакета ответа согласования ключа содержит:

верификацию того, являются ли корректными KNID и MIC2 в пакете ответа согласования ключа, и, если да, успешное выполнение верификации; в противном случае неуспешное выполнение верификации.

11. Способ по п.1, в котором верификация пакета подтверждения согласования ключа содержит:

верификацию того, являются ли корректными KNID и MIC3 в пакете подтверждения согласования ключа, и, если да, успешное выполнение верификации; в противном случае неуспешное выполнение верификации.

12. Способ по любому одному из пп.1-11, в котором протокол аутентификации содержит протокол аутентификации WAPI или протокол IEEE 802.1x RSNA.

Описание изобретения к патенту

Настоящая заявка претендует на привилегии заявки на патент Китая № 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): выполнение согласования ключа между аутентификатором и запросчиком после завершения аутентификации, причем поля контроля целостности сообщений и захвата синхронизации протокола добавляются в сообщение согласования ключа.

Предпочтительно, что конфигурирование ролей включает в себя статическое, адаптивное или динамическое конфигурирование.

Предпочтительно, что статическое конфигурирование включает в себя конфигурирование одного из пары сетевых объектов в качестве аутентификатора и другого одного в качестве запросчика.

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

Предпочтительно, что динамическое конфигурирование включает в себя: конфигурирование сетевых объектов в соответствии с приоритетом или физическим адресом.

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

Предпочтительно, что выполнение согласования ключа между аутентификатором и запросчиком включает в себя: передачу аутентификатором на запросчик пакета запроса согласования ключа, причем пакет запроса согласования ключа включает в себя идентификатор согласования ключа KNID, одноразовое случайное число Nonce_A, генерируемое аутентификатором, и контроль целостности сообщений MIC1, где MIC1 представляет собой хэш-значение, вычисленное на других чем MIC1 полях в пакете запроса согласования ключа аутентификатором, используя главный ключ MK, являющийся результатом процесса аутентификации между аутентификатором и запросчиком; верификацию запросчиком при приеме пакета запроса согласования ключа, пакета запроса согласования ключа, и, если верификация прошла успешно, ответ запросчику пакетом ответа согласования ключа; в противном случае, отбрасывание пакета запроса согласования ключа. Где пакет ответа согласования ключа включает в себя идентификатор согласования ключа KNID, одноразовое случайное число Nonce _S, генерируемого запросчиком, информацию о групповом ключе E(UK,GK_S) запросчика и контроль целостности сообщений MIC2, где E(UK,GK_S) представляет информацию, являющуюся результатом шифрования группового ключа GK_S запросчика, используя одноадресный ключ UK, причем UK представляет собой значение, вычисленное из MK, Nonce_A и Nonce_S , и MIC2 представляет собой хэш-значение, вычисленное на других чем MIC2 полях в пакете ответа согласования ключа запросчиком, используя UK, являющийся результатом согласования; верификацию аутентификатором, при приеме пакета ответа согласования ключа, пакета ответа согласования ключа, и, если верификация прошла успешно, расшифрование поля E(UK,GK_S), получение GK _S и ответ запросчику пакетом подтверждения согласования ключа; в противном случае, отбрасывание пакета ответа согласования ключа. Где пакет подтверждения согласования ключа включает в себя идентификатор согласования ключа KNID, информацию о групповом ключе E(UK,GK_A) аутентификатора и контроль целостности сообщений MIC3, где E(UK,GK_A) представляет информацию, являющуюся результатом шифрования группового ключа GK_A аутентификатора, используя одноадресный ключ UK, и MIC3 представляет собой хэш-значение, вычисленное на других чем MIC3 полях в пакете подтверждения согласования ключа аутентификатором, используя UK; и верификацию запросчиком, при приеме пакета подтверждения согласования ключа, пакета подтверждения согласования ключа, и, если верификация прошла успешно, расшифрование поля E(UK,GK _A) и получение GK_A; в противном случае, отбрасывание пакета подтверждения согласования ключа.

Предпочтительно, что верификация пакета запроса согласования ключа во время процесса согласования исходного ключа включает в себя: верификацию, является ли корректным 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 выполняют согласование ключа после исполнения протокола аутентификации, причем в сообщение согласования ключа добавляются поля контроля целостности сообщений и захвата синхронизации протокола. Конкретные этапы согласования ключа следующие:

3.1) После успешной аутентификации объекта аутентификатор А передает на запросчик S пакет запроса согласования ключа, включающий в себя идентификатор согласования ключа KNID, Nonce_A , генерируемый аутентификатором А, и контроль целостности сообщений MIC1, где MIC1 представляет собой хэш-значение, вычисленное по другим чем MIC1 полям в пакете запроса согласования ключа аутентификатором А, используя главный ключ MK, являющийся результатом процесса аутентификации.

3.2) При приеме пакета запроса согласования ключа запросчик S верифицирует пакет запроса согласования ключа в отношении корректности в нем MIC1, и, если MIC1 не является корректным, запросчик S немедленно отбрасывает пакет запроса согласования ключа; в противном случае запросчик S отвечает аутентификатору А пакетом ответа согласования ключа, включающим в себя идентификатор согласования ключа KNID, одноразовое случайное число Nonce _S, генерируемое запросчиком S, информацию о групповом ключе E(UK,GK_S) на запросчике S и контроль целостности сообщений MIC2, где MIC2 представляет собой хэш-значение, вычисленное на других чем MIC2 полях в пакете ответа согласования ключа запросчиком S, используя UK, при этом UK представляет собой значение, вычисленное из MK, Nonce_A и Nonce_S, и E(UK,GK_S ) представляет информацию, являющуюся результатом шифрования группового ключа GK_S запросчика S, используя одноадресный ключ UK.

3.3) При приеме пакета ответа согласования ключа аутентификатор А верифицирует пакет ответа согласования ключа в отношении корректности в нем идентификатора согласования ключа KNID, и если KNID не является корректным, аутентификатор А немедленно отбрасывает пакет ответа согласования ключа; в противном случае аутентификатор А вычисляет UK из MK, Nonce_A и Nonce_S и верифицирует MIC2 в отношении корректности посредством UK, и, если MIC2 не является корректным, аутентификатор А немедленно отбрасывает пакет ответа согласования ключа; в противном случае аутентификатор А расшифровывает поле E(UK,GK_S ) и получает GK_S, и отвечает запросчику S пакетом подтверждения согласования ключа, включающим в себя идентификатор согласования ключа KNID, информацию о групповом ключе E(UK,GK _A) аутентификатора А и контроль целостности сообщений MIC3, где E(UK,GK_A) представляет информацию, являющуюся результатом шифрования группового ключа GK_A аутентификатора А, используя одноадресный ключ UK, и MIC3 представляет собой хэш-значение, вычисленное на других чем MIC3 полях в пакете подтверждения согласования ключа аутентификатором А, используя UK.

3.4) При приеме пакета подтверждения согласования ключа запросчик S верифицирует пакет подтверждения согласования ключа и верифицирует в нем идентификатор согласования ключа KNID и MIC3 в отношении корректности, и если они не являются корректными, запросчик S немедленно отбрасывает пакет; в противном случае запросчик S расшифровывает поле E(UK,GK_A) и получает GK_A .

Необходимо отметить, что идентификатор согласования ключа KNID функционирует в качестве захвата синхронизации протокола в протоколе согласования ключа. KNID в протоколе согласования исходного ключа при успешной аутентификации представляет собой случайное число, генерируемое аутентификатором А, и KNID в процессах обновления ключа представляют собой значения, вычисленные соответственно аутентификатором А и запросчиком S локально из UK, Nonce _A, Nonce_S, GK_A и GK_S, после успешного выполнения последнего протокола согласования ключа. Поэтому во время процесса обновления ключа верификация пакета запроса согласования ключа запросчиком 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, так что аутентификация между тремя сайтами может выполняться посредством выполнения аутентификации три раза, используя МАС-адреса трех сайтов согласно изобретению.