BRPI0710257A2 - métodod para aumentar uma aplicação; método para autenticar uma aplicação com uma aplicação de servidor; método para derivar uma chave de autenticação; programa de computador para autenticação de uma aplicação; programa de computador para derivação; terminal móvel para autenticação de uma aplicação - Google Patents

métodod para aumentar uma aplicação; método para autenticar uma aplicação com uma aplicação de servidor; método para derivar uma chave de autenticação; programa de computador para autenticação de uma aplicação; programa de computador para derivação; terminal móvel para autenticação de uma aplicação Download PDF

Info

Publication number
BRPI0710257A2
BRPI0710257A2 BRPI0710257-7A BRPI0710257A BRPI0710257A2 BR PI0710257 A2 BRPI0710257 A2 BR PI0710257A2 BR PI0710257 A BRPI0710257 A BR PI0710257A BR PI0710257 A2 BRPI0710257 A2 BR PI0710257A2
Authority
BR
Brazil
Prior art keywords
application
server
response
self
loading
Prior art date
Application number
BRPI0710257-7A
Other languages
English (en)
Inventor
Shreekanth Lakshmesshwar
Philip Ginzboorg
Pekka Laitinen
Silke Holtmanns
Original Assignee
Nokia Corp
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 Nokia Corp filed Critical Nokia Corp
Publication of BRPI0710257A2 publication Critical patent/BRPI0710257A2/pt
Publication of BRPI0710257A8 publication Critical patent/BRPI0710257A8/pt
Publication of BRPI0710257B1 publication Critical patent/BRPI0710257B1/pt

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/061—Additional 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key 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/083—Key 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/0833—Key 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic 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/321—Cryptographic 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic 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/3271—Cryptographic 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • Y—GENERAL 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
    • Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04S—SYSTEMS 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/00—Systems 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/20—Information technology specific aspects, e.g. CAD, simulation, modelling, system security

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)
  • Stored Programmes (AREA)

Abstract

<B>MéTODO PARA AUTENTICAR UMA APLICAçãO; MéTODO PARA AUTENTICAR UMA APLICAçãO COM UMA APLICAçãO DE SERVIDOR; MéTODO PARA DERIVAR UMA CHAVE DE AUTENTICAçãO; PROGRAMA DE COMPUTADOR PARA AUTENTICAçãO DE UMA APLICAçãO; PROGRAMA DE COMPUTADOR PARA DERIVAçãO DE UMA CHAVE DE AUTENTICAçãO; TERMiNAL MóVEL PARA AUTENTICAçãO DE UMA APLICAçãO.<D> Um aspecto da invenção revela um método de autenticação para uma aplicação. O método compreende executar, com uma aplicação de servidor (408), procedimentos de autocarregamento (412) entre a aplicação de servidor (408) e uma função de servidor de autocarregamento (400); derivar (420, 422) uma chave compartilhada com base em, ao menos, uma chave recebida a partir do servidor de função de servidor de autocarregamento (400) durante os procedimentos de autocarregamento (412) e um identificador de função de aplicação de servidor, sendo que o identificador de transação de autocarregamento é recebido a partir do servidor de função de servidor de autocarregamento (400) durante os procedimentode autocarregamento (412); receber uma resposta proveniente da aplicação (406); e autenticar (426) a aplicação através da validação da resposta com a chave compartilhada.

Description

