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 Ev _dθ 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 Ev _dθbu t, 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é Evf _in .

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 Ev _dθ 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 S ₂ chiffré. Un message MS ₂ résultant de ce script S ₂ 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 EvS ₂ va être transmis au logiciel qui va sélectionner un script S ₃ 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 Evf _in .

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 MP ₁ , MP ₂ , MP ₃ 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.