ES2243096T3 - Procedimiento, tarjeta chip y aparato para una interfaz logica entre dos aplicaciones. - Google Patents
Procedimiento, tarjeta chip y aparato para una interfaz logica entre dos aplicaciones.Info
- Publication number
- ES2243096T3 ES2243096T3 ES99974202T ES99974202T ES2243096T3 ES 2243096 T3 ES2243096 T3 ES 2243096T3 ES 99974202 T ES99974202 T ES 99974202T ES 99974202 T ES99974202 T ES 99974202T ES 2243096 T3 ES2243096 T3 ES 2243096T3
- Authority
- ES
- Spain
- Prior art keywords
- mentioned
- chip card
- data
- apdu
- application
- 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.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
- G06K7/10—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation
- G06K7/10009—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves
- G06K7/10297—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves arrangements for handling protocols designed for non-contact record carriers such as RFIDs NFCs, e.g. ISO/IEC 14443 and 18092
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
- G06K7/0008—General problems related to the reading of electronic memory record carriers, independent of its reading method, e.g. power transfer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Physics & Mathematics (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Computer Security & Cryptography (AREA)
- Toxicology (AREA)
- Artificial Intelligence (AREA)
- Computer Vision & Pattern Recognition (AREA)
- General Health & Medical Sciences (AREA)
- Electromagnetism (AREA)
- Telephone Function (AREA)
- Storage Device Security (AREA)
- Credit Cards Or The Like (AREA)
- Logic Circuits (AREA)
- Communication Control (AREA)
- Stored Programmes (AREA)
Abstract
Procedimiento, con el que una primera aplicación (3) puede acceder a través de una interfaz lógica (4) a componentes (G1, G2, G3, ...) de una segunda aplicación (5), si no está definida una unidad estandarizada de datos en la interfaz (4) lógica mencionada, caracterizado porque la primera aplicación (3) mencionada envía una unidad estandarizada de datos (20) usada incorrectamente a la segunda aplicación mencionada (5) y porque la segunda aplicación mencionada (5) reconoce que la unidad de datos (20) mencionada ha sido usada incorrectamente y, por consiguiente, pone a disposición el componente mencionado.
Description
Procedimiento, tarjeta chip y aparato para una
interfaz lógica entre dos aplicaciones.
La presente invención se refiere a un
procedimiento, con el que una primera aplicación puede acceder a
través de una interfaz lógica a componentes de una segunda
aplicación, incluso si no está prevista una unidad de datos para el
acceso a estos componentes en el protocolo de comunicaciones entre
las dos aplicaciones.
Distintas aplicaciones, en particular las
aplicaciones de programas, pueden comunicarse entre sí a través de
interfaces lógicas que se designan como API (Interfaz de protocolo
de aplicación). Si la primera aplicación quiere acceder a un
componente de la segunda aplicación para hacer ejecutar con ello,
por ejemplo, una función x = F (P1, P2), envía un comando a través
de esta interfaz API. La segunda aplicación, que recibe el comando,
puede decodificarla y realizar la función F correspondiente. Por
ejemplo, la segunda aplicación puede transferir una respuesta a la
primera aplicación a través de la interfaz API.
Los comandos y respuestas de este tipo se
codifican normalmente como unidades estructuradas de datos que se
denominan APDU (Unidad de datos de protocolo de aplicación). Una
APDU se compone normalmente de una parte introductoria
("encabezamiento") y una parte de contenido ("cuerpo"), en
el que la parte introductoria indica la instrucción guía y los
parámetros de instrucción y la parte de contenido (no siempre
presente) contiene datos. Este protocolo está descrito en la norma
ISO ISO/IEC 7816, parte 4, entre otras. Otros comandos están
especificados en los documentos específicos del sistema (por
ejemplo, GSM 11.11, GSM 11.14).
Este mecanismo se usa, entre otros aspectos, para
poder acceder a componentes que se ponen a disposición por las
aplicaciones en las tarjetas de chip. De esta manera, una
aplicación, por ejemplo, en un teléfono móvil, por ejemplo una
aplicación de navegador puede acceder a componentes, por ejemplo, a
funciones de seguridad F, que se ponen a disposición por una tarjeta
de chip en un teléfono móvil. El mismo mecanismo se usa, sin
embargo, también para la comunicación entre otras aplicaciones en
otros dispositivos.
La definición de la interfaz API y la
estandarización de la APDU que se entienden por tarjetas de chip
tienen lugar la mayoría de las veces en gremios de estandarización
o se propone por empresas individuales. Por razones de
compatibilidad entre aplicaciones de distintos proveedores, entre
otros entre tarjetas de chip y teléfonos móviles de diferentes
fabricantes, la estandarización a nivel internacional de la
interfaz API es un objetivo que vale la pena.
La estandarización de los comandos APDU es, sin
embargo, un proceso que a menudo transcurre más despacio que el
desarrollo técnico de las aplicaciones. Por esta razón, las
tarjetas de chip convencionales, en particular, no pueden cumplir
todos los deseos de los usuarios y en particular no todos los deseos
de los proveedores del servicio o de los explotadores de una red de
telecomunicaciones. Las funcionalidades de una tarjeta de chip que
se pueden realizar ya técnicamente y a veces incluso están puestas
en práctica en la tarjeta, pueden ofrecerse, la mayoría de las
veces, sólo tras la siguiente estandarización de la especificación
APDU.
Por tanto, el objetivo de la presente invención
es ofrecer un procedimiento con el que una primera aplicación pueda
acceder a componentes, por ejemplo, a funciones de programas, de
una segunda aplicación, incluso cuando no está prevista una APDU en
la interfaz API.
Otro objetivo es ofrecer una tarjeta de chip que
pueda poner a disposición componentes nuevos, sin que tengan que
estandarizarse para ello nuevos comandos APDU.
Según la presente invención se alcanzan estos
objetivos en particular mediante las características de las
reivindicaciones independientes.
Otras formas ventajosas de realización se
desprenden además de las reivindicaciones subordinadas y de la
descripción.
En particular, se alcanzan estos objetivos
gracias a que una primera aplicación envía una unidad de datos
estandarizada usada defectuosamente a una segunda aplicación y a
que la mencionada segunda aplicación reconoce que la unidad de
datos mencionada ha sido usada defectuosamente y, por consiguiente,
pone a disposición los componentes mencionados.
Las unidades estandarizadas de datos, por
ejemplo, APDU, se usan, por ejemplo, defectuosamente, al ser
provistas de parámetros especiales, por ejemplo, de parámetros
imposibles o muy improbables en la parte introductoria. Los APDU
usados defectuosamente pueden, sin embargo, ser identificados
también mediante un cambio de la parte del contenido.
A continuación se describen en detalle a partir
de las figuras adjuntas los ejemplos preferidos de realización de
la invención:
Figura 1: vista esquemática de un sistema con
una tarjeta de chip convencional.
Figura 2: vista esquemática de un comando APDU
según la invención.
Figura 3: vista esquemática de un sistema con
una primera variante de una tarjeta de chip según la invención.
Figura 4: vista esquemática de un sistema con
una segunda variante de una tarjeta de chip según la invención.
Figura 5: vista esquemática de un sistema con
una tercera variante de una tarjeta de chip según la invención.
Figura 6: vista esquemática de un sistema con
una cuarta variante de una tarjeta de chip según la invención.
Aunque la siguiente descripción sólo explica el
caso especial de una interfaz API entre una primera aplicación en
un teléfono móvil y una segunda aplicación en una tarjeta de chip,
el personal técnico entenderá que la presente invención también se
puede usar para otras interfaces API entre todas las aplicaciones
posibles.
La siguiente descripción se refiere en particular
al caso especial de una tarjeta de chip que se emplea como módulo
de identificación en un teléfono móvil celular digital, por ejemplo
una tarjeta SIM (Módulo de identificación de usuario) o una tarjeta
WIM (Módulo de identificación de protocolo de aplicación
inalámbrico), que por ejemplo, puede emplearse en un teléfono móvil
GSM (Sistema global para telecomunicación móvil), WAP (Protocolo de
aplicación inalámbrico) o UMTS. El personal técnico entenderá, sin
embargo, que la presente invención también puede emplearse con
otros tipos de tarjetas de chip, por ejemplo, con tarjetas JAVA
(marca de SUN Microsystems) o tarjetas
OpenCard.
OpenCard.
La figura 1 muestra de manera esquemática un
ejemplo de un sistema convencional con una interfaz API 2,4. El
sistema comprende un aparato final 3 (Equipo móvil ME) y una
tarjeta convencional SIM y/o WIM 5. Una aplicación 1, por ejemplo
un navegador o un programa de aplicación, por ejemplo, un programa
de un proveedor del servicio, se ejecuta en el aparato móvil 3 a
través de medios de procesamiento de datos no representados. La
aplicación 1 comunica con el aparato móvil 3 a través de una
interfaz API 2 (Interfaz de protocolo de aplicación) que no se
detalla
aquí.
aquí.
El aparato móvil 3 comunica con la tarjeta SIM 5
a través de otra interfaz API 4. El aparato móvil 3 asume
normalmente el papel de maestro de la comunicación a través de esta
interfaz, mientras que la tarjeta SIM 5 responde como esclavo. Se
conoce, sin embargo, también variantes de protocolo (por ejemplo
según la herramienta SIM, por ejemplo, GSM 11.14), en las que la
tarjeta SIM asume al menos temporalmente el papel de maestro.
Un paso en el protocolo API se compone del envío
de un comando a la tarjeta de chip 5, de la ejecución del comando
mediante la tarjeta y dado el caso del envío de una respuesta al
aparato móvil 3, que se transmite a la aplicación 1. A través de la
interfaz 4 se intercambian, por ello, bien comandos o respuestas.
Los parámetros pueden estar contenidos tanto en los comandos y/o en
las respuestas.
Estas preguntas y comandos se codifican con
unidades estandarizadas de datos de protocolo (APDU: Unidad de
datos de protocolo de aplicación). Algunas APDU estandarizados para
tarjetas de chip ISO están descritas en la norma ISO/IEC
7816-4:1995(E). Las APDU adicionales se han
definido para tarjetas SIM y para tarjetas WIM para ampliar la
funcionalidad de la interfaz API 4.
La figura 2 muestra la estructura típica de una
unidad de datos (APDU) 20. La unidad de datos comprende una parte
introductoria (encabezamiento) 200 con cuatro bytes y una parte
opcional de contenido (cuerpo) 201 con una longitud variable.
La parte introductoria contiene un primer byte
(CLA) que se usa para, entre otros, indicar qué versión API sigue a
la unidad de datos. Un segundo byte (INS) indica la instrucción que
tiene que ser ejecutada por la tarjeta de chip 5 o que acaba de ser
ejecutada. Dependiendo de las instrucciones se pueden indicar aún
dos parámetros P1 y P2. Si una instrucción no exige ningún parámetro
P1 y/o P2, tiene que ponerse a cero el parámetro.
La parte de contenido opcional 201 contiene datos
y al menos un byte que indica la longitud de estos datos y/o la
longitud máxima de la respuesta esperada.
La tarjeta de chip 5 convencional comprende, en
general, una ROM 50, una EEPROM 51 y una RAM 52, así como medios de
procesamiento de datos no representados. La ROM asciende hoy día
típicamente a 64 Kbytes y contiene normalmente el sistema operativo,
una máquina virtual de Java (JVM, marca de SUN Microsystems) y
distintos componentes F1, F2,..., por ejemplo, javabeans, applets o
programas que pueden realizar diferentes funciones F. En una EEPROM
51 se depositan componentes, por ejemplo, componentes que se han
telecargado como applet después de personalizar la tarjeta, así
como datos personales del usuario, por ejemplo una guía telefónica,
un certificado electrónico, informaciones relevantes para el
perfil, etc. La EEPROM puede comprender, por ejemplo, 16 ó 32
kilobytes. En la RAM 52 se depositan datos temporales, por ejemplo,
variables temporales. Además se pueden memorizar en la EEPROM
aplicaciones y applets.
Una máquina automática de unidad de datos 500, a
menudo llamada programa de procesamiento APDU, recibe la APDU del
aparato móvil 3 que han sido recibidos a través de la interfaz API
4 y analiza la parte introductoria 200, en particular los bytes CLA
e INS, para transmitir el comando al componente afectado F1, F2,
etc. que puede ejecutar el comando. El programa de procesamiento
APDU 500 puede entonces recibir la repuesta de estos componentes y
enviar esta respuesta a través de la interfaz API 4 al aparato móvil
3.
El programa de procesamiento APDU 500 se pone en
práctica normalmente en la parte ROM 50. Un problema con esta
configuración es que el aparato móvil 3 y la aplicación 1 no pueden
acceder a nuevos componentes G1, G2, G3, en la tarjeta, por ejemplo
en la ROM, en la EEPROM o en la RAM, siempre que no se estandarice
una APDU 20 para el acceso a estos componentes. Incluso si se define
un APDU de este tipo y se estandariza tarjetas de chip 5 ya
distribuidas no pueden poner a disposición los componentes nuevos
G1, G2, G3 presentes en la tarjeta, si disponen previamente de un
programa de procesamiento APDU 500 convencional que este APDU
definido más tarde no puede reconocer. Por estos motivos, las
nuevas funcionalidades que serían posibles gracias al desarrollo
constante y rápido de las tarjetas de chip, sólo pueden extenderse
lentamente.
La figura 3 muestra un ejemplo de una primera
variante de una tarjeta de chip 5, por ejemplo una tarjeta SIM o
WIM que puede solucionar estos problemas. En todas las figuras se
usan características iguales o comparables con los mismos números
de referencia y no se describen más, siempre que no sea esto
necesario.
En esta variante se programa la aplicación 1 de
tal manera que traspasa la APDU usada incorrectamente al aparato
móvil 3 para acceder a componentes G1, G2, G3 en la tarjeta 5 para
los que no se ha estandarizado una APDU. Esta APDU usada
incorrectamente es recibida por el aparato móvil 3 y transmitido a
través de la interfaz 4 a la tarjeta 5.
El programa de procesamiento APDU 501 se ha
modificado en la tarjeta para que pueda reconocer estas APDU
especiales, usadas incorrectamente y las traspase
correspondientemente a los nuevos componentes G1, G2, G3, ...
La aplicación 1 puede usar incorrectamente las
APDU de diferentes maneras, para que el programa de procesamiento
APDU 501 modificado las pueda reconocer.
Teóricamente sería posible manipular los bytes
CLA y/o INS de la parte introductoria 200 para que no correspondan a
una versión API o a una instrucción estandarizada de este API. Esta
variante, sin embargo, no se prefiere, debido al riesgo de
conflicto con una variante del protocolo de API.
En una variante preferida de la invención se usan
en lugar de ello APDU estandarizadas para funciones existentes x = F
(P1, p2), es decir, bytes CLA e INS existentes, y provistos de
parámetros P1, P2 no coherentes o no tolerados. Por ejemplo, se
puede usar incorrectamente un APDU al indicarse parámetros cuando
no se requieren. Los APDU pueden también usarse incorrectamente al
indicarse valores de parámetro para P1 y/o P2 que bien son
imposibles, no esperados o muy improbables. Esta variante tiene la
ventaja de que la longitud del APDU no se cambia y el uso
incorrecto se puede detectar fácilmente, ya que sólo se tienen que
decodificar uno o dos bytes.
En caso de que los componentes nuevos solicitados
G1, G2, o G3 en la tarjeta de chip requieran parámetros se pueden
empaquetar estos parámetros en P1 y/o P2. Un programa de conversión
en la aplicación 1 hace las adaptaciones necesarias de formato de
parámetros, por ejemplo, si el componente nuevo G1, G2, G3, ...
requiere datos binarios y la APDU usada incorrectamente acepta sólo
el código ASCII.
En otra variante de la invención no se cambia en
absoluto la parte introductoria 200 y no puede así diferenciarse de
la parte introductoria de una APDU normal. En lugar de esto, se
usan parámetros especiales en la parte de contenido 201. La parte
de contenido de una APDU usada incorrectamente puede contener datos
bien imposibles, totalmente inesperados y muy improbables para la
instrucción indicada en la parte introductoria. En una variante la
longitud de datos indicada no corresponde a la longitud de datos
transmitida. En otra variante se contienen datos en la parte de
contenido 201 para una instrucción que no requiera datos.
Estas distintas variantes pueden también
combinarse al usarse incorrectamente, por ejemplo, la parte
introductoria y el contenido. Otras posibilidades de usar
incorrectamente una APDU existente se pueden realizar en el marco
de esta invención por el personal técnico.
El programa de procesamiento APDU 501 modificado
comprueba si la APDU 20 recibida ha sido usada incorrectamente de
una de estas maneras y transmite esta APDU, si se determina un uso
incorrecto de ese tipo, a los componentes nuevos G1, G2, G3, ... Si
se han codificado parámetros para los nuevos componentes G1, G2,
G3, ... en parámetros de la APDU usada incorrectamente, un programa
se ocupa de la decodificación. Si no se determina un uso incorrecto
se descarga la APDU a un componente convencional F1, F2, etc.
Los componentes nuevos G1, G2, G3, ... pueden
estar contenidos en la ROM 50 o en la EEPROM 51. Se pueden además
poner temporalmente a disposición componentes depositados en la RAM
52. Si la tarjeta de chip 5 al menos temporalmente puede jugar el
papel de maestro de la interfaz 4, puede con este mecanismo además
acceder a componentes, por ejemplo applets que se ponen a
disposición por parte del aparato móvil 3. Es incluso posible que el
programa de procesamiento APDU 501 acceda a componentes que se
encuentran en un dispositivo externo, que por ejemplo están unidos
con el aparato móvil 3 a través de una interfaz sin contacto, por
ejemplo, una interfaz de infrarrojos, RFID o de bluetooth.
Esta variante representada con la figura 3 hace
posible a la aplicación 1 y al aparato móvil 3 acceder a
componentes G1, G2, G3 de la tarjeta de chip 5, sin que para ello
se tenga que estandarizar una nueva APDU en la interfaz API 4.
Ciertamente tiene esta variante la desventaja de que la APDU usada
incorrectamente y los componentes solicitados correspondientemente
se tienen que definir en la parte ROM 50 ya antes de la fabricación
del programa de procesamiento APDU 501. Después de la distribución
de tarjetas se pueden hacer como máximo cambios en los componentes
G3 contenidos en la EEPROM 51, en la RAM 52 o en el aparato móvil 3
y solicitados por esta APDU usada incorrectamente.
La figura 4 muestra otra variante de la
invención, en la que el programa de procesamiento APDU 500 no
necesita adaptación en comparación con la figura 1. Como en una
tarjeta de chip 5 convencional, según la figura 1 transmite aquél la
APDU recibida a los componentes, pudiendo estar contenidos estos
componentes en la ROM 50 o también en la EEPROM 51.
En esos componentes F1', F2', etc. se comprueba
si las unidades de datos recibidos por el programa de procesamiento
APDU 500 han sido usadas incorrectamente de la manera indicada
anteriormente (prueba de uso incorrecto m). Si no es este el caso
se descarga la APDU a un componente convencional. Si se ha
determinado un uso incorrecto se transmite entre tanto la unidad de
datos a un componente nuevo G1, G2, G3, ... Se entenderá que el
componente normal F1, F2, etc. que se solicita por una APDU no
usada incorrectamente, así como el componente nuevo G1, G2, etc.,
que sólo se usa cuando se da un uso incorrecto de la APDU, se
pueden encontrar en otras zonas de memoria 50, 51, 52, 3. De esta
manera se puede, por ejemplo, redefinir un componente F3' que se
encuentra en la EEPROM 51 para que si recibe una APDU usada
incorrectamente acceda a un componente en la ROM 50.
La figura 5 muestra una variante de la invención
en la que un módulo 510 comprueba, en cuanto a posibles usos
incorrectos, todas las APDU 20 recibidas a través de la interfaz
API 4. En caso de que no se detecte un uso incorrecto se transmite
la APDU a un programa de procesamiento APDU convencional 500 que
descarga este APDU a un componente convencional F1, F2, F3, etc. Si,
por el contrario, el módulo 510 determina una APDU usada
incorrectamente, se transmite la APDU usada incorrectamente a un
nuevo programa de procesamiento APDU modificado 511 que solicita el
componente G1, G2, G3, ... previsto para esta APDU usada
incorrectamente.
El nuevo programa de procesamiento APDU 511 se
encuentra preferentemente en la EEPROM 51. De esta manera puede
también cambiarse después de la fabricación de la ROM 50 para, por
ejemplo, garantizar el acceso a componentes nuevos G1, G2, G3
puestos en práctica entre tanto. Preferentemente se encuentra
también el módulo de prueba 510 en la EEPROM, para que se puedan
descubrir nuevos tipos de usos incorrectos de la APDU después de la
fabricación de la ROM, por ejemplo, primero en la personalización o
incluso después de la distribución de las tarjetas de chip. El
módulo de prueba 510 podría encontrarse también, sin embargo, en la
ROM 50 o incluso en la RAM
52.
52.
La figura 6 muestra otra variante de la tarjeta
de chip según la invención, en la que el programa normal de
procesamiento APDU que normalmente se encuentra en la ROM 50 se
sustituye por un programa modificado de procesamiento APDU 512 en
la EEPROM. Además puede descubrir el programa de procesamiento APDU
512 posibles usos incorrectos de la APDU y en este caso solicitar
otro componente G1, G2, G3, ... Esta variante permite una gran
flexibilidad, ya que se pueden poner en práctica en cada momento en
la tarjeta 5 los componentes nuevos G1, G2, G3 y los nuevos tipos
de usos incorrectos.
En una variante no representada se puede
encontrar el programa modificado de procesamiento APDU también en
la RAM 52, para que se pueda cambiar sencillamente mediante el
sistema operativo de la tarjeta de chip o mediante la aplicación
1.
Describiremos ahora en detalle un ejemplo de la
solicitud de un componente mediante un uso incorrecto de la
APDU.
Un programa de aplicación 1, por ejemplo, un
navegador en un teléfono móvil 3 con WAP quiere hacer encriptar un
archivo T con una clave P por una tarjeta WIM 5. La aplicación 1
quiere hacer ejecutar la función de encriptación R = V (T, P) por
el aparato móvil 2 y espera del aparato móvil 5 que responda con el
archivo R encriptado por la tarjeta WIM 5.
El fabricante de tarjetas WIM ha puesto en
práctica en la tarjeta 5 los componentes necesarios, entre otros la
clave P y un componente de encriptación G1, G2, G3 (por ejemplo, un
applet java en la EEPROM 51). No se ha definido, sin embargo, un
APDU a través del API 4, que garantiza un acceso a este componente
presente de encriptación, de manera que el aparato móvil 3 no puede
hacer ejecutar esta función de encriptación.
Para, a pesar de esto, acceder a este componente,
la aplicación 1 puede requerir la ejecución de otra función, para
la que una APDU 20 haya sido estandarizada para la interfaz 4. Por
ejemplo, la aplicación 1 puede hacer ejecutar la función de firma R
= S (T, P) en la que T corresponde al archivo que se ha de firmar,
P a los parámetros de firma (por ejemplo, a la clave que se ha de
usar) y R al archivo firmado.
Para que la tarjeta de chip 5 pueda reconocer que
tiene que encriptar y no firmar el archivo T, la aplicación 1 tiene
que usar parámetros especiales P para la función S, por ejemplo,
parámetros P imposibles, inesperados, y/o muy improbables. Se
pueden indicar también parámetros, cuando no se requiere ningún
parámetro para una determinada función, o se usan parámetros de un
tipo incorrecto.
La aplicación 1 tiene además que convertir el
parámetro T para la nueva función de encriptación y, por ejemplo,
empaquetarlo en un parámetro T, P de uso incorrecto de la función
de firma.
El aparato móvil 3 que recibe la APDU recibida
por la aplicación 1 con un comando de firma, descarga ésta a la
tarjeta 5. La tarjeta de chip 5 recibe entonces esta APSU a través
de la interfaz API 4 y puede reconocer con el mecanismo descrito
anteriormente que la APDU ha sido usada incorrectamente y que los
parámetros indicados P1, P2 y/o la parte de contenido 201 se
refieren a criterios especiales a los que nunca (o de forma
extremadamente rara) se refieren con un uso normal de esta APDU.
Como se ha descrito anteriormente en este caso la tarjeta de chip
hace ejecutar otra función G1, G2, G3 (aquí una función de
encriptación) como si estos criterios no se hubieran cumplido.
Los componentes solicitados G1, G2 o G3 pueden
convertir el parámetro T y encriptar este archivo. El archivo
encriptado se descarga con otra APDU a través de la interfaz 4 y a
través del aparato móvil 3 a la aplicación 1.
De esta manera la aplicación 1 puede acceder a
componentes de una tarjeta de chip 5 que en la fabricación de la
tarjeta no estaban aún previstos y para los que no se ha
estandarizado ninguna APDU, por ejemplo, a componentes G1, G2 G3,
etc., que sólo tras la personalización o incluso después de la
distribución de la tarjeta se han telecargado como applet a través
de una interfaz aérea.
En una variante de la invención cada APDU puede
activar la realización de varias funciones diferentes en la tarjeta
de chip 5. Un APDU especial usado incorrectamente define en qué
estado se encuentra la tarjeta y qué conjunto de funciones se
tiene que usar en el futuro. Esta variante permite, gracias al
envío de una única APDU usada incorrectamente, sustituir varios o
todos los componentes de la tarjeta de chip. Por ejemplo, se pueden
sustituir temporalmente de esta manera todos los parámetros y
componentes que están depositados en la ROM 50. Otra APDU usada
incorrectamente puede entonces devolver la tarjeta de chip a su
estado normal.
El personal técnico entenderá además que no sólo
las aplicaciones 1 realizadas en el aparato móvil 3 con el
procedimiento según la invención pueden acceder a componentes
adicionales G1, G2, G3, ... de la tarjeta de chip 5, sino que
también otros dispositivos que, por ejemplo, pueden usar
incorrectamente APDU estandarizadas a través de una red de
telefonía móvil, de WAP, y/o de una interfaz sin contacto en la
zona próxima, por ejemplo de una interfaz de infrarrojos, RFID y/o
de bluetooth, para acceder a este nuevo componente.
Además la invención se refiere también a
aplicaciones 1 que usan incorrectamente funciones para poder
acceder a cualquier componente inaccesible de una tarjeta de chip,
así como a un dispositivo 3 con las siguientes características:
- -
- una zona de memoria no representada,
- -
- medios de procesamiento de datos no representados, que pueden acceder a las zonas de memoria mencionadas,
- -
- en el que un programa está contenido en la zona mencionada de memoria, que puede ser ejecutado por los medios mencionados de procesamiento de datos,
- -
- un lector de tarjetas de chip no representado, con el que se pueden enviar comandos a través de una interfaz estandarizada API a una tarjeta de chip 5,
- -
- en el que el programa mencionado contiene instrucciones para activar el envío al menos de una unidad de datos usada incorrectamente, para acceder a componentes en la tarjeta de chip para los que no está previsto ningún comando estandarizado en la interfaz API entre la tarjeta de chip y el dispositivo externo.
Claims (36)
1. Procedimiento, con el que una primera
aplicación (3) puede acceder a través de una interfaz lógica (4) a
componentes (G1, G2, G3, ...) de una segunda aplicación (5), si no
está definida una unidad estandarizada de datos en la interfaz (4)
lógica mencionada,
caracterizado porque la primera aplicación
(3) mencionada envía una unidad estandarizada de datos (20) usada
incorrectamente a la segunda aplicación mencionada (5)
y porque la segunda aplicación mencionada (5)
reconoce que la unidad de datos (20) mencionada ha sido usada
incorrectamente y, por consiguiente, pone a disposición el
componente mencionado.
2. Procedimiento según la reivindicación
precedente, en el que la segunda aplicación mencionada reconoce a
partir de la parte introductoria (200) de la unidad de datos (20)
que la unidad de datos ha sido usada incorrectamente.
3. Procedimiento según la reivindicación
precedente, en el que la parte introductoria mencionada comprende
al menos los siguientes bytes:
- -
- al menos un byte (CLA), que indica la clase de la unidad de datos,
- -
- al menos un byte, que indica la instrucción que se ha de ejecutar,
- -
- al menos dos bytes que corresponden al menos a dos parámetros para la instrucción mencionada que se ha de ejecutar,
en el que la segunda aplicación
mencionada reconoce a partir del mencionado parámetro de la parte
introductoria (200) de la unidad de datos (20), que la unidad de
datos ha sido usada
incorrectamente.
4. Procedimiento según una de las
reivindicaciones precedentes, en el que la segunda aplicación
mencionada reconoce a partir de la parte de contenido (201) de la
unidad de datos (20), que la unidad de datos ha sido usada
incorrectamente.
5. Procedimiento según una de las
reivindicaciones precedentes, en el que la mencionada primera
aplicación (3), a través de una interfaz API (4), a través de la
que se descargan comandos APDU, puede acceder a componentes (G1,
G2, G3, ...) de la segunda aplicación mencionada (5), si no está
definida una unidad estandarizada de datos en la interfaz API (4)
mencionada.
6. Procedimiento según una de las
reivindicaciones precedentes, en el que la mencionada segunda
aplicación es puesta a disposición por una tarjeta de chip (5).
7. Procedimiento según la reivindicación
precedente, en el que la mencionada segunda aplicación es puesta a
disposición por una tarjeta SIM (5).
8. Procedimiento según una de las
reivindicaciones 6 ó 7, en el que la mencionada segunda aplicación
es puesta a disposición por una tarjeta WIM (5).
9. Procedimiento según una de las
reivindicaciones 6 a 8, en el que la mencionada tarjeta de chip
comprende un programa modificado de procesamiento de la APDU (501;
511; 512), que reconoce unidades de datos (20) recibidas usadas
incorrectamente, y las transmite al componente responsable (G1, G2,
G3, ...) en la mencionada tarjeta de chip (5).
10. Procedimiento según la reivindicación
precedente, en el que el mencionado programa modificado de
procesamiento de la APDU (501) está depositado en la ROM (50).
11. Procedimiento según la reivindicación 9, en
el que el mencionado programa modificado de procesamiento de la
APDU (511; 512) está depositado en la EEPROM (51).
12. Procedimiento según una de las
reivindicaciones 1 a 8, en el que el uso incorrecto de unidades de
datos (20) se reconoce mediante componentes correspondientes (F1',
F2', F3', etc.).
13. Procedimiento según una de las
reivindicaciones 1 a 8, en el que el uso incorrecto de unidades de
datos (20) se reconoce mediante un módulo de prueba (510) que
traspasa la unidad de datos mencionada a un programa de
procesamiento de la APDU (500) si no se determina ningún uso
incorrecto y a un segundo programa de procesamiento de la APDU
(511) si se determina un uso incorrecto.
14. Procedimiento según la reivindicación
precedente, en el que el módulo de prueba (510) mencionado está
depositado en la ROM (50).
15. Procedimiento según la reivindicación 13, en
el que el módulo de prueba (510) mencionado está depositado en la
EEPROM (51).
16. Procedimiento según una de las
reivindicaciones precedentes, en el que los nuevos componentes (G1,
G2,
G3, ...) mencionados se componen de un programa en la EEPROM (51).
G3, ...) mencionados se componen de un programa en la EEPROM (51).
17. Procedimiento según una de las
reivindicaciones precedentes, en el que los mencionados nuevos
componentes (G1, G2, G3, ...) en la RAM (52) se componen de un
programa en la RAM.
18. Procedimiento según una de las
reivindicaciones precedentes, en el que los nuevos componentes (G1,
G2,
G3, ...) mencionados se componen de un programa en el dispositivo externo (3).
G3, ...) mencionados se componen de un programa en el dispositivo externo (3).
19. Procedimiento según una de las
reivindicaciones precedentes, en el que los componentes (G1, G2,
G3, ...) mencionados se componen de un programa en un segundo
dispositivo externo que se comunica a través de una interfaz sin
contacto.
20. Tarjeta de chip (5) que puede comunicarse a
través de una interfaz lógica (4) con un dispositivo externo (3),
estando definidas unidades de datos estandarizadas (20) para esta
comunicación,
caracterizada porque la
tarjeta de chip mencionada puede reconocer unidades estandarizadas
de datos (20) usadas incorrectamente y porque está configurada de
tal manera que pone a disposición otros componentes (G1, G2, G3,
...), cuando se han reconocido unidades de datos de este tipo usadas
incorrectamente, como el componente que pone a disposición cuando no
se han reconocido unidades de datos usadas
incorrectamente.
21. Tarjeta de chip según la reivindicación
precedente, que puede reconocer a partir de la parte introductoria
(200) de la unidad de datos (20) que la unidad de datos ha sido
usada incorrectamente.
22. Tarjeta de chip según la reivindicación
precedente, en la que la parte introductoria mencionada comprende
al menos los siguientes bytes:
- -
- al menos un byte (CLA), que indica la clase de la unidad de datos,
- -
- al menos un byte, que indica la instrucción que se ha de ejecutar,
- -
- al menos dos bytes que corresponden por lo menos a dos parámetros para la instrucción mencionada que se ha de ejecutar,
en la que la tarjeta de chip
mencionada está configurada de tal manera que reconoce a partir del
mencionado parámetro de la parte introductoria (200) de la unidad de
datos (20), que la unidad de datos ha sido usada
incorrectamente.
23. Tarjeta de chip según la reivindicación
precedente, que está configurada de tal manera que reconoce a
partir de la parte de contenido (200) de la unidad de datos (20)
que la unidad de datos ha sido usada incorrectamente.
24. Tarjeta de chip según una de las
reivindicaciones 20 a 23, en la que la interfaz lógica (4)
mencionada es una interfaz API.
25. Tarjeta de chip según la reivindicación
precedente que es una tarjeta SIM.
26. Tarjeta de chip según una de las
reivindicaciones 24 ó 25, que es una tarjeta WIM.
27. Tarjeta de chip según una de las
reivindicaciones 20 a 26, que comprende un programa modificado de
procesamiento de la APDU (501; 511; 512), para reconocer unidades
de datos (20) recibidas usadas incorrectamente y está configurada de
tal manera que transmite las unidades de datos (20) mencionadas
usadas incorrectamente al componente apropiado (G1, G2, G3, ...) en
la tarjeta de chip mencionada (5).
28. Tarjeta de chip según la reivindicación
precedente, en la que el programa modificado de procesamiento de la
APDU (510) está depositado en la ROM (50).
29. Tarjeta de chip según la reivindicación 27,
en la que el programa modificado de procesamiento de la APDU (511;
512) está depositado en la EEPROM (51).
30. Tarjeta de chip según una de las
reivindicaciones 20 a 26 configurada de tal manera, que el uso
incorrecto de unidades de datos (20) se reconoce mediante el
componente correspondiente (F1', F2', F3', etc.).
31. Tarjeta de chip según una de las
reivindicaciones 20 a 26, con un módulo de prueba (510) para
reconocer el uso incorrecto de unidades de datos (20) que está
configurado de tal manera que traspasa la unidad de datos
mencionada a un primer programa de procesamiento de la APDU (500),
si no se determina ningún uso incorrecto, y a un segundo programa
de procesamiento de la APDU (511), si se determina un uso
incorrecto.
32. Tarjeta de chip según la reivindicación
precedente, en la que el mencionado módulo de prueba (510) está
depositado en la ROM (50).
33. Tarjeta de chip según la reivindicación 31,
en la que el mencionado módulo de prueba (510) está depositado en
la EEPROM (51).
34. Tarjeta de chip según una de las
reivindicaciones 20 a 33, en la que el mencionado componente (G1,
G2,
G3, ...) está memorizado en la EEPROM (51).
G3, ...) está memorizado en la EEPROM (51).
35. Tarjeta de chip según una de las
reivindicaciones 20 a 34, en la que el mencionado componente (G1,
G2,
G3, ...) está memorizado en la RAM (52).
G3, ...) está memorizado en la RAM (52).
36. Dispositivo (3), que comprende las siguientes
características:
- -
- una zona de memoria
- -
- medios de procesamiento de datos, que pueden acceder a la zona de memoria mencionada,
- -
- estando contenido en la zona mencionada de memoria un programa (1), que puede ser ejecutado por los medios mencionados de procesamiento de datos,
- -
- un lector de tarjetas de chip, con el que se pueden enviar comandos a través de una interfaz API (4) estandarizada a una tarjeta de chip (5),
caracterizado porque el
programa mencionado contiene instrucciones para provocar el envío
de por lo menos una unidad de datos (20) usada incorrectamente, para
acceder a componentes (G1, G2, G3) en la tarjeta de chip (5), para
los que no está previsto ningún comando estandarizado en la interfaz
API entre la tarjeta de chip y el dispositivo
externo.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CH1999/000552 WO2001039463A1 (de) | 1999-11-19 | 1999-11-19 | Logische schnittstelle zwischen zwei anwendungen |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2243096T3 true ES2243096T3 (es) | 2005-11-16 |
Family
ID=4551738
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES99974202T Expired - Lifetime ES2243096T3 (es) | 1999-11-19 | 1999-11-19 | Procedimiento, tarjeta chip y aparato para una interfaz logica entre dos aplicaciones. |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US7606931B2 (es) |
| EP (1) | EP1230779B1 (es) |
| AT (1) | ATE296014T1 (es) |
| AU (1) | AU1145700A (es) |
| DE (1) | DE59912079D1 (es) |
| ES (1) | ES2243096T3 (es) |
| WO (1) | WO2001039463A1 (es) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2001061620A1 (en) * | 2000-02-18 | 2001-08-23 | Vasco Data Security, Inc. | Field programmable smart card terminal and token device |
| FR2857193A1 (fr) * | 2003-07-01 | 2005-01-07 | France Telecom | Procede permettant a une application embarquee sur un terminal de communiquer avec une application residente en carte sim |
| EP1566941A1 (en) * | 2004-02-19 | 2005-08-24 | Axalto S.A. | Method and device for enabling mono- and bi-directional communication between mobile equipment and smartcard applications |
| US7768948B2 (en) * | 2004-11-19 | 2010-08-03 | Atmel Automotive Gmbh | Method and device for data transmission |
| FR2892261A1 (fr) * | 2005-10-17 | 2007-04-20 | France Telecom | Procede et systeme de gestion des applications d'un terminal mobile |
| US8327191B2 (en) * | 2007-10-19 | 2012-12-04 | International Business Machines Corporation | Automatically populating symptom databases for software applications |
| FR2927454B1 (fr) * | 2008-02-12 | 2010-05-14 | Ingenico Sa | Procede de detection de cartes a microprocesseur non authentiques, carte a microprocesseur, terminal lecteur de carte et programmes correspondants |
| US9172539B2 (en) * | 2011-09-14 | 2015-10-27 | Mastercard International Incorporated | In-market personalization of payment devices |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2274230B (en) * | 1993-01-07 | 1996-05-15 | Digital Equipment Int | Communication systems |
| DE69330675T2 (de) * | 1993-06-03 | 2002-06-13 | Ibm | Verbesserte Paketstruktur für Netzschicht |
| US5473691A (en) * | 1993-11-05 | 1995-12-05 | Microsoft Corporation | System and method for computer data transmission |
| ATE281680T1 (de) * | 1997-03-24 | 2004-11-15 | Visa Int Service Ass | System und verfahren für eine mehrzweckchipkarte die eine nachträgliche speicherung einer anwendung auf dieser karte ermöglicht |
| US6385729B1 (en) * | 1998-05-26 | 2002-05-07 | Sun Microsystems, Inc. | Secure token device access to services provided by an internet service provider (ISP) |
| FI109756B (fi) * | 1998-09-21 | 2002-09-30 | Nokia Corp | Menetelmä tiedonsiirtojärjestelmässä paikallisten resurssien hyödyntämiseksi, tiedonsiirtojärjestelmä ja langaton viestin |
| AU770396B2 (en) * | 1998-10-27 | 2004-02-19 | Visa International Service Association | Delegated management of smart card applications |
| US6195700B1 (en) * | 1998-11-20 | 2001-02-27 | International Business Machines Corporation | Application protocol data unit management facility |
| US6845498B1 (en) * | 1999-05-11 | 2005-01-18 | Microsoft Corporation | Method and apparatus for sharing data files among run time environment applets in an integrated circuit card |
| JP2002123806A (ja) * | 2000-10-17 | 2002-04-26 | Fujitsu Ltd | Ｉｃカード、データ更新制御方法、データ／メッセージ復元制御方法、および制御プログラムを記録した記録媒体 |
| US6807561B2 (en) * | 2000-12-21 | 2004-10-19 | Gemplus | Generic communication filters for distributed applications |
-
1999
- 1999-11-19 AU AU11457/00A patent/AU1145700A/en not_active Abandoned
- 1999-11-19 ES ES99974202T patent/ES2243096T3/es not_active Expired - Lifetime
- 1999-11-19 WO PCT/CH1999/000552 patent/WO2001039463A1/de active IP Right Grant
- 1999-11-19 EP EP99974202A patent/EP1230779B1/de not_active Expired - Lifetime
- 1999-11-19 AT AT99974202T patent/ATE296014T1/de active
- 1999-11-19 DE DE59912079T patent/DE59912079D1/de not_active Expired - Lifetime
-
2002
- 2002-05-16 US US10/150,210 patent/US7606931B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| WO2001039463A1 (de) | 2001-05-31 |
| US20020199027A1 (en) | 2002-12-26 |
| US7606931B2 (en) | 2009-10-20 |
| DE59912079D1 (de) | 2005-06-23 |
| ATE296014T1 (de) | 2005-06-15 |
| EP1230779A1 (de) | 2002-08-14 |
| EP1230779B1 (de) | 2005-05-18 |
| WO2001039463A8 (de) | 2001-06-28 |
| AU1145700A (en) | 2001-06-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2248568T3 (es) | Sistema y metodo para mejorar la seguridad en el reacondicionamiento y reprogramacion de aparatos telefonicos moviles. | |
| EP2255340B1 (en) | Method and devices for installing and retrieving linked mifare applications | |
| US7340276B2 (en) | System for downloading program to general-purpose subscriber identification module | |
| US8768250B2 (en) | Enhanced near field communication terminal, smart card and communication method thereof | |
| CN101326735B (zh) | 用于在单个移动电子设备内仿真多个rfid标签的方法和设备 | |
| US9894060B2 (en) | Machine-to-machine device and smartcard for use in the device | |
| EP2297634A2 (en) | Methods, systems and arrangements for wireless communication with near-field communication terminals | |
| CN101473336A (zh) | 移动终端中动态分配用户芯片卡触点的方法与相应的用户芯片卡和移动终端 | |
| US6851606B2 (en) | Method for presenting proprietary data on a SIM card | |
| KR101347984B1 (ko) | 통신 객체와 프로세싱 유닛 사이의 데이터 교환을 위한 매칭 방법, 시스템 및 디바이스 | |
| ES2526641T3 (es) | Procedimiento de comunicación, dispositivo de comunicación y procesador seguro | |
| ES2243096T3 (es) | Procedimiento, tarjeta chip y aparato para una interfaz logica entre dos aplicaciones. | |
| ES2694953T3 (es) | Procedimiento para personalizar un módulo de seguridad de un dispositivo terminal de telecomunicación | |
| EP4060588A1 (en) | Virtual electronic card management method and system, security chip, terminal, and storage medium | |
| BRPI0722283A2 (pt) | Método, aparelho, sistema, programa de computador, meio fisico e módulo | |
| US6847831B2 (en) | Adaptable chip card | |
| ES2257035T3 (es) | Terminal de telecomunicacion con lector de tarjeta de chip. | |
| EP1418538B1 (en) | Multi-application ic card | |
| US20090302119A1 (en) | Chip Card, and Method for the Software-Based Modification of a Chip Card | |
| EP1675418B1 (en) | Method and apparatus for control of data synchronization between a user equipment and a user authentication card | |
| KR20000029872A (ko) | 전기장치,칩카드프로그래밍프로세스및그장치 | |
| Chirico | Smart card programming | |
| TWI494856B (zh) | Program call method and mobile device | |
| KR100296278B1 (ko) | 스마트카드와그의히스토리컬캐릭터구성방법 | |
| ES2715198T3 (es) | Procedimiento y dispositivos para transmitir un paquete de datos seguro a un dispositivo de comunicación |