ES2620028T3 - Módulo de identidad para la autentificación de un abonado en una red de comunicación - Google Patents

Módulo de identidad para la autentificación de un abonado en una red de comunicación Download PDF

Info

Publication number
ES2620028T3
ES2620028T3 ES13752837.8T ES13752837T ES2620028T3 ES 2620028 T3 ES2620028 T3 ES 2620028T3 ES 13752837 T ES13752837 T ES 13752837T ES 2620028 T3 ES2620028 T3 ES 2620028T3
Authority
ES
Spain
Prior art keywords
subscriber identity
management
identity module
subscriber
identity data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES13752837.8T
Other languages
English (en)
Inventor
Karl Eglof Hartel
Ulrich Huber
Nils Nitsch
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.)
Giesecke and Devrient GmbH
Original Assignee
Giesecke and Devrient GmbH
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 Giesecke and Devrient GmbH filed Critical Giesecke and Devrient GmbH
Application granted granted Critical
Publication of ES2620028T3 publication Critical patent/ES2620028T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/66—Substation equipment, e.g. for use by subscribers with means for preventing unauthorised or fraudulent calling
    • H04M1/667—Preventing unauthorised calls from a telephone set
    • H04M1/67—Preventing unauthorised calls from a telephone set by electronic means
    • H04M1/675—Preventing unauthorised calls from a telephone set by electronic means the user being required to insert a coded card, e.g. a smart card carrying an integrated circuit chip
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/60—Subscription-based services using application servers or record carriers, e.g. SIM application toolkits
    • 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/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/06—Registration at serving network Location Register, VLR or user mobility server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
    • 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/45—Security arrangements using identity modules using multiple identity modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/72—Subscriber identity
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/005—Data network PoA devices

Landscapes

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

Abstract

