FR3114890A1 - Methode de regulation du degre de protection d’un programme logiciel - Google Patents
Methode de regulation du degre de protection d’un programme logiciel Download PDFInfo
- Publication number
- FR3114890A1 FR3114890A1 FR2010252A FR2010252A FR3114890A1 FR 3114890 A1 FR3114890 A1 FR 3114890A1 FR 2010252 A FR2010252 A FR 2010252A FR 2010252 A FR2010252 A FR 2010252A FR 3114890 A1 FR3114890 A1 FR 3114890A1
- Authority
- FR
- France
- Prior art keywords
- software program
- protection
- software
- program
- components
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 119
- 230000001105 regulatory effect Effects 0.000 title claims abstract description 11
- 238000004458 analytical method Methods 0.000 claims abstract description 58
- 230000003068 static effect Effects 0.000 claims abstract description 35
- 230000015654 memory Effects 0.000 claims abstract description 34
- 238000012544 monitoring process Methods 0.000 claims abstract description 27
- 230000008569 process Effects 0.000 claims abstract description 6
- 230000004048 modification Effects 0.000 claims description 41
- 230000006870 function Effects 0.000 claims description 38
- 238000012986 modification Methods 0.000 claims description 37
- 239000000523 sample Substances 0.000 claims description 22
- 238000003780 insertion Methods 0.000 claims description 13
- 230000037431 insertion Effects 0.000 claims description 13
- 238000012795 verification Methods 0.000 claims description 9
- 238000012545 processing Methods 0.000 claims description 8
- 238000005204 segregation Methods 0.000 claims description 6
- 238000010801 machine learning Methods 0.000 claims description 4
- 238000012360 testing method Methods 0.000 description 11
- 238000010586 diagram Methods 0.000 description 7
- 238000011084 recovery Methods 0.000 description 6
- 230000002441 reversible effect Effects 0.000 description 6
- 238000009826 distribution Methods 0.000 description 5
- 238000012546 transfer Methods 0.000 description 5
- 238000004364 calculation method Methods 0.000 description 4
- 239000000463 material Substances 0.000 description 4
- 230000002829 reductive effect Effects 0.000 description 4
- 230000006399 behavior Effects 0.000 description 3
- 230000007123 defense Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000002787 reinforcement Effects 0.000 description 3
- 230000009466 transformation Effects 0.000 description 3
- 238000000844 transformation Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000000295 complement effect Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000007717 exclusion Effects 0.000 description 2
- 238000000605 extraction Methods 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 231100000572 poisoning Toxicity 0.000 description 2
- 230000000607 poisoning effect Effects 0.000 description 2
- 230000000135 prohibitive effect Effects 0.000 description 2
- 238000003860 storage Methods 0.000 description 2
- 230000008685 targeting Effects 0.000 description 2
- 230000003936 working memory Effects 0.000 description 2
- 241000287231 Serinus Species 0.000 description 1
- 241000700605 Viruses Species 0.000 description 1
- 230000001944 accentuation Effects 0.000 description 1
- 238000007792 addition Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 230000010485 coping Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000010921 in-depth analysis Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000036961 partial effect Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000000246 remedial effect Effects 0.000 description 1
- 238000005067 remediation Methods 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 230000017105 transposition Effects 0.000 description 1
- 230000003313 weakening effect 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/54—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by adding security routines or objects to programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/12—Protecting executable software
- G06F21/121—Restricting unauthorised execution of programs
- G06F21/125—Restricting unauthorised execution of programs by manipulating the program code, e.g. source code, compiled code, interpreted code, machine code
-
- 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/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/12—Protecting executable software
- G06F21/14—Protecting executable software against software analysis or reverse engineering, e.g. by obfuscation
-
- G—PHYSICS
- G06—COMPUTING; 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2105—Dual mode as a secondary aspect
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)
- Multimedia (AREA)
- Technology Law (AREA)
- Storage Device Security (AREA)
Abstract
METHODE DE REGULATION DU DEGRE DE PROTECTION D’UN PROGRAMME LOGICIEL Une méthode de régulation du degré de protection d’un programme logiciel exécutable dans une architecture informatique comprenant des étapes suivantes selon lesquelles on fournit le programme logiciel, des moyens de protection dudit programme logiciel, et un module de sécurité, ledit module assurant la régulation de la protection dudit programme logiciel ; on effectue une analyse statique du programme logiciel, ladite analyse statique comprenant une identification de composants dudit programme logiciel ; on modifie le programme logiciel afin que le module de sécurité collecte des données de surveillance relatives aux temps ou aux fréquences d’exécution ou à la taille de l’emprunte en mémoire des composants identifiés lors de l’analyse statique du programme logiciel ; on exécute le programme logiciel dans sa version protégé ; le module de sécurité collecte des données de surveillance relatives aux temps ou aux fréquences d’exécution des composants identifiés lors de l’analyse statique du programme logiciel ; et le module de sécurité traite les données collectées et régule dynamiquement le degré de protection du logiciel. Figure pour l’abrégé : Fig. 1A
Description
DOMAINE DE L’INVENTION
La présente invention concerne une méthode de régulation du degré de protection d’un programme logiciel exécutable dans une architecture informatique.
Elle concerne, en particulier, une méthode générique de protection d’un programme logiciel, proposant le déploiement d’une solution de protection dans un environnement d’exécution sécurisé potentiellement placé en zone hostile. La méthode selon l’invention s’applique tant aux techniques de protection visant à contrer les attaques par rétro-conception, les attaques contre la modification de programmes, les attaques visant à contourner les dispositifs de gestion de droit d’utilisation et enfin les attaques exploitant les vulnérabilités logicielles.
ART ANTERIEUR
La protection logicielle couvre différents domaines et offre des réponses techniques pour contrer des menaces très distinctes produites de manière coordonnée ou isolément.
Elle apporte notamment des renforcements ad-hoc des programmes logiciels avant leur déploiement, par des modifications ou des ajouts dans ceux-ci.
Pour une protection contre l’exploitation de vulnérabilités logicielles, une solution de protection peut être directement fournie dans l’environnement hostile, en tant que module installé dans l’environnement d’exécution du logiciel. Lorsqu’une solution est déployée dans l’environnement hostile, elle produit des effets systématiques pour toutes les situations potentiellement critiques, sans exception, mais sans régulation par rapport à une perte de performance des programmes logiciels qu’elle protège.
Dans des modes de réalisation, la solution de protection est fournie avant la compilation des programmes logiciels. Dans d’autres modes de réalisation, la solution de protection est fournie avant que ces programmes soient déployés par une modification du code binaire exécutable du programme.
Dans d’autres modes de réalisation encore, la solution de protection ne se déploie pas dans l’environnement d’exécution hostile des logiciels qu’elle protège. Elle est mise en œuvre à travers un outil logiciel installé soit sur un serveur maintenu dans l’enceinte du fournisseur de solution de protection et qui est mis à la disposition des clients utilisateurs, à distance, par exemple chez le développeur ou l’éditeur du programme logiciel, soit sur un serveur installé directement chez ces clients utilisateurs.
Pour certaines des solutions de protection précitées, la solution de protection met en œuvre des techniques propres, des secrets de fonctionnement ainsi que des éléments cryptographiques. Toutefois, l’exposition de ces éléments dans un milieu hostile facilite le travail des attaquants, voire permet de contourner la solution de protection de manière définitive.
On retiendra que la protection intervient donc avant le déploiement du logiciel protégé et fige un schéma ou un degré de protection basé sur des objectifs de sécurité ciblant l’intégralité ou une partie plus sensible du programme logiciel ainsi que sur le ralentissement de l’exécution de ce programme logiciel que l’on accepte jusqu’à un certain niveau et, nécessairement, induit par la protection du logiciel et, secondairement, sur la consommation mémoire admissible de la protection. Ces objectifs et contraintes sont définis au travers de tests d’exécution du logiciel protégé aussi représentatifs que possible sur les contraintes d’exploitation et une utilisation typique du logiciel.
Cependant, dans la pratique, le déploiement des programmes logiciels est sujet à une grande variété de situations ainsi qu’à une variation dans le temps des objectifs de la protection. La prise en compte de cette variété avant le déploiement est imprécise et conduit à figer la protection de manière conservatrice afin qu’elle satisfasse le déploiement dans les conditions les plus contraignantes.
Quel que soit le type de protection, une équation étroite relie l’efficacité de la protection à son coût en terme de cycles machine et donc de ralentissement du logiciel protégé. Ce coût impacte la vitesse d’exécution du logiciel protégé et ceux situés sur le même environnement et qui partagent les ressources matérielles effectivement disponibles. Au-delà du besoin accru de ressources de traitement par le processeur, certaines techniques auront un impact sur le niveau d’utilisation de la mémoire vive, allouée dynamiquement par le système d’exploitation pour l’exécution du programme. A titre d’exemple, les solutions de remédiation contre les attaques ciblant des vulnérabilités fragilisant l’intégrité de la zone mémoire de travail du programme, dénommée « tas » en français et plus communément connue par le terme anglais « heap » sont connues pour être consommatrices de pages et d’espace mémoire.
L’impact réel sur l’exécution et la consommation de ressources (processeur et mémoire) des logiciels (protégés et non) situés sur la même machine s’apprécie différemment selon la marge disponible sur la machine qui est fonction du nombre de logiciels exécutés de manière concomitante et le niveau de sollicitation et de besoin de ressources de chacun d’eux. Ces deux paramètres varient fortement dans le temps. Ainsi, si l’on doit figer un niveau de protection satisfaisant la situation la plus critique (tous les logiciels sont actifs en même temps et synchronisés pour être tous dans leur phase la plus pesante sur la machine), le budget alloué à la protection sera fixé au plus bas niveau. Ce bas niveau de protection est fixé et figé lors de la pose de la protection et reste constant y compris dans les conditions d’utilisation plus fréquentes (que celle qui a donné lieu à la fixation de ce niveau) qui auraient permis de disposer d’une protection plus élevée. Le niveau de protection est donc non optimal dès lors qu’il est défini a priori avant le déploiement du logiciel.
Rappelant que la protection s’accompagne toujours d’un ralentissement du logiciel et, très souvent, par une augmentation du besoin en mémoire vive, il convient idéalement, pour toutes les protections de logiciel, de permettre son application sur le contour fonctionnel réduit et identifié comme étant le plus exposé à la menace. Selon le degré de connaissance sur le logiciel à protéger par la personne en charge de sa protection, ce contour réduit sera défini de manière plus ou moins précise. Dans tous les cas, et parce que toutes les parties d’un logiciel n’ont pas le même impact sur le besoin en ressources (processeur et mémoire), il convient de disposer, au niveau de la solution de protection, d’une granularité suffisante pour permettre de moduler le degré de protection par composants du logiciel.
Les objectifs de sécurité d’un logiciel peuvent varier dans le temps et l’espace. On peut ainsi considérer par exemple que les conditions de sécurité de l’environnement d’exécution ne justifient pas une forte protection (voire pas de protection du tout) et ce notamment parce que la protection engendre toujours un coût à payer en termes de ressources. A contrario, ce même logiciel déployé dans un environnement plus exposé nécessitera sa protection. L’appréciation de la menace peut aussi varier dans le temps et faire écho à la remontée de signaux ou de nouvelles connaissances acquises (nouveau type d’attaque identifié, accentuation de la menace, …) requalifiant le niveau de la menace. En fonction de ce niveau d’alerte ressenti, on fixera différemment les objectifs de sécurité ce qui en pratique revient à faire varier le niveau de la protection. En particulier, cette remontée d’informations sur l’appréciation de la menace peut cibler telles ou telles parties du logiciel (fonction, méthode, algorithme, gestion d’un paramètre, gestion d’une variable …) de manière différenciée du reste. On pourra donc chercher à durcir davantage par la protection ces parties particulières. Dans l’état de l’art, la modification des objectifs de sécurité engendre un nouveau projet de protection qui implique l’installation d’une nouvelle version du logiciel, ce qui évidemment apporte ses complications opérationnelles ( enregistrement des données et variables du logiciel avant son arrêt, mise à l’arrêt du logiciel, installation de la version nouvellement protégée, nouvelle procédure d’authentification, nouveau lancement de la version nouvellement protégée avec prise en compte des données et variables du logiciel avant son arrêt, …).
On présente ici le domaine d’application de l’invention et les techniques courantes de protection du logiciel, selon les grands types de menace.
Protection contre la
rétro-conception
et l’analyse (sans droit et à des fins malicieuses)
Ici, la protection a trois objectifs distincts : la protection du patrimoine industriel (propriété intellectuelle), se prémunir contre la découverte d’une faille ou vulnérabilité que l’on peut exploiter et enfin dans un contexte de guerre électronique ou cyber, de se prémunir contre l’acquisition d’intelligence sur le fonctionnement d’un système de défense, de transmission ou autre, par un ennemi ou attaquant.
Dans sa recherche de connaissances sur le programme logiciel, l’attaquant a pour but de récupérer la structure générale du programme (ses fonctions, ses variables et structures de données, l’enchaînement de ces routines internes et enfin ses dépendances externes). Avec cet objectif, l’acquisition du graphe de flux de contrôle, aussi précis et complet que possible, est un point de départ, avant de porter une analyse plus poussée sur tel ou tel bloc d’instructions nouvellement identifié et perçu comme important. La récupération du graphe requiert l’emploi simultané de différentes techniques apportant des informations complémentaires. Ce sont l’analyse statique, l’analyse dynamique et l’exécution symbolique.
Différentes techniques de protection sont appliquées dans l’état de l’art. Elles ciblent des conditions précises de réalisation de l’attaque et les objectifs de l’attaquant.
En tout premier lieu, il importe de savoir si l’attaquant dispose du programme logiciel sous la forme de son code source (ce qui facilite grandement la tâche d’analyse) ou sous la forme de sa version compilée en assembleur. De fait, l’analyse est d’autant simplifiée que le programme se trouve dans sa forme abstraite (de la machine cible) c’est-à-dire produite en langage de programmation. Si l’attaquant dispose du code source, il convient de produire une offuscation par des techniques de sur-complexification du code source.
Si l’attaquant dispose du programme dans sa forme exécutable (c’est-à-dire compilée en assembleur de la machine cible ou d’une machine virtuelle des langages interprétés), il convient de savoir si l’attaquant peut disposer d’un environnement d’exécution lui permettant de réaliser une analyse dynamique par l’emploi d’un débogueur. L’analyse dynamique consiste à tracer, au travers de l’exécution du code, chacune des instructions exécutées, ainsi que les modifications engendrées dans la mémoire et les registres de travail du processeur, lorsque ces registres existent. L’outil utilisé pour cette analyse est un débogueur. Le débogueur met en œuvre une instrumentation du programme, qui permet notamment de mettre en place des points d’arrêt dans l’exécution du programme logiciel. Il permet de récupérer la trace de l’exécution du code, c’est-à-dire la séquence des instructions exécutées et les états de la mémoire de travail du processeur associés à chaque instruction.
En pratique, les conditions matérielles permettant l’emploi d’un débogueur par l’attaquant sont relativement accessibles ce qui rend nécessaires les techniques d’offuscation dont le but est de réduire la lisibilité du graphe d’exécution (porteur de la structure du programme, de ses dépendances et l’enchainement de ses propres fonctions) mais aussi de réduire l’intelligibilité des processus et algorithmes contenus dans le blocs d’instructions du programme.
A contrario, si l’attaquant ne dispose pas de cet environnement d’exécution lui permettant de réaliser ce traçage pas à pas, il reste possible de procéder à l’analyse statique du programme logiciel. L’analyse statique consiste à lire et analyser le programme logiciel « à plat », c’est-à-dire à tenter de récupérer de ce programme logiciel dans sa version exécutable, soit la version livrée et disponible pour l’analyste, des blocs intelligibles, et à en faire l’analyse. La lecture est effectuée sans recourir à l’exécution du programme logiciel. Le seul outil nécessaire à l’attaquant est la connaissance du langage du logiciel dans sa forme exécutable. Il peut s’agir de l’assembleur si l’analyse est effectuée sur un exécutable natif, c’est-à-dire correspondant à une machine réelle spécifique par exemple de type Intel™ X86 ou ARM™7, ou d’un bytecode pour un langage interprété correspondant à une machine virtuelle telle que Java™ ou .NET™.
Pour faciliter l’analyse statique, il est possible de produire des transformations dans le programme logiciel dans sa forme exécutable en vue, par exemple, de disposer d’une forme plus abstraite de ce programme logiciel et de se rapprocher du programme dans sa forme en code source. Cela est effectué à l’aide d’un décompilateur ou au travers d’outils d’analyse exploitant et appliquant l’exécution symbolique sur certaines parties du logiciel ou enfin par l’utilisation d’outil à base d’heuristiques pour retrouver des similarités dans les séquences d’instructions, plus ou moins longues et présentant variation plus ou moins grande.
On connaît des méthodes qui permettent de contrer les attaques procédant par analyse statique d’un programme logiciel. Ces méthodes tendent à ce que le programme logiciel ne se trouve jamais « en clair » en mémoire. Le programme (sa section dite « text ») est donc chiffré, comme on chiffrerait une données. Néanmoins, si les techniques de chiffrement interdisent l’analyse statique, le programme sera déchiffré pour son exécution. Le chiffrement de code ne présente donc une défense totale mais sur le fichier stocké du programme et une défense très relative quand le programme est dans son environnement d’exécution. Via l’analyse dynamique, l’attaquant pourra pointer l’état de la mémoire correspondant au fichier déchiffré et le récupérer pour produire une analyse du programme alors « en clair ». Les techniques de chiffrement engendrent naturellement toujours un ralentissement de la phase de démarrage mais ce ralentissement se limite à celle phase uniquement.
On connaît de même des méthodes qui permettent de contrer les attaques procédant par analyse dynamique d’un programme logiciel. Toutefois, quelles que soient ces méthodes, on notera que, dès lors qu’il est possible de disposer sur la machine d’un débogueur, il est impossible d’interdire une telle analyse de manière complète. Les méthodes d’offuscation présentent des objectifs relatifs en ce sens qu’elles permettent de ralentir ou rendre rédhibitoire le niveau d’efforts nécessaire. Certaines méthodes proposent de bloquer l’usage de débogueurs mais elles sont pénalisantes pour les utilisateurs licites et peu efficaces, car contournables. En pratique, pour contrer l’analyse dynamique, il convient de la ralentir suffisamment. On cherchera à que ce la réalisation de l’ingénierie inverse devienne rédhibitoire par un accroissement colossale de la taille du code à tracer et, dans la mesure du possible, sans qu’il soit possible de réduire cette taille par l’utilisation de résultats d’analyse antérieurement acquis. Pour ce faire, les méthodes selon l’art antérieur proposent bien souvent au moins de générer une certaine variabilité dans la génération de ce code.
Les méthodes procédant par offuscation de programmes logiciels permettent de rendre les analyses statiques et dynamiques beaucoup plus complexes. Certaines de ces méthodes proposent d’offusquer le code en produisant des transformations prédéfinies sur celui-ci et en substituant des séquences du code initial avec des séquences plus complexes. D’autres méthodes proposent du chiffrer certains blocs du code exécutable. De telles méthodes procédant par chiffrement partiel nécessitent cependant que le code chiffré soit déchiffré avant exécution. D’autres méthodes de virtualisation de code consistent à transcrire le code original dans une syntaxe non connue de l’attaquant et décodée à la volée par un ensemble d’interpréteurs chargés en mémoire, engendrant par nature une déstructuration totale du graphe, un accroissement massif du nombre d’instructions à tracer par l’attaquant. D’autres méthodes consistent à insérer des prédicats opaques produisant des résultats connus à l’avance en sortie d’une chaîne de traitements longue et complexe. On connait d’autres méthodes consistant à aplatir le graphe d’exécution par une série de transformations aboutissant à une déstructuration forte graphe ou exploitant le principe de la programmation orientée retour (ou saut ou appel) ou à générer un code évoluant à l’exécution. Dans tous les cas, les méthodes d’offuscation engendrent mécaniquement un ralentissement du logiciel, notamment parce que leur objectif est d’étendre le nombre d’instructions exécutées pour une fonction donnée. Si la technologie d’offuscation est bien conçue, elle doit aboutir à un accroissement de l’effort de l’attaquant (pour atteindre une connaissance suffisante du logiciel, toutes choses étant égales par ailleurs) en relation avec le nombre d’instructions insérées.
On connait les méthodes introduites plus récemment et reposant en particulier (mais pas seulement) sur des nouvelles dispositions d’architecture offertes directement sur les nouveaux processeurs. En pratique, ces techniques exploitent le chiffrement appliqué à des pages mémoire réservées pour la partie du logiciel déportée et qui ne sont accessibles à nul autre composant que la partie déportée elle-même. Cette exclusion vaut aussi au système d’exploitation gérant le logiciel. L’attaquant ne pourra jamais accéder à ces pages pour y produire son analyse. Ces dernières techniques sont prometteuses et obtiennent un plus haut niveau de sécurité à coût machine moindre que les techniques d’offuscation. Leur emploi reste relativement confidentiel ou du domaine d’experts de sécurité, notamment parce qu’elles (pour les plus emblématiques d’entre elles : l’enclaveSGXd’Intel™ et laTrustZone ™d’ARM) nécessitent au préalable l’acquisition de connaissances spécifiques pour leur emploi ainsi qu’une modification du code source par l’insertion de nouvelles instructions et une nouvelle compilation. Par ailleurs et surtout, ces techniques n’ont pas fait l’objet d’une standardisation et se distinguent par des approches différentes (et exclusives) et sont non compatibles entre elles, ce qui impose un choix de processeurs pour le déploiement du logiciel protégé à ceux qui les utilisent. Ce dernier facteur est fortement pénalisant.
Protection contre la modification (sans droit et à des fins malicieuses)
La protection a ici pour objectif de détecter les modifications ou entraves la réalisation de ces modifications. Les modifications de l’attaquant ont pour objet de dévier le fonctionnement originel vers un fonctionnement souhaité. De manière emblématique, les routines logicielles de gestion des droits des utilisateurs sont des cibles idéales à la modification. On cherchera à rendre caduque les tests de validité des droits qu’elles effectuent.
On connaît la méthode de chiffrement qui interdit la production de modification sur le fichier chiffré (stocké sur disque ou une unité de stockage). Cependant, ce fichier chiffré sera déchiffré au lancement du logiciel et les modifications seront alors possibles, pour celui qui dispose d’un accès aux pages de la mémoire active du processeur dans lesquelles le logiciel a été chargé avant son exécution.
On connait d’autres techniques consistant à modifier le logiciel par l’insertion automatisée de routines d’auto-vérification, ces routines produisant une lecture à une adresse des pages mémoire du programme logiciel chargé et où un résultat connu a priori est supposé être, parce que correspondant au logiciel original. La densité de ces contrôles, la variabilité dans la séquence d’instructions produites d’un test à l’autre et leur degré d’intégration en profondeur dans le fonctionnement du logiciel sont trois métriques qualifiant l’efficacité de telles solutions. Plus la densité de ces tests est élevée, plus bas sera le taux de faux négatif (le logiciel modifié n’est pas détecté comme tel) mais plus haute sera la perte de performance du logiciel.
On connait la technique de placement du logiciel dans un environnement de confiance, tel que proposé par les fournisseurs de processeurs. La garantie de protection contre la modification est très élevée, notamment pour la plus emblématique de ces technologies, l’enclave SGX d’Intel™.
Enfin, on connait les techniques qui permettent de calculer une valeur de hachage (« hash » en langue anglaise) sur le contenu des pages du programme logiciel une fois chargé et de vérifier, au fil de l’exécution de celui-ci, sa stabilité. Pour éviter les attaques par rejeu, ces techniques mettent en œuvre un challenge variant d’une vérification à l’autre et pour lequel l’attaquant est forcément en défaut de matériel cryptographique. On notera que le résultat de ces techniques tient en un simple booléen ou un bit d’information : le logiciel n’a pas ou a été modifié. Entre deux tests d’authentification, le logiciel peut être modifié puis remis à l’identique par l’attaquant. La fréquence de ces tests et le caractère imprévisible de ces tests sont deux conditions d’efficacité. Ici encore, la fréquence de ces tests va de pair avec la perte de performance globale du logiciel protégé.
Protection contre l’utilisation sans droit
La vérification des droits de l’utilisateur d’un logiciel repose dans la pratique sur l’insertion d’une routine spécifique réalisant les vérifications nécessaires sur différents critères techniques telles que la récupération sur un ordinateur du type personnel, d’un jeton ou les données d’identification de la machine. Cette routine externe doit être aussi difficilement localisable (et présenter une très grande variété dans ses implémentations), être intimement liée au fonctionnement du logiciel et ne pas être simplement court-circuitée (par la modification). La routine de gestion de droits, parce qu’elle est connue a priori en tant que dispositif relativement invariant sous l’analyse de l’attaquant, se doit de disposer du plus fort niveau d’offuscation et de protection contre la modification. Le biais minimum consiste à placer cette routine au niveau du point d’entrée du programme. Cependant, c’est la première zone d’analyse de l’attaquant. Il conviendra de répéter les insertions et donc les tests au fil de l’exécution du logiciel ce qui peut donc avoir lieu n’importe où, forçant l’attaquant à une analyse bien plus longue mais avec l’inconvénient d’une perte de performance du logiciel. Là encore, l’accroissement de la sécurité va de pair avec la perte de performance. Enfin, on connait la technique de placement d’une routine de gestion de droit dans un environnement de confiance. Si la gestion de droit elle-même ne permettra pas de modification, son interface avec le logiciel situé à l’extérieur de l’environnement de confiance est le maillon faible. Le test de droits ne doit pas résulter en une information binaire (les droits sont acquis ou pas de droit) ce qui permet de réaliser les modifications pour inverser ce résultat passé au logiciel lui situé en dehors de l’environnement de confiance. Pour que cette solution soit efficace, il faut là encore faire en sorte de multiplier et de camoufler les utilisations par le logiciel des résultats de ces tests de droits, revenant donc au cas général d’ambivalence entre efficacité et perte de performance.
Protection contre l’exploitation de vulnérabilités
Les vulnérabilités consistent en des erreurs de codage essentiellement concentrées sur une mauvaise définition des réserves mémoire (tampon) pour les variables du programme logiciel, et qui ont, pour la plupart, pour origine, les développement en langage C dont on retrouve des routines sous-jacentes dans d’autres langages de programmation. Ces erreurs de codage n’auraient que peu d’effet si les processeurs actuels ne mélangeaient pas données et adresses d’instructions dans leur pile d’exécution. Par une simple insertion a priori bénigne d’une donnée tronquée, l’attaquant peut déborder du tampon et venir écrire l’adresse de la prochaine instruction à exécuter, là où se trouve un programme logiciel malveillant qui aura été préalablement introduit (virus). D’autres techniques plus élaborées permettent de ne pas recourir à un autre logiciel et d’utiliser des séquences dûment choisies et chaînées dans le programme logiciel original pour dévier le fonctionnement de ce programme. L’exploitation de vulnérabilités est un large domaine techniques regroupant plusieurs fronts (modus operandi des attaques) et remédiations (parades). Dans la grande majorité des cas, l’attaque engendre une déviation sur le flux de contrôle du programme logiciel original, soit en modifiant les adresses de retour des fonctions appelées soit en modifiant les adresses des sauts vers des fonctions (internes ou externes) au logiciel.
On connait les techniques de vérification d’intégrité du graphe de contrôle consistant à insérer des réserves de taille aléatoire pour des fonctions du programme logiciel, soit par un dispositif dit de « tokenization » (attribution de jetons) des adresses de retour, soit par l’insertion de « canaries » ou enfin par l’insertion de routines de vérification des adresses de saut dans une liste d’adresses jugées licites. En dehors de futures techniques matérielles (telle que « shadow stack » (pile cachée) d’Intel™, les techniques purement logicielles sont toujours contraintes par une perte de performance, croissante avec l’efficacité de la mesure. L’intégralité des très nombreuses publications scientifiques portant sur ce sujet exposent toujours la perte de performance (supposée acceptable par les auteurs) pour attester la pertinence des techniques innovantes exposées dans ces publications. La perte de performance se montre dans ce domaine là encore indissociable de l’efficacité. Pourtant là encore, aucune publication ne fait état d’une régulation automatisée des mécanismes reliée à des mesures caractérisant la vitesse d’exécution du programme logiciel protégé. A noter que des publications font état d’un monitoring du logiciel à son exécution pour permettre, selon plusieurs techniques, de détecter une anomalie de fonctionnement reliée potentiellement à une attaque. Le monitoring à l’exécution participe à la détection sans servir de levier pour réguler celle-ci.
La mise en œuvre des méthodes précitées peut être effectuée à différents stades dans la chaîne de génération du programme exécutable et, en particulier, au stade du développement du code source par le développeur, plus particulièrement au stade de sa compilation au moyen d’un compilateur spécifique qui produit l’offuscation et génère les séquences de code offusqué, ou alors, dans un stade plus avancé, où on dispose du programme logiciel lui-même, sous une forme exécutable.
Par ailleurs, la mise en œuvre de ces méthodes peut être effectuée pour des chaines de génération de programmes logiciels natifs, c’est-à-dire résultant d’un code binaire structuré pour un processeur particulier, ou pour une chaine de génération de langage interprété tel que le langage Java™ ou .NET™.
Considérant ce qui précède, un problème que se propose de résoudre l’invention est de fournir une méthode de régulation du degré de protection d’un programme logiciel exécutable dans une architecture informatique, en vue d’ajuster le degré de protection de l’exécution de ce programme logiciel, selon les conditions d’exécution constatées dudit programme, par exemple en vue d’augmenter la vitesse d’exécution de ce programme, dans le cas où cette vitesse n’est pas suffisante ou la réduction de son empreinte en mémoire, dans le contexte dans lequel s’exécute le programme.
La solution proposée de l’invention à ce problème posé a pour objet une méthode de régulation du degré de protection d’un programme logiciel exécutable dans une architecture informatique comprenant des étapes suivantes :
on fournit un programme logiciel initial, des moyens de protection dudit programme logiciel initial, et un module de sécurité, ledit module assurant la régulation de la protection dudit programme logiciel ;
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 pour obtenir un programme logiciel modifié afin que le module de sécurité collecte des données de surveillance relatives aux temps ou aux fréquences d’exécution ou à une empreinte en mémoire vive des composants identifiés lors de l’analyse statique du programme logiciel ;
on exécute le programme logiciel modifié dans l’architecture informatique ;
le module de sécurité collecte des données de surveillance relatives aux temps ou aux fréquences d’exécution ou à l’empreinte mémoire des composants identifiés lors de l’analyse statique du programme logiciel initial, lors de l’exécution du programme logiciel modifié ; et
le module de sécurité traite les données collectées et régule dynamiquement le degré de protection du programme logiciel modifié selon les données de surveillance collectées et traitées, lors de l’exécution dudit programme logiciel modifié.
De manière avantageuse, - le programme logiciel modifié, qui est exécuté dans l’architecture informatique, est un programme logiciel qui est protégé par les moyens de protection préalablement à son exécution ou lors de son exécution, selon un degré de protection donné, et selon laquelle, après traitement des données collectée par le module de sécurité, le degré de protection est modifié dynamiquement par le module de sécurité, selon les données de surveillance collectées et traitées ; - le programme logiciel est modifié par l’insertion, dans ledit programme, de sondes de surveillance, lesdites sondes générant les données de surveillance collectées par le module de sécurité ; - on modifie le programme logiciel en interceptant des sauts ou des branchements dans ledit programme, et pointant vers les composants identifiés par leurs adresses, par un branchement ou appel au module de sécurité ; et lors de l’exécution du programme logiciel, le module de sécurité réalise les branchements ou les sauts aux adresses desdits composants ; - on fournit un environnement de confiance, pour l’exécution sécurisée de programmes logiciels ; on place le module de sécurité dans ledit environnement de confiance ; on extrait des composants identifiés du programme logiciel ; on place lesdits composants dans l’environnement de confiance ; et on exécute des composants non-extraits du programme logiciel hors de l’environnement de confiance et on exécute des composants extraits du programme logiciel dans l’environnement de confiance, sous le contrôle du module de sécurité ; - le module de sécurité régule dynamiquement le degré de protection en faisant varier la fréquence ou les conditions de réalisation de la protection du programme logiciel ; - le programme logiciel modifié comprend une pluralité de composants iso-fonctionnels, ces composants iso-fonctionnels étant protégés selon des degrés de protection différents ou selon leur localisation dans ou en dehors d’un environnement de confiance, et le module de sécurité régule dynamiquement la protection en choisissant d’exécuter un composant iso-fonctionnel plutôt qu’un autre selon son degré de protection ou sa localisation dans ou en dehors d’un environnement de confiance ; - les composants iso-fonctionnels protégés selon des degrés de protection différents ou selon leur localisation dans ou en dehors de l’environnement d’exécution de confiance, résident sous une forme chiffrée dans le programme modifié et leur déchiffrement est produit par le module de protection lors de leur sélection par ledit module ; - les moyens de protection sont des moyens de protection procédant par offuscation de composants, chiffrement de composants, vérification d’intégrité, par émulation d’instructions, par insertion d’éléments permettant de remédier à certaines vulnérabilités, par ségrégation de mémoire et/ou par placement d’un composant dans un environnement d’exécution de confiance matériel ; - les moyens de protection sont des moyens procédant par offuscation des composants ; - la méthode comprend en outre les étapes suivantes selon lesquelles : on établit un fichier de métadonnées descriptif des composants identifiés au cours de l’analyse statique du programme logiciel ; on affecte, à chacun des composants identifiés, des paramètres de niveau de sécurisation tels que des seuils de protection ou limites de consommation en cycles processeurs ou taille mémoire ; on fournit le fichier de métadonnées au module de sécurité ; et le module de sécurité régule dynamiquement le degré de protection du logiciel selon les paramètres affectés aux composants contenus dans le fichier de métadonnées ; - on affecte, à chacun des composants identifiés, un mode de protection initial et/ou un niveau minimum de sécurité et/ou des limites maximales de consommation de ressources processeur et/ou mémoire ; - l’analyse statique est effectuée sur un programme logiciel non compilé ; et les composants identifiés au cours de l’analyse statique sont des fonctions, des blocs d’instructions, des routines et/ou des sous-routines du programme logiciel ; - les modifications du programme logiciel initial sont réalisées par un logiciel d’analyse et de modification de programmes logiciels, et selon laquelle ledit logiciel d’analyse et de modification de programmes logiciels est livré dans l’environnement d’exécution de confiance matériel ou logiciel associé au programme logiciel protégé, en environnement hostile ; - l’architecture comprend un système d’exploitation, ledit système d’exploitation assurant la gestion du programme logiciel et intégrant le logiciel d’analyse et de modification de programmes logiciels ; et - l’architecture comprend en outre des moyens de prise de décision par apprentissage machine, lesdits moyens intervenant dans la régulation du degré de protection du programme logiciel.
Ainsi et, en particulier, la méthode selon l’invention permet de s’assurer que cette régulation dynamique ne puisse permettre, dans sa mise en œuvre, des attaques ciblées sur elle-même dans le but serait de conduire à une baisse du niveau de protection sur le programme. Elle permet, à un opérateur distant, humain ou formé par un processus automatisé, de modifier le niveau de protection, les fonctions de protection, les modes de protection à appliquer au programme. Cette redéfinition dynamique permet d’adapter les objectifs de protection en utilisant une connaissance sur l’état des menaces et leur criticité à un temps donné. Elle est initiée à distance et mise en œuvre dans un module de protection du logiciel, situé dans l’environnement d’exécution du logiciel. La méthode est telle que la redéfinition dynamique des objectifs de sécurité ne puisse, par sa mise en œuvre technique, permettre des attaques ciblées visant à interférer avec les données échangées ou leur traitement par le module de protection.
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
L’invention concerne une méthode de régulation du degré de protection d’un programme logiciel exécutable dans une architecture informatique. Cette méthode a pour objet de produire une régulation en temps réel une protection de l’exécution du programme logiciel, afin d’optimiser ladite exécution.
Dans un exemple de réalisation, l’architecture informatique est une architecture comprenant 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, le tout étant géré par un système d’exploitation, un module de sécurité, ce module étant formé par un composant logiciel s’exécutant au moyen du processeur et de la mémoire vive.
Un programme logiciel initial et/ou modifié est protégé par des moyens de protection du programme logiciel selon l’invention sont des moyens de protection procédant par offuscation de composants, chiffrement de composants, vérification d’intégrité, par émulation d’instructions, par insertion d’éléments permettant de remédier à certaines vulnérabilités, par ségrégation de mémoire et/ou par placement d’un composant dans un environnement d’exécution sécurisé matériel.
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 de protection dudit programme logiciel, et un module de sécurité, ledit module assurant la régulation de la protection dudit programme logiciel ; - 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é afin que le module de sécurité collecte des données de surveillance relatives aux temps ou aux fréquences d’exécution des composants identifiés lors de l’analyse statique du programme logiciel ; - on exécute le programme logiciel modifié dans l’architecture informatique ; - le module de sécurité collecte des données de surveillance relatives aux temps ou aux fréquences d’exécution des composants identifiés lors de l’analyse statique du programme logiciel, lors de l’exécution dudit programme logiciel modifié ; et - le module de sécurité traite les données collectées et régule dynamiquement le degré de protection du logiciel selon les données de surveillance collectées et traitées, lors de l’exécution dudit programme logiciel.
Ainsi, la méthode selon l’invention met en œuvre une surveillance ou, autrement dit, un monitoring, de l’exécution du programme logiciel modifié, une fois protégé pour permettre l’ajustement de la protection.
Un exemple d’une structure d’un programme logiciel initial est montré en Fig. 1A. Ce programme est écrit en assembleur. Il est formé de trois blocs d’instructions liés par deux sauts successifs à deux adresses pointant sur deux blocs successifs.
Pour la réalisation du monitoring, la méthode selon l’invention est susceptible d’être mise en œuvre selon différents modes de réalisation.
Un premier mode de réalisation est illustré aux Figs. 1B et 1C. Dans ce mode de réalisation, le programme logiciel initial est modifié par l’insertion, dans ledit programme, de sondes de surveillance. Ces sondes génèrent des données de surveillance collectées par le module de sécurité. Dans ce mode de réalisation, on met ainsi en œuvre des sondes placées dans le programme logiciel original de manière ad hoc. Ces sondes sont placées pour permettre d’émettre un message ou des données marquant chaque passage lors de l’exécution dans le bloc du programme dans lequel elles se trouvent. Ces sondes sont des séquences de quelques instructions, greffées automatiquement dans les prologues, les épilogues ou dans toute autre partie d’une fonction ou d’un bloc d’instructions. Deux sondes peuvent notamment être disposées dans une fonction ou un bloc fonctionnel, notamment pour permettre de mesurer le temps d’exécution de la partie considérée, par mesure de l’écart entre les temps de passage dans ces deux sondes.
Le placement des sondes peut être effectué de manière totalement automatisée, selon une règle prédéfinie par l’opérateur, ou de manière semi-automatique. Cette règle peut être, dans un exemple, de placer une sonde au prologue et une sonde à l’épilogue de chaque bloc d’instructions ou de chaque fonction. On peut notamment - si on dispose d’un code binaire, c’est-à-dire dans la forme exécutable du programme logiciel - produire directement les modifications sur ce binaire pour l’insertion de ces sondes aux emplacement adéquates. L’insertion de ces sondes peut être réalisé avant ou après application des moyens de protection du logiciel, sur le logiciel dans sa version originale ou protégée.
Pour ce faire, on produit au préalable une analyse statique du code binaire pour récupérer son graphe d’exécution. Ce graphe correspond à la structure du logiciel en blocs fonctionnels indépendants et appelés de manière successive ou de manière conditionnelle. La Fig. 1B présente un graphe type tel que récupéré par un outil d’analyse. Cette découpe en blocs fonctionnels est la structure de l’auto-régulation, réalisée pour chacun de ces blocs. De la même façon, si l’on dispose des codes sources, l’analyse statique du code et le placement automatique des sondes permet de disposer d’une granularité toujours supérieure pour permettre l’auto-régulation.
Un second mode de réalisation de la méthode selon l’invention est illustré aux Figs. 1D et 1E. Dans ce second mode de réalisation, on modifie le programme logiciel initial en changeant des adresses originales contenues dans ledit programme de manière à ce que ces adresses, qui pointent vers des composants identifiés dans le programme logiciel original soient modifiées par une adresse du module de sécurité. Lors de l’exécution du programme logiciel, le module de sécurité réalise alors les sauts aux adresses originales desdits composants.
Ce second mode va au-delà du placement de sondes dans le programme logiciel original. Il implique le transfert du calcul des adresses de branchement pour l’enchaînement de blocs à blocs, ce calcul étant réalisé par le module de protection. Si la protection ne modifie en rien la fonctionnalité du programme logiciel, en revanche, les outils d’analyse - désassembleur-débogueur et ses outils de génération du graphe d’exécution - ne peuvent plus produire le graphe d’exécution. La structure du programme telle qu’elle apparait avec l’original est perdue. Ce second mode de réalisation produit donc une fonction de sécurité complémentaire en ce sens qu’il réduit le graphe du programme. A titre d’exemple, on notera que le graphe de la Fig. 1E correspond au graphe après modification. La « verticalisation » du graphe de la Fig. 1E résulte du fait que tous les sauts de blocs convergent vers une seule adresse, celle du module de protection.
Le module de protection est, dans ce second mode de réalisation, apte à suivre le flot d’exécution du programme logiciel, blocs par blocs, pour en tirer des statistiques individualisées pour les sous-parties indépendantes – ou composants identifiés - du programme. Ces informations, qui sont des données collectées de surveillance relatives aux temps ou aux fréquences d’exécution des composants ou de la taille de leur empreinte en mémoire, sont alors utilisées pour mesurer, en temps réel, l’impact individuel des parties du programme logiciel de manière à mettre en œuvre une régulation fine et individualisée du degré de protection du programme logiciel. La technique consiste à simplement à intercepter tout ou partie des branchements du programme logiciel original réalisés par des sauts conditionnels ou fixes à leur adresse individuelle, définie en valeur relative ou absolue, par un appel au module de protection qui pourra lui donner la valeur initiale de ces adresses, en utilisant des données acquises lors de l’analyse statique du programme et des moyens complémentaires ad hoc implémentés de chaque appel. Il est alors possible, pour ce module de sécurité, de mettre en place des incréments et une horloge permettant de mesurer la fréquence d’appels d’un bloc et le temps nécessaire à son exécution, à savoir le temps mesuré entre deux sauts successifs correspondant au bloc d’instructions.
A noter que la régulation du degré de protection, pour être efficace, demande l’obtention d’une information granulaire sur différents composants du programme logiciel. Cette régulation dynamique est produite sur des données réelles et non plus définies a priori sur des estimations. Elle est produite dans un module de protection situé dans l’environnement d’exécution du programme protégé et qui interagit avec le programme protégé. Selon le type de déploiement, le module de protection intègre directement le programme protégé.
Avec les deux modes de réalisation de la méthode selon l’invention exposés ci-dessus, le module de protection réalise la collecte de ces données statistiques de surveillance et de la prise de décision sur la régulation, dans un environnement de confiance.
L’invention exploite donc le concept d’environnement d’exécution de confiance, qui permet, tant à l’auto-régulation qu’à la modification du profil de protection à distance, d’être appliquées en minimisant les risques associés au contournement de ces points sensibles (car influant la politique de sécurité).
En pratique, la méthode selon l’invention est susceptible d’être mise en œuvre dans deux types généraux d’environnements de confiance. Il s’agit d’environnements de confiance logiciels et d’environnements de confiance matériels. Les environnements de confiance matériels offrent, dans l’état actuel des connaissances, un niveau accru de sécurité et forment le schéma privilégié de la méthode selon l’invention. Dans ce cas, les prises de décision de l’auto-régulation sont hors d’atteinte de l’attaquant. Les environnements de confiance de type logiciel peuvent être de différentes natures et résultant de techniques élaborées d’offuscation logiciel comme par exemple la virtualisation de code ou de type de ségrégation de mémoire offerte par le système d’exploitation. Les environnements de confiance de type matériel résultent directement d’opérations de chiffrement et de gestion d’accès mémoire réalisés par le processeur comme par exemple la technologie d’enclave SGX portée par les nouveaux types de processeurs Intel™.
En complément, la méthode selon l’invention prévoit aussi de faire face à des attaques par empoisonnement ou de déviation du comportement de la régulation de la protection. Celles-ci ne modifient pas le module de protection mais lui injectent des données ou engendrent une modification du comportement du logiciel protégé de sorte que la prise de décision est orientée vers un plus bas niveau de protection. Afin de contrer cette déviation, l’invention prévoit de permettre à l’opérateur de forcer, pour certaines fonctions plus sensibles, un maintien du niveau de protection à un seuil minimal de protection qui ne pourra pas être minoré par la régulation.
Un autre variante de mise en œuvre de la méthode selon l’invention propose que l’extraction de statistiques et la redéfinition continue de la protection exploite les mécanismes d’apprentissage par la machine et en particulier par apprentissage par renforcement. La prise de décision fait intervenir un dispositif d’apprentissage renforcé (« reinforcement machine learning » en langue anglaise). Un tel dispositif permet d’accroître la pertinence des décisions prises par une acquisition continue et croissante de données recueillies au fil des différentes exécutions du programme. Il permet de faire face aux attaques par empoisonnement ou de déviation de comportement de la régulation détectées et écartées pour certaines d’entre elles, présentant un caractère trop divergeant.
Le module de protection comprend au moins une fonctionnalité assurant la prise de contrôle ou le pistage des éléments constitutifs du graphe d’exécution du programme original protégé. Cette fonctionnalité assure l’auto-régulation au fil de l’exécution. Elle permet de réduire ou de durcir la stratégie, les techniques et le paramétrage de ces techniques de protection en fonction de points de mesure caractérisant le degré de sollicitation, à savoir la fréquence d’appels, le temps d’exécution, la réserve mémoire des parties protégées ou blocs d’instructions intégrant ces parties protégées. Les Figs. 2A et 2B présentent le fichier des statistiques enrichi au fil des exécutions successives.
Dans certaines variantes de réalisation de la méthode selon l’invention, on fournit un environnement de confiance, pour l’exécution sécurisée de programmes logiciels ; on place le module de sécurité dans ledit environnement de confiance ; on extrait des composants identifiés du programme logiciel ; on place lesdits composants dans l’environnement de confiance ; et on exécute des composants non-extraits du programme logiciel hors de l’environnement de confiance et on exécute des composants extraits du programme logiciel dans l’environnement de confiance, sous le contrôle du module de sécurité. La méthode selon l’invention met alors en œuvre une étape de protection d’un programme logiciel initial basée sur un partage de l’exécution du programme protégé entre son environnement normal d’exécution et un environnement d’exécution de confiance et qui comprend à la fois des sous-parties du programme initial et au moins le module de protection, qui assure la régulation du degré de protection du programme logiciel. La partie du programme s’exécutant dans l’environnement de confiance est, selon le type d’environnement de confiance, définie, au moyen de techniques logicielles ou matérielles, lors du déploiement, soit totalement préservée soit moins exposée aux attaques de type rétro conception, modification ou exploitation de vulnérabilités.
Dans certaines variantes de l’invention, les fonctions d’analyse, de modification pour la protection et de régulation de la protection sont directement intégrées dans le système d’exploitation du système hôte dans lequel s’exécute le logiciel. Dans ces variantes, le logiciel peut ainsi être déployé sans protection. La protection est en effet directement produite par le système d’exploitation avant ou après son lancement. Dans cette variante, un fichier de métadonnées est avantageusement fourni par un opérateur ou un orchestrateur de sécurité. Ce fichier de métadonnées peut préciser certaines caractéristiques du profil de la protection.
Les Figs. 3, 4A et 4B présentent deux exemples de déploiement de ces variantes de réalisation. Dans ces exemples, on fournit un serveur de protection et un fichier de métadonnées. Le serveur réalise une protection selon un projet de protection défini soit par un opérateur soit par un orchestrateur de sécurité automatisé, que l’on pourra notamment rencontrer dans les environnements du type en nuage (« cloud ») ou du type en réseaux télécoms logiciels («Software Defined Networks » - réseaux définis logiciels). Le projet de protection résulte en une version du programme logiciel protégé et en complément , le fichier de métadonnées caractérisant le projet de protection. Deux environnements d’exécution recueillent tout ou partie du programme protégé et le module de protection. Selon l’invention, on établit un fichier de métadonnées descriptif des composants identifiés au cours de l’analyse statique du programme logiciel ; on affecte, à chacun des composants identifiés, des paramètres de niveau de sécurisation (actuel ou seuils minimum-maximum) ou des seuils maximum de consommation de ressources (processeur, mémoire); on fournit le fichier de métadonnées au module de sécurité ; et le module de sécurité régule dynamiquement le degré de protection du logiciel selon les paramètres affectés aux composants contenus dans le fichier de métadonnées. Les Figs. 4A et 4B se distinguent de la Fig. 3 en ce sens que le serveur de protection est directement fourni dans l’environnement de confiance matériel, de préférence, déployé en milieu hostile, là où est exécuté le programme logiciel protégé. Le serveur de protection est directement inséré dans le module de protection, potentiellement installé en milieu hostile et se substitue et intègre les fonctions du module de protection (récupération de statistiques, auto régulation fonctions de sécurité). A la Fig. 4B, le système d’exploitation comprend au moins le serveur de protection et le module de protection, ledit module étant possiblement intégré au serveur de protection.
Dans une variante de réalisation, on établit, entre le serveur de protection et l’environnement de protection sécurisé, un canal de communication sécurisé permettant une transmission sécurisée de données, par exemple en exploitant le protocole d’échange de clefs de type Diffie-Hellmann. Par ce canal, on peut récupérer le fichier de « métadonnées » comprenant notamment, à la fois, les données telles que les parties modifiées du programme logiciel et les données caractérisant le paramétrage de la protection ainsi que les modes de protection utilisés. Ce fichier reflète la protection telle que réalisée dans la version originale du programme logiciel protégé ou à tout moment ultérieur correspondant à la prise en compte de nouveaux objectifs de sécurité définis par l’opérateur.
A la réception d’un nouveau fichier de métadonnées et après avoir vérifié son origine et son intégrité, les données sont exploitées par le module de protection. Ainsi, il est possible, dans l’environnement de confiance, de modifier le profil de la protection selon le nouveau fichier de métadonnées reçu. Selon les modes de protection concernés par ses changements, la modification pourra être produite lors de l’exécution du programme ou à son prochain lancement.
Ainsi que cela est illustré aux Figs. 5A et 5B, la méthode selon l’invention comprend les étapes suivantes selon lesquelles:
- on fournit le programme logiciel original dans sa version source ou binaire ou bytecode pour les langages interprétés ;
- on produit, au niveau du serveur de protection, les modifications sur ce programme logiciel résultant dans la répartition de son exécution dans les deux environnements d’exécution à savoir l’environnement dit normal et l’environnement dit de confiance, de parties du programme protégées ou pas, et la production d’un module de protection intégrant différentes fonctions de sécurité externes au programme et qui est placé dans l’environnement de confiance.
A la Fig. 5A, le serveur de protection n’est pas intégré au système d’exploitation, avant et après le déploiement et l’auto-régulation de la protection à l’exécution ou par la modification du projet de protection par l’opérateur. A la Fig. 5B, le serveur de protection est intégré au système d’exploitation qui produit à la réception du programme initial toutes les opérations d’analyse, de protection et de régulation de la protection lors de l’exécution, tout en permettant la modification par un opérateur externe du projet de protection à tout moment durant l’exécution du programme. La phase de protection préliminaire, qui comporte les étapes de fourniture du programme logiciel initial, d’analyse statique, et de réalisation du projet de protection avec production du fichier de métadonnées, est réalisée par le système d’exploitation.
Ainsi que cela est montré à la Fig. 6A, la répartition des fonctions dans les deux types d’environnement, leurs niveaux de protection, varient selon les stratégies de protection envisagées. Au niveau le plus simple, on peut placer l’intégralité du programme initial dans l’environnement normal, ayant réalisé les opérations minimales lors de la protection pour l’insertion de sondes ou pour déporter la gestion dynamique de son flot de contrôle dans l’environnement sécurisé. A l’autre extrémité, au niveau de protection maximal, on placera l’intégralité des fonctions dans un environnement de confiance matériel. Ainsi que cela est montré à la Fig. 6B, le système d’exploitation comprend un environnement d’exécution de confiance, le module de sécurité étant placé dans cet environnement de confiance, pour la mise en œuvre du contrôle du flux d’exécution, de la routine d’extraction de statistiques telles que des statistique de fréquence d’appelle ou de durée d’exécution par fonction ou bloc d’instructions.
Ainsi que cela est illustré aux Figs. 7A et 7B, selon le type d’environnement d’exécution de confiance visé, à savoir un environnement logiciel ou matériel, le serveur de protection génère l’environnement de protection de confiance lui-même, par des techniques logicielles du type offuscation ou anti-modification, dont un exemple est la virtualisation de code, ou la ségrégation, ou alors, le logiciel destiné à intégrer un environnement d’exécution de confiance de type Trusted Execution Environment (TEE – Environnement d’Exécution de Confiance) matériel. Dans un exemple, l’environnement d’exécution sécurisé exploite des techniques matérielles reposant sur des dispositifs des nouveaux processeurs du type de l’enclave SGX d’Intel™, la trustzone (zone de confiance) d’ARM™ ou équivalentes offertes par d’autres fournisseurs de processeurs ou par des fournisseurs de structures matérielles (frameworks) exploitant ces dispositifs.
Ainsi, dans une variante de réalisation de la méthode selon l’invention, l’environnement d’exécution sécurisé exploite des techniques d’offuscation et/ou de protection contre la modification reposant toutes exclusivement sur des techniques logicielles de toutes natures, telles que la virtualisation de code, d’émulation d’instructions, la transposition du code initial en représentation intermédiaire, l’aplatissement de graphe, la vérification de d’intégrité à l’exécution de parties ou de l’intégralité du code. Les moyens de protection sont, dans un exemple, des moyens de protection procédant par offuscation de composants ou par placement d’un composant dans un environnement d’exécution sécurisé.
Dans le cas où l’environnement d’exécution de confiance repose sur des techniques logicielles, les techniques d’offuscation mises à l’œuvre offrent une très grande amplitude avec de nombreuses techniques des plus simples au plus complexes. Ainsi, l’environnement de confiance peut se réduire à l’implémentation de techniques d’offuscation sur l’intégralité ou certaines parties logicielles du module de protection. Cette implémentation de techniques d’offuscation constitue de facto l’environnement d’exécution de confiance logiciel. Ces techniques doivent renforcer la sécurité du module de protection.
Enfin, on peut aussi utiliser la ségrégation de mémoire offerte par certains systèmes d’exploitation pour y placer le module de protection dans un compartiment mémoire distinct et non accessible.
Dans le cas où l’environnement d’exécution sécurisé est de type matériel, la méthode selon l’invention propose de loger, dans cet environnement, le module de protection comprenant les différentes fonctions de sécurité et au moins les fonctionnalités de monitoring et d’auto-régulation, selon les deux modes proposé par l’invention. En complément au module de protection, certaines ou toutes les fonctions ou blocs d’instructions du programme peuvent être logés dans l’environnement d’exécution sécurisé.
En sortie de son traitement, le serveur de protection délivre le logiciel protégé de manière packagée ou séparée pour les deux composantes intégrant les environnements d’exécution normal ou de confiance, ainsi qu’un fichier de métadonnées associé au logiciel protégé et comprenant toutes les données descriptives du schéma de protection (fonctions du programme protégées, type d’environnement d’exécution, mode de protection par fonction, paramétrage de ces modes par fonction protégée, seuils admissibles de consommation de ressources, par blocs d’instructions etc… ainsi que les données caractérisant le programme (données d’identification des fonctions et blocs fonctionnels, identifiant des instructions intervenant dans la gestion du graphe de contrôle, c’est-à-dire les instructions de saut (conditionnel ou non conditionnel) reliant les fonctions (internes ou externes) entre elles et les données structurelles sur le graphe d’exécution (adresses des fonctions ou blocs d’instructions). Ce fichier de métadonnées est protégé par sa signature et le mécanisme classique de vérification d’authenticité exploitant le calcul de hash et le chiffrement asymétrique.
Enfin, de la même façon, le serveur de protection délivre avantageusement une signature du programme logiciel protégé et une clef publique permettant ultérieurement de contrôler l’authentification et de vérifier l’identité de la version de ce programme logiciel protégé.
On fournit le programme logiciel protégé de manière packagée ou éclatée de ses deux composants s’exécutant dans l’environnement d’exécution normal ou sécurisé.
A l’exécution, la fonctionnalité de monitoring et/ou de contrôle du graphe d’exécution du programme est capable de modifier dynamiquement le profil de la protection par la prise en compte des éléments caractérisant l’exécution des parties protégées. En premier lieu, le module sera capable de faire varier la fréquence d’exécution de certaines mesures de protection. Selon les particularités techniques propres à chaque type de protection, on peut, soit au fil de l’exécution du programme ou d’un composant du programme, soit lors de la prochaine exécution dudit programme ou dudit composant, faire varier le profil, le type, les modes, les fonctionnalités et les paramètres s’appliquant sur un périmètre éventuellement modifié de fonctions protégées du programme initial. Sans constituer une liste exhaustive, on peut citer les techniques à l’œuvre pour la modification dynamique de la protection, à savoir :
- la variation de fréquence de déclenchement des opérations de sécurité,
- la variation de paramètres de la protection (taux de faux négatifs/faux positifs acceptés,…) ou la variation du mode de protection,
- le branchement vers une version d’une fonction, routine ou bloc d’instructions protégés à un niveau différent et préalablement installés (et offusqués, camouflés, encodés ou chiffrés) dans le programme protégé. De façon avantageuse, on peut délivrer les éléments permettant à cette version de se décoder ou se déchiffrer par le transfert d’éléments détenus par le module de sécurité,
- le transfert d’un environnement d’exécution à l’autre. Notamment, mais pas seulement, par utilisation du principe de l’interprétation de code, on peut transformer une séquence d’instructions en une donnée directement transmissible à l’autre partie sans modifier le logiciel de cette partie.
Le lancement du logiciel protégé s’effectue soit dans l’environnement normal soit dans l’environnement d’exécution de confiance selon le projet de protection. La séquence d’opérations suivantes est mise en œuvre dans le module s’exécutant dans l’environnement d’exécution sécurisé :
- récupération du fichier de métadonnées caractérisant la protection initiale,
- vérification d’authenticité par utilisation de la clef publique et de la signature intégrée dans le fichier de métadonnées, si une signature a été produite et insérée dans le fichier de métadonnées,
- déchiffrement ou pas de cette partie par la clef symétrique contenue dans le fichier de métadonnées si le fichier a été chiffré (comme indiqué dans le fichier de métadonnées),
- calcul et du point d’entrée et lancement de l’exécution qui sera répartie dans les environnements d’exécution normaux et de confiance des différents composants du logiciels
- extraction de statistiques sur les données temporelles et fréquentielles recueillies lors de l’exécution de ces différents composants et/ou les données caractérisant la consommation de mémoire de ces différents composants,
- ajustement continu du niveau de protection par traitement des données statistiques et aussi de données du fichier de métadonnées précisant le périmètre de l’auto régulation et des exclusions éventuelles à ce dispositif,
- écriture dans le fichier de métadonnées et transfert éventuel vers le serveur.
L’ajustement précité est basé sur une variation, positive ou négative, de la fréquence des opérations de sécurité, sur une variation, positive ou négative, du paramétrage des fonctions de sécurité, sur la modification du branchement de tout ou partie des séquences instructions vers des autres versions iso-fonctionnelles des séquences d’instructions présentant un niveau différent de protection et qui ont été insérées initialement dans le programme protégé, ou sur un transfert de l’exécution d’une ou plusieurs fonctions ou blocs d’instructions d’un environnement (normal, de confiance) vers l’autre.
En définitive, l'invention concerne donc une large variété de méthodes de protection d’un programme logiciel ciblées sur des menaces différentes (rétro-conception, modification, utilisation sans droit et exploitation de vulnérabilités). Elle met en œuvre dans un environnement d’exécution de confiance (logiciel ou matériel) un dispositif de régulation de la protection utilisant des données fréquentielles, temporelles et d’encombrement mémoire collectées lors de l’exécution des composants du programme protégé. Pour ce faire, on place des sondes de pistage dans les différentes sous parties du programme ou alternativement on déroute le flux de contrôle du programme. Dans les deux cas, un module de protection situé dans un environnement de confiance dispose de données individualisées par composants du programme recueillies à postériori lors d’une ou plusieurs exécutions. Avec ces données, ce module de protection prend des décisions (dans un cadre éventuellement restreint que l’opérateur peut définir lors de la pose de la protection initiale) pour modifier le niveau de protection pour chaque composants du programme en tenant compte de son impact réel et non plus estimé à priori. Parce que ce module de protection gère la protection du logiciel, il est lui-même sécurisé dans un environnement de confiance.
Claims (16)
- Une méthode de régulation du degré de protection d’un programme logiciel exécutable dans une architecture informatique comprenant des étapes suivantes:
on fournit un programme logiciel initial, des moyens de protection dudit programme logiciel initial, et un module de sécurité, ledit module assurant la régulation de la protection dudit programme logiciel ;
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 pour obtenir un programme logiciel modifié afin que le module de sécurité collecte des données de surveillance relatives aux temps ou aux fréquences d’exécution ou à une empreinte en mémoire vive des composants identifiés lors de l’analyse statique du programme logiciel ;
on exécute le programme logiciel modifié dans l’architecture informatique ;
le module de sécurité collecte des données de surveillance relatives aux temps ou aux fréquences d’exécution ou à l’empreinte mémoire des composants identifiés lors de l’analyse statique du programme logiciel initial, lors de l’exécution du programme logiciel modifié ; et
le module de sécurité traite les données collectées et régule dynamiquement le degré de protection du programme logiciel modifié selon les données de surveillance collectées et traitées, lors de l’exécution dudit programme logiciel modifié. - La méthode selon la revendication 1, selon laquelle le programme logiciel modifié, qui est exécuté dans l’architecture informatique, est un programme logiciel qui est protégé par les moyens de protection préalablement à son exécution ou lors de son exécution, selon un degré de protection donné, et selon laquelle, après traitement des données collectée par le module de sécurité, le degré de protection est modifié dynamiquement par le module de sécurité, selon les données de surveillance collectées et traitées.
- La méthode selon l’une des revendications 1 ou 2, selon laquelle le programme logiciel est modifié par l’insertion, dans ledit programme, de sondes de surveillance, lesdites sondes générant les données de surveillance collectées par le module de sécurité.
- La méthode selon l’une des revendications 1, 2 ou 3, selon laquelle :
on modifie le programme logiciel en interceptant des sauts ou des branchements dans ledit programme, et pointant vers les composants identifiés par leurs adresses, par un branchement ou appel au module de sécurité ; et
lors de l’exécution du programme logiciel, le module de sécurité réalise les branchements ou les sauts aux adresses desdits composants. - La méthode selon l’une des revendications précédentes, selon laquelle :
on fournit un environnement de confiance, pour l’exécution sécurisée de programmes logiciels ;
on place le module de sécurité dans ledit environnement de confiance ;
on extrait des composants identifiés du programme logiciel ;
on place lesdits composants dans l’environnement de confiance ; et
on exécute des composants non-extraits du programme logiciel hors de l’environnement de confiance et on exécute des composants extraits du programme logiciel dans l’environnement de confiance, sous le contrôle du module de sécurité. - La méthode selon l’une revendications précédentes, dans laquelle le module de sécurité régule dynamiquement le degré de protection en faisant varier la fréquence ou les conditions de réalisation de la protection du programme logiciel.
- La méthode selon l’une des revendications précédentes, dans laquelle le programme logiciel modifié comprend une pluralité de composants iso-fonctionnels, ces composants iso-fonctionnels étant protégés selon des degrés de protection différents ou selon leur localisation dans ou en dehors d’un environnement de confiance, et le module de sécurité régule dynamiquement la protection en choisissant d’exécuter un composant iso-fonctionnel plutôt qu’un autre selon son degré de protection ou sa localisation dans ou en dehors d’un environnement de confiance.
- La méthode selon la revendication 7, dans laquelle les composants iso-fonctionnels protégés selon des degrés de protection différents ou selon leur localisation dans ou en dehors de l’environnement d’exécution de confiance, résident sous une forme chiffrée dans le programme modifié et leur déchiffrement est produit par le module de protection lors de leur sélection par ledit module.
- La méthode selon l’une des revendications précédentes, selon laquelle les moyens de protection sont des moyens de protection procédant par offuscation de composants, chiffrement de composants, vérification d’intégrité, par émulation d’instructions, par insertion d’éléments permettant de remédier à certaines vulnérabilités, par ségrégation de mémoire et/ou par placement d’un composant dans un environnement d’exécution de confiance matériel.
- La méthode selon la revendication 9, dans laquelle les moyens de protection sont des moyens procédant par offuscation des composants.
- La méthode selon l’une des revendications précédentes, comprenant en outre les étapes suivantes selon lesquelles :
on établit un fichier de métadonnées descriptif des composants identifiés au cours de l’analyse statique du programme logiciel ;
on affecte, à chacun des composants identifiés, des paramètres de niveau de sécurisation ;
on fournit le fichier de métadonnées au module de sécurité ; et
le module de sécurité régule dynamiquement le degré de protection du logiciel selon les paramètres affectés aux composants contenus dans le fichier de métadonnées. - La méthode selon l’une des revendications précédentes, selon laquelle on affecte, à chacun des composants identifiés, un mode de protection initial et/ou un niveau minimum de sécurité et/ou des limites maximales de consommation de ressources processeur et/ou mémoire.
- La méthode selon l’une des revendications précédentes, selon laquelle :
l’analyse statique est effectuée sur un programme logiciel non compilé ; et
les composants identifiés au cours de l’analyse statique sont des fonctions, des blocs d’instructions, des routines et/ou des sous-routines du programme logiciel. - La méthode selon l’une des revendications précédentes, selon laquelle les modifications du programme logiciel initial sont réalisées par un logiciel d’analyse et de modification de programmes logiciels, et selon laquelle ledit logiciel d’analyse et de modification de programmes logiciels est livré dans l’environnement d’exécution de confiance matériel ou logiciel associé au programme logiciel protégé, en environnement hostile.
- La méthode selon la revendication 14, selon laquelle l’architecture comprend un système d’exploitation, ledit système d’exploitation assurant la gestion du programme logiciel et intégrant le logiciel d’analyse et de modification de programmes logiciels.
- La méthode selon l’une des revendications précédentes, selon laquelle l’architecture comprend en outre des moyens de prise de décision par apprentissage machine, lesdits moyens intervenant dans la régulation du degré de protection du programme logiciel.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2010252A FR3114890A1 (fr) | 2020-10-07 | 2020-10-07 | Methode de regulation du degre de protection d’un programme logiciel |
| PCT/EP2021/077769 WO2022074149A1 (fr) | 2020-10-07 | 2021-10-07 | Methode de regulation du degre de protection d'un programme logiciel |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2010252A FR3114890A1 (fr) | 2020-10-07 | 2020-10-07 | Methode de regulation du degre de protection d’un programme logiciel |
| FR2010252 | 2020-10-07 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3114890A1 true FR3114890A1 (fr) | 2022-04-08 |
Family
ID=74125391
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2010252A Pending FR3114890A1 (fr) | 2020-10-07 | 2020-10-07 | Methode de regulation du degre de protection d’un programme logiciel |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR3114890A1 (fr) |
| WO (1) | WO2022074149A1 (fr) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11741238B2 (en) * | 2017-11-27 | 2023-08-29 | Lacework, Inc. | Dynamically generating monitoring tools for software applications |
| US20230412619A1 (en) * | 2022-06-16 | 2023-12-21 | Sternum Ltd. | Systems and methods for the instrumentation, real-time compromise detection, and management of internet connected devices |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110088095A1 (en) * | 2008-04-07 | 2011-04-14 | Metaforic Limited | Anti-Tamper System Employing Automated Analysis |
| US20150052603A1 (en) * | 2013-08-13 | 2015-02-19 | Arxan Technologies, Inc. | Anti-tamper system with self-adjusting guards |
-
2020
- 2020-10-07 FR FR2010252A patent/FR3114890A1/fr active Pending
-
2021
- 2021-10-07 WO PCT/EP2021/077769 patent/WO2022074149A1/fr active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110088095A1 (en) * | 2008-04-07 | 2011-04-14 | Metaforic Limited | Anti-Tamper System Employing Automated Analysis |
| US20150052603A1 (en) * | 2013-08-13 | 2015-02-19 | Arxan Technologies, Inc. | Anti-tamper system with self-adjusting guards |
Non-Patent Citations (2)
| Title |
|---|
| LIU YIN ET AL: "RT-Trust: Automated refactoring for different trusted execution environments under real-time constraints", JOURNAL OF COMPUTER LANGUAGES, ELSEVIER, AMSTERDAM, NL, vol. 56, 27 December 2019 (2019-12-27), XP086085403, ISSN: 2590-1184, [retrieved on 20191227], DOI: 10.1016/J.COLA.2019.100939 * |
| MUKHIN VADYM ET AL: "Obfuscation Code Technics Based on Neural Networks Mechanism", 2020 IEEE 2ND INTERNATIONAL CONFERENCE ON SYSTEM ANALYSIS & INTELLIGENT COMPUTING (SAIC), IEEE, 5 October 2020 (2020-10-05), pages 1 - 6, XP033851763, DOI: 10.1109/SAIC51296.2020.9239247 * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2022074149A1 (fr) | 2022-04-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Garg et al. | Comparative analysis of Android and iOS from security viewpoint | |
| Kok et al. | Early detection of crypto-ransomware using pre-encryption detection algorithm | |
| Hossain et al. | Combating dependence explosion in forensic analysis using alternative tag propagation semantics | |
| Nagra et al. | Surreptitious software: obfuscation, watermarking, and tamperproofing for software protection | |
| WO2022074149A1 (fr) | Methode de regulation du degre de protection d'un programme logiciel | |
| Kanwal et al. | An app based on static analysis for android ransomware | |
| Alqahtani et al. | A proposed crypto-ransomware early detection (CRED) model using an integrated deep learning and vector space model approach | |
| Rani et al. | A survey on machine learning-based ransomware detection | |
| Alzahrani et al. | An intelligent behavior-based ransomware detection system for android platform | |
| Vehabovic et al. | Ransomware detection and classification strategies | |
| Merlo et al. | You shall not repackage! demystifying anti-repackaging on android | |
| Sangani et al. | Machine learning in application security | |
| Ozkan et al. | Security analysis of mobile authenticator applications | |
| Palm et al. | Modeling data protection vulnerabilities of cloud systems using risk patterns | |
| Pontiroli et al. | The tao of. net and powershell malware analysis | |
| Chayal et al. | A review on spreading and forensics analysis of windows-based ransomware | |
| Alam | Cybersecurity: Past, Present and Future | |
| Khan et al. | Ransomware prevention using moving target defense based approach | |
| Kajiyama | Cloud computing security: how risks and threats are affecting cloud adoption decisions | |
| FR2974207A1 (fr) | Procede et systeme de securisation d'un logiciel | |
| Sneha et al. | Ransomware detection techniques in the dawn of artificial intelligence: a survey | |
| Genç | Analysis, detection, and prevention of cryptographic ransomware | |
| Moussaileb | Log analysis for malicious software detection | |
| Fernández-Fuentes et al. | Recovering from Memory the Encryption Keys Used by Ransomware Targeting Windows and Linux Systems | |
| FR3067486A1 (fr) | Procede de detection non intrusif des failles de securite d'un programme informatique |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20220408 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |