ES2824527T3 - Autenticación y acuerdo de claves con secreto perfecto hacia adelante - Google Patents

Autenticación y acuerdo de claves con secreto perfecto hacia adelante Download PDF

Info

Publication number
ES2824527T3
ES2824527T3 ES16714086T ES16714086T ES2824527T3 ES 2824527 T3 ES2824527 T3 ES 2824527T3 ES 16714086 T ES16714086 T ES 16714086T ES 16714086 T ES16714086 T ES 16714086T ES 2824527 T3 ES2824527 T3 ES 2824527T3
Authority
ES
Spain
Prior art keywords
authentication
network
pfs
security protocol
strong security
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
ES16714086T
Other languages
English (en)
Inventor
Anand Palanigounder
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
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 Inc filed Critical Qualcomm Inc
Application granted granted Critical
Publication of ES2824527T3 publication Critical patent/ES2824527T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/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
    • 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/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

Un procedimiento (800, 900) para evitar un ataque por reducción de opciones de autenticación (bid-down) en un sistema con un protocolo de seguridad fuerte con propiedad de secreto perfecto hacia delante, comprendiendo el procedimiento: recibir (802, 902) una solicitud de conexión de un equipo de usuario; enviar (804, 904) una solicitud de autenticación a una red local, en el que la solicitud de autenticación incluye una indicación de que una red soporta el protocolo de seguridad fuerte; recibir (808, 906) un testigo de integridad protegida de la red local, en el que el testigo de integridad protegida incluye al menos un bit configurado para indicar que la red soporta el protocolo de seguridad fuerte, y en el que el testigo de integridad protegida se incluye en un vector de autenticación; y enviar (810, 908) el testigo de integridad protegida al equipo de usuario.

Description

