АУТЕНТИФИКАЦИЯ ПРИЛОЖЕНИЯ Российский патент 2011 года по МПК H04L29/06 

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

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

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

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

Текущее развитие в направлении создания действительно мобильных компьютерных сред и компьютерных сетей явилось причиной эволюции различных технологий подключения к коммуникационным сетям, которые также предоставляют возможность доступа к Интернету пользователям, находящимся вне своей домашней сети. До сих пор при использовании Интернета доминировало применение человеко-машинной связи, то есть информационных служб. Эволюция в направлении использования так называемых беспроводных сетей третьего поколения (3G) способствует применению мультимедийных коммуникаций, что приведет также и к изменению способа использования служб на базе протокола IP в общедоступных мобильных сетях. Мультимедийная подсистема на базе протокола IP (IP Multimedia Subsystem, IMS) в соответствии со спецификацией, приведенной в проекте 3^rd Generation Partnership Project (3GPP), интегрирует мобильную речевую связь с Интернет-технологиями, позволяя обеспечить применение в мобильных сетях мультимедийных услуг на базе протокола IP. Новые мобильные терминалы с мультимедийными возможностями (мультимедийные телефоны) предоставляют открытую базовую платформу для разработчиков приложений, позволяя независимым разработчикам приложений разрабатывать новые службы и приложения для среды мультимедиа. В свою очередь, пользователи могут загружать новые приложения/службы в свои мобильные терминалы и использовать эти средства.

Например, в технической спецификации 3GPP TS 33.220 содержатся сведения об общей архитектуре начальной загрузки (Generic Bootstrapping Architecture, GBA), которая является частью общей архитектуры аутентификации (Generic Authentication Architecture, GAA). Общая модель архитектуры GBA приведена на фиг.1. Эта модель содержит четыре различных объекта: абонентское оборудование 14 (User Equipment, UE), функцию 12 сервера начальной загрузки (Bootstrapping Server Function, BSF), функцию 16 сетевого приложения (Network Application Function, NAF) и домашнюю 10 абонентскую систему (Home Subscriber System, HSS). На фиг.1 показаны также интерфейсы между этими объектами.

На фиг.2 представлена схема, иллюстрирующая процедуру начальной загрузки в GBA. Когда оборудованию UE 200 необходимо взаимодействовать с функцией NAF и этому оборудованию известно о необходимости выполнения процедуры начальной загрузки, оно первоначально выполняет аутентификацию начальной загрузки. Когда инициируется начальная загрузка, оборудование UE 200 отправляет (21) HTTP-запрос к функции BSF 202. Функция BSF 202 извлекает (22) полный набор пользовательских параметров безопасности GBA и один вектор аутентификации (Authentication Vector, AV) (AV=RAND||AUTN||XRES||CK||IK) через эталонную точку Zh из системы HSS 204. Затем функция BSF 202 пересылает RAND и AUTN в UE 200 в 401 сообщении (23) (без CK, IK и XRES). Это необходимо, чтобы потребовать от UE 200 выполнить самоаутентификацию. Оборудование UE 200 проверяет (24) AUTN, чтобы удостовериться в том, что вызов поступил из авторизованной сети. Оборудование UE 200 также производит вычисление CK, IK и RES. Это приведет к созданию ключей сеанса связи IK и CK как в BSF 202, так и в UE 200. Оборудование UE 200 отправляет (25) другой HTTP-запрос, содержащий ответ Digest AKA (вычисленный с использованием RES), в BSF 202. Функция BSF 202 выполняет аутентификацию (26) UE 200 посредством проверки ответа Digest AKA и создает (27) главный ключ Ks путем связывания CK и IK. Будет также сформировано значение B-TID. Функция BSF 202 отправляет (28) сообщение 200 OK, включающее значение B-TID, в оборудование UE 200, чтобы указать на успешное завершение аутентификации. Кроме того, в сообщении 200 OK функция BSF 202 предоставляет срок действия ключа Ks. Ключ Ks создается в оборудовании UE 200 путем конкатенации параметров СК и IК. Как UE 200, так и BSF 202 будут использовать Ks, чтобы получить ключ Ks_NAF. Ключ Ks_NAF будет использоваться для обеспечения безопасности эталонной точки Ua (см. фиг.1).

