ES2957936T3 - Método para establecer un canal de comunicación bidireccional entre un servidor y un elemento de seguridad, unos servidores correspondientes y un elemento de seguridad - Google Patents

Método para establecer un canal de comunicación bidireccional entre un servidor y un elemento de seguridad, unos servidores correspondientes y un elemento de seguridad Download PDF

Info

Publication number
ES2957936T3
ES2957936T3 ES18703004T ES18703004T ES2957936T3 ES 2957936 T3 ES2957936 T3 ES 2957936T3 ES 18703004 T ES18703004 T ES 18703004T ES 18703004 T ES18703004 T ES 18703004T ES 2957936 T3 ES2957936 T3 ES 2957936T3
Authority
ES
Spain
Prior art keywords
server
security element
euicc
message
imsi
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
ES18703004T
Other languages
English (en)
Inventor
Michel Anslot
Marc Lamberton
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 ES2957936T3 publication Critical patent/ES2957936T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/14—Two-way operation using the same type of signal, i.e. duplex
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4588—Network directories; Name-to-address mapping containing mobile subscriber information, e.g. home subscriber server [HSS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5061—Pools of addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5092—Address allocation by self-assignment, e.g. picking addresses at random and testing if they are already in use
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • 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
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/654—International mobile subscriber identity [IMSI] numbers
    • 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
    • H04W12/42—Security arrangements using identity modules using virtual identity modules
    • 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
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • 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/183—Processing at user equipment or user record carrier

Landscapes

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

Abstract

La invención se refiere a un método para establecer un canal de comunicación bidireccional entre un servidor y un elemento seguro que coopera con un terminal en una red de telecomunicaciones celular para intercambiar datos y comandos, comprendiendo el método: a- Enviar un primer mensaje de señalización de solicitud de adjunto desde el terminal a el servidor, comprendiendo el primer mensaje un MCC y un MNC del servidor, y al menos una parte de un identificador único del elemento seguro, estando provisto el servidor del identificador único; b- Envío desde el servidor al elemento seguro, en al menos un primer mensaje de señalización: - al menos un comando; - un identificador de correlación si es necesario enviar más mensajes desde el elemento seguro al servidor; - una primera carga útil que comprende datos; c- Ejecutar en el elemento seguro el comando. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Método para establecer un canal de comunicación bidireccional entre un servidor y un elemento de seguridad, unos servidores correspondientes y un elemento de seguridad
La presente invención se refiere a las telecomunicaciones y propone, entre otras cosas, un método para establecer un canal de comunicación bidireccional entre un servidor y un elemento de seguridad que coopera con un terminal en una red de telecomunicación celular utilizando mensajes de señalización únicamente. El propósito de la invención es no cobrar tarifas que deba pagar el propietario del terminal ni un Mobile Network Operator (Operador de red móvil -MNO).
En las redes de telecomunicación celular convencionales, un elemento de seguridad, tal como una UICC, una eUICC (UICC embebida) o una iUICC (UICC integrada en un chip de un terminal) coopera con el terminal. El terminal puede ser un microteléfono, un teléfono inteligente, una tableta, un reloj,...
El elemento seguro comprende un perfil de suscripción (programas, archivos, claves, estructura de archivos,...) que permite a un suscriptor entrar en comunicación con la red de un MNO. Cuando se enciende el terminal, se conecta a una estación base de este MNO para acceder a Internet, atender llamadas, etc.
Sin embargo, en algunos casos, por ejemplo, en el dominio máquina a máquina (M2M) o el internet de las cosas (loT), el elemento de seguridad no contiene ninguna suscripción de un MNO. Solo puede comprender una aplicación de arranque, una IMSI (identidad internacional de suscriptor móvil) y una clave Ki. Una situación de este tipo permite, por ejemplo, que el usuario del terminal elija un MNO de entre una pluralidad de operadores. Esta solución genera costes de itinerancia durante la descarga del perfil cuando el MNO de arranque está en el extranjero.
En el documento EP 2632 196 A1 se describe un sistema en el que, para una personalización inicial de una tarjeta inteligente acoplada a un dispositivo de comunicación de un usuario que aún no es un abonado de alguna red de telecomunicación, la tarjeta inteligente envía una primera solicitud que comprende una identidad internacional temporal a una entidad de itinerancia, que la reenvía a un registro de localización de abonados, que autentica al usuario por medio de la identidad internacional temporal. La entidad de itinerancia permite entonces que la tarjeta inteligente utilice recursos de la red de telecomunicación.
El problema de esta solución es que hay que proporcionar a la tarjeta inteligente una identidad internacional temporal inicial a una entidad de itinerancia que ya tenga registrada esta tarjeta inteligente en su HLR. Esto genera costes de itinerancia y una reserva de un MSIN a nivel del MNO.
En el documento EP 2704467 A1 y el documento “ Deferred IPv4 address handling via external Radius/Diameter AAA for PDN type IPv4v6” , de Ericsson, para el grupo de trabajo WG3 TSG-CT del 3GPP en la 52a Reunión mantenida en Francia del 20 al 24 de abril de 2009 (XP050338013) se describe un sistema similar.
La invención propone usar unos mensajes de señalización normalizados modificados, intercambiados entre un elemento de seguridad y un servidor, para configurar de forma remota (comunicación inalámbrica) este elemento de seguridad sin incurrir en costes de itinerancia.
En la figura 1 se representan mensajes de señalización normalizados. Tales mensajes se describen en la especificación técnica Ts 124.008 del ETSI para redes 3G y 4G.
Cuando se enciende un terminal (aquí, un microteléfono) que coopera con un elemento de seguridad (aquí una eUICC), el microteléfono envía una orden Read record (Leer registro) a la eUICC. La eUICC responde a esta solicitud enviando su IMSI al microteléfono. El microteléfono se conecta entonces a la estación base que tiene la mayor potencia de señal y envía una solicitud de Incorporación (junto con la IMSI) a una Mobile Management Entity (Entidad de gestión móvil - MME). La MME reenvía esta IMSI en un mensaje SAI(IMSI) (Send Authentication Info [Enviar info. de autenticación]) al HLR/RLV del MNO cuyos MCC/MNC corresponden a los comprendidos en la ImSi. La MME y el HLR / HSS son servidores que contienen al menos un microprocesador para realizar sus tareas.
El HLR / HSS responde entonces a la MME enviándole n vectores de autenticación (RAND y AUTN) en un mensaje SAI Ack (Acuse de recibo de SAI). La MME envía entonces dos valores, RAND y AUTN, en un mensaje Authentication request (Solicitud de autenticación) al microteléfono, el cual los reenvía en una orden de APDU a la eUICC. RAND se utiliza para autenticar la eUICC, y AUTN, para autenticar la red. La eUICC calcula entonces un valor (RES) y se lo envía al microteléfono. El microteléfono reenvía el valor RES a la MME, la cual compara el RES recibido con un valor RES' calculado proporcionado por el HLR / HSS. Si RES = RES', se ha producido una autenticación mutua, y el microteléfono y la red del MNO, pueden intercambiar mensajes adicionales; de lo contrario, la autenticación ha fallado, y se informa en consecuencia al microteléfono.
La presente invención propone utilizar tales mensajes de señalización para configurar remotamente un elemento de seguridad, es decir, sin estar incorporado a ninguna red de operador.
Más precisamente, la presente invención propone un método para establecer un canal de comunicación bidireccional entre un servidor y un elemento de seguridad, tal y como se define en la reivindicación 1.
Preferiblemente, el servidor envía con el primer mensaje de señalización un segundo mensaje de señalización que también contiene datos.
En una realización preferida, los datos contienen un MCC y un MNC de un servidor de un MNO y una IMSI temporal que permite que el elemento de seguridad se incorpore a la red del MNO.
Ventajosamente, el identificador único es:
- un EID del elemento de seguridad, o
- una clave obtenida del EID.
La invención también se refiere a un servidor provisto de un identificador único de un elemento de seguridad, tal y como se define en la reivindicación 5.
La invención también se refiere a un SM-DS+ mejorado que comprende, tal y como se mencionó anteriormente, un servidor, en donde también comprende un servidor SM-DS que proporciona al HSS un MNO de una IMSI temporal transmitida al elemento de seguridad, junto con una clave Ki efímera contenida también en el elemento de seguridad. La invención también se refiere a un elemento de seguridad que comprende un sistema operativo que comprende instrucciones, tal y como se define en la reivindicación 8.
Preferiblemente, el sistema operativo del elemento de seguridad tiene además instrucciones para: d) enviar al servidor, en al menos un segundo mensaje de señalización de solicitud de incorporación, el MCC, el MNC, un identificador de correlación recibido del servidor y una segunda carga útil que contiene datos, y para, en caso necesario, repetir las etapas a) a d) hasta que el elemento de seguridad y el servidor no necesiten intercambiar más datos u órdenes. El elemento de seguridad puede consistir en:
- Una UICC, o
- una eUICC, o
- una iUICC.
La invención también se refiere a un terminal que comprende un elemento de seguridad de este tipo.
Otras características y ventajas de la presente invención se describirán más adelante con respecto a las siguientes figuras, que representan:
- La figura 1 se ha descrito con respecto al estado de la técnica (el flujo de autenticación normal tras el encendido [para 3G/4G]);
- la figura 2 explica el principio de la invención;
- la figura 3 representa distintos formatos de mensajes enviados del terminal / de la eUICC a un servidor. La eUICC es aquí una UICC mejorada que tiene un SO especial, y se denomina en lo sucesivo eUICC+;
- la figura 4 representa unos mensajes especiales enviados por el servidor a la eUICC+, teniendo estos mensajes la longitud de mensajes RAND y AUTN;
- la figura 5 es una tabla que representa un ejemplo de valores de orden utilizados en los mensajes enviados del servidor a la eUICC+;
- la figura 6 es una vista simplificada de un primer caso de uso de la invención;
- la figura 7 representa un ejemplo de un sistema según la invención para este primer caso de uso;
- la figura 8 muestra un ejemplo de unos intercambios entre las distintas entidades de la figura 7;
- la figura 9 representa el flujo de señales intercambiadas entre las distintas entidades una vez que se ha requerido la suscripción para una cierta eUICC+ en un POS y se han ejecutado las etapas de la figura 8;
- la figura 10 representa lo que sucede cuando la eUICC+ se comunica con el D-HSS al identificarse a través de claves de EID;
- la figura 11 representa un ejemplo de una codificación de EID;
- la figura 12 muestra un segundo caso de uso de la invención;
- la figura 13 muestra un ejemplo de una arquitectura de SM-DS+ para este segundo caso de uso;
- la figura 14 representa un flujo de etapas que permiten al usuario de un terminal seleccionar un operador para este segundo caso de uso;
- la figura 15 muestra la comunicación posterior entre la eUICC+ y los elementos de la figura 13 para el segundo caso de uso después de haberse ejecutado las etapas de la figura 14;
- la figura 16 muestra un diagrama de flujo detallado que explica los mensajes intercambiados entre la tarjeta elllCC+ y el D-HSS para el segundo caso de uso utilizando de nuevo claves de EID.
La presente invención se describirá ahora en el ámbito de una red 3G o 4G. La invención es también aplicable a redes de 5G (y otras redes futuras) siempre y cuando se intercambien mensajes de señalización entre el elemento de seguridad y la red al encenderse del terminal.
La invención propone modificar los mensajes de señalización estándar enviados por un elemento de seguridad mejorado y un servidor con el fin de configurar de manera remota el elemento de seguridad mejorado (denominado en lo sucesivo eUICC+). Esta configuración puede consistir, por ejemplo, en el envío de un subprograma corto a la eUICC+ para modificar su IMSI, para cambiar archivos en la eUICC+, utilizando solo el canal de señalización, es decir, sin generar ningún coste para el usuario final del operador y sin conexión wifi.
La figura 2 representa un sistema en el que un terminal, por ejemplo, un microteléfono o un teléfono inteligente 10 que coopera con un elemento 11 de seguridad (una SIM, una UIC<c>, una eUICC o una iUICC, por ejemplo), se comunica con un servidor distante 12 inalámbricamente. El servidor 12 también se denomina HLR / HSS de descubrimiento, o D-HSS, en los siguientes apartados. El elemento 11 de seguridad puede integrarse en el terminal 10 o comunicarse con el terminal a través de vínculos conocidos como Bluetooth, IrDA, NFC o eGo™, por ejemplo.
El elemento 11 de seguridad es un elemento de seguridad mejorado que tiene un sistema operativo especial (SO) que se conecta al servidor 12 gracias a sus MCC/MNC (que están comprendidos en su IMSI). Los MCC/MNC de este servidor también se denominan primeros MCC/MNC (o MCC1 y MNC1). La IMSI normalizada comprende 3 dígitos para el MCC, ya sea 2 dígitos (estándar europeo) o 3 dígitos (estándar norteamericano). La longitud del MNC depende de su valor. Los dígitos restantes son el número de identificación de suscripción móvil (MSIN) en la base de clientes de la red (9 o 10 dígitos para el número MSIN).
El elemento 11 de seguridad se conecta al servidor 12 (a través del terminal 10) si el MCC1/MNC1 de la IMSI es uno de unos MCC/MNC correspondientes al nivel del servidor 12. El servidor 12 puede ser un servidor de descubrimiento (D-HSS), y el SO mejorado del elemento de seguridad es capaz de recibir y ejecutar órdenes recibidas en mensajes que tienen la longitud de los mensajes RAND y/o AUTN enviados por el servidor 12 (para redes 3G o 4G). En una red 2G, al elemento 11 de seguridad solo se le envía un mensaje RAND, y, según la invención, este mensaje RAND se ha modificado para comprender órdenes y datos.
Cuando el elemento 11 de seguridad recibe del servidor 12 los mensajes RAND y/o AUTN, responde con un campo de IMSI modificado que comprende sus MCC1/MNC1 y datos que reemplazan al MSIN estándar.
Las comunicaciones entre el elemento 11 de seguridad y el servidor 12 se sincronizan gracias a un número secuencial, que se denominará en lo sucesivo identificador de correlación (Correl-ID), para que, cuando un mensaje enviado por el servidor 12 al elemento 11 de seguridad contenga este identificador Correl-ID, el elemento 11 de seguridad responda al servidor 12 con el mismo identificador Correl-ID. En un momento dado, el identificador Correl-ID asignado por el servidor 12 debe ser diferente para todos los diálogos de comunicación activos.
Preferiblemente, el servidor cambia los Correl-ID cuando envía una nueva orden a la eUICC+ (p. ej., aumentar en 1 el último Correl-ID o enviar un Correl-ID aleatorio a la eUICC+) para evitar que la red impida la nueva incorporación. Si los MCC/MNC del elemento 11 de seguridad son diferentes de los del servidor 12, el elemento 11 de seguridad se comporta como un elemento de seguridad estándar (sin SO mejorado) y usa los algoritmos de autenticación estándar (p. ej., AKA Milenage o COMP-128) y el proceso de autenticación conocido para conectarse a la red de su MNO.
El elemento 11 de seguridad contiene un perfil predeterminado para conectarse al servidor 12. Comprende al menos una clave, denominada en lo sucesivo clave e-Ki (clave Ki efímera), y un identificador único, por ejemplo, un EID (identificador de eUICC), una clave de EID o una IMSI efímera (e-IMSI, que puede derivarse del EID). Es posible que el campo ICCID y la e-IMSI (que quiere decir envelope-IMSI) estén vacíos. El EID, o una clave que se refiera al EID (la clave de EID), se envía al servidor 12 usando la envelope-IMSI.
En la siguiente descripción, “ e” significa efímera, “t” , temporal, y “ p” , permanente. Se intercambian e-datos entre el servidor y la eUICC+ durante una fase de provisión que permite transmitir t-datos a la eUICC+, y estos t-datos se intercambian luego entre un servidor de MNO y la eUICC+ para instalar p-datos en esta eUICC+.
La figura 3 representa tres posibles formatos del campo IMSI transmitido en la señalización de autenticación.
- El formato 30 es un formato IMSI estándar. Contiene un MCC en 3 dígitos, un MNC en 2 o 3 dígitos y el MSIN del elemento de seguridad en 9 o 10 dígitos.
- Un primer formato 31 (también llamado formato 1 de envelope-IMSI) también contiene un MCC y un MNC ( MCC1 y MNC1) seguidos de un dígito dedicado (“ 0” , por ejemplo) y por una carga útil de 9 dígitos. Este primer formato 31 se usa para el primer intento de incorporación de la eUICC+ al servidor 12. Es el primer mensaje de un diálogo de comunicación entre la eUICC+ y el servidor 12. La carga útil contiene datos a comunicar al servidor, representando estos datos al menos una parte del identificador único de la eUICC+.
- La eUICC+ utiliza un segundo formato 32 (también llamado formato 2 de envelope-IMSI) para comunicar más datos (en una carga útil) al servidor 12 en intercambios que se producen después del primer intento de incorporación de la eUICC+ al servidor 12 (cuando ha recibido una respuesta desde el servidor). Contiene los mismos MCC1/MNC1 que se mencionaron anteriormente, seguidos de un identificador de correlación de 5 dígitos que empiezan por un dígito en el intervalo de 1 a 9 (el dígito dedicado mencionado anteriormente no se utiliza como primer dígito). Este identificador de correlación (que, en este ejemplo, nunca empieza por 0) es enviado por el servidor y recibido de nuevo por el servidor para permitirle saber de qué eUICC+ procede la respuesta a su(s) orden(es). Este formato 32 también contiene una carga útil que contiene más datos enviados de la eUICC+ 11 al servidor 12 y se emplea para el intercambio de mensajes posteriores entre la eUICC+ y el servidor.
La eUICC+ sólo usa mensajes en el formato 31 y el formato 32 de la figura 3 para comunicarse con el servidor. Se comunica con el servidor a través de la banda base del terminal con el que coopera.
El servidor envía a la eUICC+ mensajes especiales en vez de enviarle mensajes RAND/AUTN normalizados. Estos mensajes contienen datos y órdenes: en al menos un formato de mensaje RAND en el caso de 2G y en al menos unos formatos RAND y AUTN en el caso de redes que admitan al menos comunicaciones 3G en sus canales de señalización). En el caso de redes 5G, probablemente también se empleen mensajes de señalización que tengan la finalidad de los mensajes RAND/AUTN, y estos mensajes se usarán para enviar órdenes y datos al elemento de seguridad.
La figura 4 representa unos mensajes especiales enviados por el servidor a la eUICC+, teniendo estos mensajes la longitud de mensajes RAND y AUTN.
Estos mensajes son enviados por el servidor 12 a la eUICC+ 11 en vez de mensajes RAND/AUTN tradicionales. Tienen las mismas longitudes que los mensajes RAND y AUTN normalizados.
En redes 3G, redes 4G y, probablemente, redes futuras (como 5G, por ejemplo), se envían a la eUICC+ unos mensajes de señalización RAND y AUTN (u otros), tal y como se explicó anteriormente con respecto a la figura 1. Tienen (actualmente) una longitud de 16 bytes: la cantidad total de datos que se pueden llevar del servidor 12 a la eUICC+ es, por lo tanto, 32 bytes.
Dentro del alcance de la invención, el SO de la eUICC+ que está comprendida en al menos un microprocesador es capaz de detectar estos mensajes especiales (fig. 4) enviados por el servidor 12. El servidor 12 utiliza, por ejemplo, la estructura de la figura 4 para los mensajes RAND y AUTN, en vez de enviar unos mensajes RAND y AUTN estándar al elemento 11 de seguridad.
Aquí, un mensaje 40 de señalización comprende:
- Al menos una orden (CMD) de un byte: en este campo o en otros campos del mensaje que tiene el formato RAND pueden almacenarse múltiples órdenes.
- Un ID (identificador) de correlación de cuatro bytes, que se utilizará en la respuesta enviada de la eUICC+ al servidor 12 (formato 32 de la fig. 3). Un ID de correlación sirve para correlacionar las solicitudes y respuestas intercambiadas entre la eUICC+ y el servidor. Por supuesto, si la eUICC+ no necesita dar una respuesta, no es necesario enviar un ID de correlación.
- Una carga útil de 27 bytes (10 en el RAND y 17 en el AUTN [si la red no es 2G]), cuya estructura depende del campo orden. El mensaje AUTN que contiene esta carga útil se ha indicado mediante 41. Esta carga útil se utiliza para enviar datos del servidor a la eUICC+
Por supuesto, la orden y el Correl-ID pueden estar comprendidos en los campos del formato AUTN estándar en vez de estar comprendidos en los campos RAND (son intercambiables). El SO de eUICC+ instalado en un microprocesador tiene instrucciones que son capaces de detectar estos formatos especializados.
Naturalmente, si se utiliza una red 2G para la transmisión de mensajes entre el elemento 11 de seguridad y el servidor 12, solo se enviarán mensajes RAND del servidor al elemento 11 de seguridad (en las redes 2G no existen mensajes AUTN), y la cantidad de mensajes intercambiados será más importante, ya que no se encuentra disponible la carga útil del mensaje AUTN.
En este caso 2G, todas las órdenes, Correl-ID (en caso necesario) y datos (carga útil) están comprendidos en este formato RAND, y la eUICC+ que trabaja en una red 2G podrá ocuparse únicamente de esos mensajes RAND especiales.
Los valores de orden enviados del servidor a la eUICC son, por ejemplo, los representados en la figura 5.
Por ejemplo, una orden 0x02 de un byte es una solicitud enviada del servidor a la eUICC+ para conmutar su IMSI de una envelope-IMSI (e-IMSI) a una IMSI temporal (t-IMSI). La t-IMSI se proporciona normalmente en el HSS de un MNO con la clave e-Ki. Tal y como se verá más adelante, se pueden imaginar muchas otras órdenes.
Por ejemplo, en una orden reservada (la 0x05, por ejemplo), se le puede pedir a la eUICC+ actualizar el perfil SIM predeterminado en la eUICC+. Por lo tanto, se puede realizar una descarga de un (pequeño) subprograma en la eUICC+ utilizando únicamente mensajes de señalización. Esto puede hacerse mediante varios intercambios entre el servidor 12 y la eUICC+ (a través de los mensajes RAND y/o AUTN especiales de la fig. 4). Todos estos mensajes son mensajes de señalización y no tienen ningún impacto en la cuenta del usuario o en la del MNO (y no se necesita conexión wifi alguna).
Gracias al método propuesto por la presente invención, se establece un canal de comunicación bidireccional y seguro entre un servidor y un elemento de seguridad que coopera con un terminal en una red de telecomunicación celular utilizando únicamente mensajes de señalización.
En primer lugar, el elemento 11 de seguridad envía un primer mensaje de señalización de solicitud de incorporación al servidor 12, comprendiendo el primer mensaje los MCC1/MNC1 del servidor y al menos una primera parte de un identificador único de la eUICC+. Este identificador único puede ser, por ejemplo, su EID. Esta parte del identificador único está contenida en la carga útil del mensaje de formato 31. El servidor recibe esta primera solicitud de incorporación e identifica el campo carga útil. Luego asocia a este primer mensaje un identificador de correlación para seguir el diálogo. El servidor envía entonces al elemento de seguridad, en al menos un primer mensaje de señalización (que tiene aquí la longitud de un mensaje RAND y en vez de un mensaje RAND estándar):
- Al menos una orden (CMD);
- un identificador de correlación (Correl-ID), si hay que enviar más mensajes del elemento de seguridad al servidor;
- una primera carga útil, que comprende datos (véase el formato del mensaje RAND 40 de la fig. 4). Los bytes 0-10 de carga útil se utilizan cuando solo puede enviarse un mensaje RAND a la eUICC+ (2G), y, en caso de que haya disponibles redes 3G o 4G, puede usarse una carga útil 11-26 adicional (datos comprendidos en la carga útil del mensaje 41 de señalización).
Después de esto, la eUICC+ ejecuta la(s) orden(es) recibidas por el servidor.
En caso necesario, el elemento de seguridad envía al servidor, en al menos un segundo mensaje de señalización de solicitud de incorporación, los mismos MCC1/MNC1 y, en un campo MSIN actualizado, el identificador de correlación recibido y una segunda carga útil que contiene datos. Estos intercambios de datos/órdenes tienen lugar hasta que las dos entidades (la eUICC+ y el servidor) han terminado su diálogo.
La invención puede tener lugar en distintos casos de uso.
A continuación se describirán dos casos de uso diferentes.
En el primer caso de uso representado en la figura 6, un usuario final compra en un Point of Sales (Punto de venta -POS) (etapa 1) de un MNO un terminal nuevo (p. ej. un microteléfono), que coopera con una eUICC (embebida o no), y elige una suscripción con este MNO. El dependiente (etapa 2) escanea el EID (el ID de la eUICC) que está impresa en la caja del microteléfono, y un SM-DP+ (gestor de abonados - preparación de datos) crea una suscripción. Después de estas etapas, el cliente puede encender su microteléfono (etapa 3), y el MNO descarga la suscripción en la eUICC (etapa 4).
Sin embargo, según la especificación de arquitectura RSP SGP.21 de la GSMA (v. 2.0, con fecha de 23 de agosto de 2016), es obligatorio tener acceso wifi para realizar la descarga de la suscripción. Este acceso puede ser un incordio para los abonados. En algunas regiones, el wifi no tiene una gran tasa de penetración en los hogares. Incluso en los EE. UU., el porcentaje solo llega a un 58 %. En otros continentes, como África, la tasa de penetración de wifi es extremadamente baja. Además, un gran porcentaje de la población tiene problemas para configurar la wifi en sus dispositivos, lo que da lugar a problemas básicos a la hora de descargar un perfil de suscripción de un MNO. Dentro del alcance de la invención, no solo se propone una descarga de un perfil de suscripción que comprende todos los programas, archivos, claves, estructura de archivos, etc. que permiten que un abonado establezca una comunicación con la red de un MNO, sino también una comunicación mutua entre un elemento de seguridad y un servidor utilizando únicamente canales de transmisión por los que no cobra ningún MNO, es decir, mediante el uso de canales de señalización.
Sin acceso wifi, la suscripción no puede descargarse en la eUICC, lo que puede dar lugar a un fracaso en la adopción de las eUICC en parte del mundo.
Una solución sería proponer una incorporación inicial basada en un perfil de arranque que permita incorporar el dispositivo a una red y realizar la descarga del perfil de abonado a través de un acuerdo de itinerancia. Sin embargo, la descarga del perfil daría lugar a un coste de itinerancia, ya que las eUICC se fabrican sin saber en qué países se venderán/usarán. Por lo tanto, no es posible seleccionar el MNO o MVNO buscado.
La presente invención propone una solución a este problema, mientras se sigue cumpliendo con las normas GSMA y 3GPP.
En el primer caso de uso, la invención propone simplificar la experiencia de usuario cuando un usuario final haya comprado un teléfono inteligente o cualquier terminal de telecomunicación y desee descargar de un MNO (operador de red móvil) una suscripción en el elemento de seguridad que coopera con su terminal. El elemento de seguridad puede ser una UICC, una eUICC (UICC embebida, donde UICc significa tarjeta de circuito integrado universal) o una iUICC (tarjeta UICC integrada, que es un elemento de seguridad integrado en un procesador del terminal) sin acceso wifi para descargar su suscripción reservada a través de la red del MNO. La invención se aplica a redes 2G (GSM), 3G (UMTS), 4G (LTE) y 5G (IoT) y es conforme a las normas GSMA y 3GPP.
La especificación de arquitectura RSP SGP.21 de la de GSMA (v. 2.0, con fecha de 23 de agosto de 2016) proporciona un mecanismo estándar para la provisión y la gestión remotas de dispositivos empresariales de consumo, lo que permite la provisión por wifi de una suscripción de operador inicial y el posterior cambio de suscripción de un operador a otro.
En la figura 7 se explica el primer caso de uso.
En esta figura 7, un SM-DS 400 mejorado (gestor de abonados - servidor de descubrimiento) se denomina aquí SM-DS+ (o primer servidor). Por ejemplo, en la especificación de arquitectura RSP SGP.21, v. 2.0, de 23 de agosto de 2016, se describe un Sm-DS. El SM-DS+ 400 es compatible con los estándares GSMA de fase 2 SGP-11 “ RSP Architecture - Version 2.0” y SGP 22 “ RSP Technical Specification - Version 2.0 - Clean Version - 19 August 2016” .
El servidor SM-DS+ 400 comprende un servidor 401, llamado D-HSS (servidor de abonados locales de descubrimiento o registro de localización de abonados), o segundo servidor, y un SM-DS 402 (tercer servidor). El D-HSS 401 controla la primera incorporación del microteléfono 10 durante su primer encendido gracias a los MCC/MNC de la IMSI. El SM-DS+ 400 está vinculado a un servidor SM-DP+ 403 (gestor de abonados - preparación de datos). El SM-DS+ 400 y el SM-DP+ 403 son servidores que pertenecen a una primera entidad, por ejemplo, a un fabricante de eUICC (eUM).
El servidor SM-DP+ 403 tiene la función de gestionar paquetes de perfil, proteger cada uno con una clave de protección de perfil, almacenar las claves de protección de perfil, así como los paquetes de perfil protegidos, de manera segura en un repositorio de paquetes de perfil, y vincular los paquetes de perfil protegidos a las ElD especificadas. El servidor SM-DP+ 403 vincula los paquetes de perfil protegidos a la respectiva EID y descarga de manera segura estos paquetes de perfil vinculados en el Local Profile Assistant (Asistente de perfil local - LPA) de la respectiva eUICC. En la especificación de arquitectura RSP SGP.21, v. 2.0, de 23 de agosto de 2016, también se especifica un SM-DP+.
La figura 7 también representa un HSS 404 y unos BSS/OSS 405 (sistema de apoyo empresarial/sistema de apoyo de operaciones). El hSs 404 y los BSS/OSS 405 pertenecen por lo general a una segunda entidad, normalmente un operador (MNO).
El SM-DS+ 400 contiene un servidor de SM-DS 402 alternativo que está conectado al servidor SM-DP+ 403 utilizado por el MNO. En el caso de una eUICC normal, solo se comporta de manera estándar. En el caso de una eUICC mejorada (que se denominará en lo sucesivo eUICC+), que tiene un perfil predeterminado, mejora y simplifica la experiencia de usuario final.
El perfil predeterminado de eUICC+ (indicado como eSIM en la fig. 7) debe contener o haber generado una Ki efímera (e-Ki) para poder comunicarse con el servidor HSS 404 de MNO y contiene una aplicación de arranque. El mensaje de autenticación inicial enviado de la eUICC+ al D-HSS 401 (gracias a sus MCC/MNC) se encamina al D-HSS que está conectado a la red de señalización a través de una red visitada a la que el terminal / la eUICC+ se conecta la primera vez (la BTS del MNO que tiene la señal más intensa).
El servidor D-HSS 401 utiliza el canal de señalización de 2G/3G/4G (MAP en el caso de 2G y 3G y diámetro en el de 4G/LTE, y también diámetro u otro canal de señalización en el caso de la 5G futura) para enviar órdenes al microteléfono y su eUICC+. Comprende al menos un microprocesador estudiado para ejecutar estas tareas. El D-HSS 401 puede enviar distintas órdenes al microteléfono 10, ya sea para visualizar un menú en el microteléfono 10 o para cambiar la IMSI de perfil predeterminado de eUICC+ y redirigir la incorporación de microteléfono al MNO seleccionado por el usuario.
En términos generales, el sistema funciona de la siguiente manera:
La eUICC+ comprende una aplicación de arranque, un identificador único como un EID, unos primeros MCC/MNC (para comunicarse con el D-HSS) y una e-Ki que puede obtenerse del EID. Una vez fabricada una eUICC+, su centro de personalización introduce el EID de la eUICC+ (escanea, por ejemplo, el EID en forma de código de barras o de código QR impreso en la caja que contiene el microteléfono) en los BSS/OSS del correspondiente MNO. Esto corresponde a la etapa 1 de la figura 7. El SM-DP+ prepara una suscripción que incluye una IMSI permanente (p-IMSI) y una Ki permanente (p-Ki) (definitivas) (entre otros archivos, aplicaciones, sistema de archivos...) e informa al SM-DS+. El SM-DS+ informa al D-HSS de que hay una descarga pendiente para este EID con una t-IMSI (etapa 2), y el D-HSS 401 obtiene del EID una Ki efímera (e-Ki) que se transmite al SM-DS 402. En una etapa 3, el MS-DS+ proporciona al HSS del MNO 404 una IMSI temporal (t-IMSI) y la Ki efímera (e-Ki).
En SM-DS+ se proporciona un grupo de t-IMSI proporcionadas por el MNO que se ha abonado al servicio. Más tarde, cuando el perfil de suscripción final (con la p-IMSI y la p-Ki) se descarga en una e-UICC, esta t-IMSI puede ser reutilizada por el MNO para otra e-UICC. A continuación (etapa 4), cuando un cliente ha comprado un microteléfono o terminal 10 que contiene esta eUICC+ que contiene el EID, el microteléfono 10 primero se enciende e intenta autenticarse a la red que mejor se recibe con uno de sus identificadores únicos (que puede ser, por ejemplo, una e-IMSI, su EID o una clave de EID) enviando un mensaje de señalización (mensaje de solicitud de autenticación). Esta red retransmite la solicitud de autenticación al D-HSS, que reconoce el identificador único recibido como siendo de una eUICC+ con una suscripción pendiente, y envía a la eUICC+, tal y como se describe en la figura 8, la t-IMSI provista emparejada a este identificador único.
El D-HSS envía entonces a la eUICC+ (etapa 5) una orden en un mensaje de señalización especial que tiene la longitud de los mensajes de señalización AUTn y RAND conocidos (para redes 3G y 4G) para pedirle que reemplace su e-IMSI por la t-IMSI asociada. La eUICC+ procede entonces a cambiar de IMSI (de la e-IMSI a la t-IMSI). En la siguiente solicitud de autenticación (etapa 6), la eUICC+ utilizará la t-IMSI, y será encaminada al HSS del MNO elegido (puesto que ya ha sido provisto de una t-IMSI que tiene los códigos MCC/MNC del operador del HSS 404). La clave e-Ki provista en la eUICC+ y en el HSS se utilizará a efectos de autenticación y para descargar el perfil de suscripción. El MNO puede informar al SM-DP+ de que puede descargar (etapa 7) la suscripción final en la eUICC+, con la p-Ki y la p-IMSI (p significa permanente, tal y como ya se ha mencionado), creándose este perfil de suscripción final en este instante o reservándose de antemano en el SM-DP+.
En suma, en el diálogo entre el SM-DS+ y la eUICC+ se emplean los 2 primeros mensajes intercambiados durante la incorporación de dispositivo. En el mensaje Send Authentication Info (Enviar info. de autenticación) se envía una IMSI dinámica (cambiante) que incluye el identificador único (p. ej., el EID). La respuesta Send Authentication Info (Enviar info. de autenticación) incluye (en vez de parámetros RAND y AUTN) datos y órdenes que hay que transmitir a la eUICC+. Estos 3 parámetros se utilizan para intercambiar órdenes y datos entre la eUICC+ y el D-HSS y ejecutar dichas órdenes.
Este diálogo entre la eUICC+ y el D-HSS permite identificar automáticamente el dispositivo a través de su EID basándose, por ejemplo, en el estándar 3GPP mediante el uso de mensajes de autenticación mejorados que incluyen órdenes/datos.
Esta fase de incorporación mejorada utiliza un HLR/HSS de descubrimiento (D-HSS) mundial conectado al SM-DS+ de MNO para configurar la eUICC+ para incorporarla a la red de operador buscado. Esta fase de autenticación mejorada no incorpora el dispositivo a la redHLR/HSS de descubrimiento mundial. A través del D-HSS solo se intercambia el primer par de mensajes de enviar info. de autenticación. Este mecanismo no se cobra sobre las redes de operador y no se intercambian datos cobrables. Durante el diálogo de autenticación mejorado entre la eUICC+ y el D-HSS, el D-HSS configura remotamente la eUICC+ a través de una orden en los parámetros RAND y/o AUTN para cambiar la e-IMSI de eUICC+ al HLR/HSS de operador buscado o pendiente mediante el envío a esta e-UICC+ de la t-IMSI conocida por el MNO.
En la fase de incorporación mejorada de la invención se emplea una eUlCC mejorada (eUICC+) que comprende un sistema operativo modificado cuando sus MCC/MNC (primeros MCC/MNC) están relacionados con un operador que maneja el D-HSS. Este SO modificado comprende instrucciones que posibilitan los intercambios iniciales con el servidor 12. Gracias a este SO modificado, los mensajes RAND y AUTN, que se describirán más adelante, son decodificados por la eUICC+, y el campo e-MSIN se recodifica con una respuesta a estos mensajes. Si la eUICC es una eUICC estándar, el procedimiento de autenticación es estándar (se emplea el AKA/Milenage, o el COMP 128). Dicho de otra manera, la eUICC+ realiza este análisis de fase de autenticación mejorada si la IMSI actual se basa en los MCC/MNC de HLR/HSS de descubrimiento; de lo contrario, la eUICC realiza la fase de autenticación estándar (p. ej., el algoritmo de AKA/Milenage).
Gracias a este mecanismo, es posible descargar el perfil de suscripción de eUICC+ a través del operador buscado (con unos segundos MCC/MNC) sin tener acceso wifi.
A continuación se describe un ejemplo de flujo de señalización con respecto a la figura 8, que muestra, con más detalle, un ejemplo de intercambios entre las distintas entidades de la figura 7. Este ejemplo se basa en transmisiones en una red 4G.
En una etapa 50, un cliente compra un terminal en la tienda de un operador MNO, por ejemplo, un microteléfono, una PDA o un teléfono inteligente, que comprende un elemento de seguridad, por ejemplo, una UICC+ extraíble o una UICC+ embebida (eUICC+). En una etapa 51, la dependiente escanea el EID que aparece impreso, por ejemplo, en la caja del microteléfono.
El cliente también puede haber pedido su terminal por internet y le pide al representante del MNO que le cree una suscripción.
En una etapa 52, el EID, el ICCID y tipo de perfil se envían al SM-DP+ en un pedido de descarga. El tipo de perfil depende de la suscripción elegida por el cliente (prepago, pospago, internacional...). En una etapa 53, este pedido se confirma con una dirección de SM-DS alternativa (la dirección de SM-DS alternativa es la dirección del SM-DS+).
El SM-DP+ crea o reserva entonces un perfil de suscripción para este EID.
En una etapa 54, el SM-DP+ envía un mensaje Register event (Registrar evento) al SM-DS+ alt. (alt. corresponde a alternativo; también se puede utilizar un SM-DS raíz) que contiene el EID, la dirección de servidor de RSP (perfil SIM remoto) (la dirección del SM-DP+) y un ID de evento. Las etapas 50 a 54 son etapas estándar definidas por la GSMA.
El SM-DS+ asigna entonces, en una etapa 55, una IMSI temporal llamada t-IMSI a esta eUICC+, y en una etapa 56, solicita al D-HSS que proporcione una pareja EID / t-IMSI para esta eUICC+. El D-HSS tiene los primeros códigos MCC/MNC (MCC1 y MNC1). La t-IMSI tiene unos segundos códigos de MCC/MNC (MCC2 y MNC2). El SM-DS+ también envía, en un etapa 57, al HSS del MNO buscado una solicitud para la provisión de la t-IMSI con su Ki efímera (e-Ki).
Las etapas 50 a 56 también pueden tener lugar antes de venderse el microteléfono al cliente. Por lo tanto, las suscripciones ya están disponibles a nivel del MNO y están listas para descargarse en la eUICC+ cuando el usuario encienda su terminal.
Más tarde, en una etapa 58, el cliente enciende su terminal. En una etapa 59, la banda base del terminal envía a la MME una solicitud de Incorporación de gestión EMM donde su identificador único es una e-IMSI. La e-IMSI (mensaje de formato 31) básicamente contiene los primeros códigos MCC1/MNC1 y una carga útil que contiene un identificador completo de 9 dígitos de la eUICC+ (normalmente, una clave de EID codificada con 9 dígitos). La MME envía, en una etapa 60, la e-IMSI al D-HSS (gracias al código MCC1/MNC1 reconocido) a través de la red de un MNO que tiene la señal más intensa recibida por el terminal.
En una etapa 61, el D-HSS busca la carga útil recibida (clave de identidad EID de 9 dígitos) y asocia esta e-IMSI a la t-IMSI provista en la etapa 56. El D-HSS también envía a la eUICC+, a través de la MME, una orden de cambio de IMSI en los campos RANd y/o AUTN, tal y como se explicará más adelante.
En una etapa 62, se envía un vector que contiene esta orden a la MME, y en una etapa 63, la MME envía los RAND y AUTN a la eUICC+ en un mensaje Authentication request (Solicitud de autenticación) para iniciar una comunicación de altos y respuestas. Los mensajes RAND/AUTN contienen una t-IMSI.
En una etapa 64, la eUICC+ comprueba si el los MCC y MNC actuales (MCC1 y MNC1) corresponden a los de su servidor de descubrimiento y, en caso afirmativo, ejecuta la orden de cambio de su e-IMSI a la t-IMSI comprendida en los mensajes RAND y AUtN.
En este ejemplo, se necesita un único intercambio de mensajes entre la eUlCC y el D-HSS, ya que el D-HSS es capaz de reconocer la eUICC gracias a un único mensaje (etapas 59-61) que contiene toda la clave de EID.
En una etapa 65, la eUICC+ responde a la MME que la autenticación ha fallado con el fin de no ser conectada al D-HSS. Puede enviar un RES incorrecto (un valor nulo, por ejemplo) o enviar al terminal un código para que el terminal no responda.
En una etapa 66, la MME confirma a la eUICC+ que la autenticación ha fallado.
En una etapa 67, gracias a una orden de actualización o después de un cierto lapso de tiempo (p. ej., 10 s), la eUICC+ intenta incorporarse a la red del MNO con los segundos códigos MCC/MNC recibidos en los mensajes RAND y AUTN. Aquí envía, en una etapa 68, su t-IMSI a la MME en un mensaje EMM Attach Request (t-IMSI) (Solicitud de incorporación de EMM [t-IMSI]). La t-IMSI comprende un segundo MCC (MCC2), un segundo MNC (MNc2) y un MSIN temporal.
En una etapa 69, la MME envía esta t-IMSI al HSS del MNO(identificado por los segundos MCC/MNC), y en una etapa 70, el HSS responde con un vector Acuse de recibo de info. de autenticación.
En una etapa 71, la MME envía una solicitud de autenticación y cifrado que contiene RAND y AUTN, y en una etapa 72, la eUICC+ responde con un RES. En una etapa 73, la autenticación ha tenido éxito y la MME informa a eUICC+. Entonces se puede enviar un mensaje de solicitud de ubicación de actualización al HSS del MNO(etapa 74), que acusa recibo con un mensaje Location Update Ack (Acuse de recibo de actualización de ubicación) (etapa 75).
Finalmente, en una etapa 76, la MME puede conectarse a un Access Point Name (Nombre de punto de acceso - APN) con una pasarela de servicio y una pasarela de red PDN. El terminal puede conectarse entonces al MNO por internet, y el MNO podrá descargar una suscripción en la eUICC+.
La figura 9 representa el flujo de señales intercambiadas entre las distintas entidades una vez que se ha requerido la suscripción para una cierta eUICC+ en un POS y se han ejecutado las etapas de la figura 8. Este mecanismo es compatible con la especificación técnica RSP SGP.22 de la GSMA.
En una etapa 80, el usuario enciende su microteléfono y el asistente LPA se conecta al SM-DS raíz mediante un mensaje InitiateAuthentication (Iniciar autenticación) (eUICC+Challenge, eUICC+info1, dirección de SM-DS) (etapa 81). El SM-DS+ responde con un mensaje OK (etapa 82).
En una etapa 83, el microteléfono envía al SM-DS+ un mensaje AuthenticateClient (Autenticar cliente) (eUICC+Signed1, eUICC+Signature1, CERT.EUICC+.ECDSA, CERT.EUM.ECDSA) a efectos de autenticación. CERT.EUICC+.ECDSA es el certificado de la eUICC+ para su clave ECDSA (algoritmo de firma digital por cifrado con curvas elípticas) pública, y CERT.EUM.ECDSA es el certificado del EUM para su clave ECDSA pública. El SM-DS+ responde con un mensaje OK (etapa 84) que contiene la dirección del SM-DP+.
En una etapa 85, el asistente LPA recupera la dirección de SM-DP+ del evento de SM-DS consultado, y en una etapa 86, envía un mensaje InitiateAuthentication (eUICC+Challenge, eUICC+info1, SM-DP Address) (Iniciar autenticación [eUICC+Challenge, eUICC+info1, dirección de SM-DP]) al SM-DP+. El SM-DP+ responde con un mensaje OK (etapa 87). En una etapa 88, la eUICC+ envía un mensaje AuthenticateClient(eUICC+Signed1, eUICC+Signature1, CERT.EUICC+.ECDSA, CERT.EUM.ECDSA) (Autenticar cliente [eUICC+Signed1, EUICC+Signature1, CERT.EUICC+.ECDSA, CERT.EUM.ECDSA]) (el mismo mensaje que en la etapa 83) al SM-DP+. El SM-DP+ responde con un mensaje OK (etapa 89).
En una etapa 90, la eUICC+ solicita al SM-DP+ la suscripción con un mensaje GetBoundProfilePackage(transactionlD) (Obtener paquete de perfil vinculado [ID de transacción]) . El SM-DS+ envía a la UICC, en una etapa 91, el paquete solicitado. Este paquete comprende el perfil de suscripción y una IMSI permanente (final) y una Ki permanente (p-IMSI/P-Ki).
En una etapa 92, el usuario hace clic en un botón de asistente LPA para activar el nuevo perfil y forzar la reincorporación futura con el nuevo perfil y la identidad p-IMSI.
En una etapa 93, la eUICC+ solicita a la MME una incorporación utilizando una t-IMSI. La MME envía entonces una información de autenticación, que comprende la t-IMSI, al HSS del MNO. El HSS responde a la MME, en una etapa 95, enviando un Acuse de recibo de información de autenticación (vector[Ki]).
En una etapa 96, la MME envía un mensaje EMM Authentication and Ciphering Request (Solicitud de cifrado y autenticación de EMM), que contiene unos rAnD y AUTN, a la eUICC+. La eUICC+ responde con un RES (etapa 97) y la incorporación de la eUICC+ al EMM se acepta en una etapa 98.
Finalmente, la MME envía, en una etapa 99, una solicitud de actualización de ubicación al servidor HSS, que responde con un acuse de recibo en una etapa 100.
Las etapas 80 a 100 son etapas estándar normalizadas por la GSMA (véase SGP.22, v. 2.0, del 14 de octubre de 2016, apdo. 6.5.2.6 y Anexo I). La figura 9 muestra por tanto el flujo inalámbrico a través del LPA.
La invención descrita en el apartado anterior requiere que la eUICC+ y el D-HSS sean capaces de usar la señalización de autenticación para intercambiar datos durante el intento de incorporación inicial. Los mensajes de gestión de movilidad se especifican en la especificación técnica TS 24.008 “ Mobile radio interface Layer 3; Core network protocols; Stage 3 for 3G” del 3GPP y en la especificación técnica TS 24.301 “ Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3 for 4G/LTE” del 3GPP.
La figura 10 representa una solución en la que eUICC+ codifica los dígitos disponibles del formato 31 con una clave de EID.
- La eUICC+ envía datos dentro del MSIN (mientras mantiene los MCC1/MNC1 inalterados).
- El D-HSS puede responder enviando órdenes y parámetros codificados dentro de los campos RAND/AUTN. El esquema de codificación de e-IMSI es, por ejemplo, el siguiente:
La eUICC+ se construye con un perfil predeterminado. El perfil predeterminado contiene unos MCC1 y MNC1 que son encaminables al D-HSS. Luego, el valor de MSIN de e-IMSI (MSIN) se cambia de una transacción de autenticación a la otra. La eUICC+ emplea dos formatos de e-IMSI:
- Una e-IMSI única asignada por el fabricante eUM. Este es el “ formato 31” de la figura 3.
- Una e-IMSI modificada que lleva una carga: es el “ formato 32” de la figura 3.
El MSIN de e-IMSI inicial puede ser mapeado al/del EID de eUICC+ por el eUM que ha emitido la eUICC+ y conserva el mapeo en una base de datos. Hay 9 miles de millones de valores de e-IMSI que están correlacionados con los EID de eUM. Hay un billón de valores de EID para el eUM:e-IMSI.
Cuando el D-HSS se comunica con el microteléfono/la eUICC+, codifica los mensajes RAND y AUTN que se transmiten tradicionalmente en las redes móviles.
La figura 4 representa un ejemplo de una codificación RAND y AUTN.
Las longitudes RAND y AUTN son de 16 bytes: la cantidad total de datos que se pueden transportar del D-HSS a la eUICC+ es, por lo tanto, 32 bytes (para redes 3G, 4G y 5G).
La eUICC+ utiliza, por ejemplo, la siguiente estructura para RAND y AUN:
Una orden de un byte.
- Un ID (identificador) de correlación de cuatro bytes, que se usa en el siguiente mensaje enviado de la eUICC+ al D-HSS (formato 32). Un ID de correlación sirve para correlacionar las solicitudes y las respuestas.
- Una carga útil de 27 bytes (10 en el RAND y 17 en el AUTN), cuya estructura depende del campo orden. Los valores de orden son, por ejemplo, los representados en la figura 5.
Por ejemplo, una orden 0x02 de un byte es una solicitud enviada del D-HSS a la eUICC+ para cambiar su IMSI de una e-IMSI a una t-IMSI . Se pueden imaginar muchos otras órdenes.
La figura 11 representa un ejemplo de una codificación de EID.
Tal y como se muestra, el EID contiene, por ejemplo, 32 dígitos numéricos. Los EID se definen en la especificación técnica “ Remote Provisioning Architecture for Embedded UICC” , v. 3.1, 27 de mayo de 2016, de la GSMA. Para identificar una eUICC+ emitida por un eUM, el D-HSS solo necesita conocer los dígitos 18-29 (número de identificación individual de EID) que realmente identifican a la eUICC+ individual. La eUICC+ preferiblemente nunca comunica directamente esos dígitos, sino una clave de 14 dígitos que el D-HSS puede utilizar para recuperar la tabla de registros de eUICC+ de eUM. Esta clave se denomina clave de EID y está asociada a un EID. La clave de EID se genera a partir del EID que hay en la eUICC+. Al mismo tiempo, al D-HSS se le proporciona el EID, y calcula una correspondiente clave de EID. Las IMSI efímeras no son lo suficientemente largas como para ocuparse de miles de millones de tarjetas eUICC+ y es por ello que las e-IMSI están asociadas a claves de EID. A nivel de D-HHS, una tabla asocia cada clave de EID a cada EID.
El EID o la clave de EID está compuesto por tanto por el número de identificación individual de EID.
Desde la eUICC+ se puede enviar el EID o la clave de EID (o al menos una parte de él o ella si el D-HSS no necesita conocer todos los dígitos de este dato), pero es preferible, por motivos de seguridad, enviar una clave de EID en vez de un EID por canales de señalización.
Volviendo a la figura 10, la eUICC+ utiliza dos transacciones de autenticación fallida:
1. En la primera transacción, la eUICC+ proporciona la e-IMSI que contiene los dígitos [0-9] del EID o de la clave de EID. El D-HSS proporciona un ID de correlación y solicita los dígitos de EID o de clave de EID posteriores con una orden 0x01.
2. En la segunda transacción, la eUICC+ proporciona el ID de correlación recibido y los dígitos [10-13] del EID o de la clave de EID. El D-HSS consulta su base de datos para encontrar una entrada provista por el SM-DS+ para la suscripción de usuario final de esta eUICC+. El D-HSS asigna una IMSI temporal y fuerza un cambio de la e-IMSI a esta t-IMSI.
En la figura 10, las claves de EID se envían de la eUICC+ al D-HSS, pero estas claves podrían reemplazarse por el EID real (número de identificación individual de EID).
Más precisamente, en una etapa 110, en un primer intento de conexión de la eUICC+ a la red, la eUICC+ establece el valor de e-IMSI para que contenga los dígitos 0 a 8 de la clave de EID. Cuando el terminal envía, en una etapa 111, una unidad APDU de registro de lectura a la eUICC+, ésta responde con 8 bytes que contienen los primeros 9 dígitos de la clave (etapa 112). En una etapa 113, el terminal se conecta a la red que tiene la señal más intensa y envía a la MME un mensaje de solicitud de incorporación que contiene estos dígitos (etapa 114). En la etapa 114, se utiliza el formato 31 de la figura 3. En una etapa 115, estos dígitos se transmiten al D-HS<s>.
En una etapa 116, el D-HSS envía una orden 0x01, tal y como se representa en la figura 9 (envíame los 3 dígitos restantes), junto con un ID de correlación. Esta orden se transmite a la eUICC+ a través de la MME y el terminal (etapas 117 y 118). En una etapa 119, la eUICC+ cambia el valor de e-IMSI para que contenga el identificador Correl-ID recibido y los dígitos 27-31 de EID y envía una orden Refresh (Actualización) al terminal (etapa 120). Después de un segundo registro de lectura (etapa 121), la eUICC+ envía en su campo e-IMSI el ID de correlación recibido y los bytes 9-13 de clave de EID (etapa 122).
En una etapa 123, se utiliza el formato 32 de la figura 3, y los últimos bytes de la clave se transmiten al D-HSS (etapa 124). El D-HSS puede asociar entonces la clave recibida a la t-IMSI de la eUICC+.
Entonces, el D-HSS envía (etapa 125) una orden 0x02 a la eUICC+ para cambiar su e-IMSI a la t-IMSI transmitida junto con otro ID de correlación. Esta orden se transmite a la eUICC+ (etapas 126 y 127), que cambia su e-IMSI a su t-IMSI. Cuando la eUICC+ reciba esta orden, cambiará el valor de e-IMSI de su perfil predeterminado al valor de t-IMSI especificado en los 15 primeros bytes de la carga útil RAND+AUTN.
Luego enviará una orden proactiva de REFRESH (ACTUALIZACIÓN) para forzar al microteléfono a reincorporarse con el nuevo valor de t-IMSI (etapa 128). Gracias a este valor de t-IMSI, la eUICC+ será capaz de conectarse a la red del operador (el proceso continúa con una etapa 129, que corresponde a la etapa 64 de la figura 8).
La etapa 129 muestra que los intercambios pueden continuar de esta manera entre laeUICC+ y el D-HSS con fines adicionales.
Cabe señalar que, si la clave de EID no tiene más de 9 dígitos de largo, solo es necesario un intercambio de mensajes entre la eUICC+ y el D-HSS. En este caso, la etapa 125 viene inmediatamente después de la etapa 115 (el D-HSS ha identificado la eUICC+ y puede enviarle la identidad t-IMSI. Este también ocurre si se utiliza una clave de EID corta o si la e-IMSI de la tarjeta UICC+ no supera la longitud de 9 dígitos. En estos casos, la eUICC+ solo envía un mensaje de formato 31. No se utilizan el(los) mensaje(s) de formato 32. Entonces no es necesario enviar mensajes de identificador Correl-ID a la eUICC+.
Ahora se describirá un ejemplo preciso.
Una eUICC+ está provista de:
o EID: 12346578901234567890123456789012 (32 dígitos)
o Clave de EID: 1000000000212 (14 dígitos)
y esta eUICC+ tiene un perfil predeterminado, que comprende:
o e-IMSI: 208511234567890 (15 dígitos), donde MCC = 208 (Francia), MNC = 51 (RED) y MSIN = 1234567890. Esta e-IMSI es opcional si el EID o la clave de EID se transmiten al D-HSS.
o e-Ki: AE1F5E55BC4254D4EE451112E4AA15E7 (para comunicarse con el MNO). Si, en un primer caso, la eUICC+ envía la e-IMSI al D-HSS, la solicitud de incorporación será SAI(208511234567890) y, de vuelta, obtendrá el formato 0x02 de mensaje RAND y la t-IMSI . La eUICC+ reemplazará entonces la e-IMSI por la t-IMSI.
Si, en un segundo caso, la clave de EID se envía de la eUICC+ al D-HSS, la e-IMSI se calcula y escribe en la eUICC+: 208510100000000.
El primer mensaje de incorporación será SAI(208510100000000). De vuelta, la eUICC+ recibirá en el mensaje de formato RAND una orden 0x01 y un ID 1234 de correlación.
Después del cálculo, en el campo del MSIN, será reemplazado por 208511123400212 con 1123400212 estando en el campo del MSIN.
Y el segundo mensaje de incorporación será SAI(208511123400212).
A cambio, la eUICC+ recibirá en el mensaje RAND el formato de 0x02 y la t-IMSI y reemplazará la e-IMSI por la t-IMSI.
Por supuesto, si los mensajes RAND y AUTN pueden enviarse a la eUICC+, el número de intercambios de mensajes de señalización será menor.
Con respecto a los protocolos, entre la eUICC+ y el terminal se intercambian APDU, entre el terminal y la MME, EMM de gestión de movilidad, y entre la MME y el D-HSS, el diámetro o la MAP.
La orden Refresh (Actualización) es un aspecto sensible del concepto Discovery Service Plus (SM-DS+): Se necesita una orden que la eUICC+ pueda usar una o varias veces para desencadenar un procedimiento de incorporación/autenticación. Para proporcionar una percepción de usuario fluida, hay que garantizar que la eUICC+ sea capaz de desencadenar varios ciclos de autenticación a través del módulo de banda base de microteléfono de manera oportuna (con un retardo < 10 s por intento de autenticación). No debe restablecer el visualizador de microteléfono y no debe pedir al usuario final a que introduzca el PIN una y otra vez.
También debe ser independiente del hardware de microteléfono y debe trabajar con los dos sistemas operativos de teléfono inteligente principales: IOS y Android.
Para realizar varios ciclos de incorporación/autenticación de tiempo con distintas IMSI, la eUICC+ emplea órdenes Actualización (TS 102223) u órdenes AT. Esto permite que el módulo de banda base de microteléfono envíe a una MME una solicitud de incorporación de gestión EMM de una manera puntual y controlada.
La figura 12 muestra un segundo caso de uso de la invención.
El SM-DS+ posibilita el segundo caso de uso: el usuario final puede abonarse en cualquier lugar con simplemente encender su microteléfono. Si el usuario final selecciona un operador que está utilizando el SM-DS+ del EUM, el usuario final se abonará a través de pocas etapas. Si el usuario final selecciona un operador que no esta utilizando el SM-DS+ de este EUM, se mostrará un mensaje en el microteléfono que pedirá al usuario final a que vaya a una tienda de MNO.
Aquí son necesarias algunas etapas:
- En una primera etapa, el usuario final recibe un nuevo microteléfono, pedido, por ejemplo, por internet. El microteléfono comprende una eUICC+. Lo enciende.
- En una segunda etapa, el SO de la eUICC+ pide al cliente que seleccione un operador. Introduce, por ejemplo, 3 dígitos correspondientes al operador (aquí “ NET” ) a partir del cual desea obtener una suscripción.
- En una tercera etapa, el microteléfono se incorpora a la red de este operador y recibe un SMS con un enlace de internet en el que pinchar.
- Después de haber pinchado en el enlace, en un cuarto paso, el navegador web de microteléfono se conecta al portal de MNO y el usuario final puede seleccionar un perfil de suscripción.
- En una quinta etapa final, el perfil de suscripción es descargado en la eUICC+ por el SM-DS+ de MNO y el terminal está listo para usarse.
La figura 13 muestra una arquitectura de SM-DS+ para este segundo caso de uso.
En este caso, el servidor 130 de SM-DS+ contiene un sistema llamado sistema 133 de suscripción de autoayuda (en adelante SSS o cuarto servidor). También contiene un D-HSS 131 y un SM-DS 132. El SM-DS está vinculado a través de una conexión ES12 a un SM-DP+ 134 y al SSS 133. El SSS 133 también está vinculado a través de una conexión ES2+ al SM-DP+ y a los BSS/OSS 135 de un MNO. El cuarto servidor SSS 133 contiene un HLR temporal y un sistema de provisión. Cuando no existe ninguna suscripción para una eUICC+, esta envía una orden de petición al usuario, y el usuario introduce un nombre abreviado de un MNO o un código correspondiente a este MNO en su terminal. Al usuario se le puede proponer una lista de distintos MNO, que seleccionará uno de ellos. El D-HSS asocia este nombre abreviado o código al nombre de un MNO, y si este MNO se ha suscrito al servicio con un DS+ alt., el MNO habrá proporcionado al D-HSS un grupo de t-IMSI. El D-HSS envía entonces una orden a la eUICC+ para que realice un cambio de IMSI para incorporarse a este MNO con una de estas t-IMSI y pedir en línea una suscripción.
Más precisamente, cuando, en una primera etapa, una eUICC+ que coopera con un terminal que contiene un identificador único como un EID (o una clave de EID) intenta autenticarse ante el D-HSS 131 con su EID (en una o más etapas, tal y como se ha explicado anteriormente, a través de intercambios de mensajes de señalización), el D-HSS 131 detecta que no tiene ninguna t-IMSI pendiente (al igual que en el caso de uso 1) para el EID enviado por la eUICC+. Al igual que en el caso de uso 1, se produjeron dos intercambios para transmitir el EID (o la clave de EID) de la eUICC+ al D-HSS.
El D-HSS 131 envía de vuelta, en mensajes que tienen la longitud de mensajes RAND/AUTN, a la eUICC+ un número secuencial (identificador Correl-ID) y una orden para visualizar el mensaje «Introduzca el nombre del operador que ha seleccionado»
El usuario introducirá entonces, por ejemplo, NETPHONE como el operador elegido.
La e-UICC+ envía un mensaje con los MCC/MNC, el número secuencial y NET (un identificador que identifica al operador elegido por el usuario), todos como dígitos, al D-HSS 131.
El D-HSS 131 identifica el número secuencial y la red de origen de esta solicitud de autenticación (el país en el que se enciende el dispositivo). Basándose en el país y el identificador NET decodificado a partir del mensaje, el D-HSS 131 identifica a NETPHONE como el operador en el país que tiene el servicio de descubrimiento. El D-HSs 131 envía el EID, la t-IMSI y la e-Ki al sistema SSS de NETPHONE. NETPHONE proporciona en su red estas t-IMSI, clave Ki e EID.
El D-HSS 131 envía al dispositivo (e-UICC+) en los mensajes RAND/AUTN (finalmente, con otro número secuencial) la t-IMSI a la eUICC+ y la orden para cambiar la IMSI.
El dispositivo 10 se incorpora entonces al SSS de MNO con la t-IMSI. Entonces, el abonado, a través de un portal web, selecciona su suscripción, y la descarga de la suscripción puede iniciarse a través del asistente LPA o del SM-DP+.
Estas distintas etapas se explicarán con más detalle en las figuras 14 y 15.
La figura 14 representa un flujo de etapas que permiten al usuario de un terminal seleccionar un operador (su e-UICC+ no contiene ninguna suscripción, sino solo una aplicación de arranque, una Ki efímera y el MCC/MNC del D-HSS y un identificador único).
En una etapa 200, un cliente ha comprado un microteléfono, pero todavía no tiene una suscripción. El usuario final enciende el microteléfono.
En una etapa 201, el microteléfono envía a una MME una solicitud de incorporación de EMM que comprende un mensaje de formato 31. Los dígitos que van después de los MCC/MNC pueden contener un MSIN o un EID (o una clave de EID) o parte de ellos.
En una etapa 202, la MME envía al D-HSS un mensaje Send Authentication Info (e-IMSI) (Enviar info. de autenticación [e-IMSI]). Puede haber una pluralidad de intercambios de mensajes de señalización para recibir un identificador único y entero del elemento de seguridad (en caso de que no pueda enviarse una e-IMSI, un EID o una clave de EID de una sola vez).
En una etapa 203, el D-HSS busca el EID para encontrar la t-IMSI proporcionada por el SM-DS+, pero no encuentra ninguna correspondencia porque no se le ha proporcionado una t-IMSI. A continuación, envía una orden para pedir al usuario a que seleccione un operador en unos mensajes de formato RAND y AUTN.
En una etapa 204, el D-HSS envía a la MME un acuse de recibo de info. de autenticación (orden de petición al usuario), y la MME, en una etapa 205, envía una solicitud de cifrado y autenticación de EMM (RAND, AUTN) a la eUICC+. En una etapa 206, la eUICC+ recibe el alto de autenticación que contiene la orden de petición al usuario.
En una etapa 207, la eUICC+ envía como respuesta un valor RES malo a la MME, y en una etapa 208, se rechaza la incorporación de EMM.
En una etapa 209, el microteléfono interpreta la orden y activa un subprograma o el SO. El subprograma o el SO pide al usuario final que introduzca el nombre del operador del que quiere obtener una suscripción visualizando en la pantalla del microteléfono un mensaje “ Introduzca el nombre del operador” . El usuario introduce entonces el nombre del operador que ha elegido. Transcurrido un tiempo límite (p. ej., 10 s) o después de una orden eUICC+ Refresh (Actualizar eUICC+), se inicia la reincorporación, y en una etapa 210, la eUICC envía a la MME una solicitud de incorporación con el nombre del MNO elegido.
En una etapa 211, la MME envía al D-HSS un mensaje Authentication Info (Info. de autenticación) que contiene el nombre del MNO.
En una etapa 212, el D-HSS compara el nombre de operador (en 3 dígitos, por ejemplo) con la lista de MNO y asigna una t-IMSI a este MNO o recupera una t-IMSI del MNO.
En una etapa 213, el D-HSS proporciona un triplete (EID, t-IMSI, e-Ki) en el sistema SSS de MNO elegido. Tal y como se verá más adelante, el<s>S<s>de MNO puede ordenar que se descargue de un servidor de provisión un perfil de suscripción en el elemento de seguridad.
En una etapa 214, el D-HSS envía a la MME una orden de cambio de t-IMSI en un mensaje Authentication Info Ack (t-IMSI switch command) (Acuse de recibo de info. de autenticación [orden de cambio de t-IMSI]). Este mensaje se envía (etapa 215) a través de una instrucción a la eUICC+ en un mensaje EMM Authentication and Ciphering Req (Solicitud de cifrado y autenticación de EMM) (RAND, AUTN).
En una etapa 216, la eUICC+ recibe el alto (challenge) de autenticación que contiene la t-IMSI y envía una mala respuesta de autenticación (en una etapa 217, se envía de vuelta un valor RES incorrecto para que la eUICC+ no se incorpore al D-HSS). La MME responde entonces (etapa 218) que se ha rechazado la incorporación de EMM.
La eUICC+ está provista ahora de la t-IMSI de su MNO, y podrá conectarse a su red para obtener una suscripción.
La figura 15 muestra la comunicación posterior entre la eUICC+ y los elementos de la figura 13.
En una etapa 220, la eUICC+ recibe una orden Refresh (Actualización) o, transcurrido un tiempo límite de 10s, intenta incorporarse a la red de su MNO con la t-IMSI (etapa 221: mensaje EMM Attach Request (t-IMSI) [Solicitud de incorporación de EMM (t-IMSI)]) enviado a la MME). La MME, en una etapa 222, envía un mensaje Authentification Info (t-IMSI) (Info. de autenticación [t-IMSI]) al SSS, que responde, en una etapa 223, con un mensaje MME Send Authentification Info Ack (vector(e-Ki) (Enviar Acuse de recibo de info. de autenticación [vector(e-Ki)] a la MME). Al recibir la t-IMSI, el SSS la asocia a la e-Ki.
En una etapa 224, la MME envía un mensaje EMM Authentication and Ciphering Req (Solicitud de cifrado y autenticación de EMM) (RAND, AUTN) a la eUICC+. Como la eUICC+ conoce la t-IMSI y la e-Ki, calcula un RES correcto y se lo envía a la MME en una etapa 225. La MME responde (etapa 226) que se acepta la incorporación de la eUICC+.
La MME envía entonces, en una etapa 227, un mensaje Location Update Request (Solicitud de actualización de ubicación) al SSS, que responde con un mensaje Location Update Ack (Acuse de recibo de actualización de ubicación) (etapa 228). La MME puede entonces (etapa 229) iniciar una sesión (en un portal web con un APN) con la pasarela de servicio y la pasarela de red PDN del SSS para seleccionar una suscripción.
En una etapa 230, el SSS envía al microteléfono/eUICC+ un SMS con un enlace al portal de SSS. El usuario final pincha en el enlace recibido en el SMS para abrir un navegador web (etapa 231).
En una etapa 232, el usuario solicita suscribirse en línea al SSS y elige una suscripción (prepago, pospago, internacional...). En una etapa 233, el SSS envía al SM-DP+ un mensaje Download Order (EID, ICCID, Profile type) (Pedido de descarga [EID, ICCID, tipo de perfil]) y proporciona a los BSS/OSS el MNO con al menos una IMSI permanente y un MSISDN (etapa 234). El identificador ICCID de eUICC+ también puede transmitirse a los BSS/OSS.
En una etapa 235, el SSS confirma el pedido (EID, ICCID, sdsdAddress) enviando la dirección del SM-DS+ al SM-DP+.
En una etapa 236, el SM-DP+ envía un mensaje Register event (EID) (Registrar evento [EID]) al SM-DS+ para informarle de que tiene una suscripción lista para la eUICC+.
Después de la etapa 236, el mismo proceso representado en la figura 9 para el primer caso de uso se inicia de nuevo para este segundo caso de uso (descarga de una suscripción en la eUICC+).
La figura 16 muestra un diagrama de flujo detallado que explica un ejemplo de mensajes intercambiados entre la eUICC+ y el D-HSS para este segundo caso de uso.
En esta figura, la eUICC+ se identifica en el D-HSS con su clave de EID, que tiene una longitud de 14 dígitos.
En una etapa 300, la eUICC+ establece su valor de e-IMSI para que contenga unos dígitos 0-8 de clave de EID. El microteléfono envía, en una etapa 301, una orden Read Record (Leer registro) a la eUICC+, y esta responde, en una etapa 302, enviando una respuesta READ RECORD Rsp(e-IMSI(EID key digits 0-8)) (Resp. LEER REGISTRO [e-IMSI(dígitos 0-8 de clave de EiD)]).
En una etapa 303, el microteléfono se conecta a la red que tiene la mayor potencia de señal y, en una etapa 304, envía un mensaje de solicitud de incorporación Attach request (e-IMSI(EID key digits 0-8)) (Solicitud de incorporación [e-IMSI(dígitos 0-8 de clave de EID)]) a la MME. En una etapa 305, la MME envía al D-HSS un mensaje SAI (e-IMSI(EID key digits 0-8)) (SAI [e-IMSI (dígitos 0-8 de clave de EID)]).
En una etapa 306, el D-HSS responde con un mensaje SAI Ack (one Vector(Cmd=0x01, Correl-ID, “ ” )) (Acuse de recibo de SAI [un vector(Cmd=0x01, Correl-ID, “ ” )]) para obtener los dígitos de clave de EID restantes. En una etapa 307, la MME envía al microteléfono un mensaje Authentication request (Cmd=0x01, Corre-ID, “ ” ) (Solicitud de autenticación [Cmd=0x01, Correl-ID, “ ” ]), que se reenvía a la eUICC+ a través de una orden de APDU (etapa 308).
En una etapa 309, la eUICC+ cambia el valor de e-IMSI para que contenga el Correl-ID y los dígitos 27-31 de clave de EID recibidos. En una etapa 310, la eUICC+ envía una orden proactiva de Refresh (UICC Reset) (Actualización [Resetear UICC]) al microteléfono, que responde (etapa 311) con una orden READ RECORD (Leer registro). La eUICC+ responde (etapa 312) con un mensaje READ RECoRd Rsp(e-IMSI(Correl-Id, EID key digits 9-13)) (Resp. LEER REGISTRO [e-IMSI (dígitos 9-13 de Correl-ID y de clave de EID)]).
El microteléfono envía entonces un mensaje Attach request (e-IMSI(Correl-Id, EID key digits 9-13)) (Solicitud de Incorporación [e-IMSI (dígitos 9-13 de Correl-ID y de clave de EID)]) a la MME (etapa 313), y la MME envía al D-HSS un mensaje sAi (e-IMSl(Correl-Id, EID key digits 9-13)) (SAI [e-IMSl(dígitos 9-13 de Correl-ID y de clave de EID)]) en una etapa 314. El D-HSS conoce ahora todas las claves del ElD y puede asociarlas al EID real de la eUICC+.
En una etapa 315, el D-HSS envía a la MME una orden de SAI Ack (one Vector(Cmd=0*04, Corre-ID, “ Select an operator...” )) (Acuse de recibo de SAI [un vector(Cmd=0x04, Correl-ID, “ Seleccione un operador...” )]) para permitir al usuario seleccionar un operador de entre una lista de operadores disponibles.
Tal y como se indica en la figura 5, cuando la eUICC+ recibe una orden 0x04, usará la STK para incitar al usuario final con el mensaje proporcionado en la carga útil.
Esta orden se transmite a la eUICC+ (etapas 316: solicitud de autenticación (Authentication request) (Cmd=0x04, Correl-ID, “ Seleccione un operador..” ); y 317: Autenticar la APDU de solicitud (Authenticate request APDU) (Cmd=0x04, Correl-ID, “ Seleccione un ope rado r.” ). En una etapa 318, la eUICC+ recoge los dígitos introducidos por el usuario final en su microteléfono (aquí, el usuario final ha elegido un operador cuya abreviatura es “ NET” , que significa NETPHONE). El usuario final puede introducir el nombre de operador completo (letras o dígitos numéricos [A-Z y 0-9]). En los 5 dígitos de la carga útil de formato 32 de la figura 3 se pueden codificar 100.000 valores. Por ejemplo, los tres primeros dígitos del nombre de operador están codificados en la carga útil de la IMSI .
En una etapa 319, la eUICC+ es restablecida por una orden proactiva de REFRESH (ACTUALIZACIÓN) para forzar al microteléfono a que vuelva a incorporarse con el nuevo valor de IMSI . En una etapa 320, el microteléfono envía una orden Read Record (Leer registro) a la eUICC+, que responde con una respuesta READ RECORD Rsp(e-IMSI(Correl-ld, “ NET” )) (Resp. LEER REGISTRO [e-IMSI(Correl-lD, “ NET” )]) (etapa 321). En una etapa 322, el microteléfono envía a la MME un mensaje Attach request (e-IMSI(Correl-ld, “ NET” )) (Solicitud de incorporación [e-IMSI(Correl-ID, “ NET” )]) y, en una etapa 323, la mMe envía un mensaje SAI (e-IMSI(Correl-ld, “ NET” )) (SAI [e-IMSl(Correl-lD, “ NET” )]) al D-HSS. El D-HSS responde a la MME (etapa 324) con un mensaje SAI Ack (one Vector(Cmd=0x02, Corre-ID, “ t-IMSI” )) (Acuse de recibo de SAI [un vector(Cmd=0x02, Correl-ID, “t-IMSI” )]). El D-HSS tiene una lista de t-IMSI que corresponden a las t-IMSI asignadas a cada operador. Tal y como se muestra en la figura 9, la orden enviada junto con la t-IMSI (que tiene los códigos MCC/MNC de este operador) es una orden de cambio de la e-IMSI a la t-IMSI.
La MME envía entonces una solicitud de Autenticación (Cmd=0x02, Correl-ID, “ t-IMSI” ) al microteléfono (etapa 325), y el microteléfono envía a la eUICC+ un Autenticar la APDU de solicitud (Authenticate request APDU) (Cmd=0x02, Correl-ID, “t-IMSI” ) en la etapa 326. Aquí es obligatorio el Correl-ID, ya que el servidor D-HS no le está pidiendo una respuesta a la eUICC+.
La eUICC cambia entonces la e-IMSI por la t-IMSI y envía una orden proactiva de Refresh (UICC Reset) (Actualización [Restablecer tarjeta UICC]) al microteléfono (etapa 327).
Tal y como se indica en una etapa 328, después pueden tener lugar otros pasos, a saber, las etapas de la figura 15 para descargar una suscripción del operador elegido.
Todos los elementos representados en las figuras comprenden al menos un microprocesador que comprende instrucciones para ejecutar las distintas etapas expuestas anteriormente.
Si el usuario del terminal desea vender o dar su terminal a otro usuario (y borrar su suscripción en su terminal), se puede prever una aplicación en la eUICC+ para volver a cambiar la identidad p-IMSI a la e-IMSI. El nuevo propietario del terminal puede entonces volver a iniciar el método de la invención poniéndose en contacto con el servidor D-HSS usando los primeros MCC/MNC comprendidos en la e-IMSI (o en el identificador UID [clave] de la eUICC+).
La invención permite establecer un diálogo entre un dispositivo y un servidor de descubrimiento SM-DS+ sin incorporarse a una red celular ni usar una conectividad wifi con el objetivo de incorporarse a la red de operador seleccionada o buscada entre los cientos de operadores de red para descargar el perfil de suscripción con su credencial. La invención está diseñada para redes 2G, 3G y LTE sin modificaciones estándar. La invención es también aplicable a redes 5G.

Claims (12)

REIVINDICACIONES
1. Método para establecer un canal de comunicación bidireccional entre un servidor (12, 131,401) y un elemento (11) de seguridad que coopera con un terminal (10) de telecomunicación en una red de telecomunicación celular para intercambiar datos y órdenes, comprendiendo dicho método:
a) Enviar, a través de una banda base de dicho terminal (10) de telecomunicación, un primer mensaje de señalización de solicitud de incorporación de dicho elemento (11) de seguridad a dicho servidor (12, 131, 401), comprendiendo dicho mensaje de señalización de solicitud de incorporación un MCC y un MNC de dicho servidor (12, 131, 401), y al menos una parte de un identificador único de dicho elemento (11) de seguridad, teniendo dicho primer mensaje de señalización de solicitud de incorporación un campo modificado en comparación con un mensaje de solicitud de incorporación normalizado, en donde un campo de dicho primer mensaje de señalización de solicitud de incorporación comprende, la al menos una parte de dicho identificador único y es el campo modificado en comparación con un campo MSIN de dicho mensaje de solicitud de incorporación normalizado, estando dicho servidor (12, 131, 401) provisto de dicho identificador único;
b) Recibir el primer mensaje de señalización de solicitud de incorporación por parte del servidor y, en respuesta al mismo, enviar de dicho servidor (12, 131, 401) a dicho elemento (11) de seguridad, a través de la banda base de dicho terminal (10) de telecomunicación, al menos un primer mensaje (40) de señalización que tiene la longitud de un mensaje normalizado enviado en respuesta a dicho mensaje de solicitud de incorporación normalizado, teniendo dicho primer mensaje de señalización unos campos modificados en comparación con el mensaje normalizado, en donde los campos modificados de dicho primer mensaje de señalización comprenden:
-al menos una orden, CMD;
-un identificador de correlación, Correl-ID, si hay que enviar más mensajes de dicho elemento (11) de seguridad a dicho servidor (12, 131, 401), utilizándose dicho identificador de correlación para emparejar los mensajes intercambiados entre dicho servidor (12, 131, 401) y dicho elemento (11) de seguridad;
-una primera carga útil que comprende datos;
c) Ejecutar en dicho elemento (11) de seguridad dicha orden.
2. Método según la reivindicación 1, en donde dicho identificador único es un EID o una clave obtenida de dicho EID.
3. Método según la reivindicación 1 o 2, en donde dicho servidor envía con dicho primer mensaje de señalización un segundo mensaje (41) de señalización que contiene datos.
4. Método según cualquiera de las reivindicaciones 1 a 3, en donde dichos datos contienen un MCC, MCC2, y un MNC, MNC2, de un servidor de un MNO y una IMSI temporal, t-IMSI, que permiten a dicho elemento (11) de seguridad incorporarse a la red de dicho MNO.
5. Un servidor (12, 131, 401) provisto de un identificador único de un elemento (11) de seguridad, comprendiendo dicho servidor (12, 131, 401) al menos un microprocesador que comprende instrucciones para:
a) recibir de dicho elemento (11) de seguridad, a través de una banda base de un terminal (10) de telecomunicación, cooperando dicho elemento de seguridad con dicho terminal (10) de telecomunicación, un primer mensaje de señalización de solicitud de incorporación que comprende un MCC y un MNC de dicho servidor (12, 131,401) y al menos una parte de un identificador único de dicho elemento (11) de seguridad, teniendo dicho primer mensaje de señalización de solicitud de incorporación un campo modificado en comparación con un mensaje de solicitud de incorporación normalizado, en donde un campo de dicho primer mensaje de señalización de solicitud de incorporación comprende, la la al menos una parte de dicho identificador único y es el campo modificado en comparación con un campo MSIN de dicho mensaje de solicitud de incorporación normalizado;
b) enviar a dicho elemento (11) de seguridad, a través de la banda base de dicho terminal (10) de telecomunicación, al menos un primer mensaje (40) de señalización que tiene la longitud de un mensaje normalizado enviado en respuesta a dicho mensaje de solicitud de incorporación normalizado, teniendo dicho primer mensaje de señalización unos campos modificados en comparación con el mensaje normalizado y enviándose en respuesta al primer mensaje de señalización de solicitud de incorporación, en donde los campos modificados de dicho primer mensaje de señalización comprenden:
-al menos una orden, CMD;
-un identificador de correlación, Correl-ID, si hay que enviar más mensajes de dicho elemento (11) de seguridad a dicho servidor (12, 131, 401), utilizándose dicho identificador de correlación para emparejar los mensajes intercambiados entre dicho servidor (12, 131, 401) y dicho elemento (11) de seguridad;
-una primera carga útil que comprende datos;
c) repetir las etapas a y b hasta que dicho servidor (12, 131, 401) haya recibido de dicho elemento (11) de seguridad dicho identificador único completo;
d) recuperar una IMSI temporal, t-IMSI, provista en un servidor de un MNO correspondiente a dicho identificador único; e) enviar dicho IMSI temporal, t-IMSI, a dicho elemento (11) de seguridad con una orden para que reemplace su IMSI actual por dicha IMSI temporal, t-IMSI.
6. Un servidor según la reivindicación 5, en donde dicho identificador único es un EID o una clave obtenida de dicho EID.
7. Un SM-DS+ (400) que comprende un servidor (12, 131, 401) según cualquiera de las reivindicaciones 5 y 6, en donde también comprende un servidor SM-DS (132, 402) adaptado para proporcionar a un servidor HSS (404) un MNO con una IMSI temporal, t-IMSI, transmitida a dicho elemento (11) de seguridad junto con una Ki efímera, e-Ki, contenida en dicho elemento (11) de seguridad.
8. Un elemento (11) de seguridad que coopera con un terminal (10) de telecomunicación en una red de telecomunicación celular y que comprende un sistema operativo que comprende instrucciones para:
a) Enviar, a través de una banda base del terminal (10) de telecomunicación, un primer mensaje de señalización de solicitud de incorporación a un servidor (12, 131, 401), comprendiendo dicho mensaje de señalización de solicitud de incorporación un MCC y un MNC de dicho servidor (12, 131, 401), y al menos una parte de un identificador único de dicho elemento (11) de seguridad, teniendo dicho primer mensaje de señalización de solicitud de incorporación un campo modificado en comparación con un mensaje de solicitud de incorporación normalizado, en donde un campo de dicho primer mensaje de señalización de solicitud de incorporación comprende, la al menos una parte de dicho identificador único y es el campo modificado en comparación con un campo MSIN de dicho mensaje de solicitud de incorporación normalizado, estando dicho servidor (12, 131, 401) provisto de dicho identificador único;
b) Recibir, en respuesta al primer mensaje de señalización de solicitud de incorporación y de dicho servidor (12, 131, 401), a través de dicha banda base de dicho terminal (10) de telecomunicación, al menos un primer mensaje (40) de señalización que tiene la longitud de un mensaje normalizado enviado en respuesta a dicho mensaje de solicitud de incorporación normalizado, teniendo dicho primer mensaje de señalización unos campos modificados en comparación con el mensaje normalizado, en donde los campos modificados de dicho primer mensaje de señalización comprenden:
-al menos una orden, CMD;
-un identificador de correlación, Correl-ID, si hay que enviar más mensajes de dicho elemento (11) de seguridad a dicho servidor (12, 131, 401), utilizándose dicho identificador de correlación para emparejar los mensajes intercambiados entre dicho servidor (12, 131, 401) y dicho elemento (11) de seguridad;
-una primera carga útil que comprende datos;
c) Ejecutar en dicho elemento (11) de seguridad dicha orden.
9. Un elemento (11) de seguridad según la reivindicación 8, en donde dicho identificador único es un EID o una clave obtenida de dicho EID.
10. Un elemento (11) de seguridad según las reivindicaciones 8 o 9, en donde dicho sistema operativo comprende además unas instrucciones para enviar a dicho servidor (12, 131,401), en al menos un segundo mensaje de señalización, dicho MCC, dicho MNC, dicho identificador de correlación, Correl-ID, recibido de dicho servidor (12, 131, 401) y una segunda carga útil que contiene datos, y en donde dicho sistema operativo comprende además unas instrucciones para repetir las etapas a y b en caso necesario hasta que dicho elemento (11) de seguridad y dicho servidor (12, 131, 401) no necesiten intercambiar más datos u órdenes.
11. Un elemento (11) de seguridad según cualquiera de las reivindicaciones 8 a 10, en donde este consiste en:
-una tarjeta UICC, o
-una tarjeta eUICC, o
-una tarjeta iUICC.
12. Un terminal (10) que comprende un elemento (11) de seguridad según cualquiera de las reivindicaciones 8 a 11.
ES18703004T 2017-02-03 2018-02-02 Método para establecer un canal de comunicación bidireccional entre un servidor y un elemento de seguridad, unos servidores correspondientes y un elemento de seguridad Active ES2957936T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP17305124.4A EP3358867A1 (en) 2017-02-03 2017-02-03 Method for managing communication between a server and a user equipment
EP17305203.6A EP3358868A1 (en) 2017-02-03 2017-02-24 Method for establishing a bidirectional communication channel between a server and a secure element, corresponding servers and secure element
PCT/EP2018/052629 WO2018141895A1 (en) 2017-02-03 2018-02-02 Method for establishing a bidirectional communication channel between a server and a secure element, corresponding servers and secure element.

