ES2176035T5 - Procedimiento y dispositivo de control del ciclo de vida de un objeto portatil, en particular de una tarjeta de chip. - Google Patents

Abstract

Dispositivo de control del ciclo de vida de un objeto electrónico portátil, el ciclo de vida está determinado por una sucesión de transiciones de estados, dichos estados determinan los servicios ofertados por el objeto, dicho objeto comprende una unidad de tratamiento (2), una memoria volátil (3), memorias de programa (4) y memorias de datos (5), cada una de estas memorias (3, 4, S) presenta un contenido definiendo una pluralidad de configuraciones. caracterizado porque posee medios de control de la transición de un primer estado en un segundo estado del objeto electrónico portátil, explotando medios de autorización y/o prohibición de transiciones de estado, de tal modo que solamente se permitan ciertas transiciones entre el conjunto de las transiciones posibles.

Description

Procedimiento y dispositivo de control del ciclo de vida de un objeto portátil, en particular de una tarjeta de chip.

El invento concierne los objetos electrónicos portátiles, tales como las tarjetas de microcircuitos electrónicos, denominadas tarjetas con chip (inteligentes), las cuales están conectadas a dispositivos electrónicos para que estos últimos puedan realizar funciones particulares en el marco de una o varias aplicaciones, y cuyas etapas vitales deben controlarse. En efecto, dichas tarjetas se utilizan generalmente en aplicaciones (banco, comunicación, identidad, salud...) y requieren una gran seguridad contra los usos fraudulentos. Por ejemplo, el documento US 5473690 presenta una tarjeta con chip que comprende varias aplicaciones, cuyo acceso está protegido mediante contraseñas, una contraseña se reserva a un usuario. Si se conoce una contraseña, es posible seleccionar una u otra aplicación. Sin embargo, no se puede desactivar una aplicación o limitar su uso, cualquiera que sea el usuario de la tarjeta en función de las etapas de vida de dicha tarjeta.

El invento se aplica más generalmente a todo sistema embarcado independiente, dotado de una unidad de tratamiento y de memorias de programa y de datos.

En el mundo de la tarjeta con chip ya se sabe que ésta resulta de un ensamblaje de un componente (que incluye por lo general un microprocesador en relación con memorias vía bus de comunicación), de un módulo (realizado con un metal conductor) al que está conectado dicho componente (en el marco de una tarjeta con chip, denominada de contacto) para que dicho componente pueda ser conectado a un dispositivo electrónico de lectura y/o escritura (o acoplador) y un cuerpo de tarjeta o más generalmente un soporte en el que está integrado el conjunto módulo/componente. En el marco de una tarjeta con chip, denominada sin contacto, dicho módulo es reemplazado por una antena, el conjunto formado por el componente y dicha antena está integrado en el seno de dicho soporte.

La vida de una tarjeta con chip se divide generalmente en dos conjuntos de etapas sucediéndose unas de otras, correspondiendo respectivamente a la fabricación y a la explotación de dicha tarjeta. La composición de ambos conjuntos de etapas forma un ciclo de vida de dicha tarjeta. La fabricación de una tarjeta con chip (de contacto o sin contacto) está constituida de varias etapas.

En efecto, en primer lugar es necesario disponer de un componente electrónico que está inicializado, aislado, y seguidamente conectado a un módulo. Dicho componentes y el módulo al que está conectado, son integrados a continuación en o en el seno de un soporte (generalmente un cuerpo de tarjeta de plástico) éste mismo impreso con fines de identificación o de publicidad. Seguidamente la tarjeta con chip que se obtiene es inicializada o programada para satisfacer a las condiciones de utilización en el marco de las aplicaciones.

El segundo conjunto de etapas de vida de una tarjeta con chip corresponde a su explotación. Este mismo conjunto puede dividirse en varias etapas, cada una de ellas corresponde, por ejemplo, a la configuración o supresión de los servicios ofertados por la tarjeta con chip al usuario en función de su perfil por ejemplo.

Además, diferentes actores (fabricante de componente, fabricante de tarjetas con chip, centro de personalización de tarjetas, emisor de tarjetas, o aún portador de tarjetas) intervienen durante las diferentes etapas de la fabricación y explotación de una tarjeta con chip. De este modo, los componentes se facilitan y a veces en parte se inicializan por fabricantes de componentes electrónicos en una fracción de silicio. Esta fase corresponde a la etapa de fabricación del componente. La etapa siguiente corresponde a la fase de encarte realizada por el fabricante de la tarjeta con chip. Esta incluye el aislamiento de un componente de la fracción de silicio, la conexión de dicho componente a un módulo (o antena), la integración del conjunto en su soporte o cuerpo de tarjeta. Seguidamente se lleva a cabo la preparación de la estructura aplicativa presente en la memoria programable eléctricamente del componente. Es la etapa de personalización eléctrica que realiza el fabricante de las tarjetas con chip o un centro de personalización de tarjetas o el mismo emisor que está encargado "in fine" de la distribución de las tarjetas en el mercado. Esta fase de personalización eléctrica puede dividirse por consiguiente en tantas etapas como número de actores o intermediarios existan. Seguidamente, durante la explotación de la tarjeta con chip, ya hemos visto anteriormente que puede resultar interesante distinguir diferentes etapas a merced de la evolución del perfil del usuario de la tarjeta por ejemplo. Así pues, por todos estos motivos, es importante respetar rigurosamente las etapas de vida de una tarjeta para conocer en cualquier momento la etapa en curso de dicha tarjeta en el seno de su ciclo de vida. Además, es indispensable que, por una parte, el acceso en escritura o en lectura de la memoria programable eléctricamente del componente de una tarjeta esté protegido durante el intercambio de dicha tarjeta (o del componente) entre los diferentes actores y, que por otra parte el acceso a dicha memoria esté limitado a medida que se suceden las etapas de vida de la tarjeta mencionadas anteriormente, activando o desactivando algunos servicios por ejemplo. Para terminar, es necesario igualmente a veces validar el contexto aplicativo de la tarjeta con chip antes de que el portador de esta tarjeta la utilice en el mercado. Por ejemplo, un emisor de tarjeta con chip de tipo portamonedas electrónico, debe estar seguro de que la balanza de dicha tarjeta sea nula antes de emitir la tarjeta.

