Способ и устройство для связывания аутентификации абонента и аутентификации устройства в системах связи

Группа изобретений относится к средствам связывания аутентификации абонента и аутентификации устройства. Технический результат – повышение безопасности связи. Для этого предложен способ аутентификации между устройством (таким как клиентское устройство или терминал доступа) и сетевым объектом. Съемное запоминающее устройство может быть соединено с устройством и хранить специфический для абонента ключ, который может использоваться для аутентификации абонента. Защищенное запоминающее устройство может быть соединено с устройством и хранит специфический для устройства ключ, который может использоваться для аутентификации устройства. Аутентификация абонента может выполняться между устройством и сетевым объектом. Аутентификация устройства также может выполняться между устройством и сетевым объектом. Затем может генерироваться защитный ключ, который связывает аутентификацию абонента и аутентификацию устройства. Защитный ключ может использоваться, чтобы обезопасить связь между устройством и обслуживающей сетью. 8 н. и 40 з.п. ф-лы, 13 ил.

 

[0001] По настоящей заявке испрашивается приоритет в соответствии с предварительной патентной заявкой США № 61/355,423, озаглавленной «Устройство и способ для аутентификации устройств в системах 3GPP», поданной 16 июня 2010 года, переуступленной правопреемнику данной заявки и включенной в настоящий документ посредством ссылки.

УРОВЕНЬ ТЕХНИКИ

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

[0002] Различные признаки относятся к системам связи, а точнее, к аутентификации устройств, таких как ретрансляционные узлы и устройства межмашинной связи, используемые в проводных и/или беспроводных системах связи.

УРОВЕНЬ ТЕХНИКИ

[0003] Современные беспроводные сети могут включать в себя ретрансляционные узлы и/или терминалы доступа, в совокупности именуемые устройствами. Чтобы такое устройство функционировало надлежащим образом, оно часто обеспечивается/конфигурируется операционными и абонентскими защитными учетными данными до того, как вводится в эксплуатацию. Такие абонентские защитные учетные данные могут использоваться, например, для аутентификации устройства до предоставления беспроводного обслуживания или доступа и в некоторых случаях могут храниться в модуле, который постоянно соединен со своим главным устройством. Существует риск того, что абонентские защитные учетные данные могут быть удалены с аутентифицированного устройства и перемещены на неавторизованное устройство. В случае с ретрансляционным узлом, это может дать возможность неавторизованному ретрансляционному узлу тайно получить доступ к передачам, например, между узлом доступа и одним или несколькими терминалами доступа и/или получить бесплатный доступ к сетевым услугам. Этот риск уязвимости также существует в случае с устройствами межмашинной связи (М2М) в том, что параметры действительных абонентских учетных данных (например, соглашение об аутентификации и ключах - (АКА) на съемной универсальной карте на основе интегральной микросхемы (UICC)) М2М устройства могут быть перемещены на другое устройство с целью получения бесплатного сетевого доступа. Связанная с этим уязвимость существует в том, что не обязательно иметь физический доступ к самому М2М устройству. Доступа к данным (например, защитные ключи, получаемые в результате аутентификации), проходящим по интерфейсу М2М устройства (например, от главного устройства к интерфейсу UICC), достаточно для получения доступа к защитным ключам и раскрытия данных, защищенных вышеупомянутыми ключами.

[0004] Подобная проблема актуальна, если оператор желает контролировать то, каким устройствам разрешен доступ к их сети.

[0005] Следовательно, существует потребность в обеспечении дополнительной безопасности устройств, чтобы принять меры в отношении этих и других уязвимостей и рисков.

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

[0007] В соответствии с первым аспектом, обеспечен осуществляемый в устройстве способ, который связывает абонентскую аутентификацию и аутентификацию устройства. Устройство может начинать работу путем отправки запроса на подключение сетевому объекту, при этом запрос на подключение включает в себя индикацию возможностей аутентификации устройства у данного устройства. Аутентификация абонента может выполняться устройством с сетевым объектом. Например, аутентификация абонента может основываться на обмене данными соглашения о ключе аутентификации между устройством и сетевым объектом. Устройство также может выполнять аутентификацию устройства с сетевым объектом. К примеру, аутентификация устройства может основываться на обмене данными по схеме «запрос-ответ» между устройством и сетевым объектом.

[0008] Защитный ключ может генерироваться так, что будет связывать абонентскую аутентификацию и аутентификацию устройства. Защитный ключ может генерироваться как функция от по меньшей мере первого ключа, полученного при аутентификации абонента, и второго ключа, полученного при аутентификации устройства. Кроме того, защитный ключ также может быть функцией одноразового слова шифрования сети и одноразового слова шифрования устройства. Защитный ключ может использоваться, чтобы обезопасить связь между устройством и обслуживающей сетью. Следует отметить, что защитный ключ может генерироваться отдельно устройством и сетевым объектом, так что он не передается посредством беспроводной связи.

[0009] В соответствии с одним вариантом реализации, аутентификация абонента может выполняться с помощью первого сервера аутентификации, являющегося частью сетевого объекта, тогда как аутентификация устройства может выполняться с помощью второго сервера аутентификации, являющегося частью сетевого объекта.

[0010] В одном примере аутентификация устройства может выполняться путем использования совместно используемого секретного ключа, чтобы зашифровать/расшифровать определенные обмены данными между устройством и сетевым объектом. В другом примере аутентификация устройства может выполняться путем: (а) приема данных от сетевого объекта, которые зашифрованы с помощью открытого ключа устройства; (b) использования соответствующего секретного ключа, чтобы расшифровать зашифрованные данные; и/или (c) последующего доказательства сетевому объекту того, что устройство обладает сведениями об этих данных.

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

[0012] В различных вариантах реализации аутентификация абонента и аутентификация устройства могут одновременно выполняться при обменах комбинированными сообщениями, или аутентификация абонента может осуществляться при более раннем и отдельном от аутентификации устройства защищенном обмене данными.

[0013] В соответствии с одним аспектом, специфический для абонента ключ может быть обеспечен для устройства как часть соглашения на обслуживание. Аналогично, специфический для устройства ключ может быть обеспечен устройству при производстве, причем специфический для устройства ключ используется для аутентификации устройства.

[0014] В одном варианте реализации устройство может быть ретрансляционным узлом, который выступает как терминал доступа к сетевому объекту, а также выступает как сетевое устройство для одного или нескольких терминалов доступа. В другом варианте реализации устройство может быть терминалом доступа.

[0015] В соответствии с одним примером, устройство может включать в себя интерфейс связи, соединенный со схемой обработки. Схема обработки может быть сконфигурирована для того, чтобы: (а) выполнять аутентификацию абонента с сетевым объектом; (b) выполнять аутентификацию устройства с сетевым объектом для упомянутого устройства; (с) генерировать защитный ключ, который связывает аутентификацию абонента и аутентификацию устройства; и/или (d) использовать защитный ключ, чтобы обезопасить связь между устройством и обслуживающей сетью.

[0016] В соответствии еще с одним примером, может быть обеспечен считываемый процессором носитель, содержащий инструкции, работающие в устройстве. Выполнение процессором этих инструкций может побуждать процессор: (а) выполнять аутентификацию абонента с сетевым объектом; (b) выполнять аутентификацию устройства с сетевым объектом для упомянутого устройства; (с) генерировать защитный ключ, который связывает аутентификацию абонента и аутентификацию устройства; и/или (d) использовать защитный ключ, чтобы обезопасить связь между устройством и обслуживающей сетью.

[0017] В соответствии еще с одним аспектом, обеспечен способ, работающий в сетевом объекте. Сетевой объект может принимать запрос на подключение от устройства, при этом запрос на подключение включает в себя индикацию возможностей аутентификации устройства у данного устройства. Сетевой объект может выполнять аутентификацию абонента с устройством. Также сетевой объект может выполнять аутентификацию устройства для упомянутого устройства. Затем сетевым объектом может генерироваться защитный ключ, который связывает аутентификацию абонента и аутентификацию устройства. Защитный ключ может использоваться, чтобы обезопасить связь между сетевым объектом и устройством. Следует отметить, что, для предотвращения передачи защитного ключа по беспроводной связи, защитный ключ может генерироваться отдельно устройством и сетевым объектом.

[0018] В одном примере аутентификация абонента может быть основана на обмене данными соглашения о ключе аутентификации между сетевым объектом и устройством. Аутентификация устройства может основываться на обмене данными по схеме «запрос-ответ» между сетевым объектом и устройством.

[0019] В одном варианте реализации аутентификация устройства может включать в себя: (а) прием сертификата от устройства; и (b) проверку сертификата, ассоциированного с устройством, на предмет того, что он не был аннулирован.

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

[0021] В соответствии с несколькими примерами, аутентификация абонента и аутентификация устройства могут выполняться одновременно при обменах комбинированными сообщениями, или аутентификация может осуществляться при более раннем и отдельном от аутентификации устройства защищенном обмене данными.

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

[0023] В одном варианте реализации сетевой объект может обладать специфическим для абонента ключом как частью соглашения на обслуживание. При этом специфический для абонента ключ используется для аутентификации абонента. Подобным образом сетевой объект может обладать специфическим для устройства ключом для устройства, при этом специфический для устройства ключ используется для аутентификации устройства.

[0024] В одном варианте реализации сетевой объект может содержать интерфейс связи, соединенный со схемой обработки. Схема обработки может быть сконфигурирована для того, чтобы: (а) выполнять аутентификацию абонента с устройством; (b) выполнять аутентификацию устройства для данного устройства; (с) генерировать защитный ключ, который связывает аутентификацию абонента и аутентификацию устройства; и/или (d) использовать защитный ключ, чтобы обезопасить связь между устройством и обслуживающей сетью.

[0025] В одном варианте реализации обеспечен считываемый процессором носитель, содержащий инструкции, работающие в устройстве. Выполнение процессором этих инструкций может побуждать процессор: (а) выполнять аутентификацию абонента с устройством; (b) выполнять аутентификацию устройства для данного устройства; (с) генерировать защитный ключ, который связывает аутентификацию абонента и аутентификацию устройства; и/или (d) использовать защитный ключ, чтобы обезопасить связь между сетевым объектом и устройством.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0026] Фиг. 1 представляет собой блок-схему, иллюстрирующую систему беспроводной связи, в которой различные типы беспроводных устройств могут аутентифицироваться базовой сетью для получения обслуживания.