Publications (1)

Publication Number Publication Date
ES2957936T3 true ES2957936T3 (es) 2024-01-30

Family

ID=58261603

Family Applications (3)

Application Number Title Priority Date Filing Date
ES18701361T Active ES2867388T3 (es) 2017-02-03 2018-01-29 Método para una eUICC integrada en un dispositivo de comunicación de tipo máquina para activar la descarga de un perfil de suscripción
ES18703004T Active ES2957936T3 (es) 2017-02-03 2018-02-02 Método para establecer un canal de comunicación bidireccional entre un servidor y un elemento de seguridad, unos servidores correspondientes y un elemento de seguridad
ES18703003T Active ES2873829T3 (es) 2017-02-03 2018-02-02 Método para gestionar la comunicación entre un servidor y un equipo de usuario

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES18701361T Active ES2867388T3 (es) 2017-02-03 2018-01-29 Método para una eUICC integrada en un dispositivo de comunicación de tipo máquina para activar la descarga de un perfil de suscripción

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES18703003T Active ES2873829T3 (es) 2017-02-03 2018-02-02 Método para gestionar la comunicación entre un servidor y un equipo de usuario

Country Status (9)

Country Link
US (7) US11039300B2 (es)
EP (9) EP3358867A1 (es)
JP (4) JP6812565B2 (es)
KR (4) KR102254345B1 (es)
CN (3) CN110622535B (es)
BR (2) BR112019016200A2 (es)
ES (3) ES2867388T3 (es)
PL (1) PL3577923T3 (es)
WO (5) WO2018141665A1 (es)

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3358867A1 (en) 2017-02-03 2018-08-08 Gemalto Sa Method for managing communication between a server and a user equipment
US11863663B2 (en) * 2018-03-20 2024-01-02 Telefonaktiebolaget Lm Ericsson (Publ) Initial network authorization for a communications device
US11094158B2 (en) * 2018-08-08 2021-08-17 Carefusion 303, Inc. Mobile system for dispensing medication
EP3614706A1 (en) * 2018-08-23 2020-02-26 Thales Dis France SA Method for personalizing an improved uicc cooperating with a terminal
EP3621333A1 (en) * 2018-09-05 2020-03-11 Thales Dis France SA Method for updating a secret data in a credential container
US10911945B1 (en) * 2018-11-19 2021-02-02 Sprint Spectrum L.P. Automated eUICC service profile configuration in view of operational issue with respect to eUICC service profile
EP3664486A1 (en) 2018-12-03 2020-06-10 Thales Dis France SA Method and apparatuses for ensuring secure attachment in size constrained authentication protocols
EP3678395A1 (en) * 2019-01-04 2020-07-08 Thales Dis France SA A method for connecting a secure element to a network of a mobile network operator and corresponding secure element
WO2020145623A1 (en) * 2019-01-08 2020-07-16 Samsung Electronics Co., Ltd. Apparatus and method for handling esim profile for issp device
KR20200114392A (ko) 2019-03-28 2020-10-07 삼성전자주식회사 가입자 프로파일을 설치하기 위한 방법 및 그 전자 장치
EP3719706A1 (en) * 2019-04-01 2020-10-07 Thales Dis France SA Method for patching an operating system on a secure element transparently through an sm-sr platform
CN113874876A (zh) * 2019-06-05 2021-12-31 万事达卡国际公司 用于分布式计算系统的安全模型
US11523269B2 (en) * 2019-08-05 2022-12-06 Flo Live Israel LTD. Multiple profile remote subscriber identity module
US11627448B2 (en) 2019-08-05 2023-04-11 Flo Live Israel LTD. Method and system for fast initialization of an electronic subscriber identity module at multiple locations
US11617065B2 (en) * 2019-08-30 2023-03-28 Jio Platforms Limited System and method for remote profile provisioning
WO2021059541A1 (ja) * 2019-09-27 2021-04-01 株式会社Ｎｔｔドコモ 端末
WO2021100913A1 (ko) * 2019-11-21 2021-05-27 엘지전자 주식회사 기지국 및 다른 전자 장치의 세트와 통신하는 전자 장치 및 그 통신 방법
EP3832996A1 (en) * 2019-12-06 2021-06-09 Thales Dis France Sa Method to dynamically select a mobile operator subscription based on the terminal location, on the received signal strengths and on business agreements, corresponding secure element and home subscriber server
CN111884828A (zh) * 2019-12-18 2020-11-03 中国联合网络通信集团有限公司 物联网设备运营商的配置方法和物联网设备
WO2021098115A1 (en) * 2020-03-31 2021-05-27 Zte Corporation Parameters for application communication establishment
US11109220B1 (en) 2020-05-29 2021-08-31 T-Mobile Usa, Inc. Enterprise embedded subscriber identification module solutions
JPWO2022024944A1 (es) * 2020-07-28 2022-02-03
KR20220028863A (ko) * 2020-08-31 2022-03-08 삼성전자주식회사 통신 시스템에서 이벤트를 관리하는 방법 및 장치
US11533605B2 (en) 2020-11-05 2022-12-20 Qualcomm Incorporated Remote SIM provisioning
US11653197B2 (en) * 2020-11-05 2023-05-16 Qualcomm Incorporated Remote SIM provisioning
PL4044640T3 (pl) * 2021-02-16 2023-05-22 Deutsche Telekom Ag Mechanizm wykrywania usług dla usług konfiguracji uprawnień esim
US11516676B1 (en) 2021-07-14 2022-11-29 Sprint Communications Company Lp Secure provisioning of electronic subscriber identity module (eSIM) profiles
EP4199557A1 (en) 2021-12-14 2023-06-21 Thales Dis France SAS A method for provisioning a secure element with a profile
EP4243346A1 (en) * 2022-03-11 2023-09-13 Thales Dis France SAS A method for testing a terminal comprising a non-removable secure element comprising a naa
WO2023219622A1 (en) * 2022-05-12 2023-11-16 Jt (Jersey) Limited Identification method and apparatus
EP4297457A1 (en) 2022-06-21 2023-12-27 Thales Dis France Sas A method for sending data to a user equipment cooperating with a secure element and corresponding server
US20240048382A1 (en) * 2022-08-03 2024-02-08 1080 Network, Llc Systems, methods, and computing platforms for executing credential-less network-based communication exchanges
WO2024058432A1 (ko) * 2022-09-14 2024-03-21 삼성전자 주식회사 프로파일 다운로드를 관리하는 전자 장치 및 그 동작 방법

