ES2891029T3

ES2891029T3 - Procedimientos de carga de un perfil en un elemento seguro, administrador y elemento seguro personalizable

Info

Publication number: ES2891029T3
Application number: ES18201306T
Authority: ES
Inventors: Jérôme Dumoulin; Marc Pardieu; Cyrille Fougerouse
Original assignee: Idemia France SAS
Current assignee: Idemia France SAS
Priority date: 2017-10-20
Filing date: 2018-10-18
Publication date: 2022-01-25
Anticipated expiration: 2038-10-18
Also published as: KR102557240B1; US20190121797A1; EP3474583A1; EP3474583B1; KR20190044575A; FR3072853B1; US11100081B2; FR3072853A1

Abstract

Procedimiento de carga de un perfil en memoria de un elemento seguro (20), que consta, al nivel de un servidor remoto (310, 320, 330) del elemento seguro, de las siguientes etapas: recibir (E40), del elemento seguro, una información representativa de una versión de un modelo de elemento de perfil guardado en memoria (220, 230) del elemento seguro, comparar la información recibida con información asociada a un mismo modelo guardado en memoria del servidor remoto para generar un nuevo perfil, para determinar (E50) una diferencia de versión del modelo, en caso de determinación de una diferencia, enviar (E70) al elemento seguro un comando de actualización (E80) del modelo guardado en memoria del elemento seguro o actualizar (E55) el modelo guardado por el administrador, para alinear sus versiones, generar (E10, E65) un perfil que incluye un elemento de perfil al que se da formato con ayuda del modelo guardado por el servidor remoto, en su versión alineada, y con posterioridad a la etapa de actualización, enviar (E100, E110), al elemento seguro, el perfil generado.

Description

DESCRIPCIÓN

Procedimientos de carga de un perfil en un elemento seguro, administrador y elemento seguro personalizable Ámbito de la invención

La invención está en el ámbito de la personalización remota de elementos seguros. Se refiere, en particular, a procedimientos de gestión de modelos de elemento de perfil, un soporte de información, un administrador de modelos de elemento de perfil y a un elemento seguro personalizable.

Contexto de la invención

Puede utilizarse un elemento seguro, por ejemplo, una tarjeta inteligente, en diversos equipos o dispositivos anfitrión (terminal móvil, Smartphone, tableta digital, contador eléctrico, vehículo, etc.).

En particular, el elemento seguro puede estar integrado de manera extraíble en el dispositivo anfitrión o integrado (por ejemplo, soldado) en el mismo.

Un primer tipo de elemento seguro se conoce con el nombre de tarjeta UICC ( Universal Integrated Circuit Card, en inglés) contemplado en la norma “ EETSI TS 102 221” y agrupa las tarjetas inteligentes extraíbles convencionales, de tipo tarjeta SIM (o USIM, Universal Subscriber Identity Module en inglés), pero también testigos de autenticación ( token, en inglés) seguros, todos identificables de forma única.

Un segundo tipo de elemento seguro se conoce con el nombre de “eSE” ( embedded Secure Elément, en inglés) y se contempla en la especificación GlobalPIatform Card Specification Version 2.2.1 relativa a las normas GlobalPIatform. Este segundo tipo se dirige a elementos seguros integrados, es decir, no extraíbles.

A modo de ejemplo, el elemento seguro integrado puede ser una “eUICC” , tarjeta de circuito integrado universal integrada ( embedded Universal Integrated Circuit Card, en inglés), como se contempla en la norma ETSI TS 103 383.

En el resto del documento, en aras de una mayor simplicidad, se utiliza el término genérico “tarjeta o elemento seguro” para designar el conjunto de los distintos elementos seguros anteriormente mencionados, generalmente utilizados para identificarse (por ejemplo, en una red de telefonía móvil).

Para compensar el hecho de que el usuario no pueda cambiar simplemente el elemento seguro integrado en el dispositivo anfitrión por otro elemento seguro o que simplemente no desee realizar las manipulaciones de intercambio de un elemento seguro en el dispositivo anfitrión, el usuario a veces no tiene capacidad para cambiar el identificador único que le permite identificarse.

Se prevé por tanto que el elemento seguro pueda funcionar según varios perfiles distintos, cada uno identificado por un identificador único, y guardados o descargados en el elemento seguro. Por tanto, puede haber varios perfiles distintos en un mismo elemento seguro, por ejemplo, una misma eUICC.

Técnicamente, un perfil, por ejemplo, tal como el definido en el documento 'SGP.02 - Remote Provisioning Architecture for Embedded UICC Technical Specification - Version 3.1 - 27 mayo 2016 , es un entorno seguro que puede comprender una combinación de una estructura de archivos (sobre todo en forma de “ elementary files” o EF y/o “ Dedicated Files” o DF), de datos y de aplicaciones que permitan, cuando el perfil está activado, acceder a los servicios (p. ej., voz, datos) propuestos por un operador de red específico, típicamente un operador de red móvil. Cabe señalar que puede haber un solo perfil activo a la vez.

