ES2554671T3 - Autenticación eficaz de terminal en redes de telecomunicaciones - Google Patents

Autenticación eficaz de terminal en redes de telecomunicaciones Download PDF

Info

Publication number
ES2554671T3
ES2554671T3 ES11701966.1T ES11701966T ES2554671T3 ES 2554671 T3 ES2554671 T3 ES 2554671T3 ES 11701966 T ES11701966 T ES 11701966T ES 2554671 T3 ES2554671 T3 ES 2554671T3
Authority
ES
Spain
Prior art keywords
terminal
authentication
message
network
session
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
ES11701966.1T
Other languages
English (en)
Inventor
Frank Fransen
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.)
Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO
Koninklijke KPN NV
Original Assignee
Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO
Koninklijke KPN NV
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 Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO, Koninklijke KPN NV filed Critical Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO
Application granted granted Critical
Publication of ES2554671T3 publication Critical patent/ES2554671T3/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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/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
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for 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/06—Authentication
    • H04W12/062—Pre-authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Landscapes

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

Abstract

Un método para permitir la autenticación o acuerdo de claves por un terminal (3) en una red (1) que comprende las etapas de: derivar en el terminal (3), durante una sesión de terminal n, un primer mensaje de autenticación RESn; caracterizado por cuanto que el método incluye además: transmitir, durante la sesión de terminal n, un mensaje de rechazo de incorporación de IMSI que contiene al menos un parámetro de autenticación RANDn+m o parámetros de aplicación RANDn+m, AUTNn+m, al terminal (3) en donde RAND es un número aleatorio y AUTN es una ficha de autenticación y en donde el al menos un parámetro de autenticación permite la autenticación o el acuerdo de claves por el terminal en la red para una sesión de terminal posterior n+m.

Description