Módulo de identidad de abonado (1) para la autentificación de un abonado en una red de comunicación, en el que el módulo de identidad de abonado (1) presenta: - un primer juego de datos de identidad de abonado (13a) para la autentificación del abonado; - al menos un segundo juego de datos de identidad de abonado (13b) para la autentificación del abonado, en el que el primer juego de datos de identidad de abonado (13a) se diferencia del segundo juego de datos de identidad de abonado (13b); y - un medio para la gestión del primer juego de datos de identidad de abonado (13a) y del segundo juego de datos de identidad de abonado (13b), en el que la gestión se realiza mediante funciones de gestión estáticas (8); caracterizado porque - el medio para la gestión presenta además un código de aplicación de gestión (9) y éste código de aplicación de gestión (9) posibilita una gestión variable mediante adaptación de las funciones de gestión estáticas a los parámetros de entorno del módulo de identidad de abonado (1).

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Modulo de identidad para la autentificacion de un abonado en una red de comunicacion
La invencion se refiere a un modulo de identidad de abonado para la autentificacion de un abonado en una red de comunicacion, a un procedimiento para la gestion de un modulo de identidad de abonado con un primer juego de datos de identidad de abonado y un segundo juego de datos de identidad de abonado, a un uso del modulo de identidad de abonado, asi como a un sistema constituido por el modulo de identidad de abonado y a una instancia de servidor remota.
Los datos de identidad de abonado sirven para identificar y/o autentificar un abonado de forma univoca en una red de comunicacion, por ejemplo una red de telefonia movil digital. Mediante estos datos de identidad de abonado, a un operador de una red de comunicacion le es posible asociar de forma univoca el uso de un servicio ofrecido por el operador de red, por ejemplo, de un servicio de voz y/o datos, con cada abonado de la red de comunicacion. Ademas, al operador le es posible facilitar un acceso a la red, es decir, el ingreso en la red de comunicacion, en cuanto ha tenido lugar una autentificacion del abonado o negar el acceso a la red si no es posible una autentificacion del abonado.
Estos datos de identidad de abonado estan almacenados en un modulo de identidad de abonado, tambien denominado Subscriber Identity Modul, (SIM). Habitualmente cada terminal se equipa con un modulo de identidad de abonado de este tipo, para poder usar los servicios de la red de comunicacion.
Si un abonado se registra en una red de comunicacion, entonces mediante los datos de identidad de abonado se constata si el abonado es conocido en la red de comunicacion y que servicios puede usar en la red. Un abonado no identificable o autentificable de forma univoca no esta autorizado para el uso de los servicios y se rechaza por la red.
Se conoce la instalacion en un modulo de identidad de abonado de al menos un primer juego y un segundo juego de datos de identidad de abonado, entre los que se puede conmutar. Los modulos de identidad de abonado de este tipo tambien se designan como Dual-IMSI, Multi-IMSI y/o Auto-Roamer SIM.
La gestion de los datos de identidad de abonado, asi como la conmutacion del primer juego de datos de identidad de abonado al segundo juego de datos de identidad de abonado en el modulo de identidad de abonado se realiza generalmente mediante una instancia de servidor remota, por ejemplo una instancia de red para la gestion de los datos de identidad de abonado, tambien denominada gestor de subscripciones (Subscription Manager). La instancia de servidor remota envia para ello los comandos de gestion y conmutacion correspondientes al modulo de identidad de abonado respectivo. La gestion y conmutacion las realiza luego el sistema operativo del modulo de identidad de abonado. Alternativamente, la gestion y conmutacion las realiza un codigo de aplicacion equiparable casi al sistema operativo del modulo de identidad de abonado.
Lo problematico de ello es que en el modulo de identidad de abonado no estan implementadas estrategias de conmutacion o solo estan implementadas estrategias de conmutacion estaticas, por ejemplo, en el caso de falta de cobertura de red, red sobrecargada o criterios de emplazamiento especificos, como funciones de codigo de conmutacion. Estas funciones son un componente fijo del modulo de identidad de abonado y estan implementados de manera que no se pueden modificar. Por consiguiente, el modulo de identidad de abonado no es capaz de reaccionar de forma adecuada a las alteraciones actuales que se produzcan en el entorno, en la red, en los terminales, etc. Por consiguiente, el modulo de identidad de abonado no se puede gestionar a base de especificaciones individuales, parametros de red y/o propiedades de terminales actuales. En lugar de ello, se llama siempre a las mismas funciones de gestion y conmutacion estaticas implementadas y se terminan completamente.
Es imposible detectar y tener en cuenta todas las particularidades o alteraciones posibles, que se deben considerar en la gestion y/o conmutacion del modulo de identidad de abonado, incluidas ya dentro de las funciones del sistema operativo, debido a la multiplicidad de alteraciones posibles relativas a la red, al terminal, a la ubicacion momentanea, asi como a la multiplicidad de comandos de gestion. Ademas, en el ciclo de vida del modulo de identidad de abonado pueden aparecer adicionalmente efectos de aprendizaje que posibilitan una gestion mejorada, en particular la conmutacion. Ademas, tambien puede que se desarrollen metodos mejores posteriormente a la comercializacion del modulo de identidad de abonado, que luego no sea posible aplicar a todos los modulos de identidad de abonado en uso o, que si se aplican, requieran una costosa sustitucion de los modulos.
En el documento de solicitud de patente de Francia FR 2941585 A1 se presenta un dispositivo de comunicacion con al menos dos interfaces, permitiendo la primera interfaz un intercambio de datos entre un terminal y el dispositivo de conmutacion y permitiendo la segunda interfaz un intercambio de datos entre el dispositivo de comunicacion e Internet.
De la solicitud de patente de Alemania presentada el 14 de agosto de 2012 ante la Oficina alemana de patentes y marcas, con numero de solicitud DE 10201206166.2 del presente solicitante, se conoce adaptar la conmutacion en funcion de los parametros de red, a fin de garantizar un ingreso en la red lo mas satisfactorio posible despues de la
5
10
15
20
25
30
35
40
45
50
55
60
65
conmutacion. Basandose en la solucion descrita, la presente invencion tiene el objetivo de flexibilizar aun mas la gestion del modulo de identidad de abonado. En este documento se hara referencia a la divulgacion del documento DE 102012016166.2.
El objetivo de la invencion se consigue mediante las medidas descritas en las reivindicaciones independientes de distintas categorias. Las configuraciones ventajosas estan descritas en las respectivas reivindicaciones dependientes.
El objetivo se consigue, en particular, mediante un modulo de identidad de abonado para la autentificacion de un abonado en una red de comunicacion, presentando el modulo de identidad de abonado un primer juego de datos de identidad de abonado para la autentificacion del abonado y al menos un segundo juego de datos de identidad de abonado para la autentificacion del abonado, diferenciandose el primer juego de datos de identidad de abonado del segundo juego de datos de identidad de abonado. Ademas, el modulo de identidad de abonado presenta un medio para la gestion del primer y segundo juegos de datos de identidad de abonado, realizandose la gestion mediante funciones de gestion estaticas. El procedimiento se caracteriza porque el medio para la gestion presenta ademas un codigo de aplicacion de gestion y este codigo de aplicacion de gestion posibilita una gestion variable mediante adaptacion de las funciones de gestion estaticas a los parametros de entorno del modulo de identidad de abonado.
El procedimiento segun la invencion se basa en la division del medio para la gestion de los datos de identidad de abonado en funciones de gestion estaticas y codigo de aplicacion de gestion variable, preferentemente codigo de aplicacion Java. A este respecto, las funciones de gestion estaticas estan implementadas de forma fija como componente del modulo de identidad de abonado. Para adaptar las funciones de gestion a la condicion ambiental correspondiente, estas se activan y ejecutan de forma variable segun la invencion a traves del codigo de aplicacion de gestion, preferentemente codigo de aplicacion Java. El codigo de aplicacion de gestion fija asi, por ejemplo, el instante real de la conmutacion para la conmutacion mediante funciones de conmutacion estaticas.
Como parametros de entorno se consideran segun la invencion todas las alteraciones y circunstancias en el entorno del modulo de identidad de abonado. A modo de ejemplo se mencionan parametros de red, indicaciones de estado de red, actualizaciones de archivos del modulo de identidad de abonado, parametros del terminal en el que es operativo el modulo de identidad de abonado.
Por funciones de gestion estaticas se entienden, en particular, funciones del sistema operativo y/o un codigo de programa implementado equiparable casi al sistema operativo. A este respecto se entiende, en particular, por funcion de conmutacion estatica la adaptacion del sistema de archivos al segundo juego de datos de identidad de abonado. Por funcion de gestion estatica se entiende, en particular, la sustitucion de los datos de autentificacion (tambien denominados terceto / quinteto) del primer juego de datos de identidad de abonado, por ejemplo el algoritmo de autentificacion A3, A5 y/o A8, asi como la clave de autentificacion Ki, por los datos de autentificacion correspondientes del segundo juego de datos de identidad de abonado. Por funcion de conmutacion estatica se entiende ademas, en particular, la sustitucion de una clave OTA especifica al abonado para la comunicacion OTA con la red de comunicacion. Por funcion de gestion estatica se entiende ademas en particular la sustitucion de aplicaciones especificas al abonado, por ejemplo, applets Java especificas de los datos de identidad de abonado. Las funciones de gestion estaticas estan previstas para la carga, la activacion, la conmutacion, la desactivacion y/o el borrado de los datos de identidad de abonado.
La gestion variable se realiza en particular a traves de primeras funciones del codigo de aplicacion de gestion. Estas funciones estan disenadas para evaluar individualmente parametros de la red de comunicacion, indicaciones de estado relativas a la red de comunicacion, al terminal y/o al modulo de identidad de abonado, las indicaciones de estado del terminal, asi como indicaciones de estado a traves de condiciones de entorno como ubicacion visitada, escenarios de roaming, etc. y adaptar el comportamiento de cada modulo de identidad de abonado y de los datos de identidad de abonado correspondientes. Por ejemplo, una primera funcion es la funcion “check_Network_Status” para la verificacion del registro principal en la primera o segunda red en funcion de los datos de identidad de abonado o para la verificacion de una perdida de la conexion de red pese al registro satisfactorio anterior en esta red. Por ejemplo, una primera funcion es la funcion “check_MCC” para la verificacion de la ubicacion visitada del modulo de identidad de abonado. Por ejemplo, una primera funcion es la funcion “set_waitingtime” para establecer un tiempo de espera individual para el modulo de identidad de abonado. Por ejemplo, una primera funcion es la funcion “check_Time-out” para la verificacion de la expiracion del tiempo de espera en el caso de un intento de registro sin exito o una falta de confirmacion de la red despues del registro realizado.
La gestion variable comprende, en particular, tambien la carga de otros juegos de datos de identidad de abonado en el modulo de identidad de abonado. A este respecto, mediante las primeras funciones se analiza el comando de carga, en particular, que mecanismo de carga especial esta implementado en el modulo de identidad de abonado y que mecanismo de carga se ha seleccionado por parte de la red. En base al analisis se inicializa luego el modulo de identidad de abonado mediante las primeras funciones, a fin de poder cargar correctamente los datos de identidad de abonado. Los datos confidenciales, como informaciones de autentificacion, claves de autentificacion, claves OTA y similares se instalan en el modulo de identidad de abonado por medio de las primeras funciones mediante una capa de seguridad adicional del estandar GSM 03.48.
5
10
15
20
25
30
35
40
45
50
55
60
65
La gestion variable tambien comprende, en particular, la activacion de los datos de identidad de abonado, es decir, de un juego de datos de identidad de abonado. La activacion es necesaria para poder usar los datos de identidad de abonado en el modulo de identidad de abonado para la autentificacion / identificacion del abonado en la red de comunicacion. Al hacer la activacion, el estado del juego de datos de identidad de abonado cambia de «nuevo» a «activado». Con la activacion se confirma, por un lado, la integridad de los datos del juego de datos de identidad de abonado. A este respecto, la integridad de los datos se verifica mediante las primeras funciones, en particular mediante una suma de comprobacion CRC. Los datos de identidad de abonado solo se activan si la suma de comprobacion CRC de los datos de identidad de abonado almacenados a activar es igual a una suma de comprobacion CRC enviada por la red y recibida por el modulo de identidad de abonado. Con la activacion se bloquea, por otro lado, el juego activado hasta ahora de los datos de identidad de abonado para otras actualizaciones del lado de red.
La gestion variable tambien comprende, en particular, la desactivacion de los datos de identidad de abonado, es decir, de un juego de datos de identidad de abonado. A este respecto, se emite un comando de desactivacion en el lado de red y se recibe por el modulo de identidad de abonado. Al desactivarlos los datos de identidad de abonado en el modulo de identidad de abonado ya no se pueden usar para una autentificacion / identificacion del abonado en la red de comunicacion. Al hacer la desactivacion, el estado de los datos de identidad de abonado, es decir, del juego de datos de identidad de abonado, cambia de «activado» a «desactivado». Antes de la desactivacion, las primeras funciones verifican el estado de los datos de identidad de abonado. Si el juego de datos de identidad de abonado a desactivar es el unico juego activado de datos de identidad de abonado en el modulo de identidad de abonado, la desactivacion se impide para seguir garantizando la comunicacion entre la red y el modulo de identidad de abonado.
La gestion variable tambien comprende, en particular, la conmutacion variable de primeros datos de identidad de abonado a segundos datos de identidad de abonado, es decir, de un primer juego de datos de identidad de abonado a un segundo juego de datos de identidad de abonado. A este respecto, en principio se pueden conmutar todos los juegos de datos de identidad de abonado contenidos en el modulo de identidad de abonado. Si, por ejemplo, estan presentes un primer, segundo y tercer juegos de datos de identidad de abonado en el modulo de identidad de abonado, se puede conmutar de forma flexible entre los tres datos de identidad de abonado, es decir, entre los tres juegos de datos de identidad de abonado. A este respecto, siempre estara activado solo el primer, el segundo o el tercer juego de datos de identidad de abonado.
La gestion variable tambien comprende en particular el borrado variable de datos de identidad de abonado. A este respecto, se libera el espacio de almacenamiento que se podra usar para la carga / almacenamiento de nuevos datos de identidad de abonado.
Un modulo de identidad de abonado, segun invencion, es un modulo de tamano y recursos escasos, que presenta un microcontrolador y al menos una interfaz de datos para la comunicacion con un terminal. Este modulo de identidad de abonado presenta un espacio de almacenamiento seguro, en el que los datos de identidad de abonado estan instalados de forma segura para impedir intentos de manipulacion y/o uso indebido durante la identificacion y/o autentificacion en la red. El modulo de identidad de abonado es operativo gracias al terminal.
El modulo de identidad de abonado es, por ejemplo, una tarjeta inteligente, UICC o tarjeta SIM, en una red de telefonia movil con datos de identidad de abonado legibles por una maquina y almacenados en un chip. Dichos modulos de identidad de abonado se operan en un terminal mediante unidades de lectura de tarjetas estando previstos, en particular, para poder extraerse del terminal para su sustitucion o para su uso en un segundo terminal.
Alternativamente, el modulo de identidad de abonado es un componente integral del terminal movil, por ejemplo, un modulo electronico cableado no reprogramable. Dichos modulos de identidad de abonado tambien se denominan UICC embebidos (embedded eUlCC eUlCC). Con ese diseno, estos modulos de identidad de abonado no estan previstos para una extraccion del terminal y en principio no se pueden sustituir de forma sencilla. Dichos modulos de identidad de abonado tambien pueden ser elementos de seguridad embebidos, embedded Secure Elements, es decir, componentes de hardware seguros en el terminal movil.
Alternativamente, el modulo de identidad de terminal es un modulo M2M. Estos modulos sirven para la supervision, control y mantenimiento remotos de terminales: maquinas, instalaciones y sistemas. Alternativamente, tambien se pueden usar para unidades de conteo, como contadores electricos o contadores de agua caliente.
Alternativamente, el modulo de identidad de abonado es un componente de software de una parte de confianza de un sistema operativo, un asi denominado entorno de ejecucion de confianza (Trusted Execution Environment, TEE) del terminal. En ese caso, el modulo de identidad de abonado esta incluido, por ejemplo, dentro de un entorno en tiempo de ejecucion protegido en forma de programas que se ejecutan en el, denominados Trustlets.
Los datos de identidad de abonado segun la invencion son, por un lado, los datos que identifican un abonado de forma univoca en la red de comunicacion, por ejemplo, la identidad internacional de abonado movil (International
5
10
15
20
25
30
35
40
45
50
55
60
65
Mobile Subscriber Identity, IMSI) y/o datos especificos al abonado. La IMSI es el dato de identidad de abonado unfvoco en una red de comunicacion de telefonia movil. Se compone del codigo de pais MCC (Mobile Country Code), el codigo de red MNC (Mobile Network Code) y un numero correlativo que da el operador de la red. Los datos de identidad de abonado comprenden adicionalmente indicaciones de estado, pudiendo ser el estado de los datos de identidad de abonado: «activo», «inactivo» y/o «usado».
Ademas, los datos de identidad de abonado pueden ser datos que autentifican un abonado de forma univoca en la red de comunicacion, por ejemplo, un algoritmo de autentificacion, parametros especificos del algoritmo, una clave criptografica de autentificacion y/o una clave criptografica por el aire (inalambrica) (Over-The-Air, OTA).
El numero de juegos de datos de identidad de abonado del modulo de identidad de abonado no esta limitado. Cabe imaginarse que en el futuro en un modulo de identidad de abonado esten presentes treinta o mas juegos de datos de identidad de abonado.
Un abonado segun la invencion es, por ejemplo, una persona que quiera acceder a los servicios de la red de comunicacion mediante el terminal. Por abonado tambien se puede entender un terminal en un entorno M2M.
Una red de comunicacion segun la invencion es un dispositivo tecnico en el que tiene lugar la transmision de senales tras la identificacion y/o autentificacion del abonado que realiza la comunicacion, mediante las que se ofrecen los servicios. La red de comunicacion esta desplegada preferiblemente por celdas de telefonia movil, dependiendo el tamano de una celda de radio de las condiciones meteorologicas y geograficas, asi como de las antenas de radio usadas. En particular, en esta invencion se entiende por red de telefonia movil, por ejemplo, el sistema global para comunicaciones moviles, Global System for Mobile Communications, abreviadamente GSM como tecnologia representativa de la segunda generacion o el servicio general de paquetes via radio, General Packet Radio Service, abreviadamente GPRS o sistema universal de telecomunicaciones moviles, Universal Mobile Telecommunications System, abreviadamente UMTS, como tecnologia representativa de la tercera generacion o la evolucion a largo plazo, Long Term Evolution, abreviadamente, LTE, como tecnologia representativa de la cuarta generacion.
En una realizacion preferida, el codigo de aplicacion de gestion se puede actualizar y/o intercambiar a traves de una interfaz por aire de la red de comunicacion. Mediante esta configuracion se mantiene el medio para la gestion en el estado mas actual y eventualmente tambien se puede adaptar a corto plazo, por ejemplo, en el marco de un escenario de roaming, a los nuevos parametros y condiciones. De este modo, tambien se puede adaptar a una modificacion de acuerdos de roaming. De este modo, tambien se puede adaptar a las modificaciones en el terminal, por ejemplo, en el marco de la actualizacion del sistema operativo del terminal.
En una realizacion preferida, las funciones de gestion estaticas son segundas funciones, accediendo las primeras funciones del codigo de aplicacion de gestion mediante una interfaz de programacion a estas segundas funciones. Por consiguiente, las segundas funciones implementadas de forma dura siempre son operativas y se pueden utilizar de forma adaptativa con la interfaz de programacion. La interfaz de programacion proporciona asi la funcionalidad para la gestion mediante las segundas funciones, mientras que las primeras funciones evaluan el comando de gestion correspondiente, supervisan el exito de la gestion y proyectan / aplican una estrategia de reconmutacion adaptativa. Los comandos de gestion son, en particular, el comando de carga para la carga de nuevos datos de identidad de abonado, el comando de activacion para la activacion de los datos de identidad de abonado, el comando de conmutacion para la conmutacion de los primeros a los segundos datos de identidad de abonado (es decir, de un primer juego de datos de identidad de abonado a un segundo juego de datos de identidad de abonado), el comando de desactivacion para la desactivacion de los datos de identidad de abonado y/o el comando de borrado para el borrado de los datos de identidad de abonado.
En una realizacion preferida, las primeras funciones comprenden la supervision de parametros de ubicacion actuales. Si cambia en particular la ubicacion visitada, lo que se indica a traves de un codigo de pais de red movil, Mobile Country Code, abreviadamente, MCC, de la red, el medio para la gestion tiene que esperar, en su caso, a la redireccion de los servicios de red que realiza la red de comunicacion visitada. En particular la conmutacion y reconmutacion a los (primeros) datos de identidad de abonado ocurriria con algun desfase temporal.
En una realizacion preferida, las primeras funciones comprenden la generacion de periodos de espera. Asi, en funcion de la disponibilidad de servicios de red se coordinan el borrado, activacion, desactivacion y/o conmutacion o reconmutacion, por lo que se evita una implementacion dura con conmutacion o reconmutacion, en su caso, temprana y resultando el proceso amigable para el usuario.
En una realizacion preferida, las primeras funciones comprenden la reconmutacion adaptativa entre el primer juego de datos de identidad de abonado y el segundo juego de datos de identidad de abonado. Las funciones de gestion estaticas preven una reconmutacion estatica si fracasase el registro en la nueva red con los datos de identidad de abonado conmutados. Por circunstancias de la red se desea realizar, eventualmente, la reconmutacion solo despues de la expiracion de un tiempo de espera definido. Para ello, una primera funcion se ocuparia de establecer un tiempo de espera en funcion de los parametros de red, asi como del nuevo analisis de la situacion de red tras la expiracion del tiempo de espera antes de que se reconmutara. La reconmutacion, entonces, seria en si parte de las segundas
5
10
15
20
25
30
35
40
45
50
55
60
65
funciones, el analisis, el establecimiento del tiempo de espera y el nuevo analisis son entonces parte de las primeras funciones.
En una realizacion de la invencion, las funciones de gestion variables comprenden la generacion de mensajes de confirmacion a peticion de la instancia de servidor remota.
En una realizacion alternativa, las primeras funciones comprenden la conmutacion adaptativa entre los primeros datos de identidad de abonado y los segundos datos de identidad de abonado, es decir, el primer juego de datos de identidad de abonado y el segundo juego de datos de identidad de abonado, iniciandose la conmutacion por la instancia de servidor remota mediante un comando de conmutacion. En este caso, se conmuta inmediatamente mediante funciones de gestion estaticas. Las primeras funciones verifican ahora el estado de la conmutacion dura, para reconmutar de nuevo cuando no se haya conectado, por ejemplo, con la red tras expirar un tiempo de espera predefinido. Si el segundo proveedor de red eliminase el segundo juego de datos de identidad de abonado de sus bases de datos, ya no seria posible un registro del modulo de identidad de abonado en la segunda red conmutada despues de la conmutacion dura. Las primeras funciones del codigo de aplicacion Java tienen adicionalmente una funcion para la reconmutacion a los datos de identidad de abonado validos mas recientes, por lo que se puede reconmutar al perfil de abonado valido mas reciente. Por consiguiente, el codigo de aplicacion de gestion variable para proteger los primeros datos de identidad de abonado los almacena y los marca como datos de identidad de abonado validos mas recientes.
El modulo de identidad de abonado tiene que reconmutarse luego al estado de partida, lo que se denomina en este documento reconmutacion. Si la reconmutacion la controlan las primeras funciones, se pueden examinar otros parametros de red para garantizar la reconmutacion.
Segun la invencion, el objetivo tambien se consigue mediante un procedimiento para la gestion de un modulo de identidad de abonado con un primer juego de datos de identidad de abonado y un segundo juego de datos de identidad de abonado. El procedimiento comprende las etapas de: obtencion de un comando de gestion en el modulo de identidad de abonado; gestion del primer juego de datos de identidad de abonado y del segundo juego de datos de identidad de abonado mediante el comando de gestion. El procedimiento se caracteriza porque antes de la etapa de la gestion se inicia el codigo de aplicacion de gestion en el modulo de identidad de abonado, porque tras la etapa de la gestion por el codigo de aplicacion de gestion se evaluan los parametros de red de comunicacion y porque en funcion de la evaluacion se adapta la etapa de gestion.
Ademas, segun la invencion esta previsto el uso de un modulo de identidad de abonado descrito anteriormente en un terminal de comunicacion movil para conseguir el objetivo planteado. A este respecto, el terminal de comunicacion esta configurado para hacer operativo el modulo de identidad de abonado.
Un terminal segun la invencion es en principio un aparato o un componente de aparato que presenta medios para la comunicacion con la red de comunicacion, a fin de poder usar los servicios de la red de comunicacion. Por ejemplo, el termino englobaria un terminal movil, como un Smartphone, una tableta, un ordenador portatil o una PDA. Por terminal tambien se puede entender, por ejemplo, terminales multimedia, como marcos de fotos digitales, equipos de audio, televisores o libros electronicos que presenten igualmente medios para la comunicacion con la red de comunicacion. Por ejemplo, el termino «terminal» tambien comprende cualquier tipo de maquinas, maquinas automaticas, vehiculos y dispositivos que presenten medios, en particular modems de telefonia movil, para la comunicacion con la red de comunicacion.
Ademas, segun la invencion esta previsto un sistema que se compone de al menos un modulo de identidad de abonado descrito anteriormente y una instancia de servidor remota, enviando la instancia de servidor remota al al menos un modulo de identidad de abonado un comando de gestion para la gestion de un primer juego de datos de identidad de abonado y de un segundo juego de datos de identidad de abonado en el modulo de identidad de abonado.
A continuacion se explican mas en detalle la invencion u otras formas de realizacion y ventajas adicionales de la invencion mediante las figuras, describiendo las figuras solo ejemplos de realizacion de la invencion. Los mismos componentes en las figuras tienen los mismos numeros de referencia. Las figuras no se deben considerar hechas a escala real; elementos individuales de las figuras pueden estar representados exageradamente grandes o exageradamente simplificados.
Muestran:
la figura 1 un diagrama de bloques de un modulo de identidad de abonado segun la invencion,
la figura 2 una representacion detallada de la jerarquia de programa y de datos en el modulo de identidad de abonado segun la invencion,
la figura 3 un perfil de abonado segun la invencion con datos de identidad de abonado,
5
10
15
20
25
30
35
40
45
50
55
60
65
la figura 4 un diagrama de flujo del procedimiento segun la invencion,
la figura 5 un esquema de un ciclo de vida de los datos de identidad de abonado, a modo de ejemplo.
En la figura 1 se representa un diagrama de bloques de un modulo de identidad de abonado -1-. El modulo de identidad de abonado -1- presenta una interfaz de datos -3-. Una unidad de computo central -4- conecta la interfaz de datos -3- con una memoria -2-, volatil (RAM) o no volatil (ROM, EEPROM, FLASH). En el espacio de almacenamiento -2-, en particular, en el espacio de almacenamiento no volatil, estan almacenados los perfiles de abonado -11- que contienen los datos de identidad de abonado o juegos de datos de identidad de abonado -13a, 13b, 13n-. De este modo, se pueden adaptar los datos de identidad de abonado -13a, 13b, 13n- para la red de comunicacion respectiva. En particular, resulta posible que los datos de identidad de abonado -13- se puedan instalar tras la comercializacion del modulo de identidad de abonado -1- al abonado, por ejemplo, via OTA u OTI, a traves de la interfaz de datos -3-, por lo que resulta posible un uso mas flexible del modulo -1-. En el espacio de almacenamiento -2- se instala ademas el sistema operativo -5-, con el que se puede hacer funcionar el modulo -1-. En la figura 2 esta representada una pila de capas, a modo de ejemplo, de la jerarquia de programa y de datos de un modulo de identidad de abonado -1- segun la invencion. En el espacio de almacenamiento -2- del modulo de identidad de abonado -1- esta instalado un sistema operativo -5-. El sistema operativo -5- accede a los recursos de hardware del modulo de identidad de abonado -1-. En el modulo de identidad de abonado -1- esta instalada a su vez una maquina virtual, en este caso una maquina virtual Java Card, abreviadamente JCVM. La JCVM a su vez facilita un entorno de tiempo de ejecucion -6-, tambien denominado JCRE. Dentro del JCRE esta configurado un espacio seguro -7-, en el que el creador del modulo puede incluir, en particular, una clave unica del modulo y aplicaciones unicas del modulo. Este espacio seguro -7- es inaccesible para los operadores de las redes de comunicacion. Ademas, en el JCRE estan implementadas funciones de gestion -8-. Estas funciones de gestion acceden a las interfaces de programacion tipicas de modulos de identidad de abonado, como la API de plataforma abierta, la SIM- API, USIM-APl y/o la API Java Card. Estas interfaces facilitan paquetes de funciones que utilizan los programas del modulo de identidad de abonado -1-.
Las funciones de gestion -8- son segundas funciones segun lo que se ha ido describiendo y sirven para desactivar un perfil activo, activar un perfil inactivo, borrar un perfil desactivado, cargar un nuevo perfil y/o conmutar entre perfiles. Estas segundas funciones son componentes fijos del modulo de identidad de abonado -1- y estan implementadas de forma que no se puedan modificar. La gestion mediante estas funciones de gestion estaticas -8- se realiza despues de introducir un comando de gestion S2 (vease la figura 4) desde una instancia de servidor remota y no es adaptativa en el estado de la tecnica actual. Sin embargo, esto es desfavorable en muchos casos o escenarios de uso, dado que segun el entorno hay que aplicar diferentes estrategias durante la gestion.
Por ejemplo, en algunos casos se debe hacer una conmutacion dura a los segundos datos de identidad de abonado -13b-, aunque se haya confirmado la cobertura de red en la nueva red para los segundos datos de identidad de abonado -13b-. El modulo de identidad de abonado -1 - no deberia aplicar entonces, a ser posible, ninguna estrategia de reconmutacion.
Alternativamente, se debe reconmutar (S11) a veces inmediatamente a los primeros datos de identidad de abonado -13a-, cuando no se ha confirmado la cobertura de red S7 en la nueva red. En este caso se deberia realizar una reconmutacion lo antes posible para facilitarle al usuario un acceso lo mas rapido posible.
En otros casos, solo se debe intentar durante un tiempo el registro en la nueva red (S7 en conjuncion con S8, S9) antes de que se reconmute (S10, S11).
Para posibilitar estas gestiones adaptativas, segun la invencion se proporciona un codigo de aplicacion de gestion -9-, preferentemente en forma de codigo de aplicacion Java o un applet Java. Este codigo de aplicacion de gestion -9- presenta primeras funciones que se pueden sustituir, cargar a posteriori y/o actualizar, al contrario que las segundas funciones -8-, durante el ciclo de vida del modulo de identidad de abonado -1 -. Para ello se usa o bien una interfaz por aire (OTA) o bien una interfaz basada en internet (OTI), introduciendose el codigo de aplicacion de gestion -9- cargado a posteriori o actualizado a traves de la interfaz de datos -3- en el espacio de almacenamiento -2-.
El codigo de aplicacion de gestion -9- esta programado de forma individual. El codigo de aplicacion de gestion -9- presenta en particular las siguientes primeras funciones:
- recepcion y evaluacion del comando de gestion de la instancia remota (etapa S4 en la figura 4);
- supervision de la gestion iniciada;
- supervision de los parametros de red MCC, MNC (etapa S7 de la figura 4) y generacion de informacion de gestion a partir de estos parametros;
5
10
15
20
25
30
35
40
45
50
55
60
65
- implementacion de una estrategia de retorno adaptativa (etapa S10 de la figura 4);
- facilitacion de penodos de espera durante la conmutacion (etapas S8, S9 de la figura 4).
Para que el codigo de aplicacion de gestion -9- pueda modificar las segundas funciones de gestion (estaticas) -8-, esta prevista una interfaz de programacion -10- adicional, una API de gestion. Esta activa las verdaderas funciones de gestion -8-, en particular la conmutacion entre los primeros datos de identidad de abonado -13a- y los segundos datos de identidad de abonado -13b-, la carga de los datos de identidad de abonado -13-, la activacion / desactivacion de datos de identidad de abonado -13- y el borrado de datos de identidad de abonado -13-.
El codigo de aplicacion de gestion -9- accede asf a traves de la interfaz de programacion -10- a las funciones de gestion estaticas -8-, que acceden a su vez directamente al sistema operativo -5-, representado mediante flechas. Gracias a esta estructura es posible una gestion mas flexible, asf como la implementacion de estrategias de gestion alternativas, segun se describe de forma mas detallada a continuacion al comentar la figura 4.
El modulo de identidad de abonado -1- representado en la figura 2 tiene una multiplicidad de perfiles de abonado -11-. Cada perfil de identidad de abonado -11- de la figura 2 contiene los datos de identidad de abonado -13a, 13b, 13n- (o un juego de datos de identidad de abonado), que identifican y/o autentifican de forma unfvoca un abonado en redes de comunicacion iguales y/o diferentes. Con dichos modulos de identidad de abonado -1- ya no es forzosamente necesario que un operador de una red genere un nuevo modulo de identidad de abonado -1- para la identificacion y autentificacion de un abonado en su red por contrato y lo entregue al abonado en forma de tarjeta SIM. En lugar de ello, el operador de red crea un perfil -11- en base al contrato. El perfil -11- se carga entonces en el modulo de identidad de abonado -1- ya instalado en el terminal y pudiendo coexistir con otros perfiles -11-. De este modo, resulta que el modulo de identidad de abonado -1- ya no hace falta que sea desacoplable del terminal, en lugar de ello, los modulos de identidad de abonado -1 - pueden tener un cableado fijo abreviadamente eUlCCs, en el terminal. Esto ahorra espacio en el terminal, por lo que se pueden implementar otras funcionalidades en el sin tener que aumentar el diseno del terminal. El procedimiento segun la invencion se debe aplicar en particular a eUlCC, dado que aquf un usuario no tiene por que cambiar el modulo de identidad de abonado -1- a fin de poder usar los servicios de red de un contrato alternativo.
En la figura 3 esta representado mas en detalle un perfil de abonado -11a-. El perfil -11a- presenta un espacio seguro -111- para el operador de red. El espacio seguro -111- se puede diferenciar del espacio seguro -7-. Ademas, un perfil tiene codigo de aplicacion -112- especffico para el, asf como un sistema de archivos -113- especffico para dicho perfil tambien. Cada perfil -11- puede estar activo o inactivo, por modulo de identidad de abonado -1- siempre esta activo solo un perfil -11-, es decir, los datos de identidad de abonado -13- del perfil -11- activo se usan para autentificar y/o identificar a un abonado en una red de comunicacion. Solo se pueden conmutar perfiles -11- activos. En principio todos los perfiles son validos y pueden estar asociados todos a un mismo o a diferentes operadores de red.
Para cada perfil esta prevista una clave de perfil propia. Solo los perfiles -11- activados estan implicados en la seguridad del operador de red. El codigo de aplicacion de gestion -9- gestiona estos espacios seguros y actualiza las claves correspondientes.
En una realizacion del modulo de identidad de abonado -1- todos los datos y parametros necesarios para un perfil se almacenan en el perfil. La gestion de los datos / parametros se realiza mediante funciones variables, es decir, el codigo de aplicacion de gestion -9-.
Los datos de identidad de abonado -13- segun la figura 2 comprenden en particular una indicacion sobre el algoritmo de autentificacion usado en el operador de la red (Comp 128-1, Comp 128-2, Comp 128-3, Milenage), la identidad internacional del abonado movil (International Mobile Subscriber Identity, IMSI), las claves de autorizacion criptograficas usadas para la autentificacion, los ajustes de parametros del algoritmo utilizado, en su caso, las claves OTA especfficas del operador de red para posibilitar una comunicacion OTA segura, datos especfficos del abonado, como nombre, apellido, numero de DNI, fecha de nacimiento, lugar de nacimiento, etc.; y/o en su caso datos adicionales, especfficos del operador de red, por ejemplo que servicios estan habilitados en la red correspondiente para el abonado, que algoritmos de backup estan disponibles y similares. Este listado no es en ningun caso exhaustivo y en otras realizaciones alternativas tambien pueden comprender menos, mas u otros datos.
En la figura 4 esta representado un diagrama de flujo de un procedimiento segun la invencion. En este caso, se parte de que el perfil -13a- esta activado y de que se ha usado el primer juego de datos de identidad de abonado -11a- para autentificar el abonado en la primera red. En la etapa S2 se recibe un comando de gestion, que es un comando de conmutacion, de una instancia remota, un gestor de subscripcion, Subscription Manager a traves de la primera red de comunicacion por la interfaz de datos -3-. Con dicho comando de conmutacion S2 se inicia el codigo de aplicacion de gestion -9- en la etapa S3.
En la etapa siguiente S4 se realiza el analisis del comando de conmutacion, en particular de los parametros del comando de conmutacion. Los parametros pueden ser: conmutacion dura sin cobertura de red; conmutacion solo si
5
10
15
20
25
30
35
40
45
50
55
60
65
la nueva red esta disponible; conmutacion solo cuando en la red este disponible un servicio determinado u otros casos similares. A continuacion, en la etapa S5 se realiza la conmutacion a los segundos datos de identidad de abonado -13b-. A este respecto, el perfil -11- se desactiva y se activa el segundo perfil -11b-. Con los segundos datos de identidad de abonado -13b- del segundo perfil -11b- activado, el modulo de identidad de abonado -1- intenta registrarse en una nueva red de comunicacion. Para la etapa S5 se usa la API de conmutacion 10 a fin de acceder a las funciones de gestion estaticas -8-.
En la etapa S6 el codigo de aplicacion de gestion -9- supervisa si la nueva red esta disponible. Si la nueva red esta disponible (caso: si), el procedimiento queda finalizado, a menos que los parametros segun el analisis de la etapa S4 impongan un tratamiento alternativo, no estando representado ese caso en la figura. Si la nueva red no esta disponible (caso: no, en la etapa S6) se realiza un analisis de los parametros de red en la etapa S7. En particular se realiza la supervision de los parametros MNC y MCC, una verificacion del archivo EF_Loci, en su caso, la verificacion del archivo EF_FPLMN y otros similares. Adicionalmente tambien se verifican parametros relativos al terminal, en particular, si el terminal ya estaba listo para la conmutacion o no.
En funcion del analisis de las etapas S4 y S7 se decide entonces en la etapa S8 si se debe ajustar un tiempo de espera. Este tiempo de espera proporciona, por ejemplo, durante un escenario de roaming el lapso de tiempo requerido hasta que la nueva red permite una autentificacion mediante los segundos datos de identidad de abonado -13b-. Si en la etapa S8 se necesita un tiempo de espera (caso: si), se verifica si ha expirado en la etapa S9. Luego se prosigue con la etapa S10. Si en la etapa S8 no se necesita un tiempo de espera (caso: no) se prosigue igualmente con la etapa S10, a saber, en la que se hace una consulta sobre si es necesaria una estrategia de retorno en funcion de las etapas S4 y S7. Si se necesita una estrategia de retorno (caso: si en la etapa S10) se realiza una reconmutacion al primer perfil -13a- segun la API de gestion -10- y las funciones de gestion -8-. Si no se necesita una estrategia de retorno (caso: no en la etapa S10), entonces se vuelve a la etapa S6 y de nuevo se evalua la disponibilidad de red y se hace un analisis de los parametros segun la etapa 7.
Si en el ciclo de vida del modulo de identidad de abonado -1- una estrategia de gestion resultase muy prometedora, por ejemplo, el ajuste de un tiempo de espera determinado debido a las circunstancias del terminal con el que el modulo de identidad de abonado se comunica mediante la interfaz de datos -3-, entonces esta estrategia se puede aplicar como estrategia estandar.
Alternativamente, tambien es posible complementar o actualizar el codigo de aplicacion de gestion -9-, a fin de adaptar el modulo de identidad de abonado -1- a condiciones de red modificadas y disenar una conmutacion mas flexible debido a ello.
Alternativamente, tambien es posible sustituir completamente el codigo de aplicacion de gestion -9-, a fin de poder adaptar el modulo de identidad de abonado -1- a condiciones de red modificadas y disenar una conmutacion mas flexible debido a ello.
Una parte esencial de las funciones variables, es decir, del codigo de aplicacion de gestion -9-, es la generacion de mensajes de confirmacion para la instancia de servidor remota. Un mensaje de confirmacion se genera, por ejemplo, cuando el modulo de identidad de abonado ha conseguido registrarse de forma satisfactoria en la red usando los datos de identidad de abonado -13- conmutados. Un mensaje de confirmacion se genera, por ejemplo, cuando el modulo de identidad de abonado no ha conseguido registrarse de forma satisfactoria en la red usando los datos de identidad de abonado -13- conmutados. Un mensaje de confirmacion se genera, por ejemplo, cuando la red ha enviado una consulta al modulo de identidad de abonado. Consultas de este tipo son, en particular, consultas del estado de red, informaciones de emplazamiento y/o informaciones de estado relativas a los perfiles de abonado -11-, generandose las confirmaciones mediante las funciones variables, es decir, el codigo de aplicacion de gestion -9-.
La estrategia de gestion tambien puede prever que los mensajes de confirmacion se le envien a la instancia de red por comandos de gestion, iniciados por la red, solo tras expirar un tiempo de espera, a fin de poder retrasar eventualmente los siguientes comandos de gestion de la red.
En una variante no representada en las figuras, el codigo de aplicacion de gestion -9- aplica automaticamente un perfil de seguridad -11- antes de la recepcion del comando de conmutacion S2, siendo el perfil de seguridad -11- igual al perfil de abonado -11- activado. Si se recibe un comando de conmutacion S2 de la instancia remota en el modulo de identidad de abonado -1- y se requiere una conmutacion S5 inmediata a los segundos datos de identidad de abonado -13b-, se garantiza que sea posible en cualquier momento una reconmutacion S11 a los primeros datos de identidad de abonado -13a- almacenados en el perfil de seguridad -11-.
En la figura 5 esta representado el ciclo de vida de los datos de identidad de abonado -13-, es decir, de un juego de datos de identidad de abonado -13-, en un modulo de identidad de abonado -1-. Todo el ciclo de vida se gestiona mediante el codigo de aplicacion de gestion -9- y las funciones de gestion estaticas -8-, en donde segun la invencion el codigo de aplicacion de gestion -9- controla de forma variable la gestion, es decir, las segundas funciones. A este respecto, los datos de identidad de abonado -13- se almacenan en respuesta a un comando de carga en el espacio de almacenamiento -2- del modulo de identidad de abonado -1-. El comando de carga puede variar en funcion del
5
10
15
20
25
30
35
mecanismo de carga, de modo que el codigo de aplicacion de gestion -9- variable gestiona de forma adaptativa el modulo de identidad de abonado -1-. Los datos de identidad de abonado -13- se activan mediante el comando de activacion. A este respecto, una suma de comprobacion CRC de los datos de identidad de abonado -13- cargados se compara con una suma de comprobacion CRC proporcionada por la red antes de la activacion. En caso de coincidencia de las sumas de comprobacion, se activan los datos de identidad de abonado -13-. Desde este instante se pueden usar en el modulo de identidad de abonado -1-, por ejemplo, mediante el comando de conmutacion S2 se puede conmutar a estos datos de identidad de abonado -13-. A este respecto, el codigo de aplicacion de gestion -9- verifica si los datos de identidad de abonado -13- tambien estan activados para una conmutacion e impide la conmutacion a datos de identidad de abonado inactivos. Si los datos de identidad de abonado -13- ya no han de poder usarse para una autentificacion / identificacion del abonado en una red, estos se pueden desactivar mediante un comando de desactivacion. Finalmente, los datos de identidad de abonado -13- se pueden borrar mediante un comando de borrado, mediante lo cual el espacio de almacenamiento -2- del modulo de identidad de abonado puede usarse para nuevos datos de identidad de abonado -13-.
Todo el modulo de identidad de abonado -1- se puede desactivar cuando se desactivan y/o borran los ultimos datos de identidad de abonado que queden (es decir, el ultimo juego de datos de identidad de abonado que hubiere) -13-. Dicha desactivacion del modulo -1- se puede impedir mediante el codigo de aplicacion de gestion -9- variable.
Lista de numeros de referencia
1 Modulo de identidad de abonado
2 Espacio de almacenamiento
3 Interfaz de datos
4 Unidad de computo
5 Sistema operativo
6 Entorno de tiempo de ejecucion virtual, JCRE
7 Espacio seguro del fabricante del modulo
8 Funciones de gestion fijas
9 Codigo de aplicacion de gestion Java variable
10 Interfaz de programacion de gestion
11 a,b,n Perfiles de abonado, huecos de insercion de abonado
111 Espacio seguro del perfil
112 Codigo de aplicacion individual al perfil
113 Sistema de archivos individual del perfil, datos de identidad de abonado 13a,b,n Juegos de datos de identidad de abonado
S1 -S12 Etapas del procedimiento

