ES2414616T3 - Comunicación inalámbrica segura - Google Patents

Comunicación inalámbrica segura Download PDF

Info

Publication number
ES2414616T3
ES2414616T3 ES08836867T ES08836867T ES2414616T3 ES 2414616 T3 ES2414616 T3 ES 2414616T3 ES 08836867 T ES08836867 T ES 08836867T ES 08836867 T ES08836867 T ES 08836867T ES 2414616 T3 ES2414616 T3 ES 2414616T3
Authority
ES
Spain
Prior art keywords
authentication
random number
network
key
message
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
ES08836867T
Other languages
English (en)
Inventor
Sarvar Patel
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.)
Alcatel Lucent SAS
Nokia of America Corp
Original Assignee
Alcatel Lucent SAS
Lucent Technologies 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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=40457340&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=ES2414616(T3) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Alcatel Lucent SAS, Lucent Technologies Inc filed Critical Alcatel Lucent SAS
Application granted granted Critical
Publication of ES2414616T3 publication Critical patent/ES2414616T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • 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/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • 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
    • 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/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
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H04W92/10—Interfaces between hierarchically different network devices between terminal device and access point, i.e. wireless air interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H04W92/12—Interfaces between hierarchically different network devices between access points and access point controllers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Procedimiento realizado por el equipo móvil (100) para autenticar una red (400), comprendiendo el procedimiento:recibir información de autenticación a partir de dicha red, incluyendo dicha información de autenticación unprimer número aleatorio, RANDU, generado por un servidor de suscripción local, HSS (400), de dicha red;extraer dicho primer número aleatorio, RANDU, de la información de autenticación recibida; generar (S610) al menos una clave de red, KEYSNME, a partir del primer número aleatorio, RANDU,utilizando la autenticación celular y la encriptación de voz; generar (S630) una clave de autenticación basada en la clave de red, KEYSNME, y un segundo valor;generar (S640) un mensaje de código de autenticación de red esperado, XMAC, sobre la base de la clavede autenticación y al menos una parte de la información de autenticación recibida de acuerdo con elprotocolo de autenticación y de acuerdo con la clave de seguridad; y autenticar (S650, S660, S680) la red (400) basado en el mensaje de código de autenticación de redesperado, XMAC, caracterizado porque dicho procedimiento comprende además: obtener un segundo número aleatorio, RANDMHSS, siendo el segundo número aleatorio un númeroaleatorio que el equipo móvil (100) había generado y había enviado a la red (400) para serincorporado en la información de autenticación; generar (S620) al menos una clave de equipos móviles, KEYSMME, basada en el segundo númeroaleatorio, RANDMHSS, mediante la autenticación celular y la encriptación de voz, constituyendodicha clave de equipo móvil, KEYSMME, dicho segundo valor.

Description

