Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR MANAGING ACCESS RIGHTS IN A SMART CARD
Document Type and Number:
WIPO Patent Application WO/2009/090350
Kind Code:
A1
Abstract:
The invention relates to a method for managing access rights in a smart card, so that the execution of a control (Cmd1, Cmdk), such as reading or writing, depends on the validation of an event (Evt1', Evtk'), such as an authentication by code checking. The event validation state is stored into a register, and the access rights are stored in a control list (List_Cmd) including pairs (CpI1, CpIk) each associating a control with an event. Upon reception of a control execution request, the method comprises searching the pair (CpI1, CpIk) including the requested control in the control list (List_Cmd), and rejecting the execution in case of an unsuccessful search. In case of a successful search, the method comprises determining, from the register (or so-called card security check register), whether or not the event associated with the control is validated or not in order to authorise or reject the execution. The invention is intended for any smart card application that uses access rights.

Inventors:
PEPIN CYRILLE (FR)
ROUDIERE GUILLAUME (FR)
Application Number:
PCT/FR2008/001521
Publication Date:
July 23, 2009
Filing Date:
October 29, 2008
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
SAGEM SECURITE (FR)
PEPIN CYRILLE (FR)
ROUDIERE GUILLAUME (FR)
International Classes:
G06F21/62; G06F21/77
Foreign References:
US6779113B12004-08-17
EP1431862A22004-06-23
Other References:
See also references of EP 2210209A1
Attorney, Agent or Firm:
LAVIALLE, Bruno (22 rue du Général Foy, Paris, FR)
Download PDF:
Claims:

REVENDICATIONS

1. Procédé de gestion des droits d'accès associés à des données d'une carte à puce, pour subordonner l'exécution d'une commande (Cmdi .. Cmd k ) telle qu'une commande de lecture de ces données, à la validation d'une combinaison logique de plusieurs événements (Evti' .. Evt k ' ) détectés par la carte, tels qu'une authen- tification par vérification d'un code, dans lequel l'état de validation de chaque événement (Evti.. Evt N ) est tenu à jour dans un registre d'état de sécurité de la carte ({ Evt a , Evt b , ... Evt x }) ; dans lequel les droits d'accès d'un ensemble de données sont enregistrés dans une liste des commandes (List_Cmd) à laquelle est associée une liste d'événements

(List_Evt) donnant pour chaque événement qu'elle comporte un identificateur de cet événement, la liste de commande étant formée de couples (CpIi.. CpIk) associant chacun une commande (Cmdi .. Cmd k ) à une combinaison logique d'événements à valider qui est définie par les rangs dans la liste d'événements (List_Evt) de chacun des événements composant cette combinaison ; dans lequel à réception d'une requête d'exécution d'une commande (C) sur un ensemble de données, l'autorisation ou le refus d'exécuter cette commande est établi : en recherchant dans la liste des commandes (List_Cmd) associée à ces données, le couple (CpIi-. CpI k ) comprenant la commande requise (C) et en refusant l'exécution en cas de recherche infructueuse ;

- et en cas de recherche fructueuse, en déterminant, à partir du registre d'état de sécurité de la carte si la combinaison d'événements (Evti' ..Evtk' ) associée à la commande (C) est ou non validée pour autoriser ou re-

fuser l'exécution de la commande (C).

2. Procédé selon la revendication 1, dans lequel chaque commande (Cmdi.. Cmd k ) enregistrée dans la liste de commandes (List_Cmd) est codée sous forme d'un mot bi- naire représentatif d'un identificateur de cette commande (Cmdi..Cmd k ) .

3. Procédé selon la revendication 1 ou 2, dans lequel la liste d'événements (List_Evt) comporte aussi une ou plusieurs combinaisons d'événements, chaque combi- naison y étant définie par les rangs dans la liste d'événements (List_Evt) de chacun des événements composant cette combinaison, cette liste étant ordonnée de telle manière que chaque combinaison logique d'événements est située après les événements qui la composent. 4. Procédé selon l'une des revendications 1 à 3, dans lequel la liste d'événements (List_Evt) débute par un mot binaire représentatif du nombre (N DAC ) d'événements et de combinaisons d'événements que cette liste comporte.

5. Procédé selon l'une des revendications 1 à 4, dans lequel chaque événement ou combinaison d'événements

