FR2867929A1

FR2867929A1 - Procede d'authentification dynamique de programmes par un objet portable electronique

Info

Publication number: FR2867929A1
Application number: FR0450553A
Authority: FR
Inventors: Mames Benoit Chevallier; David Naccache; Pascal Paillier
Original assignee: Gemplus Card International SA; Gemplus SA
Current assignee: Gemplus SA
Priority date: 2004-03-19
Filing date: 2004-03-19
Publication date: 2005-09-23
Anticipated expiration: 2024-03-19
Also published as: EP1728354A1; FR2867929B1; WO2005101725A1; US20080232582A1

Abstract

La présente invention décrit un procédé permettant d'authentifier dynamiquement le contenu d'un programme exécutable, c'est-à-dire la suite des instructions que celui-ci définit. Plus précisément, l'authentification d'un programme est réalisée de manière répétée au cours de l'exécution même dudit programme. Le procédé de sécurisation d'un objet portable électronique exécutant un programme P fourni par un autre objet électronique non sûr, utilise, entre autre, un protocole à clé secrète.

Description

Ce brevet d'invention décrit un procédé permettant d'authentifier

dynamiquement le contenu d'un programme exécutable, c'est-à-dire la suite des instructions que celui-ci définit. Plus précisément, l'authentification d'un

programme est réalisée de manière répétée au cours de l'exécution même dudit programme.

Le principe de fonctionnement de l'invention permet de concevoir un nouveau type d'élément sécurisé appelé Externalized Microprocessor où X P qui, contrairement à d'autres dispositifs de calcul tels que la carte à puce (objet de nombreux brevets comme par exemple FR.2 266 222) ne contient pas de mémoire programme (classiquement appelée mémoire ROM, de l'anglais Read Only Memory ). A la différence des dispositifs classiques, en effet, le X P 15 peut exécuter des programmes qui lui sont transmis au moment même de leur exécution, en toute sécurité.

Les avantages qu'un dispositif mobile de calcul sans mémoire ROM présente par rapport aux technologies de calcul embarqué classiques (nous prendrons la carte à puce comme technologie de référence) sont extrêmes: le masquage, opération industrielle au cours de laquelle on grave une mémoire ROM spécifique, disparaît totalement; la correction des bogues se résume à une mise à jour des programmes stockés dans le disque dur des terminaux ou sur un réseau de communication tel qu'Internet, et ne nécessite donc pas de devoir retirer du marché ou renouveler des cartes à puce défectueuses; plus important encore, la taille des programmes n'est plus un facteur limitant.