Comunicación inalámbrica segura
Antecedentes
1. Campo de la de la invención
La presente invención se refiere a un procedimiento y a un sistema para comunicaciones inalámbricas seguras. En particular, la presente invención se refiere a un procedimiento para establecer claves de autenticación en el equipo de red y en el móvil para establecer un canal de comunicación autenticado mutuamente.
2. Descripción de la técnica relacionada
Los procedimientos y procesos de seguridad relacionados con las comunicaciones inalámbricas han evolucionado en los últimos años. En particular, la seguridad CDMA 2G evolucionó a la seguridad CDMA 3G.
Como es bien conocido en la técnica, la seguridad CDMA 2G implica autenticación celular y encriptación de voz (CAVE). En particular, la seguridad CDMA 2G usa al menos una clave raíz comúnmente conocida como claves Akey y de datos secretos compartidos (SSD). Las claves de SSD se generan a través de un procedimiento de actualización de SSD bien conocido. Las claves son claves SSD de semi-largo plazo y son tratadas como claves raíz en este documento. Las claves de SSD pueden ser compartidas con un Registro de Ubicación de Visitante (VLR) de una red si el VLR es el sistema servidor local por un equipo móvil, por ejemplo. Además, protocolos de seguridad, convencionales CDMA 2G pueden implicar un procedimiento de impugnación y de respuesta global y un único procedimiento de impugnación y de respuesta.
Para el procedimiento de impugnación global, la red transmite un RAND de forma aleatoria al equipo móvil. Un equipo móvil que realiza un acceso del sistema (por ejemplo, registro, origen de la llamada y terminación de la llamada) en una red que requiere autenticación, crea y envía un AUTHR de respuesta de autenticación mediante una clave de largo plazo. El par RAND/AUTHR se reenvía al Registro de Ubicación Local/Centro de Autenticación (HLR/AC) para la verificación. Además para las llamadas de tipo de origen de la llamada, los últimos 6 dígitos se utilizan para calcular la AUTHR. Tanto para el origen de la llamada y la terminación de llamadas el móvil genera claves que son útiles para la llamada (es decir, SMEKEY y PLCM). El HLR/AC también genera y devuelve al VLR el SMEKEY y PLCM si se verifica el par RAND/AUTHR.
Un procedimiento de impugnación único puede ser realizado por la red que intenta comunicarse con un equipo móvil en cualquier momento ya sea en el canal de control o canal de tráfico. Por ejemplo, el VLR solicita un par de impugnación único y respuesta esperada, RANDU y AUTHU desde el HLR/AC. La red envía el RANDU al equipo móvil y el equipo móvil calcula un AUTHU de respuesta utilizando una clave de largo plazo y envía una AUTHU de respuesta a la red. La red verifica el par RANDU/AUTHU.
Los protocolos convencionales CDMA 3G de seguridad se basan en un protocolo de autenticación y acuerdo de claves (AKA) y proporcionan autenticación mutua significando que (i) el equipo móvil autentica la red y (ii) la red autentica el equipo móvil antes de que se realicen las comunicaciones. Los protocolos de seguridad AKA bien conocidos usados en CDMA 3G se basan en quíntuples. Los quíntuples incluyen un número aleatorio RAND, XRES respuesta esperada, clave de cifrado CK, clave de integridad IK y señal de autenticación de red AUTN. Una señal de autenticación de red AUTN convencional se basa en un número de secuencia SQN, una clave de anonimato AK, un campo de gestión de autenticación AMF y un código de autenticación de mensajes (MAC).
Por ejemplo, el equipo móvil genera su propio MAC sobre la base de un número de secuencia SQN almacenado en el equipo móvil, una clave secreta K almacenada en el equipo móvil, la AMF, y el número aleatorio RAND. Entonces, el MAC generado en el equipo móvil se compara con el MAC extraído de la señal de autenticación de la red AUTN recibida del sistema de servicio. Aún más, el equipo móvil puede determinar si el número de secuencia SQN extraído de la señal de autenticación de red es un valor aceptable. Si el equipo móvil autentica correctamente la red, el equipo móvil prepara una respuesta RES y transmite la respuesta RES de retorno al sistema de servicio de la red. El sistema de servicio de la red compara a continuación la respuesta XRES esperada con la respuesta RES para autenticar el equipo móvil, completando de este modo la autenticación mutua de acuerdo con el protocolo de seguridad AKA convencional.
Si el equipo móvil durante el proceso de autenticación determina el MAC, que se extrajo de la señal de autenticación de red AUTN, no coincide con el MAC generado en el equipo móvil, el equipo móvil transmite un mensaje de fallo al sistema de servicio de la red. Además, si el equipo móvil, durante el proceso de autenticación, determina que el valor de MAC, que se extrajo de la señal de autenticación de la red AUTN, coincide con el valor MAC generado por el equipo móvil, pero que el número de secuencia SQN está fuera del rango admisible, el equipo móvil transmite un mensaje de resincronización a la red. El protocolo de seguridad AKA como se ha descrito brevemente más arriba y que se usa en CDMA 3G es bien conocido en la técnica y por lo tanto, no se proporciona más información en este documento en aras de la brevedad.
Mientras que los protocolos de seguridad han evolucionado por la transición de protocolos de seguridad CDMA de 2G a protocolos de seguridad CDMA 3G, que también se aplican en algunos protocolos de seguridad IMS convencionales, algunos de los equipos de hardware que se utilizan para las comunicaciones inalámbricas no se han actualizado y/o no son capaces de procesar los protocolos más evolucionados. Por ejemplo, algunas empresas que hayan invertido importantes cantidades de tiempo, investigación y dinero en el hardware usado para procesar los protocolos de seguridad CDMA 2G han optado por no actualizar el hardware, por diversas razones asociadas al coste. Por lo tanto, algunos dispositivos de hardware CDMA 2G convencionales no son actualmente capaces de proporcionar un canal de comunicación mutuamente autenticado utilizando los protocolos de seguridad AKA de CDMA 3G convencional.
En consecuencia, se han hecho propuestas que tratan de establecer un canal de comunicación mutuamente autenticado sin necesidad de utilizar protocolo de seguridad AKA basado en quíntuples como base descrito anteriormente con respecto a CDMA3G. Dicho de otra manera, estas propuestas están tratando de utilizar procedimientos de autenticación IS-41 utilizados anteriormente en los protocolos de seguridad CDMA 2G. Sin embargo, todas estas propuestas sufren de, al menos, la siguiente deficiencia. En particular, un compromiso de una clave de sesión IS-41 pasada (por ejemplo, SMEKEY y PLCM) permitiría a un atacante volver a reproducir un número aleatorio y completar con éxito el protocolo de acuerdo de claves y comunicarse con un equipo móvil o una red. Por lo tanto, estas propuestas no son seguras cuando se revela una clave de sesión IS-41 utilizada anteriormente.
El documento WO 2006/029051 divulga un procedimiento según el preámbulo de la reivindicación 1.
Sumario
Realizaciones ejemplares proporcionan procedimientos y aparatos relacionados con el establecimiento de comunicaciones entre el equipo móvil y una red que aprovecha los protocolos de seguridad ANSI-41.
En una realización, el procedimiento realizado por un equipo móvil para autenticar la comunicación con una red incluye las etapas de la reivindicación 1.
En otra realización, un procedimiento realizado por una red para establecer la red con un equipo móvil incluye la generación de una impugnación. La impugnación incluye un campo de número de secuencia, un campo de gestión de autenticación, y un campo de número al azar. El campo de número de secuencia incluye un número de secuencia y una parte de un primer número aleatorio de la red asociados con el equipo móvil. El campo de la gestión de autenticación incluye otra porción del primer número aleatorio, y el campo de número aleatorio incluye un segundo número aleatorio y una porción adicional del primer número aleatorio. La realización incluye además obtener al menos una clave de equipo móvil usando el primer número aleatorio, obtener al menos una clave de red utilizando un segundo número aleatorio, y la generación de una clave de autenticación basada en la clave de equipo móvil y la clave de red. Un primer código de autenticación de mensaje se genera en base a la clave de autenticación de acuerdo con el protocolo de autenticación y el acuerdo de clave de seguridad, y se genera una señal de autenticación en función del número de secuencia en el campo de número de secuencia, el campo de la gestión de autenticación y el primer código de autenticación de mensaje. El reto y la señal de autenticación se envían a los equipos móviles.
Breve descripción de los dibujos
La presente invención se comprenderá más completamente a partir de la descripción detallada dada a continuación en este documento y en los dibujos que acompañan, en los que los elementos están representados por los mismos números de referencia, que se dan a modo de ilustración solamente y por lo tanto no son limitativos de la presente invención y en el que:
La figura 1 ilustra un sistema de comunicación de acuerdo con una realización ejemplar.
La figura 2 ilustra una realización ejemplar de un equipo móvil.
La figura 3 ilustra una realización ejemplar de un número aleatorio RANDM que tiene una longitud mayor que los números aleatorios usados convencionalmente en el establecimiento de canales de comunicación.
La figura 4 ilustra una realización ejemplar de una impugnación AKA, que puede ser generada por un servidor de abonado de origen (HSS) y utilizado tanto por un HSS y un equipo móvil para establecer un canal de comunicación autenticado mutuamente entre el HSS 400 y el equipo móvil.
La figura 5 es un híbrido de un diagrama de flujo y un diagrama de señalización que ilustra una realización ejemplar de las operaciones realizadas y las comunicaciones entre el HSS, HLR/AC y el equipo móvil para formar un canal de comunicación mutuamente autenticado.
La figura 6 es un diagrama de flujo que ilustra un ejemplo el funcionamiento del equipo móvil en la autenticación del HSS.
Descripción detallada de las realizaciones ejemplares
La figura 1 ilustra un sistema de comunicación 10 que incluye al menos un equipo móvil (ME) 100, un registro de localizaciones base (HLR) 300 y un servidor de suscripción local (HSS) 400. Un experto en la materia apreciará que el sistema de comunicación 10 que se ilustra en la figura 1 se simplifica y que incluiría varios componentes intermedios utilizados para la comunicación entre el ME 100, el HLR/AC 300 y el HSS 400. La ubicación del ME 100, el tipo de servicio solicitado por el ME 100, etc., pueden determinar si el HLR 300 o el HSS 400 proporcionan un servicio solicitado al ME 100.
De acuerdo con el realización ejemplar como se describe con respecto a la figura 1, el HLR 300 incluye un centro de autenticación (AC) 310. Un experto en la materia apreciará el HLR 300 y el AC 310 pueden ser componentes separados y distintos del sistema de comunicación en lugar de que el AC 310 se incluya con el HLR 300 como se muestra en la figura 1. En el resto de esta aplicación, el HLR 300 y el centro de autentificación 310 serán referidos colectivamente como un Registro de Ubicación/Centro de autenticación (HLR/AC). El HLR/AC 300 incluye una funcionalidad para realizar procedimientos de seguridad CDMA 2G bien conocidos tales como la autenticación celular y el cifrado de voz (CAVE).
De acuerdo con el realización ejemplar, el HSS 400 puede comportarse como un registro de ubicación visitante (VLR) con respecto al HLR/AC 300, y aprovechar la funcionalidad de seguridad CMDA 2G del HLR/AC 300 para establecer un canal de comunicación mutuamente autenticado sin tener ninguna clave criptográfica AKA acordada a priori con el ME 100.
La figura 2 ilustra una realización ejemplar de ME 100. Como se muestra en la figura 2, el ME 100 incluye un módulo de identidad de usuario (UIM), una memoria 120, un procesador 130 y un transceptor 140. El UIM puede ser un módulo de identidad de usuario convencional. Alternativamente, un experto en la materia apreciarán que el UIM de ME 100 podría ser un módulo de identidad de usuario extraíble convencional (RUIM). Por ejemplo, el UIM puede ser un módulo que fue desarrollado para funcionar de acuerdo con los protocolos de seguridad CDMA 2G. Como tal, el UIM puede almacenar un MIN/IMSI/TMSI como es bien conocido en la técnica y no se discutirá aquí con más detalle en aras de la brevedad.
La memoria 120, el procesador 130 y el transceptor 140 pueden ser usados en conjunción con el UIM para llevar a cabo realizaciones ejemplares de los procedimientos descritos a continuación con respecto a las figuras 3 y 4. Para facilitar la explicación, la memoria 120, el procesador 130 y el transceptor 140 se denominan colectivamente como ME en las realizaciones ejemplares descritas a continuación.
La figura 3 ilustra una realización ejemplar de un número aleatorio RANDM que tiene una longitud mayor que los números aleatorios usados convencionalmente en el establecimiento de canales de comunicación. El ME 100 genera el número aleatorio RANDM. Por ejemplo, la generación del número aleatorio RANDM se activa después de la inserción de un UIM en el ME 100 y/o en respuesta a una señal recibida desde el HSS 400. El número aleatorio RANDM que se muestra en la figura 3 incluye 72 bits. En particular, el número aleatorio RANDM incluye 20 bits aleatorios, 32 bits que se utilizan en la autenticación celular y encriptación de voz (CAVE), y 20 bits que representan 6 dígitos de llamadas, por ejemplo. En lo sucesivo, el número aleatorio RANDM generado por el ME 100 y que se almacena en el ME se conoce como RANDMME, y el subíndice ME indica que el número aleatorio se almacena en el ME 100. Este número aleatorio RANDMME se comunica al HSS 400, y se almacena en el HSS 400 como RANDMHSS.
La figura 4 ilustra una realización ejemplar de una impugnación AKA, que puede ser generada por el HSS 400 y utilizada tanto por un HSS 400 como por un ME 100 para establecer un canal de comunicación mutuamente autenticado entre el HSS 400 y el ME 100. Como se muestra en la figura 4, la impugnación de AKA incluye el número aleatorio RANDM del formato mostrado en la figura 3. Sin embargo, debido a que el número aleatorio RANDM incluido en la impugnación AKA es un número aleatorio RANDM almacenado en el HSS 400, el número aleatorio se conoce como RANDMHSS. Del mismo modo, el número aleatorio RANDM almacenado en el ME se conoce como RANDMME. La impugnación de AKA proporciona mayor seguridad, al menos en parte, sobre la base de un número aleatorio RANDM que tiene una longitud mayor que los números aleatorios usados convencionalmente en el establecimiento de canales de comunicación.
Como se muestra en la figura 4, la impugnación AKA incluye un campo de número de secuencia (SQN), un campo de gestión de autenticación (AMF) y un campo de acuerdo de claves de números aleatorios de autenticación (AKA_RAND). Al menos una porción de cada uno del campo SQN, AMF, y del campo AKA_RAND incluye un número de bits del RANDMHSS previamente almacenado en el HSS 400 y se utiliza para generar la impugnación de AKA.
Haciendo referencia a la figura 4, el campo SQN incluye al menos una parte de un número de secuencia almacenado en el HSS 400 (SQNHSS), un indicador o bandera (R), y una porción del número aleatorio RANDMHSS. En particular, el campo SQN tiene un total de 48 bits incluyendo 16 bits del SQNHSS, 1 bit para el indicador, y 31 bits del RANDMHSS. El campo SQN es una de las entradas a una función que se utiliza para generar un código de autenticación de mensajes (MAC).
El indicador de R del campo SQN es utilizado por el HSS 400 para activar el ME 100 para generar y almacenar un
nuevo número aleatorio RANDMME. Como se ha indicado anteriormente, el número aleatorio RANDMME puede ser de 72 bits. Por ejemplo, si el indicador R es un "1", el ME 100 genera y almacena un nuevo número aleatorio RANDMME, mientras que si el indicador es un "0", el ME 100 no genera ni almacena un nuevo número aleatorio RANDMME.
Todavía con referencia a la figura 4, el AMF incluye 16 bits del número aleatorio almacenados en el HSS 400 RANDMHSS. El AMF es otra de las entradas a una función que se utiliza para calcular un MAC.
El campo AKA_RAND incluye una porción del número aleatorio RANDMHSS almacenado en el HSS 400, y los bits aleatorios generados por el HSS 400. En particular, el campo AKA_RAND incluye 128 bits. Los 128 bits del campo de AKA_RAND incluyen 25 bits del número aleatorio RANDMHSS, una única impugnación RANDU incluyendo 24 bits y otros 79 bits generados por el HSS 400.
Las operaciones realizadas y las comunicaciones que involucran la impugnación conocida como se muestra en la figura 4 y/o la información extraída de la impugnación conocida se describen ahora con respecto a la figura 5.
La figura 5 es un híbrido de un diagrama de flujo y un de diagrama señalización que ilustra realizaciones ejemplares de las operaciones realizadas y las comunicaciones entre el HSS 400, el HLR/AC 300 y el ME 100.
Como se muestra, el As es bien conocido, el HSS 400 obtiene el par de números aleatorios conocidos RANDU/AUTHU en cooperación con el HLR/AC 300. El HSS 400 envía el par RANDU/AUTHU como el RANDU/AUTHR bien conocido al HLR/AC 300 para obtener las claves de red KEYSNHSS tales como SMEKEY y PLCM. A saber, el HSS 400 aprovecha la funcionalidad de seguridad CDMA 2G del HLR/AC 300. El HLR/AC 300 genera las claves de red KEYSNHSS según la CAVE, y devuelve las claves de red KEYSNHSS al HSS 400.
Del mismo modo, el HSS 400 envía el número aleatorio móvil RANDMHSS al HLR/AC 300. Como se discutió anteriormente, el número aleatorio móvil RANDMHSS puede haber sido recibido antes desde el ME como RANDMME y almacenado en el HSS 400 como el número aleatorio móvil RANDMHSS. A saber, el número aleatorio móvil RANDMHSS es un número aleatorio que la red asocia con el equipo móvil. El HLR/AC 300 realiza la operación en la CAVE en el RANDMHSS para generar claves de equipos móviles KEYSMHSS tales como SMEKEY y PLCM.
Puede ser que un número aleatorio móvil RANDMHSS no esté disponible en el HSS 400, por ejemplo, el número aleatorio móvil RANDMME no se recibió con anterioridad o se ha eliminado del HSS 400. En este caso, la red creará el número aleatorio RANDMHSS. Por ejemplo, el HSS 400 puede crear un segundo número aleatorio RANDN y utilizar este segundo número aleatorio RANDN como la porción de CAVE RAND (ver la figura 3) del número aleatorio móvil RANDNHSS almacenado en el HSS 400. Además, el HSS 400 puede generar bits aleatorios para ser incluidos en la sección aleatoria del número aleatorio móvil RANDMHSS almacenado en el HSS 400, así como establecer los bits de la sección de dígitos de la llamada del número aleatorio móvil RANDMHSS todos en "1". Se observa que incluir todos unos en la sección de dígitos de la llamada del número aleatorio móvil RANDMHSS enviada en una impugnación podría indicar al ME la información sobre el RANDN.
Volviendo a la figura 5, en la etapa S550, el HSS 400 genera una clave de autenticación AKA_key. Por ejemplo, la clave de autenticación AKA_key puede ser un hash de las claves KEYSNHSS de red y KEYSMHSS móvil como se muestra mediante la siguiente ecuación: AKA_key = H1 (KEYSMHSS, KEYSNHSS). En la etapa S560, el HSS 400 utiliza la AKA_KEY de acuerdo con la autenticación CMDA 3G y con los protocolos de acuerdo de claves, junto con el RANDU, los valores de AMF y el número de secuencia SQNHSS para generar un código de autenticación de mensaje MACHSS que se almacena en el HSS 400.
El HSS genera entonces la impugnación de la figura 4 y la señal de autorización AUTN en la etapa S570. La señal de autorización AUTN está formada para incluir una clave de anonimato AK, el número de secuencia SQNHSS,el campo de gestión de autenticación AMF y el código de autenticación de mensaje MACHSS. La impugnación y la señal de autorización AUTN se envían al ME 100.
La figura 6 es un diagrama de flujo que ilustra el funcionamiento ejemplar del equipo móvil en la autenticación del HSS a la recepción de la impugnación y de la señal de autorización AUTN. En particular, el transceptor 140 del ME 100 recibe la impugnación y la señal desde el HSS 400 y proporciona la información al procesador 130 para su procesamiento y/o la memoria 120 para el almacenamiento.
Como se muestra en la figura 6, en la etapa S610, el ME 100 extrae el RANDU del campo AKA_RAND de la impugnación recibida y el ME 100 puede utilizar el número aleatorio extraído RANDU para generar las claves de red KEYSNME tales como la PLCM y la SMEKEY. Como se mencionó anteriormente, la generación de claves sobre la base de un número aleatorio es bien conocida en la técnica y puede ser fácilmente realizada por un UIM del ME 100 usando la CAVE. Se apreciará que el ME 100 y el HLR/AC 300 generan las claves de red KEYSN de la misma manera.
Además, el procesador 130 del ME extrae en la etapa S620 el número aleatorio RANDMHSS desde la impugnación recibida, y el procesador 130 genera las claves móviles KEYSMME. Una vez más, el ME 100 utiliza la CAVE en la RANDMHSS para generar las claves móviles KEYSMME. Como alternativa, las claves móviles KEYSMME pueden
haberse generado ya en base a RANDMME y se almacenan en la memoria 140 del ME 100. Por ejemplo, el procesador 130 establece los 20 bits menos significativos como seis dígitos marcados, los siguientes 32 bits menos significativos como una CAVE RAND y proporciona esta información al UIM para obtener una respuesta de autenticación móvil AUTHM y las claves móviles KEYSMME.
Una vez que se obtienen tanto las claves de red KEYSNME como las claves de móvil KEYSMME mediante el ME 100, el ME 100 genera la clave de autenticación AKA_key en la etapa S630. Por ejemplo, la clave de autenticación AKA_key puede ser un hash de las claves de red KEYSNME y KEYSMME móvil como se muestra por la siguiente ecuación: AKA_key = H1 (KEYSNME, KEYSNME).
En la etapa S640, el ME 100 genera entonces el código de autenticación del mensaje esperado XMAC. El código de autenticación de mensaje esperado XMAC se genera mediante el ME 100 usando el número aleatorio móvil RANDMHSS desde la parte de SQN de la impugnación AKA y la clave de autenticación AKA_key generada y almacenada en el ME 100 de acuerdo con la autenticación CDMA 3G y los protocolos de seguridad de acuerdo de clave.
El ME 100 compara entonces el código de autenticación de mensaje esperado XMAC con el MACMHSS obtenido de la señal de autenticación AUTN en la etapa S650. Si el código de autenticación de mensaje esperado XMAC y el MACMHSS asociado con el HSS 400 no coincide, el ME 100 envía un fallo de autenticación al HSS 400 como se muestra en la figura 6, y el protocolo de seguridad es abortado. Alternativamente, si el código de autenticación de mensaje esperado XMAC y el MACMHSS asociado con el HSS 400 coinciden, el procedimiento que se muestra en la figura 6 pasa a la etapa S660.
En la etapa S660, el ME 100 determina si el número aleatorio móvil RANDMHSS recibido del HSS 400 en la impugnación AKA coincide con el número aleatorio móvil RANDMME almacenado en el ME 100. Si el número aleatorio móvil RANDMHSS recibido del HSS 400 no coincide con el número aleatorio móvil RANDMME almacenado en la memoria 140 del ME 100, el ME 100 genera y envía un mensaje de resincronización en la etapa S670. Como se muestra en la figura 6, el mensaje de resincronización incluye un campo de número de secuencia SQNRESYNC yun campo MACS.
De acuerdo con una realización ejemplar, el mensaje de resincronización incluye el número aleatorio móvil RANDMME almacenado en el ME 100. Por ejemplo, en la figura 6, el campo de número de secuencia incluye 48 bits del RANDMME y el campo MACS incluye 24 bits del número aleatorio móvil RANDMME. Además, el campo MACS incluye 18 bits de una respuesta de autenticación móvil AUTHRM que se hace un XOR con 18 bits de MACS, así como 22 bits de MACS. Generación de una respuesta de autenticación móvil AUTHRM es bien conocida en la técnica y por lo tanto no se discute en este documento en aras de la brevedad.
En respuesta a la recepción del mensaje de resincronización, el HSS 400 genera un MACSHSS utilizando la clave de autenticación AKA_key para verificar el ME 100. En particular, el HSS 400 realiza una función pseudo aleatoria usando la clave de autenticación previamente generada AKA_key, el número aleatorio móvil RANDMHSS almacenado en el HSS 400, y el número aleatorio AKA_RAND almacenado en el HSS 400.
El HSS 400 compara entonces el MACSHSS con el MACS recibido en el mensaje de resincronización proporcionado por el ME 100. Por ejemplo, el HSS 400 puede extraer los 22 bits menos significativos del MACS recibido en el mensaje de resincronización y comparar los 22 bits extraídos con los 22 bits menos significativos del MACSHSS.
Además, el HSS 400 extrae la respuesta de autenticación móvil AUTHRM recibida del ME 100 aplicándole una operación XOR a los siguientes 18 bits de MACS. De acuerdo con una realización de ejemplo, el HSS 400 envía entonces el AUTHRM junto con la información adicional para el HLR/AC 300 para verificar el ME 100 y obtener nuevas claves móviles KEYSMHSS. La información adicional incluye una CAVE RANDMME y los dígitos de llamada, por ejemplo. Si la respuesta de autenticación móvil es verificada por el HLR/AC 300, 18 bits del MACS también son verificados y por lo tanto, se verifican un total de 40 bits.
Alternativamente, si en la etapa S660, el RANDMHSS es igual al RANDMME, el procedimiento que se muestra en la figura 6 pasa a la etapa S680. En la etapa S680, el ME 100 determina si el número de secuencia SQN es aceptable. El número de secuencia SQN asociado con el proceso de autenticación actual se compara con un número de secuencia SQNME previamente almacenado en el ME 100. Por ejemplo, el número de secuencia SQN asociado con el proceso de autenticación actual debe ser mayor que el número de secuencia SQNME almacenado previamente en el ME 100, pero dentro de un cierto rango. Dicho de otra manera, el número de secuencia SQN asociado con el proceso de autenticación actual debe ser mayor que el número de secuencia SQNME previamente almacenado en el ME 100 y menos de un límite superior de un número de secuencia admisible SQNME + Δ, es decir, SQNMD < SQN < SQNME + Δ, donde Δ es un valor de número entero.
Si en la etapa S680, el número de secuencia SQN se determinó estuviera fuera de un rango permisible, el ME 100 envía un mensaje de resincronización en la etapa S690. Como se muestra en la figura 6, el mensaje de resincronización incluye un campo de número de secuencia SQNRESYNC y un campo de MACS. Por ejemplo, el campo SQNRESYNC del mensaje de resincronización puede incluir ceros para los 32 bits más significativos de un número de secuencia de 48 bits y los 16 bits menos significativos del número de secuencia de 48 bits pueden
establecerse en un número de secuencia SQNME previamente almacenado en el ME 100. Como se discutió previamente, el ME 100 genera una AKA_KEY basada en la impugnación recibida. La AKA_key generada se utiliza para calcular un MAC, que está incluido en el campo de MACS del mensaje de resincronización.
El HSS 400 recibe el mensaje de resincronización generado debido a que el número de secuencia SQN se determinó que estaba fuera de un rango permisible. El HSS 400 procesa el mensaje de resincronización recibido. Por ejemplo, el HSS 400 puede estar configurado para reconocer que si los 32 bits más significativos del número de secuencia de 48 bits que se incluye en el campo de resincronización de secuencia SQNRESYNC se establecen en ceros, indica que el mensaje de resincronización incluye un número de secuencia SQNME almacenado en el ME 100. En consecuencia, el HSS 400 almacena el número de secuencia SQNME para su futuro uso. Sin embargo, el HSS 400 también verifica el ME 100 utilizando los 64 bits de MACS que se incluyen en el campo MACS como se discutió anteriormente.
Si, en la etapa S680, el ME 100 determina que el número de secuencia SQN asociado con la operación de autenticación actual está dentro de un rango permisible, el ME 100 genera un mensaje de respuesta RES en la etapa S700. La generación de un mensaje de respuesta RES basado en un número aleatorio y una clave secreta almacenada en el ME es bien conocida en la técnica y por lo tanto, no se discute en este documento en aras de la brevedad. El ME 100 también calcula una clave de cifrado CK y de la clave de integridad IK basadas en el número aleatorio y la clave secreta. El cálculo de una clave de cifrado CK y de la clave de integridad IK también es bien conocido en la técnica.
Volviendo a la figura 5, el ME 100 envía el mensaje de respuesta RES al HSS 400. El HSS 400 ya se habrá generado un mensaje de respuesta esperado XRES en la etapa S580 en la manera bien conocida. En la etapa S590, el HSS o una entidad de red en nombre del HSS 400 compara el mensaje de respuesta al mensaje de respuesta XRES esperado. Si no existe ninguna coincidencia, la autenticación falla. Sin embargo, si existe una coincidencia, el HSS 400 y el ME 100 establecen un canal de comunicación mutuamente autenticado.
Los procedimientos y aparatos y sistemas descritos anteriormente proporcionan al menos garantías de seguridad de 64 bits. Además, durante la formación de la impugnación, los procedimientos implican enviar tanto el número aleatorio desde el equipo móvil y la red. Una clave de acuerdo de clave de autenticación (AKA) se basa en claves CDMA a partir de impugnaciones. Aún más, el equipo móvil regenera un número aleatorio de 72 bits asociado con el equipo móvil sólo en la inserción UIM y no durante la resincronización. Durante la resincronización, se envía ya sea el número aleatorio de 72 bits generado o almacenado en el equipo móvil o se envía un número de secuencia de 16 bits. La red verifica y acepta el mensaje de resincronización y almacena el número aleatorio de 72 bits proporcionado por el equipo móvil. Aún más, cuando se envía una impugnación, la red utiliza un número aleatorio de 72 bits que la red asocia con el equipo móvil y un número aleatorio de nueva creación para crear claves de CDMA que a su vez generan una clave de AKA. La clave AKA se utiliza con funciones AKA estándar para crear un MAC, RES, CK e IK.
Siendo la invención así descrita, será obvio que la misma puede ser variada de muchas maneras. Tales variaciones no deben ser consideradas como una desviación del alcance de la invención, y se pretende que todas las modificaciones que serán obvias para un experto en la materia estén incluidas dentro del alcance de la presente invención.