Ключ Ks_NAF вычисляется как Ks_NAF=KDF (Ks, параметры вывода ключа), где KDF - соответствующая функция вывода ключа, а параметры вывода ключа включают личную идентификационную информацию пользователя, параметр NAF_Id и параметр RAND. Функция KDF для GBA определяется в документе 3GPP TS 33.220, приложение В. Параметр NAF_Id содержит полное DNS-имя функции NAF и идентификатор безопасности протокола Ua. Функция KDF должна быть реализована в мобильном оборудовании.

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

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

Так как конкретный ключ NAF, т.е. Ks_NAF, является действительно специфичным для функции NAF (т.е. службы), цель может быть достигнута мобильным терминалом путем ограничения доступа к Ks_NAF только теми приложениями, которым доверяет поставщик услуг NAF. Это ограничение возможно, если аппаратная платформа и программное обеспечение мобильного терминала обладают следующими свойствами безопасности: (1) процессы могут выполнять взаимную аутентификацию и (2) один процесс не может осуществлять доступ к данным другого процесса. Необходимо, однако, чтобы мобильный терминал был сконфигурирован; ему необходимо знать, каким приложениям разрешается доступ к конкретным мандатам NAF (т.е. к определенным ключам NAF).

В мобильном терминале имеются по меньшей мере две опции для конфигурирования прав доступа к мандатам GBA (т.е. к набору конкретных ключей NAF).

Во-первых, мобильный терминал может получить данные конфигурирования с правами доступа для всех приложений NAF из внешнего источника. В этом случае необходимо, чтобы данные конфигурирования поступали из заслуживающего доверия источника и защищалась целостность данных. Права доступа к мандатам GBA могут быть получены в оборудовании ME вместе с другими данными конфигурирования с использованием инфраструктуры управления устройствами (например, процедурами управления устройствами ОМА Device Management), которая обеспечивает выполнение этих требований. Безопасность данных конфигурирования может базироваться на 1) симметричной или 2) асимметричной криптографии. Эта опция может также использоваться без внешней инфраструктуры управления устройствами. Например, мобильный терминал может быть сконфигурирован перед его поставкой конечному пользователю, например, на заводе-изготовителе или в магазине, торгующем мобильными терминалами. После получения мобильного терминала конечным пользователем права доступа могут быть изменены вручную: например, мобильный терминал будет производить запрос владельца для конфигурирования каждого нового права доступа. Однако ручное конфигурирование мобильного терминала может снизить удобство эксплуатации используемой службы, поэтому лучше в максимально возможной степени производить конфигурирование прав доступа автоматически. Кроме того, потенциальным недостатком этой опции является то, что источнику данных конфигурирования должны доверять все поставщики услуг, так как он определяет права доступа для всех приложений NAF.

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

Другим способом конфигурирования прав доступа по отдельности для каждого приложения является использование инфраструктуры открытых ключей (Public Key Infrastructure, PKI) и подписанных приложений. Обычно сигнатура подписанного приложения может быть проверена с использованием конкретного цифрового сертификата для приложения. Система PKI, используемая для сертификации и верификации приложений, может включать возможность определения службы или служб, к которым этому приложению разрешается доступ (то есть, к каким конкретным мандатам NAF имеет права доступа приложение). Эта информация может быть зашифрована в самом сертификате приложения или может являться частью метаданных приложения. Обычно эта информация состоит из идентификаторов NAF, которые однозначно определяют каждый конкретный мандат NAF.

Защита конфигурации с использованием симметричных ключей GBA основана на том, что функция NAF и мобильный терминал совместно используют ключ Ks_NAF. Двумя основными способами реализации этой альтернативы являются следующие: (1) если приложение подписано с использованием ключа Ks_NAF, ему можно доверять для получения доступа к будущим экземплярам мандатов NAF, и (2) если приложение может однажды доказать мобильному терминалу, что оно знает Ks_NAF, то ему можно доверять для получения доступа к будущим экземплярам мандатов NAF.