Ce dernier avantage est d'autant plus attractif que la tendance technologique a toujours été de faire exécuter à la carte à puce des programmes de plus en plus complexes et donc de plus en plus volumineux. D'un point de vue industriel et fonctionnel, une carte à puce est un ordinateur miniature. Une petite mémoire volatile RAM (de l'anglais Random Access Memory ) embarquée avec le microprocesseur sert à stocker les résultats temporaires d'un calcul et le microprocesseur de la puce exécute un programme écrit de manière non modifiable dans la mémoire ROM: l'homme de métier emploie le terme de gravure, cette gravure ayant été effectuée à l'étape dite de masquage. Ce programme ne peut ensuite plus être modifié de quelque façon.

Pour le stockage de données spécifiques à l'utilisateur, les puces contiennent une mémoire non volatile EEPROM (pour Electrically Erasable and Programmable ROM ) ou Flash, ces deux types de mémoires pouvant autoriser à la fois lectures et écritures par centaines de milliers. Les cartes Java, cartes à puce particulières, permettent même l'importation de programmes exécutables (appelés applets , acronyme de l'anglais) dans leur mémoire non volatile selon les besoins du détenteur de la carte. En outre, les cartes Java de dernière génération embarquent un éditeur de lien ( linker ), un module de chargement ( loader ), une machine virtuelle Java, des modules d'appels de méthode à distance ( remote method invocation module en anglais), un vérificateur d'applet ( bytecode verifier ), un pare-feu pour applications Java résidentes ( applet firewall ), un ramasse-miettes ( garbage collector ), des librairies cryptographiques, des gestionnaires complexes de pile, etc. Finalement, une carte à puce comprend un port de communication pour l'échange de données et d'information de contrôle avec le monde externe. Un taux de communication classique est de 9,600 bits par seconde, mais des taux beaucoup plus rapides compatibles avec la norme définie par l'ISO ( International Organization for Standardization ) sont généralement employés (de 19,200 jusqu'à 115,200 bits par seconde). L'apparition du protocole USB dans le monde de la carte à puce ouvre de nouveaux horizons et permet facilement d'atteindre des débits de l'ordre du mégabit par seconde. Dans ce contexte, il devient tentant d'extraire la mémoire ROM du modèle de fonctionnement de la carte à puce, et de s'appuyer sur un protocole de communication ultra-rapide pour transmettre lorsque nécessaire les programmes qu'elle contenait auparavant.

D'un autre côté, faire exécuter par un dispositif mobile un programme exécutable transmis par un terminal potentiellement non-sûr et malveillant pose d'importants problèmes de sécurité. Le problème essentiel d'une telle approche réside dans la présence de clés cryptographiques stockées dans la mémoire du dispositif lui-même. Un programme malveillant (distinct par voie de conséquence des programmes s'exécutant légitimement sur le dispositif) pourrait en effet tenter de révéler ou modifier la valeur desdites clés, invalidant ainsi totalement la sécurité des applications les utilisant pour fonctionner.

L'invention que nous allons décrire permet de répondre très efficacement à cette problématique avec l'aide de fonctions de cryptographie symétrique (dite aussi cryptographie à clé secrète) classiques et efficaces: une fonction de MAC (selon l'acronyme anglais Message Authentification code ) et quelques fonctions de hachage, traduction du terme anglais hashing provenant du verbe to hash .

Ces fonctions de hachage seront notées HASH1, HASH2 et HASH3 dans le brevet. Conformément à l'état de l'art, ces fonctions sont définies par une fonction dite de compression. Par définition, on dit que HASH est une fonction de hachage définie par une fonction de compression H et par une constante IV (de l'anglais initialization vector ), lorsque la définition suivante s'applique: HASH(a1,a2,...,ak)= H(HASH(alr...,ak-1), ak) avec le cas particulier suivant: HASH(a1)= H(IV,al) les nombres entiers a1, a2, ..., ak désignant ici les arguments de la fonction de hachage.

Dans ce document, nous utilisons donc les fonctions de 20 hachage HASH1, HASH2 et HASH3 qui sont respectivement définies par (H1, IV1) , (H2r IV2) et (H3, IV3) . Ainsi, le résultat d'un hachage se calcule itérativement à l'aide d'une boucle et plusieurs appels à la fonction de compression déterminant le hachage. De telles fonctions de hachage sont très classiques en cryptographie: citons par exemple les fonctions de hachage SHA et MD5 dont les spécifications reposent sur la description donnée cidessus.

La présente invention sera plus facilement comprise à 30 l'aide des figures jointes.

La Figure 1 décrit la sémantique dynamique d'un exemple de jeu d'instructions appelé XJVML permettant d'illustrer de façon non limitative les différents modes de réalisation de l'invention.

La Figure 2 décrit le procédé naïf de l'état de l'art permettant, de façon non sûre, d'exécuter un programme P fournit par le monde extérieur au X4P.

La Figure 3 décrit une politique de sécurité en XJVML selon l'invention, autorisant la lecture et l'écriture de données dites publiques.

La Figure 4 décrit une politique de sécurité en XJVML 10 selon l'invention, autorisant uniquement la lecture de données dites publiques.

La Figure 5 explique la gestion de la politique de sécurité au cours de l'exécution du programme P. Dans la suite du texte, nous verrons un programme 15 donné P défini sur un jeu d'instruction (ou langage de programmation) comme une suite ordonnée d'instructions: 1: INS1 2: INS2 3 F: INSF, ces instructions étant positionnées à des adresses appartenant à l'ensemble {1,...,F}, F désignant le nombre d'instructions du programme P. Nous définissons également, à titre d'exemple illustratif non limitatif, un jeu d'instruction appelé XJVML qui servira à illustrer les modes de réalisation de l'invention.

XJVML décrit une architecture simpliste basée sur le processeur virtuel JVMLO défini dans le document de R. Stata et M. Abadi intitulé en langue anglaise A type System for java Bytecode Subroutines publié dans le document référencé SRC Research Report 158 le 11/06/1998 disponible à l'adresse électronique suivante: http://www.research.digital.comJSRC/.

L'architecture sur laquelle opère XJVML est semblable au modèle de calcul connu de l'homme de l'art comme étant celui de von Neumann, à ceci près qu'elle ne contient pas de mémoire programme. L'architecture de XJVML comporte: - une mémoire volatile appelée RAM, - une mémoire non volatile appelée NVM, - un générateur de nombre aléatoire appelé RNG, une pile d'opérande appelée ST, - un port de communication (dit aussi d'entrée/ sortie) appelé I0.

Le jeu d'instructions de XJVML est défini par les 15 instructions suivantes, où x dénote une donnée immédiate, L est l'adresse d'une instruction avec 1 <_ L F et F est le nombre d'instruction du programme considéré : É L'instruction inc' incrémente la donnée se trouvant sur le sommet de la pile. L'instruction pop' retire l'élément de pile se trouvant à son sommet: on utilisera le vocable dépiler . L'instruction push0' ajoute la donnée constante 0 au-dessus de l'élément se trouvant au sommet de la pile: on utilisera le vocable empiler .

É L'instruction load x' empile la donnée se trouvant à l'adresse x en RAM. L'instruction store x' dépile la donnée au sommet de la pile 30 et la recopie à l'adresse x en RAM.

L'instruction load I0' capture la donnée présentée sur le port de communication et 25 l'empile tandis que l'instruction store I0' dépile la donnée supérieure de la pile et la recopie sur le port I0. L'instruction load RNG' produit un nombre aléatoire et l'empile. L'instruction store RNG' n'existe pas.

É L'instruction if L' observe la donnée au sommet de la pile et initialise le compteur de programme à L si cette donnée n'est pas nulle.

É L'instruction hait' arrête l'exécution du programme.

É L'instruction getstatic x' empile la donnée stockée en NVM à l'adresse x et l'instruction putstatic x' dépile la donnée supérieure de la pile et la stocke dans la mémoire non volatile à l'adresse x.

É L'instruction xor' dépile les deux données supérieures de la pile, calcule le XOR (OU EXCLUSIF) de ces données et empile le résultat. L'effet de l'instruction dec' est l'exact opposé de celui de l'instruction c'est à dire que la donnée supérieure est décrémentée de 1. L'instruction mul' dépile les deux données supérieures, les multiplie et empile les deux données représentant le résultat sous forme de deux mots, l'un de poids fort, l'autre de poids faible. L'instruction goto L' est un simple saut à l'adresse de programme L. Enfin, l'instruction div' dépile les deux données supérieures, divise la moins haute de ces deux données (le numérateur) par la donnée la plus haute dans la pile (le dénominateur) , et empile la donnée résultant de l'évaluation du quotient. Il est à noter que si, pour l'instruction le dénominateur est nul, une exception est exécutée, et le compteur de programme est réinitialisé à l'adresse du début de l'exception, adresse appelée AdExcDiv par la suite. Cette exception est appelée l'exception division par zéro .

La sémantique dynamique de notre jeu d'instructions est schématisée à la Figure 1 (à noter qu'il n'y a aucune règle pour l'instruction hait'. Dans la Figure 1, undef désigne la donnée par défaut d'une cellule de la mémoire.

Il est implicite que les instructions qui utilisent la pile provoquent une interruption si la pile est vide, c'est à dire, en dénotant par s le nombre d'éléments de la pile, si s = 0, ou bien si elle contient insuffisamment de données, par exemple lors de l'exécution d'une instruction xor' alors que s = 1.

On rappelle que le terme X P désigne le dispositif soumis au procédé de l'invention, c'est à dire un dispositif électronique dépourvu de mémoire programme, et que similairement, le terme XT désigne l' Externalized Terminal , c'est à dire le terminal qui communique avec le X P et contient le programme P que celui-ci exécute.

On rappelle aussi que le programme P introduit dans chaque terminal XT (que l'on rappelle être non sûr et possiblement malveillant) se présente sous la forme d'une suite d'instructions: 1: INS1 2 INS2 F: INSF Le principe de l'échange entre le XJI,P et le XT est très simple: lorsque l'exécution commence, le X P initialise à 1 son compteur de programme, référencé ci-dessous par la variable i, et demande l'instruction d'adresse i au XT. Le X P exécute INSi, mettant ainsi à jour son état interne et déterminant par conséquent la nouvelle valeur du compteur de programme. Le compteur de programme i et l'adresse de INSi se confondent lors de l'exécution du programme. Ainsi, lors de l'exécution du programme, i désignera de façon égale l'adresse comme le compteur de programme. Ce procédé est répété tant que l'instruction de fin de programme n'est pas atteinte.

A titre d'illustration, le protocole naïf (simple et non sûr) d'échange entre le XT et le X P s'écrit comme 15 mentionné en Figure 2 (en se rappelant qu'exécuter INSi met à jour i).

Ainsi qu'il apparaît clairement, ce procédé simple est sujet à de nombreuses attaques. Typiquement, un attaquant peut retrouver la valeur d'une clé secrète stockée dans la mémoire du X P, avec l'aide du programme XJVML suivant: 1 getstatic 1 2 store IO 3 getstatic 2 4 store IO getstatic 3 6 store IO Un attaquant pourrait également, par exemple, modifier le montant d'un porte-monnaie électronique en sa faveur.

Nous proposons donc plusieurs modes de réalisation de l'authentification du programme P qui est transmis au X P.

De manière générale, l'invention concerne un procédé de sécurisation d'un objet portable électronique X P exécutant un programme P fourni par un autre objet électronique non sûr XT, caractérisé en ce qu'il utilise: - un protocole à clé secrète; - une clé secrète éphémère K; - une fonction de MAC K; - une fonction de hachage HASH1 définie par une fonction de compression H1 et une constante IV1; - une fonction de hachage HASH2 définie par une fonction de compression H2 et une constante IV2; - un identifiant de programme ID stocké dans l'objet électronique X P et valant un hachage de P. Dans une première partie de l'invention, ce procédé de sécurisation d'un objet portable électronique est caractérisé en ce que le programme P est fourni sous la forme d'une suite de F instructions, F dénotant ainsi le nombre d'instructions de ce programme P. Dans cette première partie de l'invention, la valeur de ID, qui correspond au hachage du programme P, se calcule en hachant, une à une, les instructions, dans l'ordre croissant des adresses.

De façon plus précise, la première partie de 30 l'invention est caractérisée en ce que ledit protocole comporte les phases suivantes: a) une phase d'initialisation durant laquelle le Xe génère une clé éphémère K, puis reçoit du XT l'ensemble du programme P, le nombre d'instructions F et son identifiant ID, calcule le haché h de ce programme P avec la fonction HASH1, en utilisant la fonction de compression H1 et la constante IV1r et enfin génère des signatures 6, à l'aide de la fonction K et de la clé K, signatures u, qu'il transmet au XT; b) une phase d'exécution durant laquelle le XpP vérifie l'égalité entre les valeurs de h et de ID, vérifie également que ID est stocké dans sa mémoire non volatile, puis demande, l'une après l'autre, les instructions de P pour les exécuter, et pour certaines d'entre elles, effectue une sous-phase de vérification qui consiste à demander une signature a, construite à partir des signatures a, générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et à vérifier cette signature a; c) une phase de réaction qui se déroule dès qu'une signature a est non valable, et qui consiste pour le Xe à prendre les mesures nécessaires contre le XT frauduleux.

Cette première partie de l'invention se décline alors en plusieurs modes, appelés premier, deuxième et troisième modes de réalisation de l'invention.

Dans le premier mode de réalisation, le procédé de sécurisation d'un objet portable électronique est caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature a se déroulant avant l'exécution de chaque instruction.

i 2867929 De façon plus précise, ce premier mode de réalisation est caractérisé en ce que la phase d'exécution comporte les sous-phases suivantes: b-1) le X P demande une instruction au XT; b-2) le X P demande une signature a construite à partir des signatures 6i générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et, en cas de non-validité de cette signature a, exécute la phase de réaction; b-3) le X P exécute l'instruction et retourne à la sous-phase b-l.

Ainsi, de façon préférentielle, sécurisation d'un objet portable l'invention est caractérisé en ce protocole à clé secrète comprenant les -2. Le X,uP génère une clé aléatoire de XT l'identifiant ID du programme, le F qu'il contient et initialise h ± IV -1. Pour i--1 à F Le X,uP demande au XT l'instruction numéro i (b) Le XT envoie l'instruction I1VSi au X,uP (c) Le X,uP calcule la signature 6; F-,uK (ID,i,INS,) et met à jour h <- Hl(h,INS1) (d) Le X,UP envoie 6i au XT (aucune copie de 61 n'est gardée dans le X,UP) (e) Le XT enregistre 6i O. Le X,UP vérifie que h =ID, que ID est présent en mémoire non volatile (en cas d'échec aller à l'étape 7) et initialise if-1 1. Le X,uP initialise v E- IV2 (a) le premier mode de électronique selon qu'il utilise un étapes suivantes.

session K, demande au nombre d'instructions 2. Le XT initialise 0'<--IV2 3. Le X,CLP demande au XT l'instruction numéro 1 4. Le XT (a) met à jour 6 - H2(0-, ) (b) envoie EN-Si au Xe 5. Le X P met à jour v4-H2(v,,uK(ID,i,INS;)) 6. Le X,uP (a) demande 6 au XT et vérifie que 6 = V; en cas d'échec, aller à l'étape 7 (b) exécute INS; (c) retourne à l'étape 1 7. Le X,uP sait que le programme fourni est un programme non authentique, et prend donc toutes les mesures nécessaires défensives de protection.

Dans le précédent paragraphe, IV1 et IV2 désignent les vecteurs initiaux des fonctions de hachage HASH1 et HASH2; i est toujours la valeur représentant le compteur de programme; o désigne la signature de l'instruction INSi. 20 On rappelle que l'exécution de INSi modifie la valeur de i.

Les lettres h, v et a désignent des variables du protocole dont l'utilisation est expliquée dans ce qui suit.

Le protocole ci-dessus comprend différentes étapes. Nous avons noté par (2) et (-1) les étapes dites négatives qui se déroulent avant l'exécution du programme P et par (0) à (7) les étapes dites positives qui se déroulent durant l'exécution du programme P. En étape (-2), le X P génère de façon aléatoire une clé K éphémère. Cette génération aléatoire peut se faire à l'aide d'un générateur de nombre aléatoire ( random number generator en anglais) matériel ou à l'aide d'un autre moyen. De plus, la valeur h est initialisée à la valeur initiale IV1.

L'étape (-1) est une boucle sur les adresses de programme i. Elle est constituée de sous étapes.

É Dans la sous étape (-1.a), le X P demande à XT l'instruction d'adresse i É Dans la sous étape (-1.b), le XT envoie au X P l'instruction demandée É Dans la sous étape (-1.c), le X P calcule la signature symétrique (aussi appelée signature ou MAC) 6i de l'instruction. De plus, le X P accumule le hachage du programme dans la valeur h au moyen de la fonction de compression H1.

É Dans la sous étape (-1.d), le MAC 6i est envoyé par le X P au XT.

É Enfin, dans la sous étape (-1.e), le MAC ai reçu du X P est stocké par le XT.

Se déroulent par la suite les étapes ayant lieu pendant l'exécution du programme P. A l'étape (0), le X P vérifie que la valeur finale de h (calculée durant la boucle de l'étape (-1)) est égale à la valeur ID, stockée dans sa mémoire non volatile. Grâce à la propriété de noncollision de la fonction de hachage, le X P est ainsi sûr que le programme pour lequel il a calculé la séquence des MACs 6i pendant les étapes négatives est effectivement autorisé à l'exécution. De plus, pendant l'étape (0), le compteur de programme i est initialisé à 1. Si la valeur de h diffère de celle de ID, le programme envoyé n'est pas authentique, et la section (7) est exécutée: le X P prend alors les mesures adéquates contre l'agression supposée (par exemple, le X P efface sa mémoire).

Les étapes (1), (2), (3), (4), (5), (6) sont alors répétées un certain nombre de fois, jusqu'à ce que l'instruction finale soit exécutée. Ce procédé de boucle est expliqué dans ce qui suit.

En étape (1), le X P initialise la variable v à IV2. En étape (2), le XT initialise la variable 6 à IV2.

A l'étape (3), le X P demande au XT l'instruction 10 d'adresse i.

A l'étape (4), le XT remet à jour la variable a et envoie au X P l'instruction demandée.

A l'étape (5), le XgP remet à jour la variable v. L'étape (6) est l'étape critique pour la sécurité. 15 Les sous-étapes (6.a), (6.b) et (6.c) sont effectuées. La sous-étape (6.a) est une sous-étape durant laquelle le X P demande au XT de lui envoyer la signature collective 6. Le X P fait alors la comparaison avec la valeur v qu'il a calculée auparavant. Si ces valeurs diffèrent, le programme P reçu n'est pas authentique et l'étape (7) est alors exécutée: le X P prend alors les mesures appropriées contre cette agression. Si ces valeurs sont égales, le X P continue l'exécution du protocole en exécutant l'instruction reçue et en retournant à l'étape (1).

Ainsi, dans les étapes négatives, le X P signe lui-même le programme qui lui est envoyé avec l'aide d'une clé éphémère K, tout en vérifiant que celui ci est correct en comparant le hachage du programme qui lui est envoyé à l'identifiant qu'il contient dans sa mémoire (ID). Dans les étapes positives, il ne reste alors plus qu'à comparer, pour chaque instruction, la signature fournie par le XT à celle que le X P recalcule.

Il est ainsi impossible pour le XT d'envoyer une instruction étrangère: il n'a pu faire signer à l'étape (- 1) un programme autre que celui d'identifiant ID sans être détecté à l'étape (0), du fait de la propriété de non- collision de la fonction de hachage. Par suite, durant l'exécution des étapes positives, le XT ne peut qu'envoyer des instructions signées par le X P au cours de l'exécution des étapes négatives, c'est à dire les instructions correspondant effectivement au programme; dans le cas contraire, si le XT essaie d'envoyer des instructions différentes, il ne pourra envoyer la signature correcte lors de la vérification car il ne peut calculer par lui- même les signatures d'autres instructions du fait qu'il ne connaît pas la clé de signature K. Cette solution est sûre, mais peut être sujette à améliorations.

Le premier mode fait l'objet d'une amélioration qui 20 est un deuxième mode de réalisation de vérification dynamique du programme P qui est envoyé au X P. Dans ce deuxième mode de réalisation, seules certaines instructions déclenchent une vérification de la signature collective a. Pour cela, nous répertorions dans une liste les instructions qui émettent vers l'extérieur du X P de l'information relative aux données utilisées lors de leur exécution dans le X P (par exemple les instructions du commandement du port d'entrée-sortie). Ensuite, on ajoute à cette liste d'instructions les instructions qui susceptibles de modifier l'état de la mémoire non volatile du dispositif. Toutes ces instructions sont appelées critiques pour la sécurité dans les sections suivantes et l'ensemble des instructions critiques pour la sécurité est noté S. Reprenant l'exemple illustratif du langage élémentaire XJVML, nous répertorions ainsi les instructions qui ont, pour certaines valeurs de leurs entrées, un comportement spécial, reconnaissable de l'extérieur. Une instruction est alors appelée "traçable" si la valeur des données utilisées par l'instruction peut influencer la valeur d'une variable physiquement observable (par exemple le compteur de programme). Les instructions if L' et div' sont donc traçables en raison de leur influence sur le compteur de programme (l'instruction div' pouvant provoquer une interruption en cas de nullité du dénominateur). L'inverse de cette notion est celui d' "indistinguabilité en données" qui caractérise les instructions pour lesquelles les données utilisées n'ont aucune influence sur les variables environnementales. Par exemple, l'exécution de l'instruction xor' ne révèle pas d'information sur les deux éléments du haut de la pile qui pourrait être observée de l'extérieur du X P.

Comme l'exécution d'instructions traçables peut révéler de l'information sur des valeurs internes du programme, ces instructions sont par définition critiques pour la sécurité et nous les incluons donc dans S. Par exemple, dans notre jeu d'instruction illustratif XJVML, seules les instructions if L' et div' sont traçables et l'ensemble S est donc défini comme ci-dessous: S = {putstatic x, store I0, if L, div} L'instruction store I0' est dans S car elle pourrait déclencher l'émission d'un signal électrique à l'extérieur (par le port d'entrée-sortie). L'instruction putstatic x' est également dans S car elle peut effectuer une modification de la mémoire non volatile.

Ainsi, pour un jeu d'instructions donné, la classification des instructions permettant de définir S nous conduit donc au deuxième mode de réalisation de l'invention tel que décrit dans la section suivante.

Dans ce deuxième mode de réalisation de l'invention, le procédé de sécurisation d'un objet portable électronique est caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature a se déroulant avant l'exécution de l'instruction, si celle-ci est une instruction critique pour la sécurité.

De façon plus précise, dans ce second mode, le procédé de sécurisation d'un objet portable électronique est caractérisé en ce que la phase d'exécution comporte les sous-phases suivantes: b-1) le XN,P demande une instruction au XT; b-2) si cette instruction est critique pour la sécurité, alors le XiP demande une signature a construite à partir des signatures o générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et, en cas de non-validité de cette signature a, exécute la phase de réaction; b-3) le Xe exécute l'instruction et retourne à la sous-phase b-1.

De façon préférentielle, toujours dans ce second mode, le procédé de sécurisation d'un objet portable électronique est caractérisé en ce qu'il utilise un ensemble d'instructions critiques pour la sécurité S et en ce que le protocole comprend les étapes suivantes: Le X,UP génère une clé aléatoire de session K, demande au XT l'identifiant ID du programme, le nombre d'instructions F qu'il contient et initialise h '- IV Pour i-1 à F (a) Le X/IP demande au XT l'instruction numéro i (b) Le XT envoie l'instruction INS; au X,uP (c) Le X,1P calcule la signature 6; -,UK (ID,i,INS;) et met à jour h F- HI (h, INS; ) (d) Le Xe envoie 6i au XT (aucune copie de 6; n'est gardée dans le X,uP) (e) Le XT enregistre 6; Le X,eP vérifie que h =ID, que ID est présent en mémoire non volatile (en cas d'échec aller à l'étape 8) et initialise if-1 1. Le X,pP initialise v FIV2 2. Le XT initialise 6 E- IV2 3. Le Xi& demande au XT l'instruction numéro i 4. Le XT (a) met à jour CF <--H2(0-,0-1) (b) envoie INS; au X,uP 5. Le X,uP met à jour v F-- H2 (v uK (ID, i, INS; )) 6. si INS; E S, le X,uP (a) demande 6 au XT et vérifie que 6 = V; en cas d'échec, aller à l'étape 8 (b) exécute INS; (c) retourne à l'étape 1 7. Sinon, le X,uP (a) exécute INS; (b) retourne à l'étape 3 8. Le X,uP sait que le programme fourni est un programme non authentique, et prend donc toutes les mesures nécessaires -2. -1. O. authentique, et prend donc toutes les mesures nécessaires défensives de

protection Dans le précédent paragraphe, IV1 et IV2 désignent 5 les vecteurs initiaux des fonctions de hachage HASH1 et HASH2; i dénote toujours la valeur représentant le compteur de programme; o désigne la signature de l'instruction INSi. On rappelle que l'exécution de INSi modifie la valeur de i. Les lettres h, v et a désignent des variables du 10 protocole dont l'utilisation est expliquée dans ce qui suit.

Le protocole se compose de différentes étapes. Nous avons noté par (-2) et (-1) les étapes dites négatives qui se déroulent avant l'exécution du programme P et par (0) à (8) les étapes dites positives qui se déroulent durant l'exécution du programme P. En étape (-2), le X P génère de façon aléatoire une clé K éphémère. Cette génération aléatoire peut se faire à l'aide d'un générateur de nombre aléatoire ( random number generator en anglais) matériel ou à l'aide d'un autre moyen. De plus, la valeur h est initialisée à la valeur initiale IV.

É Dans la sous étape (-1.a), le X P demande à XT l'instruction d'adresse i É Dans la sous étape (-1.b), le XT envoie au X P l'instruction demandée É Dans la sous étape (-l.c), le X P calcule la 30 signature symétrique (aussi appelée signature ou MAC) 6i de l'instruction. De plus, le X P accumule le hachage du programme dans la valeur h au moyen de la fonction de compression H1.

É Dans la sous étape (-1.d), le MAC a, est envoyé par le XiP au XT.

É Enfin, dans la sous étape (-l.e), le MAC 6i reçu du X P est stocké par le XT.

Se déroulent par la suite les étapes ayant lieu pendant l'exécution du programme P. A l'étape (0), le X P vérifie que la valeur finale de h calculée durant la boucle de l'étape (-1) est égale à la l'identifiant ID, stocké dans sa mémoire non volatile.

Grâce à la propriété de non-collision de la fonction de hachage, le X P est ainsi certain que le programme pour lequel il a calculé la séquence des MACs 6i pendant les étapes négatives est effectivement autorisé à l'exécution.

De plus, pendant l'étape (0), le compteur de programme i est initialisé à 1. Si la valeur de h diffère de celle de ID, le programme envoyé n'est pas authentique, et la section (8) est exécutée: le X P prend alors les mesures adéquates contre l'agression supposée (par exemple, le X P efface sa mémoire).

Les étapes (1), (2), (3), (4), (5), (6), (7) sont alors répétées un certain nombre de fois, jusqu'à ce que l'instruction finale soit exécutée. Ce procédé de boucle est expliqué dans ce qui suit.

En étape (1), le X P initialise la variable v à IV2. En étape (2), le XT initialise la variable a à IV2.

A l'étape (3), le X P demande au XT l'instruction d'adresse i.

A l'étape (5), le X P remet à jour la variable v. L'étape (6) est l'étape critique pour la sécurité. Celle ci commence d'abord par un test.

É Si l'instruction reçue INSi est dans l'ensemble des instructions critiques pour la sécurité S, les sous-étapes (6.a), (6.b) et (6.c) sont effectuées. La sous-étape (6.a) est une sous- étape durant laquelle le X P demande au XT de lui envoyer la signature collective 6. Le X P effectue alors la comparaison avec la valeur v qu'il a calculée auparavant. Si ces valeurs sont différentes, le programme P reçu est un programme non-authentique et l'étape (8) est alors exécutée: le X P prend alors les mesures adéquates contre cette agression (par exemple, le X P ré-initialise sa mémoire). Si ces valeurs sont égales, le X P continue l'exécution du protocole en exécutant l'instruction reçue et en retournant à l'étape (1).

É Si l'instruction reçue INSi n'est pas dans l'ensemble des instructions critiques pour la sécurité S, l'étape (7) est exécutée: le X P exécute simplement INSi et continue d'exécuter le procédé en retournant à l'étape (3).

Ainsi, dans les étapes négatives, le X P signe lui- même le programme qui lui est envoyé (encore une fois avec une clé éphémère), tout en vérifiant que celui ci est authentique en comparant le hachage du programme qui lui est envoyé à l'identifiant de programme qu'il contient dans sa mémoire (ID). Dans les étapes positives, le procédé 15 permet de vérifier collectivement, aux moments opportuns (c'est à dire pour toutes les instructions critiques pour la sécurité, répertoriées dans l'ensemble S), que les signatures fournies par le XT sont identiques à celles que le X P avait calculé dans les étapes négatives.

A l'instar du premier mode de réalisation, il est impossible pour le XT d'envoyer au X P une instruction étrangère au programme: il n'a pu faire signer à l'étape (- 1) un programme différent de celui d'identifiant ID sans être détecté à l'étape (0), du fait de la propriété de non- collision de la fonction de hachage. En conséquence, durant l'exécution des étapes positives, le XT ne peut qu'envoyer des instructions signées par le X P au cours de l'exécution des étapes négatives, c'est à dire les instructions correspondant effectivement au programme; dans le cas contraire, si le XT essaie d'envoyer des instructions différentes, il ne pourra envoyer la signature correcte lors de la vérification car il ne peut calculer par lui-même les signatures d'autres instructions du fait qu'il ne connaît pas la clé de signature K. Il est cependant encore possible d'améliorer les performances de l'invention à l'aide d'un troisième mode de réalisation de l'invention.

Dans ce troisième mode de réalisation de l'invention, 25 un niveau de sécurité est associé à chacune des données manipulées par le X P. Il permet de distinguer une donnée secrète (par exemple une clé cryptographique stockée en mémoire non volatile) d'une donnée publique (connue ou pouvant être recalculée à partir de données connues). Par concision, nous dénotons par c l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné. Il existe plusieurs façon de définir un niveau de sécurité sur une donnée de calcul, mais l'on peut supposer en toute généralité que l'ensemble 0 des niveaux de sécurité est initialisé à certaines valeurs spécifiques avant l'exécution du programme P, et que le fait d'exécuter une instruction de P peut modifier 0 selon des règles arbitrairement choisies par le concepteur du dispositif.

A titre d'exemple illustratif non limitatif, nous décrivons ci-après une réalisation particulière de ce 10 procédé appliqué à l'architecture XJVML définie plus haut.

Le niveau de sécurité est mis en oeuvre sous la forme d'un bit d'information 9 selon la convention que sa valeur vaut zéro lorsque la donnée concernée est publique et un lorsque celle-ci est secrète. Plus spécifiquement, la mise en oeuvre du procédé concerne les cellules mémoires volatiles (RAM), non volatiles (NVM) et les cellules de pile (ST) . Ainsi, on dénote par p(RAM[j]) le bit de sécurité associé au mot mémoire RAM[j], par p(NVM[j]) le bit de sécurité associé à NVM[j] et par p(ST[j]) le bit de sécurité associé à ST[j]. Par convention, les bits de sécurité des cellules NVM sont non volatiles et positionnés à 0 ou 1 par le fabricant du X P à l'étape de production ou de personnalisation, suivant la nature des données non volatiles correspondantes. Ceux de la mémoire RAM sont initialisées à 0 lors du reset du dispositif. Par convention, 9(I0) est laissé constant à 0 et p(RNG) est laissé constant à 1. Enfin, les bits de sécurité des éléments de pile désaffectés sont automatiquement remis à 0.

Nous présentons aussi deux règles élémentaires par lesquelles le bit de sécurité d'une nouvelle variable de programme, c'est-à-dire d'une donnée issue d'un calcul à partir de données précédentes, est établi en fonction de celui desdites données précédentes.

La première règle est que toutes les instructions de transfert (load', getstatic', store' et putstatic') transfèrent également le bit de sécurité de la variable transférée. La seconde règle est appliquée aux instructions arithmétiques et logiques. Elle définit chaque bit de sécurité des variables de sortie de l'instruction concernée comme le OU logique des bits de sécurité de toutes les variables d'entrée de l'instruction. Autrement dit, aussitôt qu'une donnée secrète entre dans le calcul, toutes les données qui en découlent sont répertoriées comme étant secrètes. Cette règle peut notamment mais non uniquement être facilement câblée en hardware comme un simple OU booléen ("OR", dénoté V dans la Figure 5) pour les instructions binaires (c'est à dire avec deux arguments d'entrée). Par souci de clarté, nous fournissons dans la Figure 5 la sémantique dynamique des instructions de XJVML sur O. Etant donné maintenant un jeu d'instruction quelconque, et les règles permettant de définir au cours du temps l'ensemble des niveaux de sécurité (D des données utilisées par l'exécution d'un programme, nous y associons le procédé de l'invention tel que décrit par son second mode de réalisation. Le principe du troisième mode de réalisation repose sur le fait que la vérification collective des instructions émises par le XT, jusqu'alors déclenchée par la détection d'une instruction critique pour la sécurité, peut être épargnée dès lors que cette instruction n'utilise par exemple que des données répertoriées comme publiques. Une vérification de MAC n'est effectivement pas nécessairement invoquée dans ce cas puisque le danger inhérent à l'exécution d'une instruction critique se trouve annulé par le fait que celle-ci ne peut fournir des informations que sur des données préalablement connues ou modifier de telles données.

Par concision, on dénote par Alert(INS,O) la fonction booléenne (c'est-àdire retournant VRAI ou FAUX) qui détermine si l'exécution de l'instruction critique INS occasionne ou non une vérification lorsque le niveau de sécurité des données d'entrée que cette instruction manipule est donné par O. Dans notre exemple de mise en ouvre dans le cadre du langage XJVML, la fonction Alert peut être définie de plusieurs manières différentes ainsi qu'illustré sur les Figures 3 et 4.

Ainsi, nous définissons un troisième mode de réalisation de l'invention, caractérisé en ce que la sous- phase de vérification dans la phase d'exécution est une vérification de la signature a se déroulant avant l'exécution de l'instruction si celle- ci est une instruction critique pour la sécurité, et si l'une au moins des données utilisées par cette instruction est une donnée secrète.

De façon plus précise, dans ce troisième mode, ce procédé de sécurisation d'un objet portable électronique est caractérisé en ce qu'il utilise une variable 0 définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné P et en ce que la phase d'exécution comporte les sous-phases suivantes: b-l) le X P demande une instruction au XT; b-2) si cette instruction est critique pour la sécurité et si l'une au moins des données utilisées par l'instruction est secrète, alors le Xe demande une signature a construite à partir des signatures 6= générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et, en cas de non- validité de cette signature 6, exécute la phase de réaction; b-3) le Xe exécute l'instruction, met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution, et retourne à la sous-phase b-l.

Décliné avec l'utilisation de la fonction booléenne Alert, ce troisième mode de réalisation est caractérisé en ce qu'il utilise une variable d) définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné P, et en ce que la phase d'exécution comporte les sous-phases suivantes: b-l) le Xe demande une instruction au XT; b-2) si cette instruction est critique pour la sécurité et si la fonction booléenne Alert déterminée à partir du niveau de sécurité des données utilisées par l'instruction et par la nature de l'instruction elle-même s'évalue en VRAI, alors le Xi.P demande une signature a construite à partir des signatures a, générées lors de la phase d'initialisation et à l'aide de la fonction HASH2r et, en cas de nonvalidité de cette signature a, exécute la phase de réaction; b-3) le X P exécute l'instruction, met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution, et retourne à la sous-phase b-1.

De façon préférentielle, ce troisième mode de réalisation est caractérisé en ce qu'il utilise un ensemble d'instructions critiques pour la sécurité S et en ce que le protocole comprend les étapes suivantes: -2. Le X,uP génère une clé aléatoire de session K, demande au XT l'identifiant ID du programme, le nombre d'instructions F qu'il contient et initialise hE IV -1. Pour iF-1 à F (a) Le X,uP demande au XT l'instruction numéro i (b) Le XT envoie l'instruction INS1 au X,aP (c) Le X,uP calcule la signature 61 E ,uK (ID,i,INS/) et met à jour hE HI(h,INSi) (d) Le X,eP envoie 61 au XT (aucune copie de O. n'est gardée dans le X,uP) (e) Le XT enregistre 61 O. Le X,uP vérifie que h = ID, que ID est présent en mémoire non volatile (en cas d'échec aller à l'étape 8) et initialise i4 1 1. Le X,UP initialise v+ 1V2 2. Le XT initialise 6 E IV2 3. Le X,uP demande au XT l'instruction numéro i 4. Le XT (a) met à jour 6 E H2(6,6i) (b) envoie INSI au X,uP 5. Le XpP met à jour V±H2 (v, pK (ID, i, INS1)) 6. Si I N S i E S et Alert (INSi, a)) =VRAI, le X,uP (a) demande 6 au XT et vérifie que 6 = v; en cas d'échec, aller à l'étape 8 (b) exécute INSI (c) met à jour c (d) retourne à l'étape 1 (d) retourne à l'étape 1 7. Sinon, le X,uP (a) exécute]NS; (b) met à jour (c) retourne à l'étape 3 8. Le X,UP sait que le programme fourni est un programme non authentique, et prend donc toutes les mesures nécessaires défensives de protection.

Ainsi, par différence avec le protocole décrit dans le second mode de réalisation de l'invention, une vérification de la signature collective à l'étape 6 n'est effectuée que lorsque la fonction Alert s'évalue en VRAI juste avant que l'instruction critique soit exécutée.

En fonction de la mise en oeuvre de ladite fonction, le concepteur de l'architecture obtient ainsi un moyen de vérifier le programme en fonction du contexte, c'est-à-dire en évitant dans le protocole le déclenchement d'une vérification considérée comme inutile au regard du niveau de sécurité des données en jeu.

Dans une deuxième partie de l'invention, le programme est authentifié par groupe d'instructions, et non plus par instructions simples. Les instructions peuvent en effet être regroupées sous la forme de petits blocs appelés sections qui permettent de limiter le nombre de signatures générées et vérifiées par le X,uP.

Suivant la définition classique des documents Advanced Compiler Design and Implementation , de S. Muchnick, publié en 1997 et Compilers: Principles, Techniques, and Tools , de A. Aho, R. Sethi et J. Ullman, publié en 1986, nous appelons bloc de base une suite séquentielle et ordonnée d'instructions, que l'on ne peut exécuter qu'en exécutant la première et la dernière instruction. L'homme de métier décrit habituellement l'ensemble des blocs de base d'un programme P sous la forme d'un graphe CFG(P) (CFG signifiant control flow graph en anglais), calculé par des moyens connus d'analyse de flot de contrôle (expliqués notamment dans les documents Identifying Loops in Almost Linear Time , de G. Ramalingam, publié en 1999, et Advanced Compiler Design and Implementation , de S. Muchnick, publié en 1997). Dans un tel graphe, les n uds sont identifiés aux blocs de base et les arêtes symbolisent les dépendances de flot de contrôle ( control flow dependancies ).

La présence d'une arête Bo -> B1 dans le graphe (on dit alors que B1 est un fils de Bo et Bo un père de B1) signifie que la dernière instruction du bloc Bo peut transférer le contrôle du programme à la première instruction de B1.

Lorsque Bo -> B1r Bo => B1 signifie que Bo n'a aucun autre fils que B1 (mais B1 peut avoir d'autres pères que Bo). Nous définissons maintenant une notion légèrement différente de celle des blocs de base, que nous appelons section de programme.

De manière rigoureuse, une section de programme est une suite maximale de blocs de base Bo => B1 => B2 => ... _> BZ telle que ni l'instruction de fin de programme ('halt' en XJVML) ni aucune instruction de S (instruction critique) n'apparaisse dans les blocs sauf éventuellement comme dernière instruction de B. La section est alors dénotée par s = <Bo, B1,.. B,>. Dans une section de programme, comme dans les blocs de base, le flot de contrôle est déterministe, c'est à dire indépendant de la valeur que les variables de programme sont susceptibles de prendre pendant l'exécution.

Il est connu que le calcul des blocs de base d'un programme peut être fait dans un temps presque linéaire en le nombre d'instruction de ce programme ( Identifying Loops in Almost Linear Time , de G. Ramalingam, publié en 1999) et l'homme de l'art verra facilement que les algorithmes permettant de calculer CFG(P) à partir de P peuvent être modifiés de façon simple pour calculer, de manière également performante, l'ensemble des sections du programme P. Ainsi, les sections de P peuvent être calculées facilement lors la compilation de P. La deuxième partie de l'invention se décline en un quatrième, cinquième et sixième modes de réalisation de l'invention que nous décrivons maintenant. Dans ces modes, les signatures symétriques générées par le XiP authentifient des sections plutôt que des instructions individuelles du programme.

Au contraire des trois premiers modes de réalisation de la première partie de l'invention, dans lesquels le programme était fourni sous forme de suite d'instructions, ces quatrième, cinquième et sixième modes de réalisation de l'invention sont des procédés de sécurisation d'un objet portable électronique caractérisés en ce que le programme P est fourni sous la forme d'une suite de sections ou blocs d'instructions, G dénotant le nombre de sections de ce programme P, et en ce qu'il utilise une troisième fonction de hachage, nommée HASH3r définie par une fonction de compression H3 et une constante IV3.

Dans cette seconde partie de l'invention, la valeur de ID, qui correspond au hachage du programme P, se calcule en hachant, une à une, les sections, dans l'ordre croissant des adresses de ces sections, puis finalement en hachant les hachés des sections dans l'ordre croissant des adresses de départ des sections.

De façon plus précise, la deuxième partie de l'invention est caractérisée en ce que ledit protocole comporte les phases suivantes: a) une phase d'initialisation durant laquelle le XeP génère une clé éphémère K, puis reçoit du XT l'ensemble du programme P, son nombre de sections G et son identifiant ID, calcule le haché h de ce programme P à l'aide de la fonction HASH1, en utilisant la fonction de compression H1 et la constante IV1r et à l'aide de la fonction HASH3, en utilisant la fonction de compression H3 et la constante IV3r et enfin génère des signatures 6J à l'aide de la fonction K et de la clé K, signatures 6j qu'il transmet au XT; b) une phase d'exécution durant laquelle le X P vérifie l'égalité entre les valeurs de h et de ID, vérifie également que ID est stocké dans sa mémoire non volatile, puis demande, l'une après l'autre, les sections de P pour les exécuter, effectue ensuite une sous-phase de vérification de conformité de ces sections, puis finalement, pour l'instruction finale de certaines sections, effectue une sous-phase de vérification qui consiste à demander une signature a, construite à partir des signatures o générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et à la vérifier; c) une phase de réaction qui se déroule dès qu'une signature a est non valable ou qu'une section est non conforme, et qui consiste pour le Xe à prendre les mesures nécessaires contre le XT frauduleux.

Plus précisément, la sous-phase de vérification de conformité d'une section donnée consiste à vérifier qu'aucune instruction de cette section, sauf éventuellement la dernière, n'est une instruction critique pour la sécurité.

Cette deuxième partie de l'invention se décline alors en plusieurs modes, appelés quatrième, cinquième et sixième mode de réalisation de l'invention.

Le quatrième mode de réalisation se caractérise en ce 10 que la sousphase de vérification dans la phase d'exécution est une vérification de la signature a se déroulant avant l'exécution de l'instruction finale de chaque section.

De façon plus précise, ce quatrième mode de réalisation est caractérisé en ce que la phase d'exécution comporte les sous-phases suivantes: b-l) le Xe demande une section au XT; b-2) pour chaque instruction non finale de la section demandée, le Xe vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée: b-31) le Xe demande une signature a construite à 25 partir des signatures cri générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et, en cas de nonvalidité de cette signature a, exécute la phase de réaction; b-32) le Xe exécute l'instruction; b-4) le Xe retourne alors à la sous-phase b-l. 15