DESCRIPCIÓN
Autenticación y acuerdo de claves con secreto perfecto hacia adelante
ANTECEDENTES
[0001] En general, un sistema de comunicación inalámbrica puede facilitar los procedimientos de autenticación entre una red y un dispositivo que intenta acceder a la red. Diferentes redes pueden tener diferentes procedimientos de autenticación. Un dispositivo puede incluir credenciales de seguridad usadas para autenticar al dispositivo antes de proporcionar acceso a la red. En algunos sistemas, las comunicaciones confidenciales pueden usar credenciales de seguridad que se almacenan en un módulo en el dispositivo y que acoplan el dispositivo a una red central. Por ejemplo, el protocolo de Autenticación y acuerdo de claves (AKA) ampliamente usado se basa en una clave raíz simétrica (K) que se comparte de forma segura entre el dispositivo (por ejemplo, un Módulo de identidad de abonado universal (USIM) extraíble) y la red (por ejemplo, un Servidor de abonados locales (HSS)). Otras redes pueden ser capaces de proporcionar otros tipos de garantías criptográficas para realizar intercambios seguros.
[0002] En las redes inalámbricas existentes que usan AKA, existe el riesgo de que si una clave raíz a largo plazo (por ejemplo, K) se ve comprometida, la confidencialidad de todas las comunicaciones pasadas se puede ver comprometida. Es decir, un atacante puede capturar comunicaciones cifradas pasadas y descifrarlas una vez que la clave raíz a largo plazo (K) se ve comprometida. También existe el riesgo de que redes que son capaces de proporcionar diferentes niveles de garantías criptográficas (por ejemplo, débiles y fuertes), puedan ser vulnerables a un ataque de intermediario (man-in-the-middle), de modo que una garantía criptográfica fuerte pueda reducirse a una solución más débil.
[0003] El documento "Simplification of bootstrapping procedure" de Adrian Escott describe conjuntos simplificados y armonizados de procedimientos de arranque.
BREVE EXPLICACIÓN
[0004] El alcance de protección está definido por las reivindicaciones independientes. Las características opcionales están incluidas en las reivindicaciones dependientes.
[0005] A continuación se explican brevemente algunos aspectos de la presente divulgación para proporcionar un entendimiento básico de la tecnología analizada. Esta breve explicación no es una visión general exhaustiva de todas las características contempladas de la divulgación y no pretende identificar elementos clave o críticos de todos los aspectos de la divulgación, ni delimitar el alcance de algunos o todos los aspectos de la divulgación. Su único propósito es presentar algunos conceptos de uno o más aspectos de la divulgación brevemente explicada como preludio de la descripción más detallada que se presenta posteriormente.
[0006] Un ejemplo de un procedimiento para proporcionar un protocolo de Autenticación y acuerdo de claves con Secreto perfecto hacia delante (PFS) entre un equipo de usuario y una red de acuerdo con la divulgación incluye generar, con el equipo de usuario, una solicitud de conexión, recibir, con el equipo de usuario, un testigo de autenticación, de modo que el testigo de autenticación incluya una indicación de soporte de PFS por la red, determinar, con el equipo de usuario, que la red soporta PFS, proporcionar, con el equipo de usuario, un valor de clave pública de UE a la red, recibir, con el equipo de usuario, un valor de clave pública de red de la red, determinar, con el equipo de usuario, un valor de clave compartida basado en el valor de clave pública de red y un valor de clave privada de UE, vincular, con el equipo de usuario, el valor de clave compartida con un valor de clave de sesión para crear un valor de clave compartida vinculada, y usar, con el equipo de usuario, el valor de clave compartida vinculada para proteger el tráfico de red posterior.
[0007] Las implementaciones de dicho procedimiento pueden incluir una o más de las características siguientes. La solicitud de conexión puede incluir una indicación de que el equipo de usuario soporta PFS. La generación en la solicitud de conexión puede incluir una solicitud de servicio, una solicitud de área de seguimiento o una solicitud de actualización de localización. Vincular el valor de clave compartida con el valor de clave de sesión puede incluir determinar un troceo (hash) criptográfico del valor de clave compartida y el valor de clave de sesión. El valor de clave de sesión puede ser Kasme, la clave de cifrado (CK) o la clave de integridad (IK). Proporcionar el valor de clave pública de UE a la red puede incluir generar un par Diffie-Hellman efímero usando criptografía de curva elíptica o usando aritmética de campos finitos. Determinar que la red no soporta PFS y rechazar una conexión a la red. El testigo de autenticación puede incluir un valor de bit del Campo de gestión de autenticación (AMF) establecido a 1 para indicar que la red soporta PFS.
[0008] Un aparato de ejemplo para proporcionar un protocolo de Autenticación y acuerdo de claves con Secreto perfecto hacia delante (PFS) entre el equipo de usuario (UE) y una red de acuerdo con la divulgación incluye una memoria, al menos un procesador acoplado operativamente a la memoria y configurado para recibir una solicitud de conexión de un UE, proporcionar una solicitud de autenticación que incluye un indicador de soporte de red a un recurso de red, recibir un testigo de autenticación del recurso de red, de modo que el testigo de autenticación incluya una indicación de que una red soporta PFS, proporcionar el testigo de autenticación al UE, recibir una respuesta de autenticación que incluya un valor de clave pública de UE, denegar la solicitud de conexión si la respuesta de autenticación no es una respuesta esperada, si la respuesta de autenticación es la respuesta esperada, entonces obtener un valor de clave pública de red y un valor de clave privada de red, determinar un valor de clave compartida basado en el valor de clave privada de red y el valor de clave pública de UE, vincular el valor de clave compartida con un valor de clave de sesión para crear un valor de clave compartida vinculada y usar el valor de clave compartida vinculada para proteger el tráfico de red posterior.
[0009] Las implementaciones de dicho aparato pueden incluir una o más de las características siguientes. El testigo de autenticación puede tener integridad protegida entre el UE y el recurso de red. Una solicitud de conexión recibida del UE puede incluir recibir una de una solicitud de servicio, una solicitud de área de seguimiento o una solicitud de actualización de localización en lugar de una solicitud de conexión. Se puede determinar un troceo criptográfico del valor de clave compartida y el valor de clave de sesión. El valor de clave de sesión puede ser al menos uno de KASME, clave de cifrado (CK) o clave de integridad (IK). El valor de clave compartida se puede determinar mediante criptología de curva elíptica o aritmética de campos finitos. La solicitud de conexión puede incluir una indicación de que el UE soporta PFS. El testigo de autenticación puede incluir un valor de bit del Campo de gestión de autenticación (AMF) establecido a 1 para indicar que la red soporta PFS.
[0010] Un ejemplo de un procedimiento para evitar un ataque por reducción de opciones de autenticación (bid-down) en un sistema con un protocolo de seguridad fuerte de acuerdo con la divulgación incluye recibir una solicitud de conexión de un equipo de usuario, enviar una solicitud de autenticación a una red local, de modo que la solicitud de autenticación incluya una indicación de que una red soporta el protocolo de seguridad fuerte, recibir un testigo de integridad protegida de la red local, de modo que el testigo de integridad protegida incluya al menos un bit configurado para indicar que la red soporta el protocolo de seguridad fuerte y enviar el testigo de integridad protegida al equipo de usuario.
[0011] Las implementaciones de dicho procedimiento pueden incluir una o más de las características siguientes. La solicitud de conexión puede incluir una indicación de que el equipo de usuario soporta el protocolo de seguridad fuerte. El protocolo de seguridad fuerte puede ser un protocolo de Autenticación y acuerdo de claves con Secreto perfecto hacia adelante. La solicitud de autenticación puede ser un mensaje de protocolo de diámetro con pares atributo-valor (AVP) como elementos de información para indicar que la red soporta el protocolo de seguridad fuerte. El testigo de integridad protegida se puede incluir en un vector de autenticación recibido de la red local. El al menos un bit se puede incluir en un Campo de gestión de autenticación (AMF).
[0012] Un medio de almacenamiento legible por procesador no transitorio de ejemplo que comprende instrucciones para evitar un ataque por reducción de opciones de autenticación en un sistema con un protocolo de seguridad fuerte de acuerdo con la divulgación incluye código para recibir una solicitud de conexión de un equipo de usuario, código para enviar una solicitud de autenticación a una red local, de modo que la solicitud de autenticación incluye una indicación de que una red soporta el protocolo de seguridad fuerte, código para recibir un testigo de integridad protegida de la red local, de modo que el testigo de integridad protegida incluya al menos un bit configurado para indicar que la red soporta el protocolo de seguridad fuerte y código para enviar el testigo de integridad protegida al equipo de usuario.
[0013] Las implementaciones de dicho medio de almacenamiento legible por procesador no transitorio pueden incluir una o más de las siguientes limitaciones. La solicitud de conexión puede incluir una indicación de que el equipo de usuario soporta el protocolo de seguridad fuerte. El protocolo de seguridad fuerte puede ser un protocolo de Autenticación y acuerdo de claves con Secreto perfecto hacia adelante. La solicitud de autenticación puede ser un mensaje de protocolo de diámetro con pares atributo-valor (AVP) como elementos de información para indicar que la red soporta el protocolo de seguridad fuerte. El testigo de integridad protegida se puede incluir en un vector de autenticación recibido de la red local. El al menos un bit se puede incluir en un Campo de gestión de autenticación (AMF).
[0014] Los elementos y/o técnicas descritos en el presente documento pueden proporcionar una o más de las siguientes capacidades, así como otras capacidades no mencionadas. Un dispositivo móvil puede proporcionar una indicación a una red para indicar que soporta Secreto perfecto hacia delante. Una red puede proporcionar a una red local un elemento de información para indicar que la red soporta Secreto perfecto hacia delante. La red local puede generar un testigo de integridad protegida y enviárselo al dispositivo móvil. El testigo de integridad protegida puede incluir un elemento de información para indicar que la red soporta Secreto perfecto hacia delante. El dispositivo móvil y la red pueden participar en un intercambio de Diffie-Hellman para generar una clave compartida. La clave compartida se puede usar para vincularse a una clave de sesión. La clave de sesión vinculada se puede usar para proteger el tráfico de red posterior. Se puede realizar un protocolo de Autenticación y acuerdo de claves con Secreto perfecto hacia delante. El potencial de un ataque por reducción de opciones de autenticación se puede reducir significativamente mediante el uso de un testigo de integridad protegida que incorpora Secreto perfecto hacia delante de red. Se pueden proporcionar otras capacidades, y no todas las implementaciones de acuerdo con la divulgación deben proporcionar una capacidad particular, y mucho menos todas las capacidades analizadas. Además, puede ser posible que se logre un efecto mencionado anteriormente por medios distintos a los señalados, y un elemento/técnica señalado no necesariamente produce el efecto señalado.
[0015] Otros aspectos, características y modos de realización de la presente invención resultarán evidentes a los expertos en la técnica, después de revisar la siguiente descripción de unos modos de realización ejemplares específicos de la presente invención junto con las figuras adjuntas. Aunque las características de la presente invención se pueden analizar en relación con determinados modos de realización y figuras proporcionados a continuación, todos los modos de realización de la presente invención pueden incluir una o más de las características ventajosas analizadas en el presente documento. En otras palabras, aunque al analizarlos se puede indicar que uno o más modos de realización tienen determinadas características ventajosas, también se puede usar una o más de dichas características de acuerdo con los diversos modos de realización de la invención analizados en el presente documento. De manera similar, aunque los modos de realización ejemplares se pueden analizar a continuación como modos de realización de dispositivo, sistema o procedimiento, se debe entender que dichos modos de realización ejemplares se pueden implementar en diversos dispositivos, sistemas y procedimientos.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
[0016]
La FIG. 1 es un diagrama de bloques de componentes de un modo de realización de un dispositivo móvil de acuerdo con algunos aspectos/modos de realización.
La FIG. 2 es un diagrama de bloques de un sistema de comunicación inalámbrica de ejemplo de acuerdo con algunos aspectos/modos de realización.
La FIG. 3 es un diagrama de bloques de un ejemplo de un sistema informático para su uso en el sistema de comunicación inalámbrica de la FIG. 2 de acuerdo con algunos aspectos/modos de realización.
La FIG. 4 es un diagrama de flujo de llamada de la técnica anterior de un procedimiento de autenticación de Evolución a largo plazo (LTE) del 3GPP.
La FIG. 5 es un diagrama de flujo de llamada de un procedimiento de autenticación de ejemplo con una propiedad de Secreto perfecto hacia delante (PFS) de acuerdo con algunos aspectos/modos de realización.
La FIG. 6 es un diagrama de flujo de llamada de otro procedimiento de autenticación de ejemplo con una propiedad de Secreto perfecto hacia delante (PFS).
La FIG. 7 es un diagrama de flujo de bloques de un proceso para proporcionar comunicaciones seguras con un dispositivo móvil de acuerdo con algunos aspectos/modos de realización.
La FIG. 8 es un diagrama de flujo de bloques de un proceso para proporcionar comunicaciones seguras con un servidor de red de acuerdo con algunos aspectos/modos de realización.
La FIG. 9 es un diagrama de flujo de bloques de un proceso para evitar un ataque por reducción de opciones de autenticación en un sistema con un protocolo de seguridad fuerte de acuerdo con la invención.
DESCRIPCIÓN DETALLADA
[0017] Se analizan técnicas para proporcionar Autenticación y acuerdo de claves (AKA) con Secreto perfecto hacia delante (PFS). Como se usa en el presente documento, el término Secreto perfecto hacia delante se refiere a la definición de criptografía de una propiedad de los protocolos de acuerdo de claves para ayudar a garantizar que una clave de sesión obtenida a partir de un conjunto de claves a largo plazo no se vea comprometida si una de las claves a largo plazo se ve comprometida en el futuro. El término perfecto como se usa en el presente documento no significa algo que esté completamente libre de fallos o defectos, o que esté lo más cerca posible de dicha condición. AKA es un protocolo de Autenticación y acuerdo de claves ampliamente usado en redes celulares modernas (por ejemplo, GSM, UMTS, LTE, eHRPD). AKA se especifica en 3g Pp TS 33.102. La seguridad de AKA se basa, en general, en una clave raíz simétrica (K) que se comparte de forma segura entre el UE (por ejemplo, típicamente almacenada en el USIM) y un servidor en la red local (por ejemplo, un Servidor de abonados locales (HSS)). AKA no proporciona Secreto perfecto hacia delante (PFS). Es decir, AKA no proporciona una clave de sesión que no se pueda ver comprometida si la clave a largo plazo (por ejemplo, K) se ve comprometida en el futuro. Como se analizará, en un modo de realización, las deficiencias de seguridad potenciales de AKA se pueden mitigar con propiedades de PFS. Por ejemplo, se puede producir un intercambio Diffie-Hellman efímero (DHE) entre un dispositivo móvil y un servidor de red. El dispositivo móvil y un servidor de red pueden determinar cada uno valores de clave privada individual y valores de clave pública. Las claves públicas se pueden intercambiar y combinar con las respectivas claves privadas para generar una clave compartida. La clave compartida resultante puede vincularse a una clave base en un vector de autenticación (por ejemplo, Kasme) y usarse para proteger las comunicaciones en la red. Los elementos de información de autenticación segura se pueden usar para garantizar que tanto el dispositivo móvil como el servidor de red soportan PFS. Los bits de autenticación segura pueden evitar ataques por reducción de opciones de autenticación (por ejemplo, ataques de intermediario).
[0018] Con referencia a la FIG. 1, se ilustra un dispositivo móvil 100 para el que se pueden usar diversas técnicas en el presente documento. El dispositivo móvil 100 es un equipo de usuario (UE) y puede incluir o implementar la funcionalidad de diversos dispositivos móviles de comunicación y/o informáticos; los ejemplos incluyen, pero no se limitan a, asistentes digitales personales (PDA), teléfonos inteligentes, dispositivos informáticos tales como ordenadores portátiles, ordenadores de escritorio o de tableta, sistemas informáticos de automóviles, etc., ya sean actuales o desarrollados en el futuro.
[0019] El dispositivo móvil 100 incluye un procesador 111 (o núcleo de procesador) y una memoria 140. El dispositivo móvil puede incluir opcionalmente un entorno fiable conectado operativamente a la memoria 140 mediante el bus público 101 o un bus privado (no mostrado). El dispositivo móvil 100 también puede incluir una interfaz de comunicación 120 y un transceptor inalámbrico 121 configurado para enviar y recibir señales inalámbricas 123 por medio de una antena inalámbrica 122 a través de una red inalámbrica. El transceptor inalámbrico 121 se conecta a un bus 101. Aquí, el dispositivo móvil 100 se ilustra teniendo un único transceptor inalámbrico 121. Sin embargo, un dispositivo móvil 100 puede tener de forma alternativa múltiples transceptores inalámbricos 121 y antenas inalámbricas 122 para soportar múltiples estándares de comunicación tales como Wi-Fi, CDMA, CDMA de banda ancha (WCDMA), Evolución a largo plazo (LTE), tecnología de comunicación inalámbrica de corto alcance BLUETOOTH, etc.
[0020] La interfaz de comunicación 120 y/o el transceptor inalámbrico 121 pueden soportar el funcionamiento multiportadora (señales de forma de onda de diferentes frecuencias). Los transmisores multiportadora pueden transmitir señales moduladas simultáneamente en las múltiples portadoras. Cada señal modulada puede ser una señal de acceso múltiple por división de código (CDMA), una señal de acceso múltiple por división de tiempo (TDMA), una señal de acceso múltiple por división ortogonal de frecuencia (OFDMA), una señal de acceso múltiple por división de frecuencia de portadora única (SC-FDMA), etc. Cada señal modulada se puede enviar en una portadora diferente y puede transportar datos piloto, información de cabecera, datos, etc.
[0021] El dispositivo móvil 100 también puede incluir una interfaz de usuario 150 (por ejemplo, pantalla, GUI), y un receptor de SPS 155 que recibe señales del sistema de posicionamiento por satélite (SPS) 159 (por ejemplo, desde satélites SPS) a través de una antena de SPS 158. El receptor de SPS 155 se puede comunicar con un único sistema de navegación por satélite global (GNSS) o con múltiples sistemas de este tipo. Un GNSS puede incluir, pero no se limita a, el Sistema de posicionamiento global (GPS), Galileo, Glonass, Beidou (Compass), etc. Los satélites de SPS también se denominan satélites, vehículos espaciales (SV), etc. El receptor de SPS 155 procesa, en su totalidad o en parte, las señales de SPS 159 y usa estas señales de SPS 159 para determinar la localización del dispositivo móvil 100. El procesador 111, la memoria 140, el DSP 112 y/o procesador(es) especializado(s) (no mostrado(s)) también se pueden usar para procesar las señales de SPS 159, en su totalidad o en parte, y/o para calcular la localización del dispositivo móvil 100, junto con el receptor de SPS 155. El almacenamiento de información de las señales de SPS 159 u otras señales de localización se realiza usando una memoria 140 o registros (no mostrados). Aunque que solo un procesador 111, un DSP 112 y una memoria 140 se muestran en la FIG. 1, el dispositivo móvil 100 podría usar más de uno, un par o todos estos componentes. El procesador 111 y el DSP 112 asociados con el dispositivo móvil 100 se conectan al bus 101.
[0022] La memoria 140 puede incluir un medio (o unos medios) de almacenamiento legible por ordenador no transitorio que almacena funciones como una o más instrucciones o código. Los medios que pueden componer la memoria 140 incluyen, pero no se limitan a, RAM, ROM, FLASH, unidades de disco, etc. En general, las funciones almacenadas por la memoria 140 se ejecutan mediante procesador(es) de propósito general 111, procesadores especializados o DSP 112. Por tanto, la memoria 140 es una memoria legible por procesador y/o una memoria legible por ordenador que almacena software (código de programación, instrucciones, etc.) configurado para provocar que el(los) procesador(es) 111 y/o el(los) DSP 112 realicen las funciones descritas. De forma alternativa, una o más funciones del dispositivo móvil 100 se pueden realizar en su totalidad o en parte en hardware.
[0023] Un dispositivo móvil 100 puede estimar su posición actual dentro de un sistema asociado usando diversas técnicas, basadas en otras entidades de comunicación dentro de la vista y/o en información disponible para el dispositivo móvil 100. Por ejemplo, un dispositivo móvil 100 puede estimar su posición usando la información obtenida de los puntos de acceso (AP) asociados con una o más redes inalámbricas de área local (LAN), redes de área personal (PAN) que usan una tecnología de comunicación inalámbrica de corto alcance tal como BLUETOOTH o ZIGBEE®, etc., satélites de SPS y/o datos restrictivos de mapas obtenidos de un servidor de mapas o un servidor LCI.
[0024] Haciendo referencia a continuación a la FIG. 2, se muestra un diagrama de bloques de un sistema de comunicación de ejemplo 200. El sistema de comunicación 200 puede incluir una red de acceso por radio (RAN) de Evolución a largo plazo (LTE) que proporciona comunicaciones por radio inalámbricas entre un UE 202 (es decir, un dispositivo móvil 100) y un Nodo B evolucionado (eNB) 204 (por ejemplo, una estación base, un punto de acceso, etc.) usando la tecnología de acceso por radio LTE. La red LTE en la FIG. 2 es solo ejemplar, ya que se pueden usar otras redes. Para simplificar el análisis, la FIG. 2 representa un UE 202 y un eNB 204, sin embargo, una RAN puede incluir cualquier número de UE y/o eNB. El eNB 204 transmite información al UE 202 a través de un enlace directo o canal de enlace descendente y el UE 202 puede transmitir información al eNB 204 a través de un enlace inverso o canal de enlace ascendente. Como se muestra, las RAN pueden usar cualquier tipo adecuado de tecnología de acceso por radio, tal como, pero sin limitarse a, LTE, LTE-A, HSPA, CDMA, datos por paquetes a alta velocidad (HRPD), HRPD evolucionado (eHRPD), CDMA2000, GSM, GPRS, velocidad de transferencia de datos mejorada para la evolución GSM (EDGE), UMTS o similares.
[0025] El eNB 204 se puede comunicar con una red central que permite tarificación (por ejemplo, tarificación por uso de servicios, etc.), seguridad (por ejemplo, cifrado y protección de integridad), gestión de abonados, gestión de movilidad, gestión de portadoras, gestión de QoS, control de políticas de flujos de datos y/o interconexiones con redes externas. La RAN y la red central se pueden comunicar a través de una interfaz S1, por ejemplo. La red central puede incluir una entidad de gestión de movilidad (MME) 206 que puede ser un punto final para la señalización de control de la pasarela de servicio (S-GW) 210. La MME 206 puede proporcionar funciones tales como gestión de movilidad (por ejemplo, seguimiento), autenticación y seguridad. La MME 206 se puede comunicar con la RAN a través de la interfaz S1. La pasarela de servicio (S-GW) 210 es un nodo del plano de usuario que conecta la red central a la RAN de LTE. La MME 206 se puede configurar para comunicarse con la S-GW 210 por medio de una interfaz S11. La MME 206 y la S-GW 210 se pueden configurar como un único nodo para proporcionar un único punto final para el usuario y señalización de control que se origina en una RAN y/o termina en una RAN. La red también puede incluir una Función de políticas y reglas de tarificación (PCRF) 212.
[0026] El sistema de comunicación 200 también puede incluir una pasarela (GW) de red de datos por paquetes (PDN) 214 que facilita las comunicaciones entre la red central (y las RAN) y redes externas. La PDN GW 214 puede proporcionar filtrado de paquetes, políticas de calidad de servicio (QoS), tarificación, asignación de direcciones IP y encaminamiento de tráfico a redes externas. En un ejemplo, la S-GW 210 y la PDN GW 214 se pueden comunicar a través de una interfaz S5. Aunque se ilustran como nodos separados en la FIG. 2, se debe apreciar que la S-GW 210 y la PDN GW 214, por ejemplo, se pueden configurar para funcionar como un único nodo de red para reducir los nodos del plano de usuario en el sistema de comunicación 200. El sistema de comunicación 200 también puede incluir una entidad de Servicios de abonado local (HSS) 208 que se puede comunicar con la MME 206. El sistema de comunicación 200 también puede incluir otros componentes de red, tales como un servidor/proxy de Autenticación, autorización y contabilidad (AAA) del 3GPP y un servidor/proxy de AAA del 3GPP2 (no mostrado) configurados para comunicarse entre sí y comunicarse además con la PDN GW 214 y el HSS 208.
[0027] El sistema de comunicación 200 se puede configurar para comunicarse con redes externas por medio de la PDN GW 214. Las redes externas (no mostradas) pueden incluir redes tales como, pero sin limitarse a, una red telefónica pública conmutada (PSTN), un subsistema multimedia IP (IMS) y/o una red IP. La red IP puede ser Internet, una red de área local, una red de área amplia, una intranet o similares. La FIG. 2 es un ejemplo de solo una configuración posible, y se pueden usar muchas otras configuraciones y componentes adicionales de acuerdo con diversos aspectos e implementaciones que se describen a continuación.
[0028] Un sistema informático 300 como se ilustra en la FIG. 3 se puede usar para implementar al menos parcialmente la funcionalidad de los elementos de la FIG. 2. La FIG. 3 proporciona una ilustración esquemática de un modo de realización de un sistema informático 300 que puede realizar los procedimientos proporcionados por otros diversos modos de realización, como se describe en el presente documento, y/o puede funcionar como un dispositivo móvil u otro sistema informático. Por ejemplo, el eNB 204, la MME 206, el HSs 208, la S-GW 210, la PCRF 212 y la PDN GW 214 pueden estar compuestos de uno o más sistemas informáticos 300. La FIG. 3 proporciona una ilustración generalizada de diversos componentes, que se pueden usar en parte o en su totalidad según corresponda. La FIG. 3, por lo tanto, ilustra en términos generales cómo elementos de sistema individuales se pueden implementar de manera relativamente separada o relativamente más integrada.
[0029] El sistema informático 300 se muestra comprendiendo elementos de hardware que se pueden acoplar eléctricamente por medio de un bus 305 (o que se pueden comunicar de otro modo, según sea apropiado). Los elementos de hardware pueden incluir uno o más procesadores 310, incluyendo sin limitación uno o más procesadores de propósito general y/o uno o más procesadores de propósito específico (tales como chips de procesamiento de señales digitales, procesadores de aceleración de gráficos y/o similares); uno o más dispositivos de entrada 315, que pueden incluir sin limitación un ratón, un teclado y/o similares; y uno o más dispositivos de salida 320, que pueden incluir sin limitación una unidad de visualización, una impresora y/o similares. El(los) procesador(es) 310 pueden incluir, por ejemplo, dispositivos de hardware inteligentes, por ejemplo, una unidad central de procesamiento (CPU) tal como las fabricadas por Intel® Corporation o AMD®, un microcontrolador, un ASIC, etc. También se pueden usar otros tipos de procesadores.
[0030] El sistema informático 300 puede incluir además (y/o puede estar en comunicación con) uno o más dispositivos de almacenamiento no transitorios 325 que pueden comprender, sin limitación, almacenamiento local y/o accesible por red, y/o pueden incluir, sin limitación, una unidad de disco, una serie de unidades, un dispositivo de almacenamiento óptico, un dispositivo de almacenamiento de estado sólido tal como una memoria de acceso aleatorio ("RAM") y/o una memoria de solo lectura ("ROM"), que puede ser programable, actualizarse de manera inmediata y/o similares. Dichos dispositivos de almacenamiento pueden estar configurados para implementar cualquier almacenamiento de datos adecuado, incluyendo sin limitación diversos sistemas de ficheros, estructuras de bases de datos y/o similares.
[0031] El sistema informático 300 también puede incluir un subsistema de comunicaciones 330, que puede incluir, sin limitación, un módem, una tarjeta de red (inalámbrica o cableada), un dispositivo de comunicación por infrarrojos, un dispositivo y/o un conjunto de chips de comunicación inalámbrica (tal como un transceptor/dispositivo de tecnología de comunicación inalámbrica de corto alcance BLUETOOTH, un dispositivo 802.11, un dispositivo Wi-Fi, un dispositivo WiMax, componentes de comunicación celular, etc.) y/o similares. El subsistema de comunicaciones 330 puede permitir el intercambio de datos con una red (tal como la red descrita a continuación, por citar un ejemplo), otros sistemas informáticos y/o cualquier otro dispositivo descrito en el presente documento. En muchos modos de realización, el sistema informático 300 comprenderá además, como aquí, una memoria de trabajo 335, que puede incluir un dispositivo RAM o ROM, como se describe anteriormente.
[0032] El sistema informático 300 también puede comprender elementos de software, mostrados estando localizados actualmente dentro de la memoria de trabajo 335, que incluyen un sistema operativo 340, controladores de dispositivo, librerías ejecutables y/u otro código, tal como uno o más programas de aplicación 345, que pueden comprender programas informáticos proporcionados por diversos modos de realización, y/o que pueden estar diseñados para implementar procedimientos y/o configurar sistemas, proporcionados por otros modos de realización, como se describe en el presente documento. Meramente a modo de ejemplo, uno o más procesos descritos en el presente documento podrían implementarse como código y/o instrucciones ejecutables por un ordenador (y/o un procesador dentro de un ordenador). Dicho código y/o instrucciones se pueden usar para configurar y/o adaptar un ordenador de propósito general (u otro dispositivo) para realizar una o más operaciones de acuerdo con los procedimientos descritos.
[0033] Un conjunto de estas instrucciones y/o código se puede almacenar en un medio de almacenamiento legible por ordenador, tal como el(los) dispositivo(s) de almacenamiento 325 descrito(s) anteriormente. En algunos casos, el medio de almacenamiento puede estar incorporado en un sistema informático, tal como el sistema informático 300. En otros modos de realización, el medio de almacenamiento puede estar separado de un sistema informático (por ejemplo, un medio extraíble, tal como un disco compacto) y/o proporcionarse en un paquete de instalación, de modo que el medio de almacenamiento se puede usar para programar, configurar y/o adaptar un ordenador de propósito general con las instrucciones/código almacenados en el mismo. Estas instrucciones pueden tomar la forma de código ejecutable, que se puede ejecutar por el sistema informático 300 y/o puede tomar la forma de un código fuente y/o instalable que, tras la compilación y/o instalación en el sistema informático 300 (por ejemplo, usando cualquiera de una variedad de compiladores, programas de instalación, componentes de compresión/descompresión, etc. disponibles en general) toma la forma de código ejecutable.
[0034] Con referencia a la FIG. 4, se muestra un diagrama de flujo de llamada de la técnica anterior 400 de un procedimiento de autenticación de Evolución a largo plazo (LTE) del 3GPP. El diagrama de flujo de llamada de la técnica anterior 400 cumple con los estándares publicados, tales como 3GPP TS 33.401. Los mensajes indicados en el flujo de llamada representan información (por ejemplo, campos de datos) que se transmite eléctricamente entre sistemas informáticos. La información puede ser de tipos de datos conocidos en la técnica (por ejemplo, binario, número, carácter, carácter variable (varchar), fecha, etc.). El diagrama 400 representa procedimientos de seguridad puede usar un sistema de comunicación 200, por tanto, el diagrama 400 incluye un UE 202 (por ejemplo, un dispositivo móvil 100), una red 402 y una red local 404. La red 402 puede incluir un eNodoB (eNB) 204 y una m Me 206. La red local 404 incluye al menos el HSS 208. El diagrama de flujo de llamada 400 ilustra un procedimiento de Autenticación y acuerdo de claves (AKA) para proporcionar credenciales en una red. El UE 202 envía a la MME 206 (por ejemplo, por medio del eNB 204) un mensaje de solicitud 410 de Estrato de no acceso (NAS) que incluye una Identidad internacional de equipo de estación móvil (IMSI). La MME 206 está configurada para recuperar datos de autenticación del HSS 208 para realizar la autenticación de usuario. La MME 206 puede enviar a1HSS 208 un mensaje de solicitud de información de autenticación 412 que incluye la IMSI (por ejemplo, incluida en el mensaje de solicitud de conexión de NAS 410) y una información de identidad de red (SN_id). La SN_id puede incluir un código de país móvil y un código de red móvil. El mensaje de solicitud de información de autenticación 412 también puede incluir campos de datos que indican un tipo de red (por ejemplo, E-UTRAN) y un número de Vectores de autenticación (AV) solicitados (no mostrados). El HSS 208 está configurado para recibir el mensaje de solicitud de información de autenticación 412 y generar uno o más AV. En un ejemplo, el HSS 208 puede solicitar los AV a un Centro de autenticación (AuC) (no mostrado). Los AV incluyen un testigo de autenticación (AUTN), una respuesta esperada (XRES), un número aleatorio (RAND) y una clave de Entidad de gestión de seguridad de acceso (Kasme). La Kasme forma la base para generar las claves de cifrado e integridad del Estrato de acceso (AS) y el NAS para la protección de señalización de NAS y la protección de plano de usuario. Los AV se proporcionan a la MME 206 en un mensaje de respuesta de información de autenticación 414. En otras redes 3GPP que usan AKA (por ejemplo, UMTS, GSMA), los AV incluyen un testigo de autenticación (AUTN), una respuesta esperada (XRES), un número aleatorio (RAND), una clave de cifrado (CK) y una clave de integridad (IK). CK e IK se usan para el cifrado y la protección de integridad de los mensajes.
[0035] La MME 206 se puede configurar para iniciar la autenticación del UE 202 por medio de los protocolos del Sistema de paquetes evolucionado (EPS). La MME 206 genera un mensaje de solicitud de autenticación de NAS 416, que incluye los valores de AUTN y RAND recibidos de la red local 404, así como un Identificador de conjunto de claves de NAS (KSIasme) basado en el valor de la Kasme recibido. El KSIasme se almacena en el UE 202 y en la MME 206. El UE 202 está configurado para identificar si el AV es original (por ejemplo, comprobando si se puede aceptar el AUTN). El UE 202 puede calcular entonces un valor de respuesta (RES) si se acepta la verificación (por ejemplo, se acepta el AUTN), y, a continuación, envía un mensaje de respuesta de autenticación de NAS 418 que incluye el valor de RES. Si la verificación falla, el UE 202 envía un mensaje de fallo de autenticación a la MME 206 con un valor de CAUSE que indica el motivo del fallo. La MME 206 está configurada para determinar si el valor de RES y el valor de XRES son iguales. Si son iguales, la autenticación es exitosa. Si no son iguales, la MME 206 puede estar configurada para iniciar más solicitudes de identidad o para enviar un mensaje de rechazo de autenticación hacia el UE 202.
[0036] Tras una autenticación exitosa, la MME 206 puede estar configurada para iniciar un procedimiento de Comando de modo de seguridad (SMC) de NAS que consiste en un mensaje de ida y vuelta entre la MME 206 y el UE 202. La MME 206 envía un mensaje de Comando de modo de seguridad (SMC) de NAS 420 que contiene algoritmos de confidencialidad e integridad. Por ejemplo, el mensaje de NAS SMC 420 puede contener capacidades de seguridad de UE repetidas, algoritmos de NAS seleccionados, el valor de KSIasme para identificar Kasme, y valores de NONCEue y NONCEmme en el caso de crear un contexto asignado en movilidad en modo inactivo. El mensaje de NAS SMC 420 puede tener integridad protegida (pero no cifrado) con la clave de integridad de NAS basada en KASME indicada por el valor de KSIasme en el mensaje. El UE 202 está configurado para verificar la integridad del mensaje de NAS SMC 420. Esto puede incluir garantizar que las capacidades de seguridad del UE enviadas por la MME 206 coinciden con las almacenadas en el UE 202 para garantizar que no fueron modificadas por un atacante, y comprobar la protección de integridad usando el algoritmo de integridad de NAS indicado y la clave de integridad de NAS basada en Kasme indicada por el valor de KSIasme. Si se pasan las comprobaciones del Comando de modo de seguridad de NAS, el UE 202 está configurado para responder con un mensaje de Modo de seguridad de NAS completo 422. El UE 202 está configurado para ejecutar la protección de integridad de NAS y el cifrado/descifrado, y para enviar el mensaje de Modo de seguridad de NAS completo 422 a la MME 206 cifrado y con integridad protegida. La MME 206 está configurada para descifrar y comprobar la protección de integridad en el mensaje de Modo de seguridad de NAS completo 422 usando las claves y algoritmos indicados en el Comando de modo de seguridad de NAS. El cifrado de enlace descendente de NAS en la MME con este contexto de seguridad puede comenzar después de recibir el mensaje de Modo de seguridad de NAS completo 422. El descifrado de enlace ascendente de NAS en la MME 206 puede comenzar después de enviar el mensaje de NAS SMC 420.
[0037] Después de recibir el mensaje de Modo de seguridad de NAS completo 422, la MME 206 se puede configurar para iniciar la interfaz S1 entre el eNB 204 y la MME 206 enviando un mensaje de Configuración de contexto inicial de S1AP 424. En general, el propósito del procedimiento de Configuración de contexto inicial es establecer el contexto de UE inicial global necesario, incluyendo el contexto de la portadora de acceso por radio (E-RAB) de E-UTRAN, la clave de seguridad, la lista de restricciones de traspaso, la capacidad de radio de UE y las capacidades de seguridad de UE, etc. El procedimiento usa señalización asociada al UE. El mensaje de Configuración de contexto inicial de S1AP 424 puede contener un Elemento de información (IE) de activación de rastreo, un IE de lista de restricciones de traspaso (que puede contener restricciones de itinerancia, área o acceso), un IE de capacidad de radio de UE, un IE de ID de perfil de abonado para prioridad de RAT/frecuencia, un IE de Indicador de recuperación de CS, un IE de Funcionamiento de SRVCC posible, un IE de Estado de membresía de CSG, un IE de LAI registrado, un IE de ID de GUMMEI, que indica la MME que sirve al UE, un IE de ID 2 de S1AP de UE de MME, que indica el ID de S1AP de UE de MME asignado por la MME, un IE permitido de MDT basado en gestión y un IE de ID del perfil de abonado para prioridad de RAT/frecuencia, si está disponible en la MME. El eNB se puede configurar para iniciar comunicaciones seguras con el UE 202 por medio de protocolos de Control de recursos de radio (RRC), tal como se describe en la especificación del protocolo TS 25.331 del 3GPP. El eNB puede enviar un mensaje de r Rc SMC 426 al UE 202, y el UE 202 puede estar configurado para generar un mensaje de Modo de seguridad de RRC completo 428 como se describe en la memoria descriptiva.
[0038] En referencia a la FIG. 5, en referencia además a la FIG. 2, se muestra un diagrama de flujo de llamada 500 de un procedimiento de autenticación de ejemplo con Secreto perfecto hacia delante (PFS). El diagrama 500 representa procedimientos de seguridad puede usar un sistema de comunicación 200, por tanto, el diagrama 500 incluye un UE 202 (por ejemplo, un dispositivo móvil 100), una red 502 y una red local 504. La red 502 puede incluir un eNodoB (eNB) 204 y una MME 206. La red local 504 incluye al menos el HSS 208 que se supone que soporta AKA con una propiedad de PFS. El diagrama de flujo de llamada 500 mejora el procedimiento de Autenticación y acuerdo de claves (AKA) descrito en la FIG. 4 añadiendo una propiedad de Secreto perfecto hacia delante (PFS). Los campos nuevos o mejorados en el diagrama 500 (por ejemplo, en comparación con el flujo de llamada en la FIG. 4) se etiquetan con un prefijo 'PFS' y se resaltan en el diagrama 500 con subrayado. Los elementos opcionales se indican en cursiva. Los nuevos procedimientos computacionales (por ejemplo, etapas) en el diagrama 500 se indican en los cuadros de proceso respectivos.
[0039] El UE 202 se puede configurar para enviar una solicitud de conexión de PFS NAS 510 a la MME 206. La solicitud de conexión de PFS NAS 510 incluye información de identificación (por ejemplo, IMSI) y, opcionalmente, también puede incluir un Elemento de información (IE) de UE PFS. El IE de UE PFS puede ser un bit de datos booleano, o cualquier tipo de datos para indicar que el UE 202 es capaz de procesar AKA con una propiedad de PFS. Sin embargo, el IE de UE PFS es opcional, ya que la capacidad del UE para procesar AKA con una propiedad de PFS se puede establecer de otras formas (por ejemplo, por medio de elementos de información presentes en otros intercambios de mensajes). Después de recibir la solicitud, la MME 206 está configurada para solicitar vectores de autenticación a la red local 504 (por ejemplo, el HSS 208). La MME 206 genera un mensaje de solicitud de información de autenticación de PFS 512 que incluye la información de seguridad de UE (por ejemplo, IMSI), campos de datos que indican un tipo de red (por ejemplo, E-UTRAN) y una indicación de que la red 502 soporta una propiedad de PFS (por ejemplo, un elemento de información de MME (SN) PFS). El mensaje de solicitud de información de autenticación de PFS 512 es típicamente un mensaje de protocolo de diámetro con pares de atributo-valor (AVP) como elementos de información. El elemento de información de MME (SN) PFS puede ser un valor booleano u otro valor de datos, y se usa para indicar que la red 502 soporta la propiedad de PFS. Esta indicación se puede usar para ayudar a evitar ataques de intermediario (MiM). Es decir, una estación maliciosa que intercepta la solicitud de conexión de PFS NAS 510 no puede simplemente enviar el mensaje de solicitud de conexión de PFS NAS a la red local 504 sin el elemento de información de MME (SN) PFS e intentar forzar al UE a usar el protocolo AKA sin la propiedad de PFS.
[0040] El HSS 208 está configurado para recibir el mensaje de solicitud de información de autenticación de PFS 512 y determinar si la red 502 soporta la propiedad de PFS. Si se soporta PFS, en la etapa 526, e1HSS 208 está configurado para generar un testigo de autenticación (AUTN). En este caso, se establece un campo en el Campo de gestión de autenticación (AMF) en el testigo de autenticación (AUTN) para indicar que la red 502 soporta la propiedad de PFS (por ejemplo, un bit booleano se establece a 1). Se puede denominar el bit de PFS. Si la red 502 no soporta la propiedad de PFS, entonces el bit de PFS se establece a un valor para indicar que no se soporta PFS y se usará el protocolo AKA estándar (por ejemplo, el bit booleano se establece a cero). E1HSS 208 genera un mensaje de respuesta de información de autenticación de PFS 514 que incluye un Vector de autenticación (AV). El AV en el mensaje de respuesta de información de autenticación de PFS 514 incluye el testigo de autenticación con el bit de PFS descrito anteriormente, (AUTN), el valor de respuesta esperada (XRES), el valor del número aleatorio (RAND) y el valor de la clave de Entidad de gestión de seguridad de acceso (Kasme).
[0041] El UE 202 y la MME 206 están configurados para generar pares respectivos de claves públicas y privadas Diffie-Hellman efímero (DHE) en las etapas 521 y 524, respectivamente. Los pares Diffie-Hellman se pueden generar, por ejemplo, usando criptografía de curva elíptica o aritmética de campos finitos. Como ejemplo, y no una limitación, los pares DHE pueden ser como se describe en la Patente de EE. UU. n° 4,200,770, presentada el 6 de septiembre de 1977, y titulada "Cryptographic Apparatus and Method [Aparato y procedimiento criptográfico]". El UE 202 está configurado para generar un valor de clave privada de UE (DHEpriKeyUE) y un valor de clave pública de UE (DHEpubKeyUE). La MME 206 está configurada para generar un valor de clave privada de MME (DHEpriKeyMME) y un valor de clave pública de MME (DHEpubKeyMME). Las claves privadas (DHEpriKeyUE, DHEpriKeyMME) en general se generan usando un generador de números pseudoaleatorios criptográficamente seguro (CSPRNG), pero se puede usar otra información confidencial (y preferentemente no determinista) disponible para los respectivos sistemas. Las claves públicas correspondientes también se generan mediante los respectivos sistemas. Los pares de claves DHE se pueden seleccionar y generar (por ejemplo, precalcular) con antelación mediante el UE 202 y la MME 206 para reducir el impacto de un ataque de red potencial (por ejemplo, retardos de procesamiento debidos a la generación de las claves DHE). Cabe destacar que el UE puede generar sus pares DHE en cualquier momento antes de la etapa 521 y la MME puede generar sus pares DHE en cualquier momento antes de la etapa 530 o en la etapa 530.
[0042] El UE 202 y la MME 206 están configurados para intercambiar sus claves públicas durante los procedimientos de autenticación a Ka y cada uno obtiene una clave compartida (por ejemplo, shared-DHkey). Por ejemplo, la MME 206 genera un mensaje de solicitud de autenticación de PFS NAS 516 que incluye los valores de AUTN y RAND recibidos del HSS 208, así como un Identificador de conjunto de claves (KSIasme) de NAS basado en el valor de Kasme recibido. En la etapa 528, si el UE 202 es capaz de procesar una propiedad de PFS, el UE 202 está configurado para determinar si el bit de PFS en el valor de AUTN indica que se soporta la propiedad de PFS. Si el UE 202 no está configurado para soportar una propiedad de PFS, el intercambio de mensajes puede continuar bajo los procedimientos de AKA estándar (por ejemplo, el UE envía el mensaje de respuesta de autenticación de NAS 418 descrito en la FIG.
4). El UE 202 también está configurado para determinar si el valor de AUTN es original, como se describe previamente. Si se acepta el valor de AUTN y el bit de PFS está establecido, el UE 202 calcula un valor de RES y proporciona un mensaje de respuesta de autenticación de PFS NAS 518 a la MME 206, que incluye el valor de RES y el valor de clave pública de UE (es decir, DHEpubKeyUE). Si se acepta el valor de AUTN, pero el bit de PFS no está establecido (por ejemplo, valor de cero), entonces el UE 202 puede decidir cancelar los procedimientos de conexión con la red que no soporta la propiedad de PFS o puede calcular y enviar la RES de acuerdo con los procedimientos de AKA estándar (por ejemplo, el UE envía el mensaje de respuesta de autenticación de NAS 418 descrito en la FIG. 4). Si la verificación de AUTN falla, el UE 202 envía un mensaje de fallo de autenticación a la MME 206 con un valor de CAUSE que indica el motivo del fallo.
[0043] Después de recibir el mensaje de respuesta de autenticación de PFS NAS 518, en la etapa 530, la MME 206 está configurada para determinar si el valor de RES es igual al valor de XRES, y, a continuación, obtener una clave compartida Diffie-Hellman (es decir, sharedDHEkey) basada en la clave pública de UE recibida (es decir, DHEpubKeyUE). Se debe apreciar que si la autenticación del UE falla (es decir, el valor de RES no es igual a XRES), la red puede rechazar la solicitud de conexión y no se desperdicia ningún recurso informático para realizar costosas operaciones criptográficas asimétricas. Esto ayuda a aliviar cualquier denegación de ataques de servicio por UE maliciosos. La clave compartida se vincula entonces al valor de Kasme (por ejemplo, la clave de sesión) recibido del HSS 208 y la clave vinculada se usa para proteger todo el tráfico de NAS posterior. Por ejemplo, una clave vinculada se puede designar como K'asme (por ejemplo, KASME-prima) y se puede generar en base a una función de obtención de clave (KDF) de Kasme y la clave compartida. Es decir, K'asme = KDF (Kasme, sharedDHEkey). La KDF puede ser una función de troceo (hashing) criptográfico (por ejemplo, SHA256, SHA512, SHA3, etc.). El valor de K'asme resultante se puede usar como el valor de Kasme en los procedimientos de seguridad de LTE posteriores.
[0044] La MME 206 también envía un mensaje de PFS NAS SMC 520, que incluye la clave pública de MME (es decir, DHEpubKeyMME), así como algoritmos de confidencialidad e integridad. Por ejemplo, el mensaje de PFS NAS SMC 520 puede contener capacidades de seguridad de UE repetidas, algoritmos de NAS seleccionados, el valor de KSIasme para identificar la Kasme, y valores de NONCEue y NONCEmme en el caso de crear un contexto asignado en movilidad en modo inactivo. El mensaje de PFS NAS SMC 520 puede tener integridad protegida (pero no cifrado) con la clave de integridad de NAS basada en Kasme indicada por el valor de KSIasme en el mensaje. El UE 202 está configurado para verificar la integridad del mensaje de PFS NAS SMC 520. Esto puede incluir garantizar que las capacidades de seguridad de UE enviadas por la MME coinciden con las almacenadas en el UE para garantizar que no fueron modificadas por un atacante, y verificar la protección de integridad usando el algoritmo de integridad de NAS indicado y la clave de integridad de NAS basada en Kasme indicada por el valor de KSIasme. En la etapa 532, el UE 202 está configurado para obtener la clave compartida Diffie-Hellman (por ejemplo, sharedDHEkey) en base a la clave pública de la MME (por ejemplo, DHEpubKeyMME). La sharedDHEkey se vincula entonces al valor de Kasme (por ejemplo, como se identifica mediante el valor de KSIasme) para crear la K'asme como se describe anteriormente. El valor de K'asme resultante se puede usar como el valor de Kasme en todos los procedimientos de seguridad de LTE posteriores.
[0045] Si se pasan las comprobaciones del mensaje de PFS NAS SMC 520 (es decir, las capacidades de seguridad de UE enviadas por la MME coinciden con las almacenadas en el UE, y la protección de integridad usa el algoritmo de integridad de NAS indicado y la clave de integridad de NAS basada en Kasme indicada por el valor de KSIamse), el UE 202 está configurado para responder con un mensaje de Modo de seguridad de PFS NAS completo 522. El UE 202 está configurado para ejecutar la protección de integridad de NAS y el cifrado/descifrado basado en K'asme, y para enviar el mensaje de Modo de seguridad de PFS NAS completo 522 a la MME 206 cifrado y con integridad protegida (por ejemplo, basado en K'asme). La MME 206 está configurada para descifrar y comprobar la protección de integridad en el mensaje de Modo de seguridad de PFS NAS completo 522 usando claves basadas en K'asme y otros algoritmos indicados en el mensaje de PFS NAS SMC 520.
[0046] En referencia a la FIG. 6, en referencia además a las FIGS. 2, 4 y 5, se muestra un diagrama de flujo de llamada 600 de otro procedimiento de autenticación de ejemplo con Secreto perfecto hacia delante (PFS). El diagrama 600 representa un procedimiento de seguridad alternativo que puede usar un sistema de comunicación 200, por tanto, el diagrama 600 incluye un UE 202 (por ejemplo, un dispositivo móvil 100), una red 602 y una red local 604. La red 602 puede incluir un eNodoB (eNB) 204 y una MME 206. La red local 604 incluye al menos e1HSS 208 que se supone que soporta AKA con una propiedad de PFS. El diagrama de flujo de llamada 600 mejora el procedimiento de Autenticación y acuerdo de claves (AKA) descrito en la FIG. 4 añadiendo una propiedad de Secreto perfecto hacia delante (PFS). El diagrama 600 también incluye algunos de los mensajes descritos previamente en la FIG. 5. Por ejemplo, el UE 202 se puede configurar para enviar la solicitud de conexión de PFS NAS 510 a la MME 206. Después de recibir la solicitud, la MME 206 está configurada para solicitar vectores de autenticación a la red local 604 (por ejemplo, el HSS 208). La MME 206 genera el mensaje de solicitud de información de autenticación de PFS 512 (por ejemplo, que incluye el elemento de información de MME (SN) PFS) y se lo proporciona a la red local 604. La red local 604 (por ejemplo, el HSS 208) está configurada para recibir el mensaje de solicitud de información de autenticación de PFS 512 y determinar si la red 602 soporta la propiedad de PFS. Si se soporta PFS, en la etapa 526, e1HSS 208 está configurado para generar el testigo de autenticación (AUTN) incluyendo el bit de PFS analizado en la FIG. 5. Si la red 602 no soporta la propiedad de PFS, entonces el bit de PFS se establece a un valor para indicar que no se soporta PFS y se usará el protocolo AKA estándar (por ejemplo, el bit booleano se establece a cero). E1HSS 208 genera el mensaje de respuesta de información de autenticación de PFS 514 que incluye un Vector de autenticación (AV). El AV en el mensaje de respuesta de información de autenticación de PFS 514 incluye el testigo de autenticación con el bit de PFS descrito anteriormente, (AUTN), el valor de respuesta esperada (XRES), el valor del número aleatorio (RAND) y el valor de la clave de Entidad de gestión de seguridad de acceso (Kasme).
[0047] El UE 202 y la MME 206 están configurados para generar pares respectivos de claves públicas y privadas Diffie-Hellman efímero (DHE) en las etapas 521 y 524, respectivamente. El UE 202 está configurado para generar un valor de clave privada de UE (DHEpriKeyUE) y un valor de clave pública de UE (DHEpubKeyUE). La MME 206 está configurada para generar un valor de clave privada de MME (DHEpriKeyMME) y un valor de clave pública de MME (DHEpubKeyMME). Las claves privadas (DHEpriKeyUE, DHEpriKeyMME) en general se generan usando un generador de números pseudoaleatorios criptográficamente seguro (CSPRNG), pero se puede usar otra información confidencial disponible para los respectivos sistemas. Las claves públicas correspondientes se pueden generar de forma no determinista similar mediante los respectivos sistemas. Los pares de claves DHE se pueden seleccionar y generar (por ejemplo, precalcular) con antelación mediante el UE 202 y la MME 206 para reducir el impacto de un ataque de red potencial (por ejemplo, retardos de procesamiento debidos a la generación de las claves DHE). Cabe destacar que la MME puede generar sus pares DHE en cualquier momento antes de la etapa 524 y el UE puede generar sus pares de DHE en cualquier momento antes de la etapa 521.
[0048] El UE 202 y la MME 206 están configurados para intercambiar sus claves públicas durante los procedimientos de autenticación AKA y cada uno obtiene una clave compartida (por ejemplo, sharedDHkey). Por el contrario al mensaje de solicitud de autenticación de PFS NAS 516 en la FIG. 5, en el flujo de llamada en la FIG. 6 la MME 206 genera un mensaje de solicitud de autenticación de PFS NAS 616 que incluye los valores de AUTN y RAND recibidos del HSS 208, el Identificador de conjunto de claves de NAS (KSIasme) basado en el valor de Kasme recibido, así como la clave pública de MME (es decir, DHEpubKeyMME). En la etapa 628, el UE 202 está configurado para determinar si el bit de PFS en el valor de AUTN indica que se soporta la propiedad de PFS y para determinar si la clave pública de MME (es decir, DHEpubKeyMME) está presente en el mensaje de solicitud de autenticación de PFS NAS 616.
[0049] El UE 202 también está configurado para determinar si el valor de AUTN es original, como se describe previamente. Si se acepta el valor de AUTN y el bit de PFS está establecido, y entonces la clave pública de MME (es decir, DHEpubKeyMME) está presente, entonces el UE 202 calcula un valor de RES y proporciona un mensaje de respuesta de autenticación de PFS NAS 518 a la MME 206, que incluye el valor de RES y el valor de clave pública de UE (es decir, DHEpubKeyUE). Si se acepta el valor de AUTN, pero el bit de PFS no está establecido (por ejemplo, valor de cero), y la clave pública de MME (es decir, DHEpubKeyMME) no está presente, entonces el UE 202 puede decidir cancelar los procedimientos de conexión con la red que no soporta la propiedad de PFS o puede calcular y enviar el RES de acuerdo con los procedimientos de AKA estándar (por ejemplo, el UE envía el mensaje de respuesta de autenticación de NAS 418 descrito en la FIG. 4). Si el bit de PFS está establecido pero la clave pública de MME (es decir, DHEpubKeyMME) no está presente, o la verificación de AUTN falla (por ejemplo, independientemente del valor de PFS y la presencia de la clave pública de MME), el UE 202 envía un mensaje de fallo de autenticación a la MME 206. En un ejemplo, el mensaje de fallo puede incluir un valor de CAUSE que indica el motivo del fallo.
[0050] En la etapa 530, la MME 206 está configurada para determinar si el valor de RES es igual al valor de XRES, y, a continuación, obtener una clave compartida Diffie-Hellman (es decir, sharedDHEkey) basada en la clave pública de UE recibida (es decir, DHEpubKeyUE en el mensaje de respuesta de autenticación de PFS NAS 518). La clave compartida se vincula entonces al valor de KASME recibido del HSS 208 y la clave vinculada se usa para proteger todo el tráfico de NAS posterior. Por ejemplo, una clave vinculada se puede designar como K'asme (por ejemplo, Kasme-prima) y se puede generar en base a una función de obtención de clave (KDF) de Kasme y la clave compartida. Es decir, K'asme = KDF (Kasme, sharedDHEkey). La KDF puede ser una función de troceo (hashing) criptográfico (por ejemplo, SHA256, SHA512, SHA3, etc.). El valor de K'asme resultante se puede usar como el valor de Kasme en la red de LTE. En la etapa 632, el UE 202 está configurado para obtener la clave compartida Diffie-Hellman (por ejemplo, sharedDHEkey) en base a la clave pública de la MME (por ejemplo, DHEpubKeyMME). La sharedDHEkey se vincula entonces al valor de Kasme (por ejemplo, como se identifica mediante el valor de KSIasme) para crear la K'asme como se describe anteriormente. El valor de K'asme resultante se puede usar como el valor de Kasme en los procedimientos de seguridad de LTE posteriores.
[0051] La MME 206 envía un mensaje de PFS NAS SMC 620 que incluye algoritmos de confidencialidad e integridad. Por ejemplo, el mensaje de PFS NAS SMC 620 puede contener capacidades de seguridad de UE repetidas, algoritmos de n As seleccionados y valores de NONCEue y NONCEmme en el caso de crear un contexto asignado en movilidad en modo inactivo. En un modo de realización, el mensaje de PFS NAS SMC 620 puede tener integridad protegida (pero no cifrado) con una clave de integridad de NAS basada en K'asme determinada en la etapa 530. El UE 202 está configurado para verificar la integridad del mensaje de PFS NAS SMC 620. Esto puede incluir garantizar que las capacidades de seguridad de UE enviadas por la MME coinciden con las almacenadas en el UE para garantizar que no fueron modificadas por un atacante, y comprobar la protección de integridad usando el algoritmo de integridad de NAS indicado y la clave de integridad de NAS basada en Kasme obtenida en la etapa 632.
[0052] Si se pasan las comprobaciones del mensaje de PFS NAS SMC 620 (por ejemplo, las capacidades de seguridad de UE enviadas por la MME coinciden con las almacenadas en el UE, y la protección de integridad usa el algoritmo de integridad de NAS indicado y la clave de integridad de NAS basada en K'asme), el UE 202 está configurado para responder con un mensaje de Modo de seguridad de PFS NAS completo 522. El UE 202 está configurado para ejecutar la protección de integridad de NAS y el cifrado/descifrado basado en K'asme, y para enviar el mensaje de Modo de seguridad de PFS NAS completo 522 a la MME 206 cifrado y con integridad protegida. La MME 206 está configurada para descifrar y comprobar la protección de integridad en el mensaje de Modo de seguridad de PFS NAS completo 522 usando claves basadas en K'asme y otros algoritmos indicados en el mensaje de PFS NAS SMC 620.
[0053] Además de incluir los aspectos de seguridad asociados con la propiedad de PFS, los ejemplos de flujo de llamada proporcionados en las FIGS. 5 y 6 proporcionan protección frente a ataques por reducción de opciones de autenticación (por ejemplo, ataques de intermediario en los que una entidad maliciosa modifica el intercambio de mensajes). Es decir, los flujos de llamada evitan que un intermediario reduzca el procedimiento "AKA con PFS" a un procedimiento "AKA sin PFS". Si la red local del abonado (por ejemplo, el HSS 208) soporta PFS, implica que e1HSS comprende las indicaciones recibidas de la MME (por ejemplo, el elemento de información de MME (SN) PFS) y puede establecer un bit de PFS en el campo AMF en el testigo de autenticación (AUTN) durante la generación del vector de autenticación (AV) de AKA. En general, si una red (por ejemplo, una MME) soporta PFS, indica que soporta PFS a una red local (por ejemplo, un HSS) como parte de la solicitud de AV. Esta indicación se incluye en e1HSS incluso si el UE no indica que soporta PFS en la solicitud de conexión. El HSS establece un bit de AMF (por ejemplo, el bit de PFS) en el AUTN. El AUTN tiene integridad protegida entre el HSS y el UE. Un UE que soporta PFS está configurado para comprobar si el bit de PFS está establecido en el AUTN. Si el bit de PFS está establecido, pero AKA se realiza sin PFS, entonces el UE rechazará la autenticación. Un UE que no soporta PFS puede ignorar la comprobación del bit. Si una red (por ejemplo, una MME) no soporta PFS (es decir, el bit de PFS está establecido a cero en el AV), entonces se puede invocar una política de UE para determinar si el UE continúa la autenticación sin PFS con la red.
[0054] En referencia a la FIG. 7, en referencia además a las FIGS. 1-6, un proceso 700 para proporcionar comunicaciones seguras con un dispositivo móvil incluye las etapas mostradas. El proceso 700 es, sin embargo, solo un ejemplo y no es limitativo. El proceso 700 se puede modificar, por ejemplo, añadiendo, eliminando, reordenando, combinando y/o ejecutando simultáneamente etapas. Por ejemplo, la clave pública de UE y la clave privada de UE se pueden calcular previamente. El proceso 700 se puede ejecutar en el dispositivo móvil 100, que también es un ejemplo de un UE 202 en el sistema de comunicación 200.
[0055] En la etapa 702, el procesador 111 y el transceptor inalámbrico 121 en el dispositivo móvil 100 están configurados para generar una solicitud de conexión. En un modo de realización, la solicitud de conexión puede incluir un indicador de soporte de PFS. El procesador 111 y el transceptor inalámbrico 121 son un medio para generar una solicitud de conexión. Una solicitud de conexión puede ser una comunicación inalámbrica entre el dispositivo móvil 100 y una red de comunicación, tal como LTE, LTE-A, HSPA, CDMA, Datos por paquetes a alta velocidad (HRPD), HRPD evolucionado (eHRPD), CDMA2000, Gs M, GPRS, Velocidad de transferencia de datos mejorada para la evolución de GSM (EDGE), UMTS o similares. El sistema de comunicación puede usar un protocolo 'AKA con PFS' para garantizar el flujo de mensajes en la red. Generar una solicitud de conexión puede ser enviar la solicitud de conexión de PFS NAS 510 desde el dispositivo móvil a la MME 206 por medio del eNB 204. La solicitud de conexión de soporte de PFS puede incluir opcionalmente un bit booleano, o cualquier tipo de datos, tal como el elemento de información de UE PFS opcional en la solicitud de conexión de PFS NAS 510.
[0056] En la etapa 704, el procesador 111 y el transceptor inalámbrico 121 en el dispositivo móvil 100 están configurados para recibir una solicitud de autenticación con un testigo de autenticación, de modo que el testigo de autenticación incluye una indicación de soporte de PFS por la celda de servicio. El valor del testigo de autenticación se basa, al menos en parte, en un indicador de soporte de red (por ejemplo, MME PFS). Es decir, el testigo de autenticación está configurado para indicar si la red soporta PFS o no. Por ejemplo, la indicación de soporte de PFS por la red puede ser el campo AUTN en el mensaje de respuesta de información de autenticación de PFS 514. El testigo de autenticación puede incluir un campo de datos (por ejemplo, bit, bytes) como la indicación de que una red soporta PFS (por ejemplo, el bit de PFS en el AUTN).
[0057] En la etapa 706, el procesador 111 en el dispositivo móvil 100 está configurado para determinar si una red soporta Secreto perfecto hacia delante (PFS). El testigo de autenticación recibido en la etapa 704 puede incluir un bit de PFS (por ejemplo, un bit de AMF) para indicar si la red soporta PFS o no. Si la red no soporta PFS (es decir, el bit de PFS es igual a cero), entonces en la etapa 716 el dispositivo móvil 100 está configurado para proporcionar una respuesta de autenticación sin el valor de clave pública de UE. Por ejemplo, en referencia a la FIG. 4, la respuesta de autenticación puede ser el mensaje de respuesta de autenticación de NAS 418. En la etapa 718, el dispositivo móvil 100 está configurado para realizar el procedimiento de autenticación AKA estándar, tal como se representa en la FIG.
4.
[0058] Si el dispositivo móvil 100 determina que la red soporta PFS (por ejemplo, el bit de PFS en el AUTN es igual a 1), entonces el procesador 111 en el dispositivo móvil 100 está configurado para proporcionar el valor de clave pública de UE a la red (por ejemplo, en una respuesta de autenticación) en la etapa 708. El procesador 111 y el transceptor inalámbrico 121 son un medio para proporcionar el valor de clave pública de UE a la red. Por ejemplo, el procesador 111 está configurado para generar un valor de clave pública de UE y un valor de clave privada de UE. Las claves públicas y privadas se generan como pares Diffie-Hellman. El procesador 111 es un medio para generar claves privadas y públicas de UE. El procesador 111 se puede configurar para generar un generador de números pseudoaleatorios criptográficamente seguro (CSPRNG) como el valor de clave privada de UE. El procesador 111 también genera un valor de clave pública de UE de una forma no determinista. Los valores de las claves pública y privada de UE pueden generarse antes de la ejecución del proceso 700, y almacenarse en la memoria del dispositivo móvil y recuperarse según sea necesario. En el ejemplo de LTE en la FIG. 5, el dispositivo móvil 100 puede proporcionar el mensaje de respuesta de autenticación de PFS NAS 518 a la MME 206, incluyendo un valor de RES y el valor de clave pública de UE (es decir, DHEpubKeyUE).
[0059] En la etapa 710, el transceptor inalámbrico 121 y el procesador 111 en el dispositivo móvil están configurados para recibir un valor de clave pública de red de la red. Por ejemplo, el dispositivo móvil 100 puede estar configurado para recibir un mensaje de PFS NAS SMC 520 de la red 502 (por ejemplo, de la MME 206 por medio del eNB 204). El mensaje de PFS NAS SMC 520 puede incluir la clave pública de red (por ejemplo, DHEpubKeyMME), así como algoritmos de confidencialidad e integridad.
[0060] En la etapa 712, el procesador 111 en el dispositivo móvil 100 está configurado para determinar un valor de clave compartida en base al valor de clave pública de red y el valor de clave privada de UE. Por ejemplo, el procesador 111 está configurado para obtener una clave compartida Diffie-Hellman (es decir, sharedDHEkey) en base al valor de clave pública de red recibido (es decir, DHEpubKeyMME) y el valor de clave privada de UE generado previamente (DHEpriKeyuE).
[0061] En la etapa 714, el procesador 111 en el dispositivo móvil 100 está configurado para vincular el valor de clave compartida con un valor de clave de sesión y usar el valor de clave compartida vinculada para proteger el tráfico de red posterior. Vincular el valor de clave compartida con el valor de clave de sesión puede incluir realizar un troceo criptográfico en la concatenación del valor de clave compartida con el valor de clave de sesión (por ejemplo, SHA256(clave compartida, clave raíz)). En referencia a la FIG. 5, el valor de clave compartida (es decir, sharedDHEkey) está vinculado al valor de Kasme. El valor de clave compartida vinculada resultante se designa como K'asme y se puede generar en base a una función de obtención de clave (KDF) de Kasme y la clave compartida. Es decir, K'asme = KDF (Kasme, sharedDHEkey). La KDF puede ser una función de troceo (hashing) criptográfico (por ejemplo, SHA256, SHA512, SHA3, etc.). El valor de K'asme resultante (es decir, el valor de clave compartida vinculada) se usa como el valor de Kasme en la red LTE. Es decir, el valor de clave compartida vinculada se usa para proteger el tráfico de red posterior.
[0062] En referencia a la FIG. 8, en referencia además a las FIGS. 1-6, un proceso 800 para proporcionar comunicaciones seguras con un servidor de red incluye las etapas mostradas. El proceso 800 es, sin embargo, solo un ejemplo y no es limitativo. El proceso 800 se puede modificar, por ejemplo, añadiendo, eliminando, reordenando, combinando y/o ejecutando simultáneamente etapas. Por ejemplo, los valores de las claves pública y privada de red pueden calcularse previamente y almacenarse en memoria y recuperarse según lo requiera el proceso 800. El proceso 800 se puede ejecutar en el sistema informático 300, que también es un ejemplo de una MME 206 en el sistema de comunicación 200.
[0063] En la etapa 802, el subsistema de comunicaciones 330 y el(los) procesador(es) 310 en el sistema informático 300 están configurados para recibir una solicitud de conexión de un UE. En un ejemplo, la solicitud de conexión puede incluir un indicador de soporte de PFS opcional. Una red 502 puede incluir un sistema informático 300 como medio para recibir una solicitud de conexión. En el ejemplo de LTE en la FIG. 5, la red 502 recibe la solicitud de conexión de PFS NAS 510 de un UE 202. La solicitud de conexión de PFS NAS incluye información de identificación (por ejemplo, IMSI) y, opcionalmente, puede incluir un elemento de información (IE) de UE PFS. El UE PFS IE opcional es un campo de datos (por ejemplo, bit booleano u otro carácter) configurado para indicar que el UE 202 soporta la propiedad de PFS. La solicitud de conexión de PFS NAS 510 se envía desde el UE 202 a la MME 206.
[0064] En la etapa 804, el subsistema de comunicaciones 330 y el(los) procesador(es) 310 en el sistema informático 300 están configurados para proporcionar una solicitud de autenticación que incluye un indicador de soporte de red a un recurso de red. Los procedimientos de AKA estándar requieren que una red (por ejemplo, una MME) solicite un vector de autenticación a la red local (por ejemplo, HSS). La adición de PFS al protocolo AKA mejora la resistencia de la seguridad en el sistema de comunicación 200. Se supone que la red local de un UE soporta PFS. Sin embargo, dado que existen potencialmente muchas redes diferentes disponibles para un UE, es posible que un UE se pueda conectar a una red que no soporta PFS. Por lo tanto, también es posible que un intermediario pueda intentar reducir el protocolo 'AKA con PSF' solicitado a un protocolo 'AKA sin PFS'. El proceso 800 puede eliminar este riesgo al requerir que la red indique su capacidad de soportar PFS en la red local. En el ejemplo de LTE, esta indicación se incluye en el mensaje de solicitud de información de autenticación de PFS 512 como una indicación de que la red soporta una propiedad de PFS (por ejemplo, el elemento de información de MME (SN) PFS). La solicitud de autenticación es típicamente un mensaje de protocolo de diámetro con pares atributo-valor (AVP) como elementos de información, pero en otras redes se pueden usar otros valores o tipos de datos para indicar que una red soporta la propiedad de PFS.
[0065] En la etapa 808, el subsistema de comunicaciones 330 y el(los) procesador(es) 310 están configurados para recibir un testigo de autenticación del recurso de red, de modo que el testigo de autenticación incluye una indicación de que la red soporta PFS. En respuesta a recibir la solicitud de autenticación proporcionada en la etapa 804, el recurso de red puede responder con uno o más vectores de autenticación. Los vectores de autenticación incluyen un testigo de autenticación que tiene integridad protegida entre el recurso de red y el UE. El valor del testigo de autenticación se basa, al menos en parte, en el indicador de soporte de red. Es decir, el testigo de autenticación está configurado para indicar si la red (por ejemplo, la red que proporcionó la solicitud de autenticación en la etapa 804) soporta PFS o no. Por ejemplo, el testigo de autenticación puede ser el campo AUTN en el mensaje de respuesta de información de autenticación de PFS 514. El testigo de autenticación puede incluir un campo de datos (por ejemplo, bit, bytes) como la indicación de que una red soporta PFS (por ejemplo, el bit de PFS en el AUTN).
[0066] En la etapa 810, el subsistema de comunicaciones 330 y el(los) procesador(es) 310 están configurados para proporcionar el testigo de autenticación al UE. En el ejemplo de LTE, el testigo de autenticación puede proporcionarse a través de una RAT (por ejemplo, el eNB 204) e incluirse en uno de los mensajes de solicitud de autenticación de PFS NAS 516, 616 (es decir, el valor de AUTN). En la etapa 812, la red está configurada para recibir una respuesta de autenticación que incluye un valor de clave pública de UE. El subsistema de comunicaciones 330 en el ordenador 300 es un medio para recibir una respuesta de autenticación. Por ejemplo, la respuesta de autenticación puede ser el mensaje de respuesta de autenticación de PFS NAS 518 que incluye el valor de RES y el valor de clave pública de UE (es decir, DHEpubKeyUE).
[0067] En la etapa 814, el(los) procesador(es) 310 están configurados para determinar si la respuesta de autenticación recibida en la etapa 812 es una respuesta esperada. Una respuesta esperada, por ejemplo, es una en la que un valor de respuesta (por ejemplo, RES) es igual a un valor de respuesta esperada almacenado previamente (por ejemplo, XRES). En el ejemplo de LTE, el valor de RES se incluye en el mensaje de respuesta de autenticación de PFS NAS 518, y el valor de XRES se incluye en un vector de autenticación recibido del recurso de red. El(los) procesador(es) 310 están configurados para realizar una operación de comparación lógica entre los dos valores. Si no coinciden, la solicitud de conexión del UE se deniega en la etapa 818.
[0068] En la etapa 806, el(los) procesador(es) 310 en el sistema informático 300 están configurados para generar un valor de clave pública de red y un valor de clave privada de red. Los valores de las claves pública y privada de red pueden ser pares Diffie-Hellman que se generan usando criptografía de curva elíptica. Otros procedimientos no deterministas (por ejemplo, los resultados de un CSPRNG) también se pueden usar para generar las claves. Puede generarse previamente una colección de claves antes de la ejecución del proceso 800 y almacenarse en una memoria. Un par de claves se puede recuperar de la memoria según lo requiera el proceso 800.
[0069] En la etapa 816, el(los) procesador(es) 310 están configurados para determinar un valor de clave compartida en base al valor de clave privada de red y el valor de clave pública de UE. El valor de clave compartida es una clave compartida Diffie-Hellman (es decir, sharedDHEkey) basada en la clave pública de UE recibida (es decir, DHEpubKeyUE) recibida en la etapa 812 y la clave privada de red generada en la etapa 806.
[0070] En la etapa 820, el(los) procesador(es) 310 está(n) configurado(s) para vincular el valor de clave compartida con un valor de clave de sesión y usar el valor de clave compartida vinculada para proteger el tráfico de red posterior. En general, un valor de clave de sesión se obtiene de una clave raíz simétrica que se comparte entre el UE y el recurso de red. Un ejemplo de una clave de sesión en los procedimientos AKA es el valor de la clave Kasme. El valor de clave compartida puede estar vinculado al valor de clave de sesión (por ejemplo, Kasme) a través de una función de obtención de clave (KDF). La KDF puede ser una función de troceo (hashing) criptográfico (por ejemplo, SHA256, SHA512, SHA3, etc.). También se pueden usar otros algoritmos de vinculación. En el ejemplo de LTE descrito en la FIG. 5, la clave compartida vinculada es K'asme, que se genera con una función KDF (por ejemplo, K'asme = KDF (Kasme, sharedDHEkey)). El valor de K'asme resultante se puede usar como el valor de Kasme para proteger el tráfico posterior en la red de LTE.
[0071] En referencia a la FIG. 9, en referencia además a las FIGS. 1-6, un proceso 900 para evitar un ataque por reducción de opciones de autenticación en un sistema con un protocolo de seguridad fuerte incluye las etapas que se muestran. El proceso 900 se puede ejecutar en el sistema informático 300 que está incluido en la red 502.
[0072] En la etapa 902, el subsistema de comunicaciones 330 y el(los) procesador(es) 310 en el sistema informático 300 están configurados para recibir una solicitud de conexión de un equipo de usuario. Un protocolo de seguridad fuerte soporta una propiedad de PFS. Por lo tanto, en una comparación relativa, un procedimiento de AKA que soporta PFS es más fuerte que un procedimiento AKA que no soporta PFS. En el ejemplo de LTE, el UE 202 está configurado para enviar una solicitud de conexión de PFS NAS 510 a un sistema informático 300.
[0073] En la etapa 904, el subsistema de comunicaciones 330 y el(los) procesador(es) 310 en el sistema informático 300 están configurados para enviar una solicitud de autenticación a una red local, de modo que la solicitud de autenticación incluye una indicación de que la red soporta un protocolo de seguridad fuerte. En un ejemplo, el sistema informático 300 está configurado para solicitar vectores de autenticación a la red local y generar una solicitud de autenticación que incluye la información de seguridad asociada con el equipo de usuario (por ejemplo, IMSI) y campos de datos que indican un tipo de red (por ejemplo, E -UTRAN), y una indicación de que la red soporta el protocolo de seguridad fuerte. El mensaje de solicitud de información de autenticación de PFS 512 es un ejemplo de la solicitud de autenticación enviada en la etapa 904. El elemento de información de MME (SN) PFS correspondiente es un ejemplo de una indicación de que la red soporta el protocolo de seguridad fuerte (por ejemplo, AKA con PFS). La solicitud de autenticación ayuda a evitar que un intermediario (MiM) reduzca el AKA con PFS a un protocolo AKA estándar. En un ejemplo, un MiM (por ejemplo, una estación) que podría interceptar la solicitud de conexión recibida en la etapa 902 no puede simplemente enviar esa solicitud de conexión a la red local porque el mensaje enviado resultante no incluiría una indicación de que la red soporta el protocolo de seguridad fuerte (por ejemplo, a Ka con PFS).
[0074] En la etapa 906, el subsistema de comunicaciones 330 y el(los) procesador(es) 310 en el sistema informático 300 están configurados para recibir un testigo de integridad protegida de la red local, de modo que el testigo de integridad protegida incluye al menos un bit configurado para indicar que la red soporta el protocolo de seguridad fuerte. El testigo de integridad protegida proporciona protección de integridad entre el equipo de usuario y la red local. En el ejemplo de LTE, el testigo de autenticación AUTN es un testigo de integridad protegida. En el AUTN, se puede establecer un campo en el Campo de gestión de autenticación (AMF) para indicar que la red soporta la propiedad de PFS (por ejemplo, un bit booleano se establece a 1). El bit de PFS en el AUTN es un ejemplo del al menos un bit configurado para indicar que la red soporta el protocolo de seguridad fuerte. Por ejemplo, si una red soporta el protocolo de seguridad fuerte, el bit de PFS se puede establecer a un valor para indicar que se soporta el protocolo de seguridad fuerte (por ejemplo, el bit de PFS se establece a 1). Por el contrario, si la red no soporta el protocolo de seguridad fuerte, el bit de PFS se puede establecer a cero.
[0075] En la etapa 908, el subsistema de comunicaciones 330 y el(los) procesador(es) 310 en el sistema informático 300 están configurados para enviar el testigo de integridad protegida al equipo de usuario. El equipo de usuario se puede configurar para analizar el al menos un bit del testigo de integridad protegida para determinar si la red soporta el protocolo de seguridad fuerte. En el ejemplo de LTE descrito en la FIG. 5, el equipo de usuario se puede configurar para determinar si el bit de PFS en el valor de AUTN indica que se soporta la propiedad de PFS. Si el bit de PFS está establecido (y los otros valores de autenticación son válidos), el equipo de usuario proporciona una clave pública Diffie-Hellman a la red. La clave pública es un componente del protocolo de seguridad fuerte que no se requiere para un protocolo de seguridad relativamente más débil (por ejemplo, AKA sin PFS). Si el bit de PFS en el testigo de integridad protegida no está establecido (por ejemplo, valor de cero), entonces el equipo de usuario se puede configurar para responder de acuerdo con el protocolo de seguridad más débil. Dado que el testigo de integridad protegida proporciona protección entre el equipo de usuario y la red local, el protocolo de seguridad fuerte no se puede reducir al protocolo de seguridad débil porque un intermediario no puede cambiar el valor del testigo de integridad protegida.
[0076] Los procedimientos de autenticación con una propiedad de PFS no se limitan a los flujos de llamada representados en las FIGS. 5 y 6. Por ejemplo, en escenarios de movilidad, un UE puede iniciar mensajes de Solicitud de servicio o Actualización del área de localización o Solicitud de actualización del área de seguimiento (TAU) en lugar de la solicitud de conexión de PFS NAS 510. El UE puede indicar opcionalmente si soporta PFS en estos mensajes (por ejemplo, incluyendo un UE PFS IE). Por tanto, si la MME ha cambiado o si la MME decide iniciar un nuevo a Ka , se puede realizar un nuevo AKA con propiedad de PFS según sea necesario. Además, la propiedad de PFS se puede implementar para la seguridad del Estrato de acceso (AS). De igual modo que Kasme (y otras claves de seguridad de NAS), los procedimientos DHE efímero descritos anteriormente se pueden usar para configurar las claves de seguridad de AS con una propiedad de PFS entre el eNB y el UE. La KeNB y otras claves de seguridad de AS se pueden vincular a una sharedDHEkey obtenida entre la KeNB y el UE. Por ejemplo, eNB 204 y el UE 202 pueden intercambiar claves públicas DHE usando un intercambio de mensajes de RRC (por ejemplo, RRCConnectionSetupComplete y Comando de modo de seguridad de RRC) para intercambiar las respectivas claves públicas Diffie-Hellman y configurar las claves de seguridad de AS con una propiedad de PFS. Esta implementación de una propiedad de PFS evita el compromiso de confidencialidad del tráfico por el aire (OTA) pasado entre el UE y el eNB si las claves de nivel de NAS (por ejemplo, Kasme) que se usan para obtener las claves de seguridad de AS se ven comprometidas en el futuro. Esto puede suceder cuando el UE realiza la transición entre los modos inactivo y activo, o cuando el UE se desplaza a un eNB diferente durante la movilidad en modo inactivo.
[0077] Se pueden realizar variaciones significativas de acuerdo con deseos específicos. Por ejemplo, también se podría usar hardware personalizado, y/o se podrían implementar elementos particulares en hardware, software (incluyendo software portátil, tal como applets, etc.) o en ambos. Además, se puede usar una conexión con otros dispositivos informáticos, tales como dispositivos de entrada/salida de red.
[0078] Se puede usar un sistema informático (tal como el sistema informático 300) para realizar procedimientos de acuerdo con la divulgación. Algunas o todas las metodologías de dichos procedimientos se pueden realizar mediante el sistema informático 300 como respuesta a que el procesador 310 ejecute una o más secuencias de una o más instrucciones (que se pueden incorporar en el sistema operativo 340 y/u otro código, tal como programas de aplicación 345) incluidas en la memoria de trabajo 335. Dichas instrucciones se pueden introducir en la memoria de trabajo 335 desde otro medio legible por ordenador, tal como uno o más de los dispositivos de almacenamiento 325. Simplemente a modo de ejemplo, la ejecución de las secuencias de instrucciones contenidas en la memoria de trabajo 335 podría causar que el(los) procesador(es) 310 realice(n) uno o más procesos de los procedimientos descritos en el presente documento.
[0079] Los términos "medio legible por máquina" y "medio legible por ordenador", como se usan en el presente documento, se refieren a cualquier medio que participa para proporcionar datos que provocan que una máquina funcione de una forma específica. En un modo de realización implementado usando el dispositivo móvil 100 y/o el sistema informático 300, diversos medios legibles por ordenador se pueden usar para proporcionar instrucciones/código a uno/varios procesador(es) 111, 310 para la ejecución y/o se pueden usar para almacenar y/o transportar dichas instrucciones/código (por ejemplo, como señales). En muchas implementaciones, un medio legible por ordenador es un medio de almacenamiento físico y/o tangible. Un medio de este tipo puede adoptar muchas formas, incluyendo pero sin limitarse a, medios no volátiles, medios volátiles y medios de transmisión. Los medios no volátiles incluyen, por ejemplo, discos ópticos y/o magnéticos, tales como el/los dispositivo(s) de almacenamiento 140, 325. Los medios volátiles incluyen, sin limitación, memoria dinámica, tal como la memoria de trabajo 140, 335. Los medios de transmisión incluyen, sin limitación, cables coaxiales, cable de cobre y fibra óptica, incluyendo los cables que comprenden el bus 101,305, así como los diversos componentes del subsistema de comunicaciones 330 (y/o los medios mediante los cuales el subsistema de comunicaciones 330 proporciona comunicación con otros dispositivos). Por tanto, los medios de transmisión también pueden adoptar la forma de ondas (incluyendo, sin limitación, ondas de radio, acústicas y/o de luz, tales como las generadas durante comunicaciones de datos por ondas de radio y por infrarrojos).
[0080] Las formas comunes de medios legibles por ordenador físicos y/o tangibles incluyen, por ejemplo, un disquete, un disco flexible, un disco duro, cinta magnética o cualquier otro medio magnético, un CD-ROM, un disco Blu-Ray, cualquier otro medio óptico, tarjetas perforadas, cinta de papel, cualquier otro medio físico con patrones de agujeros, una RAM, una PROM, una EPROM, una FLASH-EPROM, cualquier otro chip o cartucho de memoria, una onda portadora como se describe a continuación en el presente documento, o cualquier otro medio desde el cual un ordenador pueda leer instrucciones y/o código.
[0081] Diversas formas de medios legibles por ordenador se pueden usar para transportar una o más secuencias de una o más instrucciones al (a los) procesador(es) 111, 310 para su ejecución. Simplemente a modo de ejemplo, las instrucciones se pueden transportar inicialmente en un disco magnético y/o disco óptico de un ordenador remoto. Un ordenador remoto podría cargar las instrucciones en su memoria dinámica y enviar las instrucciones como señales a través de un medio de transmisión para recibirse y/o ejecutarse mediante el dispositivo móvil 100 y/o el sistema informático 300. Estas señales, que podrían estar en forma de señales electromagnéticas, señales acústicas, señales ópticas y/o similares, son todas ejemplos de ondas portadoras en las que pueden codificarse instrucciones, de acuerdo con diversos modos de realización de la invención.
[0082] Los detalles específicos se proporcionan en la descripción para proporcionar una comprensión completa de las configuraciones de ejemplo (incluyendo las implementaciones). Sin embargo, las configuraciones se pueden llevar a la práctica sin estos detalles específicos. Por ejemplo, se han mostrado circuitos, procesos, algoritmos, estructuras y técnicas bien conocidos sin detalles innecesarios para evitar oscurecer las configuraciones. Esta descripción proporciona solo configuraciones de ejemplo, y no limita el alcance, la aplicabilidad o las configuraciones de las reivindicaciones. Más bien, la descripción anterior de las configuraciones proporcionará a los expertos en la técnica una descripción habilitadora para implementar las técnicas descritas.
[0083] Las configuraciones se pueden describir como un proceso que se representa como un diagrama de flujo o de bloques. Aunque cada uno puede describir las operaciones como un proceso secuencial, muchas de las operaciones se pueden realizar en paralelo o simultáneamente. Además, el orden de las operaciones se puede reorganizar. Un proceso puede tener etapas adicionales no incluidas en la figura. Asimismo, los ejemplos de los procedimientos se pueden implementar mediante hardware, software, firmware, middleware, microcódigo, lenguajes de descripción de hardware o cualquier combinación de los mismos. Cuando se implemente en software, firmware, middleware o microcódigo, el código del programa o los segmentos de código para realizar las tareas necesarias se pueden almacenar en un medio legible por ordenador no transitorio, tal como un medio de almacenamiento. Los procesadores pueden realizar las tareas descritas.
[0084] Como se usa en el presente documento, incluyendo en las reivindicaciones, "o", como se usa en una lista de elementos precedida por "al menos uno de" indica una lista disyuntiva de modo que, por ejemplo, una lista de "al menos uno de A, B o C" significa A o B o C o AB o AC o BC o ABC (es decir, A y B y C), o combinaciones con más de una característica (por ejemplo, AA, AAB, ABBC, etc.).
[0085] Como se usa en el presente documento, incluyendo en las reivindicaciones, a menos que se indique lo contrario, una declaración de que una función u operación está "basada en" un elemento o condición significa que la función u operación se basa en el elemento o condición indicada y puede basarse en uno o más elementos y/o condiciones además del elemento o condición indicada.