Claims (14)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    REIVINDICACIONES
    1. Modulo de identidad de abonado (1) para la autentificacion de un abonado en una red de comunicacion, en el que el modulo de identidad de abonado (1) presenta:
    - un primer juego de datos de identidad de abonado (13a) para la autentificacion del abonado;
    - al menos un segundo juego de datos de identidad de abonado (13b) para la autentificacion del abonado, en el que el primer juego de datos de identidad de abonado (13a) se diferencia del segundo juego de datos de identidad de abonado (13b); y
    - un medio para la gestion del primer juego de datos de identidad de abonado (13a) y del segundo juego de datos de identidad de abonado (13b), en el que la gestion se realiza mediante funciones de gestion estaticas (8);
    caracterizado porque
    - el medio para la gestion presenta ademas un codigo de aplicacion de gestion (9) y este codigo de aplicacion de gestion (9) posibilita una gestion variable mediante adaptacion de las funciones de gestion estaticas a los parametros de entorno del modulo de identidad de abonado (1).
  2. 2. Modulo de identidad de abonado (1) segun la reivindicacion 1, en el que el codigo de aplicacion de gestion (9) comprende primeras funciones (S6, S7, S8, S9, S10, S11), mediante las que es posible una conmutacion variable entre el primer juego de datos de identidad de abonado (13a) y el segundo juego de datos de identidad de abonado (13b).
  3. 3. Modulo de identidad de abonado (1) segun una de las reivindicaciones anteriores, en el que el codigo de aplicacion de gestion (9) se puede actualizar y/o sustituir a traves de una interfaz por aire de la red de comunicacion.
  4. 4. Modulo de identidad de abonado (1) segun una de las reivindicaciones anteriores, en el que las funciones de gestion estaticas (8) son segundas funciones y en el que las primeras funciones (S6, S7, S8, S9, S10, S11) del codigo de aplicacion de gestion (9) acceden a estas segundas funciones mediante una interfaz de programacion (10).
  5. 5. Modulo de identidad de abonado (1) segun una de las reivindicaciones anteriores, en el que las primeras funciones (S6, S7, S8, S9, S10, S11) comprenden una supervision de parametros de emplazamiento (S7) actuales.
  6. 6. Modulo de identidad de abonado segun una de las reivindicaciones anteriores, en el que las primeras funciones (S6, S7, S8, S9, S10, S11) comprenden una generacion de periodos de espera (S8, S9).
  7. 7. Modulo de identidad de abonado (1) segun una de las reivindicaciones anteriores, en el que las primeras funciones (S6, S7, S8, S9, S10, S11) comprenden una reconmutacion (S11) adaptativa a los primeros datos de identidad de abonado (13a).
  8. 8. Modulo de identidad de abonado (1) segun una de las reivindicaciones anteriores, en el que las funciones de gestion estaticas (8) son funciones de conmutacion para la conmutacion de los primeros datos de identidad de abonado (13a) a los segundos datos de identidad de abonado (13b).
  9. 9. Modulo de identidad de abonado (1) segun una de las reivindicaciones anteriores, en el que el codigo de aplicacion de gestion (9) es codigo de aplicacion Java.
  10. 10. Procedimiento para la gestion de un modulo de identidad de abonado (1) con un primer juego de datos de identidad de abonado (13a) y un segundo juego de datos de identidad de abonado (13b), con las etapas de:
    - recepcion (S1) de un comando de gestion en el modulo de identidad de abonado (1);
    - gestion (S5) del primer juego de datos de identidad de abonado (13a) y del segundo juego de datos de identidad de abonado (13b) mediante el comando de gestion;
    caracterizado porque
    - antes de la etapa de la gestion (S5) se inicia (S3) un codigo de aplicacion de gestion (9) en el modulo de identidad de abonado (1);
    - despues de la etapa de la gestion (S5) realizada por el codigo de aplicacion de gestion (9) se evaluan (S6, S8, S9, S10, S11) los parametros de red de comunicacion (S7); y
    - en funcion de la evaluacion (S6, S8, S9, S10, S11) se adapta (S11) la etapa de la gestion (S5) para adaptar la funcion de gestion estatica a los parametros de entorno del modulo de identidad de abonado (1).
  11. 11. Procedimiento segun la reivindicacion 10, en el que el codigo de aplicacion de gestion (9) accede a las funciones 5 de gestion estaticas (8) del modulo de identidad de abonado (1) a traves de una interfaz de programacion de gestion
    (10) para la etapa de la gestion (S5, S11).
  12. 12. Procedimiento segun una de las reivindicaciones 10 u 11, en el que la evaluacion (S6, S7, S8, S9, S10, S11) comprende el analisis del emplazamiento (S7).
    10
  13. 13. Procedimiento segun una de las reivindicaciones anteriores 10 a 12, en el que la gestion comprende tanto la conmutacion, la carga, la activacion, la desactivacion, asi como el borrado de los datos de identidad de abonado (13).
    15 14. Uso de un modulo de identidad de abonado (1) segun las reivindicaciones 1 a 9 en un terminal de comunicacion
    movil.
  14. 15. Sistema compuesto por el al menos un modulo de identidad de abonado (1) segun las reivindicaciones 1 a 9 y una instancia remota, en el que la instancia remota envia un comando de conmutacion (S2) al al menos un modulo 20 de identidad de abonado (1) para la conmutacion (S5) de un primer juego de datos de identidad de abonado (13a) a un segundo juego de datos de identidad de abonado (13b).