De façon préférentielle, le quatrième mode de réalisation de l'invention est caractérisé en ce qu'il utilise un protocole à clé secrète comprenant les étapes suivantes: -2. Le X,eP génère une clé aléatoire de session K, demande au XT l'identifiant ID du programme, le nombre de sections G qu'il contient et initialise hE IV -1. Pour j-1 à G (a) Le X,eP demande au XT la section numéro j, le nombre t d'instructions dans cette section et initialise g - IV3 (b) Pour if-1 à t, le XT envoie l'instruction INS;au),1P qui met à jour g <- H3 (g, INS; ) (c) Le X,eP calcule la signature Cf 4,uK (ID, j, g) de la section et met à jour h F- H1(h, g) (d) Le Xe envoie 6J au XT (aucune copie de 6J n'est gardée dans le X,uP) (e) Le XT enregistre 6J 0. Le X,uP vérifie que h= ID, que ID est présent en mémoire non volatile (en cas d'échec aller à l'étape 9) et initialise j -1 1. Le X/2P initialise V 4-IV2 2. Le XT initialise 6 F- IV2 3. Le X,eP demande au XT la section numéro j, le nombre t d'instructions qui la compose et initialise g4 1V3 et i<--1 4. Le XT met à jour 6 E H2(6,O) et initialise /F-1 5. Le XT envoie ENS, au X,UP et incrémente if--1+1 6. Le X,uP met à jour g H3(g,INS,) 7. Si i<t, alors le X,uP (a) teste si INS;E S, et dans ce cas, aller à l'étape 9 (b) exécute 1NS; (c) retourne à l'étape 5 8. Si i=t, alors le X,uP (a) met à jour V *- H2 (V, JK (ID, j, g)) (b) demande a au XT et vérifie que 6 = V; en cas d'échec, aller à l'étape 9 (c) exécute INS, (d) retourne à l'étape 1 9. Le X,uP sait que le programme fourni est un programme non authentique, et prend donc toutes les mesures nécessaires défensives de protection.

Dans le précédent paragraphe, et dans la suite (pour les cinquièmes et sixième mode de réalisation), la signature d'une section Sj dont la première instruction a pour adresse j et constituée des instructions INS1,

., INSk peut être définie à titre d'exemple par: oi= (ID, j, g) où g désigne g = HASH3(INS1,..., INSk) HASH3 étant ici une fonction de hachage définie par une fonction de compression H3 et un vecteur d'initialisation IV3 conformément à l'état de l'art. Le fait d'employer la définition classique du hachage par itération est indispensable à notre quatrième, cinquième et sixième mode de réalisation...DTD: Le quatrième mode de réalisation se compose lui aussi d'étapes négatives et positives. Nous expliquons brièvement son fonctionnement, celui ci étant très proche des premiers modes de réalisation. Dans l'étape (-2), une clé aléatoire K est générée, l'identifiant ID et le nombre de sections G sont demandés. Puis h est initialisé à IV1. Dans l'étape (- 1), le programme P est signé à l'aide de la clé K et de la fonction de MAC K. Ici, les signatures sont des signatures par section. Les signatures 6j sont générées par le X P et envoyées ensuite au XT, qui les stocke. Dans l'étape (0), le X P vérifie que le programme est correct, en vérifiant que le haché calculé est identique à ID, et que ID est présent dans sa mémoire non volatile. Les étapes (1) et (2) sont des étapes d'initialisation pour le X P et le XT. En étape (3), le X P demande au XT le nombre d'instruction t de la section courante, et initialise g à IV3. Le XT remet quant à lui à jour la variable 6 en étape (4) et initialise i à 1. En étape (5), l'instruction courante de la section courante est envoyée au X P et i est incrémenté. Le X P remet alors à jour g, variable qui lui sert à accumuler le hachage de la section courante. L'étape (6) est celle de la vérification de conformité de la section: le X P y vérifie que toutes les instructions non finales sont non critiques. Il exécute également ces instructions. L'étape (7) est celle qui se déroule pour l'instruction finale de la section: le X P demande alors une signature et en vérifie l'authenticité. En cas de succès, l'instruction est exécutée, et le procédé repart de l'étape 1. Enfin, à tout moment, si une section est non conforme, ou si une signature est fausse, l'étape (9), qui est celle de l'étape de réaction, est exécutée: le X P prend alors les mesures nécessaires de protection.

A la différence des modes de réalisation précédents, chaque section ne peut occasionner au plus qu'une vérification de MAC. On se rappellera en effet qu'une instruction critique pour la sécurité ne peut se trouver qu'en tant que dernière instruction d'une section. Par définition, la dernière instruction INSk d'une section est: É soit une instruction de S. Dans ce cas, son exécution peut déclencher ou non une vérification de signature, selon la politique de sécurité Alert(INS,O) É soit l'instruction de fin de programme ('halt' en XJVML), qui interrompt l'exécution.

Reprenant les idées des deuxième et troisième modes de réalisation, mais appliquées à un programme P donné sous la forme de sections, nous dérivons les cinquièmes et sixièmes modes de réalisation de l'invention.

Le cinquième mode de réalisation de l'invention est un procédé de sécurisation d'un objet portable électronique, du type deuxième partie de l'invention (c'est à dire avec un programme P donné sous la forme de sections), caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature a se déroulant avant l'exécution de l'instruction finale de chaque section, si ladite instruction est une instruction critique pour la sécurité.

