Procedimiento de gestión de una aplicación integrada en un dispositivo electrónico asegurado.

Un metodo de administración de una aplicacion (API) integrada en un token electrónico asegurado (SC),

dicho token electrónico asegurado (SC) disetiado para recibir un mensaje de una máquina de servidor (SR), dicho token electrónico (SC) que comprende un agente (AA) capaz de administrar dicho mensaje, el mensaje que posee una cabecera y un cuerpo,

caracterizado porque dicho método comprende las etapas de:

(a)Registro de la aplicación (AP1) en el agente (AA) asociando una referencia (RF1) de la aplicación (AP1) con un valor de un elemento de la cabecera del mensaje,

b) cuando el mensaje es recibido desde la máquina del servidor (SR), transferir parte de dicho mensaje a la aplicación (AP1) si la cabecera del mensaje contiene un elemento que posea un valor asociado a la referencia (RF1) de la aplicación (AP1).

Procedimiento de gestión de una aplicación integrada en un dispositivo electrónico asegurado.

La presente invención hace referencia a métodos de gestión de una aplicación integrada en un token electrónico asegurado. Hace referencia particularmente a métodos de administración de aplicaciones que están integradas en tarjetas con chip.

(Técnica anterior)

Un token electrónico asegurado como una tarjeta con chip, también denominada tarjeta inteligente, puede contener aplicaciones en forma de applets. Se puede acceder a estos applets por un servidor remoto mediante un canal aéreo, conocido como OTA. El mecanismo OTA se define por los estándares ETSI SCP 102.225, ETSI-SCP

102.226 y GlobalPlatform 2.2 para RAM. El canal OTA permite acceder a datos y aplicaciones que han sido específicamente desarrollados para tarjetas SIM. Solamente las tarjetas cuyo uso se ha diseñado para un dominio Telecom o en un dominio Máquina a Máquina (M2M) pueden administrar una comunicación OTA. Concretamente las tarjetas SIM ofrecen características OTA. Puede accederse a estas tarjetas con chip a través del Protocolo de Transferencia de Hipertexto, normalmente llamado HTTP. En particular, las versiones estándar 1.0 y posteriores de OMA-SCWS definen un protocolo de administración para la administración OTA de los recursos del Servidor Web de Tarjetas Con Chip (SCWS) . Este protocolo se basa en un mensaje POST HTTP enviado por una aplicación de Agente Administrador al servidor OTA. La aplicación de Agente Administrador se encuentra en la tarjeta con chip. Como respuesta, el servidor OTA envía de vuelta un comando de administración SCWS en el cuerpo de la respuesta POST HTTP. Según el estándar, un Tipo de Contenido fijo es especificado en la cabecera de esta respuesta HTTP POST. A la recepción de este mensaje, y gracias al Tipo de Contenido, la aplicación de Agente Administrador reenvía el cuerpo de la respuesta HTTP POST al SCWS para la ejecución de los comandos de administración que contiene. Entonces, una vez los comandos administrativos han sido ejecutados por el SCWS, otra solicitud HTTP POST es enviada por la aplicación de Agente Administrador con el propósito de notificar al servidor OT A los resultados de la ejecución de los comandos. Estos datos de resultados se introducen en un mensaje HTTP POST, Y un Tipo de Contenido específico es colocado en la cabecera de este HTTP POST. Usando un principio similar, el GlobalPlatform ® 2.2 estándar (Enmienda B "RAM sobre HTTP") ha definido un protocolo de administración para la administración del OTA del contenido de la tarjeta con chip. Este canal se adapta bien al mecanismo Gestión Remota de Applet (RAM) , para la administración de Dominios de Seguridad, paquetes yapplets. El GlobalPlatform ® 2.2 estándar especifica un patrón fijo de Tipo de Contenido a emplear en los mensajes de solicitud HTTP POST Y en los mensajes de respuesta HTTP POST.

La mayoría de las aplicaciones desarrolladas para las tarjetas SIM son diseñadas con una Interfaz de programación de Aplicaciones (API) capaz de administrar el canal OTA. Dichas aplicaciones de tarjetas con chip no son capaces de administrar el canal HTTP. En la actualidad no es posible dirigirse a estas aplicaciones ya que la ruta de la respuesta HTTP tiene que estar garantizada por el Agente Administrador que no es consciente de los valores específicos de Tipo de Contenido exceptuando OMA-SCWS, RAM en HATTP y RFM en HTTP. En los tres estándares mencionados anteriormente, la aplicación de Agente Administrador es un componente clave para la administración de estos protocolos "OPA sobre HTTP". Además, la aplicación del Agente Administrador forma generalmente parte del Sistema Operativo de las tarjetas con chip. Como consecuencia, no resulta fácilmente posible modificar su comportamiento.

