FR3118223A1 - Methode d’association d’un programme logiciel executable avec une plateforme informatique - Google Patents
Methode d’association d’un programme logiciel executable avec une plateforme informatique Download PDFInfo
- Publication number
- FR3118223A1 FR3118223A1 FR2013520A FR2013520A FR3118223A1 FR 3118223 A1 FR3118223 A1 FR 3118223A1 FR 2013520 A FR2013520 A FR 2013520A FR 2013520 A FR2013520 A FR 2013520A FR 3118223 A1 FR3118223 A1 FR 3118223A1
- Authority
- FR
- France
- Prior art keywords
- software program
- execution
- program
- key
- modified
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 70
- 230000004048 modification Effects 0.000 claims abstract description 21
- 238000012986 modification Methods 0.000 claims abstract description 20
- 230000006870 function Effects 0.000 claims description 40
- 238000012546 transfer Methods 0.000 claims description 24
- 238000012360 testing method Methods 0.000 claims description 16
- 238000012795 verification Methods 0.000 claims description 12
- 238000004891 communication Methods 0.000 claims description 7
- 238000003780 insertion Methods 0.000 claims description 4
- 230000037431 insertion Effects 0.000 claims description 4
- 238000013518 transcription Methods 0.000 claims description 2
- 230000035897 transcription Effects 0.000 claims description 2
- 230000004913 activation Effects 0.000 description 15
- 238000004590 computer program Methods 0.000 description 10
- 238000004458 analytical method Methods 0.000 description 9
- 238000013175 transesophageal echocardiography Methods 0.000 description 7
- 230000004224 protection Effects 0.000 description 6
- 238000010200 validation analysis Methods 0.000 description 6
- 238000004364 calculation method Methods 0.000 description 5
- 238000013461 design Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 238000011144 upstream manufacturing Methods 0.000 description 4
- 230000004069 differentiation Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000010367 cloning Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
- G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Storage Device Security (AREA)
Abstract
METHODE D’ASSOCIATION D’UN PROGRAMME LOGICIEL EXECUTABLE AVEC UNE PLATEFORME INFORMATIQUE L’invention concerne une méthode d’association d’un programme logiciel exécutable avec une plateforme informatique. La méthode selon l’invention comprend les étapes suivantes : on fournit un programme logiciel initial, la plateforme informatique dans laquelle le programme logiciel exécutable s’exécute, ladite plateforme informatique comprenant un environnement d’exécution de confiance, des moyens de génération d’une clé d’association du programme logiciel avec la plateforme informatique, des moyens de modification du programme logiciel initial ; les moyens de génération de la clé d’association génèrent la clé d’association ; la clé d’association est transmise dans l’environnement d’exécution de confiance ; les moyens de modification du programme logiciel initial modifient le programme logiciel initial en utilisant la clé d’association ; et on obtient un programme logiciel modifié ; on exécute le programme logiciel modifié ; un composant au moins dudit programme logiciel modifié ou fourni de manière séparée s’exécute dans l’environnement d’exécution de confiance et nécessite, pour son exécution, la clé d’association. Figure de l’abrégé : Fig. 1A
Description
DOMAINE DE L’INVENTION
La présente invention concerne une méthode d’association d’un programme logiciel exécutable à une plateforme informatique exécutant ledit programme. Cette association réalise un attachement du programme logiciel à la plateforme informatique sur lequel il s’exécute. Cette association – ou attachement – autorise l’exécution du programme logiciel uniquement sur la plateforme à laquelle il est associé/attaché, et non pas sur d’autres plateformes, par exemple des plateformes similaires ou identiques.
Elle concerne, en particulier, une méthode générique de modification d’un programme logiciel, contraignant son exécution dans un environnement d’exécution unique. Une fois l’association réalisée, la méthode contrôle de manière précise l’exécution du programme logiciel localisé sur sa plateforme informatique identifiée.
La méthode selon l’invention vise à restreindre la dissémination de programmes logiciels pour une utilisation sans droit ou pour leur utilisation à l’extérieur d’un périmètre de confiance défini par son exploitant. Elle permet de récupérer, à distance, une identification de la machine qui exécute le logiciel, notamment au cours de l’exécution de ce programme logiciel.
La méthode permet d’interdire ou de stopper à distance l’exécution d’une instance unique du programme logiciel associée à une plateforme informatique identifiée de manière unitaire pour différents motifs tels que la dépense énergétique, l’expiration des droits d’utilisation concédés par l’exploitant, l’existence de risques associés à l’exploitation du logiciel, des attaques dites « cyber » exploitant l’exécution du programme logiciel.
ART ANTERIEUR
Le besoin de créer un attachement, ou une association, entre un programme logiciel et son environnement d’exécution répond au problème ancien d’éviter le clonage ou une utilisation sans droit dudit programme logiciel. Ce besoin satisfait la nécessité pour un développeur de programmes logiciels de contrôler et de limiter l’exploitation de son programme logiciel pour le maintien des revenus tirés de la vente de licences de ce programme logiciel.
En complément de ce besoin ancien et toujours actuel, de nouveaux défis de sécurité informatique apparaissent. Notamment, dans les déploiements mettant en place une pluralité de nœuds d’exécution d’un logiciel, par exemple dans les réseaux de télécommunication, il est requis de s’assurer qu’un logiciel particulier et identifié unitairement s’exécute sur une plateforme ou une architecture informatique elle-même identifiée de manière unique. Disposant d’une certitude qu’un logiciel unique s’exécute sur une machine identifiée de manière unitaire, on dispose, en complément de cette garantie, d’un contrôle à distance que ce programme logiciel est bien en cours d’exécution d’une part, et, d’autre part, on peut recourir, si il le faut, à sa prise de contrôle. En particulier, ce contrôle à distance ciblé permet de contenir les attaques informatique en réduisant les possibilités de réutilisation de tout ou partie du logiciel, notamment dans le cas de déploiements massifs de ce programme logiciels.
Différentes solutions sont connues de l’art antérieur en vue de réaliser les associations ci-dessus.
Il s’agit tout d’abord de solutions de gestion de droits (Digital Right Management en langue anglaise ou DRM) utilisées couramment dans le domaine du jeu vidéo, destinés aux ordinateurs du type personnels et qui peut s’appliquer à d’autres domaines du logiciel à usage particulier ou professionnel.
Ces solutions dites DRM sont proposées aux éditeurs de programme logiciels de jeux vidéo, qui réalisent l’attachement du programme logiciel de jeu sur la machine du joueur. Cet attachement – ou association – est réalisée par la mise en œuvre du procédé suivant selon lequel on insère, dans le programme logiciel de jeu, possiblement à plusieurs endroits, une routine de vérification des droits. Les instructions de cette routine sont insérées automatiquement dans les instructions du programme de jeu vidéo original. La routine accède à un jeton d’activation et aux données d’identification de la machine. Ces deux données sont requises pour que la routine de vérification de droits valide ou infirme ceux-ci. La validation entraîne la poursuite du jeu. La réception du jeton d’activation nécessite une étape d’activation en ligne comme explicité ci-dessous.
Il s’agit finalement d’une étape d’activation consistant à délivrer un jeton d’activation. Une fois que le programme logiciel de jeu est initialement installé sur la machine, au premier lancement du logiciel de jeu, une étape d’activation de la licence est engagée. Elle consiste en un échange entre la machine du joueur et un serveur distant et comprenant dans le sens montant, à savoir de la machine du joueur au serveur, des éléments d’identification de la machine et le numéro de série du jeu vidéo dont le joueur a été délivré après son achat en ligne. Le serveur d’activation de licence vérifie les droits résiduels associés au numéro de série et, le cas échéant, délivre un jeton d’activation de licence dans le sens descendant, et qui résulte des données d’identification de la machine du joueur.
Lors du déroulement du jeu et à l’atteinte de la routine de vérification de droit, celle-ci vérifie que les données de la machine sont bien associées au jeton d’activation et, selon le résultat du test, autorise la poursuite de l’exécution du jeu, ou alors, interrompt son lancement ou, si le test est réalisé au cours du jeu, interrompt son exécution. Ainsi, le transfert du jeton d’activation sur une autre machine est inutile.
L’attachement du programme logiciel à la machine est relatif en ce sens qu’il s’effectue par une donnée externe, à savoir le jeton d’activation. Chaque jeton est associé à une machine unique. Il y a autant de jetons que de machines différentes mais un seul logiciel de jeu fonctionnant sur toutes les machines. Ce logiciel intègre une routine de vérification de droits qui permet d’avancer dans le jeu.
La routine de vérification nécessite les deux données pour valider les droits d’utilisation : le jeton d’activation, qui doit être présent à un emplacement mémoire connu, et les différentes données d’identification qu’elle récupère à chaque test. Ces données sont récupérées lors de chaque exécution de la routine de validation de droit, au cours du jeu.
On connait les insuffisances de cette méthode. Les données d’identification de la machine résultent de l’exécution d’une instruction binaire dénommée CPUID, qui récupère les données caractérisant les capacités du processeur et d’autres données telles que la partition mémoire du système d’exploitation et/ou la version du système d’exploitation.
L’ensemble de ces données d’identification ne délivre ni unicité ni stabilité. Plus on cherchera à affiner l’identité, plus on prend le risque que certaines données utilisées auront varié entre l’étape d’activation (échange avec le serveur distant) et la vérification de la routine. Aussi, l’identification non unique permet pour des configurations matérielles simples de ne pas permettre de discriminer deux machines. Ce manque de précision sera exploité par l’attaquant.
De manière plus grave, il peut être relativement aisé et de modifier la routine de vérification des droits en contournant les instructions ayant pour objet de collecter les données d’identification de manière à toujours délivrer celles attendues et correspondant à un jeton d’activation préalablement récupéré. Le logiciel modifié, au niveau de sa routine d’activation, est associé avec le jeton utilisé lors de la modification. L’association est utilisable sur toutes les machines et la routine de gestion de droits est inopérante. Il convient de noter que cette méthode consiste à produire la modification à minima aboutissant au résultat, laissant la routine de vérification de droits mais avec une modification de celle-ci afin qu’elle exploite de mauvaises données. Une autre méthode consiste à supprimer cette routine entièrement. Afin de rendre ces opérations délicates à mener, des techniques d’obstruction contre la modification - détectant et bloquant le bon fonctionnement - sont disséminées de manière équitablement répartie, en grand nombre et camouflées. Aucune de ces techniques ne constitue un rempart absolu. Ainsi, l’attaquant favorisera les changements à minima de la routine de gestion des droits, approche qui réduira d’autant son travail de contournement des obstacles à la progression de son travail en en réduisant le nombre. Enfin pour protéger sa routine et renforcer ses défenses, le fournisseur de solution de DRM mettent en œuvre, en complément, des techniques d’offuscation de code, dans le but de rendre l’analyse plus complexe. Cependant, ces techniques ne font que ralentir l’attaquant et élever le niveau d’efforts requis pour atteindre son but.
Il s’agit ensuite d’autres solutions DRM, qui procèdent par attachement à un dispositif externe.
Ces solutions sont des solutions destinées à sécuriser l’exploitation d’applications de type professionnelles, notamment quand elles sont distribuées en grand nombre, et sont distribuées avec des dispositifs matériel livrés aux utilisateurs. Le fonctionnement est simple : le programme logiciel applicatif requiert, dans son fonctionnement, un élément stocké dans ce dispositif matériel. De manière assez commune, la technique consiste à ce que le programme, précisément la section textuelle du programme, est chiffrée dans le fichier. Un module externe au programme installé automatiquement a pour objet de déchiffrer la partie chiffrée du programme à l’aide d’une clé stockée dans le dispositif externe.
Les insuffisances de ces autres solutions sont connues. D’une part, les échanges entre le module et le dispositif externe sont susceptibles d’être espionnés et la clé peut être récupérée. De manière plus grave, on s’aperçoit que dès lors que la partie du programme chiffrée est déchiffrée, le programme est alors chargé en mémoire mais sans attachement à la machine. Un attaquant peut récupérer, par un ou plusieurs vidages de la mémoire (memory dump en langue anglaise), le contenu des pages mémoire correspondant au programme, et reconstituer le programme ne comprenant plus de gestion de droit. Par ailleurs et enfin, il convient de rappeler que l’attachement réalisé n’est pas produit sur l’environnement d’exécution, c’est-à-dire la machine sur laquelle s’exécute le programme, mais sur la présence d’un dispositif externe. Celui-ci est mobile d’une machine à l’autre ce qui confère une transportabilité de la licence. En effet, on achète le droit d’exécuter le programme sur une seule machine sans que cette machine soit identifiée.
Par ailleurs, à noter que les environnements d’exécution de confiance matériel (ou Trusted Execution Environment, en langue anglaise) désignés par TEE par la suite sont des dispositifs associant des modifications de conception sur le processeur et des instructions spécifiques pour les exploiter. Ils sont offerts par les fournisseurs de processeur tels que Intel™, AMD™, ARM™ pour les plus connus, ou des fournisseurs de middleware tels que Trustonic™, Samsung™, Huawei™. Ces derniers apportent une couche logicielle permettant de faciliter l’utilisation des dispositifs matériels des premiers. En mettant en œuvre un chiffrement des pages mémoire contenues dans ces environnement d’exécution, ils apportent une protection supplémentaire : les logiciels et les données qui y résident sont protégés en lecture et écriture de manière certaine. Ces données et leurs traitements réalisés par les logiciels qui y résident exclusivement, restent confidentiels et ne peuvent être modifiés y compris par le système d’exploitation. Même lorsque l’attaquant dispose de tous les droits d’accès sur l’architecture informatique comprenant une TEE, il ne peut accéder au contenu de la TEE.
De manière générale, on considérera par la suite qu’un environnement d’exécution de confiance est une solution matérielle et/ou logicielle permettant d’exécuter du code et d’y placer des données arbitrairement sélectionné par l’utilisateur et délivrant une protection en confidentialité et en intégrité de ces logiciels et données vis-à-vis de tout élément extérieur à ce contenu. A ce jour, les TEE intègrent cette définition en associant des modifications de design matériel au niveau du processeur et des instructions spécifiques pour les activer.
Il convient de noter les éléments techniques suivants caractérisant les TEE notamment dans la perspective d’une exécution d’un logiciel restreinte sur une machine identifiée.
De manière générale, on considérera par la suite qu’un environnement d’exécution de confiance est une solution matérielle et/ou logicielle permettant d’exécuter du logiciel et les données qu’il traite sélectionnés par l’utilisateur et délivrant une protection en confidentialité et en intégrité de ce logiciel et données traitées vis-à-vis de tout élément extérieur à ce périmètre. A ce jour, les TEE intègrent cette définition en associant des modifications de design matériel au niveau du processeur, du microcode installé sur le processeur et des instructions spécifiques utilisateur pour les activer.
Ces dispositifs TEE ne confèrent pas d’identification de l’architecture informatique. Ainsi, toute machine disposant d’un tel TEE peut être l’hôte de l’exécution confidentielle et intègre un logiciel dument préparé à cette fin. Cette indiscernabilité ouin distinguishibilityen anglais est une caractéristique des environnements d’exécution de confiance. Un mécanisme d’attestation à distance permet une vérification à distance de l’intégrité et de l’authenticité de la charge logiciel insérée dans la TEE appeléeTrusted Computing Basis(TCB – Base Informatique de Confiance) et en complément de la réalité physique du TEE. Ce mécanisme d’attestation à distance (Remote Attestation en langue anglaise) ne permet d’identifier l’architecture informatique de manière unitaire. Pourtant, à leur fabrication, ces TEE disposent d’éléments cryptographiques uniques. Cependant, ces éléments cryptographiques ne peuvent sortir des TEE. Ils ne peuvent donc pas servir à la modification nécessaire du programme nécessaire pour créer la dépendance avec ces éléments. La seule façon de pouvoir identifier de manière certaine un TEE, et l’architecture informatique qui la supporte, est d’inoculer par un canal sécurisé une clé d’identification que l’on connait a priori (pour l’avoir générée) et qui est placée et utilisée dans le TEE.
Une autre particularité est que les garanties de sécurité en confidentialité et intégrité du contenu des TEEs ne résolvent pas un des grands problèmes de la sécurité informatique : l’exploitation de vulnérabilités. Le programme inséré dans une TEE, s’il présente des vulnérabilités logicielles, est tout aussi attaquable à l’intérieur d’une TEE qu’à l’extérieur. Pire, une exploitation de vulnérabilité présente dans la TEE sera indétectable ce qui la rend plus critique. La recherche de vulnérabilités sur le programme logiciel pourra favorablement être entreprise avant que le programme logiciel intègre le TEE là où il sera alors protégé en confidentialité et intégrité. Ainsi, il est recommandé, notamment par Intel™, de réduire la taille de la TCB, c’est-à-dire taille de la charge logiciel, au plus strict nécessaire, c’est-à-dire aux seules fonctions de sécurité d’un programme.
D’autre part et, notamment, pour la plus emblématique des TEEs, la technologie SGX™ d’Intel™, interdit les appels au système d’exploitation produits à l’intérieur du TEE. On ne pourra y exécuter l’instruction CPUID permettant l’identification de la machine comme on aurait pu être tenté de le faire. On s’aperçoit donc que la routine de gestion de droit comme décrite précédemment (cas des DRM jeu vidéo) ne peut prendre place in extenso dans un environnement de confiance, notamment du type de l’enclave Intel™ SGX™.
On s’aperçoit que l’utilisation de TEE, notamment avec la technologie SGX™ d’Intel™, nécessite une analyse de sécurité, une définition précise du contenu (partie sécurité détourée et restreinte) et des modifications du programme logiciel au niveau du code source (suppression des appels système). Les différents modes de réalisation de l’invention sont calqués sur cette exigence opérationnelle. Tous nécessitent de disposer d’un module qui s’exécute dans le TEE. On cherchera à détourer au minimum ce contours sur un périmètre que l’on cherchera à rendre constant autant que faire se peut.
Par ailleurs, il convient de noter que les parties du programme, qui sont exécutées dans le TEE d’Intel™, doivent résulter d’une compilation spécifique (mode SGX). Elles donnent lieu à la création d’un fichier spécifique figé qui ne pourra être modifié durant son exécution. En revanche, on peut délivrer, en tant que paramètre ou variable, une donnée à ce programme en provenant de l’extérieur. L’ordre d’exécution précise le programme et la donnée qu’il doit utiliser. On s’aperçoit donc que l’on dispose de flexibilité au niveau des données et d’une totale rigidité au niveau du programme destiné à la TEE. Certains modes de réalisation de l’invention exploitent cette différence, par l’utilisation du principe de l’interprétation de code pour transformer des instructions d’un programme en données et disposer de la flexibilité des données pour exécuter, via l’interprétation, différents programmes dans la TEE.
Par ailleurs, on connait le modèle d’interprétation de code couramment désigné virtualisation. Ce principe consiste à produire une abstraction du programme. Celui-ci est alors transformé en une donnée désignée bytecode qui nécessite un autre programme logiciel constitué de multiples interpréteurs (dont l’ensemble forme une machine virtuelle) capable d’interpréter (c’est-à-dire d’exécuter) le bytecode.
Les dispositifs TEE permettent d’établir des canaux de transmission sécurisé. Ces liaisons permettent notamment d’inoculer dans ces environnements un élément d’identification unique qui sera alors en totale sécurité car non accessible en lecture ou en écriture.
Enfin, Il est à noter le mode d’utilisation dit Protected Control Loader (Chargement contrôle protégé) de la technologie SGX™ d’Intel™ délivre une protection en confidentialité du programme logiciel avant qu’il ne soit chargé dans la TEE (ce qui compliquera la recherche de vulnérabilités et le vol de propriété intellectuelle). Le programme, ou plutôt la partie du programme dument détourée pour intégrer la SGX, est chiffré à l’extérieur et sera déchiffré et exécuté dans une enclave SGX.
Il s’agit enfin de techniques de contrôle d’exécution d’un logiciel à distance.
En effet, on connait des techniques permettant d’interférer à distance avec l’environnement d’exécution d’un logiciel. Ces techniques permettent notamment de mettre l’architecture informatique et son environnement d’exécution à l’arrêt. Dans le cas où l’architecture informatique ou l’environnement d’exécution virtualisé exécute une pluralité de programmes informatiques distincts, cette solution n’offre qu’un contrôle global en traitant tous ces programmes informatiques de la même manière. Notamment, si un arrêt est considéré, tous les programmes informatiques qui s’y trouvent seront arrêtés sans distinction. Par ailleurs, cette solution repose sur une confiance forte dans ce moyen de contrôle et dans le mécanisme d’identification de l’architecture informatique.
Grâce à la technique relevant de la conception et du développement du programme logiciel, le logiciel peut être conçu pour son contrôle à distance. Cette technique ne permet pas a priori d’identifier de manière certaine l’instance du programme informatique dans une pluralité de déploiements de ce programme informatique. Par ailleurs, cette technique n’est pas applicable sur un programme logiciel exécutable dans son état de fichier binaire prêt au déploiement.
Il existe la technique de modification d’un programme exécutable en vue de son contrôle à distance. Cette technique consiste à ajouter une ou plusieurs routines de contrôle d’exécution communiquant avec un système de contrôle distant. Cette technique peut être associée à un moyen de délivrance d’une identification de l’architecture informatique. Cette identification repose sur une technique d’identification similaire à celle utilisée dans le domaine du jeu vidéo PC (Personal Computer, Ordinateur Personnel), reposant sur l’identifiant du processeur CPUID ou tout autre information pertinente (adresse IP, coordonnées GPS, …). De la même manière que pour la technique d’identification du jeu vidéo, l’identification de l’architecture informatique ne peut être certaine.
Les deux dernières techniques ne permettent pas de parer aux techniques de contournement mettant en œuvre une analyse inverse puis modification des modules de contrôle d’exécution. Une inversion de la valeur des tests est toujours possible (avant le prochain test d’intégrité de ces modules s’il est planifié) quand le module se situe dans l’environnement normal d’exécution.
Considérant ce qui précède, un problème que se propose de résoudre l’invention est de fournir principalement une méthode d’association forte entre un programme logiciel et sa plateforme, à savoir machine identifiée de manière certaine et unique. La solution envisagée combine un procédé d’identification certaine et unitairement d’une machine d’exécution et la création d’une dépendance aussi élevée que possible entre le programme logiciel et cette machine identifiée unitairement.
La solution utilise le concept d’exécution de confiance ainsi que la génération d’une pluralité de versions différentes du logiciel. En complément, la présente invention offre la possibilité de mettre en œuvre un contrôle distant et ciblé de l’exécution du programme logiciel.
La solution proposée de l’invention à ce problème posé a pour objet une méthode d’association d’un programme logiciel exécutable avec une plateforme informatique comprenant des étapes suivantes :
on fournit un programme logiciel initial ;
on fournit la plateforme informatique dans laquelle le programme logiciel exécutable s’exécute, ladite plateforme informatique comprenant un environnement d’exécution de confiance ;
on fournit des moyens de génération d’une clé d’association du programme logiciel avec la plateforme informatique ;
on fournit des moyens de modification du programme logiciel initial ;
les moyens de génération de la clé d’association génèrent la clé d’association ;
la clé d’association, ou une clé dérivée de ladite clé d’association, est transmise dans l’environnement d’exécution de confiance ;
les moyens de modification du programme logiciel initial modifient le programme logiciel initial en utilisant la clé d’association, ou la clé dérivée de ladite clé d’association, et on obtient un programme logiciel modifié ;
on exécute le programme logiciel modifié dans la plateforme informatique ;
un composant au moins dudit programme logiciel modifié ou fourni de manière séparée s’exécute dans l’environnement d’exécution de confiance et nécessite, pour son exécution, la clé d’association contenue dans cet environnement d’exécution de confiance.
De manière avantageuse : - le composant est un composant au moins du programme logiciel modifié ; - on modifie le programme logiciel initial en chiffrant au moins partiellement ledit programme logiciel initial et en greffant, audit programme logiciel initial une routine de chargement d’un module de déchiffrement du programme logiciel initial au moins partiellement chiffré, ladite routine s’exécutant au début de l’exécution du programme logiciel modifié, le module de déchiffrement étant disposé dans l’environnement d’exécution de confiance, et utilisant la clé d’association pour la réalisation du déchiffrement ; au lancement de l’exécution du programme logiciel modifié, la routine de chargement, par un appel au module de déchiffrement, transfère un flux d’exécution au module de déchiffrement et lui délivre un contenu chiffré du programme logiciel initial ; le module de déchiffrement déchiffre ledit contenu et le renvoie à la routine de chargement qui installe des instructions en clair du programme logiciel initial en mémoire et transfère le flux d’exécution sur une première instruction ; - le programme logiciel n’est pas chiffré dans son intégralité mais sur des parties dudit programme logiciel ; et le programme logiciel modifié comprend, pour chaque partie chiffrée, une routine de chargement qui, au cours de l’exécution du programme logiciel modifié, par un appel au module de déchiffrement, transfère le flux d’exécution au module de déchiffrement, en lui délivrant un contenu de la partie chiffrée ; - on modifie le programme logiciel initial en interceptant des sauts ou des branchements dans ledit programme ou des fonctions de ses dépendances externes, et pointant vers des composants identifiés par leur adresse ou leur nom, par un branchement ou appel au module de branchement qui se trouve dans l’environnement d’exécution de confiance et qui nécessite la clé d’association pour retourner des adresses et/ou des noms de fonctions tels qu’ils apparaissent dans le programme logiciel initial ; - on modifie des fonctions, composants, instructions et/ou blocs d’instructions du programme initial par une transcription de ces éléments en bytecode et présents dans le programme logiciel modifié dans un état chiffré ; on fournit une routine de transfert située avant chacun des éléments modifiés et on fournit un module d’interprétation de bytecode logé dans l’environnement d’exécution de confiance et qui nécessite la clé d’association pour déchiffrer les bytecodes puis les interpréter ; lors de l’exécution du programme modifié, à l’atteinte d’un composant modifié, la routine de transfert délivre au module d’interprétation le bytecode chiffré ; et le module d’interprétation déchiffre le bytecode, l’interprète et délivre un résultat en retour au module de transfert qui transfère alors l’exécution à une première instruction du prochain composant du programme initial non modifié ; - on modifie des fonctions, composants, instructions et/ou blocs d’instructions du programme initial par au moins une insertion d’une routine de test de présence de la clé d’association et des modifications pour faire en sorte que ces fonctions, composants, instructions et/ou bloc d’instructions s’exécutent dans l’environnement d’exécution de confiance ; à l’exécution du programme logiciel modifié, à l’atteinte d’un composant, instruction et/ou bloc d’instructions modifié, l’exécution du programme bascule dans l’environnement d’exécution de confiance et comprenant au moins un test de présence de la clé d’association pour ou durant son exécution ou l’envoi d’un message d’erreur ou d’arrêt du programme ; - on ajoute dans un composant logiciel qui s’exécute dans l’environnement d’exécution de confiance une routine de contrôle d’exécution communiquant avec un système de gestion-contrôle centralisé distant ; la routine de contrôle émet des preuves d’exécution marquées par la clé d’association, ou par une clé dérivée de ladite clé d’association, permettant ainsi de délivrer une preuve d’exécution identifiant de manière unique l’association logiciel-plateforme informatique et reçoit des messages de maintien ou d’arrêt d’exécution, destinés à une ou plusieurs plateformes informatiques par une ou plusieurs clés d’association ou clés dérivées ; par rapprochement avec sa propre clé ou clé dérivée, le module d’exécution exécute le message de maintien ou d’arrêt d’exécution ou l’ignore ; - des communications montantes et descendantes entre le système de gestion-contrôle centralisé distant et la plateforme informatique sont rendus inintelligibles à des instances tierces ; - la plateforme informatique comprend un serveur de génération de clés d’association et/ou un serveur d’association modifiant le programme logiciel initial et/ou un système de gestion-contrôle centralisé, lesdits serveurs ou système étant formés de programmes logiciels exécutés sur ladite plateforme informatique et potentiellement en tant que modules du système d’exploitation de la plateforme ; - la plateforme informatique comprend un serveur de génération de clés d’association et/ou un serveur d’association modifiant le programme logiciel initial et/ou un système de gestion-contrôle centralisé, lesdits serveurs ou système étant formés de programmes logiciels qui s’exécutent dans des environnements de confiance et potentiellement en tant que modules du système d’exploitation de la plateforme ; - les programmes logiciels sont des modules du système d’exploitation de la plateforme informatique, potentiellement chiffrés préalablement à leur chargement dans l’environnement d’exécution de confiance ; - le transfert du programme initial exploite un canal de communication sécurisé à destination de l’environnement de confiance ; - le serveur d’association produit une signature associée aux données transférées au module situé dans l’environnement de confiance lors de l’exécution, cette signature permettant de filtrer par une vérification préalable de l’authenticité de ces données et donc des demandes d’exécution au module.
BREVE DESCRIPTION DES FIGURES
L'invention sera mieux comprise à la lecture de la description non limitative qui suit, rédigée au regard des dessins annexés, dans lesquels :
DESCRIPTION DETAILLEE DE L’INVENTION
La méthode de l’invention est mise en œuvre par ordinateurs. La illustre son principe général. La illustre ce même principe, au niveau pratique.
Selon l’invention, on fournit une plateforme informatique. Cette plateforme informatique est aussi désignée, dans la présente demande, par architecture informatique ou machine d’exécution. La plateforme informatique est une plateforme disposant d’un ou plusieurs serveurs disposant de différentes ressources physiques et, notamment, d’un ou plusieurs processeurs, ainsi que des mémoire vive associées, un ou plusieurs espaces mémoire de stockage par exemple de type Flash ou de disque dur, d’un ou plusieurs environnement d’exécution de confiance, le tout étant géré par un système d’exploitation.
La plateforme informatique est potentiellement située en environnement hostile et équipée d’un environnement d’exécution de confiance ou environnement d’exécution sécurisé.
Selon l’invention, on établit un canal de communication sécurisé entre la machine d’exécution et un serveur de clés. Par ce canal, on inocule, dans l’environnement d’exécution sécurisé, une clé utilisée pour produire une dépendance d’un programme logiciel modifié par un serveur d’association.
L’environnement d’exécution sécurisé est un environnement de nature matérielle et/ou logicielle. Avantageusement, il s’agit d’un environnement matériel (TEE).
Grâce à ces opérations, le programme logiciel ne peut pas s’exécuter et ce, compte tenu de la dépendance crée uniquement sur la machine d’exécution détenant la clé d’association. En effet, la clé inoculée sur la machine d’exécution et située dans l’environnement de confiance, ne peut être ni lue ni copiée pour être placée sur une autre architecture informatique.
Dans l’architecture informatique, le serveur de clé est situé dans un environnement non hostile. Il fournit un programme logiciel de génération de clés d’identification.
Dans l’architecture informatique, le serveur d’association est situé dans un environnement non hostile. On fournit un logiciel d’association de programmes binaires avec un environnement d’exécution. On établit un lien avec l’architecture informatique serveur de clés pour la récupération de clés utilisées pour les associations. On fournit un programme logiciel initial. On modifie ce programme logiciel par le serveur d’association. Celui-ci utilise une des clés fournies par le serveur de clés pour créer une dépendance avec cette clé pour l’exécution de ce programme modifié.
En pratique, le serveur d’association et le serveur de clés d’association peuvent être deux programmes informatiques exécutés sur la même architecture informatique. Les deux fonctions de modification des programmes logiciels informatiques et de génération de clés peuvent aussi être deux fonctions d’un même programme logiciel. Possiblement, ces deux programmes peuvent s’exécuter directement dans un TEE, ce qui permet de déployer ces éléments en zone hostile. Ces deux fonctions peuvent aussi devenir des modules offerts directement par le système d’exploitation de la plateforme.
La création de cette dépendance avec une clé engendre la génération d’autant de versions différentes de programmes informatiques issues du programme logiciel initial qu’il existe de clés d’association différentes et donc de déploiements différents pour ce programme logiciel. Chaque version créée est différente et nécessite une clé d’association unique pour s’exécuter.
Les programmes logiciels initiaux sont destinés à fonctionner sur de multiples plateformes logicielles, par exemple de multiples ordinateurs personnels, stations de travail, serveurs, consoles de jeu, boîtiers informatiques divers, téléphones mobiles. Ces logiciels initiaux sont généralement les mêmes. Toutefois, la clé d’association est unique. Le programme modifié en utilisant la clé d’association est unique. L’association elle-même entre le programme logiciel et la plateforme informatique est donc unique.
De manière avantageuse, la dépendance du programme logiciel à la clé doit persister durant l’intégralité de son exécution par opposition à une dépendance éphémère telle que par exemple survenant uniquement dans la phase de démarrage du programme.
Un premier mode de réalisation consiste à ce que le programme soit chiffré et que son déchiffrement soit réalisé dans l’environnement d’exécution de confiance par la clé puis, une fois déchiffré, renvoyé dans l’environnement normal d’exécution pour son exécution. Ce mode de réalisation n’engendre qu’une dépendance temporaire à la clé, au seul moment de son déchiffrement. Dès le déchiffrement, le programme installé en clair dans l’environnement d’exécution normal peut être copié et exécuté sur une autre machine. Ceci nécessite, pour l’attaquant, de disposer du contrôle de la mémoire de l’environnement d’exécution. Dans les situations où il est impossible, pour des raisons pratiques, de disposer du contrôle de la mémoire de l’environnement d’exécution par l’attaquant, ce premier mode de réalisation délivre la certitude que le programme, qui n’aura pu être copié une fois déchiffré, s’exécute bien sur une machine identifiée de manière certaine. Dans le cas contraire, par ce premier mode de réalisation, le programme une fois déchiffré pouvant être récupéré et transféré vers une autre machine alors son exécution sur cette machine n’est plus certaine.
Dans un second mode de réalisation, la dépendance du programme logiciel à sa clé peut résulter en une transformation du programme en modifiant les adresses de saut du programme vers ses différents modules ou blocs d’instructions ou vers des dépendances externes de telle sorte que chaque saut pointe, après modification, vers un module de calcul d’adresse inséré dans l’environnement d’exécution sécurisé et qui utilise la clé préalablement inoculée pour ce faire. La dépendance à la clé est maintenue autant qu’il est nécessaire d’effectuer un saut vers un bloc du programme ou une dépendance externe. On peut considérer, d’un point de vue de la sécurité qu’une exécution complète et exhaustive du programme, représentative de tous les cas possibles et donc du passage dans toutes ses branches d’exécution, permet à l’attaquant de récupérer toutes les adresses des sauts par traçage dynamique d’exécution (par l’emploi d’un débogueur) et donc de pouvoir se reconstituer un programme défait de la dépendance au module de calculs d’adresses et de la clé. On notera que pour des raisons de facilité et de lisibilité de la figure, la ne couvre que le transfert de contrôle pour le calcul des adresses des blocs du programme et non pas vers les dépendances externes. Enfin, ce principe s’applique à toutes les instructions de gestion du graphe de contrôle du programme (sauts conditionnels, sauts inconditionnels, appels de routine ou fonction, retour, …).
Dans un troisième mode de réalisation, on peut réaliser des extractions d’instructions en vue de les placer de manière chiffrée dans l’environnement d’exécution sécurisé. Pour ce faire, on utilise un interpréteur de code dans le TEE et on transfère vers la TEE une donnée correspondant au bytecode des parties extraites et qui auront été chiffrées avec la clé d’association. Afin d’être exécutées, cette structure de données (le bytecode) nécessite la clé pour son déchiffrement puis exécution par le biais de l’interpréteur. La dépendance à la clé perdure tant que des instructions à venir du programme auront été ainsi transformées en bytecode puis transférées dans l’environnement le TEE. Du point de vue de la sécurité, la reconstruction du programme initial n’est jamais possible de manière certaine car les instructions extraites préalablement transformées en bytecode et chiffrées ne sont décodées qu’au sein de l’environnement d’exécution de confiance, à l’abri de tout accès extérieur.
Dans un quatrième mode de réalisation, on produit une analyse statique du code pour y extraire certaines fonctions propices à une exécution dans la TEE (c’est-à-dire satisfaisant à des critères sur le contenu des traitements réalisés notamment sans appels système tout en disposant d’un caractère de sécurité). On modifie ces fonctions pour y rajouter une routine prologue en amont de leur exécution vérifiant la présence de la clé d’association. Si le test est concluant, le restant des instructions est exécuté. Si le test est négatif, le prologue dirige le flot d’exécution vers l’épilogue de la fonction ou plus simplement vers un arrêt ou la transmission d’un code erreur vers le programme, court-circuitant les traitements de la fonction. Ainsi, seuls les environnements d’exécution disposant de la clé d’association permettent l’exécution confidentielle des fonctions exportées dans la TEE. On remarquera que cette fonction épilogue de contrôle peut aussi être appelée à tout autre moment pertinent dans l’exécution de la fonction ainsi déportée et non pas forcément en amont du flot d’exécution. En complément, pour éviter la récupération du code exécuté dans la TEE (c’est-à-dire des fonctions sélectionnées), on privilégiera l’utilisation du chiffrement de ces fonctions avant leur chargement en TEE (par exemple par l’utilisation du mode PCL d’Intel™ SGX™).
De manière optionnelle et dans tous les modes de réalisation décrits ci-dessus, On pourra toujours greffer en amont des modules exécutés dans l’environnement de confiance un épilogue de filtrage des demandes par une vérification d’authenticité. Celle-ci pourra réalisée avantageusement et par exemple par une signature produite au niveau du serveur d’association. Cette signature est réalisée par un chiffrement asymétrique (utilisation de la clé privée pour le chiffrement) et un hachage de la donnée transférée. A la réception de la demande et de la signature, l’épilogue peut réaliser les opérations de vérification d’authenticité (origine et intégrité) des demandes (et leurs données) avant de les traiter.
Enfin, une fois l’association créée, on peut insérer automatiquement une routine de contrôle dans le module ou les composants insérés dans la TEE. Cette routine pourra par exemple transférer à un système de gestion centralisé distant une preuve d’exécution d’un programme associé marquée de la clé d’association. Ainsi, on remonte vers un système de gestion centralisé la preuve qu’une version unique (modifiée) du logiciel initial, installée sur une plateforme identifiée de manière unique, a bien été exécutée. Par ailleurs, cette routine de contrôle peut aussi servir pour recevoir un ordre d’interrompre l’exécution du programme.
En résumé, l’invention délivre une identification certaine et unitaire d’une architecture informatique, différents modes d’association entre un programme logiciel spécifiquement généré de manière unitaire pour une architecture informatique identifiée de manière unique et un moyen de contrôle ciblé pour l’exécution de ce programme.
L’invention concerne donc une méthode d’association d’un programme logiciel exécutable avec une unique architecture informatique. Cette méthode a pour objet de s’assurer qu’un logiciel (ou une pluralité d’instances de ce programme logiciel) s’exécute sur les seules architectures informatiques préalablement identifiées par une étape de différentiation. Le programme logiciel initial est modifié en vue de créer une dépendance à ces machines. Cette dépendance est basée et matérialisée sur une clé unique d’association ou une clé dérivée de celle-ci et qui sert à la fois à l’identification de la plateforme informatique qu’à la modification du programme logiciel.
L’étape de différentiation consiste à insérer une clé d’association unique (ou une clé dérivée), générée par un serveur de clés d’association et qui est logée à travers un canal de communication sécurisé dans l’environnement d’exécution de confiance TEE. Protégée en lecture et en écriture à cet endroit, cette clé est l’élément qui permettra la différentiation de l’architecture informatique.
Un programme logiciel initial est modifié pour son association par des moyens procédant de techniques associant le chiffrement, le déroutage du contrôle de flux d’exécution dans un module situé dans l’environnement de confiance, l’interprétation de code, la réécriture de séquences d’instructions pour leur exécution dans un environnement d’exécution de confiance, l’insertion de routine de vérification de présence de la clé d’association, l’insertion de routine de contrôle d’exécution.
De manière générale, la méthode selon l’invention comprend les étapes suivantes selon lesquelles : - on fournit un programme logiciel initial, des moyens d’association dudit programme logiciel et des moyens délivrant une clé d’association. - on effectue une analyse statique du programme logiciel initial, ladite analyse statique comprenant une identification de composants dudit programme logiciel ; - on modifie le programme logiciel initial en vue d’obtenir un programme logiciel modifié et unique, dépendant d’une clé d’association (ou une clé dérivée) pour la bonne exécution de ses composants. Cette modification engendre à la fois des modifications sur le logiciel s’exécutant dans l’environnement normal et la création de composants logiciels s’effectuant dans l’environnement d’exécution de confiance où se situe la clé d’association. Cette même clé d’association (ou une clé dérivée) est inoculée dans l’environnement de confiance de la plateforme informatique. Ainsi et à cet endroit, la clé ne peut pas être extraite, lue ou modifiée. Générée de manière unique, elle permet aussi d’identifier de manière unique les plateformes informatiques.
Lors de l’exécution du programme modifié, le ou les composants placés dans l’environnement d’exécution de confiance, ont accès à la clé nécessaire pour leur bon fonctionnement. Ces composants peuvent dans certains cas avoir été préalablement installés dans l’environnement de confiance, ne constituant pas de facto une partie du programme modifié.
La méthode permet de disposer soit d’une pluralité de plateformes informatiques disposant de la même clé d’association (ou d’une clé dérivée) de manière à ce que différentes instances de ce programme logiciel puissent s’exécuter sur une pluralité de plateformes informatiques. Dans ce cas, une seule version du programme logiciel modifié et associé à une clé est créée pour un déploiement sur plusieurs machines.
La méthode permet aussi de ne disposer de la clé d’association (ou une clé dérivée) que dans une seule plateforme informatique. Dans ce cas, la méthode génère autant de versions du programme logiciel modifié, chacune associée à une clé d’association différente, qu’il existe de plateformes informatiques pour l’exécution de ce programme logiciel.
Ainsi, la méthode selon l’invention met en œuvre à la fois un procédé d’unification (si l’exécution du logiciel est contenue à une seule plateforme informatique) ou de validation (si l’exécution du logiciel est réalisée par un ensemble de plateformes informatiques) basée sur les environnements de confiance et un procédé de modification des programmes informatiques pour créer une dépendance fonctionnelle à l’élément qui sert à cette identification ou validation, la clé d’association (ou une clé dérivée). Les deux étapes (identification-validation des plateformes informatiques et modification du programme informatique) requièrent toutes deux la clé d’association ou une clé dérivée. Pour simplifier, on produit une version du programme spécifique qui nécessite une clé pour son fonctionnement et qui est cachée dans un environnement d’exécution de confiance. Si cette clé n’a été livrée que dans une seule plateforme (et dans son environnement de confiance) alors cette version du programme ne peut s’exécuter que sur cette seule machine. On peut par la suite prendre le contrôle sur cette version du programme de manière ciblée unitairement.
Un premier mode de réalisation, décrit dans la , consiste à chiffrer la section texte d’un fichier de programme logiciel exécutable. Cette partie contient les différentes instructions logiciel en langage assembleur et qui seront chargées par le processeur, au moment venu, dans des pages mémoires réservées à l’exécution de programme. De manière certaine, le processeur est incapable d’exécuter ce programme dans cet état. Le déchiffrement préalable de la structure de données correspondant à la section texte chiffrée est une étape incontournable avant de lancer le programme logiciel. Le chiffrement utilisé durant la modification du programme sera relié d’une manière ou d’une autre et quel que soit le type de clé utilisée (symétrique, asymétrique) relié à cette clé d’association ou une clé dérivée. On pourra par exemple chiffrer la section texte avec une clé privée d’une paire de clés asymétrique et utiliser la clé publique pour son déchiffrement ou de la même manière, on pourra utiliser la même clé symétrique dans les étapes de chiffrement et déchiffrement du programme logiciel. Quelle que soit la méthode de chiffrement (symétrique ou asymétrique), on utilisera la clé adéquate correspondant au chiffrement lors de la modification du programme pour son association et la clé adéquate (symétrique ou asymétrique) dans l’environnement d’exécution de confiance de la plateforme d’exécution. Dans ce mode de réalisation, il est à noter que le programme modifié et exécuté dans l’environnement normal peut être assimilé à un chargeur de programme. Ce chargeur va transférer sa charge (la structure de donnée chiffrée) et un ordre d’exécution à la partie du programme modifié et placée dans l’environnement d’exécution de confiance. Cette fonction ne produit qu’un déchiffrement de la structure de donnée par utilisation d’une clé dument positionnée dans ce même environnement d’exécution de confiance. Une fois le déchiffrement réalisé, le résultat est transmis au chargeur qui pourra alors charger en mémoire les instructions déchiffrées et lancer l’exécution du programme dans l’environnement normal. Par la suite, l’exécution du logiciel ne nécessite plus la clé. Une alternative à ce déchiffrement en un seul bloc et de travailler par bloc d’instructions, sous-fonction ou fonction du programme logiciel. La même méthode s’applique avec une multiplication du module de chargement qui devra être greffé juste en amont de chacun des composants considérés (fonction, blocs d’instructions, séquence d’instructions). Dans ce premier mode de réalisation, la modification du programme consiste à insérer le ou les chargeurs en bonne place, à créer le module de déchiffrement utilisant la clé d’association et le placer dans une « enclave » c’est-à-dire un composant logiciel dument compilé, dédié et automatiquement chargé dans l’environnement de confiance puis enfin à créer le lien entre le ou les chargeurs et le module de déchiffrement. Cette technique permet de réduire le logiciel dans l’environnement d’exécution de confiance à un au seul module de déchiffrement, identique pour tous les programmes à protéger, réduisant ainsi la complexité associée à l’utilisation des environnements d’exécution de confiance. Le logiciel une fois modifié est constitué du programme initial résiduel qui n’est pas chiffré, du ou des chargeurs localisés en bonne place et du module de déchiffrement constituant une enclave. Ce module peut aussi être installé préalablement à l’environnement de confiance et ne pas faire partie du logiciel modifié.
Un deuxième mode de réalisation exploite une technique de déviation du flux de contrôle du programme. La présente une partie de programme composée de trois blocs d’instructions et de deux sauts (dont on perçoit les adresses de destination des sauts en bas des blocs des deux blocs supérieurs). La illustre le fonctionnement général de cette technique. Le contournement de la gestion du flux de contrôle consiste à modifier ces adresses en l’adresse d’un module situé dans l’environnement d’exécution de confiance. Chaque saut vers un autre bloc est contourné vers le module qui calcule et retourne les adresses et pour ses calculs, il requiert la clé d’association. Dans ce mode de réalisation, la modification du programme pour son association consiste à la substitution des adresses de saut pour pointer vers l’adresse du module de gestion du flux et la création et la fourniture de ce module de calcul des adresses nécessitant la clé d’association, sa compilation spécifique pour son exécution dans l’environnement d’exécution de confiance. Cette technique permet de réduire le logiciel dans l’environnement d’exécution de confiance à un seul module, identique pour tous les programmes à protéger, réduisant ainsi la complexité associée à l’utilisation des environnements d’exécution de confiance. Le logiciel une fois modifié est constitué du programme logiciel initial auquel on aura extrait toutes les adresses de saut vers des blocs d’instructions internes au programme initial et du module de gestion du flux de contrôle compilé en tant qu’enclave. On notera que pour des raisons de facilité et de lisibilité de la figure, la ne couvre que le transfert de contrôle pour le calcul des adresses des blocs du programme et non pas vers les dépendances externes. Enfin, ce principe de prise de contrôle du flot d’exécution du programme s’applique à toutes les instructions influant sur ce graphe (sauts conditionnels, sauts inconditionnels, appels de routine ou fonction situées dans des dépendances externe, instruction de retour, …). Chacune de ces instructions peuvent donner lieu à un transfert vers le module de prise de contrôle situé en environnement de confiance.
Un troisième mode de réalisation exploite le principe d’interprétation de code. La illustre ce mode de réalisation. La modification du programme consiste à produire une analyse statique du programme logiciel initial, sélectionner certains blocs, fonctions ou composants. Ces composants seront alors transcrits dans une représentation intermédiaire avant d’être compilés pour permettre leur exécution ou interprétation par un ensemble d’interpréteurs de code formant une machine virtuelle ou interpréteur. Ces composants transformés en bytecodes sont désormais des structures de données que l’on peut transférer à l’interpréteur de code placé dans une enclave de l’environnement d’exécution de confiance. Avant leur envoi, ces bytecodes sont dans un état chiffré de telle manière que l’interpréteur nécessite la clé d’association pour les déchiffrer puis les interpréter (c’est-à-dire les exécuter). Dans le partie du programme qui s’exécute dans l’environnement normal, on réalise des greffes placées avant chaque appel de cet interpréteur (et l’envoi du bytecode associé). Cette technique permet de réduire le logiciel dans l’environnement d’exécution de confiance à un seul interpréteur de code, identique pour tous les programmes à protéger, réduisant ainsi la complexité associée à l’utilisation des environnements d’exécution de confiance. Cet interpréteur de code est placé dans une enclave dument créée lors de la modification du programme logiciel. Par ce mode de réalisation, le logiciel modifié consiste en le logiciel résiduel (non transcrit en bytecode), les routines de transfert d’exécution vers les enclaves situées dans le logiciel principal et avant les parties extraites et l’enclave comprenant l’interpréteur de code. On notera que sans le chiffrement et déchiffrement des bytecodes, toutes les plateformes d’exécution disposant d’un environnement d’exécution de confiance pourraient exécuter le logiciel modifié. En revanche, par le chiffrement et déchiffrement par la clé d’association, seules les plateformes détenant la clé peuvent exécuter le programme modifié par l’interprétation de ses composants transformés en bytecode.
Un quatrième mode de réalisation consiste à, d’une part créer et placer des parties qui seront exécutées dans l’environnement d’exécution de confiance pour certains blocs du programme. Ces extractions seront produites à travers d’une part une analyse du caractère sensible de ces parties (en termes de sécurité) et, d’autre part, par analyse de la conformité à certaines contraintes et exclusion de fonctionnement. Le programme logiciel initial est donc modifié pour la création automatique de ces enclaves correspondant à ces parties du programme. Durant la phase de génération de ces enclaves, on produit un prologue ou un module de gestion de l’association qui ne produit un test de présence de la clé d’association (ou une clé dérivée) située dans le même environnement d’exécution de confiance) et selon le résultat de ce test enclenche soit le branchement à la première instruction (ou une instruction dument sélectionnée) soit à la fin du programme en cas d’échec de ce test. Cette méthode est plus complexe à mettre en œuvre car elle nécessite de produire une génération automatique d’enclaves (et leur compilation) correspondant aux différentes composants sélectionnés.
Elle offre une sécurité équivalente à la méthode précédente en ce sens que les parties exécutées ou interprétées (pour le troisième mode de réalisation) dans l’environnement d’exécution de confiance ne seront jamais récupérables pour l’attaquant. Le logiciel une fois modifié est constitué du programme logiciel, des séquences d’instructions appelant les enclaves et des enclaves elles même. On notera que sans le greffage des tests de présence de la clé d’association dans les composants enclavés, toutes les plateformes d’exécution disposant d’un environnement d’exécution de confiance pourraient exécuter le logiciel modifié.
On notera que ces modes de réalisation ne sont pas exclusifs. Un assemblage dit « en poupées russes » présentant des protections empilées l’une sur l’autre est possible. A titre d’exemple, le premier mode de protection peut être mis en œuvre sur le programme modifié correspondant au second mode de réalisation. Ainsi en complément de l’interception du contrôle de flux d’exécution produit par le second mode de réalisation, le logiciel modifié est chiffré de manière complémentaire.
On notera que le mode de chiffrement équivalent ou égal au mode PCL d’Intel peut être appliqué dans tous les cas pour protéger tous les composants logiciels tels que définis dans les différents modes de réalisation et qui sont destinés à être exécutés dans la TEE de manière à protéger ces composants logiciels quand ces composants logiciel résident à l’extérieur (avant leur chargement dans l’environnement d’exécution).
Pour tous ces modes de réalisation, le programme logiciel modifié comprend au moins un module situé dans l’environnement d’exécution de confiance. Ce module est produit et fourni par le serveur d’association. Son rôle d’association avec la clé d’association (ou une clé dérivée) peut être enrichi par une fonction supplémentaire assurant la génération de preuves d’exécution ou le contrôle d’exécution à distance. Situé dans le TEE, ce module peut recevoir ou émettre en toute discrétion des messages inintelligibles avec un système de pilotage et contrôle distant. On peut notamment recourir aux techniques de chiffrement et d’unicité de ces signaux pour éviter l’interception, l’exploitation pour le contournement de leur contenu et la réutilisation d’un message pour leurrer le système. On pourra aussi recourir aux techniques remédiant à la rupture du lien de télécommunication. La liaison peut alors fonctionner comme un lien ombilical entre le système de gestion-contrôle centralisé et l’architecture informatique exécutant le programme logiciel. La rupture du lien engendre le perte de réception de message de maintien de l’exécution attendus par le module de contrôle d’exécution qui prend alors la décision d’arrêter le programme.
Les particularités du contrôle d’exécution que l’invention se propose d’apporter exploitent deux faits techniques différentiant : - la capacité à identifier une plateformes de manière unique (ou un groupe de plateformes disposant de la même clé) par la clé d’association infalsifiable et confidentielle. Le contrôle est précis et ciblé. Ainsi, les messages circulant dans les deux sens montant sont marqués par cette clé ou une clé dérivée. -l’opacité totale du contrôle pour un attaquant disposant de la plateforme informatique (et de tous les accès et privilèges d’accès sur la mémoire). Le module est situé dans le TEE et réalise en parfaite discrétion et intégrité sa mission, exploitant des messages inintelligibles et que l’on ne peut bloquer (sans bloquer le logiciel dans son fonctionnement).
La solution permet également un mode de réalisation ou tout ou partie des fonctions réalisées environnement non hostile par le serveur de génération de clé et le serveur d’association produisant les modifications sur le logiciel sont directement réalisées au sein de la plateforme informatique déployée en environnement hostile. De manière avantageuse, on s’assurera que ces fonctions intègre l’environnement d’exécution de confiance de la plateforme. De manière avantageuse aussi, on exploitera le canal de communication sécurisé qu’offre les environnements d’exécution de confiance avec l’extérieur pour transférer le logiciel initial directement en environnement de confiance.
Enfin, de manière avantageuse, les fonctions de génération de clé et d’association (par la modification du programme) seront produites et offertes par un module au moins du système d’exploitation de la plateforme informatique.
Claims (14)
- Une méthode d’association d’un programme logiciel exécutable avec une plateforme informatique comprenant des étapes suivantes :
on fournit un programme logiciel initial ;
on fournit la plateforme informatique dans laquelle le programme logiciel exécutable s’exécute, ladite plateforme informatique comprenant un environnement d’exécution de confiance ;
on fournit des moyens de génération d’une clé d’association du programme logiciel avec la plateforme informatique ;
on fournit des moyens de modification du programme logiciel initial ;
les moyens de génération de la clé d’association génèrent la clé d’association ;
la clé d’association, ou une clé dérivée de ladite clé d’association, est transmise dans l’environnement d’exécution de confiance ;
les moyens de modification du programme logiciel initial modifient le programme logiciel initial en utilisant la clé d’association, ou la clé dérivée de ladite clé d’association, et on obtient un programme logiciel modifié ;
on exécute le programme logiciel modifié dans la plateforme informatique ;
un composant au moins dudit programme logiciel modifié ou fourni de manière séparée s’exécute dans l’environnement d’exécution de confiance et nécessite, pour son exécution, la clé d’association contenue dans cet environnement d’exécution de confiance. - La méthode selon la revendication 1, selon laquelle le composant est un composant au moins du programme logiciel modifié.
- La méthode selon l’une des revendications 1 ou 2, selon laquelle :
on modifie le programme logiciel initial en chiffrant au moins partiellement ledit programme logiciel initial et en greffant, audit programme logiciel initial une routine de chargement d’un module de déchiffrement du programme logiciel initial au moins partiellement chiffré, ladite routine s’exécutant au début de l’exécution du programme logiciel modifié, le module de déchiffrement étant disposé dans l’environnement d’exécution de confiance, et utilisant la clé d’association pour la réalisation du déchiffrement ;
au lancement de l’exécution du programme logiciel modifié, la routine de chargement, par un appel au module de déchiffrement, transfère un flux d’exécution au module de déchiffrement et lui délivre un contenu chiffré du programme logiciel initial ;
le module de déchiffrement déchiffre ledit contenu et le renvoie à la routine de chargement qui installe des instructions en clair du programme logiciel initial en mémoire et transfère le flux d’exécution sur une première instruction. - La méthode selon la revendication 3, selon laquelle :
le programme logiciel n’est pas chiffré dans son intégralité mais sur des parties dudit programme logiciel ; et
le programme logiciel modifié comprend, pour chaque partie chiffrée, une routine de chargement qui, au cours de l’exécution du programme logiciel modifié, par un appel au module de déchiffrement, transfère le flux d’exécution au module de déchiffrement, en lui délivrant un contenu de la partie chiffrée. - La méthode selon l’une des revendications précédentes, selon laquelle :
on modifie le programme logiciel initial en interceptant des sauts ou des branchements dans ledit programme ou des fonctions de ses dépendances externes, et pointant vers des composants identifiés par leur adresse ou leur nom, par un branchement ou appel au module de branchement qui se trouve dans l’environnement d’exécution de confiance et qui nécessite la clé d’association pour retourner des adresses et/ou des noms de fonctions tels qu’ils apparaissent dans le programme logiciel initial. - La méthode selon l’une des revendications précédentes, selon laquelle :
on modifie des fonctions, composants, instructions et/ou blocs d’instructions du programme initial par une transcription de ces éléments en bytecode et présents dans le programme logiciel modifié dans un état chiffré ;
on fournit une routine de transfert située avant chacun des éléments modifiés et on fournit un module d’interprétation de bytecode logé dans l’environnement d’exécution de confiance et qui nécessite la clé d’association pour déchiffrer les bytecodes puis les interpréter ;
lors de l’exécution du programme modifié, à l’atteinte d’un composant modifié, la routine de transfert délivre au module d’interprétation le bytecode chiffré ; et
le module d’interprétation déchiffre le bytecode, l’interprète et délivre un résultat en retour au module de transfert qui transfère alors l’exécution à une première instruction du prochain composant du programme initial non modifié. - La méthode selon l’une des revendications précédentes, dans laquelle :
on modifie des fonctions, composants, instructions et/ou blocs d’instructions du programme initial par au moins une insertion d’une routine de test de présence de la clé d’association et des modifications pour faire en sorte que ces fonctions, composants, instructions et/ou bloc d’instructions s’exécutent dans l’environnement d’exécution de confiance ;
à l’exécution du programme logiciel modifié, à l’atteinte d’un composant, instruction et/ou bloc d’instructions modifié, l’exécution du programme bascule dans l’environnement d’exécution de confiance et comprenant au moins un test de présence de la clé d’association pour ou durant son exécution ou l’envoi d’un message d’erreur ou d’arrêt du programme. - La méthode selon l’une des revendications précédentes, selon laquelle :
on ajoute dans un composant logiciel qui s’exécute dans l’environnement d’exécution de confiance une routine de contrôle d’exécution communiquant avec un système de gestion-contrôle centralisé distant ;
la routine de contrôle émet des preuves d’exécution marquées par la clé d’association, ou par une clé dérivée de ladite clé d’association, permettant ainsi de délivrer une preuve d’exécution identifiant de manière unique l’association logiciel-plateforme informatique et reçoit des messages de maintien ou d’arrêt d’exécution, destinés à une ou plusieurs plateformes informatiques par une ou plusieurs clés d’association ou clés dérivées ;
par rapprochement avec sa propre clé ou clé dérivée, le module d’exécution exécute le message de maintien ou d’arrêt d’exécution ou l’ignore. - La méthode selon la revendication 8, selon laquelle des communications montantes et descendantes entre le système de gestion-contrôle centralisé distant et la plateforme informatique sont rendus inintelligibles à des instances tierces.
- La méthode selon l’une des revendications précédentes, selon laquelle :
la plateforme informatique comprend un serveur de génération de clés d’association et/ou un serveur d’association modifiant le programme logiciel initial et/ou un système de gestion-contrôle centralisé, lesdits serveurs ou système étant formés de programmes logiciels exécutés sur ladite plateforme informatique. - La méthode selon l’une des revendications précédentes, selon laquelle :
la plateforme informatique comprend un serveur de génération de clés d’association et/ou un serveur d’association modifiant le programme logiciel initial et/ou un système de gestion-contrôle centralisé, lesdits serveurs ou systèmes étant formés de programmes logiciels qui s’exécutent dans des environnements de confiance. - La méthode selon la revendication 11, selon laquelle les programmes logiciels sont des modules du système d’exploitation de la plateforme informatique, potentiellement chiffrés préalablement à leur chargement dans l’environnement d’exécution de confiance.
- La méthode selon l’une des revendications 11 et 12 selon laquelle, un transfert du programme initial exploite un canal de communication sécurisé à destination de l’environnement de confiance.
- La méthode selon les revendications précédentes selon laquelle un serveur d’association produit une signature associée aux données transférées au module situé dans l’environnement de confiance lors de l’exécution, cette signature permettant de filtrer par une vérification préalable de l’authenticité de ces données et des demandes d’exécution au module.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2013520A FR3118223B1 (fr) | 2020-12-17 | 2020-12-17 | Methode d’association d’un programme logiciel executable avec une plateforme informatique |
| US18/257,913 US20240104194A1 (en) | 2020-12-17 | 2021-12-17 | Method for associating an executable software program with a computing platform |
| PCT/EP2021/086393 WO2022129467A1 (fr) | 2020-12-17 | 2021-12-17 | Methode d'association d'un programme logiciel executable avec une plateforme informatique |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2013520 | 2020-12-17 | ||
| FR2013520A FR3118223B1 (fr) | 2020-12-17 | 2020-12-17 | Methode d’association d’un programme logiciel executable avec une plateforme informatique |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3118223A1 true FR3118223A1 (fr) | 2022-06-24 |
| FR3118223B1 FR3118223B1 (fr) | 2023-11-17 |
Family
ID=75438902
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2013520A Active FR3118223B1 (fr) | 2020-12-17 | 2020-12-17 | Methode d’association d’un programme logiciel executable avec une plateforme informatique |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20240104194A1 (fr) |
| FR (1) | FR3118223B1 (fr) |
| WO (1) | WO2022129467A1 (fr) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3179690A1 (fr) * | 2015-12-11 | 2017-06-14 | Gemalto Sa | Dispositif mobile ayant un environnement d'exécution sécurisé |
| US20170372076A1 (en) * | 2016-06-28 | 2017-12-28 | Intel Corporation | Technologies for provisioning and managing secure launch enclave with platform firmware |
| WO2020182302A1 (fr) * | 2019-03-13 | 2020-09-17 | Huawei Technologies Co., Ltd. | Appareil et procédé de configuration dynamique de contrôle d'accès à une application de confiance |
-
2020
- 2020-12-17 FR FR2013520A patent/FR3118223B1/fr active Active
-
2021
- 2021-12-17 US US18/257,913 patent/US20240104194A1/en active Pending
- 2021-12-17 WO PCT/EP2021/086393 patent/WO2022129467A1/fr active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3179690A1 (fr) * | 2015-12-11 | 2017-06-14 | Gemalto Sa | Dispositif mobile ayant un environnement d'exécution sécurisé |
| US20170372076A1 (en) * | 2016-06-28 | 2017-12-28 | Intel Corporation | Technologies for provisioning and managing secure launch enclave with platform firmware |
| WO2020182302A1 (fr) * | 2019-03-13 | 2020-09-17 | Huawei Technologies Co., Ltd. | Appareil et procédé de configuration dynamique de contrôle d'accès à une application de confiance |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2022129467A1 (fr) | 2022-06-23 |
| FR3118223B1 (fr) | 2023-11-17 |
| US20240104194A1 (en) | 2024-03-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2764462B1 (fr) | Procede de generation, a partir d'un fichier initial de paquetage comportant une application a securiser et un fichier initial de configuration, d'un fichier de paquetage pour la securisation de l'application, produit programme d'ordinateur et dispositif informatique associes | |
| Six | Application Security for the Android Platform: Processes, Permissions, and Other Safeguards | |
| Sood et al. | Targeted cyber attacks: multi-staged attacks driven by exploits and malware | |
| EP3132375B1 (fr) | Systeme d'execution de code avec mecanisme d'hypervision en aveugle | |
| RU2541879C2 (ru) | Механизм против мошенничества на основе доверенного объекта | |
| Bauman et al. | A case for protecting computer games with SGX | |
| Chell et al. | The mobile application hacker's handbook | |
| Haupert et al. | Honey, i shrunk your app security: The state of android app hardening | |
| US20030217280A1 (en) | Software watermarking for anti-tamper protection | |
| WO2022074149A1 (fr) | Methode de regulation du degre de protection d'un programme logiciel | |
| WO2015149828A1 (fr) | Protection d'un élément de logiciel | |
| FR2974207A1 (fr) | Procede et systeme de securisation d'un logiciel | |
| FR3069935A1 (fr) | Dispositifs et procedes de protection de propriete intellectuelle de logiciel pour des plates-formes integrees | |
| WO2022129467A1 (fr) | Methode d'association d'un programme logiciel executable avec une plateforme informatique | |
| Podjarny et al. | Serverless security | |
| US20190199694A1 (en) | Individual encryption of control commands | |
| JP7333704B2 (ja) | 秘密鍵の暗号関数を実装するための方法 | |
| Chau et al. | Why Johnny Can't Make Money With His Contents: Pitfalls of Designing and Implementing Content Delivery Apps | |
| JP6297149B2 (ja) | モバイル機器及び該モバイル機器の動作方法 | |
| EP3214565B1 (fr) | Procédé de modulation d'accès à une ressource, dispositif et programme correspondant | |
| Nolan | Bulletproof Android: practical advice for building secure apps | |
| Pusuluri | Taxonomy Of Security and Privacy Issues in Serverless Computing | |
| KR102326100B1 (ko) | 안전한 안드로이드 앱 생성 및 안드로이드 플랫폼에서의 앱 설치/실행을 위한 시스템 및 방법 | |
| CA3054991A1 (fr) | Procede d'acces a une ressource informatique securisee par une application informatique | |
| Bove | A Large-Scale Study on the Prevalence and Usage of TEE-based Features on Android |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20220624 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |