FR3140186A1 - Procédé de détection d’une tentative d’extraction linéaire du contenu d’une mémoire - Google Patents

Procédé de détection d’une tentative d’extraction linéaire du contenu d’une mémoire Download PDF

Info

Publication number
FR3140186A1
FR3140186A1 FR2209624A FR2209624A FR3140186A1 FR 3140186 A1 FR3140186 A1 FR 3140186A1 FR 2209624 A FR2209624 A FR 2209624A FR 2209624 A FR2209624 A FR 2209624A FR 3140186 A1 FR3140186 A1 FR 3140186A1
Authority
FR
France
Prior art keywords
instruction
code
instructions
execution
circuit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR2209624A
Other languages
English (en)
Inventor
Jean-Max Dutertre
Théophile Gousselot
Jean-Baptiste Rigaud
Olivier Potin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Institut Mines Telecom IMT
Original Assignee
Institut Mines Telecom IMT
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Institut Mines Telecom IMT filed Critical Institut Mines Telecom IMT
Priority to FR2209624A priority Critical patent/FR3140186A1/fr
Priority to PCT/EP2022/081057 priority patent/WO2023083776A1/fr
Publication of FR3140186A1 publication Critical patent/FR3140186A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/54—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by adding security routines or objects to programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/75—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information by inhibiting the analysis of circuitry or operation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G06F21/79—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data in semiconductor storage media, e.g. directly-addressable memories

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Procédé de détection d’une tentative d’extraction linéaire du contenu d’une mémoire Procédé de détection d’une tentative d’extraction linéaire d’un code de programme enregistré dans une mémoire (10) d’un circuit électronique (1), le code comportant des instructions de programme qui, pour être lues par un cœur de microprocesseur (14), sont chargées séquentiellement via un bus d’instructions (11) dans un registre d’instructions (12) pour le stockage des instructions commandé au moins par un signal d’horloge (clk) et un signal de réinitialisation (reset), le chargement de chaque instruction dans le registre d’instructions (12) s’effectuant sur un front du signal d’horloge (clk), le code comprenant des instructions de discontinuité et/ou des instructions dites « marqueurs de sécurité » insérées parmi les instructions de programme de manière à être lues au cours de l’exécution du programme, le procédé comportant le déclenchement d’une action prédéfinie d’alerte (300), en cas de non-détection d’une instruction de discontinuité ou d’un marqueur de sécurité, selon une règle de surveillance prédéfinie. Figure pour l’abrégé : Fig. 4

Description

Procédé de détection d’une tentative d’extraction linéaire du contenu d’une mémoire
La présente invention concerne un procédé de détection d’une tentative d’extraction linéaire du contenu d’une mémoire d’un microcontrôleur ou d’un processeur ainsi qu’un circuit électronique configuré pour détecter une telle tentative d’extraction.
Le piratage de cartes à puce est devenu un phénomène courant. Depuis le début des années 1990 environ, presque tous les types de processeurs de cartes à puce utilisés dans les systèmes d'accès conditionnel de télévision payante européens, puis américains et asiatiques, ont été rétro-conçus avec succès. Des cartes clones illicites qui décryptent les chaînes de télévision sans revenus pour le diffuseur ont été vendues. L'industrie a dû mettre à jour la technologie des processeurs de sécurité plusieurs fois déjà et le défi est loin d'être relevé.
L’article de O. Kömmerling et al. “Design Principles for Tamper-Resistant Smartcard Processors” USENIX Workshop on Smartcard Technology, 1999 présente des exemples de d’attaques de circuits intégrés et certaines techniques de contremesure.
On peut distinguer deux grandes familles d’attaques : invasives et non-invasives.
Dans le cas d’une attaque non-invasive, la carte attaquée n'est pas physiquement endommagée et l'équipement utilisé dans l'attaque peut généralement être déguisé en un lecteur de carte à puce normal.
En ce qui concerne les attaques invasives, ce sont des attaques physiques par sondage consistant à accéder aux interconnexions de la logique d’un circuit intégré avec une sonde (aiguille métallique positionnée au moyen d’un micromanipulateur sur les pistes métalliques).
La sonde peut être reliée à un oscilloscope (via un amplificateur au besoin) afin de permettre la lecture des données internes manipulées par le circuit cible.
La sonde peut également être pilotée par un générateur de signaux et servir à forcer une valeur logique arbitraire sur un nœud interne du circuit cible (par exemple pour forcer un circuit dans un état donné non sécurisé en fixant la valeur d’un signal de contrôle).
Cette technique d’attaque peut être passive (pour une simple écoute : «eavesdropping» en anglais) et/ou active et générant une erreur dans le circuit.
On recourt généralement à un canon à ions («Focused Ion Beam» (FIB) en anglais) pour accéder aux interconnexions à sonder. Le canon à ions est un instrument d’analyse de défaillance utilisé en microélectronique pour creuser des trous dans les circuits intégrés, couper des pistes d’interconnexion, et (re)créer des contacts électriques entre pistes.
Le mémoire de thèse de doctorat de Dmitry Nedospasov intitulé «Security of the IC backside» décrit des attaques invasives, notamment des techniques linéaires d’extraction de code.
La publication de Johannes Obermaier et Vincent Immler “The past, present, and future of physical security enclosures: From battery-backed monitoring to PUF-based inherent security and beyond” Journal of Hardware and Systems Security, Aug 2018, et celle de
Phil Isaacs et al. “Tamper Proof, Tamper Evident Encryption Technology” Pan Pacific Symposium. SMTA, 2013 présentent des exemples de contre-mesures par enceinte protectrice.
Le code de programme d’un circuit sécurisé comporte plusieurs parties stockées dans ses mémoires Flash ou ROM (il peut être exécuté à partir d’une mémoire ROM, Flash ou RAM). Ce code est protégé contre les relectures sous peine de mettre en péril la sécurité de la gamme de circuits sécurisés considérée.
La connaissance du code permet de mettre au point des attaques matérielles et logicielles. Il est impératif pour un fabricant ou un utilisateur de circuit sécurisé de protéger la confidentialité du code, en empêchant son extraction, ou «dump» en anglais.
L’extraction linéaire de code consiste pour un attaquant à relire le code d’un circuit dans le bon ordre de la première adresse mémoire à la dernière (sinon le code est inexploitable).
La relecture du code d’un circuit est bloquée avant sa commercialisation. D’où le recours par les attaquants aux techniques d’attaques invasives pour réaliser l’extraction linéaire de code.
Il est à noter qu’une extraction linéaire de code peut également permettre d’extraire les clefs secrètes et autres informations confidentielles stockées dans un circuit.
Dans le mémoire de thèse susmentionné, il est mentionné certaines techniques de protection contre l’extraction linéaire de code comme enterrer les signaux pertinents pour la sécurité dans les couches métalliques inférieures du circuit, ajouter des capteurs ou randomiser l’exécution du programme avec une redondance de registres, etc.
Il existe un besoin pour perfectionner encore les procédés de détection d’une tentative d’extraction linéaire du contenu d’une mémoire électronique, notamment en termes de simplicité de mise en œuvre et d’efficacité.
Procédé de détection
L’invention vise à répondre à cet objectif et a pour objet, selon l’un de ses aspects, un procédé de détection d’une tentative d’extraction linéaire d’un code de programme enregistré dans une mémoire d’un circuit électronique, le code comportant des instructions de programme qui, pour être lues par un cœur de microprocesseur, sont chargées séquentiellement via un bus d’instructions dans un registre d’instructions pour le stockage des instructions commandé au moins par un signal d’horloge et un signal de réinitialisation, le chargement de chaque instruction dans le registre d’instructions s’effectuant sur un front du signal d’horloge, le code comprenant des instructions de discontinuité et/ou des instructions dites « marqueurs de sécurité » insérées parmi les instructions de programme de manière à être lues au cours de l’exécution du programme, le procédé comportant le déclenchement d’une action prédéfinie d’alerte, en cas de non-détection d’une instruction de discontinuité ou d’un marqueur de sécurité, selon une règle de surveillance prédéfinie.
On définit les instructions de discontinuité comme l’ensemble des instructions de programme pouvant contrôler le flot d’exécution du programme (branchement conditionnel et inconditionnel, saut, appel et retour de fonction, etc.). Généralement, une instruction de discontinuité rompt l’exécution linéaire du programme, de sorte que l’exécution de cette instruction entraîne le passage à une instruction ayant une adresse non consécutive de celle de ladite instruction de discontinuité.
Par « exécution linéaire » du programme, on entend l’exécution de ses instructions dans l’ordre de leurs adresses mémoire consécutives.
Par « marqueur de sécurité », on entend une instruction particulière insérée dans le code enregistré dans la mémoire en vue de la protéger contre l’extraction linéaire de son contenu. Un marqueur de sécurité a la même structure que les instructions du jeu d’instructions utilisé par le circuit électronique considéré. Le marqueur de sécurité comprend par exemple 32 bits d’information s’il est utilisé dans des circuits utilisant cette taille d’instruction.
L’extraction linéaire du code consiste pour un attaquant à lire successivement les instructions du code.
L’extraction linéaire du code peut comporter le sondage du bus d’instructions et l’activation du signal de réinitialisation de sorte que le cœur du microprocesseur ne lise que des instructions nulles.
Grâce à l’invention, il est possible de détecter aisément une telle attaque d’extraction linéaire de code, notamment par la détection de l’absence d’une instruction de discontinuité ou d’un marqueur de sécurité.
La règle de surveillance prédéfinie peut être la non-détection d’une instruction de discontinuité ou d’un marqueur de sécurité pendant une durée prédéfinie et/ou après qu’un nombre prédéfini d’instructions de programme ont été lues et/ou après un nombre prédéfini de cycles d’horloge.
Marqueurs de sécurité
De préférence, les marqueurs de sécurité sont insérés dans le code avec une périodicité variable. Ceci permet de rendre difficile leur détection et/ou identification par l’attaquant.
La périodicité d’insertion des marqueurs de sécurité peut être pseudo-aléatoire.
Les marqueurs de sécurité sont préférentiellement insérés dans le code de façon que l’exécution des instructions de programme situées entre deux marqueurs de sécurité consécutifs correspond à un nombre de cycles d’horloge inférieur à celui entraînant le déclenchement de l’action prédéfinie d’alerte.
Deux marqueurs de sécurité consécutifs sont de préférence disposés de telle sorte que le nombre de cycles d’horloge entraînant le déclenchement de l’action prédéfinie d’alerte est supérieur au nombre maximal de cycles d’horloge nécessaire à l’exécution des instructions de programme situées entre les deux marqueurs de sécurité.
En effet, le nombre de cycles d’horloge nécessaires à l’exécution d’une instruction peut être variable (et ne peut être connu à l’avance pour certaines d’entre elles). Ainsi, le nombre de cycles d’horloge entraînant le déclenchement de l’action prédéfinie d’alerte est préférentiellement envisagé pour un pire cas, en étant supérieur au nombre maximal de cycles d’horloge nécessaire à l’exécution des instructions de programme situées entre deux marqueurs de sécurité consécutifs.
Au moins un marqueur de sécurité est préférentiellement inséré au début et à la fin du code d’une fonction faisant partie du programme.
Au moins un marqueur de sécurité est préférentiellement inséré à l’adresse de destination d’une instruction de branchement.
Au moins un marqueur de sécurité est préférentiellement inséré au début ou à la fin du code d’une boucle faisant partie du programme.
L’insertion de marqueurs de sécurité dans le cas d’une fonction, d’un branchement ou d’une boucle réduit le nombre d’instructions exécutées entre deux marqueurs de sécurité consécutifs et évite de déclencher l’action prédéfinie d’alerte sans raison.
Dans un mode de réalisation, les marqueurs de sécurité sont codés de sorte à avoir au moins un bit particulier de poids correspondant au même poids que celui d’au moins un bit caractéristique d’une instruction de branchement, le bit particulier ayant la même valeur encodée du bit caractéristique, de sorte à déclencher l’action prédéfinie d’alerte en cas d’une attaque par forçage à la valeur binaire complémentaire du bit caractéristique.
En effet, pour certains codages d’instructions (selon les fabricants), les instructions de branchement possèdent une valeur caractéristique sur un bit particulier.
Si l’on considère, par exemple, un jeu d’instructions codées sur 16 bits (le même raisonnement s’applique également pour les instructions sur 32 et 64 bits), on peut raisonner par exemple en considérant que toutes les instructions de branchement ont leur bit d’indice de poids fort (bit 15 dans ce cas) à la valeur 1. Or ce sont les instructions de branchement qui introduisent des discontinuités lors de l’exécution d’un code (empêchant de ce fait une extraction linéaire).
Ainsi, un attaquant peut réaliser une attaque invasive d’extraction de code linéaire en forçant à 0 ce bit caractéristique (bit 15, de poids fort) des instructions, y compris les instructions de branchement lors de l’exécution du code. Du fait de la mise à zéro de ce bit, les instructions de branchement du code ne sont plus interprétées comme des instructions de branchement. Le pointeur d’instruction (destiné à contenir l’adresse mémoire d’une instruction devant être exécutée) s’incrémente alors de façon à lire successivement toutes les instructions du code (tant que le bit caractéristique est forcé à 0). L’attaquant n’a alors pas besoin de forcer le signal de reset du registre d’instructions. Une telle attaque convient a fortiori au cas où le registre d’instructions ne dispose pas de signal de reset.
Si l’encodage au niveau bit d’un marqueur de sécurité est caractérisé par un bit de poids fort à 0, il ne sera pas corrompu par le forçage à 0 du bit de poids fort. Le procédé de détection est alors inefficace contre l’extraction linéaire par forçage d’un bit (permettant de désactiver les instructions de branchement).
Le choix d’un codage adéquat du marqueur de sécurité permet de garantir l’efficacité du procédé de détection contre le forçage d’un bit à un niveau donné entraînant une vulnérabilité.
En reprenant l’exemple précédent, le fait de choisir un codage du bit de poids fort à 1 pour le marqueur de sécurité (même valeur et même bit caractéristique que pour les instructions de branchement) assure que le forçage de ce bit à 0 empêche le marqueur de sécurité d’être reconnu. En l’absence de détection du marqueur de sécurité, l’action prédéfinie d’alerte est ainsi déclenchée.
Les marqueurs de sécurité peuvent être insérés dans le code lors de la phase de compilation de celui-ci, le code étant ensuite chargé en mémoire lors de la programmation du circuit.
Alternativement, les marqueurs de sécurité sont insérés dans le code lors de l’exécution de ce dernier, en particulier lors de la lecture des instructions de programme depuis la mémoire.
Dans ce cas de figure, la mémoire contient une logique de contrôle dotée d’un bloc logique insérant périodiquement un marqueur de sécurité parmi les instructions de programme lorsqu’elles sont lues.
Le bloc logique envoie notamment une commande de cycle d’attente au cœur du microprocesseur lors du chargement d’un marqueur de sécurité dans le registre d’instructions pour que le cœur du microprocesseur insère un cycle d’attente dans le flot d’exécution lors de la réception du marqueur de sécurité. Dans un autre mode de réalisation, le cœur du microprocesseur est configuré pour reconnaître un marqueur de sécurité et renouveler la demande de lecture de l’instruction qui a été décalée par l’insertion du marqueur de sécurité. Ce mode de fonctionnement permet d’économiser de la place mémoire et permet également une mise en œuvre plus simple du procédé de détection, car le programme n’a pas à être modifié puisqu’aucun marqueur de sécurité n’y est inséré.
De préférence, les marqueurs de sécurité sont différents les uns des autres par leur charge utile («payload »en anglais).Ceci permet de créer de la confusion chez l’attaquant et de rendre plus difficile le contournement du procédé de détection.
Dans un mode de réalisation, les instructions de programme et les marqueurs de sécurité sont stockés sous forme chiffrée dans la mémoire et sont déchiffrés avant leur chargement dans le registre de stockage.
Instructions de discontinuité
Au lieu de détecter l’absence de marqueurs de sécurité, il est possible de détecter l’absence d’instructions de discontinuité. Il n’est alors plus nécessaire d’inclure dans le code de marqueurs de sécurité, ce qui présente un plus faible allongement du temps d’exécution, par rapport à l’utilisation des marqueurs de sécurité dans le programme, étant donné que l’exécution d’un marqueur de sécurité nécessite au moins un cycle d’horloge. De plus, le procédé de détection selon cette variante peut être appliqué sans modification du compilateur.
Dans un mode de réalisation, le procédé comporte, lors d’une étape d’analyse du code avant son chargement dans le registre, l’insertion d’au moins une instruction de discontinuité à exécution linéaire dans une portion du code comprenant des instructions de programme dont l’exécution correspond à un nombre de cycles d’horloge pouvant entraîner le déclenchement de l’action prédéfinie d’alerte. Ceci permet d’éviter le déclenchement d’une fausse alerte, alors qu’il n’y a aucune attaque en cours.
Par « instruction de discontinuité à exécution linéaire », on entend une instruction de discontinuité engendrant une exécution linéaire du programme. Ainsi, l’insertion de l’instruction de discontinuité à exécution linéaire dans ladite portion de code n’affecte pas l’exécution séquentielle des instructions de cette portion de code situées consécutivement dans la mémoire.
L’insertion de l’instruction de discontinuité à exécution linéaire peut s’effectuer lors de la compilation du code, cette instruction étant stockée dans la mémoire et possédant une adresse mémoire. L’instruction de discontinuité à exécution linéaire engendre alors dans ce cas une incrémentation unitaire de l’adresse mémoire des instructions qui la suivent.
Alternativement, l’insertion de l’instruction de discontinuité à exécution linéaire s’effectue après la lecture dans la mémoire des instructions à charger et avant le chargement de ces instructions dans le registre d’instructions. L’instruction de discontinuité à exécution linéaire ne possède alors dans ce cas pas d’adresse mémoire, et engendre un maintien des adresses mémoire des instructions qui la suivent. Cette option permet de ne pas modifier le compilateur, et de ne pas augmenter la surface mémoire.
L’action prédéfinie d’alerte peut comporter l’une au moins des actions suivantes : la réinitialisation du circuit électronique, l’effacement de la mémoire, la remise à zéro de l’adresse de lecture en mémoire, la prise par l’adresse de lecture en mémoire de valeurs non consécutives de façon que l’extraction du code devienne non linéaire, et le saut d’une section de code, notamment d’une section sensible à protéger.
Dans un mode de réalisation, le procédé de détection est mis en œuvre en permanence pour protéger la totalité du code de programme, la première instruction de ce dernier pouvant être une instruction de discontinuité ou un marqueur de sécurité. Dans ce cas, la logique de détection d’une attaque est activée en permanence (et par construction ne peut pas être débrayée).
Dans un autre mode de réalisation, le procédé de détection est mis en œuvre d’une manière paramétrable via la configuration d’un fusible, notamment de type programmable une seule fois (« One Time Programmable » en anglais), ou d’une variable en mémoire non volatile, notamment une mémoire de type Flash ou EEPROM, lors de la phase de programmation du circuit, la valeur mémorisée dans le fusible ou dans la mémoire non-volatile étant lue au démarrage du circuit, en particulier à sa mise sous tension ou à son réveil après réinitialisation, ladite valeur permettant d’activer le procédé de détection, et la première instruction du code de programme étant une instruction de discontinuité ou un marqueur de sécurité, si le procédé est activé. Dans ce cas de mise en œuvre paramétrable, la valeur mémorisée (dans le fusible ou la mémoire non-volatile) est lue au démarrage du circuit (mise sous tension ou réveil après réinitialisation, encore appelée « reset ») et permet soit d’activer le procédé de détection soit de le garder inactif. Ce choix est définitif pour toute la durée d’utilisation du circuit.
Le procédé de détection peut être mis en œuvre pour protéger au moins une portion du code de programme délimitée par une adresse de début et une adresse de fin, le procédé étant activé dès qu’une instruction de programme dont l’adresse est comprise entre l’adresse de début et l’adresse de fin est lue pour être exécutée, étant désactivé dès qu’une instruction de programme n’appartenant pas à ladite portion de code est lue pour être exécutée. Dans ce cas, le procédé de détection pour ladite au moins portion de code est activé en permanence et n’est pas débrayable, i.e. chaque fois que des instructions appartenant à ladite portion de code sont exécutées, le procédé de détection est activé.
Le procédé de détection s’applique pour tout type de mémoire pouvant contenir un code de programme en vue de son exécution par un cœur de microprocesseur.
La mémoire peut être embarquée dans le même circuit intégré que le cœur de microprocesseur exécutant les instructions, par exemple une mémoire embarquée de type Flash ou RAM, ou une mémoire externe de type DRAM.
Circuit électronique
L’invention a encore pour objet, selon un autre de ses aspects, un circuit électronique comportant au moins une mémoire, un cœur de microprocesseur, un bus d’instructions, un bus de lecture, un bus d’adresse et un registre d’instructions pour le stockage des instructions commandé au moins par un signal d’horloge et un signal de réinitialisation, la mémoire étant reliée au registre d’instructions par le bus d’instructions, le registre d’instructions étant relié au cœur du microprocesseur par le bus de lecture, le cœur du microprocesseur comportant un pointeur d’instruction destiné à contenir l’adresse mémoire d’une instruction devant être exécutée, le cœur du microprocesseur étant relié à la mémoire par le bus d’adresse, le circuit étant configuré pour détecter une tentative d’extraction linéaire d’un code de programme enregistré dans la mémoire, le code comportant des instructions de programme qui, pour être lues par le cœur de microprocesseur, sont chargées séquentiellement via le bus d’instructions dans le registre d’instructions sur commande du signal d’horloge, le code comprenant des instructions de discontinuité et/ou des instructions dites « marqueurs de sécurité » insérées parmi les instructions de programme de manière à être lues au cours de l’exécution du programme, le cœur du microprocesseur comportant un circuit de protection contre une tentative d’extraction linéaire apte à déclencher une action prédéfinie d’alerte en cas de non-détection d’une instruction de discontinuité ou d’un marqueur de sécurité selon une règle de surveillance prédéfinie.
Compteur de chargement d’instructions ou de cycles d’horloge
Le circuit de protection comprend préférentiellement un compteur de chargement d’instructions ou de cycles d’horloge, le compteur de chargement d’instructions ou de cycles d’horloge étant de préférence décroissant, notamment configuré pour être décrémenté à chaque chargement d’instruction dans le registre d’instructions ou à chaque cycle d’horloge, le compteur de chargement d’instructions ou de cycles d’horloge étant notamment configuré pour être périodiquement réinitialisé à une valeur paramétrable, la réinitialisation du compteur de chargement d’instructions ou de cycles d’horloge étant en particulier régulièrement effectuée par un marqueur de sécurité avant d’atteindre un seuil d’alarme, notamment zéro, le circuit de protection étant préférentiellement configuré pour déclencher l’action prédéfinie d’alerte lorsque le compteur de chargement d’instructions ou de cycles d’horloge atteint le seuil d’alarme.
Compteur d’instructions de continuité
Dans un mode de réalisation, le circuit selon l’invention comporte un compteur d’instructions de continuité configuré pour être décrémenté à chaque exécution d’une instruction de continuité, le compteur d’instructions de continuité étant préférentiellement configuré pour être périodiquement réinitialisé à une valeur paramétrable, la réinitialisation du compteur d’instructions de continuité étant régulièrement effectuée par l’exécution d’une instruction de discontinuité avant d’atteindre un seuil d’alarme, notamment zéro, le circuit de protection étant configuré pour déclencher l’action prédéfinie d’alerte lorsque le compteur d’instructions de continuité atteint le seuil d’alarme.
Par « instruction de continuité », on entend une instruction engendrant une exécution linéaire du programme et qui n’est pas une instruction de discontinuité.
La valeur paramétrable de réinitialisation du compteur d’instructions de continuité peut être fixée soit lors d’une phase d’initialisation qui précède l’exécution d’un programme, soit à la volée lors de l’exécution du programme.
Alternativement, ce compteur est réinitialisé à une valeur fixée définitivement à la conception matérielle du circuit.
Dans le cas où le compteur d’instructions de continuité atteint le seuil d’alarme, une absence d’instruction de discontinuité est détectée, et l’action prédéfinie d’alerte est déclenchée.
En variante, le compteur d’instructions de continuité est croissant au lieu d’être décroissant.
Le compteur d’instructions de continuité peut être situé dans le cœur du microprocesseur, en particulier dans le circuit de protection. Alternativement, il est situé dans le cœur du microprocesseur en dehors du circuit de protection. Il peut également être situé en dehors du cœur du microprocesseur, par exemple entre la mémoire et le cœur.
Il est possible d’avoir plusieurs compteurs répartis à différents emplacements. L’intérêt est de contrer une attaque désactivant le signal utilisé par le compteur de sorte que ce dernier reste gelé et n’est plus capable de détecter d’attaque. L’utilisation de plusieurs compteurs avec détection de l’action prédéfinie d’alerte si les compteurs prennent des valeurs différentes permet de contrecarrer ce genre d’attaque. En effet, la multiplicité des compteurs et leurs différents emplacements complique la tâche à l’attaquant qui devra tromper chacun des compteurs.
L’information qu’une instruction a été exécutée peut provenir de n’importe quelle source d’information interne : par exemple un signal de contrôle, un signal d’état, des variations de l’adresse d’instructions.
Bloc d’insertion d’instructions de discontinuité à exécution linéaire
Le circuit selon l’invention peut comporter un bloc d’insertion d’instructions de discontinuité à exécution linéaire, ce bloc étant un circuit situé hors de la mémoire, communiquant avec celle-ci et avec le registre d’instructions, ce bloc étant configuré pour insérer au moins une instruction de discontinuité à exécution linéaire dans une portion du code lu comprenant des instructions de programme dont l’exécution correspond à un nombre de cycles d’horloge pouvant entraîner le déclenchement de l’action prédéfinie d’alerte. Ceci permet d’éviter le déclenchement d’une fausse alerte, alors qu’il n’y a aucune attaque en cours, notamment lorsque la valeur de réinitialisation du compteur d’instructions de continuité est fixe, en réinitialisant le compteur avant d’atteindre le seuil d’alarme.
Le bloc d’insertion d’instructions de discontinuité à exécution linéaire est alternativement intégré à la mémoire.
Une analyse du programme préalablement à son chargement dans la mémoire programme du circuit permet un choix adéquat de la valeur de réinitialisation du compteur d’instructions de continuité si cette dernière est configurable, ou de déterminer la nécessité d’insérer des instructions de discontinuité à exécution linéaire et où les placer convenablement. Si la valeur de réinitialisation du compteur d’instructions de continuité est fixe et n’est pas assez élevée, il est probablement utile d’insérer au moins une instruction de discontinuité à exécution linéaire dans les portions de code comportant une longue séquence d’instructions de continuité susceptible de déclencher une fausse alerte. Une alternative est l’ajout d’un bloc matériel d’insertion d’instructions de discontinuité à exécution linéaire tel que défini ci-avant.
Compteur d’instructions de discontinuité à exécution linéaire
Dans un mode de réalisation, outre le compteur d’instructions de continuité, le circuit selon l’invention comporte un compteur d’instructions de discontinuité à exécution linéaire configuré pour être décrémenté à chaque exécution d’une instruction de discontinuité à exécution linéaire, le compteur d’instructions de discontinuité à exécution linéaire étant préférentiellement configuré pour être périodiquement réinitialisé à une valeur paramétrable, la réinitialisation du compteur d’instructions de discontinuité à exécution linéaire étant régulièrement effectuée par l’exécution d’une instruction de discontinuité à exécution non linéaire avant d’atteindre un seuil d’alarme, notamment zéro, le circuit de protection étant configuré pour déclencher l’action prédéfinie d’alerte lorsque le compteur d’instructions de discontinuité à exécution linéaire atteint le seuil d’alarme.
Bien entendu, une « instruction de discontinuité à exécution non linéaire », par opposition à l’instruction de discontinuité à exécution linéaire, est une instruction de discontinuité engendrant une variation non-linéaire de l’adresse d’instructions. Autrement dit, l’adresse d’instructions ne s’incrémente pas de manière unitaire à la suite de l’exécution de l’instruction de discontinuité à exécution non linéaire.
La valeur paramétrable de réinitialisation du compteur d’instructions de discontinuité à exécution linéaire peut être fixée soit lors d’une phase d’initialisation qui précède l’exécution d’un programme, soit à la volée lors de l’exécution du programme.
Alternativement, le compteur d’instructions de discontinuité à exécution linéaire est réinitialisé à une valeur fixée définitivement à la conception matérielle du circuit.
En variante, le compteur d’instructions de discontinuité à exécution linéaire est croissant au lieu d’être décroissant.
L’information qu’une instruction est une instruction de discontinuité peut provenir de n’importe quelle source d’information interne : par exemple un signal de contrôle, un signal d’état, des variations de l’adresse d’instructions. En particulier, l’information qu’une instruction de discontinuité engendre une exécution linéaire peut provenir idéalement des variations de l’adresse d’instructions. Néanmoins, cette information peut être croisée avec d’autres sources d’information : par exemple un signal de contrôle, un signal d’état. Par exemple, sur le cœur cv32e40p (jeu d’instructions RISCV), il existe un signal “branch_taken” permettant d’identifier lors de l’exécution d’une instruction de branchement si son exécution est linéaire ou non.
Dans le cas où le compteur d’instructions de discontinuité à exécution linéaire atteint le seuil d’alarme, une absence d’instruction de discontinuité engendrant une variation non-linéaire de l’adresse d’instructions est détectée, et l’action prédéfinie d’alerte est déclenchée.
Le compteur d’instructions de discontinuité à exécution linéaire permet entre autres de détecter des attaques consistant à injecter dans le cœur uniquement des instructions de discontinuité engendrant une exécution linéaire, par exemple une instruction de branchement dont la condition n’est jamais remplie. Ce type d’attaque peut désactiver le signal d’autorisation d’écriture (write_enable) du registre d’instructions pour que l’instruction contenue dans le registre (qui est dans ce cas une instruction de discontinuité à exécution linéaire) y soit mémorisée tant que le signal d’autorisation d’écriture est désactivé. Le compteur d’instructions de continuité seul ne pourra détecter ce genre d’attaques, étant donné qu’il est réinitialisé en permanence par l’instruction de discontinuité mémorisée.
Le compteur d’instructions de discontinuité à exécution linéaire permet également de détecter des attaques consistant à forcer l’adresse d’instructions à varier linéairement, par exemple une attaque consistant à forcer le signal de pilotage du multiplexeur fournissant l’adresse d’instructions, de manière à sélectionner l’entrée engendrant une variation linéaire de l’adresse d’instructions, peu importe l’instruction exécutée dans le cœur. En effet, cette attaque a pour effet que toutes les instructions de discontinuité sont à exécution linéaire. Le compteur d’instructions de continuité seul ne peut détecter une telle attaque, étant réinitialisé à chaque instruction de discontinuité entrant dans le cœur. Cependant, le compteur d’instructions de discontinuité à exécution linéaire ne sera jamais réinitialisé et se décrémentera à chaque instruction de discontinuité (à exécution linéaire), donc l’attaque sera détectée.
Compteur de cycles
Outre le compteur d’instructions de continuité, le circuit selon l’invention peut comporter un compteur de cycles destiné à détecter une absence d’exécution d’instructions, configuré pour s’incrémenter à chaque cycle d’horloge, la réinitialisation du compteur de cycles, notamment à zéro, étant régulièrement effectuée par l’exécution d’une instruction avant d’atteindre un seuil d’alarme, notamment une valeur paramétrable, le circuit de protection étant configuré pour déclencher l’action prédéfinie d’alerte lorsque le compteur de cycles atteint le seuil d’alarme.
Le seuil d’alarme de ce compteur peut être un seuil défini à partir des spécifications du cœur, en prenant en compte le nombre de cycles maximal nécessaire à l’exécution d’une instruction du code. Si ce seuil est atteint, il y a détection d’une absence d’exécution d’instructions.
Le compteur de cycles se réinitialise à chaque instruction exécutée (à partir du même signal que celui décrémentant le compteur d’instructions de continuité).
Le compteur de cycles peut être utilisé en combinaison avec le compteur d’instructions de continuité et éventuellement le compteur d’instructions de discontinuité à exécution linéaire.
Dans le cas d’une attaque désactivant le signal contenant l’information qu’une instruction a été exécutée (signal interne pouvant être désactivé communément avec le signal d’autorisation d’écriture du registre d’instructions), le compteur d’instructions de continuité ne se décrémentera pas, ni le compteur d’instructions de discontinuité à exécution linéaire. Donc, le compteur d’instructions de continuité seul ou combiné le cas échéant avec le compteur d’instructions de discontinuité à exécution linéaire ne peut détecter ce genre d’attaque. Toutefois, le compteur de cycles détectera l’absence d’exécution d’instructions et l’action prédéfinie d’alerte sera déclenchée afin de signaler l’attaque en cours.
Compteur de longueur de séquence d’exécution linéaire
Dans un mode de réalisation, le circuit selon l’invention comporte un compteur de longueur de séquence d’exécution linéaire destiné à détecter une séquence d’instructions de continuité et/ou de discontinuité à exécution linéaire de longueur dépassant une longueur donnée, configuré pour s’incrémenter à chaque exécution d’une instruction ou à chaque cycle d’horloge, la réinitialisation, notamment à zéro, du compteur de longueur de séquence d’exécution linéaire étant régulièrement effectuée par la variation d’au moins un signal du cœur du microprocesseur indiquant la fin d’exécution d’une séquence d’exécution linéaire avant d’atteindre un seuil d’alarme, le circuit de protection étant configuré pour déclencher l’action prédéfinie d’alerte lorsque le compteur de séquence d’exécution linéaire atteint le seuil d’alarme.
Le compteur de longueur de séquence d’exécution linéaire permet de détecter les séquences d’exécution linéaire de longueur démesurée au regard du jeu d’instructions utilisé.
Ce compteur mesure la longueur des séquences d’exécution linéaire. En effet, le nombre de fois que sont chargées des instructions depuis la mémoire de façon linéaire est compté.
La variante avec compteur de longueur de séquence d’exécution linéaire ne nécessite plus l’ajout de nouvelles instructions. Il s’agit d’une détection par observation seulement. Ainsi, le temps d’exécution et la taille du programme en mémoire ne sont pas modifiés. En contrepartie, la latence de détection d’une attaque sera plus importante.
La variante avec compteur de longueur de séquence d’exécution linéaire permet, entre autres, de détecter toutes les attaques précédemment décrites (activation du reset du registre d’instructions, mémorisation d’une instruction dans le registre d’instructions, forçage de variation linéaire de l’adresse d’instructions, etc.).
Ledit au moins un signal du cœur du microprocesseur indiquant la fin d’exécution d’une séquence d’exécution linéaire peut provenir de l’observation de l’adresse de lecture transmise par le cœur du microprocesseur à la mémoire.
Le seuil d’alarme peut être une valeur paramétrable ou fixée définitivement à la conception matérielle du circuit. Dans le cas où le seuil est une valeur paramétrable, il peut être fixé à la compilation du programme ou à la volée lors de l’exécution du programme (le seuil peut être adapté à chaque portion de code, de manière à assurer une faible latence de détection).
Le seuil d’alarme du compteur de longueur de séquence d’exécution linéaire peut être fixé de manière à n’engendrer aucune détection sur l’exécution normale de programmes représentatifs du jeu d’instructions sélectionné.
Si ce seuil est atteint, une séquence d’exécution linéaire démesurément longue est détectée.
Le compteur de longueur de séquence d’exécution linéaire est alternativement descendant (au lieu d’être ascendant).
En plus de mesurer la longueur des séquences d’exécution linéaire à partir des variations de l’adresse d’instructions, il est possible de vérifier la cohérence des variations de l’adresse d’instructions avec la variation d’autres signaux du cœur, par exemple à partir des variations du signal de pilotage du multiplexeur fournissant l’adresse d’instructions, d’un signal d’état ou de contrôle, etc.
Le compteur de longueur de séquence d’exécution linéaire peut avoir différents emplacements dans le circuit.
Il peut être branché sur le bus d’adresse d’instructions. Ainsi, il est possible de compter la longueur d’une séquence d’exécution linéaire en lisant l’adresse (incrément unitaire quand des adresses successives se suivent).
Le compteur de longueur de séquence d’exécution linéaire peut être branché sur les signaux internes du cœur. Ainsi, il est possible de compter la longueur d’une séquence d’exécution linéaire en observant ces signaux, par exemple tant que la commande du multiplexeur d’adresse est maintenue en sélectionnant l'entrée "incrémentation linéaire de l'adresse", la séquence d’exécution linéaire perdure.
Le compteur de longueur de séquence d’exécution linéaire peut être branché sur le bus d’instructions. Ainsi, il est possible de compter la longueur d’une séquence d’exécution linéaire en observant des bits spécifiques de l'instruction (par exemple bits des champs funct3 et opcode du code d’une instruction pour cœur RISC-V) de façon à savoir s'il s'agit, ou non, d'une instruction de discontinuité.
La mémoire peut être de type Flash, ROM, RAM ou DRAM. Dans ce dernier cas, la mémoire est externe, c’est-à-dire non embarquée dans le même circuit intégré que le cœur de microprocesseur exécutant les instructions.
Le circuit peut comprendre un circuit de décryptage situé entre la mémoire et le registre d’instructions pour déchiffrer les instructions de programme et les marqueurs de sécurité avant leur chargement dans ledit registre. Cela s’applique au cas où les instructions de programme et les marqueurs de sécurité sont stockés sous forme chiffrée dans la mémoire.
Dans un mode de réalisation, au moins une portion du code de programme délimitée par une adresse de début et une adresse de fin est protégée contre l’extraction linéaire par le circuit de protection, l’adresse de début et l’adresse de fin étant mémorisées à la programmation du circuit dans une mémoire non-volatile protégée contre l’effacement et la modification.
Le circuit de protection comporte de préférence des registres de chargement desdites adresses de début et de fin, dans lesquels lesdites adresses sont chargées lors du démarrage du circuit, le circuit de protection étant notamment configuré pour déterminer si l’instruction dont l’adresse est contenue dans le pointeur d’instruction appartient à ladite au moins une portion de code par la comparaison de cette adresse avec les adresses de début et de fin. Si c’est le cas, le procédé de détection est activé. Le choix des portions de code protégées peut porter, par exemple, sur la phase de démarrage (phase de boot) du circuit et/ou sur les parties du code mettant œuvre des fonctions de sécurité (utilisation d’outils cryptographiques, par exemple).
Dans un mode de réalisation, le circuit comporte un circuit dit « chien de garde » («watchdog» en anglais) servant à redémarrer le circuit en cas de dysfonctionnement du programme, le circuit chien de garde comprenant un compteur de chien de garde incrémenté au front d’une horloge fournie par un oscillateur interne au circuit, le circuit chien de garde étant configuré en moderesetde sorte à émettre un signal de remise à zéro du circuit lorsque le compteur de chien de garde atteint une valeur prédéfinie, le compteur de chien de garde étant remis à zéro périodiquement par l’exécution d’une instruction de réinitialisation de ce compteur.
Le circuit peut comporter un fusible matériel permettant une activation permanente du circuit chien de garde, de sorte que lorsque le fusible est grillé lors de la programmation du circuit, le circuit chien de garde s’active en permanence en modereset.
L’invention a également pour objet, selon un autre de ses aspects, l’utilisation du circuit électronique comportant le fusible matériel permettant une activation permanente du circuit chien de garde, le fusible étant grillé et les instructions de réinitialisation du compteur de chien de garde étant utilisées comme marqueurs de sécurité.
Procédé de protection
L’invention a encore pour objet, selon un autre de ses aspects, un procédé de protection d’un code de programme comportant l’insertion dans ce code d’instructions de discontinuité ou de marqueurs de sécurité pour la mise en œuvre du procédé de détection selon l’invention.
Dans un mode de réalisation, ladite insertion s’effectue lors de la programmation du code.
Dans un autre mode de réalisation, ladite insertion s’effectue lors ou à l’issue de la compilation du code.
Alternativement, ladite insertion s’effectue après la lecture dans la mémoire stockant le code des instructions à charger et avant le chargement de ces instructions dans le registre d’instructions.
L’invention pourra être mieux comprise à la lecture de la description détaillée qui va suivre, d’exemples non limitatifs de mise en œuvre de celle-ci, et à l’examen du dessin annexé, sur lequel :
La représente de façon schématique un exemple de circuit de l’état de la technique, non protégé contre l’extraction linéaire du code contenu dans la mémoire du circuit ;
La est une vue analogue à la représentant schématiquement un exemple d’attaque d’extraction linéaire du code ;
La est une vue similaire à la illustrant schématiquement un décryptage des instructions du code ;
La est une vue analogue à la représentant schématiquement un premier exemple de circuit selon l’invention ;
La représente schématiquement un deuxième exemple de circuit selon l’invention avec une logique de contrôle modifiée de la mémoire ;
La montre schématiquement un exemple de portion de code protégée selon l’invention ;
La représente schématiquement un appel de fonction au sein d’un code risquant de déclencher une fausse alerte ;
La est analogue à la avec ajout de marqueurs de sécurité pour éviter le déclenchement d’une fausse alerte ;
La représente schématiquement un branchement au sein d’un code risquant de déclencher une fausse alerte ;
La est analogue à la avec ajout de marqueurs de sécurité pour éviter le déclenchement d’une fausse alerte ;
La représente schématiquement une boucle au sein d’un code risquant de déclencher une fausse alerte ;
La est analogue à la avec ajout de marqueurs de sécurité pour éviter le déclenchement d’une fausse alerte ;
La représente schématiquement un troisième exemple de circuit selon l’invention dans lequel le registre d’instructions fait partie du cœur de microprocesseur ;
La illustre schématiquement un quatrième exemple de circuit selon l’invention dans lequel la mémoire est externe ;
La représente un cinquième exemple de circuit selon l’invention identique à celui de la mais sans circuit de décryptage ;
La illustre schématiquement un exemple de portion de code dans lequel on insère une instruction de discontinuité à exécution linéaire ;
La représente schématiquement deux exemples de portions de code dans lesquels on insère une instruction de discontinuité à exécution linéaire dans (exemple de droite) et en dehors de la mémoire sauvegardant le code (exemple de gauche) ;
La illustre schématiquement un sixième exemple de circuit selon l’invention avec un compteur d’instructions de continuité et un bloc d’insertion d’instructions de discontinuité à exécution linéaire ;
La représente schématiquement un exemple de séquence d’instructions à exécuter à la suite d’une attaque de mémorisation dans le registre d’instructions d’une instruction de discontinuité engendrant une exécution linéaire ;
La illustre schématiquement un septième exemple de circuit selon l’invention avec un compteur d’instructions de discontinuité à exécution linéaire et un exemple d’attaque de forçage du signal de pilotage du multiplexeur fournissant l’adresse d’instructions ;
La représente schématiquement un huitième exemple de circuit selon l’invention avec un compteur de cycles et un exemple d’attaque bloquant le signal qu’une instruction a été exécutée ; et
La illustre schématiquement un neuvième exemple de circuit selon l’invention montrant différents emplacements d’un compteur de longueur de séquence d’exécution linéaire.
 Description détaillée