[0027] Фиг. 2 иллюстрирует общий подход к связыванию аутентификации устройства и аутентификации абонента.

[0028] Фиг. 3 (содержащая фиг. 3А и фиг. 3В) иллюстрирует пример того, как иерархия ключей, основанная на аутентификации абонента, может быть модифицирована, чтобы добавить аутентификацию устройства.

[0029] Фиг. 4 иллюстрирует примерный стек протоколов, который может применяться в устройстве, работающем в сети с коммутацией пакетов.

[0030] Фиг. 5 представляет собой блок-схему, иллюстрирующую сетевую систему, в которой могут генерироваться различные аутентификационные и/или защитные ключи, проиллюстрированные на фиг. 3 и фиг. 4.

[0031] Фиг. 6 представляет собой блок-схему, иллюстрирующую выбранные компоненты беспроводного устройства, которые могут быть сконфигурированы, чтобы связывать аутентификацию абонента и аутентификацию устройства.

[0032] Фиг. 7 представляет собой блок-схему последовательности действий, иллюстрирующую пример способа, работающего в беспроводном устройстве, чтобы генерировать защитный ключ, который связывает аутентификацию абонента и аутентификацию устройства.

[0033] Фиг. 8 представляет собой блок-схему, иллюстрирующую выбранные компоненты сетевого объекта, которые могут быть сконфигурированы, чтобы связывать аутентификацию абонента и аутентификацию устройства.

[0034] Фиг. 9 представляет собой блок-схему последовательности действий, иллюстрирующую пример способа, работающего в сетевом объекте, чтобы генерировать защитный ключ, который связывает аутентификацию абонента и аутентификацию устройства.

[0035] Фиг. 10 иллюстрирует первый примерный способ генерации защитного ключа путем связывания аутентификации абонента и аутентификации устройства.

[0036] Фиг. 11 иллюстрирует второй примерный способ генерации защитного ключа путем связывания аутентификации абонента и аутентификации устройства.

[0037] Фиг. 12 иллюстрирует третий примерный способ генерации защитного ключа путем связывания аутентификации абонента и аутентификации устройства.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

[0038] В следующем описании представлены конкретные детали, чтобы обеспечить полное понимание описанных вариантов реализации. Однако специалистам в данной области техники будет понятно, что различные варианты реализации могут осуществляться без этих конкретных деталей. Например, схемы могут быть показаны в блок-схемах, чтобы не затруднять понимание вариантов реализации изобретения добавлением необязательных деталей. В других случаях хорошо известные схемы, структуры и технологии могут быть показаны детально, чтобы не затруднять понимание описанных вариантов реализации изобретения.

[0039] Слово «примерный» используется здесь в значении «служащий примером, частным случаем или иллюстрацией». Любой вариант реализации, описанный здесь как «примерный», не обязательно должен быть истолкован как предпочтительный или более выгодный по сравнению с другими вариантами реализации. Также термин «варианты реализации» не обязательно подразумевает, что все варианты реализации включают в себя рассмотренные признаки, преимущества или режимы работы.

КРАТКОЕ ОПИСАНИЕ

[0040] Обеспечен способ аутентификации между устройством (таким как клиентское устройство или терминал доступа) и сетевым объектом. Съемное запоминающее устройство может соединяться с устройством и хранить специфический для абонента ключ, который может использоваться для аутентификации абонента. Защищенное запоминающее устройство может соединяться с устройством и хранить специфический для абонента ключ, который может использоваться для аутентификации абонента. Аутентификация абонента может осуществляться между устройством и сетевым объектом. Аутентификация устройства для устройства также может выполняться с сетевым объектом. Затем может генерироваться защитный ключ, который связывает аутентификацию абонента и аутентификацию устройства. То есть ключ, данные и/или информация о процессе аутентификации абонента и ключ, данные и/или информация о процессе аутентификации устройства могут комбинироваться, чтобы генерировать (составной) защитный ключ. Защитный ключ может использоваться, чтобы обезопасить связь между устройством и обслуживающей сетью.

ПРИМЕРНАЯ СЕТЕВАЯ СРЕДА

[0041] Фиг. 1 представляет собой блок-схему, иллюстрирующую систему беспроводной связи, в которой различные типы беспроводных устройств могут аутентифицироваться базовой сетью для получения обслуживания. Эта система беспроводной связи может быть, например, легко стыкуемой или совместимой сетью универсальной системы мобильных телекоммуникаций (UMTS) или совместимой сетью глобальной системы мобильной связи (GSM) или совместимой сетью глобальной системы мобильной связи (GSM). Несмотря на то, что некоторые из описанных здесь примеров могут относиться к сети стандарта «Долгосрочное развитие сетей связи» (LTE), различные признаки, описанные здесь, могут быть применимы также и в других сетях.

[0042] Система может включать в себя одно или несколько устройств 101, таких как терминалы 103/104 доступа и ретрансляционный узел 102, которые поддерживают связь с узлом 106 доступа. Ретрансляционный узел 102 может способствовать осуществлению беспроводных передач между сетью 106/108 беспроводной связи и одним или несколькими терминалами 104 доступа. Система беспроводной связи (например, сеть стандарта «Долгосрочное развитие сетей связи» (LTE) сеть стандарта LTE-Advanced и т.д.) может содержать базовую сеть 108 и один или несколько узлов 106 доступа. Узел 106 доступа может соединяться с базовой сетью 108 посредством обратной линии (например, проводное соединение). Базовая сеть 108 может включать в себя, например, объекты 110 управления мобильной связью (ММЕ), сервер 112 домашних абонентов (HSS) и/или другие компоненты.

[0043] В одном примере объект 110 управления мобильной связью (ММЕ) может быть включен в активацию/деактивацию канала-носителя для устройства 101, ретрансляционного узла 102 и/или терминалов 103/104 доступа (здесь и далее в общем называемых «устройство») и поддержку аутентификации путем взаимодействия с сервером 112 домашних абонентов (HSS). ММЕ 110 также может генерировать и/или выделять временные идентификаторы для устройств (например, устройству 101, ретрансляционному узлу 102, терминалам 103/104 доступа и т.д.). Он может проверять авторизацию устройства, чтобы обустроиться (например, получить обслуживание, подсоединиться, установить линию связи) в сети наземной открытой мобильной связи (PLMN) и может обеспечивать соблюдение ограничений роуминга устройства. ММЕ 110 может быть конечной точкой в сети для защиты шифрования/целостности для сигнализации слоя, не связанного с предоставлением доступа (NAS), и автоматического управления защитными ключами. ММЕ 110 также может выполнять процедуры отслеживания и/или персонального вызова (включая повторные передачи) для устройств, соединенных с базовой сетью 108.

[0044] Сервер 112 домашних абонентов (HSS) представляет собой главную абонентскую базу данных, которая поддерживает сетевые объекты, фактически управляющие устройствами. Она может содержать связанную с абонентской подпиской информацию (профили абонентов), аутентификацию оказания помощи и авторизацию подписки, и может предоставлять информацию о местонахождении абонента. Это схоже с реестром домашнего положения (HLR) GSM и центром аутентификации (AuC). Реестр домашнего положения (HLR) может быть базой данных, содержащей детали о каждом абоненте, авторизованном для использования базовой сети. HLR может содействовать AuC в аутентификации абонентов (то есть использовании абонентских терминалов).

[0045] Ретрансляционный узел 102 может быть конфигурирован, чтобы усиливать и/или повторять сигнал между терминалом 104 доступа и узлом 106 доступа. В общем, ретрансляционный узел 102 может выступать для терминала 104 доступа в качестве узла доступа (AN) и может выступать для узла 106 доступа в качестве терминала доступа (АТ). Например, ретрансляционный узел 102 может включать в себя интерфейс 105 терминала доступа, посредством которого он поддерживает связь с узлом 106 доступа, и может также включать в себя интерфейс 107 узла доступа, посредством которого он поддерживает связь с терминалом 104 доступа. То есть, интерфейс 105 терминала доступа может способствовать тому, что ретрансляционный узел будет выступать как терминал доступа для узла 106 доступа. Подобным образом, интерфейс 107 узла доступа может способствовать тому, что ретрансляционный узел 102 будет выступать как узел доступа для терминала 104 доступа. В некоторых вариантах реализации ретрансляционный узел 102 может переводить сигналы из первого формата во второй формат между интерфейсом 105 терминала доступа и интерфейсом 107 узла доступа. Ретрансляционный узел 102 может размещаться вблизи границ сот так, что терминал 104 доступа может поддерживать связь с ретрансляционным узлом 102 вместо того, чтобы связываться напрямую с узлом 106 доступа.

[0046] В системах радиосвязи сота представляет собой географическую зону покрытия приема и передачи. Соты могут перекрываться друг на друга. В типичном примере существует один узел доступа, связанный с каждой сотой. Размер соты определяется такими факторами, как полоса частот, уровень мощности и условия канала. Ретрансляционные узлы, такие как ретрансляционный узел 102, могут использоваться, чтобы увеличивать покрытие внутри или около соты или чтобы увеличить размер покрытия соты. Кроме того, использование ретрансляционного узла 102 может увеличить пропускную способность сигнала внутри соты, поскольку терминал 104 доступа может иметь доступ к ретрансляционному узлу 102 с более высокой скоростью передачи данных и более низкой мощностью передачи, нежели при связи терминала 104 доступа напрямую с узлом 106 доступа для этой соты. Передача с более высокой скоростью передачи данных способствует более высокой эффективности использования спектра, а более низкая мощность способствует, например, понижению потребления терминалом 104 доступа мощности батареи.