Para intentar responder a estas exigencias, se utilizan diferentes soluciones en el día de hoy. Algunas soluciones son puramente exteriores a la tarjeta con chip (conmutación de protección física de los locales en los que se ha fabricado dicha tarjeta, utilización de medios de transporte, los cuales están protegidos ...). Se utilizan generalmente otras soluciones complementarias a las primeras, pero esta vez internas o implantadas en la tarjeta. De este modo, se emplean secretos que permiten proteger el acceso en lectura/escritura de la memoria del componente e igualmente indicadores lógicos permitiendo seguir de manera irreversible las diferentes etapas de vida de la tarjeta. Para ello, se colocan bits en el seno de una memoria no borrable del componente de la tarjeta con chip en estado activo al final de las diferentes etapas de vida de la tarjeta (fabricación e inicialización del componente por el fabricante de dicho componente, encarte e inicialización de la memoria de la tarjeta por el fabricante de la tarjeta con chip, preparación de la estructura aplicativa de la memoria de la tarjeta con chip por el centro de personalización o el emisor de la tarjeta...). En función de estos indicadores, el programa (o sistema de explotación), ejecutado por el microprocesador del componente de la tarjeta con chip, instalado en el seno de una de las memorias de dicho componente de la tarjeta, adapta su comportamiento a medida que las etapas de vida de dicha tarjeta se suceden.

Cualesquiera que sean las soluciones utilizadas en el día de hoy, éstas se basan todas ellas en el hecho de que los diferentes actores implicados en la fabricación de una tarjeta son terceras personas de confianza. Solamente a las personas, susceptibles de interceptar componentes o tarjetas durante su transferencia entre dos actores diferentes se les considera "defraudadores potenciales" y las soluciones expuestas anteriormente permiten liberarse de ello. La adaptación del sistema de explotación de la tarjeta en función de los indicadores irreversibles aporta un "más" no desdeñable. De este modo, si los fabricantes de componentes o de tarjetas inscriben datos sistemas o secretos, el emisor de la tarjeta no podrá por ejemplo liberarse libremente de dichos secretos o modificar dichos datos del sistema. Sin embargo, esta solución no resuelve el problema de una inicialización fraudulenta de la tarjeta o de un error poco afortunado durante la instalación, efectuada por uno de los actores.

El invento propone solucionar los inconvenientes del estado actual de la técnica. En particular, el invento consiste en dotar al sistema de explotación de una tarjeta con chip, de soportes lógicos informáticos que permitan a dicho sistema de explotación controlar un cambio irreversible de una etapa de vida de dicha tarjeta, en función de un conjunto de verificaciones del contenido de las memorias de esa misma tarjeta con chip. Además, el invento prevé que en el momento de un cambio de etapa de vida, el sistema de explotación de la tarjeta pueda activar automáticamente acciones que permitan adaptar los servicios ofertados por dicho sistema de explotación de dicha tarjeta.

Para este fin, el invento implica un dispositivo de control del ciclo de vida de un objeto electrónico portátil, según la reivindicación 1 y un procedimiento de control según la reivindicación 11. Se definen medios de realización preferidos del invento en las reivindicaciones dependientes.

Por otra parte, el invento concierne un objeto electrónico portátil, pudiendo ser, principalmente, una tarjeta col. chip, poseyendo dicho dispositivo de control del ciclo de vida.

El invento se comprenderá mejor cuando se lea la descripción que sigue y, se examinen las figuras que la acompañan. Estas se dan únicamente a título indicativo y, en modo alguno, limitativo del invento.

Las figuras muestran:

- figura 1: un componente de una tarjeta con chip equipado de un dispositivo de verificación de transición de estado;

- figuras 2a y 2 b: una representación detallada de una tabla de transiciones de estado;

- figura 3: una representación detallada de una tabla de verificaciones de las transacciones;

- figura 4: una representación detallada de una tabla de las acciones;

- figura 5: una descripción de las etapas de implementación en el procedimiento utilizado por el dispositivo de verificación de las transiciones;

- figuras 6a a 6d: las particularidades implementadas en el caso de un ejemplo de una tarjeta con chip de tipo portamonedas electrónico.

En el invento, se llamará estado de referencia, a un estado a partir del cual es posible transferir hacia otro estado como consecuencia del paso de una transición descrita en la mesa de transiciones, instalada en la memoria del programa.

Como se describe más adelante, es posible añadir nuevos estados y por consiguiente nuevas transiciones una vez que haya tenido lugar la etapa de fabricación del componente. En ese caso, se hablará de estados aditivos para caracterizarlos por oposición a los estados de referencia. Por otra parte, se llamará estado corriente, al estado en el se encuentra el sistema embarcado.

