ES2350268T3 - Procedimiento de puesta a disposición confinada de un servicio electrónico. - Google Patents

Procedimiento de puesta a disposición confinada de un servicio electrónico. Download PDF

Info

Publication number
ES2350268T3
ES2350268T3 ES07301379T ES07301379T ES2350268T3 ES 2350268 T3 ES2350268 T3 ES 2350268T3 ES 07301379 T ES07301379 T ES 07301379T ES 07301379 T ES07301379 T ES 07301379T ES 2350268 T3 ES2350268 T3 ES 2350268T3
Authority
ES
Spain
Prior art keywords
service
consumer
request
terminal
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES07301379T
Other languages
English (en)
Inventor
Jean-Philippe Wary
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Societe Francaise du Radiotelephone SFR SA
Original Assignee
Societe Francaise du Radiotelephone SFR SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Societe Francaise du Radiotelephone SFR SA filed Critical Societe Francaise du Radiotelephone SFR SA
Application granted granted Critical
Publication of ES2350268T3 publication Critical patent/ES2350268T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/107—Network architectures or network communication protocols for network security for controlling access to devices or network resources wherein the security policies are location-dependent, e.g. entities privileges depend on current location or allowing specific operations only from locally connected terminals
    • 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/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/086—Access security using security domains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication

Abstract

Procedimiento de puesta a disposición confinada de un servicio (S1) electrónico, en un terminal (101) electrónico de un usuario, para al menos un prestador (161) abonado al servicio, prestador que propone ese servicio a una pluralidad de consumidores (130) a través de la implantación, en una etapa previa, de un dominio (SD1) de seguridad que garantiza el confinamiento del servicio y de un área (D1) de datos a la que puede acceder dicho servicio, ya sea directamente, o bien a través de un tratamiento del servicio electrónico, siendo el área de datos del dominio de seguridad accesible únicamente a través de una clave de acceso a los datos, caracterizado porque incluye las siguientes etapas: - el terminal indexa (211, 314), en el dominio de seguridad, el área de datos a la que el servicio puede acceder en el terminal electrónico en subáreas para garantizar que una petición (205, 302) de un consumidor de la pluralidad de consumidores sólo pueda leer/escribir/modificar una subárea (D1.x) predeterminada asociada al consumidor emisor de la petición, ya sea directamente, o bien a través del servicio electrónico.

Description