[0047] В некоторых примерах ретрансляционный узел 102 может быть реализовать согласно одному из трех типов ретрансляционного узла: ретрансляционный узел первого уровня, ретрансляционный узел второго уровня и/или ретрансляционный узел третьего уровня. Ретрансляционный узел первого уровня по существу представляет собой повторитель, который может повторно передавать передачу без какой-либо модификации, отличной от усиления и небольшой задержки. Ретрансляционный узел второго уровня может декодировать передачу, которую принимает, перекодировать результат декодирования и затем передавать перекодированные данные. Ретрансляционный узел третьего уровня может иметь возможность полного контроля над радиоресурсом и, таким образом, может работать подобно узлу доступа. Протоколы управления радиоресурсом, используемые ретрансляционным узлом, могут быть такими же, как и те, что используются узлом доступа, и ретрансляционный узел может иметь уникальный идентификатор соты, обычно используемый узлом доступа. В целях ясности, в этом описании ретрансляционный узел 102 отличается от узла 106 доступа тем, что может полагаться на присутствие по меньшей мере одного узла 106 доступа (и соты, связанной с узлом доступа) или другого ретрансляционного узла, чтобы получать доступ к другим компонентам в телекоммуникационной системе (например, сети 108). То есть ретрансляционный узел 102 может выступать как абонентское устройство, клиентское устройство или терминал доступа в отношении сети, следовательно, он соединяется с узлом доступа, чтобы осуществлять сообщение по сети 108. Однако для других абонентских устройств, пользовательских устройств и/или терминалов 104 доступа ретрансляционный узел 102 может выступать как сетевое устройство (например, узел доступа). Следовательно, ретрансляционный узел 102 может задействовать один или несколько интерфейсов связи, чтобы поддерживать связь с узлом доступа и/или одним или несколькими терминалами доступа/абонента/пользователя. В одном примере один и тот же передатчик/приемник (например, один или несколько беспроводных каналов) может использоваться ретрансляционным узлом 102, чтобы поддерживать связь со своим узлом доступа и/или одним или несколькими терминалами доступа. В другом примере ретрансляционный узел 102 может использовать два или более различных передатчиков/приемников, чтобы поддерживать связь с узлом доступа и/или одним или несколькими терминалами доступа.

[0048] Чтобы подавить неправильное применение подписки для доступа к услугам сети, устройства могут связывать аутентификацию устройства с аутентификацией абонента. Аутентификация устройства может действовать вместе с, например, стандартной 3GPP AKA (соглашение об аутентификации и ключах) аутентификацией доступа, основанной на учетных данных (таких как корневой ключ К абонента), хранящихся на универсальной карте 109, 111, 113 и 116 на основе интегральной микросхемы (UICC) или на универсальном модуле идентификации абонента (например, USIM), соединенном с устройством с возможностью разъединения. В некоторых вариантах реализации аутентификация устройства может выполняться с помощью тех же сообщений слоя, не связанного с предоставлением доступа (NAS), которые используются для АКА аутентификации. Таким образом, устройство (например, ретрансляционный узел 102, терминалы 103/104 доступа и т.д.) может быть связано со своей подпиской (то есть, подпиской на обслуживание с базовой сетью 108), чтобы предотвратить использование третьими лицами учетных данных абонента (то есть для услуги подписки) на неавторизованном устройстве.

[0049] Одно решение проблемы, связанной с риском неавторизованного использования учетных данных абонента, обеспечено для устройства (например, устройства 101, ретрансляционного узла 102 или терминалов 103/104 доступа и т.д.) и UICC 109, чтобы взаимно аутентифицировать друг друга (например, с использованием защищенного канала между главным устройством и UICC), но это может требовать предварительного обеспечения UICC 109, 111, 113 и 116 и/или главного устройства (например, устройства 101, ретрансляционного узла 102 или терминалов 103/104 доступа и т.д.) информацией, чтобы осуществить такую взаимную аутентификацию.

[0050] Другое решение может требовать того, чтобы ключи, используемые для сетевого доступа (например, ключи, используемые для защиты трафика между устройством и сетью), зависели как от учетных данных, хранящихся на UICC 109, 111, 113 и 116, так и от учетных данных, хранящихся на устройстве (например, на устройстве 101, ретрансляционном узле 102 или терминалах 103/104 доступа). Это может быть реализовано посредством связывания ключей АКА аутентификации с аутентификацией устройства каким-либо образом. Это решение также актуально в случае с аутентификацией международного идентификатора мобильного оборудования (IMEI) (которая, например, может позволить оператору прекратить подсоединение неавторизованных устройств к их сети). Причина этого в том, что, путем связывания ключа(ей) от АКА аутентификации, используемой для сетевого доступа, и ключей, используемых для аутентификации устройства, обеспечивается уверенность в том, что все сообщения, исходящие от устройства к сети 108, действительно исходят из устройства, которое было аутентифицировано. При предположении, что связанные ключи (и все другие последующие ключи, полученные из связанного ключа) безопасно хранятся на устройстве (например, устройстве 101, ретрансляционном узле 102 или терминалах 103/104 доступа), связывание ключей от АКА аутентификации с аутентификацией устройства обеспечивает большую защиту по сравнению с использованием для аутентификации устройства только механизма, основанного на схеме «запрос-ответ». Использование только механизма, основанного на схеме «запрос-ответ» для аутентификации устройства лишь доказывает, что настоящее устройство было доступно, чтобы сгенерировать ответ аутентификации, но не то, что оно остается настоящим в дальнейшем.

[0051] Фиг. 2 иллюстрирует общий подход к связыванию аутентификации устройства и аутентификации абонента. Устройство 202 (например, устройство 101, ретрансляционный узел 102 или терминалы 103/104 доступа) может быть обеспечено корневым_ключом_абонента 206 и/или идентификатором_абонента 207, которые могут использоваться, чтобы аутентифицировать подписку с базовой сетью 108 и/или генерировать защитные ключи, используемые для доступа к зашифрованному трафику, отправленному к устройству 202. Корневой_ключ_абонента 206 может быть уникальным образом ассоциирован с идентификатором_абонента 207. В одном примере корневой_ключ_абонента 206 и/или идентификатор_абонента 207 могут храниться на UICC 204, и/или аутентификация абонента может обрабатываться UICC 204. Подобным образом, устройство 202 может быть обеспечено корневым_ключом_устройства 208 и/или идентификатором 209 устройства (или хранит их), которые могут использоваться, чтобы аутентифицировать устройство с базовой сетью 108. Корневой_ключ_устройства 206 может быть уникальным образом ассоциирован с идентификатором 209 устройства.

[0052] В одном примере идентификатор_устройства 209 может быть международным идентификатором мобильного оборудования (IMEI) устройства 202 (например, устройства 101, ретрансляционного узла 102 или терминалов 103/104 доступа), но другие формы идентификации в отношении устройства (например, адреса оборудования IEEE, как то EUI-48 EUI-64) также могут использоваться.

[0053] В некоторых вариантах реализации корневой_ключ_устройства 206 может быть секретным ключом, совместно используемым устройством 202 только с базовой сетью 108, но не передаваемым по беспроводной связи. Идентификатор_устройства 209 может передаваться устройством 202 к базовой сети 108 так, что она может получить корректный корневой ключ устройства, предназначенный для аутентификации устройства. В качестве альтернативы корневой_ключ_устройства 206 может быть открытым ключом пары «открытый/секретный ключ», когда сертификаты используются для аутентификации устройства. Например, устройство может принимать некоторые данные от сети, причем данные зашифрованы с помощью открытого ключа. Затем устройство может использовать свой секретный ключ, чтобы дешифровать зашифрованные данные и впоследствии доказать сети, что он осведомлен об этих данных. Сертификат (например, учетные данные устройства) может быть проверен базовой сетью 108. Соответствующий секретный ключ устройства 202 может безопасно храниться на устройстве 202. Учетные данные устройства могут как относиться к сертификату устройства, так и быть ссылкой на него. Эти учетные данные устройства могут позволять релевантному сетевому объекту формировать запрос_устройства и проверять статус отмены устройства 202 (например, проверять, не являются ли учетные данные, такие как секретный ключ или совместно используемый ключ, относящиеся к устройству, рассекреченными). Дополнительно предполагается, что защищенная часть устройства (такая как безопасная среда, или TrE, как определено в техническом описании 33.320 3GPP) хранит конфиденциальные ключи устройства, такие как корневой_ключ_устройства и/или секретный ключ, относящийся к сертификату. Кроме того, предполагается, что TrE выполняет все криптографические операции, что задействуют эти ключи.

[0054] В начале, аутентификация абонента может иметь место между устройством 202 и базовой сетью 108. Например, обмен 210 данными соглашения об аутентификации и ключах (АКА) между устройством 202 и сетью 108 может привести к установлению ключа K_ASME. Такой обмен 210 данными АКА может быть основан, например, на корневом_ключе_абонента 206 и/или идентификаторе_абонента 207, чтобы аутентифицировать абонента, ассоциированного с устройством 202. Например, такая информация о подписке или учетные данные могут безопасно храниться на UICC 204, которая соединена с главным устройством 202 с возможностью отсоединения.

[0055] Сеть 108 также может осуществлять аутентификацию устройства на устройстве 202. Идентификатор_устройства 209 может быть предоставлен в базовую сеть 108 устройством 202 так, что базовая сеть 108 может выполнять поиск, чтобы получить корректный соответствующий корневой_ключ_устройства 206. Сеть 108 может создавать запрос_устройства 212 и отправляет его на устройство 202 (например, как часть релевантного NAS сообщения). В ответ устройство 202 вычисляет ответ_устройства 214 (например, основанный на запросе_устройства и корневом_ключе_устройства 208 или их производной) и возвращает его к сети 108. Устройство 202 также может использовать данные при запросе_устройства и ответе_устройства, чтобы вычислить составной защитный ключ K_ASME_D 216. Следует отметить, что в случае с устройством 202 составной защитный ключ K_ASME_D 216 может генерироваться как до отправки ответа_устройства 214, так и после нее. В одном примере составной защитный ключ K_ASME_D 216 может быть эквивалентным ключом по отношению к защитному ключу K_ASME, определенному в выделенной универсальной сети наземного радиодоступа E-UTRAN (E-UTRAN), определенной в техническом описании 33.401 3GPP, за исключением того, что ключ K_ASME_D связан с идентификатором 209 устройства, как и с ключом, получаемым в результате аутентификации АКА, таким как ключ K_ASME. Если сеть 108 принимает действительный запрос_устройства, она также вычисляет составной защитный ключ K_ASME_D 218.