La figura 1 muestra un componente 1, de una tarjeta con chip, equipado de un dispositivo de verificación de transiciones, según el invento. El componente posee una unidad de tratamiento 2, o aún un microprocesador en relación con las memorias 3, 4 y 5 vía un bus de comunicación 6. Una memoria de programa 4 (o aún ROM) no borrable posee por una parte, una zona de programa 7, dichos programas (o aún sistema de explotación del sistema embarcado) pueden ejecutarse por dicha unidad de tratamiento y, por otra parte una zona de datos determinados previamente 10, que contiene constantes utilizadas por dicho sistema de explotación. Entre dichas constantes de la zona 10, el sistema de explotación 7, posee un programa denominado motor de verificación 9, explota una tabla de transiciones 11 que permite precisar los estados a los que se puede acceder a partir del estado corriente, una tabla de verificaciones 12, que permite asociar a cada transición de estado verificaciones que tratan del contenido de las memorias 3,4 y/o 5. En una variante, el motor de verificación 9 puede activar automáticamente acciones en el momento del paso o del rechazo del paso de una transición. Para ello la zona 10 de la memoria de programa posee una tabla de las acciones 13 que permite asociar a cada transición de estado posible acciones a efectuar.

Una memoria volátil 3 (o aún RAM para Random Access Memory en lengua inglesa) permite a la unidad de tratamiento 2 almacenar de manera temporal resultados o aún secretos procedentes de cálculos descritos por los programas implantados en la memoria de programa 4. El contenido de la memoria 3 se borra en cada puesta bajo tensión del componente 1, o en cada demanda de puesta a cero de éste mismo.

Una memoria de datos 5, borrable eléctricamente y que utiliza generalmente la tecnología EEPROM (por Electrical Erasable Programmable Read Only Memory en lengua inglesa) posee una zona 14 conteniendo los datos variables necesarios para la ejecución de los programas 7. Esta zona 14 posee, principalmente, un dato 8 denominado "Estado corriente" que permite memorizar el estado corriente del objeto electrónico portátil. La memoria de datos 5 posee además una zona 15 comprendiendo en opción extensiones de las tablas 11 a 13 en caso de que fuera necesario añadir estados a los estados de referencia. La zona 15 posee entonces una extensión de la tabla de las transacciones 16, una extensión de la tabla de verificación 17 y, puede poseer una extensión de la tabla de las acciones 18 si se desea asociar acciones a las nuevas transiciones de estado aditivo, como se ha visto antes en lo referente a la tabla 13. En caso de adición de estados con respecto a los estados de referencia, es indispensable a veces enriquecer el sistema de explotación 7. Para ello, la memoria 5 puede poseer además una zona 19 que contiene los programas suplementarios que ejecutará a su vez la unidad de tratamiento 2.

La figura 2a muestra una posible implementación de la tabla de transiciones 11. Si se supone que nombramos i estados de referencia, se puede imaginar una tabla de transición comprendiendo i columnas e i líneas. Las columnas corresponden a los estados de referencia que pueden ser, en un momento dado, el estado corriente. Las i primeras líneas corresponden a los estados de referencia a los que se puede acceder a partir del estado corriente. Así pues, el valor de una casilla de la tabla de transiciones 11 correspondiendo a la intersección de una línea y de una columna de dicha tabla, permite codificar, ya sea, la ausencia de transición autorizada (valor nulo por ejemplo) -es el caso de la transición 20), ya sea, la autorización de una transición (valor no nulo -es el caso de la transición 21). En caso de una autorización autorizada, el motor de verificación de transiciones busca en el seno de la tabla de verificación 12 las verificaciones de la transición solicitada.

La figura 2b muestra igualmente una posible implementación de una tabla de transición en caso de que fuera posible añadir estados (estados aditivos) a los estados de referencia. La tabla de las transiciones posee una línea suplementaria con respecto a la figura 2a. La (i+1)a línea permite especificar si se autorizan las transiciones de un estado de referencia corriente a un estado aditivo. Así pues, el valor de la casilla 22 indica una transición prohibida de un estado de referencia hacia un estado aditivo. La casilla 23 indica que será posible transferir del estado de referencia Ei hacia un estado aditivo. Entonces es necesario una extensión 16 de la tabla de transiciones. Esta última posee j líneas correspondientes a j estados aditivos a los que se puede acceder a partir de (i+j) estados corrientes posibles materializados por los (i+j) columnas de la extensión 16 de la tabla de transiciones. De este modo, la combinación de la casilla 23 de la tabla de las transiciones y de la casilla 24 de la extensión 16 de la tabla de las transiciones, indica al motor de verificación que es posible transferir del estado de referencia Ei hacia el estado aditivo E (i+1).

La figura 3 muestra una implementación de la tabla de verificación. La tabla de verificación 12 está instalada en el seno de la zona 10 de los datos determinados previamente de la memoria 4. Cada transición autorizada dispone de una entrada en dicha tabla. Una entrada comprende un campo 30 permitiendo identificar la transición y un campo 31 conteniendo una referencia (o dirección) hacia un programa 32 del sistema de explotación 7. El motor de verificación 9 puede de este modo ejecutar a la unidad de tratamiento 2 los controles necesarios para aceptar el paso de la transición. La figura 3 ilustra igualmente una estructura de una extensión 17 de la tabla de verificación. Del mismo modo que para la tabla 12, la extensión de la tabla de verificación 17 posee una entrada posible por transición. Cada entrada comprende dos campos, un campo 33 que permite identificar la transición y un campo 34 que contiene una referencia (o dirección) de un programa 35 del sistema de explotación o, como muestra la fig. 3, de un programa suplementario instalado en la memoria de datos 5 (en zona 19).