On a illustré schématiquement à la un circuit électronique 1 selon l’état de la technique. Le circuit 1 comporte une mémoire 10, un cœur de microprocesseur 14, un bus d’instructions 11, un bus de lecture 13, un bus d’adresse 15 et un registre d’instructions 12 pour le stockage des instructions, commandé par un signal d’horlogeclket un signal de réinitialisationresetpour une remise à zéro du contenu du registre d’instructions 12.
La mémoire 10 est reliée au registre d’instructions 12 par le bus d’instructions 11.
La mémoire 10 contient un code de programme dont les instructions transitent de la mémoire 10, via le bus d’instructions 11, pour être chargées séquentiellement dans le registre d’instructions 12 sur un front du signal d’horlogeclk, par exemple sur le front montant de l’horloge.
Le registre d’instructions 12 est relié au cœur du microprocesseur 14 par le bus de lecture 13 via lequel transite l’instruction devant être exécutée vers le cœur du microprocesseur 14.
Le cœur du microprocesseur 14 comporte un pointeur d’instruction 140 destiné à contenir l’adresse mémoire de l’instruction devant être exécutée.
Le cœur du microprocesseur 14 est relié à la mémoire 10 par le bus d’adresse 15. Le bus d’adresse contient l’adresse mémoire de l’instruction devant être exécutée à la suite de l’instruction en cours d’exécution.
La est une vue analogue à la représentant schématiquement un exemple d’attaque d’extraction linéaire du code contenu dans la mémoire 10.
Dans une étape liminaire, l’attaquant doit trouver les interconnexions du circuit 1.
Dans une première étape, l’attaquant pose une sonde 200 sur le signal deresetpour forcer la remise à zéro du registre d’instructions 12. Ainsi, le cœur du microprocesseur 14 reçoit des instructions nulles : 00000 … 0 qu’il interprète comme des instructions sans effet (no operation, ounop). Le cœur du microprocesseur 14 passe donc à la lecture de l’instruction suivante et ainsi de suite. Par-là, l’attaquant réussit à provoquer une lecture linéaire et progressive du code programme contenu dans la mémoire 10, instruction après instruction.
Dans une deuxième étape, l’attaquant trouve les interconnexions du bus d’instructions 11 et y pose une ou plusieurs sondes 201. Ainsi, l’attaquant parvient à lire les instructions du code successivement et bit après bit.
Dans une troisième étape optionnelle, l’attaquant pose une sonde 202 sur la borne de signal d’horlogeclkpour savoir à quel moment lire les données sur le bus d’instructions 11.
Il s’agit d’un exemple d’attaque extrêmement difficile à contrer dans la mesure où l’attaquant remplace par des instructions nulles (nops) dans le registre d’instructions 12 toutes les instructions lues en mémoire, par le forçage de la remise à zéro du registre d’instructions 12.
Par ailleurs, les codes des circuits sécurisés sont généralement chiffrés. Cependant, cela ne les protège pas pour autant contre l’extraction linéaire par sondage, car il faut bien que le code soit déchiffré avant son exécution.
La est une vue similaire à la , illustrant schématiquement un circuit de décryptage 16 des instructions du code. Comme montré sur la figure, les sondes 200, 201, 202 sont placées en aval du circuit de décryptage 16, ce qui permet à l’attaquant de lire les instructions déjà décryptées.
La est une vue analogue à la représentant schématiquement un premier exemple de circuit 1 selon l’invention.
Le circuit 1 possède la même architecture que celle décrite ci-avant, à savoir une mémoire 10, un cœur de microprocesseur 14, un bus d’instructions 11, un bus de lecture 13, un bus d’adresse 15 et un registre d’instructions 12 pour le stockage des instructions commandé par un signal d’horlogeclket un signal de réinitialisationresetpour une remise à zéro du contenu du registre d’instructions 12. Le circuit de décryptage 16 reste optionnel et il est présent dans le cas où les instructions sont stockées dans la mémoire sous forme chiffrée. La illustre le circuit de la sans circuit de décryptage 16.
Dans un mode de réalisation représenté à la , le registre d’instructions 12 fait partie du cœur de microprocesseur 14.
La mémoire 10 est par exemple de type Flash, ROM, RAM ou DRAM. Dans ce dernier cas représenté à la , la mémoire 10 est externe, c’est-à-dire non embarquée dans le même circuit électronique 1 que le cœur de microprocesseur 14 exécutant les instructions.
Le code du programme enregistré dans la mémoire 10 est modifié pour comprendre des instructions de protection dites « marqueurs de sécurité » insérées parmi les instructions de programme de manière à être lues au cours de l’exécution du programme. Par exemple, les marqueurs de sécurité sont insérés dans le code avec une périodicité variable pour rendre difficile leur détection et/ou identification. Afin de tromper un observateur et rendre encore plus compliquée la détection et/ou l’identification des marqueurs de sécurité, il est possible qu’ils soient différents les uns des autres, notamment par leur charge utile.
Le cœur du microprocesseur 14 comporte un circuit de protection 18 contre une tentative d’extraction linéaire, apte à déclencher une action prédéfinie d’alerte 300 en cas de non-détection d’un marqueur de sécurité selon une règle de surveillance prédéfinie.
La règle de surveillance prédéfinie peut être la non-détection d’un marqueur de sécurité pendant une durée prédéfinie et/ou après qu’un nombre prédéfini d’instructions de programme ont été lues.
Le circuit de protection 18 comprend par exemple, comme illustré, un compteur de chargement d’instructions ou de cycles d’horloge 20 décroissant, configuré pour être décrémenté à chaque chargement d’instruction dans le registre d’instructions 12 ou à chaque cycle d’horloge, et qui est périodiquement réinitialisé à une valeur positive paramétrable.
La réinitialisation du compteur de chargement d’instructions ou de cycles d’horloge 20 est régulièrement effectuée par un marqueur de sécurité avant d’atteindre zéro. Si le compteur de chargement d’instructions ou de cycles d’horloge 20 atteint zéro, le circuit de protection 18 est configuré pour déclencher l’action prédéfinie d’alerte 300.
Le compteur de chargement d’instructions ou de cycles d’horloge 20 peut alternativement être incrémenté à partir de zéro auquel cas, l’action prédéfinie d’alerte 300 est déclenchée lorsque le compteur de chargement d'instructions ou de cycles d’horloge 20 atteint une valeur prédéfinie (paramétrable en option). La valeur prédéfinie paramétrable peut être une valeur contenue dans la charge utile du marqueur de sécurité précédemment exécuté.
L’action prédéfinie d’alerte 300 peut être : la réinitialisation du circuit 1, l’effacement de la mémoire 10, la remise à zéro de l’adresse de lecture en mémoire (auquel cas l’attaquant lit indéfiniment la même séquence courte d’instruction initiale), l’assignation à l’adresse de lecture en mémoire de valeurs non consécutives incohérentes, notamment par le chargement à chaque cycle d’horloge d’une valeur aléatoire dans le registre d’adresse en mémoire (auquel cas l’extraction de code devient non linéaire), le saut d’une section de code, notamment d’une section sensible à protéger (auquel cas l’attaquant extrait un code inutile), etc.
Les marqueurs de sécurité peuvent être insérés dans le code lors de la phase de compilation de celui-ci, le code étant ensuite chargé en mémoire lors de la programmation du circuit.
Alternativement, les marqueurs de sécurité sont insérés dans le code lors de l’exécution de ce dernier, en particulier lors de la lecture des instructions de programme depuis la mémoire.
Ce mode de réalisation est représenté à la où la mémoire 10 contient une logique de contrôle dotée d’un bloc logique 100 insérant périodiquement un marqueur de sécurité parmi les instructions de programme lorsqu’elles sont lues. Dans ce cas, le code stocké dans la mémoire 10 ne comprend pas de marqueur de sécurité et la logique de contrôle de la mémoire est modifiée de sorte à insérer les marqueurs de sécurité à la volée lors de la lecture des instructions de programme depuis la mémoire.
Le bloc logique 100 envoie une commande de cycle d’attente 115 au cœur du microprocesseur 14 lors du chargement d’un marqueur de sécurité dans le registre d’instructions 12 pour que le cœur du microprocesseur 14 insère un cycle d’attente dans le flot d’exécution lors de la réception du marqueur de sécurité. Ainsi, le cœur du microprocesseur 14 est prévenu de la réception d’un marqueur de sécurité plutôt que de l’instruction dont il a fourni l’adresse via le bus d’adresse 15.
La illustre un exemple schématique de portion de code protégé selon l’invention.
Les marqueurs de sécurité sont de préférence insérés dans le code avec une périodicité variable, de façon que l’exécution des instructions de programme situées entre deux marqueurs de sécurité consécutifs correspond à un nombre de cycles d’horloge inférieur à celui entraînant le déclenchement de l’action prédéfinie d’alerte.
Il à noter que le nombre de cycles d’horloge nécessaire à l’exécution d’une instruction peut être variable (et ne peut être connu à l’avance pour certaines d’entre elles). Le nombre de cycles d’horloge entraînant le déclenchement de l’action prédéfinie d’alerte est donc préférentiellement envisagé pour un pire cas, en étant supérieur au nombre maximal de cycles d’horloge nécessaire à l’exécution des instructions de programme situées entre deux marqueurs de sécurité consécutifs.
Comme toute instruction binaire, un marqueur de sécurité comprend essentiellement deux champs : l’opcodequi permet d’identifier le marqueur, et la charge utile que l’on peut par exemple faire varier pour tromper un observateur, rendant le contournement de la détection de l’attaque très difficile. Par exemple, il est possible de fixer dans la charge utile la valeur initiale prise par le compteur ou d’imposer une valeur de charge utile suivant une logique particulière (croissante, décroissante, alternée, valeur unique, etc.) afin d’introduire une variabilité permettant de tromper l’attaquant. L’utilité de la charge utile est en effet de pouvoir rendre variable de façon optionnelle le nombre maximal de cycles d’horloge à respecter entre deux marqueurs de sécurité sous peine de déclencher l’action prédéfinie d’alerte.
Par ailleurs, si un code de programme comprend des instructions particulières comme un appel de fonction, un branchement (saut), une boucle, etc., l’insertion des marqueurs de sécurité doit se faire en veillant à ne pas déclencher de fausse alerte.
La représente schématiquement un appel de fonction au sein d’un code de ce type.
La fonction 2 est imbriquée dans le code « Fonction 1 » et est appelée entre les instructions 7 et 8.
L’exécution de la fonction 2 entraîne l’accroissement du nombre d’instructions exécutées (et donc du nombre de cycles d’horloge écoulés) entre deux marqueurs de sécurité, au risque de déclencher l’action prédéfinie d’alerte 300 sans raison si aucune précaution n’est prise.
Une solution à ce problème est illustrée à la où deux marqueurs de sécurité sont ajoutés respectivement au début et à la fin du code la fonction 2, réduisant ainsi le nombre de cycles d’horloge séparant deux marqueurs de sécurité en dessous du seuil d’activation de l’action prédéfinie d’alerte 300.
La représente schématiquement un branchement au sein d’un code risquant de déclencher une fausse alerte.
Dans l’exemple illustré, le branchement se fait de l’instruction 3 à l’instruction 7, soit un saut de 4 adresses.
A l’exécution, l’instruction de saut prévient l’exécution du marqueur de sécurité placé avant l’instruction 6. Cela entraîne l’accroissement du nombre d’instructions exécutées (et donc du nombre de cycles d’horloge écoulés) entre deux marqueurs de sécurité au risque de déclencher l’action prédéfinie d’alerte 300 sans raison.
Une solution à ce problème est illustrée à la où un marqueur de sécurité est inséré à l’adresse de destination de l’instruction de branchement.
La représente schématiquement une boucle au sein d’un code risquant de déclencher une fausse alerte.
Dans l’exemple illustré, la validité d’une condition suivant l’instruction 8 fait reboucler la lecture à l’adresse de l’instruction 5 (ce qui correspond à un saut de 4 adresses en arrière).
En fait, la boucle est exécutée tant que la condition est vérifiée, à chaque fois les instructions 5 à 8 sont exécutées une nouvelle fois entraînant l’accroissement du nombre d’instructions exécutées (et donc du nombre de cycles d’horloge écoulés) entre deux marqueurs de sécurité au risque de déclencher l’action prédéfinie d’alerte 300 sans raison.
Une solution à ce problème est illustrée à la où un marqueur de sécurité est ajouté en tête de la boucle. Le saut vers le début de la boucle correspond dans ce cas à 5 adresses en arrière.
Le marqueur de sécurité peut alternativement être ajouté en fin de la boucle.
Sans avoir à ajouter de marqueurs de sécurité dans le code, il est également possible de détecter l’absence d’instructions de discontinuité, selon le même principe.
En effet, au lieu d’avoir un compteur de chargement d’instructions ou de cycles d’horloge 20, le circuit 1, notamment le circuit de protection 18 du microprocesseur 14, peut comporter un compteur d’instructions de continuité 21, comme illustré à la . Ce compteur 21 peut être configuré pour être décrémenté à chaque exécution d’une instruction de continuité, le compteur d’instructions de continuité 21 étant préférentiellement configuré pour être périodiquement réinitialisé à une valeur paramétrable, la réinitialisation du compteur d’instructions de continuité 21 étant régulièrement effectuée par l’exécution d’une instruction de discontinuité avant d’atteindre un seuil d’alarme, notamment zéro, le circuit de protection 18 étant configuré pour déclencher l’action prédéfinie d’alerte 300 lorsque le compteur d’instructions de continuité 21 atteint le seuil d’alarme.
Si l’on considère l’exemple de la portion de code représentée à la et que l’on prend comme exemple un compteur d’instructions de continuité 21 décroissant, initialisé à 4 et ayant un seuil d’alarme à zéro, ce compteur sera réinitialisé par l’instruction de discontinuité à exécution linéaire à l’adresse 6. Il va décroître lorsque les instructions 7 à 10 seront exécutées, et arrivera à zéro à l’exécution de l’instruction 10, ce qui va déclencher une fausse alerte puisqu’il n’y a aucune attaque. Pour éviter cela, il est utile soit d’augmenter la valeur initiale du compteur 21, soit d’insérer une instruction de discontinuité à exécution linéaire entre les instructions de programme 7 à 10 dont l’exécution correspond à un nombre de cycles d’horloge pouvant entraîner le déclenchement de l’action prédéfinie d’alerte, sans raison. En l’occurrence, l’instruction de discontinuité à exécution linéaire est insérée entre les instructions 9 et 10.
La montre deux possibilités pour l’insertion d’une instruction de discontinuité à exécution linéaire dans la portion de code de la : soit lors de la compilation du code ( à droite), soit hors de la mémoire et avant le chargement des instructions dans le registre d’instructions ( à gauche).
Lorsque l’instruction de discontinuité à exécution linéaire est insérée lors de la compilation du code, elle est stockée dans la mémoire et possède une adresse mémoire. Dans l’exemple illustré sur la à droite, l’instruction de discontinuité à exécution linéaire est insérée entre les instructions 9 et 10. Elle prend alors l’adresse mémoire 10 et entraîne dans ce cas une incrémentation unitaire de l’adresse mémoire des instructions qui la suivent, comme montré sur la de droite.
Lorsque l’instruction de discontinuité à exécution linéaire est insérée hors de la mémoire et avant le chargement des instructions dans le registre d’instructions, elle ne possède alors dans ce cas pas d’adresse mémoire, et engendre un maintien des adresses mémoire des instructions qui la suivent. Sur la de gauche, l’instruction de discontinuité à exécution linéaire est insérée entre les instructions 9 et 10 au moment où le cœur du microprocesseur attend de recevoir l’instruction 10. Il reçoit donc l’instruction de discontinuité au lieu de l’instruction 10, afin d’éviter le déclenchement intempestif d’une alarme. Il se déclenche alors un mécanisme qui fait que le cœur continue de demander l’instruction 10. Le cœur est par exemple configuré pour reconnaître une instruction de discontinuité à exécution linéaire et renouveler la demande de lecture de l’instruction 10 qui a été décalée par l’insertion de l’instruction de discontinuité à exécution linéaire. Le cœur finit par recevoir l’instruction 10 afin de l’exécuter. Dans ce cas, les différentes instructions gardent leurs adresses mémoires. L’instruction de discontinuité a été insérée dans le flot des instructions lues depuis la mémoire en vue d’être exécutées par le cœur.
La représente schématiquement un bloc d’insertion d’instructions de discontinuité à exécution linéaire 400 qui est un circuit situé hors de la mémoire 10, communiquant avec celle-ci et avec le registre d’instructions 12. Cette variante permet de ne pas modifier le compilateur, et de ne pas augmenter la surface mémoire.
La représente schématiquement un exemple de séquence d’instructions à exécuter à la suite d’une attaque de mémorisation dans le registre d’instructions d’une instruction de discontinuité engendrant une exécution linéaire. En l’occurrence, il s’agit d’une instruction de branchement dont la condition n’est jamais remplie : beq r0, r1, imm (beq signifiant « branch if equal »). Les registres r0 et r1 étant différents, le branchement vers l’adresse imm n’aura jamais lieu. Ce type d’attaque désactive le signal d’autorisation d’écriture (write_enable) du registre d’instructions 12 pour que l’instruction contenue dans le registre (beq r0, r1, imm, qui est dans ce cas une instruction de discontinuité à exécution linéaire) y soit mémorisée tant que dure la désactivation du signal d’autorisation d’écriture. Le compteur d’instructions de continuité 21 seul ne pourra pas détecter ce genre d’attaques, étant donné qu’il est réinitialisé en permanence par l’instruction de discontinuité (beq r0, r1, imm) mémorisée.
Ainsi, un compteur d’instructions de discontinuité à exécution linéaire 22 (représenté à la ) permet entre autres de détecter ce genre d’attaques consistant à injecter dans le cœur uniquement des instructions de discontinuité engendrant une exécution linéaire. En plus du compteur d’instructions de continuité 21, le circuit 1, en particulier le circuit de protection 18, peut comporter un compteur d’instructions de discontinuité à exécution linéaire 22 configuré pour être décrémenté à chaque exécution d’une instruction de discontinuité à exécution linéaire, le compteur d’instructions de discontinuité à exécution linéaire 22 étant préférentiellement configuré pour être périodiquement réinitialisé à une valeur paramétrable, la réinitialisation du compteur d’instructions de discontinuité à exécution linéaire 22 étant régulièrement effectuée par l’exécution d’une instruction de discontinuité à exécution non linéaire avant d’atteindre un seuil d’alarme, notamment zéro, le circuit de protection 18 étant configuré pour déclencher l’action prédéfinie d’alerte 300 lorsque le compteur d’instructions de discontinuité à exécution linéaire 22 atteint le seuil d’alarme.
Prenons un exemple avec la portion de code de la , un compteur d’instructions de continuité 21 décroissant, initialisé à 4, et un compteur d’instructions de discontinuité à exécution linéaire 22 décroissant, initialisé à 8, les seuils d’alarme des deux compteurs étant à zéro. Le compteur 21 sera réinitialisé à 4 à chaque instruction « beq r0, r1, imm » et ne décroîtra pas, alors que le compteur 22 va se décrémenter à chaque instruction jusqu’à celle d’adresse 9 où il atteindra son seuil d’alarme, provoquant le déclenchement de l’action prédéfinie d’alerte.
La combinaison des compteurs 21 et 22 permet également de contrer un autre type d’attaque consistant à forcer l’adresse d’instructions à varier linéairement. La illustre schématiquement un exemple d’une telle attaque. Le signal de pilotage 203 d’un multiplexeur 25 contenu dans le cœur 14 et fournissant l’adresse d’instructions est forcé de manière à sélectionner l’entrée engendrant une variation linéaire de l’adresse d’instructions.
Ainsi, quelle que soit l’instruction (de continuité ou de discontinuité), elle sera toujours à exécution linéaire. Le compteur d’instructions de continuité 21 seul ne peut détecter une telle attaque, étant réinitialisé à chaque instruction de discontinuité entrant dans le cœur. Cependant, le compteur d’instructions de discontinuité à exécution linéaire 22 ne sera jamais réinitialisé et se décrémentera à chaque instruction de discontinuité (à exécution linéaire), donc l’attaque sera détectée.
La illustre le cas d’une attaque désactivant le signal 204 contenant l’information qu’une instruction a été exécutée, signal 204 interne pouvant être désactivé communément avec le signal d’autorisation d’écriturewrite_enabledu registre d’instructions (la sonde 200 est placée non plus sur leresetqui n’a pas été représenté à des fins de simplification, mais sur le signalwrite_enabledu registre d’instructions 12). Dans ce cas, le compteur d’instructions de continuité 21 ne se décrémentera pas, ni le compteur d’instructions de discontinuité à exécution linéaire 22. Donc, le compteur d’instructions de continuité 21 seul ou combiné le cas échéant avec le compteur d’instructions de discontinuité à exécution linéaire 22 ne peut détecter ce genre d’attaque, d’où l’intérêt d’avoir un compteur de cycles 23 apte à détecter l’absence d’exécution d’instructions.
Le circuit 1, en particulier le circuit de protection 18, peut donc comporter un compteur de cycles 23 destiné à détecter une absence d’exécution d’instructions, le compteur 23 étant configuré pour s’incrémenter à chaque cycle d’horloge, la réinitialisation du compteur de cycles 23, notamment à zéro, étant régulièrement effectuée par l’exécution d’une instruction avant d’atteindre un seuil d’alarme, notamment une valeur paramétrable, le circuit de protection 18 étant configuré pour déclencher l’action prédéfinie d’alerte 300 lorsque le compteur de cycles 23 atteint le seuil d’alarme.
Le compteur de cycles 23 peut être utilisé en combinaison avec le compteur d’instructions de continuité 21 et éventuellement le compteur d’instructions de discontinuité à exécution linéaire 22 (représenté en pointillés sur la pour signifier qu’il est optionnel).
Par ailleurs, dans un autre mode de réalisation, il est possible de détecter des séquences d’exécution linéaire de longueur démesurée au regard du jeu d’instructions utilisé, par le biais d’un compteur de longueur de séquence d’exécution linéaire 24.
Le circuit 1 peut donc comporter un compteur de longueur de séquence d’exécution linéaire 24 destiné à détecter une séquence d’instructions de continuité et/ou d’instructions de discontinuité à exécution linéaire de longueur dépassant une longueur donnée, configuré pour s’incrémenter à chaque exécution d’une instruction ou à chaque cycle d’horloge, la réinitialisation, notamment à zéro, du compteur de longueur de séquence d’exécution linéaire 24 étant régulièrement effectuée par la variation d’au moins un signal du cœur du microprocesseur 14 indiquant la fin d’exécution d’une séquence d’exécution linéaire avant d’atteindre un seuil d’alarme, le circuit de protection 18 étant configuré pour déclencher l’action prédéfinie d’alerte lorsque le compteur de séquence d’exécution linéaire atteint le seuil d’alarme.
Cette variante avec compteur de longueur de séquence d’exécution linéaire permet, entre autres, de détecter toutes les attaques précédemment décrites (activation duresetdu registre d’instructions, mémorisation d’une instruction dans le registre d’instructions, forçage de variation linéaire de l’adresse d’instructions, etc.).
Le compteur de longueur de séquence d’exécution linéaire 24 peut avoir différents emplacements dans le circuit 1, comme représenté à la .
Il peut être branché sur le bus d’adresse d’instructions 15. Ainsi, il est possible de compter la longueur d’une séquence d’exécution linéaire en lisant l’adresse (incrément unitaire quand des adresses successives se suivent).
Le compteur de longueur de séquence d’exécution linéaire 24 peut être branché sur les signaux internes du cœur. Ainsi, il est possible de compter la longueur d’une séquence d’exécution linéaire en observant ces signaux, par exemple tant que la commande du multiplexeur d’adresse est maintenue en sélectionnant l'entrée "incrémentation linéaire de l'adresse", la séquence d’exécution linéaire perdure.
Le compteur de longueur de séquence d’exécution linéaire 24 peut être branché sur le bus d’instructions 12. Ainsi, il est possible de compter la longueur d’une séquence d’exécution linéaire en observant des bits spécifiques de l'instruction (par exemple bits des champs funct3 et opcode du code d’une instruction pour cœur RISC-V) de façon à savoir s'il s'agit, ou non, d'une instruction de discontinuité.
Les variantes précédemment décrites à la (registre d’instructions faisant partie du cœur de microprocesseur) et à la (mémoire externe) sont reproductibles sur les modes de réalisation visant à détecter une absence d’instruction de discontinuité plutôt qu’un marqueur de sécurité.
Un exemple de domaine d’application de la présente invention est la protection des circuits sécurisés (par exemple cartes à puces, microcontrôleurs sécurisés, etc.) contre l’extraction de leur programme et des données sensibles qu’ils contiennent (clés de cryptographie, droits divers, etc.).
Un exemple de marché touché par l’extraction linéaire de code est celui des cartouches d’encre des imprimantes (extraction linéaire du code des cartouches constructeurs pour en vendre des copies compatibles) qui peuvent donc être protégées par puce sécurisée selon l’invention.
L’invention n’est pas limitée aux exemples de réalisation décrits ci-dessus. Par exemple, il est possible d’implanter le procédé de détection selon l’invention d’une manière purement logicielle en le mettant en œuvre dans les microcontrôleurs, notamment temps réel, dits à chien de garde par l’utilisation du mécanisme intrinsèque de remise à zéro du circuit chien de garde. Les compteurs précédemment décrits peuvent être croissants, décroissants, ou toute autre variante.
On donne ci-après des caractéristiques de l’invention selon ses différents aspects, organisées sous la forme d’items. Chaque item indépendant se rapporte à un objet indépendant de l’invention, qui peut être combiné à d’autres items ou à d’autres caractéristiques de l’invention divulguées plus haut.
Item1. Procédé de détection d’une tentative d’extraction linéaire d’un code de programme enregistré dans une mémoire (10) d’un circuit électronique (1), le code comportant des instructions de programme qui, pour être lues par un cœur de microprocesseur (14), sont chargées séquentiellement via un bus d’instructions (11) dans un registre d’instructions (12) pour le stockage des instructions commandé au moins par un signal d’horloge (clk) et un signal de réinitialisation (reset), le chargement de chaque instruction dans le registre d’instructions (12) s’effectuant sur un front du signal d’horloge (clk), le code comprenant des instructions de discontinuité et/ou des instructions dites « marqueurs de sécurité » insérées parmi les instructions de programme de manière à être lues au cours de l’exécution du programme, le procédé comportant le déclenchement d’une action prédéfinie d’alerte (300), en cas de non-détection d’une instruction de discontinuité ou d’un marqueur de sécurité, selon une règle de surveillance prédéfinie.
Item2. Procédé selon l’item 1, la règle de surveillance prédéfinie étant la non-détection d’une instruction de discontinuité ou d’un marqueur de sécurité pendant une durée prédéfinie et/ou après qu’un nombre prédéfini d’instructions de programme ont été lues et/ou après un nombre prédéfini de cycles d’horloge.
Item3. Procédé selon l’item 1 ou 2, les marqueurs de sécurité étant insérés dans le code avec une périodicité variable et/ou les marqueurs de sécurité étant insérés dans le code de façon que l’exécution des instructions de programme situées entre deux marqueurs de sécurité consécutifs correspond à un nombre de cycles d’horloge inférieur à celui entraînant le déclenchement de l’action prédéfinie d’alerte (300), deux marqueurs de sécurité consécutifs étant de préférence disposés de telle sorte que le nombre de cycles d’horloge entraînant le déclenchement de l’action prédéfinie d’alerte est supérieur au nombre maximal de cycles d’horloge nécessaire à l’exécution des instructions de programme situées entre les deux marqueurs de sécurité.
Item4. Procédé selon l’un quelconque des items précédents, au moins un marqueur de sécurité étant inséré au début et à la fin du code d’une fonction faisant partie du programme et/ou au moins un marqueur de sécurité étant inséré à l’adresse de destination d’une instruction de branchement et/ou au moins un marqueur de sécurité étant inséré au début ou à la fin du code d’une boucle faisant partie du programme.
Item5. Procédé selon l'un quelconque des items précédents, les marqueurs de sécurité étant codés de sorte à avoir au moins un bit particulier de poids correspondant au même poids que celui d’au moins un bit caractéristique d’une instruction de branchement, le bit particulier ayant la même valeur encodée du bit caractéristique, de sorte à déclencher l’action prédéfinie d’alerte (300) en cas d’une attaque par forçage à la valeur binaire complémentaire du bit caractéristique.
Item6. Procédé selon l'un quelconque des items précédents, les marqueurs de sécurité étant insérés dans le code lors de l’exécution de ce dernier, en particulier lors de la lecture des instructions de programme depuis la mémoire (10), la mémoire (10) contenant de préférence une logique de contrôle dotée d’un bloc logique (100) insérant périodiquement un marqueur de sécurité parmi les instructions de programme lorsqu’elles sont lues, le bloc logique (100) transmettant en particulier une commande de cycle d’attente (115) au cœur du microprocesseur (14) lors du chargement d’un marqueur de sécurité dans le registre d’instructions (12) pour que le cœur du microprocesseur (14) insère un cycle d’attente dans le flot d’exécution lors de la réception du marqueur de sécurité.
Item7. Procédé selon l’un quelconque des items précédents, les marqueurs de sécurité étant différents les uns des autres par leur charge utile.
Item8. Procédé selon l’item 1 ou 2, comportant lors d’une étape d’analyse du code avant son chargement dans le registre, l’insertion d’au moins une instruction de discontinuité à exécution linéaire dans une portion du code comprenant des instructions de programme dont l’exécution correspond à un nombre de cycles d’horloge pouvant entraîner le déclenchement de l’action prédéfinie d’alerte (300).
Item9. Procédé selon l’item 8, l’insertion de l’instruction de discontinuité à exécution linéaire s’effectuant lors de la compilation du code, cette instruction étant stockée dans la mémoire (10) et possédant une adresse mémoire.
Item10. Procédé selon l’item 8, l’insertion de l’instruction de discontinuité à exécution linéaire s’effectuant après la lecture dans la mémoire (10) des instructions à charger et avant le chargement de ces instructions dans le registre d’instructions (12).
Item11. Procédé selon l'un quelconque des items précédents, l’action prédéfinie d’alerte (300) comportant l’une au moins des actions suivantes : la réinitialisation du circuit électronique (1), l’effacement de la mémoire (10), la remise à zéro de l’adresse de lecture en mémoire (10), la prise par l’adresse de lecture en mémoire de valeurs non consécutives de façon que l’extraction du code devienne non linéaire, et le saut d’une section de code, notamment d’une section sensible à protéger.
Item12. Procédé selon l'un quelconque des items précédents, étant mis en œuvre en permanence pour protéger la totalité du code de programme, la première instruction de ce dernier étant notamment une instruction de discontinuité ou un marqueur de sécurité.
Item13. Procédé selon l'un quelconque des items précédents, étant mis en œuvre d’une manière paramétrable via la configuration d’un fusible, notamment de type programmable une seule fois, ou d’une variable en mémoire non volatile, notamment une mémoire de type Flash ou EEPROM, lors de la phase de programmation du circuit, la valeur mémorisée dans le fusible ou dans la mémoire non-volatile étant lue au démarrage du circuit, en particulier à sa mise sous tension ou à son réveil après réinitialisation, ladite valeur permettant d’activer le procédé de détection, et la première instruction du code de programme étant une instruction de discontinuité ou un marqueur de sécurité, si le procédé est activé.
Item14. Procédé selon l'un quelconque des items 1 à 12, étant mis en œuvre pour protéger au moins une portion du code de programme délimitée par une adresse de début et une adresse de fin, le procédé étant activé dès qu’une instruction de programme dont l’adresse est comprise entre l’adresse de début et l’adresse de fin est lue pour être exécutée, étant désactivé dès qu’une instruction de programme n’appartenant pas à ladite portion de code est lue pour être exécutée, ladite portion de code correspondant notamment à la phase de démarrage du circuit ou une partie de code mettant en œuvre des fonctions de sécurité, notamment des outils cryptographiques.
Item15. Circuit électronique (1) comportant au moins une mémoire (10), un cœur de microprocesseur (14), un bus d’instructions (11), un bus de lecture (13), un bus d’adresse (15) et un registre d’instructions (12) pour le stockage des instructions commandé au moins par un signal d’horloge (clk) et un signal de réinitialisation (reset), la mémoire (10) étant reliée au registre d’instructions (12) par le bus d’instructions (11), le registre d’instructions (12) étant relié au cœur du microprocesseur (14) par le bus de lecture (13), le cœur du microprocesseur (14) comportant un pointeur d’instruction (140) destiné à contenir l’adresse mémoire d’une instruction devant être exécutée, le cœur du microprocesseur (14) étant relié à la mémoire (10) par le bus d’adresse (15), le circuit (1) étant configuré pour détecter une tentative d’extraction linéaire d’un code de programme enregistré dans la mémoire (10), le code comportant des instructions de programme qui, pour être lues par le cœur de microprocesseur (14), sont chargées séquentiellement via le bus d’instructions (11) dans le registre d’instructions (12) sur commande du signal d’horloge (clk), le code comprenant des instructions de discontinuité et/ou des instructions dites « marqueurs de sécurité » insérées parmi les instructions de programme de manière à être lues au cours de l’exécution du programme, le cœur du microprocesseur (14) comportant un circuit de protection (18) contre une tentative d’extraction linéaire apte à déclencher une action prédéfinie d’alerte (300) en cas de non-détection d’une instruction de discontinuité ou d’un marqueur de sécurité selon une règle de surveillance prédéfinie.
Item16. Circuit selon l’item précédent, au moins une portion du code de programme délimitée par une adresse de début et une adresse de fin étant protégée contre l’extraction linéaire par le circuit de protection (18), l’adresse de début et l’adresse de fin étant mémorisées à la programmation du circuit (1) dans une mémoire non-volatile protégée contre l’effacement et la modification, le circuit de protection (18) comportant de préférence des registres de chargement desdites adresses de début et de fin, dans lesquels lesdites adresses sont chargées lors du démarrage du circuit (1), le circuit de protection (18) étant notamment configuré pour déterminer si l’instruction dont l’adresse est contenue dans le pointeur d’instruction (140) appartient à ladite au moins une portion de code par la comparaison de cette adresse avec les adresses de début et de fin.
Item17. Circuit selon l'un des deux items précédents, comportant un circuit dit « chien de garde » servant à redémarrer le circuit (1) en cas de dysfonctionnement du programme, le circuit chien de garde comprenant un compteur de chien de garde incrémenté au front d’une horloge fournie par un oscillateur interne au circuit (1), le circuit chien de garde étant configuré en moderesetde sorte à émettre un signal de remise à zéro du circuit (1) lorsque le compteur de chien de garde atteint une valeur prédéfinie, le compteur de chien de garde étant remis à zéro périodiquement par l’exécution d’une instruction de réinitialisation de ce compteur.
Item18. Circuit selon l’item précédent, comportant un fusible matériel permettant une activation permanente du circuit chien de garde, de sorte que lorsque le fusible est grillé lors de la programmation du circuit, le circuit chien de garde s’active en permanence en modereset.
Item19. Utilisation du circuit selon l’item précédent, le fusible étant grillé et les instructions de réinitialisation du compteur de chien de garde étant utilisées comme marqueurs de sécurité.
Item20. Circuit selon l'un quelconque des items 15 à 18, le circuit de protection (18) comprenant un compteur de chargement d’instructions ou de cycles d’horloge (20) configuré pour être décrémenté à chaque chargement d’une instruction dans le registre d’instructions (12) ou à chaque cycle d’horloge, le compteur de chargement d’instructions ou de cycles d’horloge (20) étant configuré pour être périodiquement réinitialisé à une valeur paramétrable, la réinitialisation du compteur de chargement d’instructions ou de cycles d’horloge (20) étant régulièrement effectuée par un marqueur de sécurité avant d’atteindre un seuil d’alarme, notamment zéro, le circuit de protection (18) étant configuré pour déclencher l’action prédéfinie d’alerte (300) lorsque le compteur de chargement d’instructions ou de cycles d’horloge (20) atteint le seuil d’alarme.
Item21. Circuit selon l'un quelconque des items 15 à 18, comportant un compteur d’instructions de continuité (21) configuré pour être décrémenté à chaque exécution d’une instruction de continuité, le compteur d’instructions de continuité (21) étant préférentiellement configuré pour être périodiquement réinitialisé à une valeur paramétrable, la réinitialisation du compteur d’instructions de continuité étant régulièrement effectuée par l’exécution d’une instruction de discontinuité avant d’atteindre un seuil d’alarme, notamment zéro, le circuit de protection (18) étant configuré pour déclencher l’action prédéfinie d’alerte (300) lorsque le compteur d’instructions de continuité (21) atteint le seuil d’alarme.
Item22. Circuit selon l'un quelconque des items 15 à 21, hormis l’item 20, comportant un bloc d’insertion d’instructions de discontinuité à exécution linéaire (400) étant un circuit situé hors de la mémoire (10), communiquant avec celle-ci et avec le registre d’instructions (12), ce bloc étant configuré pour insérer au moins une instruction de discontinuité à exécution linéaire dans une portion du code lu comprenant des instructions de programme dont l’exécution correspond à un nombre de cycles d’horloge pouvant entraîner le déclenchement de l’action prédéfinie d’alerte (300).
Item23. Circuit selon l’item 21, comportant un compteur d’instructions de discontinuité à exécution linéaire (22) configuré pour être décrémenté à chaque exécution d’une instruction de discontinuité à exécution linéaire, le compteur d’instructions de discontinuité à exécution linéaire (22) étant préférentiellement configuré pour être périodiquement réinitialisé à une valeur paramétrable, la réinitialisation du compteur d’instructions de discontinuité à exécution linéaire (22) étant régulièrement effectuée par l’exécution d’une instruction de discontinuité à exécution non linéaire avant d’atteindre un seuil d’alarme, notamment zéro, le circuit de protection (18) étant configuré pour déclencher l’action prédéfinie d’alerte (300) lorsque le compteur d’instructions de discontinuité à exécution linéaire (22) atteint le seuil d’alarme.
Item24. Circuit selon l’item 21 ou 23, comportant un compteur de cycles (23) destiné à détecter une absence d’exécution d’instructions, configuré pour s’incrémenter à chaque cycle d’horloge (clk), la réinitialisation du compteur de cycles, notamment à zéro, étant régulièrement effectuée par l’exécution d’une instruction avant d’atteindre un seuil d’alarme, notamment une valeur paramétrable, le circuit de protection (18) étant configuré pour déclencher l’action prédéfinie d’alerte (300) lorsque le compteur de cycles (23) atteint le seuil d’alarme.
Item25. Circuit selon l'un quelconque des items 15 à 19, comportant un compteur de longueur de séquence d’exécution linéaire (24) destiné à détecter une séquence d’instructions de continuité et/ou d’instructions de discontinuité à exécution linéaire de longueur dépassant une longueur donnée, configuré pour s’incrémenter à chaque exécution d’une instruction ou à chaque cycle d’horloge, la réinitialisation, notamment à zéro, du compteur de longueur de séquence d’exécution linéaire (24) étant régulièrement effectuée par la variation d’au moins un signal du cœur du microprocesseur (14) indiquant la fin d’exécution d’une séquence d’exécution linéaire avant d’atteindre un seuil d’alarme, le circuit de protection (18) étant configuré pour déclencher l’action prédéfinie d’alerte (300) lorsque le compteur de séquence d’exécution linéaire (24) atteint le seuil d’alarme.
Item26. Procédé de protection d’un code de programme comportant l’insertion dans ce code d’instructions de discontinuité ou de marqueurs de sécurité pour la mise en œuvre du procédé selon l'un quelconque des items 1 à 14.
Item27. Procédé selon l’item 26, ladite insertion s’effectuant lors de la programmation du code.
Item28. Procédé selon l’item 26, ladite insertion s’effectuant lors ou à l’issue de la compilation du code.
Item29. Procédé selon l’item 26, ladite insertion s’effectuant après la lecture dans la mémoire (10) stockant le code des instructions à charger et avant le chargement de ces instructions dans le registre d’instructions (12).

