СПОСОБ, УСТРОЙСТВО И СИСТЕМА ДЛЯ ОБНОВЛЕНИЯ ПРИВЯЗОЧНОГО КЛЮЧА В СЕТИ СВЯЗИ ДЛЯ ЗАШИФРОВАННОЙ СВЯЗИ С ПРИЛОЖЕНИЯМИ ПРЕДОСТАВЛЕНИЯ УСЛУГ Российский патент 2023 года по МПК H04L9/08 H04W12/43 

Область техники, к которой относится изобретение

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

Уровень техники

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

Сущность изобретения

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

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

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

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

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

Краткое описание чертежей

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

Фиг. 2 показывает примерные сетевые функции или сетевые узлы в сети связи.

Фиг. 3 показывает примерные сетевые функции или сетевые узлы в сети беспроводной связи.

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

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

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

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

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

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

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

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

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

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

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

Подробное описание изобретения

Примерная сеть связи, показанная как 100 на фиг. 1, может включать в себя терминальные устройства 110 и 112, сеть 102 оператора услуг связи, различные приложения 140 предоставления услуг и другие сети 150 передачи данных. Сеть 102 оператора услуг связи, например, может включать в себя сети 120 доступа и базовую сеть 130. Сеть 102 оператора услуг связи может быть выполнена с возможностью передавать голос, данные и другую информацию (совместно называется "трафиком данных") между терминальными устройствами 110 и 112, между терминальными устройствами 110 и 112 и приложениями 140 предоставления услуг либо между терминальными устройствами 110 и 112 и другими сетями 150 передачи данных. Сеансы связи и соответствующие тракты передачи данных могут устанавливаться и конфигурироваться для такой передачи данных. Сети 120 доступа могут быть выполнены с возможностью предоставлять терминальным устройствам 110 и 112 сетевой доступ к базовой сети 130. Базовая сеть 130 может включать в себя различные сетевые узлы или сетевые функции, выполненные с возможностью управлять сеансами связи и выполнять управление сетевым доступом и маршрутизацию трафика данных. Приложения 140 предоставления услуг могут размещаться посредством различных серверов приложений, которые являются доступными посредством терминальных устройств 110 и 112 через базовую сеть 130 сети 102 оператора услуг связи. Приложение 140 предоставления услуги может развертываться в качестве сети передачи данных за пределами базовой сети 130. Аналогично, другие сети 150 передачи данных могут быть доступными посредством терминальных устройств 110 и 112 через базовую сеть 130 и могут появляться в качестве либо назначения данных, либо источника данных конкретного сеанса связи, экземпляр которого создан в сети 102 оператора услуг связи.

Базовая сеть 130 по фиг. 1 может включать в себя различные сетевые узлы или функции, географически распределенные и взаимосвязанные с возможностью предоставлять покрытие сети области предоставления услуг сети 102 оператора услуг связи. Эти сетевые узлы или функции могут реализовываться как выделенные аппаратные сетевые элементы. Альтернативно, эти сетевые узлы или функции могут виртуализироваться и реализовываться в качестве виртуальных машин или в качестве программных объектов. Сетевой узел может быть сконфигурирован с одним или более типов сетевых функций. Эти сетевые узлы или сетевые функции могут совместно предоставлять функциональности инициализации и маршрутизации базовой сети 130. Термин "сетевые узлы" и "сетевые функции" используется взаимозаменяемо в этом раскрытии.

Фиг. 2 дополнительно показывает примерное разделение сетевых функций в базовой сети 130 сети 200 связи. Хотя только отдельные экземпляры сетевых узлов или функций проиллюстрированы на фиг. 2, специалисты в данной области техники должны понимать, что каждый из этих сетевых узлов может подвергаться созданию нескольких экземпляров сетевых узлов, которые распределяются по всей базовой сети 130. Как показано на фиг. 2, базовая сеть 130 может включать в себя, но не только, сетевые узлы, такие как сетевой узел 230 управления доступом (AMNN), сетевой узел 260 аутентификации (AUNN), сетевой узел 270 управления сетевыми данными (NDMNN), сетевой узел 240 управления сеансами (SMNN), сетевой узел 250 маршрутизации данных (DRNN), сетевой узел 220 управления политиками (PCNN) и сетевой узел 210 управления данными приложений (ADMNN). Примерный обмен служебными сигналами и данными между различными типами сетевых узлов через различные интерфейсы связи указывается посредством различных сплошных соединительных линий на фиг. 2. Такой обмен служебными сигналами и данными может переноситься посредством сообщений со служебными сигналами или с данными согласно предварительно определенным форматам или протоколам.

Реализации, описанные выше на фиг. 1 и 2, могут применяться к системам беспроводной и проводной связи. Фиг. 3 иллюстрирует примерную сеть 300 сотовой беспроводной связи на основе общей реализации сети 200 связи по фиг. 2. Фиг. 3 показывает то, что сеть 300 беспроводной связи может включать в себя абонентское устройство 310 (UE) (функционирующее в качестве терминального устройства 110 по фиг. 2), сеть 320 радиодоступа (RAN) (функционирующую в качестве сети 120 доступа по фиг. 2), приложения 140 предоставления услуг, сеть 150 передачи данных (DN) и базовую сеть 130, включающую в себя функцию 330 управления доступом (AMF) (функционирующую в качестве AMNN 230 по фиг. 2), функцию 340 управления сеансами (SMF) (функционирующую в качестве SMNN 240 по фиг. 2), функцию 390 уровня приложений (AF) (функционирующую в качестве ADMNN 210 по фиг. 2), функцию 350 пользовательской плоскости (UPF) (функционирующую в качестве DRNN 250 по фиг. 2), функцию 322 управления политиками (функционирующую в качестве PCNN 220 по фиг. 2), функцию 360 сервера аутентификации (AUSF) (функционирующую в качестве AUNN 260 по фиг. 2) и функцию 370 универсального управления данными (UDM) (функционирующую в качестве UDMNN 270 по фиг. 2). С другой стороны, хотя только отдельные экземпляры для некоторых сетевых функций или узлов сети 300 беспроводной связи (базовой сети 130, в частности) проиллюстрированы на фиг. 3, специалисты в данной области техники должны понимать, что каждый из этих сетевых узлов или функций может иметь несколько экземпляров, которые распределяются по всей сети 300 беспроводной связи.

На фиг. 3, UE 310 может реализовываться как различные типы мобильных устройств, которые выполнены с возможностью осуществлять доступ к базовой сети 130 через RAN 320. UE 310 может включать в себя, но не только, мобильные телефоны, переносные компьютеры, планшетные компьютеры, устройства с поддержкой стандарта Интернета вещей (IoT), распределенные сенсорные сетевые узлы, носимые устройства и т.п. RAN 320, например, может включать в себя множество базовых радиостанций, распределенных по всем зонам обслуживания сети оператора услуг связи. Связь между UE 310 и RAN 320 может переноситься в радиоинтерфейсах (OTA), как указано посредством 311 на фиг. 3.

Продолжая с фиг. 3, UDM 370 может формировать устройство долговременного хранения данных либо базу данных для данных пользовательских договоров и подписок. UDM дополнительно может включать в себя функцию репозитория и обработки аутентификационных учетных данных (ARPF, как указано в 370 по фиг. 3) для хранения долговременных учетных данных системы безопасности для аутентификации пользователей и для использования таких долговременных учетных данных системы безопасности в качестве ввода, чтобы выполнять вычисление ключей шифрования, как подробнее описано ниже. Чтобы предотвращать неавторизованное раскрытие UDM/ARPF-данных, UDM/ARPF 370 может быть расположена в защищенном сетевом окружении сетевого оператора или третьей стороны.

AMF/SEAF 330 может обмениваться данными с RAN 320, SMF 340, AUSF 360, UDM/ARPF 370 и PCF 322 через интерфейсы связи, указываемые посредством различных сплошных линий, соединяющих эти сетевые узлы или функции. AMF/SEAF 330 может регулировать UE на предмет управления передачей служебных сигналов на не связанном с предоставлением доступа уровне (NAS) и для инициализации регистрации и доступа UE 310 относительно базовой сети 130, а также выделения SMF 340 для того, чтобы поддерживать потребность в связи конкретного UE. AMF/SEAF 330 дополнительно может регулировать управление мобильностью UE. AMF также может включать в себя функцию привязки безопасности (SEAF, как указано в 330 по фиг. 3), которая, как подробнее описано ниже, взаимодействует с AUSF 360 и UE 310 для аутентификации пользователей и управления различными уровнями ключей шифрования/дешифрования. AUSF 360 может завершать запросы на пользовательскую регистрацию/аутентификацию/формирование ключей из AMF/SEAF 330 и взаимодействовать с UDM/ARPF 370 для выполнения такой пользовательской регистрации/аутентификации/формирования ключей.

SMF 340 может выделяться посредством AMF/SEAF 330 для конкретного сеанса связи, экземпляр которого создан в сети 300 беспроводной связи. SMF 340 может регулировать выделение UPF 350 для того, чтобы поддерживать сеанс связи и потоки данных в нем в плоскости пользовательских данных, а также инициализацию/упорядочение выделяемой UPF 350 (например, для формулирования правил обнаружения и перенаправления пакетов для выделяемой UPF 350). Альтернативно выделению посредством SMF 340, UPF 350 может выделяться посредством AMF/SEAF 330 для конкретного сеанса связи и потоков данных. UPF 350, выделяемая и инициализированная посредством SMF 340 и AMF/SEAF 330, может регулировать маршрутизацию и перенаправление данных и формирование сообщений использования сети посредством конкретного сеанса связи. Например, UPF 350 может регулировать маршрутизацию сквозных потоков данных между UE 310 и DN 150, между UE 310 и приложениями 140 предоставления услуг. DN 150 и приложения 140 предоставления услуг могут включать в себя, но не только, сеть передачи данных и услуги, предоставляемые посредством оператора сети 300 беспроводной связи либо посредством сторонней сети передачи данных и поставщиков услуг.

Приложения 140 предоставления услуг могут управляться и инициализироваться посредством AF 390, например, через функции обеспечения доступа к сети, предоставленные посредством базовой сети 130 (не показано на фиг. 3, но показывается на фиг. 7, который описывается ниже). SMF 340, при управлении конкретным сеансом связи, заключающим в себе приложение 140 предоставления услуги (например, между UE 310 и приложением 140 предоставления услуги), может взаимодействовать с AF 390, ассоциированной с приложением 140 предоставления услуги, через интерфейс связи, указываемый посредством 313.

PCF 322 может регулировать управление и предоставление различных уровней политик и правил, применимых к сеансу связи, ассоциированному с UE 310, для AMF/SEAF 330 и SMF 340. В связи с этим, AMF/SEAF 330, например, может назначать SMF 340 для сеанса связи согласно политикам и правилам, ассоциированным с UE 310 и полученным из PCF 322. Аналогично, SMF 340 может выделять UPF 350, чтобы обрабатывать маршрутизацию и перенаправление данных сеанса связи согласно политикам и правилам, полученным из PCF 322.

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

Идентификация сети и безопасность данных в сети 300 беспроводной связи по фиг. 3 могут управляться через процессы аутентификации пользователей, предоставленные посредством AMF/SEAF 330, AUSF 360 и UDM/ARPF 370. В, в частности, UE 310 может сначала обмениваться данными с AMF/SEAF 330 для регистрации в сети и затем может аутентифицироваться посредством AUSF 360 согласно данным пользовательских договоров и подписок в UDM/ARPF 370. Сеансы связи, устанавливаемые для UE 310 после аутентификации пользователей в сети 300 беспроводной связи, затем могут защищаться посредством различных уровней ключей шифрования/дешифрования. Формирование и управление различными ключами могут оркестроваться посредством AUSF 360 и других сетевых функций в сети связи.

Аутентификация UE 310 в сети 300 беспроводной связи может быть основана на верификации идентификатора сети, ассоциированного с UE 310. В некоторых реализациях, UE 310 может включать в себя модуль идентификации, в дополнение к основному мобильному устройству (ME). ME, например, может включать в себя основное терминальное устройство, имеющее возможности обработки информации (один или более процессоров и одно или более запоминающих устройств) и имеющее установленную мобильную операционную систему и другие программные компоненты для того, чтобы предоставлять потребности в связи и обработке для UE 310. Модуль идентификации может включаться в UE 310 для идентификации и аутентификации пользователя в сети связи и ассоциирования пользователя с ME. Модуль идентификации может реализовываться как различные поколения модуля идентификации абонента (SIM). Например, модуль идентификации может реализовываться как универсальный модуль идентификации абонента (USIM) или карта с универсальной интегральной микросхемой (UICC). Модуль идентификации может включать в себя идентификационные данные пользователя либо их производную. Идентификационные данные пользователя могут назначаться посредством оператора сети связи, когда пользователь первоначально подписывается на сеть 300 беспроводной связи.

Идентификационные данные пользователя, например, могут включать в себя постоянный идентификатор подписки (SUPI), назначаемый посредством оператора сети беспроводной связи пользователю. В некоторых реализациях, SUPI может включать в себя международный идентификационный номер абонента мобильной связи (IMSI) или идентификатор доступа к сети (NAI). Альтернативно SUPI, идентификационные данные пользователя могут предоставляться в форме скрытых идентификационных данных, таких как маскированный идентификатор подписки (SUCI). В SUCI, идентификационные данные пользователя могут маскироваться и защищаться посредством шифрования. Например, SUCI может включать в себя: 1) SUPI-тип, который может занимать предварительно определенное число информационных битов (например, три бита для значения 0-7, причем значение 0 может указывать то, что идентификационные данные пользователя имеют IMSI-тип, значение 1 может указывать то, что идентификационные данные пользователя имеют NAI-тип, и другие значения могут резервироваться для других возможных типов); 2) идентификатор домашней сети для беспроводной сети, на которую подписывается пользователь, который может включать в себя код страны в системе мобильной связи (MCC) и код мобильной сети (MNC) для оператора сети 300 беспроводной связи, когда SUPI для пользователя имеет IMSI-тип, и альтернативно может включать в себя идентификатор, указываемый, например, в разделе 2.2 документа IETF RFC 7542, когда SUPI для пользователя имеет NAI-тип; 3) индикатор маршрутизации (RID), назначаемый посредством оператора сети 300 беспроводной связи, которая вместе с идентификатором домашней сети выше определяет AUSF и UDM, ассоциированные с UE 310; 4) идентификатор схемы защиты (PSI) для указания варианта выбора между отсутствием защиты (нулевой схемой) или наличием защиты (ненулевой схемой); 5) идентификатор общедоступного ключа домашней сети для указания идентификатора для общедоступного ключа, предоставленного посредством домашней сети для защиты SUPI (это значение идентификатора может задаваться в качестве нуля, когда вышеприведенный PSI указывает нулевую схему); и 6) вывод схемы, который может включать в себя часть идентификационного номера абонента мобильной связи (MSIN) IMSI или NAI, зашифрованного посредством общедоступного ключа домашней сети с использованием, например, шифрование на эллиптических кривых, когда вышеприведенный PSI указывает ненулевую схему, и может включать в себя MSIN или NAI (без шифрования), когда вышеприведенный PSI указывает нулевую схему. В качестве примера для SUCI, когда IMSI равен 234150999999999, т.е. MCC=234, MNC=15 и MSIN=0999999999, и при условии, что RID равен 678, и что идентификатор общедоступного ключа домашней сети равен 27, незащищенный SUCI может включать в себя {0, (234, 15), 678, 0, 0 и 0 999 999 999}, и защищенный SUCI может включать в себя {0, (234, 15), 678, 1, 27, <шифрование на эллиптических кривых 0999999999 с использованием общедоступного ключа, указываемого посредством идентификатора общедоступного ключа 27>}.

Поскольку части трактов передачи данных сеансов связи между UE 310 с другими UE, DN 150 или приложениями 140 предоставления услуг через базовую сеть 130 могут находиться за пределами окружения защищенной связи, например, внутри базовой сети 130, пользовательские идентификационные данные и пользовательские данные, передаваемые в этих трактах передачи данных, в силу этого могут быть доступными для незащищенного сетевого окружения и могут подвергаться брешам в системе безопасности. В связи с этим, может быть предпочтительным дополнительно защищать данные, передаваемые в сеансах связи с использованием различных уровней ключей шифрования/дешифрования. Как указано выше, эти ключи могут управляться посредством AUSF 360 в сочетании с процессом аутентификации пользователей в сети 300 беспроводной связи. Эти ключи шифрования/дешифрования могут организовываться в нескольких уровнях и иерархическим способом. Например, базовый ключ первого уровня может формироваться посредством AUSF 360 для UE 310 при начальной подписке на услугу сети 300 беспроводной связи. Базовый ключ второго уровня может быть сконфигурирован для UE 310 при каждой регистрации и аутентификации в сети беспроводной связи. Такой базовый ключ второго уровня может быть достоверным в течение сеанса регистрации для UE 310 и может использоваться в качестве базового ключа для формирования других высокоуровневых ключей. Пример таких высокоуровневых ключей может включать в себя привязочный ключ, который может использоваться для того, чтобы извлекать ключи даже верхних уровней для использования в качестве фактических ключей шифрования/дешифрования для передачи данных в сеансах связи.

Такая многоуровневая ключевая схема может быть, в частности, полезной для сеансов связи, заключающих в себе UE 310 и приложения 140 предоставления услуг. В частности, привязочный ключ приложения может формироваться на основе базового ключа и управляться в качестве привязки безопасности для связи между UE 310 и несколькими приложениями предоставления услуг. Различные сеансы связи с различными приложениями 140 предоставления услуг для UE 310 могут использовать различные ключи шифрования/дешифрования данных. Эти различные ключи шифрования/дешифрования данных могут независимо формироваться и управляться на основе привязочного ключа.

В некоторых реализациях, базовая сеть 130 может быть выполнена с возможностью охватывать специальную архитектуру для аутентификации и управления ключами для приложений предоставления услуг (AKMA). Сеть 300 беспроводной связи, например, дополнительно может включать в себя привязочные AKMA-функции (AAnF) или сетевые узлы в базовой сети 130. Примерная AAnF 380 проиллюстрирована на фиг. 3. AAnF 380 может регулировать формирование и управление ключами шифрования/дешифрования данных для различных приложений предоставления услуг в ассоциации с AUSF 360 и различными AF 390, ассоциированными с различными приложениями предоставления услуг. AAnF 380 дополнительно может регулировать поддержание контекста обеспечения безопасности для UE 310. Например, функциональность AAnF 380 может быть аналогичной серверной функции самоинициализации (BSF) в общей архитектуре самоинициализации (GBA). Несколько AAnF 380 могут развертываться в базовой сети 130, и каждая AAnF 380 может ассоциироваться и регулировать управление ключами одного или более приложений предоставления услуг и соответствующих AF 390.