Когда клиентские приложения устанавливаются на мобильном терминале, нет необходимости устанавливать доверие между этим приложением и сервером GAA_ME (т.е. заслуживающим доверия приложением, которое выполняет процедуру начальной загрузки с использованием BSF), установленным в мобильном терминале, если этому приложению необходимо получить конкретные ключи NAF, которые извлекаются с сервера GAA_ME. Однако имеется способ подписывания приложения с помощью конкретного цифрового сертификата для NAF и использования сигнатуры, чтобы установить доверие к приложению в терминале. Например, это используется в терминалах Symbian. Однако сервер GAA_ME не будет знать, являются ли все установленные приложения заслуживающими доверия, так как это может быть обеспечено только с помощью конкретных ключей NAF.

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

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

КРАТКОЕ ИЗЛОЖЕНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

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

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

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

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

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

Данное изобретение имеет ряд преимуществ по сравнению с известными решениями. Никакие вирусные приложения или даже любые приложения третьей стороны не могут запросить мандаты GAA с сервера GAA_ME, установленного в мобильном оборудовании, если они не могут аутентифицироваться в какой-либо функции NAF и получить совместно используемые секретные данные (т.е. KS_NAF_install), используемые для регистрации на сервере GAA_ME.

Кроме того, изобретение предусматривает решение для получения ключа, совместно используемого сервером GAA_ME и приложением на соседнем терминале. Решение, раскрытое в изобретении, может использоваться для аутентификации приложения ближней связи по отношению к серверу GAA_ME. Однако это может требовать также наличия какой-либо надежной обработки данных (обеспечения безопасности платформы) в соседнем устройстве.

Кроме того, изобретение предлагает оператору привлекательный вариант распространения таких приложений. Для операторов, которые уже имеют аутентификацию на основе имени пользователя и пароля (или какой-то другой механизм аутентификации), решение, раскрытое в изобретении, упрощает переход к использованию мандата на базе GAA.

Кроме того, изобретение может быть также использовано для того, чтобы два устройства создавали групповой общий ключ, который затем используется для групповой связи и может затем распространяться на других пользователей, например, для установления между ними безопасных туннелей и для обмена сертификатами, чтобы создать между ними виртуальную частную сеть (Virtual Private Network, VPN) или установить протокол защиты транспортного уровня (Transport Layer Security, TLS).

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

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

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

на фиг.1 представлена блок-схема, иллюстрирующая архитектуру известного уровня техники - общую архитектуру начальной загрузки (Generic Bootstrapping Architecture, GBA);

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

на фиг.3 представлена блок-схема, иллюстрирующая различные элементы в соответствии с первым вариантом осуществления изобретения, и

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

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

ПОДРОБНОЕ ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ

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

На фиг.3 представлена блок-схема, показывающая различные элементы, которые могут быть частью решения, раскрытого в данном изобретении. На фиг.3 показано пять различных объектов: мобильное оборудование 300 (Mobile Equipment, ME), функция 302 сервера начальной загрузки (Bootstrapping Server Function, BSF), функция 306 сетевого приложения (Network Application Function, NAF), домашняя абонентская система 304 (Home Subscriber System, HSS) и компьютер 308. Блок-схема на фиг.3 также учитывает ситуацию разделенного терминала. В ситуации разделенного терминала локальное приложение 320 находится, например, в компьютере 308. Локальное приложение подключается к серверу GAA_ME мобильного 314 оборудования через модуль 318 и модуль 312 ближней связи. Фактическая связь между мобильным оборудованием 314 и компьютером 308 организуется, например, через линию ближней связи, например беспроводную связь Bluetooth. Компонент АРР_МЕ 310 - это (клиентское) приложение, устанавливаемое в мобильном оборудовании 300. Другими словами, приложение может быть установлено или в самом мобильном оборудовании, или на компьютере 308, который имеет локальное подключение к мобильному оборудованию 300.