Claims (29)

  1. Procédé de détection d’une tentative d’extraction linéaire d’un code de programme enregistré dans une mémoire (10) d’un circuit électronique (1), le code comportant des instructions de programme qui, pour être lues par un cœur de microprocesseur (14), sont chargées séquentiellement via un bus d’instructions (11) dans un registre d’instructions (12) pour le stockage des instructions commandé au moins par un signal d’horloge (clk) et un signal de réinitialisation (reset), le chargement de chaque instruction dans le registre d’instructions (12) s’effectuant sur un front du signal d’horloge (clk), le code comprenant des instructions de discontinuité et/ou des instructions dites « marqueurs de sécurité » insérées parmi les instructions de programme de manière à être lues au cours de l’exécution du programme, le procédé comportant le déclenchement d’une action prédéfinie d’alerte (300), en cas de non-détection d’une instruction de discontinuité ou d’un marqueur de sécurité, selon une règle de surveillance prédéfinie.
  2. Procédé selon la revendication précédente, la règle de surveillance prédéfinie étant la non-détection d’une instruction de discontinuité ou d’un marqueur de sécurité pendant une durée prédéfinie et/ou après qu’un nombre prédéfini d’instructions de programme ont été lues et/ou après un nombre prédéfini de cycles d’horloge.
  3. Procédé selon l’une des deux revendications précédentes, les marqueurs de sécurité étant insérés dans le code avec une périodicité variable et/ou les marqueurs de sécurité étant insérés dans le code de façon que l’exécution des instructions de programme situées entre deux marqueurs de sécurité consécutifs correspond à un nombre de cycles d’horloge inférieur à celui entraînant le déclenchement de l’action prédéfinie d’alerte (300), deux marqueurs de sécurité consécutifs étant de préférence disposés de telle sorte que le nombre de cycles d’horloge entraînant le déclenchement de l’action prédéfinie d’alerte est supérieur au nombre maximal de cycles d’horloge nécessaire à l’exécution des instructions de programme situées entre les deux marqueurs de sécurité.
  4. Procédé selon l'une quelconque des revendications précédentes, au moins un marqueur de sécurité étant inséré au début et à la fin du code d’une fonction faisant partie du programme et/ou au moins un marqueur de sécurité étant inséré à l’adresse de destination d’une instruction de branchement et/ou au moins un marqueur de sécurité étant inséré au début ou à la fin du code d’une boucle faisant partie du programme.
  5. Procédé selon l'une quelconque des revendications précédentes, les marqueurs de sécurité étant codés de sorte à avoir au moins un bit particulier de poids correspondant au même poids que celui d’au moins un bit caractéristique d’une instruction de branchement, le bit particulier ayant la même valeur encodée du bit caractéristique, de sorte à déclencher l’action prédéfinie d’alerte (300) en cas d’une attaque par forçage à la valeur binaire complémentaire du bit caractéristique.
  6. Procédé selon l'une quelconque des revendications précédentes, les marqueurs de sécurité étant insérés dans le code lors de l’exécution de ce dernier, en particulier lors de la lecture des instructions de programme depuis la mémoire (10), la mémoire (10) contenant de préférence une logique de contrôle dotée d’un bloc logique (100) insérant périodiquement un marqueur de sécurité parmi les instructions de programme lorsqu’elles sont lues, le bloc logique (100) transmettant en particulier une commande de cycle d’attente (115) au cœur du microprocesseur (14) lors du chargement d’un marqueur de sécurité dans le registre d’instructions (12) pour que le cœur du microprocesseur (14) insère un cycle d’attente dans le flot d’exécution lors de la réception du marqueur de sécurité.
  7. Procédé selon l’une quelconque des revendications précédentes, les marqueurs de sécurité étant différents les uns des autres par leur charge utile.
  8. Procédé selon la revendication 1 ou 2, comportant lors d’une étape d’analyse du code avant son chargement dans le registre, l’insertion d’au moins une instruction de discontinuité à exécution linéaire dans une portion du code comprenant des instructions de programme dont l’exécution correspond à un nombre de cycles d’horloge pouvant entraîner le déclenchement de l’action prédéfinie d’alerte (300).
  9. Procédé selon la revendication précédente, l’insertion de l’instruction de discontinuité à exécution linéaire s’effectuant lors de la compilation du code, cette instruction étant stockée dans la mémoire (10) et possédant une adresse mémoire.
  10. Procédé selon la revendication 8, l’insertion de l’instruction de discontinuité à exécution linéaire s’effectuant après la lecture dans la mémoire (10) des instructions à charger et avant le chargement de ces instructions dans le registre d’instructions (12).
  11. Procédé selon l'une quelconque des revendications précédentes, l’action prédéfinie d’alerte (300) comportant l’une au moins des actions suivantes : la réinitialisation du circuit électronique (1), l’effacement de la mémoire (10), la remise à zéro de l’adresse de lecture en mémoire (10), la prise par l’adresse de lecture en mémoire de valeurs non consécutives de façon que l’extraction du code devienne non linéaire, et le saut d’une section de code, notamment d’une section sensible à protéger.
  12. Procédé selon l'une quelconque des revendications précédentes, étant mis en œuvre en permanence pour protéger la totalité du code de programme, la première instruction de ce dernier étant notamment une instruction de discontinuité ou un marqueur de sécurité.
  13. Procédé selon l'une quelconque des revendications précédentes, étant mis en œuvre d’une manière paramétrable via la configuration d’un fusible, notamment de type programmable une seule fois, ou d’une variable en mémoire non volatile, notamment une mémoire de type Flash ou EEPROM, lors de la phase de programmation du circuit, la valeur mémorisée dans le fusible ou dans la mémoire non-volatile étant lue au démarrage du circuit, en particulier à sa mise sous tension ou à son réveil après réinitialisation, ladite valeur permettant d’activer le procédé de détection, et la première instruction du code de programme étant une instruction de discontinuité ou un marqueur de sécurité, si le procédé est activé.
  14. Procédé selon l'une quelconque des revendications 1 à 12, étant mis en œuvre pour protéger au moins une portion du code de programme délimitée par une adresse de début et une adresse de fin, le procédé étant activé dès qu’une instruction de programme dont l’adresse est comprise entre l’adresse de début et l’adresse de fin est lue pour être exécutée, étant désactivé dès qu’une instruction de programme n’appartenant pas à ladite portion de code est lue pour être exécutée, ladite portion de code correspondant notamment à la phase de démarrage du circuit ou une partie de code mettant en œuvre des fonctions de sécurité, notamment des outils cryptographiques.
  15. Circuit électronique (1) comportant au moins une mémoire (10), un cœur de microprocesseur (14), un bus d’instructions (11), un bus de lecture (13), un bus d’adresse (15) et un registre d’instructions (12) pour le stockage des instructions commandé au moins par un signal d’horloge (clk) et un signal de réinitialisation (reset), la mémoire (10) étant reliée au registre d’instructions (12) par le bus d’instructions (11), le registre d’instructions (12) étant relié au cœur du microprocesseur (14) par le bus de lecture (13), le cœur du microprocesseur (14) comportant un pointeur d’instruction (140) destiné à contenir l’adresse mémoire d’une instruction devant être exécutée, le cœur du microprocesseur (14) étant relié à la mémoire (10) par le bus d’adresse (15), le circuit (1) étant configuré pour détecter une tentative d’extraction linéaire d’un code de programme enregistré dans la mémoire (10), le code comportant des instructions de programme qui, pour être lues par le cœur de microprocesseur (14), sont chargées séquentiellement via le bus d’instructions (11) dans le registre d’instructions (12) sur commande du signal d’horloge (clk), le code comprenant des instructions de discontinuité et/ou des instructions dites « marqueurs de sécurité » insérées parmi les instructions de programme de manière à être lues au cours de l’exécution du programme, le cœur du microprocesseur (14) comportant un circuit de protection (18) contre une tentative d’extraction linéaire apte à déclencher une action prédéfinie d’alerte (300) en cas de non-détection d’une instruction de discontinuité ou d’un marqueur de sécurité selon une règle de surveillance prédéfinie.
  16. Circuit selon la revendication précédente, au moins une portion du code de programme délimitée par une adresse de début et une adresse de fin étant protégée contre l’extraction linéaire par le circuit de protection (18), l’adresse de début et l’adresse de fin étant mémorisées à la programmation du circuit (1) dans une mémoire non-volatile protégée contre l’effacement et la modification, le circuit de protection (18) comportant de préférence des registres de chargement desdites adresses de début et de fin, dans lesquels lesdites adresses sont chargées lors du démarrage du circuit (1), le circuit de protection (18) étant notamment configuré pour déterminer si l’instruction dont l’adresse est contenue dans le pointeur d’instruction (140) appartient à ladite au moins une portion de code par la comparaison de cette adresse avec les adresses de début et de fin.
  17. Circuit selon l'une des deux revendications précédentes, comportant un circuit dit « chien de garde » servant à redémarrer le circuit (1) en cas de dysfonctionnement du programme, le circuit chien de garde comprenant un compteur de chien de garde incrémenté au front d’une horloge fournie par un oscillateur interne au circuit (1), le circuit chien de garde étant configuré en moderesetde sorte à émettre un signal de remise à zéro du circuit (1) lorsque le compteur de chien de garde atteint une valeur prédéfinie, le compteur de chien de garde étant remis à zéro périodiquement par l’exécution d’une instruction de réinitialisation de ce compteur.
  18. Circuit selon la revendication précédente, comportant un fusible matériel permettant une activation permanente du circuit chien de garde, de sorte que lorsque le fusible est grillé lors de la programmation du circuit, le circuit chien de garde s’active en permanence en modereset.
  19. Utilisation du circuit selon la revendication précédente, le fusible étant grillé et les instructions de réinitialisation du compteur de chien de garde étant utilisées comme marqueurs de sécurité.
  20. Circuit selon l'une quelconque des revendications 15 à 18, le circuit de protection (18) comprenant un compteur de chargement d’instructions ou de cycles d’horloge (20) configuré pour être décrémenté à chaque chargement d’une instruction dans le registre d’instructions (12) ou à chaque cycle d’horloge, le compteur de chargement d’instructions ou de cycles d’horloge (20) étant configuré pour être périodiquement réinitialisé à une valeur paramétrable, la réinitialisation du compteur de chargement d’instructions ou de cycles d’horloge (20) étant régulièrement effectuée par un marqueur de sécurité avant d’atteindre un seuil d’alarme, notamment zéro, le circuit de protection (18) étant configuré pour déclencher l’action prédéfinie d’alerte (300) lorsque le compteur de chargement d’instructions ou de cycles d’horloge (20) atteint le seuil d’alarme.
  21. Circuit selon l'une quelconque des revendications 15 à 18, comportant un compteur d’instructions de continuité (21) configuré pour être décrémenté à chaque exécution d’une instruction de continuité, le compteur d’instructions de continuité (21) étant préférentiellement configuré pour être périodiquement réinitialisé à une valeur paramétrable, la réinitialisation du compteur d’instructions de continuité étant régulièrement effectuée par l’exécution d’une instruction de discontinuité avant d’atteindre un seuil d’alarme, notamment zéro, le circuit de protection (18) étant configuré pour déclencher l’action prédéfinie d’alerte (300) lorsque le compteur d’instructions de continuité (21) atteint le seuil d’alarme.
  22. Circuit selon l'une quelconque des revendications 15 à 21, hormis la revendication 20, comportant un bloc d’insertion d’instructions de discontinuité à exécution linéaire (400) étant un circuit situé hors de la mémoire (10), communiquant avec celle-ci et avec le registre d’instructions (12), ce bloc étant configuré pour insérer au moins une instruction de discontinuité à exécution linéaire dans une portion du code lu comprenant des instructions de programme dont l’exécution correspond à un nombre de cycles d’horloge pouvant entraîner le déclenchement de l’action prédéfinie d’alerte (300).
  23. Circuit selon la revendication 21, comportant un compteur d’instructions de discontinuité à exécution linéaire (22) configuré pour être décrémenté à chaque exécution d’une instruction de discontinuité à exécution linéaire, le compteur d’instructions de discontinuité à exécution linéaire (22) étant préférentiellement configuré pour être périodiquement réinitialisé à une valeur paramétrable, la réinitialisation du compteur d’instructions de discontinuité à exécution linéaire (22) étant régulièrement effectuée par l’exécution d’une instruction de discontinuité à exécution non linéaire avant d’atteindre un seuil d’alarme, notamment zéro, le circuit de protection (18) étant configuré pour déclencher l’action prédéfinie d’alerte (300) lorsque le compteur d’instructions de discontinuité à exécution linéaire (22) atteint le seuil d’alarme.
  24. Circuit selon la revendication 21 ou 23, comportant un compteur de cycles (23) destiné à détecter une absence d’exécution d’instructions, configuré pour s’incrémenter à chaque cycle d’horloge (clk), la réinitialisation du compteur de cycles, notamment à zéro, étant régulièrement effectuée par l’exécution d’une instruction avant d’atteindre un seuil d’alarme, notamment une valeur paramétrable, le circuit de protection (18) étant configuré pour déclencher l’action prédéfinie d’alerte (300) lorsque le compteur de cycles (23) atteint le seuil d’alarme.
  25. Circuit selon l'une quelconque des revendications 15 à 19, comportant un compteur de longueur de séquence d’exécution linéaire (24) destiné à détecter une séquence d’instructions de continuité et/ou d’instructions de discontinuité à exécution linéaire de longueur dépassant une longueur donnée, configuré pour s’incrémenter à chaque exécution d’une instruction ou à chaque cycle d’horloge, la réinitialisation, notamment à zéro, du compteur de longueur de séquence d’exécution linéaire (24) étant régulièrement effectuée par la variation d’au moins un signal du cœur du microprocesseur (14) indiquant la fin d’exécution d’une séquence d’exécution linéaire avant d’atteindre un seuil d’alarme, le circuit de protection (18) étant configuré pour déclencher l’action prédéfinie d’alerte (300) lorsque le compteur de séquence d’exécution linéaire (24) atteint le seuil d’alarme.
  26. Procédé de protection d’un code de programme comportant l’insertion dans ce code d’instructions de discontinuité ou de marqueurs de sécurité pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 14.
  27. Procédé selon la revendication précédente, ladite insertion s’effectuant lors de la programmation du code.
  28. Procédé selon la revendication 26, ladite insertion s’effectuant lors ou à l’issue de la compilation du code.
  29. Procédé selon la revendication 26, ladite insertion s’effectuant après la lecture dans la mémoire (10) stockant le code des instructions à charger et avant le chargement de ces instructions dans le registre d’instructions (12).