Фиг. 4 и 5 иллюстрируют примерные реализации для вышеприведенной иерархической AKMA. Например, фиг. 4 иллюстрирует реализацию 400 для формирования базового ключа и привязочного ключа для сеансов связи, заключающих в себе приложение предоставления услуги. В частности, реализация 400 может включать в себя процедуру 402 аутентификации пользователей и процедуру 404 формирования привязочных ключей. Процедура 402 аутентификации пользователей, например, может заключать в себе действия из UE 310, AMF/SEAF 330, AUSF 360 и UDM/ARPF 370. Например, UE 310, после входа в сеть беспроводной связи, может передавать запрос на аутентификацию и регистрацию в сети в AMF/SEAF 330. Такой запрос может перенаправляться посредством AMF/SEAF 330 в AUSF 360 для обработки. В ходе процесса аутентификации, AUSF 360 может получать информацию пользовательских договоров и подписок из UDM/ARPF 370. Процесс аутентификации для беспроводной 5G-системы, например, может быть основан на протоколе 5G-AKA (аутентификации и согласования ключей) либо на EAP-AKA (протоколе расширенной AKA-аутентификации). При успешной аутентификации, вектор аутентификации может формироваться посредством UDM/ARPF 370, и такой вектор аутентификации может передаваться в AUSF 360. После успешной процедуры 402 аутентификации пользователей, базовый ключ может формироваться на стороне UE 310 и AUSF 360 на стороне сети. Такой базовый ключ может называться "K_AUSF".

Как подробнее показано посредством 410 и 420 на фиг. 4, привязочный ключ может извлекаться на основе базового ключа K_AUSF в UE 310 и в AUSF 360 в процедуре 404 формирования привязочных ключей. Такой привязочный ключ может называться "K_AKMA". Как подробнее показано посредством 412 и 422 на фиг. 4, идентификатор для привязочного ключа K_AKMA может формироваться в UE 310 и AUSF 360. Этот идентификатор может называться "K_ID".

Фиг. 5 дополнительно иллюстрирует примерную реализацию 500 для формирования ключа 506 приложения для зашифрованной связи между UE и приложением предоставления услуги, в дополнение к формированию базового ключа K_AUSF 502 и привязочного ключа K_AKMA 504. Как показано на фиг. 5, ключ 506 приложения, обозначаемый в качестве K_AF, может формироваться на стороне сети и на стороне UE на основе привязочного ключа K_AKMA 504. В частности, на стороне сети, в то время как привязочный ключ K_AKMA 504 может формироваться посредством AUSF 360 на основе базового ключа K_AUSF 502, формирование ключа K_AF 506 приложения может заключать в себе AAnF 380. На стороне UE по фиг. 5, формирование привязочного ключа K_AKMA 504 и ключа K_AF 506 приложения проиллюстрировано как выполняемое посредством части 510 ME (мобильного устройства) UE. В частности, такое формирование ключей на стороне UE может главным образом заключать в себе использование мощности и характеристик обработки ME после того, процедура 402 аутентификации пользователей, заключающая в себе модуль идентификации (например, SIM) в UE, завершается.

В схеме управления ключами приложения, проиллюстрированной на фиг. 4 и 5, одна или более AAnF 380 могут распределяться в базовой сети, и каждая из одной или более AAnF 380 может быть ассоциирована с одной или более AF 390. В связи с этим, каждая из одной или более AAnF 380 может быть ассоциирована с одним или более приложений предоставления услуг и может регулировать формирование и управление ключами приложения для зашифрованной связи, заключающей в себе эти приложения предоставления услуг. Хотя ключи приложения, каждый из которых предназначен для одного из этих приложений предоставления услуг, могут формироваться на основе идентичного привязочного ключа K_AKMA 504, эти ключи приложения, на стороне сети, могут формироваться независимо посредством соответствующей AAnF 380.

Фиг. 6 дополнительно иллюстрирует примерную логическую последовательность 600 операций для формирования ключа приложения, ассоциированного с приложением предоставления услуги для обеспечения зашифрованной связи между UE 310 и соответствующей AF 390. На этапе 601-1, UE 310 может сначала успешно регистрироваться и аутентифицироваться посредством AMF/SEAF 330, AUSF 360 и UDM/ARPF 370 (аналогично 402 на фиг. 4). После регистрации и аутентификации UE, может формироваться базовый ключ K_AUSF. На этапе 601-2, привязочный ключ K_AKMA и соответствующий идентификатор K_ID могут формироваться на стороне UE и на стороне сети (аналогично 410, 412, 420 и 422 по фиг. 4). На этапе 602, UE 310 инициирует сеанс связи с приложением предоставления услуги, ассоциированным с AF 390, посредством отправки сообщения с запросом на осуществление связи. Запрос может включать в себя идентификатор K_ID, сформированный на этапе 601-2 и ассоциированный с привязочным ключом K_AKMA, сформированным на этапе 601-1. На этапе 603, AF 390 может отправлять сообщение с запросом на предоставление ключа в AAnF 380, причем сообщение с запросом на предоставление ключа включает в себя идентификатор K_ID привязочного ключа и идентификатор AF 390, AF_ID. На этапе 604, AAnF 380 определяет то, может или нет привязочный ключ K_AKMA, ассоциированный с идентификатором K_ID привязочного ключа, быть расположен в AAnF 380. Если K_AKMA находится в AAnF 380, логическая последовательность 600 операций переходит к этапу 607. В противном случае, AAnF 380 может отправлять запрос на предоставление привязочного ключа в AUSF 360 на этапе 604, переносящий идентификатор K_ID привязочного ключа, и принимать привязочный ключ K_AKMA из AUSF 360 на этапе 605 после того, как AUSF 360 идентифицирует привязочный ключ K_AKMA согласно идентификатору K_ID привязочного ключа в ответ на запрос на предоставление привязочного ключа из AAnF 380. На этапе 606, AAnF 380 извлекает ключ K_AF приложения на основе привязочного ключа K_AKMA, если K_AF заранее еще не извлечен в AAnF 380 или уже истек. Извлеченный K_AKMA может быть ассоциирован с периодом времени достоверности ключа приложения (или временем истечения срока действия). На этапе 607, AAnF 380 может отправлять ключ K_AF приложения и соответствующее время истечения срока действия в AF 390. После получения K_AKMA из AAnF 380, AF может наконец отвечать на запрос на осуществление связи, отправленный из UE 310 на этапе 602. Ответ на этапе 608, например, может включать в себя время истечения срока действия для K_AF, и такое время истечения срока действия может записываться и сохраняться посредством UE 310.

Фиг. 7 иллюстрирует другой примерный архитектурный вид 700 для AKMA-реализаций посредством различных сетевых функций, раскрытых выше. Различные функции, такие как AMF/SEAF 330, AUSF 360, AF 390, UDM/ARPF 370, UE 310 и AAnF 380, проиллюстрированы таким образом, что они взаимодействуют друг с другом согласно примерным реализациям, описанным выше, через различные интерфейсы, ассоциированные с этими сетевыми функциями, такие как Namf-интерфейс для AMF/SEAF 330, Nausf-интерфейс для AUSF 360, Naf-интерфейс из AF 390, Nudm-интерфейс для UDM/ARPF 370 и Naanf-интерфейс для AAnF 380, как указано на фиг. 7. Фиг. 7 дополнительно показывает функцию 702 обеспечения доступа к сети (NEF) в качестве шлюза для обеспечения доступа к характеристикам базовой сети для AF 390, ассоциированной с приложениями предоставления услуг. В примерном архитектурном виде 700 по фиг. 7, UE 310 может обмениваться данными с AF 390 через Ua-интерфейс и с AMF/SEAF 330 через N1-интерфейс. Связь из UE 310 в базовую сеть ретранслируется посредством RAN 320.

В реализациях, описанных выше, AUSF, UDM, AUSF и AAnF принадлежат домашней сети UE 310. Они могут быть расположены в защищенном сетевом окружении, предоставленном посредством оператора или авторизованной третьей стороны, и могут не быть общедоступными для неавторизованного сетевого доступа. В роуминговом сценарии, домашняя UDM и AUSF предоставляют аутентификационную информацию для UE, поддерживают роуминговое местоположение UE и предоставляют информацию по подписке в гостевую сеть.

Формирование ключей приложения и шифрование/дешифрование данных, передаваемых в сеансах связи с приложениями предоставления услуг, могут заключать в себе существенную обработку данных, которая требует значительного уровня вычислительных возможностей и энергопотребления. Некоторые UE более низкого уровня, которые не допускают такой уровень вычисления, могут не иметь возможности обмениваться данными с приложениями предоставления услуг, если шифрование/дешифрование данных, описанное выше, задается обязательным. В некоторых дополнительных реализациях, описанных ниже, варианты могут предоставляться таким образом, что UE может обмениваться данными с приложениями предоставления услуг, с потоками данных в них, защищенными или незащищенными посредством ключей приложения. В связи с этим, UE более низкого уровня, которое может не допускать своевременное выполнение формирования ключей приложения и шифрования/дешифрования данных, тем не менее, может иметь вариант запроса сеанса незащищенной связи с приложениями предоставления услуг, в силу этого вообще исключая необходимость выполнять сложное формирование ключей и шифрование/дешифрование данных.