"MÉTODO PARA AUTENTICAR UMA APLICAÇÃO; MÉTODO PARAAUTENTICAR UMA APLICAÇÃO COM UMA APLICAÇÃO DESERVIDOR; MÉTODO PARA DERIVAR UMA CHAVE DEAUTENTICAÇÃO; PROGRAMA DE COMPUTADOR PARAAUTENTICAÇÃO DE UMA APLICAÇÃO; PROGRAMA DECOMPUTADOR PARA DERIVAÇÃO DE UMA CHAVE DEAUTENTICAÇÃO; TERMINAL MÓVEL PARA AUTENTICAÇÃO DE UMAAPLICAÇÃO".
Antecedentes da Invenção:
Campo da invenção:
A presente invenção refere-se à autenticação. Em particular, apresente invenção se refere a métodos, programas de computador e terminais móveisinusitados e aperfeiçoados para autenticar uma aplicação de um cliente.
Descrição da Técnica Relacionada:
O desenvolvimento atual em direção à computação e à formação derede verdadeiramente móvel causou a evolução de diversas tecnologias de acesso, asquais também fornecem aos usuários acesso à Internet quando estão fora de sua rededoméstica. Até o momento, o uso da Internet foi dominado por comunicações depessoa-para-máquina, isto é, serviços de informação. A evolução em direção àschamadas redes sem fio de terceira geração (3G) traz consigo comunicações demultimídia móveis, as quais também irão alterar a maneira com que os serviçosbaseados em IP são utilizados em redes móveis públicas. O Subsistema deMultimídia IP (IMS), conforme especificado pelo Projeto de Parceria de TerceiraGeração (3GPP), integra as comunicações móveis de voz com tecnologias deInternet, permitindo serviços de multimídia baseados em IP sejam utilizados nasredes móveis.
Os novos terminais móveis com capacidade para multimídia (telefonesmultimídia) fornecem uma plataforma de desenvolvimento aberta para Os usuáriospodem, por sua vez, fazer a transferência por download de novosserviços/aplicações para seus terminais móveis e utilizá-los nos mesmos. Porexemplo, a especificação técnica 3GPP TS33.220 revela a Arquitetura Genérica deAutocarregamento (GBA) que faz parte da Arquitetura de Autenticação (GAA). Ummodelo de rede geral da GBA é revelado na Figura 1. O modelo revelado na Figura1 inclui quatro entidades diferentes: Um Equipamento de Usuário (EU) 14, umaFunção de Servidor de Autocarregamento 12, Função de Aplicação de Rede (NAF)16 e um Sistema Doméstico de Assinante (HSS) 10. A Figura 1 revela, ainda, asinterfaces entre as entidades.
A Figura 2 é um diagrama que ilustra o procedimento deautocarregamento na GBA. Quando um UE 200 quer interagir com uma NAF e sabeque o procedimento de autocarregamento é necessário, o mesmo deve desempenhar,em primeiro lugar, uma autenticação de autocarregamento. Quando oautocarregamento é iniciado, o UE 200 envia (21) uma solicitação de http emdireção à BSF 202. A BSF 202 restaura (22) o conjunto completo de ajustes desegurança de usuário da GBA e um Vetor de Autenticação (AV, AV = RANDAUTN XRES CK IK) através do ponto de referência Zh a partir de um HSS 204.Em seguida, a BSF 202 encaminha o RAND e o AUTN para o UE 200 namensagem 401 (23) (sem o CK, IK e XRES). Isso ocorre para exigir que o UE 200autentique a si ρΓφπο. O UE 200 verifica (24) o AUTN para confirmar que odesafio é proveniente de uma rede autorizada. O UE 200 também calcula CK, IK eRES. Isso resultará em chaves de sessão IK e CK na BSF 202 e no UE 200. O UE200 envia (25) outra solicitação de HTTP, que contém a resposta Digest AKA(calculada usando-se RES), para a BSF 202. A BSF 202 autentica (26) o UE 200através da confirmação da resposta Digest AKA e gera (27) uma chave mestre Ksatravés da concatenação de CK e IK. Um valor B-TID também pode ser gerado. OBSF envia (28) uma mensagem de OK 200, que inclui B-TID, para o UE 200 com oobjetivo de indicar o sucesso da autenticação. Além disso, na mensagem de OK200, a BSF 202 deve fornecer a vida útil da chave Ks. A chave Ks é gerada no UE200 através da concatenação de CK e IK. O UE 200 e a BSF 202 podem usar a Kspara derivar a chave Ks NAF. KDF para a GBA é definida em 3GPP TS 33.220,Anexo Β. A NAF Id consistem em um nome DNS completo do identificador desegurança de protocolo de NAF e Ua. A KDF deve ser implantada no equipamentomóvel.
Quando a aplicação no terminal quer autenticar um servidor deaplicação de rede, a mesma obtém um Ks_NAF de segredo compartilhado comNAF através de uma API oferecida por uma aplicação confiável no terminal. Aaplicação confiável utiliza os procedimentos de autocarregamento descritos acimacom o servidor da Função de Servidor de Autocarregamento (BSF) para derivar oKs_NAF de segredo compartilhado com NAF. A NAF adquire o segredocompartilhado para a aplicação do cliente através da comunicação com a BSF.
Um prestador de serviço pode querer impedir que as aplicações docliente sejam desenvolvidas e apropriadas por outros prestadores de serviço einstaladas em um terminal móvel para acessar seu serviço. Para atingir tal objetivo,ele poderia, por exemplo, autenticar uma aplicação no terminal móvel todas as vezesque o mesmo tentasse acessar o serviço. Tal método, portanto, exigiria uma
associação de segurança de longo prazo entre o prestador de serviço e cada cópiadistribuída da aplicação. Manter tais associações de segurança de longo prazo podeaumentar, de modo significante, os custos do prestador de serviço.
Já que a chave NAF específica, isto é, Ks NAF, é, de fato,específica da NAF (isto é, serviço), o objetivo pode ser alcançado pelo terminal
móvel através do acesso restrito a Ks NAF para somente aquelas aplicação que sãoconsideradas confiá veis pelo prestador de serviço da NAF. Essa restrição épossível se o hardware e o software da plataforma do terminal móvel possuem aspropriedades de segurança a seguir: (1) processos podem auto-autenticar e (2) umprocesso não pode acessar os dados de outro processo. O terminal móvé, portanto,precisa ser configurado; o mesmo precisa saber quais aplicações têm acessopermitido a quais credenciais específicas da NAF (isto é, chaves específicas NAF).Existem, ao menos, duas opções para configurar permissões de acesso paracredenciais da GBA (isto é, um conjunto de chaves específicas NAF) no terminalmóvel.
Primeiramente, o terminal móvel pode adquirir os dados deconfiguração com permissões para todas as aplicações NAF a partir de uma fonteexterna. Nesse caso, exige-se que os dados de configuração tenham origem em umafonte confiável e sejam inteiramente protegidos. As permissões para acessar ascredenciais da GBA podem ser entregues a ME em conjunto com outros dados deconfiguração usando-se uma estrutura de gerenciamento de dispositivo (porexemplo, procedimentos de Gerenciamento de Dispositivo OMA), a qual implantaaquelas exigências. A segurança dos dados de configuração pode ser baseada emcriptografia 1) simétrica ou 2) assimétrica. Tal opção também pode ser utilizadasem uma estrutura de gerenciamento de dispositivo externo. Por exemplo, o terminalmóvel pode ser configurado antes que seja entregue para o usuário final, porexemplo, na fábrica pelo fabricante, ou em uma loja pelo vendedor do terminalmóvel. Após o terminal móvel ter alcançado seu usuário final, permissões podem sermodificadas manualmente: Por exemplo, o terminal móvel questionará seu próprbproprietá rio para configurar cada nova permissão. Portanto, a configuração manualdo terminal móvel pode prejudicar a prática do uso do serviço, de modo que sejamelhor configurar as permissões, de modo automático, da forma mais proveitosapossível. Ademais, uma desvantagem potencial dessa opção é que os prestadores deserviço devem confiar na fonte dos dados de configuração, pois a mesma define aspermissões para todas as aplicação NAF. Em segundo lugar, os direitos de acessopara cada aplicação podem ser configurados no terminal um a um com base nacomunicação com a fonte externa.
Outro método para configurar os direitos de acesso, de modoindividual, para cada aplicação é usar a Infra-estrutura de Chave Pública (PKI) e asaplicações assinadas. De modo típico, a assinatura da aplicação assinada pode serverificada usando-se um certificado digital especifico para aplicação. Pode ser que osistema PKI usado para certificar e verificar as aplicações inclua uma possibilidadede definir o serviço, ou serviços, que essa aplicação tem permissão para acessar(isto é, a quais credenciais específicos NAF a aplicação tem direito a acesso). Talinformação pode ser codificada no próprio certificado de aplicação, ou pode ser umaparte dos metadados da aplicação. De maneira típica, tal informação consistiria nosidentificadores que identificam cada credencial específica NAF de modo único.
A segurança da configuração com chaves simétricas GBA é baseadano fato de que a NAF e o terminal móvel compartilham a chave Ks NAF. Doismétodos principais para implantar essa alternativa são: (1) Se uma aplicaçãoassinada pela Ks_NAF, então, pode-se confiar na mesma para adquirir acesso ainstâncias futuras daquelas credenciais de NAF e (2) se uma aplicação pode provaruma vez para o terminal móvel que reconhece Ks_NAF, então, pode-se confiar namesma para adquiri acesso a instâncias futuras daquelas credenciais de N AF.
Quando as aplicações do cliente estão instaladas em um terminalmóvel, é necessário estabilizar uma confiança entre tal aplicação e um servidorGAA_ME (isto é, a aplicação confiável que desempenha o procedimento deautocarregamento com a BSF) instalado no terminal móvel se tal aplicação queradquirir as chaves específicas NAF. Portanto, existe uma maneira de assinar aaplicação usando-se um certificado digital específico NAF e usar a assinatura paraestabilizar a confiança de aplicação no terminal. Por exemplo, essa maneira estásendo adotada nos terminais Symbrian. Portanto, o servidor GAAJYEE não teriaconhecimento de quais, de todas as aplicações instaladas (confiáve is), seriamsomente dotadas de chaves específicas NAF.
O problema supramencionado pode ser resolvido através do acréscimode itens a um certificado que informa que essa aplicação assinada pela aplicaçãodeveria ser dotada de uma capacidade de cliente GAA (isto é, credencias NAFpodem ser adquiridas a partir do servidor GAA-ME para uma aplicação de terminalmóvel.Tal solução precisa de mecanismos entre o servidor GAA ME e a plataforma(com segurança de plataforma) para coordenar a confiança. Quando as aplicações docliente estão localizadas no dispositivo mais prócimo, como um laptop (caso de usode terminal seccionado), o qual quer utilizar o servidor GAA ME do telefone, talsolução se torna difícil de implantar.
Com base no que foi dito acima, existem diversos problemas nassoluções da técnica anterior que precisam resolvidos. Por exemplo, quais aplicaçõesem um terminal móvel possuem permissão para acesso às credencias NAF e comoconfigurá-las. Ademais, outro problema é como autenticar uma aplicação a umservidor GAA_ME em um terminal móvel.
SUMÁRIO DA INVENÇÃO:
De acordo com um aspecto da invenção, é fornecido um método deautenticação de uma aplicação. O método compreende executar, com uma aplicaçãode servidor confiável, procedimentos de autocarregamento entre a aplicação deservidor confiá vel e uma função de servidor de autocarregamento; derivar umachave compartilhada com base em, ao menos, uma chave ajustada com o servidor defunção de servidor de autocarregamento durante os procedimentos deautocarregamento e um identificador de função de aplicação de rede; fornecer umaaplicação com um identificador de transação de autocarregamento, sendo que oidentificador de transação de autocarregamento é recebido a partir do servidor defunção de servidor de autocarregamento durante os procedimentos deautocarregamento; receber uma resposta proveniente da aplicação; e autenticar aaplicação através da validação da resposta com a chave compartilhada.
De acordo com um aspecto da invenção, é fornecido um método deautenticação de uma aplicação com uma aplicação de servidor confiável. O métodocompreende receber, com uma aplicação, a partir de uma aplicação de servidorconfiável, ao menos um identificador de transação de autocarregamento; abrir umenlace de comunicação com um servidor de função de aplicação de rede; fornecerao servidor de função de aplicação de rede ao menos o identificador de transação deautocarregamento através do enlace de comunicação; receber, em resposta aofornecimento do identificador de transação de autocarregamento, ao menos, umaresposta proveniente do servidor de função de aplicação de rede; e autenticar aaplicação através do fornecimento à aplicação de servidor confiável de, ao menos,a resposta recebida a partir do servidor de função de aplicação de rede. De acordocom um aspecto da invenção, é fornecido um método de derivação de uma chave deautenticação. O método compreende abrir um enlace de comunicação com umaaplicação; receber, a partir da aplicação, ao menos, um identificador de transaçãode autocarregamento através do enlace de comunicação; enviar uma solicitação paraum servidor de função de servidor de autocarregamento para receber uma chavecompartilhada, sendo que a solicitação compreende, ao menos, um identificador detransação de autocarregamento; receber, a partir do identificador de transação deautocarregamento, a chave compartilhada em resposta à solicitação; derivar umaresposta usando-se, ao menos, a chave compartilhada; e enviar, ao menos, aresposta para a aplicação.
Cada um dos aspectos supramencionados pode ser implantado comoum programa de computador que pode ser incorporado em um meio de comunicaçãolegível por computador. De acordo com um aspecto da invenção, é fornecido umterminal móvel para autenticar uma aplicação. O terminal móvel compreende umaaplicação de servidor confiável configurada para executar procedimentos deautocarregamento entre a aplicação de servidor confiável e uma função de servidorde autocarregamento; derivar uma chave compartilhada com base em, ao menos, ummaterial de chave recebido a partir do servidor de função de servidor deautocarregamento durante os procedimentos de autocarregamento e um identificadorde função de aplicação de rede; fornecer uma aplicação com um identificador detransação de autocarregamento, sendo que o identificador de transação deautocarregamento é recebido a partir do servidor de função de servidor deautocarregamento durante os procedimentos de autocarregamento; receber umaresposta proveniente da aplicação; e autenticar a aplicação através da validação daresposta com a chave compartilhada.
A presente invenção possui diversas vantagens sobre as soluções datécnica anterior. Nenhuma aplicação de vírus ou, até mesmo, quaisquer aplicaçõesde terceiros podem solicitar credenciais GAA a partir do servidor GAA MEinstalado no equipamento móvel, a menos que esses possam autenticar algumas NAFe derivar um segredo compartilhado (isto é, KS_NAF_install) a ser usado pararegistro no servidor GAA_ME.
Ademais, a invenção fornece uma solução para derivar um segredocompartilhado entre o servidor GAA_ME e uma aplicação em um terminal próximo.
A solução revelado na invenção pode ser usada para autenticar a aplicação próximadirigida ao servidor GAA_ME. Portanto, isso pode exigir que também exista algumtipo de computação confiável (segurança de plat aforma) nos dispositivos próximos.
Ademais, a invenção fornece para os operadores uma opção atrativade distribuir suas aplicações. Os operadores que já possuem autenticação com baseem nome de usuário-senha (ou algum outro mecanismo de autenticação), a soluçãorevelada na invenção facilita o desenvolvimento até o uso de credencial com baseem GAA.
Ademais, a invenção pode ser usada, ainda, para que os doisdispositivos gerem uma chave compartilhada por grupo que, então, é usada parauma comunicação em grupo e pode ser distribuída, de modo adicional, para outrosusuário s, por exemplo, para ser usada com o objetivo de ajustar túneis segurosentre eles e trocar certificados, ajustar Redes Virtuais Particulares (VPN) entre elesou somente ajustar a Segurança da Camada de Transporte (TLS) entre eles.
Em geral, a solução revelado na invenção pode ser usada para ainstalação de aplicação específicas de operador e para o estabelecimento deconfiança entre um componente existente e um componente recentemente instalado.
Breve Descrição dos Desenhos:
Os desenhos em anexo, os quais são incluídos para fornecer umacompreensão adicional da invenção e constituir uma parte dessa especificação,ilustram modalidades da invenção e, em conjunto com a descrição, auxiliam aexplicar os princípios da invenção. Nos desenhos:
A Figura 1 é um diagrama em bloco que ilustra uma arquitetura datécnica anterior de Arquitetura Genérica de Autocarregamento (GBA).
A Figura 2 é um diagrama de sinalização que ilustra umprocedimento de autocarregamento da técnica anterior,
A Figura 3 é um diagrama em bloco que ilustra diversos elementos deacordo com uma modalidade da invenção, e
A Figura 4 é um diagrama de sinalização que ilustra uma modalidadepara autenticar uma aplicação dirigida para uma aplicação de servidor emequipamento móvel de acordo com uma modalidade da presente invenção. A Figura5 é um diagrama de sinalização que ilustra outra modalidade para autenticar umaaplicação dirigida para uma aplicação de servidor em equipamento móvel de acordocom uma modalidade da presente invenção.
Descrição Detalhada das Modalidades Preferidas:
Agora será feita referência detalhada às modalidade da presenteinvenção, exemplos das mesmas são ilustrados nos desenhos em anexo.
A Figura 3 revela um diagrama em bloco que ilustra diversoselementos que fazem parte da solução revelada na presente invenção. A Figura 3revela cinco entidades diferentes: Equipamento Móvel (ME) 300, uma Função deServidor de Autocarregamento (BSF), uma Função de Aplicação de Rede (NAF)306, um Sistema Doméstico de Assinante (HSS) 304 e um computador 308. Odiagrama em bloco da Figura 3 também leva em consideração uma situação determinal seccionado. Em uma situação de terminal seccionado, uma aplicação local320 reside, por exemplo, em um computador 308. A aplicação local é conectada aum servidor GAA_ME do equipamento móvel 314 através de um módulo GAA 318 ede um módulo próximo 312. A conexão atual entre o equipamento móvel 314 e ocomputador 308 é realizada, por exemplo, através de um enlace próximo, porexemplo, Bluetooth. O APP_ME 310 é uma aplicação (de cliente) que é instalada noequipamento móvel 300. Em outras palavras, a aplicação pode ser instalada nopróprio equipamento móvelou em um computador 308 que possui uma conexão localcom o equipamento móvel 300.
A arquitetura GAA fornece uma maneira de gerar um segredocompartilhado entre o equipamento móvel 300 e a NAF 306. O segredo é utilizadoquando o equipamento móvel 300 quer ser autenticado pela NAF 306. A aplicaçãono equipamento mó/el 300 precisa de credenciais USIM (ou ISIM ou SIM) paraexecutar o autocarregamento da GAA para gerar chaves NAF específicas. Acapacidade de adquirir credenciais USIM a partir de USIM não deve estardisponível, de preferência, para todas as aplicação no equipamento móvel 300devido a uma ameaça à segurança. Portanto, um servidor GAA_ME confiável 314pode ser instalado em um equipamento móvel 300 durante a produção ouposteriormente, sendo que o servidor possui a capacidade de adquirir as credenciaisUSIM a partir de USIM e, sendo assim, possui a capacidade de realizar oautocarregamento para gerar credenciais NAF. Portanto, uma aplicação de umcliente (APP ME) usaria os serviços do servidor GAA_ME 314 para adquirir ascredenciais NAF específicas. Tal aplicação de cliente GAA ME é preparada eempacotada pelo fornecedor NAF. Essa aplicação é assinada usando-se umaassinatura digital que a plataforma (symbian, xp, Linux, Java e etc.) compreende.Após a instalação, tal aplicação é registrada pelo servidor GAA_ME 314 durantesua primeira execução.
O equipamento móvel 300 e a função de aplicação de rede 306 podeincluir uma memória ou memórias (não reveladas na Figura 3) que também podemincluir um programa de computador (ou parte do mesmo), o qual, quando executadoem uma unidade de processamento de dados, desempenha, ao menos, algumas dasetapas da invenção. A unidade de processamento de dados também pode incluir umamemória ou uma memóriapode ser associada à quela, a qual pode incluir o programade computador (ou parte do mesmo) que, quando executado na unidade deprocessamento de dados, desempenha, ao menos, algumas das etapas da invenção.A Figura 4 é um diagrama de sinalização que ilustra uma modalidade para registrare autenticar uma aplicação por uma aplicação de servidor em equipamento móvel deacordo com uma modalidade da presente invenção. A Figura 4 revela três entidadesdiferentes: uma Função de Servidor de Autocarregamento (BSF), um servidor deFunção de Aplicação de Rede (NAF) 404 e um Equipamento Móvel (ME) 400 . Umequipamento móvel 404 inclui uma aplicação de cliente APP ME 406 e umaaplicação de servidor GAA ME 408 já reveladas na Figura 3. Em outramodalidade, uma aplicação de cliente APP_ME pode residir no exterior doequipamento móvel404, ou seja, por exemplo, em um dispositivo externo conectadoao equipamento móvel 404. Na modalidade da Figura 4, a APP ME 406 envia umasolicitação de registro (410) para o servidor GAA_ME 408. A solicitação indicapara o servidor GAA ME 408 que a APP ME quer se auto-autenticar para oservidor GAA ME 408. A solicitação pode conter, ainda, um identificador NAF e/ou um identificador de instância de aplicação. O fornecedor de aplicação pode terestabelecido o códgo rígido da aplicação ou, de alguma forma, ter configurado ofuncionamento do identificador NAF e da instân cia de aplicação.
O servidor 408 executa (412 ) um protocolo de autocarregamento com a BSF 400. O protocolo de autocarregamento é revelado em maiores detalhes, porexemplo, na especificação técnica 3GPP de referência 3GPP TS 33.220 V7.2.0(2005-12). Durante o autocarregamento, o servidor GAA_ME 408 recebe, aomenos, um BTID (Identificador de Transação de Autocarregamento) e a vida útil deuma chave proveniente da BSF 400 e passa (414), ao menos, o BTID de volta para o APP_ME 406. Já que o servidor GAA ME 408 é capaz de derivar materiais Ks ereconhecer o identificador NAF, o mesmo deriva, ainda, a chave Ks NAF, a qual éum segredo compartilhado entre o servidor GAA_ME 408 e a NAF 402. O servidorGAAME 408 derivará, em seguida, (422) uma chave de instalaçãoKSNAFinstall usando-se KS_NAF e, de modo opcional, o identificador de instância de aplicação mencionado anteriormente que usa qualquer métodoapropriado.
Após receber a BTID a partir do servidor GAA_ME 408, o APP ME406 abre um enlace de comunicação com a NAF 402. Pode-se manter o enlace decomunicação seguro para que a ação humana seja suavizada usando-se, por exemplo, a Camada de Soquetes Segura (SSL) ou qualquer outro método adequado.
Após isso, o APP_ME 406 se auto-autentica (416) para a NAF 402usando-se um procedimento de autenticação adequado Existem diversos métodos deautenticação aplicávei s na técnica anterior que podem ser utilizados. Oprocedimento de autenticação pode incluir os listados a seguir:
Senha única com código rígido estabelecido para a aplicação. Nesse
caso, é preferível que o códig) da aplicação seja ofuscado de modo que se tornemuito difícil restaurar a senha simplesmente através do exame do código.
O nome de usuári o e a senha adquiridos fora da banda (como lançarou visitar uma loja). - Registro para a NAF online para adquirir as credenciais.
Ademais, o método de autenticação e a segurança do canal podem serespecíficos da NAF. A chave compartilhada TLS pode, ainda, ser usada no caso desegredos compartilhados. Ademais, os métodos de autenticação HTTP-DIGEST sãobastante utilizados para autenticação.
Uma vez que o APP_ME 406 foi autenticado para a NAF 402, a NAF402 irá buscar (418) a chave específica KS NAF da NAF a partir da BSF 400usando-se a BTID e irá derivar (420) KS_NAF_install (similar à etapa 422). Emseguida, a mesma transferirá (424) o KS_NAF_install para o APP ME 406. Taltransferência deve ser, de preferência, confidencial.
Agora, o APP ME 406 pode se auto-autenticar (426) para oGAA_ME_Server 408 usando-se KS_NAF_install como um segredo compartilhado.Se a autenticação é bem sucedida, o servidor GAA_ME 408 pode adicionar (428) aaplicação na sua lista de aplicações confíávei s dependendo de sua configuraçãolocal. Portanto, a etapa 428 pode ser, ainda, uma etapa opcional. Se a aplicaçãoestá em uma lista de aplicações confiáveis, quando, no futuro, o APP_ME 406solicita chaves NAF, o servidor GAA_ME 408 autocarrega e fornece as chavesNAF sem qualquer autorização adicional proveniente da NAF 402.
Na modalidade revelada na Figura 4, as duas caixas de derivação dechave de instalação (420, 422) são posicionadas no mesmo nível. Portanto, cadauma pode ser movida de modo ascendente ou descendente dependendo dasolicitação. A derivação da chave de instalação pode ser realizada usando-se, porexemplo, transformação de chaves, usando-se KS_(ext)_NAF e o identificador deinstância de aplicação ou usando-se somente a própria KS_(ext)_NAF comoKS_NAF_nstall.
O segredo compartilhado utilizado para autenticar, de modo inicial, oAPP_ME 406 e a NAF 402 também pode ser uma senha única. A senha pode serdeletada na NAF 402 uma vez que o terminal estabelece uma confiança com oservidor GAA_ME do cliente 408. O segredo compartilhado também pode serderivado com base em algumas características do terminal móvel. Ademais, oprotocolo de autenticação entre o APP_ME 406 e a própria NAF 402 pode serquaisquer dos protocolos de autenticação bem conhecidos. Uma vez que aautenticação foi executada, o método para garantir a segurança da comunicaçãoentre o AP ME 406 e a NAF 402 pode ser um dos métodos bem conhecidos. Casoum segredo compartilhado (por exemplo, nome de usuár io e senha) seja usado, oprotocolo TLS de chave compartilhada é uma alternativa.
Em uma modalidade da invenção, quando o servidor GAA_ME 408autenticou, de modo bem sucedido, o APP_ME 406 usando uma determinadaidentidade de NAF, o servidor GAA_ME 408 pode conceder o acesso APP_MEsomente para as instâncias futuras de chave Ks_NAF que pertencem a mesmaidentidade de NAF e outras chaves NAF específicas não seriam acessíveis. Emoutra modalidade da invenção, um acesso irrestrito é concedido para o APP ME406, isto é, o mesmo pode adquirir chaves KS_NAF de qualquer NAF.
Ademais, em uma modalidade da invenção, durante o procedimento,múltiplas chaves Ks_NAF podem ser usadas para conceder acesso a diversas chaves,isto é, a NAF 402 busca chaves múltiplas Ks NAF a partir da BSF 400 (sobautorização) e a NAF 402 deriva múltiplas chaves Ks_NAF_install e as envia para oAPP_ME 406. O APP_ME 406 pode, em seguida, registrá-las com o servidor
GAA-ME 408. Desta maneira, o APP_ME 406 obteria o acesso a mais de umachave NAF específica. A Figura 5 é um diagrama de sinalização que ilustra umamodalidade para registrar e autorizar uma aplicação para uma aplicação de servidorem equipamento móvel de acordo com uma modalidade da presente invenção. AFigura 5 revela três entidades diferentes: uma Função de Servidor deAutocarregamento (BSF) 500, um servidor de Função de Aplicação de Rede (NAF)502 e um Equipamento Móvel (ME) 504 . Um equipamento móvel 504 inclui umaaplicação de cliente APP ME 506 e uma aplicação de servidor GAA ME 508 járeveladas na Figura 3. Em outra modalidade, uma aplicação de cliente APP MEpode residir no exterior do equipamento móvel504, ou seja, por exemplo, em umdispositivo externo conectado ao equipamento móvel 504.
Na modalidade da Figura 5, a APP_ME 506 envia uma solicitação deregistro (510) para o servidor GAA_ME 508. A solicitação indica para o servidorGAA ME 508 que a APP ME quer se auto-autorizar para o servidor GAAJYEE508. A solicitação pode conter, ainda, um identificador NAF e /ou um identificadorde instâ ncia de aplicação. O fornecedor de aplicação pode ter estabelecido o códgorígido da aplicação ou, de alguma forma, ter configurado o funcionamento doidentificador NAF e da instância de aplicação.
O servidor GAA_ME 508 executa (512) um protocolo deautocarregamento com a BSF 500. O protocolo de autocarregamento é revelado emmaiores detalhes, por exemplo, na especificação técnica 3GPP de referência 3GPPTS 33.220 V7.2.0 (2005-12). Durante o autocarregamento, o servidor GAA ME508 recebe, ao menos, um BTID (Identificador de Transação de Autocarregamento)e a vida útil de uma chave proveniente da BSF 500 . Já que o servidor GAA ME508 é capaz de derivar a chave Ks e reconhecer o identificador NAF, o mesmoderiva, ainda, a chave Ks NAF (514), a qual é um segredo compartilhado entre oservidor GAA ME 508 e a NAF 502. O servidor GAA ME 508 também irá gerar(514) um desafio remoto para o APP_ME (506). Após isso, o servidor GAA_ME508 passa (514), ao menos, o BTID e o desafio para o APP_ME 506.
Após receber a BTID e o desafio a partir do servidor GAA_ME 508,o APP ME 506 abre um enlace de comunicação com a NAF 502 e passa (518) oBTID e o desafio para a NAF 502. Pode-se manter o enlace de comunicação seguropara que uma possível ação humana seja suavizada.
A NAF 502 busca (520) a chave NAF específica KS NAF a partir daBSF 400 usando-se o BTID e deriva (522) uma resposta para o desafio através douso de Ks NAF. A resposta pode ser calculada, por exemplo, através do uso de umafunção de sinal numérico unidirecional ou um código de autenticação de mensagemde sinal numérico dotado de chaves (HMAC) em que os parâmetro s de entradaincluem, ao menos, a Ks NAF e o desafio. A NAF 502 pode, ainda, assinar dadoscom a Ks NAF. Os dados podem incluir um ou mais sinais numéricos de aplicaçõesque a NAF 502 autoriza para ter acesso às chaves NAF específicas (Ks_NAFs).Um desses sinais numéricos pode ser o sinal numérico da aplicação APP ME (506)que foi instalado no ME (504) anteriormente. Deve-se compreender que o sinalnumérico da aplicação é meramente uma possibilidade. Quaisquer outrasinformações, ou seja, uma caracterização da aplicação, podem ser usadas no lugarde um sinal numérico. Por exemplo, se a aplicação reside em outro dispositivo queé conectado ao terminal do usuário através de uma rede local, como WLAN ouBluetooth, então, a caracterização da aplicação pode ser o endereço da rede dodispositivo. Ademais, uma caracterização possível de uma aplicação em umdispositivo externo pode ser o número de série daquele dispositivo. Ademais, umacaracterização possível poderia ser uma chave pública de assinatura de conteúdo.Ademais, em uma modalidade da invenção, a solicitação (518) da NAF 502 podeincluir alguma caracterização da plataforma (por exemplo, "dispositivo Nokia queexecuta a Série 60 v3.1"), a qual, em seguida, ajuda a NAF 502 a enviar a corretacaracterização aceitável da aplicação de volta. Em seguida, a NAF 502 (524)transfere a resposta e os dados possivelmente assinados para o APP ME 506.
Os dados assinados referem-se, por exemplo, a alguns dados extrasque a NAF 502 adiciona à mensagem que é assinada usando-se a Ks_NAF. Destaforma, o servidor GAA ME pode verificar a assinatura desses dados extra ecertificar-se de que é proveniente de uma fonte confiável, a qual reconhece aKs NAF. Agora, o APP_ME 506 pode se auto-autorizar (526) para oGAA ME Server 508 através do uso da resposta e dos dados assinados. Se aautorização for bem sucedida, isto é, a resposta e a assinatura dos dados assinadosestão corretos, o servidor GAA_ME 508 continua com o procedimento deautorização e concede a Ks_NAF ao APP_ME 506. De modo adicional, o servidorGAA ME 508 também pode calcular o sinal numérico do APP_ME 506 e verificarse esse sinal numérico está nos dados assinados. Se ao menos uma das verificaçõesfor bem sucedida, o servidor GAA_ME 508 pode adicionar (528) a aplicação na sualista de aplicações confiáveis dependendo de sua configuração local. Se a aplicaçãoestá em uma lista de aplicações confiáveis, quando, no futuro, o APP_ME 506solicita chaves NAF, o servidor GAA_ME 508 autocarrega e fornece as chavesNAF sem qualquer autorização adicional proveniente da NAF .
A adição possível da aplicação na sua lista de confiáveis tornapossível ter "concessões únicas" e "concessões integrais". No primeiro caso, oAPP ME teria sempre que adquirir a autorização extra (dados assinados ou deresposta ou ambos) para cada solicitação por Ks NAF ou, no segundo caso, oAPP ME adquiriria uma concessão permanente e não teria que adquirir umaautorização extra nas solicitações futuras por Ks_NAF. Enfim, se as verificaçõesfeitas acima foram bem sucedidas, o servidor GAA_ME 508 (530) indica para o
APP_ME que o procedimento foi bem sucedido e inclui, possivelmente, a Ks NAF
a essa mensagem.
Em uma modalidade da invenção, quando o servidor GAA ME 508autenticou, de modo bem sucedido, o APP_ME 506, o servidor GAA_ME 408 podeconceder o acesso APP ME somente para as chaves NAF específicas Ks_NAF queforam usadas durante o procedimento e outras chaves NAF específicas não seriamacessíveis. De modo especial, esse pode ser o caso se os dados assinados não foramenviados a partir da NAF 502 para o servidor GAA_ME 508 através do APP_ME506. Em outra modalidade da invenção, um acesso irrestrito é concedido para oAPP_ME 506, isto é, o mesmo pode adquirir todas as chaves KS NAF possíveis.
Em outra modalidade da invenção, a KS_(ext)_NAF é usada comouma chave de grupo para garantir a segurança de uma comunicação em grupo epode ser compartilhada com outros dispositivo que podem não ter qualquer forma degeração de chave GBA ou nenhuma capacidade de solicitação. Essa modalidadepode ser usada para garantir a segurança de um enlace de comunicação, porexemplo, em um ambiente doméstico com muitos dispositivo de baixa capacidade,ou pode ser usada para ajustar uma VPN pessoal (rede particular virtual).
Ademais, em uma modalidade da invenção, a NAF ID pode serenviada a partir do APP_ME 506 para o servidor GAA_ME 508 na etapa 510,conforme descrito acima, ou na etapa 526.
Ademais, em uma modalidade da invenção, durante o procedimento,múltiplas chaves Ks_NAF podem ser usadas para conceder acesso a diversas chaves,isto é, a NAF 502 busca chaves múltiplas Ks NAF a partir da BSF 500 (sobautorização) e a NAF 502 calcula múltiplas respostas para o desafio usando essaschaves Ks NAF e também assina, de modo opcional, os dados usando todas ou umsubconjunto das chaves e as envia para o APP_ME 506. O APP_ME 506 pode, emseguida, registrá-las com o servidor GAA-ME 508. Desta maneira, o APP_ME 506obteria o acesso a mais de uma chave NAF específica.
Ademais, esse método pode ser aplicado em muitos outros casos emque o equipamento de terminal é configurado para confiar em um prestador deserviço (por exemplo, um fabricante de equipamento ou através de um operador derede) e, então, o equipamento e o prestador de serviço possuem, ou concordam, emum chave compartilhada. Descrevemos em detalhes que, se uma nova aplicaçãopode provar para o terminal que possui a confiança de um determinado prestador deserviço, então, a mesma pode ser marcada como "confiável" e pode ser instaladano terminal do usuá rio. Tal evidência é baseada no conhecimento da chavecompartilhada entre o terminal e o prestador de serviço. Por exemplo, ao invés daaplicação ser instalada no terminal, poderia haver um dispositivo periférico ou outroterminal em uma rede próxima (por exemplo, rede Bluetooth ou WLAN) que iriaquerer conectar-se ao terminal do usuár io. O procedimento de estabelecimento deconfiança é o mesmo também nesses casos.
3 GPP GBA é uma das maneiras de derivar a chave compartilhada eestabelecer a confiança entre o terminal e o prestador de serviço. Outras maneirastambém podem ser consideradas. Por exemplo, com uma infra-estrutura de chavepública (PKI) em funcionamento, ambas as partes trocariam certificados de suaschaves públicas, verificariam mutuamente suas assinaturas e procederiam paraderivar uma chave compartilhada. Como outro exemplo, uma chave compartilhada alongo prazo pode ser pré-instalada no terminal pelo operador da rede ou pelofabricante do terminal.
Fica evidente para uma pessoa versada na técnica que, com o avançoda tecnologia, a idéia básica da invenção pode ser implantada de diversos modos. Ainvenção e suas modalidade não são, portanto, limitadas aos exemplos descritosacima, ao invés disso, essas podem variar dentro do escopo das reivindicações.

