RU2414086C2 - Аутентификация приложения - Google Patents

Аутентификация приложения Download PDF

Info

Publication number
RU2414086C2
RU2414086C2 RU2008141089/09A RU2008141089A RU2414086C2 RU 2414086 C2 RU2414086 C2 RU 2414086C2 RU 2008141089/09 A RU2008141089/09 A RU 2008141089/09A RU 2008141089 A RU2008141089 A RU 2008141089A RU 2414086 C2 RU2414086 C2 RU 2414086C2
Authority
RU
Russia
Prior art keywords
application
server
function
bootstrap
response
Prior art date
Application number
RU2008141089/09A
Other languages
English (en)
Other versions
RU2008141089A (ru
Inventor
Шреекант ЛАКШМЕШВАР (IN)
Шреекант ЛАКШМЕШВАР
Филип ГИНЗБУРГ (FI)
Филип ГИНЗБУРГ
Пекка ЛАЙТИНЕН (FI)
Пекка ЛАЙТИНЕН
Сильке ХОЛЬТМАННС (FI)
Сильке ХОЛЬТМАННС
Original Assignee
Нокиа Корпорейшн
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Нокиа Корпорейшн filed Critical Нокиа Корпорейшн
Publication of RU2008141089A publication Critical patent/RU2008141089A/ru
Application granted granted Critical
Publication of RU2414086C2 publication Critical patent/RU2414086C2/ru

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431Key distribution or pre-distribution; Key agreement
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02Terminal devices
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80Wireless
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/061Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying further key derivation, e.g. deriving traffic keys from a pair-wise master key
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083Network architectures or network communication protocols for network security for authentication of entities using passwords
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04Key management, e.g. using generic bootstrapping architecture [GBA]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04SSYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S40/00Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
    • Y04S40/20Information technology specific aspects, e.g. CAD, simulation, modelling, system security

Abstract

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

Description

ПРЕДПОСЫЛКИ СОЗДАНИЯ ИЗОБРЕТЕНИЯ
Область техники, к которой относится изобретение
Данное изобретение относится к аутентификации. В частности, данное изобретение относится к новым и усовершенствованным способам, компьютерным программам и мобильному терминалу для аутентификации клиентского приложения.
Уровень техники
Текущее развитие в направлении создания действительно мобильных компьютерных сред и компьютерных сетей явилось причиной эволюции различных технологий подключения к коммуникационным сетям, которые также предоставляют возможность доступа к Интернету пользователям, находящимся вне своей домашней сети. До сих пор при использовании Интернета доминировало применение человеко-машинной связи, то есть информационных служб. Эволюция в направлении использования так называемых беспроводных сетей третьего поколения (3G) способствует применению мультимедийных коммуникаций, что приведет также и к изменению способа использования служб на базе протокола IP в общедоступных мобильных сетях. Мультимедийная подсистема на базе протокола IP (IP Multimedia Subsystem, IMS) в соответствии со спецификацией, приведенной в проекте 3rd 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) обе стороны будут обмениваться сертификатами своих открытых ключей, проверять подпись каждого из партнеров и выполнять обработку, чтобы извлечь общий ключ. Или в качестве другого примера долгосрочный общий ключ может быть предварительно установлен на терминале сетевым оператором или производителем терминала.
Для специалиста в этой области техники очевидно, что с развитием техники основная идея изобретения может быть реализована различными способами. Таким образом, изобретение и варианты его осуществления не ограничиваются приведенными выше примерами, а могут изменяться в объеме формулы изобретения.

Claims (49)

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, отличающийся тем, что указанный код также адаптирован для приема от приложения запроса на ключ функции сетевого приложения и для отправки приложению ключа функции сетевого приложения в ответ на запрос.
RU2008141089/09A 2006-03-28 2007-03-26 Аутентификация приложения RU2414086C2 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US78635706P 2006-03-28 2006-03-28
US60/786,357 2006-03-28

