ES2925180T3 - Configuración de un módulo de identidad de abonado incorporado - Google Patents

Configuración de un módulo de identidad de abonado incorporado Download PDF

Info

Publication number
ES2925180T3
ES2925180T3 ES19159268T ES19159268T ES2925180T3 ES 2925180 T3 ES2925180 T3 ES 2925180T3 ES 19159268 T ES19159268 T ES 19159268T ES 19159268 T ES19159268 T ES 19159268T ES 2925180 T3 ES2925180 T3 ES 2925180T3
Authority
ES
Spain
Prior art keywords
data
user data
operating system
update
criterion
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
ES19159268T
Other languages
English (en)
Inventor
Aurélien Raboisson
Jérôme Dumoulin
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.)
Idemia France SAS
Original Assignee
Idemia 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 Idemia France SAS filed Critical Idemia France SAS
Application granted granted Critical
Publication of ES2925180T3 publication Critical patent/ES2925180T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0644—Management of space entities, e.g. partitions, extents, pools
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • 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/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Software Systems (AREA)
  • Databases & Information Systems (AREA)
  • Telephone Function (AREA)
  • Storage Device Security (AREA)

Abstract

La invención propone un módulo de identidad de abonado embarcado (2), que comprende: una primera zona de memoria (Z1) para almacenar un sistema operativo (OS1); una segunda área de memoria (Z2) para almacenar datos de usuario (DT) accesibles por el sistema operativo (OS1); una tercera área de memoria (Z3) para almacenar un modelo de datos (MD) que define al menos un criterio (CT) que deben cumplir los datos de usuario (DT) contenidos en la segunda área de memoria (Z2); comprendiendo además el módulo de identidad de abonado a bordo: un módulo de determinación (8) configurado para determinar si dichos datos de usuario (DT) cumplen con dicho al menos un criterio; y un módulo de procesamiento (10) configurado para provocar la ejecución de al menos una primera acción predeterminada, definida en el modelo de datos (MD), si dichos datos de usuario (DT) no se ajustan a dicho al menos un criterio. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Configuración de un módulo de identidad de abonado incorporado
Antecedentes de la invención
La invención está relacionada con el campo de las telecomunicaciones y se refiere, más particularmente, a los módulos de identidad de abonado incorporados (normalmente, un chip electrónico o una tarjeta inteligente), también llamados elementos seguros o SE, usados en un terminal y que permiten, por ejemplo, albergar aplicaciones y datos de manera segura en un entorno de confianza.
Un módulo de identidad de abonado incorporado en un terminal de telecomunicaciones puede adoptar varias formas y, en particular, presentar diversos factores de forma (formatos). De este modo, un módulo de identidad de abonado incorporado puede presentarse en forma de una tarjeta SIM (o UICC, por “ Universal Integrated Circuit Card” ) o de una tarjeta eSIM (por “embedded SIM” ), también llamada eUICC. Otro ejemplo de elemento seguro es un elemento seguro incorporado, denominado eSE (por “embedded Secure Element” ), que, generalmente, está soldado al terminal huésped.
A continuación, por motivos de simplificación de presentación, los principios de la invención se describen en el contexto de una tarjeta SIM. Esto no constituye, de ninguna manera, una limitación, pudiendo aplicarse los principios de la invención a los diferentes tipos de elementos seguros (por ejemplo, tarjeta SIM, eSIM, eUICC, SE, eSE o combinación de elementos seguros).
La invención se refiere, concretamente, a la configuración de un módulo de identidad de abonado, incorporado con el fin de evitar la aparición de errores o de fallos.
De manera conocida, una tarjeta SIM puede comprender en memoria, datos de usuario (claves, identificadores, etc.), también llamados datos de abonado, accesibles por el sistema operativo de dicha tarjeta. El sistema operativo puede leer los datos de usuario durante el funcionamiento de la tarjeta SIM, por ejemplo, para recuperar el identificador IMSI (por “ International Mobile Subscriber Identity” ) del usuario en una red móvil.
Por otro lado, se conoce actualizar el sistema operativo de una tarjeta SIM, con el fin, por ejemplo, de mejorar el sistema operativo, suprimir fallos o añadir nuevas funcionalidades. No obstante, una actualización de este tipo es susceptible de generar problemas en el funcionamiento de la tarjeta SIM.
En efecto, es posible que el sistema operativo, una vez actualizado, requiera un formato o un tipo diferente del de los datos de usuario que están realmente almacenados en memoria en la tarjeta SIM. Tras una actualización, los datos de usuario presentes en la tarjeta SIM pueden no ser ya compatibles con los que se esperan actualmente por el sistema operativo, lo cual corre el riesgo de plantear problemas de funcionamiento y generar errores.
A título de ejemplo, una actualización puede configurar el sistema operativo de una tarjeta SIM, de manera que espere leer un octeto complementario en un archivo de configuración almacenado en los datos de usuario de dicha tarjeta. Si este octeto no está presente durante la lectura del archivo, esto puede presentar un obstáculo durante la configuración del sistema operativo. Según otro ejemplo, si una actualización del sistema operativo de la tarjeta SIM prevé la adición de una funcionalidad, esta última no podrá ponerse en práctica por el sistema operativo si los archivos necesarios no están presentes en los datos de usuario, lo cual puede generar errores y degradar el funcionamiento de la tarjeta SIM.
Existe una necesidad de aliviar los problemas e inconvenientes mencionados en este documento, que son susceptibles de encontrarse por cualquier módulo de identidad de abonado incorporado, tal como una tarjeta SIM, eSIM, eUICC, eSE u otro.
El documento EP 2.448.216 A1 trata sobre la gestión de un módulo de eUICC, en donde puede cargarse una eSIM para permitir la autenticación de un usuario ante una red de comunicación. En particular, este documento describe la posibilidad de actualizar un sistema operativo en un módulo de eUICC.
El documento EP 3.023.904 A1 se centra en la preparación de una secuencia de comandos que va a enviarse a un elemento seguro que incluye un almacenamiento local de datos de propiedades de archivo, para proporcionar un perfil al elemento seguro.
El documento US-9.053.107 B1 divulga un procedimiento para determinar actualizaciones de archivos a partir de una organización de los archivos en diferentes bloques en un dispositivo de almacenamiento.
Objeto y sumario de la invención
Tal como se explicó anteriormente, pueden aparecer problemas en una tarjeta SIM, concretamente, cuando se actualiza su sistema operativo, en la medida en que una actualización de este tipo puede modificar el formato o el tipo de los datos de usuario requeridos por el sistema operativo para funcionar de manera apropiada.
Ahora bien, durante una actualización de este tipo, del sistema operativo, los datos de usuario susceptibles de almacenarse en memoria en la tarjeta SIM, no se modifican por la actualización. Generalmente, el acceso a los datos de usuario durante una actualización del sistema operativo no es posible por motivos, concretamente, de derechos de acceso y de confidencialidad. La invención se define por las reivindicaciones adjuntas.
Por tanto, una actualización de una tarjeta SIM puede tener como consecuencia que los datos de usuario, almacenados en dicha tarjeta, ya no sean compatibles con el sistema operativo, una vez actualizado este último. Por tanto, la invención se dirige a configurar un módulo de identidad de abonado incorporado, tal como una tarjeta SIM, un módulo de eUICC u otro, de manera que su sistema operativo pueda funcionar de manera apropiada, en particular, cuando se ha realizado una actualización del sistema operativo (pero no de los datos de usuario). Dicho de otro modo, la invención permite evitar que se produzcan errores, concretamente, tras una actualización del sistema operativo de un módulo de identidad de abonado incorporado, debido a una incompatibilidad entre el sistema operativo y los datos de usuario.
Para ello, la presente invención se refiere a un módulo de identidad de abonado incorporado, que comprende:
- una primera zona de memoria, configurada para grabar en memoria un sistema operativo; y
- una segunda zona de memoria, configurada para grabar en memoria datos de usuario accesibles por el sistema operativo;
comprendiendo el módulo de identidad de abonado incorporado, además:
- una tercera zona de memoria, distinta de las zonas de memoria primera y segunda, configurada para grabar en memoria un modelo de datos que define al menos un criterio que deben satisfacer los datos de usuario contenidos en la segunda zona de memoria;
- un módulo de determinación, configurado para determinar si dichos datos de usuario son conformes a dicho al menos un criterio; y
- un módulo de procesamiento, configurado para provocar la ejecución de al menos una primera acción predeterminada, definida en el modelo de datos, si dichos datos de usuario no son conformes a dicho al menos un criterio.
Según un modo de realización particular, el módulo de determinación está configurado para determinar si dichos datos de usuario son conformes a dicho al menos un criterio, al detectarse que se ha actualizado el sistema operativo. Dicho de otro modo, el módulo de determinación procede a dicha determinación, en respuesta a una detección de actualización del sistema operativo.
Según un modo de realización particular, el módulo de identidad de abonado incorporado está configurado, si dichos datos de usuario no son conformes a dicho al menos un criterio, para:
- consultar, en la tercera zona de memoria, el modelo de datos, con el fin de determinar dicha al menos una primera acción predeterminada; y
- provocar la ejecución, por el sistema operativo, de dicha al menos una primera acción predeterminada. Según un modo de realización particular, el sistema operativo está configurado, si dichos datos de usuarios son conformes a dicho al menos un criterio, para ejecutar al menos una segunda acción predeterminada, diferente de dicha primera acción predeterminada.
Según un modo de realización particular, dicha al menos una segunda acción predeterminada está definida en el modelo de datos, en asociación con dichos datos de usuarios.
Según un modo de realización particular, dicha al menos una segunda acción predeterminada no está definida en el modelo de datos.
Según un modo de realización particular, dicha al menos una segunda acción predeterminada no se ejecuta por el sistema operativo.
Según un modo de realización particular, dicha al menos una segunda acción predeterminada no modifica los datos de usuario.
Según un modo de realización, no se realiza ninguna consulta del modelo de datos, para determinar dicha al menos una segunda acción predeterminada. Dicha al menos una segunda acción se especifica, por ejemplo, en el sistema operativo.
Según un modo de realización particular, dicho al menos un criterio comprende al menos uno de entre:
- un tipo de dato predeterminado;
- una longitud o un formato predeterminado de una cadena de bits/bytes de datos;
- una posición de bits/bytes predeterminada en una cadena de bits/bytes de datos;
- una condición de presencia (dato realmente presente o no en memoria) que indica si deben estar presentes o no datos de usuario en la segunda zona de memoria;
- una ubicación (por ejemplo, una dirección de memoria) en la segunda zona de memoria;
- un valor;
- un umbral;
- un valor de contenido;
- un estado predeterminado de datos.
La lista de criterios presentada anteriormente es a título ilustrativo y no es de ninguna manera limitativa. El experto en la técnica podría usar otros tipos de criterios.
Según un modo de realización particular, el modelo de datos define una pluralidad de criterios que deben satisfacer los datos de usuarios,
estando el módulo de determinación, configurado para determinar si los datos de usuarios son conformes a cada uno de dichos criterios,
estando el módulo de procesamiento, configurado para realizar al menos dicha al menos una primera acción predeterminada, definida en el modelo de datos, si dichos datos de usuarios no son conformes a al menos uno de dichos criterios.
Según un modo de realización particular, el módulo de identidad de abonado incorporado comprende un módulo de actualización configurado para:
- recibir una orden de actualización que comprende primeros datos de actualización referentes al sistema operativo, en asociación con segundos datos de actualización referentes al modelo de datos; y
- actualizar el sistema operativo a partir de los primeros datos de actualización y para actualizar el modelo de datos a partir de los segundos datos de actualización.
Según un modo de realización, el módulo de determinación está configurado para determinar si dichos datos de usuarios presentes en la segunda zona de memoria, son conformes a dicho al menos un criterio definido en el modelo de datos, una vez actualizado dicho modelo de datos (es decir, en respuesta a la actualización del modelo de datos) a partir de los segundos datos de actualización. En un ejemplo particular, esta verificación realizada por el módulo de determinación se realiza en la totalidad de los datos de usuarios presentes en la segunda zona de memoria.
Según un modo de realización particular, el módulo de determinación está configurado para determinar si dichos datos de usuarios presentes en la segunda zona de memoria, son conformes a dicho al menos un criterio definido en el modelo de datos, una vez actualizado el sistema operativo (es decir, en respuesta a la actualización del sistema operativo) a partir de los primeros datos de actualización. En un ejemplo particular, esta verificación realizada por el módulo de determinación se realiza en la totalidad de los datos de usuarios presentes en la segunda zona de memoria, una vez actualizado el sistema operativo.
Según un modo de realización particular, el módulo de determinación está configurado para determinar si dichos datos de usuarios presentes en la segunda zona de memoria, son conformes a dicho al menos un criterio definido en el modelo de datos, una vez que se han actualizado el sistema operativo y el modelo de datos, respectivamente, a partir de los primeros datos de actualización y segundos datos de actualización (es decir, en respuesta a estas dos actualizaciones). En un ejemplo particular, esta verificación realizada por el módulo de determinación se realiza en la totalidad de los datos de usuarios presentes en la segunda zona de memoria, una vez que se han actualizado el sistema operativo y el modelo de datos.
Según un modo de realización, la invención se pone en práctica por medio de componentes de software y/o de hardware. En este sentido, el término “módulo” puede corresponder en este documento tanto a un componente de software como a un componente de hardware o a un conjunto de componentes de hardware y de software.
La invención se dirige, igualmente, a un procedimiento de procesamiento puesto en práctica por un módulo de identidad de abonado incorporado, que incluye:
- una primera zona de memoria, en donde está grabado un sistema operativo;
- una segunda zona de memoria, en donde están grabados datos de usuario accesibles por el sistema operativo;
- una tercera zona de memoria, distinta de las zonas de memoria primera y segunda, en donde está grabado un modelo de datos que define al menos un criterio que deben satisfacer los datos de usuario contenidos en la segunda zona de memoria;
comprendiendo el procedimiento las siguientes etapas:
- determinar si dichos datos de usuario son conformes a dicho al menos un criterio definido en el modelo de datos; y
- desencadenar la ejecución de al menos una primera acción predeterminada, definida en el modelo de datos, si dichos datos de usuario no son conformes a dicho al menos un criterio.
Debe observarse que los diferentes modos de realización mencionados anteriormente con respecto al módulo de identidad de abonado incorporado de la invención, así como las ventajas asociadas, se aplican de manera análoga al procedimiento de procesamiento de la invención.
Según un modo de realización, el procedimiento comprende:
- una actualización del sistema operativo, en la primera zona de memoria,
- en donde dicha determinación de si los datos de usuario son conformes a dicho al menos un criterio definido en el modelo de datos, se realiza al detectarse que se ha actualizado el sistema operativo.
Según un modo de realización, la etapa de desencadenamiento comprende, si dichos datos de usuario no son conformes a dicho al menos un criterio:
- consultar, en la tercera zona de memoria, el modelo de datos, para determinar dicha al menos una primera acción predeterminada; y
- desencadenar la ejecución, por el sistema operativo, de dicha al menos una primera acción predeterminada.
Según un modo de realización, el procedimiento es tal que, si dichos datos de usuarios son conformes a dicho al menos un criterio, el sistema operativo ejecuta al menos una segunda acción predeterminada, diferente de dicha primera acción predeterminada.
Según un modo de realización, el procedimiento comprende una consulta del modelo de datos para determinar dicha al menos una segunda acción predeterminada definida en el modelo de datos en asociación con dichos datos de usuarios.
Según un modo de realización, no se realiza ninguna consulta del modelo de datos para determinar dicha al menos una segunda acción predeterminada ejecutada por el sistema operativo.
Según un modo de realización, dicha al menos una segunda acción predeterminada no se ejecuta por el sistema operativo.
Según un modo de realización particular, dicha al menos una segunda acción predeterminada no modifica dichos datos de usuario.
Según un modo de realización, dicha determinación de si dichos datos de usuario son conformes a dicho al menos un criterio definido en el modelo de datos, se realiza al detectarse que se ha actualizado el modelo de datos a partir de los segundos datos de actualización.
Según un modo de realización, dicho al menos un criterio comprende al menos uno de entre:
- un tipo de dato predeterminado;
- una longitud o un formato predeterminado de una cadena de bits/bytes de datos;
- una posición de bits/bytes predeterminada en una cadena de bits/bytes de datos;
- una condición de presencia (dato realmente presente o no en memoria) que indica que deben estar presentes o no datos de usuarios en la segunda zona de memoria;
- una ubicación (por ejemplo, dirección de memoria) en la segunda zona de memoria;
- un valor;
- un umbral;
- un valor de contenido; y
- un estado predeterminado de datos.
La lista de criterios anterior se presenta a título ilustrativo y no es de ninguna manera limitativa. El experto en la técnica podría usar otros tipos de criterios.
Según un modo de realización, el procedimiento comprende, además, las siguientes etapas:
- recibir una orden de actualización, que comprende primeros datos de actualización referentes al sistema operativo, en asociación con segundos datos de actualización referentes al modelo de datos; y
- actualizar el sistema operativo a partir de los primeros datos de actualización y actualizar el modelo de datos a partir de los segundos datos de actualización.
Según un modo de realización particular, dicha determinación de si dichos datos de usuario son conformes a dicho al menos un criterio definido en el modelo de datos, se realiza al detectarse que se ha actualizado el modelo de datos a partir de los segundos datos de actualización. Esta determinación se centra, por ejemplo, en todos los datos de usuarios presentes en la segunda zona de memoria.
Según un modo de realización, la etapa de determinación de si dichos datos de usuarios presentes en la segunda zona de memoria son conformes a dicho al menos un criterio definido en el modelo de datos, se realiza en respuesta a la actualización del sistema operativo a partir de los primeros datos de actualización. En un ejemplo particular, esta etapa de determinación se realiza en la totalidad de los datos de usuarios presentes en la segunda zona de memoria, una vez actualizado el sistema operativo.
Según un modo de realización, la etapa de determinación de si dichos datos de usuarios presentes en la segunda zona de memoria son conformes a dicho al menos un criterio definido en el modelo de datos, se realiza en respuesta a la actualización del sistema operativo y del modelo de datos, a partir, respectivamente, de los primeros datos de actualización y de los segundos datos de actualización. En un ejemplo particular, esta etapa de determinación se realiza en la totalidad de los datos de usuarios presentes en la segunda zona de memoria, una vez que se han actualizado el sistema operativo y el modelo de datos.
En un modo de realización particular, las diferentes etapas del procedimiento de procesamiento se determinan mediante instrucciones de programas de ordenador.
Por consiguiente, la invención también se dirige a un programa de ordenador en un soporte de información (o soporte de grabación), siendo este programa susceptible de ponerse en práctica en un módulo de identidad de abonado incorporado, tal como una tarjeta SIM o un módulo de eUICC, o, más generalmente, en un ordenador, incluyendo este programa instrucciones adaptadas para la puesta en práctica de las etapas de un procedimiento de procesamiento, tal como se definió anteriormente.
Este programa puede utilizar cualquier lenguaje de programación y presentarse en forma de código fuente, código objeto o de código intermedio entre código fuente y código objeto, tal como en una forma parcialmente compilada, o en cualquier otra forma deseable.
La invención también se dirige a un soporte de información (o soporte de grabación) legible por un ordenador y que incluye instrucciones de un programa de ordenador, tal como se mencionó anteriormente.
El soporte de información puede ser cualquier entidad o dispositivo que pueda almacenar el programa. El soporte puede incluir un medio de almacenamiento, tal como una ROM o una memoria Flash, por ejemplo.
Por otra parte, el soporte de información puede ser un soporte transmisible, tal como una señal eléctrica u óptica, que pueda dirigirse a través de un cable eléctrico u óptico, por radio o mediante otros medios. En particular, el programa según la invención, puede descargarse en una red de tipo Internet.
Como alternativa, el soporte de información puede ser un circuito integrado, en donde está incorporado el programa, estando el circuito adaptado para ejecutar o para usarse en la ejecución del procedimiento en cuestión.
Breve descripción de los dibujos
Otras características y ventajas de la presente invención se desprenderán de la descripción realizada a continuación, con referencia a los dibujos adjuntos que ilustran ejemplos de realización de la misma desprovistos de cualquier carácter limitativo. En las figuras:
- la Figura 1 representa esquemáticamente un módulo de identidad de abonado incorporado;
- la Figura 2 representa, en forma de un diagrama, las etapas de un procedimiento de procesamiento según un modo de realización particular de la invención;
- la Figura 3 representa esquemáticamente datos de usuarios almacenados en memoria en un módulo de identidad de abonado incorporado, según un modo de realización particular de la invención;
- la Figura 4 representa esquemáticamente un modelo de datos, según un modo de realización particular de la invención;
- la Figura 5 representa, en forma de un diagrama, las etapas de un procedimiento de procesamiento según un modo de realización particular de la invención; y
- la Figura 6 representa, en forma de un diagrama, las etapas de un procedimiento de procesamiento según un modo de realización particular de la invención.
Descripción detallada de varios modos de realización
De manera conocida, un módulo de identidad de abonado incorporado, tal como una tarjeta SIM (por “Subscriber Identity Module” ), por ejemplo, es un dispositivo electrónico que contiene un microcontrolador y una memoria, que puede usarse en telefonía móvil para almacenar informaciones específicas de un abonado de una red móvil, concretamente, para redes de GSM, UMTS y LTE, por ejemplo. Un módulo de identidad de abonado incorporado permite, igualmente, almacenar datos y aplicaciones del usuario, de su operador o, en determinados casos, de terceros.
Un módulo de identidad de abonado incorporado permite que un terminal de comunicación móvil (tal como un teléfono móvil, por ejemplo), con el que actúa conjuntamente, use la red de comunicación móvil de un único operador de telefonía. Para ello, el módulo de identidad de abonado incorporado comprende datos de abono como, por ejemplo, un identificador IMSI (por “ International Mobile Subscriber Identity”), claves criptográficas o incluso algoritmos atribuidos por el operador de la red móvil.
La tarjeta SIM, que puede presentar diversos factores de forma (formatos), constituye un ejemplo de módulo de identidad de abonado incorporado, en el sentido de la invención, que se caracteriza, concretamente, porque es amovible con respecto a su terminal huésped. Otros módulos de identidad de abonado incorporados, en el sentido de la invención, pueden ser fijos o estar integrados en el terminal huésped, como es el caso de las tarjetas SIM incorporadas (denominadas, tarjetas eSIM o tarjetas eUICC), o incluso para los eSE, ya mencionados anteriormente. El uso de las tarjetas eSIM se ha desarrollado desde hace algunos años. Estos módulos reprogramables permiten que un usuario cambie de operador sin tener que sustituir físicamente la tarjeta SIM en el teléfono móvil. Las principales especificaciones de un módulo de eUICC se definen por el grupo GSM A (por “ Global System for Mobile Communications Association” ) en la norma GSMA SGP.02 v3.2, titulada “ Remote Provisioning Architecture for Embedded UICC - Technical Specification - Version 3.2”, del 27 de junio de 2017, y en la 1a norma GSMA SGP.22 v2.2, titulada “ RSP Technical Specification - Versión 2.2", del 1 de septiembre de 2017. Un módulo de eUlCC es un elemento de hardware seguro, generalmente, de pequeño tamaño, que puede integrarse en un terminal de comunicación (en un terminal móvil, por ejemplo) con el fin de poner en práctica las funciones de una tarjeta SIM tradicional. En este documento, se describen ejemplos de puesta en práctica de la invención, en el contexto de una tarjeta SIM. No obstante, se comprende que la invención puede aplicarse, más generalmente, a cualquier módulo de identidad de abonado incorporado, tal como una tarjeta SIM, un módulo de eUICC (o eSIM) o, incluso, un eSE, por ejemplo, como ya se explicó anteriormente.
La invención propone configurar un módulo de identidad de abonado incorporado, de manera que se evite que se produzcan errores o fallos, concretamente, tras la actualización de su sistema operativo. Para ello, la invención, según diferentes modos de realización, pone en práctica un módulo de identidad de abonado incorporado, que almacena en memoria un modelo de datos que permite al sistema operativo determinar si los datos de usuarios que son accesibles para el mismo en la memoria de dicho módulo, son conformes o no a lo que se espera por el sistema operativo, y que permite al sistema operativo comportarse de manera apropiada cuando no es así.
Salvo que se indique lo contrario, los elementos comunes o análogos a varias figuras, llevan los mismos signos de referencia y presentan características idénticas o análogas, de manera que, generalmente, estos elementos comunes no se describen de nuevo por motivos de simplicidad.
La Figura 1 representa esquemáticamente la estructura de un módulo 2 de identidad de abonado incorporado, según un modo de realización particular. En este ejemplo, este módulo 2 es una tarjeta SIM, aunque otros ejemplos sean posibles.
Se supone que esta tarjeta SIM 2 está destinada, por ejemplo, a incorporarse en un terminal móvil (no representado en la figura), tal como un teléfono móvil de tipo teléfono inteligente, por ejemplo, de manera que se permite a un usuario autenticarse ante una red móvil. De este modo, el terminal móvil puede actuar conjuntamente con la tarjeta SIM 2, con el fin de acceder a las funcionalidades (y/o servicios) puestas a disposición por la red móvil del operador en cuestión. La estructura del terminal móvil y de la red móvil no se describe en detalle en este ejemplo de realización, en la medida en que no resulta útil para la comprensión del principio de la invención.
Como se representa en la Figura 1, la tarjeta SIM 2 comprende un procesador 4, una primera memoria M1 no volátil, una segunda memoria M2 no volátil y una interfaz 6 de comunicación.
La interfaz 6 de comunicación está configurada para permitir a la tarjeta SIM 2 comunicarse con el exterior, en particular, en este caso, con un terminal de telecomunicaciones móvil (no representado), en donde puede incorporarse la tarjeta SIM.
La memoria M1 no volátil comprende, en este ejemplo, tres zonas de memoria distintas, a saber: una primera zona Z1 de memoria, una segunda zona Z2 de memoria y una tercera zona Z3 de memoria. La primera zona Z1 de memoria está configurada para grabar en memoria (es decir, almacenar) un sistema operativo, u OS, indicado OS1. La segunda memoria Z2 está configurada para grabar en memoria datos DT de usuario accesibles por el sistema operativo OS1. Finalmente, la tercera zona Z3 de memoria está configurada para grabar en memoria un modelo MD de datos que se describe posteriormente.
La memoria M1 es, por ejemplo, una memoria no volátil regrabable, de tipo Flash, EEPROM u otro. Aunque las zonas Z1 a Z3 de memoria se representan, en este caso, en una misma memoria M1, se comprende que estas zonas de memoria pueden estar formadas en memorias (o dispositivos de memoria) distintas. De manera general, una zona de memoria, en el sentido de la invención, puede ser una memoria denominada lógica y/o física. A título de ejemplo, las zonas Z1, Z2 y Z3 de memoria, en el sentido de la invención, pueden corresponder, cada una, a una dirección específica en el interior de una sola y misma memoria física (componente). Alternativamente, cada una de las zonas Z1, Z2 y Z3 de memoria, en el sentido de la invención, puede estar en una memoria física diferente. Según otra variante, las zonas Z1, Z2 y Z3 de memoria, en el sentido de la invención, pueden corresponder a 2 direcciones de memoria distintas en el interior de una misma partición, y a una tercera dirección en el interior de otra partición, o bien, incluso, a una mezcla de configuraciones posibles entre memoria lógica y/o física (componente).
El procesador 4 controla el funcionamiento de la tarjeta SIM 2, actuando conjuntamente con los otros componentes internos de la tarjeta SIM. En particular, el procesador 4, que pone en práctica el sistema operativo OS1, accede a los datos necesarios en las zonas Z2 y Z3 de memoria.
Los datos DT de usuarios (también llamados, datos de abonado) que están almacenados en la segunda zona Z2 de memoria, pueden ser cualquier dato propio de un usuario de la tarjeta SIM 2. Los datos de usuario pueden comprender, por ejemplo, al menos uno de entre: un identificador de IMSI (por “ International Mobile Subscriber Identity” ), al menos una clave criptográfica y al menos un algoritmo, atribuyéndose todos estos elementos por un operador de una red móvil, al usuario de la tarjeta SIM 2.
Cuando un terminal de comunicación móvil intenta usar los servicios de una red móvil, puede enviar los datos de usuario almacenados en la tarjeta SIM 2, que son necesarios para que el operador de la red permita el acceso a los servicios requeridos. De este modo, el operador puede autenticar al usuario y verificar, con la ayuda de una base de datos de HLR (por “ Home Location Register” ), que el mismo esté realmente abonado al servicio solicitado.
Como se describe posteriormente, los datos DT de usuarios almacenados en la segunda zona Z2 de memoria, pueden comprender, por ejemplo, metadatos que caracterizan a dichos datos DT, por ejemplo, en cuanto a formato y/o tipo, tamaño o longitud, posición o incluso estado (encriptado/no encriptado, etc.).
El modelo MD de datos, almacenado en la tercera zona Z3 de memoria, está constituido por un conjunto de informaciones que caracterizan a los datos DT de usuarios almacenados (o supuestamente almacenados) en la segunda zona Z2 de memoria. El modelo MD de datos permite, por ejemplo, al sistema operativo OS1 determinar qué tipo y/o formato deben respetar, en teoría, los datos DT de usuarios presentes en la zona Z2 de memoria. Para ello, el modelo MD de datos define al menos un criterio que deben respetar la totalidad o parte de los datos DT de usuario. Estos criterios definen en qué formas deben presentarse los datos DT de usuario para que el sistema operativo OS1 pueda leerlos y usarlos correctamente. Este criterio comprende, por ejemplo, al menos una característica (tipo, formato, posición, estado, ...) que deben respetar un o unos datos DT de usuarios.
En un modo de realización particular, los datos DT de usuario están situados en una memoria, de tipo seguro o no, fuera del módulo de identidad de abonado incorporado, por ejemplo, en una memoria del terminal de telecomunicación móvil, en donde está incorporado el módulo de identidad de abonado incorporado o incluso en un servidor remoto.
La invención se basa en el principio de que los datos DT de usuario no se presentan, necesariamente, en la forma requerida por el sistema operativo OS1, para un funcionamiento normal u óptimo. Esta situación puede producirse, concretamente, tras una actualización del sistema operativo OS1, en la medida en que una actualización de este tipo es susceptible de modificar, concretamente, el formato de datos requerido por el sistema operativo, para un funcionamiento apropiado. En determinados casos, el tipo, formato, estado, longitud, presencia, ubicación y/o posición de los datos DT de usuario, no son conformes a lo que espera el sistema operativo OS1. Como se describe posteriormente, este modelo MD de datos permite al sistema operativo OS1 detectar cuándo los datos DT de usuario no son conformes a lo que se espera, y permite, además, al sistema operativo OS1 reaccionar de manera apropiada cuando se produce una situación de este tipo.
Como se representa en la Figura 1, la tarjeta SIM 2 está configurada, por ejemplo, para recibir, por medio de su interfaz 6 de comunicación, una orden CMD1 de actualización, destinada a actualizar el sistema operativo OS1 de la tarjeta SIM 2. Como se indica a continuación, la orden CMD1 de actualización puede incluir primeros datos UP1 de actualización referentes al sistema operativo OS1, en asociación con segundos datos UP2 de actualización referentes al modelo MD de datos. Estos datos UP1 y UP2 permiten, respectivamente, actualizar el sistema operativo OS1 y el modelo MD de datos, en las zonas de memoria correspondientes de la tarjeta SIM 2.
Por otro lado, la memoria M2 es una memoria no volátil regrabable o una memoria de sólo lectura (ROM), constituyendo esta memoria un soporte de grabación (o soporte de información), según un modo de realización particular, legible por la tarjeta SIM 2, y en donde está grabado un programa PG1 de ordenador, según un modo de realización particular. Este programa PG1 de ordenador incluye instrucciones para la ejecución de las etapas de un procedimiento de procesamiento, según un modo de realización particular, como se describe, a continuación, en el presente documento, en ejemplos particulares.
Como se representa en la Figura 1, el procesador 4 controlado por el programa PG1 de ordenador pone, en este caso, en práctica un módulo 8 de determinación y un módulo 10 de procesamiento.
El módulo 8 de determinación está configurado para determinar si los datos DT de usuario, almacenados en la segunda zona Z2 de memoria, son conformes a al menos un criterio definido en el modelo MD de datos.
El módulo 10 de procesamiento está configurado para provocar la ejecución de al menos una primera acción predeterminada, definida en el modelo MD de datos, si la totalidad o parte de los datos DT de usuario no son conformes a dicho al menos un criterio.
El funcionamiento de la tarjeta SIM 2 y, concretamente, de los módulos 8 y 10 mencionados anteriormente, se desprenderá, más precisamente, de los ejemplos de realización descritos a continuación, con referencia a las Figuras 3-6. Se comprenderá que los módulos 8 y 10, tales como se representan en la Figura 1, solo representan un ejemplo de puesta en práctica, no limitativo de la invención.
Debe observarse, igualmente, que determinados elementos, generalmente presentes en una tarjeta SIM, se han omitido voluntariamente, dado que no son necesarios para la comprensión de la presente invención.
Ahora se describen las etapas de un procedimiento de procesamiento, según un modo de realización particular de la invención, con referencia a la Figura 2. Este procedimiento se pone en práctica por la tarjeta SIM 2 y, más particularmente, por el procesador 4 que ejecuta el programa PG1 de ordenador. El procedimiento de procesamiento comprende las siguientes etapas:
- determinar (S2) si los datos DT de usuario almacenados en la zona Z2 de memoria son conformes a al menos un criterio CT definido en el modelo MD de datos; y
- desencadenar (S4) la ejecución de al menos una primera acción predeterminada AT1, definida en el modelo MD de datos en asociación con los datos DT de usuario en cuestión, si dichos datos DT de usuario no son conformes a dicho al menos un criterio.
Dicho de otro modo, la tarjeta SIM 2 verifica en S2 si la totalidad o parte de los datos DT de usuario son conformes a al menos un criterio CT definido en el modelo MD de datos y, en caso de no conformidad, la tarjeta SIM 2 ejecuta al menos una primera acción AT1, definida para ello en el modelo MD de datos. La o las primeras acciones AT1 desencadenadas de este modo, pueden ser cualesquiera, y pueden estar adaptadas según el caso de uso.
Las etapas S2 y S4 anteriormente citadas, se realizan, por ejemplo, después de que se haya actualizado el sistema operativo OS1, por ejemplo, en respuesta a una orden CMD1 de actualización (Figura 1). Las etapas S2 y S4 se realizan, por ejemplo, por la tarjeta SIM 2, al detectarse que se ha actualizado el sistema operativo OS1.
Dicha primera acción predeterminada AT1 comprende, por ejemplo, una modificación predeterminada de los datos DT de usuario no conformes.
Un objetivo de la invención, en este ejemplo, es permitir al sistema operativo OS1 reaccionar de manera apropiada cuando los datos DT de usuario presentes en la zona Z2 de memoria no están (o ya no están) en la forma esperada, por ejemplo, debido a una actualización del sistema operativo OS2, como ya se explicó anteriormente.
La invención permite, ventajosamente, evitar que se produzcan errores o fallos cuando el sistema operativo OS1 de la tarjeta SIM 2 accede, en la zona Z2 de memoria, a datos DT de usuario que no se encuentran en la forma esperada o requerida por dicho sistema operativo OS1.
Ahora se describe la puesta en práctica de un procedimiento de procesamiento, según un modo de realización particular, con referencia a las Figuras 3-5. Este procedimiento se pone en práctica por la tarjeta SIM 2, representada en la Figura 1, y, más particularmente, por el procesador 4 que ejecuta el programa PG1 de ordenador.
Se supone que, como se representa en la Figura 3, los datos DT de usuarios almacenados en la segunda zona Z2 de memoria, comprenden, en este caso, los datos DT1, DT2 y DT3. Los datos DT1, DT2 y DT3 de usuario presentan características respectivas CR1, CR2 y CR3 (llamadas colectivamente, CR). Estas características definen, por ejemplo, el formato, tipo, longitud, posición, ubicación, presencia y/o estado (encriptado/no encriptado, por ejemplo) de los datos de usuario correspondientes. En un ejemplo particular, las características CR1-CR3 de los datos DT1-DT3 de usuario, son accesibles por el sistema operativo OS1 en la forma de metadatos almacenados en la segunda zona Z2 de memoria, en asociación con los datos DT de usuarios correspondientes. Los datos DT de usuario almacenados en la zona Z2 de memoria comprenden, por ejemplo, cada uno de los metadatos que caracterizan el tipo y/o el formato de datos, el tamaño o longitud de los datos, el estado encriptado/no encriptado, la posición, la ubicación, la presencia, etc.
Debe observarse que, en los ejemplos previstos en este documento, cada uno de los datos DT1, DT2 y DT3 de usuario (Figura 3) puede comprender cualquier cantidad de datos. La naturaleza del contenido de estos datos puede variar, igualmente, según el caso, como ya se explicó.
Se supone, además, como se representa en la Figura 4, que el modelo MD de datos almacenado en la tercera zona Z3 de memoria, comprende, en este caso, informaciones que caracterizan a cada uno de los datos DT1-DT3 de usuarios.
Más precisamente, el modelo MD de datos define criterios CT1, CT2 y CT3 (llamados colectivamente, CT) asociados, respectivamente, a los datos DT1, DT2 y DT3 de usuario,
Debe observarse que cada uno de los criterios CT1-CT3 puede comprender uno o una pluralidad de criterios que se aplican a los datos DT de usuario correspondientes. Debe observarse, igualmente, que puede definirse un mismo criterio CT en el modelo MD de datos, para al menos dos datos DT de usuarios distintos. Por motivos de simplicidad, en este ejemplo representado en las Figuras 3 y 4, se supone que cada criterio CT está constituido por un único criterio que deben respetar los datos DT de usuario correspondientes.
En este ejemplo, el modelo MD de datos define, igualmente, acciones ATI y AT2 (llamadas colectivamente, AT) denominadas, respectivamente, “primeras acciones” y “segundas acciones” , en asociación con cada uno de los datos DT1, DT2 y DT3 de usuario. Más precisamente, como se representa en la Figura 4, en este caso, se supone que el modelo MD de datos define:
- una primera acción AT11 y una segunda acción AT21, en asociación con los datos DT1 de usuario;
- una primera acción AT12 y una segunda acción AT22, en asociación con los datos DT2 de usuario; y - una primera acción AT13 y una segunda acción AT 13, en asociación con los datos DT3 de usuario.
Debe observarse que cada una de las primeras acciones, indicadas colectivamente AT1, y cada una de las segundas acciones, indicadas colectivamente AT2, pueden comprender una o una pluralidad de acciones predefinidas. Debe observarse, igualmente, que puede definirse una misma acción AT en el modelo MD de datos, para al menos dos datos DT de usuarios distintos. Por motivos de simplicidad, en este ejemplo representado en las Figuras 3 y 4, se supone que cada primera y segunda acción AT1, AT2 está constituida por una única acción que debe efectuarse por el sistema operativo OS1.
Cada primera acción AT1, en el sentido de la invención, define una acción que el sistema operativo OS1 debe efectuar si los datos DT de usuario correspondientes no son conformes al criterio CT aplicable según el modelo MD de datos. Cada primera acción predeterminada AT1 puede ser cualquiera y puede comprender, por ejemplo, una modificación predeterminada que debe realizarse en datos DT de usuario no conformes.
A la inversa, cada segunda acción AT2, en el sentido de la invención, define una acción que el sistema operativo OS1 debe efectuar si los datos DT de usuario correspondientes son conformes al criterio CT aplicable según el modelo MD de datos. Cada segunda acción predeterminada puede ser cualquiera y, en un ejemplo particular, no provoca ninguna modificación de los datos DT de usuarios correspondientes, que se considera que son conformes. Por tanto, el experto en la técnica apreciará la flexibilidad ofrecida por la posibilidad de poder definir primeras acciones AT1 y segundas acciones AT2 de manera específica, y dedicadas a cada uno de los datos DT de usuarios considerados o, de manera común, a varios datos DT de usuario distintos.
De manera general, el modelo MD de datos puede definir al menos un criterio CT en asociación con al menos una primera acción AT1 y, eventualmente, con al menos una segunda acción AT2.
Según un modo de realización particular, si no se define ninguna segunda acción AT2 por el modelo MD de datos para datos DT de usuario dados, entonces, en caso de conformidad de los datos DT de usuario con respecto al criterio CT aplicable, el sistema operativo OS1 no efectúa ninguna modificación de los datos DT de usuario.
Según un modo de realización particular, el modelo MD de datos define al menos un criterio CT y al menos una segunda acción AT2, en asociación con datos DT de usuario, pero ninguna primera acción AT1. En caso de no conformidad de estos datos DT de usuario, el sistema operativo OS1 no modifica dichos datos DT de usuario en cuestión y, eventualmente, puede enviar un mensaje de error.
Según un modo de realización particular, el modelo MD de datos define al menos un criterio CT en asociación con datos DT de usuario, pero ninguna primera acción AT1 ni ninguna segunda acción AT2.
No obstante, son posibles otros modos de realización y no se han descrito, en este caso, por motivos de simplicidad y claridad. Por tanto, los modos de realización descritos en este documento, no constituyen, de ninguna manera, una limitación a los mismos para la presente invención.
El desarrollo del procedimiento de procesamiento, según un modo de realización particular, puesto en práctica por la tarjeta SIM 2 en el ejemplo representado en las Figuras 3 y 4, se describe ahora con referencia a la Figura 5. A lo largo de una etapa S10, la tarjeta SIM 2 detecta que se requiere la verificación de la conformidad de al menos un dato DT de usuario. En el siguiente ejemplo, se supone que se requiere la verificación de la conformidad de los datos DT2 de usuario.
Según un ejemplo particular, la tarjeta SIM 2 determina (S10) que debe verificarse la conformidad de los datos DT2 de usuario, al detectarse que se ha actualizado el sistema operativo OS1.
Según un ejemplo particular, antes de la etapa S10, la tarjeta SIM 2 actualiza su sistema operativo OS1, por ejemplo, en respuesta a la recepción de una orden de actualización del OS. La tarjeta SIM 2 determina (S10), entonces, que debe verificarse la conformidad de los datos DT2 de usuario, al detectarse que se ha actualizado el sistema operativo OS1. En un ejemplo particular, la tarjeta SIM 2 determina (S10), entonces, que se requiere la verificación de la conformidad de todos los datos DT de usuario presentes en la zona Z2 de memoria. Cuando se actualiza el sistema operativo OS1, es susceptible de cambiar de configuración y necesitar datos DT de usuario diferentes de los que se requerían para su configuración anterior. Verificando la conformidad de los datos DT de usuario tras una actualización del sistema operativo, es posible evitar eficazmente problemas de incompatibilidad entre el sistema operativo actualizado y los datos de usuario, como ya se explicó anteriormente.
Según un ejemplo particular, la tarjeta SIM 2 determina (S10) que debe verificarse la conformidad de los datos DT2 de usuario, al detectarse que se requiere una lectura de los datos DT2 de usuario en la zona Z2 de memoria. Entonces, se realiza la verificación de conformidad al vuelo, cada vez que se requiere la lectura de un dato DT de usuario.
En el ejemplo considerado en este caso, al detectarse (S10) que se requiere la verificación de la conformidad del dato DT2 de usuario, la tarjeta SIM 2 consulta, a lo largo de una etapa S12 de consulta, el modelo MD de datos en la tercera zona Z3 de memoria, y determina el o los criterios CT que deben respetar, según el modelo MD de datos, los datos DT2 de usuario. Por tanto, en este ejemplo, la tarjeta SIM 2 detecta en S12 que el criterio CT2 es el criterio aplicable a los datos DT2 de usuario, como se representa en la Figura 4.
A lo largo de una etapa S14 de determinación, la tarjeta SIM 2 determina si los datos DT2 de usuario cuya verificación se requiere son conformes al criterio CT2 correspondiente, tal como se define en el modelo MD de datos. Para ello, la tarjeta SIM 2 accede a los datos DT2 de usuario en la zona Z2 de memoria y compara los mismos con el criterio aplicable CT2, para determinar si hay conformidad o no. Si se detecta que los datos DT2 de usuario son conformes a lo que se especifica en el modelo Md de datos, el procedimiento continúa en S16. En caso contrario (no conformidad), el procedimiento continúa en S18.
A lo largo de la etapa S18 (DT2 no conforme), la tarjeta SIM 2 consulta de nuevo el modelo MD de datos, en la tercera zona Z3 de memoria, para determinar dicha al menos una primera acción predeterminada AT1 definida por el modelo MD de datos, en asociación con los datos DT2 de usuario, a saber: la acción AT12 en el presente caso. A lo largo de una etapa S20 de ejecución, la tarjeta SIM 2 ejecuta, a continuación, la acción predeterminada AT12, según las especificaciones del modelo MD de datos.
Esta primera acción predeterminada AT12 puede comprender la realización de cualquier conjunto de instrucciones (porción de programa) previamente grabado en el modelo MD de datos. La acción predeterminada AT12 puede comprender una modificación de los datos DT2 de usuario por el sistema operativo OS1. El tipo de esta modificación puede variar según el caso (por ejemplo, cambio de longitud, cambio de tipo, encriptad del dato de usuario, actualización del valor del contenido del dato de usuario, ...).
En un ejemplo particular, la tarjeta SIM 2 determina, durante la primera consulta en S12, dicha al menos una primera acción predeterminada AT12, definida por el modelo MD de datos en asociación con los datos DT2 de usuario. En este caso, resulta inútil realizar de nuevo esta operación en S18.
En cambio, si los datos DT2 de usuarios son conformes al criterio CT2 (etapa S14; Figura 5), la tarjeta SIM 2 funciona normalmente, es decir, como se define, por ejemplo, por el programa del sistema operativo OS1. En un ejemplo particular, el sistema operativo OS1 provoca la ejecución, durante la etapa S16, de al menos una segunda acción predeterminada AT2, a saber, la acción AT22 en el presente caso. En este ejemplo, esta segunda acción predeterminada AT22 es diferente de dicha al menos una primera acción predeterminada AT1 (a saber, AT12 en el presente caso) requerida por el modelo MD de datos, en caso de una detección (en S14) de no conformidad de los datos DT2 de usuarios.
Según un ejemplo particular, dicha al menos una segunda acción predeterminada AT2 está definida en el modelo MD de datos, en asociación con los datos DT de usuario, cuya verificación de conformidad se requiere. El modelo MD de datos puede definir cualquier instrucción que permita al sistema operativo OS1 determinar la acción AT2 que debe realizarse en S16. En un ejemplo particular, la acción AT2 se especifica en el sistema operativo OS1 y el modelo MD de datos comprende una instrucción que ordena al sistema operativo OS1 la ejecución de esta acción. La tarjeta SIM 2 puede consultar de nuevo el modelo MD de datos para determinar AT2, o ya ha determinado AT2 durante la consulta en S12.
Según otro ejemplo, dicha al menos una segunda acción predeterminada AT2 no está definida en el modelo MD de datos. Dicho de otro modo, no se realiza (o necesita) ninguna consulta del modelo MD de datos para determinar dicha al menos una segunda acción predeterminada AT2, ejecutada por el sistema operativo OS1 en S16.
En un ejemplo particular, dicha al menos una segunda acción predeterminada AT2 realizada en S16, se especifica en el sistema operativo OS1.
A continuación, se describen ahora ejemplos particulares aplicados al procedimiento de las Figuras 2 o 5.
- Ejemplo 1: si en S4/S14 se detecta que los datos DT de usuario no tienen un tipo o formato conforme al especificado por el modelo MD de datos (por ejemplo, mal identificador AID de una applet, tipo de archivo incorrecto: binario, cíclico o lineal...), entonces, el sistema operativo OS1 realiza una secuencia de comandos predefinida AT1 o abandona una operación de lectura de los datos DT en cuestión;
- Ejemplo 2: si en S4/S14 se detecta que los datos DT de usuario son más largos o más voluminosos que un valor umbral predefinido L1 definido en un criterio CT, entonces, el sistema operativo OS1 lee los n primeros o últimos bits (u octetos) de los datos DT de usuario en cuestión (siendo n un número entero natural) e ignora los bits (u octetos) restantes;
- Ejemplo 3: si en S4/S14 se detecta que los datos DT de usuario son menos largos o menos voluminosos que un valor umbral predefinido L2 definido en un criterio CT, entonces, el sistema operativo OS1 añade a los datos DT de usuario en cuestión, tantos bits (o bytes), por ejemplo, nulos (en el estado “0” ), como bits (o bytes) falten (técnica denominada, de “ relleno” ), con el fin de obtener datos DT de usuario del tamaño requerido según el valor umbral L2;
- Ejemplo 4: si en S4/S14 se detecta que los datos DT de usuario no están situados en una posición predefinida en la zona Z2 de memoria (dirección de memoria de los datos DT incorrectos), entonces, el sistema operativo OS1 busca los datos DT de usuario en cuestión, en otra posición predefinida en la zona Z2 de memoria, o abandona una operación de lectura de dichos datos de usuarios, o incluso realiza una secuencia de comandos predefinida (ejecutar un cálculo, tener en cuenta un valor por defecto, ...).
Según un ejemplo particular, representado en la Figura 6, el procedimiento de procesamiento representado en las Figuras 2 o 5, comprende, además, las siguientes etapas realizadas por la tarjeta SIM 2 (Figura i ):
- recibir (S30) una orden CMD1 de actualización, que comprende primeros datos UP1 de actualización referentes al sistema operativo OS1, en asociación con segundos datos UP2 de actualización referentes al modelo MD de datos; y
- actualizar (S32) el sistema operativo OS1 a partir de los primeros datos UP1 de actualización, y actualizar (S34) el modelo MD de datos a partir de los segundos datos UP2 de actualización.
La orden CMD1 de actualización se recibe, por ejemplo, en S30, desde un servidor remoto SV, por medio de un terminal de comunicación móvil, en donde está incorporada (o con el que actúa conjuntamente) la tarjeta SIM 2. De este modo, es posible, a partir de los datos UP1 comprendidos en la orden recibida CMD1, actualizar el sistema operativo OS1, con el fin, por ejemplo, de corregir fallos o añadir nuevas funcionalidades. Además, es posible, a partir de los datos UP2 comprendidos en la orden recibida CMD1, actualizar el modelo MD de datos, con el fin de que este último especifique al sistema operativo OS1 la forma de los datos DT de usuarios esperada (criterio CT), así como el procesamiento que debe realizarse (primera acción AT1) en el caso en donde los datos DT de usuario no fueran conformes a lo que se espera por el sistema operativo OS1. Estas actualizaciones del sistema operativo OS1 y del modelo MD, se realizan sin que se actualicen los datos DT de usuario.
Una vez realizadas las etapas S32 y S34, el sistema operativo OS1 puede usar los datos DT de usuario en la zona Z2 de memoria, con la ayuda del modelo MD de datos actualizado.
De manera general, la orden CMD1 de actualización recibida en S30 por la tarjeta SIM 2, puede comprender al menos uno de entre los datos UP1 y los datos UP2, descritos anteriormente.
Según un modo de realización particular, la orden CMD1 de actualización comprende únicamente los primeros datos UP1 de actualización referentes al sistema operativo OS1. La tarjeta SIM 2 realiza, entonces, la actualización S32 del OS1 a partir de los datos UP1, pero no realiza la etapa S34. Una vez realizada la etapa S32, el sistema operativo OS1 actualizado puede, entonces, usar los datos DT de usuario en la zona Z2, con la ayuda del modelo MD de datos.
Según un modo de realización particular, la orden CMD1 de actualización comprende únicamente los segundos datos UP2 de actualización referentes al modelo MD de datos. La tarjeta SIM 2 realiza, entonces, la actualización S34 del modelo MD a partir de los datos UP2, pero no realiza la etapa S32. Una vez realizada la etapa S34, el sistema operativo OS1 puede, entonces, usar los datos DT de usuario en la zona Z2, con la ayuda del modelo MD de datos actualizado.
Según un ejemplo particular, la tarjeta SIM 2 detecta en S10 (Figura 5) que se requiere una verificación de la conformidad de datos DT de usuario (eventualmente, de todos los datos de usuario presentes en la segunda zona Z2 de memoria), al detectarse una actualización del modelo MD de datos y/o una actualización del sistema operativo OS1.
La totalidad, o parte de las etapas representadas en la Figura 6, pueden realizarse antes de la ejecución de la etapa S2 (Figura 2) o S10 (Figura 5), tales como se describieron anteriormente. De este modo, es posible, para el operador de una red móvil, por ejemplo, actualizar el sistema operativo OS1 de la tarjeta SIM 2 y/o el modelo MD de datos, y configurar el sistema operativo OS1 de manera que se gestionen las situaciones en donde los datos de usuario almacenados en memoria ya no fueran compatibles con el sistema operativo OS1.
Según un ejemplo particular (Figura 6), antes de la etapa S30, la tarjeta SIM 2 recibe (S24) una petición RQ de actualización, procedente del servidor remoto SV. En respuesta a esta petición RQ, la tarjeta SIM 2 envía (S26) a dicho servidor SV la versión VOS1 del sistema operativo OS1 almacenado en la zona Z1 de memoria y, eventualmente, también la versión VMD del modelo MD de datos almacenado en la zona Z3 de memoria. El servidor remoto SV determina, entonces (S28), a partir de VOS1 (y, eventualmente, VMD), si el sistema operativo OS1 está actualizado y, en caso negativo, envía en S30 la orden CMD1 de actualización (Figura 1), como ya se describió. Esta orden CMD1 comprende, por ejemplo, un archivo de actualización del sistema operativo OS1 y del modelo MD de datos. Este archivo de actualización comprende, en este caso, los datos UP1 y UP2 de actualización referentes, respectivamente, al sistema operativo OS1 y al modelo MD de datos, como ya se explicó. La tarjeta SIM 2 procede, entonces, como ya se indicó anteriormente: recibir (S30) la orden CMD1 de actualización, luego actualizar (S32) el sistema operativo OS1 y actualizar (S34) el modelo MD de datos, y esto sin modificar los datos DT de usuarios.
Según un ejemplo particular, la tarjeta SIM 2 envía en S26 (Figura 6) al menos uno de entre VOS1 y VMD al servidor SV. El servidor SV determina, entonces, en S28, a partir de VOS1 y/o VMD, si el sistema operativo OS1 en Z1 y/o el modelo MD de datos en Z3, están respectivamente actualizados y, en caso negativo, envía en S30 la orden CMD1 de actualización (Figura 1), que comprende al menos uno de entre UP1 y UP2 necesario para la actualización.
Un experto en la técnica comprenderá que los modos de realización y variantes descritos anteriormente tan solo constituyen ejemplos no limitativos de puesta en práctica de la invención. En particular, el experto en la técnica podrá prever cualquier adaptación o combinación de los modos de realización y variantes descritos anteriormente con el fin de responder a una necesidad muy particular.