La figura 4 muestra una representación de la tabla de las acciones 13 instalada en la zona 10 de los datos determinados previamente de la memoria de programas 4. En el momento de una demanda de paso de transición, es posible activar acciones. Estas pueden ser de tres tipos: acción sistemática, acción positiva (es decir acondicionada al hecho de que las verificaciones son satisfactorias) o acción negativa (es decir acondicionada al hecho de que las verificaciones no son satisfactorias). La figura 4 muestra que a cada transición autorizada, existe una entrada en la tabla de las acciones 13. Esta entrada comprende 4 campos. El primer campo 400 permite identificar la transición. Los otros tres campos 401, 402 y 403 contienen cada uno una referencia o dirección de un programa 404, 405 o 406 del sistema de explotación. El campo 401 está dedicado a una acción sistemática, el campo 402 a una acción positiva y el campo 403 a una acción negativa. La figura 4 muestra igualmente una extensión 18 de la tabla de acciones. Esta tabla 18 está instalada en la zona 15 de la memoria de datos 5 del componente 1. Del mismo modo que para la tabla de acciones 13, la extensión de la tabla de acciones 18 comprende una entrada posible mediante transición. Una entrada comprende 4 campos. El primer campo 407 permite identificar la transición. Los otros tres campos 408, 409 y 410 contienen cada uno de ellos una referencia o dirección de un programa 411, 412 o 413 del sistema de explotación o como lo muestra la figura 4, de los programas implantados en la zona 19 de la memoria de datos 5 del componente 1. El campo 408 está dedicado a una acción sistemática, el campo 409 a una acción positiva y el campo 410 a una acción negativa.

La figura 5a describe el procedimiento que permite validar o rechazar el paso de una transición de estado, de un primer estado de referencia hacia otro estado de referencia. La demanda de paso de una transición puede formularse como consecuencia de una orden del fabricante de tarjeta o por cualquier otro actor del ciclo de vida de la tarjeta con chip. Dicha demanda puede igualmente formularse directamente mediante la misma tarjeta, por ejemplo, a través de una acción asociada a una transición. En el marco de la figura 5a, el estado de referencia corriente es el estado Ei. Se formula la orden 50 de cambio de estado Ei al estado Ej. La etapa 51 consiste en verificar que se autoriza en el seno de la tabla de las transiciones 11 que la transición del estado Ei hacia el estado Ej. En caso de que esta transición estuviese prohibida, se rechaza la demanda de paso de transición 50. El estado corriente sigue siendo el estado Ei. En cambio, si está autorizada la transición, el motor de verificación 9 ejecuta las verificaciones asociadas a dicha transición. Para ello el motor de verificación evalúa la entrada de la tabla de verificación 12 reservada a la transición T (Ei->Ej). La ejecución de dichas verificaciones corresponde a la etapa 52 del procedimiento. El motor de verificación 9 ejecuta las acciones sistemáticas asociadas a la transición T (Ei->Ej) en función de la entrada de la tabla de las acciones 13 reservadas a dicha transición (etapa 53). Si las verificaciones 54 exigidas durante la demanda de paso de la transición 50 no fuesen satisfactorias, el estado corriente sigue siendo invariable. En función de la entrada de la tabla de las acciones 13 asociada a la transición T (Ei->Ej) el motor de verificación ejecuta las acciones negativas (etapa 55 del procedimiento). El desarrollo del procedimiento está entonces terminado. En cambio, si las verificaciones 54 son satisfactorias, entonces el estado corriente resulta el estado Ej (etapa 56 del procedimiento). Las acciones positivas se ejecutan entonces (etapa 57 del procedimiento) en función del estado de la entrada de la tabla de acciones 13 asociada a la transición T (Ei->Ej). El desarrollo del procedimiento está terminado.

La figura 5b describe el procedimiento que permite validar o rechazar el paso de una transición de estado, de un primer estado aditivo hacia otro estado aditivo. El estado aditivo corriente es el estado Ei. La orden 510 de transferir el estado aditivo Ei al estado aditivo (o de referencia) Ej está formulada. La etapa 511 del procedimiento consiste en verificar en el seno de la extensión la tabla de las transiciones 16 que la transición del estado Ei en el estado Ej está autorizada. En caso de que esta transición estuviese prohibida, se rechaza la demanda de paso de transición 510. El estado corriente sigue siendo el estado Ei. En cambio, si la transición está autorizada, el motor de verificación 9 ejecuta las verificaciones asociadas a dicha transición. Para ello, el motor de verificación evalúa la entrada de la extensión de la tabla de verificaciones 17 reservada a la transición T (Ei->Ej). La ejecución de dichas verificaciones constituye la etapa 512 del procedimiento. El motor de verificación 9 ejecuta las acciones sistemáticas asociadas a la transición T (Ei->Ej) en función de la entrada de la extensión de la tabla de las acciones 18 reservadas a dicha transición (etapa 513 del procedimiento). Si la verificación 514 exigida durante la demanda de paso de la transición 510 no fuese satisfactoria, el estado corriente permanece invariable. En función de la entrada de la extensión de la tabla de las acciones 18 asociada a la transición T (Ei->Ej), el motor de verificación 9 ejecuta las acciones negativas (etapa 515 del procedimiento). El desarrollo del procedimiento está entonces terminado. En cambio, si las verificaciones 514 son satisfactorias, el estado corriente se vuelve el estado Ej (etapa 516 del procedimiento). Las acciones positivas se ejecutan entonces (etapa 517 del procedimiento) en función del estado de la entrada de la extensión de la tabla de las acciones 18 asociada a la transición T (Ei->Ej). El desarrollo del procedimiento está termi-
nado.