La invención tiene por objeto un procedimiento de puesta a disposición confinada de un servicio electrónico.
El campo de la invención es el de los terminales móviles y, más particularmente, el de los servicios proporcionados a través de estos terminales móviles. En el presente caso, se entiende por terminal móvil un teléfono móvil de segunda generación o de una generación superior a la segunda. Por extensión, un terminal móvil es todo dispositivo que se comunica a través de una red y transportable, sin ayuda, por una persona. Se incluyen por tanto en esta categoría al menos los teléfonos móviles, las agendas electrónicas y los ordenadores portátiles.
Es un objeto de la invención la puesta a disposición de servicios en un terminal móvil economizando los recursos de este terminal.
Es otro objeto de la invención, en un terminal dado, poner ese servicio a disposición de una pluralidad de consumidores economizando los recursos de dicho terminal.
Es otro objeto de la invención reforzar la seguridad en la puesta a disposición del servicio.
Son conocidas en el estado de la técnica plataformas de soporte lógico para la telefonía móvil que permiten proponer servicios, distintos de los de telefonía móvil, en teléfonos móviles.
Una de estas soluciones consiste en cablear el servicio en un chip que se halla embarcado en el teléfono. En tal caso, el servicio está dedicado a un prestador y a un consumidor del servicio. Si se quiere multiplicar los servicios, entonces hay que multiplicar los chips en el teléfono, es decir, multiplicar también los conectores, lo que rápidamente pasa a ser muy oneroso. Con todo, esta solución garantiza un buen confinamiento entre los servicios, que de hecho corresponden todos ellos a un chip diferente y, por tanto, todos ellos a una memoria física diferente. Pero el coste de puesta en práctica de más de un servicio es disuasorio.
Otra de estas soluciones es una arquitectura puramente lógica que pone en práctica el concepto de dominio de seguridad. Un dominio de seguridad queda definido a nivel del sistema operativo del teléfono móvil, o de una capa superior del sistema operativo. Es una capa superior de este tipo, por ejemplo, una máquina virtual de tipo Java. El dominio de seguridad incluye al menos un área de memoria dividida en un área de programas y un área de datos. Los mecanismos del sistema operativo o de la capa superior garantizan que los códigos de instrucción del área de programas del dominio de seguridad no puedan acceder más que a los datos del área de datos de dicho dominio de seguridad. Este acceso al dominio de seguridad está protegido además por un conjunto de claves. Así, un dominio de seguridad lleva asociadas varias claves. Así, el ámbito de la técnica introduce la noción de juego de claves ("keyset") que interviene en la protección del dominio de seguridad, estando cada una de estas claves dedicada a una misión o una función de seguridad muy precisa, según las necesidades de refuerzo de la seguridad del dominio de seguridad. La siguiente lista de claves o de funciones de seguridad no es exhaustiva pero, para el refuerzo de la seguridad en un dominio, se pueden poner en práctica varias claves según las necesidades de seguridad propias del dominio en cuestión. Así, puede haber una clave para instanciar servicios en el dominio de seguridad, una clave para activar esos servicios, una clave para autentificar los accesos a esos servicios, una clave para cifrar las comunicaciones con esos servicios y una clave para modificar los parámetros del dominio de seguridad, es decir, para modificar el contenido del área de datos de dicho dominio. Sólo conociendo la clave correcta, o un medio de acceso a la clave correcta, se puede emprender la acción deseada.
Estos mecanismos permiten garantizar un buen confinamiento de los datos entre los diferentes dominios de seguridad para el caso en el que el sistema operativo subyacente pone en práctica el adecuado confinamiento (noción de «firewalling» o «sandbox» de Java). Pero esta solución adolece al menos de un gran inconveniente.
En efecto, un servicio es prestado a un consumidor para quien es importante la seguridad de sus datos. Por tanto, para cada consumidor, hay que instalar un dominio de seguridad distinto en el móvil de cada uno de los usuarios del servicio. Así que, si un operador que gestiona el terminal móvil desea proponer el mismo servicio protegido a dos consumidores diferentes, el operador está obligado a instalar dos veces el dominio de seguridad en el terminal del usuario y a prever dos juegos de claves, uno para cada uno de los consumidores. Estas instalaciones se multiplican con el número de servicios y el número de consumidores para cada uno o el conjunto de esos servicios. Consecuencia de ello es el aumento de los recursos de los que debe disponer un terminal móvil y, por tanto, el aumento de su coste y/o la disminución de sus prestaciones para un servicio dado.
En el contexto del mundo de la tarjeta inteligente Java (JavaCard™) y de la plataforma «Global Platform» (http://www.globalplatform.org/), se propone la noción de dominio de seguridad, pero se ve confrontada a la misma limitación, es decir, a la obligación de multiplicar los dominios de seguridad para instanciar varias veces una misma «applet» (aplicación en metalenguaje del lado del cliente) sobre datos diferentes y cuya confidencialidad y confinamiento han de ser garantizados a los prestadores y consumidores del servicio. A nivel del estado de la técnica de la tarjeta inteligente Java, hemos pasado de una tarjeta monoaplicación a una tarjeta multiaplicación con un modelo de tipo Global Platform, pero en nuestra invención proponemos resolver los problemas anteriormente identificados pasando de la noción de Tarjeta inteligente Java multiaplicación a tarjeta inteligente Java multiaplicación multidatos permitiendo extender el confinamiento nativo Java hasta los datos gestionados por una misma aplicación.
La solicitud europea EP1303153 da a conocer un procedimiento de selección de módulos de programas en un teléfono móvil; la solicitud internacional WO2005/076204 da a conocer un dispositivo de tipo tarjeta inteligente que propone una pluralidad de dominios de seguridad.
El objeto de la invención es solventar estos problemas proponiendo un procedimiento de puesta a disposición confinada de un servicio electrónico, en un terminal electrónico, para al menos un prestador abonado al servicio, prestador que propone ese servicio a una pluralidad de consumidores a través de la implantación, en una etapa previa, de un dominio de seguridad que garantiza el confinamiento del servicio y de un área de datos a la que puede acceder dicho servicio, ya sea directamente, o bien a través del tratamiento del servicio electrónico, siendo el dominio de seguridad accesible únicamente a través de una clave de acceso a los datos. En la invención, en el dominio de seguridad, el área de datos a la que puede acceder el servicio en el terminal electrónico está, de manera destacable, indexada en subáreas para garantizar que una petición de un consumidor de la pluralidad de consumidores sólo pueda leer/escribir/modificar una subárea predeterminada asociada al consumidor emisor de la petición, ya sea directamente, o bien a través del tratamiento del servicio electrónico.
Así pues, sólo se utilizan los recursos de un dominio de seguridad para proponer un servicio a al menos un prestador que a su vez propone ese servicio a una pluralidad de consumidores[j1].
La invención tiene pues como objeto un procedimiento de puesta a disposición confinada de un servicio electrónico, en un terminal electrónico, para al menos un prestador que, abonado al servicio, propone ese servicio a una pluralidad de consumidores a través de un dominio de seguridad que garantiza el confinamiento del servicio, y de un área de datos a la que puede acceder dicho servicio, siendo accesible el área de datos del dominio de seguridad únicamente a través de una clave de acceso a los datos, caracterizado porque:
En el dominio de seguridad, el área de datos a la que puede acceder el servicio en el terminal electrónico está indexada en subáreas para garantizar que una petición de un consumidor de la pluralidad de consumidores sólo puede leer/escribir/modificar una subárea predeterminada asociada al consumidor emisor de la petición.
En una variante, el procedimiento según la invención se caracteriza asimismo porque la indexación se realiza localmente en el terminal y mediante el servicio mediante la presentación al servicio por parte del consumidor de al menos un identificador que permite el desbloqueo del acceso a la subárea de datos asociada al consumidor identificado por el identificador.
En una variante, el procedimiento según la invención se caracteriza asimismo porque la identificación viene seguida de una autenticación basada en una clave de cifrado que el servicio es capaz de producir a partir de al menos el identificador del consumidor.
En una variante, el procedimiento según la invención se caracteriza asimismo porque la indexación se realiza mediante un dispositivo tercero caracterizado porque el dispositivo tercero, a la recepción de una petición de un consumidor, pone en práctica las siguientes etapas:
-
identificación del servicio requerido,
-
identificación del terminal en el que es requerido el ser vicio,
-
identificación del consumidor,
-
y, en caso de identificación positiva, emisión de una petición de
actualización hacia el terminal identificado para tomar en cuenta la petición del consumidor.
En una variante, el procedimiento según la invención se caracteriza asimismo porque la identificación del prestador viene seguida de una autenticación.
En una variante, el procedimiento según la invención se caracteriza asimismo porque la petición de actualización es cifrada con la clave de acceso a los datos.
En una variante, el procedimiento según la invención se caracteriza asimismo porque el prestador puede, a través de peticiones específicas hacia el servicio o el sistema operativo del dominio de seguridad o el sistema operativo del terminal, efectuar directamente todas las operaciones de gestión del área de datos indexada, tales como creación, inicialización, bloqueo, destrucción, sincronización de los datos entre diferentes consumidores y/o usuarios (lista que no es exhaustiva), pudiendo ser protegidas estas operaciones de gestión mediante diferentes claves ("keyset") conocidas por el prestador.
En una variante del dispositivo, el procedimiento según la invención es destacable porque la indexación del área de datos se realiza a partir de información que identifica al usuario del área en el terminal. Así, es posible gestionar a varios usuarios en un mismo terminal para uno o una pluralidad de consumidores frente a un mismo o una pluralidad de prestadores o servicios. Esta variante permite, entre otras cosas, la sincronización de información entre una pluralidad de usuarios para uno o una pluralidad de consumidores de un mismo servicio.
Se comprenderá mejor la invención con la lectura de la descripción siguiente y con la revisión de las figuras que la acompañan. Éstas se aportan a título indicativo y sin carácter limitativo alguno de la invención. Las figuras muestran:
Figura 1:
una ilustración de dispositivos cuyas memorias están estructuradas
según unas etapas del procedimiento según la invención en una puesta
en práctica local o remota,
figura 2:
una ilustración de etapas del procedimiento según la invención en una
puesta en práctica local,
figura 3:
también una ilustración de etapas del procedimiento según la invención,
en una puesta en práctica remota,
figura 4:
una ilustración de una tabla de indexación.
La
figura 1 muestra un terminal 101 móvil que pone en práctica el
procedimiento según la invención. En el presente ejemplo, el terminal 101 es un teléfono móvil. En la práctica, puede tratarse de todos los dispositivos ya citados en el preámbulo. La figura 1 muestra que el teléfono 101 incluye al menos un microprocesador 102, circuitos 103 de interfaz de comunicación, una memoria 104 de programas y un lector 105 de tarjeta chip. Los elementos 102 a 105 se hallan interconectados mediante un bus 106.
En este documento, cuando se atribuye una acción a un dispositivo, esta acción la realiza de hecho un microprocesador de dicho dispositivo gobernado mediante códigos de instrucción de una memoria de programas de dicho dispositivo. Cuando se atribuye una acción a un programa, esta acción corresponde a la ejecución de la totalidad o parte de los códigos de instrucción de un área de una memoria de programas, correspondiendo entonces dicha área al programa, por un microprocesador del dispositivo al que pertenece la memoria de programas en la que está grabado el programa.
En este documento se utiliza el término servicio para designar un programa que
corresponde a una oferta de servicio vendido por un operador o prestador.
Así, por ejemplo, un operador de telefonía móvil vende a un prestador de servicios un servicio de contabilidad de puntos de fidelidad. Este prestador tiene a su vez clientes que son consumidores de servicio, por ejemplo un panadero, un vendedor de discos o de bienes cualesquiera, del servicio de contabilidad de puntos de fidelidad. Este consumidor del servicio puede a su vez proponer a sus clientes finales, de hecho las personas en general, una tarjeta electrónica de fidelidad. En un terminal, el mismo servicio/programa puede ser por tanto utilizado para varios consumidores, en este caso para varias tiendas.
Son ejemplos de servicios, además del que acaba de ser mencionado, servicios de cifrado de extremo a extremo, servicios de autenticación mutua, servicios de gestión de derechos electrónicos, servicios de pago, servicios de firmas electrónicas,..., lista que no es exhaustiva.
En una variante de la invención, el prestador coincide con el propio operador de telefonía.
Los circuitos 103 permiten al teléfono 101 comunicarse según normas variadas, entre ellas las normas de telefonía móvil, y ello en todos los modos de voz/data, así como normas de comunicación local como BlueTooth®, Wifi, pero también las normas llamadas sin contacto como la RFID/NFC.
Los circuitos 105 permiten al teléfono 101 establecer una interfaz con una tarjeta 107 SIM/USIM (Subscriber Identification Module, por módulo de identificación del abonado/UMTS). La tarjeta 107 incluye al menos un microprocesador 108 y una memoria 109 de programa. Los elementos 105, 108 y 109 se hallan interconectados mediante un bus 110.
La memoria 109 incluye como es convencional un área 111 que incluye códigos de instrucción correspondientes a un sistema operativo. El sistema operativo permite a unos programas instalados en la tarjeta 107 acceder a los recursos (comunicaciones, sistema de archivos,...) de la tarjeta 107. Todos los programas instalados en la tarjeta 107 recurren por tanto a funciones del sistema operativo 111.
La figura 1 muestra un área 112 de la memoria 109 que corresponde a un programa «lambda» y que por tanto incluye códigos de instrucción directamente conectados con el sistema operativo 111.
En la invención se utiliza el conocido mecanismo de dominio de seguridad. Este mecanismo implica la puesta en práctica de funcionalidades suplementarias en el sistema operativo. En la práctica, estos mecanismos son realizados por una máquina virtual, por ejemplo una máquina virtual Java. La figura 1 muestra una máquina 113 virtual de este tipo. En teoría, esta máquina virtual es un intermediario entre llamadas realizadas por un programa escrito para la máquina virtual y el sistema operativo en el que está instalada la máquina virtual.
En la práctica, las máquinas virtuales saben crear dominios de seguridad, es decir, los dominios de seguridad pueden ser creados con la puesta en producción de la tarjeta o dinámicamente, tras la fase de puesta en producción de la tarjeta. La figura 1 muestra un dominio SD1 de seguridad. El dominio SD1 es un área de la memoria
109. El dominio SD1 incluye un área S1 que corresponde a códigos de instrucciones interpretables por la máquina 113 y correspondientes a la realización de un servicio tal como aquellos mencionados anteriormente.
El dominio SD1 también incluye un área de datos. En la invención, esta área de datos está 30 subdividida en subáreas D1.1, D1.2 hasta D1.n. El mecanismo de dominio de seguridad garantiza que sólo los códigos de instrucción del área S1 pueden acceder a los datos del área de datos de SD1. La invención permite asociar cada subárea D1.x con un consumidor dado. Según el consumidor que invoque el servicio S1, sólo será accesible una subárea. Cada servicio y, por tanto, cada dominio de seguridad, queda identificado mediante un identificador de servicio Sx. Cada consumidor queda identificado mediante un identificador de consumidor idC.
Para ello, la máquina 113 y/o el área S1 incluyen códigos de instrucciones grabados en un área SEC y dedicados a la verificación de la validez de una petición dirigida al servicio S1 o, con carácter general, al servicio Sx. Cada dominio de seguridad tiene su propia área SEC. Los códigos grabados en el área SEC garantizan pues la indexación del área de datos.
Cuando se dice que el servicio S1 se comunica con el exterior, éste lo hace a través de la tarjeta 107 SIM y el teléfono 101.
La figura 1 muestra un dispositivo 130 consumidor utilizado por un consumidor que desea enviar peticiones al servicio S1. El dispositivo 103 incluye un microprocesador 131, una memoria 132 de identificador, una memoria 133 de claves de cifrado, de autenticación, una memoria 134 de programas y circuitos 135 de interfaz de comunicación. El dispositivo 130 también incluye una memoria 136 de identificación de un servicio, una memoria 137 de instrucciones y, en una variante, una memoria 138 de identificación de un servidor proxy.
Los elementos 131 a 138 se hallan interconectados a través de un bus 139. Los circuitos 135 son de igual naturaleza que los circuitos 103 y compatibles al menos
con una de las normas de entre las puestas en práctica por los circuitos 103.
La memoria 134 incluye al menos códigos de instrucciones para la emisión de una petición al servicio S1. En una variante de la invención, la memoria 134 también incluye códigos de instrucciones para poder responder a un desafío de autenticación lanzado por el servicio S1. En una variante, la memoria 134 incluye códigos de instrucciones para la puesta en práctica de una función F de cifrado, simétrico o asimétrico.
La figura 2 ilustra unas etapas del procedimiento según la invención para el caso en el que la indexación del área de datos del dominio de seguridad SD1 es gestionada localmente por la tarjeta 107 SIM.
Con anterioridad a la puesta en práctica de las etapas que van a ser descritas en relación con las figuras 2 y 3, un operador ha puesto en práctica una etapa de instalación de los servicios en la tarjeta 107. En esta etapa, el operador estructura la memoria 109 tal como se ha descrito en relación con la figura 1. Es decir, el operador instala en la memoria 109 al menos un dominio de seguridad tal como el dominio SD1.
La figura 2 muestra una etapa 201 en la que un consumidor activa el dispositivo 130 para interaccionar con el teléfono 101. Esta activación se realiza, por ejemplo, a través de una interfaz mecánica de mando mientras que un portador del teléfono 101 aproxima este último al dispositivo 130. En tal caso, la comunicación entre el dispositivo 130 y el teléfono 101 se opera, sin carácter limitativo, a través de los mecanismos del tipo RFID/NFC o de los mecanismos del tipo infrarrojo o Bluetooth® o cualquier otro medio de comunicación de proximidad o a través de comunicaciones Data transportadas sobre una infraestructura de red móvil o fija.
El dispositivo 130 produce una petición 205 que incluye al menos un identificador 202 del consumidor, un identificador 203 del servicio y un código 204 de instrucción. En el ejemplo que nos ocupa, esta información es emitida a través de una única petición. En la práctica, podría serlo a través de un intercambio de peticiones entre el dispositivo 130 y el teléfono 101. La información útil para la producción de la petición 205 es leída en las memorias 132, 136 y 137. Estas memorias son actualizadas por el operador/prestador en el momento en que suministra al consumidor el dispositivo 130. El contenido del campo 204 puede variar en función de una intención del consumidor y a través de una parametrización del dispositivo 130. Por el contrario, los campos 202 y 203 se hallan bajo el control del prestador, al igual que la memoria 133.
La petición 205, una vez emitida, es emitida hacia el teléfono 101.
En una etapa 206, el teléfono 101 recibe la petición 205 y la transmite a la tarjeta 107 que la trata. Este tratamiento consiste al menos en leer el campo 203 para identificar un servicio y, por tanto, un dominio de seguridad. Si existe el servicio designado por el campo 203, entonces la petición 205 es tratada por ese servicio. Considérese en el presente caso que se trata, por ejemplo, del servicio S1. Entonces el servicio S1 trata la petición 205. Si no es encontrado el servicio designado por la petición 205, entonces sencillamente se ignora esta petición. El tratamiento de la petición 205 por parte del servicio S1 consiste al menos, primeramente, en leer el campo 202 y en buscar si un área D1.x se corresponde con el consumidor así designado. Esta búsqueda corresponde de hecho a una identificación realizada durante una etapa 207. Si el servicio no consigue identificar a un consumidor, entonces se pasa a una etapa 208 de fin, lo que supone ignorar la petición 205, de lo contrario, se pasa a una etapa 209 de prueba de una autenticación.
La etapa 209 es una variante de la invención. En la etapa 209, el servicio prueba si, por configuración, la puesta en práctica del servicio requiere una autenticación después de la identificación. Si tal es el caso, el servicio S1 pasa a una etapa 210 de autenticación del consumidor, de lo contrario, pasa a una etapa 211 de ejecución del código de instrucción descrito en el campo 204.
En la etapa 210, el servicio procede a una autenticación implícita o explícita en un solo sentido o mutua del consumidor a través de uno o varios intercambios. Una autenticación implícita es una autenticación basada en la recepción/transmisión de un valor resultado de una operación criptográfica que establece la posesión, por la entidad que ha de ser autenticada, de dicho secreto de autenticación.
En una variante preferida de la etapa 210, la tarjeta 109 produce un mensaje 212 de desafío que incluye un evento. Este mensaje 212 es recibido en una etapa 213 por el dispositivo 130. En la etapa 213, el dispositivo cifra el evento con la función F conocida por el dispositivo 130 y con la clave de la memoria 133. En una variante de la etapa 213, el dispositivo 130 calcula una diversificación de la clave de la memoria 133 partiendo del valor del evento y de una función de diversificación o «hash» o en un solo sentido F conocida por el dispositivo 130. De hecho, la clave de la memoria 133 es una clave Kf hija de una clave Ks del juego de claves («keyset») asociado al dominio de seguridad SD1. Tenemos por tanto:
Kf = Fk (idC, Ks)
donde idC es el contenido de la memoria 132. Al instalar el dominio de seguridad, la tarjeta 109 conoce Ks. De acuerdo con
esta variante de la invención, el servicio S1 conoce Fk y F. Estas funciones Fk se instalan al mismo tiempo que los dominios de seguridad de la memoria 109. Finalmente, en virtud de la petición 205, el servicio S1 conoce idC.
Finalizada la etapa 213, el dispositivo 130 emite un mensaje 214 de respuesta que incluye F(evento, Kf).
En una etapa 215, el servicio S1 recibe, a través de la tarjeta 107 y el teléfono 101, el mensaje 214. Entonces el servicio S1 compara el contenido del mensaje 214 con su propio cálculo F(evento, Fk(idC, Ks)). Si estos cálculos son iguales, entonces el servicio S1 pasa a la etapa 221 o, de lo contrario, pasa a una etapa 216 de fin y la petición 205 es ignorada.
En la etapa 211, el servicio S1 ejecuta la o las instrucciones descritas en el campo 204. Esta ejecución implica lecturas y/o escrituras en el área de datos del dominio de seguridad. En la invención, el servicio S1 asocia con cada identificador de consumidor una subárea del área de datos. Esta asociación se opera, por ejemplo, a través del área SEC que corresponde al dominio de seguridad, o directamente mediante el servicio S1. Esta área describe entonces, para cada identificador de consumidor, la subárea en la que hay que leer/escribir/modificar. Cualquier intento de leer o escribir fuera de esta subárea conllevaría una denegación de ejecución por parte de la máquina virtual.
En una variante de la invención, la instrucción recibida a través del campo 204 es cifrada con la clave Kf de la memoria 133 y la función F. Por tanto, esta instrucción sólo puede ser ejecutada correctamente si el consumidor se ha identificado correctamente y si ha proporcionado al servicio S1 los debidos elementos S1 para decodificar la instrucción. Se describirá un mecanismo de cifrado de este tipo en la variante ilustrada por la figura 3.
La figura 3 ilustra una variante de la invención en la que la actualización/lectura de una subárea de un dominio de seguridad se opera a través de un servidor proxy de un prestador que ha propuesto un servicio a consumidores de servicios.
La figura 1 ilustra un servidor 161 proxy de este tipo. El servidor 161 está conectado a una red 162 a través de los circuitos 163 de interfaz. El dispositivo 130 es apto para conectarse a la red 162 a través de, por ejemplo, una estación base 164 de una red de telefonía móvil, pudiendo la red ser asimismo una red fija o, directamente, Internet. Por tanto, el dispositivo 130 y el servidor 161 pueden comunicarse.
El servidor 161 incluye un microprocesador 165, una memoria 166 de programa y una memoria 167 de configuración.
La memoria 166 incluye códigos de instrucciones para la puesta en práctica de una comunicación con el dispositivo 130, códigos de instrucciones para la puesta en práctica de una comunicación con los servicios instalados en la tarjeta SIM 107 del teléfono 101, códigos de instrucciones para la puesta en práctica de una función F de cifrado simétrico y códigos de instrucciones para la puesta en práctica de una función Fk de producción de una clave Kf de cifrado.
En esta variante de la invención, el área SEC de seguridad de los dominios de seguridad instalados en la tarjeta 109 conoce y es apta para poner en práctica la función F. La memoria 133 incluye el valor
Kf = Fk (idC, Ks)
habiendo sido descritos anteriormente cada uno de estos símbolos.
La memoria 167 de hecho corresponde a una tabla, correspondiendo cada línea de la tabla a un consumidor. Por tanto, cada línea incluye al menos un campo 168 identificador de consumidor, un campo 169 identificador de servicio y un campo 170 de clave de cifrado. El contenido del campo 170 es de hecho una de las claves del juego de claves asociado al dominio de seguridad en el que se pone en práctica el servicio identificado por el campo 169.
La figura 3 muestra una etapa 301 en la que un usuario del dispositivo 130 produce y emite una petición 302 para acceder a un servicio instalado en el teléfono
101. Esta petición incluye varios campos, entre ellos al menos un campo 303 identificador del terminal 101, un campo 304 identificador del consumidor, un campo 305 identificador de un servicio y un campo 306 que describe un código de instrucción que habrá de ser ejecutado por el servicio identificado por el contenido del campo 305. Esta petición 302, una vez producida, es emitida hacia el servidor 161, cuya dirección conoce el dispositivo 130 a través del contenido del campo 138. Esta emisión se opera en modo de datos (protocolo de tipo TCP/IP), o a través de un mensaje corto (protocolo de tipo SMS/MMS).
Al igual que en relación con la etapa 201, la información descrita para la trama 302 será emitida por el dispositivo 130. Sin embargo, esta información puede ser emitida en una sola trama según se ha descrito, o en varias tramas en el transcurso de un diálogo entre el dispositivo 130 y el servidor 161.
El contenido del campo 303 es, en un ejemplo preferido, un número de teléfono (MSISDN) que permite establecer comunicación con el teléfono 101. Este número de teléfono es obtenido por el dispositivo 130, ya sea en el transcurso de una introducción de datos, o bien en el transcurso de un diálogo entre el teléfono 101 y el dispositivo 130. Sin carácter limitativo, el contenido del campo 303 podría ser cualquier identificador de red del abonado, un IMSI o el IMEI en el contexto de una red móvil, pero también un identificador de la tarjeta inteligente del abonado, de tipo ICCID o la trama TAR obtenida por el teléfono en el «boot» (arranque) de la tarjeta inteligente, pudiendo asimismo estar basado este identificador en cualquier medio de identificación del usuario frente al operador de conexión: una dirección IPv6, una dirección ethernet, e incluso una dirección de correo electrónico, pudiendo contemplarse también un identificador de tipo SIP o VoIP, un identificador de tipo ENUM o cualquier otra identidad electrónica.
En una etapa 307, el servidor 161 emprende una búsqueda en la tabla 167. Esta búsqueda es una identificación 308 del consumidor que ha emitido la petición
302. Esta búsqueda consiste en buscar una línea de la tabla 167 cuyos campos 168 y 169 son iguales a los campos 304 y 305. Si semejante línea L es encontrada, entonces la identificación es positiva o, en caso contrario, es negativa y el servidor 161 pasa a una etapa 309 en la que ignora la petición 302.
En caso de identificación positiva, el servidor 161 pasa a una etapa 310 de prueba de autenticación. Esta etapa consiste en determinar si, además de la identificación, se requiere una autenticación. Esta etapa es opcional y se puede realizar a través de un campo de configuración de la línea L. Si este campo vale 1, por ejemplo, entonces se requiere la autenticación, de lo contrario, no se requiere la autenticación.
Si se requiere la autenticación, el servidor pasa a una etapa 311 de lanzamiento de un desafío al dispositivo 130. La etapa 311 es idéntica a la etapa 210 ya descrita y viene seguida de las etapas 312, 313 y 314, idénticas a las etapas 213, 215 y 216. Sin embargo, en esta ocasión, las etapas 312, 313 y 314 son puestas en práctica por el servidor 161 y no por la tarjeta 107.
En caso de éxito de la petición de autenticación lanzada por el servidor 161, el servidor pasa a una etapa 314 de producción de una petición 315 de instrucción.
En un ejemplo preferido, la petición de instrucción 315 incluye, al menos, en una cabecera, un campo 316 que identifica el teléfono destinatario de la petición de instrucción. La petición se emite, por ejemplo, a través de un mensaje corto o a través de cualquier otro medio de comunicación, dependiendo del tipo de identificador de red utilizado, incluyendo el campo 316 el valor recibido por el servidor 161 a través del campo 303.
La petición 315 también incluye un campo 317 identificador de servicio cuyo contenido corresponde al contenido del campo 169 de la línea L encontrada en la etapa 308.
La petición 315 también incluye un campo 318 cifrado mediante la función F utilizando la clave Ks del campo 170 de la línea L. En síntesis, el campo 318 incluye al menos un campo 319 que describe la instrucción que ha de ejecutarse y, de manera opcional, un campo 320 de tipo suma de control (CRC). El campo 320 incluye una suma de control del campo 319.
La clave Ks es de hecho la clave de acceso a los datos del juego de claves del dominio de seguridad en el que se ejecuta el servicio identificado por el campo 169.
El campo 319 puede ser más complejo incluyendo una serie de instrucciones y/o de parámetros para la instrucción. El campo 319 incluye, de manera implícita o explícita, una identificación del consumidor que ha emitido la petición que ha conducido a la producción de la instrucción 315. Esta identificación es, por ejemplo, un identificador que permite al servicio identificado por el campo 317 determinar una subárea del área de datos del dominio de seguridad en el que se ejecuta el servicio.
Esta identificación se halla de manera implícita, por ejemplo, contenida en los parámetros de la o de las instrucciones que se han de ejecutar. Estos parámetros designan efectivamente datos que han de actualizarse o leerse. El servidor 161 utiliza su conocimiento de la identidad del consumidor para producir instrucciones, para el campo 319, que sólo leen y escriben en una subárea asignada al consumidor identificado en la línea L. El conocimiento de esta subárea se almacena entonces en la línea L. En una variante, el conocimiento de esta subárea se almacena en el área SEC del dominio de seguridad.
La petición de instrucción 115, una vez producida, es emitida hacia el teléfono 101, el cual la recibe en una etapa 321 y la transmite a la tarjeta 107. La tarjeta 107 utiliza entonces el contenido del campo 317 para transmitir la petición 315 al servicio identificado por el campo 317, si lo hay o, de lo contrario, la petición 315 es ignorada. En el ejemplo que nos ocupa, se considera que se trata del servicio S1.
En la etapa 321, el servicio S1 utiliza la clave Ks para descifrar el campo 318. Seguidamente el servicio S1 calcula una suma de control del contenido del campo 319 descifrado y compara el resultado de esa suma de control con el contenido del campo 320 descifrado, si se pone en práctica la opción suma de control (CRC). Si esta comparación es una igualdad, entonces el servicio S1 pasa a una etapa 322 de ejecución de las instrucciones descritas por el contenido del campo 319 descifrado o, de lo contrario, la petición 315 es ignorada por el servicio.
En esta variante, la indexación de los datos la desempeña un servidor tercero que garantiza, mediante las instrucciones que envía a un servicio dado, después de haber identificado y/o autentificado a un consumidor, que ese consumidor sólo tiene acceso a los datos que le atañen.
En una variante, el dispositivo consumidor es, de hecho, una aplicación instalada en la memoria 104 de programa del terminal 101 (por ejemplo, una aplicación de mensajería, o una aplicación de tipo «player multimedia» que tiene que gestionar datos relativos a la DRM y flujos continuos de transmisión (streaming) cifrados, o una aplicación para intercambiar/compartir datos multimedia, como también una aplicación de tipo telefonía o videotelefonía sobre IP). Este programa puede necesitar entonces servicios de cifrado o servicio de gestión de derechos para permitir que el usuario del teléfono 101 se comunique con uno o varios servidores de contenido. En tal caso, la aplicación se identifica como un consumidor y sólo tiene acceso a una subárea del área de datos del dominio de seguridad en el que se ejecuta el servicio de cifrado o de gestión de derechos. En el caso de una aplicación genérica, es el servidor de contenido el que proporciona a la aplicación genérica la información que le permita identificarse como servicio.
En la invención, en la misma tarjeta SIM pueden coexistir varios dominios de seguridad y, por tanto, varios servicios. Cabe por tanto la posibilidad de proponer el mismo servicio a varios consumidores a través de un único dominio de seguridad. También cabe la posibilidad de prestar varios servicios a varios consumidores a través de varios dominios de seguridad.
En una variante del dispositivo, el procedimiento según la invención es destacable porque la indexación del área de datos se realiza a partir de información que identifica al usuario del área en el terminal. Así, es posible gestionar a varios usuarios en un mismo terminal para uno o una pluralidad de consumidores frente a un mismo o una pluralidad de prestadores o servicios. Esta variante permite, entre otras cosas, la sincronización de información entre una pluralidad de usuarios para uno o una pluralidad de consumidores de un mismo servicio.
En la práctica, los dominios de seguridad se ponen en práctica a través de una plataforma Java. Entonces se utiliza una máquina virtual Java. Los programas que corresponden a los servicios se denominan entonces "applets" (miniaplicaciones) o aplicación java que se ejecuta en un dispositivo cliente.
Como ya se ha descrito, la indexación de un área de datos de un dominio de seguridad es realizada bien localmente por el servicio, o bien a distancia por un servidor proxy. En los ejemplos descritos, esta indexación se opera a través de una "tabla de asignación" 400 que asocia un identificador de consumidor con una descripción de un área de memoria. Una descripción de este tipo corresponde, por ejemplo, a direcciones de inicio y de fin del área de memoria. En una variante de la invención, se considera que cada subárea tiene el mismo tamaño. Un área de datos es vista entonces como un cuadro, correspondiendo así pues cada casilla del cuadro a una subárea. En tal caso, un simple índice permite acceder directamente a la subárea correcta. En otra variante más, se utiliza una indexación secuencial, almacenando cada subárea un identificador de consumidor, operándose entonces la elección de la subárea correcta mediante un recorrido secuencial de las subáreas hasta que se encuentre el identificador correcto. Los códigos de instrucciones producidos toman en cuenta el modo de indexación.
En la invención, las miniaplicaciones y los dominios de seguridad son instalados por el operador que ha suministrado la tarjeta SIM. Ello permite al operador garantizar la calidad y la inocuidad de los códigos a través de diferentes procedimientos de análisis formal. Esto también permite al operador formatear previamente las áreas de datos de las áreas de seguridad.
Para el mantenimiento de estas aplicaciones, el procedimiento según la invención permite al operador/ prestador, a través de peticiones específicas hacia el servicio o el sistema operativo del dominio de seguridad o el sistema operativo del terminal, efectuar directamente todas las operaciones de gestión del área de datos indexada, tales como creación, inicialización, bloqueo, destrucción, sincronización de los datos entre diferentes consumidores y/o usuarios, ..., pudiendo ser protegidas estas operaciones de gestión mediante diferentes claves conocidas por el prestador.
El operador/prestador, en la medida en que conoce la totalidad o parte del juego de claves asociado a un dominio de seguridad, puede producir, como en el caso descrito en relación con la indexación a distancia, una instrucción que será reconocida y ejecutada por el servicio que debe ser mantenido. En una variante, para el mantenimiento, el operador/prestador se identifica/autentifica como un supraconsumidor al cual el dominio de seguridad concede todos los derechos sobre el conjunto de su área de datos.

Claims (9)

  1. REIVINDICACIONES
    1. Procedimiento de puesta a disposición confinada de un servicio (S1) electrónico, en un terminal (101) electrónico de un usuario, para al menos un prestador
    (161) abonado al servicio, prestador que propone ese servicio a una pluralidad de consumidores (130) a través de la implantación, en una etapa previa, de un dominio (SD1) de seguridad que garantiza el confinamiento del servicio y de un área (D1) de datos a la que puede acceder dicho servicio, ya sea directamente, o bien a través de un tratamiento del servicio electrónico, siendo el área de datos del dominio de seguridad accesible únicamente a través de una clave de acceso a los datos, caracterizado porque incluye las siguientes etapas:
    -el terminal indexa (211, 314), en el dominio de seguridad, el área de datos a la que el servicio puede acceder en el terminal electrónico en subáreas para garantizar que una petición (205, 302) de un consumidor de la pluralidad de consumidores sólo pueda leer/escribir/modificar una subárea (D1.x) predeterminada asociada al consumidor emisor de la petición, ya sea directamente, o bien a través del servicio electrónico.
  2. 2.
    Procedimiento según la reivindicación 1, caracterizado porque la indexación se realiza localmente (211) en el terminal y mediante el servicio mediante la presentación al servicio por parte del consumidor de al menos un identificador que permite el desbloqueo del acceso a la subárea de datos asociada al consumidor identificado por el identificador.
  3. 3.
    Procedimiento según la reivindicación 2, caracterizado porque la identificación
    (207) viene seguida de una autenticación (209, 210, 212 a 215) basada en una clave de cifrado que el servicio es capaz de producir a partir de al menos el identificador del consumidor.
  4. 4. Procedimiento según la reivindicación 1, caracterizado porque la indexación se realiza mediante un dispositivo (161) tercero, caracterizado porque el dispositivo tercero, a la recepción de una petición de un consumidor, pone en práctica las siguientes etapas:
    -identificación del servicio requerido, -identificación del terminal en el que es requerido el servicio,
    -identificación del consumidor,
    -y, en caso de identificación positiva, emisión de una petición de actualización hacia el terminal identificado para tomar en cuenta la petición del consumidor.
  5. 5. Procedimiento según la reivindicación 4, caracterizado porque la identificación
    (308) del prestador viene seguida de una autenticación (310 a 313).
  6. 6.
    Procedimiento según una de las reivindicaciones 4 ó 5, caracterizado porque la petición de actualización es cifrada (314) con la clave de acceso a los datos.
  7. 7.
    Procedimiento según una de las reivindicaciones 1 a 6, caracterizado porque el prestador puede, a través de peticiones específicas hacia el servicio o el sistema operativo del dominio de seguridad o el sistema operativo del terminal, efectuar directamente todas las operaciones de gestión del área de datos indexada, tales como creación, inicialización, bloqueo, destrucción, sincronización de los datos entre diferentes consumidores y/o usuarios, ..., pudiendo ser protegidas estas operaciones de gestión mediante diferentes claves conocidas por el prestador.
  8. 8.
    Procedimiento según una de las reivindicaciones 1 a 7, caracterizado porque la indexación del área de datos se realiza a partir de información que identifica al usuario del área en el terminal, para uno o una pluralidad de consumidores frente a un mismo o una pluralidad de prestadores o servicios.
  9. 9.
    Puesta en práctica del procedimiento según una de las reivindicaciones 1 a 8 en una tarjeta (107) chip (tarjeta SIM) de un teléfono móvil.
    1/3
ES07301379T 2006-10-05 2007-09-19 Procedimiento de puesta a disposición confinada de un servicio electrónico. Active ES2350268T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0654118 2006-10-05
FR0654118A FR2906960B1 (fr) 2006-10-05 2006-10-05 Procede de mise a disposition cloisonnee d'un service electronique.

Publications (1)

Publication Number Publication Date
ES2350268T3 true ES2350268T3 (es) 2011-01-20

Family

ID=37998428

Family Applications (1)

Application Number Title Priority Date Filing Date
ES07301379T Active ES2350268T3 (es) 2006-10-05 2007-09-19 Procedimiento de puesta a disposición confinada de un servicio electrónico.

Country Status (9)

Country Link
US (1) US20080091604A1 (es)
EP (1) EP1909462B1 (es)
JP (1) JP2008102925A (es)
KR (1) KR20080031827A (es)
CN (1) CN101159940A (es)
AT (1) ATE477660T1 (es)
DE (1) DE602007008336D1 (es)
ES (1) ES2350268T3 (es)
FR (1) FR2906960B1 (es)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2933559A1 (fr) * 2008-07-01 2010-01-08 France Telecom Procede d'installation d'une application de gestion et procede de gestion de donnees d'application d'un module de securite associe a un terminal mobile
EP2897341B1 (en) 2009-04-20 2016-11-09 Interdigital Patent Holdings, Inc. System of multiple domains and domain ownership
CN102668501B (zh) * 2009-10-15 2015-12-09 交互数字专利控股公司 用于接入基于订阅的服务的注册和凭证转出
FR2973185B1 (fr) * 2011-03-22 2013-03-29 Sagem Defense Securite Procede et dispositif de connexion a un reseau de haute securite
KR101308226B1 (ko) * 2011-10-28 2013-09-13 에스케이씨앤씨 주식회사 모바일 기기에 장착된 ｓｅ를 위한 통신 인터페이스 방법 및 이를 적용한 ｓｅ
US9197700B2 (en) 2013-01-18 2015-11-24 Apple Inc. Keychain syncing
US10375087B2 (en) * 2014-07-21 2019-08-06 Honeywell International Inc. Security architecture for the connected aircraft
CN105450406B (zh) * 2014-07-25 2018-10-02 华为技术有限公司 数据处理的方法和装置
CN105678192B (zh) * 2015-12-29 2018-12-25 北京数码视讯科技股份有限公司 一种基于智能卡的密钥应用方法及应用装置
CN107038038B (zh) * 2016-02-03 2021-12-21 紫光同芯微电子有限公司 一种运行大容量usim小应用程序的方法
US20170272435A1 (en) * 2016-03-15 2017-09-21 Global Tel*Link Corp. Controlled environment secure media streaming system
CN106453398B (zh) * 2016-11-22 2019-07-09 北京安云世纪科技有限公司 一种数据加密系统及方法
CN107563224B (zh) * 2017-09-04 2020-07-28 浪潮集团有限公司 一种多用户物理隔离方法及装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4268690B2 (ja) * 1997-03-26 2009-05-27 ソニー株式会社 認証システムおよび方法、並びに認証方法
US6859791B1 (en) * 1998-08-13 2005-02-22 International Business Machines Corporation Method for determining internet users geographic region
GB2380901B (en) * 2001-10-10 2005-09-14 Vodafone Plc Mobile telecommunications apparatus and methods
JP3895245B2 (ja) * 2002-09-19 2007-03-22 株式会社エヌ・ティ・ティ・ドコモ 鍵の更新が可能な利用者の識別情報に基づく暗号化方法及び暗号システム
JP4428055B2 (ja) * 2004-01-06 2010-03-10 ソニー株式会社 データ通信装置及びデータ通信装置のメモリ管理方法
KR100437513B1 (ko) * 2004-02-09 2004-07-03 주식회사 하이스마텍 복수의 발급자 시큐리티 도메인을 설치할 수 있는 스마트카드 및 하나의 스마트 카드에 복수의 발급자 시큐리티도메인을 설치할 수 있는 방법
JP4576894B2 (ja) * 2004-06-14 2010-11-10 ソニー株式会社 情報管理装置及び情報管理方法

Also Published As

Publication number Publication date
KR20080031827A (ko) 2008-04-11
JP2008102925A (ja) 2008-05-01
US20080091604A1 (en) 2008-04-17
FR2906960A1 (fr) 2008-04-11
DE602007008336D1 (de) 2010-09-23
EP1909462A2 (fr) 2008-04-09
EP1909462A3 (fr) 2009-08-05
FR2906960B1 (fr) 2009-04-17
EP1909462B1 (fr) 2010-08-11
ATE477660T1 (de) 2010-08-15
CN101159940A (zh) 2008-04-09

Similar Documents

Publication Publication Date Title
ES2350268T3 (es) Procedimiento de puesta a disposición confinada de un servicio electrónico.
US9775024B2 (en) Method for changing MNO in embedded SIM on basis of dynamic key generation and embedded SIM and recording medium therefor
CN106161359B (zh) 认证用户的方法及装置、注册可穿戴设备的方法及装置
KR101276092B1 (ko) 보안 정보 저장 장치와 적어도 하나의 제３자 사이의 통신방법 및 시스템, 그리고 이에 대응되는 개체, 장치 및제３자
JP5496652B2 (ja) 移動端末の近接通信モジュールへのセキュアなアクセスを保障する方法
WO2016107410A1 (zh) 通信控制装置、鉴权装置、中心控制装置及通信系统
ES2881873T3 (es) Procedimiento de protección de una ficha de pago
ES2713390T3 (es) Procedimiento de verificación de identidad de un usuario de un terminal comunicante y sistema asociado
EP3787221A1 (en) Method for storing digital key and electronic device
ES2699925T3 (es) Procedimiento de autenticación de un usuario, servidor, terminal de comunicaciones y programas correspondientes
CN104205891A (zh) 虚拟sim卡云平台
ES2559617T3 (es) Procedimiento para la comunicación de datos entre un elemento seguro y un punto de acceso a la red y el elemento seguro correspondiente
WO2013182154A1 (zh) 一种对通讯终端上应用程序加、解密的方法、系统和终端
KR20080098640A (ko) 휴대형 통신 객체 내의 대용량 기억부 및 보안 기억부를 원격 액세스하기 위한 시스템
CN104660567B (zh) D2d终端接入认证方法、d2d终端及服务器
WO2012163975A1 (en) A method for accessing at least one service, corresponding communicating device and system
JP5388088B2 (ja) 通信端末装置、管理装置、通信方法、管理方法及びコンピュータプログラム。
KR100726074B1 (ko) 무선 인터넷 사용자 인증 방법 및 시스템
KR101040577B1 (ko) 모바일 애플리케이션 재발급 방법 및 시스템
US20180253541A1 (en) Transaction system
KR102088499B1 (ko) 스마트폰과 연동되는 모바일 유닛과 서버 간의 보안 통신을 위한 방법 및 시스템
KR20110005615A (ko) 사용자 매체를 이용한 무선 오티피 운영 방법 및 시스템과 이를 위한 무선단말 및 기록매체
Kasper et al. Rights management with NFC smartphones and electronic ID cards: A proof of concept for modern car sharing
US20230033931A1 (en) Method, ledger and system for establishing a secure connection from a chip to a network and corresponding network
KR20130053132A (ko) 메모리 카드 및 이를 구비한 휴대 단말기, 이를 이용한 암호화 메시지 교환 방법