FR3116356A1 - Procédé de compilation d’un code source - Google Patents

Procédé de compilation d’un code source Download PDF

Info

Publication number
FR3116356A1
FR3116356A1 FR2011657A FR2011657A FR3116356A1 FR 3116356 A1 FR3116356 A1 FR 3116356A1 FR 2011657 A FR2011657 A FR 2011657A FR 2011657 A FR2011657 A FR 2011657A FR 3116356 A1 FR3116356 A1 FR 3116356A1
Authority
FR
France
Prior art keywords
instruction
instructions
additional
illegal
code
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.)
Granted
Application number
FR2011657A
Other languages
English (en)
Other versions
FR3116356B1 (fr
Inventor
Michel Jaouen
Stéphane LE ROY
Moïse GERGAUD
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.)
STMicroelectronics Grand Ouest SAS
Original Assignee
STMicroelectronics Grand Ouest SAS
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 STMicroelectronics Grand Ouest SAS filed Critical STMicroelectronics Grand Ouest SAS
Priority to FR2011657A priority Critical patent/FR3116356B1/fr
Priority to US17/451,394 priority patent/US11893370B2/en
Priority to CN202111336977.7A priority patent/CN114489657A/zh
Publication of FR3116356A1 publication Critical patent/FR3116356A1/fr
Application granted granted Critical
Publication of FR3116356B1 publication Critical patent/FR3116356B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/002—Countermeasures against attacks on cryptographic mechanisms
    • H04L9/004—Countermeasures against attacks on cryptographic mechanisms for fault attacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Devices For Executing Special Programs (AREA)
  • Stored Programmes (AREA)

Abstract

Selon un aspect, il est proposé un procédé de compilation par un outil de compilation d’un code source (CS) en un code (PRG) exécutable par ordinateur comprenant : - une réception (20) en entrée de l’outil de compilation du code source,- une traduction (21) du code source (CS) en un code objet comprenant des instructions-machines exécutables par un processeur, puis - une introduction (22), entre des instructions-machines du code objet, d’instructions additionnelles choisies parmi des instructions illégales et des instructions de non opération de façon à obtenir ledit code exécutable (PRG), puis - une délivrance (23) du code exécutable (PRG) en sortie de l’outil de compilation. Figure pour l’abrégé : Figure 2

Description