La figura 5c describe el procedimiento que permite validar o rechazar el paso de una transición de estado, de un estado de referencia hacia un estado aditivo. El estado de referencia corriente es el estado Ei. La orden 520 de cambio del estado de referencia Ei al estado aditivo Ej está formulada. La etapa 528 del procedimiento consiste en verificar en el seno de la tabla de las transiciones 11, que una transición del estado de referencia corriente Ei hacia un estado aditivo está autorizada. Si tal transición está prohibida, el procedimiento está terminado. El estado corriente sigue siendo invariable. En cambio, si está autorizada una transición de dicho estado de referencia hacia un estado aditivo, el motor de verificación desarrolla las etapas 521 a 527 del procedimiento, respectivamente idénticas a las etapas 511 a 517 descritas en enlace con la figura 5b.

Un ejemplo de aplicación en el campo del portamonedas electrónico se encuentra presente en enlace con las figuras 6a a 6d. Dicha aplicación permite pagar compras con "dinero electrónico" almacenado en una tarjeta con chip, en vez de pagar en metálico. El empleo de esta técnica impone una gestión de las tarjetas tan protegida como la que hubiera impuesto el empleo de dinero metálico. Por ejemplo es preciso evitar la creación de moneda ficticia. La seguridad de una tarjeta con chip portamonedas electrónico se basa generalmente en claves almacenadas en el interior de dicha tarjeta permitiendo transacciones protegidas utilizando la criptografía. Una tarjeta de este tipo dispone de un sistema de explotación que ofrece un juego de mandos y de servicios permitiendo abonar o cargar en cuenta dinero. Al principio del ciclo de vida de la tarjeta con chip portamonedas electrónico, dicha tarjeta con chip no está inicializada. Esta no contiene ninguna información. La figura 6a muestra los estados de referencia determinados previamente:

- Estado E1 "tarjeta virgen" (referencia 80): solamente se encuentran disponibles mandos de prueba permitiendo validar el comportamiento de la memoria de datos 5 (verificación que las casillas memorias de tecnología EEPROM puedan escribirse y borrarse correctamente).

- Estado E2 "tarjeta probada" (referencia 82): Los mandos test ya no están disponibles. A su vez, solamente se encuentran disponibles mandos denominados generalmente "mandos físicos" (permitiendo un acceso en escritura mediante un direccionamiento físico independientemente de toda estructura lógica de tipo archivo por ejemplo). Estos permiten inicializar la tarjeta (escritura en la zona 14 de la memoria de datos de los constituyentes lógicos necesarios para el funcionamiento de la aplicación, es decir archivos, balanzas...);

- Estado E3 "tarjeta inicializada" (referencia 84): los mandos físicos ya no están disponibles. Se pueden utilizar mandos lógicos que permiten personalizar la tarjeta (añadidura de nuevas estructuras lógicas e inicialización de datos en dichas estructuras). Además, está activado un mecanismo de recubrimiento de tal modo que la tarjeta con chip no pierda la coherencia de esos datos durante una puesta bajo tensión de ésta durante la ejecución de uno de dichos mandos lógicos.

- Estado 4 "tarjeta personalizada" (referencia 86): los mandos lógicos específicos a la aplicación Portamonedas electrónico (debe/haber) están activos.

El juego de mandos disponibles evoluciona en función de la etapa de vida en la que se encuentra la tarjeta con chip. Las informaciones almacenadas en memorias de datos permiten al sistema de explotación conocer el estado en el que se encuentra la tarjeta con chip. La figura 6a muestra, por otra parte, que en el marco de una tarjeta de tipo portamonedas electrónico, todas las transiciones entre estados de referencia deben pasarse sucesivamente (del estado E1 al estado E4) y esto de manera irreversible. Cualquier otra transición queda prohibida. Solamente se ofrece la posibilidad de utilizar ulteriormente estados aditivos 88. Esta posible transición lleva la referencia 87. El sistema de explotación en función del estado solo autoriza un conjunto de mandos específicos a cada estado de referencia.

Las verificaciones y acciones que deben activarse durante el paso de una transición se describen así:

- Transición del estado El hacia el estado E2 (anotada T (E1->E2) y referencia 81):

- Verificación: ninguna

- Acción sistemática

borrado de la memoria de datos para evitar que un defraudador deposite datos que pueda interpretar el sistema de explotación de la tarjeta;

- Transición del estado E2 hacia el estado E3 (anotada T (E2->E3) y referencia 83):

- Verificación:

- integridad de los datos escritos en la memoria de datos con los mandos físicos (validación de un código de redundancia por dato),

- verificación del estado virgen de la memoria fuera de dichos datos;

- Acción positiva:

- Activación del mecanismo de recubrimiento;

- Transición del estado E3 hacia el estado E4 (anotada T (E3->E4) y referencia 85):

- Verificación:

- nulidad de la balanza del portamonedas electrónico

- Acción: ninguna

- Transición del estado E4 hacia un estado aditivo (anotada T (E4->Eadd) y referencia 87):

- Verificación: ninguna

- Acción: ninguna

Las figuras 6b a 6d ilustran respectivamente una realización de una tabla de transición 11, de una tabla de verificación 12 y, de una tabla de acciones 13, según el invento. La tabla de transiciones 11 tal como se describe en enlace con la figura 6b permite autorizar únicamente las transiciones 81, 83, 85 y 87. Para ello solamente las casillas 60 a 63 de dicha tabla contienen un valor no nulo. Las demás casillas de la tabla de transición contienen un valor nulo para indicar que cualquier otra transición queda prohibida. La tabla de verificación tal como se presenta a través de la figura 6c, permite asociar las verificaciones que deben satisfacerse para autorizar el paso de las transiciones 81, 83, 85 y 87, dichas transiciones están autorizadas por la tabla de transición 11 (figura 6b).