FR2209624A 2021-11-09 2022-09-22 Procédé de détection d’une tentative d’extraction linéaire du contenu d’une mémoire Pending FR3140186A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR2209624A FR3140186A1 (fr) 2022-09-22 2022-09-22 Procédé de détection d’une tentative d’extraction linéaire du contenu d’une mémoire
PCT/EP2022/081057 WO2023083776A1 (fr) 2021-11-09 2022-11-08 Procédé de détection d'une tentative d'extraction linéaire du contenu d'une mémoire

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2209624 2022-09-22
FR2209624A FR3140186A1 (fr) 2022-09-22 2022-09-22 Procédé de détection d’une tentative d’extraction linéaire du contenu d’une mémoire

Publications (1)

Publication Number Publication Date
FR3140186A1 true FR3140186A1 (fr) 2024-03-29

Family

ID=87889362

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2209624A Pending FR3140186A1 (fr) 2021-11-09 2022-09-22 Procédé de détection d’une tentative d’extraction linéaire du contenu d’une mémoire

Country Status (1)

Country Link
FR (1) FR3140186A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050289270A1 (en) * 2004-06-07 2005-12-29 Proton World International N.V. Control of the execution of a program
FR2990533A1 (fr) * 2012-05-09 2013-11-15 Morpho Procede de suivi d'execution d'un logiciel et logiciel pour la mise en oeuvre du procede

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050289270A1 (en) * 2004-06-07 2005-12-29 Proton World International N.V. Control of the execution of a program
FR2990533A1 (fr) * 2012-05-09 2013-11-15 Morpho Procede de suivi d'execution d'un logiciel et logiciel pour la mise en oeuvre du procede

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
AKKAR: "Automatic integration of counter-measures against fault injection attacks", 30 January 2003 (2003-01-30), XP055910499, Retrieved from the Internet <URL:https://www.researchgate.net/profile/Louis-Goubin-2/publication/228947109_Automatic_integration_of_counter-measures_against_fault_injection_attacks/links/55d9f4eb08aeb38e8a8a0cce/Automatic-integration-of-counter-measures-against-fault-injection-attacks.pdf> [retrieved on 20220407] *
ANONYMOUS: "Microprocessor Concepts", 1 January 2013 (2013-01-01), XP055911287, Retrieved from the Internet <URL:https://www.tutorialspoint.com/basics_of_computers/basics_of_computers_microprocessor_concepts.htm> [retrieved on 20220411] *
JOHANNES OBERMAIERVINCENT IMMLER: "The past, présent, and future ofphysical security enclosures: From battery-backed monitoring to PUF-based inhérent security and beyond", JOURNAL OF HARDWARE AND SYSTEMS SECURITY, August 2018 (2018-08-01)
O. KΔMMERLING ET AL.: "Design Principles for Tamper-Resistant Smartcard Processors", USENIX WORKSHOP ON SMARTCARD TECHNOLOGY, 1999
PHIL ISAACS ET AL.: "Tamper Proof, Tamper Evident Encryption Technology", PAN PACIFIC SYMPOSIUM. SMTA, 2013