[0056] Вычисление запроса_устройства 212, ответа_устройства 214 и составного защитного ключа K_ASME_D может быть следующим. Запрос_устройства 212 может быть вычислен следующим образом:

Device_challenge=eKSI, [(E_device_root_key (device_temp_key)], network_nonce

(Запрос_устройства=eKSI, [E_корневой_ключ_устройства (временный_ключ_устройства)], одноразовое_слово_шифрования_сети), где

eKSI - это идентификатор выделенного/расширенного набора ключей, который связан с K_ASME_D, [..] обозначает необязательный параметр, E_k(data) обозначает данные, зашифрованные с помощью ключа k, и одноразовое_слово_шифрования_сети - случайное число подходящего размера (например, 128-бит), выбранное сетью. Алгоритм шифрования может быть как асимметричным (в случае если корневой_ключ_устройства - открытый ключ, ассоциированный с сертификатом устройства), так и симметричным (в случае если корневой_ключ_устройства - совместно используемый ключ). Временный_ключ_устройства может быть ключом, получаемым или генерируемым как часть аутентификации устройства. В одном примере временный_ключ_устройства может быть выбран (например, случайно) сетью 108, отправляется на устройство 202 в зашифрованном виде и обладает подходящей длиной (например, 256- или 128-битное значение).

[0057] И устройство 202, и сеть 108 могут хранить временный_ключ_устройства среди сетевых доступов в целях оптимизации. Если это не так, второй параметр ([(E_device_root_key (device_temp_key)]) в запросе 212 устройства не является факультативным.

[0058] Ответ_устройства 214 может быть вычислен так:

Device_response=device_nonce, device_res

(Ответ_устройства=одноразовое_слово_шифрования_устройства, res_устройства), где

Одноразовое_слово_шифрования_устройства - произвольное число подходящего размера (например, 128-бит), выбранное устройством и

Device_res=KDF (device_temp_key, network_nonce, device_nonce), где

(Res_устройства=KDF (временный_ключ_устройства, одноразовое_слово_шифрования_сети, одноразовое_слово_шифрования_устройства)), где

KDF - криптографическая функция от, подходящая для генерации ответа res_устройства.

[0059] С учетом получения, ранее, ключа аутентификации K_ASME (например, как части обмена 210 данными АКА) вычисление составного защитного ключа K_ASME_D 216 и 218 (то есть связывание аутентификации устройства и аутентификации абонента) может осуществляться следующим образом:

K_ASME_D=KDF (device_temp_key, K_ASME, network_nonce, device_nonce)

(K_ASME_D=KDF (временный_ключ_устройства, K_ASME, одноразовое_слово_шифрования_сети, одноразовое_слово_шифрования_устройства)), где

K_ASME может быть ключом или значением, полученным во время аутентификации абонента между устройством и сетью (в результате обмена 210 данными аутентификации АКА). В одном примере ключ K_ASME может быть ключом, ранее сгенерированным и/или использованным между устройством 202 и сетью 108. В качестве альтернативы, если процесс 212 и 214 аутентификации устройства осуществляется с использованием тех же сообщений NAS, что и сообщения NAS, применяемые для процедуры 210 АКА, ключ K_ASME может быть заново или одновременно сгенерирован. Подобным образом временный_ключ_устройства может быть ключом или значением, полученным во время аутентификации устройства между устройством 202 и сетью 108.

[0060] Составной защитный ключ далее может использоваться как основа и/или корень для вычисления дополнительных защитных ключей 217 и 219. Дополнительные защитные ключи могут служить для защиты, например связи уровня NAS и/или уровня AS.

[0061] Составной защитный ключ K_ASME_D, соответствующие ему параметры защиты и все ключи, выведенные от K_ASME_D, могут безопасно содержаться на устройстве 202 и не хранятся на UICC 204. Составной защитный ключ K_ASME_D затем может использоваться для защиты сообщений, обмен 220 которыми происходит между устройством 202 и базовой сетью 108.

[0062] Фиг. 3 (содержащая фиг. 3А и фиг. 3В) иллюстрирует пример того, как иерархия ключей, основанная на аутентификации абонента, может быть модифицирована, чтобы также включать в себя аутентификацию устройства. Иерархия ключей может применяться, чтобы установить параметры защиты (например, защитный ключ) для использования при сообщении шифрования/дешифрования между устройством и сетью. В этом примере аутентификация абонента и устройства может выполняться между устройством 322 и сетевым объектом 324. Устройство 322 может быть, например, терминалом доступа (АТ), пользовательским устройством (UE), мобильным телефоном и/или ретрансляционным узлом. Сетевой объект 324 может представлять собой одно или несколько сетевых устройств, таких как объект управления мобильной связью (ММЕ) и/или сервер домашних абонентов (HSS).

[0063] Этот пример иллюстрирует, как первая иерархия 300 ключей, основанная на аутентификации абонента, модифицируется, чтобы получить вторую иерархию 300’ ключей, основанную и на аутентификации абонента, и на аутентификации устройства.

[0064] В целях аутентификации абонента, как показано в первой иерархии 300 ключей, универсальная карта на основе интегральной микросхемы (UICC на устройстве 322) и сетевой объект 324 (например, ММЕ 110, HSS 112 на фиг. 1 или другой сетевой объект) может использовать главный ключ К 302, чтобы генерировать ключ 304 к шифру (СК) и ключ 306 целостности (IK). Ключ 304 к шифру (СК) и ключ 306 целостности (IK) затем могут использоваться устройством 322 и сетевым объектом 324 как часть обмена данными соглашения об аутентификации и ключах (АКА), чтобы генерировать ключ объекта управления безопасностью доступа K_ASME 308 (также упоминаемый здесь как ключ аутентификации абонента). Активация защиты устройства 202 может быть выполнена посредства процедуры соглашения об аутентификации и ключах (АКА), процедуры конфигурации безопасного режима (NAS SMC) слоя, не связанного с предоставлением доступа (NAS), и процедуры конфигурации безопасного режима (AS SMC) слоя, связанного с предоставлением доступа (AS).

[0065] В этом примере аутентификация абонента может включать в себя обмен 326 данными АКА, в результате которого получается K_ASME 308. Обмен 326 данными АКА может включать в себя запрос 340 аутентификации абонента и ответ 342 аутентификации абонента. В этом примере процесс аутентификации абонента, который генерирует ключ K_ASME 308, может также генерировать соответствующие ключи уровня NAS (K_NAS-enc 305 и K_NAS-int 311) и/или ключи уровня AS (K_UP-enc 315, K_RRC-enc 317 и K_RRC-int 319). Следует отметить, что в некоторых вариантах реализации, если эти версии ключей уровня NAS и ключей уровня AS не используются, далее генерация этих ключей может быть пропущена во время аутентификации абонента.

[0066] Вторая иерархия 300’ ключей иллюстрирует то, как аутентификация устройства может быть связана с аутентификацией абонента, чтобы генерировать защитные ключи уровня NAS и уровня AS. Во время, до или после аутентификации абонента (и генерации ее соответствующего ключа K_ASME 308) аутентификация 328 устройства может выполняться на основе (по меньшей мере частично) специфического для устройства корневого ключа. Аутентификация 328 устройства может включать в себя запрос 344 аутентификации устройства и ответ 346 аутентификации устройства. В одном варианте реализации аутентификация 307 устройства может быть независима от аутентификации абонента; только если и аутентификация абонента, и аутентификация устройства удовлетворены, составной защитный ключ K_ASME_D 309 генерируется. В альтернативном варианте реализации аутентификация устройства может выполняться до аутентификации абонента.

[0067] Составной защитный ключ K_ASME_D 309 может использоваться как базовый ключ для вычисления, например ключей 310 и 312 NAS (слоя, не связанного с предоставлением доступа), и ключей 314, 316, 318 и 320 AS (слоя, связанного с предоставлением доступа). То есть устройство 322 и сетевой объект 324 затем могут использовать ключ K_ASME_D 309, чтобы генерировать один или несколько защитных ключей.

[0068] Сети с коммутацией пакетов могут быть структурированы на множество иерархических уровней протокола, где более низкие уровни протокола обеспечивают обслуживание слоев более высокого уровня и каждый слой отвечает за выполнение различных задач. Например, фиг. 4 иллюстрирует примерный стек протоколов, который может применяться в устройстве, работающем в сети с коммутацией пакетов. В этом примере стек 402 протоколов включает в себя физический (PHY) уровень 404, уровень 406 управления доступом к среде (MAC), уровень 408 управления линией радиосвязи (RLC), уровень 410 протокола конвергенции пакетных данных (PDCP), уровень 412 управления радиоресурсами (RRC), уровень 414 слоя, не связанного с предоставлением доступа (NAS), и уровень 416 приложений (APP).

[0069] Уровни ниже Уровня 414 NAS зачастую именуются уровнем 418 слоя, связанного с предоставлением доступа (AS). Уровень 408 RLC может включать в себя один или несколько каналов 420. Уровень 412 RRC может использовать различные режимы слежения для терминала доступа, включая состояние соединения и состояние незанятости. Уровень 414 слоя, не связанного с предоставлением доступа (NAS) может поддерживать контекст управления мобильностью, контекст пакетных данных и/или IP-адреса устройства связи. Следует отметить. Что другие уровни могут присутствовать в стеке 402 протоколов (например, выше, ниже проиллюстрированных уровней или между ними), но были опущены в иллюстративных целях.

[0070] Со ссылкой на фиг. 4, сеансы/радио каналы-носители 422 могут быть установлены, например, на уровне 412 RRC и/или на уровне 414 NAS. Следовательно, уровень 414 NAS может использоваться устройством 202 и базовой сетью 108, чтобы генерировать защитные ключи 310 K_NAS-enc и 312 K_NAS-int, показанные на фиг. 3. Подобным образом, уровень 412 RRC может использоваться устройством 202 и базовой сетью 108, чтобы генерировать защитные ключи 316 K_UP-enc, 318 K_RRC-enc и 320 K_RRC-int слоя, связанного с предоставлением доступа (AS). Когда защитные ключи 316 K_UP-enc, 318 K_RRC-enc и 320 K_RRC-int могут генерироваться на уровне 312 RRC, они могут использоваться уровнем 410 PDCPP, чтобы обезопасить сигнальное сообщение и/или сообщение «пользователь/данные». Например, ключ 316 K_UP-enc может использоваться уровнем 410 PDCPP, чтобы обезопасить сообщение плоскости пользователя/данных (UP), тогда как ключи 318 K_RRC-enc и 320 K_RRC-int могут использоваться чтобы обезопасить сигнальное сообщение (например, управление) на уровне 410 PDCPP.

[0071] В производной от этих защитных ключей, используемых для алгоритмов шифрования и целостности, и AS (плоскость пользователя и RRC), и NAS требуют, чтобы был обеспечен индивидуальный идентификатор алгоритма в качестве одного из вводов. На уровне AS алгоритмы, которые будут использоваться, обеспечиваются командой безопасного режима управления радиоресурсами (RRC).

[0072] Фиг. 5 представляет собой блок-схему, иллюстрирующую сетевую систему, в которой могут генерироваться различные аутентификационные и/или защитные ключи, проиллюстрированные на фиг. 3 и фиг. 4. Здесь устройство 322 может использовать стек связи, включающий в себя различные уровни (например, APP, NAS, RRC, RLC, MAC и PHY). Сеть 504 доступа (например, узел 106 доступа на фиг. 1) может обеспечивать возможность беспроводной связи с устройством 322 так, что оно может поддерживать связь с сетью 108. Сервер 506 домашних абонентов и устройство 322 могут знать или иметь доступ к корневому ключу (К), который может использоваться, чтобы генерировать или получить ключ к шифру (СК) и/или ключ целостности (IK). Устройство 322 и/или HSS 506 затем могут использовать ключ к шифру (СК) и/или ключ целостности (IK), чтобы генерировать ключ объекта управления безопасностью доступа K_ASME. Аутентификация устройства также может выполняться в комбинации (с) или на основе ключа K_ASME, чтобы генерировать составной защитный ключ K_ASME_D, объединяя, таким образом, аутентификацию абонента и устройства в один ключ. Используя ключ K_ASME_D, устройство 322 и объект 510 управления мобильностью (ММЕ) затем могут генерировать ключи K_NAS-enc и K_NAS-int. Устройство 322 и ММЕ 510 также могут генерировать специфический для сети доступа ключ K_eNB/NH. Используя этот специфический для сети доступа ключ, устройство 322 и ММЕ 510 могут генерировать ключи K_eNB/NH K_UP-enc K_RRC-enc K_RRC-int.

[0073] Подробности относительно производной от этих ключей обеспечены в STD-T63-33.401 3GPP, в Релизе 8 «Развитие архитектуры системы (SAE): архитектура системы безопасности» (известен как 3GPP TS 33.401), который включен сюда посредством ссылки. Следует отметить, что фиг. 3-5 описывают конкретную среду/конкретный контекст, в которых аутентификация и связывание абонента и устройства могут осуществляться, это не должно ограничивать данный признак, который может быть применим в различных типах сетей.

ПРИМЕРНОЕ БЕСПРОВОДНОЕ УСТРОЙСТВО

[0074] Фиг. 6 представляет собой блок-схему, иллюстрирующую выбранные компоненты беспроводного устройства 600, которые могут быть сконфигурированы, чтобы связывать аутентификацию абонента и аутентификацию устройства. Беспроводное устройство 600 в общем включает в себя схему 602 обработки, соединенную с одним или несколькими интерфейсами 604 беспроводной связи. Например, беспроводное устройство 600 может быть ретрансляционным узлом и/или терминалом доступа.

[0075] Схема 602 обработки может быть сконфигурирована, чтобы получать, обрабатывать и/или отправлять данные, контролировать хранение данных и доступ к ним, отдавать команды и контролировать другие заданные операции. Схема 602 обработки может содержать схемы, сконфигурированные, чтобы осуществлять желаемое программирование, обеспечиваемое с помощью подходящего носителя в по меньшей мере одном варианте реализации. Например, схема 602 обработки может применяться как один или несколько процессоров, контроллеров, множество процессоров и/или другая структура, сконфигурированная, чтобы реализовывать выполняемые команды, включая, например, команды программного и/или программно-аппаратного обеспечения, и/или схем аппаратного обеспечения. Варианты реализации схемы 602 обработки могут включать в себя процессор общего назначения, цифровой сигнальный процессор (DSP), специализированную интегральную схему (ASIC), программируемую пользователем вентильную матрицу (FPGA) или другой программируемый логический компонент, выделенные вентильные или транзисторные логические схемы, выделенные компоненты аппаратного обеспечения или любую из комбинаций перечисленных компонентов, чтобы выполнять описанные здесь функции. Процессор общего назначения может быть микропроцессором, но, в качестве альтернативы, процессор может быть любым стандартным процессором, контроллером, микроконтроллером или конечным автоматом. Процессор также может применяться как комбинация вычислительных компонентов, как то комбинация DSP и микропроцессора, некоторого количества микропроцессоров, одного или нескольких микропроцессоров совместно с ядром DSP или любая другая такая конфигурация. Эти примеры схемы 602 обработки представлены для иллюстрации, и другие подходящие конфигурации в рамках настоящего описания также предполагаются.

[0076] Интерфейс 604 беспроводной связи может быть сконфигурирован так, чтобы обеспечивать осуществление беспроводной связи беспроводным устройством 600. Например, интерфейс 604 беспроводной связи может быть сконфигурирован, чтобы сообщать информацию двунаправленно в отношении других беспроводных устройств, таких как терминалы доступа, узлы доступа, другие ретрансляционные узлы и т.д. Интерфейс 604 беспроводной связи может быть соединен с антенной (не показано) и может включать в себя беспроводные схемы приемопередатчика, включающие в себя по меньшей мере один передатчик и/или по меньшей мере один приемник (например, одну или несколько приемопередающих цепей) для беспроводной связи.

[0077] Схема 602 обработки может включать в себя модуль 610 связывания аутентификации абонента и устройства. Модуль 610 связывания аутентификации абонента и устройства может содержать схемы и/или программные средства, адаптированные, чтобы выполнять процедуры аутентификации абонента с использованием абонентских защитных учетных данных (например, специфический для абонента ключ 607 и/или идентификатор 609 абонента, хранимые на универсальной карте 608 на основе интегральной микросхемы), адаптированные, чтобы выполнять (в пределах безопасной среды 606) процедуры аутентификации устройства с использованием защитных учетных данных устройства (например, специфический для устройства ключ 605 и/или идентификатор 611 устройства), и связывать вместе аутентификации абонента и устройства. Такое «связывание» может включать комбинирование некоторых результатов от аутентификации абонента и аутентификации устройства. Например, первый защитный ключ, полученный при аутентификации абонента, может комбинироваться со вторым защитным ключом, полученным при аутентификации устройства, чтобы получить третий (составной) защитный ключ.

[0078] В некоторых вариантах реализации беспроводное устройство 600 может включать в себя безопасную (доверенную) среду (TrE) 606. Безопасная среда 606 может быть адаптирована для того, чтобы удовлетворять техническим условиям для безопасной среды согласно деталям описания TS 33.320 3GPP. Безопасная среда 606 может быть предварительно обеспечена (или безопасно дополнена) по меньшей мере некоторыми защитными учетными данными (например, специфический для устройства ключ 605 и/или идентификатор 611 устройства). К примеру, безопасная среда 606 может иметь защитные учетные данные, связанные с аутентификацией устройства.

[0079] В некоторых вариантах реализации беспроводное устройство 600 может включать в себя защищенную обработку в пределах универсальной карты 608 на основе интегральной микросхемы (UICC). UICC 608 может соединяться с беспроводным устройством 600 с возможностью отсоединения. UICC 608 может быть предварительно обеспечена защитными учетными данными (например, специфический для абонента ключ 607 и/или идентификатор 609 абонента), как то учетные данные соглашения об аутентификации и ключах (АКА). В качестве альтернативы защищенная обработка может выполняться в пределах универсального модуля идентификации абонента (USIM).

[0080] В соответствии с одним или несколькими признаками беспроводного устройства 600, схема 602 обработки может быть сконфигурирована, чтобы выполнять любые из процессов, функций, этапов и/или стандартных операций, связанных с проиллюстрированными на фиг. 2-5, 7, 10, 11 и 12. Здесь термин «сконфигурирована» в отношении схемы 602 обработки может обозначать, что схема 602 обработки конфигурируется, используется, применяется и/или программируется, чтобы выполнять конкретный процесс, функцию, этап и/или стандартную операцию в соответствии с различными признаками, описанными здесь.

[0081] Фиг. 7 представляет собой блок-схему, иллюстрирующую пример способа, работающего в беспроводном устройстве, чтобы генерировать защитный ключ, который связывает аутентификацию абонента и аутентификацию устройства. Беспроводное устройство может быть предварительно обеспечено специфическим для устройства ключом (этап 702). Например, такой специфический для устройства ключ может быть встроен в чип или сконфигурирован при производстве беспроводного устройства. Беспроводное устройство также может включать в себя идентификатор устройства, ассоциированный со специфическим для устройства ключом. Кроме того, беспроводное устройство может быть предварительно обеспечено специфическим для абонента ключом (этап 704). Например, такой специфический для абонента ключ может быть корневым ключом, назначенным для абонента, и может храниться внутри фиксированного или съемного модуля (например, UICC или USIM), соединенного с беспроводным устройством. Беспроводное устройство может также включать в себя идентификатор подписки, ассоциированный со специфическим для абонента ключом. Беспроводное устройство может выполнять аутентификацию абонента с сетевым объектом (например, используя специфический для абонента ключ) (этап 706). Это может включать в себя, например, обмен данными соглашения об аутентификации и ключах с сетевым объектом. Беспроводное устройство также может выполнять аутентификацию устройства с сетевым объектом (например, используя специфический для устройства ключ) (этап 708). Аутентификация абонента и аутентификация устройства могут осуществляться в одно и то же или в разное время с одним и тем же или с разными сетевыми объектами. Защитный ключ (например, K_ASME_D и т.д.) затем может генерироваться беспроводным устройством, причем такой защитный ключ связывает аутентификацию абонента и аутентификацию устройства (этап 710). Так, в одном примере данные (например, один или несколько полученных в результате ключей, сертификатов, идентификаторов и т.д.) от аутентификации устройства и данные (например, один или несколько полученных в результате ключей, сертификатов, идентификаторов и т.д.) от аутентификации абонента могут комбинироваться, чтобы генерировать защитный ключ. Например, на фиг. 1 ключ K_ASME от аутентификации 210 абонента в временный_ключ_устройства от аутентификации устройства на фиг. 1 могут комбинироваться, чтобы генерировать защитный ключ K_ASME_D. Затем защитный ключ может использоваться, чтобы обезопасить беспроводную связь между беспроводным устройством и сетевым объектом (этап 712). Например, защитный ключ может использоваться, чтобы генерировать другие ключи и/или сертификаты (например, защитные ключи уровня NAS и/или уровня AS), которые могут применяться для шифровки/дешифровки связи (например, данных или сигналов) между беспроводным устройством и сетью.

ПРИМЕРНЫЙ СЕТЕВОЙ ОБЪЕКТ

[0082] Фиг. 8 представляет собой блок-схему, иллюстрирующую компоненты сетевого объекта 800, который может быть сконфигурирован, чтобы связывать аутентификацию абонента и аутентификацию устройства. Сетевой объект 800 может включать в себя схему 802 обработки, соединенную с интерфейсом 804 связи. Схема 802 обработки может быть сконфигурирована, чтобы получать, обрабатывать и/или отправлять данные, контролировать хранение данных и доступ к ним, отдавать команды и контролировать другие заданные операции. Схема 802 обработки может содержать схемы, сконфигурированные, чтобы осуществлять желаемое программирование, обеспечиваемое с помощью подходящего носителя в по меньшей мере одном варианте реализации. Например, схема 802 обработки может применяться как один или несколько процессоров, контроллеров, множество процессоров и/или другая структура, сконфигурированная так, чтобы реализовывать выполняемые команды, включая, например, команды программного и/или программно-аппаратного обеспечения, и/или схем аппаратного обеспечения. Варианты реализации схемы 802 обработки могут включать в себя процессор общего назначения, цифровой сигнальный процессор (DSP), специализированную интегральную схему (ASIC), программируемую пользователем вентильную матрицу (FPGA) или другой программируемый логический компонент, выделенные вентильные или транзисторные логические схемы, выделенные компоненты аппаратного обеспечения или любую из комбинаций перечисленных компонентов, чтобы выполнять описанные здесь функции. Процессор общего назначения может быть микропроцессором, но, в качестве альтернативы, процессор может быть любым стандартным процессором, контроллером, микроконтроллером или конечным автоматом. Процессор также может применяться как комбинация вычислительных компонентов, как то комбинация DSP и микропроцессора, некоторого количества микропроцессоров, одного или нескольких микропроцессоров совместно с ядром DSP или любая другая такая конфигурация. Эти примеры схемы 802 обработки представлены для иллюстрации, и другие подходящие конфигурации также предполагаются входящими в объем настоящего изобретения.

[0083] Схема 802 обработки может включать в себя модуль 806 связывания аутентификации абонента и устройства. Модуль 806 связывания аутентификации абонента и устройства может содержать схемы и/или программные средства, адаптированные, чтобы выполнять процедуры для аутентификации абонента на основе абонентских защитных учетных данных (например, специфический для абонента ключ и/или идентификатор абонента), выполнять процедуры для аутентификации устройства на основе защитных учетных данных устройства (например, специфический для устройства ключ и/или идентификатор устройства) и связывать данные (например, ключи, значения, сертификаты и т.д.) от аутентификации абонента и аутентификации устройства, чтобы генерировать защитный ключ.

[0084] Интерфейс 804 связи сконфигурирован, чтобы способствовать осуществлению связи устройства сетевого объекта 800 как напрямую, так и не напрямую (например, посредством одного или нескольких сетевых объектов), с другими устройствами, такими как ретрансляционные узлы и терминалы доступа.

[0085] В соответствии с одним или несколькими признаками сетевого объекта 800, схема 802 обработки может быть сконфигурирована, чтобы выполнять любые из процессов, функций, этапов и/или стандартных операций, связанных с различными сетевыми объектами, такими как объект 110 управления мобильностью (ММЕ) и сервер 112 домашних абонентов (HSS). Кроме того, сетевой объект 800 может содержать один объект или комбинацию из двух и более объектов сети. В качестве неограничивающего примера сетевой объект 800 может содержать объект управления мобильностью (ММЕ), сервер домашних абонентов (HSS), сервер аутентификации устройств среди прочих. Здесь термин «сконфигурирована» в отношении схемы 802 обработки может обозначать, что схема 802 обработки конфигурируется, используется, применяется или программируется (происходит одно из этих действий или более), чтобы выполнять конкретный процесс, функцию, этап и/или стандартную операцию в соответствии с различными признаками, описанными здесь.

[0086] Фиг. 9 представляет собой блок-схему, иллюстрирующую пример способа, работающего в сетевом объекте, чтобы генерировать защитный ключ, который связывает аутентификацию абонента и аутентификацию устройства. Сетевой объект может содержать специфический для устройства ключ для беспроводного устройства (этап 902). Например, такой специфический для устройства ключ может быть встроен в чип или сконфигурирован при производстве беспроводного устройства, и эта информация может храниться в базе данных, к которой сетевой объект имеет доступ. Идентификатор устройства может быть ассоциирован со специфическим для устройства ключом и может использоваться, чтобы идентифицировать устройство и его ключ. Кроме того, сетевой объект может быть предварительно обеспечен специфическим для абонента ключом, ассоциированным с подпиской для беспроводного устройства (этап 904). Например, такой специфический для абонента ключ может быть корневым ключом, назначенным для абонента, и может храниться внутри фиксированного или съемного модуля (например, UICC или USIM), соединенного с беспроводным устройством. Сетевой объект может также выполнять аутентификацию абонента с беспроводным устройством (например, используя специфический для абонента ключ) (этап 906). Это может включать в себя, например, обмен данными соглашения об аутентификации и ключах с сетевым объектом. Сетевой объект также может выполнять аутентификацию устройства с беспроводным устройством (например, используя специфический для устройства ключ) (этап 908). Аутентификация абонента и аутентификация устройства могут осуществляться в одно и то же или в разное время. Защитный (составной) ключ (например, K_ASME_D и т.д.) затем может генерироваться сетевым объектом, причем такой защитный ключ связывает аутентификацию абонента и аутентификацию устройства (этап 910). Так, в одном примере данные (например, один или несколько полученных в результате ключей, сертификатов, идентификаторов и т.д.) от аутентификации устройства и данные (например, K_ASME и т.д.) от аутентификации абонента могут комбинироваться, чтобы генерировать защитный ключ. Затем защитный ключ может использоваться, чтобы обезопасить беспроводную связь между беспроводным устройством и сетевым объектом (этап 712). Например, защитный ключ может использоваться, чтобы генерировать другие ключи и/или сертификаты, которые могут применяться для шифровки/дешифровки связи между беспроводным устройством и сетью.

ПЕРВЫЙ ПРИМЕРНЫЙ СПОСОБ АУТЕНТИФИКАЦИИ АБОНЕНТ-УСТРОЙСТВО

[0087] Фиг. 10 иллюстрирует первый примерный способ генерации защитного ключа путем связывания аутентификации абонента и аутентификации устройства. В этом примере устройство 1002 может быть ретрансляционным узлом или терминалом доступа, например. Во время стадии присоединения, когда устройство 1102 может стремиться присоединиться к беспроводной сети (например, которая включает в себя ММЕ 1002 и HSS 1006), раскрывая идентификатор устройства или другую связанную с устройством информацию по беспроводной связи, может возникнуть проблема безопасности (например, для устройства 1002). Следовательно, в этом способе устройство 1002 не предоставляет свои учетные данные (например, специфический для устройства идентификатор, как то международный идентификатор мобильного оборудования (IMEI) и т.д.) по беспроводной связи до тех пор, пока они не будут запрошены сетью безопасным способом. Это делается с целью предотвращения пассивных атак на идентификатор устройства.

[0088] Устройство может начать работу путем отправки сети запроса 1010 присоединения, включающего в себя индикацию, что оно способно осуществлять аутентификацию устройства. По получении запроса 1010 присоединения объект 104 управления мобильностью (ММЕ) может запрашивать и принимать информацию 1012 о подписке и аутентификации (например, связанную с аккаунтом подписки или пользователем устройства 1002) от сервера 1006 домашних абонентов (HSS). ММЕ 1004 затем отправляет запрос 1014 аутентификации, который включает в себя АКА запрос с целью выполнить АКА аутентификацию. По получении запроса 1014 АКА аутентификации устройство 1002 отправляет ответ 1016 аутентификации, включающий в себя АКА ответ. Запрос 1014 АКА аутентификации и ответ 1016 используются для выполнения аутентификации подписки. Такие процедуры АКА аутентификации могут привести к получению ключа аутентификации абонента (например, K_ASME), генерируемого устройством 1002 и ММЕ.

[0089] Аутентификация устройства может осуществляться на различных стадиях во время процесса активации защиты. В этом примере аутентификация устройства может прикрепляться сзади к сообщениям безопасности уровня NAS. Например, устройство 1004 может отправлять команду 1018 безопасного режима NAS, которая включает в себя запрос об идентификации устройства (например, запрос версии программного обеспечения IMEI (IMEISV) и/или запрос учетных_данных_устройства). В ответ устройство 1002 может предоставлять идентификатор устройства или учетные данные, в пределах сообщения 1020 «безопасный режим - выполнен» о том, что должна выполняться аутентификация устройства. Следует отметить, что, дабы избежать раскрытия идентификатора устройства или учетных данных во время передачи по беспроводной связи, идентификатор устройства или учетные данные на этапе 1020 «безопасный режим - выполнен» могут быть защищены вычисленным ранее ключом аутентификации абонента (например, K_ASME). По получении идентификатора устройства или учетных данных ММЕ 1004 может отправлять сообщение запроса 1022 об идентификации, с идентификатором выделенного/расширенного набора ключей (eKSI) и запросом_устройства. eKSI может быть ассоциирован с K_ASME_D, подлежащим генерации. Так, eKSI, используемый в запросе 1022 об идентификации, может быть отличным от любого другого eKSI, который мог бы использоваться, например, для АКА (то есть аутентификации абонента). По получении сообщения запроса 1022 об идентификации устройство 1002 может генерировать ответ_устройства, основанный на запросе_устройства, и отправляет его как часть сообщения ответа 1024 об идентификации. Ответ_устройства может основываться на запросе_устройства и на идентификационном номере устройства или учетных данных. Устройство 1002 затем может вычислить (составной) защитный ключ (K_ASME_D) 1025, основанный на данных ключе аутентификации (например, K_ASME) и данных аутентификации устройства (например, ответ устройства и т.д.). ММЕ 1004 проверяет ответ_устройства, например, путем использования идентификатора устройства или сертификата устройства 1002 и использования запроса_устройства. Если устройство 1002 успешно аутентифицируется посредством ММЕ 1004, ММЕ 1004 также генерирует защитный ключ (K_ASME_D) 1027. На этой стадии устройство 1002 и ММЕ 1004 совместно используют защитный ключ (K_ASME_D) и относящийся к нему идентификатор eKSI.

[0090] ММЕ 1004 далее может отправлять команду 1026 безопасного режима с идентификатором развитого/расширенного набора ключей (eKSI), относящимся к защитному ключу (K_ASME_D). Это позволяет устройству 1002 вычислить один или несколько защитных ключей на основе защитного ключа (K_ASME_D). Устройство 1002 может отправлять сообщение 1028 «безопасный режим-выполнен» на ММЕ 1004, позволяя, таким образом, ММЕ 1004 отправлять сообщение 1030 «присоединение выполнено».

ВТОРОЙ ПРИМЕРНЫЙ СПОСОБ АУТЕНТИФИКАЦИИ АБОНЕНТА-УСТРОЙСТВА

[0091] Фиг. 11 иллюстрирует второй примерный способ генерации защитного ключа путем связывания аутентификации абонента и аутентификации устройства. В этом примере при раскрытии идентификатора устройства или сертификата (или другой информации, связанной с учетными данными) по беспроводной связи может возникнуть проблема безопасности. В отличие от способа по фиг. 10, в этом случае предполагается, что предварительное предоставление идентификатора устройства не приведет ни к каким проблемам и рискам в вопросах конфиденциальности.

[0092] Устройство уже имеет идентификатор устройства или учетные данные (например, IMEI), которые будут приняты ММЕ, но не имеет контекста безопасности E-UTRAN, который желателен для использования ММЕ.

[0093] Устройство 1102 отправляет запрос 1108 присоединения, включающий в себя идентификатор устройства или учетные данные, к ММЕ 1004. ММЕ 1004 может получать информацию 1110 о подписке и аутентификации от сервера 1106 домашних абонентов (HSS) и отправляет запрос 1112 аутентификации, который включает в себя АКА запрос (для аутентификации подписки) и/или запрос устройства (для аутентификации устройства). Следует отметить, что устройство 1102 может отвечать путем отправки ответа 1114 аутентификации, который может включать в себя АКА ответ и/или ответ устройства. АКА ответ может быть основан, по меньшей мере частично, на идентификаторе абонента. Ответ устройства может основываться на идентификаторе устройства и/или учетных данных и запросе устройства. Устройство 1104 затем может генерировать (составной) защитный ключ K_ASME_D путем комбинирования информации об аутентификации абонента и информации об аутентификации устройства. Подобным образом, после успешной проверки АКА ответа и ответа устройства, ММЕ 1104 также может генерировать защитный ключ K_ASME_D путем комбинирования информации об аутентификации абонента и информации об аутентификации устройства.

[0094] ММЕ отправляет команду 1116 безопасного режима, чтобы начать использование безопасного контекста, основанного на защитном ключе K_ASME_D. Устройство 1102 отвечает посредством сообщения 1118 «безопасный режим - выполнен». То есть устройство 1102 и ММЕ 1104 могут генерировать один или несколько дополнительных защитных ключей (или иначе защищать сообщение между устройством 1102 и ММЕ 1104), используя защитный ключ K_ASME_D. ММЕ 1104 затем может отправлять сообщение 1120 «присоединение выполнено» на устройство 1102.

[0095] Здесь необходимо отметить, что если идентификатор устройства и/или учетные данные (или ранее полученные/сгенерированные ключи устройства) хранились на HSS 1106 или другом сервере в сети с идентификатором подписки, то устройство 1102 могло бы использовать эту последовательность действий, чтобы выполнить присоединение. Чтобы осуществить это, устройство 1102 может обозначить (например, в запросе 1108 присоединения), что его идентификатор устройства и/или учетные данные могут быть получены от HSS 1106 или другого сетевого сервера. В качестве альтернативы ММЕ 1104 может обозначить для устройства 1102, что запрос_устройства связан с конкретным идентификатором устройства (например, включая идентификатор устройства, такой как IMEI, вместе с запросом_устройства в некоторой форме). Таким образом, устройство 1102 может знать, что запрос устройства (в запросе 1112 аутентификации) ассоциирован с его идентификатором устройства.

ТРЕТИЙ ПРИМЕРНЫЙ СПОСОБ АУТЕНТИФИКАЦИИ АБОНЕНТА-УСТРОЙСТВА

[0096] Фиг. 12 иллюстрирует третий примерный способ генерации защитного ключа путем связывания аутентификации абонента и аутентификации устройства. В этом примере аутентификация абонента была ранее выполнена, так что контекст 1206 безопасности абонента (например, ключ K_ASME) уже имеется. Комбинированная аутентификация абонента и устройства может быть инициирована сетью, чтобы заменить существующий контекст безопасности. Вариант реализации может быть полезным для устройств, которым могло бы понадобиться установление основанного на АКА контекста безопасности, чтобы получить полноценные и действующие учетные данные от оператора.

[0097] Этот подход предполагает, что ММЕ уже знает идентификатор устройства (например, IMEI) и/или учетные_данные_устройства.

[0098] ММЕ 1204 отправляет запрос 1208 аутентификации в устройство 1202, включающий в себя запрос_устройства. В ответ устройство 1202 отправляет ответ 1210 аутентификации в ММЕ 1204, включающий в себя ответ_устройства. Ответ_устройства может основываться на запросе_устройства и идентификаторе устройства и/или сертификате. На этой стадии и устройство 1202, и ММЕ 1204 могут иметь достаточно информации, чтобы вычислить (составной) защитный ключ K_ASME_D (например, на базе основанного на АКА контекста безопасности и информации об аутентификации).

[0099] ММЕ 1204 может отправлять команду 1212 безопасного режима NAS, чтоб заменить существующий контекст безопасности 1206 на контекст, основанный на новом защитном ключе K_ASME_D (например, который включает в себя как аутентификацию абонента, так и аутентификацию устройства). В ответ устройство 1202 может генерировать новый контекст безопасности, основанный на защитном ключе K_ASME_D, и может отправлять сообщение 1214 «безопасный режим NAS - выполнен» в ответ.

[0100] Следует отметить, что хотя различные примеры здесь иллюстрируют, что как аутентификация абонента, так и аутентификация устройства могут выполняться посредством ММЕ, другие сетевые объекты также могут выполнять некоторые из этих функций в комбинации с ММЕ или вместо него.

[0101] Один или несколько компонентов, этапов, признаков и/или функций, проиллюстрированных на фиг. 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 и/или 12, могут быть перераспределены и/или комбинированы в один компонент, этап, признак или функцию, реализуемую(-ый) в нескольких компонентах, этапах или функциях. Дополнительные элементы, компоненты, этапы и/или функции также могут быть добавлены, не выходя за объем настоящего изобретения. Аппараты, устройства и/или компоненты, проиллюстрированные на фиг. 1, 5, 6 и/или 8, могут быть сконфигурированы так, чтобы реализовывать один или несколько способов, признаков или этапов, описанных на фиг. 2, 3, 4, 7 и/или 9-12. Новые алгоритмы, описанные здесь, также могут эффективно реализовываться в программном обеспечении и/или аппаратном обеспечении.

[0102] Также следует отметить, что по меньшей мере несколько вариантов реализации были описаны как процессы, изображенные в виде блок-схемы последовательности операций или структурной диаграммы. Хотя блок-схема может описывать операции как последовательный процесс, многие из операций могут выполняться параллельно или одновременно друг с другом. Кроме того, порядок операций может быть изменен. Процесс завершается, когда его операции будут выполнены. Процесс может соответствовать способу, функции, процедуре, подпрограмме и т.д. Когда процесс соответствует функции, его завершение соответствует возвращению функции к вызывающей функции или главной функции.

[0103] Кроме того, варианты реализации могут реализовываться аппаратным обеспечением, программным обеспечением, программно-аппаратным обеспечением, промежуточным программным обеспечением, микропрограммами или комбинацией перечисленных программ. При реализации в аппаратном обеспечении, программном обеспечении, программно-аппаратном обеспечении, промежуточном программном обеспечении или микропрограммах, программный код или кодовые сегменты для выполнения необходимых задач могут храниться на машиночитаемом носителе, таком как носитель данных или другое запоминающее устройство (запоминающие устройства). Процессор может выполнять необходимые задачи. Кодовый сегмент может представлять собой процедуру, функцию, подпрограмму, программу, стандартную операцию, модуль, пакет программ, класс или любую комбинацию команд, структур данных или операторов программы. Кодовый сегмент может быть соединен с другим кодовым сегментом или схемой аппаратного обеспечения посредством передачи и/или приема информации, данных, аргументов, параметров или содержимого памяти. Информация, аргументы, параметры, данные и т.д. могут переноситься, переадресовываться или передаваться с помощью подходящих средств, включая совместное использование памяти, передачу сообщений, сетевую передачу и т.д.

[0104] Термины «машиночитаемый носитель», «пригодный для ввода в компьютер носитель» или «считываемый процессором носитель» могут включать в себя, но не ограничиваться этим, портативные или стационарные запоминающие устройства, оптические запоминающие устройства и другие различные не временные носители, способные хранить, содержать или переносить команду (команды) и/или данные. Таким образом, различные способы, описанные здесь, могут частично или полностью реализовываться командами и/или данными, которые могут храниться на «машиночитаемом носителе», «пригодном для ввода в компьютер носителе» или «считываемом процессором носителе», и осуществляться одним или несколькими процессорами, машинами и/или устройствами.

[0105] Способы или алгоритмы, описанные в связи с раскрытыми здесь примерами, могут реализовываться напрямую в аппаратном обеспечении, в модуле программного обеспечения, выполняемом процессором, или их комбинации в виде блока обработки, команд программирования или других команд и могут содержаться на одном устройстве или могут быть распределены по нескольким устройствам. Модуль программного обеспечения может находиться в памяти RAM, флэш-памяти, ROM-памяти, EPROM-памяти, EEPROM-памяти, регистрах, на жестком диске, съемном диске, CD-ROM или любом другом не временном носителе данных, известном в данной области техники. Носитель данных может быть соединен с процессором так, что процессор может считывать информацию с носителя данных и записывать информацию на него. В качестве альтернативы, носитель данных может быть частью процессора.

[0106] Специалисты в данной области техники смогут также понять, что различные иллюстративные логические блоки, модули, схемы и этапы алгоритмов, описанные в связи с раскрытыми здесь вариантами реализации, могут применяться как электронное аппаратное обеспечение, компьютерное программное обеспечение или их комбинация. Чтобы четко продемонстрировать взаимозаменяемость аппаратного обеспечения и программного обеспечения, различные иллюстративные компоненты, блоки, модули, схемы и этапы были описаны выше в общем на основе своей функциональности. Осуществляется ли такая функциональность в качестве аппаратного обеспечения или программного обеспечения, зависит от конкретного приложения и проектных ограничений, наложенных на всю систему.

[0107] Различные признаки изобретения, описанные здесь, могут применяться в различных системах, не выходя за рамки изобретения. Следует отметить, что вышеупомянутые варианты реализации представляют собой лишь примеры и не должны быть истолкованы как ограничивающие изобретение. Описание вариантов реализации имеет целью быть иллюстративным и не ограничивающим объем изобретения. Как таковые настоящие идеи могут легко применяться в отношении устройств других типов, и множество их альтернатив, модификаций и вариаций будут понятны специалистам в данной области техники.

1. Способ, осуществляемый в устройстве для связывания аутентификации абонента и аутентификации устройства, содержащий этапы, на которых:

выполняют аутентификацию абонента на сетевом объекте на основе ключа аутентификации абонента;

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

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

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

2. Способ по п. 1, в котором аутентификация абонента выполняется первым сервером аутентификации, который является частью сетевого объекта, а аутентификация устройства выполняется вторым сервером аутентификации, который является частью сетевого объекта.

3. Способ по п. 1, в котором аутентификация устройства выполняется посредством:

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

использования соответствующего секретного ключа, чтобы расшифровать зашифрованные данные; и

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

4. Способ по п. 1, дополнительно содержащий этап, на котором:

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

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

6. Способ по п. 1, в котором аутентификация абонента и аутентификация устройства выполняются одновременно в обменах сообщениями, при которых аутентификация абонента и аутентификация устройства комбинируются.

7. Способ по п. 1, в котором аутентификация абонента выполняется в более раннем и отдельном от аутентификации устройства защищенном обмене данными.

8. Способ по п. 1, в котором защитный ключ генерируется в зависимости от, по меньшей мере, первого ключа, полученного при аутентификации абонента, и второго ключа, полученного при аутентификации устройства.

9. Способ по п. 1, в котором упомянутое устройство представляет собой ретрансляционный узел, который выступает как терминал доступа к сетевому объекту, а также выступает как сетевое устройство для одного или нескольких терминалов доступа.

10. Способ по п. 1, в котором защитный ключ генерируется по отдельности устройством и сетевым объектом.

11. Способ по п. 1, дополнительно содержащий:

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

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

12. Способ по п. 1, в котором данные аутентификации устройства включают в себя зашифрованный параметр, полученный из временного ключа устройства, одноразового слова шифрования сети и одноразового слова шифрования устройства.

13. Способ по п. 1, в котором запрос включает в себя идентификатор, при этом способ дополнительно включает в себя этапы, на которых:

принимают команду от сетевого объекта, которая включает в себя идентификатор; и

генерируют дополнительные защитные ключи на основе защитного ключа и идентификатора.

14. Способ по п. 1, в котором аутентификация устройства выполняется после аутентификации абонента.

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

16. Устройство связывания аутентификации абонента и аутентификации устройства, содержащее:

интерфейс связи; и

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

выполнять аутентификацию абонента на сетевом объекте на основе ключа аутентификации абонента;

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

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

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

17. Устройство по п. 16, в котором аутентификация устройства выполняется посредством:

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

использования соответствующего секретного ключа, чтобы расшифровать зашифрованные данные; и

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

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

19. Устройство по п. 16, в котором защитный ключ генерируется в зависимости от, по меньшей мере, первого ключа, полученного при аутентификации абонента, и второго ключа, полученного при аутентификации устройства.

20. Устройство по п. 16, в котором данные аутентификации устройства включают в себя зашифрованный параметр, полученный из временного ключа устройства, одноразового слова шифрования сети и одноразового слова шифрования устройства.

21. Устройство связывания аутентификации абонента и аутентификации устройства, содержащее:

средство для выполнения аутентификации абонента на сетевом объекте на основе ключа аутентификации абонента;

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

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

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

22. Устройство по п. 21, дополнительно содержащее:

средство для хранения уникального для абонента ключа, используемого для аутентификации абонента; и

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

23. Устройство по п. 21, в котором данные аутентификации устройства включают в себя зашифрованный параметр, полученный из временного ключа устройства, одноразового слова шифрования сети и одноразового слова шифрования устройства.

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

выполнять аутентификацию абонента на сетевом объекте на основе ключа аутентификации абонента;

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

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

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

25. Постоянный считываемый процессором носитель по п. 24, при этом данные аутентификации устройства включают в себя зашифрованный параметр, полученный из временного ключа устройства, одноразового слова шифрования сети и одноразового слова шифрования устройства.

26. Способ, осуществляемый в сетевом объекте для связывания аутентификации абонента и аутентификации устройства, содержащий этапы, на которых:

выполняют аутентификацию абонента на устройстве на основе ключа аутентификации абонента;

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

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

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

27. Способ по п. 26, в котором аутентификация устройства включает в себя:

прием сертификата от устройства;

проверку сертификата, ассоциированного с устройством, на предмет того, что он не был аннулирован.

28. Способ по п. 26, дополнительно содержащий этап, на котором:

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

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

30. Способ по п. 26, в котором аутентификация абонента и аутентификация устройства выполняются одновременно в комбинированных обменах сообщениями, при которых аутентификация абонента и аутентификация устройства комбинируются.

31. Способ по п. 26, в котором аутентификация абонента выполняется в более раннем и отдельном от аутентификации устройства защищенном обмене данными.

32. Способ по п. 26, в котором защитный ключ генерируется в зависимости от, по меньшей мере, первого ключа, полученного при аутентификации абонента, и второго ключа, полученного при аутентификации устройства.

33. Способ по п. 26, в котором защитный ключ генерируется по отдельности устройством и сетевым объектом.

34. Способ по п. 26, дополнительно содержащий:

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

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

35. Способ по п. 26, в котором данные аутентификации устройства включают в себя зашифрованный параметр, полученный из временного ключа устройства, одноразового слова шифрования сети и одноразового слова шифрования устройства.

36. Способ по п. 26, в котором запрос включает в себя идентификатор, при этом способ дополнительно включает в себя этапы, на которых:

передают команду сетевому объекту, которая включает в себя идентификатор; и

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

37. Способ по п. 26, в котором аутентификация устройства выполняется после аутентификации абонента.

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

39. Сетевой объект для связывания аутентификации абонента и аутентификации устройства, содержащий:

интерфейс связи; и

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

выполнять аутентификацию абонента на устройстве на основе ключа аутентификации абонента;

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

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

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

40. Сетевой объект по п. 39, в котором аутентификация абонента и аутентификация устройства выполняются одновременно в обменах комбинированными сообщениями, при которых аутентификация абонента и аутентификация устройства комбинируются.

41. Сетевой объект по п. 39, в котором аутентификация абонента выполняется в более раннем и отдельном от аутентификации устройства защищенном обмене данными.

42. Сетевой объект по п. 39, в котором защитный ключ генерируется в зависимости от, по меньшей мере, первого ключа, полученного при аутентификации абонента, и второго ключа, полученного при аутентификации устройства.

43. Сетевой объект по п. 39, дополнительно содержащий:

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

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

44. Сетевой объект по п. 39, в котором данные аутентификации устройства включают в себя зашифрованный параметр, полученный из временного ключа устройства, одноразового слова шифрования сети и одноразового слова шифрования устройства.

45. Сетевой объект для связывания аутентификации абонента и аутентификации устройства, содержащий:

средство для выполнения аутентификации абонента на устройстве на основе ключа аутентификации абонента;

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

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

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

46. Сетевой объект по п.45, в котором данные аутентификации устройства включают в себя зашифрованный параметр, полученный из временного ключа устройства, одноразового слова шифрования сети и одноразового слова шифрования устройства.

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

выполнять аутентификацию абонента на устройстве на основе ключа аутентификации абонента;

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

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

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

48. Постоянный считываемый процессором носитель по п. 47, при этом данные аутентификации устройства включают в себя зашифрованный параметр, полученный из временного ключа устройства, одноразового слова шифрования сети и одноразового слова шифрования устройства.