Brevet FR3045858A1 — publié le 20170623

DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne les séquences de codes d'instruction exécutables par une machine virtuelle. Elle concerne plus particulièrement un procédé de chargement d'une séquence de codes d'instruction, un procédé d'exécution d'une séquence de codes d'instruction, un procédé mis en oeuvre dans une entité électronique et des entités électroniques associées. L'invention s'applique particulièrement avantageusement dans le cas où l'on souhaite se prémunir contre les attaques utilisant du code inatteignable, comme expliqué ci-dessous. ARRIERE-PLAN TECHNOLOGIQUE Il est connu, par exemple dans le cadre de la technologie dénommée "Java Card", d'utiliser une machine virtuelle implantée dans une entité électronique (telle qu'une carte à microcircuit) pour charger une séquence de codes d'instruction (par exemple sous forme d'un fichier .CAP) dans l'entité électronique et exécuter cette séquence de codes d'instruction. Afin de se protéger contre certaines attaques, il est connu de vérifier la séquence de codes d'instruction avant son exécution. Une telle vérification est généralement réalisée à l'extérieur de l'entité électronique, ou, au sein même de l'entité électronique, typiquement lors du chargement de la séquence de codes d'instruction. Comme expliqué par exemple dans l'article "The Ultimate Control Flow Transfer in a Java Based Smart Card", de Guillaume Bouffart et Jean-Louis Lanet, in Computers & Security 2015, les techniques de vérification actuelles ne permettent toutefois pas de détecter du code inatteignable (en anglais : "unreachable code"), à savoir des codes d'instruction présents dans une partie d'une séquence où le flux de commande (en anglais : "control floW') ne passe jamais en fonctionnement normal. Un tel code inatteignable peut en revanche être exécuté lorsqu'un attaquant met en oeuvre une attaque par faute qui permet de s'écarter du flux de commande normal. 3045858 2 OBJET DE L'INVENTION Dans ce contexte, la présente invention propose un procédé de chargement, au sein d'une mémoire d'une entité électronique, d'une séquence de codes d'instruction exécutables par une machine virtuelle résidant dans l'entité 5 électronique, caractérisé par les étapes suivantes : - détection d'un code d'instruction contenu dans une liste prédéterminée de codes d'instruction ; - conversion d'une paire formée du code détecté et d'un code situé dans la séquence à une position relative prédéterminée par rapport au code détecté, en 10 une paire distincte de codes selon une règle prédéterminée ; - écriture de la paire distincte dans la mémoire en remplacement de la paire formée du code détecté et du code situé à ladite position relative. Pour l'exécution d'une séquence ainsi chargée, il sera nécessaire comme expliqué ci-après de procéder à une nouvelle conversion de la paire de 15 codes d'instruction écrite dans la mémoire. Cette nouvelle conversion ne pourra pas toutefois se dérouler correctement (et l'exécution pourra par exemple être interrompue) si un attaquant cherche à sauter (en anglais : "skip") l'exécution de l'un des deux codes au moyen d'une attaque (telle qu'une attaque laser), par exemple dans le but de faire exécuter du code inatteignable comme expliqué ci-20 dessus. L'exécution ultérieure est ainsi protégée de telles attaques. Selon d'autre caractéristiques éventuellement envisageables (sans que cela ne soit limitatif) : - le code situé à une position relative prédéterminée par rapport au code 25 détecté est un code contigu, dans la séquence, au code détecté ; - le code contigu est le code précédant, dans la séquence, le code détecté ; - la liste prédéterminée contient l'ensemble des codes correspondant à une instruction de rupture inconditionnelle du flux de commande ; 30 - les codes de la séquence correspondent à des codes normalisés selon une spécification donnée (éventuellement une spécification relative à une norme) ; - les codes de la paire distincte correspondent à des codes inutilisés selon ladite spécification donnée ; - l'étape de conversion comprend une étape de lecture, dans une table 3045858 3 de correspondance, de la paire distincte associée à la paire formée du code détecté et du code situé à ladite position relative ; - l'étape de conversion comprend une étape d'application d'une fonction arithmétique à la paire formée du code détecté et du code situé à ladite position 5 relative. L'invention propose également un procédé d'exécution d'une séquence de codes d'instruction par une machine virtuelle résidant sur une entité électronique, comprenant les étapes suivantes : - en cas de lecture d'un code d'instruction appartenant à une liste 10 prédéfinie de codes, conversion, selon une règle prédéterminée, d'une paire formée par le code lu et par le code situé à une position relative prédéterminée par rapport au code lu, en une paire distincte de codes comprenant un premier code et un second code ; - exécution, par la machine virtuelle, d'une instruction définie au moins 15 en partie par le premier code. L'instruction ne sera donc exécutée que si l'étape de conversion a pu, comme cela est prévu en fonctionnement normal, déterminer le premier code (ainsi que le second code) sur la base de la paire formée par le code lu et par le code situé à ladite position relative ; la conversion échouera en revanche si un 20 attaquant empêche le traitement de l'un de ces deux codes pour tenter d'exécuter du code inatteignable. Selon d'autre caractéristiques éventuellement envisageables (sans que cela ne soit limitatif) : - le code situé à ladite position relative est le code suivant le code lu ; 25 - le procédé comprend une étape d'exécution, par la machine virtuelle, d'une autre instruction définie au moins en partie par le second code ; - l'autre instruction est une instruction de rupture inconditionnelle du flux de commande ; - le premier code et le second code correspondent à des codes 30 normalisés selon une spécification donnée ; - les codes de la liste prédéfinie correspondent à des codes inutilisés selon ladite spécification donnée ; - l'étape de conversion comprend une étape de lecture, dans une table de correspondance, de la paire distincte associée à la paire formée par le code lu 3045858 4 et par le code situé à ladite position relative ; - l'étape de conversion comprend une étape d'application d'une fonction arithmétique à la paire formée par le code lu et par le code situé à ladite position relative ; 5 - le procédé comprend une étape de vérification que la paire formée par le code lu et par le code situé à ladite position relative fait partie d'un ensemble de paires possibles (c'est-à-dire en pratique que la paire formée par le code lu et par le code suivant fait partie d'une liste préétablie de paires). On peut prévoir, en cas d'échec de ladite vérification, la mise en oeuvre 10 d'une fonction de traitement d'erreur (comprenant par exemple l'inscription en mémoire non-volatile d'un code d'erreur et/ou le blocage de tout fonctionnement ultérieur de l'entité électronique et/ou l'effacement de certaines données au moins de l'entité électronique). L'invention propose également un procédé mis en oeuvre dans une entité 15 électronique comprenant un procédé de chargement tel que décrit ci-dessus et un procédé d'exécution tel que décrit ci-dessus. L'invention propose en outre une entité électronique comprenant une machine virtuelle, une mémoire et un module de chargement, au sein de la mémoire, d'une séquence de codes d'instruction exécutables par la machine 20 virtuelle, caractérisée en ce que le module de chargement est conçu pour détecter un code d'instruction contenu dans une liste prédéterminée de codes d'instruction, pour convertir une paire formée du code détecté et d'un code situé dans la séquence à une position relative prédéterminée par rapport au code détecté, en une paire distincte de codes selon une règle prédéterminée, et pour écrire la paire 25 distincte dans la mémoire en remplacement de la paire formée du code détecté et du code situé à ladite position relative. L'invention propose enfin une entité électronique comprenant une machine virtuelle et une mémoire, caractérisée par un module d'exécution conçu pour convertir selon une règle prédéterminée, en cas de lecture dans la mémoire 30 d'un code d'instruction appartenant à une liste prédéfinie de codes, une paire formée par le code lu et par le code situé à une position relative prédéterminée par rapport au code lu, en une paire distincte de codes comprenant un premier code et un second code, la machine virtuelle étant conçue pour exécuter une instruction définie au moins en partie par le premier code. 3045858 5 Les caractéristiques optionnelles présentées ci-dessus en termes de procédé peuvent également s'appliquer à ces entités électroniques. Par ailleurs, lorsque l'entité électronique comprend un processeur, le module de chargement et/ou le module d'exécution peuvent être mis en oeuvre du 5 fait de l'exécution d'instructions (mémorisées dans la mémoire susmentionnée ou une autre mémoire) par le processeur. DESCRIPTION DETAILLEE D'UN EXEMPLE DE REALISATION La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et 10 comment elle peut être réalisée. Sur les dessins annexés : - la figure 1 représente schématiquement une entité électronique conforme à l'invention ; - la figure 2 est un logigramme présentant un procédé de chargement 15 d'une application dans l'entité électronique de la figure 1 ; et - la figure 3 est un logigramme présentant un procédé d'exécution d'une application au sein de l'entité électronique de la figure 1. La figure 1 représente schématiquement une entité électronique conforme à l'invention. 20 L'entité électronique est ici un élément sécurisé, par exemple une carte à microcircuit C (éventuellement une carte à circuit intégré universelle ou UICC pour "Universal Integrated Circuit Card'). Une telle carte à microcircuit C est par exemple montée de manière amovible dans un dispositif électronique tel qu'un téléphone cellulaire. Il s'agit généralement dans ce cas d'une carte SIM (pour 25 "Subscriber Identity Module"). L'entité électronique pourrait être en variante un autre type d'élément sécurisé, par exemple un élément sécurisé intégré (ou eSE pour "embedded Secure Element"). Un tel élément sécurisé peut être soudé au sein d'un dispositif électronique tel qu'un téléphone cellulaire. Il peut s'agir d'une carte à circuit 30 intégré universelle intégrée ou eUICC pour "embedded Universal Integrated Circuit Card'. L'entité électronique pourrait également être une carte de type SD (par exemple une carte SD, "secure microSD" ou "microSD"), par exemple avec un masque Java Card. 3045858 6 Selon une autre variante encore, l'entité électronique pourrait être un ordinateur personnel ou une carte de transport, par exemple. L'entité électronique comprend un processeur PROC, une mémoire MEM et au moins une interface I. 5 Le processeur PROC est par exemple réalisé sous la forme d'un microprocesseur. La mémoire MEM est ici une mémoire non-volatile réinscriptible. L'entité électronique peut comprendre d'autres mémoires (non représentées), par exemple une mémoire vive. 10 Certains au moins des éléments précités peuvent en pratique être réunis au sein d'un même circuit électronique tel qu'un microcontrôleur. L'interface I permet la connexion de l'entité électronique à un dispositif électronique extérieur (tel qu'un lecteur de carte équipant un téléphone cellulaire) et l'échange de données entre les circuits électroniques (en particulier le 15 processeur PROC) de l'entité électronique et le dispositif électronique extérieur. Lorsque l'entité électronique est une carte à microcircuit C comme décrit ici (par exemple au format défini par la norme ISO/IEC 7816), l'interface I peut comprendre une pluralité de contacts électriques disposés au niveau de la surface extérieure de la carte à microcircuit C. En variante, l'interface I pourrait être 20 réalisée par des moyens de communication sans contact, par exemple conformément à la norme ISO/IEC 14443. L'entité électronique (ici la carte à microcircuit C) pourrait comprendre des deux types d'interface et utiliser l'une ou l'autre selon son mode de fonctionnement. La mémoire MEM mémorise un premier ensemble d'instructions conçues 25 pour mettre en oeuvre un module de chargement (ou installateur) LD.M lorsque ces instructions sont exécutées par le processeur PROC. Comme expliqué plus loin en référence à la figure 2, le module de chargement LD.M permet de recevoir une application APP sur l'interface I, de traiter cette application APP pour en obtenir une version modifiée APP' et de 30 mémoriser la version modifiée APP' dans la mémoire MEM. L'application APP est reçue sous forme d'une séquence de codes d'instruction exécutables. Par exemple, dans le cadre de la technologie dénommée "Java Card", l'application APP (couramment désignée "appliquette") est reçue sous forme d'un fichier .CAP. Dans ce même contexte, les codes 3045858 7 d'instruction sont définis sur un octet (ce pour quoi ils sont couramment désignés par l'appellation "bytecode"). La mémoire MEM mémorise un second ensemble d'instructions conçues pour mettre en oeuvre un module d'exécution (ou interpréteur) EX.M lorsque ces 5 instructions sont exécutées par le processeur PROC. Comme expliqué plus loin en référence à la figure 3, le module d'exécution EX.M permet de lire des codes d'instruction dans la mémoire MEM, de traiter éventuellement ces codes comme décrit ci-dessous, et de mettre en oeuvre les instructions désignées par ces codes (après traitement éventuel). 10 Le module de chargement LD.M et le module d'exécution EX.M font par exemple partie d'une machine virtuelle, ici une machine virtuelle selon la technologie "Java Card' précitée. La figure 2 est un logigramme présentant un procédé de chargement d'une application dans l'entité électronique de la figure 1. 15 Ce procédé débute à l'étape E2 à laquelle le module de chargement LD.M reçoit via l'interface I une séquence de codes d'instruction formant une application APPL, ici sous forme d'un fichier .CAP. La séquence de codes d'instruction est alors par exemple mémorisée dans une mémoire vive (non-représentée) associée au processeur PROC. 20 Le procédé ci-dessous est alors mis en oeuvre pour chacune des méthodes définies dans le fichier .CAP concerné. Le module de chargement LD.M parcourt la séquence de codes d'instruction jusqu'à détecter une première instruction de rupture inconditionnelle du flux de commande (en anglais : "unconditional control flow break"). (Une telle 25 détection est réalisée en pratique en comparant successivement chacun des codes d'instruction de la séquence aux différents codes correspondant à une instruction de rupture inconditionnelle du flux de commande.) Les instructions de rupture inconditionnelle du flux de commande comprennent par exemple les instructions de saut inconditionnel (telles que 30 l'instruction "goto") et les instructions de retour d'un sous-programme (telles que l'instruction "sretum"). Les instructions de rupture inconditionnelle du flux de commande comprennent ici (suivies chacune du code d'instruction correspondant en hexadécimal) : - Goto (0x70) ; 3045858 8 - Ret (0x72) ; - Areturn (0x77) ; - Sreturn (0x78) ; - Ireturn (0x79) ; 5 - Return (0x7A) ; - Athrow (0x93) ; - Goto_w (OxA8). Le module de chargement peut alors déterminer à l'étape E4 si la première instruction de rupture inconditionnelle du flux de commande est une 10 instruction de retour (telle que l'instruction "returri" dans le cadre de la technologie "Java Card') et si aucune instruction de branchement (conditionnel ou inconditionnel) n'a été rencontrée. Si tel est le cas (une telle instruction de retour étant conçue pour mettre fin à la méthode décrite par le fichier .CAP concerné, sans possibilité de saut 15 préalable à une autre adresse), le procédé se poursuit à l'étape E6 à laquelle le module de chargement LD.M remplace tout code d'instruction jusqu'à la fin de la méthode en cours par un code prédéterminé, correspondant par exemple à une instruction de retour ou une instruction propriétaire avec pour effet par exemple la récupération de la valeur d'erreur, l'incrémentation d'un compteur ou encore la 20 désactivation de la carte. En variante l'utilisation d'une instruction sans effet, telle que l'instruction "nop" est également possible. En effet, tout code présent après une instruction de retour sans instruction de branchement préalable correspond nécessairement à du code inatteignable (comme expliqué en introduction), qui est ainsi supprimé grâce à 25 l'étape E6. S'il est en revanche déterminé à l'étape E4 que la première instruction de rupture inconditionnelle du flux de commande n'est pas une instruction de retour ou si une instruction de branchement (conditionnel ou inconditionnel) a été rencontrée, le procédé se poursuit à l'étape E8 pour traitement de l'instruction de 30 rupture inconditionnelle du flux de commande. Le module de chargement LD.M détermine à l'étape E8 la paire P formée (ici dans l'ordre inverse) par le code de l'instruction détecté y et le code précédent dans la séquence de codes d'instruction x, et convertit cette paire P=(x,y) en une paire distincte F(P) selon une règle prédéterminée, ici une bijection F. (Selon un 3045858 9 mode de réalisation envisageable, la règle prédéterminée est connue seulement de l'entité électronique et variable d'une entité électronique à une entité électronique différente.) On note a et b les codes de la paire F(P). 5 On prévoit ici que les codes a, b de la paire F(P) soient des codes inutilisés du jeu d'instructions concerné (ici celui prévu pour la technologie "Java Card"). Dans l'exemple décrit ici de la technologie "Java Card', il existe 187 codes d'instructions normalisés, dont 8 correspondent à des instructions de 10 rupture inconditionnelle du flux de commande, et 69 codes d'instructions inutilisés (les codes d'instruction étant définis sur un octet comme déjà indiqué, il existe 256 codes possibles). Il existe donc 1496 paires P possibles formées par un code normalisé x et un code normalisé y correspondant à une instruction de rupture inconditionnelle 15 de flux de commande. On peut donc associer, à chacune de ces paires P envisageables, une paire (a, b) de codes inutilisés au moyen d'une bijection F (le nombre de telles paires de codes inutilisés étant égal à 4761). Selon un premier mode de réalisation envisageable, l'association de chaque paire P=(x,y) à une paire F(P)=(a,b) donnée est mémorisée dans une 20 table de correspondance (stockée par exemple dans la mémoire MEM). Selon un second mode de réalisation envisageable, la paire F(P)=(a,b) est obtenue par application d'une fonction arithmétique à la paire P=(x,y). Par exemple, en associant un élément i(x) de l'ensemble Z187 à chaque code d'instruction x, un élément j(y) de l'ensemble Z8 à chaque code y 25 correspondant à une instruction de rupture inconditionnelle du flux de commande, et un élément k(a) de l'ensemble Z69 à chaque code inutilisé a, la paire F(P)=(a,b) associée à une paire P=(x,y) peut être déterminée par les opérations suivantes : k(a) = INT{[i(x)+187.j(y)]/69} ; k(b) = [i(x)+187.j(y)] mod 69. On a noté ci-dessus Z, l'ensemble des entiers compris entre 0 et (m-1). 30 Le module de chargement LD.M remplace alors, dans la séquence de codes d'instruction, la paire P (dont le second membre y a été détecté comme correspondant à une instruction de rupture inconditionnelle du flux de commande) par la paire F(P) obtenue à l'étape E8, ce qui permet de former une séquence de codes d'instruction modifiée APPL' (étape El 0). 3045 85 8 10 Le module de chargement LD.M poursuit alors son parcours de la séquence de codes d'instruction en recherchant un autre code correspondant à une instruction de rupture inconditionnelle du flux de commande (étape E12). Si un tel code est trouvé, le procédé boucle à l'étape E8 pour traitement 5 de ce nouveau code correspondant à une instruction de rupture inconditionnelle du flux de commande. Si en revanche la fin de la séquence d'instructions est parcourue sans rencontrer un nouveau code correspondant à une instruction de rupture inconditionnelle du flux de commande, le module de chargement LD.M procède à 10 l'étape E14 à l'enregistrement de la séquence de codes d'instruction modifiée APPL' dans la mémoire MEM. On décrit à présent à titre purement illustratif un exemple d'application du procédé de la figure 2 sur une partie d'une séquence de codes d'instruction : bspush 0x55 0x10 0x55 15 sstore_3 0x32 goto @0x4 0x70 0x4 sconst_0 0x3 (où on a représenté à gauche les instructions qui correspondent à cette partie de séquence et à droite les codes d'instruction correspondants en 20 hexadécimal). Le module de chargement LD.M parcourt la séquence de codes d'instruction et détecte l'instruction goto (précisément le code 0x70) qui est une instruction de rupture inconditionnelle du flux de commande (à l'étape E4 s'il s'agit de la première telle instruction, ou à l'étape E12 sinon). 25 Le module de chargement LD.M convertit alors (étape E8) la paire P formée du code précédent x=0x32 et du code détecté y=0x70 en une paire F(P)=(a,b), avec par exemple a=0xCl et b=OxBB (la notation Ox introduisant comme indiqué ci-dessus un nombre en hexadécimal). La séquence modifiée obtenue (à l'étape El 0) est donc la suivante : 30 0x10 0x55 OxCl OxBB 0x4 0x3. Cette séquence est enregistrée dans la mémoire MEM à l'étape E14. La figure 3 est un logigramme présentant un procédé d'exécution de l'application APPL' (qui correspond à la séquence de codes d'instruction enregistrée lors du procédé qui vient d'être décrit en référence à la figure 2) au 3045858 11 sein de l'entité électronique de la figure 1. Comme déjà indiqué, un tel procédé est ici mis en oeuvre par un module d'exécution EX.M. Ce procédé débute à l'étape E20 à laquelle le module d'exécution EX.M 5 (c'est-à-dire en pratique le processeur PROC) lit dans la mémoire MEM un code COD, de la séquence de codes d'instruction APPL'. (On remarque qu'il est possible en variante que la séquence de codes d'instruction APPL' soit au préalable chargée dans une mémoire vive, où les codes de cette séquence sont alors successivement lus par le processeur PROC.) 10 Lors du premier passage à l'étape E20, ce code CODA est le premier code de la séquence de codes d'instruction. Le module d'exécution EX.M détermine alors à l'étape E22 si le code CODA lu fait partie d'une liste prédéfinie L de codes d'instruction (qui correspond ici à l'ensemble des codes utilisés comme premier membre a d'une paire F(P) 15 lorsque la paire P parcourt l'ensemble des paires P envisageables). Dans la négative, le code COD, lu est exécuté de manière conventionnelle à l'étape E24: il s'agit normalement soit d'un code normalisé correspondant à une instruction (que le module d'exécution EX.M met alors en oeuvre comme prévu par la norme ou la spécification concernée), soit d'un 20 paramètre associé à un code normalisé traité à l'itération précédente. Si un code normalisé est attendu et que la valeur du code CODA lu ne correspond pas à un code normalisé, une erreur est détectée et l'exécution de la séquence de codes est par exemple interrompue. Le procédé boucle à l'étape E20 après traitement du code courant CODA. 25 Dans le cas de l'exemple de partie de séquence donné ci-dessus, le module d'exécution EX.M procède ainsi à l'étape E24 lorsqu'il lit le code 0x10 (code normalisé correspondant à l'instruction bspush), puis le code 0x55 (paramètre attendu de l'instruction bspush). S'il est en revanche déterminé à l'étape E22 que le code CODA lu fait 30 partie de la liste prédéfinie L de codes d'instruction, le module d'exécution EX.M (c'est-à-dire en pratique le processeur PROC) lit à l'étape E26 le code d'instruction suivant COD'i (dans la mémoire MEM ou, en variante comme déjà indiqué, dans une mémoire vive où a momentanément été recopiée la séquence de codes d'instruction APPL'). 3045858 12 Le module d'exécution EX.M peut alors vérifier à l'étape E28 que la paire (CODn, CODn+i) formée des deux codes successifs (successivement lus aux étapes E20 et E26) correspond bien à l'une des paires F(P) possibles (c'est-à-dire à l'une des paires F(P) obtenues lorsque la paire P parcourt l'ensemble des paires 5 possibles). Dans la négative, la séquence de codes lus ne correspond pas à la séquence telle qu'elle a été enregistrée à l'étape E14 décrite plus haut. Ce problème provient par exemple du fait qu'un attaquant a réussi à faire passer (en anglais : "skip") une instruction sans qu'elle soit prise en compte, dans le but 10 d'atteindre une zone de code inatteignable comme décrit en introduction. On procède donc dans ce cas à l'étape E30 à un traitement d'erreur, qui met par exemple fin à l'exécution de la séquence de codes d'instruction APPL'. Si en revanche la paire (CODn, CODn+i) formée des deux codes successifs correspond bien à l'une des paires F(P) possibles, le module 15 d'exécution EX.M convertit à l'étape E32 cette paire (CODn, COD,i) en une paire distincte (COD'n, COD'+1) selon une règle prédéterminée, ici en appliquant la fonction inverse F-1 de la bijection F utilisée au cours du chargement de la séquence de codes d'instruction APPL' comme décrit plus haut. On a donc ici (COD'n, COD'+1) = F-1[(CODn, CODn+i)]. 20 Selon le premier mode de réalisation déjà mentionné plus haut, l'association de chaque paire P à une paire F(P) est mémorisée dans une table de correspondance, qui peut donc également être utilisée (en sens inverse) pour déterminer la paire F-1[(CODn, CODn+i)] à partir de la paire (CODn, CODn+i). Selon un second mode de réalisation envisageable, la paire F-1[(CODn, 25 CODn+i)] est obtenue par application d'une fonction arithmétique à la paire (CODe, CODn+i). Dans le cas donné ci-dessus où (a,b)=F[(x,y)] avec : k(a) = INT{[i(x)+187.j(y)]/69} ; k(b) = [i(x)+187.j(y)] mod 69, la fonction inverse F-1 est par exemple mise en oeuvre comme suit 30 i(COD'n) = [k(CODn+i) + 69.k(CODn)] mod 187, j(COD'n+i ) = INT{[k(CODn+i ) + 69.k(COD,)]/187. On retrouve ainsi les deux codes d'instruction initialement présents dans la séquence de codes d'instruction APPL reçue à l'étape E2 décrite plus haut. Les codes COD'n, COD'n+i de la paire obtenue par l'étape de conversion 3045858 13 E32 sont alors successivement exécutés de manière conventionnelle. Dans l'exemple décrit ici, le premier code COD', peut être soit un code normalisé correspondant à une instruction (que le module d'exécution EX.M met alors en oeuvre comme prévu par la norme ou la spécification concernée), soit un 5 paramètre associé à un code normalisé précédemment traité ; le second code COD'n+i est quant à lui ici nécessairement un code associé à une instruction de rupture inconditionnelle du flux de commande (qui sera alors exécuté, éventuellement après lecture du code suivant correspondant à un paramètre associé au code COD'n+i). 10 Le procédé boucle ensuite à l'étape E20 pour lecture du code suivant. Dans le cas de la partie de séquence de codes d'instruction donnée plus haut à titre d'exemple, le module d'exécution EX.M détermine à l'étape E22 que le code OxCl fait partie de la liste prédéfinie L, lit par conséquent à l'étape E26 le code suivant OxBB, vérifie à l'étape E28 que la paire (0xC1, OxBB) est une paire 15 F(P) possible, puis convertit cette paire (0x01, OxBB) en la paire initiale (0x32, 0x70) à l'étape E32. Le module d'exécution EX.M exécute alors l'instruction sstore 3 (correspondant au code 0x32), puis l'instruction goto @0x4 (après un nouveau passage à l'étape E20 pour lire le code suivant 0x4). 20 Dans l'exemple qui vient d'être décrit, les codes convertis sont des codes contigus dans la séquence de codes d'exécution. On peut prévoir de manière générale d'utiliser une paire formée d'un premier code et d'un second code situé à une position relative prédéterminée par rapport au premier code (éventuellement non contiguë au premier code). Lors de l'exécution, on pourra alors au besoin 25 mémoriser de manière temporaire certains codes avant leur exécution. En effet, si un premier code est lu et fait partie de la liste prédéfinie L de codes d'instruction et que le second code de la paire est situé m octets plus loin (le nombre m étant prédéterminé), le module d'exécution EX.M lit et mémorise temporairement les codes d'instruction (intermédiaires) situés entre le premier code et le second code, 30 lit le second code, convertit la paire formée par le premier code et le second code comme décrit ci-dessus en un troisième code et un quatrième code, puis exécute les instructions définies (dans cet ordre) par le troisième code, les codes intermédiaires et le quatrième code. REVENDICATIONS1. Procédé de chargement, au sein d'une mémoire (MEM) d'une entité électronique (C), d'une séquence (APPL) de codes d'instruction exécutables par une machine virtuelle résidant dans l'entité électronique (C), caractérisé par les étapes suivantes : - détection (E4 ; E12) d'un code d'instruction contenu dans une liste prédéterminée de codes d'instruction ; - conversion (E8) d'une paire formée du code détecté et d'un code situé dans la séquence (APPL) à une position relative prédéterminée par rapport au 10 code détecté, en une paire distincte de codes (F(P)) selon une règle prédéterminée; - écriture (E14) de la paire distincte (F(P)) dans la mémoire (MEM) en remplacement de la paire formée du code détecté et du code situé à ladite position relative. 15 2. Procédé de chargement selon la revendication 1, dans lequel le code situé à une position relative prédéterminée par rapport au code détecté est un code contigu, dans la séquence, au code détecté. 3. Procédé de chargement selon la revendication 2, dans lequel le code contigu est le code précédant, dans la séquence (APPL), le code détecté. 20 4. Procédé de chargement selon l'une des revendications 1 à 3, dans lequel la liste prédéterminée contient l'ensemble des codes correspondant à une instruction de rupture inconditionnelle du flux de commande. 5. Procédé de chargement selon l'une des revendications 1 à 4, dans lequel les codes de la séquence (APPL) correspondent à des codes normalisés 25 selon une spécification donnée et dans lequel les codes de la paire distincte (F(P)) correspondent à des codes inutilisés selon ladite spécification donnée. 6. Procédé de chargement selon l'une des revendications 1 à 5, dans lequel l'étape de conversion (E8) comprend une étape de lecture, dans une table de correspondance, de la paire distincte associée à la paire formée du code 30 détecté et du code situé à ladite position relative. 7. Procédé de chargement selon l'une des revendications 1 à 5, dans lequel l'étape de conversion (E8) comprend une étape d'application d'une fonction arithmétique à la paire formée du code détecté et du code situé à ladite position relative. 3045858 15 8. Procédé d'exécution d'une séquence de codes d'instruction (APPL') par une machine virtuelle résidant sur une entité électronique, comprenant les étapes suivantes : - en cas de lecture d'un code d'instruction (CODn) appartenant à une liste 5 prédéfinie (L) de codes, conversion (E32), selon une règle prédéterminée, d'une paire formée par le code lu (CODe) et par le code (COD,,i) situé à une position relative prédéterminée par rapport au code lu, en une paire distincte de codes comprenant un premier code (COD'n) et un second code (COD'n+i) ; - exécution (E34), par la machine virtuelle, d'une instruction définie au moins en partie par le premier code (COD'n). 9. Procédé d'exécution selon la revendication 8, dans lequel le code situé à ladite position relative est le code suivant le code lu. 10. Procédé d'exécution selon la revendication 8 ou 9, comprenant une étape d'exécution, par la machine virtuelle, d'une autre instruction définie au moins en partie par le second code (COD'n+i). 11. Procédé d'exécution selon la revendication 8 ou 9, dans lequel l'autre instruction est une instruction de rupture inconditionnelle du flux de commande. 12. Procédé d'exécution selon l'une des revendications 8 à 11, dans lequel le premier code (COD'n) et le second code (COD'n+i) correspondent à des codes normalisés selon une spécification donnée et dans lequel les codes de la liste prédéfinie (L) correspondent à des codes inutilisés selon ladite spécification donnée. 13. Procédé d'exécution selon l'une des revendications 8 à 12, dans lequel l'étape de conversion (E32) comprend une étape de lecture, dans une table de correspondance, de la paire distincte associée à la paire formée par le code lu et par le code situé à ladite position relative. 14. Procédé d'exécution selon l'une des revendications 8 à 12, dans lequel l'étape de conversion (E32) comprend une étape d'application d'une fonction arithmétique à la paire formée par le code lu et par le code situé à ladite position relative. 15. Procédé d'exécution selon l'une des revendications 8 à 14, comprenant une étape de vérification (E28) que la paire formée par le code lu (CODn) et par le code suivant (CODn+i) fait partie d'un ensemble de paires possibles. 3045858 16 16. Procédé d'exécution selon la revendication 15, comprenant, en cas d'échec de ladite vérification (E28), la mise en oeuvre d'une fonction de traitement d'erreur. 17. Procédé mis en oeuvre dans une entité électronique, comprenant un 5 procédé de chargement selon l'une des revendications 1 à 7 et un procédé d'exécution selon l'une des revendications 8 à 16. 18. Entité électronique (C) comprenant une machine virtuelle, une mémoire (MEM) et un module de chargement (LD.M), au sein de la mémoire (MEM), d'une séquence (APPL) de codes d'instruction exécutables par la machine 10 virtuelle, caractérisée en ce que le module de chargement (LD.M) est conçu pour détecter un code d'instruction contenu dans une liste prédéterminée de codes d'instruction, pour convertir une paire formée du code détecté et d'un code situé dans la séquence (APPL) à une position relative prédéterminée par rapport au 15 code détecté, en une paire distincte de codes selon une règle prédéterminée, et pour écrire la paire distincte dans la mémoire (MEM) en remplacement de la paire formée du code détecté et du code situé à ladite position relative. 19. Entité électronique (C) comprenant une machine virtuelle et une mémoire (MEM), caractérisée par un module d'exécution (EX.M) conçu pour 20 convertir selon une règle prédéterminée, en cas de lecture dans la mémoire (MEM) d'un code d'instruction (CODe) appartenant à une liste prédéfinie de codes, une paire formée par le code lu (CODe) et par le code (COD'i) situé à une position relative prédéterminée par rapport au code lu, en une paire distincte de codes comprenant un premier code (COD'n) et un second code (COD'n+i), la 25 machine virtuelle étant conçue pour exécuter une instruction définie au moins en partie par le premier code (COD'n).