De este modo, la entrada 64 de la tabla de verificación 12 posee un campo 641 que permite identificar que dicha entrada está reservada para la transición 81. La entrada 64 posee además un campo 642 que contiene una referencia nula para indicar que no se requiere ninguna verificación para autorizar el paso de la transición 81. En una variante, la transición 81 no dispone de ninguna entrada asociada. Esta variante está ilustrada más lejos en el caso de la tabla de acciones. La tabla de verificación 12 posee una entrada 65 que comprende respectivamente un campo 651 para indicar que la entrada está asociada a la transición 83 y un campo 652 conteniendo la referencia de un programa 67, instalado en la memoria de los programas, para que el motor de verificación pueda efectuar las verificaciones descritas anteriormente. Del mismo modo, la tabla de verificación 12, posee una entrada 66 que comprende respectivamente un campo 661 para indicar que la entrada está asociada a la transición 83 y un campo 662 conteniendo la referencia de un programa 68, instalado en la memoria de los programas, para que el motor de verificación pueda efectuar las verificaciones descritas anteriormente. La figura 6d presenta una realización de la tabla de las acciones 13. Dicha tabla posee una entrada 71 que engloba un campo 711 permitiendo indicar que dicha entrada está asociada a la transición 81. La misma entrada 71 posee un campo 712 conteniendo la referencia de un programa 75, instalado en la memoria de los programas, con objeto de que el motor de verificación pueda ejecutar las accione sistemáticas asociadas a la transición 81. La entrada 71 posee además, un campo 713 y un campo 714 que contienen una referencia nula para indicar al motor de verificación que ninguna acción positiva ni negativa están asociadas al paso de la transición 81. Del mismo modo, la tabla de las acciones 13 posee una segunda entrada 72 comprendiendo los campos 721 a 724 para indicar al motor de verificación que dicha entrada está asociada a la transición 83, que el programa 71 debe ejecutarse como acción positiva durante el paso de dicha transición y que no debe ejecutarse ninguna acción sistemática o negativa. La ausencia de entrada, en el seno de la tabla de las acciones 13, asociada a la transición 85, indica que no debe ejecutarse ninguna acción (sistemática, positiva o negativa) durante el paso o el rechazo del paso de dicha transición.

Gracias al dispositivo y al procedimiento descritos anteriormente, puede controlarse el ciclo de vida de un objeto electrónico portátil. Cada transición de estados es irreversible y las verificaciones en cada demanda de transición garantizan una configuración de memoria del objeto coherente. Además, las acciones sistemáticas, positivas o negativas permiten adaptar el comportamiento de dicho objeto. Por último, en caso de que fuera previsto autorizar una o varias transiciones de uno o varios estados de referencia hacia un estado aditivo, el ciclo de vida del objeto puede enriquecerse fácilmente, por ejemplo después de que el objeto sea emitido en el mercado, sin que el ciclo de vida determinado previamente (compuesto por una sucesión de transiciones de estado de referencia hacia otro estado de referencia) pueda desviarse.

Se suprime todo riesgo de fraude durante la inicialización de un objeto electrónico portátil o de error poco afortunado durante dicha inicialización, conservando a la vez una gran adaptabilidad del control del ciclo de vida del objeto.

Claims (34)

1. Dispositivo de control del ciclo de vida de un objeto electrónico portátil, el ciclo de vida está determinado por una sucesión de transiciones de estados, dichos estados determinan los servicios que ofrece el objeto, dicho objeto comprende una unidad de tratamiento (2) una memoria volátil (3), memorias de programas (4) y memorias de datos (5), cada una de esas memorias (3,4,5) presenta un contenido que define una pluralidad de configuraciones.

caracterizado porque comprende medios de control de la transición de un primer estado a un segundo estado del objeto electrónico portátil, que explota medios de autorización y/o prohibición de transiciones de estado, autorizando y/o prohibiendo una transición de estado al explotar una tabla (II) de las transiciones de estado permitidas, de modo que sólo se permitan ciertas transiciones entre el conjunto de las transiciones posibles.

2. Dispositivo según la reivindicación 1, caracterizado porque los medios de control comprenden medios de verificación del contenido de la memoria volátil (3), memorias de datos (5) y memorias de programas (4) del objeto electrónico portátil, en función de la transición de estados que se permite efectuar.

3. Dispositivo según la reivindicación 1 o 2 caracterizado porque los medios de control comprenden:

- además de la tabla (11) de las transiciones de estado permitidas;

- una tabla (12) de las verificaciones que deben efectuarse por transición de estado permitida;

- y un motor de verificación (9) que explota dichas tablas.

4. Dispositivo según cualquiera de las reivindicaciones 1 o 2 caracterizado porque los medios de control de la transición de un primer estado a un segundo estado del objeto electrónico portátil comprenden:

- una extensión (16) de la tabla (11) de las transiciones de estado permitidas;

5. Dispositivo según la reivindicación 3, caracterizado porque los medios de control de la transición de un primer estado a un segundo estado del objeto electrónico portátil comprenden:

- una extensión (16) de la tabla (11) de las transiciones de estado permitidas;

- una extensión (17) de la tabla (12) de las verificaciones que deben efectuarse por transición de estado permitida;

- y porque el motor de verificación (9) explota dichas extensiones de tablas (16, 17).

6. Dispositivo según cualquiera de las reivindicaciones 1 a 5, caracterizado porque los medios de control comprenden medios que permiten poner en funcionamiento acciones durante el tratamiento de una demanda de salto de transición de un primer estado a un segundo estado del objeto electrónico portátil.