Claims (6)

  1. REIVINDICACIONES
    1. Procedimiento realizado por el equipo móvil (100) para autenticar una red (400), comprendiendo el procedimiento:
    recibir información de autenticación a partir de dicha red, incluyendo dicha información de autenticación un primer número aleatorio, RANDU, generado por un servidor de suscripción local, HSS (400), de dicha red; extraer dicho primer número aleatorio, RANDU, de la información de autenticación recibida; generar (S610) al menos una clave de red, KEYSNME, a partir del primer número aleatorio, RANDU, utilizando la autenticación celular y la encriptación de voz; generar (S630) una clave de autenticación basada en la clave de red, KEYSNME, y un segundo valor; generar (S640) un mensaje de código de autenticación de red esperado, XMAC, sobre la base de la clave de autenticación y al menos una parte de la información de autenticación recibida de acuerdo con el protocolo de autenticación y de acuerdo con la clave de seguridad; y autenticar (S650, S660, S680) la red (400) basado en el mensaje de código de autenticación de red esperado, XMAC, caracterizado porque dicho procedimiento comprende además:
    obtener un segundo número aleatorio, RANDMHSS, siendo el segundo número aleatorio un número aleatorio que el equipo móvil (100) había generado y había enviado a la red (400) para ser incorporado en la información de autenticación; generar (S620) al menos una clave de equipos móviles, KEYSMME, basada en el segundo número aleatorio, RANDMHSS, mediante la autenticación celular y la encriptación de voz, constituyendo dicha clave de equipo móvil, KEYSMME, dicho segundo valor.
  2. 2.
    Procedimiento de acuerdo con la reivindicación 1, en el que la etapa de autenticación comprende:
    obtener un código de autenticación de mensaje, MACHSS, a partir de la información de autenticación recibida, y comparar (S650) el código de autenticación de mensaje esperado, XMAC, con el código de autenticación de mensaje obtenido, MACHSS.
  3. 3.
    Procedimiento de acuerdo con la reivindicación 2, en el que la etapa de autenticación comprende además:
    comparar (S660) el segundo número al azar, RANDMHSS, con un tercer número al azar, RANDMME, almacenado en el equipo móvil (100); y enviar (S670) un mensaje de resincronización a la red (400) si el segundo número aleatorio, RANDMHSS,no coincide con el tercer número al azar, RANDMME, incluyendo el mensaje de resincronización al menos una porción del tercer de número aleatorio.
  4. 4.
    Procedimiento de acuerdo con la reivindicación 2, en el que la información de autenticación recibida incluye un campo de número de secuencia, SQN, un campo de gestión de autenticación, AMF, y una clave de campo de número aleatorio de acuerdo de autenticación, AKA_RAND, y que comprende además:
    determinar (S680) si un número de secuencia en el campo de número de secuencia, SQN, está dentro de un rango permisible; y enviar (S690) un mensaje de resincronización si se determinó que el número de secuencia no está dentro del rango permitido.
  5. 5.
    Procedimiento de acuerdo con la reivindicación 4, en el que el mensaje de resincronización incluye un número de secuencia almacenado en el equipo móvil.
  6. 6.
    Procedimiento de acuerdo con la reivindicación 1, en el que la información de autenticación recibida incluye un campo de número de secuencia, SQN, un campo de gestión de autenticación, AMF, y una clave de campo de número aleatorio acuerdo autenticación, AKA_RAND, y
    que comprende además:
    obtener un código de autenticación de mensajes, MACHSS, a partir de la información recibida; comparar (S650) el código de autenticación de mensaje esperado, XMAC, con el código de autenticación de mensaje obtenido, MACHSS, comparar (S660) el segundo número al azar, RANDM, con un tercer número al azar, RANDMME, Almacenado en el equipo móvil; y determinar (S680) si un número de secuencia en el campo de número de secuencia, SQN, está dentro de un rango permisible; y enviar (S700) una respuesta de autenticación a la red si el código de autenticación de mensaje esperado coincide con el código de autenticación de mensaje obtenido, el segundo número aleatorio coincide con el tercer número aleatorio, y el campo de número de secuencia está dentro del rango permisible.