ES13752837.8T 2012-09-19 2013-08-22 Módulo de identidad para la autentificación de un abonado en una red de comunicación Active ES2620028T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE102012018540 2012-09-19
DE102012018540.5A DE102012018540A1 (de) 2012-09-19 2012-09-19 Teilnehmeridentitätsmodul zum Authentisieren eines Teilnehmers an einem Kommunikationsnetzwerk
PCT/EP2013/002529 WO2014044348A1 (de) 2012-09-19 2013-08-22 Teilnehmeridentitätsmodul zum authentisieren eines teilnehmers an einem kommunikationsnetzwerk

Publications (1)

Publication Number Publication Date
ES2620028T3 true ES2620028T3 (es) 2017-06-27

Family

ID=49034045

Family Applications (1)

Application Number Title Priority Date Filing Date
ES13752837.8T Active ES2620028T3 (es) 2012-09-19 2013-08-22 Módulo de identidad para la autentificación de un abonado en una red de comunicación

Country Status (6)

Country Link
US (1) US9451461B2 (es)
EP (1) EP2898714B1 (es)
DE (1) DE102012018540A1 (es)
ES (1) ES2620028T3 (es)
PL (1) PL2898714T3 (es)
WO (1) WO2014044348A1 (es)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102012015573A1 (de) * 2012-08-07 2014-02-13 Giesecke & Devrient Gmbh Verfahren zum Aktivieren eines Betriebssystems in einem Sicherheitsmodul
DE102012025085A1 (de) 2012-12-20 2014-07-10 Giesecke & Devrient Gmbh Teilnehmeridentitätsmodul und Verfahren zum Betreiben eines Teilnehmeridentitätsmoduls
CN105723760B (zh) * 2013-11-19 2020-09-04 瑞典爱立信有限公司 简档改变管理
US9585022B2 (en) * 2013-11-19 2017-02-28 Telefonaktiebolaget Lm Ericsson (Publ) Profile integration management
FR3019432B1 (fr) * 2014-03-25 2017-06-09 Mohamed Nabil Ghouthi Dispositif garantissant, entre deux usagers sur des reseaux mobiles, l'anonymat, la protection contre la geolocalisation, et la protection de leurs echanges de donnees sur ces reseaux
DE102014008267A1 (de) * 2014-06-06 2015-12-17 Giesecke & Devrient Gmbh Verfahren und Vorrichtungen zum Verwalten von Subskriptionen auf einem Sicherheitselement
US9843674B2 (en) * 2014-09-24 2017-12-12 Oracle International Corporation Managing selection and triggering of applications on a card computing device
KR102248694B1 (ko) * 2014-12-02 2021-05-07 삼성전자주식회사 프로파일을 관리하는 방법과 이를 지원하는 전자 장치
DE102014019089A1 (de) * 2014-12-18 2016-06-23 Giesecke & Devrient Gmbh Verfahren zum Verwalten einer Anzahl von Subskriptionen eines Mobilfunknetzbetreibers auf einem Sicherheitselement
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
DE102015001815A1 (de) 2015-02-13 2016-08-18 Giesecke & Devrient Gmbh Teilnehmeridentitätsmodul
KR102227262B1 (ko) * 2015-02-17 2021-03-15 삼성전자주식회사 프로파일을 전달하는 방법과 이를 지원하는 전자 장치
US10785645B2 (en) * 2015-02-23 2020-09-22 Apple Inc. Techniques for dynamically supporting different authentication algorithms
DE102015003977A1 (de) 2015-03-26 2016-09-29 Giesecke & Devrient Gmbh Verfahren zum Laden eines Profils
DE102015008179A1 (de) 2015-06-25 2016-12-29 Giesecke & Devrient Gmbh Kommunizieren eines Teilnehmeridentitätsmoduls zu einem Server, insbesondere bei Profilwechsel
FR3039738B1 (fr) 2015-07-28 2018-06-22 Idemia France Procede de gestion d'un profil enregistre dans un element securise, et element securise correspondant
DE102015012181A1 (de) * 2015-09-16 2017-03-16 Giesecke & Devrient Gmbh Verfahren zum Handhaben einer Subskriptionshistorie
DE102015015734B3 (de) 2015-12-01 2017-06-01 Giesecke & Devrient Gmbh Teilnehmeridentitätsmodul mit mehreren Profilen und eingerichtet für ein Authenticate-Kommando
CN107046529B (zh) * 2017-01-05 2020-03-24 同济大学 一种基于hash加密的车路协同安全通信方法
IT201700057287A1 (it) * 2017-05-26 2018-11-26 St Microelectronics Srl Procedimento per gestire schede a circuito integrato, scheda ed apparecchiatura corrispondenti
DE102017009314A1 (de) * 2017-10-06 2019-04-11 Giesecke+Devrient Mobile Security Gmbh Chipset mit verteilten SIM-Funktionalitäten und Applikationen, für Mobilfunknetzwerk mit Netzwerkparameter wie Frequenzband oder Protokoll
DE102019001840B3 (de) 2019-03-15 2020-04-23 Giesecke+Devrient Mobile Security Gmbh Verfahren zum bereitstellen von subskriptions-profilen, teilnehmeridentitätsmodul und subskriptions-server
FR3113753B1 (fr) * 2020-08-25 2023-05-12 Idemia France Procédé de vérification d’une carte à microcircuit, procédé de personnalisation d’une carte à microcircuit, carte à microcircuit et dispositif électronique associé

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6591116B1 (en) * 1999-06-07 2003-07-08 Nokia Mobile Phones Limited Mobile equipment and networks providing selection between USIM/SIM dependent features
JP3884432B2 (ja) * 2001-07-18 2007-02-21 トゲヴァ・ホールディング・アクチェンゲゼルシャフト 電気通信方法、識別モジュール、およびコンピュータ化サービスユニット
WO2003100647A1 (en) 2002-05-21 2003-12-04 Russell Jesse E An advanced multi-network client device for wideband multimedia access to private and public wireless networks
US7613480B2 (en) * 2003-12-31 2009-11-03 At&T Mobility Ii Llc Multiple subscription subscriber identity module (SIM) card
CN1661960B (zh) 2004-02-27 2010-04-07 北京三星通信技术研究有限公司 一种利用cave作为接入认证算法的机卡分离的认证方法以及装置
DE102004015536A1 (de) * 2004-03-30 2005-10-27 O2 (Germany) Gmbh & Co. Ohg Telekommunikationssystem für den Mobilfunk, Verfahren zum Betrieb eines Telekommunikationssystems für den Mobilfunk sowie Teilnehmerkarte zum Einsatz in mobilen Endgeräten für den Mobilfunk
US7644272B2 (en) * 2004-10-22 2010-01-05 Broadcom Corporation Systems and methods for providing security to different functions
US20080020755A1 (en) * 2006-05-16 2008-01-24 Mino Holdings, Inc. Method and system for international roaming using virtual sim card
US20080081609A1 (en) * 2006-09-29 2008-04-03 Motorola, Inc. Method and system for associating a user profile to a sim card
GB0807976D0 (en) * 2008-05-01 2008-06-11 Romalon Plc Improvements relating to multi-jurisdictional telecommunications services
FR2941585B1 (fr) 2009-01-28 2013-04-12 Plugnsurf Dispositif portatif de communication multi-reseaux
FR2949285B1 (fr) * 2009-08-21 2012-05-04 Kwok Kuen Cheng Procede et dispositif permettant la gestion optimale d'appels entre des reseaux de telephonie mobile cellulaire nationaux.
GB0916852D0 (en) * 2009-09-25 2009-11-11 Newton Alan R Extension socket drive
US20110246317A1 (en) * 2009-10-23 2011-10-06 Apriva, Llc System and device for facilitating a transaction through use of a proxy account code
CN102598732B (zh) * 2009-11-13 2016-11-23 瑞典爱立信有限公司 附连到接入网络
US8874167B2 (en) 2009-11-17 2014-10-28 Broadcom Corporation Method and system for multi-standby operation for a multi-SIM multi-standby communication device
US8505081B2 (en) * 2010-01-29 2013-08-06 Qualcomm Incorporated Method and apparatus for identity reuse for communications devices
US8996002B2 (en) * 2010-06-14 2015-03-31 Apple Inc. Apparatus and methods for provisioning subscriber identity data in a wireless network
GB2494710B (en) * 2011-09-19 2015-06-24 Truphone Ltd Managing mobile device identities
DE102012016166A1 (de) 2012-08-14 2014-02-20 Giesecke & Devrient Gmbh Verfahren zum Betreiben eines Teilnehmeridentitätsmoduls