Claims (52)

1. Método para autenticar uma aplicação, sendo que o método éCARACTERIZADO pelo fato de que compreende: executar, com uma aplicação deservidor, procedimentos de autocarregamento entre a aplicação de servidor e umafunção de servidor de autocarregamento; derivar uma chave compartilhada com baseem, ao menos, uma chave recebida a partir do servidor de função de servidor deautocarregamento durante os procedimentos de autocarregamento e um identificador defunção de aplicação de rede; fornecer para a aplicação um identificador de transaçãode autocarregamento, sendo que o identificador de transação de autocarregamento érecebido a partir do servidor de função de servidor de autocarregamento durante osprocedimentos de autocarregamento; receber uma resposta proveniente da aplicação; eautenticar a aplicação através da validação da resposta com a chave compartilhada.
2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelofato de que a autenticação da aplicação compreende: Autenticar a aplicação através dacomparação da chave compartilhada com a resposta.
3. Método, de acordo com a reivindicação 1, que compreendeadicionalmente: Gerar um desafio; fornecer para a aplicação um desafio; eCARACTERIZADO pelo fato de que a etapa de autenticação compreende autenticara aplicação através da validação da resposta com o desafio e a chave compartilhada.
4. Método, de acordo com a reivindicação 3, que compreendeadicionalmente: Receber dados assinados com a resposta; e CARACTERIZADO pelofato de que a etapa de autenticação compreende, de modo adicional, verificar os dadosassinados com a chave compartilhada.
5. Método, de acordo com a reivindicação 1, CARACTERIZADO pelofato de que compreende adicionalmente: receber uma solicitação de registro a partir daaplicação, sendo que a solicitação compreende, ao menos, um identificador de funçãode aplicação de rede e um identificador de instância de aplicação antes de fornecerpara a aplicação um identificador de transação de autocarregamento.
6. Método, de acordo com a reivindicação 1, CARACTERIZADO pelofato de que compreende adicionalmente: receber uma solicitação de registro a partir daaplicação, antes de fornecer para a aplicação um identificador de transação deautocar r egamento.
7. Método, de acordo com a reivindicação 6, CARACTERIZADO pelofato de que a solicitação de registro compreende um identificador de instância deaplicação.
8. Método, de acordo com as reivindicações 5 a 7, CARACTERIZADOpelo fato de que a derivação da chave compartilhada compreende: Derivar a chavecompartilhada com base na chave recebida a partir do servidor de função servidor deautocarregamento durante os procedimento de autocarregamento, o identificador defunção de aplicação de rede e o identificador de instância de aplicação.
9. Método, de acordo com a reivindicação 1, CARACTERIZADO pelofato de que compreende adicionalmente: marcar a aplicação como confiável se aautenticação for bem sucedida.
10. Método, de acordo com a reivindicação 9, CARACTERIZADOpelo fato de que compreende adicionalmente: fornecer para a aplicação uma chavecompartilhada.
11. Método, de acordo com a reivindicação 9, CARACTERIZADOpelo fato de que compreende adicionalmente: receber a partir da aplicação umasolicitação de uma chave de função de aplicação de rede; e enviar para a aplicação achave de função de aplicação de rede em resposta à solicitação.
12. Método para autenticar uma aplicação com uma aplicação deservidor, sendo que o método é CARACTERIZADO pelo fato de que compreende:receber, com a aplicação, a partir de uma aplicação de servidor confiá vel, ao menosum identificador de transação de autocarregamento; abrir um enlace de comunicaçãocom um servidor de função de aplicação de rede; fornecer ao servidor de função deaplicação de rede, ao menos, o identificador de transação de autocarregamento atravésdo enlace de comunicação; receber, em resposta ao fornecimento do identificador detransação de autocarregamento, ao menos, uma resposta proveniente do servidor defunção de aplicação de rede; e autenticar a aplicação através do fornecimento àaplicação de servidor confiável com, ao menos, a resposta recebida a partir doservidor de função de ap licação de rede.
13. Método, de acordo com a reivindicação 12, CARACTERIZADOpelo fato de que o recebimento proveniente da aplicação de servidor compreendereceber o identificador de transação de autocarregamento e um desafio; e ofornecimento para um servidor de função de aplicação de rede que compreende ofornecimento ao servidor de função de aplicação de rede o identificador de transaçãode autocarregamento e o desafio através do enlace de comunicação.
14. Método, de acordo com a reivindicação 13, CARACTERIZADOpelo fato de que o recebimento proveniente da função de aplicação de rede compreendereceber a resposta e os dados assinados provenientes da função de aplicação de rede; ea autenticação da aplicação compreende fornecer à aplicação do servidor a resposta eos dados assinados recebidos a partir do servidor de função de aplicação de rede.
15. Método, de acordo com a reivindicação 12, CARACTERIZADOpelo fato de que compreende adicionalmente: receber uma chave compartilhadaproveniente da aplicação de servidor após uma autenticação bem sucedida.
16. Método, de acordo com a reivindicação 12, CARACTERIZADOpelo fato de que compreende adicionalmente: após a autenticação, enviar para aaplicação de servidor uma solicitação de uma chave de função de aplicação de rede; ereceber a chave de função de aplicação de rede a partir da aplicação de servidor emresposta à solici tação.
17. Método para derivar uma chave de autenticação, sendo que ométodo é CARACTERIZADO pelo fato de que compreende: abrir um enlace decomunicação com uma aplicação; receber, a partir da aplicação, ao menos, umidentificador de transação de autocarregamento através do enlace de comunicação;enviar uma solicitação para um servidor de função de servidor de autocarregamentopara receber uma chave compartilhada, sendo que a solicitação compreende, ao menos,um identificador de transação de autocarregamento; receber, a partir do identificadorde transação de autocarregamento, a chave compartilhada em resposta à solicitação;derivar uma resposta usando-se, ao menos, a chave compartilhada; e enviar, ao menos,a resposta para a aplicação.
18. Método, de acordo com a reivindicação 17, CARACTERIZADOpelo fato de que o recebimento, a partir da aplicação, compreende receber oidentificador de transação de autocarregamento e um desafio através do enlace decomunicação; e a derivação da resposta compreende derivar a resposta através do uso,ao menos, da chave compartilhada e do desafio.
19. Método, de acordo com a reivindicação 17 ou 18,CARACTERIZADO pelo fato de que o envio de, ao menos, uma resposta compreendeenviar a resposta e os dados assinados com a chave compartilhada para a aplicação.
20. Programa de computador para autenticação de uma aplicação, sendoque o programa de computador é CARACTERIZADO pelo fato de que compreendeum código adaptado para realizar as etapas seguintes quando executado em umdispositivo de processamento de dados: executar procedimentos de autocarregamentocom uma função de servidor de autocarregamento; derivar uma chave compartilhadacom base em, ao menos, uma chave recebida a partir do servidor de função de servidorde autocarregamento durante os procedimentos de autocarregamento e um identificadorde função de aplicação de rede; fornecer para a aplicação um identificador detransação de autocarregamento, sendo que o identificador de transação deautocarregamento é recebido a partir do servidor de função de servidor deautocarregamento durante os procedimentos de autocarregamento; receber uma respostaproveniente da aplicação; e autenticar a aplicação através da validação da resposta coma chave compartilhada.
21. Programa de computador, de acordo com a reivindicação 20,CARACTERIZADO pelo fato de que a autenticação da aplicação compreende:Autenticar a aplicação através da comparação da chave compartilhada com a resposta.
22. Programa de computador, de acordo com a reivindicação 20,adaptado, de modo adicional, para realizar as etapas seguintes quando executado nodito dispositivo de processamento de dados: gerar um desafio; fornecer para aaplicação um desafio; e CARACTERIZADO pelo fato de que a autenticação daaplicação compreende autenticar a aplicação através da validação da resposta com odesafio e a chave compartilhada.
23. Programa de computador, de acordo com a reivindicação 22,adaptado, de modo adicional, para realizar as etapas seguintes quando executado nodito dispositivo de processamento de dados: Receber dados assinados com a resposta; eCARACTERIZADO pelo fato de que a autenticação da aplicação compreende, demodo adicional, verificar os dados assinados com a chave compartilhada.
24. Programa de computador, de acordo com a reivindicação 20,CARACTERIZADO pelo fato de ser adaptado, de modo adicional, para realizar asetapas seguintes quando executado no dito dispositivo de processamento de dados:Receber uma solicitação de registro a partir da aplicação, sendo que a solicitaçãocompreende, ao menos, um identificador de função de aplicação de rede e umidentificador de instân cia de aplicação antes de fornecer para a aplicação umidentificador de transação de autocarregamento.
25. Programa de computador, de acordo com a reivindicação 20,CARACTERIZADO pelo fato de ser adaptado, de modo adicional, para realizar asetapas seguintes quando executado no dito dispositivo de processamento de dados:Receber uma solicitação de registro a partir da aplicação, antes de fornecer para aaplicação um identificador de transação de autocarregamento.
26. Programa de computador, de acordo com a reivindicação 25,CARACTERIZADO pelo fato de que a solicitação de registro compreende umidentificador de instânc ia de aplicação.
27. Programa de computador, de acordo com as reivindicações 24 a 26,CARACTERIZADO pelo fato de que a derivação da chave compartilhadacompreende: Derivar a chave compartilhada com base na chave recebida a partir doservidor de função servidor de autocarregamento durante os procedimento deautocarregamento, o identificador de função de aplicação de rede e o identificador deinstância de aplicação.
28. Programa de computador, de acordo com a reivindicação 20,CARACTERIZADO pelo fato de ser adaptado, de modo adicional, para realizar asetapas seguintes quando executado no dito dispositivo de processamento de dados:Marcar a aplicação como confiável se a autenticação for bem sucedida.
29. Programa de computador, de acordo com a reivindicação 28,CARACTERIZADO pelo fato de ser adaptado, de modo adicional, para realizar asetapas seguintes quando executado no dito dispositivo de processamento de dados:Fornecer para a aplicação uma chave compartilhada.
30. Programa de computador, de acordo com a reivindicação 28,CARACTERIZADO pelo fato de ser adaptado, de modo adicional, para realizar asetapas seguintes quando executado no dito dispositivo de processamento de dados:Receber a partir da aplicação uma solicitação de uma chave de função de aplicação derede; e enviar para a aplicação a chave de função de aplicação de rede em resposta àsolicitação.
31. Programa de computador, de acordo com quaisquer dasreivindicações 20 a 30, CARACTERIZADO pelo fato de que o programa decomputador é incorporado em um meio de comunicação legível por co mputador
32. Programa de computador para autenticação de uma aplicação comuma aplicação de servidor, sendo que o programa de computador éCARACTERIZADO pelo fato de que compreende um código adaptado para realizar asetapas seguintes quando executado em um dispositivo de processamento de dados:receber a partir de uma aplicação de servidor, ao menos um identificador de transaçãode autocarregamento; abrir um enlace de comunicação com um servidor de função deaplicação de rede; fornecer ao servidor de função de aplicação de rede, ao menos, oidentificador de transação de autocarregamento através do enlace de comunicação;receber, em resposta ao fornecimento do identificador de transação deautocarregamento, ao menos, uma resposta proveniente do servidor de função deaplicação de rede; e autenticar a aplicação através do fornecimento à aplicação deservidor com, ao menos, a resposta recebida a partir do servidor de função deaplicação de rede.
33. Programa de computador, de acordo com a reivindicação 32,CARACTERIZADO pelo fato de que o recebimento proveniente da aplicação deservidor compreende receber o identificador de transação de autocarregamento e umdesafio; e o fornecimento para um servidor de função de aplicação de rede compreendeo fornecimento ao servidor de função de aplicação de rede o identificador de transaçãode autocarregamento e o desafio através do enlace de comunicação.
34. Programa de computador, de acordo com a reivindicação 33,CARACTERIZADO pelo fato de que o recebimento proveniente da função deaplicação de rede compreende receber a resposta e os dados assinados provenientes dafunção de aplicação de rede; e a autenticação da aplicação compreende fornecer àaplicação do servidor a resposta e os dados assinados recebidos a partir do servidor defunção de aplicação de rede.
35. Programa de computador, de acordo com a reivindicação 32,CARACTERIZADO pelo fato de ser adaptado, de modo adicional, para realizar aetapas seguinte quando executado no dito dispositivo de processamento de dados:Receber uma chave compartilhada proveniente da aplicação de servidor após umaautenticação bem sue edida.
36. Programa de computador, de acordo com a reivindicação 32,CARACTERIZADO pelo fato de ser adaptado, de modo adicional, para realizar asetapas seguintes quando executado no dito dispositivo de processamento de dados: Apósa autenticação, enviar para a aplicação de servidor uma solicitação de uma chave defunção de aplicação de rede; e receber a chave de função de aplicação de rede a partirda aplicação de servidor em resposta à solicitação.
37. Programa de computador, de acordo com quaisquer dasreivindicações 32 a 36, CARACTERIZADO pelo fato de que o programa decomputador é incorporado em um meio de comunicação legível por co mputador
38. Programa de computador para derivação de uma chave deautenticação, sendo que o programa de computador é CARACTERIZADO pelo fatode que compreende um código adaptado para realizar as etapas seguintes quandoexecutado em um dispositivo de processamento de dados: abrir um enlace decomunicação com uma aplicação; receber, a partir da aplicação, ao menos, umidentificador de transação de autocarregamento através do enlace de comunicação;enviar uma solicitação para um servidor de função de servidor de autocarregamentopara receber uma chave compartilhada, sendo que a solicitação compreende, ao menos,um identificador de transação de autocarregamento; receber, a partir do identificadorde transação de autocarregamento, a chave compartilhada em resposta à solicitação;derivar uma resposta usando-se, ao menos, a chave compartilhada; e enviar, ao menos,a resposta para a aplicação.
39. Programa de computador, de acordo com a reivindicação 38,CARACTERIZADO pelo fato de que o recebimento compreende receber oidentificador de transação de autocarregamento e um desafio através do enlace decomunicação; e a derivação compreende derivar a resposta através do uso, ao menos,da chave compartilhada e do desafio.
40. Programa de computador, de acordo com a reivindicação 38,CARACTERIZADO pelo fato de que o envio de, ao menos, a resposta compreendeenviar a resposta e os dados assinados com a chave compartilhada para a aplicação.
41. Programa de computador, de acordo com quaisquer dasreivindicações 38 a 40, CARACTERIZADO pelo fato de que o programa decomputador é incorporado em um meio de comunicação legível por co mputador
42. Terminal móvel para autenticação de uma aplicação,CARACTERIZADO pelo fato de que compreende uma aplicação de servidorconfigurada para executar procedimentos de autocarregamento entre a aplicação deservidor e uma função de servidor de autocarregamento; derivar uma chavecompartilhada com base em, ao menos, uma chave recebida a partir do servidor defunção de servidor de autocarregamento durante os procedimentos de autocarregamentoe um identificador de função de aplicação de rede; fornecer para a aplicação umidentificador de transação de autocarregamento, sendo que o identificador de transaçãode autocarregamento é recebido a partir do servidor de função de servidor deautocarregamento durante os procedimentos de autocarregamento; receber uma respostaproveniente da aplicação; e autenticar a aplicação através da validação da resposta coma chave compartilhada.
43. Terminal móvel, de acordo com a reivindicação 42,CARACTERIZADO pelo fato de que a aplicação de servidor é configurada paraautenticar a aplicação através da comparação da chave compartilhada com a resposta.
44. Terminal móvel, de acordo com a reivindicação 42,CARACTERIZADO pelo fato de que a aplicação do servidor é configurada para gerarum desafio; fornecer para a aplicação o desafio; e validar a resposta com o desafio e achave compartilhada.
45. Terminal móvel, de acordo com a reivindicação 44,CARACTERIZADO pelo fato de que a aplicação de servidor é configurada parareceber dados assinados com a resposta; e a etapa de autenticação compreende, demodo adicional, verificar os dados assinados com a chave compartilhada.
46. Terminal móvel, de acordo com a reivindicação 42,CARACTERIZADO pelo fato de que a aplicação de servidor é configurada parareceber uma solicitação de registro a partir da aplicação, sendo que a solicitaçãocompreende, ao menos, um identificador de função de aplicação de rede e umidentificador de instân cia de aplicação antes de fornecer para a aplicação umidentificador de transação de autocarregamento.
47. Terminal móvel, de acordo com a reivindicação 42,CARACTERIZADO pelo fato de que a aplicação de servidor é configurada parareceber uma solicitação de registro a partir da aplicação antes de fornecer para aaplicação um identificador de transação de autocarregamento.
48. Terminal móvel, de acordo com a reivindicação 47,CARACTERIZADO pelo fato de que a solicitação de registro compreende umidentificador de instânc ia de aplicação.
49. Terminal móvel, de acordo com as reivindicações 46 ou 48,CARACTERIZADO pelo fato de que a aplicação de servidor é configurada paraderivar a chave compartilhada com base na chave recebida a partir do servidor defunção servidor de autocarregamento durante os procedimentos de autocarregamento,no identificador de função de aplicação de rede e no identificador de instância deaplicação.
50. Terminal móvel, de acordo com a reivindicação 42,CARACTERIZADO pelo fato de que a aplicação de servidor é configurada paramarcar a aplicação como confiável se a autenticação for bem sucedida.
51. Terminal móvel, de acordo com a reivindicação 50,CARACTERIZADO pelo fato de que a aplicação de servidor é configurada parafornecer para a aplicação a chave compartilhada.
52. Terminal móvel, de acordo com a reivindicação 50,CARACTERIZADO pelo fato de que a aplicação de servidor é configurada parareceber a partir da aplicação uma solicitação de uma chave de função de aplicação derede; e enviar para a aplicação a chave de função de aplicação de rede em resposta àsolicitação.
BRPI0710257-7A 2006-03-28 2007-03-26 método para autenticar uma aplicação com uma aplicação de servidor e terminal móvel para autenticação de uma aplicação BRPI0710257B1 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US78635706P 2006-03-28 2006-03-28
US60/786,357 2006-03-28
PCT/FI2007/000073 WO2007110468A1 (en) 2006-03-28 2007-03-26 Authenticating an application