ES08836867T 2007-10-09 2008-10-08 Comunicación inalámbrica segura Active ES2414616T3 (es)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US99812507P 2007-10-09 2007-10-09
US998125P 2007-10-09
US285336 2008-10-02
US12/285,336 US8379854B2 (en) 2007-10-09 2008-10-02 Secure wireless communication
PCT/US2008/011587 WO2009048574A2 (en) 2007-10-09 2008-10-08 Secure wireless communication

Publications (1)

Publication Number Publication Date
ES2414616T3 true ES2414616T3 (es) 2013-07-22

Family

ID=40457340

Family Applications (1)

Application Number Title Priority Date Filing Date
ES08836867T Active ES2414616T3 (es) 2007-10-09 2008-10-08 Comunicación inalámbrica segura

Country Status (12)

Country Link
US (3) US8379854B2 (es)
EP (1) EP2210437B1 (es)
JP (1) JP5255060B2 (es)
KR (1) KR101148543B1 (es)
CN (1) CN101810018B (es)
AU (1) AU2008311306B2 (es)
BR (1) BRPI0818515B1 (es)
ES (1) ES2414616T3 (es)
IL (1) IL204842A (es)
MX (1) MX2010003677A (es)
RU (1) RU2444861C2 (es)
WO (1) WO2009048574A2 (es)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7957533B2 (en) * 2007-10-02 2011-06-07 Alcatel-Lucent Usa Inc. Method of establishing authentication keys and secure wireless communication
WO2010069962A1 (en) * 2008-12-15 2010-06-24 Koninklijke Kpn N.V. Service-based authentication to a network
EP2249593B1 (en) * 2009-05-04 2013-01-02 NTT DoCoMo, Inc. Method and apparatus for authenticating a mobile device
CN103458410B (zh) * 2009-09-21 2017-07-14 华为技术有限公司 认证处理方法及装置
CN102025685B (zh) * 2009-09-21 2013-09-11 华为技术有限公司 认证处理方法及装置
CN101729249B (zh) * 2009-12-21 2011-11-30 西安西电捷通无线网络通信股份有限公司 用户终端之间安全连接的建立方法及系统
US8296836B2 (en) * 2010-01-06 2012-10-23 Alcatel Lucent Secure multi-user identity module key exchange
JP5286380B2 (ja) * 2011-03-07 2013-09-11 株式会社東芝 データ送信装置および送信方法
CN102685741B (zh) * 2011-03-09 2014-12-03 华为终端有限公司 接入认证处理方法及系统、终端和网络设备
US8700406B2 (en) * 2011-05-23 2014-04-15 Qualcomm Incorporated Preserving audio data collection privacy in mobile devices
KR101425711B1 (ko) * 2011-10-13 2014-08-04 (주) 아이씨티케이 스마트 모바일 환경에서의 정보 보안 시스템
JP5612006B2 (ja) 2012-03-13 2014-10-22 株式会社東芝 データ送信装置、データ受信装置、及びプログラム
US8971851B2 (en) 2012-06-28 2015-03-03 Certicom Corp. Key agreement for wireless communication
CN102737639B (zh) * 2012-07-13 2014-05-28 北京理工大学 一种语音信息安全通信方法
KR101330867B1 (ko) * 2012-12-27 2013-11-18 신한카드 주식회사 결제 디바이스에 대한 상호인증 방법
KR101898934B1 (ko) * 2014-03-26 2018-09-14 삼성전자주식회사 통신 시스템에서 인증 방법 및 장치
US20160112411A1 (en) * 2014-10-15 2016-04-21 Nokia Solutions And Networks Oy One time credentials for secure automated bluetooth pairing
KR101623742B1 (ko) * 2015-01-23 2016-05-25 주식회사 악어스캔 파일 연관 메시지 공유 방법 및 메시지 공유 시스템
WO2017096596A1 (zh) * 2015-12-10 2017-06-15 深圳市大疆创新科技有限公司 无人机认证方法，安全通信方法及对应系统
WO2018126400A1 (en) * 2017-01-05 2018-07-12 Nokia Technologies Oy Inactive state security support in wireless communications system
CN108347331B (zh) * 2017-01-25 2021-08-03 北京百度网讯科技有限公司 车联网系统中T_Box设备与ECU设备进行安全通信的方法与设备
WO2018208221A1 (zh) 2017-05-09 2018-11-15 华为国际有限公司 网络认证方法、网络设备及终端设备
EP3503456A1 (en) * 2017-12-19 2019-06-26 Koninklijke Philips N.V. Homomorphic encryption for password authentication
US10437745B2 (en) * 2018-01-05 2019-10-08 Denso International America, Inc. Mobile de-whitening
SG11202009946VA (en) * 2018-04-10 2020-11-27 Visa Int Service Ass System and method for secure device connection

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19514084C1 (de) * 1995-04-13 1996-07-11 Siemens Ag Verfahren zum rechnergestützten Austausch kryptographischer Schlüssel zwischen einer Benutzercomputereinheit U und einer Netzcomputereinheit N
US6918035B1 (en) 1998-07-31 2005-07-12 Lucent Technologies Inc. Method for two-party authentication and key agreement
US6857075B2 (en) * 2000-12-11 2005-02-15 Lucent Technologies Inc. Key conversion system and method
US8098818B2 (en) * 2003-07-07 2012-01-17 Qualcomm Incorporated Secure registration for a multicast-broadcast-multimedia system (MBMS)
CN1601958B (zh) * 2003-09-26 2010-05-12 北京三星通信技术研究有限公司 基于cave算法的hrpd网络接入认证方法
US8341700B2 (en) * 2003-10-13 2012-12-25 Nokia Corporation Authentication in heterogeneous IP networks
CN1969580B (zh) * 2004-06-17 2010-11-03 艾利森电话股份有限公司 移动通信系统中的安全
US20060046690A1 (en) 2004-09-02 2006-03-02 Rose Gregory G Pseudo-secret key generation in a communications system
CN1767430B (zh) * 2004-10-27 2010-04-21 华为技术有限公司 鉴权方法
US8265593B2 (en) * 2007-08-27 2012-09-11 Alcatel Lucent Method and system of communication using extended sequence number
US7957533B2 (en) * 2007-10-02 2011-06-07 Alcatel-Lucent Usa Inc. Method of establishing authentication keys and secure wireless communication