Family Cites Families (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IL141441A0 (en) * 2001-02-15 2002-03-10 Aharonson Dov Smart card having an optical communication circuit and a method for use thereof
US20040005892A1 (en) * 2002-04-18 2004-01-08 Arnaldo Mayer System and method for managing parameter exchange between telecommunications operators
WO2005125261A1 (en) * 2004-06-17 2005-12-29 Telefonaktiebolaget Lm Ericsson (Publ) Security in a mobile communications system
CN1870808A (zh) * 2005-05-28 2006-11-29 华为技术有限公司 一种密钥更新方法
US7995565B2 (en) * 2006-10-03 2011-08-09 Research In Motion Limited System and method for managing call continuity in IMS network environment using SIP messaging
US8064597B2 (en) * 2007-04-20 2011-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for mobile device credentialing
CN102215474B (zh) * 2010-04-12 2014-11-05 华为技术有限公司 对通信设备进行认证的方法和装置
EP2461613A1 (en) * 2010-12-06 2012-06-06 Gemalto SA Methods and system for handling UICC data
US8924572B2 (en) * 2010-12-21 2014-12-30 Tektronix, Inc. Topology detection of LTE nodes
US9253630B2 (en) * 2011-06-02 2016-02-02 Truphone Limited Identity management for mobile devices
EP2533485B1 (en) * 2011-06-08 2015-03-04 Giesecke & Devrient GmbH Methods and devices for OTA management of subscriber identify modules
ES2748112T3 (es) * 2011-06-21 2020-03-13 Alcatel Lucent Método para cargar credenciales de suscriptor y equipo asociado
CN108601014A (zh) * 2011-07-01 2018-09-28 交互数字专利控股公司 在无线发射/接收单元（wtru）中使用的方法和wtru
WO2013039900A1 (en) * 2011-09-16 2013-03-21 Alcatel-Lucent Usa Inc. Network operator-neutral provisioning of mobile devices
CN102395130B (zh) * 2011-11-01 2014-06-04 重庆邮电大学 一种lte中鉴权的方法
EP2632196A1 (en) * 2012-02-24 2013-08-28 Alcatel Lucent Smart card initial personnalization
EP2817987B1 (en) * 2012-02-24 2018-10-03 Sony Corporation Mobile communication using reconfigurable user identification module
CN108599964B (zh) * 2012-02-29 2022-02-22 交互数字专利控股公司 一种由wtru执行的方法及wtru
KR102173534B1 (ko) * 2012-05-24 2020-11-03 삼성전자 주식회사 이동통신사업자 정보 제공 방법 및 이를 수행하는 장치
EP2704467A1 (en) * 2012-09-03 2014-03-05 Alcatel Lucent Smart card initial personnalization with local generation of keys
US20140280241A1 (en) 2013-03-15 2014-09-18 MediaGraph, LLC Methods and Systems to Organize Media Items According to Similarity
EP2835994B1 (en) * 2013-08-09 2017-06-21 Giesecke & Devrient GmbH Methods and devices for performing a mobile network switch
EP2835996B1 (en) * 2013-08-09 2018-03-28 Giesecke+Devrient Mobile Security GmbH Methods and devices for performing a mobile network switch
GB2522044A (en) * 2014-01-10 2015-07-15 Samsung Electronics Co Ltd Provisioning apparatus and methods therefor
US9563771B2 (en) 2014-01-22 2017-02-07 Object Security LTD Automated and adaptive model-driven security system and method for operating the same
GB2525205B (en) * 2014-04-15 2020-12-16 Vodafone Ip Licensing Ltd Provisioning a network subscription
KR102200209B1 (ko) * 2014-04-22 2021-01-08 삼성전자 주식회사 프로파일 설치 방법 및 장치
US9439116B2 (en) * 2014-05-19 2016-09-06 Cisco Technology, Inc. System and method for identifying a subscriber in a network environment
US9503956B2 (en) * 2014-05-30 2016-11-22 Gogo Llc Systems and methods for facilitating communications originating from a non-terrestrial network
CN104093139B (zh) * 2014-07-15 2017-10-03 中国联合网络通信集团有限公司 空中写卡方法、服务器和智能卡
KR102231948B1 (ko) * 2014-07-17 2021-03-25 삼성전자 주식회사 프로파일 관리서버의 업데이트 방법 및 장치
KR102191017B1 (ko) * 2014-07-19 2020-12-15 삼성전자주식회사 eSIM 프로비저닝 방법과 이를 지원하는 서버 장치
FR3029728B1 (fr) * 2014-12-04 2017-01-06 Oberthur Technologies Procede de provisionnement d'un profil de souscripteur pour un module securise
EP3035724A1 (en) * 2014-12-19 2016-06-22 Telefónica, S.A. Method and system for dynamic managing of subscriber devices with multi-imsi sims in mobile networks
US10237729B2 (en) * 2015-03-05 2019-03-19 Qualcomm Incorporated Identity privacy in wireless networks
KR102358130B1 (ko) * 2015-03-25 2022-02-04 삼성전자 주식회사 이동통신시스템에서 단말을 변경하여 이동 통신 서비스를 이용하는 방법 및 장치
KR102303504B1 (ko) * 2015-03-25 2021-09-17 삼성전자 주식회사 무선 통신 시스템에서 단말의 프로파일 설치 방법 및 장치
EP3082355A1 (en) 2015-04-17 2016-10-19 Gemalto Sa A method for controlling remotely the permissions and rights of a target secure element
US9807544B2 (en) * 2015-06-25 2017-10-31 Verizon Patent And Licensing Inc. Addition of secondary endpoint based on message reply
US10212165B1 (en) * 2015-08-25 2019-02-19 Vital Connect, Inc. Secured vital sign data group streams
US10149168B2 (en) * 2015-12-16 2018-12-04 Qualcomm Incorporated Secured paging
EP3391607B1 (en) * 2015-12-18 2019-12-04 Telefonaktiebolaget LM Ericsson (publ) Method of generating a pseudonym associated with a communication device, a network node, computer program and computer program product
KR102468974B1 (ko) * 2016-03-21 2022-11-22 삼성전자주식회사 전자 장치 및 전자 장치의 제어 방법
EP3277008A1 (de) * 2016-07-29 2018-01-31 Deutsche Telekom AG Teilnehmeridentitätselement zum authentifizieren eines kommunikationsgerätes gegenüber einem kommunikationsnetzwerk
US10394674B2 (en) * 2016-08-24 2019-08-27 Apple Inc. Local recovery of electronic subscriber identity module (eSIM) installation flow
US10455352B2 (en) 2016-10-10 2019-10-22 Cognizant Technology Solutions India Pvt. Ltd. System and method for determining location of resources in a predefined region
WO2018076711A1 (zh) * 2016-10-31 2018-05-03 华为技术有限公司 一种简档下载方法及设备
WO2018094581A1 (zh) * 2016-11-22 2018-05-31 华为技术有限公司 一种签约数据集的安装方法、终端及服务器
US11832347B2 (en) * 2017-01-13 2023-11-28 Huawei Technologies Co., Ltd. Subscription profile downloading method, device, and server
EP3358867A1 (en) 2017-02-03 2018-08-08 Gemalto Sa Method for managing communication between a server and a user equipment
EP3457728A1 (en) * 2017-09-15 2019-03-20 Gemalto Sa A method for allocating temporarily a subscription to a credential container
US20190313246A1 (en) * 2018-04-06 2019-10-10 Iot And M2M Technologies, Llc Device default wifi credentials for simplified and secure configuration of networked transducers

Also Published As

Publication number Publication date
JP2020511097A (ja) 2020-04-09
CN110447251A (zh) 2019-11-12
US11290869B2 (en) 2022-03-29
US11064346B2 (en) 2021-07-13
US11825551B2 (en) 2023-11-21
EP3577923B1 (en) 2023-08-09
EP3577922A1 (en) 2019-12-11
CN110447251B (zh) 2022-04-15
ES2867388T3 (es) 2021-10-20
CN110622535B (zh) 2022-06-07
KR102254345B1 (ko) 2021-05-20
EP3358868A1 (en) 2018-08-08
JP2020505879A (ja) 2020-02-20
JP2020508017A (ja) 2020-03-12
US20210314765A1 (en) 2021-10-07
EP3358869A1 (en) 2018-08-08
EP3577923A1 (en) 2019-12-11
EP3577922B1 (en) 2021-03-31
US11974358B2 (en) 2024-04-30
PL3577923T3 (pl) 2023-10-30
US11601798B2 (en) 2023-03-07
EP3577924A1 (en) 2019-12-11
KR20190134603A (ko) 2019-12-04
US20230164542A1 (en) 2023-05-25
BR112019016201A2 (pt) 2020-04-07
EP3577921B1 (en) 2021-03-17
US20200015069A1 (en) 2020-01-09
KR102260229B1 (ko) 2021-06-03
KR20190134604A (ko) 2019-12-04
WO2018141897A1 (en) 2018-08-09
WO2018141896A1 (en) 2018-08-09
KR102371357B1 (ko) 2022-03-07
JP6775090B2 (ja) 2020-10-28
JP6803481B2 (ja) 2020-12-23
KR102241255B1 (ko) 2021-04-16
JP6812565B2 (ja) 2021-01-13
KR20190131481A (ko) 2019-11-26
CN110463237A (zh) 2019-11-15
KR20190139203A (ko) 2019-12-17
EP4250788A1 (en) 2023-09-27
CN110622535A (zh) 2019-12-27
US20210392489A1 (en) 2021-12-16
US20190349766A1 (en) 2019-11-14
WO2018141665A1 (en) 2018-08-09
EP3577921A1 (en) 2019-12-11
EP3358870A1 (en) 2018-08-08
ES2873829T3 (es) 2021-11-04
JP2020507291A (ja) 2020-03-05
US20200021973A1 (en) 2020-01-16
WO2018141895A1 (en) 2018-08-09
WO2018141889A1 (en) 2018-08-09
US20200236538A1 (en) 2020-07-23
US11129015B2 (en) 2021-09-21
US11039300B2 (en) 2021-06-15
BR112019016200A2 (pt) 2020-03-24
JP6911156B2 (ja) 2021-07-28
EP3358867A1 (en) 2018-08-08
CN110463237B (zh) 2022-03-29

Similar Documents

Publication Publication Date Title
ES2957936T3 (es) Método para establecer un canal de comunicación bidireccional entre un servidor y un elemento de seguridad, unos servidores correspondientes y un elemento de seguridad
ES2535386T3 (es) Procedimientos y dispositivos para gestión durante la comunicación (OTA) de módulos de identificación de abonado
US10938955B2 (en) System and method for lightweight-machine-to-machine device registration and assignment
US10075205B2 (en) Method and apparatus for provisioning profiles
ES2754216T3 (es) Método de aprovisionamiento de un perfil de abonado para un módulo asegurado
US20200344594A1 (en) Method for assistance with the remote configuration of an euicc card and system for implementing such a method
ES2953741T3 (es) Método para personalizar una cooperación de UICC mejorada con un terminal
RU2778145C2 (ru) Способ содействия в дистанционной настройке euicc-карты и система для реализации такого способа
ES2777783T3 (es) Técnicas para emparejamiento móvil