En principio, la gestión de estos perfiles puede ser llevada a cabo bien por un servidor remoto (“ Machine to Machine” o M2M system), o bien localmente por una aplicación instalada en la eUICC, incluso manualmente por el propio usuario. Estos perfiles pueden crearse remotamente al nivel de una infraestructura de personalización. En la práctica, esta infraestructura de personalización está controlada por el propio operador o por un tercero (p. ej., Profile Creator definido en el documento ' eUICC Profile Package: Interoperable Format Technical Spécification V2.0 SIMALLIANCE) para la cuenta del operador y genera paquetes o conjuntos de perfil (PP de Profile Packages, en inglés), en función de los deseos del operador.

Tal paquete de perfil, en adelante denominado simplemente “perfil” , representa la estructura de datos del perfil a instalar y se envía a la eUICC para su carga y descarga. Ventajosamente, los terceros, el operador y el proveedor de la eUICC utilizan el mismo formato de descripción, lo que permite garantizar una interoperabilidad entre estas entidades. En la práctica, un perfil incluye un conjunto de elementos de perfil (PE de Profile Elements, en inglés) que utilizan un lenguaje de descripción independiente del protocolo de transporte. Cada elemento de perfil representa una o varias características del perfil y se describe individualmente de forma que pueda ser tratado por la UICC independientemente de los otros elementos de perfil, respetando, no obstante, algunas secuencias específicas.

De manera general, un elemento de perfil puede incluir un archivo, una referencia a una estructura de archivos de sistema, un conjunto de parámetros de una aplicación de acceso a redes, una aplicación interoperable, derechos de acceso, etc. Por ejemplo, un elemento de perfil puede ser de uno de los siguientes tipos: PE-Header o PEH (señala el comienzo de un perfil), PE-MF ( Master File en inglés, Archivo de directorio donde están situados los archivos principales de perfil), PE-CD ( Configuration Data, en inglés, Archivo de directorio donde están situados los archivos de configuración), PE-TELECOM (archivo de directorio donde están situados los archivos elementales vinculados con funcionalidades de telecomunicaciones), PE-USIM ( Universal Subscriber Identity Module, en inglés, archivo de directorio en donde se sitúan los archivos elementales vinculados con la identificación de un suscriptor en una red móvil), PE-ISIM ( IP multimedia Services Identity Module, archivo de directorio donde están situados los archivos elementales relacionados con la identificación de un suscriptor en una red IP), PE-PINCodes (archivo de directorio donde están situados los archivos elementales vinculados con la gestión de códigos PIN), PE-SecurityDomain (archivo de directorio donde están situados los archivos elementales vinculados con la creación de un dominio seguro), PE-Application (archivo de directorio donde están situados los archivos elementales vinculados con la carga de una aplicación), PE-End (señala el fin de un perfil), etc.

Un elemento de perfil de tipo PE-Header que señala el comienzo de un perfil proporciona información diversa sobre el contenido del perfil, por ejemplo, una lista de servicios que deben estar soportados por la eUICC, en donde cada servicio está marcado con un indicador que especifica si el servicio es obligatorio u opcional. Un elemento de perfil, en particular vinculado a un servicio concreto, puede incluir un indicador concreto.

Para reducir el tamaño de los datos del perfil a transmitir, se prevé que los elementos de perfil puedan hacer referencia a uno o varios modelos (templates, en inglés) y proporcionan información que completa los modelos (a veces sustituyendo los valores por defecto). Un modelo puede comprender información/datos en relación con todo o parte de un elemento de perfil, incluso de varios elementos de perfil. La creación de un perfil generalmente se implementa utilizando estos modelos.

Los perfiles deben ser conformes a las especificaciones de las normas ETSI (p. ej., ETSI TS 102221 V13.1.0 (2016 05)), esta limitación ha llevado a la organización SIMALLIANCE a definir varios modelos, en los que el sistema de archivos puede tomar valores por defecto (identificador de archivos, derechos de acceso, ...) definidos por las normas a las que se refiere. Estos templates definen por lo tanto un formateado de los datos fijando valores por defecto para ciertos parámetros, de forma que su utilización permite facilitar y acelerar, por la reducción de los datos a transmitir, la creación del perfil por la infraestructura de personalización anteriormente mencionada, así como su instalación en la eUICC.

Para ello, los templates se cargan previamente (por ejemplo, durante una fase de pre-personalización o personalización del elemento seguro) en la memoria de la eUICC. Un template, cuando está cargado carga con valores dados que permiten “personalizarlo” , permite describir un elemento de perfil personalizado. En la práctica, cada template está asociado a un número de identificación único denominado OID ( Object IDentifier, en inglés) para poder ser identificado de forma única.

De conformidad con la arquitectura propuesta por la GSMA para la carga de perfiles en elementos seguros a distancia a través de OTA (de Over the Air, en inglés), los elementos de perfil, que incluyen una referencia (el OID) a los templates eventualmente utilizados, son enviados por un servido de transporte SM-SR (de Subscription Management-Secure Routing, en inglés) al dominio de seguridad principal o raíz ISD-R (de Issuer Security Domain Root, en inglés) de la eUICC. En una configuración y arquitectura específica, propuesta por la GSMA (conocida con la denominación “ consumer mode”, en inglés), el envío también puede hacerse directamente a través de un servidor de transporte SM-DP+ al dominio de seguridad de perfil ISD-R.

En la recepción de un nuevo elemento de perfil a cargar y a instalar que comprende una o varias referencias (OID) a templates, es suficiente que la eUICC cargue el o los templates referenciados de este modo, en la memoria de la eUICC, y fusione ( Merge, en inglés) los valores de cada template cargado en memoria con los valores recibidos en el elemento de perfil al que hacen referencia, para construir un elemento de perfil completo para la eUICC. Por fusionar, debe entenderse el hecho de utilizar de manera prioritaria los datos del elemento de perfil recibido y completarlos utilizando los datos del o de los templates referenciados y presentes en la memoria cuando los datos no están presentes en el elemento de perfil recibido.

En la práctica, la eUICC carga e instala sucesivamente cada elemento de perfil que constituye un perfil a cargar.

Los templates definen cierto número de informaciones (por ejemplo, archivos o archivos elementary) que constituyen los elementos de perfil, que pueden evolucionar con el tiempo (por ejemplo, su tamaño, sus valores, etc.), en función, por ejemplo, de la evolución de normas específicas.

Puede ocurrir, por tanto, que un elemento de perfil esté diseñado por referencia a un template concreto que ha evolucionado y que haya sido fusionado, por ejemplo, por la eUICC, con un template que no tiene en cuenta esta evolución. El resultado de la fusión puede presentar entonces un formato inesperado. En este caso, podría proporcionarse un mensaje de error. Incluso si el formato obtenido es conforme al esperado, puede ocurrir, no obstante, que la carga del perfil o bien incluso la ejecución del perfil o de una funcionalidad vinculada con el elemento de perfil obtenido de la fusión no funcione bien y genere asimismo un mensaje de error.

De hecho, en este caso ilustrativo bajo el mismo identificador OID de témplate, la infraestructura de personalización o el operador se basan en un témplate actualizado para describir el elemento de perfil, mientras que la eUICC se basa en un témplate distinto (con el mismo OID pero sin actualizar) para recrear (por fusión) el elemento de perfil final. También puede aplicarse la situación inversa, con una eUICC que se basa en un témplate actualizado y la infraestructura de personalización o el operador se basa en un template (mismo OID) no actualizado para describir el elemento de perfil. Esta situación no es satisfactoria.

Existe por tanto una necesidad general de mejorar la gestión de los templates utilizados en la carga (p. ej., creación, instalación o actualización) de perfiles en un elemento seguro.

Resumen de la invención

La presente invención tiene por lo tanto como objeto reducir al menos uno de estos inconvenientes. La invención se refiere a procedimientos, un soporte de información, un administrador y a un elemento seguro tal y como se definen en las reivindicaciones independientes 1, 6, 11, 12 y 14. Los modos de realización se definen en las reivindicaciones dependientes.

En este contexto, un aspecto se refiere en primer lugar a un procedimiento de carga de un perfil en la memoria de un elemento seguro, que consta, al nivel de un servidor remoto del elemento seguro, de las siguientes etapas: obtener una información representativa de una versión de un modelo de elemento de perfil guardado en memoria del elemento seguro,

determinar una diferencia de versión entre la versión obtenida y una versión de un mismo modelo (que concretamente lleva el mismo identificador OID) guardado en una memoria accesible por el servidor remoto, en caso de determinación de una diferencia, actualizar al menos uno de entre el modelo guardado en memoria del elemento seguro y el modelo accesible por el servidor remoto, para alinear sus versiones,

generar un perfil incluyendo un elemento de perfil que hace referencia a dicho modelo accesible por el servidor remoto, en su versión alineada, y

con posterioridad a la etapa de actualización, enviar al elemento seguro el perfil generado.

Correlativamente, un aspecto se refiere a un administrador de perfil para la personalización de un elemento seguro por carga de perfil, comprendiendo el administrador al menos un microprocesador configurado para:

obtener una información representativa de una versión de un modelo de elemento de perfil guardado en memoria del elemento seguro,

determinar una diferencia de versión entre la versión obtenida y una versión de un mismo modelo guardado en una memoria accesible por el administrador,

en caso de determinación de una diferencia, actualizar al menos uno de entre el modelo guardado en memoria del elemento seguro y el modelo accesible por el administrador, para alinear sus versiones,

generar un perfil incluyendo un elemento de perfil que hace referencia al modelo accesible por el administrador, en su versión alineada, y

Estas disposiciones permiten alinear, con un coste pequeño, las versiones de modelos de elemento de perfil entre el administrador (o servidor remoto) y el elemento seguro, para que un perfil elaborado en estas versiones de modelos y cargado posteriormente en el elemento seguro no funcione mal.

En las reivindicaciones se definen características opcionales de los modos de realización de la invención, principalmente en términos de procedimiento. Naturalmente, estas características pueden traducirse en características estructurales del administrador.

En un modo de realización, el procedimiento además comprende una etapa de envío de una solicitud que comprende un comando para obtener, en respuesta, dicha información. Esto permite al administrador iniciar la obtención de información relativa a los modelos guardados en elementos seguros, y por lo tanto controlar el flujo de respuestas desde los mismos.

Según un modo de realización particular, el envío de la solicitud se desencadena mediante la realización de un evento desencadenante entre el caudal de una duración predefinida al nivel del servidor remoto, una solicitud de carga de un perfil en el elemento seguro recibida de un tercero, la actualización y la caducidad de un modelo guardado en la memoria accesible por el servidor remoto. Por lo tanto, el administrador puede solicitar los elementos seguros en momentos clave, que puedan afectar a los futuros perfiles a cargar.

Según otro modo de realización particular, la solicitud comprende un comando de tipo parte 4 según la descripción realizada en la norma ISO7816-4, última versión de agosto de 2014 (por ejemplo, un comando GET DATA de la norma GlobalPlatform). Para simplificar, en el resto del documento, se hace referencia principalmente a un comando basado en el comando GET DATA de la norma globalPlatform. Esta disposición permite no modificar las interfaces de comunicación entre el administrador y los elementos seguros.

En otro modo de realización, la etapa de obtención de dicha información es en respuesta a una etapa previa de actualización (por ejemplo, actualización del sistema operativo), por el servidor remoto, del elemento seguro. Esta disposición limita los intercambios entre el administrador y el elemento seguro para seguir el estado de los modelos que posee este último.

Según un modo de realización particular, la etapa previa de actualización comprende la actualización de un sistema operativo del elemento seguro. Se trata en efecto de una actualización importante del elemento seguro, que afecta con frecuencia al número de archivos, y por tanto potencialmente a los modelos de elemento de perfil guardados por el elemento seguro.

Según otro modo de realización particular, la etapa de obtención de dicha información se lleva a cabo en respuesta a un evento desencadenante posterior a la actualización previa, entre una primera conexión o autentificación de red del elemento seguro y un evento de utilización de un comando o procedimiento definido por una interfaz del elemento seguro, que permite, por ejemplo, una interacción entre el elemento seguro y el terminal, denominado toolkit. Esta disposición permite limitar los riesgos de pico de carga al nivel del administrador para tratar las respuestas de una flota de elementos seguros. En efecto, es habitual que un administrador active una actualización colectiva de la flota de elementos seguros. Gracias al evento desencadenante, las respuestas de los elementos seguros no se envían simultáneamente, sino que se desacompasan (de forma no homogénea en la flota) hasta la realización de dicho evento desencadenante.

En cuanto a estos modos de realización, el microprocesador del administrador también está configurado para enviar una solicitud que comprende un comando para obtener, en respuesta, dicha información o enviar un comando de actualización de un sistema operativo del elemento seguro para obtener, en respuesta, dicha información.

En otro modo de realización, la información representativa de una versión del modelo de elemento de perfil comprende uno o varios de entre: un número de versión de dicho modelo, una fecha de caducidad de dicho modelo y un valor de hash calculado a partir de dicho modelo. Esta información puede integrarse fácilmente en los campos de metadatos de los modelos, y ocupan poco espacio en las respuestas enviadas. Asimismo, esta disposición permite minimizar el uso de memoria y de ancho de banda.

En otro modo de realización, dicha etapa de determinación de una diferencia comprende la determinación de una diferencia entre la versión obtenida del modelo guardado en memoria del elemento seguro y la versión del modelo utilizado para generar el perfil a enviar,

y la etapa de actualización en caso de diferencia comprende el envío de un comando de actualización del modelo guardado en memoria del elemento seguro con el modelo utilizado para generar el perfil a enviar.

Esta disposición permite actualizar el elemento seguro en función de un perfil ya creado por el administrador. Se limitan así los procesamientos realizados al nivel de este último.

Según un modo de realización particular, el comando de actualización comprende un comando STORE DATA de la norma GlobalPlatform. Por lo tanto, la invención no requiere la modificación de las interfaces de comunicación del administrador y del elemento seguro.

En otro modo de realización, la etapa de actualización en caso de diferencia comprende, previamente a la etapa de generación, la actualización del modelo accesible por el servidor remoto para que corresponda a la versión del modelo obtenido del elemento seguro, de modo que el perfil a enviar se genere con ayuda del modelo actualizado.

El administrador puede obtener la versión adecuada del modelo de un servidor externo/dedicado o bien local de una colección de templates. Para ello, el administrador puede, por ejemplo, basarse en otra información contenida en la respuesta que identifica un constructor del elemento seguro o un servidor del mismo.

Esta disposición permite limitar los intercambios con los elementos seguros, dado que el administrador y el perfil a cargar se adaptan al mismo tiempo (el primero se actualiza, el segundo se genera) a la configuración del elemento seguro (en términos de versión de los modelos utilizados).

En cuanto al elemento seguro, un aspecto se refiere asimismo a un procedimiento de carga de un perfil en memoria de un elemento seguro, que consta, al nivel del elemento seguro, de las siguientes etapas:

enviar, a un servidor remoto, una información representativa de una versión de un modelo de elemento de perfil guardado en memoria del elemento seguro,

en respuesta este envío, recepción y ejecución de un comando de actualización del modelo de elemento de perfil guardado en memoria, enviado por el servidor remoto,

con posterioridad a la etapa de actualización, recepción de un perfil a cambiar enviado por el servidor remoto, incluyendo el perfil a cambiar al menos un elemento de perfil que hace referencia a dicho modelo guardado en memoria, y

carga e instalación, en la memoria, del perfil recibido por fusión con el modelo guardado al que hace referencia.

Correlativamente, un aspecto también se refiere a un elemento seguro personalizable (20) que comprende al menos un microprocesador configurado para:

enviar, a un servidor remoto (330), una información representativa de una versión de un modelo de elemento de perfil guardado en memoria del elemento seguro,

La presente invención en lo referente al elemento seguro presenta las mismas ventajas que las descritas anteriormente en relación con el servidor remoto. Además, también se han previsto características opcionales, por ejemplo, tal como las definidas en las reivindicaciones, principalmente en términos de procedimiento.

Por ejemplo, en un modo de realización, la etapa de envío de dicha información por el elemento seguro es en respuesta a la recepción de una solicitud emitida por el servidor remoto, que comprende un comando para obtener, en respuesta, dicha información. La solicitud puede comprender un comando de tipo parte 4 según la descripción hecha en la norma ISO7816-4 (por ejemplo, un comando GET DATA de la norma GlobalPlatform).

En otro modo de realización, la etapa de envío de dicha información por el elemento seguro es en respuesta a una etapa previa de actualización, por el servidor remoto, del sistema operativo del elemento seguro.

Concretamente, la etapa de envío de dicha información por el elemento seguro puede ser en respuesta a un evento desencadenante posterior a la actualización previa, entre una primera conexión o autentificación de red del elemento seguro y un evento de utilización de un comando o procedimiento definido por una interfaz del elemento seguro, que permite, por ejemplo, una interacción entre el elemento seguro y el terminal, denominado toolkit.

En estos modos de realización, el microprocesador del elemento seguro está ahora configurado también para generar y enviar dicha información en respuesta a la recepción de una solicitud emitida por el servidor remoto, que comprende un comando para obtener, en respuesta, dicha información, o en respuesta a una etapa previa de actualización, por el servidor remoto, del sistema operativo del elemento seguro.

Según un modo de realización particular, el elemento seguro envía una de dicha información representativa de una versión de modelo de elemento de perfil para cada modelo guardado en memoria del elemento seguro. Esta disposición permite al administrador tener una visión completa del estado del elemento seguro.

Como variante, puede hacerlo únicamente para cada modelo guardado en memoria del elemento seguro que ha sido modificada durante la actualización previa del sistema operativo. Esto reduce el tamaño de la respuesta enviada por el elemento seguro. La red de comunicaciones está entonces menos sobrecargada, y la carga de procesamiento para el administrador se reduce.

En el marco de esta variante, el procedimiento también puede comprender previamente a la etapa de actualización previa del sistema operativo (por tanto, por ejemplo, en la recepción de un comando de actualización del OS), una etapa de inclusión en la memoria de información relativa a todos o parte de los modelos de elemento de perfil guardados en memoria del elemento seguro, y

el o los modelos modificados en la actualización previa del sistema operativo se identifican entonces con ayuda de la información memorizada.

Esta disposición permite identificar con escaso coste los modelos modificados por la actualización del OS.

En otro modo de realización, la información representativa de una versión del modelo de elemento de perfil comprende uno o varios de entre: un número de versión de dicho modelo, una fecha de caducidad de dicho modelo y un valor de hash calculado a partir de dicho modelo.

En otro modo de realización, el comando de actualización del modelo de elemento de perfil enviado por el servidor remoto comprende un comando STORE DATA de la norma GlobalPlatform.

En un modo de realización particular, las distintas etapas de los procedimientos anteriormente mencionados se determinan mediante instrucciones de programas informáticos.

En consecuencia, un aspecto se refiere también a un soporte de información legible por un microprocesador que comprende instrucciones de un programa de ordenador para implementar uno de estos procedimientos, cuando son cargados y ejecutados por el microprocesador.

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.

El soporte de información puede ser cualquier entidad o dispositivo que pueda almacenar el programa. Por ejemplo, el soporte puede comprender un medio de almacenamiento, como una ROM, por ejemplo, una ROM de microcircuito, o incluso un medio de grabación magnético, por ejemplo, un disco duro, o incluso una memoria flash.

Por otra parte, el soporte de información puede ser un soporte transmisible tal como una señal eléctrica u óptica, que puede dirigirse a través de un cable eléctrico u óptico, por radio o mediante otros medios. El programa puede descargarse concretamente a una plataforma de almacenamiento de una red de tipo Internet, de comunicaciones o bien de telecomunicaciones.

Como alternativa, el soporte de información puede ser un circuito integrado en el que está incorporado el programa, estando el circuito adaptado para ejecutar o para utilizarse en la ejecución de los procedimientos en cuestión.

El soporte de información que contiene el programa informático presenta características y ventajas análogas a las de los procedimientos que implementa el programa.

Breve descripción de las figuras

En la siguiente descripción aparecerán también otras particularidades y ventajas de la invención, que ilustran ejemplos de realización de la misma desprovistos de cualquier carácter limitativo. En las figuras:

- la Figura 1 ilustra, de forma simplificada, un ejemplo de sistema de comunicación en donde pueden implementarse modos de realización de la presente invención;

- la Figura 2 representa esquemáticamente un ejemplo de posible arquitectura para un elemento seguro o un administrador según unos modos de realización de la invención;

- la Figura 3 representa, en forma de cronograma, etapas de un procedimiento de gestión según un primer modo de realización de la invención;

- la Figura 4 representa, en forma de cronograma, etapas de un procedimiento de gestión según un segundo modo de realización de la invención.

Descripción detallada de la invención

De manera general, la invención se refiere a la carga (que incluye la creación, instalación o actualización) de uno o varios perfiles utilizados para personalizar un elemento seguro, perfil(es) cuyas descripciones se basan al menos en un modelo ( témplate). Estos templates se utilizan para dar formato a los datos de los elementos de perfil que constituyen los perfiles, para facilitar la creación de nuevos perfiles y su instalación en el elemento seguro.

Según la presente invención, se envía información representativa de una versión del al menos un témplate localizado en la memoria del elemento seguro desde el elemento seguro hasta un administrador o servidor remoto. Por administrador se entiende una entidad correspondiente, por ejemplo, y de forma no limitativa, al menos un servidor que tenga al menos un papel de preparación y/o de instalación y/o de gestión de perfiles, por ejemplo, SM-DP (de Subscription Manager Data Preparation) y SM-SR (de Subscription Manager Secure Routing) o SM-DP+ ( SM-DP enhanced) y responsable de la carga, de forma segura, de los perfiles al elemento seguro. Se entiende por “versión” de un template una edición o un estado dado de la evolución del template en un momento dado. En el ámbito informático, se trata de forma general de un estado considerado estable que permite el uso del template (de forma más general la ejecución del programa considerado).

Por extensión, la “versión” del template hace también referencia a una información que permite identificar este estado en un momento dado. Como se verá a continuación, esta versión es al menos una información de entre la pluralidad de las que constituyen los metadata del modelo y que pueden ser de distinto tipo u orientación, por ejemplo, el versioning (versión mayor y menor del modelo) del modelo, validez del modelo (fecha de caducidad) y autenticidad (valor de hash) del modelo.

En determinados modos de realización, esta información de versión es empleada por el elemento seguro en respuesta a la transmisión, por parte del administrador/servidor remoto, de un comando al elemento seguro. Por ejemplo, el comando puede ser un comando de actualización del elemento seguro (concretamente su sistema operativo u OS, de Operating System), de tal forma que la información se envía cuando el elemento seguro acaba de ser actualizado (por ejemplo, tras una actualización del OS) por un servidor externo. Eventualmente, el envío de información puede estar condicionado por otros eventos, como una primera conexión del elemento seguro actualizado a una red de comunicaciones o un evento que permite, por ejemplo, una interacción entre el elemento seguro y el terminal (toolkit) (dicho de otro modo, la utilización de un comando o procedimiento definido por la interfaz toolkitcon el elemento seguro).

En otros ejemplos, el comando puede ser una solicitud TEMPLATE AUDIT REQUEST, creada por los inventores, y cuyo objeto es obtener dicha información en todos o parte de los templates guardados en la memoria del elemento seguro. Pueden preverse varios eventos desencadenantes de esta solicitud, como los descritos a continuación, incluyendo el flujo de una duración predefinida (para una interrogación periódica), la solicitud de carga de un perfil en el elemento seguro (solicitud recibida de un tercero, por ejemplo), la creación de un nuevo perfil, la actualización o caducidad de un template. La información investigada y enviada por el elemento seguro es la que estructura un template y que forma lo que se denominan los metadatos o “ metadata”, cuyo papel es describir las características del template. Actualmente, la técnica anterior, que corresponde a la norma SIMALLIANCE, solo identifica y prevé para un único metadato un número de identificación único OID del template. Este número de identificación OID se conserva, aunque el template evolucione. Para permitir procesamientos de compatibilidad según la invención, los inventores se proponen, por tanto, añadir una o varias nuevas informaciones mediante nuevos campos creados a tal fin en la estructura habitual (metadata) de los templates.

De este modo, según unos modos de realización, la nueva información en cuestión puede comprender uno o varios de entre:

uno o varios números de versión ( versioning, en inglés) del template,

una fecha de caducidad del template,

un valor de hash calculado sobre el conjunto del template (a saber, teniendo en cuenta los valores de los metadata del template considerado y el valor del contenido del template considerado).

La solicitud TEMPLATE AUDIT REQUEST, creada por los inventores, pretende por tanto recuperar toda o parte de esta información diversa que constituye los metadata de uno o varios templates, lo que permite entonces determinar con precisión una versión del o de los templates en memoria del elemento seguro.

Esta información solicitada puede por tanto estar contenida total o parcialmente (por ejemplo, una combinación de estas informaciones) en la respuesta que reenvía el elemento seguro.

En un modo de realización de seguridad, puede llevarse a cabo una firma y/o eventualmente un cifrado del conjunto de la información proporcionada (es decir, de toda la parte útil de la respuesta) para garantizar la autenticidad de la respuesta con respecto al elemento seguro y/o eventualmente para garantizar la integridad de los datos de la respuesta. La decisión de cifrar o firmar todo o parte de la información contenida en la respuesta puede ser en función de un indicador, por ejemplo, un campo “ responseToCipher” , proporcionado en la solicitud del administrador.

A título ilustrativo, la información proporcionada puede estar contenida en una respuesta detallada a continuación, denominada TEMPLATE AUDIT RESPONSE y creada por los inventores, en la solicitud TEMPLATE AUDIT REQUEST.

Los modos de realización descritos a continuación se centran, en aras de una mayor simplificación, sin ser limitativos, principalmente en la información de número de versión del témplate. No obstante, pueden utilizarse todas o parte de las distintas informaciones ( metadata) para detectar una diferencia de versión entre un template guardado, accesible o utilizado por el administrador y un template correspondiente (es decir, con el mismo identificador OID) guardado en memoria del elemento seguro. De igual modo, en aras de una mayor claridad, estos modos de realización toman principalmente a modo de ejemplo un solo template (“el template” ), mientras que en el ámbito de la presente invención puede procesarse al mismo tiempo una pluralidad de templates.

Según un primer modo de realización, a partir de esta información, el administrador puede determinar si existe una diferencia de versión entre el template localizado en el elemento seguro y un template utilizado para crear un elemento de perfil al nivel de un servidor remoto, por ejemplo, el SM-DP. El elemento de perfil se crea, por ejemplo, en el marco de la generación de un nuevo perfil a cargar en el elemento seguro. Si se determina una diferencia de versión, puede realizarse una actualización del template memorizado en el elemento seguro para ponerlo al nivel del administrador, para que esté alineado con el mismo (es decir, sea idéntico en metadata y/o en datos del contenido que forman el template). Una vez realizada esta actualización del template del elemento seguro, el administrador que ha generado el nuevo perfil a partir del template local puede, por tanto, enviarlo al elemento seguro, que a partir de entonces puede tratarlo correctamente a la recepción, ya que ahora dispone del template actualizado, es decir en la misma versión que la utilizada para generar el perfil recibido.

En el caso en donde se emplean varios templates para la generación del nuevo perfil a cargar (por ejemplo, varios elementos de perfil hacen referencia cada uno a al menos un template), esta actualización naturalmente se amplía y realiza para cada uno de los templates referenciados en el nuevo perfil a cargar, que presentan una diferencia de versión con el mismo template guardado en el elemento seguro.

Según un segundo modo de realización, la información recibida permite al administrador identificar la versión del template guardado en el elemento seguro. En ese caso, el administrador puede actualizarse para que su template esté en la misma versión que la del elemento seguro, y de este modo el administrador puede utilizar el template actualizado (que tenga la versión identificada) para crear un elemento de perfil del perfil a cargar en el elemento seguro. De este modo, el administrador se asegura de generar un perfil basado en la misma versión de template (para cada template) que la presente en el elemento seguro. El administrador envía a continuación el perfil generado al elemento seguro que lo procesa en la recepción con ayuda del template guardado en memoria.

Por tanto, en estos distintos modos de realización, el elemento seguro puede procesar el elemento de perfil gracias a la información de metadata obtenida por el administrador que permite, bien prever una actualización del template guardado localmente en el elemento seguro, o bien dar formato, por el administrador, al perfil a cambiar (y, por tanto, a cualquier elemento de perfil que incluya) de modo que pueda procesarse con el template existente al nivel del elemento seguro.

Naturalmente, estas etapas se describen para un solo template y un solo elemento de perfil, pero pueden en principio aplicarse sin dificultad adicional a todos los elementos de perfil de un perfil a cargar, así como a los templates correspondientes utilizados para dar formato a sus datos.

La Figura 1 ilustra, de forma simplificada, un ejemplo de sistema de comunicación en donde pueden implementarse modos de realización de la presente invención.

En esta representación esquemática aparece un dispositivo anfitrión 10 que tiene integrado un elemento seguro 20, por ejemplo, una tarjeta eUICC.

El dispositivo anfitrión 10 es, por ejemplo, un terminal móvil, un teléfono móvil inteligente ( smartphone, en inglés), una tableta o cualquier otro tipo de equipo electrónico tal como un contador eléctrico, un vehículo, una máquina de café, etc.

El dispositivo anfitrión 10 y el elemento seguro 20 se comunican, por ejemplo, mediante comandos APDU ( Application Protocol Data Unit, en inglés) según la norma ISO 7816.

Naturalmente, un sistema de comunicaciones generalmente incluye una pluralidad de estos dispositivos anfitriones provistos de elementos seguros integrados. La presente invención implementa concretamente operaciones particulares en el elemento seguro integrado.

El sistema de comunicaciones también comprende una red 30 de comunicaciones. Esta red 30 es, por ejemplo, una red de telefonía móvil que normalmente comprende estaciones base (no ilustradas) para conectar los terminales móviles, así como una pluralidad de entidades (de tipo pasarela GMSC, servidores HLR, MSC, VLR, etc.) no ilustrados.

De manera general, la red 30 comprende una entidad de gestión de suscriptores (o administrador) SM 330 ( Subscription Manager, en inglés) que forma un servidor remoto y representado en la presente memoria por dos módulos de servidor distintos: un servidor de transporte o enrutamiento seguro SM-SR 310 (de Subscription Manager Secure Routing, en inglés) y un servidor de preparación de datos SM-DP 320 ( Subscription Manager Data Preparación, en inglés).

El servidor de preparación de datos SM-DP 320 se encarga principalmente de la preparación de los datos de perfiles y de la gestión de su carga e instalación segura en el elemento seguro 20.

El servidor de enrutamiento seguro SM-SR 310 se encarga principalmente de realizar, de forma segura, el transporte de los comandos (y, por tanto, de scripts de comandos) de carga, instalación y gestión de perfiles a los elementos seguros de la red.

Estos dos servidores están adaptados para una comunicación conjunta dentro de la entidad SM 330, y comunicarse con el dispositivo anfitrión 10 y el elemento seguro 20 que incorpora. Para simplificar, a continuación, se hace referencia principalmente a la entidad SM (administrador) cuando se trata de una operación realizada por uno de los dos servidores SM-DP y SM-SR, o cualquier otro tipo de servidor que participa en la gestión de suscripción, perfiles, del elemento seguro o de su contenido en sentido amplio.

En este ejemplo, el elemento seguro 20 comprende varios dominios de seguridad, en la presente memoria, dos de ellos con las referencias 245 y 250, como los definidos por la norma GSMA - Remote Provisionning Architecture for Embedded UICC - Technical Specification - Version 3.2 - 27 de junio 2017, e independientes entre sí por motivos de seguridad y confidencialidad de los datos que implementan. El elemento seguro 20 comprende, asimismo, en memoria, una recopilación de templates 255 a los que hacen referencia los perfiles a instalar (y de manera más precisa los elementos de perfil que constituyen tales perfiles).

Un dominio de seguridad principal, denominado ISD-R 245 (de Issuer Security Domain Root, en inglés), es la entidad representativa, en el elemento seguro, del servidor SM-SR 310. Por lo tanto, el ISD-R 245 y el servidor SM-SR 310 pueden comunicarse a través de la red 30 según un protocolo de transporte seguro. Como dominio de seguridad principal, el ISD-R 245 también se encarga de la gestión de otros dominios de seguridad del elemento seguro 20. En concreto, corresponde al ISD-R 245 crear otro dominio de seguridad ISD-P 250 (de Issuer Security Domain Profile, en inglés) asociado a un servidor SM-DP 320. Naturalmente, pueden crearse otros dominios de seguridad ISD-P en el elemento seguro 20 mediante el ISD-R. En este caso, pueden preverse otros servidores SM-DP en el administrador 330.

Los perfiles pueden cargarse en uno o varios de estos dominios de seguridad, para instalarse en los mismos, eventualmente como actualización de un perfil anterior.

En el marco de la invención, el elemento seguro 20 contiene una recopilación 255 de uno o varios templates dentro de su memoria que han sido, por ejemplo, preinstalados por el constructor en el momento de la fabricación o de la instalación del elemento seguro 20 en el dispositivo anfitrión 10, o que se han cargado, por ejemplo, a través de OTA, durante la vida del elemento seguro (por ejemplo, en el transcurso de la creación de un nuevo ISD-P o de un nuevo OS).

En determinados modos de realización, el lSD-R 245 es también responsable de gestionar los templates guardados en el elemento seguro (provisión de información en estos templates, actualización).

Generalmente, el servidor SM-DP 320 está configurado para preparar los datos de un perfil en forma de script de comandos o “script de instalación” , formado, por ejemplo, por una lista de C-APDU (comandos APDU) definidos en la norma ETSI TS 102 226. Como se ha mencionado anteriormente, tal perfil comprende una pluralidad de elementos de perfil a los que generalmente se ha dado formato según modelos predefinidos ( templates) accesibles por el servidor SM-DP 320.

Ya se trate de la recopilación de templates guardados en el elemento seguro 20 o accesible por el administrador, los templates cada uno de ellos consta de metadata que incluyen sustancialmente la misma información, en concreto un OID y todo o parte de un número de versión (por ejemplo, compuesto de una versión mayor y de una versión menor) del template, de una fecha de caducidad del template y de un valor de hash o huella del template.

A título ilustrativo, el valor de hash/huella puede basarse en la utilización de un algoritmo SHA256, aplicado en valores de los metadata y en el contenido (descripción del elemento de perfil) del témplate considerado. El cálculo de este hash puede hacerse antes de la introducción en memoria del témplate en el elemento seguro o en el administrador, de forma que pueda almacenarse al mismo tiempo que los otros metadata que constituyen el template.

Según el primer modo de realización de la invención ya mencionado anteriormente, antes de que los elementos de un nuevo perfil a cargar en un elemento seguro se envíen al elemento seguro, por ejemplo, en respuesta a una instrucción de carga de perfil, la invención verifica que los templates presentes en el elemento seguro corresponden bien (en términos de versión, por ejemplo) a los que se han utilizado para dar formato a los elementos de perfil a cargar. Si estos templates difieren, se actualizan, por ejemplo, al nivel del elemento seguro, antes de enviar el script.

Según el segundo modo de realización ya mencionado, se hace para identificar los templates presentes en el elemento seguro, concretamente su versión, para utilizar al nivel de la entidad SM 330 (administrador), templates que tengan las mismas versiones para generar los elementos de perfil que constituyen el perfil a cargar.

Una vez actualizados los templates necesarios en el elemento seguro para que correspondan a los utilizados para generar el perfil a cargar, es decir, en la entidad SM 330 para generar el perfil a cargar con las mismas versiones que las guardadas en el elemento seguro, la entidad SM 330 se encarga de transmitir, al elemento seguro, el perfil generado a cargar y, por tanto, los distintos elementos de perfil creados que hacen referencia a los templates utilizados (a través de los OID).

Para ello, la entidad SM 330 está configurada para particionar o segmentar el script de instalación (es decir, el perfil generado), por ejemplo, en función de los elementos de perfil que comprende, en una pluralidad de bloques binarios que forman los paquetes que se enviarán al elemento seguro 20.

Normalmente, la entidad SM 330 puede comunicarse de forma segura con el SD-R 245, al que transmite los paquetes en el transcurso de sesiones seguras (por ejemplo, utilizando el protocolo seguro SCP81).

En la recepción, el ISD-R 245 descifra cada paquete recibido y lo transmite al ISD-P 250. Al recibirse todo o parte de los paquetes, puede comenzar el procesamiento de los elementos de perfil, que consiste principalmente en recuperar, en la memoria local, los templates actualizados referenciados por estos elementos de perfil recibidos, y escribir así en la memoria del elemento seguro los elementos del perfil reconstituido (después de la fusión). De ello resulta que el perfil queda entonces instalado (por lo tanto, cargado) en la memoria del elemento seguro.

La Figura 2 ilustra esquemáticamente un ejemplo de posible arquitectura para un elemento seguro, por ejemplo, el elemento seguro 20 de la Figura 1, o un administrador, por ejemplo, la entidad SM 330 de la Figura 1, según unos modos de realización de la invención.

Esta arquitectura 200 comprende principalmente un bus 205 de comunicación al que están conectadas:

- una unidad 210 de procesamiento (o microprocesador) denominada CPU (Central Processing Unit);

- una memoria 220 no volátil, por ejemplo, ROM (Read Only Memory), EEPROM (de Electrically Erasable Read Only Memory) o bien Flash;

- una memoria viva 230 o memoria caché o memoria volátil, por ejemplo, RAM (Random Access Memory); y

- una interfaz COM 240 de comunicación adaptada para intercambiar datos con otra entidad a través de una red o de una interfaz de lectura/escritura (p. ej., Interfaz ISO 7816).

La memoria viva 230 comprende registros adaptadas al registro de las variables y parámetros creados y modificados en el transcurso de la ejecución de un programa informático que comprende instrucciones para la implementación de un procedimiento según la invención. Los códigos de instrucción del programa guardado en memoria no volátil 220 se cargan en la memoria RAM 230 para que sean ejecutados por la unidad de procesamiento CPU 210.

La memoria no volátil 220 es, por ejemplo, una memoria reescribible de tipo EEPROM o memoria Flash que puede constituir un soporte en el sentido de la invención, es decir, que puede comprender un programa informático que comprende instrucciones para la implementación de etapas de un procedimiento según la invención.

En el marco de la invención, puede comprender concretamente la recopilación de templates guardados en el elemento seguro o en el administrador 330.

La Figura 3 representa, en forma de cronograma, etapas de un procedimiento de gestión según una realización del primer modo de realización de la invención mencionado anteriormente. Estas etapas pueden ser implementadas por los distintos elementos representados en la Figura 1, en concreto la entidad Sm 330 y la eUICC 20.

En esta realización, en el transcurso de una etapa E10, el administrador SM 330, a través de, por ejemplo, el servidor SM-DP 320, crea un nuevo perfil compuesto por elementos de perfil a los que se da formato con ayuda de uno o varios templates.

Esta etapa puede ser desencadenada por la realización (E0) de un evento desencadenante de entre el flujo de una duración predefinida al nivel del administrador, una solicitud de cambio de un nuevo perfil en la eUICC 20 recibida de un tercero, la actualización de un modelo guardado en una memoria accesible por el administrador y la caducidad de un modelo de ese tipo.

Esto incluye, por ejemplo, que la entidad SM 330 recibe una instrucción de creación y carga de un nuevo perfil en la eUICC 20. Esta instrucción, manual o automática, puede, según el caso, proceder de parte de un usuario del dispositivo anfitrión 10 o bien de un operador.

De igual modo, si un template guardado localmente por el administrador ha caducado y por tanto está potencialmente actualizado, conviene actualizar la eUICC 20 con perfiles actualizados basados en el nuevo témplate.

A título ilustrativo, se supone que se ha utilizado un solo témplate y que su versión se denomina “V10.0” para la 10a versión. Se recuerda que la noción de versión de template es una creación de los inventores para facilitar la gestión de los templates dado que cada uno de ellos se caracteriza por un único OID que permanece sin cambios cuando el template en cuestión se modifica/actualiza, por ejemplo, cuando cambia de formato.

La representación de una versión de un template está, por ejemplo, compuesta por dos números de versión separados, por ejemplo, de una coma o de un punto, que corresponde a un número de versión mayor (valor entero situado, por ejemplo, delante del punto) y de un número de versión menor (valor decimal situado, por ejemplo, después del punto).

En nuestro ejemplo, la versión del template denotada como V10.0, corresponde por tanto a un número de versión mayor “ 10” y a un número de versión menor “0” .

En el ejemplo descrito, la eUICC 20 dispone, en memoria, de la versión V9.0 del template en cuestión. Por tanto, en el ejemplo, el template guardado en memoria de la eUICC 20 corresponde a una versión más antigua que la del template de la que dispone el administrador SM 330 para crear un nuevo perfil a cargar en la eUICC 20.

Naturalmente, esto es solo un ejemplo ilustrativo, y la presente invención no se limita al mismo. Por tanto, podrían utilizarse otras versiones de templates, caracterizados por uno o varios metadata distintos (número de versión, fecha de caducidad, hash del template) asociados a los templates.

También en respuesta al evento desencadenante E0, el administrador SM 330 desea verificar la compatibilidad con la eUICC 20 señalada, del perfil creado a partir de uno o varios templates identificados por sus OID. Para ello, el administrador intenta obtener al menos una información ( metadata) representativa de una versión de template para al menos estas templates identificadas por los OID anteriores y guardadas en la eUICC 20. Esta etapa puede realizarse en paralelo con la etapa E10, o antes de la misma.

Para ello, en el transcurso de una etapa E20, el administrador SM 330 genera y envía a la eUICC 20 una solicitud de auditoria que busca obtener, en respuesta, esta información. Esta solicitud de auditoria puede adoptar la forma de un comando denominado en la presente memoria TEMPLATE AUDIT REQUEST.

Como se describe más adelante, tal comando permite obtener información, correspondiente a todo o parte de los metadata asociados a uno, varios o todos los templates guardados en la eUICC 20.

Este comando TEMPLATE AUDIT REQUEST es una creación de los inventores, por lo que SIMALLIANCE no lo describe.

La notación ASN.1 (de Abstract Syntax Notation One, en inglés), permite una descripción estandarizada de estructura de datos, y se elige aquí para presentar el formato del comando creado, así como para los datos que lo componen.

Así, por ejemplo, se propone el siguiente formato para describir el comando TEMPLATE AUDIT REQUEST utilizado:

TemplateAuditRequest ::= SEQUENCE {

templateARF [PRIVATE 109] SEQUENCE OF AuditRequestFilter }

Se trata, por tanto, de un comando que consta de una secuencia de uno o varios elementos templateARF en el formato AuditRequestFilter. El elemento templateARF define la información ( metadata) deseada para uno o varios templates objeto de la auditoria.

En detalle, el formato AuditRequestFilter de tal elemento puede ser el siguiente:

AuditRequestFilter ::= SEQUENCE {

templateID OBJECTIDENTIFIER OPTIONAL,

templateRTI requestedTemplateInformation }

Se trata, una vez más, de una secuencia en la que el primer elemento templateID identifica uno o varios templates objeto de la auditoria, y el segundo elemento templateRTI lista la información ( metadata) deseada relacionada con las templates identificadas a través del elemento templateID considerado.

A título de ejemplo meramente ilustrativo, una solicitud puede contener la siguiente secuencia de templateARF, relativa a una solicitud correspondiente a distintos templates (OID_1, OID_42, OID_13, OID_54, OID_5, OID_8) o para todos ellos:

{

[OID_1],

[templateMajor-version,

templateExpirationDate],

[OID_42, OID_13, OID_54],

[templateMajor-Version,

templateMinor- Versión,

templateExpirationDate],

[OID_5],

[],

[OID_8],

[templateMinor- Version]

[],

[templateHash] }

En concreto, el campo templateID puede comprender una lista de identificadores OID que identifican de forma única plantillas para las que se pide la información de metadatos. Por lista se debe entender que al menos un OID figura en la misma. Es, por ejemplo, el caso del primer bloque del ejemplo anterior que lista el único OID OID_1, pero también del segundo bloque que lista los OID OID_42, OID_13 y OID_54.

En determinados modos de realización, pueden utilizarse OID de “grupos” y ser conocidos por el administrador y por los elementos seguros. Un OID de grupo permite, por ejemplo, designar una familia de template con ayuda de un solo OID. En determinados modos de realización, la ausencia de OID en el campo templateID (es decir, una lista vacía) define implícitamente que se señalan todos los templates guardados en la eUICC 20. Es el caso del último bloque del ejemplo anterior.

En cuanto al campo templateRTI, este enumera la distinta información ( metadata) deseada en respuesta, para cada uno de los templates listados en el campo templateID correspondiente.

En un modo de realización, si en este campo no se indica ninguna información (campo vacío, por ejemplo), este último puede definir implícitamente que se desea el retorno del conjunto de metadata del o de los templates considerados. Es, por ejemplo, el caso del tercer bloque del ejemplo anterior que se aplica al OID_5.

A título ilustrativo, el campo templateRTI puede estar compuesto por el elemento requestedTemplateInformation , descrito a continuación, para listar la distinta información solicitada:

requestedTemplateInformation::= SEQUENCE {

templateMajor- Version UInt8 OPTIONAL,

templateMinor- Version UInt8 OPTIONAL,

templateExpirationDate DATE OPTIONAL,

templateHash OCTET STRING OPTIONAL }

En este ejemplo se trata de una lista que define si se desea un número de versión del o de los modelos implicados y/o una fecha de caducidad del o de los modelos implicados y/o un valor de hash calculado a partir de cada modelo.

Concretamente, templateMajor-Version es un campo que, cuando está situado en el comando, indica que se desea el número de versión principal denominado mayor (por ejemplo, de tipo entero sin signo (UInt8)) del o de los templates señalados (en el campo template ID).

Si, por ejemplo, el template señalado está en versión v1.3, el valor que se proporciona el campo templateMajor-Version es 1.

templateMinor-Version es un campo que, cuando está situado en el comando, indica que se desea el número de subversión (por ejemplo, de tipo entero sin signo (UInt8)) del o de los templates señalados.

Si, por ejemplo, el template señalado está en versión v1.3, el valor que se proporciona para el campo templateMinor-Version es 3.

templateExpirationDate es un campo que, cuando está situado en el comando, indica que se desea la fecha de caducidad del o de los templates señalados.

templateHash es un campo que, cuando está situado en el comando, indica que se desea el valor de hash/huella vinculado a cada uno de los templates señalados.

El comando TEMPLATE AUDIT REQUEST permite por tanto solicitar una o varias informaciones ( metadata) relativas a uno o varios templates guardados en la memoria de la eUICC 20. El campo requestedTemplateInformation define esta información deseada, mientras que el campo templateID define el o los templates señalados.

Cabe señalar que un comando TEMPLATE AUDIT REQUEST al que se ha dado formato con una lista de informaciones deseadas ( requestedTemplateInformation ) vacía solicita toda la información (metadata) de al menos un template señalado, como referenciado en la lista no vacía templateID.

Un comando TEMPLATE AUDIT REQUEST al que se ha dado formato con una lista de identificación de templates (templateID) vacía solicita la al menos una información ( metadata) referenciada en la lista no vacía requestedTemplateInformation , para todos los templates guardados en memoria de la eUICC 20.

Por último, un comando TEMPLATE AUDIT REQUEST al que se haya dado formato con una lista de identificación de templates (templateID) vacía y una lista de información deseada (requestedTemplateInformation) vacía solicita por tanto toda la información ( metadata) para todos los templates guardados en memoria de la eUICC 20. La lista de los campos mencionados anteriormente no es limitativa en absoluto, pudiendo preverse otros campos. Por ejemplo, pueden preverse otros campos que definan la información deseada en los metadata asociados a los templates para que varíe la información solicitada.

Para que la eUICC 20 pueda comprender el comando TEMPLATE AUDIT REQUEST, este última, representada anteriormente con el formato ASN.1, es convertida, antes de su envío, por el administrador SM 330 a un formato comprensible para la eUICC. Por ejemplo, se convierte en un comando de tipo parte 4 según la descripción de la norma ISO7816-4 (por ejemplo, en un comando GET DATA de la norma GlobalPlatform), basado en una estructura de TLV (de Tag Length Value, en inglés).

El comando GET DATA representativo de la solicitud de auditoria TEMPLATE AUDIT REQUEST es así enviado por el administrador a la eUICC 20, que lo recibe.

En el transcurso de una etapa E30, la solicitud que comprende el comando GET DATA, correspondiente a una representación utilizable por el ISD-R de la descripción ASN.1 del comando TEMPLATE a Ud IT REQUEST (templateAuditRequest), es procesada por el SD-R de la eUICC 20.

El procesamiento comprende la recuperación de los templates guardados localmente que son identificados por los OID del campo o campos templateID de la solicitud, y luego, la recuperación de la información solicitada tal como se identifica en el o los campos templateRTI correspondientes. Como se ha indicado anteriormente, se trata, por ejemplo, de la versión principal y/o la subversión y/o la fecha de caducidad y/o el valor de hash de cada témplate señalado.

Esta información se compila en una respuesta al comando GET DATA. Al igual que la solicitud TEMPLATE AUDIT REQUEST, esta respuesta dedicada es una creación de los inventores. A título ilustrativo, esta respuesta denominada TemplateAuditResponse puede estructurarse como sigue, descrita en formato ASN.1:

TemplateAuditResponse::= SEQUENCE {

templateList SEQUENCE OF TemplateOT,

constructorID OBJECTIDENTIFIER OPTIONAL,

templateSignature OCTET STRING OPTIONAL }

Se trata de una lista en la que una primera parte es una secuencia de uno o varios campos o elementos, templateList, en el formato TemplateOT (descrito a continuación) que listan, cada uno de ellos, un identificador de témplate (OID) señalado por el comando TEMPLATE AUDIT REQUEST y finalmente encontrado en la eUICC 20, así como la información solicitada asociada. Concretamente, si la solicitud de auditoria no indica templates particulares (lista templateID vacía) y/o información solicitada particular (lista requestedTemplateInformation vacía), esta secuencia de templateList permite identificar cada témplate guardado en la eUICC 20 y la información proporcionada.

Si no está presente algún témplate señalado en la eUICC 20 (por ejemplo, la eUICC no tiene ningún témplate), entonces no se proporciona ninguna información en la respuesta. De manera más general, si un témplate señalado no está en la memoria de la eUICC, no se proporciona ninguna información correspondiente en un campo templateList de la respuesta. Esto permitirá al administrador saber qué templates faltan (con respecto a la lista señalada).

A continuación, se propone un ejemplo de representación ASN.1 del elemento TemplateOT:

TemplateOT ::= SEQUENCE {

templateID OBJECT IDENTIFIER,

templateContent OCTET STRING OPTIONAL,

templateMajor-Version UInt8 OPTIONAL,

templateMinor-Version UInt8 OPTIONAL,

templateExpirationDate DATE OPTIONAL,

templateHash OCTET STRING OPTIONAL }

Se trata de una lista para un témplate particular (identificado por el campo templateID que indica el OID correspondiente) que detalla la información solicitada para este template: templateMajor-Version (número de versión principal denominado mayor), templateMinor-Version (número de subversión), templateExpirationDate (fecha de caducidad) y/o templateHash (valor de hash o huella).

El campo templateContent (descrito más adelante en relación con el comando de actualización de un template) no se utiliza en el comando TEMPLATE AUDIT REQUEST. Podría suprimirse de esta descripción de la solicitud de auditoria. No obstante, en aras de una mayor compacidad, se elige utilizar el mismo formato TemplateOT en esta solicitud y en el comando de actualización de un template descrito a continuación.

Por supuesto, también se puede solicitar otra información cuando se prevea la misma (como los metadatos asociados a los templates).

Los otros campos, constructorID y templateSignature , de la respuesta TEMPLATE AUDIT RESPONSE son opcionales y permiten autentificar la respuesta procedente de la eUICC 20.

Concretamente, el campo constructorID puede comprender un identificador del constructor de la eUICC 20. Esta información puede permitir al administrador identificar, por ejemplo, desde qué servidor o constructor conviene recuperar la actualización de templates para la eUICC considerada.

El campo templateSignature puede contener una firma criptográfica de la respuesta TemplateAuditResponse.

Puede ser una firma en el conjunto de la respuesta o en la información proporcionada (concretamente la secuencia de campos templateList), utilizando, por ejemplo, una clave de cifrado del ISD-R según un modo de clave privada /clave pública. El administrador SM 330 (por ejemplo, SM-SR o SM-DP) puede verificar entonces la firma recibida. Esta verificación permite también autentificar el origen del template y/o de los metadata proporcionados.

La respuesta TEMPLATE AUDIT RESPONSE permite también suministrar, al administrador SM 330, el conjunto de la información asociada a los templates señalados por la solicitud de auditoria que la eUICC guarda en la memoria. Puede suceder que la eUICC 20 no disponga de determinados templates señalados por la solicitud, en cuyo caso la respuesta no proporciona ninguna información sobre estos.

Una vez elaborada, la respuesta TEMPLATE AUDIT RESPONSE es enviada por la eUICC 20 al administrador SM 330 en el transcurso de una etapa E40, permitiendo a este último obtener una información representativa de una versión de un modelo de elemento de perfil guardado en memoria del elemento seguro, o más.

En la recepción, el administrador SM 330 comprueba eventualmente la firma de la respuesta con ayuda de la clave de cifrado mencionada anteriormente para validar la autenticidad de la respuesta.

Luego, en el transcurso de una etapa E50, el administrador SM 330 compara la información recibida con información asociada al template o a los templates que se han utilizado para crear el nuevo perfil a cargar en la etapa E10. Esta comparación permite determinar si existe una diferencia de versión entre cada versión de template obtenida por la información recibida y una versión del mismo template (es decir, con el mismo identificador OID) almacenado en una memoria accesible por el administrador y utilizado para genera el perfil en la etapa E10,

En un modo de realización, la comparación se basa en un número de versión asociado al template considerado. Cabe señalar que dos templates referenciados por el mismo OID, pero con versiones principales distintas (por ejemplo, V1.1 para uno de los templates (ya sea, un templateMajor-version situado en 1) y V2.1 para el otro (ya sea un templateMajor-version situado en 2)) son incompatibles, es decir, que los datos a los que se da formato con uno de estos templates no se pueden comprender con la ayuda del otro template (por ejemplo, la longitud de un dato del template considerado ha pasado a ser distinta de una versión a otra). En ese caso puede instaurarse una actualización del template.

Sin embargo, dos templates referenciados por el mismo OID, que tengan una misma versión principal, pero subversiones distintas (por ejemplo, V1.1 para uno de los templates (ya sea un templateMinor-version en 1) y V1.2 para el otro (ya sea un templateMinor-version en 2)) pueden ser retrocompatibles, es decir, que los datos formateados con uno de estos templates se pueden comprender con la ayuda del otro template, incluso aunque puedan aparecer errores debidos al hecho, por ejemplo, de una diferencia del valor de los datos del template (por ejemplo, modificación de un valor guardado en un archivo o bien, por ejemplo, modificación de un parámetro utilizado para realizar una autentificación). Aquí también puede instaurarse una actualización.

El administrador SM 330 puede por lo tanto recuperar el número de versión principal y/o el número de subversión del template utilizado para la creación del perfil durante la etapa E10 (V10.0 en el ejemplo de la Figura 3), recuperar asimismo el número de versión principal y/o subversión del mismo template (mismo OID) que el proporcionado en la respuesta TEMPLATE AUDIT RESPONSE recibida en la etapa E40 (V9.0 en el ejemplo de la Figura 3), y seguidamente comparar estos números entre sí.

En el ejemplo de la Figura 3 , el administrador SM 330 es así capaz de determinar la existencia de una diferencia de versiones.

En otro modo de realización, la comparación se basa en la fecha de caducidad asociada a los templates.

Normalmente, el administrador SM 330 dispone, en memoria, de las últimas versiones de los templates, ya que es más fácil actualizar el administrador que una multitud de eUICC diseminadas aquí y allá.

La comparación E50 puede comparar directamente la fecha de caducidad (actualizada) del template utilizado para la creación del perfil en la etapa E10 con la del mismo template (mismo OID) suministrado en la respuesta TEMPLATE AUDIT RESPONSE recibida en la etapa E40.

De manera más simple, el administrador SM 330 puede simplemente comparar la fecha de caducidad recibida en la respuesta TEMPLATE AUDIT RESPONSE con el momento presente, para determinar directamente si se ha sobrepasado, alcanzado o no alcanzado la fecha de caducidad recibida.

En otro modo de realización, la comparación se basa en el valor de hash asociado a los templates.

El valor de hash permite detectar por sí mismo una diferencia global entre dos templates (el utilizado para crear el perfil a cargar y el otro almacenado en la eUICC) y permite por tanto determinar que existe una diferencia de versión entre estos templates. Permite también garantizar la integridad de los templates en su conjunto ( metadata y contenido) así como poder detectar, de forma más fina, una diferencia potencial global al nivel del contenido de ambos templates (referenciados por el mismo OID).

En la práctica, el administrador SM 330 calcula el valor de hash para el template utilizado para crear el nuevo perfil en la etapa E10, o lo recupera si ya está disponible (por ejemplo, en los metadatos asociados a este template).

Seguidamente el administrador compara este valor de hash con el contenido en la respuesta TEMPLATE AUDIT RESPONSE para el mismo template (con el mismo OID).

De forma más avanzada, el número de la versión principal y/o de la subversión y/o la fecha de caducidad y/o el valor de hash del template permite garantizar una granularidad más fina en cuanto a la comparación de ambos templates con un mismo OID (uno utilizado para crear el perfil a cambiar, y otro guardado en la eUICC) y por tanto en cuanto a la deducción de al menos una diferencia de versión entre ambos.

En efecto, la comparación del valor de hash asociado a la comparación de uno u otros valores ( metadata) entre los proporcionados detectar ventajosamente dónde está la diferencia entre dos templates que tengan el mismo OID, ya sea en uno de los metadata asociados a los templates, ya sea en su contenido.

También, una determinación de una diferencia de versión puede basarse en información de distintas naturalezas.

En la etapa E50, el administrador SM 330 determina así si existe una diferencia entre un template utilizado para la creación del nuevo perfil y el template con el mismo OID en la eUICC. Por supuesto, esta operación se lleva a cabo para cada template utilizado para la creación del nuevo perfil.

Si la eUICC 20 no suministrara información sobre un template señalado por la solicitud de auditoria (generalmente porque no tiene una versión en memoria), el administrador SM 330 detecta automáticamente una diferencia de versión.

Si no se observa ninguna diferencia de versión en la etapa E50 a partir de la información recibida en E40, el procedimiento va directamente a una etapa E100 que se describirá más adelante.

En un modo de realización, el administrador SM 330 puede determinar, a partir de la información recibida, si una eventual diferencia de versión es mínima, es decir, ofrece una compatibilidad de funcionamiento satisfactoria (no suficientemente distinta para que haya problemas en el procesamiento del elemento de perfil correspondiente, que impidan la instalación o la ejecución de un nuevo perfil). Este es el caso, por ejemplo, si ambos templates difieren únicamente en una subversión. En ese caso, el template en la eUICC 20 puede no estar actualizado y el procedimiento prosigue directamente a la etapa E100.

Sin embargo, si se detecta una diferencia importante de versión, la versión del template en la eUICC 20 no es compatible con el perfil creado y que se va a cargar. Esta situación requiere entonces la actualización del template presente en la eUICC. Esta actualización puede consistir en actualizar al menos uno de los metadata y/o el contenido del template señalado.

Por otra parte, en caso de ausencia en memoria de la eUICC 20, de una versión del template señalado, el administrador SM 330 puede entonces decidir cargar ese template en la eUICC 20. Esta carga es asimismo una actualización del template.

De este modo, en el transcurso de la etapa E60, el administrador SM 330 prepara la actualización del template. En este marco, el administrador SM 330 puede recuperar eventualmente de forma preliminar el template actualizado desde un servidor dedicado del constructor que se ha indicado en el parámetro constructorID proporcionado en la respuesta TEMPLATE AUDIT RESPONSE. Esta preparación E60 comprende la generación de uno (o varios) comandos de actualización para actualizar el template en la eUICC.

Por supuesto, se llevan a cabo varias actualizaciones si la respuesta TEMPLATE AUDIT RESPONSE permite identificar varias diferencias de versión importante entre los templates utilizados para crear el nuevo perfil a cambiar y los templates correspondientes utilizados en la eUICC 20.

Por ejemplo, la descripción, según el formato ASN.1, del comando genérico de actualización puede ser el siguiente: StoreDataTemplateUpdate ::= SEQUENCE {

templateTU[PRIVATE 109] TemplateUpdate }

Se trata por tanto de un comando que consta de un único campo templateTU con el formato TemplateUpdate. El campo templateTU identifica uno o varios templates (a través de sus OID) y proporciona datos/información de actualización (un dato constituye al menos un parámetro de los metadata del témplate y/o un dato de contenido del témplate).

En detalle, el formato TemplateUpdate de tal campo puede ser el siguiente:

TemplateUpdate ::= SEQUENCE {

templateToUpdate SEQUENCE OF TemplateOT,

templateSignature OCTET STRING OPTIONAL }

Se trata de una lista en la que una primera parte es una secuencia de uno o varios campos templateOT descrita más arriba que forman el elemento templateToUpdate.

Cada campo corresponde a un template (identificado por su OID en el templateID ) y proporciona información de actualización que incluye todo o parte del contenido mismo del template ( templateContent ), del número de versión principal denominado mayor (templateMajor-Version), del número de subversión (templateMinor-Version), de la fecha de caducidad (templateExpirationDate) y del valor de hash o huella (templateHash).

El contenido templateContent del template que forma parte de los campos constitutivos de TemplateOT, es el propio modelo, es decir, el conjunto de datos o valores que describen, por defecto, un elemento de perfil, por ejemplo, tamaño de un archivo, longitud de un registro, valor de un parámetro, ... En el contexto del ejemplo de la Figura 3 , se puede tratar de datos y valores del modelo V10.0. Como variante, únicamente se envían las modificaciones de datos y valores entre la versión V9.0 (de la eUICC) y la versión V10.0. En un modo de realización con actualización, de todos o parte de los metadata y del contenido, el valor de hash siempre está presente. En efecto, el cálculo de este valor depende del valor de los metadata y del contenido del template, por lo que, si hay algún cambio, el valor de hash preferiblemente se recalcula y forma parte de la actualización para que este último se acepte durante el control, por parte de la eUICC, del valor de hash teniendo en cuenta este cambio. También, los números de versión principal y de subversión generalmente se actualizan cuando se modifica el contenido del template. Se ofrece la posibilidad de poder actualizar únicamente la fecha de caducidad acompañada del nuevo valor de hash del template inherente a esta actualización de la fecha de caducidad.

El siguiente campo, templateSignature, contiene una firma criptográfica eventual del comando de actualización. Se calcula, por ejemplo, en el conjunto del campo templateToUpdate con la ayuda de una clave de cifrado del administrador SM 330 según un modo de clave privada/clave pública. Esta firma permite a la eUICC destinataria del comando de actualización autentificar el origen de los datos recibidos (del template o de los templates considerados).

Para que la eUICC 20 pueda comprender el comando de actualización, este último, representado anteriormente con el formato ASN.1, es convertido, antes de su envío, por el administrador SM 330 a un formato comprensible por la eUICC. Por ejemplo, se convierte en un comando de tipo STORE DATA de la norma GlobalPlatform, basado en una estructura TLV (de Tag Length Value, en inglés).

Según sea la longitud de los datos del comando de actualización (repetición de varias estructuras, cada una de ellas con un OID y la información/contenido de actualización del template considerado), pueden utilizarse uno o varios comandos STORE DATA. Por ejemplo, puede utilizarse un comando STORE DATA para cada template.

En el caso particular en el que la respuesta TEMPLATE AUDIT RESPONSE permita identificar que falta un template en el mapa (aplicable a varios templates faltantes), el comando de actualización consiste, de hecho, en un comando de creación de este template faltante. Se utiliza el mismo comando STORE DATA.

El comando STORE DATA que representa el comando de actualización también es enviado a la etapa E70 por el administrador a la eUICC 20, que lo recibe. Este envío es realizado, por ejemplo, a través de un OTA basado (por ejemplo) en el protocolo de transporte seguro SCP080 en caso de uso del protocolo de comunicación SMS (“Short Message Service” ), o basado en el protocolo de transporte seguro SCP081 en caso de uso de un protocolo de comunicación HTTPs.

El comando de actualización entra en el ámbito de una gestión remota del elemento seguro, que puede ser de tipo RAM (“ Remóte Application Management’), o RFM (“ Remóte File Management’).

En el transcurso de una etapa E80, la eUlCC 20 recibe, por tanto, el o los comandos de actualización (STORE DATA) y los ejecuta del modo habitual. Es la actualización de o de los templates propiamente dicha.

La ejecución puede comprender concretamente la verificación de la firma templateSignature para garantizar el origen del comando (o de los comandos) de actualización recibida.

La ejecución también puede comprender la verificación de la integridad y origen de los distintos datos e informaciones que constituyen cada campo d e le l e m e n t o templateOT que constituye el elemento templateToUpdate . Para ello, la eUICC puede calcular su propio valor de hash en base a los datos e información recibidos y contenidos en un elemento templateOT considerado, completados por los actualmente guardados en memoria y relacionados con un mismo OID, si una parte de los datos y de la información no están presentes en los campos del elemento templateOT considerado del elemento templateToUpdate recibido. Seguidamente la eUICC la compara con el valor de hash recibido por este mismo elemento templateOT representativo de un témplate considerado. De este modo, si ambos valores de hash no son idénticos, el témplate considerado (es decir, el elemento templateOT considerado que constituye el elemento templateToUpdate ) es rechazado por la eUICC, sin que los demás elementos templateOT que también constituyen el elemento templateToUpdate sean necesariamente rechazados (si su verificación por valor de hash es correcta). De igual modo, si un valor de hash no forma parte de la información recibida para un campo templateOT considerado, este último será rechazado por la eUICC.

En el ejemplo de la Figura 3 , la etapa E80 permite a la eUICC actualizar la plantilla considerada (inicialmente en la versión V9.0) en su versión V10.0.

Una vez realizada la (o las) actualizaciones, la eUICC envía una confirmación (etapa E90) al administrador SM 330.

En el transcurso de la etapa E100, el administrador SM 330 envía el script de instalación del nuevo perfil creado en E10 a partir del template en versión V10.0.

En la práctica, los elementos de perfiles enviados se cargan secuencialmente en la eUICC 20 (etapas E110), y el perfil se constituye fusionando, si procede, los elementos de perfiles recibidos con el template V10.0 actualizada en E80 (y cualquier otro template guardado en la eUICC, eventualmente actualizado según las enseñanzas de la invención), y se instala (etapa E120). Estas etapas de carga de perfil son clásicas.

En el transcurso de una etapa E130, la eUICC 20 informa al administrador SM 330 que la instalación del perfil se ha realizado con éxito.

Los ejemplos anteriores se basan, para simplificar, en un solo template (de versión V10.0) utilizado durante la creación del perfil en la etapa E10. No obstante, la invención no se limita a un único template, y cubre los casos donde se utilizan varios templates (y por tanto contemplados en la solicitud de auditoria y eventualmente actualizados). Para el experto en la técnica es fácil aplicar las enseñanzas anteriores en caso de que haya varios templates. Los comandos descritos en el presente documento están previstos, por otra parte, para uno o varios templates (uno o varios OID).

En los ejemplos anteriores, el administrador SM 330 envía una solicitud de auditoria como reacción a un evento desencadenante.

La presente invención también se refiere a otros modos de realización que no implican el uso de una solicitud de auditoria.

Por ejemplo, la eUICC 20 puede enviar espontáneamente la respuesta TEMPLATE AUDIT RESPONSE al administrador SM 330, por ejemplo, a intervalos regulares. En la práctica, la eUICC 20 puede obtener una referencia temporal del equipo anfitrión 10 en la que basar la periodicidad de envío de tal respuesta. Por ejemplo, la eUICC 20 puede convenir con el equipo anfitrión 10 un envío periódico de comandos (por ejemplo, comandos “status” ) que cuando se reciben, hacen que la eUICC 20 incremente un contador de referencia temporal. Cuando el contador llega al final de un nuevo periodo prefijado, la eUICC construye espontáneamente la respuesta TEMPLATE AUDIT RESPONSE con información sobre el conjunto de templates que contiene en la memoria.

Según otra variante, la eUICC 20 envía espontáneamente una notificación al administrador SM 330, mediante una respuesta TEMPLATE AUDIT RESPONSE, cuando se producen eventos concretos como, por ejemplo, la actualización del OS ( “ Operating System”) de la eUICC o incluso el vencimiento de determinados templates (es decir cuando se alcanza o sobrepasa su fecha de caducidad).

La actualización del OS puede estar ordenada por el administrador SM 330.

En este modo particular de actualización del OS, el envío de la respuesta TEMPLATE AUDIT RESPONSE por la eUICC es en respuesta a una etapa previa de actualización, por parte del administrador, del sistema operativo de la eUICC.

En una realización, la respuesta TEMPLATE AUDIT RESPONSE contiene información sobre cada témplate que la eUlCC tiene en memoria, dado que el administrador no ha podido indicar a la eUICC qué templates son de interés.

Como variante, la respuesta TEMPLATE AUDIT RESPONSE contiene información sobre los únicos templates que la eUICC contiene en memoria y que se han actualizado al mismo tiempo que el sistema operativo.

Para hacerlo, la eUICC 20 puede almacenar en memoria, previamente a la actualización del OS, la información de metadata (OID y/o versiones mayores y/o versiones menores y/o fechas de caducidad y/o valor de hash) de los templates guardados en memoria de la eUICC. Seguidamente, una vez realizada la actualización del OS, la eUICC lleva a cabo una comparación entre la información de los metadata de los templates que se encuentran guardados en memoria de esta última y la información de metadata correspondiente tales como las memorizadas antes de la actualización del OS. Esta comparación permite identificar fácilmente los templates que se han modificado en la actualización del OS.

En un modo de realización particular, el evento relativo a la actualización del OS puede combinarse con otro evento para desencadenar el envío (espontáneo) de la respuesta TEMPLATE AUDIT RESPONSE por parte de la eUICC. Por ejemplo, este otro evento puede comprender una primera conexión o autentificación de red después de la actualización del OS, o bien un evento de tipo toolkit, o incluso cualquier otro tipo de evento.

También, según otra variante del primer modo de realización descrito anteriormente, en el que la eUICC 20 dispone de una versión [V9.0] de template más reciente que el administrador SM 330 [V8.0], la actualización E80 del template puede consistir en instalar una versión antigua del template en la eUICC (en este caso V8.0). Esto permite, cuando el administrador SM 330 ya ha calculado el nuevo perfil a cambiar a partir de la antigua versión del template, no tener que volver a calcular el perfil. A continuación, podría preverse una actualización posterior del template en el servidor y/o en la eUICC.

La Figura 4 representa, en forma de cronograma, etapas de un procedimiento de gestión según un segundo modo de realización de la invención. Estas etapas pueden ser implementadas por los distintos elementos representados en la Figura 1, en concreto el administrador SM 330 y la eUICC 20.

En este ejemplo, las etapas similares a las del ejemplo de la Figura 3 llevan referencias numéricas idénticas. También, salvo que se especifique lo contrario, es necesario referirse a la Figura 3 en lo que respecta a la descripción de estas etapas. Al igual que en el caso anterior, la eUICC guarda un template de elemento de perfil en versión V9.0. En cuanto al administrador SM 330, puede no guardar ningún template correspondiente (es decir, que tenga el mismo OID) o bien guardar un template correspondiente en otra versión, por ejemplo, V10.0.

En este segundo modo de realización, el procedimiento comprende el envío de una solicitud TEMPLATE AUDIT REQUEST por parte del administrador SM 330 a la eUICC 20 (etapa E20), el procesamiento de la solicitud en la eUICC (etapa E30) y la recepción de una respuesta TEMPLATE AUDIT RESPONSE procedente de la eUICC 20, por parte del administrador SM 330 (etapa E40). Las explicaciones proporcionadas anteriormente (Figura 3) en relación con estas etapas también son aplicables aquí.

Por otra parte, también pueden contemplarse variantes basadas en el envío espontáneo de la respuesta TEMPLATE a Ud IT RESPONSE para la eUICC 20 (a intervalos regulares, tras una actualización del OS, eventualmente en combinación con otro evento).

Si el administrador SM 330 ya dispone en memoria de un template que tenga el mismo OID que el que aparece en la respuesta recibida, puede comparar, en la etapa E50, la información recibida con la información asociada al template que ya tiene en memoria. Esta etapa permite determinar si existe una diferencia de versión entre los dos templates. Naturalmente, la etapa E50 es realizada por el conjunto de templates para los que se proporciona información en la respuesta.

Esta etapa es opcional en el sentido de que el administrador SM 330 puede no disponer de un tal template en memoria o puede hacer caso omiso y realizar la etapa E55 aun cuando un template correspondiente ya esté en la memoria.

Cabe señalar que la ausencia de template en la memoria corresponde implícitamente a la detección de una diferencia de versión entre el template guardado en la eUICC y el (hipotético) correspondiente almacenado en el administrador.

En el transcurso de una etapa E55 realizada tras la recepción de la respuesta de auditoria (E40), es decir, tras una diferencia de versiones detectada en la etapa E50, el administrador SM 330 trata la información recibida para identificar la versión del template guardado en la eUICC 20, en este caso V9.0. Seguidamente el administrador SM 330 recupera esta misma versión de template, por ejemplo, de su propia memoria o de una base de datos interna o externa o bien de un servidor, por ejemplo, el servidor dedicado del constructor de la eUICC identificado por el valor del campo constructorID de la respuesta. Lo guarda entonces en memoria, en sustitución del eventual témplate (con el mismo OID) que ya había en memoria.

Naturalmente, esta etapa se realiza para el conjunto de templates para los que se proporciona una información en la respuesta o para el conjunto de templates para los que se determina una diferencia de versión en la etapa E50. En el transcurso de una etapa E65, similar a la etapa E10 descrita en relación con la Figura 3 , el administrador SM 330 puede entonces crear un nuevo perfil compuesto por elementos de perfil a los que se ha dado formato con la ayuda de templates que tienen las mismas características ( metadata y contenido) que los presentes en la eUICC. En nuestro ejemplo, el administrador SM 330 genera un nuevo perfil del que se crea un elemento de perfil por referencia al template en versión V9.0. Ventajosamente, el perfil al que se ha dado formato de este modo está adaptado al o a los template(s) presente(s) en la eUICC 20.

Las siguientes etapas consisten en la transmisión del perfil a la eUICC 20 a través del administrador SM 330 (etapas E100, E110) y en su instalación con ayuda de los templates (el template V9.0 en nuestro ejemplo) guardados en la eUICC 20 (etapa E120). A continuación, se informa al administrador SM 330 del buen desarrollo de la instalación (etapas E130).

En este segundo modo de realización, la actualización del template en caso de diferencia de versión se produce al nivel del administrador 330 (por sustitución del antiguo template o por carga del template si el administrador no tenía ya otra versión) y antes de la etapa de generación del nuevo perfil. Permite la correspondencia entre el template actualizado y la versión en la eUICC (y por tanto la indicada en la última respuesta recibida por el administrador) cuando decide crear el nuevo perfil. De este modo, el nuevo perfil a cargar en la eUICC se genera a partir del template actualizado.

Los ejemplos anteriores son tan solo modos de realización de la invención sin carácter limitativo.

Claims

REIVINDICACIONES

1. Procedimiento de carga de un perfil en memoria de un elemento seguro (20), que consta, al nivel de un servidor remoto (310, 320, 330) del elemento seguro, de las siguientes etapas:

recibir (E40), del elemento seguro, una información representativa de una versión de un modelo de elemento de perfil guardado en memoria (220, 230) del elemento seguro,

comparar la información recibida con información asociada a un mismo modelo guardado en memoria del servidor remoto para generar un nuevo perfil, para determinar (E50) una diferencia de versión del modelo,

en caso de determinación de una diferencia, enviar (E70) al elemento seguro un comando de actualización (E80) del modelo guardado en memoria del elemento seguro o actualizar (E55) el modelo guardado por el administrador, para alinear sus versiones,

generar (E10, E65) un perfil que incluye un elemento de perfil al que se da formato con ayuda del modelo guardado por el servidor remoto, en su versión alineada, y

con posterioridad a la etapa de actualización, enviar (E100, E110), al elemento seguro, el perfil generado.

2. Procedimiento según la reivindicación 1, que además comprende una etapa (E20) de envío de una solicitud que comprende un comando para recibir, en respuesta (E40), dicha información.

3. Procedimiento según la reivindicación 1, en donde la etapa (E40) de recepción de dicha información es en respuesta a una etapa previa de actualización, por el servidor remoto, de un sistema operativo del elemento seguro.

4. Procedimiento según una cualquiera de las reivindicaciones 1 a 3, en donde dicha etapa (E50) de determinación de una diferencia comprende la determinación de una diferencia entre la información obtenida del modelo guardado en memoria del elemento seguro (20) y la versión del modelo utilizado para generar el perfil a enviar.

5. Procedimiento según una cualquiera de las reivindicaciones 1 a 3, en donde, durante la etapa de actualización (E55), el modelo guardado por el servidor remoto (310, 320, 330) se hace corresponder con la versión del modelo obtenido del elemento seguro, de modo que el perfil a enviar se genere con la ayuda del modelo actualizado.

6. Procedimiento de carga de un perfil en memoria de un elemento seguro (20), que consta, al nivel del elemento seguro, de las siguientes etapas:

enviar (E40), a un servidor remoto (310, 320, 330), una información representativa de una versión de un modelo de elemento de perfil guardado en memoria (220, 230) del elemento seguro,

en respuesta a este envío (E40), recibir y ejecutar (E80) un comando de actualización del modelo de elemento de perfil guardado en memoria, enviado (E70) por el servidor remoto, con posterioridad a la etapa de actualización (E80), recibir (E110) un perfil a cargar enviado por el servidor remoto, incluyendo el perfil a cargar al menos un elemento de perfil al que se ha dado formato con ayuda del modelo guardado en memoria, y

cargar e instalar (E120), en memoria, el perfil recibido por fusión con el modelo guardado con cuya ayuda se da formato al perfil.

7. Procedimiento según la reivindicación 6, en donde la etapa (E40) de envío de dicha información por el elemento seguro es en respuesta a la recepción de una solicitud (E20) emitida por el servidor remoto (310, 320, 330), que comprende un comando para obtener, en respuesta, dicha información.

8. Procedimiento según la reivindicación 6, en donde la etapa (E40) de envío de dicha información por el elemento seguro es en respuesta a una etapa previa de recepción de un comando de actualización, enviado por el servidor remoto, del sistema operativo del elemento seguro y de actualización de dicho sistema operativo.

9. Procedimiento según la reivindicación 8, en donde el elemento seguro (20) envía dicha información representativa de una versión de modelo de elemento de perfil para cada modelo guardado en memoria (220, 230) del elemento seguro o únicamente para cada modelo guardado en memoria (220, 230) del elemento seguro que se ha modificado durante la actualización previa del sistema operativo.

10. Procedimiento según una cualquiera de las reivindicaciones 1 a 9, en donde la información representativa de una versión del modelo de elemento de perfil comprende uno o varios de entre: un número de versión de dicho modelo, una fecha de caducidad de dicho modelo y un valor de hash calculado a partir de dicho modelo.

11. Soporte de información legible por un microprocesador, que comprende instrucciones de un programa de ordenador para implementar un procedimiento según una cualquiera de las reivindicaciones 1 a 10 cuando el microprocesador las carga y ejecuta.

12. Administrador (310, 320, 330) de perfil para la personalización de un elemento seguro (20) por carga de perfil, comprendiendo el administrador al menos un microprocesador (210) configurado para:

recibir, del elemento seguro, una información representativa de una versión de un modelo de elemento de perfil guardado en memoria (220, 230) del elemento seguro (20),

comparar la información recibida con información asociada a un mismo modelo guardado en memoria del administrador para generar un nuevo perfil, para determinar una diferencia de versión del modelo.

en caso de determinación de una diferencia, enviar al elemento seguro un comando de actualización del modelo guardado en memoria del elemento seguro o actualizar el modelo guardado por el administrador, para alinear sus versiones,

generar un perfil incluyendo un elemento de perfil al que se ha dado formato con ayuda del modelo guardado por el administrador, en su versión alineada, y con posterioridad a la etapa de actualización, enviar al elemento seguro el perfil generado.

13. Administrador (310, 320, 330) de perfil según la reivindicación 12, en donde el microprocesador (210) además está configurado para enviar una solicitud que comprende un comando para recibir, en respuesta, dicha información o enviar un comando de actualización de un sistema operativo del elemento seguro (20) para recibir, en respuesta, dicha información.

14. Elemento seguro personalizable (20) que comprende al menos un microprocesador (210) configurado para:

enviar, a un servidor remoto (310, 320, 330), una información representativa de una versión de un modelo de elemento de perfil guardado en memoria (220, 230) del elemento seguro, en respuesta a este envío, recibir y ejecutar un comando de actualización del modelo de elemento de perfil guardado en memoria, enviado por el servidor remoto,

con posterioridad a la etapa de actualización, recibir un perfil a cargar enviado por el servidor remoto, incluyendo el perfil a cargar al menos un elemento de perfil al que se da formato con ayuda del modelo guardado en memoria, y

cargar e instalar, en memoria, el perfil recibido por fusión con el modelo guardado con cuya ayuda se da formato al perfil.

15. Elemento seguro personalizable (20) según la reivindicación 14, en donde el microprocesador (210) además está configurado para generar y enviar dicha información en respuesta a la recepción de una solicitud emitida por el servidor remoto (310, 320, 330), que comprende un comando para obtener, en respuesta, dicha información, o en respuesta a una etapa previa de actualización, por el servidor remoto, del sistema operativo del elemento seguro.