BRPI0617286A2 - métodos para estabelecer uma associação de segurança entre um nó de serviço e um cliente, para estabelecer uma associação de segurança entre primeiro e segundo clientes, e para proteger um nó contra ataques de repetição, nó de serviço, terminal de cliente, e, função de geração de código - Google Patents
métodos para estabelecer uma associação de segurança entre um nó de serviço e um cliente, para estabelecer uma associação de segurança entre primeiro e segundo clientes, e para proteger um nó contra ataques de repetição, nó de serviço, terminal de cliente, e, função de geração de código Download PDFInfo
- Publication number
- BRPI0617286A2 BRPI0617286A2 BRPI0617286-5A BRPI0617286A BRPI0617286A2 BR PI0617286 A2 BRPI0617286 A2 BR PI0617286A2 BR PI0617286 A BRPI0617286 A BR PI0617286A BR PI0617286 A2 BRPI0617286 A2 BR PI0617286A2
- Authority
- BR
- Brazil
- Prior art keywords
- code
- node
- service
- client
- additional information
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 58
- 230000006870 function Effects 0.000 claims description 43
- 239000000463 material Substances 0.000 claims description 11
- 230000002265 prevention Effects 0.000 claims description 11
- 238000004891 communication Methods 0.000 claims description 5
- 238000003780 insertion Methods 0.000 claims description 5
- 230000037431 insertion Effects 0.000 claims description 5
- 238000013459 approach Methods 0.000 abstract description 3
- 230000011664 signaling Effects 0.000 description 5
- 238000009795 derivation Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 238000004846 x-ray emission Methods 0.000 description 2
- SQVRNKJHWKZAKO-PFQGKNLYSA-N N-acetyl-beta-neuraminic acid Chemical compound CC(=O)N[C@@H]1[C@@H](O)C[C@@](O)(C(O)=O)O[C@H]1[C@H](O)[C@H](O)CO SQVRNKJHWKZAKO-PFQGKNLYSA-N 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000011017 operating method Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
Classifications
-
- 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
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
-
- 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
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/55—Push-based network services
-
- 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/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
- H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
-
- 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]
- 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
- 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/56—Financial cryptography, e.g. electronic payment or e-cash
-
- 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
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/04—Large scale networks; Deep hierarchical networks
- H04W84/042—Public Land Mobile systems, e.g. cellular systems
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)
- Computer And Data Communications (AREA)
Abstract
MéTODOS PARA ESTABELECER UMA ASSOCIAçãO DE SEGURANçA ENTRE UM Nó DE SERVIçO E UM CLIENTE, PARA ESTABELECER UMA ASSOCIAçãO DE SEGURANçA ENTRE PRIMEIRO E SEGUNDO CLIENTES, E PARA PROTEGER UM Nó CONTRA ATAQUES DE REPETIçãO, Nó DE SERVIçO, TERMINAL DE CLIENTE, E, FUNçãO DE GERAçãO DE CóDIGO. Método para estabelecer uma associação de segurança entre um cliente e um nó de serviço para a finalidade de inserir informação do nó de serviço para o cliente, onde o cliente e um servidor de código compartilham um segredo básico. O método compreende enviar uma requisição para geração e provisão de um código de serviço, do nó de serviço para um servidor de código, a requisição identificando o cliente e o nó de serviço, gerar um código de serviço no servidor de código usando as identidades do cliente e do nó de serviço, o segredo básico e informação adicional, e enviar o código de serviço ao nó de serviço, juntamente com citada informação adicional, enviar citada informação adicional do nó de serviço para o cliente e, no cliente, gerar citado código de serviço usando a informação adicional recebida e o código base. Uma abordagem similar pode ser usada para prover gerenciamento de código p2p.
Description
"MÉTODOS PARA ESTABELECER UMA ASSOCIAÇÃO DESEGURANÇA ENTRE UM NÓ DE SERVIÇO E UM CLIENTE, PARAESTABELECER UMA ASSOCIAÇÃO DE SEGURANÇA ENTREPRIMEIRO E SEGUNDO CLIENTES, E PARA PROTEGER UM NÓCONTRA ATAQUES DE REPETIÇÃO, NÓ DE SERVIÇO, TERMINALDE CLIENTE, E, FUNÇÃO DE GERAÇÃO DE CÓDIGO"
Campo da invenção
A presente invenção relaciona-se a um método e aparelho paraestabelecer uma associação de segurança entre um terminal de cliente e um nóde serviço, no sentido de fornecer um serviço tipo inserção (SMS melhorado)e, em particular, embora não necessariamente, a tal método e aparelho queemprega uma Arquitetura Bootstrapping Genérica.
Fundamentos da Invenção
No sentido de facilitar a provisão de serviços a terminais deusuário, uma rede móvel tal como uma rede 3 G freqüentemente requererá oestabelecimento de um canal de comunicação seguro ou "associação desegurança" entre terminais de cliente (isto é, terminais móveis) e os nós deserviço baseados em rede que provêem os serviços. A ArquiteturaBootstrapping Genérica (GBA) é discutida na Especificação Técnica 3 GPPTS 33.220 e provê um mecanismo pelo qual um terminal de cliente (UE) podeser autenticado para uma Função de Autenticação de Rede (o nó de serviço) ecódigos de sessão segura obtidos para uso entre o terminal de cliente e aFunção de Autenticação de Rede. O modelo simples de rede para estaarquitetura é ilustrado na Figura 1. Este mecanismo executa Bootstrapping noconhecido procedimento de Autenticação e Acordo de Código (AKA) [GPPTS 33.102] que permite que um terminal de cliente seja autenticado para umaFunção de Servidor de Bootstrapping (BSF) da rede doméstica do cliente,com base em um K secreto que é compartilhado entre o USIM do terminal decliente e o Sistema de Assinante Doméstico (KSS) da rede doméstica doassinante. O procedimento AKA estabelece adicionalmente códigos de sessãoa partir dos quais códigos são derivados, os quais são posteriormenteaplicados entre o terminal de cliente e uma Função de Aplicação de Rede(NAF). Quando um terminal de cliente e NAF desejam obter códigos desessão a partir da BSF5 a NAF envia um identificador de transação à BSF, oidentificador de transação contendo um índice que a BSF usa para identificaro terminal de cliente e códigos apropriados que este envia ao NAF.
De acordo com o mecanismo GBA, o UE inicia o processo degeração de código enviando uma requisição contendo uma identidade deusuário ao BSF. A requisição também contém a identidade da NAF. A BSFrecupera um vetor de autenticação a partir do Servidor de AssinanteDoméstico (HSS), cada vetor de autenticação consistindo de um númerorandômico RAND, uma resposta esperada XRES, um código cifrado CK, umcódigo de integridade IK e um ficha de autenticação AUTN. A BSF geramaterial de código KS concatenando CK e IK contidos dentro do vetor deautenticação. A BSF gera um identificador de código B-TID no formato NAIpor codificação de base 64 do valor RAND e combinando o valor codificadocom o nome do servidor BSF, isto é, como
base64encode(RAND)@BSF_servers_domainji.ame.
A BSF retém o código KS em associação com o identificadorde transação B-TID e a identidade NAF. O B-TID e AUTN são enviados pelaBSF ao UE, o USIM do terminal de cliente verificando o valor AUTN usandoo K secreto compartilhado e retornando uma compilação do resultadoesperado XRES à BSF. O USIM também gera o material de código KSusando o K secreto e o valor RAND (recuperado) do B-TID.
Em seguida à conclusão deste procedimento, o UE comunica àNAF, o B-TID recebido. A NAF e a BSF são autenticadas uma à outra, e aNAF envia à BSF o B-TID recebido juntamente com sua própria identidade.A BSF usa o B-TID e a identidade da NAF para localizar o código KS corretoe usa KS para gerar um código NAF. Outra informação tal como a identidadeNAF é também usada na geração do código NAF. O código NAF gerado éretornado à NAF. O UE é similarmente capaz de gerar o código NAF usandoo código KS que este já tenha gerado.
Após o mecanismo GBA ter sido executado pela primeira vez,requisições subseqüentes para estabelecer uma associação de segurança entreo UE e a mesma ou uma NAF diferente pode usar o material de código KS jáestabelecido, desde que aquele código não tenha expirado. Entretanto, istoainda requererá que o UE inicie uma requisição para estabelecimento de umaassociação de segurança enviando seu B-TID á NAF.
Sumário da Invenção
Há ocasiões nas quais é desejável permitir que a NAF inicie oestabelecimento de uma associação de segurança com o UE. Por exemplo,pode-se considerar um serviço tipo inserção que fornece informação denotícias, esportes, e finanças, etc., a usuários que tenham se registradopreviamente para um serviço. Um procedimento operacional típico para obteristo pode ser para o provedor de serviço enviar uma mensagem SMS ao UEque requisita ao usuário para abrir uma conexão segura. Entretanto, há muitasameaças relacionadas a este modelo pois uma SMS pode ser manipulada,enviada por uma parte não autorizada, ser repetida, etc. Se existiu umaassociação de segurança, ou o nó de serviço pôde iniciar uma, antes que osdados de serviços reais sejam enviados, os procedimentos de segurançapoderiam ser baseados nisto e a maioria dos problemas poderiam serminimizada.
De acordo com um primeiro aspecto da presente invenção, éprovido um método para estabelecer uma associação de segurança entre umprimeiro nó e um segundo nó para a finalidade de inserir informação a partirdo primeiro nó para o segundo nó, onde o segundo nó e uma função degeração de código compartilham um segredo básico, o métodocompreendendo:
• enviar uma requisição para geração e provisão de umcódigo de serviço a partir do primeiro nó para a função de geração de código,a requisição contendo identidades do primeiro e segundo nós;
gerar um código de serviço na função de geração decódigo, usando a identidade do primeiro nó, o segredo básico e informaçãoadicional, e enviar o código de serviço ao primeiro nó juntamente com acitada informação adicional;
• enviar a citada informação adicional e a citada identidadedo primeiro nó, a partir do primeiro nó para o segundo nó; e
• no segundo nó, gerar o citado código de serviço usando ainformação adicional recebida, a primeira identidade de usuário e o segredobásico.
Será verificado que a função de geração de código pode ser umnó isolado ou pode ser um servidor distribuído. No caso de uma rede 3Gempregando a Arquitetura Bootstrapping Genérica, uma Função de Servidorde Bootstrapping e um Servidor de Assinante Doméstico (HSS) podem juntosprover a função de geração de código, onde a Função de Servidor deBootstrapping se comunica com o nó de serviço e com o Servidor deAssinante Doméstico. No caso de uma rede 2G, a função de geração decódigo pode ser uma combinação de uma Função de Servidor deBootstrapping e um servidor AuC.
No caso de uma rede 3 G empregando a ArquiteturaBootstrapping Genérica, o nó de serviço compreende uma Função deAplicação de Rede. A etapa de gerar um código de serviço na função degeração de código, compreende as etapas de:
• gerar material de código KS usando a citado segredobásico; e
• gerar o código de serviço usando o citado material decódigo KS, a identidade do nó de serviço e a citada informação adicional.
A etapa de gerar o código de serviço no cliente tambémcompreende estas duas etapas.
Citada etapa de gerar um código de serviço no servidor decódigo pode utilizar valores diferentes daqueles enviados ao cliente pelo nóde serviço. O cliente pode obter certos outros valores do servidor de código.
Citada informação adicional pode compreender um ou mais
dentre:
um valor randômico;marcação de tempo;número de seqüência;outros identificadores
No caso da Arquitetura Bootstrapping Genérica, citado valorrandômico é o parâmetro RAND e é levado dentro do B-TID.Citada informação adicional pode compreender umidentificador de transação no formato de NAI, e compreendendo um valorrandômico codificado.
Citada informação adicional pode ser enviada do nó de serviçopara o cliente em uma mensagem também contendo dados de serviço, osdados de serviço sendo criptografados com o código de serviço, onde ocliente pode decriptografar os dados criptografados uma vez que este tenhagerado o código de serviço.
Em uma realização da invenção, a função de geração decódigo envia ao nó de serviço um valor de autenticação de rede. O nó deserviço redireciona este valor ao cliente, juntamente com a citada informaçãoadicional. O cliente usa o segredo básico e o valor de autenticação paraautenticar a função de geração de código. Somente se a função de geração decódigo é autenticada o cliente gera e usa o código de serviço.
Em uma realização alternativa da invenção, o cliente requisitaum valor de autenticação a partir da função de geração de código após terrecebido a citada informação adicional do nó de serviço. Somente quando ocliente tiver autenticado a função de geração de código, o código de serviço égerado e usado.
O terminal pode compreender meios para receber do nó deserviço um código de autenticação de mensagem, o terminal compreendendomeios para gerar um código ou códigos de autenticação a partir de pelo menosuma parte da informação de geração de código, e usando o(s) código(s) deautenticação para autenticar o código de autenticação de mensagem. Os meiosde geração podem ser um USIM/ISIM.
Citado código de serviço pode ser um código de Diffie-Hellman para o segundo nó, o método adicionalmente compreendendo a etapade prover ao primeiro nó um código de Diffie-Hellman para aquele primeironó, e enviar o código de Diffie-Hellman para o primeiro nó ao segundo nó,citada associação de segurança sendo estabelecida com base nos dois códigosde Diffie-Hellman diferentes.
De acordo com um segundo aspecto da presente invenção, éprovido um nó de serviço para fornecer um serviço de inserção a um cliente,via um enlace de comunicação seguro, o nó de serviço compreendendo:
· meio para enviar uma requisição para geração e provisãode um código de serviço a uma função de geração de código, a requisiçãoidentificando o cliente e o nó de serviço;
• meio para receber da função de geração de código umcódigo de serviço, juntamente com a citada informação adicional;
· meio para redirecionar citada informação adicional aocliente; e
• meio para criptografia e/ou informação de serviço deproteção de integridade, usando o código de serviço e para enviar ainformação criptografada e/ou informação protegida ao cliente.No caso da Arquitetura Bootstrapping Genérica, citadainformação adicional compreende um B-TID contendo um valor RAND.Citado meio para envio é também arranjado para enviar ao cliente umaidentidade do nó de serviço.
De acordo com um terceiro aspecto da invenção é provido umterminal de cliente para receber um serviço inserção fornecido por um nó deserviço, o terminal de cliente compreendendo:
• meio de memória para armazenar um segredo que écompartilhado com uma função de geração de código;
· meio para receber informação de geração de código docitado nó de serviço;
• meio para gerar um código de serviço usando o citadosegredo compartilhado e citada informação de geração de código; e
• meio para usar o citado código de serviço paradecriptografar e/ou verificar a integridade das comunicações com o nó deserviço.
De acordo com um quarto aspecto da presente invenção, éprovida uma função de geração de código para uso ao estabelecer umaassociação de segurança entre um cliente e um nó de serviço para a finalidadede inserir informação do nó de serviço para o cliente, o servidor de códigocompreendendo:
• meio de memória para armazenar um segredo que écompartilhado com o citado cliente;
• meio para receber uma requisição para geração e provisãode um código de serviço a partir do citado nó de serviço, a requisiçãoidentificando o cliente e o nó de serviço; e
• meio para gerar um código de serviço usando asidentidades do cliente e o nó de serviço, o segredo básico, uma informaçãoadicional, e para enviar o código de serviço ao nó de serviço, juntamente coma citada informação adicional.
De acordo com um quinto aspecto da presente invenção, éprovido um método para estabelecer uma associação de segurança entre oprimeiro e segundo clientes, para a finalidade de inserir informação doprimeiro cliente para o segundo cliente, onde o primeiro e segundo clientestêm relações acreditadas com o primeiro e segundo servidores de código,respectivamente, e compartilham um segredo com seus respectivos servidoresde código, o método compreendendo:
• enviar uma requisição para geração e provisão de umcódigo de serviço do primeiro cliente para o segundo servidor de código, viaprimeiro servidor de código, a requisição identificando o primeiro e segundonós;
• gerar um código de serviço no segundo servidor de códigousando a identidade do primeiro nó, o segredo básico, e informação adicional,e enviar o código de serviço ao primeiro nó juntamente com a citadainformação adicional;
• enviar citada informação adicional do primeiro nó para osegundo nó; e
no segundo nó, gerar citado código de serviço usando a informação adicionalrecebida e o segredo básico.
De acordo com um sexto aspecto da presente invenção, éprovido um método para proteger um nó contra ataques de repetição, ométodo compreendendo:
gerar um código de serviço em uma função de servidor debootstrapping;
prover o código de serviço a um primeiro nó, juntamente cominformação requerida para gerar o código de serviço;
enviar uma mensagem de geração de código do primeiro nópara o segundo nó, a mensagem incluindo a citada informação, um valor deprevenção de repetição, e um código de autenticação de mensagem calculadoatravés do corpo da mensagem, incluindo o valor de prevenção de repetição, ovalor de prevenção de repetição sendo incrementado ou decrementado paracada execução do procedimento;
receber citada mensagem de geração de código no citadosegundo nó e armazenar o valor de prevenção de repetição contido nela; e
no segundo nó, cada vez que uma mensagem de geração decódigo é recebida, verificar o citado código de autenticação de mensagem,determinar se o valor de prevenção de repetição contido na mensagem já foiarmazenado ou não no segundo nó, e caso afirmativo, rejeitar a mensagem.
Realizações deste aspecto da invenção permitem que osegundo nó rejeite ataques de repetição com base em mensagens previamenteenviadas ao segundo nó, com respeito a um procedimento GBA válido. Se oatacante fosse meramente incrementar aquele valor de prevenção de repetiçãopara um valor não usado previamente, o segundo nó detectaria esta mudançacom base no valor MAC incorreto, e daí detectaria o ataque. Novamente, oprimeiro nó pode ser um servidor NAF, com o segundo nó sendo um cliente,ou ambos primeiro e segundo nós podem ser clientes. Será verificado quecaracterísticas do primeiro ao quinto aspectos da presente invenção podem sercombinados com aqueles do sexto aspecto, e vice-versa.
Breve Descrição dos Desenhos
Figura 1 ilustra um modelo simples de rede para a ArquiteturaBootstrapping Genérica;
Figuras 2 a 7 ilustram fluxos de sinalização associados arespectivos procedimentos para estabelecer uma associação de segurançaentre um cliente (UE) e NAF; e
Figuras 8 e 9 ilustram fluxos de sinalização associados arespectivos procedimentos para estabelecer uma associação de segurançaentre um par de clientes (UEa e UEb).Descrição Detalhada de Certas Realizações
A Arquitetura Bootstrapping Genérica (GBA) para redes 3 Gtêm sido descrita com referência à Figura 1, que ilustra as interfaces (Ua, Ub,Zn e Zh) entre as várias entidades. Devia ser considerado que a descrição estáem um nível relativamente alto e implementações reais podem "parecer"diferentes, embora empregando a mesma funcionalidade geral. Por exemplo, épossível que, quando uma BSF recebe uma requisição de código de serviço deuma NAF (como será descrito abaixo), a BSF receptora precisa executar umaetapa de resolução de endereço para identificar uma BSF de "serviço" para aNAF ou cliente (UE) e, se a BSF de recepção não é a BSF de serviço, arequisição é redirecionada para a BSF de serviço.
A descrição é concernente à provisão de um serviço inserçãopara um cliente. Tipicamente, o cliente estará pré registrado com o provedorde serviço, mas a iniciativa de inserir informação particular é tomada peloprovedor de serviço. Em tal situação, o provedor de serviço e o cliente já nãoterão uma associação de segurança estabelecida um com o outro (associaçõesde segurança são tipicamente de vida curta) e precisa ser estabelecida.
Uma primeira solução proposta aqui considera a abordagem deque a NAF solicita à BSF um código (ou serviço) NAF. A BSF retorna àNAF, o código NAF juntamente com o identificador de transação de cliente(B-TID) e o valor de autenticação de rede correspondente (AUTN). Como foiestabelecido acima, o B-TID contém o valor RAND codificado (como oprefixo NAI) que pode ser usado pelo cliente para derivar o código base (KS).A NAF pode agora compor uma mensagem contendo o B-TID, AUTN edados adicionais incluindo a identidade NAF que o cliente requer no sentidode derivar o código NAF, e enviar esta mensagem ao cliente. Esta mensagempode ser uma mensagem que somente dispara a configuração de um SA (istoé, compartilhamento de um código de serviço) ou poderia conter dados deserviço (isto é, dados de carga útil) criptografados com o código de serviço.Em ambos os casos, os valores B-TID, AUTN e outros dados requeridos pelocliente para gerar KS são enviados em texto comum, mas são "assinados"com um Código de Autenticação de Mensagem. Notar que o(s) código(s) naSA são derivados usando o código compartilhado entre o HSS e o UE, e que oAUTN está incluído na mensagem. Portanto, não é possível "enganar"mensagens, embora o código usado para proteger a integridade da mensagemseja derivado do verdadeiro SA que é destinado a estabelecer.
Quando o cliente recebe a mensagem, este recupera a parteRAND do B-TID (revertendo a codificação) e o AUTN e os aplica ao USIM/ISIM para derivar o código base Ks. Então este usa os dados adicionaispara derivar o código NAF e verifica a mensagem recebida usando o MAC.
As trocas de sinalização associadas a este procedimento sãoilustradas na Figura 2.
No sentido de evitar a manipulação dos dados adicionais (requeridos pelo cliente) pela NAF, a BSF pode assinar aqueles dados usandoum derivado de KS. Isto pode ser importante, por exemplo, para evitar que aNAF estenda o tempo de vida de um código.
A solução apresentada acima permite que a NAF insira nocliente a informação requerida para estabelecer uma associação de segurança entre as duas partes. Então, o cliente não tem que configurar uma conexãocom a BSF para realizar estas tarefas. Isto representa uma soluçãoextremamente eficiente no tempo. Entretanto, requer que a NAF comute todainformação relacionada a código (tempo de vida de código, Add-info, etc.) deuma forma protegida a partir da BSF para o UE. O B-TID e os outros dadospodem então compreender realmente uma grande estrutura de dados. Istopode ser problemático no caso em que o volume de dados que pode serincorporado na estrutura de mensagem entre o cliente e a NAF, por exemplo,onde esta estrutura é SMS.
No sentido de reduzir o volume de dados requerido, trocadoentre a NAF e o cliente para estabelecer a associação de segurança, a soluçãoacima pode ser modificada omitindo o valor AUTN dos dados enviados pelaBSF à NAF. A NAF agora compõe uma mensagem contendo o B-TED eoutros dados necessários (incluindo a identidade NAF) que o terminalnecessita para derivar o código NAF e os envia ao cliente. Novamente, estamensagem poderia ser uma mensagem que apenas dispara a configuração deuma associação de segurança, ou poderia conter dados de carga útilcriptografados.
Quando o cliente recebe a mensagem da NAF, conecta a BSF, transmitindo o B-TID a ela, autentica-se e requisita a informação restantenecessária para derivar o material de codificação associado ao B-TID, isto é,por exemplo, AUTN. Depois de ter recebido esta informação, este deriva ocódigo de serviço (NAF) e verifica a integridade da mensagem. Como ocliente tem que se conectar à BSF, pode ao mesmo tempo obter toda a informação relacionada ao material de codificação, isto é, Add-Info, tempo devida de código, etc., reduzindo então a quantidade de informação"administrativa" que tem que ser transmitida da NAF para o cliente.
A troca de sinalização associada a este procedimento, supondoo cenário de geração Ks (isto é, análogo à Figura 2) é mostrada na Figura 3.
Pode ser indesejável em algumas circunstâncias revelar o valorRAND à NAF. Isto pode ser evitado formando o B-TID usando umareferência para o valor RAND real (ou o RAND efetivo, RANDe) de tal modoque a NAF vê apenas o valor de referência. O RAND efetivo (RANDe) teriaentão que ser sinalizado juntamente com AUTN, da BSF para o cliente. Esteprocedimento modificado é ilustrado na Figura 4.
A vantagem principal das soluções descritas com referência àsFiguras 3 e 4 é que a BSF terá uma oportunidade adicional para controlar ageração de código no cliente. O cliente necessita AUTN para derivar ocódigo. Por outro lado, o cliente terá que se conectar à BSF e se autenticarpara a BSF5 requerendo uma nova variante do protocolo GBA através dainterface Ub.
Uma ameaça às soluções das Figuras 3 e 4 é que um atacantepode gerar um lote de mensagens (implicando em conter um B-TID válido) eenviá-las a diferentes clientes para iniciar um ataque Negação-de-Serviço(DoS). Como os clientes não possuem meios para autenticar as mensagens(isto é, um AUTN) estes se conectarão à BSF em uma tentativa de autenticaras mensagens recebidas. Tal ataque, se não houver resistência, consumiráconsideráveis recursos em parte da BSF. Para tornar tal ataque DoS maisdifícil, seria desejável habilitar o cliente a verificar imediatamente o MAC damensagem inserida pela NAF, no sentido de validara a mensagem sem ter quese conectar à BSF. Para obter isto, o cliente tem que ser capaz de derivar ocódigo que é usado para geração do MAC da mensagem. Como o AUTN nãoé enviado ao cliente na mensagem push, esta derivação tem que ser baseadasomente no RAND (ou valor derivado, Figura 4) no B-TID.
Uma solução é o uso só RAND (ou valor derivado) no B-TIDpara derivar dois códigos Ck' e Ik' na BSF. A BSF então deriva um códigoMAC usando esses códigos, e envia o código MAC à NAF. Este código deintegridade deveria preferivelmente também depender da identidade NAF.Usar uma "impressão digital" das outras informações necessárias para derivaro código NAF na derivação do código de integridade, seria o único meio deobter isto sem ter que enviar toda a informação ao UE. A NAF computa umsegundo MAC (curto) através de pelo menos uma parte dos dados a seremenviados ao cliente, e inclui o MAC na mensagem enviada ao cliente. Nocliente, o USIM/ISIM usa os algoritmos AKA para gerar Ck' e Ik' e daí osegundo código MAC, e o cliente pode então verificar a mensagem.
Alternativamente, a BSF pode prover os códigos Ck' e Dc' à NAF parahabilitar a NAF a gerar o próprio segundo código MAC. Isto não interrompe arepetição da mensagem antiga (embora isto possa ser equacionado com o usode marcações de tempo) mas interrompe atacantes gerando mensagensrandômicas.
Em uma solução alternativa, ilustrada no diagrama desinalização da Figura 5, a BSF não gera e envia o próprio código NAF à NAF5em resposta à requisição NAF para um código PUSH para um dado usuário.
Ao invés disso, a BSF envia um valor público de Diffie-Hellman gNAF Keybaseado no Código NAF (ou em algum outro valor baseado no segredoassociado Ks) e dados relacionados à identidade das partes envolvidas e usopretendido do código. A NAF pode agora escolher um valor secreto RANDpróprio, e anexar o valor correspondente público de Diffie-Hellman g^0para aquele valor secreto à informação enviada ao UE. Ambas as partespodem então derivar um código compartilhado comum, S_Key = gRAND*NAFKey. O S_Key é usado para codificar o MAC. É notado que os esquemasDiffie-Hellman podem ser implementados através de diferentes tipos degrupos. Aqui, usamos a notação padrão quando o grupo é Zp e o elemento degeração g usado é denotado por g.
De acordo ainda com uma solução alternativa, ilustrada nodiagrama de sinalização da Figura 6, quando a NAF requer um código PUSHpara um dado usuário, a BSF não inclui um código NAF padrão, mas ao invésdisso deriva um código que se apóia adicionalmente em ambos UE_identity eNAF_identity (em adição a quaisquer dados adicionais). Tal código édenotado "NAF_UE_Key" na Figura. No sentido de assegurar o fornecimentodo código à NAF a partir da BSF, a BSF inclui na mensagem para a BSF umMAC calculado usando o NAF_UE_Key.
A discussão acima considerou a aplicação da invenção àprovisão de códigos relacionados a serviços a usuários e nós de serviço. Umaoutra aplicação da presente invenção relaciona-se à provisão de códigos aterminais de cliente para permitir que um terminal de cliente insira mensagensa um terminal de cliente de rede não hierárquica de uma maneira segura, querdizer gerenciamento de código "peer-to-peer" (p2p).
De acordo com uma solução, um UE inicial, isto é, UEa,emprega o método ilustrado em geral na Figura 7. Esta abordagem se apóiaem uma relação de confiança explícita entre a BSFa e a BSFb. A parte inicialprimeiramente executa um procedimento GBA padrão com a BSFa de suarede doméstica, no sentido de obter um código base, KsA. UEa então usa ocódigo base para derivar uma RAND atrelada à outra parte UEb à qual UEadeseja inserir uma mensagem. Isto pode ser feito do mesmo modo que oscódigos NAF são derivados. A segunda ação executada pelo UEa érequisitada informação de código para UEb. Esta requisição, contendo asidentidades de ambos os clientes, é enviada à BSFa, que envia a requisição àBSF dentro da rede doméstica do UEb, isto é, BSFb.
A BSFb retorna a UEa, via BSFa, um valor público de Diffie-Hellman para UEb, a saber gNAF Key. Este também retorna o B-TID (contendoo valor RAND usado para gerar o NAF Key), AUTN, e dados adicionaisrequeridos. A parte inicial UEa então forma uma mensagem contendo seuvalor de Diffie-Hellman público, gRAND, e a informação necessária peloreceptor para derivar o KSB, o NAF_Key relacionado, e daí o código desessão gRAND*NAF-Keyj UEa pode naturalmente derivar o mesmo código desessão.
Uma solução de gerenciamento de código p2p alternativa éilustrada na Figura 8 e requer que a BSFb gere o código para sercompartilhado pelas redes não hierárquicas. A primeira ação pela a parteinicial UEa é requisitar um código para a outra parte UEb. Esta requisição éenviada ao início da parte BSFa, que redireciona a requisição à BSFb da partede recepção. A parte inicial inclui sua identidade bem como aquela da partede recepção na requisição, e a BSFb deriva o código a ser compartilhado,NAF_UE_Key. O código derivado, juntamente com B-TID, AUTN, etc., éentão fornecido ao UEa.Com este esquema, a parte de recepção recebe uma verificaçãoimplícita da identidade reivindicada do remetente, pois esta identidade éusada na derivação de NAF_UE_Key. A parte de recepção poderia tambémobter uma autenticação explícita se a BSFb inclui um MAC baseado em um "NAF_Key" cobrindo todos os dados, conforme descrito acima.
Será verificado pela pessoa especialista na técnica que váriasmodificações podem ser feitas à realizações acima descritas, sem se afastar doescopo da presente invenção. Por exemplo, embora as soluções apresentadasacima tenham sido relacionadas a GBA, a invenção tem aplicabilidade geral a arquiteturas onde a informação deve ser inserida de um provedor de serviço, eonde o provedor de serviço e o cliente não compartilham um segredo comum.Em uma outra modificação, onde soluções múltiplas são implementadas emparalelo, a requisição de autenticação enviada à BSF contém um seletorindicando qual solução a NAF/UE empregará.
Claims (28)
1. Método para estabelecer uma associação de segurança entreum primeiro nó e um segundo nó, para finalidade de inserir informação doprimeiro nó para o segundo nó, onde o segundo nó e uma função de geraçãode código compartilham um segredo básico, o método caracterizado pelo fatode compreender:• enviar uma requisição para geração e provisão de umcódigo de serviço a partir do primeiro nó para a função de geração de código,a requisição contendo identidades do primeiro e segundo nós;• gerar um código de serviço na função de geração decódigo, usando a identidade do primeiro nó, o segredo básico e informaçãoadicional, e enviar o código de serviço ao primeiro nó juntamente com acitada informação adicional;• enviar a citada informação adicional e a citada identidadedo primeiro nó, a partir do primeiro nó para o segundo nó; e• no segundo nó, gerar o citado código de serviço usando ainformação adicional recebida, a primeira identidade de usuário e o segredobásico.
2. Método de acordo com a reivindicação 1 ou 2, caracterizadopelo fato de que o citado primeiro nó e um nó de serviço e o citado segundonó é um cliente.
3. Método de acordo com a reivindicação 2, caracterizado pelofato de que o citado cliente é um terminal de cliente de uma rede 3 Gempregando uma Arquitetura Bootstrapping Genérica, citado nó de serviçocompreendendo uma Função de Aplicação de Rede e citada função degeração de código compreendendo uma Função de Servidor de Bootstrapping.
4. Método de acordo com a reivindicação 3, caracterizado pelofato de que a citada função de geração de código compreende adicionalmenteum Sistema de Assinante Doméstico ou um Registro de LocalizaçãoDoméstica/Centro de Autenticação, citado segredo básico sendo conhecida ouacessível pelo Sistema de Assinante Doméstico ou HE/Centro de Autenticação.
5. Método de acordo com a reivindicação 3 ou 4, caracterizadopelo fato de que a citada etapa de gerar um código de serviço na função degeração de código compreende as etapas de:• gerar material de código KS usando a citado segredobásico; e• gerar o código de serviço usando o citado material decódigo KS, a identidade do nó de serviço e a citada informação adicional.
6. Método de acordo com a reivindicação 3, caracterizado pelofato de que citada etapa de gerar citado código de serviço no clientecompreende:• gerar material de código KS usando a citado segredobásico; e• gerar o código de serviço usando citado material de códigoKS, e citada informação adicional.
7. Método de acordo com a reivindicação 6, caracterizado pelofato de que a citado segredo básico é armazenada em um ISIM/USIM docliente, e citada etapa de gerar o material de código KS é efetuada dentro doISIM/USIM.
8. Método de acordo com qualquer uma das reivindicaçõesprecedentes, caracterizado pelo fato da citada etapa de gerar um código deserviço na função de geração de código utilizar valores diferentes daquelesenviados ao cliente pelo nó de serviço.
9. Método de acordo com a reivindicação 8, caracterizado pelofato de que pelo menos certos daqueles outros valores são obtidos pelo clientea partir da função de geração de código.
10. Método de acordo com qualquer uma das reivindicaçõesprecedentes, caracterizado pelo fato de que a citada informação adicionalcompreende um ou mais dentre:um identificador de transação; eum valor de autenticação de rede.
11. Método de acordo com qualquer uma das reivindicações 1a 9, caracterizado pelo fato de que a citada informação adicional compreendeum identificador de transação no formato de uma ΝΑΙ, o identificador detransação compreendendo um valor randômico codificado gerado pela funçãode geração de código, o valor randômico codificado sendo usado para gerar ocódigo de serviço.
12. Método de acordo com a reivindicação 2, caracterizadopelo fato de que a citada informação adicional compreende um identificadorde transação no formato de uma ΝΑΙ, o identificador de transaçãocompreendendo um indicador para um valor randômico gerado e armazenadona função de geração de código, o valor randômico sendo usado para gerar ocódigo de serviço, o método compreendendo enviar uma requisição contendoo citado indicador, do cliente para a função de geração de código, e retornar ovalor randômico ao cliente, para habilitar o cliente a gerar o código deserviço.
13. Método de acordo com a reivindicação 2, caracterizadopelo fato de que a função de geração de código envia ao nó de serviço umvalor de autenticação de rede e o nó de serviço redireciona este valor aocliente, juntamente com a citada informação adicional, o cliente usando osegredo básico e o valor de autenticação para autenticar a função de geraçãode código.
14. Método de acordo com a reivindicação 2, e caracterizadopelo fato de compreender enviar uma requisição do cliente para a função degeração de código para um valor de autenticação, após o cliente ter recebido acitada informação adicional do nó de serviço, receber o valor de autenticaçãono cliente, e autorizar a requisição de associação de segurança recebida do nóde serviço, com base neste valor.
15. Método de acordo com a reivindicação 2, caracterizadopelo fato de que a citada informação adicional é redirecionada do nó de serviço para o cliente em uma mensagem contendo também dados de serviço,os dados de serviço sendo criptografados e/ou protegidos na integridade como código de serviço, onde o cliente pode decriptografar os dadoscriptografados, uma vez que tenha gerado o código de serviço.
16. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de que a citada etapa de gerar um códigode serviço na função de geração de código compreende usar a identidade dosegundo nó.
17. Método de acordo com qualquer uma das reivindicaçõesprecedentes, caracterizado pelo fato de que o citado código de serviço é um código de Diffie-Hellman para o segundo nó, o método compreendendoadicionalmente a etapa de prover ao primeiro nó um código de Diffie-Hellman para aquele primeiro nó, e enviar o código Diffie-Hellman para oprimeiro nó ao segundo nó, citada associação de segurança sendo estabelecidacom base nos dois códigos de Diffie-Hellman.
18. Método de acordo com a reivindicação 1, caracterizadopelo fato de que citados primeiro e segundo nós são primeiro e segundoclientes, respectivamente.
19. Método de acordo com a reivindicação 18, caracterizadopelo fato de que a citada função de geração de código compreende umservidor de código tendo uma relação de confiança com citado segundocliente, e citada requisição para geração e provisão de um código de serviço éenviada ao citado servidor de código via um segundo servidor de códigotendo uma relação de confiança com citado primeiro cliente.
20. Método de acordo com a reivindicação 19, e caracterizadopelo fato de compreender enviar, do citado primeiro nó para citado segundonó, um código de serviço obtido pelo citado primeiro nó, no primeiro esegundo nós, derivando um código de sessão usando ambos citados códigosde serviço.
21. Método de acordo com a reivindicação 18, caracterizadopelo fato de que citadas etapas de redirecionar citada informação adicional doprimeiro nó para o segundo nó, e gerar citado código de serviço no segundonó usando a informação adicional recebida e o segredo básico, fazem parte deum procedimento de troca de Diffie-Hellman.
22. Nó de serviço para fornecer um serviço de inserção a umcliente, via um enlace de comunicação segura, o nó de serviço caracterizadopelo fato de compreender:• meio para enviar uma requisição para geração e provisãode um código de serviço a uma função de geração de código, a requisiçãoidentificando o cliente e o nó de serviço;• meio para receber da função de geração de código umcódigo de serviço, juntamente com a citada informação adicional;• meio para redirecionar citada informação adicional aocliente; e· meio para criptografia e/ou informação de serviço deproteção de integridade, usando o código de serviço e para enviar ainformação criptografada e/ou informação protegida ao cliente.
23. Terminal de cliente para receber um serviço inseridofornecido por um nó de serviço, o terminal de cliente caracterizado pelo fatode compreender:• meio de memória para armazenar um segredo que écompartilhado com uma função de geração de código;• meio para receber informação de geração de código docitado nó de serviço;• meio para gerar um código de serviço usando o citadosegredo compartilhado e citada informação de geração de código; e• meio para usar o citado código de serviço paradecriptografar e/ou verificar a integridade das comunicações com o nó deserviço.
24. Terminal de acordo com a reivindicação 23 e caracterizadopelo fato de compreender meio para receber do nó de serviço um código deautenticação de mensagem, o terminal compreendendo meio para gerar umcódigo ou códigos de autenticação a partir de pelo menos uma parte dainformação de geração de código, e usando o(s) código(s) de autenticaçãopara autenticar o código de autenticação de mensagem.
25. Terminal de acordo com a reivindicação 23 e caracterizadopelo fato de que citado meio para gerar um código ou códigos de autenticaçãocompreende um USIM/ISIM.
26. Função de geração de código para uso ao estabelecer umaassociação de segurança entre um cliente e um nó de serviço para a finalidadede inserir informação do nó de serviço para o cliente, o servidor de códigocaracterizada pelo fato de compreender:• meio de memória para armazenar um segredo que écompartilhado com citado cliente;• meio para receber uma requisição para geração e provisãode um código de serviço a partir do citado nó de serviço, a requisiçãoidentificando o cliente e o nó de serviço; e• meio para gerar um código de serviço usando a identidadedo nó de serviço, o segredo básico, uma informação adicional, e para enviar ocódigo de serviço ao nó de serviço juntamente com citada informaçãoadicional.
27. Método para estabelecer uma associação de segurançaentre primeiro e segundo clientes, para a finalidade de inserir informação doprimeiro cliente para o segundo cliente, onde o primeiro e segundo clientespossuem relações de confiança com o primeiro e segundo servidores decódigo, respectivamente, e compartilham um segredo com seus respectivosservidores de código, o método caracterizado pelo fato de compreender:· enviar uma requisição para geração e provisão de umcódigo de serviço do primeiro cliente para o segundo servidor de código, viaprimeiro servidor de código, a requisição identificando o primeiro e segundonós;• gerar um código de serviço no segundo servidor de código,usando a identidade do primeiro nó, o segredo básico e informação adicional,e enviar o código de serviço ao primeiro nó juntamente com a citadainformação adicional;• enviar a citada informação adicional do primeiro nó, parao segundo nó; eno segundo nó, gerar o citado código de serviço usando a informaçãoadicional recebida, e o segredo básico.
28. Método para proteger um nó contra ataques de repetição, ométodo caracterizado pelo fato de compreender:gerar um código de serviço em uma função de servidor debootstrapping;prover o código de serviço a um primeiro nó juntamente com ainformação requerida para gerar o código de serviço;enviar uma mensagem de geração de código do primeiro nópara o segundo nó, a mensagem incluindo a citada informação, um valor deprevenção de repetição e um código de autenticação de mensagem calculadoatravés do corpo da mensagem, incluindo o valor de prevenção de repetição, ovalor de prevenção de repetição sendo incrementado ou decrementado paracada execução do procedimento;receber citada mensagem de geração de código no citadosegundo nó e armazenar o valor de prevenção de repetição contido nele; eno segundo nó, cada vez que é recebida uma mensagem degeração de código, verificar o citado código de autenticação de mensagem,determinar se o valor de prevenção de repetição contido na mensagem já foiarmazenado ou não no segundo nó e, caso afirmativo, rejeitar a mensagem.
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US11/248589 | 2005-10-13 | ||
| US11/248,589 US20070086590A1 (en) | 2005-10-13 | 2005-10-13 | Method and apparatus for establishing a security association |
| US11/305329 | 2005-12-19 | ||
| US11/305,329 US8122240B2 (en) | 2005-10-13 | 2005-12-19 | Method and apparatus for establishing a security association |
| PCT/EP2006/067225 WO2007042512A2 (en) | 2005-10-13 | 2006-10-10 | Method and apparatus for establishing a security association |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0617286A2 true BRPI0617286A2 (pt) | 2011-07-19 |
Family
ID=37309618
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0617286-5A BRPI0617286A2 (pt) | 2005-10-13 | 2006-10-10 | métodos para estabelecer uma associação de segurança entre um nó de serviço e um cliente, para estabelecer uma associação de segurança entre primeiro e segundo clientes, e para proteger um nó contra ataques de repetição, nó de serviço, terminal de cliente, e, função de geração de código |
Country Status (8)
| Country | Link |
|---|---|
| US (3) | US8122240B2 (pt) |
| EP (2) | EP1949651B1 (pt) |
| JP (2) | JP5118048B2 (pt) |
| BR (1) | BRPI0617286A2 (pt) |
| CA (1) | CA2624591C (pt) |
| ES (1) | ES2424474T3 (pt) |
| RU (1) | RU2406251C2 (pt) |
| WO (2) | WO2007042345A1 (pt) |
Families Citing this family (51)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070086590A1 (en) * | 2005-10-13 | 2007-04-19 | Rolf Blom | Method and apparatus for establishing a security association |
| DE602006009846D1 (de) * | 2006-01-24 | 2009-11-26 | British Telecomm Public Ltd Co | Verfahren und system zur rekursiven authentifikation in einem mobilnetz |
| EP1835688A1 (en) * | 2006-03-16 | 2007-09-19 | BRITISH TELECOMMUNICATIONS public limited company | SIM based authentication |
| US7936878B2 (en) * | 2006-04-10 | 2011-05-03 | Honeywell International Inc. | Secure wireless instrumentation network system |
| CN101102186B (zh) * | 2006-07-04 | 2012-01-04 | 华为技术有限公司 | 通用鉴权框架推送业务实现方法 |
| GB0705494D0 (en) * | 2007-03-22 | 2007-05-02 | Ibm | A method and system for a subscription to a symmetric key |
| WO2009004590A2 (en) * | 2007-07-03 | 2009-01-08 | Nokia Siemens Networks Oy | Method, apparatus, system and computer program for key parameter provisioning |
| CN101378591B (zh) * | 2007-08-31 | 2010-10-27 | 华为技术有限公司 | 终端移动时安全能力协商的方法、系统及装置 |
| CN101399767B (zh) | 2007-09-29 | 2011-04-20 | 华为技术有限公司 | 终端移动时安全能力协商的方法、系统及装置 |
| EP3079298B1 (en) * | 2007-11-30 | 2018-03-21 | Telefonaktiebolaget LM Ericsson (publ) | Key management for secure communication |
| WO2010003459A1 (en) * | 2008-07-09 | 2010-01-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Traffic control within a network architecture providing many-to-one transmission with denial-of service protection |
| US8429403B2 (en) * | 2008-08-12 | 2013-04-23 | Juniper Networks, Inc. | Systems and methods for provisioning network devices |
| WO2010027589A2 (en) * | 2008-08-25 | 2010-03-11 | Motorola, Inc. | Method for multi-factor assertion generation and usage |
| JP5468623B2 (ja) * | 2009-02-05 | 2014-04-09 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | ネットワークにおけるブートストラップ・メッセージを保護するための装置と方法 |
| MY157052A (en) | 2009-03-05 | 2016-04-15 | Interdigital Patent Holdings | Secure remote subscription management |
| US20120047262A1 (en) * | 2009-04-27 | 2012-02-23 | Koninklijke Kpn N.V. | Managing Undesired Service Requests in a Network |
| UA106642C2 (uk) | 2009-12-11 | 2014-09-25 | Нокіа Корпорейшн | Профіль засобу безпеки смарт-картки у сервері абонентських даних |
| EP2656648B1 (en) * | 2010-12-21 | 2018-05-09 | Koninklijke KPN N.V. | Operator-assisted key establishment |
| FR2973637A1 (fr) * | 2011-03-31 | 2012-10-05 | France Telecom | Mise en place d'une association de securite de type gba pour un terminal dans un reseau de telecommunications mobiles |
| US9331993B2 (en) * | 2011-06-16 | 2016-05-03 | Telefonaktiebolaget L M Ericsson (Publ) | Authentication server and communication device |
| US8914636B2 (en) * | 2011-06-28 | 2014-12-16 | Interdigital Patent Holdings, Inc. | Automated negotiation and selection of authentication protocols |
| CN102869015B (zh) * | 2011-07-04 | 2017-12-15 | 中兴通讯股份有限公司 | 一种mtc设备触发的方法和系统 |
| US8627076B2 (en) * | 2011-09-30 | 2014-01-07 | Avaya Inc. | System and method for facilitating communications based on trusted relationships |
| GB2500720A (en) * | 2012-03-30 | 2013-10-02 | Nec Corp | Providing security information to establish secure communications over a device-to-device (D2D) communication link |
| US20150074008A1 (en) * | 2012-04-20 | 2015-03-12 | Synabee, Inc | Secure identification system and method |
| EP2675106A1 (en) * | 2012-04-23 | 2013-12-18 | ABB Technology AG | Industrial automation and control device user access |
| 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 |
| WO2014037277A1 (en) * | 2012-09-06 | 2014-03-13 | Koninklijke Kpn N.V. | Establishing a device-to-device communication session |
| CN104885492B (zh) | 2012-10-29 | 2020-03-17 | 皇家Kpn公司 | 侦听装置对装置通信 |
| CN105075182B (zh) * | 2013-02-07 | 2019-01-04 | 诺基亚技术有限公司 | 用于通过提供安全性信息来允许合法拦截的方法 |
| EP2785011A1 (en) * | 2013-03-27 | 2014-10-01 | Gemalto SA | Method to establish a secure voice communication using generic bootstrapping architecture |
| GB2518254B (en) * | 2013-09-13 | 2020-12-16 | Vodafone Ip Licensing Ltd | Communicating with a machine to machine device |
| US9602508B1 (en) * | 2013-12-26 | 2017-03-21 | Lookout, Inc. | System and method for performing an action based upon two-party authorization |
| US10263980B2 (en) | 2014-03-06 | 2019-04-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Network node, device and methods for providing an authentication module |
| WO2016116128A1 (en) * | 2015-01-19 | 2016-07-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for direct communication key establishment |
| JP2018507646A (ja) | 2015-02-27 | 2018-03-15 | テレフオンアクチーボラゲット エルエム エリクソン（パブル） | 通信デバイスとネットワークデバイスとの間の通信におけるセキュリティ構成 |
| GB201506045D0 (en) * | 2015-04-09 | 2015-05-27 | Vodafone Ip Licensing Ltd | SIM security |
| WO2016165737A1 (en) * | 2015-04-13 | 2016-10-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Wireless communications |
| WO2017015156A1 (en) * | 2015-07-17 | 2017-01-26 | Robert Bosch Gmbh | Method and system for shared key and message authentication over an insecure shared communication medium |
| CN106797562B (zh) * | 2015-08-13 | 2019-04-26 | 华为技术有限公司 | 一种消息保护的方法、相关设备以及系统 |
| CN106487501B (zh) * | 2015-08-27 | 2020-12-08 | 华为技术有限公司 | 密钥分发和接收方法、密钥管理中心、第一和第二网元 |
| CN106714152B (zh) | 2015-11-13 | 2021-04-09 | 华为技术有限公司 | 密钥分发和接收方法、第一密钥管理中心和第一网元 |
| US20190020643A1 (en) * | 2016-02-12 | 2019-01-17 | Telefonaktiebolaget Lm Ericsson (Publ) | Securing an interface and a process for establishing a secure communication link |
| JP7030778B2 (ja) * | 2016-07-28 | 2022-03-07 | コーニンクレッカ フィリップス エヌ ヴェ | データの複製先であるネットワークノードの識別 |
| US10225359B2 (en) * | 2016-09-22 | 2019-03-05 | International Business Machines Corporation | Push notifications from multiple tenant servers |
| US10728756B2 (en) * | 2016-09-23 | 2020-07-28 | Qualcomm Incorporated | Access stratum security for efficient packet processing |
| US11538031B2 (en) | 2017-03-31 | 2022-12-27 | Vijay Madisetti | Method and system for identity and access management for blockchain interoperability |
| CN108200085B (zh) * | 2018-01-31 | 2019-03-08 | 北京深思数盾科技股份有限公司 | 一种数据分发、转发方法及装置 |
| EP3726873A1 (en) * | 2019-04-18 | 2020-10-21 | Thales Dis France SA | Method to authenticate a user at a service provider |
| CN110492988B (zh) * | 2019-07-03 | 2020-07-21 | 特斯联（北京）科技有限公司 | 一种多路并行复用的大数据系统及其处理方法 |
| CN113570467B (zh) * | 2021-06-09 | 2024-04-26 | 上海淇玥信息技术有限公司 | 资源特享信息推送方法、装置及电子设备 |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2514593B1 (fr) | 1981-10-09 | 1986-12-26 | Bull Sa | Procede et dispositif pour authentifier la signature d'un message signe |
| JPS6126111A (ja) | 1984-07-16 | 1986-02-05 | Shin Meiwa Ind Co Ltd | 産業用ロボツト |
| DE3789769T2 (de) * | 1986-07-31 | 1994-08-11 | Advance Kk | System zur erzeugung eines gemeinsamen geheimübertragungsschlüssels und kommunikationssystem unter verwendung des gemeinsamen geheimübertragungsschlüssels. |
| JP2000511382A (ja) * | 1996-06-05 | 2000-08-29 | シーメンス アクチエンゲゼルシヤフト | 第１のコンピュータユニットと第２のコンピュータユニットの間の暗号化キー管理方法 |
| JPH10301492A (ja) * | 1997-04-23 | 1998-11-13 | Sony Corp | 暗号化装置および方法、復号装置および方法、並びに情報処理装置および方法 |
| US7389412B2 (en) | 2001-08-10 | 2008-06-17 | Interactive Technology Limited Of Hk | System and method for secure network roaming |
| US8140845B2 (en) * | 2001-09-13 | 2012-03-20 | Alcatel Lucent | Scheme for authentication and dynamic key exchange |
| US8117450B2 (en) * | 2001-10-11 | 2012-02-14 | Hewlett-Packard Development Company, L.P. | System and method for secure data transmission |
| JP3989364B2 (ja) * | 2002-11-28 | 2007-10-10 | 株式会社エヌ・ティ・ティ・ドコモ | データ復号端末、秘密鍵提供端末、データ暗号化端末、暗号データ復号システム、及び復号鍵更新方法 |
| KR100610317B1 (ko) | 2004-01-06 | 2006-08-09 | 삼성전자주식회사 | 홈 네트워크를 구성하는 기기들에 대한 인증 장치 및 방법 |
| US7769995B2 (en) * | 2004-01-07 | 2010-08-03 | Microsoft Corporation | System and method for providing secure network access |
| DK1714418T3 (en) * | 2004-02-11 | 2017-04-24 | ERICSSON TELEFON AB L M (publ) | KEY MANAGEMENT FOR NETWORK ELEMENTS |
| US7747862B2 (en) * | 2004-06-28 | 2010-06-29 | Intel Corporation | Method and apparatus to authenticate base and subscriber stations and secure sessions for broadband wireless networks |
| US7624269B2 (en) * | 2004-07-09 | 2009-11-24 | Voltage Security, Inc. | Secure messaging system with derived keys |
| JP2006108903A (ja) * | 2004-10-01 | 2006-04-20 | Hiromi Fukaya | 暗号化データ配布方法、暗号化装置、復号化装置、暗号化プログラム及び復号化プログラム |
| US8726023B2 (en) * | 2005-02-03 | 2014-05-13 | Nokia Corporation | Authentication using GAA functionality for unidirectional network connections |
| MX2007009705A (es) | 2005-02-11 | 2007-10-04 | Nokia Corp | Metodo y aparato para proporcionar procedimientos de carga inicial en una red de comunicacion. |
| 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 |
-
2005
- 2005-12-19 US US11/305,329 patent/US8122240B2/en active Active
-
2006
- 2006-08-25 WO PCT/EP2006/065676 patent/WO2007042345A1/en not_active Ceased
- 2006-10-10 CA CA2624591A patent/CA2624591C/en active Active
- 2006-10-10 JP JP2008535012A patent/JP5118048B2/ja active Active
- 2006-10-10 WO PCT/EP2006/067225 patent/WO2007042512A2/en not_active Ceased
- 2006-10-10 BR BRPI0617286-5A patent/BRPI0617286A2/pt not_active Application Discontinuation
- 2006-10-10 RU RU2008118495/09A patent/RU2406251C2/ru active
- 2006-10-10 ES ES11184132T patent/ES2424474T3/es active Active
- 2006-10-10 EP EP06807110A patent/EP1949651B1/en active Active
- 2006-10-10 EP EP11184132.6A patent/EP2437469B1/en active Active
-
2012
- 2012-01-11 US US13/348,343 patent/US8868912B2/en not_active Expired - Lifetime
- 2012-09-21 JP JP2012208854A patent/JP5470429B2/ja active Active
-
2014
- 2014-10-10 US US14/512,239 patent/US20150143126A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US8122240B2 (en) | 2012-02-21 |
| EP1949651B1 (en) | 2012-07-04 |
| US20120166802A1 (en) | 2012-06-28 |
| RU2406251C2 (ru) | 2010-12-10 |
| JP5470429B2 (ja) | 2014-04-16 |
| ES2424474T3 (es) | 2013-10-02 |
| CA2624591C (en) | 2015-05-19 |
| US20150143126A1 (en) | 2015-05-21 |
| JP2009512296A (ja) | 2009-03-19 |
| EP2437469A1 (en) | 2012-04-04 |
| JP2013034220A (ja) | 2013-02-14 |
| EP1949651A2 (en) | 2008-07-30 |
| WO2007042512A3 (en) | 2007-07-26 |
| WO2007042345A1 (en) | 2007-04-19 |
| US8868912B2 (en) | 2014-10-21 |
| JP5118048B2 (ja) | 2013-01-16 |
| US20070086591A1 (en) | 2007-04-19 |
| CA2624591A1 (en) | 2007-04-19 |
| WO2007042512A2 (en) | 2007-04-19 |
| EP2437469B1 (en) | 2013-05-22 |
| RU2008118495A (ru) | 2009-11-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0617286A2 (pt) | métodos para estabelecer uma associação de segurança entre um nó de serviço e um cliente, para estabelecer uma associação de segurança entre primeiro e segundo clientes, e para proteger um nó contra ataques de repetição, nó de serviço, terminal de cliente, e, função de geração de código | |
| US8144874B2 (en) | Method for obtaining key for use in secure communications over a network and apparatus for providing same | |
| US10284555B2 (en) | User equipment credential system | |
| US8144875B2 (en) | Method and system for establishing real-time authenticated and secured communications channels in a public network | |
| US20070086590A1 (en) | Method and apparatus for establishing a security association | |
| CN115865520A (zh) | 移动云服务环境中具有隐私保护的认证和访问控制方法 | |
| Toorani | Cryptanalysis of a new protocol of wide use for email with perfect forward secrecy | |
| US20240340164A1 (en) | Establishment of forward secrecy during digest authentication | |
| Vyas et al. | An Analysis Of Session Key Exchange Protocols | |
| Zheng et al. | An improved authentication and key agreement protocol of 3G | |
| Wan et al. | Access control protocols with two-layer architecture for wireless networks | |
| Garg et al. | Design of secure authentication protocol in SOCKS V5 for VPN using mobile phone | |
| Vyas et al. | Analysis of Key Exchange Protocols using Session Keys |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B15K | Others concerning applications: alteration of classification |
Ipc: H04W 12/04 (2009.01), H04L 9/08 (2006.01), H04L 9/ |
|
| B15K | Others concerning applications: alteration of classification |
Free format text: AS CLASSIFICACOES ANTERIORES ERAM: H04W 12/04 , H04L 9/08 , H04L 9/32 , H04L 29/06 , H04L 29/08 , H04W 84/04 Ipc: H04W 12/04 (2009.01), H04L 9/08 (1990.01), H04L 9/ |
|
| B06T | Formal requirements before examination [chapter 6.20 patent gazette] | ||
| B06F | Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette] | ||
| B07A | Application suspended after technical examination (opinion) [chapter 7.1 patent gazette] | ||
| B09B | Patent application refused [chapter 9.2 patent gazette] | ||
| B12B | Appeal against refusal [chapter 12.2 patent gazette] |