Plus précisément, ce cinquième mode est caractérisé en ce que la phase d'exécution comporte les sous-phases suivantes: b-l) le Xe demande une section au XT; b-2) pour chaque instruction non finale de la section demandée, le Xe vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée: b-31) si l'instruction est critique pour la sécurité, le Xedemande une signature a construite à partir des signatures o générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature a, exécute la phase de réaction; b- 32) le Xe exécute l'instruction; b-4) le Xe retourne alors à la sous- phase b-1.

De façon préférentielle, ce cinquième mode est caractérisé en ce qu'il utilise un ensemble d'instructions critiques pour la sécurité S et en ce que le protocole comprend les étapes suivantes: -2. Le XuP génère une clé aléatoire de session K, demande au XT l'identifiant ID du programme, le nombre de sections G qu'il contient et initialise hE IV1 -1. Pour j-1 à G (a) Le X/P demande au XT la section numéro j, le nombre t d'instructions dans cette section et initialise g E IV3 (b) Pour i*-1 à t, le XT envoie l'instruction INS,au X,uP qui met à jour g E H3(g,INS;) (c) Le X,UP calcule la signature c1 E J4 (ID, j,g) de la section et met à jour hEH1(h,g) (d) Le X,eP envoie 6j au XT (aucune copie de 6j n'est gardée dans le X,UP) (e) Le XT enregistre 6 0. Le X,uP vérifie que h = ID, que ID est présent en mémoire non volatile (en cas d'échec aller à l'étape 10) et initialise jE 1 1. Le X,uP initialise v4-1V2 2. Le XT initialise a< 1V2 3. Le X,uP demande au XT la section numéro j, le nombre t d'instructions qui la compose et initialise g - IV3 et i F 1 4. Le XT met à jour o.H2(6,6i) et initialise H 1 5. Le XT envoie INS; au X,uP et incrémente i i +1 6. Le X,UP met à jour g <- H3 (g, INS; ) 7. Si i<t, alors le X/2P (a) teste si INS;E S, et dans ce cas, aller à l'étape 10 (b) exécute ENS; (c) retourne à l'étape 5 8. Si i=t et INS; E S, alors le X,uP ( a) met à jour v F- H2 (v, K (ID, j, g)) (b) demande 6 au XT et vérifie que a = V; en cas d'échec, aller à l'étape 10 (c) exécute INS; (d) retourne à l'étape 1 9. Si i=t et INS; e S, alors le X,uP (a) met à jour v'-H2(v, r(ID, j,g)) (b) exécute INS; (c) retourne à l'étape 3 10. Le X,uP sait que le programme fourni est un programme non authentique, et prend donc toutes les mesures nécessaires défensives de protection.

Ce cinquième mode de réalisation de l'invention est très proche du quatrième, et nous n'allons expliquer ici que les phases différentes de celui ci, c'est à dire les phases 8 et 9. Dans le quatrième mode de réalisation, toutes les instructions finales des sections faisaient l'objet d'une vérification de signature. Ici, en étape (8), on teste l'instruction finale: si elle est critique, on demande une signature. Par contre, si l'instruction finale n'est pas critique, alors, dans l'étape (9), on exécute l'instruction sans demander de signature, et on continue le protocole en retournant à l'étape 3.

Comme on peut le voir, l'avantage est grand: seules certaines instructions finales feront l'objet d'une vérification de signature, et ainsi, le protocole sera d'autant plus rapide.

Mais il est encore possible d'apporter une dernière amélioration au protocole, faisant l'objet du sixième mode de réalisation de l'invention.

Celui ci est un procédé de sécurisation d'un objet portable électronique caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature a se déroulant avant l'exécution de l'instruction finale de chaque section, si ladite instruction est une instruction critique pour la sécurité, et si l'une au moins des données utilisées par cette instruction est une donnée secrète.

Plus précisément, le sixième mode de réalisation de l'invention est un procédé de sécurisation d'un objet portable électronique caractérisé en ce qu'il utilise une variable 4) définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné et en ce que la phase d'exécution comporte les sous-phases suivantes: b-l) le XEtP demande une section au XT; b-2) pour chaque instruction non finale de la section demandée, le X P vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée: b-31) si l'instruction est critique pour la sécurité et si l'une au moins des données utilisées par l'instruction est secrète, le Xe demande une signature 6 construite à partir des signatures 6j générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et, en cas de non- validité de cette signature o, exécute la phase de réaction; b-32) le Xe exécute l'instruction; b-33) le Xe met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution; b-4) le Xe retourne alors à la sous-phase b-1.

Une autre façon de réaliser le sixième mode de 20 réalisation de l'invention est d'utiliser un protocole, caractérisé en ce qu'il utilise une variable 0 définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné, en ce qu'il utilise une fonction booléenne Alert et en ce que la phase d'exécution comporte les sous-phases suivantes: b-1) le Xe demande une instruction au XT; b-2) pour chaque instruction non finale de la section demandée, le Xe vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée: b-31) si l'instruction est critique pour la sécurité et si la fonction booléenne Alert déterminée à partir du niveau de sécurité des données utilisées par l'instruction et par la nature de l'instruction elle-même s'évalue en VRAI, le Xe demande une signature construite à partir des signatures 6j générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et, en cas de non-validité de cette signature a, exécute la phase de réaction; b-32) le Xe exécute l'instruction; b-33) le XN,P met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution; b-4) le Xe retourne alors à la sous-phase b-1.

Ainsi, de manière préférentielle, le sixième mode de réalisation de l'invention est caractérisé en ce qu'il utilise un ensemble d'instructions critiques pour la sécurité S, et en ce qu'il comprend les étapes suivantes: -2. Le X/1P génère une clé aléatoire de session K, demande au XT l'identifiant ID du programme, le nombre de sections G qu'il contient et initialise h - IVi -1. Pour j<-1 à G (a) Le),1P demande au XT la section numéro j, le nombre t d'instructions dans cette section et initialise g--IV3 (b) Pour if 1 à t, le XT envoie l'instruction INS;au X,uP qui met à jour g -H3(g,INS,) (c) Le X,uP calcule la signature o < ,uK (ID, j, g) de la section et met à jour h (h,g) (d) Le X,UP envoie 6j au XT (aucune copie de 6i n'est gardée dans le X,uP) (e) Le XT enregistre 6j O. Le X,uP vérifie que h = ID, que ID est présent en mémoire non volatile (en cas d'échec aller à l'étape 10) et initialise j -1 1. Le X,uP initialise VIT/2 2. Le XT initialise 6 F IV2 3. Le X,UP demande au XT la section numéro j, le nombre t d'instructions qui la compose et initialise g IV3 et /4 1 4. Le XT met à jour 6 4- H2(6,61) et initialise i<--1 5. Le XT envoie INSi au X jLP et incrémente i - i +1 6. Le X,UP met à jour g-H3(g,INS,) 7. Si i<t, alors le X,LIP (a) teste si INS;ES, et dans ce cas, aller à l'étape 10 (b) exécute INSi (c) met à jour (d) retourne à l'étape 5 8. Si i=t et I N S; E S et Alert ( INS;, (D) =VRAI, alors le X/4P (a) met à jour v 4 H2(v,jK(ID, j,g)) (b) demande 6 au XT et vérifie que 6 = V; en cas d'échec, aller à l'étape 10 (c) exécute Mi (d) met à jour (e) retourne à l'étape 1 9. Si i=t et ( I N S, e S ou Alert ( INS;, ) =FAUX) , alors le X4uP (a) met à jour v<-H2(v /K(ID, j,g)) (b) exécute INSi (c) met à jour 44 (d) retourne à l'étape 3 10. Le X,iP sait que le programme fourni est un programme non authentique, et prend donc toutes les mesures nécessaires défensives de protection.

La différence de ce dernier mode de réalisation avec le cinquième mode de réalisation est minime, et est expliquée dans ce qui suit: en étape (8), on ne teste pas seulement si l'instruction finale est critique pour la sécurité, mais aussi si une des données d'entrée de l'instruction est secrète (ceci nous est donné par la condition Alert(INS=,D)=VRAI). Si ces deux conditions sont réunies, une vérification de signature est enclenchée, l'instruction est ensuite exécutée, et le protocole redémarre de l'étape (1). Par contre, dans le cas contraire, l'instruction est exécutée sans déclencher de vérification de signature, et le protocole redémarre de l'étape (3).

Comme pourra le voir l'homme de l'art, le dernier protocole minimise au maximum le nombre de signatures demandées au XT, tout en garantissant la sécurité du Xe.

Dans le deuxième ou troisième modes de la première partie de l'invention, et dans le quatrième, cinquième ou sixième mode de la deuxième partie de l'invention, le procédé est caractérisé en ce qu'au moins un des types suivants d'instructions sont critiques pour la sécurité : les instructions de test et/ou les instructions émettant de l'information vers l'extérieur par un moyen de communication et/ou - les instructions modifiant le contenu de la mémoire non-volatile et/ou - les instructions de calcul présentant des cas particuliers lors de leur exécution, tels que le lancement d'exceptions.

De plus, les troisième et sixième modes sont préférentiellement caractérisés en ce que la fonction booléenne Alert s'évalue en VRAI pour au moins un des types suivants d'instructions: - les instructions de test et/ou - les instructions émettant de l'information vers 10 l'extérieur par un moyen de communication et/ou - les instructions modifiant le contenu de la mémoire non-volatile et/ou - les instructions de calcul présentant des cas particuliers lors de leur exécution, tels que le 15 lancement d'exceptions.

Dans une solution encore plus efficace, les troisième et sixième modes sont caractérisés en ce que la fonction booléenne Alert s'évalue en VRAI pour au moins un des types suivants d'instructions, si au moins une des données d'entrée est secrète, et FAUX si toutes les données testées sont publiques: - les instructions de test et/ou - les instructions émettant de l'information vers 25 l'extérieur par un moyen de communication et/ou les instructions modifiant le contenu de la mémoire non-volatile et/ou les instructions de calcul présentant des cas particuliers lors de leur exécution, tels que le 30 lancement d'exceptions.

Pour les troisième et sixième modes, l'ensemble des niveaux de sécurité 0 utilisé lors de l'exécution d'un programme P est préférentiellement indiqué par la valeur d'une fonction cp, telle que, pour toute donnée u utilisée 5 par le programme, cp(u)=0 désigne le fait que u est publique et cp(u)=l désigne le fait que u est privée, et telle que, pour toute donnée v résultant de l'exécution d'une instruction du programme P, cp(v) =1 si au moins une des données d'entrée de l'instruction est privé, et, sinon, cp(v)=O.

Plus précisément, les valeurs de la fonction cf) sont calculées au moyen d'une mise en oeuvre matérielle d'une fonction OU logique réalisée sur les valeurs de la fonction cp pour les données d'entrée des instructions.

Enfin, par souci de simplicité et de pratique, les fonctions de hachage HASH1, HASH2 et HASH3 peuvent être identiques.

La présente invention s'applique à un objet électronique caractérisé en ce qu'il met en oeuvre l'ensemble des modes de réalisation de l'invention tels que décrits ci-dessus.

Claims

47 REVENDICATIONS

1. Procédé de sécurisation d'instructions d'un objet portable électronique X P exécutant un programme P fourni par un autre objet électronique non sûr XT sous la forme d'une suite de F instructions, F dénotant ainsi le nombre d'instructions de ce programme P, procédé utilisant - un protocole à clé secrète coopérant avec une clé secrète éphémère K; - une fonction cryptographique symétrique MAC K coopérant avec une fonction de hachage HASH1, définie par une fonction de compression H1 et une constante IV1, et une fonction de hachage HASH2 définie par une fonction de compression H2 et une constante IV2i - un identifiant de programme ID stocké dans l'objet électronique X P et valant un hachage de P, procédé caractérisé en ce que ledit protocole à clé 20 publique comporte les phases suivantes: a) une phase d'initialisation durant laquelle le X P génère une clé éphémère K, puis reçoit du XT l'ensemble du programme P, le nombre d'instructions F et son identifiant ID, calcule le haché h de ce programme P avec la fonction HASH1, en utilisant la fonction de compression H1 et la constante IV1i et enfin génère des signatures 61 à l'aide de la fonction K et de la clé K, signatures o qu'il transmet au XT; b) une phase d'exécution durant laquelle le X P vérifie l'égalité entre les valeurs de h et de ID, vérifie également que ID est stocké dans sa mémoire non volatile, puis demande, l'une après l'autre, les instructions de P pour les exécuter, et pour certaines d'entre elles, effectue une sous-phase de vérification qui consiste à demander une signature a, construite à partir des signatures o générées lors de la phase d'initialisation et à l'aide de la fonction HASH2, et à vérifier cette signature 6; c) une phase de réaction qui se déroule dès qu'une signature a est non valable.

2. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 1 caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature o se déroulant avant l'exécution de chaque instruction.

3. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 2 25 caractérisé en ce qûe la phase d'exécution comporte les sous-phases suivantes b-1) le X P demande une instruction au XT; b-2) le X P demande une signature o construite à partir des signatures o,. générées lors de la 30 phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature a, exécute la phase de réaction; b-3) le X P exécute l'instruction et retourne à la sous-phase b-l.

4. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 1 caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature a se déroulant avant l'exécution de 10 l'instruction, si celleci est une instruction critique pour la sécurité.

Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 4 15 caractérisé en ce que la phase d'exécution comporte les sous-phases suivantes: b-l) le X P demande une instruction au XT; b-2) si cette instruction est critique pour la sécurité, alors le X P demande une signature a 20 construite à partir des signatures 61 générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature a, exécute la phase de réaction; b-3) le X P exécute l'instruction et retourne à 25 la sous- phase b-l.
6 Procédé de sécurisation d'un objet portable électronique selon la revendication 1 caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature a 30 se déroulant avant l'exécution de l'instruction si celle-ci est une instruction critique pour la sécurité, et si l'une au moins des données utilisées par cette instruction est une donnée secrète.

7. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 6 caractérisé en ce qu'il utilise une variable c définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné P et en ce que la phase d'exécution comporte les sous-phases suivantes: b-l) le X P demande une instruction au XT; b-2) si cette instruction est critique pour la sécurité et si l'une au moins des données utilisées par l'instruction est secrète, alors le X P demande une signature a construite à partir des signatures a, générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature a, exécute la phase de réaction; b-3) le X P exécute l'instruction, met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution, et retourne à la sous-phase b-l.

8. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 7 caractérisé en ce qu'il utilise une variable 0 définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné P, en ce qu'il utilise une fonction booléenne Alert et en ce que la phase d'exécution comporte les sous-phases suivantes: b-l) le X P demande une instruction au XT; b-2) si cette instruction est critique pour la sécurité et si la fonction booléenne Alert déterminée à partir du niveau de sécurité des données utilisées par l'instruction et par la nature de l'instruction elle-même s'évalue en VRAI, alors le X P demande une signature a construite à partir des signatures o, générées lors de la phase d'initialisation et à l'aide la 10 fonction HASH2, et, en cas de non-validité de cette signature a, exécute la phase de réaction; b-3) le X P exécute l'instruction, met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution, et retourne à la sous-phase b-1.

9. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 1, caractérisé en ce qu'il utilise une fonction de hachage HASH3 définie par une fonction de compression H3 et une constante IV3, et en ce que le programme P est fourni sous la forme d'une suite de G sections ou blocs d'instructions, G dénotant ainsi le nombre de sections dudit programme.

10. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 9 caractérisé en ce que ledit protocole comporte les phases suivantes.

a) une phase d'initialisation durant laquelle le 30 X P génère une clé éphémère K, puis reçoit du XT l'ensemble du programme P, son nombre de sections G et son identifiant ID, calcule le haché h de ce programme P à l'aide de la fonction HASH1, en utilisant la fonction de compression H1 et la constante IV1, et à l'aide de la fonction HASH3, en utilisant la fonction de compression H3 et la constante IV3, et enfin génère des signatures a. à l'aide de la fonction K et de la clé K, signatures 6J qu'il transmet au XT; b) une phase d'exécution durant laquelle le Xe vérifie l'égalité entre les valeurs de h et de ID, vérifie également que ID est stocké dans sa mémoire non volatile, puis demande, l'une après l'autre, les sections de P pour les exécuter, effectue ensuite une sousphase de vérification de conformité de ces sections, puis finalement, pour l'instruction finale de certaines sections, effectue une sous-phase de vérification qui consiste à demander une signature a, construite à partir des signatures o générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et à la vérifier; c) une phase de réaction qui se déroule dès qu'une signature a est non valable ou qu'une section est non conforme.

11. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 10 caractérisé en ce que la sousphase de vérification de conformité d'une section donnée consiste à vérifier qu'aucune instruction de cette section, 15 25 sauf éventuellement la dernière, n'est une instruction critique pour la sécurité.

12. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 11 caractérisé en ce que la sousphase de vérification dans la phase d'exécution est une vérification de la signature a se déroulant avant l'exécution de l'instruction finale de chaque section.

13. Procédé de sécurisation d'instructions d'un objet É portable électronique selon la revendication 12 caractérisé en ce que la phase d'exécution comporte les sous-phases suivantes: b-l) le X P demande une section au XT; b-2) pour chaque instruction non finale de la section demandée, le X P vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée: b-31) le X P demande une signature construite à partir des signatures a. générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non- validité de cette signature a, exécute la phase de réaction; b-32) le X P exécute l'instruction; b-4) le X P retourne alors à la sous-phase b-l.

14. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 11 20 caractérisé en ce que la sousphase de vérification dans la phase d'exécution est une vérification de la signature a se déroulant avant l'exécution de l'instruction finale de chaque section, si ladite instruction est une instruction critique pour la sécurité.

15. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 14 10 caractérisé en ce que la phase d'exécution comporte les sous-phases suivantes: b-l) le X P demande une section au XT; b-2) pour chaque instruction non finale de la section demandée, le X P vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée.

b-31) si l'instruction est critique pour la sécurité, le X P demande une signature a construite à partir des signatures o générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de nonvalidité de cette signature a, exécute la phase de réaction; b-32) le X P exécute l'instruction; b-4) le X P retourne alors à la sous-phase b-l.

16. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 11 caractérisé en ce que la sousphase de vérification 25 dans la phase d'exécution est une vérification de la signature a se déroulant avant l'exécution de l'instruction finale de chaque section, si ladite instruction est une instruction critique pour la sécurité, et si l'une au moins des données utilisées par cette instruction est une donnée secrète.

17. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 16 caractérisé en ce qu'il utilise une variable définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné et en ce que la phase d'exécution comporte les sous-phases suivantes: b-1) le X P demande une section au XT; b-2) pour chaque instruction non finale de la section demandée, le X P vérifie si cette instruction. est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée b-31) si l'instruction est critique pour la sécurité et si l'une au moins des données utilisées par l'instruction est secrète, le X P demande une signature a construite à partir des signatures 6] générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature a, exécute la phase de réaction; b-32) le X P exécute l'instruction; 25 b-33) le X P met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution; b-4) le X P retourne alors à la sous-phase b-l.

18. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 16 caractérisé en ce qu'il utilise une variable c 10 définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné, en ce qu'il utilise une fonction booléenne Alert et en ce que la phase d'exécution comporte les sous-phases suivantes: b-l) le X P demande une instruction au XT; b-2) pour chaque instruction non finale de la section demandée, le X P vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée: b-31) si l'instruction est critique pour la sécurité et si la fonction booléenne Alert déterminée à partir du niveau de sécurité des données utilisées par l'instruction et par la nature de l'instruction elle-même s'évalue en VRAI, le X P demande une signature a construite à partir des signatures o. générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature 6, exécute la phase de réaction; b-32) le X P exécute l'instruction; b-33) le X P met à jour le niveau de sécurité (donnée secrète ou donnée non secrète) de chacune des données issues de l'exécution; b-4) le X P retourne alors à la sous-phase b-1.

19. Procédé de sécurisation d'instructions d'un objet portable électronique selon l'une quelconque des revendications 4 à 8 ou 11 à 18, caractérisé en ce qu'au moins un des types suivants d'instructions sont critiques pour la sécurité : - les instructions de test et/ou - les instructions émettant de l'information vers l'extérieur par un moyen de communication et/ou - les instructions modifiant le contenu de la mémoire non-volatile et/ou - les instructions de calcul présentant des cas 20 particuliers lors de leur exécution, tels que le lancement d'exceptions.

20. Procédé de sécurisation d'instructions d'un objet portable électronique selon l'une quelconque des 25 revendications 8 ou 18, caractérisé en ce que la fonction booléenne Alert s'évalue en VRAI pour au moins un des types suivants d'instructions: - les instructions de test et/ou - les instructions émettant de l'information vers 30 l'extérieur par un moyen de communication et/ou - les instructions modifiant le contenu de la mémoire non-volatile et/ou - les instructions de calcul présentant des cas particuliers lors de leur exécution, tels que le lancement d'exceptions.

21. Procédé de sécurisation d'instructions d'un objet portable électronique selon l'une quelconque des revendications 8 ou 18, caractérisé en ce que la fonction booléenne Alert s'évalue en VRAI pour au moins un des types suivants d'instructions, si au moins une des données d'entrée est secrète, et FAUX si toutes les données testées sont publiques: - les instructions de test et/ou - les instructions émettant de l'information vers l'extérieur par un moyen de communication et/ou les instructions modifiant le contenu de la mémoire non-volatile et/ou les instructions de calcul présentant des cas particuliers lors de leur exécution, tels que le lancement d'exceptions.

22. Procédé de sécurisation d'instructions d'un objet portable électronique selon l'une quelconque des revendications 7 à 8 ou 17 à 18, caractérisé en ce que l'ensemble des niveaux de sécurité cJ utilisé 25 lors de l'exécution d'un programme P est indiqué par la valeur d'une fonction cp, telle que, pour toute donnée u utilisée par le programme, 9(u)=0 désigne le fait que u est publique et 9(u)=l désigne le fait que u est privée, et telle que, pour toute donnée v 30 résultant de l'exécution d'une instruction du programme P, cp(v)=l si au moins une des données d'entrée de l'instruction est privée, et sinon cp (v) =0.