Also Published As

Publication number Publication date
IL204842A0 (en) 2010-11-30
JP5255060B2 (ja) 2013-08-07
RU2444861C2 (ru) 2012-03-10
BRPI0818515B1 (pt) 2020-10-13
KR20100068279A (ko) 2010-06-22
IL204842A (en) 2014-01-30
KR101148543B1 (ko) 2012-05-23
US20090103728A1 (en) 2009-04-23
BRPI0818515A2 (pt) 2015-06-16
WO2009048574A2 (en) 2009-04-16
JP2011501915A (ja) 2011-01-13
US8379854B2 (en) 2013-02-19
RU2010118011A (ru) 2011-11-20
AU2008311306B2 (en) 2011-08-25
US20130129093A1 (en) 2013-05-23
MX2010003677A (es) 2010-04-21
US20140273971A1 (en) 2014-09-18
WO2009048574A3 (en) 2009-05-28
AU2008311306A1 (en) 2009-04-16
EP2210437A2 (en) 2010-07-28
CN101810018B (zh) 2013-06-19
US8792641B2 (en) 2014-07-29
CN101810018A (zh) 2010-08-18
EP2210437B1 (en) 2013-04-03

Similar Documents

Publication Publication Date Title
ES2414616T3 (es) Comunicación inalámbrica segura
ES2584862T3 (es) Autenticación en comunicación de datos
KR100625503B1 (ko) 무선 통신 시스템에서 비밀 공유 데이터를 갱신하는 방법
ES2930214T3 (es) Sistema SAE/LTE de actualización de clave
ES2400020T3 (es) Generación de claves criptográficas
US7957533B2 (en) Method of establishing authentication keys and secure wireless communication
ES2424474T3 (es) Método y aparato para establecer una asociación de seguridad
ES2367692T3 (es) Diseño de seguridad mejorado para criptografía en sistemas de comunicación de móviles.
US6918035B1 (en) Method for two-party authentication and key agreement
US8503376B2 (en) Techniques for secure channelization between UICC and a terminal
US8265593B2 (en) Method and system of communication using extended sequence number
ES2249455T3 (es) Comprobacion de integridad en un sistema de comunicaciones.
ES2706540T3 (es) Sistema de credenciales de equipos de usuario
Liu et al. Toward a secure access to 5G network
ES2357564T3 (es) Método y sistema de autentifcación de usuario en respuesta a instancia.
Audestad Mobile Security