Архитектура GAA предоставляет способ создания совместно используемых секретных данных для мобильного оборудования 300 и функции 306 NAF. Эти секретные данные используются всякий раз, когда мобильному оборудованию 300 требуется выполнить аутентификацию в функции 306 NAF. Приложениям в мобильном оборудовании 300 необходимы мандаты USIM (или ISIM, или SIM), чтобы выполнить начальную загрузку GAA для создания конкретных ключей NAF. Возможность получения мандатов USIM от USIM не обязательно должна быть доступна для всех приложений в мобильном оборудовании 300 вследствие угрозы безопасности.

Поэтому доверенный сервер GAA_ME 314 может быть установлен в мобильном оборудовании 300 во время его изготовления или позже и обеспечивает возможность получения мандатов USIM из модуля USIM и, следовательно, возможность выполнения начальной загрузки, чтобы создать мандаты NAF. Затем клиентское приложение (АРР_МЕ) будет использовать услуги сервера 314 GAA_ME, чтобы получить конкретные мандаты NAF. Такое клиентское приложение GAA_ME подготавливается и упаковывается поставщиком NAF. Такое приложение подписывается с использованием цифровой подписи, которая может восприниматься платформой (Symbian, ХР, Linux, Java и т.д.). После установки такое приложение регистрируется на сервере 314 GAA_ME во время первого его запуска.

Мобильное оборудование 300 и функция 306 сетевого приложения может включать память или памяти (не показано на фиг.3), которые могут также включать компьютерную программу (или ее часть), которая при ее исполнении в блоке обработки данных выполняет по меньшей мере некоторые шаги согласно изобретению. Блок обработки данных может также включать память, или память может быть с ним связана. Эта память может включать компьютерную программу (или ее часть), которая при исполнении в блоке обработки данных выполняет по меньшей мере некоторые из шагов изобретения. На фиг.4 приведена схема передачи сигналов, иллюстрирующая первый вариант осуществления изобретения для регистрации и аутентификации приложения в серверном приложении в мобильном оборудовании в соответствии с изобретением.

На фиг.4 показано три различных объекта: сервер 400 функции сервера начальной загрузки (Bootstrapping Server Function, BSF), функция 402 сетевого приложения (Network Application Function, NAF) и мобильное оборудование 404 (Mobile Equipment, ME). Мобильное оборудование 404 содержит клиентское приложение 406 APP_ME и серверное приложение 408 GAA_ME, которое уже было показано на фиг.3. В другом варианте осуществления изобретения клиентское приложение APP_ME может находиться за пределами мобильного оборудования 404, т.е. на внешнем устройстве, подключенном к мобильному оборудованию 404.

В варианте осуществления изобретения на фиг.4 приложение 406 APP_ME посылает запрос на регистрацию (410) на сервер 408 GAA_ME. Запрос указывает серверу 408 GAA_ME на то, что APP_ME необходимо аутентифицировать себя на сервере 408 GAA_ME. Запрос может также включать идентификатор NAF и/или идентификатор экземпляра приложения. Поставщик приложения может предоставить жестко запрограммированное приложение, или оно определенным образом сконфигурировано, чтобы иметь идентификатор NAF и идентификатор экземпляра приложения.

Сервер 408 GAA_ME исполняет (412) протокол начальной загрузки 3GPP с использованием BSF 400. Протокол начальной загрузки раскрывается более подробно, например, в технической спецификации 3GPP «3GPP TS 33.220 V7.2.0 (2005-12)». В течение начальной загрузки сервер 408 GAA_ME принимает, по меньшей мере, идентификатор транзакции начальной загрузки (Bootstrapping Transaction Identifier, BTID) и срок действия ключа от функции 400 BSF и передает (414), по меньшей мере, идентификатор BTID обратно в приложение 406 АРР_МЕ. Так как сервер 408 GAA_ME имеет возможность извлечь данные Ks и узнать идентификатор NAF, он может получить ключ Ks_NAF, который является совместно используемыми секретными данными для сервера 408 GAA_ME и функции 402 NAF. Сервер 408 GAA_ME затем извлечет (422) ключ установки KS_NAF_install с использованием KS_NAF и, факультативно, идентификатор экземпляра приложения, упомянутый ранее, с помощью любого подходящего способа.