(Evti .. Evtk) enregistré dans une liste est codé sous forme d'un mot binaire débutant par un premier indicateur binaire (Spl/Cps) indiquant s'il s'agit d'un événement ou d'une combinaison logique d'événements. 6. Procédé selon la revendication 5, dans lequel chaque mot binaire correspondant à un événement (Mot_Evt_Spl) comprend l'identificateur de cet événement codé en fin de mot (S-P2) .

7. Procédé selon la revendication 5 ou 6, dans lequel chaque mot correspondant à une combinaison logique d'événements (Mot_Evt_Cps) comprend une série d'indicateurs binaires située en fin de mot (S-Rg), dans laquelle chaque indicateur binaire valant "UN" indique que l'événement ayant dans la liste d'événements (List_Evt) le rang qu'a cet indicateur dans la série (S-

Rg) fait partie de cette combinaison logique d' événements .

8. Procédé selon l'une des revendications 5 à 7, dans lequel le second indicateur binaire (OU/ET) de chaque mot correspondant à une combinaison logique d'événements (Mot_Evt_Cρs) indique s'il s'agit d'une combinaison logique conjonctive ou bien disjonctive.

9. Carte à puce comprenant des moyens de mise en oeuvre du procédé selon l'une des revendications 1 à 8.

Description:

Procédé de gestion des droits d'accès dans une carte à puce .

L' invention concerne la gestion des droits d'accès à des données enregistrées dans une carte à puce. ARRIERE PLAN DE L' INVENTION

Une carte à puce contient typiquement de la mémoire morte réinscriptible, du type Flash ou EEPROM, un processeur ou microcontrôleur ainsi que de la mémoire volatile ou mémoire RAM. Les droits d'accès assurent la confidentialité des données contenues dans la carte, cette confidentialité étant essentielle dans de multiples applications, comme par exemple les cartes bancaires, ou les cartes SIM utilisées dans les téléphones mobiles. Lorsque la carte est engagée dans un appareil, l'exécution de commandes telles que lecture ou écriture de données n' est possible que si des conditions particulières sont remplies.

Ces conditions sont par exemple une authentifica- tion préalable par vérification d'un code, ou bien l'établissement d'un canal sécurisé entre le lecteur de carte et le terminal depuis lequel les commandes sont émises .

La gestion des droits d'accès, qui permet de dé- terminer si les conditions requises sont remplies pour exécuter une commande, est assurée par un programme d'évaluation des droits, appelé masque, préenregistré dans la mémoire de la carte, et exécuté par son processeur . Lorsqu'une requête en exécution d'une commande telle que la lecture d'un ensemble de données est reçue, le programme d'évaluation des droits identifie d'abord les droits d'accès associés à ces données.

Ces droits mémorisés dans la carte définissent les conditions requises pour exécuter chaque commande sur

les données visées : par exemple, une authentification par vérification d'un code est nécessaire pour exécuter une commande de lecture.

Le programme détermine ensuite si les conditions en question sont remplies, en consultant un registre, dit d'état de sécurité de la carte, mémorisé dans celle-ci, et dans lequel est tenue à jour une liste d'événements préalablement validés.

Ces événements sont par exemple 1' authentification par vérification d'un code, l'établissement effectif d'un canal de communication sécurisé entre la carte et le terminal avec lequel elle interagit, ou autre, chaque événement étant dans un état dit validé s'il a été accompli avec succès. Dans la pratique, il s'avère que les programmes et architectures de gestion de droits d'accès connus ne donnent pas entièrement satisfaction.

Ceci est dû au fait que la structure générale des droits d' accès est complexe puisque chaque ensemble de données mémorisées dans la carte, par exemple chaque fichier, possède des droits d'accès qui lui sont propres.

De plus, pour un même fichier, ces droits définissent des conditions qui ne sont pas les mêmes d'une commande à l'autre. De plus, pour une même commande à exécuter sur un même fichier, les conditions diffèrent selon que la carte communique avec un terminal par contact électrique, ou par une liaison sans fil.

La lecture d'un fichier peut nécessiter une au- thentification, l'écriture dans ce fichier peut nécessiter en outre l'établissement d'un canal sécurisé, et sa suppression peut nécessiter une autre authentification avec un autre code distinct du premier.

Pour un autre fichier, la lecture, l'écriture et la suppression peuvent être effectuées sans qu'aucune condition n'ait à être remplie.

Ainsi, chaque fichier possède des droits qui lui sont propres, et le système de droits d'accès peut aussi être complexe en soi puisqu' il peut faire intervenir une multitude de conditions telles que plusieurs niveaux d' authentifications par différents codes, l'établissement de canaux sécurisés, ou autre. En outre, ces conditions sont combinables : par exemple, le droit d'écriture de données dans un fichier peut être accordé si : une authentification de premier niveau a été effectuée et un canal sécurisé a été établi ou si une authentification de second niveau a été effec- tuée avec succès.

Ainsi, les droits d'accès occupent un espace mémoire important dans la carte, alors que la capacité de mémoire d'une carte à puce est en soi restreinte. De plus, le temps d'exécution du programme d'évaluation des droits est pénalisé par le fait qu'il doit effectuer des lectures multiples pour déterminer si une commande peut ou non être exécutée sur un fichier donné.

Plusieurs normes, telles que les normes ISO 7816- 4 ou bien ISO 7816-9 décrivent des mécanismes de gestion des droits d'accès, mais toutes présentent des lacunes : elles sont peu ouvertes, et donnent lieu à un temps d'évaluation des droits trop long.

OBJET DE L' INVENTION Le but de l'invention est de proposer une archi- tecture de gestion des droits d'accès qui permette de remédier aux inconvénients ci-dessus en offrant une compacité de l'enregistrement des données, une vitesse d'exécution élevée du programme de gestion des droits, ainsi qu'une sécurité de fonctionnement suffisante. RESUME DE L' INVENTION

A cet effet, l'invention a pour objet un procédé de gestion des droits d'accès associés à des données d'une carte à puce, pour subordonner l'exécution d'une commande telle qu'une commande de lecture de ces données, à la validation d'une combinaison logique de plusieurs événements détectés par la carte, tels qu'une authentifi- cation par vérification d'un code, dans lequel l'état de validation de chaque événement est tenu à jour dans un registre d'état de sécurité de la carte; dans lequel les droits d'accès d'un ensemble de données sont enregistrés dans une liste des commandes à laquelle est associée une liste d'événements donnant pour chaque événement qu'elle comporte un identificateur de cet événement, la liste de commande étant formée de couples associant chacun une commande à une combinaison logique d'événements à valider qui est définie par les rangs dans la liste d'événements de chacun des événements composant cette combinaison ; dans lequel à réception d'une requête d'exécution d'une commande sur un ensemble de données, l'autorisation ou le refus d'exécuter cette commande est établi :

- en recherchant dans la liste des commandes as- sociée à ces données, le couple comprenant la commande requise et en refusant l'exécution en cas de recherche infructueuse ;

- et en cas de recherche fructueuse, en déterminant, à partir du registre d'état de sécurité de la carte si la combinaison d'événements associée à la commande est ou non validée pour autoriser ou refuser l'exécution de la commande .

L'invention concerne également un procédé tel que défini ci-dessus, dans lequel chaque commande enregistrée dans la liste de commandes est codée sous forme d'un mot

binaire représentatif d'un identificateur de cette commande. Il est à noter que toutes les commandes possibles ne sont pas nécessairement répertoriées dans cette liste de commandes. L'invention concerne également un procédé tel que défini ci-dessus, dans lequel la liste d'événements comporte aussi une ou plusieurs combinaisons d' événements , chaque combinaison y étant définie par les rangs dans la liste d' événements de chacun des événements composant cette combinaison, cette liste étant ordonnée de telle manière que chaque combinaison logique d'événements est située après les événements qui la composent.

L' invention concerne également un procédé tel que défini ci-dessus, dans lequel la liste d'événements dé- bute par un mot binaire représentatif du nombre d'événements et de combinaisons d'événements que cette liste comporte, cette liste pouvant être vide.

L'invention concerne également un procédé tel que défini ci-dessus, dans lequel chaque événement ou combi- naison d'événements enregistré dans une liste est codé sous forme d' un mot binaire débutant par un premier indicateur binaire indiquant s'il s'agit d'un événement ou d'une combinaison logique d'événements.

