Brevet FR3067486A1 — publié le 20181214

PROCEDE DE DETECTION NON INTRUSIF DES FAILLES DE SECURITE D'UN PROGRAMME INFORMATIQUE DOMAINE DE L'INVENTION La présente invention concerne un procédé de détection non intrusif des failles de sécurité d'un programme informatique. ARRIERE PLAN TECHNOLOGIQUE DE L'INVENTION Un nombre croissant de programmes informatiques 15 manipulent des données qu'il faut conserver secrètes ou réalisent des transactions qu'il est essentiel de sécuriser. C'est le cas des programmes informatiques traitant par exemple de données personnelles, telles que des données de santé, ou réalisant des opérations financières, telles que des virements 20 de compte à compte_ Pour assurer le secret, l'authenticité et/ou la sécurité des données manipulées, il est d'usage d'employer des techniques cryptographiques. Il peut s'agir par exemple de chiffrer le 25 contenu d'un message à l'aide d'une clé de chiffrement. Seul le détenteur de la clé est capable, dès lors, d'accéder à ce contenu. Dans un système informatique, les fonctions 30 cryptographiques sont généralement regroupées au sein d'une bibliothèque standard et éprouvée. Cette bibliothèque peut faire partie du système d'exploitation et être disponible d'accès à l'ensemble des applications s'exécutant sur ce système. 35 Les techniques cryptographiques, même si elles sont d'usages très répandus, ont toutefois des limites. Par exemple, si la clé de chiffrement présente une longueur trop faible, il 10 2 peut être possible d'accéder au contenu d'un message chiffré, « en force brute », en essayant toutes les combinaisons possibles de clé au cours de tentatives successives de déchiffrage du message. 5 De plus, et bien qu'un soin important soit apporté à la conception des bibliothèques de fonctions cryptographiques, il est possible que celles-ci présentent des failles qui peuvent être exploitées par des tiers pour accéder à des informations réservées ou réaliser des transactions frauduleuses. Lorsqu'une telle faille est identifiée par la communauté informatique, elle est immédiatement communiquée afin qu'une version améliorée de la bibliothèque puisse être rendue disponible ou que les règles d'utilisation conforme des fonctions soient mises à jour. Malgré tous les moyens mis en oeuvre, on ne peut être certain qu'un programme informatique ne recèle pas de failles de sécurité. Une des raisons expliquant ce constat réside dans l'approche modulaire adoptée pour la conception d'un programme. Les modules constituant ce programme peuvent être développés par des personnes ou des groupes de personnes différents d'une même organisation, d'autres modules peuvent être développés par des organisations tierces, ou être rendus disponibles par la communauté informatique sous la forme de modules d'usage dit « libre ». Cette approche modulaire de conception et de réutilisation de modules préexistants facilite la conception et la réalisation des programmes informatiques, mais rend particulièrement délicate la bonne application d'une politique de sécurité stricte garantissant une conception totalement absente de failles. Plusieurs approches techniques ont dès lors été proposées pour tester des programmes pour y détecter la présence d'éventuelles failles de sécurité. Selon une première approche, dite « statique » et connue par exemple du document U57207065, on réalise une analyse d'un 3 programme dans sa version source. Ce type d'analyse présente le risque de ne pas détecter certaines failles pourtant bien présentes lors de l'exécution du programme, ce qui le rend vulnérable. En effet le comportement d'un programme 5 informatique, c'est-à-dire la séquence précise des événements qui s'enchaînent lorsque la version exécutable du programme s'exécute sur le système informatique, ne dépend pas uniquement du contenu de sa version source. Par exemple, un fichier de configuration du programme qui est associé à la version source 10 du programme uniquement au moment de sa compilation, ou qui est consulté par le programme dans sa forme exécutable à son démarrage, peut affecter son comportement au cours de son exécution et rendre le programme vulnérable selon le contenu de ce fichier de configuration. 15 L'expérience montre également que l'approche statique de détection conduit à reporter sous forme d'alertes un nombre excessif de failles potentielles. Le procédé de détection ne pouvant discriminer les failles potentielles des failles avérées 20 faute de connaître le contexte d'exécution du programme, certaines de ces alertes se révèlent être de fausses alertes. D'une manière générale, les fausses alertes sont à éviter, même si celles-ci peuvent être facilement identifiées et 25 écartées par l'utilisateur. Lorsque celles-ci sont fournies en nombre excessif, elles décrédibilisent la pertinence de la méthode de détection et conduisent ses utilisateurs à ignorer dans leur ensemble les alertes fournies même si celles-ci concernent des failles avérées. 30 Selon une autre approche de détection, dite « dynamique » et connue par exemple du document U58844043, on instrumentalise le programme dans sa version exécutable à l'aide de points de traçage (« tracepoint » selon le terme anglo-saxon usuellement 35 employé). Lorsqu'un point de traçage est atteint au cours de l'exécution du programme, un appel est effectué à une fonction sonde, permettant de reporter dans un fichier de traçage 4 certaines informations relatives à l'état du programme au moment de l'appel. Le fichier de traçage peut être analysé pour y déceler des comportements susceptibles de former des failles de sécurité. 5 Les approches dynamiques connues de détection ne sont toutefois pas entièrement satisfaisantes, car elles nécessitent l'introduction des points de traçage dans la version exécutable du programme et l'exécution de la fonction seconde. Or il n'est 10 pas toujours possible d'instrumentaliser de la sorte un programme, par exemple parce que le programme dans sa version source n'est pas disponible ou parce que les droits d'utilisation associés à ce programme n'en autorisent pas sa modification. De plus, cette instrumentalisation peut affecter 15 le comportement dynamique du programme ce qui peut conduire à rendre indétectables certaines failles de sécurité. La présente invention vise à pallier tout ou partie des inconvénients précités. Elle vise notamment à fournir un procédé 20 de détection des failles de sécurité d'un programme informatique qui soit particulièrement fiable, c'est à dire qui permet d'identifier les failles de sécurité avérées du programme, et qui limite autant que faire se peut les fausses alertes. 25 BREVE DESCRIPTION DE L'INVENTION En vue de la réalisation de l'un de ces buts, l'objet de l'invention propose un procédé de détection non intrusif des 30 failles de sécurité d'un programme informatique, le procédé comportant les étapes suivantes : - Installer et exécuter une version exécutable et non instrumentalisée du programme dans un système informatique, le système informatique comprenant au 35 moins une fonction cryptographique susceptible d'être appelée par le programme ; 5 - au cours de l'exécution du programme, enregistrer dans un fichier de traçage les modalités d'appels de la fonction cryptographique ; - après l'exécution du programme, analyser le fichier 5 de traçage à l'aide d'une base de règles pour détecter des appels à la fonction cryptographique susceptible de former une faille de sécurité. En enregistrant dans un fichier de traçage les modalités 10 d'appel d'une fonction cryptographique, on dispose des informations nécessaires pour, à l'aide d'une base de règles préétablies, identifier les usages de cette fonction cryptographique pouvant former une faille de sécurité potentielle. Il n'est donc pas nécessaire d'instrumentaliser le 15 programme, de choisir l'emplacement de points de traçage, ni même de disposer de la version source de ce programme pour le tester. Selon d'autres caractéristiques avantageuses et non 20 limitatives de l'invention, prises seules ou en combinaison : - l'enregistrement dans un fichier de traçage est mise en oeuvre par un programme de traçage s'exécutant concourrament avec le programme informatique ; 25 - la fonction cryptographique est instrumentalisée pour permettre l'enregistrement de ses modalités d'appel ; - le procédé comprend une étape préliminaire de remplacement 30 d'une fonction cryptographique originelle du système informatique par la fonction cryptographique instrumentalisée ; - d'enregistrement comprend l'obtention d'une partie au moins 35 de la pile d'exécution lorsque la fonction cryptographique est appelée par le programme ; 6 - le système comprend une pluralité de fonctions cryptographiques et seules les modalités d'appel aux fonctions cryptographiques de gestion et d'usage sont enregistrées dans le fichier de traçage ; 5 - les modalités d'appel de la fonction cryptographique enregistrées dans le fichier de traçage comprennent l'une au moins des modalités choisies dans le groupe constitué du nom de la fonction cryptographique, des arguments de la 10 fonction cryptographique, du nom d'un module appelant la fonction cryptographique, de l'horodatage de l'appel à la fonction cryptographique, et de la réponse retournée par la fonction cryptographique ; 15 - l'étape d'analyse met en oeuvre un moteur d'inférence ; - l'étape d'analyse est précédée du recensement dans le fichier de traçage des objets cryptographiques ; 20 - le procédé comprend une étape d'enregistrement du numéro de version de la fonction cryptographique ; - le procédé comprend une étape de filtrage des failles de sécurités détectées. 25 L'invention concerne également un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé de détection non intrusif des failles de sécurité d'un programme informatique, lorsque le 30 programme d'ordinateur est exécuté sur un ordinateur BREVE DESCRIPTION DES DESSINS L'invention sera mieux comprise à la lumière de la 35 description qui suit des modes de réalisation particuliers et non limitatifs de l'invention en référence aux figures ci-jointes parmi lesquelles : 7 - la figure 1 représente un système informatique pour la mise en oeuvre d'une partie au moins de l'invention ; - la figure 2 représente les étapes d'un procédé de 5 détection conforme à l'invention. DESCRIPTION DETAILLEE DE L'INVENTION 10 La figure 1 représente de manière simplifiée et schématique un système informatique 1 pour l'exécution d'une application ou d'un programme. Ce système comprend une plate-forme matérielle HW. Il peut 15 s'agir d'un ordinateur, d'un serveur, ou d'une manière générale d'un dispositif de calcul ou d'une pluralité de dispositifs de calcul interconnectés entre eux, tels qu'un téléphone mobile ou une tablette relié à un serveur. 20 La plate-forme matérielle HW est munie d'un système d'exploitation OS ou d'une pluralité de tels systèmes si la plate-forme matérielle HW est constituée d'une pluralité de dispositifs de calcul hétérogènes. Dans ce dernier cas, les systèmes d'exploitation peuvent être identiques ou différents 25 entre eux. Dans le cadre de la présente demande, on désignera par « application » ou « programme », une collection d'instructions liées entre elles et formant un programme qui ne s'exécute que 30 sur un seul dispositif de calcul, même si ce programme peut être interfacé et communiquer avec d'autres programmes s'exécutant sur d'autres dispositifs de calcul pour former une solution complète. 35 Une application APP s'exécutant sur la plate-forme matérielle HW est matérialisée par un fichier exécutable qui peut être mémorisé dans un des moyens de stockage du système 1. 8 Le fichier exécutable peut être issu de la compilation de la forme source de l'application, c'est-à-dire de la forme dans laquelle l'application a été conçue et exprimée à travers un langage particulier de programmation. L'application APP dans sa 5 forme exécutable peut comprendre un environnement d'exécution RI, intégré au programme exécutable au moment de sa compilation. Alternativement, l'environnement d'exécution RI peut être distinct de l'application dans sa forme exécutable, cet environnement d'exécution RI formant alors une couche 10 intermédiaire entre la plate-forme matérielle HW, le système d'exploitation OS et l'application APP. Dans tous les cas, l'environnement d'exécution assure un certain degré d'indépendance entre l'application APP en tant que telle et la plate-forme matérielle HW et/ou le système d'exploitation OS sur 15 lequel l'application APP est appelée à s'exécuter. Cet environnement d'exécution RI peut consister en une machine virtuelle Java par exemple où en une bibliothèque de fonctions standards qui s'intègre à l'application au moment de sa compilation. 20 Une application APP peut être paramétrée par un fichier de configuration CFG, enregistré sur un moyen de stockage de la plate-forme matérielle HW. Ce paramétrage ne nécessite pas la recompilation de l'application. Un tel fichier de configuration 25 comporte les valeurs des paramètres de l'application, ces valeurs pouvant être éditées simplement. Au cours de l'exécution de l'application, généralement à son démarrage, celle-ci consulte le fichier de configuration afin de déterminer la valeur de ses paramètres. 30 Le système informatique 1 de la figure 1 comprend également un ensemble de fonctions logicielles LB, PRG susceptibles d'être appelées par des applications s'exécutant sur la plate-forme matérielle. Ces fonctions peuvent faire partie du système 35 d'exploitation ou être indépendantes de celui-ci. Elles peuvent être regroupées au sein d'une bibliothèque de fonctions LB (« Library » selon le terme anglo-saxon généralement employé) 9 contenant du code exécutable et auxquelles une application est reliée dynamiquement pendant son exécution. Les fonctions peuvent également être implémentées par d'autres applications PRG susceptibles de s'exécuter sur la plate-forme matérielle. 5 Dans tous les cas, l'application APP peut faire appel à ces fonctions à travers une interface de programmation applicative API (« API » pour « Application Programing Interface » selon le terme anglo-saxon consacré). 10 Dans le cas de la présente description, le système informatique 1 comprend au moins une fonction cryptographique, et plus généralement une pluralité de telles fonctions. Par souci de clarté, on rappelle que les fonctions 15 cryptographiques mises à disposition d'une application fournissent un ensemble de services qui peuvent être répartis selon plusieurs catégories : - Catégorie de gestion de clés: il s'agit de fonctions 20 permettant la génération, le stockage, le partage des clés selon différents formats d'encodage/décodage, permettant ainsi d'assurer le secret ou l'authenticité d'un contenu ; 25 - Catégorie d'exploitation des clés : il s'agit des fonctions permettant effectivement de chiffrer/déchiffrer, signer ou vérifier la signature d'un contenu ; 30 - Catégorie purement informationnelle : il s'agit des fonctions permettant d'accéder à des informations sur les fonctions cryptographiques elles-mêmes, telles que leurs disponibilités ou leurs états d'installation. 35 À titre d'exemple, on connaît la bibliothèque cryptographique « open SSL », disponible pour de nombreuses 10 plates-formes et environnement, et permettant de mettre en oeuvre un grand nombre de méthodes de chiffrement (AES, DES,_ ), de fonctions de hachage cryptographique (MD5, SHA-1,...), et de protocoles de cryptographie à clé publique - privé (RSA, DSA,...). 5 La bibliothèque « open SSL » fournie également les fonctions mettant en oeuvre des protocoles de communication sécurisée, tels que le protocole TSL (« Transport Security Layer ») ou SSL (« Secure Socket Layer »), ces protocoles faisant appel aux 10 fonctions cryptographiques précités. On notera à ce propos que plus généralement, une application peut faire appel à une fonction cryptographique directement ou indirectement à travers l'appel à une fonction intermédiaire 15 faisant elle-même appel à une fonction cryptographique. Comme on l'a précisé en introduction de cette demande, le bon usage des fonctions cryptographiques est censé permettre de prévenir l'incorporation de failles de sécurité dans une 20 application en cours de développement. Les failles, lorsque celles-ci existent, peuvent être mis à profit par un tiers pour accéder à, ou altérer, des informations qui devraient être maintenues confidentielles et/ou intègres. Il est donc important de pouvoir détecter les failles de sécurité d'une application 25 avant sa mise en production en vue de les éliminer. Comme on l'a vu également, on ne peut garantir, à l'issue de la phase de développement qu'une application ne recèle pas de telles failles. 30 La présente invention vise donc à proposer un procédé non intrusif de détection des failles de sécurité d'une telle application. En référence à la figure 2, un procédé conforme à 35 l'invention comprend une première étape 51 dans laquelle on installe et on exécute une version exécutable et non instrumentalisée d'un programme à évaluer dans un système 11 informatique 1. Ce système informatique 1 est par exemple conforme à celui qui vient d'être décrit en relation avec la figure 1. 5 Par « non instrumentalisée », on signifie que le programme informatique APP évalué est précisément celui qui sera utilisé en production. Il n'est muni d'aucun artifice, ajout ou code spécifique qui viserait à détecter des failles de sécurité ou plus généralement à faciliter son débogage. On s'assure ainsi 10 que le programme s'exécute dans des conditions tout à fait identiques ou similaires à celles qu'il rencontrera dans son environnement de production. En d'autres termes, on s'assure que la séquence d'instructions s'exécutera de manière identique ou très similaire au cours du procédé de détection des failles 15 qu'au cours de son fonctionnement normal, en production. De plus, il est possible de mettre en oeuvre le procédé sans disposer de la version source du programme et/ou sans disposer des droits permettant de modifier la version disponible du programme. 20 Un procédé conforme à l'invention comporte également une deuxième étape S2, postérieure à la première, dans laquelle au cours de l'exécution du programme, on enregistre dans un fichier de traçage les modalités d'appel à au moins une fonction 25 cryptographique disponible dans le système. Préférentiellement, et pour rendre le procédé efficace, les modalités d'appel d'une pluralité de fonctions cryptographiques sont enregistrées. Plusieurs approches sont possibles pour permettre cet 30 enregistrement. Selon une première approche, un programme de traçage indépendant et distinct du programme sous test, peut s'exécuter sur le système informatique concourrament au programme sous 35 test. Le programme de traçage peut par exemple prendre la forme d'un agent qui est activé par le système d'exploitation ou par l'environnement d'exécution du programme sous test, lorsque 12 celui-ci accède à une fonction cryptographique disponible dans le système, par appel à une API. L'agent, au cours de son exécution, peut procéder à l'enregistrement dans le fichier de traçage des modalités d'appel de chaque fonction 5 cryptographique. Selon une approche alternative ou complémentaire, les fonctions cryptographiques elles-mêmes peuvent être instrumentalisées pour procéder, au moment de leurs appels, à 10 l'enregistrement des modalités d'appel dans le fichier de traçage. Instrumentaliser la fonction peut être réalisé au niveau de la fonction elle-même, au niveau d'une bibliothèque de telles fonctions ou au niveau des interfaces permettant d'accéder à ces fonctions. On aura dans ce cas prévu, au cours 15 d'une étape préliminaire SO du procédé, le remplacement dans le système informatique d'une partie au moins des fonctions cryptographiques originelles (ou des bibliothèques de fonctions cryptographiques ou des interfaces permettant d'accéder à ces fonctions) par une version instrumentalisée, c'est à dire 20 comportant des instructions spécifiques pour procéder à l'enregistrement dans le fichier de traçage des modalités d'appel. Au cours de cette étape d'enregistrement S2, pour des 25 raisons d'efficacité, on cherche à enregistrer au juste nécessaire dans le fichier de traçage les informations relatives à l'appel. Ainsi, de manière très avantageuse, on n'enregistre pas d'informations lorsque la fonction cryptographique appelée est de nature informationnelle uniquement. En d'autres termes, 30 seuls les appels aux fonctions cryptographiques tombant dans les catégories de gestion et d'exploitation sont enregistrés dans le fichier de traçage. Au cours de l'étape d'enregistrement, les modalités d'appel 35 qui sont enregistrées dans le fichier traçage peuvent comprendre les informations suivantes : 13 - optionnellement, une information d'horodatage de l'appel ; - le nom de la fonction cryptographique appelée ; 5 - les arguments de la fonction ; - le nom du module appelant cette fonction ; - la réponse retournée par la fonction. 10 Lorsqu'un argument de la fonction ou la réponse retournée par la fonction est un pointeur de mémoire, on accède à la mémoire désignée par ce pointeur pour enregistrer dans le fichier de traçage l'élément pointé plutôt que le pointeur lui- 15 même. On dispose ainsi dans ce fichier d'informations complètes et utiles qui pourront être ultérieurement exploitées. Les informations que l'on vient de lister sont généralement accessibles dans la pile d'exécution associée au programme sous 20 test. Il est possible d'obtenir une représentation de cette pile d'exécution, appelée trace d'appel, à l'aide de fonctions disponibles dans le système informatique, par exemple sous la forme d'un service du système d'exploitation ou d'une fonction de bibliothèque. Le programme de traçage et/ou 25 l'instrumentalisation des fonctions cryptographique fait donc appel à un tel service ou une telle fonction pour accéder à la trace d'appel et enregistrer dans le fichier de traçage les informations relatives aux modalités d'appel des fonctions cryptographiques. En d'autres termes, l'étape d'enregistrement 30 comprend l'obtention d'une partie au moins de la pile d'exécution (ou une représentation de celle-ci) lorsque la fonction cryptographique est appelée par le programme sous test APP. 35 Cette étape d'enregistrement est poursuivie tant que le programme sous test APP s'exécute dans ou sur le système informatique 1. On fera en sorte que cette exécution se réalise 14 suivant des scénarios les plus variées possible afin de solliciter au mieux le programme APP et d'enregistrer dans le fichier de traçage des appels multiples et représentatifs du fonctionnement du programme dans son environnement de 5 production. À l'issue de cette étape d'enregistrement S2, on dispose d'un fichier de traçage recensant l'ensemble des appels aux fonctions cryptographiques pertinentes, et de leurs modalités, sont donc très représentatives n'ait exécutable de été modifié production. forme en tant que tel 10 au cours approches programme dans sa récoltées 15 normal de de l'exécution du programme. Contrairement aux que le ou instrumentalisé Les informations du fonctionnement connues, ces informations sont obtenues sans ce programme. Lorsque le programme APP consulte un fichier de configuration CFG pour ajuster son comportement à des paramètres définis par un utilisateur, ce paramétrage est pris en compte dans la collecte d'information qui se réalise au cours de cette étape d'enregistrement S2. 20 Le procédé conforme à l'invention tire profit du fichier de traçage ainsi constitué pour procéder à son analyse et y déceler des failles potentielles de sécurité. Plus précisément, le procédé comprend une troisième étape S3, qui est 25 préférentiellement postérieure à l'étape d'enregistrement S2, d'analyse du fichier de traçage à l'aide d'une base de règles permettant de détecter les appels aux fonctions cryptographiques qui sont susceptibles de former une faille de sécurité. 30 Ainsi, le procédé conforme à l'invention peut mettre en oeuvre un moteur d'inférence logiciel apte à détecter des failles de sécurité à partir d'une base de faits, dérivée du fichier de traçage, et d'une base de règles. La base de règles permet de représenter quel fait ou quelle combinaison de faits forme une 35 faille potentielle de sécurité. Le moteur d'inférence peut s'exécuter sur le système informatique 1 décrit précédemment et qui a servi à établir le fichier de traçage, mais il peut 15 également s'exécuter sur un autre dispositif de calcul de manière tout à fait indépendante de ce système informatique 1. Selon un mode mis en oeuvre particulier de l'invention, cette 5 étape d'analyse comprend (ou est précédée) d'une première sous étapes dans laquelle on répertorie au sein du fichier de traçage les objets cryptographiques qui ont été créés ou manipulés (comme argument ou comme résultat d'une fonction) au cours du fonctionnement du programme, pendant l'étape d'enregistrement. 10 Ces objets peuvent correspondre à des clés de cryptage, des mots de passe, un contenu encrypté ou un contenu à encrypter_ Les objets recensés forment alors les faits constituant la base de faits alimentant le moteur d'inférence. 15 Chaque règle de la base de règles peut être définie par une ou une pluralité de prémisses, cherchant à qualifier un fait (c'est à dire un objet cryptographique), et par une conclusion dérivable des prémisses, cette conclusion permettant de détecter une faille potentielle, sa nature et/ou son degré de pertinence. 20 À titre d'exemple, une règle particulièrement simple composée d'une unique prémisse, peut correspondre à la règle suivante : si la longueur d'une clé de chiffrage est inférieure à 16, alors détecter une faille potentielle de niveau trois 25 dénommée « clé de chiffrage trop courte ». À titre d'exemple complémentaire, une règle plus complexe composée d'une pluralité de prémisses peut s'exprimer de la manière suivante : Si une clé de chiffrage est utilisée pour une 30 étape de chiffrement ; et si la même clé de chiffrage est utilisée pour une étape de signature, alors détecter une faille potentielle de sécurité de niveau un et dénommée « chiffrage signature ». 35 La base de règles peut être constituée à partir de plusieurs sources. Il peut s'agir par exemple d'incorporer sous forme de règles d'inférence des recommandations ou des bonnes pratiques 16 associées à l'usage d'une fonction ou d'une bibliothèque de fonctions. La base de règles est évolutive, elle peut être complémentée au fur et à mesure de la mise à jour des règles d'usage des bibliothèques, pour prendre en compte la découverte 5 de nouvelles failles potentielles. À ce titre, la base de règles employées peut être différente selon la nature de la bibliothèque de fonctions qui est déployée dans le système informatique, ou selon la version de cette 10 bibliothèque. Ainsi, selon un aspect particulièrement avantageux, un procédé conforme à l'invention comprend l'enregistrement, par exemple dans le fichier de traçage ou dans un fichier de travail distinct, du numéro de version de la fonction cryptographique ou de la bibliothèque de fonctions 15 cryptographiques. Cet enregistrement peut être réalisé avant ou après l'étape d'enregistrement. La base de règles employée au cours de l'étape d'analyse peut être choisie parmi une pluralité de bases de règles, selon le numéro de version. Alternativement, ce numéro de version peut constituer un fait auquel peut 20 s'appliquer une règle du type : si la version est égale à 1.0 et une clé est initialisée à 0 alors détecter une faille potentielle de sécurité de niveau un et dénommée « initialisation dangereuse ». 25 Au cours de l'étape d'analyse, on applique systématiquement les règles de la base de règles aux faits et aux combinaisons de faits formant la base de faits. A l'issue de cette étape, on dispose donc d'une liste de failles potentielles. 30 Selon un mode préféré de mise en oeuvre du procédé de l'invention, la troisième étape d'analyse S3 est suivie, ou comprend, une étape de filtrage S4 des failles potentielles détectées. 35 Cette étape de filtrage vise à limiter l'émission de fausses alertes positives. Elle peut s'appuyer sur une liste d'exceptions préétablie (et paramétrable) de manière à éliminer 17 de la liste des failles potentielles détectées par la base de règles celles qui sont répertoriées dans la liste d'exceptions. Bien entendu l'invention n'est pas limitée aux modes de 5 mise en oeuvre décrits et on peut y apporter des variantes de réalisation sans sortir du cadre de l'invention REVENDICATIONS1. Procédé de détection non intrusif des failles de sécurité d'un programme informatique (APP), le procédé comportant les étapes suivantes - (Si) installer et exécuter une version exécutable et non instrumentalisée du programme (APP) dans un système informatique (1), le système informatique comprenant au moins une fonction cryptographique susceptible d'être appelée par le programme; - (S2) au cours de l'exécution du programme, enregistrer dans un fichier de traçage les modalités d'appels à la fonction cryptographique ; - (S3) après l'exécution du programme, analyser le fichier de traçage à l'aide d'une base de règles pour détecter des appels à la fonction cryptographique susceptibles de former une faille de sécurité. 2. Procédé selon la revendication précédente dans lequel l'enregistrement dans un fichier de traçage est mise en oeuvre par un programme de traçage s'exécutant concourrament avec le programme informatique. 3. Procédé selon l'une des revendications précédentes dans lequel 25 la fonction cryptographique est instrumentalisée pour permettre l'enregistrement de ses modalités d'appel. 4. Procédé selon la revendication précédente comprenant une étape préliminaire (S0) de remplacement d'une fonction 30 cryptographique originelle du système informatique par la fonction cryptographique instrumentalisée. 5. Procédé selon l'une des revendications précédentes dans lequel l'étape d'enregistrement comprend l'obtention d'une partie au 35 moins de la pile d'exécution lorsque la fonction cryptographique est appelée par le programme. 19 6. Procédé selon l'une des revendications précédentes dans lequel le système (1) comprend une pluralité de fonctions cryptographiques et seules les modalités d'appel aux fonctions cryptographiques de gestion et d'usage sont enregistrées dans 5 le fichier de traçage. 7. Procédé selon l'une des revendications précédentes dans lequel les modalités d'appel de la fonction cryptographique enregistrées dans le fichier de traçage comprennent l'une au 10 moins des modalités choisies dans le groupe constitué du nom de la fonction cryptographique, des arguments de la fonction cryptographique, du nom d'un module appelant la fonction cryptographique, de l'horodatage de l'appel à la fonction cryptographique, et de la réponse retournée par la fonction 15 cryptographique. 8. Procédé selon l'une des revendications précédentes dans lequel l'étape d'analyse (S3) met en oeuvre un moteur d'inférence. 20 9. Procédé selon l'une des revendications précédentes, dans lequel l'étape d'analyse (S3) est précédée du recensement dans le fichier de traçage des objets cryptographiques. 10. Procédé selon l'une des revendications précédentes comprenant une étape d'enregistrement du numéro de version de la fonction cryptographique. 11. Procédé selon l'une des revendications précédentes comprenant une étape de filtrage (S4) des failles de sécurités détectées. 12. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé de détection non intrusif des failles de sécurité d'un programme informatique selon l'une des revendications 1 à 11, lorsque le programme d'ordinateur est exécuté sur un ordinateur.