Publications (2)

Publication Number Publication Date
RU2008141089A RU2008141089A (ru) 2010-05-10
RU2414086C2 true RU2414086C2 (ru) 2011-03-10

Family

ID=38540823

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2008141089/09A RU2414086C2 (ru) 2006-03-28 2007-03-26 Аутентификация приложения

Country Status (15)

Country Link
US (1) US8522025B2 (ru)
EP (1) EP2005702B1 (ru)
JP (1) JP4824813B2 (ru)
KR (1) KR101038064B1 (ru)
CN (1) CN101455053B (ru)
AU (1) AU2007231303A1 (ru)
BR (1) BRPI0710257B1 (ru)
ES (1) ES2661307T3 (ru)
IL (1) IL194428A (ru)
MX (1) MX2008012363A (ru)
MY (1) MY149495A (ru)
PL (1) PL2005702T3 (ru)
RU (1) RU2414086C2 (ru)
WO (1) WO2007110468A1 (ru)
ZA (1) ZA200809137B (ru)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2716736C2 (ru) * 2015-12-28 2020-03-16 Льейданетворкс Сервейс Телематикс, С.А. Способ сертификации электронного сообщения, содержащего признанную электронную подпись, оператором связи
US11805410B2 (en) 2019-01-21 2023-10-31 Telefonaktiebolaget Lm Ericsson (Publ) Methods for authentication and key management in a wireless communications network and related apparatuses