L'invention concerne également un procédé tel que défini ci-dessus, dans lequel chaque mot binaire correspondant à un événement comprend l'identificateur de cet événement codé en fin de mot .

L'invention concerne également un procédé tel que défini ci-dessus, dans lequel chaque mot correspondant à une combinaison logique d'événements comprend une série d'indicateurs binaires située en fin de mot, dans laquelle chaque indicateur binaire valant "UN" indique que l'événement ayant dans la liste d'événements le rang qu'a cet indicateur dans la série fait partie de cette combi- naison logique d'événements.

L'invention concerne également un procédé tel que défini ci-dessus, dans lequel le second indicateur binaire de chaque mot correspondant à une combinaison logique d'événements indique s'il s'agit d'une combinaison logique conjonctive ou bien disjonctive.

L'invention concerne également une carte à puce comprenant des moyens de mise en oeuvre du procédé ci- dessus .

BREVE DESCRIPTION DES DESSINS - La figure 1 est une représentation schématique d'une liste d'événements et d'une liste de commandes associées à un ensemble de données dans le procédé selon l'invention ;

- La figure 2 est une représentation schématique d'un mot représentatif d'un événement simple dans le procédé selon l'invention ;

- La figure 3 est une représentation schématique d'un mot représentatif d'un événement composite dans le procédé selon l'invention. DESCRIPTION DETAILLEE DE L'INVENTION

L'invention s'applique notamment à une carte à puce comprenant des moyens de mémorisation, tels qu'une mémoire volatile et une mémoire non volatile ainsi qu'un processeur, et un programme de gestion de droits d'accès aux fichiers ou ensembles de données mémorisés dans cette carte .

L'idée à la base de l'invention est de définir un format d'enregistrement des droits d'accès modulable en fonction du besoin, en association avec un algorithme ca- pable d'assurer une évaluation rapide des droits d'accès. Une commande à exécuter sur un ensemble de données, ou fichier, est généralement subordonnée à la validation préalable d'un événement ou d'une combinaison d'événements, c'est à dire à la validation d'un événement qui peut être soit simple soit composite. Ainsi, dans la

suite, les événements en tant que tels sont appelés événements simples et les combinaisons d' événements sont appelées événements composites.

La validation d'un événement simple correspond par exemple à la vérification d'un code PINl ou PIN2 ou d'un mot de passe, ou bien à l'établissement d'un canal de communication sécurisé.

Un événement composite est la combinaison logique "ET" ou bien "OU", c'est-à-dire la conjonction ou la dis- jonction, de plusieurs événements simples, et il peut aussi être défini comme la combinaison logique de plusieurs événements composites se ramenant à une combinaison d'événements simples.

Les événements sont numérotés et gérés comme des valeurs numériques ou identificateurs, et l'état de sécurité de la carte, noté { Evt a , Evtb, ... Evt x }, est la liste des événements validés à un instant donné, elle est mémorisée et tenue à jour dans un registre de mémoire de la carte à puce. Si le système de droits d'accès ne fait intervenir que des événements simples, le format d'enregistrement des droits d'accès comprend principalement une liste de commande, notée List_Cmd et représentée schématiquement en figure 1, qui est associée à chaque ensemble de données ou fichier.

Il s'agit d'une liste de couples ou doublons, notés CpIi.. CpIk, comprenant chacun une commande et un événement, toutes les commandes existantes n'étant pas nécessairement présentes dans cette liste. Dans l'exemple de la figure 1, le couple CpIi associe la commande Cmdi à l'événement Evti' , et le couple Cpl k associe la commande Cmd k à l'événement Evtj/ .

Chaque événement Evti'..Evt]/ est représenté dans la liste de commande par son identificateur numérique qui

permet par exemple de connaître son état par simple lecture du registre d'état de sécurité de la carte.

A réception d'une requête en exécution d'une commande notée C sur un ensemble de données, l'accord ou le refus d' exécuter cette commande est décidé en recherchant la commande C dans la liste de commande List_Cmd relative à l'ensemble de données visé.

En cas de recherche infructueuse, la commande C n'est pas exécutée. En cas de recherche fructueuse, la commande est exécutée si l'événement associé à la commande C dans la liste List_Cmd est validé dans le registre d'état de sécurité, et elle n'est pas exécutée sinon.

