BR112017020675B1 - Acordo de autenticação e chave com sigilo perfeito de emissão - Google Patents

Acordo de autenticação e chave com sigilo perfeito de emissão Download PDF

Info

Publication number
BR112017020675B1
BR112017020675B1 BR112017020675-7A BR112017020675A BR112017020675B1 BR 112017020675 B1 BR112017020675 B1 BR 112017020675B1 BR 112017020675 A BR112017020675 A BR 112017020675A BR 112017020675 B1 BR112017020675 B1 BR 112017020675B1
Authority
BR
Brazil
Prior art keywords
network
authentication
pfs
integrity
value
Prior art date
Application number
BR112017020675-7A
Other languages
English (en)
Other versions
BR112017020675A2 (pt
Inventor
Anand Palanigounder
Original Assignee
Qualcomm Incorporated
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 Qualcomm Incorporated filed Critical Qualcomm Incorporated
Publication of BR112017020675A2 publication Critical patent/BR112017020675A2/pt
Publication of BR112017020675B1 publication Critical patent/BR112017020675B1/pt

Links

Classifications

    • 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/067—Network architectures or network communication protocols for network security for supporting key management in a packet data network using one-time keys
    • 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
    • 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
    • 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/085—Secret sharing or secret splitting, e.g. threshold schemes
    • 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/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • 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/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • 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/3236—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 cryptographic hash functions
    • H04L9/3242—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 cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • 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/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • 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
    • 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/0433—Key management protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • 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/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Power Engineering (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Algebra (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)

Abstract

ACORDO DE AUTENTICAÇÃO E CHAVE COM SIGILO PERFEITO DE EMISSÃO. São revelados sistemas e métodos para proporcionar acordo de autenticação e chave (AKA) com sigilo perfeito de emissão (PFS). Em uma modalidade, uma rede de acordo com a revelação pode receber uma solicitação de anexação a partir de um UE, proporcionar uma solicitação de autenticação incluindo um indicador de suporte de rede para um recurso de rede, receber um token de autenticação a partir do recurso de rede, de tal modo que o token de autenticação inclua uma indicação de que a rede suporta PFS, proporcionar o token de autenticação ao UE, receber uma resposta de autenticação incluindo um valor de chave cúbica de UE, obter um valor de chave pública de rede e um valor de chave privada de rede, determinar um valor de chave compartilhada no valor de chave privada de rede e no valor de chave pública de UE, ligar o valor de chave compartilhada com um valor de chave de sessão para criar um valor de chave compartilhada ligado, e usar o valor de chave compartilhada ligado para proteger tráfego de rede subsequente.

Description

REFERÊNCIA CRUZADA A PEDIDOS RELACIONADOS
[0001] Esse pedido reivindica o benefício do Pedido Provisional dos Estados Unidos N° 62/140.331, intitulado “Atthentication and Key Agreement with Perfect Forward Secrecy”, depositado em 30 de março de 2015, Pedido Provisional dos Estados Unidos N° 62/140.426, intitulado “Atthentication and Key Agreement with Perfect Forward Secrecy”, depositado em 30 de março de 2015, e Pedido de Utilidade dos Estados Unidos 14/825.988, intitulado “Atthentication and Key Agreement with Perfect Forward Secrecy”, depositado em 13 de agosto de 2015, os quais individualmente são atribuídos ao cessionário presente e cujos conteúdos são aqui incorporados integralmente mediante referência.
ANTECEDENTES
[0002] Em geral, um sistema de comunicação sem fio pode facilitar os procedimentos de autenticação entre uma rede e um dispositivo tentando acessar a rede. Diferentes redes podem ter diferentes procedimentos de autenticação. Um dispositivo pode incluir credenciais de segurança usadas para autenticar o dispositivo antes de proporcionar acesso à rede. Em alguns sistemas, comunicações confidenciais podem utilizar credenciais de segurança que são armazenadas em um módulo no dispositivo, e que acoplam o dispositivo a uma rede hospedeira. Por exemplo, o protocolo de Acordo de Autenticação e Chave (AKA) amplamente utilizado se baseia em uma chave de raiz simétrica (K) que é compartilhada de forma segura entre o dispositivo (por exemplo, um módulo de identidade de assinante universal (USIM)) e a rede (por exemplo, Servidor de assinante doméstico (HSS)). Outras redes podem ser capazes de proporcionar outros tipos de garantias criptográficas para realizar trocas seguras.
[0003] Nas redes sem fio existentes que utilizam AKA, há um risco de que se uma chave de raiz de longo prazo (por exemplo, K) for comprometida, a confidencialidade de todas as comunicações anteriores pode ser comprometida. Isto é, um atacante pode capturar as comunicações codificadas anteriores e decodificar as mesmas quando a chave de raiz de longo prazo (K) é comprometida. Há também um risco de que as redes que são capazes de proporcionar diferentes níveis de garantias criptográficas (por exemplo, fracas e fortes), podem ser vulneráveis a um ataque de intruso de tal modo que uma garantia criptográfica forte pode ser reduzida a uma solução mais fraca.
BREVE SUMÁRIO
[0004] O que se segue resume alguns aspectos da presente revelação para proporcionar um entendimento básico da tecnologia discutida. Esse sumário não é uma visão geral extensiva de todas as características contempladas da revelação, e também não pretende identificar elementos essenciais ou cruciais de todos os aspectos da revelação nem delinear o escopo de qualquer um ou de todos os aspectos da revelação. Seu único propósito é o de apresentar alguns conceitos de um ou mais aspectos da revelação de forma reduzida como um prelúdio para a descrição mais detalhada que é apresentada posteriormente.
[0005] Um exemplo de um método para proporcionar um protocolo de acordo de autenticação e chave com sigilo perfeito de emissão (PFS) entre um equipamento de usuário e uma rede de acordo com a revelação inclui gerar, com o equipamento de usuário, uma solicitação de anexação, receber com o equipamento de usuário um token de autenticação, de tal modo que o token de autenticação inclua uma indicação de suporte PFS pela rede, determinar com o equipamento de usuário que a rede suporta PFS, proporcionar com o equipamento de usuário um valor de chave pública de UE para a rede, receber com o equipamento de usuário um valor de chave pública de rede a partir da rede, determinar com o equipamento de usuário um valor de chave compartilhada com base no valor de chave pública de rede e um valor de chave privada de UE, ligar com o equipamento de usuário, o valor de chave compartilhada com um valor de chave de sessão para criar um valor de chave compartilhada aglutinado, e utilizar com o equipamento de usuário, o valor de chave compartilhada aglutinado para proteger tráfego de rede subsequente.
[0006] As implementações de tal método podem incluir uma ou mais das seguintes características. A solicitação de anexação pode incluir uma indicação de que o equipamento de usuário suporta PFS. A geração na solicitação de anexação pode incluir um ou mais de uma solicitação de serviço, solicitação de área de rastreamento ou solicitação de atualização de localização. A ligação do valor de chave compartilhada com o valor de chave de sessão pode incluir a determinação de um hash criptográfico do valor de chave compartilhada e o valor de chave de sessão. O valor de chave de sessão pode ser KASME, chave de codificação (CK) ou chave de integridade (IK). A provisão do valor de chave pública de UE para a rede pode incluir a geração de um par efêmero Diffie-Hellman utilizando criptografia de curva elíptica, ou utilizando aritmética de campo finito. A determinação de que a rede não suporta PFS e a negativa em conexão com a rede. O token de autenticação pode incluir um valor de bit de campo de gerenciamento de autenticação (AMF) estabelecido para 1 para indicar que a rede suporta PFS.
[0007] Um aparelho exemplar para proporcionar um protocolo de acordo de autenticação e chave com sigilo perfeito de emissão (PFS) entre o equipamento de usuário (UE) e uma rede de acordo com a revelação inclui uma memória, ao menos um processador acoplado de forma operativa com a memória e configurado para receber uma solicitação de anexação a partir de um UE, proporcionar uma solicitação de autenticação incluindo um indicador de suporte de rede para um recurso de rede, receber um token de autenticação a partir do recurso de rede, de tal modo que o token de autenticação inclua uma indicação de que a rede suporta PFS, proporcionar o token de autenticação ao UE, receber uma resposta de autenticação incluindo um valor de chave pública de UE, negar a solicitação de anexação se a resposta de autenticação não for uma resposta esperada, se a resposta de autenticação for a resposta esperada, então obter um valor de chave pública de rede e um valor de chave privada de rede, determinar um valor de chave compartilhada com base no valor de chave privada de rede e no valor de chave pública de UE, ligar o valor de chave compartilhada com um valor de chave de sessão para criar um valor vinculado de chave compartilhada, e utilizar o valor vinculado de chave compartilhada para proteger o tráfego de rede subsequente.
[0008] Implementações de tal aparelho podem incluir uma ou mais das seguintes características. O token de autenticação pode ser protegido em termos de integridade entre o UE e o recurso de rede. Uma solicitação de anexação recebida a partir do UE pode incluir o recebimento de uma dentre uma solicitação de serviço, solicitação de área de rastreamento ou solicitação de atualização de localização em vez de uma solicitação de anexação. Um hash criptográfico do valor de chave compartilhada e o valor de chave de sessão podem ser determinados. O valor de chave de sessão pode ser pelo menos um dentre KASME, chave de codificação (CK), ou chave de integridade (IK). O valor de chave compartilhada pode ser determinado por um dentre criptologia de curva elíptica ou aritmética de campo finito. A solicitação de anexação pode incluir uma indicação de que o UE suporta PFS. O token de autenticação pode incluir um valor de bit de campo de gerenciamento de autenticação (AMF) ajustado para 1 para indicar que a rede suporta PFS.
[0009] Um exemplo de um método para prevenir um ataque de tentativa em um sistema com um protocolo de segurança robusto de acordo com a revelação inclui receber uma solicitação de anexação a partir de um equipamento de usuário, enviar uma solicitação de autenticação para uma rede doméstica, e de tal modo que a solicitação de autenticação inclua uma indicação de que a rede suporta o protocolo de segurança robusto, receber um token de integridade protegida a partir da rede doméstica, e de tal modo que o token de integridade protegida inclui pelo menos um bit configurado para indicar que a rede suporta o protocolo de segurança robusto, e enviar o token de integridade protegida para o equipamento de usuário.
[0010] Implementações de tal método podem incluir uma ou mais das seguintes características. A solicitação de anexação pode incluir uma indicação de que o equipamento de usuário suporta o protocolo de segurança robusto. O protocolo de segurança robusto pode ser um protocolo de acordo de autenticação e chave com sigilo perfeito de emissão. A solicitação de autenticação pode ser uma mensagem de protocolo de diâmetro com Pares de Valores de Atributo (AVP) como elementos de informação para indicar que a rede suporta o protocolo de segurança robusto. O token de integridade protegida pode ser incluído em um vetor de autenticação recebido a partir da rede doméstica. O pelo menos um bit pode ser incluído em um Campo de Gerenciamento de Autenticação (AMF).
[0011] Um meio de armazenamento legível por processador não transitório, exemplar compreendendo instruções para prevenir um ataque de tentativa em um sistema com um protocolo de segurança robusto de acordo com a revelação inclui código para receber uma solicitação de ataque a partir de um equipamento de usuário, código para enviar uma solicitação de autenticação para uma rede doméstica, e de tal modo que a solicitação de autenticação inclua uma indicação de que uma rede suporta o protocolo de segurança robusto, código para receber um token de integridade protegida a partir da rede doméstica, e de tal modo que o token de integridade protegida inclua pelo menos um bit configurado para indicar que a rede suporta o protocolo de segurança robusto, e código para enviar o token de integridade protegida para o equipamento de usuário.
[0012] Implementações de tal meio de armazenamento legível por processar, não transitório podem incluir uma ou mais das seguintes limitações: a solicitação de anexação pode incluir uma indicação de que o equipamento de usuário suporta o protocolo de segurança robusto. O protocolo de segurança robusto pode ser um protocolo de acordo de autenticação e chave com sigilo perfeito de emissão. A solicitação de autenticação pode ser uma mensagem de protocolo de diâmetro com Pares de Valores de Atributo (AVP) como elementos de informação para indicar que a rede suporta o protocolo de segurança robusto. O token de integridade protegida pode ser incluído em um vetor de autenticação recebido a partir da rede doméstica. O pelo menos um bit pode ser incluído em um Campo de Gerenciamento de Autenticação (AMF).
[0013] Itens e/ou técnicas aqui descritos podem proporcionar uma ou mais das seguintes capacidades, assim como outras capacidades não mencionadas. Um dispositivo móvel pode proporcionar uma indicação para uma rede para indicar que ele suporta sigilo perfeito de emissão. Uma rede pode proporcionar a uma rede doméstica um elemento de informação para indicar que a rede suporta sigilo perfeito de emissão. Um token de integridade protegida pode ser gerado pela rede doméstica e enviado para o dispositivo móvel. O token de integridade protegida pode incluir um elemento de informação para indicar que a rede suporta sigilo perfeito de emissão. O dispositivo móvel e a rede podem participar em uma troca Diffie-Hellman para gerar uma chave compartilhada. A chave compartilhada pode ser usada para ligação a uma chave de sessão. A chave de sessão vinculada pode ser usada para proteger tráfego de rede subsequente. Um protocolo de acordo de autenticação e chave com sigilo perfeito de emissão pode ser realizado. O potencial para um ataque de tentativa pode ser significativamente reduzido por intermédio do uso de token de integridade protegida incorporando sigilo perfeito de emissão de rede. Outras capacidades podem ser proporcionadas e nem toda implementação de acordo com a revelação deve proporcionar qualquer capacidade específica, sem falar todas as capacidades discutidas. Adicionalmente, pode ser possível que um efeito assinalado acima seja obtido mediante meios diferentes daqueles assinalados, e um item/técnica assinalado pode não necessariamente produzir o efeito assinalado.
[0014] Outros aspectos, características e modalidades da presente invenção se tornarão evidentes àqueles de conhecimento comum na arte, a partir da análise da descrição seguinte de modalidades específicas, exemplares da presente invenção em conjunto com as figuras anexas. Embora as características da presente invenção possam ser discutidas em relação a certas modalidades e figuras abaixo, todas as modalidades da presente invenção podem incluir uma ou mais das características vantajosas aqui discutidas. Em outras palavras, embora uma ou mais modalidades possam ser discutidas como tendo certas características vantajosas, uma ou mais de tais características também podem ser usadas de acordo com as várias modalidades da invenção discutidas aqui. De forma semelhante, embora modalidades exemplares possam ser discutidas abaixo como modalidades de dispositivo, sistema ou método, deve ser entendido que tais modalidades exemplares podem ser implementadas em vários dispositivos, sistemas e métodos. BREVE DESCRIÇÃO DOS DESENHOS A Figura 1 é um diagrama de blocos de componentes de uma modalidade de um dispositivo móvel de acordo com alguns aspectos/modalidades. A Figura 2 é um diagrama de blocos de um sistema de comunicação sem fio exemplar de acordo com alguns aspectos/modalidades. A Figura 3 é um diagrama de blocos de um exemplo de um sistema de computador para uso no sistema de comunicação sem fio da Figura 2 de acordo com alguns aspectos/modalidades. A Figura 4 é um diagrama de fluxo de chamada da técnica anterior de um procedimento de autenticação 3GPP de evolução de longo prazo (LTE). A Figura 5 é um diagrama de fluxo de chamada de um procedimento de autenticação exemplar com uma propriedade de sigilo perfeito de emissão (PFS) de acordo com alguns aspectos/modalidades. A Figura 6 é um diagrama de fluxo de chamada de outro procedimento de autenticação exemplar com uma propriedade de sigilo perfeito de emissão (PFS). A Figura 7 é um diagrama de fluxo de blocos de um processo de proporcionar comunicações seguras com um dispositivo móvel de acordo com alguns aspectos/modalidades. A Figura 8 é um diagrama de fluxo de blocos de um processo de proporcionar comunicações seguras com um servidor de rede de acordo com alguns aspectos/modalidades. A Figura 9 é um diagrama de fluxo de blocos de um processo para prevenir um ataque de tentativa em um sistema com um protocolo de segurança robusto de acordo com alguns aspectos/modalidades.
DESCRIÇÃO DETALHADA
[0015] São discutidas técnicas para fornecer acordo de autenticação e chave (AKA) com sigilo perfeito de emissão (PFS). Tal como aqui utilizado, o termo sigilo perfeito de emissão refere-se à definição de criptografia de uma propriedade de protocolos de acordo-chave para ajudar a garantir que uma chave de sessão derivada de um conjunto de chaves de longo prazo não seja comprometida se uma das chaves de longo prazo for comprometida no futuro. O termo perfeito, tal como aqui utilizado, não significa algo que esteja completamente livre de falhas ou defeitos, ou tão perto de tal condição quanto possível. AKA é um protocolo amplamente utilizado de acordo de autenticação e chave em redes celulares de modem (por exemplo, GSM, UMTS, LTE, eHRPD). AKA é especificado no 3GPP TS 33.102. A segurança da AKA geralmente depende de uma chave de raiz simétrica (K) que seja compartilhada de forma segura entre o UE (por exemplo, normalmente armazenado no USIM) e um servidor na rede local (por exemplo, o Servidor de assinante doméstico (HSS)). O AKA não oferece Privilégio de Avanço Perfeito (PFS). Ou seja, AKA não fornece uma chave de sessão que não pode ser comprometida se a chave de longo prazo (por exemplo, K) for comprometida no futuro. Como será discutido, em uma modalidade, a segurança potencial As deficiências de AKA podem ser mitigadas com propriedades PFS. Por exemplo, uma troca Efêmera de Diffie-Hellman (DHE) pode ocorrer entre um dispositivo móvel e um servidor de rede. O dispositivo móvel e um servidor de rede podem determinar cada valor de chave particular individual e valores de chave pública. As chaves públicas podem ser trocadas e combinadas com as respectivas chaves privadas para gerar uma chave compartilhada. A chave compartilhada resultante pode ser vinculada a uma chave de base em um vetor de autenticação (por exemplo, KASME) e usada para proteger as comunicações na rede. Os elementos de informação de autenticação protegidos podem ser usados para garantir que o dispositivo móvel e o servidor de rede suportem PFS. Os bits de autenticação protegidos podem impedir ataques de lance (por exemplo, ataques do homem no meio).
[0016] Referindo-se à figura 1, é ilustrado um dispositivo móvel 100 para o qual várias técnicas aqui podem ser utilizadas. O dispositivo móvel 100 é um equipamento de usuário (UE) e pode incluir ou implementar a funcionalidade de vários dispositivos de comunicação móvel e/ou informática; Os exemplos incluem, mas não estão limitados, assistentes digitais pessoais (PDAs), smartphones, dispositivos de computação, como laptops, desktops ou tablets, sistemas de computação automóvel, etc., atualizados ou desenvolvidos no futuro.
[0017] O dispositivo móvel 100 inclui um processador 111 (ou núcleo do processador) e a memória 140. O dispositivo móvel pode opcionalmente incluir um ambiente confiável operacionalmente conectado à memória 140 pelo barramento público 101 ou um barramento privado (não mostrado). O dispositivo móvel 100 pode também incluir uma interface de comunicação 120 e um transceptor sem fio 121 configurado para enviar e receber sinais sem fio 123 através de uma antena sem fio 122 através de uma rede sem fio. O transceptor sem fio 121 está vinculado a um barramento 101. Aqui, é ilustrado o dispositivo móvel 100 como tendo um único transceptor sem fio 121. No entanto, um dispositivo móvel 100 pode, alternativamente, ter vários dispositivos sem fio transceptores 121 e antenas sem fio 122 para suportar múltiplos padrões de comunicação como WiFi, CDMA, Wideband CDMA (WCDMA), Long Term Evolution (LTE), tecnologia de comunicação sem fio BLUETOOTH de curto alcance, etc.
[0018] A interface de comunicação 120 e/ou o transceptor sem fio 121 pode suportar a operação em vários suportes (sinais de forma de onda de diferentes freqüências). Os transmissores de várias transportadoras podem transmitir sinais modulados simultaneamente nas várias operadoras. Cada sinal modulado pode ser um sinal de Acesso Múltiplo de Divisão de Código (CDMA), um sinal de Acesso Múltiplo de Divisão de Tempo (TDMA), um sinal de Acesso Múltiplo de Divisão de Freqüência Ortogonal (OFDMA), um sinal de Acesso Múltiplo de Divisão de Freqüência de Via Única (SC-FDMA), etc. Cada sinal modulado pode ser enviado em um transportador diferente e pode conter informações piloto, sobrecarga, dados, etc.
[0019] O dispositivo móvel 100 também pode incluir uma interface de usuário 150 (por exemplo, exibição, GUI) e um receptor SPS 155 que recebe sinais de sistema de posicionamento por satélite (SPS) 159 (por exemplo, de satélites SPS) por meio de uma antena SPS 158. O receptor SPS 155 pode se comunicar com um único sistema de satélite de navegação global (GNSS); ou múltiplos desses sistemas. Um GNSS pode incluir, mas não está limitado a, Sistema de Posicionamento Global (GPS), Galileo, Glonass, Beidou (Compass), etc. Os satélites SPS também são chamados de satélites, veículos espaciais (SVs), etc. O receptor SPS 155 processa, no todo ou em parte, os sinais SPS 159 e usa esses sinais SPS 159 para determinar a localização do dispositivo móvel 100. O processador 111, a memória 140, o DSP 112 e/ou o (s) processador (es) especializado (s) (não mostrado) podem também ser utilizado para processar os sinais SPS 159, no todo ou em parte, e/ou para calcular a localização do dispositivo móvel 100, em conjunto com o receptor SPS 155. O armazenamento de informações dos sinais SPS 159 ou de outros sinais de localização é realizado usando uma memória 140 ou registros (não mostrados). Enquanto apenas um processador 111, um DSP 112 e uma memória 140 são mostrados na figura 1, mais do que um de qualquer, um par ou todos esses componentes poderiam ser usados pelo dispositivo móvel 100. O processador 111 e o DSP 112 associados ao dispositivo móvel 100 estão conectados ao barramento 101.
[0020] A memória 140 pode incluir um meio de armazenamento (ou mídia) legível por computador não transitório que armazena funções como uma ou mais instruções ou código. Os meios que podem constituir a memória 140 incluem, mas não estão limitados a, RAM, ROM, FLASH, unidades de disco, etc. Em geral, as funções armazenadas pela memória 140 são executadas por processadores de uso geral 111, especializados processadores ou DSP (11). Assim, a memória 140 é uma memória legível por processador e/ou uma memória legível por computador que armazena software (código de programação, instruções, etc.) configurado para fazer com que o (s) processador (es) 111 e/ou DSP (s) 112 para executar as funções descritas. Alternativamente, uma ou mais funções do dispositivo móvel 100 podem ser realizadas no todo ou em parte em hardware.
[0021] Um dispositivo móvel 100 pode estimar a sua posição atual dentro de um sistema associado utilizando várias técnicas, com base em outras entidades de comunicação dentro da vista e/ou informação disponível para o dispositivo móvel 100. Por exemplo, um dispositivo móvel 100 pode estimar a sua posição utilizando informações obtidas a partir de pontos de acesso (APs) associados a uma ou mais redes de área local sem fio (LANs), redes de área pessoal (PANs) utilizando uma tecnologia de comunicação sem fio de curto alcance, como BLUETOOTH ou ZIGBEE®, etc., satélites SPS e/ou dados de restrição de mapa obtidos de um servidor de mapas ou servidor LCI.
[0022] Referindo-se em seguida à figura 2, é mostrado um diagrama de blocos de um exemplo de sistema de comunicação 200. O sistema de comunicação 200 pode incluir uma rede de acesso de rádio de longo prazo (LTE) (RAN) que fornece rádio sem fio comunicações entre um UE 202 (isto é, um dispositivo móvel 100) e um NodeB evoluído (eNB) 204 (por exemplo, uma estação base, ponto de acesso, etc.) usando tecnologia de acesso de rádio LTE. A rede LTE na figura 2 é exemplar apenas como outras redes podem ser usadas. Por simplicidade de discussão, a figura 2 representa um UE 202 e um eNB 204, no entanto uma RAN pode incluir qualquer número de UE e/ou eNBs. O eNB 204 transmite informações para o UE 202 sobre um canal de ligação ou descendente direto e o UE 202 pode transmitir informações para o eNB 204 através de um link reverso ou canal de ligação ascendente. Conforme mostrado, as RANs podem utilizar qualquer tipo adequado de tecnologia de acesso de rádio, tais como, entre outros, LTE, LTE-A, HSPA, CDMA, dados de pacotes de alta taxa (HRPD), HRPD evoluído (eHRPD), CDMA2000, GSM, GPRS, taxa de dados aprimorada para a evolução GSM (EDGE), UMTS ou similar.
[0023] O eNB 204 pode se comunicar com uma rede de núcleo que permite o carregamento (por exemplo, taxas de uso de serviços, etc.), segurança (por exemplo, proteção de criptografia e integridade), gerenciamento de assinantes, gerenciamento de mobilidade, gerenciamento de portadores, gerenciamento de QoS, política controle de fluxos de dados e/ou interconexões com rede externa. O RAN e a rede de núcleo pode se comunicar através de uma interface S1, por exemplo. A rede de núcleo pode incluir uma entidade de gerenciamento de mobilidade (MME) 206 que pode ser um ponto final para sinalização de controle do gateway de serviço (S-GW) 210. O MME 206 pode fornecer funções como gerenciamento de mobilidade (por exemplo, rastreamento) autenticação e segurança. O MME 206 pode se comunicar com o RAN através da interface S1. O gateway de serviço (S-GW) 210 é um nó de plano de usuário que conecta a rede de núcleo ao RAN LTE. O MME 206 pode ser configurado para se comunicar com o S-GW 210 através da interface S11. O MME 206 e o S-GW 210 podem ser configurados como um único nó para fornecer um único ponto final para o usuário e a sinalização de controle proveniente de um RAN e/ou terminando em um RAN. A rede também pode incluir uma política e função de regras de cobrança (PCRF) 212.
[0024] O sistema de comunicação 200 também pode incluir um gateway de rede de dados de pacotes (PDN) (21) que facilita as comunicações entre a rede de núcleo (e as RANs) e as redes externas. O PDN GW 214 pode fornecer filtragem de pacotes, policiamento QoS, cobrança, alocação de endereço IP e roteamento de tráfego para redes externas. Em um exemplo, o S-GW 210 e o PDN GW 214 podem se comunicar através de uma interface S5. Embora ilustrado como nós separados na figura 2, deve ser apreciado que o S-GW 210 e o PDN GW 214, por exemplo, podem ser configurados para operar como um único nó de rede para reduzir os nós do plano do usuário no sistema de comunicação 200. O sistema de comunicação 200 também pode incluir uma entidade de serviços de assinante doméstico (HSS) 208 que pode se comunicar com o MME 206. O sistema de comunicação 200 também pode incluir outros componentes de rede, como um servidor/proxy de autenticação, autorização e contabilidade 3GPP e um servidor/proxy 3GPP2 AAA (não mostrado) configurado para comunicar uns com os outros e ainda comunicar com o PDN GW 214 e a HSS 208.
[0025] O sistema de comunicação 200 pode ser configurado para se comunicar com redes externas através do PDN GW 214. As redes externas (não mostradas) podem incluir redes tais como, mas não limitado a, uma rede telefônica comutada pública (PSTN), um IP subsistema multimídia (IMS), e/ou uma rede IP. A rede IP pode ser a Internet, uma rede de área local, uma rede de área ampla, uma intranet ou similar. A figura 2 é um exemplo de apenas uma configuração possível e muitas outras configurações e componentes adicionais podem ser usados de acordo com vários aspectos e implementações descritos abaixo.
[0026] Um sistema informático 300, como ilustrado na figura 3, pode ser utilizado para implementar pelo menos parcialmente a funcionalidade dos elementos na figura 2. A figura 3 fornece uma ilustração esquemática de uma modalidade de um sistema de computador 300 que pode executar os métodos fornecidos por várias outras modalidades, como aqui descrito, e/ou pode funcionar como um dispositivo móvel ou outro sistema de computador. Por exemplo, o eNB 204, MME 206, HSS 208, S-GW 210, PCRF 212 e PDN GW 214 podem ser constituídos por um ou mais sistemas de computador 300. A figura 3 fornece uma ilustração generalizada de vários componentes, qualquer ou todos os quais podem ser utilizados conforme apropriado. A figura 3, portanto, amplamente ilustra como os elementos individuais do sistema podem ser implementados de uma maneira relativamente separada ou relativamente mais integrada.
[0027] O sistema de computador 300 é mostrado compreendendo elementos de hardware que podem ser acoplados eletricamente através de um barramento 305 (ou podem estar em comunicação, conforme apropriado). Os elementos de hardware podem incluir um ou mais processadores 310, incluindo, sem limitação, um ou mais processadores de uso geral e/ou um ou mais processadores de uso especial (como chips de processamento de sinal digital, processadores de aceleração de gráficos e/ou similares); um ou mais dispositivos de entrada 315, que podem incluir, sem limitação, um mouse, um teclado e/ou semelhante; e um ou mais dispositivos de saída 320, que podem incluir, sem limitação, um dispositivo de exibição, uma impressora e/ou semelhante. O (s) processador (es) 310 pode incluir, por exemplo, dispositivos de hardware inteligentes, por exemplo, uma unidade de processamento central (CPU), como aqueles fabricados pela Intel® Corporation ou AMD®, um microcontrolador, um ASIC, etc. Outros tipos de processadores também poderiam ser utilizados.
[0028] O sistema de computador 300 pode ainda incluir (e/ou estar em comunicação com) um ou mais dispositivos de armazenamento não transitórios 325, que podem compreender, sem limitação, armazenamento local e/ou acessível em rede, e/ou podem incluir, sem limitação, uma unidade de disco, uma matriz de unidade, um dispositivo de armazenamento óptico, um dispositivo de armazenamento de estado sólido, como uma memória de acesso aleatório (“RAM”) e/ou uma memória somente de leitura (“ROM”), que podem ser programáveis, atualizáveis por flash e/ou similares. Tais dispositivos de armazenamento podem ser configurados para implementar quaisquer armazenamentos de dados apropriados, incluindo, sem limitação, vários sistemas de arquivos, estruturas de banco de dados e/ou similares.
[0029] O sistema de computador 300 pode também incluir um subsistema de comunicações 330, que pode incluir, sem limitação, um modem, uma placa de rede (sem fio ou com fio), um dispositivo de comunicação infravermelho, um dispositivo de comunicação sem fio e/ou um chipset (como um BLUETOOTH tecnologia de comunicação sem fio de curto alcance transceptor/dispositivo, um dispositivo 802.11, um dispositivo Wi-Fi, um dispositivo WiMax, instalações de comunicação celular, etc.) e/ou similares. O subsistema de comunicação 330 pode permitir que os dados sejam trocados com uma rede (como a rede descrita abaixo, para nomear um exemplo), outros sistemas informáticos e/ou quaisquer outros dispositivos aqui descritos. Em muitas modalidades, o sistema de computador 300 compreenderá ainda, como aqui, uma memória de trabalho 335, que pode incluir um dispositivo RAM ou ROM, como descrito acima.
[0030] O sistema de computador 300 também pode compreender elementos de software, mostrados como sendo atualmente localizados dentro da memória de trabalho 335, incluindo um sistema operacional 340; acionadores de dispositivo; bibliotecas executáveis e/ou outro código; como um ou mais programas de aplicação 345, que podem compreender programas de computador fornecidos por várias modalidades, e/ou podem ser projetados para implementar métodos e/ou configurar sistemas, fornecidos por outras modalidades, conforme aqui descrito. Apenas a título de exemplo, um ou mais processos aqui descritos podem ser implementados como código e/ou instruções executáveis por um computador (e/ou um processador dentro de um computador). Esse código e/ou instruções podem ser usados para configurar e/ou adaptar um computador de propósito geral (ou outro dispositivo) para executar uma ou mais operações de acordo com os métodos descritos.
[0031] Um conjunto dessas instruções e/ou código pode ser armazenado em um meio de armazenamento legível por computador, como o (s) dispositivo (s) de armazenamento 325 descrito acima. Em alguns casos, o meio de armazenamento pode ser incorporado dentro de um sistema informático, como o sistema informático 300. Em outras modalidades, o meio de armazenamento pode ser separado de um sistema informático (por exemplo, um meio removível, como um disco compacto), e/ou fornecido em um pacote de instalação, de modo que o meio de armazenamento possa ser usado para programar, configurar e/ou adaptar um computador de propósito geral com as instruções/códigos armazenados no mesmo. Essas instruções podem assumir a forma de código executável, que é executável pelo sistema de computador 300 e/ou pode assumir a forma de código fonte e/ou código que se pode instalar, que, após a compilação e/ou a instalação no sistema de computador 300 (por exemplo, usando qualquer um de uma variedade de compiladores geralmente disponíveis, os programas utilitários de instalação, de compressão/descompressão, etc.), em seguida, assume a forma de código executável.
[0032] Referindo-se à figura 4, é mostrado um diagrama de fluxo de chamada de técnica anterior 400 de um procedimento de autenticação de evolução de longo prazo 3GPP (LTE). O diagrama de fluxo de chamadas da técnica anterior 400 está em conformidade com padrões publicados, como o 3GPP TS 33.401. As mensagens indicadas no fluxo de chamadas representam informações (por exemplo, campos de dados) que são transmitidas eletricamente entre sistemas informáticos. A informação pode ser de tipos de dados como é conhecido na arte (por exemplo, binário, número, caracteres, caracteres variáveis, data, etc.). O diagrama 400 representa procedimentos de segurança que podem ser usados por um sistema de comunicação 200, portanto, o diagrama 400 inclui um UE 202 (por exemplo, um dispositivo móvel 100), uma rede 402 e uma rede local 404. A rede 402 pode incluir um eNodeB (eNB) 204 e um MME 206. A rede local 404 inclui pelo menos o HSS 208. O diagrama de fluxo de chamadas 400 ilustra um procedimento de acordo de autenticação e chave (AKA) para fornecer credenciais em uma rede. O UE 202 envia o MME 206 (por exemplo, através do eNB 204) uma mensagem de solicitação de Camada de Não Acesso de acesso 410 (NAS) incluindo uma estação móvel internacional Identidade do equipamento (IMSI). O MME 206 está configurado para recuperar dados de autenticação do HSS 208 para executar a autenticação do usuário. O MME 206 pode enviar o HSS 208 uma mensagem de solicitação de informações de autenticação 412 incluindo o IMSI (por exemplo, incluído na mensagem de solicitação de anexação NAS 410) e uma informação de identidade de rede (SN_id). O SN_id pode incluir um código de país móvel e um código de rede móvel. A mensagem de solicitação de informação de autenticação 412 também pode incluir campos de dados que indicam um tipo de rede (por exemplo, E-UTRAN) e uma série de vetores de autenticação solicitados (AV) (não mostrado). O HSS 208 está configurado para receber a mensagem de solicitação de informações de autenticação 412 e gerar uma ou mais AVs. Em um exemplo, o HSS 208 pode solicitar os AVs de um Centro de Autenticação (AuC) (não mostrado). Os AVs incluem um token de autenticação (AUTN), uma resposta esperada (XRES), um número aleatório (RAND) e uma entidade de gerenciamento de segurança de acesso de chave (KASME). O KASME constitui a base para gerar a Camada de Acesso (AS) e a codificação NAS e chaves de integridade para proteção de sinalização NAS e proteção de plano de usuário. Os AVs são fornecidos ao MME 206 em uma mensagem de resposta de informação de autenticação 414. Em outras redes 3GPP que usam AKA (por exemplo, UMTS, GSMA), os AVs incluem um token de autenticação (AUTN), uma resposta esperada (XRES), um número aleatório (RAND), uma chave de codificação (CK) e Chave de Integridade (IK). A CK e a IK são usadas para codificar e proteção de integridade das mensagens.
[0033] O MME 206 pode ser configurado para iniciar a autenticação do UE 202 através de protocolos do Sistema Evoluído de Pacotes (EPS). O MME 206 gera uma mensagem de solicitação de autenticação NAS 416, incluindo os valores AUTN e RAND recebidos da rede local 404, bem como um identificador de conjunto de chaves NAS (KSIASME) com base no valor KASME recebido. O KSIASME é armazenado no UE 202 e no MME 206. O UE 202 é configurado para identificar a frescura do AV (por exemplo, verificando se o AUTN pode ser aceito). O UE 202 pode então calcular um valor de resposta (RES) se a verificação for aceita (por exemplo, o AUTN é aceito) e, em seguida, envia uma mensagem NAS de resposta de autenticação 418 que inclui o valor de RES. Se a verificação falhar, o UE 202 envia uma mensagem de falha de autenticação para o MME 206 com um valor de CAUSA indicando o motivo da falha. O MME 206 está configurado para determinar se o valor RES e o valor XRES são iguais. Se forem iguais, a autenticação é bem-sucedida. Se eles não são iguais, o MME 206 pode ser configurado para iniciar novas solicitações de identidade ou enviar uma mensagem de rejeição de autenticação para o UE 202.
[0034] Após uma autenticação bem sucedida, o MME 206 pode ser configurado para iniciar um procedimento de comando de modo de segurança NAS (SMC) que consiste em uma mensagem de ida e volta entre o MME 206 e o UE 202. O MME 206 envia um Comando de Modo de Segurança NAS (SMC) mensagem 420 contendo algoritmos de confidencialidade e integridade. Por exemplo, a mensagem 420 do NAS SMC pode conter recursos de segurança do UE reproduzidos, algoritmos NAS selecionados, o valor KSIASME para identificar o KASME e os valores NONCEUE e NONCEMME no caso de criar um contexto mapeado na mobilidade inativa. A mensagem 420 do NAS SMC pode ser protegida contra integridade (mas não codificada) com a chave de integridade NAS com base no KASME indicado pelo valor KSIASME na mensagem. O UE 202 é configurado para verificar a integridade da mensagem 420 de NAS SMC. Isto pode incluir assegurar que as capacidades de segurança do UE enviadas pelo MME 206 correspondem às armazenadas no UE 202 para garantir que estas não foram modificadas por um invasor e verificando a proteção de integridade usando o indicado algoritmo de integridade NAS, e a chave de integridade NAS com base no KASME indicado pelo valor KSIASME. Se as verificações do Comando do Modo de Segurança NAS forem passadas, o UE 202 está configurado para responder com uma mensagem de Modo de Segurança NAS 422. O UE 202 está configurado para executar proteção de integridade NAS e criptografar/decodificação e enviar a mensagem do modo de segurança NAS completado 422 para o MME 206, criptografada e com integridade protegida. O MME 206 é configurado para decodificar e verificar a proteção de integridade na mensagem Modo de Segurança NAS Completado 422 usando as chaves e os algoritmos indicados no Comando do Modo de Segurança NAS. NAS downlink codificação no MME com este contexto de segurança pode começar depois de receber a mensagem Modo de Segurança NAS Completado 422. Decodificação de uplink NAS no MME 206 pode ser iniciada após enviar a mensagem NAS SMC 420.
[0035] Após o recebimento da mensagem Modo de Segurança NAS Completado 422, o MME 206 pode ser configurado para iniciar a interface S1 entre o eNB 204 e o MME 206 mediante o envio de uma mensagem de configuração de contexto inicial S1AP 424. Em geral, a finalidade do procedimento de configuração de contexto inicial é de estabelecer o contexto de UE inicial global necessário, incluindo o contexto de portadora de acesso de rádio E- UTRAN (E-RAB), a chave de segurança, a lista de restrições de transferência, a capacidade de rádio UE e as capacidades de segurança do UE, etc. O procedimento usa sinalização associada de UE. A mensagem de configuração de contexto inicial S1AP 424 pode conter um Elemento de informação de ativação de rastreamento (IE), um IE de lista de restrição de entrega (que pode conter roaming, restrições de área ou acesso), um IE de capacidade de rádio do UE, um ID de perfil de assinante para IE de prioridade de RAT/Freqüência, um IE de Indicador de retirada de CS, um IE de Operação Possível SRVCC, um IE de Status de Membro CSG, um IE de LAI Registrado, um IE de ID GUMMEI, que indica o MME servindo o UE, um MME UE S1AP ID 2IE, que indica o MME UE S1AP ID atribuído pelo MME, um IE de MDT baseado em Gerenciamento Permitido e uma ID de Perfil de Assinante para IE de Prioridade RAT/Freqüência, se disponível no MME. O eNB pode ser configurado para iniciar comunicações seguras com o UE 202 através de protocolos de controle de recursos de rádio(RRC), como descrito na especificação do protocolo 3GPP TS 25.331. O eNB pode enviar uma mensagem CRC SMC 426 para o UE 202 e o UE 202 pode ser configurado para gerar uma mensagem completa de modo de segurança RRC 428 conforme descrito na especificação.
[0036] Referindo-se às figuras 5, com referência adicional às figuras 2 é mostrado um diagrama de fluxo de chamadas 500 de um procedimento de autenticação de exemplo com sigilo direto perfeito (PFS). O diagrama 500 representa procedimentos de segurança que podem ser usados por um sistema de comunicação 200, assim o diagrama 500 inclui um UE 202 (por exemplo, um dispositivo móvel 100), uma rede 502 e uma rede local 504. A rede 502 pode incluir um eNodeB (eNB) 204 e um MME 206. A rede local 504 inclui pelo menos o HSS 208 que é suposto suportar AKA com uma propriedade PFS. O diagrama de fluxo de chamadas 500 melhora o procedimento de acordo de autenticação e chave (AKA) descrito na figura 4, adicionando uma propriedade perfeita de sigilo para frente (PFS). Os campos novos ou melhorados no diagrama 500 (por exemplo, em comparação com o fluxo de chamadas na figura 4) são rotulados com um prefixo “PFS” e destacados no diagrama 500 com o sublinhado. Os elementos opcionais são indicados em itálico. Os novos procedimentos computacionais (por exemplo, estágios) no diagrama 500 são indicados nas respectivas caixas de processo.
[0037] O UE 202 pode ser configurado para enviar uma solicitação de ligação de NAS de PFS 510 ao MME 206. A solicitação de encadernação de PFS NAS 510 inclui informação de identificação (por exemplo, IMSI) e pode, opcionalmente, incluir também um Elemento de Informação de PFS de UE (IE). O UE PFS IE pode ser um bit de dados booleano, ou qualquer tipo de dados para indicar que o UE 202 é capaz de processar AKA com uma propriedade PFS. O UE PFS IE é opcional, no entanto, como a capacidade do UE para processar AKA com uma propriedade PFS pode ser estabelecida de outras maneiras (por exemplo, através de elementos de informação presentes em outras trocas de mensagens). Após o recebimento do pedido, o MME 206 está configurado para solicitar vetores de autenticação da rede local 504 (por exemplo, o HSS 208). O MME 206 gera uma mensagem de solicitação de informações de autenticação PFS 512 incluindo a informação de segurança do UE (por exemplo, IMSI), campos de dados que indicam um tipo de rede (por exemplo, E-UTRAN) e uma indicação de que a rede 502 suporta uma propriedade PFS (por exemplo, um elemento informativo PFS MME (SN)). A mensagem de solicitação de informações de autenticação PFS 512 geralmente é uma mensagem de protocolo de diâmetro com pares de valor de atributos (AVP) como elementos informativos. O elemento informativo PFS MME (SN) pode ser um valor booleano ou outro valor de dados e é usado para indicar que a rede 502 suporta a propriedade PFS. Esta indicação pode ser usada para ajudar a prevenir ataques de intrusos (MiM). Ou seja, uma estação maliciosa que intercepta a solicitação de anexação NAS PFS 510 não pode apenas emitir a mensagem de anexação NAS PFS à rede local 504 sem o elemento de informação MME (SN) PFS e tentar forçar o UE a utilizar o protocolo AKA sem a propriedade PFS.
[0038] O HSS 208 está configurado para receber a mensagem de solicitação de informações de autenticação PFS 512 e determinar se a rede 502 suporta a propriedade PFS. Se PFS é suportado, no estágio 526 o HSS 208 é configurado para gerar um token de autenticação (AUTN). Nesse caso, um campo no Authentication Management Field (AMF) no token de autenticação (AUTN) é configurado para indicar que a rede 502 suporta a propriedade PFS (por exemplo, um bit booleano é definido como 1). Isso pode ser referido como o bit PFS. Se a rede 502 não suportar a propriedade PFS, o bit PFS é definido como um valor para indicar que o PFS não é suportado e o protocolo AKA padrão será usado (por exemplo, o bit Booleano é definido como zero). O HSS 208 gera uma mensagem de resposta de informação de autenticação PFS 514 incluindo um vetor de autenticação (AV). O AV na mensagem de resposta de informação de autenticação PFS 514 inclui o token de autenticação com o bit PFS descrito acima, (AUTN), o valor de resposta esperada (XRES), o valor de número aleatório (RAND) e o valor de entidade de gerenciamento de segurança de acesso à chave (KASME).
[0039] O UE 202 e o MME 206 são configurados para gerar respectivos pares de chaves efêmeras de Diffie- Hellman (DHE) públicas e privadas nos estágios 521 e 524, respectivamente. Os pares Diffie-Hellman podem ser gerados, por exemplo, usando criptografia de curva elíptica ou aritmética de campo finito. Como exemplo, e não uma limitação, os pares de DHE podem ser como descrito na Patente dos Estados Unidos N° 4 200 770, depositada em 6 de setembro de 1977 e intitulada “Cryptographic Apparatus and Method”. O UE 202 é configurado para gerar um valor de chave privada de UE (DHEpriKeyUE) e um valor de chave pública de UE (DHEpubKeyUE). O MME 206 está configurado para gerar um valor de chave particular MME (DHEpriKeyMME) e um valor de chave pública MME (DHEpubKeyMME). As chaves privadas (DHEpriKeyUE, DHEpriKeyMME) geralmente são geradas usando um gerador de números pseudo-aleatórios seguro em termos criptográficos (CSPRNG), mas podem ser utilizadas outras informações confidenciais (e preferencialmente não deterministas) disponíveis para os respectivos sistemas. As chaves públicas correspondentes também são geradas pelos respectivos sistemas. Os pares de chaves DHE podem ser selecionados e gerados (por exemplo, pré-computados) antecipadamente pelo UE 202 e o MME 206 para reduzir o impacto de um potencial ataque de rede (por exemplo, atrasos de processamento devido à geração das chaves DHE). Deve notar-se que o UE pode gerar seus pares de DHE a qualquer momento antes do estágio 521 e o MME pode gerar seus pares DHE em qualquer momento antes do estágio 530 ou no estágio 530.
[0040] O UE 202 e o MME 206 são configurados para trocar suas chaves públicas durante os procedimentos de autenticação AKA e derivar individualmente uma chave compartilhada (por exemplo, sharedDHkey). Por exemplo, o MME 206 gera uma mensagem de solicitação de autenticação de NAS PFS 516, incluindo os valores AUTN e RAND recebidos do HSS 208, bem como um identificador de conjunto de chaves NAS (KSIASME) com base no valor KASME recebido. Na fase 528, se o UE 202 é capaz de processar uma propriedade PFS, o UE 202 é configurado para determinar se o bit PFS no valor AUTN indica que a propriedade PFS é suportada. Se o UE 202 não estiver configurado para suportar uma propriedade PFS, a troca de mensagens pode continuar sob os procedimentos AKA padrão (por exemplo, o UE envia a mensagem de resposta de autenticação NAS 418, descrita na figura 4). O UE 202 também está configurado para determinar se o valor AUTN está fresco, conforme descrito anteriormente. Se o valor AUTN for aceito e o bit PFS estiver definido, o UE 202 calcula um valor RES e fornece uma mensagem de resposta de autenticação de NAS PFS 518 ao MME 206, incluindo o valor RES e o valor da chave pública do UE (ou seja, DHEpubKeyUE). Se o valor AUTN for aceito, mas o bit PFS não estiver definido (por exemplo, valor de zero), o UE 202 pode decidir abortar os procedimentos de conexão com a rede que não suporta a propriedade PFS ou pode calcular e enviar o RES em de acordo com os procedimentos AKA padrão (por exemplo, o UE envia a mensagem de resposta de autenticação NAS 418, descrita na figura 4). Se a verificação AUTN falhar, o UE 202 envia uma mensagem de falha de autenticação para o MME 206 com um valor CAUSA indicando o motivo da falha.
[0041] Ao receber a mensagem de resposta de autenticação NAS PFS 518, na etapa 530, o MME 206 é configurado para determinar se o valor RES é igual ao valor XRES e, em seguida, derivar uma chave compartilhada Diffie- Hellman (ou seja, sharedDHEkey) com base no recebeu a chave pública do UE (ou seja, DHEpubKeyUE). Deve ser apreciado que, se a autenticação do UE falhar (ou seja, o valor RES não é igual a XRES), a rede pode rejeitar a solicitação de anexos e nenhum recurso de computação é desperdiçado ao executar operações de criptografia assimétricas caras. Isso ajuda a aliviar qualquer ataque de negação de serviço por UEs mal-intencionados. A chave compartilhada é então vinculada ao valor KASME (por exemplo, a chave de sessão) recebida do HSS 208; e a chave vinculada é usada para proteger todo o subseqüente tráfego NAS. Por exemplo, uma chave vinculada pode ser designada como K'ASME (por exemplo, KASME-prime) e pode ser gerada com base em uma função de derivação de chave (KDF) do KASME e a chave compartilhada. Ou seja, K'ASME = KDF (KASME, sharedDHEkey). O KDF pode ser uma função hash de criptografia (por exemplo, SHA256, SHA512, SHA-3, etc.). O valor K'ASME resultante pode ser usado como o valor KASME nos procedimentos de segurança LTE subseqüentes.
[0042] O MME 206 também envia uma mensagem SMC do NAS PFS 520, incluindo a chave pública MME (ou seja, DHEpubKeyMME), bem como algoritmos de confidencialidade e integridade. Por exemplo, a mensagem do PFS NAS SMC 520 pode conter recursos de segurança do UE reproduzidos, algoritmos NAS selecionados, o valor KSIASME para identificar o KASME e os valores NONCEUE e NONCEMME no caso de criar um contexto mapeado na mobilidade inativa. A mensagem NAS PFS SMC 520 pode estar protegida quanto à integridade (mas não codificada) com chave de integridade NAS com base em KASME indicado pelo valor KSIASME na mensagem. O UE 202 é configurado para verificar a integridade da mensagem PFS NAS SMC 520. Isto pode incluir a garantia de que os recursos de segurança UE enviados pelo MME corresponder às armazenadas na UE para garantir que estes não foram modificados por um atacante e verificar o proteção de integridade usando o indicado algoritmo de integridade NAS e a chave de integridade NAS com base na KASME indicada pelo valor KSIAMSE. Na etapa 532, o UE 202 é configurado para derivar o Diffie-Hellman chave partilhada (por exemplo, sharedDHEkey) com base na chave MME pública (por exemplo, DHEpubKeyMME). A sharedDHEkey é então vinculada ao valor KASME (por exemplo, como identificado pela valor KSIASME) para criar o K'ASME como descrito acima. O valor K'ASME resultante pode ser usado como o valor KASME em todos os procedimentos de segurança LTE subsequentes.
[0043] Se passarem as verificações da mensagem baseada em PFS NAS SMC 520 (ou seja, os recursos de segurança de UE enviados pelo MME corresponderem aos armazenadas no UE, e a proteção da integridade usar o indicado algoritmo de integridade NAS e a chave integridade NAS com base em KASME indicada pelo valor KSIAMSE), o UE 202 está configurado para responder com uma mensagem de modo de segurança completado PFS NAS 522. O UE 202 é configurado para executar proteção da integridade NAS e codificação/decodificação com base em K'ASME, e enviar a mensagem modo de segurança PFS NAS completado 522 para o MME 206, codificada e com integridade protegida (por exemplo, com base em K'ASME). O MME 206 é configurado para decodificar e verificar a proteção de integridade na mensagem modo de segurança PFS NAS completado 522 usando chaves com base em K'ASME e outros algoritmos indicados na mensagem PFS NAS SMC 520.
[0044] Referindo-se às figuras 6, com referência adicional às figuras 2, 4 e 5, um diagrama de fluxo de chamadas 600 de outro procedimento de autenticação com o exemplo perfeito frente sigilo (PFS) é mostrado. O diagrama 600 representa procedimentos de segurança alternativos que podem ser usados por um sistema de comunicações 200, pelo que o diagrama 600 inclui um UE 202 (por exemplo, um dispositivo móvel 100), uma rede 602, e uma rede local 604. A rede 602 pode incluir um eNodeB (eNB) 204 e uma rede 206. A rede local 604 inclui, pelo menos, o HSS 208 que é assumido para suportar AKA com uma propriedade PFS. O diagrama de fluxo de chamadas 600 melhora a autenticação e o processo de acordo de chave (AKA) descrito na figura 4 pela adição de um imóvel perfeito frente sigilo (PFS). O diagrama 600 também inclui algumas das mensagens previamente descritas na figura 5. Por exemplo, o UE 202 pode ser configurado para enviar a solicitação de anexação PFS NAS 510 para a MME 206. Após a recepção do pedido, a MME 206 é configurada para solicitar vetores de autenticação da rede local 604 (por exemplo, o HSS 208). O MME 206 gera a solicitação de mensagem de informação de autenticação PFS 512 (por exemplo, incluindo o MME (SN) PFS elemento informacional) e a fornece à rede local 604. A rede local 604 (por exemplo, o HSS 208) é configurada para receber a autenticação PFS Peça informações mensagem 512 e determinar se a rede 602 suporte a propriedade PFS. Se PFS é suportado, na fase 526 o HSS 208 está configurado para gerar o token de autenticação (AUTN) incluindo o bit de PFS discutido na figura 5. Se a rede 602 não suporta a propriedade PFS,então o bit de PFS é definido como um valor para indicar que o PFS não é suportado e o protocolo AKA padrão vai ser utilizado (por exemplo, o bit booleana é definido como zero). O HSS 208 gera a informação de autenticação PFS mensagem de resposta 514, incluindo um vetor de autenticação (AV). O AV na informação de autenticação PFS mensagem de resposta 514 inclui o token de autenticação com o bit PFS descrito acima, (AUTN), o valor esperado de resposta (XRES), o valor de número aleatório (RAND), e o valor de entidade de gerenciamento de segurança de acesso à chave (KASME).
[0045] O UE 202 e o MME 206 são configurados para gerar os respectivos pares de chaves públicas e privadas efêmeras Diffie-Hellman (DHE) na fase 521 e 524, respectivamente. A UE 202 está configurado para gerar um valor de UE chave privada (DHEpriKeyUE) e um valor de chave pública UE (DHEpubKeyUE). O MME 206 é configurado para gerar um valor chave privada MME (DHEpriKeyMME) e um valor de chave pública MME (DHEpubKeyMME). As chaves privadas (DHEpriKeyUE, DHEpriKeyMME) são tipicamente gerado usando um gerador de números pseudo-aleatória criptograficamente segura (CSPRNG), mas podem ser usadas outras informações confidenciais disponíveis para os respectivos sistemas. As chaves públicas correspondentes podem ser geradas de forma não-determinística semelhante pelos respectivos sistemas. Os pares de chaves DHE podem ser selecionados e gerados (por exemplo, pré-computados) antecipadamente pelo UE 202 e pelo MME 206 para reduzir o impacto de um potencial ataque de rede (por exemplo, devido a atrasos de processamento gerar as chaves de DHE). Deve-se notar que o MME pode gera seus pares DHE qualquer momento antes da fase 524 e a UE pode gera seus pares DHE a qualquer momento antes da etapa 521.
[0046] O UE 202 e o MME 206 são configurados para trocar as suas chaves públicas durante os procedimentos de autenticação AKA e individualmente derivar uma chave compartilhada (por exemplo, sharedDHkey). Em contraste com a mensagem de solicitação de autenticação PFS NAS 516 na figura 5, no fluxo de chamadas na figura 6, o MME 206 gera uma mensagem de solicitação de autenticação PFS NAS 616, incluindo os valores AUTN e RAND recebidos a partir do HSS 208, o identificador de conjunto de chaves NAS (KSIASME) com base no valor KASME recebido, bem como a chave pública MME (isto é, DHEpubKeyMME). Na fase 628, o UE 202 é configurado para determinar se o bit PFS no valor AUTN indica que a propriedade PFS é suportada, e determinar se a chave pública MME (isto é, DHEpubKeyMME) está presente na mensagem de solicitação de autenticação PFS NAS 616.
[0047] O UE 202 também está configurado para determinar se o valor AUTN é fresco, como anteriormente descrito. Se o valor AUTN é aceito, e o bit PFS está definido e, em seguida, a chave pública MME (isto é, DHEpubKeyMME) está presente, então o UE 202 calcula um valor RES e fornece uma PFS NAS mensagem de resposta de autenticação 518 à MME 206, incluindo o valor RES e o valor da chave pública UE (ou seja, DHEpubKeyUE). Se o valor AUTN é aceito, mas o pouco PFS não está definido (por exemplo, valor igual a zero) e a chave pública MME (isto é, DHEpubKeyMME) não está presente, então, o UE 202 pode decidir abortar os procedimentos de conexão com a rede que não suporta PFS propriedade ou pode calcular e enviar o RES em conformidade com procedimentos padrão (AKA por exemplo, o UE envia a mensagem NAS resposta de autenticação 418 descrito na Fig. 4). Se o bit de PFS está definido, mas a chave pública MME (isto é, DHEpubKeyMME) não está presente, ou a verificação AUTN falha (por exemplo, independentemente do valor PFS e a presença da chave pública MME), a UE 202 envia uma mensagem de falha de autenticação ao MME 206. Em um exemplo, a mensagem de falha pode incluir um valor Causa indicando o motivo da falha.
[0048] Na fase 530 o MME 206 é configurado para determinar se o valor do RES é igual ao valor XRES, e, em seguida, derivar um Diffie-Hellman chave comum (isto é, sharedDHEkey) com base na chave recebida do UE público (ou seja, DHEpubKeyUE na mensagem de resposta de autenticação PFS NAS 518). A chave compartilhada é então vinculada ao valor KASME recebido do HSS 208; e a chave vinculada é usada para proteger todo o posterior tráfego NAS. Por exemplo, uma chave vinculada pode ser designada como K'ASME (por exemplo, KASME-prime) e pode ser gerada com base numa função de derivação de chave (KDF) de KASME e a chave partilhada. Ou seja, K'ASME = KDF (KASME, sharedDHEkey). O KDF pode ser uma função hash de criptografia (por exemplo, SHA256, SHA512, SHA-3, etc.). O valor K'ASME resultante pode ser utilizado como o valor KASME na rede LTE. Na etapa 632, o UE 202 é configurado para derivar o Diffie-Hellman chave partilhada (por exemplo, sharedDHEkey) com base na chave MME pública (por exemplo, DHEpubKeyMME). A sharedDHEkey é então vinculado ao valor KASME (por exemplo, como identificado pela valor KSIASME) para criar o K'ASME como descrito acima. O valor K'ASME resultante pode ser utilizado como o valor KASME nos procedimentos de segurança LTE subsequentes.
[0049] O MME 206 envia uma mensagem PFS NAS SMC 620, incluindo confidencialidade e integridade algoritmos. Por exemplo, a mensagem PFS NAS SMC 620 pode conter as reproduzidas capacidades de segurança UE, selecionando os algoritmos NAS, e ambos os valores NONCEUE e NONCEMME no caso de se criar um contexto mapeado na mobilidade ociosa. Numa modalidade, a mensagem NAS PFS SMC 620 pode estar protegida quanto à integridade (mas não codificada) com chave de integridade NAS com base em K'ASME determinada na fase 530. O UE 202 é configurado para verificar a integridade da mensagem NAS PFS SMC 620. Isso pode incluir a garantia de que os recursos de segurança UE enviados pelo MME corresponder às armazenadas na UE para garantir que estes não foram modificados por um atacante e verificando a integridade de proteção usando o indicado algoritmo de integridade NAS, e a chave de integridade NAS com base na K'ASME derivada na fase 632.
[0050] Se passarem as verificações da mensagem baseada no PFS NAS SMC 620 (por exemplo, os recursos de segurança UE enviados pelo MME corresponderem aos armazenados no UE, e a proteção da integridade usa o indicado algoritmo de integridade NAS, e a chave de integridade NAS com base em K'ASME), o UE 202 é configurado para responder com uma mensagem de modo de segurança completado PFS NAS 522. O UE 202 é configurado para executar proteção de integridade NAS e codificação/decodificação com base em K'ASME, e para enviar a mensagem de modo de segurança completado PFS NAS 522 para a MME 206, codificada e com integridade protegida. O MME 206 é configurado para decodificar e verificar a proteção de integridade na mensagem Modo de Segurança Completado PFS NAS 522 utilizando chaves baseadas em K'ASME e outros algoritmos indicados na mensagem de PFS NAS SMC 620.
[0051] Além de incluir os aspectos de segurança associados com a propriedade PFS, os exemplos de fluxo de chamada fornecidos nas figuras 5 e 6 fornecem proteção para ataques de tentativa (por exemplo, intruso, em que uma entidade maliciosa modifica a troca de mensagens). Ou seja, os fluxos de chamadas impedem que um intruso de licitação para baixo do procedimento de “AKA com PFS” para um procedimento de “AKA sem PFS”. Quando a rede local do assinante (por exemplo, o HSS 208) suporta PFS, fica implícito que o HSS entende as indicações recebidas do MME (por exemplo, o MME (SN) PFS elemento informacional) e pode definir um pouco PFS na AMF arquivado no testemunho de autenticação (AUTN) durante AKA autenticação vetor (AV) geração. Geralmente, se uma rede (por exemplo, uma MME) suporta PFS, indica o seu apoio PFS a uma rede local (por exemplo, um HSS) como parte do pedido de AV. Esta indicação é incluída para o HSS mesmo se a UE não indica apoio PFS no pedido anexar. O HSS define um bit de AMF (por exemplo, o bit de PFS) no AUTN. A AUTN é protegida em integridade entre o HSS e o UE. Um UE que suporta PFS é configurado para verificar se o bit PFS é definido na AUTN. Se o bit de PFS está definido, mas AKA é realizada sem PFS, em seguida, o UE irá rejeitar a autenticação. A UE, que não suporta PFS pode ignorar a verificação de bit. Se uma rede (por exemplo, uma MME) não suporta PFS (ou seja, o bit de PFS está definido para zero no AV), então uma política de UE pode ser invocada para determinar se a UE continua a autenticação sem PFS com a rede.
[0052] Com referência à figura 7, ainda com referência às figuras 1-6, um processo 700 para fornecer comunicações seguras com um dispositivo móvel inclui as etapas mostradas. O processo 700 é, no entanto, apenas um exemplo e não limitativo. O processo 700 pode ser alterado, por exemplo, ao ter as etapas adicionadas, removidas, rearranjadas, combinadas, e/ou realizadas simultaneamente. Por exemplo, a chave pública UE e a chave privada de UE podem ser previamente calculadas. O processo 700 pode executar no dispositivo móvel 100, o qual também é um exemplo de um UE 202 no sistema de comunicações 200.
[0053] Na fase 702, o processador 111 e o emissor-receptor sem fio 121 no dispositivo móvel 100 estão configurados gerar uma solicitação de anexação. Numa modalidade, a solicitação de ligação pode incluir um indicador de suporte PFS. O processador 111 e o emissor- receptor sem fio 121 são um meio para gerar uma solicitação de anexação. Um pedido ligação pode ser uma comunicação sem fio entre o dispositivo mel 100 e uma rede de comunicação, tal como o LTE, LTE-A, HSPA, CDMA, os dados de pacote de alta taxa (HRPD), evoluiu HRPD (eHRPD), CDMA2000, GSM, GPRS, taxa de dados melhorada para a evolução do GSM (EDGE), UMTS, ou semelhantes. O sistema de comunicação pode utilizar um protocolo ‘AKA com PFS’ para garantir o fluxo de mensagens na rede. Gerando um anexar solicitação pode ser o envio da solicitação de anexação PFS NAS 510 a partir do dispositivo móvel para o MME 206 através do eNB 204. T ele PFS apoio solicitação de anexação pode incluir, opcionalmente, um pouco booleano, ou qualquer tipo de dados, como o elemento de informação opcional UE PFS na solicitação de anexação PFS NAS 510.
[0054] Na fase 704, o processador 111 e o transceptor sem fio 121, no dispositivo móvel 100, estão configurados para receber um pedido de autenticação com um token de autenticação, de tal modo que o token de autenticação inclui uma indicação de apoio PFS pela célula servidora. O valor do token de autenticação é baseado, pelo menos em parte, por um indicador de suporte de rede (por exemplo, o MME PFS). Ou seja, o token de autenticação é configurado para indicar se a rede suporta PFS. Por exemplo, a indicação de apoio PFS pela rede pode ser o campo AUTN na informação de autenticação PFS mensagem de resposta 514. O token de autenticação pode incluir um campo de dados (por exemplo, bits, bytes) como a indicação de que uma rede suporta PFS (por exemplo, o bit PFS na AUTN).
[0055] Na fase 706, o processador 111 no dispositivo móvel 100 é configurado para determinar se uma rede suporta frente sigilo perfeito (PFS). O token de autenticação recebido na etapa 704 pode incluir um pouco PFS (por exemplo, um bit de AMF) para indicar se ou não a rede suporta o PFS. Se a rede não suporta PFS (isto é, PFS bit é igual a zero), então na fase 716 o dispositivo móvel 100 está configurado para fornecer uma resposta de autenticação, sem o valor da chave pública UE. Por exemplo, referindo-se figura 4, a resposta de autenticação pode ser a mensagem de resposta de autenticação NAS 418. Na etapa 718, o dispositivo móvel 100 é configurado para realizar o procedimento de autenticação AKA padrão, tal como representado na figura 4.
[0056] Se o dispositivo mel 100 determina que a rede suporte o PFS (por exemplo, o bit de PFS na AUTN é igual a 1), então o processador 111 no dispositivo móvel 100 é configurado para proporcionar o valor da chave pública do UE para a rede (por exemplo, numa resposta de autenticação) na fase 708. o processador 111 e o receptor sem fio 121 são um meio para proporcionar o valor da chave pública do UE para a rede. Por exemplo, o processador 111 é configurado para gerar um valor de chave pública UE e um valor de chave privada UE. As chaves públicas e privadas são gerados como pares Diffie-Hellman. O processador 111 é um meio para a geração de chaves públicas e privadas UE. O processador 111 pode ser configurado para gerar um gerador de criptograficamente seguro número pseudo-aleatório (CSPRNG) como o valor da chave privada do UE.Um valor de chave pública UE também está ser gerado de um modo não- determinista pelo processador 111. Os valores de chave públicas e privadas UE pode ser gerado antes da execução do processo 700, e armazenado na memória no dispositivo móvel e recuperados como requerido. No exemplo LTE na figura 5, o dispositivo móvel 100 pode e fornecer o PFS NAS mensagem de resposta de autenticação 518 à MME 206, incluindo um valor RES e o público UE valor de chave (ou seja, DHEpubKeyUE).
[0057] Na fase 710, o emissor-receptor sem fio 121 e o processador 111 no dispositivo móvel estão configurados para receber um valor de chave pública da rede a partir da rede. Por exemplo, o dispositivo mel 100 pode ser configurada para receber uma mensagem NAS PFS SMC 520 a partir da rede 502 (por exemplo, a partir do MME 206 através do eNB 204). A mensagem PFS NAS SMC 520 pode incluir a chave pública da rede (por exemplo, DHEpubKeyMME), bem como a confidencialidade e integridade algoritmos.
[0058] Na etapa 712, o processador 111 no dispositivo móvel 100 é configurado para determinar um valor de chave compartilhada com base no valor de chave pública de rede e o valor da chave privada UE. Por exemplo, o processador 11, um está configurado para derivar um Diffie-Hellman chave comum (isto é, sharedDHEkey) com base no valor de rede recebido de chave pública (ou seja, DHEpubKeyMME) e o gerado anteriormente UE p valor de chave privada (DHEpriKeyUE).
[0059] Na fase 714, o processador 111 no dispositivo móvel 100 está configurado para ligar-se o valor da chave partilhada com um valor de chave de sessão e utilizar o valor da chave partilhada vinculado para proteger o tráfego de rede posterior. A vinculação do valor de chave partilhada com o valor da chave de sessão pode incluir a realização de um hash criptográfico na concatenação do valor de chave partilhada com o valor da chave de sessão (por exemplo, SHA256 (compartilhado chave, chave de raiz)). Com referência à figura 5, o valor da chave comum (isto é, sharedDHEkey) está vinculado ao valor KASME. O valor de chave partilhada vinculado resultante é designado como K'ASME e pode ser gerado com base numa função de derivação de chave (KDF) de KASME e a chave partilhada. Ou seja, K'ASME = KDF (KASME, sharedDHEkey). O KDF pode ser uma função hash de criptografia (por exemplo, SHA256, SHA512, SHA-3, etc.). O valor K'ASME resultante (isto é,o valor da chave compartilhada vinculado) é usado como o valor KASME na rede LTE. Ou seja, o valor da chave compartilhada vinculado é usado para proteger o tráfego de rede posterior.
[0060] Com referência à figura 8, ainda com referência às figuras 1-6, um processo 800 para fornecer comunicações seguras com um servidor de rede inclui as etapas mostradas. O processo 800 é, no entanto, apenas um exemplo e não limitativo. O processo 800 pode ser alterada, por exemplo, por ter as fases adicionados, removidos, rearranjado, combinados, e/ou realizados simultaneamente. Por exemplo, rede pública e os valores de chave privada pode ser pré-computados e armazenados na memória e recuperados conforme exigido pelo processo de 800. O processo 800 pode executar no sistema de computador 300, que também é um exemplo de uma MME 206 i o sistema de comunicação n 200.
[0061] Na fase 802, o subsistema de comunicações 330 e do processador (s) 310 no sistema de computador 300 está configurado para receber uma solicitação de anexar a partir de um UE. Em um exemplo, a solicitação anexar pode incluir um indicador de suporte PFS opcional. A rede 502 pode incluir um sistema de computador 300 como um meio para receber um pedido de anexar. No exemplo LTE na figura 5, a rede 502 recebe o PFS NAS solicitação de anexação 510 a partir de um UE 202. As NAS PFS anexar solicitação inclui a informação de identificação (por exemplo, IMSI) e pode, opcionalmente, incluir uma informação PFS Elemento UE (IE). O opcional UE PFS IE é um campo de dados (por exemplo, pouco booleano, ou outros caracteres) configurado para indicar que o UE 202 suporta a propriedade PFS. O PFS NAS solicitação de anexação 510 é enviado do UE 202 para a MME 206.
[0062] Na fase 804, o subsistema de comunicações 330 e do processador (s) 310 no sistema de computador 300 são configurados para proporcionar um pedido de autenticação, incluindo um indicador de suporte de rede para um recurso de rede. Os procedimentos padrão AKA requerem uma rede (por exemplo, uma MME) para solicitar um vetor de autenticação a partir da rede local (por exemplo, o HSS). A adição de PFS para o protocolo AKA melhora a resistência da segurança no sistema de comunicação 200. Assume-se que um UE de PFS apoio rede local. Uma vez que existem potencialmente muitas redes diferentes disponíveis para a UE, no entanto, é possível que a UE possa anexar a uma rede que não suporta PFS. Por isso, é também possível que um intruso pode tentar baixar o protocolo solicitado ‘AKA com PSF’ para um protocolo ‘AKA sem PFS’. O processo 800 pode eliminar esse risco, exigindo a rede para indicar a sua capacidade para suportar PFS para rede local. No exemplo LTE, essa indicação é incluído em na mensagem de informação de solicitação de autenticação PFS 512 como uma indicação de que a rede suporta uma propriedade PFS (por exemplo, o MME (SN) PFS elemento informacional). A solicitação de autenticação é normalmente uma mensagem de protocolo de diâmetro com pares de valores de atributo (AVP) como elementos informativos, mas em outras redes outro valor de dados ou tipos pode ser usado para indicar que uma rede de trabalho suporta a propriedade PFS.
[0063] Na fase 808, o subsistema de comunicações 330 e o processador (es) 310 são configurados para receber um token de autenticação a partir do recurso de rede, de tal modo que o token de autenticação inclui uma indicação de que a rede suporta o PFS. Em resposta a receber o pedido de autenticação fornecida na etapa 804, o recurso de rede pode resposta com um ou mais vetores de autenticação. Os vetores de autenticação incluem um token de autenticação que é protegida a integridade entre o recurso de rede e o UE. O valor do token de autenticação é baseado, pelo menos em parte, no indicador de suporte de rede. Isto é, o token de autenticação é configurado para indicar se ou não a rede (por exemplo, a rede que desde que o pedido de autenticação na fase 804) suporta PFS. Por exemplo, o token de autenticação pode ser o campo AUTN na informação de autenticação PFS mensagem de resposta 514. O token de autenticação pode incluir um campo de dados (por exemplo, bits, bytes) como a indicação de que uma rede suporta PFS (por exemplo, o bit de PFS na AUTN).
[0064] Na fase 810, o subsistema de comunicações 330 e o processador (es) 310 são configurados para fornecer o token de autenticação para o UE. No exemplo LTE, o token de autenticação pode ser fornecido por meio de um rato (por exemplo, eNB 204) e incluído em um dos PFS NAS mensagens de pedido de autenticação 516, 616 (ou seja, o valor AUTN). Na etapa 812, a rede é configurada para receber uma resposta de autenticação, incluindo um valor de chave pública UE. O subsistema de comunicações 330 no computador 300 é um meio para receber uma resposta de autenticação. Por exemplo, a mensagem de resposta de autenticação pode ser a resposta de autenticação PFS NAS 518 incluindo o valor RES e o valor da chave pública UE (ou seja, DHEpubKeyUE).
[0065] Na fase 814, o processador (es) 310 é configurado para determinar se a resposta de autenticação recebida na etapa 812 é uma resposta esperada. Uma resposta esperada, por exemplo, é aquela em que um valor de resposta (por exemplo, RES) é igual a um valor de resposta esperado previamente armazenado (por exemplo, XRES). No exemplo LTE, o valor RES é incluído na mensagem de resposta de autenticação PFS NAS 518, e o valor XRES foi incluído num vetor de autenticação recebido do recurso de rede. O processador (s) 310 é configurado para executar uma operação de comparação lógica sobre os dois valores. Se eles não corresponderem, anexar da UE pedido é negado na fase 818.
[0066] Na fase 806, o processador (s) 310 no sistema de computador 300 é configurado para gerar um valor de chave pública da rede e um valor da chave privada de rede. O público da rede e valores de chave privada pode ser Diffie-Hellman pares que são gerados usando criptografia de curva elíptica. Outros métodos não determinísticos (por exemplo, os resultados de um CSPRNG) também podem ser utilizados para gerar as chaves. Um grupo de chaves pode ser pré-gerado antes da execução do processo 800 e armazenado em uma memória. Um par de chaves pode ser recuperado a partir da memória como exigido pelo processo de 800.
[0067] Na fase 816, o processador (s) 310 é configurado para determinar um valor de chave partilhada com base no valor de chave privada de rede e no valor da chave pública do UE. O valor de chave compartilhada é uma chave compartilhada Diffie-Hellman (ou seja, sharedDHEkey) com base na chave pública recebida do UE (ou seja, DHEpubKeyUE), na fase 812 e a chave privada gerada na fase 806.
[0068] Na fase 820, o processador (s) 310 é configurado para vincular o valor da chave partilhada com um valor de chave de sessão e utilizar o valor vinculado da chave compartilhada para proteger o tráfego de rede posterior. Em geral, um valor de chave de sessão é derivado de uma chave de raiz simétrica que é compartilhada entre o UE e o recurso de rede. Um exemplo de uma chave de sessão nos procedimentos de AKA é o valor da chave KASME. O valor de chave partilhada pode ser vinculado ao valor da chave de sessão (por exemplo, KASME) por meio de uma função de derivação de chave (KDF). O KDF pode ser uma função hash de criptografia (por exemplo, SHA256, SHA512, SHA-3, etc.). Também podem ser utilizados outros algoritmos de ligação. No exemplo de LTE descrito na figura 5, a chave compartilhada vinculada é K'ASME, que é gerada com uma função KDF (por exemplo, K'ASME = KDF (KASME, sharedDHEkey)). O valor de K'ASME pode ser usado como o valor KASME para proteger o tráfego posterior na rede LTE.
[0069] Com referência à figura 9, com referência adicional às figuras 1-6, um processo 900 para a prevenção de um ataque de tentativa sobre um sistema com um protocolo de segurança forte inclui as etapas mostradas. O processo 900, no entanto, é apenas um exemplo e não é limitador. O processo 900 pode ser alterado, por exemplo, por ter estágios adicionados, removidos, rearranjados, combinados, e/ou realizados simultaneamente. O processo 900 pode executar no sistema de computador 300, que está incluído na rede 502.
[0070] Na fase 902, o subsistema de comunicações 330 e o processador (es) 310 no sistema de computador 300 está configurado para receber uma solicitação de anexação a partir de um equipamento de usuário. Em um exemplo, um protocolo de segurança robusta suporta uma propriedade PFS. Portanto, em uma comparação relativa, um procedimento AKA que suporta PFS é mais forte do que um procedimento AKA que não suporta PFS. No exemplo LTE, a UE 202 está configurado para enviar uma solicitação de anexação PFS NAS 510 para um sistema de computador 300.
[0071] Na fase 904, o subsistema de comunicações 330 e o processador (es) 310 no sistema de computador 300 são configurados para enviar uma solicitação de autenticação a uma rede local, de tal modo que o pedido de autenticação inclui uma indicação de que a rede suporta um protocolo de segurança robusta. Em um exemplo, o sistema de computador 300 está configurado para solicitar vetores de autenticação da rede local, e gerar um pedido de autenticação, incluindo as informações de segurança associado com o equipamento de usuário (por exemplo, IMSI), e campos de dados que indica um tipo de rede (por exemplo, E-UTRAN), e uma indicação de que a rede suporta o protocolo de segurança forte. O PFS informação de autenticação pedido mensagem 512 é um exemplo do pedido de autenticação enviado na fase 904. O elemento informacional MME (SN) PFS correspondente é um exemplo de uma indicação de que a rede suporta o protocolo de segurança forte (por exemplo, com AKA PFS). O pedido de autenticação ajuda a impedir que um intruso (MiM) baixe a AKA com PFS para um protocolo padrão AKA. Em um exemplo, um MIM (por exemplo, uma estação), que pode interceptar a solicitação de anexação recebida na fase 902 não pode enviar a solicitação de anexação para a rede local porque a mensagem encaminhada resultante não iria incluir uma indicação de que a rede suporta o protocolo de segurança robusta (por exemplo, AKA com PFS).
[0072] Na fase 906, o subsistema de comunicações 330 e o processador (es) 310 no sistema de computador 300 está configurado para receber um token de integridade protegida a partir da rede local, de modo que o token de integridade protegida inclui pelo menos um bit configurado para indicar que a rede suporta a protocolo de segurança robusta. O token de integridade protegida fornece proteção de integridade entre o equipamento de usuário e da rede local. No exemplo de LTE, o token de autenticação AUTN é um token de integridade protegida. No AUTN, um campo no campo de gerenciamento de autenticação (AMF) pode ser definido para indicar que a rede suporta a propriedade PFS (por exemplo, um bit Booleano é definido como 1). O bit PFS na AUTN é um exemplo de, pelo menos, um bit configurado para indicar que a rede suporta o protocolo de segurança forte. Por exemplo, se uma rede suporta o protocolo de segurança forte, o bit PFS pode ser definido como um valor para indicar que o protocolo de segurança robusto é suportado (por exemplo, o bit PFS é definido como 1). Por outro lado, se o protocolo de segurança robusto não é suportado pela rede, o bit PFS pode ser definido como zero.
[0073] Na fase 908, o subsistema de comunicações 330 e o processador (es) 310 no sistema de computador 300 são configurados para enviar o token de integridade protegida para o equipamento de usuário. O equipamento de usuário pode ser configurado para interpretar o, pelo menos, um bit do token de integridade protegida para determinar se a rede suporta o protocolo de segurança forte. No exemplo LTE descrito na figura 5, o equipamento de usuário pode ser configurado para determinar se o bit PFS no valor AUTN indica que a propriedade PFS é suportada. Se o bit de PFS está definido (e os outros valores de autenticação são válidos), então o equipamento do usuário fornece uma chave pública Diffie-Hellman para a rede. A chave pública é um componente do protocolo de segurança robusta que não é necessário para um protocolo de segurança relativamente mais fraca (por exemplo, sem AKA PFS). Se o bit de PFS no token de integridade protegida não está definido (por exemplo, valor de zero), então o equipamento de usuário pode ser configurado para responder em conformidade com o protocolo de segurança mais fraca. Como o token de integridade protegida fornece proteção entre o equipamento do usuário e a rede local, o protocolo de segurança robusto não pode baixar para o protocolo de segurança fraca porque um intruso não pode alterar o valor do token de integridade protegida.
[0074] Os procedimentos de autenticação com uma propriedade PFS não estão limitados aos fluxos de chamada representados nas figuras 5 e 6. Por exemplo, em cenários de mobilidade, o UE pode iniciar uma mensagem de solicitação de serviço ou atualização de área de localização ou atualização de área de Rastreamento (TAU) em vez da solicitação de anexação NAS PFS 510. O UE pode, opcionalmente, indicar o seu suporte PFS nessas mensagens (por exemplo, incluindo um UE PFS IE). Assim, se o MME mudou ou se o MME decidir dar início a um novo AKA, então, uma nova AKA com propriedade PFS pode ser executada conforme necessário. Além disso, propriedade PFS pode ser implementada para segurança de camada de acesso (AS). Semelhante a KASME (e outras chaves de segurança NAS), os métodos de DHE efêmeros descritos acima podem ser utilizados para configurar as chaves de segurança com uma propriedade PFS entre o eNB e o UE. O KeNB e outras chaves de segurança AS podem ser vinculados a um sharedDHEkey derivada entre o KeNB e o UE. Por exemplo, o eNB 204 e o UE 202 podem trocar chaves públicas DHE usando uma troca de mensagens RRC (por exemplo RRCConnectionSetupComplete e Comando de Modo de Segurança RRC) para trocar respectivas chaves públicas Diffie-Hellman e configurar as chaves de segurança com uma propriedade PFS. Essa implementação de uma propriedade PFS impede compromisso de confidencialidade de tráfego aéreo (OTA) anterior entre o UE e o eNB se as chaves de nível NAS (por exemplo KASME) que são usadas para derivar como chaves de segurança forem comprometidas no futuro. Isso pode acontecer quando o UE muda entre os modos inativos e ativos, ou quando o UE se move para um diferente eNB durante mobilidade modo ocioso.
[0075] Variações substanciais podem ser feitas de acordo com desejos específicos. Por exemplo, hardware personalizado pode também ser utilizado, e/ou elementos específicos podem ser implementados em hardware, software (incluindo software portátil, como applets, etc.), ou ambos. Além disso, pode ser empregada conexão com outros dispositivos de computação, tais como os dispositivos de entrada/saída de rede.
[0076] Um sistema de computador (tal como o sistema de computador 300) pode ser usado para realizar os métodos de acordo com a revelação. Alguns ou todos os procedimentos de tais métodos podem ser realizadas pelo sistema de computador 300 em resposta ao processador 310 executando uma ou mais sequências de uma ou mais instruções (que podem ser incorporadas no sistema operacional 340 e/ou outro código, tal como um programas de aplicação 345) contidos na memória de trabalho 335. Tais instruções podem ser lidas na memória de trabalho 335 a partir de outro meio legível por computador, tal como um ou mais do dispositivo (s) de armazenamento 325. Simplesmente a título de exemplo, a execução das sequências de instruções contidas na memória de trabalho 335 pode fazer com que o processador (es) 310 execute um ou mais procedimentos dos métodos descritos aqui.
[0077] Os termos: “meio legível por máquina” e “meio legível por computador”, como utilizados aqui, referem-se a qualquer meio que participe no fornecimento de dados que faz com que uma máquina funcione de uma forma específica. Numa modalidade implementada utilizando o dispositivo móvel 100 e/ou o sistema de computador 300, vários meios legíveis por computador podem estar envolvidas no fornecimento de instruções/código para processador (es) 111, 310 para a execução e/ou podem ser usados para armazenar e/ou transportar tais instruções/código (por exemplo, como sinais). Em muitas implementações, um meio legível por computador é um meio de armazenamento físico e/ou tangível. Tal meio pode assumir muitas formas, incluindo, mas não limitado a, meios não voláteis, meios voláteis, e meios de transmissão. Meios não voláteis incluem, por exemplo, discos ópticos e/ou magnéticos, tais como o dispositivo de armazenamento (s) 140, 325. Meios voláteis incluem, sem limitação, a memória dinâmica, como a memória de trabalho 140, 335. Os meios de transmissão incluem, sem limitação, os cabos coaxiais, fios de cobre e as fibras ópticas, incluindo os fios que constituem o barramento 101, 305, bem como os vários componentes do subsistema de comunicações 330 (e/ou os meios de comunicação, através da qual o subsistema de comunicações 330 proporciona comunicação com outros dispositivos). Por isso, meios de transmissão também pode assumir a forma de ondas de rádio (incluindo, sem limitação, ondas acústicas e/ou de luz, tais como as que são gerados durante comunicações de dados de infravermelhos e ondas de rádio).
[0078] As formas comuns de mídia legível por computador física ou tangível incluem, por exemplo, um disquete, um disco flexível, disco rígido, fita magnética ou qualquer outro meio magnético, um CD-ROM, um disco físico/ou Blu-Ray, qualquer outro meio tico, cartões perfurados, fita de papel, qualquer outro meio físico com padrões de furos, uma RAM, um PROM, EPROM, uma FLASH-EPROM, qualquer outro chip de memória ou cartucho, uma onda portadora, tal como descrito a seguir, ou qualquer outro meio a partir do qual um computador pode ler as instruções e/ou código.
[0079] Diversas formas de meios legíveis por computador podem estar envolvidas na execução de uma ou mais sequências de uma ou mais instruções o processador (es) 111, 310 para a execução. Apenas a título de exemplo, as instruções podem inicialmente ser realizadas em um disco magnético e/ou de disco óptico de um computador remoto. Um computador remoto pode carregar as instruções em sua memória dinâmica e enviar as instruções como sinais através de um meio de transmissão para serem recebidos e/ou executados pelo dispositivo móvel 100 e/ou sistema de computador 300. Estes sinais, que pode estar na forma de sinais eletromagnéticos, sinais acústicos, os sinais ópticos e/ou similares, são exemplos de ondas portadoras nas quais podem ser codificadas instruções, de acordo com várias modalidades da invenção.
[0080] Os métodos, sistemas e dispositivos discutidos acima são exemplos. Várias configurações alternativas podem omitir, substituir, ou adicionar vários procedimentos ou componentes conforme apropriado. Por exemplo, em métodos alternativos, estágios podem ser executados em ordens diferentes a partir da discussão acima, e vários estágios podem ser adicionados, omitidos, ou combinados. Além disso, as características descritas em relação a determinadas configurações podem ser combinadas em várias outras configurações. Diferentes aspectos e elementos das configurações podem ser combinados de uma maneira semelhante. Além disso, a tecnologia evolui e, portanto, muitos dos elementos são exemplos e não limitam o escopo da revelação ou das reivindicações.
[0081] Os detalhes específicos são dados na descrição para fornecer uma completa compreensão dos exemplos de configuração (incluindo implementações). No entanto, as configurações podem ser praticadas sem estes detalhes específicos. Por exemplo, circuitos, processos, algoritmos, estruturas e técnicas bem conhecidos têm sido mostrados sem detalhes desnecessários, de modo a evitar obscurecer as configurações. Esta descrição fornece configurações de exemplo apenas, e não limitam o escopo, aplicabilidade, ou configurações das reivindicações. Em vez disso, a descrição precedente das configurações proporcionará aos versados na arte uma descrição que permita a implementação de técnicas descritas. Várias alterações podem ser feitas na função e arranjo de elementos sem se afastar do espírito ou âmbito da revelação.
[0082] As configurações podem ser descritas como um processo que é descrito como um diagrama de fluxo ou diagrama de blocos. Embora cada uma possa descrever as operações como um processo sequencial, muitas das operações podem ser realizadas em paralelo ou simultaneamente. Além disso, a ordem das operações pode ser rearranjada. Um processo pode ter etapas adicionais não incluídas na figura. Além disso, os exemplos dos métodos podem ser implementados por hardware, software, firmware, middleware, ou microcódigo, linguagens de descrição de hardware, ou qualquer combinação dos mesmos. Quando implementado em software, firmware, middleware, ou microcódigo, o código de programa ou segmentos de código para executar as tarefas necessárias pode ser armazenado em um meio legível por computador não transitório, como um meio de armazenamento. Processadores podem executar as funções descritas.
[0083] Tal como aqui utilizado, incluindo nas reivindicações, “ou”, como utilizado em uma lista de itens precedidos por “pelo menos um de” indica uma lista disjuntiva de tal modo que, por exemplo, uma lista de ”pelo menos um de A, B, ou C” significa A ou B ou C ou AB ou AC ou BC ou ABC (isto é, A e B e C), ou combinações com mais do que uma característica (por exemplo, AA, AAB, ABBC, etc.).
[0084] Tal como aqui utilizado, incluindo nas reivindicações, a menos que indicado de outra forma, uma indicação de que uma função ou operação é “baseada em” um item ou condição significa que a função ou operação baseia- se no item ou condição indicada e pode ser baseada em um ou mais itens e/ou condições, além do item ou condição indicada.
[0085] Tendo descrito diversas configurações exemplares, diversas modificações, construções alternativas e equivalentes podem ser utilizadas sem se afastar do espírito da revelação. Por exemplo, os elementos acima mencionados podem ser componentes de um sistema maior, em que outras regras podem ter precedência sobre ou de outro modo modificar a aplicação da invenção. Além disso, certo número de etapas pode ser realizado antes, durante, ou após os elementos acima serem considerados. Por conseguinte, a descrição acima não limita o âmbito das reivindicações.

Claims (15)

1. Método (800, 900) para prevenir um ataque de tentativa em um sistema com um protocolo de segurança robusto, o método caracterizado por compreende: receber (802, 902) uma solicitação de anexação a partir de um equipamento de usuário; enviar (804, 904) uma solicitação de autenticação para uma rede local, em que a solicitação de autenticação inclui uma indicação de que a rede suporta o protocolo de segurança robusto; receber (808, 906) um token de integridade protegida a partir da rede local, em que o token de integridade protegida inclui pelo menos um bit configurado para indicar que a rede suporta o protocolo de segurança robusto, e em que o token de integridade protegida é incluído em um vetor de autenticação; e enviar (810, 908) o token de integridade protegida para o equipamento de usuário.
2. Método (800, 900), de acordo com a reivindicação 1, caracterizado pelo fato de que a solicitação de anexação inclui uma indicação de que o equipamento de usuário suporta o protocolo de segurança robusto.
3. Método (800, 900), de acordo com a reivindicação 1, caracterizado pelo fato de que o protocolo de segurança robusto é um protocolo de acordo de autenticação e chave com sigilo perfeito de emissão.
4. Método (800, 900), de acordo com a reivindicação 1, caracterizado pelo fato de que a solicitação de autenticação é uma mensagem de protocolo de diâmetro com Pares de Valores de Atributo, AVP, como elementos de informação para indicar que a rede suporte o protocolo de segurança robusto.
5. Método (800, 900), de acordo com a reivindicação 1, caracterizado pelo fato de que pelo menos um bit é incluído em um Campo de Gerenciamento de Autenticação, AMF.
6. Memória legível por processador não transitório, caracterizada pelo fato de que compreende instruções para prevenir um ataque de tentativa em um sistema com um protocolo de segurança robusto, as instruções compreendendo: código para receber (802, 902) uma solicitação de ataque a partir de um equipamento de usuário; código para enviar (804, 904) uma solicitação de autenticação para uma rede local, em que a solicitação de autenticação inclui uma indicação de que uma rede suporta o protocolo de segurança robusto; código para receber (808, 906) um token de integridade protegida a partir da rede local, em que o token de integridade protegida inclui pelo menos um bit configurado para indicar que a rede suporta o protocolo de segurança robusto, e em que o token de integridade protegida é incluído em um vetor de autenticação; e código para enviar (810, 908) o token de integridade protegida para o equipamento de usuário.
7. Memória legível por processador não transitório, de acordo com a reivindicação 6, caracterizada pelo fato de que a solicitação de anexação inclui uma indicação de que o equipamento de usuário suporte o protocolo de segurança robusto.
8. Memória legível por processador não transitório, de acordo com a reivindicação 6, caracterizada pelo fato de que o protocolo de segurança robusto é um protocolo de acordo de autenticação e chave com sigilo perfeito de emissão.
9. Memória legível por processador não transitório, de acordo com a reivindicação 6, caracterizada pelo fato de que a solicitação de autenticação é uma mensagem de protocolo de diâmetro com Pares de Valores de Atributo, AVP, como elementos de informação para indicar que a rede suporte o protocolo de segurança robusto.
10. Memória legível por processador não transitório, de acordo com a reivindicação 6, caracterizada pelo fato de que pelo menos um bit é incluído em um Campo de Gerenciamento de Autenticação, AMF.
11. Sistema de computador (300) para prevenir um ataque de tentativa em um sistema com um protocolo de segurança robusto, o sistema caracterizado pelo fato de que compreende: uma memória (325, 335); pelo menos um processador (310) acoplado de forma operável à memória e configurado para: receber (802, 902) uma solicitação de anexação a partir de um equipamento de usuário; enviar (804, 904) uma solicitação de autenticação para uma rede local, em que a solicitação de autenticação inclui uma indicação de que a rede suporta o protocolo de segurança robusto; receber (808, 906) um token de integridade protegida a partir da rede local, em que o token de integridade protegida inclui pelo menos um bit configurado para indicar que a rede suporta o protocolo de segurança robusto, e em que o token de integridade protegida é incluído em um vetor de autenticação; e enviar (810, 908) o token de integridade protegida para o equipamento de usuário.
12. Sistema de computador (300), de acordo com a reivindicação 11, caracterizado pelo fato de que a solicitação de anexação inclui uma indicação de que o equipamento de usuário suporta o protocolo de segurança robusto.
13. Sistema de computador (300), de acordo com a reivindicação 11, caracterizado pelo fato de que o protocolo de segurança robusto é um protocolo de acordo de autenticação e chave com sigilo perfeito de emissão.
14. Sistema de computador (300), de acordo com a reivindicação 11, caracterizado pelo fato de que a solicitação de autenticação é uma mensagem de protocolo de diâmetro com Pares de Valores de Atributo, AVP, como elementos de informação para indicar que a rede suporte o protocolo de segurança robusto.
15. Sistema de computador (300), de acordo com a reivindicação 11, caracterizado pelo fato de que pelo menos um bit é incluído em um Campo de Gerenciamento de Autenticação, AMF.
BR112017020675-7A 2015-03-30 2016-03-03 Acordo de autenticação e chave com sigilo perfeito de emissão BR112017020675B1 (pt)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201562140426P 2015-03-30 2015-03-30
US201562140331P 2015-03-30 2015-03-30
US62/140,331 2015-03-30
US62/140,426 2015-03-30
US14/825,988 2015-08-13
US14/825,988 US9801055B2 (en) 2015-03-30 2015-08-13 Authentication and key agreement with perfect forward secrecy
PCT/US2016/020545 WO2016160256A1 (en) 2015-03-30 2016-03-03 Authentication and key agreement with perfect forward secrecy

Publications (2)

Publication Number Publication Date
BR112017020675A2 BR112017020675A2 (pt) 2018-06-26
BR112017020675B1 true BR112017020675B1 (pt) 2024-01-23

Family

ID=55650686

Family Applications (1)

Application Number Title Priority Date Filing Date
BR112017020675-7A BR112017020675B1 (pt) 2015-03-30 2016-03-03 Acordo de autenticação e chave com sigilo perfeito de emissão

Country Status (9)

Country Link
US (2) US9801055B2 (pt)
EP (2) EP3731490B1 (pt)
JP (1) JP6759232B2 (pt)
KR (1) KR102547749B1 (pt)
CN (1) CN107409133B (pt)
AU (1) AU2016243284B2 (pt)
BR (1) BR112017020675B1 (pt)
ES (1) ES2824527T3 (pt)
WO (1) WO2016160256A1 (pt)

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015177398A1 (en) * 2014-05-20 2015-11-26 Nokia Technologies Oy Cellular network authentication control
US9717003B2 (en) * 2015-03-06 2017-07-25 Qualcomm Incorporated Sponsored connectivity to cellular networks using existing credentials
US9801055B2 (en) 2015-03-30 2017-10-24 Qualcomm Incorporated Authentication and key agreement with perfect forward secrecy
US9800578B2 (en) * 2015-10-27 2017-10-24 Blackberry Limited Handling authentication failures in wireless communication systems
SG10201509342WA (en) * 2015-11-12 2017-06-29 Huawei Int Pte Ltd Method and system for session key generation with diffie-hellman procedure
EP3185159A1 (en) * 2015-12-24 2017-06-28 Gemalto Sa Method and system for enhancing the security of a transaction
CN113055888B (zh) * 2016-01-05 2022-03-08 华为技术有限公司 移动通信方法、装置及设备
CN109644340B (zh) 2017-01-30 2022-09-13 瑞典爱立信有限公司 空闲模式期间5g中的安全性上下文处理的方法和装置
CN108574570B (zh) * 2017-03-08 2022-05-17 华为技术有限公司 私钥生成方法、设备以及系统
US11792172B2 (en) * 2017-05-05 2023-10-17 Nokia Technologies Oy Privacy indicators for controlling authentication requests
US11172359B2 (en) * 2017-08-09 2021-11-09 Lenovo (Singapore) Pte. Ltd. Method and apparatus for attach procedure with security key exchange for restricted services for unauthenticated user equipment
US11297502B2 (en) 2017-09-08 2022-04-05 Futurewei Technologies, Inc. Method and device for negotiating security and integrity algorithms
CN116866905A (zh) * 2017-09-27 2023-10-10 日本电气株式会社 通信终端和通信终端的方法
CN109699028B (zh) 2017-10-23 2020-08-25 华为技术有限公司 一种生成密钥的方法、装置及系统
WO2019089543A1 (en) * 2017-10-30 2019-05-09 Huawei Technologies Co., Ltd. Method and device for obtaining ue security capabilities
CN109756451B (zh) 2017-11-03 2022-04-22 华为技术有限公司 一种信息交互方法及装置
US10542428B2 (en) 2017-11-20 2020-01-21 Telefonaktiebolaget Lm Ericsson (Publ) Security context handling in 5G during handover
WO2019106451A1 (en) * 2017-11-30 2019-06-06 Telefonaktiebolaget Lm Ericsson (Publ) Serving-network based perfect forward security for authentication
CN111869182B (zh) * 2018-03-22 2023-01-17 英国电讯有限公司 对设备进行认证的方法、通信系统、通信设备
US11061920B2 (en) * 2018-03-28 2021-07-13 Opus Global, Inc. Application programming interfaces (“APIs”) for accessing and amalgamating data from incongruent sources
WO2019196800A1 (en) * 2018-04-10 2019-10-17 Mediatek Singapore Pte. Ltd. Improvement for incorrect ksi handling in mobile communications
FR3080730B1 (fr) * 2018-04-27 2020-10-09 Airbus Ds Slc Procede de configuration pour un acces a des services de repli de communication et systeme associe
CN110830991B (zh) * 2018-08-10 2023-02-03 华为技术有限公司 安全会话方法和装置
KR102460418B1 (ko) * 2018-11-21 2022-10-31 한국전자통신연구원 통신 시스템에서 제어 메시지의 송수신 방법 및 장치
US20220159457A1 (en) * 2019-03-13 2022-05-19 Telefonaktiebolaget Lm Ericsson (Publ) Providing ue capability information to an authentication server
US11108749B2 (en) * 2019-03-25 2021-08-31 Micron Technology, Inc. Secure device coupling
US11252652B2 (en) 2019-04-02 2022-02-15 Electronics And Telecommunications Research Institute Non-IP data delivery authorization update method and connection release method for non-IP data delivery, and device for performing the method
US11463875B2 (en) * 2019-04-26 2022-10-04 Qualcomm Incorporated Detection of system information modification using access stratum security mode command
US11638152B2 (en) * 2019-11-28 2023-04-25 Qualcomm Incorporated Identifying an illegitimate base station based on improper response
CN113098688B (zh) * 2020-01-09 2022-05-06 大唐移动通信设备有限公司 一种aka方法及装置
CN116847341A (zh) * 2020-08-31 2023-10-03 Oppo广东移动通信有限公司 一种网络连接方法及终端、待配网设备、存储介质
CN112468495B (zh) * 2020-11-26 2022-05-17 上海天旦网络科技发展有限公司 完全前向保密加密系统的降级监控方法、系统及介质
US20230246812A1 (en) * 2022-01-28 2023-08-03 Eagle Technology, Llc Communications system having crypto-variable array and associated methods

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4200770A (en) 1977-09-06 1980-04-29 Stanford University Cryptographic apparatus and method
US5764887A (en) * 1995-12-11 1998-06-09 International Business Machines Corporation System and method for supporting distributed computing mechanisms in a local area network server environment
EP1079565A3 (en) * 1999-08-25 2003-04-02 Activcard Ireland Limited Method of securely establishing a secure communication link via an unsecured communication network
CN1268088C (zh) * 2001-11-29 2006-08-02 东南大学 基于pki的vpn密钥交换的实现方法
US7647389B2 (en) * 2002-02-28 2010-01-12 Alcatel-Lucent Usa Inc. Method for configuration negotiation in a data communication system
CA2564909C (en) * 2004-04-30 2011-06-28 Research In Motion Limited Systems and methods to securely generate shared keys
MX2007005037A (es) * 2004-10-29 2007-06-19 Thomson Licensing Canal autorizado seguro.
AU2005312442C1 (en) * 2004-12-06 2010-07-08 Samsung Electronics Co., Ltd. Method, apparatus, and system for negotiating a session between an access terminal and an access network in a high rate packet data system
BRPI0611696B1 (pt) * 2005-06-13 2019-05-07 Nokia Technologies Oy Método, dispositivo e sistema para fornecer identidades de nós móveis em conjunto com preferências de autenticação em uma arquitetura de inicialização genérica
JP5123209B2 (ja) * 2006-01-24 2013-01-23 ▲ホア▼▲ウェイ▼技術有限公司 モバイルネットワークに基づくエンドツーエンド通信での認証の方法、システム、および認証センタ
DK1989853T3 (en) * 2006-02-23 2017-03-20 Togewa Holding Ag SWITCHING SYSTEM AND SIMILAR PROCEDURE FOR UNICAST OR MULTICAST TRANSMISSIONS FROM START TO END OF DATA AND / OR MULTIMEDIA FLOW BETWEEN NETWORK Nodes
CN100591013C (zh) * 2006-09-05 2010-02-17 华为技术有限公司 实现认证的方法和认证系统
US8255684B2 (en) * 2007-07-19 2012-08-28 E.F. Johnson Company Method and system for encryption of messages in land mobile radio systems
CN101282211B (zh) * 2008-05-09 2011-07-06 西安西电捷通无线网络通信股份有限公司 一种密钥分配方法
CN101286842B (zh) * 2008-05-26 2011-04-06 西安西电捷通无线网络通信股份有限公司 一种利用公钥密码技术的密钥分配及其公钥在线更新方法
CN101388770B (zh) * 2008-10-20 2012-08-22 华为技术有限公司 获取动态主机配置协议密钥的方法、服务器及客户端装置
US8848904B2 (en) 2008-10-24 2014-09-30 University Of Maryland, College Park Method and implementation for information exchange using Markov models
CN101800982B (zh) * 2010-01-15 2012-12-05 西安电子科技大学 无线局域网切换快速认证安全性增强方法
US8644515B2 (en) * 2010-08-11 2014-02-04 Texas Instruments Incorporated Display authenticated security association
US8897751B2 (en) * 2011-03-14 2014-11-25 Alcatel Lucent Prevention of eavesdropping type of attack in hybrid communication system
EP2715969B1 (en) 2011-05-31 2018-04-25 BlackBerry Limited System and method for authentication and key exchange for a mobile device via spectrally confined wireless communications
US8837741B2 (en) * 2011-09-12 2014-09-16 Qualcomm Incorporated Systems and methods for encoding exchanges with a set of shared ephemeral key data
CN104394528B (zh) * 2012-01-04 2018-03-27 华为技术有限公司 X2安全通道建立方法与系统、以及基站
US8683570B1 (en) * 2012-03-30 2014-03-25 Emc Corporation Scheduling soft token data transmission
CN104603813A (zh) * 2012-06-11 2015-05-06 英特托拉斯技术公司 数据收集和分析的系统和方法
TW201417598A (zh) 2012-07-13 2014-05-01 Interdigital Patent Holdings 安全性關聯特性
WO2014047135A2 (en) 2012-09-18 2014-03-27 Interdigital Patent Holdings, Inc. Generalized cryptographic framework
CN103929299B (zh) * 2014-04-28 2017-05-10 王小峰 地址即公钥的自安全轻量级网络报文传输方法
US9801055B2 (en) 2015-03-30 2017-10-24 Qualcomm Incorporated Authentication and key agreement with perfect forward secrecy

Also Published As

Publication number Publication date
US9801055B2 (en) 2017-10-24
AU2016243284B2 (en) 2020-06-18
EP3731490C0 (en) 2024-04-10
JP6759232B2 (ja) 2020-09-23
KR20170132184A (ko) 2017-12-01
ES2824527T3 (es) 2021-05-12
US20180020347A1 (en) 2018-01-18
US10178549B2 (en) 2019-01-08
EP3731490B1 (en) 2024-04-10
EP3278530B1 (en) 2020-07-15
AU2016243284A1 (en) 2017-09-07
EP3731490A1 (en) 2020-10-28
CN107409133A (zh) 2017-11-28
US20170006469A1 (en) 2017-01-05
WO2016160256A1 (en) 2016-10-06
CN107409133B (zh) 2020-06-19
EP3278530A1 (en) 2018-02-07
JP2018510578A (ja) 2018-04-12
KR102547749B1 (ko) 2023-06-23
BR112017020675A2 (pt) 2018-06-26

Similar Documents

Publication Publication Date Title
US10178549B2 (en) Authentication and key agreement with perfect forward secrecy
CN110786031B (zh) 用于5g切片标识符的隐私保护的方法和系统
US11330433B2 (en) Privacy key and message authentication code
EP3499840B1 (en) User-plane security for next generation cellular networks
US9918225B2 (en) Apparatuses and methods for wireless communication
US10057760B2 (en) Apparatus and methods for Electronic Subscriber Identity Module (ESIM) installation notification
US11974132B2 (en) Routing method, apparatus, and system
EP3146741B1 (en) Cellular network authentication control
US11997078B2 (en) Secured authenticated communication between an initiator and a responder
BR112017018018B1 (pt) Método operacional em um dispositivo cliente, dispositivo cliente,método operacional em um dispositivo gateway, dispositivo gateway e método operacional em um nó de acesso associado a um dispositivo cliente
BR112017019799B1 (pt) Método operacional em um dispositivo de usuário e dispositivo de usuário, método operacional em um dispositivo de rede de comunicação de longa distância sem fio e dispositivo de rede de comunicação de longa distância sem fio
BR112012031924B1 (pt) Método e equipamento para vincular autenticação de assinante e autenticação de dispositivo em sistemas de comunicação
JP6651613B2 (ja) ワイヤレス通信
CN109842881B (zh) 通信方法、相关设备以及系统

Legal Events

Date Code Title Description
B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B350 Update of information on the portal [chapter 15.35 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: 20 (VINTE) ANOS CONTADOS A PARTIR DE 03/03/2016, OBSERVADAS AS CONDICOES LEGAIS