EP3182286B1 - Procede de verification de fonctionnalites d'un logiciel destine a etre embarque dans un composant cryptographique, systeme - Google Patents

Procede de verification de fonctionnalites d'un logiciel destine a etre embarque dans un composant cryptographique, systeme Download PDF

Info

Publication number
EP3182286B1
EP3182286B1 EP16204849.0A EP16204849A EP3182286B1 EP 3182286 B1 EP3182286 B1 EP 3182286B1 EP 16204849 A EP16204849 A EP 16204849A EP 3182286 B1 EP3182286 B1 EP 3182286B1
Authority
EP
European Patent Office
Prior art keywords
function
result
software
memory
cryptographic
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.)
Active
Application number
EP16204849.0A
Other languages
German (de)
English (en)
Other versions
EP3182286A1 (fr
Inventor
Julien Prat
Fany VETU
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.)
Airbus DS SLC SAS
Original Assignee
Airbus DS SLC 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 Airbus DS SLC SAS filed Critical Airbus DS SLC SAS
Publication of EP3182286A1 publication Critical patent/EP3182286A1/fr
Application granted granted Critical
Publication of EP3182286B1 publication Critical patent/EP3182286B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26—Functional testing
    • G06F11/261—Functional testing by simulating additional hardware, e.g. fault simulation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/28—Error detection; Error correction; Monitoring by checking the correct order of processing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3604—Analysis of software for verifying properties of programs
    • G06F11/3612—Analysis of software for verifying properties of programs by runtime analysis
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3698—Environments for analysis, debugging or testing of software
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/72—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 in cryptographic circuits