Claims (15)

REIVINDICACIONES
1. Un procedimiento (800, 900) para evitar un ataque por reducción de opciones de autenticación (bid-down) en un sistema con un protocolo de seguridad fuerte con propiedad de secreto perfecto hacia delante, comprendiendo el procedimiento:
recibir (802, 902) una solicitud de conexión de un equipo de usuario;
enviar (804, 904) una solicitud de autenticación a una red local, en el que la solicitud de autenticación incluye una indicación de que una red soporta el protocolo de seguridad fuerte;
recibir (808, 906) un testigo de integridad protegida de la red local, en el que el testigo de integridad protegida incluye al menos un bit configurado para indicar que la red soporta el protocolo de seguridad fuerte, y en el que el testigo de integridad protegida se incluye en un vector de autenticación; y
enviar (810, 908) el testigo de integridad protegida al equipo de usuario.
2. El procedimiento (800, 900) de la reivindicación 1, en el que la solicitud de conexión incluye una indicación de que el equipo de usuario soporta el protocolo de seguridad fuerte.
3. El procedimiento (800, 900) de la reivindicación 1, en el que el protocolo de seguridad fuerte es un protocolo de autenticación y acuerdo de claves con secreto perfecto hacia delante.
4. El procedimiento (800, 900) de la reivindicación 1, en el que la solicitud de autenticación es un mensaje de protocolo de diámetro con pares atributo-valor, AVP, como elementos de información para indicar que la red soporta el protocolo de seguridad fuerte.
5. El procedimiento (800, 900) de la reivindicación 1, en el que el al menos un bit se incluye en un Campo de gestión de autenticación, AMF.
6. Un medio de almacenamiento legible por procesador no transitorio que comprende instrucciones, cuando se ejecutan en un ordenador, para evitar un ataque por reducción de opciones de autenticación en un sistema con un protocolo de seguridad fuerte con propiedad de Secreto perfecto hacia delante, comprendiendo las instrucciones:
código para recibir (802, 902) una solicitud de conexión de un equipo de usuario;
código para enviar (804, 904) una solicitud de autenticación a una red local, en el que la solicitud de autenticación incluye una indicación de que una red soporta el protocolo de seguridad fuerte;
código para recibir (808, 906) un testigo de integridad protegida de la red local, en el que el testigo de integridad protegida incluye al menos un bit configurado para indicar que la red soporta el protocolo de seguridad fuerte, y en el que el testigo de integridad protegida se incluye en un vector de autenticación; y
código para enviar (810, 908) el testigo de integridad protegida al equipo de usuario.
7. El medio de almacenamiento legible por procesador no transitorio de la reivindicación 6, en el que la solicitud de conexión incluye una indicación de que el equipo de usuario soporta el protocolo de seguridad fuerte.
8. El medio de almacenamiento legible por procesador no transitorio de la reivindicación 6, en el que el protocolo de seguridad fuerte es un protocolo de autenticación y acuerdo de claves con secreto perfecto hacia delante.
9. El medio de almacenamiento legible por procesador no transitorio de la reivindicación 6, en el que la solicitud de autenticación es un mensaje de protocolo de diámetro con pares atributo-valor, AVP, como elementos de información para indicar que la red soporta el protocolo de seguridad fuerte.
10. El medio de almacenamiento legible por procesador no transitorio de la reivindicación 6, en el que el al menos un bit se incluye en un Campo de gestión de autenticación, AMF.
11. Un aparato (300) para evitar un ataque por reducción de opciones de autenticación en un sistema con un protocolo de seguridad fuerte con propiedad de Secreto perfecto hacia delante, comprendiendo el aparato:
una memoria (325, 335);
al menos un procesador (310) acoplado operativamente a la memoria y configurado para:
recibir (802, 902) una solicitud de conexión de un equipo de usuario;
enviar (804, 904) una solicitud de autenticación a una red local, en el que la solicitud de autenticación incluye una indicación de que una red soporta el protocolo de seguridad fuerte;
recibir (808, 906) un testigo de integridad protegida de la red local, en el que el testigo de integridad protegida incluye al menos un bit configurado para indicar que la red soporta el protocolo de seguridad fuerte, y en el que el testigo de integridad protegida se incluye en un vector de autenticación; y
enviar (810, 908) el testigo de integridad protegida al equipo de usuario.
12. El aparato de la reivindicación 11, en el que la solicitud de conexión incluye una indicación de que el equipo de usuario soporta el protocolo de seguridad fuerte.
13. El aparato (300) de la reivindicación 11, en el que el protocolo de seguridad fuerte es un protocolo de autenticación y acuerdo de claves con secreto perfecto hacia delante.
14. El aparato (300) de la reivindicación 11, en el que la solicitud de autenticación es un mensaje de protocolo de diámetro con pares atributo-valor, AVP, como elementos de información para indicar que la red soporta el protocolo de seguridad fuerte.
15. El aparato (300) de la reivindicación 11, en el que el al menos un bit se incluye en un Campo de gestión de autenticación, AMF.
ES16714086T 2015-03-30 2016-03-03 Autenticación y acuerdo de claves con secreto perfecto hacia adelante Active ES2824527T3 (es)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201562140331P 2015-03-30 2015-03-30
US201562140426P 2015-03-30 2015-03-30
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 (1)