Existe la necesidad de reutilizar el mismo protocolo "OT A sobre HTPP" para motivos distintos de la administración de recursos SCWS y administración del contenido de la Tarjeta como se define por GlobalPlatform ® o los estándares ETSI. En particular, existe una necesidad de acceso a cualquier aplicación integrada en una tarjeta con chip mediante el mecanismo HTTP. En particular un servidor lejano debe poder comunicarse con una aplicación integrada en una tarjeta con chip mediante una sesión HTTP para personalizar la aplicación o utilizar un servicio suministrado por la aplicación.

La W02006/061754 revela un sistema y un método de transferencia de derechos de administración de tarjetas con chip de una parte a otra.

(Sumario de la invención)

El objeto de la invención es resolver el problema técnico mencionado anteriormente.

El objeto de la presente invención es un método de administrar una aplicación que está integrada en un token electrónico asegurado. El token electrónico asegurado está diseñado para recibir un mensaje desde una máquina de servidor. El token electrónico asegurado comprende un agente capaz de administrar dicho mensaje. El mensaje tiene una cabecera y un cuerpo. El método comprende las etapas de:

a) registro de la aplicación en el agente mediante la asociación de una referencia de la paliación con un valor de un elemento de la cabecera del mensaje,

b) cuando se recibe el mensaje de la máquina de servidor, transfiere parte de dicho mensaje a la aplicación si la cabecera del mensaje contiene un elemento que posee el valor asociado a la referencia de la aplicación.

Provechosamente, cuando la aplicación puede generar una respuesta al mensaje y el método puede comprender la 5 etapa de envío de dicha respuesta a la máquina del servidor.

En una realización preferida, el mensaje puede cumplir el formato HTTP o HTTPS.

Provechosamente, el elemento de la cabecera puede ser un Tipo de Contenido como se define por el estándar 10 HTTP-RFC 2616 HTTP/1.

En una realización preferida, el agente puede rechazar la etapa de registro si la aplicación no cumple con las reglas preestablecidas de seguridad.

Provechosamente, el agente puede rechazar la etapa de registro si el valor de dicho elemento se encuentra ya registrado en otra aplicación.

La etapa de registro puede ser solicitada por la aplicación.

O Provechosamente, el token electrónico asegurado puede comprender una segunda aplicación y la etapa de registro puede ser solicitada por la segunda aplicación.

Alternativamente, la etapa de registro puede ser solicitada por la máquina del servidor.

Otro objeto de la invención es un token electrónico asegurado diseñado para recibir un mensaje de la máquina del servidor. El token electrónico asegurado comprende un agente capaz de administrar el mensaje. El mensaje tiene una cabecera y un cuerpo. El token electrónico asegurado comprende: un microprocesador, una interfaz de comunicación, un sistema operativo, una memoria de trabajo y una memoria no volátil. El token electrónico asegurado está diseñado para comprender una aplicación, un primer y segundo medio. El primer medio es capaz de 3 O registrar la aplicación asociando una referencia de la aplicación con un valor de un elemento de la cabecera del mensaje. El segundo medio es capaz de transferir parte del mensaje a la aplicación si la cabecera del mensaje contiene un elemento que tiene el valor asociado a la referencia de la aplicación.

Provechosamente, el agente puede comprender un tercer medio capaz de verificar si la aplicación cumple con las 3 5 reglas de seguridad preestablecidas, y capaz de rechazar el registro de la aplicación en caso de una verificación insatisfactoria.

En una realización preferida, la aplicación puede generar una respuesta al mensaje y el agente puede comprender un cuarto medio capaz de enviar dicha respuesta a la máquina del servidor.

Provechosamente, la aplicación puede comprender un quinto medio capaz de solicitar al agente el registro de la aplicación.

En una realización preferida, el mensaje puede cumplir con el formato HTTP o HTTPS y el elemento de cabecera 45 puede ser un Tipo de Contenido como se define por el estándar HTTP -RFC 2616 HTTP/1.1.

En una realización preferida, el token electrónico asegurado puede ser una tarjeta con chip.

(Breve descripción de los dibujos)

Otras características y ventajas de la presente invención aparecerán con mayor claridad a lo largo de la lectura de la siguiente descripción de un número de realizaciones preferidas de la invención con referencia a los correspondientes esquemas que acompañan en los cuales:

La Figura 1 representa de forma esquemática un ejemplo de la arquitectura de un token electrónico asegurado que comunica con un servidor lejano mediante una máquina anfitriona... [Seguir leyendo]

