СПОСОБЫ И УСТРОЙСТВО ДЛЯ ОБЕСПЕЧЕНИЯ ИЕРАРХИИ КЛЮЧЕЙ PMIP В СЕТИ БЕСПРОВОДНОЙ СВЯЗИ
METHODS AND DEVICE FOR PROVISION OF PMIP KEYS HIERARCHY IN WIRELESS COMMUNICATION NETWORK

ПРИТЯЗАНИЕ НА ПРИОРИТЕТ СОГЛАСНО 35 U.S.C. §119
Настоящая патентная заявка притязает на приоритет предварительной заявки США №60/941256 под названием “Methods and Apparatus for Providing Key Hierarchy and Computation in Wireless Communication Networks”, поданной 31 мая 2007 г., назначенной правообладателю настоящего изобретения и, таким образом, в явном виде включенной сюда в порядке ссылки.
ОБЛАСТЬ ТЕХНИКИ
По меньшей мере, один признак относится к системам связи и, в частности, к способу облегчения генерации и распространения секретных ключей proxy mobile IP (PMIP) в беспроводной сети.
УРОВЕНЬ ТЕХНИКИ
В ходе развития различных сетей беспроводной связи в рамках 3GPP2 один тип сетевой архитектуры известен как сеть ultra mobile broadband (UMB) и призван усовершенствовать стандарт мобильной телефонной связи CDMA2000 для приложений и требований следующего поколения. Сети пакетной передачи данных UMB базируются на технологиях сети интернет (TCP/IP), применимых к системе радиосвязи следующего поколения, призваны быть более эффективными и способными обеспечивать больше услуг, чем технологии, на смену которым они приходят. UMB предусматривает применение технологии четвертого поколения (4G) и использует нижележащую сеть TCP/IP с широкой полосой и низкой латентностью, имеющую услуги высокого уровня, например, речевые услуги, встроенные на верхнем уровне. Значительно более широкая полоса (по сравнению с предыдущими поколениями) и значительно более низкая латентность позволяют использовать различные типы приложений, которые прежде было невозможно использовать, в то же время продолжая доставлять речевые услуги высокого качества (или более высокого качества).
Сети UBM имеют менее централизованное управление своими узлами сетевого доступа, которые называются усовершенствованными базовыми станциями (eBS). Узлы доступа могут быть подключены к локальному или совмещенному сетевому контроллеру ссылок на сеанс (SRNC). Такие узлы доступа и/или SRNC могут осуществлять большинство функций базовой станции (BS) и контроллер базовых станций (BSC) в традиционной сети CDMA. Следовательно, вследствие дополнительных операций, осуществляемых ближе к беспроводному интерфейсу узлом доступа (eBS) и SRNC в архитектуре UMB, возникает ряд проблем, связанных с поддержанием безопасности узлов доступа и SRNC. Одна такая проблема заключается в поддержке и защите связи, когда терминал доступа переходит в другие сети из своей домашней сети.
Протокол Mobile IP (MIP) предписывает мобильному узлу (терминалу доступа) принимать пакеты, которые должны поступать на его домашний IP-адрес, даже когда мобильный узел (терминал доступа) не присутствует в своей домашней сети. Он предусматривает обмен сообщениями запроса регистрации (RRQ) и ответа регистрации (RRP) между мобильным узлом (терминалом доступа) и домашним агентом (HA). Затем HA принимает пакеты от имени мобильного узла и туннелирует пакеты в текущее положение мобильного узла (терминала доступа). Сообщения RRQ и RRP аутентифицируются с использованием ключа, совместно используемого мобильным узлом (терминалом доступа) и его домашним агентом.
В ряде случаев, когда мобильный узел (терминал доступа), подключающийся к сети, не имеет стека Mobile IP, но требует услуг мобильности, сети может понадобиться помощь посредника (именуемого Proxy Mobile Node, PMN) для генерации запросов регистрации и обработки ответов регистрации от имени мобильного узла (терминала доступа). Чтобы гарантировать поведение, согласующееся с Mobile IP, пакеты управления от PMN должны передаваться через текущую подсеть мобильного узла (терминала доступа). Поэтому пакеты управления MIP, генерируемые PMN, туннелируются через функцию помощника, которая располагается в текущей подсети мобильного узла (расположенного, например, в стороннем агенте или узле доступа). Таким образом, PMN (и ключ PMN-HA) может располагаться в единичном/безопасном положении, даже когда мобильный узел (терминал доступа) перемещается или переходит из одной подсети в другую.
Следовательно, необходим способ генерации и распространения ключей для туннелей PMIP в сети.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Предусмотрен первый способ, выполняемый на шлюзе доступа, содержащий этапы, на которых: (a) принимают запрос на изменение туннельной привязки Proxy Mobile Internet Protocol (PMIP) для терминала доступа от первого узла доступа ко второму узлу доступа; (b) генерируют ключ первого узла; (c) передают ключ первого узла на промежуточный узел сети, который может генерировать и выдавать первый ключ PMIP на второй узел доступа; и/или (d) устанавливают туннель PMIP между шлюзом и вторым узлом доступа, защищенный первым ключом PMIP. Способ может дополнительно содержать этапы, на которых(e) определяют, аутентифицирован ли терминал доступа через второй узел доступа; (f) генерируют и передают ключ первого узла только, если терминал доступа не аутентифицирован. При этом если терминал доступа аутентифицирован, способ дополнительно содержит этапы, на которых: (g) генерируют ключ второго узла; (h) генерируют второй ключ PMIP как функцию ключа второго узла и/или (i) передают второй ключ PMIP на второй узел доступа. Промежуточный узел сети является сетевым контроллером ссылок на сеанс (SRNC). Ключ первого узла и ключ второго узла могут быть произвольно выбранными и независимыми друг от друга, или они могут базироваться на корневом ключе.
Способ может дополнительно содержать этап, на котором поддерживают иерархию ключей PMIP, связанных с терминалом доступа (AT) и используемых для защиты туннелей PMIP к узлам сети, обслуживающим терминал доступа, причем иерархия ключей включает в себя ключ первого узла. Иерархия ключей PMIP может включать в себя произвольно выбранный корневой ключ, из которого выводится ключ первого узла. Корневой ключ для иерархии ключей PMIP может не быть известен терминалу доступа. Иерархия ключей PMIP может быть независимой от первичной иерархии ключей, известной терминалу доступа и используемой для аутентификации терминала доступа. Второй узел доступа может быть усовершенствованной базовой станцией (eBS), которая обеспечивает возможность беспроводной связи для терминала доступа. Шлюз действует в сети, совместимой с Ultra Mobile Broadband (UMB).
Предусмотрен второй способ, выполняемый на шлюзе доступа, содержащий этапы, на которых: (a) принимают запрос на изменение туннельной привязки Proxy Mobile Internet Protocol (PMIP) для терминала доступа от первого узла доступа ко второму узлу доступа; (b) генерируют ключ первого узла; (c) генерируют первый ключ PMIP как функцию ключа первого узла; (d) передают первый ключ PMIP на второй узел доступа и/или (e) устанавливают туннель PMIP между шлюзом и вторым узлом доступа, защищенный первым ключом PMIP. Способ может дополнительно содержать этапы, на которых: (f) определяют, аутентифицирован ли терминал доступа через второй узел доступа; и (g) генерируют и передают ключ первого узла, только если узел доступа аутентифицирован. При этом если терминал доступа не аутентифицирован, способ может дополнительно содержать этапы, на которых: (h) генерируют ключ второго узла и/или (i) передают ключ второго узла на промежуточный узел сети, который может генерировать и выдавать второй ключ PMIP на второй узел доступа. Промежуточный узел сети может быть сетевым контроллером ссылок на сеанс (SRNC). Второй узел доступа может быть усовершенствованной базовой станцией (eBS). Способ может дополнительно содержать этап, на котором поддерживают иерархию ключей PMIP, связанных с терминалом доступа (AT) и используемых для защиты туннелей PMIP к узлам сети, обслуживающим терминал доступа, причем иерархия ключей включает в себя ключ первого узла. При этом иерархия ключей PMIP включает в себя произвольно выбранный корневой ключ, из которого выводится ключ первого узла.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Различные признаки, природа и преимущества явствуют из подробного описания, приведенного ниже со ссылкой на чертежи, снабженные сквозной системой обозначений.
Фиг.1 - блок-схема сети UMB, в которой можно реализовать один или несколько признаков распространения секретных ключей PMIP согласно одному примеру.
Фиг.2 - схема вторичной иерархии ключей (PMIP), которая может поддерживаться на шлюзе для проверки запросов хэндовера согласно одному примеру.
Фиг.3 - блок-схема сети связи, в которой терминал доступа переводит услуги связи с первого узла доступа на второй узел доступа.
Фиг.4 - схема последовательности операций, демонстрирующая, как шлюз может генерировать и распространять ключи PMIP в среде, показанной на Фиг.3, в случае, когда терминал доступа аутентифицирован.
Фиг.5 - схема последовательности операций, демонстрирующая, как шлюз может генерировать и распространять ключи PMIP в среде, показанной на Фиг.3, в случае, когда терминал доступа AT аутентифицирован через первый узел доступа, но перемещается ко второму узлу доступа без аутентификации.
Фиг.6 - схема последовательности операций, демонстрирующая, как шлюз может генерировать и распространять ключи PMIP в среде, показанной на Фиг.3, в случае, когда терминал доступа переходит от неаутентифицированного соединения с узлом доступа к другому неаутентифицированному соединению со вторым узлом доступа без аутентификации.
Фиг.7 - способ, выполняемый на сетевом шлюзе для генерации ключей, используемых для защиты туннелей PMIP в сети связи.
Фиг.8 - способ, выполняемый на сетевом шлюзе для генерации и распространения ключей, используемых для защиты туннелей PMIP для конкретного терминала доступа в сети связи.
Фиг.9 - блок-схема иллюстративного устройства шлюза.
Фиг.10 - схема иллюстративной иерархии ключей для терминала доступа.
ПОДРОБНОЕ ОПИСАНИЕ
В нижеследующем описании конкретные детали приведены для обеспечения исчерпывающего понимания конфигураций. Однако специалисту в данной области техники очевидно, что конфигурации можно осуществлять на практике без этих конкретных деталей. Например, схемы можгут быть показаны в виде блок-схем, чтобы не затемнять конфигурации ненужными деталями. В других случаях общеизвестные схемы, структуры и подходы могут быть показаны детально, чтобы не затемнять конфигурации.
Кроме того, заметим, что конфигурации можно описывать как процесс, представленный в виде схемы последовательности операций, логической блок-схемы, структурной схемы или блок-схемы. Хотя схема последовательности операций может описывать операции в виде последовательного процесса, многие операции могут осуществляться параллельно или одновременно. Кроме того, порядок операций может быть изменен. Процесс заканчивается, когда его операции завершены. Процесс может соответствовать методу, функции, процедуре, подпроцедуре, подпрограмме и т.д. Когда процесс соответствует функции, его окончание соответствует возврату функции к вызывающей функции или главной функции.
В одном или нескольких примерах и/или конфигурациях описанные функции можно реализовать в оборудовании, программном обеспечении, программно-аппаратном обеспечении или в любой их комбинации. При реализации в программном обеспечении функции могут храниться или передаваться в виде одной или нескольких инструкций или кода на компьютерно-считываемом носителе. Компьютерно-считываемые носители включают в себя компьютерные носители информации и среды передачи данных, в том числе любую среду, которая позволяет переносить компьютерную программу из одного места в другое. Носители информации могут представлять собой любые физические носители, к которым компьютер общего или специального назначения может осуществлять доступ. В порядке примера, но не ограничения, такие компьютерно-считываемые носители могут содержать ОЗУ, ПЗУ, ЭСППЗУ, CD-ROM или другое запоминающее устройство на основе оптического диска, запоминающее устройство на основе магнитного диска, или другие магнитные запоминающие устройства, или любой другой носитель, который можно использовать для переноса или хранения нужного средства программного кода в виде инструкций или структур данных и к которому можно осуществлять доступ посредством компьютера общего или специального назначения или процессора общего или специального назначения. Кроме того, любое соединение допустимо именовать компьютерно-считываемым носителем. Например, при передаче программного обеспечения с веб-сайта, сервера или другого удаленного источника с использованием коаксиального кабеля, волоконно-оптического кабеля, витой пары, цифровой абонентской линии (DSL) или беспроводных технологий, например, инфракрасной, радио и СВЧ-связи, коаксиальный кабель, волоконно-оптический кабель, витая пара, DSL или беспроводные технологии, например, инфракрасная, радио и СВЧ-связь, входят в определение носителя. Используемый здесь термин «диск» включает в себя компакт-диск (CD), лазерный диск, оптический диск, цифровой универсальный диск (DVD), флоппи-диск и blu-ray диск, причем диски обычно воспроизводят данные посредством магнитных технологий, а диски воспроизводят данные посредством оптических технологий с применением лазеров. Сочетания вышеприведенных примеров также подлежат включению в понятие компьютерно-считываемых носителей.
Кроме того, носитель информации может представлять одно или несколько устройств для хранения данных, включая постоянную память (ПЗУ), оперативную память (ОЗУ), носители информации на основе магнитного диска, оптические носители информации, устройства флэш-памяти и/или другие машинно-считываемые носители для хранения информации.
Кроме того, конфигурации можно реализовать посредством оборудования, программного обеспечения, программно-аппаратного обеспечения, промежуточного программного обеспечения, микрокода или любой их комбинации. При реализации в виде программного обеспечения, программно-аппаратного обеспечения, промежуточного программного обеспечения или микрокода программный код или сегменты кода для осуществления необходимых задач может/могут храниться на компьютерно-считываемом носителе, например, носителе информации или в другом(их) хранилище(ах). Процессор может осуществлять необходимые задачи. Сегмент кода может представлять процедуру, функцию, подпрограмму, программу, процедуру, подпроцедуру, модуль, пакет программного обеспечения, класс или любую комбинацию инструкций, структур данных или операторов программы. Сегмент кода может быть подключен к другому сегменту кода или аппаратной схеме путем передачи и/или приема информации, данных, аргументов, параметров или содержимого памяти. Информацию, аргументы, параметры, данные и т.д. можно передавать, пересылать или отправлять с использованием любого подходящего средства, включая совместное использование памяти, передачу сообщений, передачу жетонов, сетевую передачу и т.д.
В нижеследующем описании определенные термины используются для описания определенных признаков. Термины “терминал доступа” и “устройство связи” можно использовать взаимозаменяемо по отношению к мобильному устройству, мобильному телефону, беспроводному терминалу и/или другим типам мобильных или стационарных устройств связи, способных осуществлять связь по беспроводной сети.
Один аспект предусматривает способ защиты туннеля PMIP между шлюзом обслуживающей сети и узлом сети доступа. На шлюзе поддерживается иерархия ключей PMIP. Шлюз использует ключ первого узла для защиты туннелей PMIP, когда аутентификация терминала доступа произведена. В противном случае шлюз использует ключ второго узла для защиты туннелей PMIP, когда аутентификация терминала доступа не произведена.
СЕТЕВАЯ СРЕДА
На Фиг.1 показана блок-схема сети UMB, в которой можно реализовать один или несколько признаков распространения секретных ключей PMIP согласно одному примеру. Сеть UMB может использовать плоскую архитектуру, которая не опирается на центральную сущность, например, контроллер базовых станций (BSC), для координации соединений между усовершенствованными базовыми станциями (eBS) UMB. eBS может объединять функции традиционной базовой станции, BSC, и некоторые функции обслуживающего узла пакетных данных (PDSN) в едином узле, что упрощает развертывание сети UMB. Благодаря сокращению количества компонентов (по сравнению с традиционными сетями) сеть UMB может быть более надежной, более гибкой, более удобной в развертывании и/или менее дорогой в эксплуатации. Например, в традиционных сетях BS, BSC, PDSN и домашний агент (HA) mobile IP совместно обслуживают пользовательский трафик. Сети UMB повторно используют большую часть инфраструктуры базовой сети, но консолидируют функции в меньшем количестве сетевых компонентов. Объединение этих функций в меньшее количество узлов снижает латентность, сокращает капитальные затраты и затраты на обслуживание, и снижает сложность взаимодействия между узлами для доставки сквозного QoS.
Этот пример показывает, как сеть доступа UMB 102 и обслуживающая сеть 113 могут обеспечивать доступ к беспроводной сети для совокупности терминалов доступа AT 106 и 108 (например, при повторном использовании инфраструктуры базовой сети (например, домашней сети 103). Обслуживающая сеть 113 может быть “домашней” сетью для AT 106 и 108, но AT также могут переходить в или посещать другие сети 105 и получать возможность связи посредством беспроводной сети от таких других сетей.
В этом примере сеть доступа 102 включает в себя первую eBS 104 и вторую eBS 107 (в общем случае именуемые “узлами сетевого доступа”), которые позволяют одному или нескольким терминалам доступа (AT-1) 106 подключаться к обслуживающей сети 113 и к домашней сети 103. Первая eBS 104 может быть подключена к первому сетевому контроллеру ссылок на сеанс (SRNC) 114 (в общем случае именуемому “сетевым контроллером”) и к первому шлюзу доступа (AGW) 112 (в общем случае именуемому “узлом сетевого шлюза”) в обслуживающей сети 113, который подключен к инфраструктуре 103 домашней сети. Аналогично, вторая eBS 107 может быть подключена ко второму SRNC 109 и первому AGW 112. Обслуживающая сеть 113 может включать в себя шлюзы AGW-a 112 и AGW-b 120, которые подключены к локальному серверу аутентификации, авторизации и экаунтинга (LAAA) 124 и визитной функции управления политиками и ресурсов (vPCRF) 132 для облегчения связи и/или обеспечения возможности связи для eBS и AT. Домашняя сеть 103 может включать в себя домашний агент (HA) 126, домашний AAA (HAAA) 128 и домашнюю PCRF (hPCRF) 130. Дополнительно, другие сети доступа 105 также могут быть подключены к HA 126 и/или LAAA 124 для обеспечения возможности связи посредством беспроводной сети для терминалов доступа.
В различных реализациях сеть доступа UMB 102 также может включать в себя другие eBS 116 и 117, подключенные к SRNC 118, который подключен ко второму шлюзу AGW 120, который может обеспечивать возможность связи посредством беспроводной сети для AT-2 108. Сети 102, 113, 105 и/или 103 описаны в качестве примера системы связи, в которой можно реализовать один или несколько из описанных здесь признаков новизны. Однако устройства и/или функции этих устройств в этих сетях могут располагаться в других показанных сетях (или в другой сети) без отхода от принципа действия и описанных здесь признаков.
Согласно различным примерам AT 106 и/или 108 могут представлять собой устройства беспроводной связи, мобильные телефоны, беспроводные терминалы и другие типы мобильных и/или беспроводных устройств, которые поддерживают возможность беспроводной радиосвязи посредством сети UMB.
eBS 104, 107 и 116 поддерживают радиоинтерфейс UMB. eBS 104, 107 и/или 116 могут включать в себя протоколы физического и/или MAC уровня UMB и могут осуществлять управление радиоресурсами, управление радиоканалами, шифрование 2 уровня и/или сжатие IP-заголовков (например, ROHC).
Шлюзы AGWs 112 и/или 120 могут обеспечивать возможность подключения по IP-протоколу 3 уровня к домашней сети 103. Шлюзы AGW 112 и/или 120 могут включать в себя различные функции, например, аутентификацию, буферизацию в неактивном состоянии и/или клиент proxy mobile IP. Например, шлюзы AGW 112 и/или 120 могут включать в себя управление IP-адресами, сторонний агент (FA) для MIPv4, DHCP Relay, клиент Proxy Mobile Internet Protocol (PMIP), классификацию/управление политиками пакетов Internet Packet (IP), аутентификатор EAP и/или клиент AAA.
SRNC 114, 109 и 118 могут управлять различными функциями для поддержки управления радиоресурсами, включая хранение информации сеансов, функции пейджинга и управление положением. Функции SRNC могут включать в себя, например, (a) хранение информации сеансов радиоинтерфейса, (b) контроллер пейджинга, (c) управление положением, и/или (d) аутентификатор EAP для AT. Первый SRNC 114 может поддерживать информацию, относящуюся к радиодоступу, для AT 106, а второй SRNC 118 может поддерживать информацию, относящуюся к радиодоступу, для AT 108. SRNC может отвечать за поддержание ссылки на сеанс (например, точки сохранения сеанса для согласованного контекста радиоинтерфейса), поддержание управления в неактивном состоянии и обеспечение функций управления пейджингом, когда AT находится в неактивном состоянии. SRNC также может отвечать за аутентификацию доступа AT. Функция SRNC может располагаться на, или совмещаться с, eBS или может располагаться в отдельной (нерадиофицированной) сущности. Заметим, что SRNC можно реализовать в централизованной или распределенной конфигурации. В централизованной конфигурации единый SRNC 118 соединен с несколькими eBS 116 и 117 и AGW 120. В распределенной конфигурации каждая eBS включает в себя SRNC, например, в eBS-a 104 и SRNC-a 114.
Услуги аутентификации, авторизации и экаунтинга (AAA) для домашней сети 103 могут быть разделены между домашним агентом 126, локальным AAA (LAAA) 124 и домашним AAA (HAAA) 128. HAAA 128 может отвечать за аутентификацию, авторизацию и экаунтинг, связанные с использованием сетевых ресурсов AT 106, 108, 110 и/или 112. Домашний агент (HA) 126 может обеспечивать решение мобильности, которое поддерживает, например, Client Mobile IP (CMIP) и/или Proxy Mobile IP (PMIP) и также может облегчать межтехнологическую мобильность.
Функция управления политиками и ресурсов (PCRF) может сохранять и распространять политики для AT 106, 108, 110 и/или 122. В одной реализации домашняя PCRF (hPCRF) 130 может отвечать за политики домашней сети, и визитная PCRF (vPCRF) 132 может отвечать за политики визитной сети. hPCRF 130 и vPCRF 132 обеспечивают локальные и визитные соответственно для AGW 112 и 120. Эти правила могут включать в себя, например, (a) обнаружение пакетов, принадлежащих служебному потоку данных, (b) обеспечение управления политиками для служебного потока данных и/или (c) обеспечение применимых параметров оплаты для служебного потока данных.
В одном примере AT-1 106 может аутентифицироваться, передавая запрос аутентификации через свою обслуживающую eBS-a 104, который проходит через AGW-a 112 на LAAA 124 и HAAA 128. После аутентификации трафик на и/или от AT-1 106, AGW-a 112 и HA 126.
Хотя различные примеры могут быть проиллюстрированы с точки зрения сети UMB, описанные здесь признаки можно применять к другим типам сетей, например, к сетям WiMAX и Long Term Evolution (LTE) и др.
Аутентификация с использованием расширяемого протокола аутентификации (EAP)
На Фиг.10 показана схема иллюстративной первичной иерархии ключей для терминала доступа. Когда расширяемый протокол аутентификации (EAP) (или какой-либо другой безопасный протокол аутентификации) используется сетью для аутентификации терминала доступа (AT), заранее сконфигурированный Long Term Credential 1001 (например, уникальный идентификатор AT или значение и т.д.) можно использовать для получения двух ключей, известных как Master Session Key (MSK) 1002 и Extended Master Session Key (EMSK) 1004.
MSK 1002 можно вычислять посредством HAAA, отправленного на SRNC для вывода сеансовых ключей для защиты трафика, передаваемого по радиоканалу. EMSK 1004 может храниться на AT и сервере AAA, и его можно использовать для вывода других ключей для мобильности или повторной аутентификации в дальнейшем. Когда AT осуществляет начальную аутентификацию доступа EAP, MSK 1002 доступен, как AT, так и SRNC. AT может использовать MSK 1002 для вывода сеансового ключа MSK' 1006 (где MSK '= f(MSK)) для аутентификации самого себя в первой сети доступа (AN1). Затем AT может пытаться подключиться ко второй сети доступа AN2 и может осуществлять повторную аутентификацию, на которой Domain Specific Root Key (DSRK) 1008 доставляется на локальный сервер AAA или AGW, на котором могут осуществляться процедуры повторной аутентификации. В целях повторной аутентификации Re-authentication Root Key (rRK) 1010 можно выводить на AT и локальном сервере AAA/AGW. Все, что ниже иерархии rRK, может относиться к использованию повторной аутентификации и, в конце концов, обеспечивает материал ключа для вывода сеансовых ключей для использования с другими узлами доступа. Например, Re-authentication Integrity Key (ключа целостности повторной аутентификации) (rIK) 1012 и ключа MSK повторной аутентификации (rMSK) 1014.
Для защиты Mobile IPv4, EMSK 1004 можно использовать для генерации особого корневого ключа (MIP4-MN-RK) 1016. Затем ключ MIP4-MN-RK 1016 используется для вычисления ключа MN-AAA 1018, который AT можно использовать для подтверждения обладания действительным материалом ключа во время использования Mobile IPv4 (например, при приеме запроса изменения на новом узле доступа eBS). После того как AT назначен домашний агент (HA) для целей MIP4, ключ MN-HA 1020 также можно вывести из MIP4-MN-RK 1016.
Ключ MIP4-MN-RK 1016 может представлять собой заранее сконфигурированный ключ для использования в случаях, когда EAP не используется для аутентификации доступа. Например, это может иметь место для систем HRPD/1X, которые используют усовершенствование MIPv4 для IP-мобильности. При переходе из сети HRPD в сеть UMB или наоборот наиболее поздний доступный ключ MIP4-MN-RK можно использовать для генерации ключей MN-HA. Наиболее поздний доступный ключ может представлять собой динамически выведенный ключ MIP4-MN-RK (из EMSK 1004), когда он доступен, или заранее сконфигурированный ключ MIP4-MN-RK, когда динамически выведенный ключ недоступен. Например, когда AT начинает работать в сети HRPD, заранее сконфигурированный ключ MIP4-MN-RK будет использоваться для целей MIP4. Если затем AT переходит в сеть UMB с тем же сеансом MIP4, ключ MIP4-MN-RK, используемый в данный момент, будет продолжать использоваться до истечения его срока годности. Если AT начинает работать в сети UMB, он осуществляет EAP, и динамический ключ MIP4-MN-RK будет доступен. В этом случае динамический ключ MIP4-MN-RK используется для MIP4, пока не истечет срок действия ключа, даже если AT затем перемещается в сеть HRPD. По истечении срока действия динамического ключа MIP4-MN-RK AT может затем использовать заранее сконфигурированный или динамический ключ MIP4-MN-RK, в зависимости от того, какой из них доступен в этот момент, для генерации новых ключей MIP4.
Для защиты Proxy Mobile IPv4 (например, защиты туннелей PMIP между узлами сетевой инфраструктуры) иерархию ключей можно задать на основании случайного ключа (PMN-RK), который может быть уникальным для AT и может выбираться локальным сервером AAA (LAAA) или шлюзом доступа (AGW) во время начальной аутентификации доступа.
Генерация и распространение ключа PMIP
Когда AT переходит или перемещается от первой eBS ко второй eBS, AGW, управляющий связью для AT, устанавливает туннель proxy mobile IP (PMIP) к новой обслуживающей eBS. Однако AGW должен препятствовать другим eBS (или злоумышленникам) объявлять о том, что они обеспечивают возможность беспроводной связи для AT, когда это не так. Например, согласно Фиг.1, если AT-1 106 намеревается поменять свой обслуживающий узел доступа с eBS-a 104 на eBS-b 107, шлюз AGW-a 112 должен иметь возможность проверить действительность запроса изменения на eBS-b 107. AGW-a 112 может препятствовать неавторизованной сущности изменять туннельную привязку PMIP (например, между шлюзом AGW-a 112 и eBS-a 104/SRNC-a 114) благодаря использованию секретных ключей PMIP для каждой туннельной привязки.
Существует, по меньшей мере, два типа туннелей PMIP, туннели PMIP RAN между eBS и AGW и сетевые туннели PMIP между AGW и SRNC и между первым AGW и вторым AGW. Когда AT перемещается от первого узла доступа eBS-1 ко второму узлу доступа eBS-2 (в сети доступа), AGW может устанавливать новый туннель PMIP RAN с новой обслуживающей eBS-2. Аналогично, когда AT перемещается или переходит в новую сеть доступа или обслуживающую сеть, домашний шлюз AGW может устанавливать сетевой туннель PMIP с новой сетью доступа или обслуживающей сетью. После перехода к новой обслуживающей eBS-2 можно установить новый туннель PMIP с новым ключом PMIP.
Следовательно, один признак предусматривает ключ proxy mobile-node home-agent (PMN-HA) (“ключ PMIP”), который можно использовать, например, для привязки или защиты туннелей PMIP между узлом доступа eBS и шлюзом AGW и/или между SRNC и шлюзом AGW. Таким образом, от шлюза AGW к узлу доступа eBS можно передавать секретный ключ, который позволяет им защищать сигнализацию PMIP в туннеле PMIP между ними.
Системы связи могут реализовывать иерархию ключей для вывода ключей, используемых для разных целей в системе связи. В ряде случаев “главный” ключ присваивается AT и может использоваться системой связи и/или AT для вывода других ключей. Выведенные ключи генерируются как функция главного ключа (и, возможно, других параметров) таким образом, что главный ключ нельзя обнаружить. Аналогично некоторые выведенные ключи можно использовать для безопасного вывода других низкоуровневых ключей.
В ряде случаев первичная иерархия ключей, например иерархия ключей EAP (Фиг.10), поддерживается на HAAA и AT. Первичная иерархия ключей может базироваться на главном ключе, уникально связанном с AT и известном как HAAA, так и AT. Первичную иерархию ключей можно использовать для вывода ключей, используемых для аутентификации AT на HAAA.
Вторичная иерархия ключей (PMIP) может поддерживаться на сетевом шлюзе (AGW) и использоваться для проверки запросов на перемаршрутизацию/хэндовер сеанса или услуги на новый узел доступа. Эта вторичная иерархия ключей может быть известна шлюзу AGW, но не AT. В некоторых примерах вторичная иерархия ключей может базироваться на случайном ключе (PMN-RK), который уникален для AT и известен только шлюзу. Совокупность ключей PMN-HA можно выводить из случайного корневого ключа (PMN-RK) вторичной иерархии ключей.
На Фиг.2 показана схема вторичной иерархии ключей (PMIP), которая может поддерживаться на шлюзе AGW для генерации и/или распространения ключей для защиты туннелей PMIP согласно одному примеру. В этом примере корневой ключ PMIP4-RK 202 может быть случайным ключом, выбранным шлюзом AGW. В одной реализации иерархия ключей 200 может не иметь корреляции с высокоуровневыми ключами первичной иерархии ключей, используемыми, например, для аутентификации терминала доступа AT. Например, корневой ключ PMIP4-RK 202 во вторичной иерархии ключей 200 может быть случайным ключом, который не зависит от первичной иерархии ключей для терминала доступа AT. В другой реализации PMIP4-RK ключ 202 можно выводить на основании высокоуровневого ключа в первичной иерархии ключей для терминала доступа AT.
В одном примере шлюз AGW может генерировать разные ключи узла, PMN-RK1 и PMN-RK2, в зависимости от того, аутентифицируется ли соответствующий терминал доступа AT в ходе хэндовера или перехода к новому сетевому узлу доступа (eBS). Таким образом, поскольку неаутентифицированный терминал доступа AT более подвержен компрометации, шлюз AGW может использовать разные ключи. Таким образом, туннели PMIP, для которых AT не аутентифицирован, можно защищать ключом первого узла PMN-RK1, а туннели PMIP, для которых AT аутентифицирован, защищается ключом второго узла PMN-RK2. Это гарантирует, что в случае компрометации ключа первого узла PMN-RK1 это не будет компрометировать AT при перемещении к другим узлам доступа, где может происходить повторная аутентификации.
RK1-1
RK1-1
RK1-1
В первом режиме работы, когда аутентификации AT не происходит через новый обслуживающий узел доступа, можно генерировать и использовать ключ первого узла PMN-RK1 204. AGW генерирует ключ первого узла PMN-RK1 и доставляет его на промежуточный узел сети (SRNC), связанный с новым обслуживающим узлом доступа. Затем промежуточный узел сети SRNC генерирует ключ PMIP (PMN-HARK1-1) на основании ключа первого узла PMN-RK1 и, возможно, других параметров, например, счетчика или идентификатора узла доступа. Ключ PMIP (PMN-HA) передается на новый обслуживающий узел доступа и затем может использоваться между новым обслуживающим узлом доступа и шлюзом AGW для установления и/или защиты туннеля PMIP. Заметим, что другие параметры (например, счетчик, идентификатор узла доступа и т.д.), с помощью которых вычисляется ключ PMIP (PMN-HA), могут быть известны или предоставлены шлюзу AGW, чтобы он также генерировал такой же ключ PMIP (PMN-HA) для установления или проверки туннеля PMIP.
RK2-1
Во втором режиме работы, когда аутентификация AT осуществляется через новый обслуживающий узел доступа, можно генерировать и использовать ключ второго узла PMN-RK1 206. В этом примере ключ второго узла PMN-RK2 206 остается на шлюзе AGW, и ключ второго узла (PMN-HA) вычисляется и передается непосредственно на новый обслуживающий узел доступа. В этом примере, аутентификация AT может содержать осуществление запроса аутентификации доступа (например, с использованием протокола EAP-AK) либо запроса повторной аутентификации доступа (например, с использованием протокола повторной аутентификации EAP (ERP)).
RK1-1
RK1-N
RK2-1
RK2-N
В другом примере тот же ключ первого узла PMN-RK1 204 можно использовать для генерации совокупности разных ключей PMIP (PMN-HA … PMN-HA), когда тот же терминал доступа AT перемещается или переходит от одного узла доступа к другому. Аналогично ключ второго узла PMN-RK2 206 можно использовать для генерации совокупности разных ключей PMIP (PMN-HA … PMN-HA), когда терминал доступа AT перемещается или переходит между разными узлами доступа.
Поскольку терминалу доступа AT не нужно знать ключи PMIP PMN-HAx, единственной сущностью, “выводящей” этот ключ, является AGW. Поэтому нет необходимости выводить корневой ключ PMIP4-RK 202, поскольку достаточно простой сильной генерации случайных чисел. Сгенерированное случайное число (т.е. корневой ключ PMIP4-RK) можно использовать в качестве затравки для AGW для генерации вторичной иерархии ключей для использования при проверке, следует ли устанавливать новый туннель PMIP (например, туннель PMIPv4).
Альтернативно ключ PMIP (PMN-HAx) можно создавать из первичной иерархии ключей (EAP), как в случае ключа аутентификации.
В других реализациях корневой ключ не используется для генерации ключей узла PMN-RK1 204 и PMN-RK2 206. Вместо этого эти два ключа узла можно генерировать независимо. Например, PMN-RK1 204 и PMN-RK2 206 могут быть произвольно выбранными.
На Фиг.3-6 показано, как шлюз доступа AGW может распространять ключи PMIP на узлы доступа eBSs и/или сетевой контроллер ссылок на сеанс SRNC в различных сценариях.
На Фиг.3 показана блок-схема сети связи, в которой терминал доступа AT переводит услуги связи с первого узла доступа eBS-a 304 на второй узел доступа eBS-b 308.
На Фиг.4 показана схема последовательности операций, демонстрирующая, как шлюз может генерировать и распространять ключи PMIP в среде, показанной на Фиг.3, в случае, когда терминал доступа AT аутентифицирован. В этом примере терминал доступа AT 312 первоначально обслуживается первым узлом доступа eBS-a 304, но перемещается или переходит ко второму узлу доступа eBS-b 308.
Шлюзы AGW 302 могут поддерживать иерархию ключей PMIP 402. На начальной стадии соединения 404 с первым узлом доступа eBS-a 304 AT 312 может инициировать запрос аутентификации доступа 408. Запрос аутентификации доступа 408 (например, EAP-AK) может передаваться терминалом доступа AT 312 через узел доступа AGW 302, например, на HAAA домашней сети для аутентификации. Как часть этого процесса узел доступа AGW 302 может определять, что терминал доступа AT 312 проходит аутентификацию. Следовательно, узел доступа AGW 302 может генерировать ключ первого узла PMN-RK2 410. Например, ключ первого узла PMN-RK2 410 можно генерировать на основании корневого ключа PMIP4-RK или можно генерировать произвольно. Затем ключ первого узла PMN-RK2 можно использовать для вычисления первого ключа PMIP PMN-HARK2-1 412. Ключи PMN-RK2 и PMN-HARK2-1 могут поддерживаться как часть иерархии ключей PMIP 402. Затем первый ключ PMIP PMN-HA RK2-1 передается 414 на первый узел доступа eBS-a 304. В одном примере первый ключ PMIP PMN-HA RK2-1 передается как часть ответа аутентификации. Ответ аутентификации доступа 416 может передаваться первым узлом доступа eBS-a 304 на терминал доступа AT 312. Заметим, что процедура начальной стадии соединения 404 может осуществляться, когда терминал доступа AT 312 впервые устанавливает услугу связи через сеть связи (в которую входят eBS-a, SRNC-a и AGW) или когда AT 312 переходит или перемещается к eBS-a 304. Затем туннель PMIP можно установить 418 между первым узлом доступа eBS-a 304 и AGW 302.
RK2-1
RK2-1
RK2-1
На последующей стадии хэндовера 406 AT 312 может посылать запрос повторной аутентификации доступа 420 с целью изменения своего обслуживающего узла доступа на второй узел доступа eBS-b 308. Поскольку запрос повторной аутентификации 420 осуществляется с использованием протокола аутентификации, например EAP-AK или ERP, сеть может проверить, что запрос действительно поступает от AT 312 (а не от неавторизованной сущности). Поскольку AGW 302 знает, что ответ аутентификации направляется обратно на AT 312, он может определить, что следует использовать ключ первого узла PMN-RK2 (который он использует только, когда AT аутентифицирован). Затем шлюз AGW 302 вычисляет второй ключ PMIP PMN-HA 422 на основании ключа первого узла PMN-RK2. Затем второй ключ PMIP PMN-HA передается 424 на второй узел доступа eBS-b 308. Ответ повторной аутентификации доступа 426 также может передаваться вторым узлом доступа eBS-b 308 на терминал доступа AT 312. Второй ключ PMIP PMN-HA можно затем использовать для установления туннеля PMIP 428 между вторым узлом доступа eBS-b 308 и шлюзом AGW 302.
На Фиг.5 показана схема последовательности операций, демонстрирующая, как шлюз может генерировать и распространять ключи PMIP в среде, показанной на Фиг.3, в случае, когда терминал доступа AT аутентифицирован через первый узел доступа eBS-a 304, но перемещается ко второму узлу доступа eBS-b 308 без аутентификации.
Шлюз AGW 302 может поддерживать иерархию ключей PMIP 502. На начальной стадии соединения 504 с первым узлом доступа eBS-a 304 терминал доступа AT 312 может инициировать запрос аутентификации доступа 508. Запрос аутентификации доступа 508 (например, EAP-AK) может передаваться терминалом доступа AT 312 через шлюз AGW 302, например, на HAAA домашней сети для аутентификации. Как часть этого процесса шлюз AGW 302 может определять, что терминал доступа AT 312 проходит аутентификацию. Следовательно, шлюз AGW 302 может генерировать ключ первого узла PMN-RK2 510. Например, ключ первого узла PMN-RK2 510 можно генерировать на основании корневого ключа PMIP4-RK или можно генерировать произвольно. Затем ключ первого узла PMN-RK2 можно использовать для вычисления первого ключа PMIP PMN-HARK2-1 512. Ключи PMN-RK2 и PMN-HARK2-1 могут поддерживаться как часть иерархии ключей PMIP 502. Затем первый ключ PMIP PMN-HA RK2-1 передается 514 на первый узел доступа eBS-a 304. В одном примере первый ключ PMIP PMN-HA RK2-1 передается как часть ответа аутентификации. Ответ аутентификации доступа 516 может передаваться первым узлом доступа eBS-a 304 на терминал доступа AT 312. Заметим, что процедура начальной стадии соединения 504 может осуществляться, когда терминал доступа AT 312 впервые устанавливает услугу связи через сеть связи (в которую входят eBS-a, SRNC-a и AGW) или когда AT 312 переходит или перемещается к eBS-a 304. Затем туннель PMIP можно установить 518 между первым узлом доступа eBS-a 304 и AGW 302.
На последующей стадии хэндовера 506 AT 312 может посылать запрос хэндовера 520 с целью изменения своего обслуживающего узла доступа на второй узел доступа eBS-b 308. Поскольку запрос хэндовера 520 осуществляется без аутентификации или повторной аутентификации терминала доступа AT, сеть не может проверить, что запрос действительно поступает от терминала доступа AT 312. Поэтому шлюз AGW 302 знает, что ему не следует использовать ключ первого узла PMN-RK2 (который используется только, когда AT аутентифицирован). Вместо этого шлюз AGW 302 вычисляет ключ второго узла PMN-RK1 522, который нужно использовать только, когда AT не аутентифицирован. Ключ второго узла PMN-RK1 передается 524 на SRNC-b 310 (также именуемый “промежуточным узлом сети”). Затем SRNC-b 310 вычисляет второй ключ PMIP PMN-HARK1-1 528 на основании ключа второго узла PMN-RK1 и, возможно, других параметров, например, идентификатора узла доступа для eBS-b или счетчика. Затем второй ключ PMIP PMN-HARK1-1 передается 530 на второй узел доступа eBS-b 308. Ответ хэндовера 532 также может передаваться вторым узлом доступа eBS-b 308 на терминал доступа AT 312. Второй ключ PMIP PMN-HARK1-1 можно затем использовать для установления туннеля PMIP 534 между вторым узлом доступа eBS-b 308 и шлюзом AGW 302.
На Фиг.6 показана схема последовательности операций, демонстрирующая, как шлюз может генерировать и распространять ключи PMIP в среде, показанной на Фиг.3 в случае, когда терминал доступа AT переходит от неаутентифицированного соединения с узлом доступа eBS-a 304 к другому неаутентифицированному соединению со вторым узлом доступа eBS-b 308 без аутентификации.
Шлюз AGW 302 может поддерживать иерархию ключей PMIP 602. На стадии соединения 604 с первым узлом доступа eBS-a 304 терминал доступа AT 312 может инициировать запрос хэндовера 608 без аутентификации терминала доступа AT 312. Как часть этого процесса шлюз AGW 302 может определять, что терминал доступа AT 312 переносит свое соединение на первый узел доступа eBS-a 304 без аутентификации. Следовательно, шлюз AGW 302 может генерировать ключ первого узла PMN-RK1 610. Например, ключ первого узла PMN-RK1 610 можно генерировать на основании корневого ключа PMIP4-RK или можно генерировать произвольно. Затем ключ первого узла PMN-RK1 можно передавать 611 на SRNC-a 306 (“промежуточный узел сети”), связанный с первым узлом доступа eBS-a 304. SRNC-a 306 использует ключ первого узла PMN-RK1 для вычисления первого ключа PMIP PMN-HARK1-1 612. Ключи PMN-RK1 и PMN-HARK1-1 могут поддерживаться как часть иерархии ключей PMIP 602. Затем первый ключ PMIP PMN-HA RK1-1 передается 614 на первый узел доступа eBS-a 304. Ответ хэндовера 616 может передаваться первым узлом доступа eBS-a 304 на терминал доступа AT 312. Заметим, что процедура стадии соединения 604 может осуществляться, когда терминал доступа AT 312 впервые устанавливает услугу связи через сеть связи (в которую входят eBS-a, SRNC-a и AGW) или когда AT 312 переходит или перемещается к eBS-a 304. Затем туннель PMIP можно установить 618 между первым узлом доступа eBS-a 304 и шлюзом AGW 302.
На последующей стадии хэндовера 606 AT 312 может посылать запрос хэндовера 520 с целью изменения своего обслуживающего узла доступа на второй узел доступа eBS-b 308. Поскольку запрос хэндовера 620 осуществляется без аутентификации или повторной аутентификации терминала доступа AT 312, сеть не может проверить, что запрос действительно поступает от терминала доступа AT 312. Поэтому шлюз AGW 302 знает, что ему следует использовать ключ первого узла PMN-RK1 (который используется только, когда AT не аутентифицирован). Шлюз AGW 302 передает ключ первого узла PMN-RK1 524 на SRNC-b 310 (также именуемый “промежуточным узлом сети”). Затем SRNC-b 310 вычисляет второй ключ PMIP PMN-HARK1-2 628 на основании ключа первого узла PMN-RK1 и, возможно, других параметров, например, идентификатора узла доступа для eBS-b или счетчика. Затем второй ключ PMIP PMN-HARK1-2 передается 630 на второй узел доступа eBS-b 308. Ответ хэндовера 632 также может передаваться вторым узлом доступа eBS-b 308 на терминал доступа AT 312. Второй ключ PMIP PMN-HARK1-2 можно затем использовать для установления туннеля PMIP 634 между вторым узлом доступа eBS-b 308 и шлюзом AGW 302.
Заметим, что, когда терминал доступа AT перемещается между двумя узлами доступа, которые подключены к одному и тому же SRNC и аутентификация терминала доступа AT не осуществляется ни для какого соединения, SRNC уже имеет ключ узла PMN-RK1. Поэтому SRNC может просто вычислить новый ключ PMIP для нового терминала доступа. При установлении туннеля PMIP новый терминал доступа может просто передавать новый ключ PMIP и параметры, используемые для его генерации на шлюз AGW. Затем шлюз AGW, знающий ключ узла PMN-RK1, может генерировать новый ключ PMIP для проверки.
На Фиг.7 показан способ, выполняемый на сетевом шлюзе для генерации ключей, используемых для защиты туннелей PMIP в сети связи. В одном примере шлюз может действовать в сети, совместимой с Ultra Mobile Broadband (UMB). Шлюз может принимать запрос на изменение туннельной привязки Proxy Mobile Internet Protocol (PMIP) для терминала доступа от первого узла доступа ко второму узлу доступа 702. Такой запрос может быть частью процедуры аутентификации или повторной аутентификации или может быть частью процедуры запроса хэндовера. Затем шлюз может определять, аутентифицирован ли терминал доступа через второй узел доступа 704. Таким образом, шлюз может определять, аутентифицирован ли, в запросе переноса услуги связи от предыдущего узла доступа на новый узел доступа, поступающем от терминала доступа. Это можно осуществлять, например, посредством процедуры EAP-AK или процедуры ERP. Если терминал доступа не аутентифицирован через новый узел доступа, то шлюз генерирует ключ первого узла 706 и передает ключ первого узла на промежуточный узел сети (например, SRNC), который может генерировать и выдавать первый ключ PMIP на второй узел доступа 708. В противном случае шлюз генерирует ключ второго узла 710, генерирует второй ключ PMIP как функцию ключа второго узла 712 и передает второй ключ PMIP на второй узел доступа 714.
В различных реализациях ключ первого узла и ключ второго узла могут базироваться на общем корневом ключе, произвольно выбранном корневом ключе, или они могут быть независимы друг от друга (т.е. каждый из ключей первого и второго узла могут быть произвольно выбраны). Заметим, что ключ первого узла и ключ второго узла могут не быть известны терминалу доступа, поскольку они используются только для привязки PMIP к сети. Следовательно, иерархия ключей PMIP (например, ключ первого узла, ключ второго узла, ключи PMIP и т.д.) может быть независимой от первичной иерархии ключей (EAP), известной терминалу доступа и используемой для аутентификации терминала доступа.
Затем шлюз может установить туннель PMIP между шлюзом и вторым узлом доступа с использованием либо первого ключа PMIP, либо второго ключа PMIP 716. Таким образом, если передается ключ первого узла, то первый ключ PMIP используется для установления и защиты туннеля PMIP. В этом случае шлюз может генерировать локальную версию первого ключа PMIP с использованием параметров, известных шлюзу и промежуточному узлу сети. Например, шлюз и промежуточный узел сети могут использовать счетчик, известный обоим, значение идентификатора для второго узла доступа или какой-либо другой параметр для генерации ключа первого узла. При установлении туннеля PMIP второй узел доступа может предоставлять шлюзу копию первого ключа PMIP совместно с параметрами, используемыми для его генерации (за исключением ключа первого узла). В противном случае, если передается второй ключ PMIP, шлюз уже знает этот ключ и может проверить, что это действительно второй узел доступа, прежде чем принять туннельную привязку PMIP ко второму узлу доступа.
На Фиг.8 показан способ, выполняемый на сетевом шлюзе для генерации и распространения ключей, используемых для защиты туннелей PMIP для конкретного терминала доступа в сети связи. Шлюз может поддерживать иерархию ключей PMIP, связанных с терминалом доступа и используемых для защиты туннелей PMIP к узлам сети, обслуживающим терминал доступа 802. Шлюз может принимать извещение об изменении туннельной привязки PMIP для терминала доступа на новый узел доступа 804. Он может определять, аутентифицирован ли терминал доступа через новый узел доступа 806. Затем генерируется ключ первого узла, который облегчает туннельную привязку PMIP; однако ключ первого узла используется, только когда терминал доступа аутентифицирован или не аутентифицирован, но не в обоих случаях 808. Таким образом, отдельные ключи узла используются для туннельных привязок, где терминал доступа аутентифицирован и где терминал не аутентифицирован. Ключ первого узла может использоваться шлюзом или промежуточным узлом сети для генерации ключа PMIP. Таким образом, ключ первого узла или его производный ключ (т.е. ключ PMIP) используется для создания туннеля PMIP между шлюзом и новым узлом доступа 810.
На Фиг.9 показана блок-схема иллюстративного устройства шлюза. Устройство шлюза 902 может включать в себя схему обработки 904, подключенную к сетевому интерфейсу 906. Схема обработки 904 может быть предназначена для поддержания вторичной иерархии ключей (PMIP) и осуществления одного или нескольких из этапов, показанных на Фиг.2-8, для того, чтобы генерировать и распространять ключи PMIP по-разному, в зависимости от того, прошел ли терминал доступа успешную аутентификацию.
Согласно еще одной конфигурации схема может быть способна принимать запрос на изменение туннельной привязки Proxy Mobile Internet Protocol (PMIP) для терминала доступа от первого узла доступа ко второму узлу доступа. Та же схема, другая схема или вторая секция той же или другой схемы может быть предназначена для определения, аутентифицирован ли терминал доступа через второй узел доступа. Кроме того, та же схема, другая схема или третья секция той же или другой схемы может быть предназначена для генерации ключа первого узла, если терминал доступа не аутентифицирован, и передачи ключа первого узла на промежуточный узел сети, который может генерировать и выдавать первый ключ PMIP на второй узел доступа. Аналогично та же схема, другая схема или четвертая секция может быть предназначена для генерации ключа второго узла, если терминал доступа аутентифицирован, и генерации второго ключа PMIP как функции ключа второго узла и передачи второго ключа PMIP на второй узел доступа. Та же схема, другая схема или четвертая секция может быть предназначена для установления туннеля PMIP между шлюзом и вторым узлом доступа, защищенного первым или вторым ключом PMIP.
Специалисту в данной области техники очевидно, что, в общем случае, большую часть обработки, описанной в этом раскрытии, можно реализовать аналогичным образом. Любая(ые) схема(ы) или секция(и) схемы можно реализовать, по отдельности или совместно, как часть интегральной схемы с одним или несколькими процессорами. Одну или несколько схем можно реализовать на интегральной схеме, процессоре Advance RISC Machine (ARM), цифровом сигнальном процессоре (DSP), процессоре общего назначения и т.д.
Один или несколько из компонентов, этапов и/или функций, показанных на Фиг.1, 2, 3, 4, 5, 6, 7, 8, 9 и/или 10, можно реорганизовать и/или объединять в единый компонент, этап или функцию или реализовать в нескольких компонентах, этапах или функциях. Также можно добавлять дополнительные элементы, компоненты, этапы и/или функции. Устройства и/или компоненты, показанные на Фиг.1, 3 и 9, можно конфигурировать или адаптировать к осуществлению одного или нескольких способов, признаков или этапов, описанных на Фиг.2, 4-8 и/или 10. Описанные здесь алгоритмы можно эффективно реализовать в программном обеспечении и/или встроенном оборудовании.
Специалистам в данной области техники дополнительно известно, что различные иллюстративные логические блоки, модули, схемы и этапы алгоритма, описанные в связи с раскрытыми здесь конфигурациями, можно реализовать в виде электронного оборудования, компьютерного программного обеспечения или их комбинации. Для наглядной иллюстрации этой взаимозаменяемости оборудования и программного обеспечения различные иллюстративные компоненты, блоки, модули, схемы и этапы описаны выше, в целом, применительно к их функциям. Реализуются ли эти функции в виде оборудования или программного обеспечения, зависит от конкретного применения и конструкционных ограничений, налагаемых на всю систему.
Следует отметить, что вышеописанные конфигурации являются лишь примерами и не подлежат рассмотрению как ограничивающие формулу изобретения. Описание конфигураций носит иллюстративный характер и не ограничивает объем изобретения. Таким образом, принципы настоящего изобретения можно легко применять к другим типам устройств, и специалисты в данной области техники могут предложить многочисленные альтернативы, модификации и вариации.