Definitions

  • the field of the invention relates to methods making it possible to validate the state of a memory after the execution of an executable program when this program handles encrypted data.
  • the validation of the memory makes it possible to judge the good execution of a program.
  • the field therefore relates to that of methods allowing verification of the correct functioning of a computer program, also called software, before it is put into production in a dedicated component.
  • a cryptographic component allows the execution of various functions by means of software embedded in the cryptographic component.
  • a function makes it possible to process unencrypted data in order to encrypt it.
  • the tests consisting in validating the correct functioning of such a cryptographic component are difficult to implement.
  • the main operations performed by cryptographic functions cannot be validated simply during debugging operations.
  • Document D1 ( DI NATALE G ET AL: "A Reliable Architecture for the Advanced Encryption Standard ”) is considered to be the state of the art closest to the subject of the invention since it belongs to the same technical field of cryptographic functions.
  • Document D1 concerns the detection of hardware failures during the execution of a AES-type encryption algorithm, the algorithm being executed in parallel on several identical blocks (“RSMA blocks”). To do this, at each clock cycle, the output of two of the blocks having received the same inputs are compared for detect possible faults, therefore faults can only be detected when the output of the affected block is compared to that of another block, and as a result it is possible for errors to occur without being detected.
  • the invention aims to overcome the aforementioned drawbacks.
  • the invention is defined by a method for validating the operation of a first software (SW1) intended to be embedded in a cryptographic component according to claim 1 and by a system for testing software executing a set of cryptographic functions of software intended to be integrated into a cryptographic component according to claim 12.
  • SW1 first software
  • SW1 system for testing software executing a set of cryptographic functions of software intended to be integrated into a cryptographic component according to claim 12.
  • the system of the invention makes it possible to implement all the steps of the method of the invention as well as all the embodiments.
  • the term “cryptographic component” is understood to mean a component comprising a memory, inputs and outputs, a processor such as a microprocessor and performing cryptographic functions.
  • the memory includes volatile memory such as RAM and non-volatile memory such as Flash memory.
  • volatile memory erases its saved data on each reboot of the volatile memory.
  • non-volatile memory backs up the data stored during the various operations performed by the cryptographic functions.
  • the method of the invention applies to any cryptographic component which requires preserving the state of the memory, that is to say its content, vis-à-vis a third party.
  • the memory of a cryptographic component is not accessible. When accessible, data is encrypted and cannot be retrieved "unencrypted" by a third party.
  • the method of the invention makes it possible, during phases of testing and validation of the software of a cryptographic component, to verify the correct functioning of the software despite the non-accessibility of the state of the memory modified by the execution of a cryptographic function. .
  • Each cryptographic function can be represented by a set of instructions making it possible, from input data, to generate output data such as for example an encrypted key. Certain instructions implement the inputs and outputs of the component and / or the memory so that the state of the memory or of the component is modified by the execution of these instructions. Other instructions do not modify the state of the memory or certain inputs or outputs of the cryptographic component.
  • a simulator within the meaning of the present invention of a cryptographic component is produced to test the main cryptographic functions having an impact on the state of the memory of the component or its inputs and outputs.
  • An advantage of using a simulator 11 is to be able to read the state of the memory M1 and to compare it with a state of a memory M2 of a test bench 10 reproducing the modifications of the state of the memory.
  • the simulator 11 makes it possible to define the accesses to the memory M1 and to extract its content in order to perform comparison operations.
  • a first software SW1 is intended to be embedded on the cryptographic component.
  • the first software SW1 makes it possible to carry out a set of cryptographic functions.
  • the first SW1 software to be tested is embedded in a simulator.
  • the first software SW1 when the first software SW1 is tested and validated, it is then on board a cryptographic component which is integrated into a communication device such as a mobile.
  • the inputs and outputs of the cryptographic component are reproduced in the simulator making it possible to test and validate the SW1 software.
  • a second software SW2 is designed to reproduce simplified functions of the first software SW1.
  • the second software SW2 reproduces the main cryptographic functions of the first software SW1 while not reproducing certain processing operations not necessary for the validation of the cryptographic functions.
  • the first software SW1 comprises instructions having no impact on the state of the memory or on the inputs and outputs.
  • the verifications can be carried out by means of comparison of the states of the memories associated with each of the software.
  • the method of the invention therefore makes it possible to have a simple test tool while ensuring that the results of the tests are representative of the operational functioning of the first software SW1 in the cryptographic component.
  • the figure 1 represents a functional diagram of the method of the invention.
  • the second software SW2 makes it possible to establish comparison parameters to validate the correct execution of cryptographic functions of the first software SW1.
  • the first software SW1 is validated in a simulator which comprises the various elements of the branch 11.
  • a specification SPEC 1 makes it possible to describe the cryptographic functions of the first software SW1 integrating all the sub-functions necessary for the execution of each cryptographic function. Certain sub-functions have no influence on the state of the memory, others do not involve parameters or values of the inputs and outputs of the cryptographic component.
  • the second software SW2 is designed from a functional specification SPEC 2 simplified from the functional description SPEC 1 of software SW1.
  • the simplification of the SPEC 1 specification includes for example the elimination of the sub-functions of a cryptographic function which does not impact the state of the memory M1 or which does not interact with the inputs and outputs of the cryptographic component.
  • the second software SW2 is capable of reproducing the execution of the sub-functions of each cryptographic function having in particular an influence on the state of the memory M1 or on the inputs and outputs of the cryptographic component.
  • the second software SW2 therefore allows the execution of at least one function resulting in generating a state of the memory M2 STATUS and a result RESULTS_2 of a function equivalent to the function of the first software SW1.
  • An objective of the method of the invention is to compare the states of the memories M1 STATUS and M2 STATUS after the execution of the two functions in each of the environments of the branches 10 and 11 and to compare the results RESULT_1 and RESULT_2 of these two functions.
  • Branch 10 can be understood as a test bench or a test platform or even a test environment making it possible to validate the first software SW1. Once validated, the first software SW1 can then be put into production, which means: to be embedded in a cryptographic component.
  • the specification elements SPEC 1 and SPEC 2 respectively of branch 11 and 10 are not necessarily included in the branches insofar as the specifications of the software SW1 and SW2 can be data independent of the execution of the method of the invention. and can be used for the design of software SW1 and SW2 upstream of the execution of the method.
  • the representation of the elements designating the specifications SPEC 1 and SPEC 2 allows a better understanding of the invention insofar as it is understood that the second software SW2 is compiled independently of the first software SW1. This constitutes an advantage of the invention.
  • the second software SW2 is a simplified version of the first software SW1 makes it possible to save design time.
  • the validation means of branch 10 only deal with the sub-functions of a cryptographic function having an influence on the memory or on the inputs and outputs of the simulator and therefore of the cryptographic component.
  • the specification SPEC 1 makes it possible to design the cryptographic functions of the first software SW1, for example by means of code instructions in a given language.
  • a part of hardware instructions HW can be coded in VHDL
  • a part of software instructions SW, in particular the algorithmic part of the cryptographic functions can be coded in C language.
  • the method of the present invention allows the production and use of a second software SW2 designed in the same language as the first software SW1 or even in another language.
  • a second software SW2 designed in the same language as the first software SW1 or even in another language.
  • an advantage is a certain flexibility in the design of the test platform 10.
  • the use of a language less constrained than the language used to code the first software SW1 can be chosen.
  • libraries of basic functions can be used to reduce the design time of the second software SW2.
  • a simpler or more accessible language can be used so as to facilitate the handling of the second software SW2 or its development.
  • the second software SW2 can be designed by focusing on processing only the variables and parameters linked to the cryptographic functions which cannot be the case with the first software SW1 which is tested in the simulator and which is intended to operate. in the cryptographic component.
  • the operations performed by the second software SW2 are essentially operations only implementing the sub-functions of at least one cryptographic function having an influence on the memory M2 of the simulator or on the inputs and outputs of the simulator which are functionally identical to the inputs and outputs of the cryptographic component.
  • a cryptographic function can be an encryption function of a digital key.
  • an input data item of the second software SW2 can be defined by means of an interface by the definition of a value in clear, that is to say unencrypted, defining a digital key of a certain length.
  • the key is encrypted and saved in the memory M2 when the second software SW2 performs the cryptographic function.
  • saving a data item in the memory M2 is also meant the fact of generating a value of the state of the memory M2 depending on whether the memory M2 is a dedicated physical component or a simple file.
  • the state of the memory M2 is therefore modified after the execution of a cryptographic function, this state is denoted M2 STATUS in branch 10.
  • the method of the invention comprises an instruction conversion function, denoted T-CASE, for generating CDE_1 instructions.
  • CDE_1 instructions are generated from a simple CDE_2 command intended for the second software SW2.
  • An advantage of this conversion function is to generate an instruction CDE_1 conforming to the nomenclature of the instructions used in the cryptographic component and therefore of the branch 11 simulator. Therefore, this conversion function of a simple CDE_2 command into a set of instructions CDE_1 makes it possible to validate that the simple command CDE_2 is representative of the instructions making it possible to activate the tested cryptographic function of the test bench of branch 10 and of the input data necessary for the execution of at least one cryptographic function .
  • the figure 1 represents a simple CDE_2 command which can be expressed simply by means of a user interface.
  • the CDE_2 command activates the cryptographic function that you want to activate and makes it possible to define the input data for this function in the environment of the branch 11 simulator.
  • a command can include an instruction or a set of instructions.
  • the branch 11 representing the simulator and therefore the conforming behavior of the first software SW1 as it will be in the cryptographic component, comprises an input for activating the cryptographic functions of the first software SW1, denoted CDE_1.
  • the notation CDE_1 defines the command comprising the instructions to perform a cryptographic function and it also defines the physical interface. This physical interface as shown on the figure 1 can be present in the simulator and / or come from an interface with branch 10 via a T-CASE instruction conversion function.
  • the instructions of the CDE_1 command can be defined in a complex language and can integrate elements not necessary for the execution of a given cryptographic function in its environment. The latter case can for example occur when the same command makes it possible to execute several cryptographic functions simultaneously.
  • the method of the invention therefore makes it possible from the second software SW2 to generate a command CDE_1 in accordance with the execution of at least one cryptographic function of the first software SW1 in the environment of the simulator.
  • This CDE_1 command is therefore generated using an instruction conversion function which can be included in the second software SW2 or be integrated in a software and a dedicated component as shown in figure 1 by the T-CASE component.
  • the component physical T-CASE also represents the function of converting instructions in order to simplify the reading of the graph.
  • This component is capable of reading a CDE_2 command from the test bench and interpreting it so as to generate a CDE_1 command in accordance with the environment of the simulator.
  • the two branches 10 and 11 can be used simultaneously from a single CDE_2 input command so as to parallelize the cryptographic functions of the first SW1 and of the second software SW2 which correspond to each other.
  • the state of the M2 STATUS memory can be generated from a calculation and be saved in a file or it can be written into a physical M2 memory of the test bench.
  • the second software SW2 modifies the initial state M2 INIT into a new state M2 STATUS .
  • the design of the second software SW2 is advantageously coded from functional specifications identical to those of the first software SW1 while for example using another language or using another environment or from another person.
  • This differentiation of the means of production of the first SW1 and of the second software SW2 makes it possible to guarantee that the same error is not reproduced in the software SW1 and SW2. Thanks to this design differentiation of the two software SW1 and SW2, the tests of the cryptographic functions are independent of a design error which would be identical in the first software SW1 and in the second software SW2.
  • the step of generating the T-CASE instructions makes it possible to test that the input instructions are indeed read in accordance with what they will be in the cryptographic component.
  • the states of memories M1 STATUS and M2 STATUS can be compared at the end of the execution of the cryptographic function tested by means of a comparison function denoted COMP_A.
  • the results RESULT_1 and RESULT_2 of the functions executed respectively by the software SW1 and SW2 can be compared by a comparison function COMP_B.
  • An advantage of the invention is to provide a method making it possible to validate the correct execution of a cryptographic function while no access to the state of the memory is possible.
  • An advantage of the invention is to make it possible not only to verify that the results of the cryptographic functions executed respectively in the test bench 10 and in the simulator 11 correspond, but also to make it possible to verify the integrity of the state of the modified memory.
  • M1 STATUS by comparing it with the state of the M2 STATUS memory respectively of the simulator and of the test bench. This last operation of comparing the states of the memories of the test bench 10 and of the simulator 11 makes it possible to verify that the impacts of the execution of a cryptographic function of the first software SW1 on the state of the memory M1 is identical to the one. impact of the execution of a cryptographic function of the second software SW2 on the memory M2.
  • the method of the invention therefore makes it possible to ensure that the state of the memory does indeed comply with expectations by this operation of comparison of the states M1 STATUS and M2 STATUS .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Computer Security & Cryptography (AREA)
  • Debugging And Monitoring (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Description

    DOMAINE
  • Le domaine de l'invention concerne les procédés permettant de valider l'état d'une mémoire après l'exécution d'un programme exécutable lorsque ce programme manipule des données cryptées. La validation de la mémoire permet de juger de la bonne exécution d'un programme. Le domaine concerne donc celui des procédés permettant une vérification du bon fonctionnement d'un programme d'ordinateur, également appelé logiciel, avant sa mise en production dans un composant dédié.
    • ETAT DE L'ART
  • Actuellement, lorsqu'un programme est compilé et stocké dans une mémoire physique, il est possible de valider son contenu en comparant l'état de la mémoire avec une référence attendue. Cette opération permet une première validation avant d'autres validations du programme par exemple en testant certaines fonctions.
  • Certains outils tels que des débogueurs, « debugger » dans la terminologie anglo-saxonne, permettent de valider pas à pas un programme compilé sur une mémoire afin de tester l'ensemble des fonctions exécutables.
  • Or pour les programmes comportant des fonctions cryptographiques et/ou pilotant des composants traitant des données cryptographiques, l'accès aux données sauvegardées par de telles fonctions ou de tels composants est généralement protégé et il n'est pas possible de lire le contenu de la mémoire de sorte à vérifier la bonne exécution d'une fonction.
  • En outre, une opération visant à comparer l'état de la mémoire d'un programme avec un état de référence permet rapidement d'obtenir un statut de bon ou de mauvais fonctionnement d'une fonction ou d'un composant. Or, lorsque le composant est un composant cryptographique, l'accès à la mémoire est quasiment impossible compte tenu des mécanismes de protections naturellement mis en œuvre pour protéger l'accès et la copie des données chiffrées du composant.
  • Un composant cryptographique permet l'exécution de différentes fonctions au moyen d'un logiciel embarqué dans le composant cryptographique. Par exemple, une fonction permet de traiter des données non chiffrées afin de les chiffrer. Dans ce cadre, sans accès à la mémoire du composant cryptographique, les tests consistants à valider le bon fonctionnement d'un tel composant cryptographique sont difficiles à mettre en œuvre. Les principales opérations réalisées par les fonctions cryptographiques ne peuvent être validées simplement lors d'opérations de débogage.
  • En conséquence, la mémoire d'un tel composant étant protégée, l'accès aux données sauvegardées dans une mémoire chiffrée nécessite de tester le composant lorsque ce dernier est dans une configuration opérationnelle. Ces opérations entrainent des coûts supplémentaires et peuvent être longues.
  • Dans ce cadre, les opérations simples de comparaison de l'état de la mémoire sont difficiles à mettre en oeuvre lorsque le composant est un composant cryptographique.
  • Il n'existe pas de moyen de vérifier sur un composant cryptographique que le contenu qui a été inscrit sur la mémoire non volatile est bien conforme aux attentes.
  • Compte tenu du fait qu'il est quasiment impossible de « photographier » la mémoire d'un composant cryptographique pour permettre la réalisation d'opération de débogage, une limitation aux procédés de programmation, de test et de validation de l'exécution du programme apparait aujourd'hui dans les solutions techniques proposées.
  • Le document D1 (DI NATALE G ET AL: "A Reliable Architecture for the Advanced Encryption Standard") est considéré comme l'état de la technique le plus proche de l'objet de l'invention car il appartient au même domaine technique des fonctions cryptographiques. Le document D1 concerne la détection de défaillances matérielles lors de l'exécution d'un algorithme de chiffrement de type AES, l'algorithme étant exécuté en parallèle sur plusieurs blocs identiques (« RSMA blocks »). Pour ce faire, à chaque cycle d'horloge, la sortie de deux des blocs ayant reçus les mêmes entrées sont comparées pour détecter d'éventuelles défaillances . Les défaillances peuvent donc être détectées seulement lorsque la sortie du bloc concerné est comparée à celle d'un autre bloc. En conséquence, il est possible que des erreurs surviennent sans qu'elles soient détectées.
    • RESUME DE L'INVENTION
  • L'invention vise à pallier aux inconvénients précités.
  • L'invention est définie par un procédé de validation du fonctionnement d'un premier logiciel (SW1) destiné à être embarqué dans un composant cryptographique selon la revendication 1 et par un système de tests d'un logiciel exécutant un ensemble de fonctions cryptographique d'un logiciel destiné à être intégré dans un composant cryptographique selon la revendication 12. Des modes de réalisation avantageux sont décrits dans les revendications dépendantes.
  • Le système de l'invention permet de mettre en œuvre toutes les étapes du procédé de l'invention ainsi que tous les modes de réalisation.
    • BREVE DESCRIPTION DES FIGURES
  • D'autres caractéristiques et avantages de l'invention ressortiront à la lecture de la description détaillée qui suit, en référence aux figures annexées, qui illustrent :
    • ▪ figure 1 : un schéma fonctionnel des principales étapes du procédé de l'invention.
    DESCRIPTION
  • Dans la présente invention on entend par « composant cryptographique », un composant comprenant une mémoire, des entrées et des sorties, un processeur tel qu'un microprocesseur et réalisant des fonctions cryptographiques. La mémoire comprend une mémoire volatile telle qu'une RAM et une mémoire non volatile telle qu'une mémoire Flash. La mémoire volatile efface ses données sauvegardées à chaque reboot de la mémoire volatile. La mémoire non volatile sauvegarde les données stockées lors des différentes opérations exécutées par les fonctions cryptographiques.
  • Parmi les fonctions cryptographiques assurées par un composant cryptographique, on trouve par exemple :
    • ▪ une fonction d'authentification ;
    • ▪ une fonction de chiffrement ou de déchiffrement ;
    • ▪ une fonction de signature ou de vérification d'une signature ;
    • ▪ une fonction de calcul d'empreintes ;
    • ▪ une fonction de stockage de données ;
    • ▪ une fonction de calcul de code d'authentification de message, par exemple de message MAC.
  • Cette liste est non exhaustive et est citée à titre d'exemple.
  • Le procédé de l'invention s'applique à tout composant cryptographique qui impose de préserver l'état de la mémoire, c'est-à-dire son contenu, vis-à-vis d'un tiers. Généralement, la mémoire d'un composant cryptographique n'est pas accessible. Lorsqu'elle est accessible, les données sont chiffrées et ne peuvent pas être récupérées « en clair » par un tiers. Le procédé de l'invention permet lors de phases de tests et de validation du logiciel d'un composant cryptographique de vérifier le bon fonctionnement du logiciel malgré la non accessibilité de l'état de la mémoire modifiée par l'exécution d'une fonction cryptographique.
  • Chaque fonction cryptographique peut être représentée par un ensemble d'instructions permettant, à partir de données d'entrées, de générer des données de sorties comme par exemple une clef chiffrée. Certaines instructions mettent en oeuvre les entrées et les sorties du composant et/ou la mémoire de sorte que l'état de la mémoire ou du composant est modifiée par l'exécution de ces instructions. D'autres instructions ne modifient pas l'état de la mémoire ou certaines entrées ou sorties du composant cryptographique.
  • Un simulateur au sens de la présente invention d'un composant cryptographique est réalisé pour tester les principales fonctions cryptographiques ayant un impact sur l'état de la mémoire du composant ou ses entrées et sorties. Un avantage de l'utilisation d'un simulateur 11 est de pouvoir lire l'état de la mémoire M1 et de le comparer avec un état d'une mémoire M2 d'un banc de test 10 reproduisant les modifications de l'état de la mémoire. Le simulateur 11 permet de définir les accès à la mémoire M1 et d'extraire son contenu pour effectuer des opérations de comparaison.
  • Un premier logiciel SW1 est destiné à être embarqué sur le composant cryptographique. Le premier logiciel SW1 permet de réaliser un ensemble de fonctions cryptographiques. Le premier logiciel SW1 pour être testé est embarqué dans un simulateur.
  • Selon un mode de réalisation de l'invention, lorsque le premier logiciel SW1 est testé et validé, il est alors ensuite embarqué sur un composant cryptographique qui est intégré dans un dispositif de communication tel qu'un mobile.
  • Les entrées et sorties du composant cryptographique sont reproduites dans le simulateur permettant de tester et valider le logiciel SW1.
  • Un second logiciel SW2 est conçu pour reproduire des fonctions simplifiées du premier logiciel SW1. Ainsi le second logiciel SW2 reproduit les principales fonctions cryptographiques du premier logiciel SW1 tout en ne reproduisant pas certains traitements non nécessaires à la validation des fonctions cryptographiques. En effet, le premier logiciel SW1 comporte des instructions n'ayant aucun impact sur l'état de la mémoire ou sur les entrées et sorties.
  • Le problème que se propose de résoudre l'invention et de définir un protocole de tests, et donc un procédé, permettant de vérifier le bon fonctionnement du premier logiciel SW1 du composant à partir notamment du second logiciel SW2. Les vérifications peuvent être effectuées aux moyens de comparaisons des états des mémoires associées à chacun des logiciels. Le procédé de l'invention permet donc de disposer d'un outil de test simple tout en assurant que les résultats des tests sont représentatifs du fonctionnement opérationnel du premier logiciel SW1 dans le composant cryptographique.
  • La figure 1 représente un schéma fonctionnel du procédé de l'invention.
  • Une première branche 10 représente les différents éléments pour la mise en oeuvre le procédé de l'invention pour valider le premier logiciel SW1 qui est destiné à être embarqué dans un composant cryptographique. A cet effet, la branche 10 comprend un second logiciel SW2 conçu pour :
    • générer un état de la mémoire M2STATUS après l'exécution d'une fonction cryptographique du premier logiciel SW1 ;
    • générer au moins un résultat RESULT_2 d'une fonction cryptographique du second logiciel SW2 ;
    • générer des commandes d'entrée T_CASE conformes à l'environnement du simulateur de la branche 11 pour l'exécution d'une fonction du premier logiciel SW1 correspondante à une fonction du second logiciel SW2.
  • Le second logiciel SW2 permet d'établir des paramètres de comparaison pour valider la bonne exécution de fonctions cryptographiques du premier logiciel SW1.
  • Le premier logiciel SW1 est validé dans un simulateur qui comprend les différents éléments de la branche 11. Une spécification SPEC 1 permet de décrire les fonctions cryptographiques du premier logiciel SW1 intégrant toutes les sous-fonctions nécessaires à l'exécution de chaque fonction cryptographique. Certaines sous-fonctions n'ont aucune influence sur l'état de la mémoire, d'autres ne font pas intervenir des paramètres ou valeurs des entrées et des sorties du composant cryptographiques.
  • Dans la présente description on parle indifféremment de sous fonctions d'une fonction cryptographique ou d'opérations d'une fonction cryptographique.
  • Le second logiciel SW2 est conçu à partir d'une spécification fonctionnelle SPEC 2 simplifiée de la description fonctionnelle SPEC 1 du logiciel SW1. La simplification de la spécification SPEC 1 comprend par exemple la suppression des sous-fonctions d'une fonction cryptographique n'impactant pas l'état de la mémoire M1 ou n'interagissant pas avec les entrées et sorties du composant cryptographique.
  • Le second logiciel SW2 est capable de reproduire l'exécution des sous fonctions de chaque fonction cryptographique ayant notamment une influence sur l'état de la mémoire M1 ou sur les entrées et sorties du composant cryptographique. Le second logiciel SW2 permet donc l'exécution d'au moins une fonction aboutissant à générer un état de la mémoire M2STATUS et un résultat RESULTS_2 d'une fonction équivalente à la fonction du premier logiciel SW1. Un objectif du procédé de l'invention est de comparer les états des mémoires M1STATUS et M2STATUS après l'exécution des deux fonctions dans chacun des environnements des branches 10 et 11 et de comparer les résultats RESULT_1 et RESULT_2 de ces deux fonctions.
  • La branche 10 peut être entendue comme un banc de tests ou une plateforme de tests ou encore un environnement de tests permettant de valider le premier logiciel SW1. Une fois validé, le premier logiciel SW1 peut alors être mis en production, ce qui signifie : être embarqué dans un composant cryptographique.
  • Les éléments de spécification SPEC 1 et SPEC 2 respectivement de la branche 11 et 10 ne sont pas nécessairement inclus dans les branches dans la mesure où les spécifications des logiciels SW1 et SW2 peuvent être des données indépendantes de l'exécution du procédé de l'invention et peuvent être utilisées pour la conception des logiciel SW1 et SW2 en amont de l'exécution du procédé.
  • La représentation des éléments désignant les spécifications SPEC 1 et SPEC 2 permet une meilleure compréhension de l'invention dans la mesure où on comprend que le second logiciel SW2 est compilé de manière indépendante du premier logiciel SW1. Cela constitue un avantage de l'invention. En outre, le second logiciel SW2 est une version simplifiée du premier logiciel SW1 permet de gagner un temps de conception. Les moyens de validation de la branche 10 ne traitent que des sous-fonctions d'une fonction cryptographique ayant une influence sur la mémoire ou sur les entrées et les sorties du simulateur et donc du composant cryptographique.
  • La spécification SPEC 1 permet de concevoir les fonctions cryptographiques du premier logiciel SW1 par exemple aux moyens d'instructions de code dans un langage donné. Selon un mode de réalisation, une partie d'instructions matérielles HW peut être codée en VHDL, une partie d'instructions logicielles SW, notamment la partie algorithmique des fonctions cryptographiques, peut être codée en langage C.
  • Le procédé de la présente invention permet la réalisation et l'exploitation d'un second logiciel SW2 conçu dans un même langage que le premier logiciel SW1 ou encore dans un autre langage. Lorsque ce dernier est conçu dans un autre langage, un avantage est une certaine souplesse de conception de la plateforme de test 10. Par exemple, l'utilisation d'un langage moins contraint que le langage utilisé pour coder le premier logiciel SW1 peut être choisi. A titre d'exemples, des librairies de fonctions de base peuvent être utilisées pour réduire le temps de conception du second logiciel SW2. En outre, un langage plus simple ou plus accessible peut être utilisé de sorte à faciliter la prise en main du second logiciel SW2 ou son développement.
  • Notamment, il peut être programmé dans un environnement de développement moins contraint. En outre, il peut s'affranchir de paramètres de conception du composant cryptographique qui imposent une optimisation du code générée. Enfin, le second logiciel SW2 peut être conçu en s'attachant à ne traiter que les variables et les paramètres liés aux fonctions cryptographiques ce qui ne peut pas être le cas du premier logiciel SW1 qui est testé dans le simulateur et qui est destiné à fonctionner dans le composant cryptographique.
  • Une mémoire M1 est représentée dans la branche 11 selon deux configurations :
    • M1INIT représente l'état de la mémoire M1 du simulateur avant toute exécution d'opérations, c'est-à-dire à l'initialisation du procédé ;
    • M1STATUS représente l'état de la mémoire M1 du simulateur après qu'une ou plusieurs opérations aient été effectuées, par exemple, par l'exécution d'au moins une fonction cryptographique.
  • La branche 10 représente une mémoire M2 ou une représentation de la mémoire M2. La mémoire M2 ou sa représentation est représentée selon deux configurations :
    • M2INIT représente l'état de la mémoire du banc de tests ou la valeur théorique générée à l'initialisation du procédé de l'invention ;
    • M2STATUS représente l'état de la mémoire du banc de tests ou la valeur générée par le second logiciel SW2 après qu'une ou plusieurs opérations aient été effectuées, par exemple, par l'exécution d'une fonction cryptographique par le second logiciel SW2 correspondante à la fonction exécutée dans le premier logiciel SW1.
  • Les opérations réalisées par le second logiciel SW2 sont essentiellement des opérations ne mettant qu'en oeuvre les sous fonctions d'au moins une fonction cryptographique ayant une influence sur la mémoire M2 du simulateur ou sur les entrées et sorties du simulateur qui sont identiques fonctionnellement aux entrées et sorties du composant cryptographique.
  • A titre d'exemple, une fonction cryptographique peut être une fonction de chiffrement d'une clef numérique. Dans ce cas, une donnée d'entrée du second logiciel SW2 peut être définie au moyen d'une interface par la définition d'une valeur en clair, c'est-à-dire non chiffrée, définissant une clef numérique d'une certaine longueur.
  • Le second logiciel SW2 est capable de :
    • calculer la valeur chiffrée de la clef ;
    • générer les données correspondant à l'état de la mémoire M2 qui peuvent correspondre à la valeur chiffrée seule ou à la valeur chiffrée seule avec d'autres données à stocker dans la mémoire, comme par exemple un identifiant ;
    • retourner le résultat RESULT_2 de la fonction exécutée qui peut être par exemple un acquittement indiquant que le chiffrement est réussi. En outre, ce dernier résultat peut comporter une copie de la clef chiffrée par exemple, c'est-à-dire le résultat de la fonction appelée
  • La clef est chiffrée et sauvegardée dans la mémoire M2 lorsque le second logiciel SW2 exécute la fonction cryptographique. On entend également par sauvegarde d'une donnée dans la mémoire M2, le fait de générer une valeur de l'état de la mémoire M2 selon que la mémoire M2 est un composant physique dédié ou un simple fichier. L'état de la mémoire M2 est donc modifié après l'exécution d'une fonction cryptographique, cet état est noté M2STATUS dans la branche 10.
  • De manière optionnelle, le procédé de l'invention comprend une fonction de conversion d'instructions, notée T-CASE, pour générer des instructions CDE_1. Les instructions CDE_1 sont générées à partir d'une commande simple CDE_2 destinée au second logiciel SW2. Un avantage de cette fonction de conversion est de générer une instruction conforme CDE_1 à la nomenclature des instructions utilisées dans le composant cryptographique et donc du simulateur de la branche 11. De ce fait, cette fonction de conversion d'une commande simple CDE_2 en un ensemble d'instructions CDE_1 permet de valider que la commande simple CDE_2 est représentative des instructions permettant d'activer la fonction cryptographique testée du banc de test de la branche 10 et des données d'entrées nécessaires à l'exécution d'au moins une fonction cryptographique.
  • La figure 1 représente une commande simple CDE_2 qui peut être exprimé simplement au moyen d'une interface utilisateur. La commande CDE_2 permet d'activer la fonction cryptographique que l'on souhaite activer et permet de définir les données d'entrées de cette fonction dans l'environnement du simulateur de la branche 11.
  • Une commande peut comprendre une instruction ou un ensemble d'instructions.
  • Par ailleurs, la branche 11, représentant le simulateur et donc le comportement conforme du premier logiciel SW1 tel qu'il sera dans le composant cryptographique, comprend une entrée pour activer les fonctions cryptographiques du premier logiciel SW1, notée CDE_1. La notation CDE_1 définit la commande comportant les instructions pour exécuter une fonction cryptographique et elle définit également l'interface physique. Cette interface physique comme cela est représentée sur la figure 1 peut être présente dans le simulateur et/ou provenir d'une interface avec la branche 10 par l'intermédiaire d'une fonction de conversion d'instructions T-CASE.
  • Les instructions de la commande CDE_1 peuvent être définies dans un langage complexe et peuvent intégrer des éléments non nécessaires à l'exécution d'une fonction cryptographique donnée dans son environnement. Ce dernier cas peut par exemple se produire lorsqu'une même commande permet d'exécuter plusieurs fonctions cryptographiques simultanément.
  • Le procédé de l'invention permet donc à partir du second logiciel SW2 de générer une commande CDE_1 conforme à l'exécution d'au moins une fonction cryptographique du premier logiciel SW1 dans l'environnement du simulateur. Cette commande CDE_1 est donc générée à l'aide d'une fonction de conversion d'instructions qui peut être incluse dans le second logiciel SW2 ou être intégrée dans un logiciel et un composant dédié comme cela est représenté à la figure 1 par le composant T-CASE. Le composant physique T-CASE représente également la fonction de conversion d'instructions de manière à simplifier la lecture du graphique.
  • Ce composant est capable de lire une commande CDE_2 du banc de test et de l'interpréter de manière à générer une commande CDE_1 conforme à l'environnement du simulateur. Ainsi les deux branches 10 et 11 peuvent être employées simultanément à partir d'une seule commande d'entrée CDE_2 de manière à paralléliser les fonctions cryptographiques du premier SW1 et du second SW2 logiciels qui se correspondent.
  • L'état de la mémoire M2STATUS peut être générée à partir d'un calcul et être sauvegardé dans un fichier ou il peut être inscrit dans une mémoire M2 physique du banc de test. Suite à l'exécution d'une fonction cryptographique, le second logiciel SW2 modifie l'état initial M2INIT en un nouvel état M2STATUS.
  • La conception du second logiciel SW2 est avantageusement codé à partir de spécifications fonctionnelles identiques à celles du premier logiciel SW1 tout en utilisant par exemple un autre langage ou utilisant un autre environnement ou à partir d'une autre personne. Cette différenciation des moyens de production du premier SW1 et du second SW2 logiciels permet de garantir qu'une même erreur ne soit pas reproduite dans les logiciels SW1 et SW2. Grâce à cette différentiation de conception des deux logiciels SW1 et SW2, les tests des fonctions cryptographiques sont indépendants d'une erreur de conception qui serait identique dans le premier logiciel SW1 et dans le second logiciel SW2.
  • Par ailleurs, l'étape de génération des instructions T-CASE permet de tester que les instructions d'entrées sont bien lues conformément à ce qu'elles seront dans le composant cryptographique.
  • De manière à valider une fonction cryptographique du premier logiciel SW1, les états des mémoires M1STATUS et M2STATUS peuvent être comparés à l'issue de l'exécution de la fonction cryptographique testée au moyen d'une fonction de comparaison notée COMP_A. En outre, les résultats RESULT_1 et RESULT_2 des fonctions exécutées respectivement par les logiciels SW1 et SW2 peuvent être comparés par une fonction de comparaison COMP_B.
  • Lorsque les comparaisons concordent, une fonction cryptographique du premier logiciel SW1 peut être validée.
  • Un avantage de l'invention est de fournir un procédé permettant de valider la bonne exécution d'une fonction cryptographique alors qu'aucun accès à l'état de la mémoire n'est possible.
  • Un avantage de l'invention est de permettre non seulement de vérifier que les résultats des fonctions cryptographiques exécutées respectivement dans le banc de test 10 et dans le simulateur 11 correspondent mais également de permettre de vérifier l'intégrité de l'état de la mémoire modifié M1STATUS en la comparant avec l'état de la mémoire M2STATUS respectivement du simulateur et du banc de test. Cette dernière opération de comparaison des états des mémoires du banc de test 10 et du simulateur 11 permet de vérifier que les impacts de l'exécution d'une fonction cryptographique du premier logiciel SW1 sur l'état de la mémoire M1 est identique à l'impact de l'exécution d'une fonction cryptographique du second logiciel SW2 sur la mémoire M2.
  • En effet, lorsqu'une fonction cryptographique du premier logiciel SW1 est exécutée, elle peut impactée des données connexes de la mémoire M1 non directement générées par la fonction cryptographique. Le procédé de l'invention permet donc s'assurer que l'état de la mémoire est bien conforme aux attentes par cette opération de comparaison des états M1STATUS et M2STATUS.

Claims (12)

  1. Procédé de validation du fonctionnement d'un premier logiciel (SW1) destiné à être embarqué dans un composant cryptographique, comprenant :
    ▪ Une première étape réalisée dans un simulateur (11) et comportant une première exécution d'au moins une première fonction cryptographique à partir d'une première commande d'instructions (CDE_1) par le premier logiciel (SW1) mis en oeuvre par un premier processeur et au moyen d'une première mémoire (M1), ladite première exécution de ladite au moins une première fonction cryptographique générant :
    ∘ un premier état (M1STATUS) de la première mémoire (M1), ledit premier état comportant l'ensemble des données présentes dans la première mémoire après l'exécution d'une commande d'instructions (CDE_1) ;
    ∘ un premier résultat (RESULT_1) de la première commande (CDE_1), le premier résultat comprenant la valeur retournée par au moins un calcul de la première fonction cryptographique,
    ▪ une seconde étape réalisée dans un banc de tests (10) et comportant une seconde exécution d'au moins une seconde fonction cryptographique à partir d'une seconde commande d'instructions (CDE_2) par un second logiciel (SW2) mis en oeuvre par un second processeur et au moyen d'une seconde mémoire (M2), la première et la seconde fonctions réalisant des mêmes opérations modifiant l'état de leur mémoire respective (M1, M2), ladite seconde exécution de ladite au moins une seconde fonction cryptographique générant :
    ∘ un second état (M2STATUS) de la seconde mémoire (M2), ledit second état comportant l'ensemble des données présentes dans la seconde mémoire après l'exécution d'une commande d'instructions (CDE_1) ;
    ∘ un second résultat (RESULT _2) de la seconde commande (CDE_2), le second résultat (RESULT_2) comprenant la valeur retournée par au moins un calcul de la seconde fonction cryptographique,
    ▪ Une étape de validation comparant (COMP_A, COMP_B) à partir d'un calculateur:
    ∘ le premier état (M1STATUS) de la première mémoire (M1) avec le second état (M2STATUS) de la seconde mémoire (M2) ;
    ∘ le premier résultat (RESULT_1) avec le second résultat (RESULT_2) ;
    le fonctionnement du premier logiciel étant validé si le premier état (M1STATUS) de la première mémoire (M1) et le premier résultat (RESULT_1) sont identiques respectivement au second état (M2STATUS) de la seconde mémoire (M2) et au deuxième résultat (RESULT_2).
  2. Procédé de validation selon la revendication 1, caractérisé en ce qu'une fonction de conversion d'instructions (T-CASE) de la première commande d'instructions (CDE_1) génère la seconde commande d'instructions (CDE_2) pour l'exécution d'une fonction cryptographique du premier logiciel (SW1).
  3. Procédé de validation selon la revendication 2, caractérisé en ce que la fonction de conversion d'instructions (T-CASE) est réalisée par le second logiciel (SW2) au moyen du second processeur.
  4. Procédé de validation selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'ensemble de fonctions cryptographiques réalisées par le premier ou le second logiciel (SW1, SW2) comprend au moins l'une des fonctions suivante :
    ▪ Une fonction d'authentification ;
    ▪ Une fonction de chiffrement ou de déchiffrement ;
    ▪ Une fonction de signature ou de vérification d'une signature ;
    ▪ Une fonction de calcul d'empreintes;
    ▪ Une fonction de stockage de données ;
    ▪ Une fonction de calcul de code d'authentification de message.
  5. Procédé de validation selon l'une quelconque des revendications précédentes, caractérisé en ce que l'état d'une mémoire (M1 STATUS, M2STATUS) comprend, en outre, l'ensemble des données présentes dans la mémoire après l'exécution d'une commande d'instructions (CDE_1, CDE_2).
  6. Procédé de validation selon l'une quelconque des revendications précédentes, caractérisé en ce que le résultat (RESULT_1, RESULT_2) d'une fonction cryptographique exécutée au moyen d'une commande (CDE_1, CDE_2) comprend la valeur retournée par au moins un calcul d'une fonction cryptographique.
  7. Procédé de validation selon l'une quelconque des revendications précédentes, caractérisé en ce que le résultat (RESULT_1, RESULT_2) d'une commande comprend au moins l'une des données de la liste suivante :
    ▪ Un acquittement indiquant le succès ou l'échec de l'exécution d'une fonction cryptographique ;
    ▪ Un acquittement d'une fonction d'authentification ;
    ▪ Un résultat d'une fonction de chiffrement ou de déchiffrement ;
    ▪ Une signature numérique ;
    ▪ Un résultat d'une vérification de signature numérique;
    ▪ Une empreinte ;
    ▪ Un résultat d'une vérification d'empreinte;
    ▪ Un code d'authentification de message (MAC);
    ▪ Un résultat d'une vérification de code d'authentification de message (MAC).
  8. Procédé de validation selon l'une quelconque des revendications précédentes, caractérisé en ce que chaque fonction cryptographique du premier logiciel (SW1) et du second logiciel (SW2) comprend des opérations visant à réaliser des calculs sur au moins une valeur comprise dans des instructions de commande d'entrée (CDE_1, CDE_2) et à sauvegarder cette valeur dans une mémoire (M1, M2) associée au logiciel (SW1, SW2).
  9. Procédé de validation selon l'une quelconque des revendications précédentes, caractérisé en ce que chaque fonction cryptographique du premier logiciel (SW1) comprend :
    ▪ un premier ensemble d'opérations ayant une première influence sur l'état de la mémoire (M1), la première influence étant liée à une modification de l'état de la mémoire ;
    ▪ un second ensemble d'opérations ayant une seconde influence sur au moins une entrée et/ou une sortie d'une interface du premier logiciel (SW1), la seconde influence étant liée à la lecture ou la modification de données transitant sur lesdites interfaces ;
    ▪ un troisième ensemble d'opérations n'ayant pas d'influence ni sur la mémoire (M1) ni sur une entrée ou une sortie.
  10. Procédé de validation selon la revendication 9, caractérisé en ce que chaque fonction cryptographique du second logiciel (SW2) comprend le premier et le second ensemble d'opérations.
  11. Procédé de validation selon la revendication 9 ou 10, caractérisé en ce que chaque fonction cryptographique du second logiciel (SW2) ne comprend pas le troisième ensemble d'opérations.
  12. Système de tests d'un logiciel exécutant un ensemble de fonctions cryptographiques d'un logiciel destiné à être intégré dans un composant cryptographique, comprenant
    ▪ un simulateur (11) comprenant un premier processeur pour l'exécution d'une première fonction cryptographique, une première mémoire enregistrant un nouvel état après l'exécution de la première fonction cryptographique, des premières interfaces pour lire une commande d'exécution (CDE_1) de la première fonction cryptographique et pour retourner une valeur du résultat (RESULT_1 ) de l'exécution de ladite fonction ;
    ▪ un banc de test (10) comprenant un second processeur pour l'exécution d'une seconde fonction cryptographique comprenant des opérations réalisées par la première fonction cryptographique exécutée dans le simulateur, la première fonction cryptographique correspondant ainsi à la première fonction cryptographique exécutée dans l'environnement du banc de test (10), une seconde mémoire (M2) enregistrant un nouvel état après l'exécution de la seconde fonction cryptographique, des secondes interfaces pour lire une commande d'exécution (CDE_2) et pour retourner une valeur du résultat (RESULT _2) de l'exécution de la seconde fonction ;
    ▪ un calculateur permettant de comparer les états des deux mémoires (M1STATUS, M2STATUS) à la fin de l'exécution de la première et de la seconde fonction et permettant de comparer les valeurs des résultats (RESULT_1, RESULT_2) de chaque fonction.
EP16204849.0A 2015-12-18 2016-12-16 Procede de verification de fonctionnalites d'un logiciel destine a etre embarque dans un composant cryptographique, systeme Active EP3182286B1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1562841A FR3045881B1 (fr) 2015-12-18 2015-12-18 Procede de verification de fonctionnalites d'un logiciel destine a etre embarque dans un composant cryptographique, systeme

Publications (2)

Publication Number Publication Date
EP3182286A1 EP3182286A1 (fr) 2017-06-21
EP3182286B1 true EP3182286B1 (fr) 2020-08-12

Family

ID=55948886

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16204849.0A Active EP3182286B1 (fr) 2015-12-18 2016-12-16 Procede de verification de fonctionnalites d'un logiciel destine a etre embarque dans un composant cryptographique, systeme

Country Status (4)

Country Link
US (1) US10216623B2 (fr)
EP (1) EP3182286B1 (fr)
ES (1) ES2819273T3 (fr)
FR (1) FR3045881B1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3045881B1 (fr) * 2015-12-18 2018-12-07 Airbus Slc Sas Procede de verification de fonctionnalites d'un logiciel destine a etre embarque dans un composant cryptographique, systeme
US11562073B2 (en) 2018-11-28 2023-01-24 The Boeing Company Systems and methods of software load verification
CN111008154B (zh) * 2019-12-31 2021-09-28 南京大学 一种基于强化学习的Android应用自动测试方法及系统
CN115080952A (zh) * 2022-06-16 2022-09-20 国网新疆电力有限公司信息通信公司 一种基于aep内存的密码验证测试方法及系统

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4481627A (en) * 1981-10-30 1984-11-06 Honeywell Information Systems Inc. Embedded memory testing method and apparatus
US6697982B2 (en) * 2001-05-04 2004-02-24 Texas Instruments Incorporated Generating netlist test vectors by stripping references to a pseudo input
US7962766B2 (en) * 2005-07-14 2011-06-14 Atmel Corporation Method and system for encryption-based design obfuscation for an integrated circuit
CN101896888A (zh) * 2008-02-26 2010-11-24 三菱电机株式会社 嵌入式系统中的自动再现测试装置及自动再现测试方法
JP2013061843A (ja) * 2011-09-14 2013-04-04 Fujifilm Corp コンピュータ・ソフトウエア解析システムならびにクライアント・コンピュータ，その動作制御方法およびその動作プログラム
US10114958B2 (en) * 2015-06-16 2018-10-30 Microsoft Technology Licensing, Llc Protected regions
FR3045881B1 (fr) * 2015-12-18 2018-12-07 Airbus Slc Sas Procede de verification de fonctionnalites d'un logiciel destine a etre embarque dans un composant cryptographique, systeme

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
FR3045881A1 (fr) 2017-06-23
FR3045881B1 (fr) 2018-12-07
US10216623B2 (en) 2019-02-26
US20170177467A1 (en) 2017-06-22
ES2819273T3 (es) 2021-04-15
EP3182286A1 (fr) 2017-06-21

Similar Documents

Publication Publication Date Title
FR2921170A1 (fr) Procede de generation automatique de programmes de test d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef, et dispositif de mise en oeuvre
EP1161725B1 (fr) Procede de surveillance du deroulement d'un programme
EP1702268A2 (fr) Procede de controle d integrite d execution de programm es par verification d empreintes de traces d execution
EP3182286A1 (fr) Procede de verification de fonctionnalites d'un logiciel destine a etre embarque dans un composant cryptographique, systeme
EP2453356B1 (fr) Procédé, programme d'ordinateur et dispositif de sécurisation de code intermédiaire de programmation pour son exécution par une machine virtuelle
EP3033857B1 (fr) Authentification de code binaire
JP5718373B2 (ja) 不揮発性メモリのメモリブロックを検査する方法
WO2015073469A1 (fr) Validation fonctionnelle d'un logiciel
US11989113B2 (en) Efficiently debugging a program in homomorphically encrypted space
FR3072195B1 (fr) Procede de gestion d'un retour de produit pour analyse et produit correspondant
CN112948819B (zh) 应用文件脱壳方法和装置、计算机可读存储介质
EP2797018B1 (fr) Procede et systeme de simulation des effets d'une attaque sur un code informatique
EP4328771A1 (fr) Procédé d'exécution d'un code machine par un calculateur
EP2229648B1 (fr) Methode de transfert securise de donnees
EP1295206B1 (fr) Dispositif et procede d'evaluation d'algorithmes
EP4131041B1 (fr) Procédé de vérification d'une exécution d'un programme logiciel
WO2018122990A1 (fr) Dispositif de traitement d'informations, procédé de traitement d'informations et programme de traitement d'informations
FR3137988A1 (fr) Procédé et circuit pour la vérification de l’intégrité d’un logiciel
WO2016181062A1 (fr) Procede de securisation d'une comparaison de donnees lors de l'execution d'un programme
EP1775595A1 (fr) Simulateur de test de circuits intégrés
EP3032451A1 (fr) Procede d'execution d'un programme par un processeur et entite electronique comportant un tel processeur
FR3035984A1 (fr) Procede de detection d'un logiciel malveillant
FR3006471A1 (fr) Systeme et procede d'execution d'applications d'une carte a puce
CN110334505A (zh) 清除电子设备的密码方法、装置及电子设备
WO2007099164A1 (fr) Procede de securisation de l'execution d'une suite d'etapes logiquement enchainees

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20171221

RBV Designated contracting states (corrected)

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20200507

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: FRENCH

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602016041770

Country of ref document: DE

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1302229

Country of ref document: AT

Kind code of ref document: T

Effective date: 20200915

REG Reference to a national code

Ref country code: FI

Ref legal event code: FGE

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20200812

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201112

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201112

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201113

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1302229

Country of ref document: AT

Kind code of ref document: T

Effective date: 20200812

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20201212

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2819273

Country of ref document: ES

Kind code of ref document: T3

Effective date: 20210415

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602016041770

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

26N No opposition filed

Effective date: 20210514

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20201231

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20201216

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20201216

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20201231

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20201231

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200812

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20201231

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20241122

Year of fee payment: 9

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20251126

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FI

Payment date: 20251119

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20251120

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: ES

Payment date: 20260102

Year of fee payment: 10