Такие варианты могут предоставляться через механизм подписки на услуги. Например, AKMA может предоставляться в качестве услуги, на которую могут подписываться UE. Например, UE может или подписываться или не подписываться на AKMA-услугу. Когда UE подписывается на AKMA-услугу, UE может запрашивать сеанс защищенной связи с приложением предоставления услуги. UE и различные сетевые функции (такие как AAnF 380), соответственно, могут выполнять необходимое формирование ключей приложения для шифрования/дешифрования данных. В противном случае, когда UE не имеет подписки на AKMA-услугу, UE может запрашивать только сеанс незащищенной связи с приложением предоставления услуги, и ключ приложения и шифрование/дешифрование данных могут не требоваться.

В качестве другого примера, вместо подписки на AKMA-услугу полностью, UE может подписываться на AKMA-услугу для ни одного, некоторых или всех приложений предоставления услуг, доступных и зарегистрированных в сети связи через функции обеспечения доступа к сети. Когда UE имеет подписку на AKMA-услугу для конкретного приложения предоставления услуги, UE может запрашивать сеанс защищенной связи с этим приложением предоставления услуги. UE и различные сетевые функции (такие как AAnF 380), соответственно, могут выполнять необходимое формирование ключей приложения для шифрования/дешифрования данных. В противном случае, когда UE не имеет подписки на AKMA-услугу для конкретного приложения предоставления услуги, UE может запрашивать только сеанс незащищенной связи с этим приложением предоставления услуги, и ключ приложения и шифрование/дешифрование данных могут не требоваться для связи с этим конкретным приложением предоставления услуги.

Информация по подпискам UE AKMA-услуги для приложений предоставления услуг может управляться на стороне сети посредством UDM/ARPF 370. В частности, UDM/ARPF 370 может отслеживать информацию по подписке на AKMA-услуги для каждого UE. UDM/ARPF 370 может быть выполнена с возможностью предоставлять интерфейс для других сетевых функций сети связи, таких как AUSF 360, с тем чтобы запрашивать информацию по подписке на AKMA-услуги конкретного UE. UDM/ARPF 370, например, может доставлять информацию по подписке на AKMA-услуги посредством UE в AUSF 360 через Nudm-интерфейс, проиллюстрированный на фиг. 7, при запросе. В этих реализациях, UDM/ARPF 370 по существу выполнена с возможностью выступать в качестве репозитория информации по подписке на AKMA-услуги, в дополнение к другим функциональностям управления пользовательскими данными. Альтернативно, выделенные сетевые функции, отдельные и отличные от UDM/ARPF 370, могут включаться в базовую сеть и конфигурироваться с возможностью управлять подпиской на AKMA-услуги.

Такая информация по подписке может записываться в различных формах в UDM/ARPF 370. Информация по подписке может индексироваться посредством UE. Например, каждая подписка на AKMA-услуги может быть ассоциирована с идентификатором UE. Каждая подписка на AKMA-услуги дополнительно может включать в одно или более из следующего: (1) индикатор для того, подписывается или нет UE на AKMA-услугу, (2) идентификатор для одной или более AAnF, ассоциированных с подпиской UE, и (3) периоды времени достоверности (либо время истечения срока действия) привязочных ключей K_AKMA, соответствующих AAnF. Идентификатор для AAnF может предоставляться в форме сетевого адреса AAnF. Альтернативно, идентификатор AAnF может предоставляться в форме полностью определенного доменного имени (FQDN) AAnF. Каждое UE может соответствовать одной или более AAnF, на которые оно подписывается.

Соответственно, модуль идентификации UE (например, универсальный модуль идентификации абонента (USIM) или универсальная интегрированная идентификационная карта (UICC)) может включать в себя информацию по подписке на AKMA-услуги для UE. Такая информация по подписке может включать в одно или более из следующего: (1) индикатор для того, подписывается или нет UE на AKMA-услугу, (2) идентификатор одной или более AAnF, ассоциированных с подпиской на AKMA-услуги UE, (3) периоды времени достоверности привязочных ключей K_AKMA, соответствующих AAnF, и (4) идентификаторы AF, соответствующих услугам поддержки приложений, подписанным посредством UE. С другой стороны, идентификатор для AAnF может предоставляться в форме сетевого адреса AAnF. Альтернативно, идентификатор AAnF может предоставляться в форме FQDN AAnF. Каждое UE может соответствовать одной или более подписанных AAnF. Аналогично, идентификатор для AF может предоставляться в форме сетевого адреса AF. Альтернативно, идентификатор AF может предоставляться в форме FQDN AF. Каждое UE может соответствовать одной или более AF. В некоторых реализациях, несколько AF могут быть ассоциированы с идентичной AAnF, но каждая AF может быть ассоциирована только с одной AAnF.

Фиг. 8 показывает примерные логические последовательности 800, 850 и 860 операций для аутентификации пользователей и формирования привязочного ключа K_AKMA, когда UE подписано на AKMA-услугу. Логическая последовательность 800 операций иллюстрирует примерную процедуру регистрации и аутентификации UE, тогда как логическая последовательность 850 операций иллюстрирует примерный процесс для формирования привязочного ключа K_AKMA, и логическая последовательность 860 операций иллюстрирует другой примерный процесс для формирования привязочного ключа K_AKMA, альтернативный логической последовательности 850 операций. Как показано посредством 840, UE 310 может подписываться на AKMA-услугу, и информация по подписке на AKMA-услуги, соответствующая UE 310, может записываться в UE 310. Такая информация по подписке может включать в себя одну или более комбинаций следующего: индикатор для того, подписано или нет UE 310 на AKMA-услугу; один или более AAnF-идентификаторов; один или более AF-идентификаторов; и периоды времени достоверности привязочных AKMA-ключей. Как дополнительно указано посредством 842, соответствующая информация пользовательских подписок, записанная в UDM/ARPF 370, может включать в себя одно или более из следующего: индикатор для того, подписано или нет UE 310 на AKMA-услугу; один или более AAnF-идентификаторов; и период времени достоверности привязочного AKMA-ключа. В течение процедуры регистрации и аутентификации UE, UDM/ARPF 370 может передавать информацию по подписке на AKMA-услуги в AUSF 360. При успешной регистрации и аутентификации UE, AUSF 360 может извлекать привязочный AKMA-ключ на основе информации по подписке на AKMA-услуги, принимаемой из UDM/ARPF 370. В это время, UE 310 также может извлекать привязочный AKMA-ключ на основе информации по подписке на AKMA-услуги, сохраненной в UE 310.

Конкретные примерные этапы для регистрации/аутентификации UE и формирование привязочных AKMA-ключей проиллюстрированы посредством этапов 801-810 на фиг. 8. На этапе 801, UE 310 отправляет сообщение с запросом в AMF/SEAF 330 для того, чтобы инициировать регистрацию/аутентификацию UE 310 в сети. AMF/SEAF 330 может предоставляться посредством домашней сети UE либо посредством гостевой сети в сценарии, в котором UE находится в роуминге. Сообщение с запросом может включать в себя идентификатор пользователя UE 310, такой как SUCI или глобально уникальные временные идентификационные 5G-данные UE (5G-GUTI). На этапе 802, AMF/SEAF 330 отправляет запрос на AUSF-аутентификацию в AUSF 360 (например, запрос Nausf_UEAuthentication_Authenticate). Такой AUSF-запрос может включать в себя SUCI или SUPI UE 310. В случае если запрос на регистрацию/аутентификацию на этапе 801 включает в себя 5G-GUTI, AMF/SEAF 330 может сначала получать SUPI из домашней AMF UE. Если это завершается неудачно, AMF/SEAF 330 может получать SUCI из UE 310. AUSF-запрос дополнительно может включать в себя идентификационные данные или название обслуживающей сети (SN) для UE 310. На этапе 803, после того, как AUSF 360 (домашняя AUSF для UE) определяет то, что SN-название является достоверным, AUSF 360 инициирует сообщение с запросом на аутентификацию пользователей (например, запрос Nudm_UEAuthentication_Get) в UDM/ARPF 370. Такое сообщение с запросом на аутентификацию пользователей может включать в себя SUCI или SUPI UE 310 и дополнительно может включать в себя SN-название.

Продолжая с фиг. 8, на этапе 804, UDM/ARPF 370 принимает сообщение с запросом на аутентификацию пользователей этапа 803 и может дешифровать SUCI, содержащийся в сообщении, чтобы получать SUPI. UDM/ARPF 370 затем определяет тип аутентификации пользователей (например, 5G-AKA или EAP-AKA) и формирует вектор аутентификации. UDM/ARPF 370 дополнительно выполняет запрос в свой репозиторий данных подписок, чтобы определять то, подписано или нет UE 310 на AKMA-услугу, и если да, получать информацию по подписке на AKMA-услуги для UE 310. UDM/ARPF 370 затем отвечает на сообщение с запросом на аутентификацию пользователей по этапу 803 посредством возвращаемого сообщения, включающего в себя вектор аутентификации, SUPI, дешифрованный из SUCI, и/или информацию по подписке на AKMA-услуги для UE 310 (например, Nudm_UEAuthentication_Get ответ) в AUSF 360. Вектор аутентификации, сформированный посредством UDM/ARPF 370 и включенный в возвращаемое сообщение, может включать в себя, например, аутентификационный маркер (AUTN), случайное число (RAND) и/или различные ключи аутентификации. Информация по подписке на AKMA-услуги для UE может включать в себя, например, идентификаторы для одной или более AAnF и или период времени достоверности привязочного AKMA-ключа.