Si le système de droits d'accès fait intervenir des événements composites, on adjoint à la liste de com- mandes List_Cmd, une liste d'événements, représentée schématiquement en figure 1 où elle est repérée par

List_Evt .

Cette liste d'événements est exploitée conjointement avec la liste de commandes pour définir les évène- ments composites :

La liste d'événements comporte des événements simples repérés par leurs identificateurs, et chaque événement composite est défini dans la liste de commande par les rangs, dans la liste d'événements, des événements qui le composent.

La liste d'événements peut aussi comporter des événements composites, ce qui permet de définir des combinaisons logiques complexes, c'est à dire faisant intervenir les opérateurs "OU" et "ET". Chaque événement com- posite de la liste d'événements est alors défini par les rangs, dans cette liste d'événements, des événements simples ou composites qui le composent.

Ainsi, quoi qu'il en soit, chaque événement simple intervenant dans la définition d'un événement compo- site apparaît nécessairement dans la liste d'événements.

Si le système de droits fait également intervenir des événements simples conditionnant à eux seuls l'exécution d'une commande, ces événements simples apparaissent dans la liste de commande, de manière analogue au cas où le système de droits ne fait intervenir que des événements simples.

Les événements simples et les événements composites sont codés par des mots binaires, respectivement Mot_Evt_Spl et Mot_Evt_Cps, qui ont des structures diffé- rentes.

La structure d'un mot binaire Mot_Evt_Spl correspondant à un événement simple est représentée schémati- quement en figure 2. Ce mot binaire, c'est-à-dire cet ensemble de bits ou indicateurs binaires, comprend un pre- mier bit, noté Spl/Cps, suivi d'une série de bits notée S-P2.

Le premier bit Spl/Cps qui est un marqueur indiquant s'il s'agit d'un événement simple ou composite est mis à une valeur représentative d'un événement simple. Il est inutile si l'on gère uniquement des événements simples .

La série de bits S-P2 est le codage en puissances de deux de l'identificateur de l'événement permettant par exemple de connaître son état de validation par lecture dans le registre d'état de sécurité de la carte.

Si la série S-P2 comporte 4 bits, 16 événements simples sont possibles : l'événement simple dont l'identificateur est la valeur numérique "3", noté Evt 3 , étant alors codé sous la forme [ 0 - 0 0 1 1 ] , et l'événement simple dont l'identificateur est la valeur "6", noté Evte, étant alors codé sous la forme [ 0 - 0 1 1 0 ].

La structure d'un mot binaire Mot_Evt__Cps définissant un événement composite est représentée schémati- quement en figure 3. Ce mot binaire comprend un premier

bit noté Spl/Cps suivi d'un second bit noté OU/ET, lui- même suivi par une série de bits notée S-Rg.

Le bit Spl/Cps qui est un marqueur indiquant s'il s'agit d'un événement simple ou composite est mis à une valeur représentative d'un événement composite. Le second bit noté ET/OU est un marqueur indiquant si l'événement composite est la conjonction ou la disjonction de plusieurs événements.

La série de bits S-Rg définit les événements constitutifs de l'événement composite, qui y sont codés par rangs et non pas par puissances de deux : dans cette série le rang de chaque bit ayant la valeur 1 fait référence à l'événement ayant le même rang dans la liste d'événements List_Evt. Cette solution de codage par rang permet de réduire significativement la longueur du mot Mot_Evt_Cps : un événement composite peut être constitué d'un nombre d'événements correspondant simplement à la longueur de la série S-Rg. Ainsi, pour une taille de liste d'événements de

6, c'est-à-dire si N vaut 6, l'événement composite "Evti OU Evt 2 OU Evt 3 " est codé par le mot binaire [ 1 - 0 - 0 0 0 1 1 1 ].

Dans le mot ci-dessus, le premier bit Spl/Cps est à 1 pour spécifier que l'événement est composite, le second bit ET/OU qui est à 0 signifie qu'il s'agit de la combinaison logique "OU", et les trois bits suivants sont à 1 pour indiquer qu'il s'agit de la combinaison des événements de rangs 1, 2 et 3 dans la liste d'événements List_Evt.

De manière analogue, l'événement composite "Evt 4 ET Evt 5 " est codé par le mot [ 1 - 1 - 0 1 1 0 0 0 ].