23. Procédé de sécurisation d'instructions d'un objet portable électronique selon la revendication 22, caractérisé en ce que les valeurs de la fonction cp sont calculées au moyen d'une mise en uvre matérielle d'une fonction OU logique réalisée sur les valeurs de la fonction cp pour les données d'entrée des instructions.

24. Procédé de sécurisation d'instructions d'un objet portable électronique selon l'une quelconque des revendications 1 à 23, caractérisé en ce que les fonctions de hachage HASH1, HASH2 et HASH3 sont identiques.

25. Objet électronique caractérisé en ce qu'il met en uvre l'une quelconque des revendications 1 à 24.

construite à partir des signatures 61 générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de nonvalidité de cette signature 6, exécute la phase de réaction; b-32) le Xe exécute l'instruction; b-4) le Xe retourne alors à la sous-phase b-1.

22. Procédé de sécurisation d'un objet portable électronique selon la revendication 21 caractérisé en ce qu'il utilise un ensemble d'instructions critiques pour la sécurité S et en ce que le protocole comprend les étapes suivantes: - 2. Le X,eP génère une clé aléatoire de session K, demande au XT l'identifiant ID du programme, le nombre de sections G qu'il contient et initialise h - IV1 - 1. Pour j-1 à G (a) Le X/2P demande au XT la section numéro j, le nombre t d'instructions dans cette section et initialise g-IV3 (b) Pour i-1 à t, le XT envoie l'instruction INS;au XuP qui met à jour g - H3 (g, INS; ) (c) Le X,uP calcule la signature o - /tK(ID, j,g) de la section et met à jour h FH1(h, g) (d) Le X,eP envoie 6j au XT (aucune copie de 6j n'est gardée dans le X,eP) (e) Le XT enregistre 6j 0. Le X,eP vérifie que h=-ID, que ID est présent en mémoire non volatile (en cas d'échec aller à l'étape 10) et initialise if-1 25 1. Le X,iP initialise V 4 IV2 2. Le XT initialise 6 4 IV2 3. Le X,UP demande au XT la section numéro j, le nombre t d'instructions qui la compose et initialise g4 IV3 et 5 4. Le XT met à jour 64 H2( , ) et initialise 5. Le XT envoie INS; au X,uP et incrémente i<--i+1 6. Le X,uP met à jour g E--H3(g,INS;) 7. Si i<t, alors le X,uP (a) teste si INSE S, et dans ce cas, aller à l'étape 10 (b) exécute INS, (c) retourne à l'étape 5 8. Si i=t et INS; E S, alors le X,uP (a) met à jour v 4 H2 (v, ji (ID, j, g)) (b) demande 6 au XT et vérifie que 0-=V; en cas d'échec, aller à l'étape 10 (c) exécute INS; (d) retourne à l'étape 1 9. Si i=t et INS; e S, alors le X,uP (a) met à jour v 4 H2 (v,,u (ID, j, g)) (b) exécute INS; (c) retourne à l'étape 3 10. Le X,uP sait que le programme fourni est un programme non authentique, et prend donc toutes les mesures nécessaires 25 défensives de protection.

23. Procédé de sécurisation d'un objet portable électronique selon la revendication 16 caractérisé en ce que la sous-phase de vérification dans la phase d'exécution est une vérification de la signature 6 se déroulant avant l'exécution de 25 l'instruction finale de chaque section, si ladite instruction est une instruction critique pour la sécurité, et si l'une au moins des données utilisées par cette instruction est une donnée secrète.

24. Procédé de sécurisation d'un objet portable électronique selon la revendication 23 caractérisé en ce qu'il utilise une variable définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné et en ce que la phase d'exécution comporte les sous-phases suivantes: b-l) le XN.P demande une section au XT; b-2) pour chaque instruction non finale de la 15 section demandée, le Xe vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée b-31) si l'instruction est critique pour la sécurité et si l'une au moins des données utilisées par l'instruction est secrète, le Xe demande une signature a construite à partir des signatures 6] générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature a, exécute la phase de réaction; b32) le Xe exécute l'instruction; b-33) le Xe met à jour le niveau de sécurité (donnée secrète ou donnée non 30 secrète) de chacune des données issues de l'exécution; b-4) le XNP retourne alors à la sous-phase b-1.

25. Procédé de sécurisation d'un objet portable électronique selon la revendication 23 caractérisé en ce qu'il utilise une variable 0 définissant l'ensemble des niveaux de sécurité définis à un instant donné par l'exécution d'un programme donné, en ce qu'il utilise une fonction booléenne Alert et en ce que la phase d'exécution comporte les sous-phases suivantes: b-l) le XpP demande une instruction au XT; b-2) pour chaque instruction non finale de la section demandée, le X P vérifie si cette instruction est critique, effectuant dans ce cas la phase de réaction, et sinon exécute cette instruction et passe à l'instruction suivante; b-3) pour l'instruction finale de la section demandée: b-31) si l'instruction est critique pour la sécurité et si la fonction booléenne Alert déterminée à partir du niveau de sécurité des données utilisées par l'instruction et par la nature de l'instruction elle-même s'évalue en VRAI, le XEeP demande une signature construite à partir des signatures 6i générées lors de la phase d'initialisation et à l'aide la fonction HASH2, et, en cas de non-validité de cette signature a, exécute la phase de réaction; b-32) le XiP exécute l'instruction; b-33) le Xe met à jour sécurité (donnée secrète secrète) de chacune des données issues de l'exécution; b-4) le Xe retourne alors à la sous-phase b-l.

26. Procédé de sécurisation d'un objet portable électronique selon la revendication 25 caractérisé en ce qu'il utilise un ensemble d'instructions critiques pour la sécurité comprend les étapes suivantes: 2. Le X/1P génère une clé aléatoire XT l'identifiant ID du programme, G qu'il contient et initialise h4-1V1 -1. Pour _If-1 à G (a) Le X,uP demande au XT la section numéro j, le nombre t d'instructions dans cette section et initialise g 4- IV3 (b) Pour if-1 à t, le XT envoie l'instruction INS;au X/1P qui met à jour g H3 (g, INS, ) (c) Le X,uP calcule la signature C 3'j J4 (ID, j,g) de la section et met à jour h 4- H1(h,g) (d) Le X1uP envoie C1 au XT (aucune copie de 0'j n'est gardée dans le X, UP) (e) Le XT enregistre (Fi O. Le X/.IP vérifie que h=ID, que ID est présent en mémoire non volatile (en cas d'échec aller à l'étape 10) et initialise j 4-1 1. Le X/2P initialise V 4-IVz 2. Le XT initialise 6 f- IVz le niveau de ou donnée non S, et en ce qu'il de session K, demande au le nombre de sections 3. Le X,uP demande au XT la section numéro j, le nombre t d'instructions qui la compose et initialise g4 IV3 et i 1 4. Le XT met à jour 6 H2(6,o) et initialise i4 1 5. Le XT envoie INS; au XdUP et incrémente 1<1+1 6. Le X,eP met à jour g 4 H3(g,INS;) 7. Si i<t, alors le X,zP (a) teste si INS;E S, et dans ce cas, aller à l'étape 10 (b) exécute INS; (c) met à jour (d) retourne à l'étape 5 8. Si i=t et I N S, E S et Alert ( INS; , (D) =VRAI, alors le X/1P (a) met à jour v 4 H2 (v, /2 (ID, j, g)) (b) demande 6 au XT et vérifie que 0'=V; en cas d'échec, aller à l'étape 10 (c) exécute INS; (d) met à jour (e) retourne à l'étape 1 9. Si i=t et (INSi S ou Alert ( INS, , (D) =FAUX) , alors le X,2P (a) met à jour v 4 H2 (v,,uK (ID, j, g)) (b) exécute INS; (c) met à jour (d) retourne à l'étape 3 10. Le X,UP sait que le programme fourni est un programme non authentique, et prend donc toutes les mesures nécessaires défensives de protection.

27. Procédé de sécurisation d'un objet portable électronique selon l'une quelconque des revendications 7 à 13 ou 16 à 26, caractérisé en ce qu'au moins un des types suivants d'instructions sont critiques pour la sécurité : 25 - les instructions de test et/ou - les instructions émettant de l'information vers l'extérieur par un moyen de communication et/ou - les instructions modifiant le contenu de la mémoire non-volatile et/ou - les instructions de calcul présentant des cas particuliers lors de leur exécution, tels que le lancement d'exceptions.

28. Procédé de sécurisation d'un objet portable électronique selon l'une quelconque des revendications 12, 13, 25 ou 26, caractérisé en ce que la fonction booléenne Alert s'évalue en VRAI pour au moins un des types suivants d'instructions: - les instructions de test et/ou - les instructions émettant de l'information vers l'extérieur par un moyen de communication et/ou - les instructions modifiant le contenu de la mémoire non-volatile et/ou - les instructions de calcul présentant des cas particuliers lors de leur exécution, tels que le lancement d'exceptions.

29. Procédé de sécurisation d'un objet portable électronique selon l'une quelconque des revendications 12, 13, 25 ou 26, caractérisé en ce que la fonction booléenne Alert s'évalue en VRAI pour au moins un des types suivants d'instructions, si au moins une des données d'entrée est secrète, et FAUX si toutes les données testées sont publiques: - les instructions de test et/ou - les instructions émettant de l'information vers l'extérieur par un moyen de communication et/ou les instructions modifiant le contenu de la mémoire non-volatile et/ou - les instructions de calcul présentant des cas particuliers lors de leur exécution, tels que le lancement d'exceptions.

30. Procédé de sécurisation d'un objet portable électronique selon l'une quelconque des revendications 11 à 13 ou 24 à 26, caractérisé en ce que l'ensemble des niveaux de sécurité c utilisé lors de l'exécution d'un programme P est indiqué par la valeur d'une fonction cp, telle que, pour toute donnée u utilisée par le programme, 9(u)=0 désigne le fait que u est publique et 9(u)=l désigne le fait que u est privée, et telle que, pour toute donnée v résultant de l'exécution d'une instruction du programme P, 9(v)=1 si au moins une des données d'entrée de l'instruction est privée, et sinon 9(v)=O.

31. Procédé de sécurisation d'un objet portable électronique selon la revendication 30, caractérisé en ce que les valeurs de la fonction 9 sont calculées au moyen d'une mise en oeuvre matérielle d'une fonction OU logique réalisée sur les valeurs de la fonction cp pour les données d'entrée des instructions.

32. Procédé de sécurisation d'un objet portable électronique selon l'une quelconque des revendications 1 à 31, caractérisé en ce que les fonctions de hachage HASH1, HASH2 et HASH3 sont identiques.

33. Objet électronique caractérisé en ce qu'il met en uvre l'une quelconque des revendications 1 à 32.