После получения идентификатора BTID с сервера 408 GAA_ME приложение 406 АРР_МЕ открывает линию связи с функцией 402 NAF. Линия связи может быть защищенной с использованием, например, протокола безопасных соединений (Secure Socket Layer, SSL) или другого подходящего способа, чтобы исключить возможности атак злоумышленников.

После этого приложение 406 АРР_МЕ выполняет собственную аутентификацию (416) в функции 402 NAF с использованием соответствующей процедуры аутентификации. В известном уровне техники имеется несколько применимых способов аутентификации, которые могут использоваться. Процедура аутентификации может включать один из следующих способов.

- Одноразовый пароль, который жестко запрограммирован в приложении. В этом случае предпочтительно, чтобы код приложения был "запутан", чтобы было очень тяжело извлечь пароль путем простого анализа кода.

- Имя пользователя и пароль, получаемые вне полосы частот (например, в сообщении электронной почты или при посещении магазина).

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

Кроме того, способ аутентификации и организация защиты канала могут быть специфическими для функции NAF. В случае совместно используемых секретных данных может также использоваться протокол TLS с общим ключом. К тому же для аутентификации могут с успехом применяться способы аутентификации HTTP-DIGEST.

Когда приложение 406 АРР_МЕ выполнило аутентификацию в функции 402 NAF, функция 402 NAF извлекает (418) конкретный ключ KS_NAF для NAF из функции 400 BSF с использованием идентификатора BTID и получает (420) KS_NAF_install (аналогично шагу 422). Затем эта функция передает (424) KS_NAF_install в приложение 406 АРР_МЕ. Желательно, чтобы эта передача была секретной.

Теперь приложение 406 АРР_МЕ может выполнить свою аутентификацию (426) на сервере 408 GAA_ME, используя KS_NAF_install в качестве совместно используемых секретных данных. Если аутентификация завершилась успешно, сервер 408 GAA_ME может добавить (428) приложение в свой список заслуживающих доверия приложений, в зависимости от его локальной конфигурации. Поэтому шаг 428 может быть также факультативным шагом. Если приложение находится в списке заслуживающих доверия приложений, то всякий раз, когда в будущем приложение 406 АРР_МЕ делает запрос на ключи NAF, сервер 408 GAA_ME выполняет начальную загрузку и предоставляет ключи NAF без какой-либо дополнительной авторизации от функции 402 NAF.

В варианте осуществления изобретения, показанном на фиг.4, два блока извлечения ключа установки (420, 422) помещены на одном уровне. Однако каждый из них может быть перемещен вверх или вниз, в зависимости от требований. Извлечение ключа установки может быть выполнено, например, путем хэширования с использованием KS__(ext)_NAF и идентификатора экземпляра приложения или просто путем использования самого элемента KS_(ext)_NAF в качестве KS_NAF_install.

Совместно используемые секретные данные, используемые для начальной аутентификации приложения 406 АРР_МЕ и функции 402 NAF, могут также быть одноразовым паролем. Пароль может быть удален в функции 402 NAF сразу же после того, как терминал установит отношения доверия с сервером 408 GAA_ME клиента. Совместно используемые секретные данные могут также быть получены на базе некоторых характеристик мобильного терминала. Кроме того, в качестве протокола аутентификации между приложением 406 АРР_МЕ и самой функцией 402 NAF может использоваться любой из широко известных протоколов аутентификации. Сразу после выполнения аутентификации может использоваться один из широко известных способов обеспечения безопасности связи между приложением 406 АР_МЕ и функцией 402 NAF. Если применяются совместно используемые секретные данные (например, имя пользователя и пароль), одной из альтернатив является протокол TLS с общим ключом.