Publication Number Publication Date
ES2824527T3 true ES2824527T3 (es) 2021-05-12

Family

ID=55650686

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16714086T Active ES2824527T3 (es) 2015-03-30 2016-03-03 Autenticación y acuerdo de claves con secreto perfecto hacia adelante

Country Status (9)

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

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210168615A1 (en) * 2019-11-28 2021-06-03 Qualcomm Incorporated Identifying an illegitimate base station

Families Citing this family (32)

* 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
RU2706173C1 (ru) * 2016-01-05 2019-11-14 Хуавей Текнолоджиз Ко., Лтд. Способ, аппаратура и устройство мобильной связи
PT3574669T (pt) * 2017-01-30 2021-10-26 Ericsson Telefon Ab L M Gestão de contexto de segurança em 5g durante o modo conectado
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
JP6822577B2 (ja) * 2017-09-27 2021-01-27 日本電気株式会社 通信端末及びコアネットワークノード
CN112073184B (zh) 2017-10-23 2022-01-14 华为技术有限公司 一种生成密钥的方法、装置及系统
CN111316233A (zh) * 2017-10-30 2020-06-19 华为技术有限公司 用于获取ue安全能力的方法和设备
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
EP3718279A1 (en) * 2017-11-30 2020-10-07 Telefonaktiebolaget LM Ericsson (publ) Serving-network based perfect forward security for authentication
US11849318B2 (en) 2018-03-22 2023-12-19 British Telecommunications Plc Wireless communication network authentication
US11061920B2 (en) * 2018-03-28 2021-07-13 Opus Global, Inc. Application programming interfaces (“APIs”) for accessing and amalgamating data from incongruent sources
CN114629645B (zh) * 2018-04-10 2024-09-03 联发科技（新加坡）私人有限公司 移动通信中错误ksi处理的改进方法、装置及计算机可读存储介质
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
CN113098688B (zh) * 2020-01-09 2022-05-06 大唐移动通信设备有限公司 一种aka方法及装置
CN114125832B (zh) * 2020-08-31 2023-07-14 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
WO2005107141A1 (en) * 2004-04-30 2005-11-10 Research In Motion Limited Systems and methods to securely generate shared keys
JP4719749B2 (ja) * 2004-10-29 2011-07-06 トムソン ライセンシング セキュア認証チャネル
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
JP4791535B2 (ja) * 2005-06-13 2011-10-12 ノキア コーポレイション 汎用ブートストラッピング・アーキテクチャ（ｇｂａ）において、移動ノードの識別子を認証のプリファレンスと共に提供する装置、方法およびコンピュータ・プログラム
KR101009330B1 (ko) * 2006-01-24 2011-01-18 후아웨이 테크놀러지 컴퍼니 리미티드 모바일 네트워크를 기반으로 하는 엔드 투 엔드 통신에서의 인증을 위한 방법, 시스템 및 인증 센터
ES2617546T3 (es) * 2006-02-23 2017-06-19 Togewa Holding Ag Sistema de conmutación y método correspondiente para la unidifusión o multidifusión de transmisiones de flujo de datos de extremo a extremo y/o multimedia entre nodos de red
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
US9544766B2 (en) 2011-05-31 2017-01-10 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
JP2015531096A (ja) 2012-06-11 2015-10-29 インタートラスト テクノロジーズ コーポレイション データ収集・解析システムと方法
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

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210168615A1 (en) * 2019-11-28 2021-06-03 Qualcomm Incorporated Identifying an illegitimate base station
US11638152B2 (en) * 2019-11-28 2023-04-25 Qualcomm Incorporated Identifying an illegitimate base station based on improper response

Also Published As

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

Similar Documents

Publication Publication Date Title
ES2824527T3 (es) Autenticación y acuerdo de claves con secreto perfecto hacia adelante
CN110786031B (zh) 用于5g切片标识符的隐私保护的方法和系统
US10674355B2 (en) Apparatuses and methods for wireless communication
EP3499840B1 (en) User-plane security for next generation cellular networks
US8904167B2 (en) Method and apparatus for securing wireless relay nodes
ES2896733T3 (es) Funcionamiento relacionado con un equipo de usuario que utiliza un identificador secreto
Cichonski et al. Guide to LTE security
ES2806991T3 (es) Autentificación para sistemas de próxima generación
CN109842881B (zh) 通信方法、相关设备以及系统
Cichonski et al. DRAFT NIST Special Publication 800-187