Chaque événement composite est la conjonction ou la disjonction de plusieurs événements de la liste d'événements List_Evt, de sorte qu'un événement composite

peut être constitué d'événements eux même composites. Ceci permet d'établir des combinaisons logiques complexes, c'est-à-dire faisant intervenir la conjonction et la disjonction. Dans ce cadre, l'exemple ci-dessous illustre le codage de l'événement composite " (Evti OU Evt 2 ) ET Evt 3 I! :

La liste d'événements est alors codée sur 34 bits [N=5] [ 1 0 1 ] 3 bits

[Evtl] [ 0 - 0 0 0 1 ] 5 bits [Evt2] [ 0 - 0 0 1 0 ] 5 bits

[Evt3] [ 0 - 0 0 1 1 ] 5 bits

[Evt4 = Evtl OU Evt2] [ 1 - 0 - 0 0 0 0 1 1 ] 8 bits

[Evt4 ET Evt3] [ 1 - 1 - 0 0 1 1 0 0 ] 8 bits

Comme dans le cas de la gestion d'événements sim- pies, la gestion des droits d'accès d'un système comprenant des événements composites est assurée en se référant au registre d'état de sécurité de la carte.

A réception d'une requête en exécution d'une com- mande C sur un ensemble de données, l'accord ou le refus d' exécuter cette commande est décidé en recherchant la commande C dans la liste de commande List_Cmd relative à l'ensemble de données visé. Si la recherche est infructueuse, la commande C n'est pas exécutée. Si la recherche est fructueuse, la commande est exécutée lorsque l'événement associé à la commande C dans la liste List_Cmd est valide.

S'il s'agit d'un événement simple, on détermine par lecture du registre d' état de sécurité de la carte si cet événement est ou non valide pour autoriser ou non l'exécution de la commande.

S'il s'agit d'un événement composite, la combinaison logique le définissant est identifiée à partir de la liste d'événements List_Evt à laquelle renvoie la liste de commandes List Cmd. Puis on détermine à partir

d'une lecture du registre d'état de sécurité de la carte si cette combinaison logique est ou non vérifiée pour autoriser ou refuser l'exécution de la commande.

Le format d'enregistrement des droits d'accès est ainsi modulable en fonction des besoins, car la taille et la présence de chaque élément peut être définie au plus juste pour chaque cas d'utilisation, c'est-à-dire pour chaque application de carte à puce.

Les paramètres à faire varier sont le nombre maximum de commandes existantes, noté N CMD ; le nombre maximum d'événements possibles, noté N E vτ ; et le nombre maximum d' événements pouvant apparaître dans la liste d'événements, noté N DAC .

Pour gérer des droits très simples, n'impliquant que les commandes de lecture (READ) et d'écriture (WRITE) et ne faisant intervenir que les événements simples suivants : "toujours", noté [ALL] ; "jamais", noté [NEV] ; "vérification du code PIN", notée [PIN] ; "établissement d'un canal sécurisé", noté [SM], le système peut être pa- ramétré avec les valeurs suivantes :

N CMD = 2 : les commandes sont donc codées sur 1 seul bit : [READ] = 0 et [WRITE] = 1.

N DAC = 0 : comme il y a uniquement des événements simples, la liste List_Evt et le bit Spl/Cps ne sont pas nécessaires.

N EV τ = 4 : les événements simples sont codés sur une série S-P2 comprenant deux bits : [ALL] = 0 0 ; [PIN] = 0 1 ; [SM] = 1 0 ; [NEV] = 1 1.

Pour un droit d'accès correspondant à une lecture autorisée tout le temps, et à une écriture autorisée seulement lorsque le code PIN est vérifié, le codage peut être effectué sur seulement β bits, comme illustré ci- dessous :

[READ] [ 0 ] 1 bit [ALL] [ 0 0 ] 2 bits

[WRITE] [ 1 ] 1 bit

[PIN] [ 0 1 ] 2 bits

A l'opposée, pour un système très ouvert, on peut prendre les valeurs suivantes :

N CMD = 64 : les commandes sont alors codées sur 6 bits .

N EV τ = 128 les événements simples sont codés sur 8 bits comprenant le bit Spl/Cps et 7 bits correspondant à la série S-P2 dédiée à leurs identificateurs codés en puissances de deux.