В одном варианте осуществления изобретения, когда сервер 408 GAA_ME успешно выполнит аутентификацию приложения 406 АРР_МЕ, используя определенный идентификатор NAF, сервер 408 GAA_ME может предоставить АРР_МЕ доступ только к будущим экземплярам ключа Ks_NAF, которые принадлежат к тому же самому идентификатору NAF, а остальные конкретные ключи NAF будут недоступны. В другом варианте осуществления изобретения приложению 406 АРР_МЕ предоставляется полный доступ, т.е. оно может получить ключи KS_NAF любой функции NAF.

Кроме того, в первом варианте осуществления изобретения во время процедуры могут использоваться множественные ключи Ks_NAF, чтобы предоставить доступ к различным ключам, т.е. функция 402 NAF извлекает различные ключи Ks_NAF из функции 400 BSF (при условии, что она авторизована это делать) и функция 402 NAF извлекает различные ключи Ks_NAF_install и отправляет их приложению 406 АРР_МЕ. Приложение 406 АРР_МЕ может затем зарегистрировать их с помощью сервера 408 GAA_ME. Таким образом, приложение 406 АРР_МЕ получит доступ более чем к одному конкретному ключу NAF.

На фиг.5 приведена схема передачи сигналов, иллюстрирующая другой вариант осуществления изобретения для регистрации и аутентификации приложения в серверном приложении в мобильном оборудовании в соответствии с данным изобретением. На фиг.5 показано три различных объекта: функция 500 сервера начальной загрузки (BSF), функция сетевого приложения 502 (NAF) и мобильное оборудование 504 (ME). Мобильное оборудование 504 содержит клиентское приложение 506 АРР_МЕ и серверное приложение 508 GAA_ME, которое уже было показано на фиг.3. В другом варианте осуществления клиентское приложение АРР_МЕ может находиться за пределами мобильного оборудования 504, т.е. на внешнем устройстве, подключенном к мобильному оборудованию 504.

В варианте осуществления изобретения на фиг.5 приложение 506 АРР_МЕ посылает запрос на регистрацию (510) на сервер 508 GAA_ME. Запрос указывает серверу 508 GAA_ME на то, что АРР_МЕ необходимо авторизовать себя на сервере 508 GAA_ME. Запрос может также включать идентификатор NAF и/или идентификатор экземпляра приложения. Поставщик приложения может предоставить жестко запрограммированное приложение, или оно определенным образом конфигурируется, чтобы иметь идентификатор NAF и идентификатор экземпляра приложения.

Сервер 508 GAA_ME выполняет (512) протокол начальной загрузки 3GPP с использованием функции 500 BSF. Протокол начальной загрузки раскрывается более подробно, например, в технической спецификации 3GPP «3GPP TS 33.220 W.2.0 (2005-12)». В течение начальной загрузки сервер 508 GAA_ME принимает, по меньшей мере, идентификатор BTID и срок действия ключа из функции 500 BSF. Так как сервер 508 GAA_ME имеет возможность извлечь ключ Ks и знает идентификатор NAF, он может извлечь ключ Ks_NAF (514), который является совместно используемыми секретными данными для сервера 508 GAA_ME и функции 502 NAF. Сервер 508 GAA_ME также создает (514) произвольный вызов для приложения 506 АРР_МЕ. После этого сервер 508 GAA_ME передает (514), по меньшей мере, идентификатор BTID и вызов в приложение 506 АРР_МЕ.

После приема идентификатора BTID и вызова из сервера 508 GAA_ME приложение 506 АРР_МЕ открывает линию связи с функцией 502 NAF и передает (518) B-TID и вызов в приложение 502 NAF. Линия связи может быть защищенной, чтобы исключить возможности атак злоумышленников.