Claims (14)

REIVINDICACIONES
1. Módulo (2) de identidad de abonado incorporado, que comprende:
- una primera zona (Z1) de memoria, configurada para grabar en memoria un sistema operativo (OS1); y
- una segunda zona (Z2) de memoria, configurada para grabar en memoria datos (DT) de usuario accesibles por el sistema operativo (OS1);
estando el módulo de identidad de abonado incorporado, caracterizado por que comprende, además: - una tercera zona (Z3) de memoria, distinta de las zonas (Z1, Z2) de memoria primera y segunda, configurada para grabar en memoria un modelo (MD) de datos, que define:
o al menos un criterio (CT) que debe satisfacer los datos (DT) de usuario contenidos en la segunda zona (Z2) de memoria;
o al menos una primera acción predeterminada (AT1), en asociación con los datos de usuario;
- un módulo (8) de determinación, configurado para determinar si dichos datos (DT) de usuario son conformes a dicho al menos un criterio (CT); y
- un módulo (10) de procesamiento, configurado, si dichos datos (DT) de usuario no son conformes a dicho al menos un criterio, para:
o consultar, en la tercera zona (Z3) de memoria, el modelo (MD) de datos, con el fin de determinar dicha al menos una primera acción predeterminada; y
o provocar la ejecución de dicha al menos una primera acción predeterminada (AT1), definida en el modelo (MD) de datos.
2. Módulo de identidad de abonado incorporado, según la reivindicación 1, en donde el módulo de determinación está configurado para determinar si dichos datos (DT) de usuario son conformes a dicho al menos un criterio, al detectarse que se ha actualizado el sistema operativo.
3. Módulo de identidad de abonado incorporado, según las reivindicaciones 1 o 2, en donde el sistema operativo (OS1) está configurado, si dichos datos (DT) de usuarios son conformes a dicho al menos un criterio, para ejecutar al menos una segunda acción predeterminada, diferente de dicha primera acción predeterminada.
4. Módulo de identidad de abonado incorporado, según la reivindicación 3, en donde dicha al menos una segunda acción predeterminada está definida en el modelo (MD) de datos, en asociación con dichos datos de usuarios.
5. Módulo de identidad de abonado incorporado, según una cualquiera de las reivindicaciones 1 a 4, en donde dicho al menos un criterio comprende al menos uno de entre:
- un tipo de dato predeterminado;
- una longitud o un formato predeterminado de una cadena de bits o bytes de datos;
- una posición de bits o bytes predeterminada, en una cadena de bits o bytes de datos;
- una condición de presencia, que indica que deben estar presentes o no datos de usuarios en la segunda zona (Z2) de memoria;
- una ubicación en la segunda zona de memoria;
- un valor;
- un umbral;
- un valor de contenido; y
- un estado predeterminado de datos.
6. Módulo de identidad de abonado incorporado, según una cualquiera de las reivindicaciones 1 a 5, en donde el modelo de datos define una pluralidad de criterios que deben satisfacer los datos de usuarios, estando el módulo de determinación configurado para determinar si los datos de usuarios son conformes a cada uno de dichos criterios,
estando el módulo de procesamiento configurado para realizar al menos dicha al menos una primera acción predeterminada, definida en el modelo (MD) de datos, si dichos datos (DT) de usuarios no son conformes a al menos uno de dichos criterios.
7. Módulo de identidad de abonado incorporado, según una cualquiera de las reivindicaciones 1 a 6, que comprende un módulo de actualización configurado para:
- recibir una orden de actualización, que comprende primeros datos (UP1) de actualización referentes al sistema operativo (OS1), en asociación con segundos datos (UP2) de actualización referentes al modelo (MD) de datos; y
- actualizar el sistema operativo (OS1) a partir de los primeros datos (UP1) de actualización y actualizar el modelo de datos a partir de los segundos datos (UP2) de actualización.
8. Módulo de identidad de abonado incorporado, según la reivindicación 7, en donde el módulo (8) de determinación está configurado para determinar si dichos datos de usuarios presentes en la segunda zona (Z2) de memoria, son conformes a dicho al menos un criterio definido en el modelo de datos, una vez actualizado este último a partir de los segundos datos de actualización.
9. Procedimiento de procesamiento puesto en práctica por un módulo (2) de identidad de abonado incorporado, que incluye:
- una primera zona (Z1) de memoria, en donde está grabado un sistema operativo (OS1); y - una segunda zona (Z2) de memoria, en donde están grabados datos (DT) de usuario accesibles por el sistema operativo (OS1);
estando el procedimiento caracterizado por que el módulo (2) de identidad de abonado incorporado incluye, además:
- una tercera zona (Z3) de memoria, distinta de las zonas (Z1, Z2) de memoria primera y segunda, en donde está grabado un modelo (MD) de datos, que define:
o al menos un criterio (CT) que debe satisfacer los datos (DT) de usuario contenidos en la segunda zona (Z2) de memoria; y
o al menos una primera acción predeterminada (AT1), en asociación con los datos de usuario; comprendiendo el procedimiento las siguientes etapas:
- determinar si dichos datos (DT) de usuario son conformes a dicho al menos un criterio (CT) definido en el modelo (MD) de datos; y
- si dichos datos (DT) de usuario no son conformes a dicho al menos un criterio:
o consultar, en la tercera zona (Z3) de memoria, el modelo (MD) de datos, con el fin de determinar dicha al menos una primera acción predeterminada; y
o desencadenar la ejecución de dicha al menos una primera acción predeterminada (AT1), definida en el modelo (MD) de datos.
10. Procedimiento según la reivindicación 9, que comprende una actualización del sistema operativo (OS1) en la primera zona (Z1) de memoria,
en donde dicha determinación de si los datos (DT) de usuario son conformes a dicho al menos un criterio definido en el modelo de datos, se realiza al detectarse que se ha actualizado el sistema operativo.
11. Procedimiento según una de las reivindicaciones 9 o 10, en donde, si dichos datos (DT) de usuarios son conformes a dicho al menos un criterio, el sistema operativo ejecuta al menos una segunda acción predeterminada (AT2), diferente de dicha primera acción predeterminada.
12. Procedimiento según una cualquiera de las reivindicaciones 9 a 11, que comprende, además, las siguientes etapas:
- recibir una orden de actualización, que comprende primeros datos (UP1) de actualización referentes al sistema operativo (OS1), en asociación con segundos datos (UP2) de actualización referentes al modelo (MD) de datos; y
- actualizar el sistema operativo (OS1) a partir de los primeros datos (UP1) de actualización y actualizar el modelo de datos a partir de los segundos datos (UP2) de actualización.
13. Procedimiento según la reivindicación 12, en donde dicha determinación de si dichos datos (DT) de usuario son conformes a dicho al menos un criterio definido en el modelo (MD) de datos, se realiza al detectarse que se ha actualizado el modelo de datos a partir de los segundos datos de actualización.
14. Programa (PG1) de ordenador que incluye instrucciones para la ejecución de las etapas de un procedimiento de procesamiento, según una cualquiera de las reivindicaciones 9 a 13, cuando dicho programa se ejecuta por un ordenador asociado a un módulo de identidad de abonado incorporado.
ES19159268T 2018-02-26 2019-02-26 Configuración de un módulo de identidad de abonado incorporado Active ES2925180T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1851650A FR3078469B1 (fr) 2018-02-26 2018-02-26 Configuration d'un module d'identite de souscripteur embarque