Publications (3)

Publication Number Publication Date
BRPI0710257A2 true BRPI0710257A2 (pt) 2011-08-09
BRPI0710257A8 BRPI0710257A8 (pt) 2016-07-12
BRPI0710257B1 BRPI0710257B1 (pt) 2019-11-05

Family

ID=38540823

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0710257-7A BRPI0710257B1 (pt) 2006-03-28 2007-03-26 método para autenticar uma aplicação com uma aplicação de servidor e terminal móvel para autenticação de uma aplicação

Country Status (15)

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

Families Citing this family (59)

* 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
TR201819540T4 (tr) 2006-07-06 2019-01-21 Nokia Technologies Oy Kullanıcı Ekipmanı Kimlik Bilgisi Sistemi
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
US8478360B2 (en) * 2008-03-03 2013-07-02 Qualcomm Incorporated 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
KR101507632B1 (ko) * 2008-03-14 2015-03-31 텔레폰악티에볼라겟엘엠에릭슨(펍) 로컬 네트워크로의 원격 액세스를 위한 방법 및 장치
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
US8826380B2 (en) * 2009-01-16 2014-09-02 Telefonaktiebolaget L M Ericsson (Publ) Proxy server, control method thereof, content server, and control method thereof
US8826016B2 (en) * 2009-02-05 2014-09-02 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
US8566594B2 (en) * 2010-04-14 2013-10-22 Qualcomm Incorporated Power savings through cooperative operation of multiradio devices
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
US20130074163A1 (en) * 2010-06-10 2013-03-21 Telefonaktiebolaget L M Ericsson (Publ) User equipment and control method therefor
CN102595389B (zh) 2011-01-14 2017-11-03 中兴通讯股份有限公司 一种mtc服务器共享密钥的方法及系统
US8903095B2 (en) * 2011-04-01 2014-12-02 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
MX2014005223A (es) * 2011-10-31 2014-09-01 Nokia Corp Mecanismo de seguridad para codigo externo.
GB201122206D0 (en) 2011-12-22 2012-02-01 Vodafone Ip Licensing Ltd Sampling and identifying user contact
WO2013121246A1 (en) * 2012-02-14 2013-08-22 Nokia Corporation 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 惠普发展公司，有限责任合伙企业 管理应用和网络之间的接口
CN104756458B (zh) * 2012-10-29 2018-07-10 瑞典爱立信有限公司 用于保护通信网络中的连接的方法和设备
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
KR20180038572A (ko) * 2013-05-22 2018-04-16 콘비다 와이어리스, 엘엘씨 머신-투-머신 통신을 위한 네트워크 지원형 부트스트랩핑
US9521000B1 (en) * 2013-07-17 2016-12-13 Amazon Technologies, Inc. Complete forward access sessions
JP2016525852A (ja) 2013-07-31 2016-08-25 ヒューレット−パッカード デベロップメント カンパニー エル．ピー．Ｈｅｗｌｅｔｔ‐Ｐａｃｋａｒｄ Ｄｅｖｅｌｏｐｍｅｎｔ Ｃｏｍｐａｎｙ， Ｌ．Ｐ． 消耗製品のメモリ内のデータ保護
GB2518254B (en) 2013-09-13 2020-12-16 Vodafone Ip Licensing Ltd Communicating with a machine to machine device
WO2015065063A1 (en) * 2013-10-30 2015-05-07 Samsung Electronics Co., Ltd. Method and apparatus to identity verification using asymmetric keys in wireless direct communication network
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
WO2015092130A1 (en) 2013-12-20 2015-06-25 Nokia Technologies Oy Push-based trust model for public cloud applications
WO2015102887A1 (en) * 2013-12-31 2015-07-09 Google Inc. Methods, systems, and media for providing access control for a computing device
US20150254662A1 (en) 2014-03-05 2015-09-10 Mastercard International Incorporated Verifying transaction context data at wallet service provider
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
KR102033465B1 (ko) * 2015-02-27 2019-10-17 텔레호낙티에볼라게트 엘엠 에릭슨(피유비엘) 통신 디바이스와 네트워크 디바이스 사이의 통신에서의 보안 설비
WO2016191376A1 (en) * 2015-05-22 2016-12-01 Antique Books, Inc. Initial provisioning through shared proofs of knowledge and crowdsourced identification
EP3188435B1 (en) * 2015-12-28 2019-11-13 Lleidanetworks Serveis Telemàtics S.A. Method for certifying an electronic mail comprising a trusted digital signature by a telecommunications operator
CN108702615B (zh) * 2016-02-12 2022-08-05 瑞典爱立信有限公司 保护接口以及用于建立安全通信链路的过程
US10482255B2 (en) * 2016-02-16 2019-11-19 Atmel Corporation Controlled secure code authentication
EP3611624B1 (en) * 2017-04-14 2024-02-28 Sony Group Corporation Communication device, information processing device, and data processing system
EP3912375A4 (en) * 2019-01-14 2022-08-24 Telefonaktiebolaget LM Ericsson (publ) METHOD AND DEVICE FOR SAFETY
CN113302960B (zh) 2019-01-21 2024-06-11 瑞典爱立信有限公司 用于无线通信网络中的认证和密钥管理的方法以及相关装置
EP3939200A4 (en) * 2019-03-12 2022-12-07 Nokia Technologies Oy SHARING A COMMUNICATION NETWORK ANCHORED CRYPTOGRAPHIC KEY WITH A 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
US12056243B2 (en) 2019-08-27 2024-08-06 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
US20250133397A1 (en) * 2021-09-18 2025-04-24 Telefonaktiebolaget Lm Ericsson (Publ) Gba key diversity for multiple applications in ue
US12556536B1 (en) * 2022-03-17 2026-02-17 Amazon Technologies, Inc. Transparent credential proxying