Families Citing this family (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1744567A1 (en) * 2005-07-12 2007-01-17 Hewlett-Packard Development Company, L.P. Signalling gateway
DK2039199T3 (en) * 2006-07-06 2019-01-21 Nokia Technologies Oy ACCESSORIES SYSTEM FOR USER EQUIPMENT
KR101495722B1 (ko) * 2008-01-31 2015-02-26 삼성전자주식회사 홈 네트워크에서의 통신 보안성을 보장하는 방법 및 이를위한 장치
US20090220075A1 (en) * 2008-02-28 2009-09-03 Akros Techlabs, Llc Multifactor authentication system and methodology
US9402277B2 (en) * 2008-03-03 2016-07-26 Qualcomm Incorporated Proxy server for facilitating power conservation in wireless client terminals
US8934404B2 (en) * 2008-03-03 2015-01-13 Qualcomm Incorporated Access point with proxy functionality for facilitating power conservation in wireless client terminals
US8478360B2 (en) * 2008-03-03 2013-07-02 Qualcomm Incorporated Facilitating power conservation in wireless client terminals
US8503462B2 (en) * 2008-03-14 2013-08-06 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for remote access to a local network
US20090259851A1 (en) * 2008-04-10 2009-10-15 Igor Faynberg Methods and Apparatus for Authentication and Identity Management Using a Public Key Infrastructure (PKI) in an IP-Based Telephony Environment
EP2382580A4 (en) * 2009-01-16 2013-06-12 Ericsson Telefon Ab L M PROXY SERVER, METHOD FOR CONTROLLING THE SAME, CONTENT SERVER, AND CONTROL METHOD THEREOF
WO2010090569A1 (en) * 2009-02-05 2010-08-12 Telefonaktiebolaget Lm Ericsson (Publ) Apparatuses and a method for protecting a bootstrap message in a network
US8639273B2 (en) * 2009-02-06 2014-01-28 Qualcomm Incorporated Partitioned proxy server for facilitating power conservation in wireless client terminals
KR101012872B1 (ko) 2009-09-16 2011-02-08 주식회사 팬택 플랫폼 보안 장치 및 방법
KR101659082B1 (ko) * 2010-04-06 2016-09-22 주식회사 엘지유플러스 휴대용 단말기에 설치된 애플리케이션 실행 제어 방법 및 시스템
WO2011128183A2 (en) * 2010-04-13 2011-10-20 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for interworking with single sign-on authentication architecture
US8527017B2 (en) 2010-04-14 2013-09-03 Qualcomm Incorporated Power savings through cooperative operation of multiradio devices
US8761064B2 (en) 2010-04-14 2014-06-24 Qualcomm Incorporated Power savings through cooperative operation of multiradio devices
US8566594B2 (en) * 2010-04-14 2013-10-22 Qualcomm Incorporated Power savings through cooperative operation of multiradio devices
EP2580701A4 (en) * 2010-06-10 2016-08-17 Ericsson Telefon Ab L M USER EQUIPMENT AND ITS CONTROL METHOD
CN102595389B (zh) 2011-01-14 2017-11-03 中兴通讯股份有限公司 一种mtc服务器共享密钥的方法及系统
WO2012134369A1 (en) * 2011-04-01 2012-10-04 Telefonaktiebolaget L M Ericsson (Publ) Methods and apparatuses for avoiding damage in network attacks
US9608971B2 (en) 2011-09-08 2017-03-28 Telefonaktiebolaget Lm Ericcson (Publ) Method and apparatus for using a bootstrapping protocol to secure communication between a terminal and cooperating servers
US9503460B2 (en) * 2011-10-13 2016-11-22 Cisco Technology, Inc. System and method for managing access for trusted and untrusted applications
EP2774068A4 (en) * 2011-10-31 2015-08-05 SECURITY MECHANISM FOR AN EXTERNAL CODE
GB201122206D0 (en) 2011-12-22 2012-02-01 Vodafone Ip Licensing Ltd Sampling and identifying user contact
US9781085B2 (en) * 2012-02-14 2017-10-03 Nokia Technologies Oy Device to device security using NAF key
FR2992811A1 (fr) * 2012-07-02 2014-01-03 France Telecom Mise en place d'une association de securite lors de l'attachement d'un terminal a un reseau d'acces
CN104272287A (zh) * 2012-07-31 2015-01-07 惠普发展公司,有限责任合伙企业 管理应用和网络之间的接口
BR112012033255A2 (pt) * 2012-10-29 2017-11-28 Ericsson Telecomunicacoes Sa método e aparelho para garantir uma conexão em uma rede de comunicação
US9253185B2 (en) * 2012-12-12 2016-02-02 Nokia Technologies Oy Cloud centric application trust validation
US9032212B1 (en) * 2013-03-15 2015-05-12 Emc Corporation Self-refreshing distributed cryptography
US9332011B2 (en) * 2013-04-09 2016-05-03 Yash Karakalli Sannegowda Secure authentication system with automatic cancellation of fraudulent operations
US9392459B2 (en) 2013-05-22 2016-07-12 Convida Wireless, Llc Access network assisted bootstrapping
US9521000B1 (en) * 2013-07-17 2016-12-13 Amazon Technologies, Inc. Complete forward access sessions
US9852282B2 (en) 2013-07-31 2017-12-26 Hewlett-Packard Development Company, L.P. Protecting data in memory of a consumable product
GB2586549B (en) * 2013-09-13 2021-05-26 Vodafone Ip Licensing Ltd Communicating with a machine to machine device
KR102398221B1 (ko) 2013-10-30 2022-05-16 삼성전자주식회사 무선 직접통신 네트워크에서 비대칭 키를 사용하여 아이덴티티를 검증하기 위한 방법 및 장치
US9801002B2 (en) 2013-11-26 2017-10-24 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for identifying application instances within a machine-to-machine network domain
CN105814834B (zh) 2013-12-20 2019-12-20 诺基亚技术有限公司 用于公共云应用的基于推送的信任模型
US9374358B2 (en) 2013-12-31 2016-06-21 Google Inc. Methods, systems, and media for providing access control for a computing device
US10664833B2 (en) 2014-03-05 2020-05-26 Mastercard International Incorporated Transactions utilizing multiple digital wallets
US10326597B1 (en) 2014-06-27 2019-06-18 Amazon Technologies, Inc. Dynamic response signing capability in a distributed system
MY184944A (en) * 2014-07-24 2021-04-30 Mimos Berhad Method and system for computation and verification of authentication parameters from independant measurements of time or location
MX367997B (es) 2015-02-27 2019-09-13 Ericsson Telefon Ab L M Disposiciones de seguridad en comunicación entre un dispositivo de comunicación y un dispositivo de red.
US11265165B2 (en) * 2015-05-22 2022-03-01 Antique Books, Inc. Initial provisioning through shared proofs of knowledge and crowdsourced identification
CN108702615B (zh) * 2016-02-12 2022-08-05 瑞典爱立信有限公司 保护接口以及用于建立安全通信链路的过程
US10482255B2 (en) * 2016-02-16 2019-11-19 Atmel Corporation Controlled secure code authentication
US20210089854A1 (en) * 2017-04-14 2021-03-25 Sony Corporation Communication device, information processing device, and data processing system
US20220191008A1 (en) * 2019-03-12 2022-06-16 Nokia Technologies Oy Communication network-anchored cryptographic key sharing with third-party application
EP3726873A1 (en) * 2019-04-18 2020-10-21 Thales Dis France SA Method to authenticate a user at a service provider
US11238147B2 (en) * 2019-08-27 2022-02-01 Comcast Cable Communications, Llc Methods and systems for verifying applications
US10986504B1 (en) * 2020-03-24 2021-04-20 Appbrilliance, Inc. System architecture for accessing secure data from a mobile device in communication with a remote server
US11520895B2 (en) 2020-12-07 2022-12-06 Samsung Electronics Co., Ltd. System and method for dynamic verification of trusted applications
WO2023042176A1 (en) * 2021-09-18 2023-03-23 Telefonaktiebolaget Lm Ericsson (Publ) Gba key diversity for multiple applications in ue

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003202929A (ja) * 2002-01-08 2003-07-18 Ntt Docomo Inc 配信方法および配信システム
US8037515B2 (en) * 2003-10-29 2011-10-11 Qualcomm Incorporated Methods and apparatus for providing application credentials
CN1315268C (zh) * 2003-11-07 2007-05-09 华为技术有限公司 一种验证用户合法性的方法
EP1536606A1 (fr) 2003-11-27 2005-06-01 Nagracard S.A. Méthode d'authentification d'applications
US20050135622A1 (en) * 2003-12-18 2005-06-23 Fors Chad M. Upper layer security based on lower layer keying
CN1300976C (zh) * 2004-01-16 2007-02-14 华为技术有限公司 一种网络应用实体获取用户身份标识信息的方法
CN1265676C (zh) * 2004-04-02 2006-07-19 华为技术有限公司 一种实现漫游用户使用拜访网络内业务的方法
GB0409496D0 (en) * 2004-04-28 2004-06-02 Nokia Corp Subscriber identities
GB0409704D0 (en) * 2004-04-30 2004-06-02 Nokia Corp A method for verifying a first identity and a second identity of an entity
US20060020791A1 (en) * 2004-07-22 2006-01-26 Pekka Laitinen Entity for use in a generic authentication architecture
US8543814B2 (en) 2005-01-12 2013-09-24 Rpx Corporation Method and apparatus for using generic authentication architecture procedures in personal computers
US8726023B2 (en) * 2005-02-03 2014-05-13 Nokia Corporation Authentication using GAA functionality for unidirectional network connections
EP2259539B1 (en) * 2005-02-04 2013-10-09 QUALCOMM Incorporated Secure bootstrapping for wireless communications
US7628322B2 (en) * 2005-03-07 2009-12-08 Nokia Corporation Methods, system and mobile device capable of enabling credit card personalization using a wireless network
US20060206710A1 (en) * 2005-03-11 2006-09-14 Christian Gehrmann Network assisted terminal to SIM/UICC key establishment
FI20050384A0 (fi) * 2005-04-14 2005-04-14 Nokia Corp Geneerisen todentamisarkkitehtuurin käyttö Internet-käytäntöavainten jakeluun matkaviestimissä
FI20050562A0 (fi) * 2005-05-26 2005-05-26 Nokia Corp Menetelmä avainmateriaalin tuottamiseksi
US8353011B2 (en) * 2005-06-13 2013-01-08 Nokia Corporation Apparatus, method and computer program product providing mobile node identities in conjunction with authentication preferences in generic bootstrapping architecture (GBA)
US8087069B2 (en) * 2005-06-13 2011-12-27 Nokia Corporation Method, apparatus and computer program product providing bootstrapping mechanism selection in generic bootstrapping architecture (GBA)
EP1900169B1 (en) * 2005-07-07 2010-02-03 Telefonaktiebolaget LM Ericsson (publ) Method and arrangement for authentication and privacy
US20070042754A1 (en) * 2005-07-29 2007-02-22 Bajikar Sundeep M Security parameter provisioning in an open platform using 3G security infrastructure
US20070086590A1 (en) * 2005-10-13 2007-04-19 Rolf Blom Method and apparatus for establishing a security association

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2716736C2 (ru) * 2015-12-28 2020-03-16 Льейданетворкс Сервейс Телематикс, С.А. Способ сертификации электронного сообщения, содержащего признанную электронную подпись, оператором связи
US11805410B2 (en) 2019-01-21 2023-10-31 Telefonaktiebolaget Lm Ericsson (Publ) Methods for authentication and key management in a wireless communications network and related apparatuses

Also Published As

Publication number Publication date
CN101455053B (zh) 2012-07-04
AU2007231303A1 (en) 2007-10-04
CN101455053A (zh) 2009-06-10
IL194428A (en) 2012-04-30
BRPI0710257A2 (pt) 2011-08-09
JP2009531764A (ja) 2009-09-03
US8522025B2 (en) 2013-08-27
ES2661307T3 (es) 2018-03-28
ZA200809137B (en) 2009-11-25
BRPI0710257A8 (pt) 2016-07-12
JP4824813B2 (ja) 2011-11-30
EP2005702A4 (en) 2012-04-04
MX2008012363A (es) 2008-10-09
EP2005702A1 (en) 2008-12-24
IL194428A0 (en) 2009-08-03
MY149495A (en) 2013-09-13
PL2005702T3 (pl) 2018-05-30
EP2005702B1 (en) 2017-12-20
WO2007110468A1 (en) 2007-10-04
BRPI0710257B1 (pt) 2019-11-05
KR20080106982A (ko) 2008-12-09
RU2008141089A (ru) 2010-05-10
US20070234041A1 (en) 2007-10-04
KR101038064B1 (ko) 2011-06-01

Similar Documents

Publication Publication Date Title
RU2414086C2 (ru) Аутентификация приложения
JP5390619B2 (ja) Homenode−b装置およびセキュリティプロトコル
US20080016230A1 (en) User equipment credential system
US20110271330A1 (en) Solutions for identifying legal user equipments in a communication network
JP2007528650A (ja) エンティティの第1のidおよび第2のidの検証方法
US11917416B2 (en) Non-3GPP device access to core network
US20230328524A1 (en) Non-3gpp device access to core network
JP2017139026A (ja) 信頼できる認証およびログオンのための方法および装置
WO2018137239A1 (zh) 一种鉴权方法、鉴权服务器和核心网设备
RU2779029C1 (ru) Доступ не отвечающего спецификациям 3gpp устройства к базовой сети
TWI755951B (zh) 通訊系統及通訊方法
KR20140095050A (ko) 이동 통신 시스템에서 단일 사용자 승인을 지원하는 관리 방법 및 장치
AU2012203961B2 (en) Authenticating an application

Legal Events

Date Code Title Description
PC41 Official registration of the transfer of exclusive right

Effective date: 20160602