7. Dispositivo según la reivindicación 6, cuando ésta depende de las reivindicaciones 4 o 5, caracterizado porque los medios que permiten poner en funcionamiento acciones durante el tratamiento de una petición de salto de transición de un primer estado a un segundo estado del objeto electrónico portátil, comprenden una tabla (13) de acciones explotables por el motor de verificación (9).

8. Dispositivo según la reivindicación 7, caracterizado porque los medios que permiten poner en funcionamiento acciones durante el tratamiento de una petición de salto de transición de un primer estado a un segundo estado del objeto electrónico portátil, comprenden una extensión (18) de la tabla (13) de acciones explotables por el motor de verificación (9).

9. Objeto electrónico portátil que comprende una unidad de tratamiento (2), una memoria volátil (3), memorias de programas (4) y memorias de datos (5), caracterizado porque comprende el dispositivo de control del ciclo de vida del objeto, según las reivindicaciones 1 a 8.

10. Tarjeta con chip que comprende una unidad de tratamiento (2), una memoria volátil (3), memorias de programas (4) y memorias de datos (5), caracterizado porque comprende el dispositivo de control del ciclo de vida de la tarjeta, según una de las reivindicaciones 1 a 8.

11. Procedimiento de control del ciclo de vida de un objeto electrónico portátil, el ciclo de vida está determinado por una sucesión de transiciones de estado, dichos estados determinan los servicios ofrecidos por el objeto, dicho objeto comprende una unidad de tratamiento (2), una memoria volátil (3), memorias de programas (4) y memorias de datos (5), cada una de esas memorias (3, 4, 5) presentan un contenido que define una pluralidad de configuraciones,

dicho procedimiento se aplica en el seno del objeto, a raíz de una demanda de transición de estados,

caracterizado porque comprende:

- una etapa (51, 511, 528, 521) de validación de la autorización de dicha demanda al explotar medios de autorización y/o prohibición de transiciones de estado, de tal modo que solamente sean permitidas ciertas transiciones entre el conjunto de las transiciones posibles, dicha etapa consiste en analizar una tabla (11) de las transiciones permitidas.

- una etapa (56, 516, 526) de modificación del estado corriente del objeto si la transición solicitada es autorizada (51, 511, 528, 521).

12. Procedimiento según la reivindicación 11, caracterizado porque comprende una etapa (53, 513,523) de ejecución de acciones sistemática, acciones asociadas a la transición solicitada.

13. Procedimiento según cualquiera de las reivindicaciones 11 ó 12 caracterizado porque comprende:

- una etapa (52, 512, 522) de evaluación de las verificaciones de la configuración del objeto. Verificaciones asociadas a una transición permitida;

- y porque la etapa (57, 517, 527) de modificación del estado corriente del objeto se ha realizado y dichas verificaciones de la configuración del objeto son satisfactorias (54, 514, 524).

14. Procedimiento según la reivindicación 13, caracterizado porque comprende una etapa 57, 517, 527) de ejecución de acciones positivas, realizada si se permite la transición solicitada (51, 511, 528, 521) y si las verificaciones asociadas a la transición solicitada son satisfechas (54, 514, 524).

15. Procedimiento según cualquiera de las reivindicaciones 13 ó 14, caracterizado porque comprende una etapa (55, 515, 525) de ejecución de acciones negativas si las verificaciones asociadas a la transición solicitada no se han satisfecho (54, 514, 524).

16. Procedimiento según cualquiera de las reivindicaciones 11 a 12, caracterizado porque comprende una etapa (57, 517, 527) de ejecución de acciones positivas realizadas si se ha permitido la transición solicitada (51, 511, 528, 521).

17. Procedimiento según la reivindicación 12, caracterizado porque la etapa (53) de ejecución de acciones sistemáticas consiste:

- en explotar una entrada (400, 401) correspondiente a la transición solicitada, de una tabla (13) de acciones y;

- en ejecutar un programa de acciones (404) definido por dicha entrada.

18. Procedimiento según cualquiera de las reivindicaciones 13 a 15, caracterizado porque la etapa (52) de evaluación de las verificaciones asociada a la transición solicitada, consiste:

- en explotar una entrada (30) de una tabla (12) de las verificaciones y;

- en ejecutar un programa (32) de verificación definido por dicha entrada.

19. Procedimiento según la reivindicación 14, caracterizado porque la etapa (56) de ejecución de acciones positivas consiste, si la transición solicitada es autorizada (51) y si las verificaciones asociadas a la transición solicitada se han satisfecho (54):

- en explotar una entrada (400, 402) correspondiente a la transición solicitada, de una tabla (13) de acciones y;

- en ejecutar un programa de acciones (405) definido por dicha entrada.

20. Procedimiento según la reivindicación 15, caracterizado porque la etapa (55) de ejecución de acciones negativas consiste, si las verificaciones asociadas a la transición solicitada no se han satisfecho (54);

- en explotar una entrada (400, 403) correspondiente a la transición solicitada, de la tabla (13) de acciones y;

- en ejecutar un programa de acciones (406) definido por dicha entrada.

21. Procedimiento según la reivindicación 15, caracterizado porque la etapa (56) de ejecución de acciones positivas consiste, si la transición solicitada se ha autorizado (51):

- en explotar una entrada (400, 402) correspondiente a la transición solicitada, de una tabla (13) de acciones y;

- en ejecutar un programa de acciones (405) definido por dicha entrada.