Publications (1)

Publication Number Publication Date
ES2925180T3 true ES2925180T3 (es) 2022-10-14

Family

ID=62873426

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19159268T Active ES2925180T3 (es) 2018-02-26 2019-02-26 Configuración de un módulo de identidad de abonado incorporado

Country Status (5)

Country Link
US (1) US10809930B2 (es)
EP (1) EP3531729B1 (es)
ES (1) ES2925180T3 (es)
FR (1) FR3078469B1 (es)
PL (1) PL3531729T3 (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020171672A1 (en) * 2019-02-22 2020-08-27 Samsung Electronics Co., Ltd. Method for interoperating between bundle download process and esim profile download process by ssp terminal
JP7081619B2 (ja) * 2020-03-25 2022-06-07 カシオ計算機株式会社 機器の制御装置、機器、機器の制御方法及びプログラム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070288531A1 (en) * 2006-06-07 2007-12-13 Giovanni Motta Mobile device with an embedded file system capable of updating file system components
US8607208B1 (en) * 2008-10-01 2013-12-10 Oracle International Corporation System and methods for object code hot updates
US8996851B2 (en) * 2010-08-10 2015-03-31 Sandisk Il Ltd. Host device and method for securely booting the host device with operating system code loaded from a storage device
US8555067B2 (en) 2010-10-28 2013-10-08 Apple Inc. Methods and apparatus for delivering electronic identification components over a wireless network
US9053107B1 (en) * 2011-12-06 2015-06-09 Google Inc. Determining updates for files based on an organization of the files on different blocks of a storage device
ES2857674T3 (es) 2014-11-24 2021-09-29 Idemia France Creación de archivos implícita en secuencias de comandos APDU

Also Published As

Publication number Publication date
US20190265901A1 (en) 2019-08-29
EP3531729B1 (fr) 2022-06-22
FR3078469B1 (fr) 2020-03-06
FR3078469A1 (fr) 2019-08-30
PL3531729T3 (pl) 2022-08-16
US10809930B2 (en) 2020-10-20
EP3531729A1 (fr) 2019-08-28

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
ES2708696T3 (es) Método para el cambio del operador de red móvil en una SIM integrada basado en un privilegio especial
ES2728299T3 (es) Procedimientos y dispositivos para proporcionar un perfil de suscripción a un dispositivo móvil
ES2378252T3 (es) Método y aparato para proteger la información de "SIMlock" en un dispositivo electrónico
ES2734370T3 (es) Protección de la carga de datos en una memoria no volátil de un elemento dotado de seguridad
EP2903389B1 (en) Method for keeping subscriber identity module cards on standby and terminal equipment
BR102015032941A2 (pt) método para gerenciamento de uma pluralidade de perfis em um módulo sim, módulo sim e produto de programa de computador
ES2774032T3 (es) Módulo de identidad del abonado integrado que comprende perfiles de comunicación
US9411748B2 (en) Secure replay protected storage
US9530027B2 (en) Device lock for transit
US10820189B2 (en) Installation of a profile in an embedded subscriber identity module
ES2925180T3 (es) Configuración de un módulo de identidad de abonado incorporado
JP2012530290A (ja) コンピューティングデバイスの不正使用を防止するための方法および装置
WO2002087269A2 (en) System and method for securing information in memory
BR112015027847B1 (pt) Método para acessar um serviço, um dispositivo compreendendo uma memória, dispositivo para acessar um serviço , e sistema para acessar um serviço
ES2871926T3 (es) Procedimiento de gestión de perfiles de suscripción, servidor de gestión de suscripciones y UICC
CN111177709A (zh) 一种终端可信组件的执行方法、装置及计算机设备
ES2782835T3 (es) Método de notificación para configurar un elemento seguro
ES2558008T3 (es) Determinación de la configuración de aparatos y datos de programación
WO2017143715A1 (zh) 一种终端解除锁网的方法、开机的方法及装置
US10251054B2 (en) System and method for policy control functions management mechanism
US8959602B2 (en) Modification of a secured parameter in a user identification module
US8656457B2 (en) Controlling locking state transitions in a terminal
ES2692835T3 (es) Procedimiento de administración de ciclos de vida de perfiles de comunicación
ES2865293T3 (es) Dispositivo electrónico que comprende un módulo seguro que soporta un modo de gestión local de configurar de un perfil de abonado