Дополнительно на этапе 805, AUSF 360 верифицирует вектор аутентификации, отправленный из UDM/ARPF 370 на этапе 804, и инициирует основную процедуру аутентификации. Такая процедура аутентификации, например, может быть основана на 5G-AKA или EAP-AKA. После успешного завершения основной процедуры аутентификации, UE 310 и AUSF 360 должны формировать базовый ключ K_AUSF. UE 310 и AMF/SEAF 330 дополнительно должны формировать ключи на связанном и на не связанном с предоставлением доступа уровне.

Логическая последовательность 850 операций после этапа 805 на фиг. 8 иллюстрирует примерную реализацию для формирования привязочных ключей. В частности, на этапе 806, после того, как основная логическая последовательность 850 операций для аутентификации UE является успешной, UE 310 и AUSF 360 могут формировать привязочный AKMA-ключ K_AKMA=KDF(K_AUSF, AKMA-тип, RAND, SUPI, AAnF-идентификатор). Термин "KDF" представляет примерный алгоритм формирования ключей, предусматривающий HMAC-SHA-256 (256-битовый хэш-код аутентификации сообщений для защищенного хэш-алгоритма). K_AUSF представляет базовый ключ. Параметр "AKMA-тип" представляет различный AKMA-тип, например, AKMA может быть основана на ME (ME-часть UE регулирует вычисление при формировании ключей и шифровании/дешифровании). В качестве другого примера, AKMA может быть основана на UICC, причем характеристики обработки в UICC UE используются для формирования ключей и шифрования/дешифрования. Параметр "RAND" представляет случайное число в векторе аутентификации, сформированном посредством UDM/ARPF 370 на вышеприведенном этапе 804. AAnF-идентификаторы могут включать в себя сетевые адреса AAnF или FQDN AAnF. Хотя вышеприведенное примерное KDF-вычисление перечисляет все параметры, поясненные выше, не все эти параметры должны обязательно включаться в вычисление. Любые комбинации любых из этих параметров могут использоваться для KDF-вычисления и для формирования K_AKMA. В некоторых реализациях, K_AUSF-параметр может задаваться обязательным, и другие параметры могут задаваться необязательными. В некоторых других реализациях, K_AUSF-параметр и, по меньшей мере, часть информации по AKMA-подписке (например, AKMA-тип, AAnF-идентификатор) может задаваться обязательной, и другие параметры могут задаваться необязательными.

На этапе 807, UE 310 и AUSF 360 могут формировать идентификатор для привязочного AKMA-ключа, например, в качестве K_ID=RAND@AAnF-идентификатор или K_ID=base64encode(RAND)@AAnF-идентификатор. Здесь, RAND представляет собой случайное число в векторе аутентификации, полученном из вышеуказанной UDM/ARPF 370, и AAnF-идентификатор включает в себя сетевой AAnF-адрес или FQDN-адрес. Примерный способ кодирования, заданный посредством "base64encode", указывается, например, в протоколе согласно IEFT RFC 3548. Дополнительно на этапе 808, AUSF 360, после вычисления привязочного AKMA-ключа на этапе 806 и идентификатора привязочного AKMA-ключа на этапе 807, может передавать сообщение по схеме проталкивания в AAnF 380. Сообщение по схеме проталкивания, например, может включать в себя привязочный ключ K_AKMA, идентификатор K_ID привязочного ключа. Сообщение по схеме проталкивания дополнительно может включать в себя период времени достоверности для привязочного ключа K_AKMA. AAnF 380 затем может сохранять привязочный ключ K_AKMA и идентификатор K_ID привязочного ключа. AAnF 380 дополнительно может идентифицировать локальный период времени достоверности для привязочного ключа K_AKMA, определенный согласно локальным стратегиям управления ключами в AAnF 380. AAnF 380 может сравнивать локальный период времени достоверности для привязочного ключа и период времени достоверности для привязочного ключа, принимаемый из AUSF 360 на этапе 808, и использовать меньшее значение в качестве фактического периода времени достоверности для привязочного ключа. Если период времени достоверности для привязочного ключа не находится в сообщении, отправленном из AUSF 360 в AAnF 380 на этапе 808, AAnF 380 затем может использовать локальный период времени достоверности в качестве фактического периода времени достоверности для привязочного ключа. Если локальный период времени достоверности для привязочного ключа не обнаружен в AAnF 380, то период времени достоверности, принимаемый из AUSF 360 на этапе 808, может использоваться в качестве фактического периода времени достоверности для привязочного ключа. Дополнительно на этапе 809, AAnF 380 передает ответ на AUSF 360 после успешной передачи сообщения по схеме проталкивания из AUSF 360 в AAnF 380 на этапе 808.

Логическая последовательность 860 операций дополнительно иллюстрирует примерную реализацию для формирования привязочных ключей, альтернативную вышеприведенной логической последовательности 850 операций. Этапы 806A, 807A, 808A и 809A логической последовательности 860 операций соответствуют этапам 806, 807, 808 и 809, соответственно. Логическая последовательность 860 операций является аналогичной логической последовательности 850 операций за исключением того, что идентификатор K_ID для привязочного ключа K_AKMA формируется посредством AAnF 380, а не AUSF 360 на стороне сети (как показано посредством этапа 808A, выполняемого посредством AAnF 380). Соответственно, сообщение по схеме проталкивания, отправленное из AUSF 360 в AAnF 380, может включать в себя параметр RAND, который может использоваться в качестве одного из компонентов для формирования K_ID посредством AAnF 380 на этапе 808A. Подробности для различных других этапов в логической последовательности 860 операций могут содержаться в вышеприведенном описании для логической последовательности 850 операций.

После успешного формирования привязочного ключа согласно вышеприведенной логической последовательности 850 или 860 операций, UE 310 может инициировать связь с AF 390, как подробнее описано ниже. В завершение для фиг. 8, как показано посредством этапа 810, AMF/SEAF 330 может отправлять ответ сообщение в UE 310, указывающее успешное завершение запроса на регистрацию/аутентификацию этапа 801 и успешное завершение формирования привязочных ключей для подписанной AAnF. В некоторых других альтернативных реализациях, этап 810 может выполняться до этапа 806 для указания успешного завершения запроса на регистрацию/аутентификацию по этапу 801.

В вышеприведенных реализациях для фиг. 8, AKMA-услуга предлагается в качестве варианта вместо обязательности и предоставляется в UE для подписки. Информация по подписке может сохраняться и управляться посредством UDM/ARPF 370 на стороне домашней сети и в UE 310. В связи с этим, UE 310 предоставляется варианты либо подписки на AKMA-услугу, либо неподписки на AKMA-услугу. В случае, если UE не подписывается на AKMA-услугу (когда, например, в UE отсутствуют возможности обрабатывать формирование ключей и шифрование данных), UE может воздерживаться от процесса формирования привязочных ключей приложения и может обмениваться данными с серверами приложений вообще без использования ключей приложения. В случае, если UE подписывается на AKMA, информация по подписке необязательно может использоваться, как показано посредством необязательного параметра "AAnF-идентификатор" и "AKMA-тип" на этапе 806, 806A, 807 и 807A, для формирования привязочного AKMA-ключа и его идентификатора.

Привязочный ключ K_AKMA приложения, после формирования так, как описано выше на фиг. 8, затем может использоваться в качестве основы для формирования ключа приложения для зашифрованной связи между UE 310 и приложением предоставления услуги, в котором UE 310 подписано на AKMA-услугу. Как проиллюстрировано выше относительно фиг. 8, такие параметры, как случайное число RAND в векторе аутентификации, сформированном посредством UDM/ARPF 370, могут использоваться для конструирования K_ID (см., например, этапы 807 и 808 на фиг. 8). Идентификатор K_ID дополнительно может использоваться в качестве поискового индекса, чтобы идентифицировать соответствующий привязочный AKMA-ключ в течение каждой связи между UE 310 и приложениями предоставления услуг. Частая передача этих параметров, к примеру, параметра RAND, через тракт передачи данных за пределами защищенного окружения базовой сети может приводить к бреши в системе безопасности или утечке этих параметров. Примерные реализации формирования ключей приложения для зашифрованной связи с приложением предоставления услуги, как проиллюстрировано в логических последовательностях операций по фиг. 9-12 и описано ниже, могут предоставлять схемы для уменьшения риска нарушения безопасности этих параметров.

На фиг. 9-12, после основной регистрации и аутентификации UE 310 и формирования привязочного ключа приложения, например, после этапов 801-806 аутентификации и формирования привязочных ключей, как проиллюстрировано на фиг. 8, UE 310 может формировать начальный ключ приложения и отправлять запрос на связь в AF, ассоциированную с приложением предоставления услуги. AF может получать начальный ключ приложения из AAnF. AAnF в это время может формировать новое случайное число (NewRAND) или идентификатор нового привязочного ключа и отправлять NewRAND или идентификатор нового привязочного ключа в UE 310 через AF. UE затем может формировать новый ключ приложения на основе NewRAND или идентификатора нового привязочного ключа и использовать новый ключ приложения для того, чтобы запрашивать и устанавливать фактический сеанс связи с приложением предоставления услуги. NewRAND и идентификатор нового привязочного ключа, используемые для формирования нового ключа приложения, могут называться "порождающим числом для формирования ключей" для формирования нового ключа приложения.