imagen1
imagen2
imagen3
imagen4
imagen5
15
25
35
45
55
65
incluye un depósito de perfiles de suscripción y un centro de autenticación (AuC).
Información adicional de la arquitectura general de una red EPS puede encontrarse en 3GPP TS 23.401. En un entorno de M2M, un servidor único 2 se utiliza normalmente para la comunicación con un gran número de terminales 3. Los terminales individuales 3 pueden identificarse mediante identificadores individuales, tales como una dirección IP, una IMSI u otro identificador de terminal.
Formas de realización de la presente invención se describirán a condición con más detalle para redes de acceso inalámbricas 2G, 3G y 4G. En estas formas de realización, se considerará la sucesión de sesiones de terminales n1, n, n+1. La presente invención, sin embargo, es aplicable igualmente para sesiones de terminales n-m, n, n+m para sesiones de terminales n-k, n, n+m o secuencias más avanzadas de sesiones de terminales en tanto que al menos un parámetro de AKA recibido durante una sesión de terminal anterior puede utilizarse para futuras sesiones de terminales.
Las Figuras 2A y 2B son ilustraciones esquemáticas de un terminal 3 y un HLR/AuC de una red 2G en conformidad con una forma de realización de la invención.
El HLR/AuC comprende una interfaz de recepción 20 y una interfaz de transmisión 21. La interfaz de recepción 20 está configurada para recibir una demanda de autenticación desde un terminal 3 cuando se establece una sesión de terminal n. La demanda de autenticación contiene al menos el identificador de abonado, el identificador IMSI (Identidad de Abonado Móvil Internacional) memorizada en la tarjeta SIM. El subíndice n para IMSI en la Figura 2B es indicativo de la sesión de terminal ilustrada pero, en general, la IMSI tendrá lo mismo que para una sesión de terminal anterior n-1 y una sesión de terminal posterior n+1.
El HLR/AuC comprende una clave secreta Ki y un número aleatorio RANDn para el terminal 3, siendo este último normalmente distinto para cada sesión de terminal n. La clave secreta Ki y el número aleatorio RANDn se utilizan en combinación con el algoritmo de autenticación A3 y el algoritmo de generación de claves A8 para derivar un mensaje de autenticación prevista XRESn y la clave de encriptación Kcn utilizando el procesador 22 en una manera conocida por sí misma. Además, sin embargo, la demanda de autenticación da lugar también a la generación de un número aleatorio RANDn+1 por el generador 23. RANDn+1 puede utilizarse también para derivar un mensaje de respuesta de autenticación prevista XRESn+1 y la clave de encriptación Kcn+1 por anticipado, esto es, antes de que se reciba la demanda de una sesión de terminal posterior n+1. XRESn+1 y la clave de encriptación Kcn+1 pueden memorizarse luego en una memoria (no ilustrada). El HLR/AuC está configurado para transmitir el triplete de parámetros de AKA [RANDn+1, XRESn, Kcn] por intermedio de la interfaz de transmisión 21 a un nodo de red adicional, p.ej., nodo SGSN ilustrado en la Figura 1.
Conviene señalar que no todos los componentes del triplete están destinados para el terminal 3. En el nodo SGSN (véase Figura 1), los componentes del triplete recibidos desde el HLR/AuC son objeto de proceso. XRESn se utiliza para la autenticación del terminal 3 en la red para la sesión de terminal n, mientras la clave de encriptación Kcn puede utilizarse para desencriptar los datos de usuario UD recibidos en el nodo SGSN durante la sesión de terminal
n. La clave de encriptación Kcn puede, sin embargo, utilizarse también para la encriptación de RANDn+1, después de lo cual puede reenviarse el número RANDn+1 encriptado al terminal 3 por intermedio de la red de acceso de radio RAN. La encriptación y la desencriptación pueden realizarse durante el algoritmo de encriptación A5 en combinación con la clave de encriptación Kcn.
El terminal 3 comprende una interfaz de recepción 30 y una interfaz de transmisión 31. En alguna etapa durante la sesión de terminal n, la interfaz de recepción 30 recibe el parámetro RANDn+1 de AKA posiblemente encriptado utilizando el algoritmo de encriptación A5 y la clave de encriptación Kcn. El algoritmo de encriptación A5 es conocido y la clave de encriptación Kcn se deriva en el terminal 3, lo que permite al terminal 3 desencriptar el parámetro RANDn+1 de AKA.
El parámetro RANDn+1 de AKA permite al terminal 3, utilizando el procesador 32, derivar un mensaje de autenticación RESn+1 y una clave de encriptación Kcn+1 para una sesión de terminal posterior n+1, utilizando el algoritmo de autenticación A3 y el algoritmo de generación de claves A8 en un tiempo arbitrario después de haber terminado la sesión de terminal n y sin tener primero que demandar RANDn+1 desde la red 1 para la sesión de terminal posterior n+1. El mensaje de autenticación RESn+1 y una clave de encriptación Kcn+1 pueden memorizarse temporalmente en la memoria 33 en el terminal 3. Los datos de usuario UD, a transmitirse durante la sesión de terminal posterior n+1 pueden encriptarse utilizando la clave Kcn+1 y el algoritmo de encriptación A5. Cuando se inicia la sesión de terminal posterior n+1, la interfaz de transmisión 31 puede utilizarse para transmitir el identificador IMSI (que tiene la suscripción n+1 en la Figura 2A para indicar la sesión de terminal posterior; en general IMSIn+1 es igual a IMSIn), el mensaje de autenticación RESn+1 y, de forma opcional, los datos de usuario UD encriptados destinados para el servidor de aplicación 2.
Conviene señalar que formas de realización similares pueden considerarse por un experto en terminales de 3G/4G y nodos de red 3G/4G sobre la base de las Figuras 2A y 2B y la explicación anterior.
15
25
35
45
55
65
Aunque en la presente descripción de las formas de realización, el procedimiento implica la autenticación y el acuerdo de claves, debe entenderse que la invención es también aplicable para otra autenticación o acuerdo de claves a nivel individual. Las Figuras 3A a 3D proporcionan ilustraciones esquemáticas de procedimientos de autenticación y acuerdo de claves (AKA) para una red de telecomunicaciones 2G 1 en conformidad con las formas de realización de la invención.
La Figura 3A es una ilustración esquemática de un procedimiento de AKA en donde los datos de usuario UD se transmiten en mensajes de señalización desde un terminal UE 3 a una red 1.
En la etapa 1a, el terminal UE 3 transmite una demanda de incorporación que contiene al menos uno o la totalidad de los identificadores de terminales IMSI, UD de mensaje de solicitud o un mensaje de autenticación RESn utilizando, a modo de ejemplo, la interfaz de transmisión 31, con el fin de demandar una sesión de terminal n. El mensaje de autenticación RESn puede ser un mensaje de 32 bits. RESn se obtiene, a modo de ejemplo, mediante una ejecución posterior de la forma de realización de la invención, según se explicará más adelante haciendo referencia a la Figura 6. La demanda de incorporación puede recibirse de forma inalámbrica en la red RAN de la Figura 1 reenviarse al MSC/SGSN en la etapa 1b.
En la etapa 2a, el MSC/SGSN emite una demanda de autenticación al HLR, conteniendo dicha demanda de autenticación el identificador IMSI del equipo UE 3. La demanda de autenticación se recibe por intermedio de la interfaz de recepción 20 en el HLR. El HLR recupera el mensaje de respuesta de autenticación XRESn prevista y la clave de encriptación Kcn y además, genera un parámetro de AKA RANDn+1 para fines de AKA para una sesión de terminal posterior n+1, utilizando el generador 23, mediante el mismo terminal UE 3. RANDn+1 puede ser un mensaje de 128 bits. El HLR puede calcular ya los valores de XRESn+1 y de Kcn+1 para la sesión de terminal posterior n+1 y memorizar estos parámetros. En la etapa 2b, el HLR informa el triplete [RANDn+1, XRESn, Kcn] al MSC/SGSN. En el MSC/SGSN, la autenticación del terminal 3 en la red 1 para la sesión de terminal n puede procesarse comparando RESn, recibida en la etapa 1b, con XRESn del triplete recibida en la etapa 2b. Si la autenticación tiene un resultado satisfactorio, el terminal UE 3 y la red pueden conmutarse a un modo de seguridad (etapas 2c, 2d), en donde se conviene en que toda comunicación adicional se realice bajo la clave de encriptación Kcn.
Los datos de usuario UD, recibidos en la etapa 1b, pueden reenviarse luego al servidor M2M 2. En la forma de realización ilustrada en la Figura 3A, esta operación se realiza utilizando mensajes SMS por intermedio de las etapas 3a, 3b, pero se pueden aplicar otros métodos de reenvío de los datos de usuario desde el MSC/SGSN al servidor de aplicación 2. En la presente forma de realización, de nuevo de forma opcional, una confirmación de recibo de un mensaje de entrega de los datos de usuarios en el servidor de aplicación 2 se recibe en la etapa 3c en el MSC/SGSN.
Puesto que los datos de usuario están incluidos ya en el mensaje de señalización, esto es, la demanda de incorporación de IMSI en la presente forma de realización, no es necesario establecer una conexión de datos completa entre el terminal UE 3 y la red 1. Por lo tanto, en las etapas 4a y 4b, un mensaje de rechazo de incorporación de IMSI se reenvía al terminal UE 3 desde la red 1 para evitar el establecimiento de una conexión completa y, en consecuencia, para economizar recursos de red. El mensaje de rechazo de incorporación de IMSI contiene, sin embargo, el parámetro RANDn+1 de AKA que se recibe por el terminal UE 3 por intermedio de la interfaz de recepción 30 como la etapa final de la sesión de terminal n.
Según se explica haciendo referencia a la Figura 2A, el parámetro de AKA RANDn+1 puede utilizarse para derivar un mensaje de autenticación RESn+1 y/o una clave de encriptación Kcn+1 que puede memorizarse en la memoria 33 para una sesión de terminal posterior n+1.
Las etapas 5a, 5b y 6 ilustran el uso de RESn+1 para una sesión de terminal posterior n+1 para demandar de inmediato la autenticación en la red para esta sesión.
La Figura 3B es una ilustración esquemática de un procedimiento de AKA en donde datos de usuario UD se transmiten en mensajes de señalización desde un terminal UE 3 a una red 1 en una forma encriptada.
En la etapa 1a, el terminal UE 3 transmite una demanda de incorporación que contiene el identificador de abonado IMSI, el mensaje de solicitud de UD y un mensaje de autenticación RESn, que utiliza la interfaz de transmisión 31, con el fin de demandar una sesión de terminal n. El mensaje de autenticación RESn puede ser un mensaje de 32 bits. Los datos de usuario UD se encriptan ahora utilizando la clave de encriptación Kcn y el algoritmo de encriptación A5 según se describe haciendo referencia a la Figura 2A. La demanda de incorporación se recibe, de forma inalámbrica, en la red RAN según se ilustra en la Figura 1 y se reenvía al MSC/SGSN en la etapa 1b.
En la etapa 2a, el MSC/SGSN emite una demanda de autenticación al HLR, conteniendo dicha demanda de autenticación el identificador IMSI del terminal UE 3. La demanda de autenticación se recibe por intermedio de la interfaz de recepción 20 en el HLR. El HLR recupera el mensaje de respuesta de autenticación XRESn prevista y la clave de encriptación Kcn y además, genera un parámetro de AKA RANDn+1 para fines de AKA para una sesión de
15
25
35
45
55
65
terminal posterior n+1, utilizando el generador 23, mediante el mismo terminal UE 3. RANDn+1 puede ser un mensaje de 128 bits. El HLR puede calcular ya XRESn+1 y Kcn+1 para la sesión de terminal posterior n+1 y memorizar estos parámetros. En la etapa 2b, el HLR informa del triplete [RANDn+1, XRESn, Kcn] al MSC/SGSN.
En el MSC/SGSN, la autenticación del terminal 3 en la red 1 para la sesión de terminal n puede procesarse comprando RESn que se recibe en la etapa 1b, con XRESn del triplete recibido en la etapa 2b. Si la autenticación tiene un resultado satisfactorio, el terminal UE 3 y la red pueden conmutarse a un modo de seguridad (etapas 2c, 2b), en donde se conviene en que toda comunicación adicional se realice bajo la clave de encriptación Kcn.
Los datos de usuarios UD del mensaje de solicitud, recibidos en la etapa 1b, pueden reenviarse luego al servidor M2M 2. En la forma de realización ilustrada en la Figura 3A, esta operación se realiza utilizando mensajes SMS por intermedio de las etapas 3a, 3b, pero se pueden aplicar otros métodos de reenvío de los datos de usuario desde el MSC/SGSN al servidor de aplicación 2. En la presente forma de realización, de nuevo de forma opcional, un acuse de recibo del mensaje de entrega de los datos de usuarios en el servidor de aplicación 2 se recibe en la etapa 3c en el MSC/SGSN. Además, los datos de usuario UD del mensaje de solicitud se desencriptan utilizando la clave de encriptación Kcn y el algoritmo de encriptación A5 conocido en el MSC/SGSN. De forma alternativa, los datos de usuario UD del mensaje de solicitud se reenvían hacia el servidor de aplicación 2 en forma encriptada y desencriptada en un nodo de red adicional o el servidor de aplicación 2 que tenga acceso a la clave de encriptación Kcn y al algoritmo de encriptación A5.
De nuevo, puesto que los datos de usuarios UD del mensaje de solicitud están ya incluidos en el mensaje de señalización, esto es, la demanda de incorporación de IMSI en la presente forma de realización, no es necesario establecer una conexión de datos completa entre el terminal UE 3 y la red 1. Por lo tanto, en las etapas 4a y 4b, se reenvía un mensaje de rechazo de incorporación de IMSI al terminal UE 3 desde la red 1 para evitar el establecimiento de una conexión completa y, en consecuencia, economizar recursos de la red. El mensaje de rechazo de incorporación de IMSI contiene, sin embargo, el parámetro RANDn+1 de AKA que se recibe por el terminal UE 3 por intermedio de la interfaz de recepción 30 en la etapa final de la sesión de terminal n.
Según se explica haciendo referencia a la Figura 2A, el parámetro RANDn+1 de AKA puede utilizarse para derivar un mensaje de autenticación RESn+1 y/o una clave de encriptación Kcn+1 que puede memorizarse en la memoria 33 para una sesión de terminal posterior n+1.
Las etapas 5a, 5b y 6 ilustran el uso de RESn+1 para una sesión de terminal posterior n+1 para demandar, de inmediato, la autenticación en la red para esta sesión. Los datos de usuario UD del mensaje de solicitud a enviarse en esta sesión de terminal pueden encriptarse utilizando el algoritmo de encriptación A5 y la clave de encriptación Kcn+1 siendo esta última derivada del parámetro RANDn+1 de AKA recibido durante la sesión de terminal anterior n, Ki y el algoritmo de generación de claves A8.
Puesto que el intervalo temporal entre la sesión de terminal n y la sesión de terminal posterior n+1 puede ser considerable, puede realizarse la intercepción del parámetro RANDn+1 de AKA y el uso posterior de este parámetro para derivar el mensaje de autenticación RESn+1 y/o clave Kcn+1. Aunque el uso de algoritmos adecuados de autenticación y generación de claves puede retardar la derivación del mensaje de autenticación y/o la clave por partes no autorizadas, la encriptación del parámetro de AKA RANDn+1 puede ser ventajosa para impedir la captura denominada sniffing de paquete de datos. Dicha forma de realización se ilustra en la Figura 3C.
La Figura 3C es una ilustración esquemática de un procedimiento de AKA en donde los datos de usuarios UD se transmiten en mensajes de señalización desde un terminal UE 3 a una red 1 en forma encriptada y en donde el parámetro de AKA RANDn+1 transmitido al terminal UE 3 durante la sesión de terminal n es también objeto de encriptación. Conviene señalar que aunque la Figura 3C ilustra la opción combinada, no es necesario encriptar los datos UD de mensaje de solicitud cuando se realiza la encriptación del parámetro de AKA RANDn+1.
En la etapa 1a, el terminal UE 3 transmite de nuevo una demanda de incorporación que contiene el identificador de abonado IMSI, los datos UD del mensaje de solicitud y un mensaje de autenticación RESn, que utiliza la interfaz de transmisión 31, con el fin de demandar una sesión de terminal n. El mensaje de autenticación RESn puede ser un mensaje de 32 bits. Los datos de usuario UD pueden encriptarse utilizando la clave de encriptación Kcn y el algoritmo de encriptación A5 según se describe haciendo referencia a la Figura 2A. La demanda de incorporación se recibe, de forma inalámbrica, en la red RAN ilustrada en la Figura 1 y se reenvía al MSC/SGSN en la etapa 1b.
En la etapa 2a, el MSC/SGSN emite una demanda de autenticación al HLR, conteniendo dicha demanda de autenticación el IMSI de terminal UE 3. La demanda de autenticación se recibe por intermedio de la interfaz de recepción 20 en el HLR. El HLR recupera el mensaje de respuesta de autenticación prevista XRESn y la clave de encriptación Kcn y genera, además, un parámetro de AKA RANDn+1 para fines de AKA para una sesión de terminal posterior n+1, utilizando el generador 23 por el mismo terminal UE 3. RANDn+1 puede ser un mensaje de 128 bits. El HLR puede calcular ya XRESn+1 y Kcn+1 para la sesión de terminal posterior n+1 y memorizar estos parámetros. En la etapa 2b, el HLR informa del triplete [RANDn+1, XRESn, Kcn] al MSC/SGSN.
imagen6
imagen7
imagen8
15
25
35
45
55
65
El parámetro RANDn+1 de AKA puede utilizarse para derivar un mensaje de autenticación RESn+1 y/o las claves criptográficas IKn+1 y CKn+1 que pueden memorizarse para una sesión de terminal posterior n+1. AUTNn+1 se utiliza para la autenticación de red de una sesión de terminal posterior n+1 para determinar que RANDn+1 fue recibido desde la red correcta.
Las etapas 5a, 5b y 6 ilustran el uso de RESn+1 para una sesión de terminal posterior n+1 para la demanda inmediata de la autenticación en la red para esta sesión. Los datos de usuarios UD del mensaje de solicitud a enviarse en esta sesión de terminal pueden encriptarse utilizando un algoritmo de encriptación y la clave de encriptación CKn+1, siendo esta última derivada del parámetro RANDn+1 de AKA, recibido durante la sesión de terminal anterior n, Ki y un algoritmo de generación de claves. Conviene señalar que, según se describió anteriormente para las redes 2G con referencia a la Figura 3D, no se requiere rechazar la demanda de incorporación de IMSI para la sesión de terminal n y para proporcionar los parámetros de AKA para la sesión de terminal posterior n+1 con el rechazo de incorporación de IMSI. La conexión para la sesión de terminal n puede establecerse y, durante cualquiera de las etapas de esta sesión, los parámetros de AKA pueden reenviarse desde la red 1 al terminal UE 3.
La Figura 4D es una ilustración esquemática de un procedimiento de AKA en donde los datos de usuarios UD se transmiten en mensajes de señalización desde un terminal UE 3 a una red 1 y en donde también un código de autenticación de mensaje MAC para los datos de usuarios UD, indicado como MAC_key(UD) en donde el término key indica la clave utilizada para generar MAC. Conviene señalar que el código de autenticación de mensajes puede aplicarse también a otros elementos de datos dentro de la demanda de incorporación o incluso la demanda de incorporación completa, con lo que se permite la protección de la integridad de otros elementos de datos (p.ej., IMSI, RES) de la demanda de incorporación.
En la etapa 1a, el terminal UE 3 transmite una demanda de incorporación que contiene el identificador de abonado IMSI, los datos de usuarios UD del mensaje de solicitud y un mensaje de autenticación RESn con el fin de demandar una sesión de terminal n, de forma similar a la que se ilustra en la Figura 4A. El mensaje de autenticación RESn puede ser un mensaje de 128 bits. RESn es, p.ej., obtenido mediante una ejecución anterior de la forma de realización de la invención, según se explicará más adelante haciendo referencia a la Figura 6.
Además, la demanda de incorporación contiene un código de autenticación de mensaje MAC para la sesión de terminal n. El código de autenticación de mensaje MAC ha sido generado en el terminal UE 3 utilizando una clave de integridad IKn obtenida durante una ejecución anterior de la presente forma de realización en donde los parámetros de AKA para la sesión de terminal n fueron ya recibidos.
La demanda de incorporación se reenvía a un nodo de red adicional, p.ej., el RNC o el nodo eNodeB de la red RAN de la Figura 1 y se reenvían al nodo SGSN en la etapa 1b.
En la etapa 2a, el nodo SGSN emite una demanda de autenticación al HLR, conteniendo la demanda de autenticación el IMSI del UE 3. La demanda de autenticación se recibe en el HLR. El HLR recupera el mensaje de respuesta de autenticación prevista XRESn y las claves criptográficas IKn para protección de la integridad y CKn para la encriptación. Además, los parámetros RANDn+1 y AUTHn+1 de AKA se generan en el HLR para fines de AKA para una sesión de terminal posterior n+1 por el mismo terminal UE 3. RANDn+1 y AUTNn+1 tienen ambos una longitud de 128 bits. El HLR puede calcular ya XRESn+1 e IKn+1 y CKn+1 para la sesión de terminal posterior n+1 y memorizar estos parámetros. En la etapa 2b, el HLR informa del quinteto [RANDn+1, AUTNn+1, XRESn, IKn, CKn] al nodo SGSN. En el nodo SGSN, la autenticación del terminal 3 en la red 1 para la sesión de terminal n puede procesarse comparando RESn que se recibe en la etapa 1b, con XRESn del quinteto que se recibe en la etapa 2b. Además, la integridad de los datos de usuarios UD puede verificarse en el nodo SGSN generando el código de autenticación de mensaje XMAC_IKn (UD) prevista utilizando la clave de integridad IKn procedente del quinteto y un algoritmo de MAC adecuado. XMAC_IKn (UD) puede compararse luego con MAC_IKn (UD) que se recibe en la etapa 1b. Si la autenticación tiene un resultado satisfactorio, el terminal UE 3 y la red pueden conmutarse a un modo de seguridad (etapas 2c, 2d), en donde se conviene en que toda señalización y comunicación de datos adicionales esté protegida utilizando las calves IKn y CKn, respectivamente.
Conviene señalar que la integridad de los datos de usuarios UD puede verificarse también por el servidor de aplicación 2. En ese caso, el nodo SGSN del HLR debe enviar la clave de protección de integridad IKn al servidor de aplicación 2 y el servidor de aplicación 2 debe tener acceso al algoritmo de MAC.
Los datos de usuarios UD recibidos en la etapa 1b, pueden reenviarse al servidor M2M 2. En la forma de realización ilustrada en la Figura 4D, esta operación se realiza utilizando mensajes SMS por intermedio de las etapas 3a, 3b, pero pueden aplicarse otros métodos de reenvío de los datos de usuarios desde el nodo SGSN al servidor de aplicación 2. En la presente forma de realización, de nuevo de forma opcional, una confirmación de recibo del mensaje de entrega de los datos de usuarios en el servidor de aplicación 2 se recibe en la etapa 3c en el nodo SGSN.
Puesto que los datos de usuarios están ya incluidos en el mensaje de señalización, esto es, la demanda de
15
25
35
45
55
65
incorporación de IMSI en la presente forma de realización, no es necesario establecer una comunicación de datos completa entre el terminal UE 3 y la red 1. Por lo tanto, en las etapas 4a y 4b, un mensaje de rechazo de incorporación de IMSI se reenvía al terminal UE 3 desde la red 1 para evitar el establecimiento de una conexión completa y, en consecuencia, economizar recursos de red. El mensaje de rechazo de incorporación de IMSI contiene, sin embargo, los parámetros RANDn+1 y AUTNn+1 de AKA que se reciben por el terminal UE 3 como la etapa final de la sesión de terminal n.
El parámetro RANDn+1 de AKA puede utilizarse para derivar un mensaje de autenticación RESn+1 y/o las claves criptográficas IKn+1 y CKn+1 que pueden memorizarse para una sesión de terminal posterior n+1. AUTNn+1 se utiliza para la autenticación de red de una sesión de terminal posterior n+1 para determinar que el RANDn+1 fue recibido desde la red correcta.
Las etapas 5a, 5b y 6 ilustran el uso de RESn+1 para una sesión de terminal posterior n+1 para la demanda inmediata de la autenticación en la red para esta sesión, incluyendo también un mensaje de verificación de integridad encriptada MAC_ IKn+1 (UD) encriptado bajo la clave de integridad derivada IKn+1.
Conviene señalar que la forma de realización de la verificación de integridad para la red 3G de la Figura 4D es también aplicable para las redes 2G y 4G. Para las redes 2G modernas, en donde puede aplicarse un USIM, una clave de integridad está disponible en la tarjeta USIM después del procesamiento de la orden de autenticación AUTHENTICATE. Cuando se utiliza una tarjeta SIM, es posible utilizar la clave de encriptación Kc para generar el código de integridad de mensaje MAC. Para las redes 4G se puede aplicar un procedimiento similar como el que se ilustra en la Figura 4D, utilizando p.ej., la clave de integridad KNASintn para la encriptación del mensaje de verificación de integridad MACn.
La Figura 5 proporciona una ilustración esquemática de un procedimiento de AKA para una red de telecomunicaciones 4G en conformidad con una forma de realización de la invención utilizando la encriptación de los datos de usuarios UD del mensaje de aplicación y los parámetros RANDn+1 y AUTNn+1 de AKA. Conviene señalar que estas etapas de encriptación son opcionales.
En la etapa 1a, el terminal UE 3 transmite una demanda de incorporación que contiene el indicador de abonado IMSI, los datos de usuarios UD del mensaje de solicitud y un mensaje de autenticación RESn con el fin de demandar una sesión de terminal n. El mensaje de autenticación RESn puede ser un mensaje de 128 bits de longitud. RESn se obtiene, a modo de ejemplo, mediante una ejecución anterior de la forma de realización de la invención, según se explicará más adelante con referencia a la Figura 6. La demanda de incorporación se reenvía al nodo NodeB de la red E-UTRAN según se ilustra en la Figura 1 y se reenvía a la entidad MME en la etapa 1b. Los datos de usuarios UD pueden encriptarse utilizando la clave de encriptación KNASencn y un algoritmo de encriptación. Otra clave, derivada de KASME puede, sin embargo, utilizarse para esta finalidad.
En la etapa 2a, la entidad MME emite una demanda de autenticación al servidor HSS, conteniendo dicha demanda de autenticación el IMSI del UE 3. La demanda de autenticación se recibe en el servidor HSS. El servidor HSS recupera el mensaje de respuesta de autenticación prevista XRESn y la clave de encriptación KASMEn. Además, los parámetros de encriptación RANDn+1 y AUTHn+1 de AKA se generan en el servidor HSS para fines de AKA para una sesión de terminal posterior n+1 por el mismo terminal UE 3, equivalente como para las redes 3G. RANDn+1 y AUTNn+1 tienen ambos una longitud de 128 bits. El servidor HSS puede calcular ya XRESn+1 y KASMEn+1 para la sesión de terminal posterior n+1 y memorizar estos parámetros. En la etapa 2b, el servidor HSS informa del cuarteto [RANDn+1, AUTNn+1, XRESn, KASMEn] a la entidad MME. En la entidad MME, la autenticación de terminal 3 en la red 1 para la sesión de terminal n puede procesarse comparando RESn que se recibe en la etapa 1b con XRESn del cuarteto que se recibe en la etapa 2b. Si la autenticación tiene un resultado satisfactorio, el terminal UE 3 y la red pueden conmutarse a un modo de seguridad, en donde se conviene en que toda comunicación de datos y señalización adicional se realice bajo claves de encriptación, respectivamente.
Conviene señalar que para los sistemas de EPC, existen dos órdenes del modo de seguridad, una entre el terminal UE 3 y la entidad MME (la orden del modo de seguridad NAS) para iniciar protecciones de integridad y/o la encriptación de la señalización en la red base (el estrato de no acceso NAS) y otro entre el terminal UE 3 y el nodo (la orden del módulo de seguridad AS) para iniciar la protección de integridad y la encriptación de la señalización de RRC y la encriptación en el plano del usuario para la red de acceso de radio (el estrato de acceso AS).
Los datos de usuarios UD recibidos en la etapa 1b, pueden reenviarse luego al servidor M2M 2. Cuando se encriptan los datos de usuarios, los datos de usuarios UD pueden desencriptarse en la entidad MME utilizando la clave de encriptación derivada de KASMEn tal como KNASencn que se recibe en el cuarteto y un algoritmo de encriptación o los datos de usuarios se reenvían en forma encriptada para su desencriptación en un nodo de red adicional o servidor de aplicación 2 que tiene acceso a la clave de encriptación y al algoritmo de encriptación. En la forma de realización ilustrada en la Figura 5, el reenvío de los datos de usuarios UD se realiza utilizando mensajes SMS, por intermedio de las etapas 3a, 3b, pero se pueden aplicar otros métodos de reenvío de datos de usuarios desde la entidad MME al servidor de aplicación 2. En la presente forma de realización, de nuevo de forma opcional, una confirmación de recibo de un mensaje de entrega de los datos de usuarios en el servidor de aplicación 2 se
15
25
35
45
55
65
recibe en la etapa 3c en la entidad MME.
Puesto que los datos de usuarios están ya incluidos en el mensaje de señalización, esto es, la demanda de incorporación de IMSI en la presente forma de realización, no es necesario establecer una conexión de datos completa entre el terminal UE 3 y la red 1. Por lo tanto, en las etapas 4a y 4b, un mensaje de rechazo de incorporación de IMSI se reenvía al terminal UE 3 desde la red 1 para evitar el establecimiento de una conexión completa y, en consecuencia, economizar recursos de red. El mensaje de rechazo de incorporación de IMSI contiene, sin embargo, los parámetros RANDn+1 y AUTNn+1 de AKA que se reciben por el terminal UE 3 como la etapa final de la sesión de terminal n. En la forma de realización ilustrada en la Figura 5, los parámetros RANDn+1 y AUTNn+1 de AKA son objeto de encriptación utilizando la clave de encriptación KNASencn que se deriva de KASMEn a partir del cuarteto recibido en la etapa 2b y un algoritmo de encriptación complican la captura del tipo sniffing de este parámetro en la interfaz de aire inalámbrica.
El parámetro RANDn+1 de AKA puede utilizarse para derivar un mensaje de autenticación de respuesta RESn+1 y/o claves de encriptación IKn+1 y CKn+1 que pueden memorizarse para una sesión de terminal posterior n+1. AUTNn+1 se utiliza para la autenticación de red de una sesión de terminal posterior n+1 para determinar que el RANDn+1 fue recibido desde la red correcta.
Las etapas 5a, 5b y 6 ilustran el uso de RESn+1 para una sesión de terminal posterior n+1 para la demanda inmediata de la autenticación en la red para esta sesión. Los datos de usuarios UD del mensaje de solicitud a enviarse en esta sesión pueden encriptarse utilizando un algoritmo de encriptación y la clave de encriptación derivada de KASMEn+1 siendo esta última derivada del parámetro RANDn+1 de AKA que se recibe durante la sesión de terminal anterior n, Ki y un algoritmo de generación de claves.
La Figura 6 proporciona un diagrama de estados para el terminal 3 y un nodo de red, tal como el HLR o HSS de la Figura 1, ilustrando los dados (los círculos) y las transiciones de estados.
La flecha I ilustra la situación en donde ni el terminal 3 ha recibido un parámetro de AKA durante una sesión de terminal anterior para una sesión de terminal siguiente ni el HLR ha memorizado información de AKA. Por lo tanto, una demanda de incorporación de IMSI no puede contener un mensaje de respuesta RESn y el procedimiento de AKA normal según se describe en la sección precedente se realiza a este respecto.
La flecha II ilustra la situación en donde la demanda de incorporación de IMSI para la sesión de terminal n contiene RESn. Sin embargo, el HLR no ha memorizado la información de AKA para esta sesión de terminal n incluyendo el parámetro de AKA para la sesión de terminal n+1. Por lo tanto, RESn es rechazada y se seguirá el procedimiento de AKA convencional.
De forma similar, según se ilustra por la flecha III, el procedimiento de AKA convencional se sigue si el mensaje de demanda de incorporación de IMSI no contiene RESn por lo que el HLR/HSS habría memorizado el vector AKA. A continuación, HLR/HSS elimina la información de AKA para la sesión de terminal n.
La flecha IV ilustra la situación en donde los parámetros RANDn+1 / AUTNn+1 de AKA se transmiten desde la red al terminal 3, p.ej., en un mensaje de rechazo de incorporación de IMSI, un informe de entrega o un mensaje de aceptación de la desincorporación de IMSI desde la red. Tanto el HLR/HSS como el terminal 3 pueden calcular ahora y memorizar la información de AKA, esto es, (X) RESn+1 y/o las claves para la sesión de terminal n+1.
Por último, la flecha V ilustra la situación ilustrada en las Figuras 3A-3D, Figuras 4A-4C y Figura 5, en donde el (primer) mensaje de señalización desde el terminal 3 a la red contiene ya el mensaje de respuesta de autenticación RESn y el mensaje (final) desde la red para la sesión de terminal n contiene los parámetros RANDn+1, AUTNn+1 de AKA que permiten al terminal 3 y al HLR/HSS calcular y memorizar al menos un mensaje de autenticación RESn+1 y/o la clave para una sesión de terminal posterior n+1.
Las formas de realización anteriores permiten reducir el número de mensajes en la red de telecomunicación. Debe entenderse que la idea inventiva puede aplicarse también fuera del campo de las comunicaciones máquina a máquina y no requiere que los mensajes de solicitud/datos de usuarios se incorporen en el mismo mensaje (señalización) como el mensaje de autenticación de respuesta RES.
Una realización muy esquemática, a modo de ejemplo de dicha forma de realización se proporciona en la Figura 7 para una red 2G. Una demanda de conexión para una sesión de terminal n incluye ya un mensaje de autenticación de respuesta RESn que puede utilizarse para la autenticación del terminal en la red después de recibir la respuesta de autenticación XRESn desde el HLR. Después de la autenticación, puede realizarse un intercambio de información entre el terminal 3 y un dispositivo de destino.
El triplete recibido desde el HLR contiene también el parámetro RANDn+1 de AKA que se comunica al terminal 3, a modo de ejemplo, durante la aceptación de la demanda de conexión según se ilustra en la Figura 7 o en otra etapa (p.ej., durante la terminación de la sesión n). El parámetro RANDn+1 de AKA comunicado puede utilizarse en el
imagen9

