EP2318976A1 - Procede et systeme permettant de securiser un logiciel - Google Patents

Procede et systeme permettant de securiser un logiciel

Info

Publication number
EP2318976A1
EP2318976A1 EP09802522A EP09802522A EP2318976A1 EP 2318976 A1 EP2318976 A1 EP 2318976A1 EP 09802522 A EP09802522 A EP 09802522A EP 09802522 A EP09802522 A EP 09802522A EP 2318976 A1 EP2318976 A1 EP 2318976A1
Authority
EP
European Patent Office
Prior art keywords
module
software
tasks
event
scripts
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.)
Withdrawn
Application number
EP09802522A
Other languages
German (de)
English (en)
Inventor
Eric Grall
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.)
Thales SA
Original Assignee
Thales SA
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 Thales SA filed Critical Thales SA
Publication of EP2318976A1 publication Critical patent/EP2318976A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • 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/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/14—Protecting executable software against software analysis or reverse engineering, e.g. by obfuscation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5017—Task decomposition
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/509—Offload

Definitions

  • the invention relates to a method and a system architecture for securing software, for example an executable.
  • secure or secure means in this description the fact of making inaccessible software to anyone who is not allowed to know its contents.
  • Script is used, either to designate a text file comprising a series of commands that make it possible to automatically execute and chain most of the functions that are usually accessible, ie a binary file corresponding to executable code in a given environment.
  • Scripts therefore offer the possibility of linking, without user intervention, including events, etc. It will also be an encrypted script corresponding to a script on which an encryption algorithm has been applied so that only authorized resources or people can access the information contained in the software.
  • the object of the present invention is based on a new approach to ensure the protection of copyrights related to the software, while overcoming the disadvantages existing in the prior art.
  • the object of the present invention implements encapsulation of script or message and transmission of encapsulated scripts to a trusted resource adapted to execute them.
  • the scripts may or may not be encrypted, in which case the trusted resource decrypts them before execution.
  • the invention applies in particular to software that can be in the form of state machines.
  • the word “encapsulation” refers to the fact of using another protocol to transport some or all of the scripts in a medium adapted to this transport protocol.
  • the scripts will be formatted in messages that will themselves be encapsulated in IP-type communication protocols, etc.
  • the object of the invention relates to a method for securing software that can be broken down into several independent tasks of the "Action-Event” type, said tasks managing a set of encrypted or unencrypted "scripts” characterized in that it comprises at least the following steps: • Decompose the software to be secured into several independent Ti tasks, • On the arrival of a start event Ev d goal, select at least one of the tasks Ti composed of a set of scripts, • The one or more selected tasks Ti, target of the event Ev d ⁇ bu t, will select one or more of their scripts according to their internal operating state corresponding to the progress of a task with respect to the program or software, and will format at least one message with the appropriate scripts,
  • the one or more tasks sending the one or more messages via a communication module encapsulating said message or messages according to the dedicated transmission medium
  • At least one of the tasks includes, for example, one or more encrypted scripts and said dedicated resource is a cryptographic resource CE that decrypts the encapsulated message before executing it based on an identifier parameter contained in the script and associated with a key decryption.
  • said dedicated resource is a cryptographic resource CE that decrypts the encapsulated message before executing it based on an identifier parameter contained in the script and associated with a key decryption.
  • the communication means may be a communication bus or a messaging system.
  • the software is, for example, executable software or in the form of interpretable code, or binary software or in the form of interpretable code.
  • the method according to the invention comprises a single resource CE and a virtualization software module adapted to partition different tasks Ti, each task executing on an OS operating system that communicates with the virtualization module.
  • the invention also relates to a system for securing or protecting software that can be broken down into several independent tasks of the "Event-Action" type, said tasks managing a set of "scripts" characterized in that it comprises at least the following elements :
  • the system comprises, for example, several cryptographic resources comprising a decryption module of said selected encrypted module, associated with an encryption key and a module for executing said module after decryption.
  • the communication means is, for example, a communication bus or a messaging system.
  • the encryption module may comprise at least one of the following encryption algorithms: an AES (Advanced Encryption Standard) symmetric algorithm, an RSA (Rivest Shamir Adleman) type asymmetric algorithm, cryptographic algorithms, and an encryption key Ks.
  • AES Advanced Encryption Standard
  • RSA Raster Shamir Adleman
  • FIG. 1 an example of cutting in the form of an event tree of a software to be secured composed of several independent modules or binary services or interpreted,
  • FIG. 2 a definition for a binary task managing the selection of several binary or interpreted modules, comprising unencrypted scripts and encrypted scripts,
  • FIG. 3 a definition for the software or hardware resource managing the execution of modules
  • FIG. 4 an example of a connection diagram between the software to be secured and an external resource enabling it to be executed
  • FIG. 6, an example of external resources encrypting the sensitive modules
  • FIG. 7 a block diagram of the different events and the different tasks executed
  • FIGS. 8A, 8B an exemplary format respectively for an event and for a script message
  • the start event Ev d goal is issued by a cryptographic resource CE and execution.
  • This event selects a first task T1 composed of a set of script.
  • the script is an encrypted script, the padlock symbol representing encryption.
  • This script Si is transmitted in the form of an MS-i script message, to the cryptographic resource and CE execution.
  • the target task of the start event will select one or more of its scripts according to its internal state of operation corresponding to a progress with respect to the program and format another message with the appropriate scripts, then send this message via a communication module whose particular function is to encapsulate said message according to the transmission medium.
  • the resource CE decrypts and executes the script Si.
  • the execution of the script Si generates an EvSi script event that will select another script of the software, for example, encrypted script S 2 .
  • An MS 2 message resulting from this encrypted script S 2 will be transmitted to the resource CE which will first decrypt it and execute it once decrypted.
  • an EVS script event 2 will be transmitted to the software which will select a script S 3 which in this example is unencrypted and so on until the software receives a late event Evf in .
  • the format of an event may be that shown in Figure 8A.
  • the format of an event comprises in one case an identifier of the task to be executed, an identifier of the cryptographic resource CE on which the script chosen will be executed according to a given event and the state of the system characterized by the set of states of the script selection tasks. This state corresponds to the view Event / Stimulis at a time T of the progress in the execution of the software, a stimulus identifier, a reserve zone and a zone comprising the result of the execution.
  • the format of a script message may be that of FIG. 8B, namely, an identifier of the cryptographic resource on which the script will be executed, an identifier of the task to be executed, a reserve zone and a part containing the data. script specific.
  • FIG. 9 proposes a macroscopic format for a script, including an Idscript script identifier, a security policy Ps including the security state of the script, namely, whether or not it should be secure, the identifier of the crypto resource which will be used, data specific to the encryption algorithm used, an identifier corresponding to the IdLang script language, binary or interpreted data specific to the script, Di.
  • a task has the capability of a state machine reacting to external events by selecting one or more scripts encrypted or not via an external cryptographic resource CE.
  • scripts can be binary code (example: Java or C ++ compiled), interpreted code (example: java, php, or python), or the script (example: tel, javascript) will then be encapsulated in a message M ⁇ Mi ⁇ to one of the cryptographic resources CE of the complete system.
  • these scripts will be encrypted via an external cryptography resource (PC machine having the appropriate cryptographic elements) before being inserted into a task (or a service) such as described in Figure 6.
  • the scripts managed by the Ti tasks generate an Ev event and a particular execution result.
  • FIGS. 10 and 11 will illustrate two examples. use.
  • the different entities software and cryptographic resources communicate, for example, by a communication means such as a communication bus.
  • FIG. 2 schematizes an example of a definition of a binary task Ti managing the selection of several Mi modules or binary or interpreted services according to an external event Ev and its execution status in terms of progress in the program flow. This state is specific to each task but depends on the overall progress of the software.
  • the binary task Ti or 10 manages a set of modules Mi in binary or interpreted form, and selects If one of these modules Mi following an event Ev and its internal state Eti, 1 1.
  • the task Ti corresponds to the "state management" part of the event tree but instead of directly executing the selected binary module Mi, the task Ti encapsulates in a message the module Mi thanks to an encapsulation module 12 and the encapsulated message M ⁇ Mi ⁇ is then transmitted via the same module or a specific transmission module that allows it to be sent for execution by an external resource CE.
  • the Mi modules can be encrypted or not, the representation of an encrypted module takes the form of a padlock in the figure. This EC resource (FIG.
  • the encapsulated message M ⁇ Mi ⁇ is executed in the external resource CE, the execution generates an event Ev.
  • a task represented in FIG. 2 notably possesses the following functions: It manages a set of Mi modules in binary or interpreted, encrypted or non-encrypted form and selects one of these modules according to an external event and its internal state,
  • the system according to the invention may comprise one or more external resources CE, having symmetrical and asymmetrical cryptographic functionalities.
  • the cryptographic resources have, for example, a cryptographic module 14 adapted to generate and manage keys, certificates, symmetric and asymmetric cryptographic algorithms ( Figure 3).
  • an external resource also has a software code execution module, 15, or calculation unit, for example in the case of the language, it may be a Java Virtual Machine (JVM) interpreter, in the case of a compiled language, it may be a boot loader better known by the English expression "boot launcher" to implement an executable on a target machine.
  • JVM Java Virtual Machine
  • This cryptographic resource can either be implemented in hardware (example: Microprocessor with an internal cryptographic resource, FPGA, Field Programmable Gate Array or ASIC, Application- Specific Integrated Circuit) or software on a dedicated microprocessor.
  • the cryptographic algorithms managed by this resource will be of the symmetric type, such as AES and 3DES algorithms, and asymmetric such as the RSA and El Gamal algorithms.
  • the keys or certificates corresponding to the use of these algorithms will be managed by the cryptographic resources.
  • the external resource CE notably has the following functions: • It decrypts the binary or interpreted module (encrypted via an external system) encapsulated in the message via a set of cryptographic algorithm;
  • FIG. 4 shows an example of a connection diagram between a software consisting of a set of tasks managing Mi or interpreted binary modules and which transfers their execution to a dedicated external CE, CE resource, via a communication bus or a messaging system carrying the binary modules and the events.
  • the encapsulated messages M ⁇ Mi ⁇ transits via the communication bus BC to the dedicated resource CE.
  • the encapsulated message M ⁇ Mi ⁇ is executed by the dedicated external resource CE.
  • the executed message generates an EV event that will act on the state module 1 1, Eti.
  • the target task or tasks Ti of a process triggering event will select one or more of its scripts according to their internal operating state specific to each of them corresponding to the progress with respect to the program or software and go format each message with an appropriate script.
  • a task will then transmit this message via a communication module encapsulating the message according to the transmission medium considered.
  • the communication bus BC positioned between the tasks or services and the cryptographic resources makes it possible to transit the events and the messages.
  • the messages will carry the execution scripts.
  • Execution scripts will be formatted as messages that will be communicated (or transported) via a communication bus.
  • the communication bus can be either a conventional software messaging system, middleware known to those skilled in the art or an equivalent system having at least equivalent functionality.
  • FIG. 5 represents an implementation variant comprising a set of tasks Ti composed of several binary or interpreted modules and two resources CE, 21, 22.
  • Each task Ti is connected via a communication bus BC to dedicated resources, 21, 22 which will receive the messages encapsulated by the tasks Ti and execute them, by decrypting beforehand in the case where the encapsulated messages are encrypted.
  • Encapsulated messages can be encrypted messages or unencrypted messages.
  • the cryptographic resource CE will then decrypt the script according to the identifier of the task and will then execute it via its internal interpreter (or a "boot launcher" in the case of a binary compiled), generating a new EV event. This event will then be transmitted to all the tasks connected to the cryptographic resource, which can react to this stimulus according to their state.
  • FIG. 6 is an example of an external resource adapted to encrypt the so-called security-sensitive modules.
  • the unencrypted modules 30 are transmitted to this encryption resource 31 which delivers encrypted modules for example in confidentiality and in integrity 32.
  • the encryption resource 31 comprises, for example, the following elements: a symmetric algorithm Aes (Advanced Encryption Standard ), an asymmetric RSA (Rivest Shamir Adleman) algorithm, cryptographic algorithms, and an encryption key Ks.
  • Development and encryption of "sensitive" modules will have to be carried out in a controlled zone corresponding to the sensitivity level of this part. of the software. Once encrypted, the manipulation of these modules can be performed by any means of software deployment known to those skilled in the art.
  • FIGS. 7, 8A, 8B and 9 explained above show on the one hand the block diagram of the steps implemented by the method according to the invention, as well as examples of format for the messages.
  • the method according to the invention is based in particular on the modeling of a software or executable into several tasks or services independent of each other that will be triggered by external events.
  • the process used is based on the implementation of several phases:
  • Each of the modules will have a unique identification, -
  • Each of the actions of the program will then proceed as follows: o At a given event, one of the tasks (the destination task) will select one of these scripts according to its internal state as in the case of a state machine, and send it via a message to one of the "C &E" resources. This choice will be defined in the script itself; o The cryptographic resource will then decide if the script is secure.
  • the cryptographic resource will execute it directly via its internal computing unit (CPU), otherwise it will first decrypt the script via its cryptographic unit, and the key (and other cryptographic information of the security policy) associated with the identifier of the script; o The execution of the script will then generate another event, including the necessary identifiers following the progress, as well as the result of the execution (in binary form, or others, o The event Ev will then be sent to the different Ti tasks connected to the communication bus which will or will not be stimulated for another action, and this until the end of the program (end stimulus event).
  • CPU internal computing unit
  • an executable in the case where an executable must be able to use input / output systems such as a display, a monitor or a keyboard, it is possible to treat these input / output systems in two ways:
  • the input-outputs are not considered to be part of the sensitive areas, so without a certain level of confidentiality, then a particular task can implement directly unsecured scripts to make account of the implementation of these inputs / outputs.
  • the inputs / outputs, display, keyboard, etc. are considered to be part of the sensitive areas and therefore having a certain level of confidentiality, then the implementation of these inputs / outputs will be via one of the cryptographic resources.
  • FIG. 10 schematizes an exemplary implementation of the invention on a multi-processor system MP 1 , MP 2 , MP 3 or computer cluster managing python scripts Sk encrypted or not with a set of microprocessors interconnected via a BC communication bus for communicating point-to-point in a network better known as Anglo-Saxon "unicast", multicast or a point to a set of point (broadcast broadcast) such as the Ethernet standard.
  • the cryptographic resource will be implemented via a soft programmable FPGA softcore component (Field Programmable Gate Array), that is to say an FPGA component having a microprocessor core.
  • a soft programmable FPGA softcore component Field Programmable Gate Array
  • This component has the cryptographic functionality for decryption and storage of the associated encryption keys via the implementation of cryptographic algorithms and a calculation unit for implementing a Python interpreter.
  • the messages and events will then be encapsulated in IP type frames and the identifiers may correspond to the IP addresses associated with each of the entities (microprocessors and FPGAs).
  • FIG. 11 shows a second example of implementation of the invention on a single machine allowing the execution of several tasks in a partitioned manner.
  • Ti tasks include scripts coded in Python or JAVA. These scripts as it was previously mentioned, can be encrypted.
  • OSi operating systems are carried on the same microprocessor, via a virtualization solution known to those skilled in the software domain, and communicate via the interfaces of this paravirtualization software layer IPC and CV.
  • the cryptographic resource is represented by an ASIC-type hardware component, directly connected to the virtualization layer and accessible via the interfaces of this layer. via an IPC Intern Process Communication (socket) system. The messages and events will then be communicated via this messaging system internal to the paravirtualization layer.
  • the cryptographic resource manages two types of interpreters (Java and Python) for the purpose of interoperability interesting in the fields where the interpreted languages (database, administration, etc.) are used.
  • the cryptographic resource CE includes elements similar to those described in FIG.
  • the external entity is a PC type machine having the cryptographic capabilities equivalent to the resource CE in terms of cryptographic algorithm (for example, AES, 3DES, ...) and keys or certificates.
  • the method and the system according to the invention have, in particular, the advantage of being able to secure part or all of the executable software in the event of an attempt to steal equipment or to illicitly copy part or all the code of an executable. .
  • This is particularly interesting in the case of a PIN in any type of equipment either when executing the code for a device in operation or when stopping the equipment.
  • the invention also makes it possible to mix several types of sensitive or non-sensitive scripts, encrypted or not. It has the ability to disperse the execution of some or all of the code in one or more CE resources in order to secure the execution of the program. It also offers the possibility of having an execution platform that can be made available to a subcontractor, with an original code or owner of a client and not visible to the subcontractor. It therefore leads to the notion of confidential protection of the executable code in a context of use or client validation.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Technology Law (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Storage Device Security (AREA)

Abstract

Procédé et système pour sécuriser un logiciel pouvant être décomposé en plusieurs tâches indépendantes de type « Evénement-Action », les dites tâches gérant un ensemble de « scripts » caractérisé en ce qu'il utilise un module d'encapsulation de script et de message et une transmission de scripts encapsulés vers une ressource de confiance adaptés à les exécuter.

Description

PROCEDE ET SYSTEME PERMETTANT DE SECURISER UN LOGICIEL
L'invention concerne un procédé et une architecture de système permettant de sécuriser un logiciel, par exemple, un exécutable. Le terme « sécurisation ou sécuriser » désigne dans la présente description le fait de rendre inaccessible un logiciel à toute personne qui n'est pas autorisée à connaître son contenu.
Elle se situe dans le domaine matériel ou hardware et dans le domaine logiciel pour « sécuriser » la propriété Intellectuelle d'un logiciel c'est-à-dire rendre inaccessible les informations contenues dans un logiciel ou encore certaines parties d'un exécutable se présentant sous un format binaire ou un code interprété.
Dans la suite de la description, le mot « script » est utilisé, soit pour désigner un fichier texte comportant une série de commandes qui permettent d'exécuter et d'enchaîner automatiquement la plupart des fonctions habituellement accessibles, soit un fichier binaire correspondant à du code exécutable dans un environnement donné. Les scripts offrent donc la possibilité d'enchaîner, sans intervention de l'utilisateur, notamment des événements, etc. Il sera aussi question de script chiffré correspondant à un script sur lequel un algorithme de chiffrement aura été appliqué afin que seules les ressources ou personnes autorisées puissent accéder aux informations contenues dans le logiciel.
Dans le développement traditionnel d'un logiciel, le problème de la propriété intellectuelle du code source est souvent posé. Cette problématique intervient, par exemple, dans le domaine des plate-formes de confiance sur lesquelles peuvent être mis en œuvre un ou plusieurs exécutables avec un niveau de sécurité permettant de contrer le vol ou d'éviter l'ingénierie inverse plus connue sous l'appellation anglo-saxonne « reverse engineering » du logiciel fonctionnant sur machine. A la connaissance du Demandeur le problème de la sécurité d'un exécutable est généralement traité en mettant en œuvre des mécanismes cryptographiques permettant de chiffrer l'exécutable sur un support de stockage de type accessible en lecture uniquement connu sous l'abréviation ROM (abréviation anglo-saxonne de « read only memory ») ou encore une mémoire de masse réinscriptible ou mémoire FLASH, et de le déchiffrer soit au démarrage dans une mémoire de travail (RAM abréviation anglo saxonne de random Access Memory), soit à la volée dans le cas d'un code interprété, par exemple, le langage JAVA et son « By-code » ou encore le langage Python, langages connus de l'Homme du métier. Ceci revient à posséder sur une même machine un microprocesseur permettant le traitement du fichier binaire de l'exécutable et son déchiffrement en utilisant une ressource cryptographique intégrée. Pour le langage JAVA, le code est déchiffré à la volée et exécuté par l'interpréteur JVM (Java Virtual Machine) de la machine hôte. Cette technique chiffre donc dans un premier temps la totalité du code exécutable et ensuite le code est déchiffré avant d'être exécuté par un microprocesseur ou bien une partie d'un byte-code chiffré est interprété par un interpréteur spécifique. La demande de brevet US20070061 69A1 divulgue l'utilisation de ressources cryptologiques dans le but de conférer des propriétés de confidentialité, d'intégrité ou d'authentification via le chiffrement de mémoires de stockage. Ce type de ressource peut être associé à la norme TPM (Trusted Platform Module) intégré dans la plupart des équipements civils. Le brevet US 7 210 009 concerne un système comprenant un processeur configuré pour assurer un mode d'exécution sécuritaire de tout logiciel.
En général, les mécanismes décrits dans l'art antérieur présentent les inconvénients suivants :
> C'est une même ressource de calcul (Microprocesseur) qui permet le fonctionnement de l'exécutable et qui possède au final la totalité du code source ; > La confiance dans un système est complètement centralisée au niveau de la ressource de déchiffrement qui possède les éléments sensibles (Clés, certificats,...) ;
> Les mécanismes connus n'offrent pas de souplesse dans leur capacité à séparer les parties de code dites « sensibles » et les autres dites « publiques ».
L'objet de la présente invention repose sur une nouvelle approche permettant d'assurer la protection des droits d'auteurs liés au logiciel, tout en s'affranchissant des inconvénients existants dans l'art antérieur. A cet effet, l'objet de la présente invention met en œuvre une encapsulation de script ou de message et une transmission des scripts encapsulés vers une ressource de confiance adaptée à les exécuter. Les scripts peuvent être ou non chiffrés, dans ce cas la ressource de confiance déchiffre ces derniers avant exécution.
L'invention s'applique notamment pour des logiciels pouvant se mettre sous la forme d'automates à états.
Dans ce cadre, le mot « encapsulation » désigne le fait d'utiliser un autre protocole afin de transporter une partie ou la totalité des scripts dans un médium adapté à ce protocole de transport. Dans cette invention, les scripts seront formatés dans des messages qui seront eux-même encapsulés dans des procotoles de communication du type IP, etc.
L'objet de l'invention concerne un procédé pour sécuriser un logiciel pouvant être décomposé en plusieurs tâches indépendantes de type « Evénement- Action », les dites tâches gérant un ensemble de « scripts » chiffrés ou non chiffrés caractérisé en ce qu'il comporte au moins les étapes suivantes : • Décomposer le logiciel à sécuriser en plusieurs tâches Ti indépendantes, • Sur l'arrivée d'un événement de début Evdθbut, sélectionner au moins une des tâches Ti composée d'un ensemble de scripts, • La ou lesdites tâches Ti sélectionnées, cible de l'événement Evdθbut, vont sélectionner un ou plusieurs de leurs scripts suivant leur état interne de fonctionnement correspondant à l'avancement d'une tâche vis à vis du programme ou logiciel, et va formater au moins un message avec les scripts adéquats,
• La ou lesdites tâches envoient le ou lesdits messages via un module de communication encapsulant ledit ou lesdits messages suivant le médium de transmission dédié,
• Transmettre ledit ou lesdits messages encapsulés à au moins une ressource dédiée via un moyen de communication, ladite ou lesdites ressources dédiées étant déterminées par un paramètre inclus dans ledit ou lesdits messages encapsulés,
• La ou lesdites ressources dédiées exécutent alors le ou les messages encapsulés, • L'exécution d'un script génère un autre événement EV comportant les identifiants nécessaires à la suite du déroulement du procédé, ainsi que le résultat de l'exécution,
• L'événement EV va alors être envoyé aux différentes tâches Ti connectées au moyen de communication qui seront ou non stimulées pour une autre action, et ceci jusqu'à la réception d'un événement de fin de procédé Evfin.
Au moins une des tâches comprend, par exemple, un ou plusieurs scripts chiffrés et ladite ressource dédiée est une ressource cryptographique CE qui déchiffre le message encapsulé avant de l'exécuter en fonction d'un paramètre identifiant contenu dans le script et associé à une clé de déchiffrement.
Le moyen de communication peut être un bus de communication ou un système de messagerie.
Le logiciel est, par exemple, un logiciel exécutable ou sous forme de code interprétable, ou encore un logiciel binaire ou sous forme de code interprétable. Selon un mode de réalisation le procédé selon l'invention comporte une seule ressource CE et un module logiciel de virtualisation adapté à cloisonner différentes tâches Ti, chaque tâche s'exécutant sur un système d'exploitation OS qui communique avec le module de virtualisation. L'invention concerne aussi un système permettant de sécuriser ou protéger un logiciel pouvant être décomposé en plusieurs tâches indépendantes de type « Evénement-Action », lesdites tâches gérant un ensemble de « scripts » caractérisé en ce qu'il comporte au moins les éléments suivants :
• Un module permettant d'encapsuler un module sélectionné dans une tâche Ti elle-même sélectionnée en fonction de l'état du logiciel et d'un événement extérieur, et de le mettre sous la forme d'un message encapsulant le module sélectionné,
• Un module de transmission du message encapsulant le module sélectionné via un moyen de communication vers une ou plusieurs ressources d'exécution dudit message et dudit module sélectionné.
Le système comporte, par exemple, plusieurs ressources cryptographiques comprenant un module de déchiffrement dudit module chiffré sélectionné, associé à une clé de chiffrement et un module d'exécution dudit module après déchiffrement. Le moyen de communication est, par exemple, un bus de communication ou un système de messagerie.
Le module de chiffrement peut comprendre au moins un des algorithmes de chiffrement suivant : un algorithme symétrique Aes (Advanced Encryption Standard), un algorithme asymétrique de type RSA (Rivest Shamir Adleman), des algorithmes cryptographiques, et une clé de chiffrement Ks.
D'autres caractéristiques et avantages du dispositif selon l'invention apparaîtront mieux à la lecture de la description qui suit d'un exemple de réalisation donné à titre illustratif et nullement limitatif annexé des figures qui représentent : • La figure 1 , un exemple de découpage sous forme d'un arbre à événements d'un logiciel à sécuriser composé de plusieurs modules ou services binaires ou interprétés indépendants,
• La figure 2, une définition pour une tâche binaire gérant la sélection de plusieurs modules binaires ou interprétés, comprenant des scripts non chiffrés et des scripts chiffrés,
• La figure 3, une définition pour la ressource logicielle ou matérielle gérant l'exécution de modules,
• La figure 4, un exemple de schéma de connexion entre le logiciel à sécuriser et une ressource externe permettant de l'exécuter,
• La figure 5, un exemple d'utilisation de plusieurs tâches et de ressources,
• La figure 6, un exemple de ressources externe chiffrant les modules sensibles, « La figure 7, un synoptique des différents événements et des différentes tâches exécutés,
• Les figures 8A, 8B, un exemple de format respectivement pour un événement et pour un message de script,
• La figure 9, un exemple de format macroscopique pour un script, • Les figures 10 et 11 deux exemples de mise en œuvre du procédé selon l'invention.
Afin de mieux faire comprendre l'objet de la présente invention, la description qui suit sera donnée en relation avec un logiciel, par exemple un exécutable, pouvant être décrit en plusieurs tâches Ti fonctionnant sur le principe « événement-action », principe connu de l'Homme du métier. Le logiciel est donc modélisé sur le principe de tâches ou de services fonctionnels déclenchés via des événements externes. Ces tâches permettront, sur le même principe qu'un automate à états, de réagir à un événement extérieur en sélectionnant le script adéquat (vis à vis de son état interne). Mais au lieu d'exécuter le script, la tâche (ou le service) encapsulera le script chiffré ou non dans un message à destination d'une ressource cryptographique. Chacune de ces tâches ou services est définie par un ou plusieurs scripts générant un événement particulier. Sur la figure 1 est représenté un logiciel pouvant être décomposé en plusieurs modules Mi ou services binaires indépendants. Le logiciel peut être représenté sous la forme d'un arbre à événements.
Le fonctionnement d'un tel logiciel est représenté à la figure 7. L'événement démarrage Evdθbut est émis par une ressource cryptographique CE et d'exécution. Cet événement sélectionne une première tâche T1 composée d'un ensemble de script. Dans l'exemple, le script est un script chiffré, le symbole du cadenas représentant le chiffrement. Ce script Si est transmis sous la forme d'un message script MS-i, à la ressource cryptographique et d'exécution CE. La tâche cible de l'événement début va sélectionner un ou plusieurs de ses scripts suivant son état interne de fonctionnement correspondant à un avancement vis-à-vis du programme et formater un autre message avec les scripts adéquats, puis va envoyer ce message via un module de communication ayant notamment pour fonction d'encapsuler ledit message suivant le médium de transmission. La ressource CE déchiffre et exécute le script S-i. L'exécution du script Si génère un événement script EvSi qui va sélectionner un autre script du logiciel, par exemple, script S2 chiffré. Un message MS2 résultant de ce script S2 chiffré va être transmis à la ressource CE qui va dans un premier temps le déchiffrer et l'exécuter une fois déchiffré. A la suite de cette exécution, un événement script EvS2 va être transmis au logiciel qui va sélectionner un script S3 qui dans cet exemple est non chiffré et ainsi de suite jusqu'à ce que le logiciel reçoive un événement fin d'exécution Evfin.
Le format d'un événement peut être celui représenté à la figure 8A. Le format d'un événement comprend dans un cas un identifiant de la tâche à exécuter, un identifiant de la ressource cryptographique CE sur laquelle va être exécuté le script choisi selon un événement donné et l'état du système caractérisé par l'ensemble des états des tâches de sélection des scripts. Cet état correspondant à la vision Evénement/Stimulis à un instant T de l'avancement dans l'exécution du logiciel, un identifiant stimuli, une zone de réserve et une zone comprenant le résultat de l'exécution. Le format d'un message de script peut être celui de la figure 8B, à savoir, un identifiant de la ressource cryptographique sur laquelle va être exécuté le script, un identifiant de la tâche à exécuter, une zone réserve et une partie contenant les données propres au script. La figure 9 propose un format macroscopique pour un script, comprenant un identifiant script Idscript, une politique de sécurité Ps comprenant l'état de sécurisation du script, à savoir, doit-il être ou non sécuriser, l'identifiant de la ressource crypto qui va être utilisée, des données propres à l'algorithme de chiffrement utilisé, un identifiant correspondant au langage du script IdLang, des données binaires ou interprétées propres au script, Di. Une tâche a la capacité d'un automate à états réagissant à des événements externes en sélectionnant un ou plusieurs scripts chiffrés ou non via une ressource externe cryptographique CE.
Ces scripts pouvant être du code binaire (exemple : Java ou C++ compilé), du code interprété (exemple : java, php, ou python), ou du script (exemple : tel, javascript) seront alors encapsulés dans un message M{Mi} vers une des ressources cryptographiques CE du système complet. Dans le cas où les scripts possèdent une certaine sensibilité (ou confidentialité), ces scripts seront chiffrés via une ressource externe de cryptographie (Machine de type PC ayant les éléments cryptographiques adéquats) avant d'être inséré dans une tâche (ou un service) tel que décrite à la figure 6.
Les scripts gérés par les tâches Ti permettent de générer un événement Ev et un résultat d'exécution particulière.
L'architecture du système selon l'invention repose notamment sur l'utilisation de plusieurs entités combinées entre elles de manière judicieuse qui vont être décrites seules ou ensembles dans les figures 2 à 6. Les figures 10 et 1 1 permettront d'illustrer deux exemples d'utilisation. Les différentes entités logiciel et ressources cryptographiques, communiquent, par exemple, par un moyen de communication tel qu'un bus de communication. La figure 2 schématise un exemple de définition d'une tâche binaire Ti gérant la sélection de plusieurs modules Mi ou services binaires ou interprétés suivant un événement externe Ev et son état d'exécution en terme d'avancement dans le déroulement du programme. Cet état est spécifique à chacune des tâches mais dépend de l'avancement global du logiciel. La tâche binaire Ti ou 10 gère un ensemble de modules Mi sous forme binaire ou interprété, et sélectionne Si un de ces modules Mi suivant un événement Ev et son état interne Eti, 1 1 . La tâche Ti correspond à la partie « gestion de l'état » de l'arbre à événement mais au lieu d'exécuter directement le module binaire Mi sélectionné, la tâche Ti encapsule dans un message le module Mi grâce à un module d'encapsulation 12 et le message encapsulé M{Mi} est ensuite transmis via le même module ou un module de transmission spécifique qui permet son envoi pour exécution par une ressource externe CE. Les modules Mi peuvent être chiffrés ou non, la représentation d'un module chiffré prend la forme d'un cadenas sur la figure. Cette ressource CE (figure 3) comportant un module 14 de déchiffrement lorsque les modules ont été chiffrés et un module binaire 15 ou un interpréteur selon le format du message encapsulé reçu. Le message encapsulé M{Mi} est exécuté dans la ressource externe CE, l'exécution génère un événement Ev.
Une tâche représentée sur la figure 2 possède notamment les fonctions suivantes : • Elle gère un ensemble de modules Mi sous forme binaire ou interprété, chiffrés ou non chiffrés et sélectionne un de ces modules suivant un événement externe et son état interne,
• Elle correspond à la partie « gestion de l'état » de l'arbre à événement, mais au lieu d'exécuter directement le module binaire, il va l'encapsuler dans un message et l'envoyer pour exécution vers une ressource externe, • Elle n'a donc aucune visibilité sur les modules, autre que leur sélection suivant un ensemble de paramètres internes et externes (Ev pour événement, Etat).
Le système selon l'invention peut comporter une ou plusieurs ressources externes CE, ayant des fonctionnalités cryptographiques symétriques et asymétriques. Pour cela, les ressources cryptographiques possèdent, par exemple, un module de cryptographie 14 adapté à générer et gérer des clés, des certificats, des algorithmes cryptographiques symétriques et asymétriques (figure 3). De manière générale, une ressource externe possède aussi un module d'exécution de code logiciel, 15, ou unité de calcul, par exemple dans le cas du langage, il peut s'agit d'un interpréteur JVM (Java Virtuel Machine), dans le cas d'un langage compilé, il peut s'agir d'un chargeur d'amorçage plus connu sous l'expression anglaise « Boot lanceur » permettant de mettre en œuvre un exécutable sur une machine cible. Cette ressource cryptographique peut être soit mise en œuvre de manière hardware (exemple : Microprocesseur avec une ressource cryptographique interne, FPGA, Field-Programmable Gâte Array ou ASIC, Application- Specific Integrated Circuit) ou de manière logicielle sur un microprocesseur dédié. Les algorithmes cryptographiques gérés par cette ressource seront du type symétrique, tels que les algorithmes AES et 3DES, et asymétrique tels que les algorithmes RSA et El Gamal. Les clés ou les certificats correspondant à l'utilisation de ces algorithmes seront gérés par les ressources cryptographiques. En résumé, la ressource externe CE a notamment les fonctions suivantes : • Elle déchiffre le module binaire ou interprété (chiffré via un système externe) encapsulé dans le message via un ensemble d'algorithme cryptographique ;
• Elle gère l'exécution du module sous forme binaire, ou interprété via sa capacité de « boot loader » dans le cas binaire et d'interpréteur dans le cas d'un « bytecode » ou équivalent ; • Elle exécute et renvoie le résultat de l'exécution sous la forme d'un événement ;
• Elle ne possède qu'une visibilité relative du programme car fragmentaire. L'exécutable fonctionne alors sur le principe d'un automate d'états dans lequel chacun des scripts génère un événement destiné à une tâche particulière ou à plusieurs tâches (ou un service) et permettra ainsi via le déroulement de plusieurs tâches (et des scripts associés) l'exécution du programme logiciel. Dans le cadre de cette solution, il est possible de chiffrer les scripts confidentiels d'une tâche (ou d'un service) via une ressource cryptographique (externe) comme il est décrit à la figure 6. La figure 4 schématise un exemple d'un schéma de connexion entre un logiciel composé d'un ensemble de tâches gérant des modules binaires Mi ou interprétés et qui déporte leur exécution vers une ressource externe CE, CE dédiée, via un bus de communication ou un système de messagerie transportant les modules binaires et les événements. Les messages encapsulés M{Mi} transite via le bus de communication BC vers la ressource dédiée CE. Le message encapsulé M{Mi} est exécuté par la ressource externe dédiée CE. Le message exécuté génère un événement EV qui va aller agir sur le module d'état 1 1 , Eti. La tâche ou les tâches Ti cibles d'un événement déclencheur du procédé vont sélectionner un ou plusieurs de ses scripts suivant leur état interne de fonctionnement propre à chacune d'elle correspondant à l'avancement vis-à-vis du programme ou logiciel et vont formater chacune un message avec un script adéquat. Une tâche va ensuite transmettre ce message via un module de communication encapsulant le message suivant le médium de transmission considéré. Le bus de communication BC positionné entre les tâches ou services et les ressources cryptographiques permet de faire transiter les événements et les messages. Ces événements transporteront, par exemple, le stimulus de déclenchement d'une des tâches et le résultat de l'exécution d'un script, qui se présente sous la forme d'un événement. Les messages transporteront les scripts exécution. Les scripts d'exécution seront formatés sous la forme de messages qui seront communiqués (ou transportés) via un bus de communication. Le bus de communication peut être soit un système de messagerie logiciel classique, soit un intergiciel connu de l'Homme du métier ou encore un système équivalent présentant au moins des fonctionnalités équivalentes.
La figure 5 représente une variante de mise en œuvre comprenant un ensemble de tâches Ti composées de plusieurs modules binaires ou interprétés et deux ressources CE, 21 , 22. Chacune des tâches Ti est reliée par l'intermédiaire d'un bus de communication BC à des ressources dédiées, 21 , 22 qui vont recevoir les messages encapsulés par les tâches Ti et les exécuter, en les déchiffrant préalablement dans le cas où les messages encapsulés sont chiffrés. Les messages encapsulés peuvent être des messages chiffrés ou des messages non chiffrés. Pour traiter les messages chiffrés et encapsulés, la ressource cryptographique CE va alors déchiffrer 24 le script suivant l'identifiant de la tâche et va ensuite l'exécuter via son interpréteur interne 25 (ou un « boot lanceur » dans le cas d'un binaire compilé), générant ainsi un nouvel événement EV. Cet événement sera alors transmis à toutes les tâches connectées à la ressource cryptographique, qui pourront réagir à ce stimulus suivant leur état.
La mise en œuvre de plusieurs ressources cryptographiques permet notamment de « disperser » ou de « distribuer » l'exécution du code sur plusieurs ressources cryptographiques afin d'éviter d'une part une connaissance centralisée du code complet par une seule ressource, et d'autre part de permettre la gestion d'un mode de défaillance dans le cas où une des ressources ne fonctionne plus (redondance des ressources cryptographiques). La figure 6 est un exemple de ressource externe adaptée à chiffrer les modules dits sensibles au sens de la sécurité. Les modules non chiffrés 30, sont transmis à cette ressource de chiffrement 31 qui délivre des modules chiffrés par exemple en confidentialité et en intégrité 32. La ressource de chiffrement 31 comprend, par exemple, les éléments suivants : un algorithme symétrique Aes (Advanced Encryption Standard), un algorithme asymétrique de type RSA (Rivest Shamir Adleman), des algorithmes cryptographiques, et une clé de chiffrement Ks. Le développement et le chiffrement des modules « sensibles » devront être effectué dans une zone maitrisé correspondant au niveau de sensibilité de cette partie du logiciel. Une fois chiffré, la manipulation de ces modules pourra être effectuée par tous moyens de déploiement logiciel connus par l'homme de l'art. Les figures 7, 8A, 8B et 9 explicitées ci-dessus présentent d'une part le synoptique des étapes mises en œuvre par le procédé selon l'invention, ainsi que des exemples de format pour les messages.
Le procédé selon l'invention repose notamment sur la modélisation d'un logiciel ou exécutable en plusieurs tâches ou services indépendants les uns des autres qui vont être déclenchés par des événements externes. Le procédé utilisé est basé sur la mise en œuvre de plusieurs phases :
• Décomposition d'un exécutable en plusieurs tâches indépendantes de type Εvenement-Action', gérant un ensemble de scripts ayant des niveaux de sensibilité différents, dont des scripts chiffrés et/ou non chiffrés,
• Connections des tâches définies à une ou plusieurs ressources cryptographiques via un système de communication (bus logiciel, messagerie,...),
• Chacun des modules aura une identification unique, - Chacune des actions du programme se déroulera alors de la manière suivante : o A un événement donné, une des tâches (la tâche destination) va sélectionner un de ces scripts suivant son état interne comme dans le cas d'un automate à états, et l'envoyer via un message à une des ressources « C&E ». Ce choix sera défini dans le script lui-même ; o La ressource cryptographique va alors décider si le script est sécurisé. Dans le cas où le script est non chiffré, la ressource cryptographique va l'exécuter directement via son unité interne de calcul (CPU), sinon elle va tout d'abord déchiffrer le script via son unité cryptographique, et de la clé (et d'autres informations cryptographiques de la politique de sécurité) associé à l'identifiant du script ; o L'exécution du script va alors générer un autre événement, comportant les identifiants nécessaires à la suite du déroulement, ainsi que le résultat de l'exécution (sous forme binaire, ou autres, o L'événement Ev va alors être envoyé aux différentes tâches Ti connectées au bus de communication qui seront ou non stimulées pour une autre action, et ceci jusqu'à la fin du programme (événement stimulus de fin).
Selon un mode de réalisation, dans le cas où un exécutable doit pouvoir utiliser des systèmes d'entrée/sorties tel qu'un afficheur, un moniteur ou un clavier, il est possible de traiter ces systèmes d'entrée/sortie de deux façons :
• Dans le premier cas, les entrées-sorties (afficheur) ne sont pas considérées comme faisant partie des zones sensibles, donc ne possédant pas un certain niveau de confidentialité, alors une tâche particulière pourra mettre en œuvre directement des scripts non sécurisés afin de rendre compte de la mise en œuvre des ces entrées/sorties. • Dans un second cas, les entrées/sorties, afficheur, clavier, etc. sont considérées comme faisant partie des zones sensibles et donc possédant un certain niveau de confidentialité, alors la mise en œuvre de ces entrées/sorties se fera via l'intermédiaire d'une des ressources cryptographiques.
La figure 10 schématise un exemple de mise en œuvre de l'invention sur un système multi-processeurs MP1, MP2, MP3 ou grappe d'ordinateurs gérant des scripts python Sk chiffrés ou non avec un ensemble de microprocesseurs reliés entre eux via un bus de communication BC permettant de communiquer de manière point à point dans un réseau plus connu sous le terme anglosaxon « unicast », multicast ou encore d'un point vers un ensemble de point (diffusion broadcast) tel que le standard Ethernet. La ressource cryptographique sera dans ce contexte, mise en œuvre via un composant programmable de type FPGA Softcore (Field Programmable Gâte Array), c'est-à-dire un composant FPGA possédant un cœur microprocesseur. Ce composant possède les fonctionnalités cryptographiques de déchiffrement et de stockage des clés de chiffrement associés via la mise en œuvre d'algorithmes cryptographiques et une unité de calcul permettant de mettre en œuvre un interpréteur Python. Dans ce contexte, les messages et les événements seront alors encapsulés dans des trames de type IP et les identifiants pourront correspondre aux adresses IP associées à chacune des entités (microprocesseurs et FPGA).
La figure 1 1 montre un deuxième exemple de mise en œuvre de l'invention sur une seule machine permettant l'exécution de plusieurs tâches de manière partitionnée. Les tâches Ti comprennent des scripts codés en langage Python ou en langage JAVA. Ces scripts comme il a été précédemment mentionné, peuvent être chiffrés. Plusieurs systèmes d'exploitation OSi sont portés sur un même microprocesseur, via une solution de virtualisation connue de l'Homme du métier du domaine logiciel, et communiquent via les interfaces de cette couche logicielle de paravirtualisation IPC et CV. Dans ce cadre, la ressource cryptographique est représentée par un composant matériel de type ASIC, relié directement à la couche de virtualisation et est accessible via les interfaces de cette couche via un système de messagerie logicielle (IPC Intern Process Communication ou socket). Les messages et les événements seront alors communiqués via ce système de messagerie interne à la couche de paravirtualisation. Dans cet exemple, la ressource cryptographique gère deux types d'interpréteurs (Java et Python) dans un but d'interopérabilité intéressant dans les domaines où l'on utilise les langages interprétés (base de données, administration, etc.). La ressource cryptographique CE comprend des éléments similaires à ceux décrits à la figure 10.
Dans les figures 10 et 1 1 , l'entité extérieure est une machine de type PC possédant les capacités cryptographiques équivalentes à la ressource CE en terme d'algorithme cryptographique (par exemple, AES, 3DES,...) et de clés ou de certificats.
Le procédé et le système selon l'invention présentent notamment comme avantage de pouvoir sécuriser une partie ou tout le logiciel exécutable en cas de tentative de vol d'un équipement ou de copie illicite d'une partie ou de tout le code d'un exécutable. Ceci est particulièrement intéressant dans le cas d'un code confidentiel dans tout type d'équipements que ce soit lors de l'exécution du code pour un appareil en fonctionnement ou bien lors de l'arrêt de l'équipement.
L'invention permet aussi de mixer plusieurs types de scripts sensibles ou non sensibles, chiffrés ou non. Elle a une capacité à disperser l'exécution d'une partie ou de la totalité du code dans une ou plusieurs ressources CE afin de sécuriser l'exécution du programme. Elle offre aussi la possibilité de disposer d'une plate-forme d'exécution pouvant être mise à disposition d'un sous- traitant, avec un code original ou propriétaire d'un donneur d'ordre et non visible par le sous-traitant. Elle conduit donc à la notion de protection en confidentialité du code exécutable dans un contexte d'utilisation ou de validation client.

Claims

REVENDICATIONS
1 - Procédé pour sécuriser un logiciel pouvant être décomposé en plusieurs tâches indépendantes de type « Evénement-Action », les dites tâches gérant un ensemble de « scripts » chiffrés ou non chiffrés caractérisé en ce qu'il comporte au moins les étapes suivantes :
• Décomposer le logiciel à sécuriser en plusieurs tâches Ti indépendantes,
• Sur l'arrivée d'un événement de début Evdθbut, sélectionner au moins une des tâches Ti composée d'un ensemble de scripts,
• La ou lesdites tâches Ti sélectionnées, cible de l'événement Evdθbut, vont sélectionner un ou plusieurs de leurs scripts suivant leur état interne de fonctionnement correspondant à l'avancement d'une tâche vis à vis du programme ou logiciel, et va formater au moins un message avec les scripts adéquats,
• La ou lesdites tâches envoient le ou lesdits messages via un module de communication encapsulant ledit ou lesdits messages suivant le médium de transmission dédié,
• Transmettre ledit ou lesdits messages encapsulés à au moins une ressource dédiée via un moyen de communication, ladite ou lesdites ressources dédiées étant déterminées par un paramètre inclus dans ledit ou lesdits messages encapsulés,
• La ou lesdites ressources dédiées exécutent alors le ou les messages encapsulés, • L'exécution d'un script génère un autre événement EV comportant les identifiants nécessaires à la suite du déroulement du procédé, ainsi que le résultat de l'exécution,
• L'événement EV va alors être envoyé aux différentes tâches Ti connectées au moyen de communication qui seront ou non stimulées pour une autre action, et ceci jusqu'à la réception d'un événement de fin de procédé Evfin. 2 - Procédé selon la revendication 1 caractérisé en ce qu'au moins une des tâches comprend un ou plusieurs scripts chiffrés et en ce que ladite ressource dédiée est une ressource cryptographique CE qui déchiffre le message encapsulé avant de l'exécuter en fonction d'un paramètre identifiant contenu dans le script et associé à une clé de déchiffrement.
3 - Procédé selon l'une des revendications 1 ou 2 caractérisé en ce que le moyen de communication est un bus de communication ou un système de messagerie.
4 - Procédé selon l'une des revendications 1 à 3 caractérisé en ce que le logiciel est un logiciel exécutable ou sous forme de code interprétable.
5 - Procédé selon l'une des revendications 1 à 4 caractérisé en ce que le logiciel est un logiciel binaire ou sous forme de code interprétable.
6 - Procédé selon l'une des revendications 1 à 5 caractérisé en ce qu'il utilise une seule ressource CE et un module logiciel de virtualisation adapté à cloisonner différentes tâches Ti, chaque tâche s'exécutant sur un système d'exploitation OS qui communique avec le module de virtualisation.
7 - Système permettant de sécuriser ou protéger un logiciel pouvant être décomposé en plusieurs tâches indépendantes de type « Evènement- Action », lesdites tâches gérant un ensemble de « scripts » caractérisé en ce qu'il comporte au moins les éléments suivants :
• Un module permettant d'encapsuler un module sélectionné dans une tâche Ti elle-même sélectionnée en fonction de l'état du logiciel et d'un événement extérieur, et de le mettre sous la forme d'un message encapsulant le module sélectionné, • Un module de transmission du message encapsulant le module sélectionné via un moyen de communication vers une ou plusieurs ressources d'exécution dudit message et dudit module sélectionné.
8 - Système selon la revendication 7 caractérisé en ce qu'il comporte une ou plusieurs ressources cryptographiques comprenant un module de déchiffrement dudit module chiffré sélectionné, associé à une clé de chiffrement et un module d'exécution dudit module après déchiffrement.
9 - Système selon l'une des revendications 7 ou 8 caractérisé en ce que le moyen de communication est un bus de communication ou un système de messagerie.
10 - Système selon l'une des revendications 8 à 9 caractérisé en ce que le module de chiffrement comprend au moins un des algorithmes de chiffrement suivant : un algorithme symétrique Aes (Advanced Encryption Standard), un algorithme asymétrique de type RSA (Rivest Shamir Adleman), des algorithmes cryptographiques, et une clé de chiffrement Ks.
EP09802522A 2008-07-29 2009-07-29 Procede et systeme permettant de securiser un logiciel Withdrawn EP2318976A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0804321A FR2934697B1 (fr) 2008-07-29 2008-07-29 Procede et systeme permettant de securiser un logiciel
PCT/EP2009/059825 WO2010012785A1 (fr) 2008-07-29 2009-07-29 Procede et systeme permettant de securiser un logiciel

Publications (1)

Publication Number Publication Date
EP2318976A1 true EP2318976A1 (fr) 2011-05-11

Family

ID=40429990

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09802522A Withdrawn EP2318976A1 (fr) 2008-07-29 2009-07-29 Procede et systeme permettant de securiser un logiciel

Country Status (4)

Country Link
US (1) US20110191597A1 (fr)
EP (1) EP2318976A1 (fr)
FR (1) FR2934697B1 (fr)
WO (1) WO2010012785A1 (fr)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8898769B2 (en) * 2012-11-16 2014-11-25 At&T Intellectual Property I, Lp Methods for provisioning universal integrated circuit cards
US8959331B2 (en) 2012-11-19 2015-02-17 At&T Intellectual Property I, Lp Systems for provisioning universal integrated circuit cards
US9036820B2 (en) 2013-09-11 2015-05-19 At&T Intellectual Property I, Lp System and methods for UICC-based secure communication
US9124573B2 (en) 2013-10-04 2015-09-01 At&T Intellectual Property I, Lp Apparatus and method for managing use of secure tokens
US9208300B2 (en) 2013-10-23 2015-12-08 At&T Intellectual Property I, Lp Apparatus and method for secure authentication of a communication device
US9240994B2 (en) 2013-10-28 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for securely managing the accessibility to content and applications
US9313660B2 (en) 2013-11-01 2016-04-12 At&T Intellectual Property I, Lp Apparatus and method for secure provisioning of a communication device
US9240989B2 (en) 2013-11-01 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for secure over the air programming of a communication device
US9413759B2 (en) 2013-11-27 2016-08-09 At&T Intellectual Property I, Lp Apparatus and method for secure delivery of data from a communication device
US9713006B2 (en) 2014-05-01 2017-07-18 At&T Intellectual Property I, Lp Apparatus and method for managing security domains for a universal integrated circuit card
CN111258595B (zh) * 2020-03-13 2023-08-01 超越科技股份有限公司 一种基于PyInstaller的python源代码封装方法
GB202014682D0 (en) * 2020-09-17 2020-11-04 Nordic Semiconductor Asa Bootloaders
CN112751825B (zh) * 2020-12-07 2022-09-16 湖南麒麟信安科技股份有限公司 基于ssl证书的软件源发布权限控制方法及系统
CN115659292B (zh) * 2022-12-28 2023-05-02 北京大学 脚本代码的加密方法及装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7657450B2 (en) * 2000-12-08 2010-02-02 Microsoft Corporation Reliable, secure and scalable infrastructure for event registration and propagation in a distributed enterprise
US7210009B2 (en) * 2003-09-04 2007-04-24 Advanced Micro Devices, Inc. Computer system employing a trusted execution environment including a memory controller configured to clear memory
US20060048223A1 (en) * 2004-08-31 2006-03-02 Lee Michael C Method and system for providing tamper-resistant software
US7908483B2 (en) * 2005-06-30 2011-03-15 Intel Corporation Method and apparatus for binding TPM keys to execution entities
CN101228531A (zh) * 2005-07-22 2008-07-23 松下电器产业株式会社 执行装置
US8171306B2 (en) * 2008-11-05 2012-05-01 Microsoft Corporation Universal secure token for obfuscation and tamper resistance

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2010012785A1 *

Also Published As

Publication number Publication date
FR2934697B1 (fr) 2010-09-10
FR2934697A1 (fr) 2010-02-05
WO2010012785A1 (fr) 2010-02-04
US20110191597A1 (en) 2011-08-04

Similar Documents

Publication Publication Date Title
EP2318976A1 (fr) Procede et systeme permettant de securiser un logiciel
EP3055965B1 (fr) Procede et dispositif d'authentification et d'execution securisee de programmes
EP3248360B1 (fr) Systèmes et procédés de communication sécurisée à chemin sécurisé
JP7516691B1 (ja) 異なるデータアーキテクチャを有するネットワークにわたって資産を転送するためのセキュアかつ信頼できるブリッジ
US20230198765A1 (en) Multi-directional zero-knowledge attestation systems and methods
FR2971599A1 (fr) Procede de transaction securisee a partir d'un terminal non securise
EP2614458B1 (fr) Procede d'authentification pour l'acces a un site web
WO2012054016A1 (fr) Procédés et systèmes de génération d'appareils virtuels autorisés
WO2000048355A2 (fr) Procede de verification de l'usage de cles publiques engendrees par un systeme embarque
EP2274701A2 (fr) Systeme et procede de securisation d'un ordinateur comportant un micronoyau
FR2926149A1 (fr) Dispositif, systemes et procede de demarrage securise d'une installation informatique
CN114615087A (zh) 数据共享方法、装置、设备及介质
WO2024253699A1 (fr) Sécurité renforcée par matériel pour maillage de service
FR3106909A1 (fr) Circuit intégré configuré pour réaliser des opérations de chiffrement symétrique avec protection de clé secrète
EP3667530A1 (fr) Accès sécurise à des données chiffrées d'un terminal utilisateur
CA2988357C (fr) Procede de chiffrement, procede de chiffrement, dispositifs et programmes correspondants
EP3994596B1 (fr) Architecture informatique en nuage securisee et procede de securisation
FR3147030A1 (fr) Identification d'une application
EP1506479A2 (fr) Procede pour accomplir des fonctions cryptographiques dans une application informatique
FR3073998B1 (fr) Procede numerique de controle d'acces a un objet, une ressource ou service par un utilisateur
EP3547602A1 (fr) Procédé de mise en oeuvre d'une fonction cryptographique pour une clé secrète
Venkateswaran et al. IoT Security, Data Management and Cloud Integration
EP3948596A1 (fr) Procédé d'exécution de code sécurisé, dispositifs, système et programmes correspondants
Jones AN EMPIRICAL CRYPTOGRAPHY ALGORITHM FOR CLOUD SECURITY BASED ON HASH ENCRYPTION
EP2075733A1 (fr) Dispositif et un procédé de protection contre la rétro conception

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

17P Request for examination filed

Effective date: 20110128

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): 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 SE SI SK SM TR

AX Request for extension of the european patent

Extension state: AL BA RS

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

DAX Request for extension of the european patent (deleted)
18D Application deemed to be withdrawn

Effective date: 20110525