22. Procedimiento según cualquiera de las reivindicaciones 11 a 16, puesto en aplicación en el seno del objeto, a raíz de una solicitud de transición de un primer estado aditivo hacia un segundo estado aditivo, caracterizado porque la etapa (511) de validación de la autorización de dicha solicitud consiste en analizar una extensión (16) de la tabla (11) de las transiciones permitidas.

23. Procedimiento según la reivindicación 22, cuando ésta depende de la reivindicación 12, caracterizado porque la etapa (513) de ejecución de acciones sistemáticas consiste:

- en explotar una entrada (407, 408) correspondiente a la transición solicitada, de una extensión (18) de una tabla (13) de acciones y;

- en ejecutar un programa de acciones (411) definido por dicha entrada.

24. Procedimiento según cualquiera de las reivindicaciones 22 a 23, cuando la reivindicación 22 depende de las reivindicaciones 13 a 16, caracterizado porque la etapa (512) de evaluación de las verificaciones asociadas a la transición solicitada consiste.

- en explotar una entrada (33) de una extensión (17) de una tabla (12) de las verificaciones y;

- en ejecutar un programa (35) de verificaciones definido por dicha entrada.

25. Procedimiento según cualquiera de las reivindicaciones 22 a 24, cuando la reivindicación 22 depende de la reivindicación 14, caracterizado porque la etapa (516) de ejecución de acciones positivas consiste, si la transición solicitada es autorizada (511) y si las verificaciones asociadas a la transición solicitada se han satisfecho (514);

- en explotar una entrada (407, 409) correspondiente a la transición solicitada, de una extensión (18) de una tabla (13) de acciones y;

- en ejecutar un programa de acciones (412) definido por dicha entrada.

26. Procedimiento según cualquiera de las reivindicaciones 22 a 25, cuando la reivindicación 21 depende de la reivindicación 15, caracterizado porque la etapa (515) de ejecución de acciones negativas consiste, si las verificaciones asociadas a la transición solicitada no se han satisfecho (514);

- en explotar una entrada (407, 410) correspondiente a la transición solicitada, de una extensión (18) de una tabla (13) de acciones y;

- en ejecutar un programa de acciones (413) definido por dicha entrada.

27. Procedimiento según cualquiera de las reivindicaciones 22 a 23, cuando la reivindicación 22 depende de la reivindicación 16, caracterizado porque la etapa (516) de ejecución de acciones positivas consiste, si se ha autorizado la transición solicitada (511);

- en explotar una entrada (407, 409) correspondiente a la transición solicitada, de una extensión (18) de una tabla (13) de acciones y;

- en ejecutar un programa de acciones (412) definido por dicha entrada.

28. Procedimiento según cualquiera de las reivindicaciones 11 a 16, puesto en aplicación en el seno del objeto, a raíz de una solicitud de transición de un estado de referencia hacia un estado aditivo, caracterizado porque la etapa (528, 521) de validación de la autorización de dicha solicitud consiste:

- validar (528) la autorización de una transición del dicho estado de referencia hacia un estado aditivo analizando la tabla (11) de las transiciones permitidas;

- validar (521) la autorización de una transición del dicho estado de referencia hacia dicho estado aditivo analizando una extensión (16) de la tabla (11) de las transiciones permitidas.

29. Procedimiento según la reivindicación 28, cuando ésta depende de la reivindicación 12, caracterizado porque la etapa (513) de ejecución de acciones sistemáticas consiste;

- en explotar una entrada (407, 408) correspondiente a la transición solicitada, de una extensión (18) de una tabla (13) de acciones y;

- en ejecutar un programa de acciones (411) definido por dicha entrada.

30. Procedimiento según cualquiera de las reivindicaciones 28 a 29, cuando la reivindicación 28 depende de las reivindicaciones 13 a 15, caracterizado porque la etapa (522) de evaluación de las verificaciones asociadas a la transición solicitada consiste);

- en explotar una entrada (33) de una extensión (17) de una tabla (12) de las verificaciones y;

- en ejecutar un programa (35) de verificaciones definido por dicha entrada.

31. Procedimiento según cualquiera de las reivindicaciones 28 a 30, cuando la reivindicación 28 depende de la reivindicación 14, caracterizado porque la etapa (526) de ejecución de acciones positivas consiste, si la transición solicitada ha sido autorizada (528, 521) y si las verificaciones asociadas a la transición solicitada se han satisfecho (524);

- en explotar una entrada (407, 409) correspondiente a la transición solicitada, de una extensión (18) de una tabla (13) de acciones y;

- en ejecutar un programa de acciones (412) definido por dicha entrada.

32. Procedimiento según cualquiera de las reivindicaciones 28 a 30, cuando la reivindicación 21 depende de la reivindicación 28, depende de la reivindicación 15, caracterizado porque la etapa (525) de ejecución de acciones negativas consiste, si las verificaciones asociadas a la transición solicitada no se han satisfecho (524);

- en explotar una entrada (407, 410) correspondiente a la transición solicitada, de una extensión (18) de una tabla (13) de acciones y;

- en ejecutar un programa de acciones (413) definido por dicha entrada.

33. Procedimiento según cualquiera de las reivindicaciones 28 a 29, cuando la reivindicación 28 depende de la reivindicación 16, caracterizado porque la etapa (526) de ejecución de acciones positivas consiste, si la transición solicitada se ha autorizado (528, 521);

- en explotar una entrada (407, 409) correspondiente a la transición solicitada, de una extensión (18) de una tabla (13) de acciones y;

- en ejecutar un programa de acciones (412) definido por dicha entrada.

34. Procedimiento según cualquiera de las reivindicaciones 11 a 33, caracterizado porque dicho procedimiento no autoriza el paso de una transición de estado, de un estado aditivo hacia un estado de referencia.