Как показано посредством 840 на фиг. 9-12, предполагается, что UE 310 подписано на AKMA-услугу, и что информация по подписке на AKMA-услуги, сохраненная в UE 310, может включать в себя одну или более комбинаций следующего: индикатор для того, подписано или нет UE на AKMA-услугу; один или более AAnF-идентификаторов; один или более AF-идентификаторов; и период времени достоверности привязочного AKMA-ключа. Как дополнительно указано посредством 842 на фиг. 9-12, соответствующая информация пользовательских подписок, записанная в UDM/ARPF 370, может включать в себя одно или более из следующего: индикатор для того, подписано или нет UE на AKMA-услугу; один или более AAnF-идентификаторов; и период времени достоверности привязочного AKMA-ключа. Идентификатор для AAnF может предоставляться в форме сетевого адреса AAnF. Альтернативно, идентификатор AAnF может предоставляться в форме FQDN AAnF. Каждое UE может соответствовать одной или более подписанных AAnF. Аналогично, идентификатор для AF может предоставляться в форме сетевого адреса AF. Альтернативно, идентификатор AF может предоставляться в форме FQDN AF. Каждое UE может соответствовать одной или более AF. В некоторых реализациях, несколько AF могут быть ассоциированы с идентичной AAnF, но каждая AF может быть ассоциирована только с одной AAnF.

Обращаясь к логической последовательности 900 операций по фиг. 9, и как показано в 901, UE 310, AMF/SEAF 330, AUSF 360 и UDM/ARPF 370 могут сначала выполнять основную регистрацию и аутентификацию UE 310 и формирование привязочного AKMA-ключа после этапов 801-806 аутентификации и формирования привязочных ключей, как проиллюстрировано на фиг. 8. Подробности для основной аутентификации и формирования привязочных AKMA-ключей описываются выше относительно фиг. 8. На этапе 907, UE 310 и AUSF 360 формируют начальный идентификатор для привязочного AKMA-ключа, например, в качестве K_ID=RAND@AAnF-идентификатор или K_ID=base64encode(RAND)@AAnF-идентификатор. При успешной регистрации и аутентификации UE, на этапе 908, AMF/SEAF 330 передает ответное сообщение в UE 310, чтобы указывать то, что регистрация и аутентификация является успешной. Этап 908 может выполняться в другие моменты времени. Например, этап 908 может выполняться перед этапом 806 в ходе процедуры 901.

Продолжая с фиг. 9, на этапе 909, UE 310 может формировать начальный ключ приложения K_in-AF=KDF(K_AKMA, RAND, AF-идентификатор), причем KDF представляет примерный алгоритм формирования ключей, описанный относительно этапа 806 по фиг. 8. На этапе 910, UE 310 отправляет запрос на начальную связь в AF 390, ассоциированную с приложением предоставления услуги. Запрос на начальную связь, например, может включать в себя идентификатор для привязочного AKMA-ключа, K_ID. Дополнительно на этапе 911, AF 390 принимает запрос на начальную связь из UE 310 и отправляет запрос на начальный ключ K_in-AF приложения в AAnF 380 согласно AAnF-идентификатору, включенному в K_ID. Запрос на начальный ключ K_in-AF приложения из AF 390, например, может включать в себя K_ID и идентификатор для AF, AF_ID. AAnF 380 может выполнять запрос на предмет привязочного AKMA-ключа K_AKMA согласно K_ID, отправленному из AF 390 на этапе 911. Если AAnF 380 находит привязочный AKMA-ключ K_AKMA, логическая последовательность 900 операций может переходить к 914. Если AAnF 380 не находит привязочный AKMA-ключ K_AKMA, она может отправлять запрос на предоставление привязочного AKMA-ключа в AUSF 360 на этапе 912. Такой запрос мой включать в себя K_ID. При приеме запроса по этапу 912, AUSF 360 может идентифицировать запрашиваемый привязочный AKMA-ключ K_AKMA согласно K_ID и отвечать в AAnF 380 с K_AKMA и его периодом времени достоверности на этапе 913. На этапе 914, AAnF 380 затем может сохранять привязочный ключ K_AKMA и его период времени достоверности. AAnF 380 дополнительно может идентифицировать локальный период времени достоверности для привязочного ключа K_AKMA, определенный согласно локальным стратегиям управления ключами в AAnF 380. AAnF 380 может сравнивать локальный период времени достоверности для привязочного ключа и период времени достоверности для привязочного ключа, принимаемый из AUSF 360 на этапе 808, и использовать меньшее значение в качестве фактического периода времени достоверности для привязочного ключа. Если период времени достоверности для привязочного ключа не включается в сообщение, отправленное из AUSF 360 в AAnF 380 на этапе 808, AAnF 380 затем может использовать локальный период времени достоверности в качестве фактического периода времени достоверности для привязочного ключа. Если локальный период времени достоверности для привязочного ключа не обнаружен в AAnF 380, то период времени достоверности, принимаемый из AUSF 360 на этапе 808, может использоваться в качестве фактического периода времени достоверности для привязочного ключа. Дополнительно на этапе 914, AAnF 380 может формировать K_in-AF на основе K_in-AF=KDF(K_AKMA, RAND, AF_ID). Примерный KDF-алгоритм вычисления ключей описан ранее относительно этапа 909 по фиг. 9 и этапа 806 на фиг. 8.

Продолжая с фиг. 9, на этапе 915, AAnF 380 может формировать новое случайное число, обозначаемое в качестве NewRAND. AAnF 380 дополнительно может формировать новый идентификатор для привязочного AKMA-ключа в качестве K_ID-New=NewRAND@AAnF-идентификатор или K_ID-New=Base64encode(NewRAND)@AAnF-идентификатор. На этапе 916, AAnF 308 отправляет ответ на запрос на предмет начального K_in-AF на этапе 911. Такой ответ может включать в себя начальный ключ K_in-AF приложения, NewRAND, K_ID-New и/или период времени достоверности для K_ID-New. В некоторых реализациях, период времени достоверности для K_ID-New может не превышать период времени достоверности для привязочного AKMA-ключа. Если этап 917 (см. нижеприведенное описание) выполняется до этапа 916, ответ на этапе 916 дополнительно может включать в себя новый K_AF, сформированный на нижеприведенном этапе 917.

На этапе 917, AAnF 380 формирует новый ключ K_AF-New приложения в качестве K_AF-New=KDF(K_AKMA, NewRAND, AF_ID). KDF-алгоритм является аналогичным алгоритмам, уже описанным выше. Этап 917 альтернативно может выполняться до этапа 916. На этапе 918, AF 390 может записывать пару из K_AF-New и K_ID-New. AF 390 дополнительно может отвечать на запрос этапа 910 и отправлять ответное сообщение в UE 310. Такое ответное сообщение может включать в себя новое случайное число NewRAND и/или идентификатор K_ID-New нового привязочного AKMA-ключа. Ответное сообщение дополнительно может включать в себя период времени достоверности для K_AF-New. В некоторых реализациях, передача этого ответного сообщения может шифроваться с использованием K_in-AF. Другими словами, различные передаваемые компоненты ответа на этапе 918 могут шифроваться с использованием K_in-AF. Впоследствии, AF 390 может удалять начальный K_in-AF.

На этапе 919, UE 310 принимает ответ по этапу 918. Если ответ шифруется с K_in-AF, UE 310 может дешифровать ответ с использованием K_in-AF, который он извлекает на этапе 909. Если ответ включает в себя NewRAND, UE 310 может получать компонент NewRAND, включенный в ответ после дешифрования. UE 310 затем может формировать новый идентификатор K_ID-New для привязочного AKMA-ключа в качестве K_in-AF=NewRAND@AAnF-идентификатор. Если зашифрованный K_ID-New уже включается в ответ по этапу 918, UE 310 может дешифровать ответ, чтобы получать K_ID-New непосредственно.

На этапе 920, UE 310 может формировать новый ключ KAF-New приложения в качестве KAF-New=KDF(KAKMA, NewRAND, AF-идентификатор), причем KDF представляет собой алгоритм формирования ключей, описанный выше относительно этапа 806 по фиг. 8. UE 310 может сохранять идентификатор KID-New нового привязочного AKMA-ключа и новый ключ KAF-New приложения. Если период времени достоверности для нового ключа KAF-New приложения включен в ответ по этапу 918, UE 310 также может дешифровать ответ, чтобы получать период времени достоверности для KAF-New и сохранять его локально.

На этапе 921, UE 310 может инициировать другой запрос на осуществление связи в AF 390. Сообщение с запросом может включать в себя новый идентификатор K_ID-New для привязочного AKMA-ключа, и сообщение с запросом дополнительно может шифроваться посредством UE 310 с использованием нового ключа K_AF-New приложения. На этапе 922, AF 390 принимает запрос на осуществление связи по этапу 921 и может сначала определять то, существует или нет новый ключ K_AF-New приложения локально. Если K_AF-New существует локально, то AF 290 может использовать такой K_AF-New для того, чтобы дешифровать запрос на осуществление связи из UE 310 на этапе 921. Если AF 390 не может находить K_AF-New, она затем может отправлять сообщение с запросом в AAnF 380 на предмет нового ключа K_AF-New приложения. Сообщение с запросом может включать в себя новый идентификатор K_ID-New для привязочного AKMA-ключа и AF_ID. На этапе 923, AAnF 380 принимает сообщение с запросом из этапа 922 и запрос на предмет нового ключа K_AF-New приложения на основе K_ID-New и возвращает K_AF-New в AF 390 в ответ. Если этап 916 вообще не включает в себя период времени достоверности для K_AF-New, такой период времени достоверности может включаться в ответное сообщение в AF 390 на этапе 923. В завершение, на этапе 924, AF 390 может использовать K_AF-New для того, чтобы дешифровать запрос на осуществление связи, отправленный из UE 310 на этапе 921, и отвечать в UE 310 для установления связи с UE 310. Такой ответ может включать в себя период времени достоверности для нового ключа K_AF-New приложения.