Also Published As

Publication number Publication date
PL2898714T3 (pl) 2017-08-31
EP2898714B1 (de) 2016-12-28
US9451461B2 (en) 2016-09-20
DE102012018540A1 (de) 2014-03-20
EP2898714A1 (de) 2015-07-29
WO2014044348A1 (de) 2014-03-27
US20150281957A1 (en) 2015-10-01

Similar Documents

Publication Publication Date Title
ES2620028T3 (es) Módulo de identidad para la autentificación de un abonado en una red de comunicación
US10244074B2 (en) Method and apparatus for receiving profile by terminal in mobile communication system
US9788209B2 (en) Apparatus and methods for controlling distribution of electronic access clients
EP3099045B1 (en) Method for managing a plurality of profiles in a sim module, and corresponding uicc or embedded uicc, and computer program product
US11032713B2 (en) Method and electronic device for providing communication service
EP2704053B1 (en) Method and system for updating a firmware of a security module
KR101504855B1 (ko) 단말에 포함된 uicc에 포함된 데이터를 보안 서버 상에 내보내기 위한 방법
US9439076B2 (en) Method for incorporating subscriber identity data into a subscriber identity module
US9198026B2 (en) SIM lock for multi-SIM environment
ES2607782T3 (es) Procedimiento y dispositivo para proporcionar un elemento seguro con un perfil de suscripción
US20080003980A1 (en) Subsidy-controlled handset device via a sim card using asymmetric verification and method thereof
US9924357B2 (en) Method for providing mobile communication provider information and device for performing same
WO2015018533A1 (en) Methods and devices for performing a mobile network switch
CN102340750A (zh) 一种对手机隐私空间的密码取回的方法
ES2702061T3 (es) Operación de un módulo de identificación de abonado
ES2925180T3 (es) Configuración de un módulo de identidad de abonado incorporado
EP2315464B1 (en) Modification of a secured parameter in a user identification module
US8656457B2 (en) Controlling locking state transitions in a terminal
KR20160088356A (ko) 보안 소자 상의 서브스크립션들을 관리하는 장치들 및 방법