N DAC - 8 : les événements composites sont codés sur 10 bits comprenant le bit Spl/Cps, le bit OU/ET, et 8 bits correspondant à la série S-Rg. Chaque événement composite peut ainsi être une combinaison de un à huit événements pris dans les 8 premiers événements de la liste List_Evt.

Ainsi, chaque élément de la liste de commandes, c'est-à-dire chaque couple représentatif d'une commande et de l'événement associé à celle-ci est alors codé sur 14 bits pour un événement simple et 16 bits pour un composite .

Avec ces paramètres, l'exemple suivant décrit les droits d'accès pour les conditions suivantes : la lecture est autorisée si le code PINl a été vérifié ; l'écriture est autorisée lorsque le code PIN2 a été vérifié ET qu'un canal sécurisé est établi ; l'effacement est autorisé si le code PIN3 a été vérifié OU si un canal sécurisé a été établi : [N=4] [ 0 1 0 0 ] 4 bits

[SM] [ 0 - 0 0 0 1 1 1 1 ] 8 bits

[PIN2] [ 0 - 0 0 0 0 0 1 0 ] 8 bits

[PIN3] [ 0 - 0 0 0 0 0 1 1 ] 8 bits

[READ] [ 0 0 0 0 0 1] 6 bits

[PINl] [ 0 - 0 0 0 0 0 0 1 ] 8 bits

[WRITE] [ 0 0 0 0 1 0] 6 bits

[PIN2 ET SM] [ 1 - 1 - 0 0 0 0 0 0 1 1 ] 10 bits

[DELETE] [ 0 0 0 0 1 1] 6 bits

[PIN3 OU SM] [ 1 - 0 - 0 0 0 0 0 1 0 1 ] 10 bits Ainsi, l'ensemble des droits d'accès relatifs à ces données ou ce fichier est codé sur seulement 74 bits. L'algorithme implémenté par le programme d'évaluation des droits d'accès retourne la valeur "VRAI" si les conditions nécessaires sont remplies pour accéder au fichier, et il retourne la valeur "FAUX" sinon.

Pour déterminer si l'accès doit être autorisé ou refusé, le programme identifie d'abord la commande qui est demandée, notée C, ainsi que l'état de sécurité de la carte noté { Evt a , Evt b , ... Evt x } .

Dans un premier temps, si une liste d'événements est présente, c'est-à-dire si N Dac ne vaut pas 0, le pro- gramme identifie les événements simples apparaissant dans la liste List_Evt, qui sont aussi présents dans l'état de sécurité de la carte { Evt a , Evt b , ... Evt x } .

En d'autres termes, il détermine quels sont les événements simples de la liste des droits d'accès qui sont effectivement validés par l'état de sécurité de la carte, et il enregistre cet état.

Ensuite, pour chaque événement composite présent dans la liste d'événements si elle en comporte, le programme vérifie s'il est valide ou non en fonction de l'état des événements enregistrés ci-dessus, et il enregistre également cet état.

La liste d'événements est ordonnée de la manière suivante : les événements simples en premier, suivis éventuellement d' événements composites agencés de telle manière que les événements auxquels ils font référence

les précèdent dans la liste. Grâce à cet ordre, le droit d'accès peut être évalué en une seule passe, sans récur- sivité .

Le programme recherche ensuite la commande C dans la liste des commandes, et si la commande C est absente de cette liste, il retourne la valeur "FAUX", du fait que par convention l'absence de la commande recherchée correspond à la condition "jamais".

Lorsque la commande C est présente dans la liste, le programme évalue la validité de l'événement qui lui est associé, qui est l'événement apparaissant dans le couple contenant la commande C.

S'il s'agit d'un événement simple, son état de validité peut être déterminé par lecture directe dans l'état de sécurité de la carte. S'il s'agit d'un événement composite, son état de validité est déterminé à partir des états enregistrés à l'issue de la première étape.

Le programme retourne ensuite la valeur "VRAI" ou "FAUX" selon que l'événement associé à la commande est valide ou non valide.

Pour optimiser la recherche de la commande, on peut jouer sur les paramètres N CMD/ N EVT , N Dac pour que tous les éléments soient enregistrés sur des octets complets.

On peut également imposer que les événements simples et composites aient la même taille.