Фиг. 10 показывает логическую последовательность 1000 операций в качестве альтернативой реализации по отношению к фиг. 9. Логическая последовательность 1000 операций является аналогичной логической последовательности 900 операций по фиг. 9 (как показано посредством идентичной маркировки на фиг. 9 и 10), за исключением того, что этап 907 по фиг. 9 удаляется из фиг. 10 (как показано посредством 1002). В связи с этим, AUSF 360 на фиг. 10, возможно, не должна формировать начальный идентификатор для привязочного AKMA-ключа, K_ID. Соответственно, этап 1012 на фиг. 10 (показан как подчеркнутый этап) заменяет этап 912 по фиг. 9. В частности, поскольку начальный K_ID не формируется в AUSF 360, запрос из AAnF 380 в AUSF 360 на предмет информации привязочных AKMA-ключей может выполняться согласно RAND, а не K_ID. AAnF 380 может извлекать параметр RAND из K_ID, который она принимает из AF 390 на этапе 911 по фиг. 10.

Фиг. 11 показывает другую логическую последовательность 1100 операций, альтернативную логическим последовательностям 900 и 1000 операций по фиг. 9 и 10. Логическая последовательность 1100 операций является аналогичной логической последовательности 900 операций по фиг. 9 (как показано посредством идентичной маркировки на фиг. 9 и 10) с отличиями относительно фиг. 9, приведенными в качестве примечаний на фиг. 11. Например, этапы 1102 и 1104 (подчеркнутые этапы на фиг. 11) добавляются в логической последовательности 1100 операций. В частности, на этапе 1102, привязочный AKMA-ключ превентивно проталкивается из AUSF 360 в AAnF 380 после того, как он формируется посредством AUSF 360, вместо пассивного запроса посредством AAnF 380 из AUSF 360, что реализовано на этапах 912 и 913 по фиг. 9 (которые удаляются из реализации по фиг. 11, как показано посредством 1106). На этапе 1104, AAnF 380 предоставляет ответ в AUSF 360, если привязочный AKMA-ключ успешно принимается посредством AAnF 380. Дополнительно, этап 914 по фиг. 11, по сравнению с идентичным этапом на фиг. 10, может модифицироваться, как указано на фиг. 11, по причине того, что AAnF 380 уже должна иметь привязочный AKMA-ключ как результат превентивного проталкивания из AUSF 360 на этапе 1102.

Фиг. 12 показывает еще одну другую логическую последовательность 1200 операций, альтернативную логическим последовательностям 900, 1000 и 1100 операций по фиг. 9, 10 и 11. Логическая последовательность 1200 операций придерживается реализаций логической последовательности 1000 операций по фиг. 10 и логической последовательности 1100 операций по фиг. 11 в том, что этапы 907, 912 и 913 по фиг. 9 удаляются, как показано посредством 1 201 и 1206, этап 914 модифицируется относительно фиг. 9, как указано на фиг. 11, и этапы 1202 и 1204 проталкивания добавляются. В связи с этим, в реализации по фиг. 12, привязочный AKMA-ключ превентивно проталкивается из AUSF 360 в AAnF 380, идентично реализации на фиг. 11. Дополнительно, нет необходимости формировать любой начальный K_ID в AUSF 360, поскольку запрос не должен обязательно направляться впоследствии в AUSF 360 для выполнения запроса относительно привязочного AKMA-ключа как результат проталкивания информации на этапе 1202 и 1204.

В реализациях, проиллюстрированных на фиг. 9-12, новое случайное число формируется посредством AAnF 380 и используется для формирования нового ключа приложения и нового идентификатора для привязочного AKMA-ключа. Исходный RAND, сформированный в качестве части вектора аутентификации посредством UDM/ARPF 370, может передаваться между различными сетевыми функциями только ограниченным способом и в силу этого может быть в меньшей степени общедоступным для брешей в системе безопасности. Новое случайное число может формироваться для каждой связи между UE 310 и AF 390, и в силу этого брешь в системе безопасности одного нового случайного числа может не приводить к риску для отдельного сеанса связи. Безопасность связи в силу этого повышается в реализациях по фиг. 9-12.

Как описано выше, чтобы дополнительно повышать безопасность связи, различные ключи, предусмотренные в зашифрованной связи между UE 310 и приложением предоставления услуги, могут быть ассоциированы с периодами времени достоверности (или временем истечения срока действия). Другими словами, эти ключи являются достоверными только в течение таких периодов времени достоверности. В частности, когда эти ключи становятся недостоверными, связь между UE 310 и приложениями предоставления услуг может не защищаться посредством шифрования. В связи с этим, эти ключи, возможно, должны обновляться, когда они становятся недостоверными. Фиг. 13-14, описанные ниже, показывают различные реализации для обновления различных ключей (включающих в себя, например, привязочный AKMA-ключ и ключ приложения), когда они являются недостоверными или становятся недостоверными.

Фиг. 13 иллюстрирует инициированную UE реализацию 1300 для обновления недостоверных ключей. Процедура 402 аутентификации пользователей и этапы 410, 412, 420, 422 являются идентичными соответствующим этапам, описанным относительно фиг. 4. Вышеприведенное описание по фиг. 4 применяется к этим этапам на фиг. 13. После этих этапов, привязочный AKMA-ключ может формироваться. На этапе 1301, UE 310 определяет то, что привязочный AKMA-ключ или AKMA-ключ приложения является или становится недостоверным. UE 310 затем удаляет недостоверный привязочный AKMA-ключ или ключ приложения, соответствующие периоды времени достоверности и идентификатор для недостоверного привязочного AKMA-ключа.

На этапе 1302, когда UE находится в состоянии бездействия, UE может инициировать сообщение с запросом на регистрацию в беспроводную сеть (в сетевые функции, такие как AMF/SEAF 330 или AUSF 360). Такое сообщение с запросом на регистрацию может включать в себя SUCI или 5G-GUTI и ngKSI (индекс контекста обеспечения безопасности), например, в 7, указывающий то, что контекст UE-безопасности является недостоверным. Когда UE 310 находится в активном состоянии с обработкой неэкстренных услуг или невысокоприоритетных услуг, и UE 310 переходит в состояние бездействия, UE может инициировать запрос на регистрацию в сеть. Когда UE 310 находится в активном состоянии с обработкой экстренных услуг или высокоприоритетных услуг, UE может ожидать до завершения экстренных или высокоприоритетных услуг и затем переходить в состояние бездействия и инициировать запрос в регистрацию в сети. В некоторых других реализациях, когда UE находится в активном состоянии, UE может ожидать завершения активных услуг и затем инициировать запрос на регистрацию в сеть независимо от экстренности и приоритета активных услуг.

На этапе 1303, UE может проходить через основную аутентификацию и регистрацию в сети и затем формировать новый привязочный AKMA-ключ и/или ключ приложения и определять периоды времени достоверности и идентификаторы для этих новых ключей. UE и сеть и записывают эти ключи, периоды времени достоверности и идентификаторы.

Фиг. 14 показывает инициированное сетью обновление недостоверных AKMA-ключей. На фиг. 14, UE, возможно, подписано на AKMA-услугу. На 840 по фиг. 14, информация по подписке на AKMA-услуги, соответствующая UE, может записываться в UE. Такая информация по подписке может включать в себя одну или более комбинаций следующего: индикатор для того, подписано или нет UE на AKMA-услугу; один или более AAnF-идентификаторов; один или более AF-идентификаторов; и период времени достоверности привязочного AKMA-ключа. На 842 по фиг. 14, соответствующая информация пользовательских подписок, записанная в UDM/ARPF 370, может включать в себя одно или более из следующего: индикатор для того, подписано или нет UE на AKMA-услугу; один или более AAnF-идентификаторов; и период времени достоверности привязочного AKMA-ключа. В течение процедуры регистрации и аутентификации UE, UDM/ARPF 370 может передавать информацию по подписке на AKMA-услуги в AUSF 360.

На этапе 1401 по фиг. 14, UE и сеть завершают основную процедуру аутентификации и формируют привязочный AKMA-ключ K_AKMA и соответствующий идентификатор K_ID, AKMA-ключ K_AF приложения и периоды времени достоверности для этих ключей. Эти ключи могут быть недостоверными по различным причинам. На фиг. 14, логическая последовательность 1460, 1470 и 1480 операций иллюстрирует обновления ключей согласно различным примерным сценариям, в которых по меньшей мере один из этих ключей становится недостоверным.