1. Un método de administración de una aplicación (AP1) integrada en un token electrónico asegurado (SC) , dicho token electrónico asegurado (SC) diseñado para recibir un mensaje de una máquina de servidor (SR) , dicho token electrónico (SC) que comprende un agente (AA) capaz de administrar dicho mensaje, el mensaje que posee una cabecera y un cuerpo,

caracterizado porque dicho método comprende las etapas de:

(a) Registro de la aplicación (AP1) en el agente (AA) asociando una referencia (RF1) de la aplicación (AP1) con un valor de un elemento de la cabecera del mensaje,

b) cuando el mensaje es recibido desde la máquina del servidor (SR) , transferir parte de dicho mensaje a la aplicación (AP1) si la cabecera del mensaje contiene un elemento que posea un valor asociado a la referencia 15 (RF1) de la aplicación (AP1) .

2. Un método según la reivindicación 1, en el que dicho método comprende la etapa adicional de:

c) cuando la aplicación (AP1) genera una respuesta al mensaje, enviar dicha respuesta a la máquina del 2 O servidor (SR) .

3. Un método según reivindicación 1 y 2, en el que dicho mensaje cumple con el formato HTTP o HTTPS.

4. Un método según reivindicación 3, en el que dicha cabecera es un Tipo de Contenido como se define por el 25 estándar HTTP-RFC 2616 HTTP/1.1.

5. Un método según una de las reivindicaciones de 1 a 4, en el que dicho agente (AA) rechaza dicha etapa de registro si la aplicación (AP1) no cumple con las reglas de seguridad predeterminadas.

O 6. Un método según una de las reivindicaciones de 1 a 5, en la que dicho agente (AA) rechaza la etapa de registro si el valor de dicho elemento ya está registrado en otra aplicación.

7. Un método según una de las reivindicaciones de 1 a 6, en la que dicha etapa de registro es solicitada por la aplicación (AP1) .

8. Un método según una de las reivindicaciones de 1 a 6, en la cual dicho token electrónico asegurado (SC) comprende una segunda aplicación (AP2) y en la que dicha etapa de registro es solicitada por la segunda aplicación (AP2) .

9. Un método según una de las reivindicaciones de 1 a 6, en la cual dicha etapa de registro es solicitada por la máquina de servidor (SR) .

10. Un token electrónico asegurado (SC) diseñado para recibir un mensaje de una máquina de servidor (SR) ,

dicho token electrónico asegurado (SC) comprende un agente (AA) capaz de administrar dicho mensaje, el mensaje 45 que contiene una cabecera y un cuerpo, dicho token electrónico asegurado compuesto por:

-Un microprocesador (MP) ,

-Una interfaz de comunicación (IN) .

50. Un sistema operativo (OS) ,

-Una memoria de trabajo (MEM1) y una memoria no volátil (MEM2) ,

dicho token electrónico asegurado (SC) creado para comprender una aplicación (AP1) ,

caracterizado porque dicho agente (AA) comprende un primer y segundo medio (M1, M2) , dicho primer medio siendo capaz de registrar la aplicación (AP1) mediante la asociación de una referencia (RF1) de la aplicación (AP1) con un valor de un elemento de la cabecera del mensaje y dicho segundo medio (M2) siendo capaz de transferir

parte de dicho mensaje a la aplicación (AP1) si la cabecera del mensaje contiene un elemento que tenga un valor asociado a la referencia (RF1) de la aplicación (AP1) .

11. Un token electrónico asegurado (SC) según la reivindicación 10, en la cual dicho agente (AA) comprende un tercer medio (M3) capaz de verificar si la aplicación (AP1) cumple con las reglas de seguridad predeterminadas y 65 capaz de rechazar el registro de dicha aplicación (AP1) en caso de una verificación no satisfactoria.

12. Un token electrónico asegurado (SC) según una de las reivindicaciones 10 u 11, en la cual la aplicación (AP1) genera una respuesta al mensaje, y en la cual dicho agente (AA) comprende un cuarto medio (M49) capaz de transferir dicha respuesta a la máquina de servidor (SR) .

13. Un token electrónico asegurado (SC) según una de las reivindicaciones de 10 a 12, en la cual la aplicación (AP1) comprende un quinto medio (M5) capaz de solicitar al agente (AA) el registro de la aplicación (AP1) .

14. Un token electrónico asegurado (SC) según una de las reivindicaciones de 10 a 13, en la cual dicho mensaje cumple con el formato HTIP o HTIPS y en la cual dicho elemento de cabecera es un Tipo de Contenido como se 10 define por el estándar HTIP-RFC 2616 HTIP/1.1.

15. Un token electrónico asegurado (SC) según una de las reivindicaciones 10 A 14, en la que dicho token electrónico asegurado (SC) es una tarjeta con chip.