Claims (1)

  1. imagen1
    imagen2
    imagen3
ES11701966.1T 2010-01-28 2011-01-24 Autenticación eficaz de terminal en redes de telecomunicaciones Active ES2554671T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP10151964 2010-01-28
EP10151964 2010-01-28
PCT/EP2011/050906 WO2011092138A1 (en) 2010-01-28 2011-01-24 Efficient terminal authentication in telecommunication networks

Publications (1)

Publication Number Publication Date
ES2554671T3 true ES2554671T3 (es) 2015-12-22

Family

ID=42238228

Family Applications (1)

Application Number Title Priority Date Filing Date
ES11701966.1T Active ES2554671T3 (es) 2010-01-28 2011-01-24 Autenticación eficaz de terminal en redes de telecomunicaciones

Country Status (4)

Country Link
US (1) US8954739B2 (es)
EP (2) EP3002965B1 (es)
ES (1) ES2554671T3 (es)
WO (1) WO2011092138A1 (es)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011025876A1 (en) * 2009-08-27 2011-03-03 Interdigital Patent Holdings, Inc. Method and apparatus for solving limited addressing space in machine-to-machine (m2m) environments
US9264237B2 (en) * 2011-06-15 2016-02-16 Microsoft Technology Licensing, Llc Verifying requests for access to a service provider using an authentication component
WO2013107511A1 (en) * 2012-01-19 2013-07-25 Nokia Siemens Networks Oy Detection of non-entitlement of a subscriber to a service in communication networks
DE102012201164B4 (de) * 2012-01-26 2017-12-07 Infineon Technologies Ag Vorrichtung und verfahren zur erzeugung eines nachrichtenauthentifizierungscodes
US10433161B2 (en) * 2012-01-30 2019-10-01 Telefonaktiebolaget Lm Ericsson (Publ) Call handover between cellular communication system nodes that support different security contexts
TWI531257B (zh) * 2013-07-16 2016-04-21 財團法人資訊工業策進會 無線通訊系統及其認證方法
GB2518257A (en) 2013-09-13 2015-03-18 Vodafone Ip Licensing Ltd Methods and systems for operating a secure mobile device
KR102232121B1 (ko) * 2013-11-14 2021-03-25 삼성전자주식회사 장치 대 장치 통신 시스템에서 보안키를 관리하는 방법 및 장치
WO2015126347A1 (en) * 2014-02-20 2015-08-27 Aselsan Elektronik Sanayi Ve Ticaret Anonim Sirketi A high security system and method used in radio systems
US9693178B2 (en) 2015-03-18 2017-06-27 Intel IP Corporation Procedures to provision and attach a cellular internet of things device to a cloud service provider
US10123239B2 (en) 2015-12-03 2018-11-06 Telefonaktiebolaget Lm Ericsson (Publ) Light-weight RRC connection setup in multi-RAT network
EP3384698B1 (en) * 2015-12-03 2022-09-14 Telefonaktiebolaget LM Ericsson (publ) Multi-rat access stratum security
WO2018089442A2 (en) * 2016-11-09 2018-05-17 Intel IP Corporation Ue and devices for detach handling
US10637858B2 (en) * 2018-02-23 2020-04-28 T-Mobile Usa, Inc. Key-derivation verification in telecommunications network
US11265699B2 (en) 2018-02-23 2022-03-01 T-Mobile Usa, Inc. Identifier-based access control in mobile networks
CN113287335B (zh) * 2019-01-15 2023-03-10 中兴通讯股份有限公司 防止用户跟踪的方法和设备、存储介质和电子设备

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU701680B2 (en) 1995-01-05 1999-02-04 Ericsson Inc. Position registration for mobile phones
FI106605B (fi) * 1997-04-16 2001-02-28 Nokia Networks Oy Autentikointimenetelmä
US20050114680A1 (en) * 2003-04-29 2005-05-26 Azaire Networks Inc. (A Delaware Corporation) Method and system for providing SIM-based roaming over existing WLAN public access infrastructure
US20070178885A1 (en) * 2005-11-28 2007-08-02 Starhome Gmbh Two-phase SIM authentication
US20110004754A1 (en) 2007-06-12 2011-01-06 John Michael Walker Method And Apparatuses For Authentication And Reauthentication Of A User With First And Second Authentication Procedures
US8245039B2 (en) * 2008-07-18 2012-08-14 Bridgewater Systems Corp. Extensible authentication protocol authentication and key agreement (EAP-AKA) optimization
EP2182328A1 (en) 2008-10-28 2010-05-05 Koninklijke KPN N.V. Telecommunications network and method of transferring user data in signalling messages from a communication unit to a data processing centre