Family Cites Families (23)

* 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 配信方法および配信システム
US7698550B2 (en) * 2002-11-27 2010-04-13 Microsoft Corporation Native wi-fi architecture for 802.11 networks
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
ES2436340T3 (es) * 2005-02-04 2013-12-30 Qualcomm Incorporated Secuencia Inicial segura para comunicaciones inalámbricas
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
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)
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)
DE602005019255D1 (de) * 2005-07-07 2010-03-25 Ericsson Telefon Ab L M Verfahren und anordnung für authentifikation und privatsphäre
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

Also Published As

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

Similar Documents

Publication Publication Date Title
BRPI0710257A2 (pt) métodod para aumentar uma aplicação; método para autenticar uma aplicação com uma aplicação de servidor; método para derivar uma chave de autenticação; programa de computador para autenticação de uma aplicação; programa de computador para derivação; terminal móvel para autenticação de uma aplicação
US12052350B2 (en) Quantum resistant secure key distribution in various protocols and technologies
US10708058B2 (en) Devices and methods for client device authentication
US8738898B2 (en) Provision of secure communications connection using third party authentication
EP3767984B1 (en) Communicating with a machine to machine device
CN101822082B (zh) 用于uicc和终端之间安全信道化的技术
JP5390619B2 (ja) Ｈｏｍｅｎｏｄｅ−ｂ装置およびセキュリティプロトコル
CN101371491B (zh) 提供无线网状网络的方法和装置
BR112021003460A2 (pt) dispositivo sem identidade de assinante, dispositivo de identidade do assinante, método para uso em um dispositivo sem identidade de assinante, método para uso em um dispositivo com identidade de assinante e produto de programa de computador
US11316670B2 (en) Secure communications using network access identity
EP3440861B1 (en) Lte-level security for neutral host lte
BR112021003448A2 (pt) dispositivo sem identidade de assinante, dispositivo de identidade do assinante, método para uso em um dispositivo sem identidade de assinante, método para uso em um dispositivo com identidade de assinante e produto de programa de computador transferível por download
KR20060070313A (ko) 무선 이동 단말의 인증 시스템 구현 장치 및 방법
Boire et al. Credential provisioning and device configuration with EAP
AU2012203961B2 (en) Authenticating an application
Latze Towards a secure and user friendly authentication method for public wireless networks
Santos Secure Wifi Portals in WIFI4EU Environment

Legal Events

Date Code Title Description
B25A Requested transfer of rights approved

Owner name: NOKIA TECHNOLOGIES OY (FI)

B15K Others concerning applications: alteration of classification

Ipc: H04L 29/06 (2006.01), H04L 9/08 (2006.01), H04L 9/

B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B06T Formal requirements before examination [chapter 6.20 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 05/11/2019, OBSERVADAS AS CONDICOES LEGAIS.