Функция 502 NAF извлекает (520) конкретный ключ KS_NAF для NAF из функции 400 BSF, используя идентификатор BTID, и получает (522) ответ на вызов с использованием Ks_NAF. Ответ может быть вычислен, например, посредством использования односторонней хэш-функции или ключевого хэшированного кода аутентификации сообщения (НМАС), где входные параметры включают, по меньшей мере, Ks_NAF и вызов. Функция 502 NAF может также подписывать данные с использованием ключа Ks_NAF. Данные могут включать один или более хэшей для приложений, которые функция 502 NAF авторизует для получения доступа к конкретным ключам NAF (Ks_NAF). Один из этих хэшей может быть хэшем приложения АРР_МЕ (506), которое установлено ранее в мобильном оборудовании ME (504). Следует отметить, что хэш приложения является просто одной из возможностей. Вместо хеша возможно использование любой другой порции информации, т.е. адекватного описания приложения. Например, если приложение размещается на другом устройстве, которое подключено к терминалу пользователя через локальную сеть, такую как беспроводная локальная сеть WLAN или Bluetooth, в качестве описания приложения может использоваться сетевой адрес устройства. Возможным описанием приложения на внешнем устройстве может быть также серийный номер этого устройства. Кроме того, одним из возможных описаний может быть открытый ключ для подписывания контента. Кроме того, в варианте осуществления изобретения запрос (518) к функции 502 NAF может включать какое-то описание платформы (например, «Работа на устройстве Nokia Series 60 v3.1»), которое затем помогает функции 502 NAF отправить обратно правильное допустимое описание приложения. Затем функция 502 NAF (524) передает ответ и, возможно, подписанные данные в приложение 506 АРР_МЕ.

Подписанные данные относятся, например, к каким-то дополнительным данным, которые функция 502 NAF добавляет в сообщение, то есть подписанным с использованием ключа Ks_NAF. Таким образом, сервер GAA_ME может проверить подпись этих дополнительных данных и убедиться в том, что они поступили из заслуживающего доверия источника, которому известен ключ Ks_NAF.

Теперь приложение 506 АРР_МЕ может выполнить свою авторизацию (526) на сервере 508 GAA_ME_Server посредством использования ответа и подписанных данных. Если авторизация успешна, т.е. ответ и сигнатура подписанных данных являются правильными, сервер 508 GAA_ME продолжает процедуру авторизации и предоставляет доступ приложению 506 АРР_МЕ к ключу Ks_NAF. Кроме того, сервер 508 GAA_ME может также вычислить хэш приложения 506 АРР_МЕ и проверить, имеется ли этот хэш в подписанных данных. Если по меньшей мере одна из вышеуказанных проверок завершилась успешно, сервер 508 GAA_ME может добавить (528) приложение в свой список заслуживающих доверия приложений, в зависимости от его локальной конфигурации. Если приложение находится в списке заслуживающих доверия приложений, то всякий раз, когда в будущем приложение 506 АРР_МЕ делает запрос на ключи NAF, сервер 508 GAA_ME выполняет начальную загрузку и предоставляет ключи NAF без какой-либо дополнительной авторизации от функции NAF.

Возможное добавление приложения в такой доверенный список позволяет иметь «одноразовые права доступа» и «полные права доступа». В первом случае АРР_МЕ должно будет всегда получать дополнительную авторизацию (ответ, подписанные данные или оба эти элемента) для каждого запроса на Ks_NAF, а во втором случае АРР_МЕ получит постоянное право доступа и не должно получать дополнительную авторизацию при будущих запросах на ключ Ks_NAF.

Наконец, если произведенные выше проверки были успешными, сервер 508 GAA_ME (530) указывает приложению АРР_МЕ, что процедура завершилась успешно и, возможно, включает в это сообщение ключ Ks_NAF.

В варианте осуществления изобретения, когда сервер 508 GAA_ME успешно выполнит аутентификацию приложения 506 АРР_МЕ, сервер 408 GAA_ME может предоставить доступ только к конкретному ключу Ks_NAF определенной функции NAF, который использовался в течение процедуры, а конкретные ключи других функций NAF будут недоступны. В частности, это может произойти в случае, если подписанные данные не были отправлены из функции 502 NAF 502 на сервер 508 GAA_ME через приложение 506 АРР_МЕ. В другом варианте осуществления изобретения приложению 506 АРР_МЕ предоставляются полные права доступа, т.е. оно может получить все возможные ключи KS_NAF.