Для примерной логической последовательности 1460 операций, привязочный AKMA-ключ может быть недостоверным. На этапе 1402, UE 310 может инициировать запрос на осуществление связи в AF 390. Запрос на осуществление связи может включать в себя идентификатор для привязочного AKMA-ключа, K_ID. На этапе 1403, AF 390 может отправлять сообщение с запросом на предоставление начального ключа приложения, включающее в себя K_ID и AF_ID, в AAnF 380 согласно AAnF-идентификатору в K_ID. На этапе 1404, AAnF 380 может выполнять запрос на предмет привязочного AKMA-ключа K_AKMA согласно K_ID. Если AAnF 380 не находит привязочный AKMA-ключ K_AKMA, она может отправлять сообщение с запросом на предоставление привязочного AKMA-ключа в AUSF 360. Сообщение с запросом может включать в себя K_ID. На этапе 1405, AUSF 360 может выполнять запрос на предмет достоверного привязочного AKMA-ключа согласно K_ID и может не иметь возможности находить достоверный привязочный AKMA-ключ. AUSF 360 затем может отвечать сообщением со сбоем в AAnF 380, указывающим то, что достоверный привязочный AKMA-ключ не найден. На этапе 1406, AAnF 380 отвечает в AF 390 сообщением со сбоем, указывающим то, что достоверный привязочный AKMA-ключ не найден. На этапе 1407, AF 390 может отвечать сообщением со сбоем в UE 310, указывающим то, что достоверный привязочный AKMA-ключ не найден. На этапе 1408, UE 310 инициирует другой запрос на регистрацию в сеть. Такое сообщение с запросом на регистрацию может включать в себя SUCI UE или 5G-GUTI UE и ngKSI (индекс контекста обеспечения безопасности), например, в 7, указывающий то, что контекст UE-безопасности является недостоверным. На этапе 1409, после того, как UE 310 и сеть завершают другую основную аутентификацию и регистрацию, новый привязочный AKMA-ключ и/или AKMA-ключ приложения, их идентификаторы и/или их периоды времени достоверности могут формироваться. UE 310 и сеть могут сохранять эти ключи, периоды времени достоверности и идентификаторы.

Для примерной логической последовательности 1470 операций, ключ приложения, возможно, истек. На этапе 1410, UE 310 может инициировать запрос на осуществление связи в AF 390. Запрос на осуществление связи может включать в себя идентификатор для привязочного AKMA-ключа, K_ID. На этапе 1411, AF 390 может определять то, что ключ приложения истек. На этапе 1412, AF 390 может отвечать сообщением со сбоем в UE 310, указывающим то, что ключ приложения истек. На этапе 1413, UE 310 инициирует другой запрос на регистрацию в сеть. Такое сообщение с запросом на регистрацию может включать в себя SUCI UE или 5G-GUTI UE и ngKSI (индекс контекста обеспечения безопасности), например, в 7, указывающий то, что контекст UE-безопасности является недостоверным. На этапе 1414, после того, как UE 310 и сеть завершают другую основную аутентификацию и регистрацию, новый привязочный AKMA-ключ и/или AKMA-ключ приложения, их идентификаторы и/или их периоды времени достоверности могут формироваться. UE 310 и сеть могут сохранять эти ключи, периоды времени достоверности и идентификаторы.

Для примерной логической последовательности 1480 операций, привязочный AKMA-ключ, возможно, истек. На этапе 1415, UE 310 может инициировать запрос на осуществление связи в AF 390. Запрос на осуществление связи может включать в себя идентификатор для привязочного AKMA-ключа, K_ID. На этапе 1416, AF 390 может отправлять сообщение с запросом на предоставление ключа приложения, включающее в себя K_ID и AF_ID, в AAnF 380 согласно AAnF-идентификатору в K_ID. На этапе 1417, AAnF 380 может определять то, что привязочный AKMA-ключ K_AKMA истек. На этапе 1418, AAnF 380 отвечает в AF 390 сообщением со сбоем, указывающим то, что привязочный AKMA-ключ истек. На этапе 1419, AF 390 может отвечать сообщением со сбоем в UE 310, указывающим то, что привязочный AKMA-ключ истек. На этапе 1420, UE 310 инициирует другой запрос на регистрацию в сеть. Такое сообщение с запросом на регистрацию может включать в себя SUCI UE или 5G-GUTI UE и ngKSI (индекс контекста обеспечения безопасности), например, в 7, указывающий то, что контекст UE-безопасности является недостоверным. На этапе 1421, после того, как UE 310 и сеть завершают другую основную аутентификацию и регистрацию, новый привязочный AKMA-ключ и/или AKMA-ключ приложения, их идентификаторы и/или их периоды времени достоверности могут формироваться. UE 310 и сеть могут сохранять эти ключи, периоды времени достоверности и идентификаторы.

Вышеприведенные реализации, описанные для фиг. 1-14, в силу этого предоставляют архитектуру для сети связи, чтобы предлагать услугу ключей приложения, на которую могут подписываться терминальные устройства. Эти реализации дополнительно предоставляют различные схемы для формирования, управления и обновления различных иерархических уровней ключей для обеспечения зашифрованной связи между терминальными устройствами и приложениями предоставления услуг через сеть связи. Раскрытые реализации упрощают гибкость при связи с приложениями предоставления услуг и снижают риск для брешей в системе безопасности.

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

Во всем подробном описании и в формуле изобретения, термины могут иметь детализированные смысловые значения, предлагаемые или подразумеваемые в контексте за рамками явно указанного смыслового значения. Аналогично, фраза "в одном варианте осуществления/реализации" при использовании в данном документе не обязательно означает идентичный вариант осуществления, и фраза "в другом варианте осуществления/реализации" при использовании в данном документе не обязательно означает другой вариант осуществления. Например, подразумевается, что заявленный предмет изобретения включает в себя комбинации примерных вариантов осуществления полностью или частично.

В общем, терминология может пониматься, по меньшей мере, частично из использования в контексте. Например, такие термины, как "и", "или" или "и/или", при использовании в данном документе, могут включать в себя множество смысловых значений, которые может зависеть, по меньшей мере, частично от контекста, в котором используются такие термины. Типично, "или", если используется для того, чтобы ассоциировать список, такой как A, B или C, имеет намерение означать A, B и C, используемый здесь во включающем смысле, а также A, B или C, используемый здесь в исключающем смысле. Помимо этого, термин "один или более", при использовании в данном документе, по меньшей мере, частично в зависимости от контекста, может использоваться для того, чтобы описывать любой признак, структуру или характеристику в смысле в единственном числе, либо может использоваться для того, чтобы описывать комбинации признаков, структур или характеристик в смысле во множественном числе. Аналогично, такие термины, как "a", "an" или "the", могут пониматься как передающие использование в единственном числе либо как передающие использование во множественном числе, по меньшей мере, частично в зависимости от контекста. Помимо этого, термин "на основе" может пониматься как необязательно имеющий намерение передавать исключающий набор факторов, и вместо этого, может предоставлять возможность существования дополнительных факторов, необязательно явно описанных, снова, по меньшей мере, частично в зависимости от контекста.

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

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

Изобретение относится к средствам повторного формирования ключей в терминальном устройстве для зашифрованной связи между терминальным устройством и приложением предоставления услуги. Технический результат – повышение защищенности сети связи. Обнаруживают, что первый ключ для обеспечения прямой зашифрованной связи с приложением предоставления услуги, ранее сформированный после успешного завершения первой аутентификации терминального устройства в сети связи, стал недостоверным. Передают запрос на вторую аутентификацию в сеть связи в качестве реакции на обнаружение того, что первый ключ стал недостоверным. Формируют второй ключ для обеспечения прямой зашифрованной связи с приложением предоставления услуги после того, как вторая аутентификация в сети связи является успешной. Заменяют первый ключ вторым ключом и напрямую обмениваются данными с приложением предоставления услуги на основе второго ключа, при этом первый ключ и второй ключ содержат, соответственно, первый привязочный ключ и второй привязочный ключ, сформированные в течение первой аутентификации и регистрации и второй аутентификации и регистрации терминального устройства в сети связи, соответственно. 3 н. и 17 з.п. ф-лы, 14 ил.

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

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

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

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

заменяют первый ключ вторым ключом; и

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

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

2. Способ по п.1, в котором:

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

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

3. Способ по п.2, в котором каждый из первого привязочного ключа и второго привязочного ключа ассоциирован с периодом времени до истечения срока действия ключа и идентификатором ключа.

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

5. Способ по п.4, в котором:

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

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

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

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

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

9. Способ по п.1, в котором обнаружение того, что первый ключ стал недостоверным, содержит этапы, на которых:

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

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

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

10. Способ по п.1, в котором запрос на вторую аутентификацию содержит маскированный идентификатор подписки (SUCI) для идентификации терминального устройства или глобальный уникальный временный идентификатор (GUTI) с идентификатором набора ключей, указывающим то, что контекст обеспечения безопасности для терминального устройства является недостоверным.

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

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

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

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

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

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

определяют, что запрашиваемый привязочный ключ стал недостоверным; и

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

16. Способ по п.15, в котором первый запрос на привязочный ключ содержит первый идентификатор для привязочного ключа.

17. Способ по п.16, в котором определение того, что запрашиваемый привязочный ключ является недостоверным, содержит этапы, на которых:

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

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

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

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

18. Способ по п.15, в котором запрашиваемый привязочный ключ ассоциирован с периодом времени до истечения срока действия, и запрашиваемый привязочный ключ стал недостоверным вследствие конца периода времени до истечения срока действия.

19. Способ по п.15, в котором запрос на процедуру аутентификации содержит маскированный идентификатор подписки (SUCI) для идентификации терминального устройства или глобальный уникальный временный идентификатор (GUTI) с идентификатором набора ключей, указывающим, что контекст обеспечения безопасности для терминального устройства является недостоверным.

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

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

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

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

замены первого ключа вторым ключом; и

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

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