PROCÉDÉ DE COMPILATION D’UN CODE SOURCE
Des modes de mise en œuvre et de réalisation de l'invention concernent la sécurisation de certains aspects d'un système informatique comme par exemple la sécurisation d'un jeu d'instructions exécutables par ce système informatique, notamment par rapport à la sécurité contre des attaques par injection de faute ou bien en termes de sûreté.
L'invention s'applique avantageusement mais non limitativement aux systèmes informatiques dont l'unité de traitement comporte par exemple un microcontrôleur ou un microprocesseur.
Un programme comprend au moins un code objet formé de plusieurs instructions-machine (ou simplement « instructions »).
Une instruction-machine est une opération élémentaire d’un code objet pouvant être exécutée par un processeur.
Les instructions-machine peuvent être obtenues à partir d’un code source à l’aide d’un outil de compilation.
Un outil de compilation (ou « compilateur ») est un programme qui transforme un code source en un code objet. En particulier, le code source peut comprendre des fonctions qui sont traduites en instructions dans le code objet.
Par ailleurs, l’exécution des instructions d’un code objet par un processeur est cadencée par une horloge.
Des perturbations sur les composants électroniques de l’horloge peuvent survenir. De telles perturbations peuvent impacter l’exécution des instructions et de ce fait peuvent réduire la sûreté du programme.
Afin de s’assurer que le programme s’exécute correctement, il est possible de contrôler l’exécution de la suite d’instructions au moins à certaines étapes stratégiques du programme. Cela nécessite d’appliquer des règles de codage spécifiques. Ces règles de codage spécifiques nécessitent des compétences techniques élevées. En outre, l’application de ces règles de codage prend du temps.
Il existe donc un besoin de proposer une solution permettant d’éviter un codage spécifique.
Par ailleurs, une personne mal avisée peut réussir à perturber l’exécution des instructions d’un programme par attaque par injection de faute en détraquant l’horloge utilisée pour cadencer l’exécution des instructions.
En particulier, en détraquant l’horloge, certaines instructions peuvent être sautées et ne sont donc pas exécutées. D’autres instructions peuvent être exécutées plusieurs fois. Lorsque certaines instructions de branchement de fin de fonction ne sont pas exécutées, il est possible que l’exécution du programme exécute la fonction suivante dans le code sans que cette fonction soit appelée.
Ainsi, en détraquant l’horloge, l’exécution du programme peut être non-contrôlée, ce qui peut poser des problèmes de sécurité.
En particulier, en perturbant l’exécution des instructions d’un programme, une personne mal avisée peut réussir à corrompre le programme.
Afin de contrer des attaques par injection de fautes, il est possible de réaliser un contrôle des instructions réalisées. Il est également possible de dupliquer les appels aux fonctions de façon à s’assurer qu’elles sont bien exécutées.
Ces solutions présentent l’inconvénient d’être très intrusives pour le développement du code du programme.
Ces solutions présentent également l’inconvénient de ne pas pouvoir prévoir toutes les répercussions possibles d’une injection par faute dans l’exécution du programme. En effet, il est toujours possible d’avoir une injection par faute impactant certaines parties du code assembleur pour lesquelles aucun contrôle n’est réalisé. Les injections par faute peuvent alors ne pas être détecter.
En outre, le code compilé est le même pour tout système informatique utilisant un code public. En particulier, le code compilé est le même pour un même outil de compilation utilisant un même niveau d’optimisation de compilation. L’attaque par injection de faute peut donc être facile à reproduire sur plusieurs plateformes en se basant sur un même code.
Il existe donc un besoin de rendre un programme plus robuste aux attaques par injection de faute et/ou aux perturbations extérieures.
Il existe également un besoin de proposer une solution permettant de détecter une exécution non contrôlée du programme pouvant notamment résulter d’une attaque par injection de faute.
Selon un aspect, il est proposé un procédé de compilation par un outil de compilation, ou compilateur, d’un code source en un code exécutable par ordinateur, l’outil de compilation étant mis en œuvre au sein d’une unité de traitement informatique, le procédé comprenant :
- une réception en entrée de l’outil de compilation du code source et un stockage du code source dans une mémoire de l’unité de traitement,
- une traduction par l’outil de compilation, du code source en un code objet comprenant des instructions-machines exécutables par un processeur, puis
- une introduction par l’outil de compilation, entre des instructions-machines du code objet, d’instructions additionnelles choisies parmi des instructions illégales et des instructions de non opération de façon à obtenir ledit code exécutable, puis
- une délivrance du code exécutable en sortie de l’outil de compilation.
Un tel procédé de compilation peut être mis en œuvre par un outil de compilation, pouvant notamment être exécuté par un ordinateur. Un tel procédé de compilation peut être mis en œuvre afin d’obtenir plusieurs codes exécutables pouvant être liés afin d’obtenir un programme compilé exécutable par un système informatique comprenant une unité de traitement.
Un tel procédé de compilation permet donc d’obtenir un code objet modifié comportant des instructions traduites du code source et des instructions additionnelles introduites par l’outil de compilation.
Le procédé de compilation est réalisé en fonction d’un processeur avec lequel on souhaite que le code exécutable obtenu puisse être exécuté. Par exemple, le processeur avec lequel on souhaite exécuter le code exécutable obtenu peut être un processeur ayant une architecture de type ARM. Le code source est alors traduit en instructions pouvant être lues par un tel processeur.
En particulier, le code exécutable peut être exécuté par un processeur d’un microcontrôleur de l’unité de traitement du système informatique.
Le fait d’introduire des instructions additionnelles entre les instructions traduites du code source permet d’améliorer la robustesse du code exécutable obtenu en termes de sûreté et contre les attaques par injection de faute.
Un tel procédé de compilation peut être mis en œuvre par un outil de compilation. En particulier, l’outil de compilation peut mettre en œuvre automatiquement le procédé de compilation proposé lors d’une compilation d’un code source.
Un tel procédé de compilation permet de faciliter le développement du code exécutable car l’insertion des instructions additionnelles est effectuée automatiquement par l’outil de compilation.
En outre, l’exécution du code exécutable obtenu peut s’effectuer en utilisant une mémoire flash, et non pas une mémoire RAM (acronyme de l’anglais « Random Access Memory »).
Une instruction illégale est une instruction présentant un code opérationnel non valide. Ce code opérationnel est non valide car il ne correspond à aucun type d’instructions pouvant être exécutées par le processeur sur lequel le code exécutable est exécuté.
Lorsqu’une instruction illégale est lue par le processeur, celle-ci ne peut être exécutée par ce dernier. Une exception d’instruction illégale est alors émise.
Ainsi, en introduisant des instructions illégales parmi les instructions traduites du code source, il est possible de détecter un dysfonctionnement dans l’exécution du code exécutable en détectant des exceptions d’instruction illégale.
En particulier, il est possible d’utiliser un dispositif de contrôle configuré pour détecter les exceptions d’instruction illégale résultant des instructions illégales additionnelles introduites parmi les instructions traduites du code source.
Ce dispositif de contrôle peut également être configuré pour stopper une exécution non contrôlée du code exécutable, après avoir détecté une exception d’instruction illégale, puis pour effectuer une action de sécurisation pour éviter un problème de sécurité. L’action de sécurisation pour éviter un problème de sécurité peut être par exemple une réinitialisation du processeur exécutant le code exécutable ou un effacement des données sensibles, telles que des clés de cryptographie. L’action de sécurisation peut également être une écriture dans les registres RTC (acronyme de l’anglais « Real Time Clock ») pour mémoriser une tentative d’attaque par injection de faute. Il est également possible de ralentir le processeur pour ralentir les tentatives d’attaques.
Il est possible d’introduire uniquement des instructions additionnelles illégales. Il est également possible d’introduire uniquement des instructions additionnelles de non opération. Il est également possible de combiner ces différents types d’instructions additionnelles.
Le code objet peut comprendre des fonctions comportant un ensemble d’instructions-machine. Ces fonctions sont initialement écrites dans le code source.
Dans un mode de mise en œuvre avantageux, les instructions additionnelles illégales sont introduites entre des fonctions du code objet.
L’introduction des instructions illégales présente l’avantage d’être simple à mettre en œuvre et peu intrusive dans l’exécution du code exécutable.
Dans un mode de mise en œuvre avantageux, au moins une instruction additionnelle illégale est introduite après une instruction de branchement du code objet traduit à partir du code source.
Par exemple, lorsque ladite au moins une instruction illégale est insérée entre deux fonctions du code objet, ladite au moins une instruction illégale est insérée après une instruction de branchement inconditionnel marquant la fin de la première de ces deux fonctions du code objet.
Ainsi, lorsque le code s’exécute normalement, l’instruction de branchement de fin de fonction est exécutée et ladite au moins une instruction additionnelle illégale n’est pas lue. En outre, lorsque le code s’exécute anormalement et que l’instruction de branchement de fin de fonction est sautée, ladite au moins une instruction additionnelle illégale peut être lue. La lecture de ladite au moins une instruction additionnelle illégale génère alors une exception d’instruction illégale signalant un dysfonctionnement dans l’exécution du code exécutable.
Par ailleurs, il est possible que des instructions de branchement inconditionnel soient déjà comprises dans certaines fonctions du code objet. Il est alors également possible d’insérer ladite au moins une instruction après une instruction de branchement comprise au sein d’une fonction.
Ainsi, lorsque le code s’exécute normalement, l’instruction de branchement au sein de la fonction est exécutée et ladite au moins une instruction additionnelle illégale n’est pas lue. En outre, lorsque cette instruction de branchement est sautée suite à un dysfonctionnement dans l’exécution du code exécutable, ladite au moins une instruction illégale est lue et une exception d’instruction illégale est générée signalant ainsi un dysfonctionnement dans l’exécution du code exécutable.
Il est également possible d’introduire une instruction additionnelle illégale après une instruction de branchement conditionnel lorsqu’on est assuré que la condition pour effectuer le branchement sera vérifiée lors d’une exécution normale du code exécutable.
Dans un mode de mise en œuvre avantageux, une instruction additionnelle de branchement suivie d’au moins une instruction additionnelle illégale sont introduites entre deux instructions-machine du code objet traduit du code source.
L’introduction de l’instruction de branchement suivie d’au moins une instruction illégale peut être réalisée au sein d’une fonction, à n’importe quel emplacement entre deux instructions.
En particulier, l’instruction de branchement est introduite juste après la première instruction desdites deux instructions traduites du code source. Cette instruction de branchement prend comme opérande l’adresse de la deuxième instruction parmi lesdites deux instructions traduites du code source.
Ainsi, lorsque le code s’exécute normalement, l’instruction de branchement introduite est exécutée et ladite au moins une instruction additionnelle illégale n’est pas lue. L’instruction qui est ensuite exécutée est la prochaine instruction traduite du code source.
En outre, lorsque cette instruction de branchement est sautée suite à un dysfonctionnement dans l’exécution du code exécutable, ladite au moins une instruction illégale est lue et une exception d’instruction illégale est générée signalant ainsi un dysfonctionnement dans l’exécution du code exécutable.
L’instruction de branchement peut être inconditionnelle ou bien conditionnelle lorsqu’on est assuré que la condition pour effectuer le branchement sera vérifiée lors d’une exécution normale du code exécutable.
En particulier, dans un mode de réalisation avantageux, le code objet traduit du code source comprend une instruction de comparaison suivie d’une instruction de branchement conditionnel. En outre, une instruction additionnelle de comparaison suivie d’une instruction additionnelle de branchement conditionnel est introduite dans le code objet en amont de l’instruction de comparaison traduite du code source ou à la suite de l’instruction de branchement conditionnel traduite du code source, l’instruction additionnelle de comparaison étant identique à l’instruction de comparaison traduite du code source et l’instruction additionnelle de branchement conditionnel étant opposée à l’instruction de branchement conditionnel suivant l’instruction de comparaison traduite du code source. Par ailleurs, au moins une instruction additionnelle illégale est introduite à la suite de la dernière instruction de branchement conditionnel parmi l’instruction additionnelle de branchement conditionnel et l’instruction de branchement conditionnel traduite du code source.
Par ailleurs, dans un mode de réalisation avantageux, au moins une instruction additionnelle illégale est introduite après une instruction de branchement d’appel à une fonction, et au moins une instruction d’addition est introduite dans ladite fonction, cette instruction d’addition étant configurée pour pouvoir modifier une adresse de retour stockée dans un registre de liens en ajoutant à cette adresse de retour le nombre d’instructions additionnelles illégales introduites après l’instruction de branchement d’appel à la fonction.
Dans un mode de mise en œuvre avantageux, au moins deux instructions additionnelles illégales successives sont introduites entre au moins deux instructions-machine du code objet traduit du code source.
Il est possible qu’une lecture d’une instruction additionnelle illégale soient sautée lors d’une exécution non contrôlée du code exécutable.
Ainsi, en introduisant un nombre d’instructions illégales successives supérieur à deux, les chances de lecture d’une instruction additionnelle illégale lors d’une exécution non contrôlée du code exécutable sont plus élevées. Les chances de détecter un dysfonctionnement dans l’exécution du code exécutable sont donc plus élevées.
Dans un mode de mise en œuvre avantageux, le nombre d’instructions additionnelles illégales successives introduites entre au moins deux instructions-machine du code objet traduit du code source est choisi aléatoirement.
En introduisant un nombre aléatoire d’instructions additionnelles illégales successives, il est possible d’obtenir un code exécutable différent pour chaque compilation d’un même code source.
Comme chaque code exécutable obtenu à partir d’un même code source est différent, il est donc plus difficile de réaliser une attaque par injection de faute ayant un même effet sur l’exécution de chaque code exécutable.
Ainsi, le fait d’introduire un nombre aléatoire d’instructions additionnelles illégales successives permet de compliquer une réplication des attaques par injection de fautes sur plusieurs systèmes informatiques différents.
Dans un mode de mise en œuvre avantageux, l’introduction d’instructions additionnelles est réalisée que sur une partie du code objet.
Dans un mode de mise en œuvre avantageux, les instructions additionnelles sont introduites dans le code objet à des emplacements du code objet sélectionnés au moins en partie aléatoirement.
En particulier, les instructions additionnelles sont introduites à des emplacements choisis aléatoirement parmi différents emplacements possibles.
En introduisant aléatoirement les instructions additionnelles, il est possible d’obtenir un code exécutable différent pour chaque compilation d’un même code source.
Comme chaque code exécutable généré à partir d’un même code source est différent, il est plus difficile de réaliser une attaque par injection de faute ayant un même effet sur l’exécution de chaque code exécutable obtenu.
Ainsi, le fait d’introduire au moins en partie aléatoirement les instructions additionnelles permet de compliquer une réplication des attaques par injection de fautes sur plusieurs systèmes informatiques différents.
Selon un autre aspect il est proposé un outil de compilation configuré pour mettre en œuvre le procédé de compilation tel que décrit précédemment.
Selon un autre aspect il est proposé un support d’enregistrement lisible par ordinateur sur lequel est enregistré un outil de compilation tel que décrit précédemment.
Selon un autre aspect, il est proposé un système informatique comprenant :
- une mémoire comportant un code exécutable obtenu à partir d’un procédé de compilation tel que décrit précédemment,
- un processeur configuré pour exécuter ledit code exécutable.
Dans un mode de mise en œuvre avantageux, le système informatique comprend en outre un dispositif de contrôle configuré pour :
- recevoir une exception d’instruction illégale pouvant être générée par le processeur lorsque le processeur lit une instruction additionnelle illégale lors d’une exécution du code exécutable, et
- stopper l’exécution du code exécutable après avoir reçu une exception d’instruction illégale.
D'autres avantages et caractéristiques de l’invention apparaîtront à l’examen de la description détaillée de modes de mise en œuvre et de réalisation, nullement limitatifs, et des dessins annexés sur lesquels :
illustrent schématiquement des modes de réalisation et de mise en œuvre de l’invention.
La illustre un outil de compilation CMP selon un mode de réalisation de l’invention. L’outil de compilation CMP est un compilateur ou programme de compilation, mis en œuvre au sein d’une unité de traitement informatique, par exemple un ordinateur du type PC.
Le compilateur CMP comprend une entrée IN et une sortie OUT. L’entrée IN de l’outil de compilation CMP est configurée pour recevoir un code source CS. Ce code source CS est stocké dans une mémoire de l’unité de traitement L’outil de compilation CMP est configuré pour mettre en œuvre un procédé de compilation selon l’invention et décrit ci-après. Le procédé de compilation permet d’obtenir en sortie OUT un code PRG exécutable par ordinateur. Le code PRG est notamment un programme exécutable par un processeur.
Le processeur sur lequel peut être exécuté le code exécutable peut présenter une architecture de type ARM. Le processeur peut être celui d’un microcontrôleur. Le processeur peut également être un microprocesseur.
Le code source est écrit selon un langage de programmation, par exemple en langage C. Le code source comprend des instructions écrites selon ce langage de programmation. Le code source peut définir plusieurs fonctions comprenant chacune au moins une instruction.
Le code exécutable PRG comprend des instructions en binaire exécutables par un processeur.
Un procédé de compilation selon l’invention pouvant être mis en œuvre par l’outil de compilation CMP est illustré à la . Ce procédé de compilation permet de compiler un code source CS en un code PRG exécutable par ordinateur.
Le procédé comprend tout d’abord une étape 20 de réception dans laquelle l’outil de compilation reçoit en entrée un code source.
Le procédé de compilation comprend une étape 21 de traduction du code source CS reçu en entrée de l’outil de compilation CMP. Lors de cette étape 21, l’outil de compilation traduit les instructions du code source en instructions-machine exécutables par le processeur avec lequel le code exécutable PRG doit être exécuté.
Le procédé de compilation comprend ensuite une étape 22 d’introduction d’instructions additionnelles. Lors de cette étape 22, des instructions additionnelles sont introduites entre des instructions-machine traduites du code source. Cette étape 2 d’introduction permet d’obtenir le code exécutable PRG.
Le code exécutable PRG comprend donc les instructions traduites du code source à l’étape 21 et les instructions additionnelles introduites lors de l’étape 22.
Les instructions additionnelles pouvant être introduites peuvent comprendre des instructions illégales et/ou des instructions de non opération. En particulier, il est possible d’introduire des instructions additionnelles d’un même type ou bien de plusieurs types différents.
Les instructions additionnelles sont introduites à des emplacements du code d’instructions-machine pouvant être choisis entre plusieurs emplacements possibles, notamment dans une fonction ou entre des fonctions du codes. Les emplacements dans lesquels les instructions additionnelles sont introduites peuvent être choisis aléatoirement.
Les instructions additionnelles peuvent être introduites dans l’ensemble du code d’instructions-machine ou bien seulement dans certaines parties de ce code. Leur nombre peut également varier et être choisi aléatoirement.
En outre, l’introduction d’instructions additionnelles, ou le déplacement d’une zone de stockage d’unevaleur littérale comme cela sera décrit dans la suite, peut nécessiter une actualisation des adresses des instructions traduites du code source, notamment dans les fonctions et pour les appels de fonction. Dans les exemples 3-1 à 3-8 en annexe décrits ci-dessous, les adresses des instructions traduites du code source n’ont pas été actualisées pour faciliter la compréhension et la comparaison avec l’exemple de la .
L’introduction d’instructions additionnelles permet d’obtenir un code exécutable PRG robuste, notamment contre les attaques par injection de fautes ou par des perturbations extérieures au processeur.
Le procédé de compilation comprend ensuite une étape 23 de délivrance dans laquelle le code exécutable PRG est délivré en sortie de l’outil de programmation.
Les exemples 3-1 à 3-8 en annexe illustrent différents codes exécutables pouvant être obtenus par différents modes de mise en œuvre M1 à M8 de l’étape 22 du procédé de compilation selon l’invention, à partir d’un code source en langage C représenté à l’exemple 1 en annexe.
Le code source illustré est utilisé uniquement pour faciliter la compréhension du procédé de compilation.
Le code source comprend une fonction principale « main », une fonction « function_a » et une fonction «function_b ».
La fonction « function_b » est écrite à la suite de la fonction « function_a ».
La fonction principale « main » est écrite à la suite de la fonction « function_b ».
La fonction principale comprend un appel à la fonction « function_a ».
Le code source est traduit en instructions binaires exécutables par un processeur ayant une architecture ARM. Ces instructions traduites sont représentées en langage assembleur sur l’exemple 2 en annexe pour faciliter la compréhension du procédé de compilation.
Comme cela peut être constaté sur l’exemple 2 en annexe, les instructions traduites de la fonction « function_b » sont à la suite des instructions traduites de la fonction « function_a ».
En outre, les fonctions « function_a » et « function_b » comprennent chacune une instruction de branchement de fin de fonction représentée en langage assembleur par l’instruction ARM « bx lr » (voir les instructions 5c et 94) traduisant l’instruction « return » en langage C, comme représenté sur l’exemple 1 en annexe.
Des instructions additionnelles sont ensuite introduites dans la suite d’instructions traduites du code source. Différents exemples d’introductions additionnelles introduites dans la suite d’instructions traduites du code source sont illustrés aux exemples 3-1 à 3-8 en annexe. Les instructions sont représentées en langage assembleur sur ces exemples à des fins de compréhension.
Dans le mode de réalisation M1 de l’étape 22 représenté à l’exemple 3-1, des instructions additionnelles illégales sont introduites entre les fonctions. En particulier, ces instructions additionnelles illégales sont introduites après l’instruction de branchement de fin de fonction (c’est-à-dire l’instruction « bx lr ») pour chaque fonction.
Ces instructions illégales sont représentées par l’expression « <UNDEFINED> ».
Dans ce mode de réalisation M1, un même nombre d’instructions additionnelles illégales sont introduites après l’instruction de branchement de fin de fonction de chaque fonction. En particulier, dans ce mode de réalisation, trois instructions additionnelles illégales sont introduites après l’instruction de branchement de fin de fonction. De préférence, au moins deux instructions additionnelles illégales sont ajoutées après l’instruction de branchement de fin de fonction.
En variante, dans le mode de réalisation M2 de l’étape 22 représenté à l’exemple 3-2, un nombre aléatoire d’instructions additionnelles illégales est introduit après l’instruction de branchement de fin de fonction de chaque fonction. Ici, par exemple, deux instructions additionnelles illégales sont introduites après l’instruction de branchement de fin de fonction de la fonction « function_a », quatre instructions additionnelles illégales sont introduites après l’instruction de branchement de fin de fonction de la fonction « function_b », et cinq instructions additionnelles illégales sont introduites après l’instruction de branchement de fin de fonction de la fonction « function_a ». De préférence, au moins deux instructions additionnelles illégales sont ajoutées après l’instruction de branchement de fin de fonction.
Les instructions additionnelles illégales introduites peuvent être lues par le processeur sur lequel est exécuté le code exécutable PRG. La lecture d’une instruction additionnelle illégale génère une exception d’instruction illégale.
Lorsque le code exécutable PRG fonctionne correctement l’instruction de branchement de fin de fonction est exécutée de sorte que les instructions additionnelles illégales ne sont pas lues.
Ces instructions additionnelles peuvent être lues si l’instruction de branchement de fin de fonction n’est pas exécutée par le processeur. Cette instruction de branchement de fin de fonction peut notamment être sautée lorsque le processeur subit une attaque par injection de faute ou bien des perturbations extérieures au processeur.
Lorsque l’instruction de branchement de fin de fonction d’une fonction est sautée, il est possible que le processeur exécute la fonction située à la suite de cette fonction sautée. Par exemple, si l’instruction de branchement de fin de fonction de la fonction « function_a » n’est pas exécutée, le processeur peut exécuter la fonction « function_b ».
Néanmoins, la lecture d’une instruction additionnelle illégale située après une instruction de branchement de fin de fonction permet de générer une exception d’instruction illégale. Comme les instructions additionnelles illégales ne peuvent être lue que lorsque l’instruction de branchement de fin de fonction n’est pas exécutée, la génération d’une exception d’instruction illégale suite à la lecture d’une instruction additionnelle illégale permet d’indiquer un dysfonctionnement dans l’exécution du code exécutable PRG.
Le fait d’introduire au moins deux instructions additionnelles illégales permet de réduire les chances que les instructions additionnelles illégales soient toutes sautées lorsque l’exécution du code exécutable PRG subit un dysfonctionnement.
Il est également possible d’introduire des instructions additionnelles illégales au sein des fonctions, tel que dans les modes de mise en œuvre illustrés aux exemples 3-3 et 3-4.
Comme représenté dans le mode de mise en œuvre M3 de l’étape 22 illustré à l’exemple 3-3, le procédé de compilation peut être adapté pour introduire au moins une instruction additionnelle de branchement inconditionnel suivie d’au moins une instruction additionnelle illégale entre deux instructions traduites du code source. L’instruction additionnelle de branchement inconditionnel est donc située à la suite de la première instruction de ces deux instructions traduites du code source et prend comme opérande l’adresse de la deuxième instruction de ces deux instructions. De préférence, au moins deux instructions additionnelles illégales sont introduites à la suite de l’instruction additionnelle de branchement. Le nombre d’instructions additionnelles illégales à la suite de l’instruction additionnelle de branchement inconditionnel peut également être choisi aléatoirement.
Le fait d’introduire un nombre aléatoire d’instructions additionnelles illégales successives permet de compliquer une réplication des attaques par injection de fautes sur plusieurs systèmes informatiques différents.
En particulier, dans l’exemple illustré, ces instructions additionnelles sont introduites entre les instructions 34 et 38 de la fonction « function_a ». L’instruction additionnelle de branchement inconditionnel pointe sur l’adresse de l’instruction 38 de la fonction « function_a » et est suivie de deux instructions additionnelles illégales.
Ainsi, lorsque le code exécutable PRG s’exécute normalement, l’instruction additionnelle de branchement est exécutée de sorte que les instructions additionnelles illégales ne sont pas lues.
Néanmoins, lorsque l’instruction additionnelle de branchement n’est pas exécutée suite à un dysfonctionnement dans l’exécution du code exécutable PRG, les instructions additionnelles illégales situées à la suite de cette instruction additionnelle de branchement sont lues. Des exceptions d’instruction illégale sont alors générées. Ces exceptions d’instruction illégale peuvent ainsi être utilisées pour détecter un dysfonctionnement dans l’exécution du code exécutable PRG.
Par ailleurs, comme représenté dans le mode de mise en œuvre M4 de l’étape 22 représenté à l’exemple 3-4, au moins une instruction additionnelle illégale peut être introduite au sein d’une fonction à la suite d’une instruction de branchement inconditionnel traduite du code source. De préférence, au moins deux instructions additionnelles illégales sont ajoutées après une instruction de branchement inconditionnel traduite du code source. Le nombre d’instructions additionnelles illégales à la suite d’une instruction de branchement traduite du code source peut également être choisi aléatoirement.
En particulier, dans l’exemple illustré à l’exemple 3-4, deux instructions additionnelles illégales sont ajoutées après les instructions de branchement inconditionnel 2c, 4c et 50 de la fonction « function_a ».
L’instruction de branchement inconditionnel 2c est utilisée avant une instruction « return » d’une première structure « if » de la fonction « function_a » dans le code source. Cette instruction de branchement 2c permet ensuite de réaliser l’instruction 5c de branchement de fin de fonction traduisant l’instruction « return ».
L’instruction de branchement 4c est utilisée avant une instruction « return » d’une deuxième structure « if » de la fonction « function_a » dans le code source. Cette instruction de branchement 2c permet ensuite de réaliser de l’instruction 5c de branchement de fin de fonction traduisant l’instruction « return ».
L’instruction de branchement 50 est utilisée pour traduire la structure « while(1) » de la fonction « function_a » du code source.
Ainsi, lorsque le code exécutable PRG s’exécute normalement, l’instruction de branchement traduite du code source est exécutée de sorte que les instructions additionnelles illégales qui la suivent ne sont pas lues.
Néanmoins, lorsque l’instruction de branchement traduite du code source n’est pas exécutée suite à un dysfonctionnement dans l’exécution du code exécutable PRG, les instructions additionnelles illégales situées à la suite de cette instruction de branchement sont lues. Des exceptions d’instructions illégales sont alors générées. Ces exceptions d’instructions illégales peuvent ainsi être utilisées pour détecter un dysfonctionnement dans l’exécution du code exécutable PRG.
Par ailleurs, il est également possible d’utiliser certaines zones de stockage de valeurs littérales (en anglais « literal pool ») comme instructions additionnelles illégales au sein des fonctions, tel que dans le mode de mise en œuvre M5 de l’étape 22 illustré à l’exemple 3-5.
Les valeurs littérales sont des valeurs immédiates pouvant être stockées dans des zones du code exécutable. Ces valeurs littérales ne sont pas des instructions à exécuter par le processeur et sont traitées comme des instructions illégales lorsqu’elles sont lues. Ainsi, une valeur littérale peut être utilisée comme une instruction illégale pour détecter un dysfonctionnement dans l’exécution d’un code exécutable PRG. Par exemple, une valeur littérale peut être utilisée comme instruction illégale, en déplaçant la zone de stockage de cette valeur littérale après une instruction additionnelle de branchement introduite parmi les instructions traduites du code source, ou bien après une instruction de branchement traduite du code source.
Dans l’exemple illustré à l’exemple 3-5, deux valeurs littérales sont utilisées comme instructions illégales : la valeur littérale stockée à l’adresse <function_a+0x60> et la valeur littérale stockée à l’adresse <function_a+0x6c>. Une instruction additionnelle illégale est également introduite après cette dernière valeur littérale.
En particulier, comme on peut le voir sur cet exemple 3-5, la zone de stockage de la valeur littérale a été déplacée pour être placée à la suite de l’instruction de branchement de fin de fonction.
Ainsi, ces deux valeurs littérales et cette instruction additionnelle illégale peuvent servir pour détecter un dysfonctionnement dans l’exécution du code exécutable PRG.
Plus particulièrement, lorsque le code exécutable PRG s’exécute normalement, l’instruction de branchement de fin de fonction traduite du code source est exécutée de sorte que les valeurs littérales et l’instruction additionnelle illégale qui les suit ne sont pas lues.
Néanmoins, lorsque l’instruction de branchement de fin de fonction n’est pas exécutée suite à un dysfonctionnement dans l’exécution du code exécutable PRG, les valeurs littérales peuvent être lues et interprétées comme une instruction illégale. Des exceptions d’instruction illégale sont dans ce cas générées. De même, la lecture de l’instruction additionnelle illégale entraîne une génération d’une exception d’instruction illégale. Ces exceptions d’instruction illégale peuvent ainsi être utilisées pour détecter un dysfonctionnement dans l’exécution du code exécutable PRG.
L’utilisation de valeur littérales comme instructions illégales permet de réduire le nombre d’instructions additionnelles illégales à insérer dans le code exécutable PRG. Cela permet donc de réduire la taille du code exécutable PRG.
Par ailleurs, comme représenté dans le mode de mise en œuvre M6 de l’étape 22 représenté à l’exemple 3-6, au moins une instruction additionnelle illégale peut être introduite à la suite d’un appel de fonction. De préférence, au moins deux instructions additionnelles illégales sont introduites après un appel de fonction. Le nombre d’instructions additionnelles illégales à introduire à la suite d’un appel de fonction peut également être choisi aléatoirement.
En particulier, dans l’exemple illustré à l’exemple 3-6, trois instructions additionnelles illégales sont ajoutées dans la fonction « main » après l'instruction b4 de branchement (« bl 0<function_a> ») servant d’appel à la fonction « function_a ».
L’ajout d’instructions illégales après une instruction d’appel de fonction implique de modifier le registre LR (de l’anglais « link register ») à la fin de l’appel à la fonction. En particulier le registre LR est modifié de façon à pointer sur l’adresse de l’instruction qui suit les instructions additionnelles illégales introduites après l’instruction d’appel à la fonction.
Par exemple, dans l’exemple représenté à l’exemple 3-6, afin de modifier le registre LR, une instruction additionnelle est ajoutée dans la fonction « function_a » avant l’instruction 5c (« bx lr ») de branchement de fin de fonction permettant de retourner à la fonction principale « main » (traduisant l’instruction « return » dans le code source). Cette instruction additionnelle est une instruction d’addition (« add lr, lr, #12 ») permettant d’ajouter à l’adresse contenue dans le registre LR le nombre d’instructions additionnelles illégales introduites après l’instruction b4 d’appel de fonction. En particulier, dans l’exemple 3-6, on ajoute douze à la valeur du registre LR car trois instructions additionnelles illégales ont été introduites, la taille de chaque instruction additionnelle illégale étant de quatre octets.
Ainsi, lorsque le code exécutable PRG est exécuté normalement, l’instruction b4 de branchement pour appeler la fonction « function_a » est exécutée. Puis, à la fin de l’exécution de la fonction « function_a », le processeur exécute l’instruction b8 qui suit les instructions additionnelles illégales. Les instructions additionnelles ne sont donc pas lues.
Néanmoins, lorsque l’instruction b4 de branchement pour appeler la fonction « function_a » n’est pas exécutée suite à un dysfonctionnement dans l’exécution du code exécutable PRG, la fonction « function_a » n’est pas exécutée et les instructions additionnelles illégales situées à la suite de cette instruction de branchement sont lues. Des exceptions d’instructions illégales sont alors générées. Ces exceptions d’instructions illégales peuvent ainsi être utilisées pour détecter un dysfonctionnement dans l’exécution du code exécutable PRG.
Par ailleurs, comme représenté dans le mode de mise en œuvre M7 de l’étape 22 représenté à l’exemple 3-7, au moins une instruction additionnelle illégale peut être introduite au sein d’une fonction à la suite d’une instruction de branchement conditionnel (en particulier après des instructions « beq » ou « bne »). L’instruction de branchement conditionnel peut être une instruction traduite du code source ou bien une instruction ajoutée parmi les instructions traduites du code source. Dans ce dernier cas, on introduit donc une instruction de branchement conditionnel suivie d’au moins une instruction additionnelle illégale parmi les instructions traduites du code source.
En particulier, les instructions additionnelles illégales sont ajoutées après des instructions de branchement conditionnel pour lesquelles la condition de ces branchements est forcément vérifiée lors d’une exécution normale du code exécutable PRG.
Plus particulièrement, les instructions de branchement conditionnel peuvent par exemple être utilisés après une instruction de comparaison.
Une instruction de comparaison permet de comparer deux valeurs afin de savoir si ces valeurs sont égales ou non, puis de réaliser certaines autres instructions selon le résultat obtenu de cette comparaison. La sélection de ces autres instructions à réaliser est effectuée grâce à une instruction de branchement conditionnel.
Afin de s’assurer qu’une instruction de comparaison traduite du code source suivie d’une première instruction de branchement conditionnel est bien effectuée lors d’une exécution du code exécutable PRG, il est possible d’introduire cette même instruction de comparaison suivie d’une deuxième instruction de branchement conditionnel opposée à la première instruction de branchement conditionnel. Cette instruction de comparaison suivie de la deuxième instruction de branchement peut être introduite avant ou après l’instruction de comparaison traduite du code source suivie de la première instruction de branchement.
Une instruction additionnelle illégale est introduite suite à l’instruction de branchement conditionnel de la comparaison la plus éloignée dans l’ordre d’exécution des instructions du code exécutable PRG. Ainsi, si ni le premier branchement conditionnel ni le deuxième branchement conditionnel n’est exécuté, l’instruction additionnelle illégale est lue. Cela signifie que l’exécution du code exécutable PRG ne s’est pas déroulée correctement. En effet, du fait que les deux instructions de branchement conditionnel sont opposées, lors d’une exécution normale du code exécutable PRG, au moins l’un des deux branchements conditionnels doit être effectué.
La lecture de l’instruction additionnel illégale génère une exception d’instruction illégale. Cette exception d’instruction illégale peut ainsi être utilisée pour détecter un dysfonctionnement dans l’exécution du code exécutable PRG.
En particulier, dans l’exemple illustré à l’exemple 3-7, des instructions additionnelles sont introduites parmi les instructions traduites du code source afin de vérifier que l’instruction c4 de comparaison et l’instruction c8 de branchement conditionnel seront bien exécutées lors d’une exécution du code exécutable PRG.
En particulier, une première série d’instructions additionnelles S1 sont introduites entre les instructions c0 et c4 traduites du code source. Cette première série d’instructions additionnelles sont introduites pour initialiser un indicateur de zéro (en anglais « zero flag ») à ‘1’. En particulier, la valeur de cet indicateur de zéro est défini par le résultat de chaque instruction de comparaison. Les instructions de branchement conditionnel utilisent cet indicateur de zéro pour déterminer si le branchement doit être effectué ou non.
La première série d’instructions additionnelles comprend une instruction de comparaison utilisée pour comparer la valeur du registre r3 à cette même valeur du registre r3. Le registre r3 est le registre utilisé pour la comparaison de l’instruction c4 traduite du code source. Les deux valeurs comparées étant identiques, l’instruction de comparaison introduite permet de déterminer que ces deux valeurs sont égales. L’instruction de comparaison introduite permet donc d’initialiser l’indicateur de zéro à ‘1’ lorsqu’elle est exécutée.
La première série d’instructions additionnelles comprend en outre une instruction de branchement conditionnel à la suite de l’instruction de comparaison, et une instruction additionnelle illégale à la suite de cette instruction de branchement conditionnel. L’instruction de branchement conditionnel est de type « beq » (de l’anglais « branch if equal ») et permet donc d’effectuer un branchement lorsque le résultat de la comparaison qui la précède permet de déterminer une égalité entre les deux valeurs testées. L’instruction de branchement conditionnel lit l’indicateur de zéro pour déterminer si le branchement doit être effectué. Si l’instruction de comparaison introduite qui précède cette instruction de branchement conditionnel a bien été exécutée, l’indicateur de zéro est à ‘1’ de sorte que le branchement est forcément effectué si le code exécutable PRG s’exécute normalement, et la prochaine instruction devant être exécutée est l’instruction c4. Néanmoins, si l’instruction de comparaison n’a pas été exécutée, suite à un dysfonctionnement, le branchement n’est pas effectué et l’instruction additionnelle illégale est lue. La lecture de cette instruction additionnelle illégale génère une exception d’instruction illégale. Cette exception d’instruction illégale permet de détecter un dysfonctionnement dans l’exécution du code exécutable PRG.
L’instruction c4, qui suit la première série d’instructions additionnelles, est une instruction de comparaison traduite du code source permettant de comparer la valeur du registre r3 à la valeur ‘0’.
Cette instruction est suivie par une instruction c8 de branchement conditionnel de type « bne » (de l’anglais « branch if not equal »). Cette instruction permet d’effectuer un branchement si les valeurs testées par la comparaison effectuée à partir de l’instruction c4 ne sont pas égales.
Une deuxième série d’instructions additionnelles S2 sont introduites après l’instruction c8 traduite du code source.
La deuxième série d’instructions additionnelles comprend une instruction de comparaison utilisée pour comparer la valeur du registre r3 à la valeur ‘1’. L’instruction de comparaison introduite permet donc de mettre l’indicateur de zéro à ‘0’.
La deuxième série d’instructions additionnelles comprend en outre une instruction de branchement conditionnel à la suite de l’instruction de comparaison, et une instruction additionnelle illégale à la suite de cette instruction de branchement conditionnel. L’instruction de branchement conditionnel est de type « bne » (de l’anglais « branch if not equal ») et permet donc d’effectuer un branchement lorsque le résultat de la comparaison qui la précède permet de déterminer une différence entre les deux valeurs testées. L’instruction de branchement conditionnel lit l’indicateur de zéro pour déterminer si le branchement doit être effectué. Si l’instruction de comparaison introduite qui précède cette instruction de branchement conditionnel a bien été exécutée, l’indicateur de zéro est à ‘0’ de sorte que le branchement est forcément effectué si le code exécutable PRG s’exécute normalement, et la prochaine instruction devant être exécutée est l’instruction yy. Néanmoins, si l’instruction de comparaison n’a pas été exécutée, suite à un dysfonctionnement, le branchement n’est pas effectué et l’instruction additionnelle illégale est lue. La lecture de cette instruction additionnelle illégale génère une exception d’instruction illégale. Cette exception d’instruction illégale permet de détecter un dysfonctionnement dans l’exécution du code exécutable PRG.
Une troisième série d’instructions additionnelles S3 sont introduites après la deuxième série d’instructions additionnelles S2.
La troisième série d’instructions additionnelles comprend une instruction de comparaison identique à l’instruction c4 de comparaison traduite du code source.
La troisième série d’instructions additionnelles comprend en outre une instruction de branchement conditionnel à la suite de l’instruction de comparaison, et une instruction additionnelle illégale à la suite de cette instruction de branchement conditionnel.
L’instruction de branchement conditionnel est de type « beq » (de l’anglais « branch if equal ») et est donc opposée à l’instruction c8 de branchement conditionnel.
Lors d’une exécution normale du code exécutable PRG, l’instruction de comparaison de la troisième série d’instruction ne peut être exécutée que si la comparaison effectuée à partir de l’instruction c4 a permis de déterminer que la valeur du registre r3 est égale à ‘0’. De ce fait, lors d’une exécution normale du code exécutable PRG, la comparaison effectuée à partir de l’instruction de comparaison introduite dans la troisième série d’instructions additionnelles doit déterminer que la valeur du registre r3, qui n’a pas modifié, est toujours égale à ‘0’. Ainsi, lors d’une exécution normale du code exécutable PRG, la condition de l’instruction de branchement conditionnel de la troisième série d’instructions additionnelles est vérifiée et le branchement doit être effectuée. L’instruction suivante devant être lue est donc l’instruction cc.
Néanmoins, si l’instruction additionnelle illégale de la troisième série d’instructions additionnelles est lue, cela signifie que l’exécution du code exécutable PRG a subi un dysfonctionnement. La lecture de cette instruction additionnelle illégale génère une exception d’instruction illégale. Cette exception d’instruction illégale permet de détecter un dysfonctionnement dans l’exécution du code exécutable PRG.
Dans les modes de mises en œuvre dans lesquels des instructions additionnelles illégales sont introduites parmi les instructions traduites du code source, il est prévu un dispositif de contrôle DCTRL dans le système informatique SYS avec lequel le code exécutable peut être exécuté.
Un tel système informatique SYS est représenté à la . Le système informatique SYS comprend une mémoire MEM non volatile comportant un code exécutable PRG obtenu à partir du procédé de compilation décrit précédemment.
Le système informatique SYS comprend en outre un processeur PROC configuré pour exécuter le code exécutable PRG.
Le dispositif de contrôle DCTRL est configuré pour détecter les exceptions d’instruction illégale. Ce dispositif de contrôle DCTRL est configuré pour stopper une exécution non contrôlée du code exécutable PRG, après avoir détecté ces exceptions d’instruction illégales, puis pour effectuer une action de sécurisation.
L’action de sécurisation peut être par exemple une réinitialisation du processeur exécutant le code exécutable PRG ou un effacement des données sensibles, telles que des clés de cryptographie. L’action de sécurisation peut également être une écriture dans les registres RTC (acronyme de l’anglais « Real Time Clock ») pour mémoriser une tentative d’attaque par injection de faute. Il est également possible de ralentir le processeur pour ralentir les tentatives d’attaques.
Le système informatique sur lequel est exécuté le code exécutable PRG peut comprendre un tel dispositif de contrôle.
Le dispositif de contrôle peut être mis en œuvre par des moyens logiciels ou bien des moyens matériels, par exemple par un circuit logique.
Par ailleurs, comme vu précédemment, les instructions additionnelles introduites à l’étape 22 du procédé de compilation peuvent être des instructions de non opération (« nop »). Un tel mode de mise en œuvre M8 de l’étape 22 est représenté à l’exemple 3-8.
Ces instructions additionnelles de non opération sont introduites au sein des fonctions à des emplacements choisis aléatoirement parmi les instructions traduites du code source.
En effet, le fait d’introduire aléatoirement des instructions de non opération permet d’obtenir un code exécutable PRG différent pour chaque compilation de façon à compliquer une réplication des attaques par injection de fautes sur plusieurs systèmes informatiques en s’appuyant sur la même implantation logicielle.
Le fait d’introduire des instructions additionnelles entre les instructions traduites du code source permet d’améliorer la robustesse du code exécutable PRG compilé en termes de sûreté et contre les attaques par injection de faute.
Un tel procédé de compilation permet de faciliter le développement du code exécutable car l’insertion des instructions additionnelles est effectuée automatiquement par l’outil de compilation.
En outre, l’exécution du code exécutable peut s’effectuer en utilisant une mémoire flash, et non pas une mémoire RAM (acronyme de l’anglais « Random Access Memory »).
ANNEXE
Exemple 1 : Code source (en langage C) :
Exemple 2 : Code objet traduit du code source de l’exemple 1 (en langage assembleur ARM)
Exemple 3-1 : code exécutable pouvant être obtenu par un premier mode de mise en œuvre M1 de l’étape 22 du procédé de compilation (traduit en langage assembleur ARM)
Exemple 3-2 : code exécutable pouvant être obtenu par un deuxième mode de mise en œuvre M2 de l’étape 22 procédé de compilation (traduit en langage assembleur ARM)
Exemple 3-3 : code exécutable pouvant être obtenu par un troisième mode de mise en œuvre M3 de l’étape 22 du procédé de compilation (traduit en langage assembleur ARM)
Exemple 3-4 : code exécutable pouvant être obtenu par un quatrième mode de mise en œuvre M4 de l’étape 22 du procédé de compilation (traduit en langage assembleur ARM)
Exemple 3-5 : code exécutable pouvant être obtenu par un cinquième mode de mise en œuvre M5 de l’étape 22 du procédé de compilation (traduit en langage assembleur ARM)
Exemple 3-6 : code exécutable pouvant être obtenu par un sixième mode de mise en œuvre M6 de l’étape 22 du procédé de compilation (traduit en langage assembleur)
Exemple 3-7 : code exécutable pouvant être obtenu par un septième mode de mise en œuvre M7 de l’étape 22 du procédé de compilation (traduit en langage assembleur)
Exemple 3-8 : code exécutable pouvant être obtenu par un huitième mode de mise en œuvre M8 de l’étape 22 du procédé de compilation (traduit en langage assembleur)

Claims (14)

  1. Procédé de compilation par un outil de compilation d’un code source (CS) en un code (PRG) exécutable par ordinateur, l’outil de compilation étant mis en œuvre au sein d’une unité de traitement informatique, procédé comprenant :
    - une réception (20) en entrée de l’outil de compilation du code source et un stockage du code source dans une mémoire de l’unité de traitement,
    - une traduction (21), par l’outil de compilation, du code source (CS) en un code objet comprenant des instructions-machines exécutables par un processeur, puis
    - une introduction (22) par l’outil de compilation, entre des instructions-machines du code objet, d’instructions additionnelles choisies parmi des instructions illégales et des instructions de non opération de façon à obtenir ledit code exécutable (PRG), puis
    - une délivrance (23) du code exécutable (PRG) en sortie de l’outil de compilation.
  2. Procédé selon la revendication 1, dans lequel le code objet comprend des fonctions comportant un ensemble d’instructions-machine, les instructions additionnelles illégales étant introduites entre des fonctions du code objet.
  3. Procédé selon l’une quelconque des revendications 1 ou 2, dans lequel au moins une instruction additionnelle illégale est introduite après une instruction de branchement du code objet traduit à partir du code source (CS).
  4. Procédé selon l’une des revendications 1 à 3, dans lequel une instruction additionnelle de branchement suivie d’au moins une instruction additionnelle illégale sont introduites entre deux instructions-machine du code objet traduit du code source.
  5. Procédé selon l’une des revendications 1 à 4, dans laquelle le code objet traduit du code source comprend une instruction de comparaison suivie d’une instruction de branchement conditionnel,
    et dans laquelle une instruction additionnelle de comparaison suivie d’une instruction additionnelle de branchement conditionnel est introduite dans le code objet en amont de l’instruction de comparaison traduite du code source ou à la suite de l’instruction de branchement conditionnel traduite du code source, l’instruction additionnelle de comparaison étant identique à l’instruction de comparaison traduite du code source et l’instruction additionnelle de branchement conditionnel étant opposée à l’instruction de branchement conditionnel suivant l’instruction de comparaison traduite du code source,
    et dans laquelle au moins une instruction additionnelle illégale est introduite à la suite de la dernière instruction de branchement conditionnel parmi l’instruction additionnelle de branchement conditionnel et l’instruction de branchement conditionnel traduite du code source.
  6. Procédé selon l’une des revendications 1 à 5, dans lequel au moins une instruction additionnelle illégale est introduite après une instruction de branchement d’appel à une fonction, et au moins une instruction d’addition est introduite dans ladite fonction, cette instruction d’addition étant configurée pour pouvoir modifier une adresse de retour stockée dans un registre de liens en ajoutant à cette adresse de retour le nombre d’instructions additionnelles illégales introduites après l’instruction de branchement d’appel à la fonction.
  7. Procédé selon l’une des revendications 1 à 6, dans lequel au moins deux instructions additionnelles illégales successives sont introduites entre au moins deux instructions-machine du code objet traduit du code source.
  8. Procédé selon la revendication 7, dans lequel le nombre d’instructions additionnelles illégales successives introduites entre au moins deux instructions-machine du code objet traduit du code source est choisi aléatoirement.
  9. Procédé selon l’une des revendications 1 à 8, dans lequel l’introduction d’instructions additionnelles n’est réalisée que sur une partie du code objet.
  10. Procédé selon l’une des revendications 1 à 9, dans lequel les instructions additionnelles sont introduites dans le code objet à des emplacements du code objet sélectionnés au moins en partie aléatoirement.
  11. Outil de compilation configuré pour mettre en œuvre le procédé de compilation selon l’une des revendications 1 à 10.
  12. Support d’enregistrement lisible par ordinateur sur lequel est enregistré l’outil de compilation (CMP) selon la revendication 11.
  13. Système informatique comprenant :
    - une mémoire (MEM) comportant un code exécutable (PRG) obtenu à partir d’un procédé de compilation selon l’une des revendications 1 à 10,
    - un processeur (PROC) configuré pour exécuter ledit code exécutable (PRG).
  14. Système informatique selon la revendication 13 comprenant en outre un dispositif de contrôle (PCTRL) configuré pour :
    - recevoir une exception d’instruction illégale pouvant être générée par le processeur lorsque le processeur lit une instruction additionnelle illégale lors d’une exécution du code exécutable, et
    - stopper l’exécution du code exécutable après avoir reçu une exception d’instruction illégale.
FR2011657A 2020-11-13 2020-11-13 Procédé de compilation d’un code source Active FR3116356B1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR2011657A FR3116356B1 (fr) 2020-11-13 2020-11-13 Procédé de compilation d’un code source
US17/451,394 US11893370B2 (en) 2020-11-13 2021-10-19 System and process for compiling a source code
CN202111336977.7A CN114489657A (zh) 2020-11-13 2021-11-12 用于编译源代码的系统和过程

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2011657 2020-11-13
FR2011657A FR3116356B1 (fr) 2020-11-13 2020-11-13 Procédé de compilation d’un code source

Publications (2)

Publication Number Publication Date
FR3116356A1 true FR3116356A1 (fr) 2022-05-20
FR3116356B1 FR3116356B1 (fr) 2024-01-05

Family

ID=75108404

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2011657A Active FR3116356B1 (fr) 2020-11-13 2020-11-13 Procédé de compilation d’un code source

Country Status (2)

Country Link
US (1) US11893370B2 (fr)
FR (1) FR3116356B1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070250703A1 (en) * 2004-10-22 2007-10-25 Oberthur Card System Sa Protection Against Attacks by Generation of Errors on Jump Instructions
WO2020080515A1 (fr) * 2018-10-18 2020-04-23 Denso Corporation Systèmes et procédés d'exécution parallèle et de comparaison de processus associés pour une protection contre les défaillances

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10101956A1 (de) * 2001-01-17 2002-07-25 Infineon Technologies Ag Verfahren zur Erhöhung der Sicherheit einer CPU
JP2003005980A (ja) * 2001-06-22 2003-01-10 Matsushita Electric Ind Co Ltd コンパイル装置およびコンパイルプログラム
US20150227371A1 (en) * 2014-02-12 2015-08-13 Imagination Technologies Limited Processors with Support for Compact Branch Instructions & Methods
JP6370098B2 (ja) * 2014-05-16 2018-08-08 杉中 順子 情報処理装置、情報処理監視方法、プログラム、及び記録媒体
US10936714B1 (en) * 2018-02-02 2021-03-02 Itsec Analytics Pte. Ltd. Systems and methods for preventing code insertion attacks
US11809871B2 (en) * 2018-09-17 2023-11-07 Raytheon Company Dynamic fragmented address space layout randomization

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070250703A1 (en) * 2004-10-22 2007-10-25 Oberthur Card System Sa Protection Against Attacks by Generation of Errors on Jump Instructions
WO2020080515A1 (fr) * 2018-10-18 2020-04-23 Denso Corporation Systèmes et procédés d'exécution parallèle et de comparaison de processus associés pour une protection contre les défaillances

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KEULENAER RONALD DE ET AL: "Link-time smart card code hardening", INTERNATIONAL JOURNAL OF INFORMATION SECURITY (IJIS), SPRINGER, HEIDELBERG, DE, vol. 15, no. 2, 27 March 2015 (2015-03-27), pages 111 - 130, XP035894606, ISSN: 1615-5262, [retrieved on 20150327], DOI: 10.1007/S10207-015-0282-0 *

Also Published As

Publication number Publication date
FR3116356B1 (fr) 2024-01-05
US11893370B2 (en) 2024-02-06
US20220164172A1 (en) 2022-05-26

Similar Documents

Publication Publication Date Title
EP3457620B1 (fr) Procédé d&#39;exécution d&#39;un code binaire d&#39;une fonction sécurisée par un microprocesseur
EP2453356B1 (fr) Procédé, programme d&#39;ordinateur et dispositif de sécurisation de code intermédiaire de programmation pour son exécution par une machine virtuelle
WO2004066127A1 (fr) Procede et dispositif de securisation de l&#39;execution d&#39;un programme informatique
Grech et al. Elipmoc: Advanced decompilation of ethereum smart contracts
FR2798204A1 (fr) Points d&#39;interruption classes et methode de debogage des programmes informatiques
FR2961922A1 (fr) Procede de compilation selective, dispositif et produit programme d&#39;ordinateur correspondant.
FR2794543A1 (fr) Migration de differents langages sources vers un support d&#39;execution
FR2914081A1 (fr) Procede de protection de documents numeriques contre des utilisations non autorisees.
Li et al. Detecting standard violation errors in smart contracts
EP3457621A1 (fr) Procédé d&#39;exécution d&#39;un code binaire d&#39;une fonction sécurisée par un microprocesseur
Schneidewind et al. The good, the bad and the ugly: Pitfalls and best practices in automated sound static analysis of ethereum smart contracts
FR3071082A1 (fr) Procede d&#39;execution d&#39;un code binaire d&#39;une fonction securisee par un microprocesseur
EP1728354A1 (fr) Procede d&#39;authentification dynamique de programmes par un objet portable electronique
FR2871590A1 (fr) Procede de chargement d&#39;un logiciel en langage intermediaire oriente objet dans un appareil portatif.
FR3116356A1 (fr) Procédé de compilation d’un code source
FR3065095A1 (fr) Procede d&#39;execution d&#39;un code machine d&#39;une fonction securisee
EP3284206B1 (fr) Procédé de sécurisation de l&#39; exécution d&#39;un programme
FR2895814A1 (fr) Procede de securisation de l&#39;execution d&#39;un programme d&#39;ordinateur
Anwar et al. Extracting Threat Intelligence From Cheat Binaries For Anti-Cheating
FR2831684A1 (fr) Installation de programme compile notamment dans une carte a puce
FR2817363A1 (fr) Verification formelle notamment d&#39;une machine virtuelle securisee
FR3008504A1 (fr) Procede de fourniture d&#39;un code d&#39;instruction et circuit
Song Computer Security Optional Notes
EP4131041B1 (fr) Procédé de vérification d&#39;une exécution d&#39;un programme logiciel
FR2888369A1 (fr) Protection contre les attaques par generation de fautes sur les instructions de saut

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20220520

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4