ES2953741T3 - Método para personalizar una cooperación de UICC mejorada con un terminal - Google Patents

Método para personalizar una cooperación de UICC mejorada con un terminal Download PDF

Info

Publication number
ES2953741T3
ES2953741T3 ES19753096T ES19753096T ES2953741T3 ES 2953741 T3 ES2953741 T3 ES 2953741T3 ES 19753096 T ES19753096 T ES 19753096T ES 19753096 T ES19753096 T ES 19753096T ES 2953741 T3 ES2953741 T3 ES 2953741T3
Authority
ES
Spain
Prior art keywords
uicc
hss
imsi
data
cryptographic data
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
ES19753096T
Other languages
English (en)
Inventor
Michel Anslot
Marc Lamberton
Philippe Bouckaert
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.)
Thales DIS France SAS
Original Assignee
Thales DIS France SAS
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 Thales DIS France SAS filed Critical Thales DIS France SAS
Application granted granted Critical
Publication of ES2953741T3 publication Critical patent/ES2953741T3/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/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H04W48/14—Access restriction or access information delivery, e.g. discovery data delivery using user query or user detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/04—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration using triggered events
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H04W8/205—Transfer to or from user equipment or user record carrier
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H04W8/265—Network addressing or numbering for mobility support for initial activation of new user

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La presente invención se refiere a un método para personalizar una UICC mejorada que coopera con un terminal, comprendiendo el método: i-enviar desde la UICC mejorada a un D-HSS mejorado un mensaje de solicitud de conexión que comprende una IMSI con un MCC/MNC determinado; ii-Envío desde el D-HSS mejorado a la UICC mejorada al menos un comando y un primer dato criptográfico; iii-Calcular en la UICC mejorada una clave secreta utilizando los primeros datos criptográficos; iv-Envío desde la UICC mejorada al D-HSS mejorado en al menos un mensaje de fallo de Autenticación un comando y un segundo dato criptográfico o una parte del mismo; v - Repetir los pasos ii a iv hasta que la UICC contenga todos los primeros datos criptográficos y el D-HSS mejorado contenga todos los segundos datos criptográficos; vi-Cuando el D-HSS mejorado contiene todos los segundos datos criptográficos, calcular en el D-HSS mejorado la misma clave secreta utilizando los segundos datos criptográficos completos; vii-Asignar por el D-HSS mejorado un IMSI gratuito perteneciente a un operador y transferir del D-HSS mejorado a la UICC mejorada el IMSI gratuito y otros datos de personalización viii-Personalizar la UICC mejorada con el IMSI gratuito, los datos de personalización y el llave secreta. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Método para personalizar una cooperación de UICC mejorada con un terminal
La presente solicitud se refiere a telecomunicaciones y está vinculada al documento EP-3358869.
La presente invención se refiere en particular a la personalización y/o diversificación de UICC (tarjetas de circuito integrado universal) mejoradas inalámbricas.
La personalización consiste en instalar en una UICC que coopere con un terminal de telecomunicación un perfil de un MNO (operador de red móvil) mientras que la diversificación consiste en instalar en una UICC de los parámetros de MNO dados que permiten que la UICC se conecte a su MNO, siendo estos parámetros, por ejemplo, una IMSI (identidad de abonado móvil internacional), una Ki (una clave de cifrado), un ICCID (ID de tarjeta de circuito integrado) y un perfil que contiene parámetros para un algoritmo de autenticación (por ejemplo, OPc, Ri, Ci para el algoritmo de Milenage) inalámbrico. La presente invención propone un procedimiento para personalizar y diversificar de forma inalámbrica una “ UICC universal” fabricada con un perfil genérico no diversificado. Esta operación se realiza sobre el canal de señalización (SS7 o MAP) y optimiza el proceso de fabricación y los costes y no incurre en ningún coste de itinerancia de datos.
Se aplica a redes 2G a 5G y es compatible con los estándares 3GPP.
Se sabe que una UICC proporciona acceso seguro, identificable y autenticado a redes móviles. Desde su creación a principios de la década de 1990 al día actual, la UICC (por ejemplo, una tarjeta SIM) proporciona acceso seguro, identificable y autenticado a redes móviles. También es la parte principal del equipo suministrado por el operador utilizado por los consumidores cuando se conecta a la red móvil.
La SIM continuará proporcionando acceso seguro a las redes móviles del operador.
Hoy en día, toda la personalización y diversificación de la UICC se realiza en fábrica lo que conduce a costes de fabricación y complejidad: Todas las órdenes de UICC de los operadores también requieren que los archivos de entrada y salida intercambien de forma segura los parámetros de UICC principales: ICCID, IMSI, Ki, clave OTA, claves PUK, OPC, Ri, Ci,... Además de ser personalizadas y diversificadas, las UICC producidas tienen un período de validez limitado (típicamente de 3 a 12 meses). Después de la expiración de las UICC no vendidas, el MNO debe liberar recursos de sus sistemas de red y TI. Esto genera costes para el MNO para desintegrar y destruir estas UICC caducadas. El documento US 2015/359026 A1 describe un método para personalizar una UICC que actúa conjuntamente con un terminal, en donde la UICC envía un mensaje de solicitud de conexión que comprende una IMSI con un MCC/MNC dado a un HSS que asigna una IMSI libre que pertenece a un operador y transfiere a la UICC la IMSI libre y otros datos de personalización, sobre los cuales la UICC se personaliza. El documento 3GPP S3-180843 describe un acuerdo de clave basado en Diffie-Hellmann en el que un HSS envía a unos primeros datos criptográficos (exponente público efímero EDCH) de USIM, el USIM calcula una clave secreta mediante el uso de dichos primeros datos criptográficos, y el USIM envía a los segundos datos criptográficos de HSS (exponente público efímero EDCH), tras lo cual el HSS y el USIM calculan la misma clave secreta.
La invención tiene como objetivo realizar la personalización de la UICC y la diversificación dinámicamente cuando se usa la primera vez. La invención se define en las reivindicaciones.
Se conoce a partir de la solicitud de patente europea EP-3358868 que puede establecerse un canal de comunicación bidireccional entre un servidor y un elemento de seguridad que coopera con un terminal en una red de telecomunicaciones celular para intercambiar datos y comandos. En esta solicitud de patente, se describe que este canal de comunicación bidireccional puede establecerse mediante:
- Enviar un primer mensaje de señalización de solicitud de fijación desde el terminal al servidor, comprendiendo el primer mensaje un MCC y un MNC del servidor, y al menos una parte de un identificador único del elemento de seguridad, estando provisto el servidor con el identificador único;
- Enviar desde el servidor al elemento de seguridad, en al menos un primer mensaje de señal:
- Al menos un comando;
- Un identificador de correlación si se deben enviar mensajes adicionales desde el elemento de seguridad al servidor; - Una primera carga útil que comprende datos;
- Ejecutar el comando en el elemento seguro.
En resumen, esta solicitud propone usar el canal de señalización (MAP o SS7) para intercambiar datos y comandos entre el elemento de seguridad (UICC) y un elemento de la red (un HSS mejorado también llamado D-HSS+).
La presente invención propone usar dicho mecanismo para intercambiar datos entre una UICC y un D-HSS para personalizar y/o diversificar una UICC sobre el canal de señalización.
Este fin se alcanza gracias a un método para personalizar una UICC que actúa conjuntamente con un terminal, comprendiendo el método:
i- Enviar desde la UICC a un D-HSS, que es un HSS mejorado, un mensaje de petición de conexión que comprende una IMSI con un MCC/MNC dado;
ii- Enviar desde el D-HSS hasta la UICC al menos un comando y unos primeros datos criptográficos;
iii- Calcular en la UICC una clave secreta usando los primeros datos criptográficos;
iv- Enviar desde la UICC al D-HSS en al menos un mensaje de fallo de autenticación un comando y unos segundos datos criptográficos o una parte de los mismos;
v- Repetir las etapas ii a iv hasta que la UICC contenga todos los primeros datos criptográficos y el D-HSS contiene los segundos datos criptográficos;
vi- Cuando el D-HSS contiene todos los segundos datos criptográficos, calcular en el D-HSS la misma clave secreta usando los segundos datos criptográficos completos;
vii- Asignar por el D-HSS una IMSI libre que pertenece a un operador y que se transfiere desde el D-HSS a los datos de personalización de UICC que incluyen la IMSI libre y otros datos de personalización
viii- Personalizar la UICC con los datos de personalización y la clave secreta. Preferiblemente, los datos de personalización se cifran con la clave secreta y luego se transfieren desde el D-HSS a la UICC.
Ventajosamente, las primera y segunda claves criptográficas son números intercambiados de Diffie-Hellman, siendo los primeros datos criptográficos A = ga mod p y siendo los segundos datos criptográficos B = gb mod p, donde p y g son números previamente acordados por el D-HSS y la UICC, siendo “ a” un número aleatorio seleccionado por el D-HSS y siendo “ b” un número aleatorio seleccionado por la UICC.
Preferiblemente, la UICC envía en un mensaje de autenticación el IMEI del terminal con el que coopera y el D-HSS usa ese IMEI para seleccionar un MNO para el usuario del terminal.
Ventajosamente, el D-HSS envía un commando a la UICC en un mensaje de Ack de SAI para solicitar al usuario que introduzca el nombre de un MNO.
Ventajosamente, el D-HSS personaliza la UICC enviando datos de personalización para el MNO seleccionado a la UICC, conteniendo los datos de personalización un IMSI, una ICCID, un OPc, una Ri y una Ci enviada en múltiples mensajes de Ack de SAI que comprenden comandos.
Preferiblemente, cada uno de los múltiples mensajes de Ack de SAI comprende diferentes IMSl utilizados para correlacionar el diálogo entre el D-HSS y la UICC.
Ventajosamente, una vez que la UICC se personaliza, el D-HSS proporciona la red MNO seleccionada con el IMSI/Ki para permitir que la UICC se comunique con la red MNO seleccionada.
La invención también se refiere a una UICC dispuesta para implementar este método y un D-HSS dispuesto para implementar este método según las reivindicaciones 9 y 10.
La invención se entenderá mejor en la lectura de la siguiente descripción de las figuras que representan un conjunto completo de intercambios que permiten personalizar o diversificar una UICC+ (una UICC especial) según la invención. Más precisamente:
- Las figuras 1A, 1B y 1C representan etapas diferentes preliminares que permiten establecer un canal seguro entre un terminal que comprende un elemento de seguridad mejorado (UICC+) según la invención y un D-HSS mejorado; - Las figuras 2A y 2B representan tres opciones para asignar una IMSI a una UICC+ al nivel de un D-HSS+;
- Las figuras 3A a 3C representan las etapas de personalización de una UICC+ de acuerdo con la invención.
El propósito de la invención es personalizar o diversificar una UICC+ utilizando solo los intercambios de MAP (Parte de aplicación móvil) que es un protocolo de capa de aplicación usado por diversos elementos en redes de núcleo móvil GSM, UMTS y GPRS para proporcionar servicios a usuarios de teléfonos móviles (terminales). La MAP se puede transportar usando protocolos SS7 “ tradicionales” en TDM (T1 y E1) o sobre IP usando SIGTRAN.
La figura 1A representa diferentes etapas preliminares (1 a 18) que permiten establecer un canal seguro entre un terminal 10 que comprende un elemento de seguridad mejorado (UICC+) según la invención y un D-HSS 12 mejorado (llamado D-HSS+).
Se representan algunos otros actores: Una MME (Entidad de gestión de movilidad) 11, un HSS 13 de un MNO y un MNO 14.
En la etapa 1, un fabricante de UICC emite UICC únicas.
Por “ única” , se entiende que todas las UICC emitidas son estrictamente idénticas o pueden emitirse con un MNO_ID dado. No se proporcionan por ninguna suscripción.
En las etapas 2 y 3, el MNO 14 proporciona previamente una pluralidad de IMSl y las envía al D-HSS+ 12. El D-HSS 12 usará esta IMSI cuando un abonado selecciona el MNO.
En la etapa 3, el MNO carga archivos de entrada (IMSI) al D-HSS+ 12. Por lo tanto, el D-HSS+ 12 está provisto de estas IMSI.
En la etapa 4, el MNO 14 carga una lista de archivos de entrada de IMSI al D-HSS+ 12. Esta lista contiene el MNO_ID y las IMSI correspondientes. El D-HSS+ 12 se configura con la lista de MNO_ID, lo que permite identificar el MNO. Este MNO_ID se recupera directamente en el IMSI (primer caso, el operador del haz), o se configura en la UICC (segundo caso, MNO identificado), o se selecciona por el usuario (tercer caso). Estos tres casos se detallarán a continuación. En la etapa 5, el usuario del terminal 10 cambia en su terminal que intenta conectarse a una red de telecomunicaciones. Para ello, se elige una IMSI aleatoria (RDN_IMSI) en la UICC+ en una lista o intervalo definido (por ejemplo, una IMSI entre 20.000). Esta lista o intervalo de IMSI se almacenan en la UICC+ al nivel de su fabricación. Los códigos MCC/MNC de esta IMSI son los de D-HSS+ 12 con el que se comunica la UICC+ en las etapas preliminares. En la etapa 6, el terminal 10 envía un mensaje de solicitud de conexión a la MME 11 que comprende la IMSI seleccionada aleatoriamente en el intervalo o la lista definidos. A continuación, la MME reenvía esta solicitud (etapa 7) en un mensaje de SAI (ENVIAR_INFO_AUTENTICACIÓN) al D-HSS+ 12.
En la etapa 8, el D-HSS+ 12 responde a esta solicitud con un mensaje Ack de SAI que contiene un vector compuesto de: - Un comando (aquí DH1 para Diffie-Hellman 1)
- Una IMSI (aquí denominada SIGUIENTE_IMSI_1)
- Una clave de Diffie-Hellman (16 bytes, de 0 a 15), constituyendo esta clave unos primeros datos criptográficos - Un valor XRES
La MME 11 reenvía el commando DH1, el SIGUIENTE_IMSI_1 y la clave criptográfica a la UICC+ 10 en un parámetro de solicitud de autenticación (AUTN). Un parámetro AUTN permite enviar 15 bytes.
En la etapa 10, la UICC+ calcula una clave secreta Ki basada en la clave de Diffie-Hellman recibida y almacena esta clave secreta Ki. También genera gracias a esta clave un código PUK, un código PUK2 y una clave OTA. En la etapa 11, la UICC+ 10 envía un mensaje de fallo de autenticación a la MME 11 que contiene:
- La RDN_IMSI
- Un mensaje de fallo de sincronización
- Un testigo de resincronización AUTS que comprende un comando (aquí DH2), los ocho primeros bytes de unos segundos datos criptográficos (la longitud total de la clave criptográfica es 16 bytes) y un MNO_ID si dicho ID está disponible. Como se explicará más adelante, el método de la invención permite personalizar y diversificar la UICC+. Se debe hacer una personalización si el nombre de un MNO ya se almacena en la UICC+ (un haz de UICC+ se fabrica para un operador determinado). Una diversificación puede tener lugar cuando no está presente ningún nombre de MNO en la UICC+ 10 fabricada.
A continuación, la MME envía al D-HSS+ (etapa 12), en un mensaje de SAI, el RDN_IMSI y el testigo AUTS.
En la etapa 13, el D-HSS+ 12 envía a la MME 11 otro mensaje de SAI que contiene un vector que comprende un commando (nXt para “ siguiente” ), SIGUIENTE_IMSI_1 y otro valor Xr Es .
El comando y el SIGUIENTE_IMSI_1 se envían a continuación por la MME 11 a la UICC+ 10 en un mensaje de solicitud de autenticación.
En la etapa 15, la UICC+ 10 responde con un RES y la MME envía (en la etapa 16) un mensaje de actualización de ubicación al D-HSS+ 12.
En la etapa 17, el D-HSS+ 12 responde con un mensaje de Error de actualización de localización (itinerancia no permitida) ya que solo los ocho primeros bytes de la clave criptográfica de la UICC+ se han enviado al D-HSS+ 12 y el final del proceso de Diffie-Hellman necesita los 16 bytes de esta clave. En la etapa 18, la MME 11 envía un mensaje de rechazo de conexión a la UICC+ (no permitida PLMN).
La figura 1B muestra las siguientes etapas, etapa 19 después de la etapa 18.
En la etapa 19, la UICC+ 10 establece el valor de IMSI a SIGUIENTE_IMSI_1 y envía un comando de actualización al terminal. Este último ejecuta la actualización en la etapa 20.
En la etapa 21, la UICC+ 10 envía un mensaje de solicitud de conexión a la MME 11 que contiene SIGUIENTE_IMSI_1 y la MME 11 envía al D-HSS+ 12 esta IMSI en un mensaje de SAI (etapa 22).
En la etapa 23, el D-HSS+ 12 envía a la MME 11 en un mensaje de Ack de SAI un vector que contiene un commando NXT (siguiente), una nueva IMSI (SIGUIENTE_IMSI 2) y un XRES. Se utiliza la nueva IMSI (SIGUIENTE_IMSI 2) para que la EGM no reciba dos veces la misma IMSI. Esto es cierto para la siguiente descripción. La MME 11 reenvía el commando y la nueva IMSI en un mensaje de solicitud de autenticación a la UICC+ (etapa 24).
El comando NXT es interpretado por la UICC+10 como una solicitud para enviar la parte restante de los segundos datos criptográficos de 16 bytes. A continuación, envía (etapa 25) un mensaje de fallo de autenticación que contiene SIGUIENTE_IMSI_1, un fallo de sincronización (un estado del mensaje de fallo de autenticación) y un AUTS que comprende un comando (DH3) y los últimos ocho bytes (8 a 15) de la clave criptográfica. En la etapa 26, la MME reenvía el SIGUIENTE_IMSI_1 y el AUTS al D-HSS+ 12 en un mensaje de SAI.
El D-HSS+ 12 calcula entonces la clave Ki basada en las claves de Diffie-Hellman intercambiadas. También genera la clave de PUK, PUK2 y OTA (etapa 27). Este es el final del intercambio de Diffie-Hellman, la UICC+ 10 y el D-HSS+ 12 que tienen las claves necesarias para intercambiar secretos.
El establecimiento de un canal seguro se basa en este ejemplo en un protocolo de Diffie-Hellman. Algunos otros protocolos son, por supuesto, posibles para establecer un canal seguro, como por ejemplo mediante el uso de claves simétricas (SCP03, por ejemplo) o claves asimétricas (SCP11, por ejemplo). También es posible derivar una clave utilizando la IMSI aleatoria (o una parte de la misma) seleccionada por la UICC+ (esta clave se calcula en la UICC+ y, después de la transmisión de la IMSI aleatoria al D-HSS+ 12, calculada en esta D-HSS+ 12 usando toda la IMSI (MSIN de hecho) o una parte de la misma).
A continuación, el procedimiento continúa con etapas similares a las etapas 13 a 26 para recuperar el IMEI del terminal 10 (el terminal puede ser un terminal subvencionado perteneciente a un haz): En la etapa 28, el D-HSS+ 12 envía a la MME 11 en un mensaje de Ack de SAI un vector que comprende el commando SIGUIENTE, SIGUIENTE_IMSI_2 y XRES. La MME reenvía (etapa 29) el commando SIGUIENTE y SIGUIENTE_IMSI 2 a la UICC+ en un mensaje de solicitud de autenticación.
En la etapa 30, la UICC+ 10 responde a la MME 11 con un RES comprendido en un mensaje de respuesta de autenticación y la MME 11 envía un mensaje de actualización de localización al D-HSS+ 12 (etapa 31).
En la etapa 32, el D-HSS+ 12 responde con un mensaje de Error de actualización de localización (itinerancia no permitida).
En la etapa 33, la MME 11 envía un mensaje de rechazo de conexión a la UICC+ (no permitida PLMN). En la etapa 34, la UICC+ 10 establece el valor de IMSI a SIGUIENTE_IMSI_2 y envía un comando de actualización al terminal. Este último ejecuta la actualización en la etapa 35.
En la etapa 36, la UICC+ 10 envía un mensaje de solicitud de conexión a la MME 11 que contiene SIGUIENTE_IMSI_2 y la MME 11 envía al D-HSS+ 12 esta IMSI en un mensaje de SAI (etapa 37).
La figura 1C muestra las siguientes etapas, etapa 38 después de la etapa 37.
En la etapa 38, el D-HSS+ 12 envía a la MME 11 en un mensaje de Ack de SAI un vector que contiene un commando NXT (siguiente), una nueva IMSI (SIGUIENTE_IMSI_3) y un XRES. Se utiliza la nueva IMSI (SIGUIENTE_IMSI_3) para que la EGM no reciba dos veces la misma IMSI. Todos estos IMSI (SIGUIENTE_IMSI X) son IMSI temporales. La MME 11 reenvía el commando y la nueva IMSI en un mensaje de solicitud de autenticación a la UICC+ (etapa 39). El comando NXT es interpretado por la UICC+ como una solicitud para enviar el IMEI del terminal con el que coopera. A continuación, envía (etapa 40) un mensaje de fallo de autenticación que contiene SIGUIENTE_IMSI_2, un mensaje de fallo de sincronización y un AUTS que comprende un comando (IMEI) y el IMEI del terminal. En la etapa 41, la MME reenvía el SIGUIEn Te_IMSI_2 y el AUt S al D-HSS+ 12 en un mensaje de SAI.
Las etapas 42 a 51 son idénticas a las etapas 28 a 37, que se reemplaza con SIGUIENTE_IMSI 2 por SIGUIENTE_IMSI_3. Después de estas diferentes etapas, existen diferentes posibilidades. Estas se representan en las figuras 2A y 2B. Para el primer caso (operador de paquete), el terminal pertenece a un operador de haz (el MNO ha decidido vender sus terminales a un coste bajo), el D-HSS+ 12 identifica este MNO gracias al IMEI enviado por la UICC+ 10 (etapas 40 y 41) y asigna el MNO IMSi basándose en reglas de haz.
Para el segundo caso (MNO identificado), las UICC+ diferentes no están diversificadas (pertenecen a un operador determinado). En este caso, el D-HSS+ 12 identifica un operador basándose en el m No_ID (etapas 11 y 12) y asigna el MNO IMSI basándose en las reglas MNO.
Para el tercer caso, todas las UICC+ son estrictamente idénticas y el usuario puede elegir su operador. En este caso, después de la etapa 51 de la figura 1C, el método continúa con la etapa 60 de la figura 2A.
La etapa 60 consiste en iniciar en el D-HSS+ 12 el envío de un mensaje que permite al usuario del terminal elegir su operador (MNO). En la etapa 61, un mensaje de Ack de SAI que contiene un vector que comprende un comando (Seleccionar), Siguiente_IMSI_4, y un mensaje “ seleccionar un operador” se envía a la MME 11, junto con un XRES. A continuación, la MME 11 transmite (etapa 62) a la UICC+ un mensaje de solicitud de autenticación que contiene este vector (Cmd=Seleccionar, Siguiente_lMSI_4, “ Seleccionar un operador...” ).
La UICC+ 10 responde con un RES (etapa 63-respuesta de autenticación) que se modifica por la MME 11 en un mensaje de actualización de ubicación (etapa 64) transmitida al D-HSS+ 12.
El D-HSS+ 12 responde con un mensaje de Error de actualización de localización (itirenacia no permitida - etapa 65) y la MME 11 transmite a la UICC+ 10 (etapa 66) un mensaje de rechazo de conexión (no permitido en la PLMN). En la etapa 67, se lanza un applet STK (Kit de herramientas Sim) sobre el terminal para solicitar al usuario de este terminal que introduzca el nombre de un MNO, por ejemplo, en forma abreviada (NET).
Después de un comando de registro de lectura (etapa 68) lanzado por el terminal (Leer Registro Rsp (IMSI(SIGUIENTE_IMSI_4), “ NET” )), la UICC+ 10 establece el valor SIGUIENTE_IMSI_4 y NET y envía un comando de actualización a la etapa 48 de tipo dispositivo -(etapa 69).
En la etapa 70, la UICC+ 10 envía un mensaje de petición de conexión a la MME 11 que contiene SIGUIENTE_IMSI_4. En la etapa 71, la MME envía el Siguiente_IMSI_4 en un mensaje de SAI al D-HSS+. Estas últimas respuestas con un mensaje de SAI-Ack (un vector (Cmd=“ Give nombre del operador” , SIGUIENTE_IMSI_5, XRES) a la MME (etapa 72) y la MME envía una solicitud de autenticación (Cmd=“ Dar nombre del operador” , SIGUIENTE_IMSI_5) a la UICC+ (etapa 73). El comando “ Proporcionar nombre de operador” solicita al usuario que introduzca el nombre de un operador (MNO). En la etapa 74, la UICC+ envía un mensaje de autenticación_fallo que contiene SIGUIENTE_IMSI_5, sinc_fallo y un AUTS que comprende el comando “ Dar el nombre del operador” y el nombre del operador (“ NET” ) a la MME. El usuario ha entrado previamente el nombre “ NET” a través de la interfaz de usuario de su terminal.
La MEE 11 luego (etapa 75) envía al D-HSS+ 12 en un mensaje de SAI, SIGUIENTE_IMSI_5 y un AUTS que contiene el commando “ dar el nombre del operador” y el nombre del MNO (“ NET” ). En la etapa 76, el D-HSS+ 12 identifica un operador basándose en el nombre “ NET” y el país de origen donde se ha encendido el terminal. El D-HSS+ 12 asigna el MNO IMSI basado en reglas “ NET” . Estas reglas se proporcionan en el D-HSS+, el país de origen se obtiene por el canal de señalización y el D-HSS+ tiene una tabla que asocia un MNO a la pareja “ país de origen”/“ NET” .
Para los casos “ operador de paquete” y “ MNO identificado” , las etapas 60 a 76 no están implementadas.
Para todos los tres casos, se seguirá el siguiente procedimiento (etapa 100 de la figura 3A).
Las figuras 3A a 3C representan las etapas de personalización de una UICC+ de acuerdo con la invención. Estas etapas son comunes a los tres casos presentados en las figuras 2A y 2B.
La primera etapa (100) consiste en cifrar con la clave criptográfica, al nivel de los datos de personalización de D-HSS+ 12 que se transmitirán por fragmentos a la UICC+. Estos datos de personalización contienen un IMSI, una ICCID, un OPc, un Ri y un Ci.
Aquí se supone que se necesitan tres fragmentos para transmitir estos datos de personalización a la UICC+ 10.
En la etapa 101, el D-HSS+ 12 envía a la MME 11 en un mensaje de Ack de SAI un vector que comprende un comando “ PERSO1” , primeros datos de personalización “ perso_datos_1 ” , una nueva IMSI (SIGUIENTE_IMSI_6) y un XRES.
La MME 11 envía a la UICC+10 este vector (etapa 102 - en un mensaje de solicitud de autenticación) y la última respuesta a la MME 11 con una respuesta de autenticación (RES - etapa 103). A continuación, la MME 11 envía al D-HSS+ 12 (etapa 104) un mensaje de actualización de ubicación al que responde el D-HSS+ 12 con un mensaje de Error de actualización de localización (itinerancia no permitida - etapa 105). A continuación, la MME 11 informa a la UICC+ 10 (etapa 106) que se ha rechazado la unión (no permitida la conexión (no permitida la PLMN)).
En la etapa 107, la UICC+ 10 establece el valor de IMSI al valor SIGUIENTE_IMSI_6 y envía un mensaje de actualización. A continuación, el terminal envía (etapa 110) un mensaje de petición de conexión que contiene SIGUIENTE_IMSI_6 a la MME 11 y el último transmite al D-HSS+ 12 esta IMSI al D-HSS+ 12 en un mensaje de SAI (etapa 111).
Las etapas 112 a 121 son las mismas que las etapas 114 a 121, el commando PERSO1 se reemplaza por PERSO2 y perso_datos_1 que se reemplaza por otros datos de personalización perso_datos_2. Se utiliza otra IMSI (SIGUIENTE_IMSI_7) para estas etapas.
En la etapa 122, el mismo formato de mensaje se usa por la D-HSS+ 12 con un comando PERSO3, un SIGUIENTE_IMSI_8 y perso_datos_3. Las etapas 122 a 127 son idénticas a las etapas 112 a 117. Siguiente_IMSI_8 es la IMSI del MNO.
Después de las etapas 122 a 127, se supone que todos los datos de personalización han sido recibidos por la UICC+10 y, en la etapa 128, la UICC+ 10 decodifica todos los datos de personalización y los escribe en su sistema de archivos.
La UICC+ 10 ahora está completamente personalizada.
Después de un comando proactivo de refresco (etapa 129), el D-HSS+ 12 proporciona al MNO HSS/BSS si ya no se ha realizado (etapa 130).
En la etapa 131, el D-HSS+ 12 proporciona el MNO con el par IMSI/Ki. Después de eso, la UICC+ 10 envía un commando de actualización al terminal (etapa 132), este comando se ejecuta (etapa 133) y la UICC+ ahora puede enviar un mensaje de petición de conexión (etapa 134) al MNO HSS 13, conteniendo este mensaje de petición de conexión el IMSI. Dado que este HSS 13 ha sido proporcionado con el IMSI/Ki en la etapa 130, el MNO HSS 13 puede (etapa 135) enviar una respuesta de conexión a la UICC+ y (en la etapa 136), el terminal/UICC+ ahora está unido a su nueva red MNO. A continuación, el usuario puede recibir desde su MNO un SMS que contiene un MSISDN, un código de PIN (si difiere de un código de PIN predeterminado como 0000) y un código PUK.
En resumen, la invención permite crear un diálogo entre un terminal y un servidor de descubrimiento D-HSS+ sin unirse a una red celular, con el objetivo de personalizar remotamente la UICC+ universal con las credenciales de la red de operador objetivo entre cientos de operadores de red. La invención usa una UICC+ no diversificada, la UICC+ universal producida es única con el mismo perfil predeterminado para todos los operadores.
La invención está diseñada para redes 2G, 3G y 4G/LTE sin modificaciones estándar. La invención también sería adecuada para redes 5G.
El diálogo entre el D-HSS+ y la UICC+ usa los tres mensajes de autenticación intercambiados durante la unión del dispositivo. El mensaje de información de autenticación de envío envía la IMSI del perfil universal (o una parte del mismo). La respuesta de información de autenticación enviada incluye parámetros de RAND, AUTN y un error de sincronización se usa para enviar de vuelta a los datos D-HSS+ en el parámetro AUTS. Estos cuatro parámetros se utilizan para intercambiar datos y ejecutar comandos entre la UICC+ y el servicio de D-HSS+.
Esta fase de unión mejorada puede usar una raíz mundial D-HSS+ que contiene un HLR/HSS de descubrimiento (D-HSS+) para configurar la UICC+ para unirse a la red de operador dirigida/pendiente. Esta fase de autenticación mejorada no une el dispositivo a la red de raíz D-HSS+. Solo los primeros mensajes (Enviar información de autenticación) se intercambian a través del HLR/HSS de descubrimiento (D-HSS+). Este mecanismo no se carga sobre las redes de operador y no se intercambian datos cargables. Durante el diálogo de autenticación mejorado entre la UICC+ y el HLR/HSS de descubrimiento (D-HSS+), el D-HSS+ puede configurar de forma remota la UICC+ a través de comandos y claves criptográficas intercambiadas en los parámetros RAND, AUTN y AUTS para personalizar la UICC+ con ICCID, IMSI, Ki, claves OTA, PUK, PUK2, PIN, PIN , OPC, Ri y Ci y/o recuperar el IMEI y/o el MNO_ID (en caso de tarjetas producidas con un logotipo de un MNO, por ejemplo).

Claims (10)

REIVINDICACIONES
1. Método para personalizar una UICC que actúa conjuntamente con un terminal, comprendiendo dicho método:
i- Enviar desde dicha UICC (10) a un D-HSS (12), que es un HSS mejorado, un mensaje de petición de conexión que comprende una IMSI con un MCC/MNC dado;
ii- Enviar desde dicho D-HSS (12) a dicha UICC (10) al menos un comando y unos primeros datos criptográficos;
iii- Calcular en dicha UICC (10) una clave secreta Ki usando dichos primeros datos criptográficos; iv- Enviar desde dicha UICC (10) a dicho D-HSS (12) en al menos un mensaje de fallo de autenticación un comando y unos segundos datos criptográficos o una parte de los mismos;
v- Repetir las etapas ii a iv hasta que dicha UICC contiene todos los primeros datos criptográficos y dicho D-HSS (12) contiene los segundos datos criptográficos;
vi- Cuando dicho D-HSS (12) contiene todos los segundos datos criptográficos, calcular en dicho D-HSS (12) la misma clave secreta usando dichos segundos datos criptográficos completos; vii- Asignar (100) mediante dicho D-HSS (12) una IMSI libre que pertenece a un operador y que se transfiere desde dicho D-HSS (12) a dichos datos de personalización de UICC (10) que incluyen dicha IMSI libre y otros datos de personalización;
viii- Personalizar (128) dicha UICC (10) con dichos datos de personalización y dicha clave secreta.
2. Método según la reivindicación 1, en donde dichos datos de personalización se cifran con dicha clave secreta y luego se transfieren (100) desde dicho D-HSS (12) a dicha UICC (10).
3. Método según la reivindicación 2, en donde dichos primer y segundo datos criptográficos son números intercambiados de Diffie-Hellman, siendo dichos primeros datos criptográficos A = ga mod p y siendo dichos segundos datos criptográficos B = gb mod p, donde p y g son números previamente acordados por dicho D-HSS (12) y dicha UICC (10), siendo “ a” un número aleatorio seleccionado por dicho D-HSS (12) y siendo “ b” un número aleatorio seleccionado por dicha UICC (10).
4. Método según cualquiera de las reivindicaciones 1 a 3, en donde dicha UICC (10) envía en un mensaje de autenticación el IMEI de dicho terminal con el que coopera y dicho D-HSS (12) usa ese IMEI para seleccionar un MNO para el usuario de dicho terminal.
5. Método según cualquiera de las reivindicaciones 1 a 3, en donde dicho D-HSS (12) envía un commando a dicha UICC (10) en un mensaje de Ack de SAI para solicitar al usuario que introduzca el nombre de un MNO.
6. Método según la reivindicación 4, en donde dicho D-HSS (12) personaliza dicha UICC (10) enviando datos de personalización para el MNO seleccionado a dicha UICC (10), conteniendo dichos datos de personalización una IMSI, un ICCID, un OPc, un Ri y un Ci enviado en múltiples mensajes de Ack de SAI que comprenden comandos.
7. Método según la reivindicación 6, en donde cada uno de dichos múltiples mensajes de Ack de SAI comprende diferentes IMSI usadas para correlacionar el diálogo entre dicho D-HSS (12) y dicha UICC (10).
8. Método según las reivindicaciones 6 o 7, en donde, una vez que dicha UICC se personaliza, dicho D-HSS proporciona la red MNO seleccionada con un IMSI/Ki para permitir que dicha UICC se comunique con dicha red MNO seleccionada.
9. UICC (10) configurada para:
i- Enviar desde dicha UICC (10) a un D-HSS (12), que es un HSS mejorado, un mensaje de petición de conexión que comprende una IMSI con un MCC/MNC;
ii- Recibir mediante dicha UICC (10) al menos un commando y unos primeros datos criptográficos enviados por dicho D-HSS (12);
iii- Calcular en dicha UICC (10) una clave secreta Ki usando dichos primeros datos criptográficos; iv- Enviar desde dicha UICC (10) a dicho D-HSS (12) en al menos un mensaje de fallo de autenticación un comando y unos segundos datos criptográficos o una parte de los mismos;
v- Repetir las etapas ii a iv hasta que dicha UICC contiene todos los primeros datos criptográficos y dicho D-HSS (12) contiene los segundos datos criptográficos;
vi- Recibir desde dicho D-HSS (12) datos de personalización que incluyen una IMSI libre que pertenece a un operador y otros datos de personalización;
vii- Personalizar (128) dicha UICC (10) con dichos datos de personalización y dicha clave secreta (Ki).
10. D-HSS (12), que es una HSS mejorada, configurada para:
i- Recibir desde una UICC (10) un mensaje de solicitud de conexión que comprende una IMSI con un MCC/MNC;
ii- Enviar desde dicho D-HSS (12) a dicha UICC (10) al menos un comando y unos primeros datos criptográficos, con el fin de que dicha UICC (10) calcule una clave secreta Ki usando dichos primeros datos criptográficos;
iii- Recibir desde dicha UICC (10) en al menos un mensaje de fallo de autenticación, un comando y unos segundos datos criptográficos o una parte de los mismos;
iv- Repetir las etapas ii a iii hasta que dicha UICC contiene todos los primeros datos criptográficos y dicho D-HSS (12) contiene los segundos datos criptográficos;
v-Cuando dicho D-HSS (12) contiene todos los segundos datos criptográficos, calcular en dicho D-HSS (12) la misma clave secreta usando dichos segundos datos criptográficos completos; vi-Asignar (100) mediante dicho D-HSS (12) una IMSI libre que pertenece a un operador y que se transfiere desde dicho D-HSS (12) a dichos datos de personalización de UICC (10) que incluyen dicha IMSI libre y otros datos de personalización.
ES19753096T 2018-08-23 2019-08-16 Método para personalizar una cooperación de UICC mejorada con un terminal Active ES2953741T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP18306134.0A EP3614706A1 (en) 2018-08-23 2018-08-23 Method for personalizing an improved uicc cooperating with a terminal
PCT/EP2019/072049 WO2020038847A1 (en) 2018-08-23 2019-08-16 Method for personalizing an improved uicc cooperating with a terminal

Publications (1)

Publication Number Publication Date
ES2953741T3 true ES2953741T3 (es) 2023-11-15

Family

ID=64453437

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19753096T Active ES2953741T3 (es) 2018-08-23 2019-08-16 Método para personalizar una cooperación de UICC mejorada con un terminal

Country Status (7)

Country Link
US (1) US11895486B2 (es)
EP (2) EP3614706A1 (es)
JP (1) JP7096947B2 (es)
CN (1) CN112655231B (es)
BR (1) BR112021003272A2 (es)
ES (1) ES2953741T3 (es)
WO (1) WO2020038847A1 (es)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3621333A1 (en) * 2018-09-05 2020-03-11 Thales Dis France SA Method for updating a secret data in a credential container
EP4149127A1 (en) * 2021-09-10 2023-03-15 Thales Dis France SAS A method for updating a secure element cooperating with a telecommunication terminal
FR3144733B1 (fr) * 2022-12-28 2025-08-29 Thales Sa Procédé amélioré de provisionnement d'un équipement utilisateur avec un profil de souscription d'un opérateur final

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011115407A2 (en) * 2010-03-15 2011-09-22 Samsung Electronics Co., Ltd. Method and system for secured remote provisioning of a universal integrated circuit card of a user equipment
US20130163762A1 (en) * 2010-09-13 2013-06-27 Nec Corporation Relay node device authentication mechanism
EP2461613A1 (en) * 2010-12-06 2012-06-06 Gemalto SA Methods and system for handling UICC data
KR101954450B1 (ko) * 2011-09-05 2019-05-31 주식회사 케이티 내장 ｕｉｃｃ의 인증정보를 이용한 인증방법과, 그를 이용한 프로비저닝 및 ｍｎｏ 변경 방법, 그를 위한 내장 ｕｉｃｃ, ｍｎｏ 시스템 및 기록매체
EP2632195A1 (en) * 2012-02-24 2013-08-28 Alcatel Lucent Smart card personnalization
EP2704467A1 (en) * 2012-09-03 2014-03-05 Alcatel Lucent Smart card initial personnalization with local generation of keys
US20150359026A1 (en) * 2012-12-21 2015-12-10 Nec Corporation Radio communication system, radio access network node, communication device, and core network node
KR20140098872A (ko) * 2013-01-31 2014-08-08 남궁용주 모바일 nfc단말기 웹 서비스를 위한 바이오인식과 tsm 기반의 보안 시스템 및 방법
US9100175B2 (en) * 2013-11-19 2015-08-04 M2M And Iot Technologies, Llc Embedded universal integrated circuit card supporting two-factor authentication
US9994054B2 (en) * 2014-08-19 2018-06-12 Entrust, Inc. Generating an identity document with personalization data and unique machine data
EP3358867A1 (en) 2017-02-03 2018-08-08 Gemalto Sa Method for managing communication between a server and a user equipment
SE542465C2 (en) * 2017-12-01 2020-05-12 Tele2 Iot Ab Methods, subscriber identity component and managing node for providing wireless device with connectivity

Also Published As

Publication number Publication date
BR112021003272A2 (pt) 2021-05-18
EP3614706A1 (en) 2020-02-26
EP3841769A1 (en) 2021-06-30
CN112655231A (zh) 2021-04-13
JP7096947B2 (ja) 2022-07-06
CN112655231B (zh) 2024-05-28
EP3841769B1 (en) 2023-07-05
JP2021534691A (ja) 2021-12-09
US20210258781A1 (en) 2021-08-19
WO2020038847A1 (en) 2020-02-27
US11895486B2 (en) 2024-02-06

Similar Documents

Publication Publication Date Title
US11825551B2 (en) Method for establishing a bidirectional communication channel between a server and a secure element, corresponding servers and secure element
US10075205B2 (en) Method and apparatus for provisioning profiles
ES2535386T3 (es) Procedimientos y dispositivos para gestión durante la comunicación (OTA) de módulos de identificación de abonado
US10231127B2 (en) Methods and devices for performing a mobile network switch
ES2953741T3 (es) Método para personalizar una cooperación de UICC mejorada con un terminal
CN104137588A (zh) 智能卡初始个性化
ES2954628T3 (es) Método para permitir una solución multi-IMSI en redes 5G