Also Published As

Publication number Publication date
WO2011092138A1 (en) 2011-08-04
US20120311335A1 (en) 2012-12-06
EP2529566A1 (en) 2012-12-05
US8954739B2 (en) 2015-02-10
EP3002965B1 (en) 2019-08-21
EP2529566B1 (en) 2015-09-16
EP3002965A1 (en) 2016-04-06

Similar Documents

Publication Publication Date Title
ES2554671T3 (es) Autenticación eficaz de terminal en redes de telecomunicaciones
US11122428B2 (en) Transmission data protection system, method, and apparatus
US11799650B2 (en) Operator-assisted key establishment
KR100625503B1 (ko) 무선 통신 시스템에서 비밀 공유 데이터를 갱신하는 방법
US6918035B1 (en) Method for two-party authentication and key agreement
EP2033479B1 (en) Method and apparatus for security protection of an original user identity in an initial signaling message
KR101350538B1 (ko) 직접 링크 통신의 향상된 보안
US11617082B2 (en) Methods providing NAS connection identifications and related wireless terminals and network nodes
CN108141355B (zh) 使用Diffie-Hellman过程生成会话密钥的方法和系统
ES2968518T3 (es) Generación de claves para protección en redes móviles de próxima generación
ES2905349T3 (es) Métodos que proporcionan seguridad para múltiples conexiones de NAS utilizando contajes independientes y nodos de red y terminales inalámbricos relacionados
AU2017313215B2 (en) Authentication server of a cellular telecommunication network and corresponding UICC
CN101951590B (zh) 认证方法、装置及系统
Elouafiq Authentication and Encryption in GSM and 3GUMTS: An Emphasis on Protocols and Algorithms
JP2014508436A (ja) 無線通信システムにおける短文データの暗号化方法及び装置
Farhat et al. Private identification, authentication and key agreement protocol with security mode setup
CN117546441A (zh) 一种安全通信方法及装置、终端设备、网络设备
Saxena et al. BVPSMS: A batch verification protocol for end-to-end secure SMS for mobile users
US20230246809A1 (en) Processing module for authenticating a communication device in a 3g capable network
Wang et al. Research on an improved proposal of 3G security