Similar Documents

Publication Publication Date Title
US10762210B2 (en) Firmware protection and validation
EP1161725B1 (fr) Procede de surveillance du deroulement d&#39;un programme
EP1659515A1 (fr) Protection d&#39;un microcontrôleur
WO2006045924A1 (fr) Protection contre les attaques par generation de fautes sur les instructions de saut
EP1605333B1 (fr) Contrôle de l&#39;exécution d&#39;un programme
EP2465069A2 (fr) Fonction physiquement inclonable avec système de prévention anti-sabotage et anti-vieillissement
FR2849226A1 (fr) Procede et dispositif de securisation de l&#39;execution d&#39;un programme informatique.
EP1904946B1 (fr) Detection d&#39;une faute par perturbation longue
EP1772805A2 (fr) Coprocesseur sécurisé comprenant un circuit de détection d&#39; un évènement
US9047448B2 (en) Branch auditing in a computer program
WO2012085482A1 (fr) Protection des applets contre les analyses par canaux caches
EP1316874B1 (fr) Blocage du fonctionnement d&#39;un circuit intégré
EP2158557B1 (fr) Procédé et dispositif de détection de sauts erronés au cours de l&#39;éxecution d&#39;un programme
EP1108249A1 (fr) Procede de securisation du traitement d&#39;une information sensible dans un module de securite monolithique, et module de securite associe
FR3140186A1 (fr) Procédé de détection d’une tentative d’extraction linéaire du contenu d’une mémoire
WO2023083776A1 (fr) Procédé de détection d&#39;une tentative d&#39;extraction linéaire du contenu d&#39;une mémoire
EP4177780A1 (fr) Procede de detection d&#39;une tentative d&#39;extraction lineaire du contenu d&#39;une memoire
FR3070076B1 (fr) Procede de protection d&#39;un dispositif electronique contre des attaques par injection de faute
EP1710700A2 (fr) Coprocesseur sécurisé comprenant des moyens pour empêcher l&#39;accès à un organe du coprocesseur
FR2910145A1 (fr) Procede et dispositif pour securiser la lecture d&#39;une memoire.
EP1717704A2 (fr) Protection du déroulement d&#39;un programme exécuté par un circuit intégré
FR2895814A1 (fr) Procede de securisation de l&#39;execution d&#39;un programme d&#39;ordinateur
EP2652664A1 (fr) Procede dynamique de controle de l&#39;integrite de l&#39;execution d&#39;un code executable
WO2007006887A1 (fr) Protection contre les attaques par generation de fautes sur les instructions de saut
EP1494104A1 (fr) Contrôle d&#39;intégrité d&#39;un programme en utilisant des statistiques

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20240329