ES2537172T3 - Procedimiento de gestión de una aplicación integrada en un dispositivo electrónico asegurado - Google Patents
Procedimiento de gestión de una aplicación integrada en un dispositivo electrónico asegurado Download PDFInfo
- Publication number
- ES2537172T3 ES2537172T3 ES10727732.9T ES10727732T ES2537172T3 ES 2537172 T3 ES2537172 T3 ES 2537172T3 ES 10727732 T ES10727732 T ES 10727732T ES 2537172 T3 ES2537172 T3 ES 2537172T3
- Authority
- ES
- Spain
- Prior art keywords
- application
- message
- agent
- electronic token
- secured electronic
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Storage Device Security (AREA)
- Mobile Radio Communication Systems (AREA)
- Information Transfer Between Computers (AREA)
- Telephonic Communication Services (AREA)
Abstract
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).
Description
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.
15 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.
2 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.
25 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)
50 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:
55 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 según la invención;
La Figura 2 es un ejemplo de una primera realización del registro integrado en el agente según la invención;
6 O La Figura 3 es un ejemplo de arquitectura de agente según la invención; y
La Figura 4 es un ejemplo de una segunda realización de un registro integrado en el agente según la invención.
65 (Descripción detallada de las realizaciones preferidas)
3 O
5 O
La invención puede aplicarse a cualquier tipo de token electrónico asegurado. En particular, la presente invención puede ser aplicada también para asegurar el token electrónico utilizando un Protocolo de Transferencia de Hipertextos Seguro, normalmente denominado HTIPS. En esta especificación, el token electrónico asegurado es una tarjeta SIM pero podría ser otra clase de dispositivo electrónico asegurado capaz de emplear mecanismos HTIP
o HTIPS. Un token electrónico asegurado puede ser portátil y puede contener una o varias memorias, un microprocesador y una interfaz de comunicación. En esta especificación, el token electrónico asegurado está conectado a una máquina anfitriona. En particular, la máquina anfitriona puede ser un teléfono móvil o un terminal de telecomunicaciones. El token electrónico accede al servidor remoto mediante la máquina anfitriona. Alternativamente, los mensajes HTIPS pueden ser intercambiados directamente entre el token electrónico seguro y la máquina del servidor sin ninguna máquina anfitriona intermedia.
La presente invención se basa en un agente que permite el registro de una aplicación. Tanto el agente como la aplicación están almacenados en el token electrónico seguro. Un servidor lejano envía un mensaje con una cabecera y un cuerpo. El cuerpo del mensaje está diseñado para ser recibido por la aplicación registrada. Una vez registrado, la aplicación está asociada a un valor específico de un campo de cabecera. Según la invención, el agente es una aplicación mejorada de un Agente Administrador. Cuando recibe un mensaje del servidor lejano el agente es capaz de enviar una parte de este mensaje a la aplicación correspondiente.
Gracias a la invención, el servidor lejano siempre emplea el mecanismo estándar HTIP y permanece totalmente independiente de los límites de la interfaz de la aplicación en cuestión. El agente administra las cuestiones y el formateo de datos para la aplicación a la cual va dirigida.
Una ventaja de la invención es evitar la actualización de la terminal de telecomunicaciones empleada. Tal actualización es muy pesada de administrar y costosa ya que el número de terminales de telecomunicaciones en el campo es enorme. Además existen muchas clases diferentes de teléfonos móviles ya desplegados.
Otra ventaja de la invención es permitir a la aplicación integrada emplear un conjunto específico de comandos y respuestas. El conjunto especifico de comandos y respuestas pueden satisfacer cualquier formato.
Otra ventaja de la invención es evitar el despliegue de varias aplicaciones básicas de Agente Administrador en un único token. Dicho despliegue de varios agentes consume memoria y requiere una validación muy pesada, auditorias y certificaciones en relación a cuestiones de seguridad.
Otra ventaja de la invención es permitir la mezcla de la administración de varios asuntos OTA en una única sesión HTTP OTA. Por ejemplo la invención permite mezclar una operación de Activación con una operación de rastreo IMEI.
Otra ventaja de la invención es permitir que el servidor lejano envíe mensajes que no contiene el Identificador Applet (AID) del applet en cuestión.
Otra ventaja de la invención es permitir el acceso OTA a aplicaciones que han sido descargadas tras la emisión de la tarjeta sin efecto alguno en el Agente Administrador. En otras palabras, las aplicaciones que son descargadas en una etapa de post-personalización pueden obtenerse mediante el canal OT A incluso si el Agente Administrador continua sin cambios.
La Figura 1 muestra la arquitectura de un identificar electrónico seguro SC de tipo tarjeta SIM según una realización preferida de la invención.
El token electrónico seguro SC comprende una memoria de trabajo MEM1 de tipo RAM, dos memorias no volátiles MEM2 Y MEM3, un microprocesador MP y una interfaz de comunicación IN. La memoria no volátil MEM2 comprende un sistema operativo OS que puede contener una máquina Java Virtual.
La memoria no volátil MEM3 comprende dos applets AP1 y AP2, un servidor web de tarjeta con chip SCWS, un dominio de seguridad SD y un agente AA. El dominio de seguridad SD cumple con el estándar GlobalPlatform.
Las dos memorias MEM2 y MEM3 pueden implementarse como combinaciones de una, dos o más memorias. Dichas memorias pueden ser flash de tipo NAND o memoria EEP-ROM u otro tipo de memoria no volátil.
La tarjeta SIM SC está diseñada para intercambiar mensajes con teléfonos de telecomunicaciones HM a través de la interfaz de comunicación IN. El teléfono de telecomunicaciones HM está diseñado para intercambiar mensajes con un servidor lejano SR mediante el mecanismo OTA. Entonces la tarjeta SIM SC puede intercambiar mensajes con el servidor lejano SR mediante la máquina anfitriona conectada HM.
El agente AA puede implementarse como un applet en Java Cardo En este ejemplo las dos aplicaciones AP1 y AP2 dependen del dominio de seguridad SD. El applet AP1 comprende un medio M5 que es capaz de solicitar al agente AA el registro del applet AP1.
En una realización preferida, el agente AA puede combinarse con el Dominio de seguridad SO.
La Figura 2 muestra un ejemplo de una primera realización de un registro RG integrado en el agente AA según la invención.
El registro RG está diseñado para contener un conjunto de pares {valor del elemento, referencia de una aplicación} . En el ejemplo de la Figura 2, el registro RG contiene dos pares: {EV1 ,RF1} y {EV2,RF2}.
RF1 es una referencia del applet AP1 y RF2 es una referencia del applet AP2. Por ejemplo RF1 puede ser igual a la AID del applet AP1 o una dirección específica a AP1 o a un identificador almacenado en un registro especializado.
EV1 es un valor asociado al applet AP1 y EV2 es un valor asociado al applet AP2. En esta primera realización, se supone que los valores EV1 y EV2 son los valores posibles para un campo implícito predeterminado de la cabecera del mensaje HTIP. En particular, los dos valores EV1, EV2 pueden diseñarse para ser encontrados en el campo Tipo de Contenido de la cabecera HTIP. Por ejemplo EV1 puede ser igual a "aplicación/Rastreolmei/1.0" y EV2 puede ser igual a "aplicación/PDM/1.0". En este ejemplo EV2 puede corresponderse con una aplicación de un listín telefónico en la cual PDM significa Gestor de Datos Personales.
La Figura 3 muestra un ejemplo de una arquitectura de agente AA. El agente comprende un registro RG y cuatro medios M1, M2, M3 YM4.
El medio M1 es capaz de registrar el applet AP1. El registro es llevado a cabo mediante la asociación de una referencia RF1 de la aplicación AP1 con un valor de un elemento de la cabecera del mensaje HTIP. La referencia empleada en el registro RG permite que el agente AA identifique la aplicación a la que va dirigida para iniciarla.
Cuando un mensaje HTIP es recibido desde el servidor SR, el medio M2 es capaz de transferir parte del mensaje HTIP al applet AP1 si la cabecera del mensaje HTIP contiene un elemento igual al valor EV1 asociado a la referencia RF1. De manera similar, el medio M2 es capaz de transferir parte del mensaje HTIP recibido al applet AP2 si la cabecera del mensaje HTIP contiene un elemento igual al valor EV2 asociado a la referencia RF2. Generalmente, la parte del mensaje HTIP que es transferida al applet dirigido es el cuerpo completo del mensaje HTIP enviado por el servidor SR.
El medio M3 es capaz de comprobar si el applet AP3 cumple con las reglas de seguridad predeterminadas. El medio M3 rechaza registrar un applet si la verificación de seguridad finaliza de manera insatisfactoria. Por ejemplo el medio M3 puede verificar que el applet AP1 se encuentra en el mismo dominio de seguridad que el agente AA.
En la mayoría de los casos, el applet AP1 genera una respuesta de los datos recibidos del agente AA. El medio M4 es capaz de transferir la respuesta al servidor lejano SR. El envío de la respuesta se realiza gracias a un mensaje HTIP que contiene la respuesta.
La Figura 4 muestra un ejemplo de una segunda realización de un registro RF integrado en el agente AA según la invención. El registro RG está diseñado para contener un conjunto de subconjuntos {Identificador del elemento de la cabecera, valor del elemento y referencia de una aplicación}. En el ejemplo de la Figura 4, el registro RG contiene un subconjunto: {HE1 ,EV1 ,RF1}. RF1 es una referencia del applet AP1 y EV1 es un valor asociado al applet AP1. HE1 es un identificador de un campo de la cabecera del mensaje HTIP. Por ejemplo, el identificador HE1 puede apuntar al campo de Tipo de Contenido. Por ejemplo HE1 puede ser igual a "Tipo de Contenido" cuando el identificador HE1 se corresponde al campo Tipo de Contenido. Alternativamente, el mensaje HTIP puede contener otra cabecera definida con campo personalizado. Por ejemplo HE1 puede ser igual a "X-Adm-Hacia" si el identificador HE1 se corresponde a una cabecera personalizada adicional del mensaje HTIP.
Según la realización de la invención, la primera etapa del método se corresponde al registro del applet AP1 en el agente AA. Por ejemplo, el registro puede ser solicitado por el propio applet AP1. El applet se encuentra registrado en el agente AA almacenando un par que comprende un valor EV1 de un elemento de la cabecera del mensaje HTIP y una referencia RF1 del applet AP1. En una realización preferida, elemento de la cabecera del mensaje HTIP es el Tipo de Contenido. El valor EV1 debe ser escogido de manera que sea diferente de los patrones definidos por los estándares OMA-SCWS y Global Platform ® 2.2.
La aplicación AP1 puede generar una solicitud de inicio de una sesión OTA. Entonces la aplicación AP1 envia esta solicitud al agente AA.
Luego el agente AA envia un primer mensaje HTIP POST al servidor remoto SR mediante la máquina anfitriona HM conectada.
Entonces el servidor remoto SR envía un mensaje de solicitud de respuesta HTIP al token SC. La cabecera de este mensaje de respuesta HTIP contiene un campo de Tipo de Contenido igual a EV1. El mensaje de respuesta HTTP es recibido por el agente AA en el token SC. El agente AA verifica si se ha registrado un applet para el valor EV1. Ya
3 O
5 O
que se ha registrado el applet AP1 y asociado al valor EV1 para el campo Tipo de Contenido, el agente AA extrae el cuerpo del mensaje de respuesta HTTP recibido. Por ejemplo, el cuerpo puede contener un comando aplicativo cuyo objetivo sea actualizar el listín telefónico. El cuerpo también puede contender un mensaje aplicativo en base a la estructura TLV o basado en otro formato relevante. Entonces el agente AA envía los datos extraídos al applet AP1. En una realización preferida, RF1 es igual a la AIO del applet AP1. Entonces el agente AA es capaz de encontrar fácilmente la aplicación en cuestión. Luego el applet AP1 trata los datos recibidos y computa una respuesta correspondiente al comando aplicativo recibido. El applet AP1 envía la respuesta al agente AA. Luego el agente AA genera un mensaje HTTP POST que contiene la respuesta del applet y envía el mensaje HTTP POST al servidor SR. El applet AP1 proporciona al agente AA la URL del servidor SR. El mensaje HTTP POST se genera con una cabecera cuyo campo Tipo de Contenido está establecido en EV1 y con un cuerpo que comprende la respuesta suministrada por el applet AP1. Entonces el servidor SR recibe un mensaje HTTP POST que se corresponde al mensaje de respuesta HTTP POST inicial.
En una realización preferida tanto el servidor SR como el agente AA poseen credenciales que permite asegurar la comunicación HTTP a través de HTTPS.
Alternativamente, el registro RG puede contener un subconjunto {HE1 ,EV1 ,RF1} como se describe en la Figura 4. En especial, el identificador HE1 puede corresponderse con el campo de Tipo de Contenido de la cabecera HTTP. En este caso, el agente AA verifica si ha sido registrado un applet para el valor EV1 en el campo de la cabecera HE1.
Gracias a la invención, un servidor HTTP remoto puede enviar una transcripción completa OTA a la aplicación integrada en el token electrónico seguro. En especial, un servidor HTTP remoto puede enviar transcripciones completas OT A a una aplicación distinta de un Servidor Web de Tarjetas Con chip.
Provechosamente, cualquier intento de registro de un applet al valor de un elemento que ya está registro en otro applet será denegado.
Alternativamente, el agente AA es capaz de administrar los posibles conflictos cuando selecciona la aplicación a la que va dirigido gracias al registro RG. La regla principal es seleccionar una aplicación como máximo. O ninguna aplicación es seleccionada o se selecciona una sola aplicación conforme a una política específica predeterminada. Por ejemplo el agente AA puede seleccionar la primera aplicación que coincide con una entrada en el registro RG.
En una realización, sólo puede autorizarse un auto-registro. En otras palabras un applet puede solicitar el registro solamente para sí mismo.
Alternativamente, el registro puede delegarse en otra aplicación integrada en un token seguro SC. Entonces puede autorizarse el registro de un applet por otro applet. En este caso, el applet objetivo registrado debe ya existir en el token SC.
En otra realización, el agente AA puede también permitir el registro remoto de un applet. Entonces el servidor lejano SR puede pedir el registro del applet AP1. El agente AA puede proporcionar un comando OTA específico para el registro remoto por ejemplo. Entonces un servidor lejano puede cargar, instalar y registrar un nuevo applet en un token seguro.
Provechosamente, el agente AA puede proporcionar una característica que permita solicitar la eliminación de la entrada del applet en el registro RG. Esta característica puede implementarse gracias a un punto de entrada OTA o Java Cardo
Una ventaja de la invención es permitir una administración dinámica de los canales HTTPS entre un servidor lejano y una aplicación integrada en un token seguro. Gracias al mecanismo de registro, el enlace entre la aplicación y el servidor remoto puede ser establecido y eliminado según las necesidades aplicativas y administrativas.
Claims (12)
- REIVINDICACIONES1. 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), dicho5 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:10 (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.3 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).40 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),
55 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 transferir60 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 untercer 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).5 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 mensajecumple 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.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP09305663 | 2009-07-09 | ||
| EP09305663A EP2273748A1 (en) | 2009-07-09 | 2009-07-09 | Method of managing an application embedded in a secured electronic token |
| PCT/EP2010/059034 WO2011003748A1 (en) | 2009-07-09 | 2010-06-24 | Method of managing an application embedded in a secured electronic token |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| ES2537172T3 true ES2537172T3 (es) | 2015-06-03 |
| ES2537172T5 ES2537172T5 (es) | 2018-06-20 |
Family
ID=42104632
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES10727732.9T Active ES2537172T5 (es) | 2009-07-09 | 2010-06-24 | Procedimiento de gestión de una aplicación integrada en un dispositivo electrónico asegurado |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US8825780B2 (es) |
| EP (2) | EP2273748A1 (es) |
| JP (1) | JP5492988B2 (es) |
| CN (1) | CN102484645B (es) |
| ES (1) | ES2537172T5 (es) |
| PL (1) | PL2452478T5 (es) |
| WO (1) | WO2011003748A1 (es) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160285493A1 (en) * | 2015-03-23 | 2016-09-29 | Stmicroelectronics S.R.L. | Methods for performing a remote management of a multi-subscription sim module, and corresponding sim module and computer program product |
| US20170193466A1 (en) * | 2015-12-31 | 2017-07-06 | Jonathan A Clark | Electronic system for routing marketplace transactions |
| US10423800B2 (en) * | 2016-07-01 | 2019-09-24 | Capitalogix Ip Owner, Llc | Secure intelligent networked architecture, processing and execution |
Family Cites Families (35)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1125262A1 (en) * | 1998-10-27 | 2001-08-22 | Visa International Service Association | Delegated management of smart card applications |
| FR2790629A1 (fr) * | 1999-02-19 | 2000-09-08 | Bull Cp8 | Procede d'activation d'applications localisees dans une carte a puce par un navigateur du type dit "web" |
| FR2800540B1 (fr) * | 1999-10-28 | 2001-11-30 | Bull Cp8 | Terminal securise muni d'un lecteur de carte a puce destine a communiquer avec un serveur via un reseau de type internet |
| FR2805107B1 (fr) † | 2000-02-10 | 2002-04-05 | Bull Cp8 | Procede de gestion de transmissions de donnees multimedias via un reseau de type internet, notamment de donnees telephoniques, et carte a puce pour la mise en oeuvre du procede |
| US6824064B2 (en) * | 2000-12-06 | 2004-11-30 | Mobile-Mind, Inc. | Concurrent communication with multiple applications on a smart card |
| JP3805211B2 (ja) * | 2001-06-11 | 2006-08-02 | 株式会社東芝 | サービス提供方法及びサービス提供装置 |
| US20040123138A1 (en) * | 2002-12-18 | 2004-06-24 | Eric Le Saint | Uniform security token authentication, authorization and accounting framework |
| US20040123152A1 (en) * | 2002-12-18 | 2004-06-24 | Eric Le Saint | Uniform framework for security tokens |
| JP4196721B2 (ja) * | 2003-04-30 | 2008-12-17 | 凸版印刷株式会社 | Ｉｃカード及びそのアプリケーション設定方法 |
| JP2004348526A (ja) * | 2003-05-23 | 2004-12-09 | Dainippon Printing Co Ltd | Ｉｃカード、ｉｃカードプログラム及びコード部の入れ替え方法 |
| DE602004012870T2 (de) * | 2003-07-11 | 2009-05-14 | International Business Machines Corp. | Verfahren und system zur benutzerauthentifizierung in einer benutzer-anbieterumgebung |
| US7107357B2 (en) * | 2003-08-11 | 2006-09-12 | Teamon Systems, Inc. | Communications system providing shared client-server communications interface and related methods |
| US7140549B2 (en) * | 2004-02-24 | 2006-11-28 | Sun Microsystems, Inc. | Method and apparatus for selecting a desired application on a smart card |
| US7374099B2 (en) * | 2004-02-24 | 2008-05-20 | Sun Microsystems, Inc. | Method and apparatus for processing an application identifier from a smart card |
| CN101010927A (zh) * | 2004-06-15 | 2007-08-01 | 雅斯拓股份有限公司 | 用于sim和终端之间的通信的协议转换“载体无关协议”－tcp/ip |
| US7533265B2 (en) * | 2004-07-14 | 2009-05-12 | Microsoft Corporation | Establishment of security context |
| US20090235352A1 (en) * | 2004-12-07 | 2009-09-17 | Koninklijke Philips Electronics N.V. | System and method for application management on multi-application smart cards |
| US7945676B2 (en) * | 2005-03-10 | 2011-05-17 | International Business Machines Corporation | Processing requests transmitted using a first communication protocol directed to an application that uses a second communication protocol |
| US7395973B2 (en) * | 2005-12-08 | 2008-07-08 | Chun-Hsin Ho | Smart card |
| EP1811421A1 (en) * | 2005-12-29 | 2007-07-25 | AXSionics AG | Security token and method for authentication of a user with the security token |
| US8032872B2 (en) * | 2006-01-09 | 2011-10-04 | Oracle America, Inc. | Supporting applets on a high end platform |
| US20080189554A1 (en) * | 2007-02-05 | 2008-08-07 | Asad Ali | Method and system for securing communication between a host computer and a secure portable device |
| KR101030489B1 (ko) * | 2007-06-22 | 2011-04-25 | 주식회사 케이티 | 스마트 카드를 관리하기 위한 시스템 및 그 방법 |
| US7748609B2 (en) * | 2007-08-31 | 2010-07-06 | Gemalto Inc. | System and method for browser based access to smart cards |
| EP2263359B1 (fr) * | 2008-03-31 | 2014-09-03 | Orange | Procédé d'accès et de transfert de données liées à une application installée sur un module de sécurité associé à un terminal mobile, module de sécurité, serveur de gestion et système associés |
| US8732452B2 (en) * | 2008-06-23 | 2014-05-20 | Microsoft Corporation | Secure message delivery using a trust broker |
| JP5432261B2 (ja) * | 2008-08-08 | 2014-03-05 | エスケープラネット株式会社 | 端末機とスマートカードとの間のインターフェースシステム及びその方法、並びにこれに適用されるスマートカード |
| KR101095163B1 (ko) * | 2008-08-27 | 2011-12-16 | 에스케이플래닛 주식회사 | 위젯 실행을 위한 사용자 단말기와 스마트 카드 간 연동 시스템 및 그 방법 |
| US8745187B2 (en) * | 2008-10-10 | 2014-06-03 | Sk Planet Co., Ltd. | System and method for installing smart card applet |
| CN101820613B (zh) * | 2009-02-27 | 2014-03-19 | 中兴通讯股份有限公司 | 一种应用下载的系统和方法 |
| US8219148B2 (en) * | 2009-04-06 | 2012-07-10 | Gemalto Sa | Method for activating the subscription of an UICC device |
| US8527774B2 (en) * | 2009-05-28 | 2013-09-03 | Kaazing Corporation | System and methods for providing stateless security management for web applications using non-HTTP communications protocols |
| US20110055573A1 (en) * | 2009-09-03 | 2011-03-03 | International Business Machines Corporation | Supporting flexible use of smart cards with web applications |
| CN102025710B (zh) * | 2009-09-11 | 2015-11-25 | 中国银联股份有限公司 | 多应用智能卡及智能卡多应用管理系统和方法 |
| US20110131421A1 (en) * | 2009-12-02 | 2011-06-02 | Fabrice Jogand-Coulomb | Method for installing an application on a sim card |
-
2009
- 2009-07-09 EP EP09305663A patent/EP2273748A1/en not_active Withdrawn
-
2010
- 2010-06-24 CN CN201080039990.XA patent/CN102484645B/zh active Active
- 2010-06-24 EP EP10727732.9A patent/EP2452478B2/en active Active
- 2010-06-24 US US13/382,342 patent/US8825780B2/en active Active
- 2010-06-24 ES ES10727732.9T patent/ES2537172T5/es active Active
- 2010-06-24 WO PCT/EP2010/059034 patent/WO2011003748A1/en active Application Filing
- 2010-06-24 PL PL10727732T patent/PL2452478T5/pl unknown
- 2010-06-24 JP JP2012518878A patent/JP5492988B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN102484645B (zh) | 2015-07-29 |
| PL2452478T3 (pl) | 2015-07-31 |
| EP2452478A1 (en) | 2012-05-16 |
| ES2537172T5 (es) | 2018-06-20 |
| CN102484645A (zh) | 2012-05-30 |
| EP2452478B2 (en) | 2018-01-10 |
| JP5492988B2 (ja) | 2014-05-14 |
| US20120117219A1 (en) | 2012-05-10 |
| EP2452478B1 (en) | 2014-12-17 |
| US8825780B2 (en) | 2014-09-02 |
| EP2273748A1 (en) | 2011-01-12 |
| JP2012533101A (ja) | 2012-12-20 |
| WO2011003748A1 (en) | 2011-01-13 |
| PL2452478T5 (pl) | 2018-06-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2555970T3 (es) | Procedimiento para exportar datos de una UICC a un servidor seguro | |
| US8028167B2 (en) | Method and apparatus for certificate roll-over | |
| US9198026B2 (en) | SIM lock for multi-SIM environment | |
| KR102173534B1 (ko) | 이동통신사업자 정보 제공 방법 및 이를 수행하는 장치 | |
| KR20110020870A (ko) | 고유하게 퍼스널라이징된 마스터 ｓｉｍ에 의한 ｓｉｍ의 퍼스널라이제이션 | |
| US20130132734A1 (en) | Computing device integrity protection | |
| RU2015114703A (ru) | Телекоммуникационная чип-карта | |
| ES2537172T3 (es) | Procedimiento de gestión de una aplicación integrada en un dispositivo electrónico asegurado | |
| WO2010084081A1 (en) | Method of loading data in an electronic device | |
| ES2941815T3 (es) | Personalización segura de un chip que comprende un entorno de ejecución seguro, tal como iUICC, iSSP o TEE | |
| KR102114431B1 (ko) | 모바일 터미널의 내장 보안 요소에 서브스크립션을 로딩하는 방법 | |
| US20220232387A1 (en) | Method for setting up a subscription profile, method for providing a subscription profile, subscriber identity module | |
| CN107005409B (zh) | 身份到安全元件内的引入 | |
| CN105790946B (zh) | 建立数据通道的方法、系统及相关设备 | |
| EP2584755A1 (en) | Method of sending a command to a secure element | |
| US11778456B2 (en) | UE with integrated subscriber identity modules by resource sharing | |
| WO2021164126A1 (zh) | 会话创建方法及相关设备 | |
| EP2908568A1 (en) | Method of provisioning a server with a group of keys | |
| US10616212B2 (en) | Method of sending a data from a secure token to a server | |
| KR20220132532A (ko) | 단말기의 보안 프로세서에 저장된 제네릭 애플리케이션을 안전하게 다양화하는 방법 | |
| EP2273758A1 (en) | Method of sending messages to an application embedded in a secured electronic token |