В другом варианте осуществления изобретения KS_(ext)_NAF используется в качестве группового ключа, чтобы обеспечить безопасность групповой связи, и он может использоваться совместно с другими устройствами, которые могут не иметь какой-либо генерации ключей GBA или возможности запроса. Это может использоваться для обеспечения безопасности линии связи, например, в домашней среде с использованием многочисленных устройств с ограниченными возможностями или для установки персональной виртуальной частной сети (Virtual Private Network, VPN).

Кроме того, в варианте осуществления изобретения идентификатор NAF_Id может передаваться из приложения 506 АРР_МЕ на сервер 508 GAA_ME или на шаге 510, как это описано выше, или на шаге 526.

Кроме того, в варианте осуществления изобретения во время процедуры могут использоваться множественные ключи Ks_NAF, чтобы предоставить доступ к различным ключам, т.е. функция 502 NAF извлекает различные ключи Ks_NAF из функции 500 BSF (при условии, что она авторизована это делать) и функция 502 NAF вычисляет различные ответы на запросы, используя эти ключи Ks_NAF, и также, факультативно, подписывает данные, используя все или подмножество ключей Ks_NAF, и отправляет их приложению 506 АРР_МЕ. Приложение 506 АРР_МЕ может затем зарегистрировать их с помощью сервера 508 GAA_ME. Таким образом, приложение 506 АРР_МЕ получит доступ более чем к одному конкретному ключу NAF.

Кроме того, этот способ может применяться во многих других случаях, в которых терминальное оборудование конфигурируется так, чтобы доверять поставщику услуг (например, производителю оборудования или сетевому оператору), и, таким образом, терминальное оборудование и поставщик услуг или имеет, или может согласовать общий ключ. Как было подробно рассмотрено, если новое приложение может быть удостоверено на терминале в качестве заслуживающего доверия со стороны упомянутого поставщика услуг, оно затем может быть помечено как «заслуживающее доверия» и установлено на терминале пользователя. Эта проверка базируется на знании ключа, используемого совместно терминалом и поставщиком услуг.

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

Архитектура GBA 3GPP является одним из способов извлечения общих ключей и установления доверия между терминалом и поставщиком услуг. Могут быть предложены также и другие способы. Например, при использовании инфраструктуры открытых ключей (Public Key Infrastructure, PKI) обе стороны будут обмениваться сертификатами своих открытых ключей, проверять подпись каждого из партнеров и выполнять обработку, чтобы извлечь общий ключ. Или в качестве другого примера долгосрочный общий ключ может быть предварительно установлен на терминале сетевым оператором или производителем терминала.

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

Изобретение относится к области сетей передачи данных. Технический результат заключается в оптимизации доступа приложений. Сущность изобретения заключается в том, что способ включает выполнение серверным приложением (408) процедур (412) начальной загрузки между этим серверным приложением (408) и функцией (400) сервера начальной загрузки; получение (420, 422) общего ключа на основе, по меньшей мере, ключа, принятого от сервера (400) функции сервера начальной загрузки во время процедур (412) начальной загрузки, и идентификатора функции сетевого приложения; предоставление (414) приложению (406) идентификатора транзакции начальной загрузки, принятого от сервера функции сервера начальной загрузки (400) во время процедур начальной загрузки (412); прием ответа от приложения (406) и аутентификацию (426) приложения путем проверки ответа с использованием общего ключа. 7 н. и 42 з.п. ф-лы, 5 ил.

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

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

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

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

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

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

7. Способ по п.6, в котором запрос регистрации содержит идентификатор экземпляра приложения.

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

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

10. Способ по п.9, также содержащий предоставление приложению общего ключа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

26. Машиночитаемый носитель данных по п.25, отличающийся тем, что запрос регистрации содержит идентификатор экземпляра приложения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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