FR2974207A1 - Procede et systeme de securisation d'un logiciel - Google Patents

Abstract

Procédé de sécurisation d'un logiciel originel mettant en œuvre un secret comprenant: • partitionner (1) le logiciel en N éléments, N étant un entier strictement supérieur à 1 ; • générer (3) M procédures sécurisées, M étant un entier supérieur ou égal à N, par, pour chaque procédure : • tirage aléatoire d'une fonction parmi une bibliothèque de fonctions ; • sélection d'un des N éléments ou de l'ensemble vide ; • combinaison de la fonction tirée aléatoirement et de l'élément sélectionné quand la sélection n'est pas l'ensemble vide ; de sorte que chaque élément est combiné dans une seule procédure et que tous les éléments sont combinés ; • modifier chaque procédure par introduction de balises de direction contrôlant les appels des procédures les unes par les autres et de balises contrôlant l'exécution des éléments ; • concaténer (9) les M procédures en un logiciel sécurisé pour mettre en œuvre le secret.

Description

PROCEDE ET SYSTEME DE SECURISATION D'UN LOGICIEL

La présente invention concerne un procédé, un système et un produit programme d'ordinateur de sécurisation d'un logiciel originel mettant en oeuvre un secret.

Le développement des services en ligne au premier rang desquels le paiement rend nécessaire la mise au point de systèmes d'authentification et de signature électronique sûrs et pouvant être mis en oeuvre de façon extrêmement économique à très grande échelle. L'une des approches pour répondre à cet objectif n'est pas technique mais économique : elle consiste à répartir entre « co-accepteurs » les investissements dans des systèmes de sécurité prouvée. De tels systèmes sont, par exemple, des certificats électroniques sur support physique ou des générateurs de mots de passe à usage unique incluant un élément de sécurité matériel (« secure element »), bien que ces derniers ne permettent pas la signature électronique, ne soient pas immunes à certains types d'attaques (hameçonnage, homme du milieu), et de part leur nature symétrique, nécessitent que chaque co-accepteur fasse confiance à tous les autres (ou à un seul, commun), c'est-à-dire nécessite la mise en place d'un cercle de confiance. Au-delà de la difficulté d'organisation, cette approche économique se heurte à la difficulté de répartir les investissements entre coaccepteurs ; dans le cas général, cette répartition ne se fait pas et le système d'authentification et de signature électronique reste un système `privé', intégralement financé par un accepteur unique en ayant les moyens, et pour ses seuls besoins.

Une approche alternative est technique. Elle consiste à mettre au point des dispositifs de sécurisation pour des systèmes d'authentification et de signature électronique possédant un coût marginal par utilisateur faible voire nul et pour lesquels il n'y a, par construction, pas de problèmes de répartition des coûts d'équipement des utilisateurs.

Les exemples de systèmes possédant un coût marginal par utilisateur faible sont ceux où le moyen d'authentification et de signature électronique est une application (et / ou des données) stockée sur un support déjà possédé par l'utilisateur, tel qu'une clé USB, un téléphone mobile, un ordinateur, un baladeur, etc., et exécutée directement sur ce support ou sur un équipement lui étant connecté et possédant un environnement d'exécution d'applications, tel qu'un téléphone mobile ou un ordinateur. De telles applications et données peuvent en effet être produites et distribuées à un coût marginal quasiment nul. La difficulté majeure de cette approche est la conception des dispositifs de sécurisation, puisque de telles applications et données sont sensibles à de nombreux cas d'attaques. Les supports de stockage et d'exécution sont en effet particulièrement exposés à des vers et programmes malicieux capables d'en prendre le contrôle ou d'y lire les informations les mieux dissimulées. A titre d'exemple, l'utilisation de certificats logiciels stockés dans les navigateurs Internet ou sur un support de stockage non physiquement protégé (disque ou clé de stockage USB, ...) est déconseillée pour l'authentification sur des services bancaires ou de paiement en ligne, les clés privées de tels certificats pouvant être dérobées imperceptiblement par un programme malicieux. Un second exemple est celui de mécanismes consistant à reconnaître le support de stockage ou d'exécution grâce à ses caractéristiques uniques (numéro de série, numéro de processeur, numéro de carte réseau, etc.) : la lecture de ces caractéristiques nécessite en effet l'exécution - généralement locale - d'un programme ou d'un script qu'il est aisé de modifier et / ou de contourner pour permettre l'usurpation d'identité. Un troisième exemple enfin est celui d'applications de génération de mots de passe à usage unique, que ces applications soient exécutées sur le terminal d'accès au service en ligne ou dans un autre environnement, et que ces applications soient connectées ou non au serveur d'authentification. En effet, ces applications mettent en oeuvre un ensemble de secrets, de façon symétrique voire asymétrique (clé privée) ; l'accès à cet ensemble de secrets, parfois « cachés » mais non protégés par un élément matériel, permet d'usurper l'identité de l'utilisateur ; cela peut généralement être réalisé sans expertise particulière grâce à des moyens rendus disponibles à faible coût sur le réseau internet.

Dans ces trois exemples représentatifs de l'état de l'art, l'accès respectivement aux données, à l'application, ou à l'application et aux données, suffit à contourner la sécurité du système d'authentification et de signature électronique. Ces systèmes sont généralement protégés par la saisie d'une information supplémentaire (« code PIN serveur ») par l'utilisateur sur le terminal où est exécutée l'application ; or, cette information n'est pas plus hors de portée que ne le sont l'application et les données, du fait de techniques dites de « key-logging » ou « screen-logging » (observation des frappes clavier ou clic souris sur des zones de l'écran). Par ailleurs, dans le cas d'applications de génération de mots de passe à usage unique de conception classique, l'observation d'un seul mot de passe valide suffit en cas d'accès au support de stockage des données à reconstruire la valeur du code PIN. Ainsi, les systèmes d'authentification et de signature électronique présentant un coût marginal par utilisateur sont-ils largement vulnérables et ne peuvent-ils être mis en oeuvre, pour les services « sensibles » où ils sont rendus nécessaires, sans dispositif de sécurisation convenablement conçu. Un exemple de tel dispositif de sécurisation est présenté dans la demande de brevet FR2937204 au nom du déposant : il s'agit d'un moyen d'authentification et de signature électronique exécuté sur un autre équipement que le terminal d'accès au service, et par ailleurs non connecté - c'est-à-dire ne communiquant pas avec le serveur. Ce dispositif ne fait pas d'hypothèse sur l'environnement d'exécution hormis qu'il n'est pas accessible à distance, c'est-à-dire que l'on ne peut y lire les secrets mis en oeuvre qu'en ayant physiquement accès à son support. Par exemple, une application s'exécutant dans une machine virtuelle sur un environnement `mono-tâche' d'un téléphone mobile vérifie ces hypothèses de façon satisfaisante, mais ce n'est plus le cas dès lors qu'il s'agit d'une plate-forme `ouverte' ou `multitâche' comme celle d'un ordinateur ou d'un « smartphone », et encore moins lorsque cette plate-forme est elle-même le terminal d'accès aux services. Il serait donc particulièrement avantageux de disposer de dispositifs de sécurisation étendant ou complétant ceux mentionnés ci-dessus, permettant l'emploi sûr de systèmes d'authentification et de signature électronique pouvant être mis en oeuvre de façon extrêmement économique à grande échelle. Pour résoudre un ou plusieurs des inconvénients ou insuffisances cités précédemment, un procédé de sécurisation d'un logiciel originel mettant en oeuvre un secret, comprend : - partitionner le logiciel en N éléments, N étant un entier strictement supérieur à 1 ; - générer M procédures sécurisées, M étant un entier supérieur ou égal à N, par, pour chaque procédure : - tirage aléatoire d'une fonction parmi une bibliothèque de fonctions ; - sélection d'un des N éléments ou de l'ensemble vide ; - combinaison de la fonction tirée aléatoirement et de l'élément sélectionné quand la sélection n'est pas l'ensemble vide ; de sorte que chaque élément est combiné dans une seule procédure et que tous les éléments sont combinés ; - modifier chaque procédure par introduction de balises de direction contrôlant les appels des procédures les unes par les autres et de balises contrôlant l'exécution des éléments ; - concaténer les M procédures en un logiciel sécurisé apte à être installé et exécuté sur une plateforme d'exécution non sécurisée pour mettre en oeuvre le secret. Des caractéristiques ou des modes de réalisation particuliers, utilisables seuls ou en combinaison, sont : - les balises de direction contrôlant les appels des procédures les unes par les autres comportent : - pour chaque procédure, une sélection d'une pluralité de procédures appelables en fonction d'un paramètre d'exécution ; - des conditions non-prédictibles fonctions de paramètre d'exécutions, fixant l'exécution de certaines des procédures sélectionnées ; - une suite mathématique définie par un premier terme et une fonction de récurrence définissant un argument d'appel de chaque procédure tel que si une procédure a comme argument d'appel l'élément de la suite d'indice n, alors les procédures appelées par celle-ci ont comme argument d'appel l'élément de la suite d'indice n+1 ; - la suite mathématique est la suite de Syracuse ; - la sélection des deux procédures appelables est basée sur une fonction uniforme du paramètre d'exécution assurant que la probabilité d'appel pour chaque procédure est substantiellement identique ; - les balises contrôlant l'exécution des éléments comportent des appels vers des éléments extérieurs à l'élément contenant l'appel et, dans les éléments extérieurs, des repères de destination de ces appels ; - les fonctions de la bibliothèque de fonction sont des fonctions de transformation modifiant la valeur d'au moins une variable ; - le logiciel originel étant un logiciel mettant en oeuvre un procédé cryptographique nécessitant au moins un secret, le secret est fourni par la variable modifiée par les fonctions de transformation associées aux procédures ; - le secret étant pour partie calculé et pour partie dépendant d'un secret non-calculé dont l'emplacement est dynamique et calculé, les fonctions de transformation modifient par leurs exécutions une seconde variable, la seconde variable étant un pointeur vers l'emplacement dynamique ; - les fonctions de transformation modifient par leurs exécutions une troisième variable, la troisième variable étant utilisée par le logiciel pour crypter et décrypter au moins un des éléments ; - le premier terme de la suite est calculé à partir d'un nombre aléatoire utilisé lors de la génération d'un mot de passe à usage unique. Dans un second aspect de l'invention, un produit programme d'ordinateur comprend des instructions de code de programme pour l'exécution du procédé ci-dessus lorsque le programme est exécuté sur un ordinateur. Dans un troisième aspect de l'invention, un système de sécurisation d'un logiciel originel mettant en oeuvre un secret, comprend un calculateur adapté pour exécuter le procédé décrit ci-dessus. L'invention sera mieux comprise à la lecture de la description qui suit, faite uniquement à titre d'exemple, et en référence aux figures en annexe dans lesquelles : - la figure 1 est un ordinogramme d'un procédé selon un mode de réalisation de l'invention ; et - la figure 2 est un ordinogramme d'une étape particulière du procédé de la figure 1. On décrit tout d'abord un procédé P permettant de dériver un code CF* du code CF. Le procédé P permet d'obtenir un code CF* unique pour chaque utilisateur et environnement EE, ou pour un sous-ensemble réduit d'utilisateurs, de telle sorte qu'en observant les codes CF* dont dispose un nombre significatif d'utilisateurs, la probabilité que deux de ces codes soient identiques ou similaires est nulle ou très faible. Le procédé P peut être implémenté par de nombreux dispositifs (« 20 outils de développement »), de préférence adaptés pour conférer une capacité importante d'automatisation au procédé P. La première étape du procédé P consiste , étape 1 de la Figure 1, à définir une partition aléatoire et plus ou moins arbitraire du code CF en segments s,, s2, ..., sN où N est un entier strictement supérieur à 1 tiré 25 aléatoirement. Cette partition peut être effectuée sur le code source de CF ou bien sur le code exécutable en respectant quelques règles qui seront précisées dans la suite de ce document. La seconde étape 3 du procédé P consiste à créer le code source de M procédures Sy;, M étant un entier supérieur ou égal à N. 30 Pour cela, on procède, étape 5 de la Figure 2, au tirage aléatoire d'une matrice TF à coefficients TF;i entiers positifs ou nuls, cette matrice possédant autant de lignes qu'il y a de fonctions Sy. Les coefficients TF;i de TF font référence à une bibliothèque L de fonctions tf, c'est-à-dire que pour un indice i donné, les coefficients TF;i désignent par leur valeur les fonctions de la bibliothèque L qui seront employées dans Syi, zéro indiquant l'absence de fonction. Il convient de noter que la librairie L contient préférentiellement un nombre de fonctions beaucoup plus important qu'il n'y a de fonctions Sy. La nature et le rôle de ces fonctions tf seront décrits ci-dessous après la fin de la description du procédé P. Le code de Syi est alors constitué, étape 7, en combinant le code des procédures tf désignées par les coefficients TFij et celui du segment s6(i) où (5 est une permutation des indices tirée aléatoirement. La troisième et dernière étape 9, en référence à la Figure 1, du procédé P consiste à finaliser le code CF* en introduisant dans le code des fonctions Sy d'une part des conditions « d'aiguillage » c'est-à-dire contrôlant les appels récursifs des fonctions Sy les unes par les autres, d'autre part des balises contrôlant l'exécution des segments si. Les appels récursifs, tout d'abord, sont définis et contrôlés par trois 15 types de paramètres : - deux permutations d'indices, 6inc et (5cond tirées aléatoirement et définissant lors de l'exécution quelles fonctions Syginc(i,x) et Syacond(i,x) sont appelées par Syi, où x représente des paramètres de l'exécution ; en tant que fonctions de x, 6inc et 6cond sont 20 préférentiellement uniformément réparties, c'est-à-dire que la probabilité d'appel est la même pour chaque fonction Sy ; - une condition ci(x) tirée aléatoirement, fonction de paramètres de l'exécution x et définissant lors de l'exécution si Syacond(i,x) est effectivement appelée par Syi (appel conditionnel), tandis que 25 l'appel à Syginc(i,x) est inconditionnel ; - une suite mathématique (Un) définie par son premier terme Uo et sa relation de récurrence f définissant Un+1 comme f(Un), utilisée de la façon suivante : si Syi a été appelée avec Un comme argument, Syainc(i,x) et Syacond(i,x) sont appelées avec f(Un), c'est-à-dire Un+1 30 comme argument. Les balises, ensuite, permettent de contrôler l'exécution du segment s6(i) dans la fonction Syi. En effet, l'ordre d'exécution des Syi n'est pas prédictible lors de la mise en oeuvre du procédé P, d'une part parce que cet ordre dépend de paramètres et conditions d'exécution, d'autre part parce qu'il dépend largement du tirage aléatoire de Uo effectué lors de chaque nouvelle exécution. On conçoit donc aisément qu'il soit nécessaire de contrôler l'exécution des segments de CF, afin qu'en termes de fonctionnalités, CF soit incluse dans CF*, c'est-à-dire que l'exécution de CF* réalise au moins l'authentification ou la signature électronique et/ou les autres fonctionnalités qui sont l'objet de CF. Dans le cas particulier où l'exécution du code CF peut se faire en exécutant séquentiellement, intégralement, et une seule fois chaque segment si, le rôle des balises consiste simplement à ordonnancer ces exécutions, c'est-à-dire faire en sorte que si soit exécuté une seule fois, après s;_, et avant si,l. Il suffit dans ce cas, lors de chaque exécution de Sy;, de vérifier si les conditions préalables à l'exécution de s6(;) sont vérifiées, c'est-à-dire si s6(i)_1 a déjà été exécuté et si s6(;) ne l'a pas encore été. Cette vérification se fait préférentiellement en fixant la valeur d'une balise après exécution de s6(i)_1 à une valeur servant de condition d'entrée à l'exécution de s6(i). Dans le cas plus général où l'exécution du code CF nécessite d'exécuter une ou plusieurs fois les segments si, éventuellement partiellement et de façon déterminée en partie par les conditions d'exécution elles-mêmes, les balises de contrôle sont généralisées pour permettre une exécution multiple, partielle et/ou débutant en cours de segment. De la même façon que précédemment, la valeur d'une balise est fixée en fin de segment si ou au point d'un appel d'un segment extérieur à si ; cette balise définit à la fois quel segment si doit être exécuté et le point de début d'exécution, c'est-à-dire le début du segment si ou la destination de l'appel. Ces balises sont ainsi une représentation de la structure des appels entre différentes zones de CF et pas uniquement de la partition de CF. L'insertion des balises de contrôle nécessite une adaptation supplémentaire du dispositif implémentant le procédé P. Il convient de remarquer qu'un élément important dans la mise en oeuvre du procédé P pour la génération du code CF* est de garantir que le code CF est intégralement exécuté lorsqu'on exécute CF*. Définir quelles classes de codes CF s'exécutent intégralement, c'est-à-dire ont un début et une fin, est un problème ouvert. On ne se posera donc la question concernant l'exécution intégrale de CF « plongé dans CF* » que si l'on suppose que le code CF lui-même s'exécute intégralement lorsqu'il est exécuté de façon autonome ; remarquons de plus que si l'on restreint l'application aux opérations permettant le calcul d'un code d'authentification ou d'une signature électronique le code CF résultant a bien un début et une fin en un temps fini sous réserve de saisie du code PIN par l'utilisateur.

La question pour un tel code, une fois partitionné en N segments si, est de savoir si tous ces segments ou fractions de segments s'exécuteront un nombre suffisant de fois, alors que l'on ne sait pas prédire de façon déterministe l'exécution des fonctions Sy contenant ces segments. Il suffit pour cela que le nombre d'appels récursifs des fonctions Sy entre elles soit suffisamment grand et que toutes les fonctions Sy aient la même probabilité d'être appelées. La seconde condition suffisante a été imposée dans la définition de ainc et acond. La première condition suffisante s'apprécie notamment selon le choix de la suite (Un) et de son premier terme U0.

De nombreuses variantes existent, par exemple choisir pour (Un) la suite de Syracuse définie par la relation de récurrence suivante : - Un+1 vaut Un/2 si Un est pair - Un+1 vaut 3Un+1 si Un est impair et différent de 1 - Un+1 vaut 1 si Un vaut 1 La particularité de cette suite est qu'il existe une conjecture selon laquelle elle converge en un nombre fini d'étapes vers 1 quel que soit le premier terme. Cela permet une condition d'arrêt simple du code CF* : il suffit d'arrêter de nouveaux appels récursifs - et donc de commencer à « remonter » la pile utilisée pour les appels récursifs - dès lors que Un a atteint la valeur 1.

De plus, des estimations du nombre X d'étapes nécessaires selon Uo pour la convergence de cette suite sont disponibles. Si a est la probabilité - supposée uniforme - que la condition ci soit vérifiée et si X désigne le nombre d'étapes nécessaires pour la convergence de la suite (Un) choisie - si elle converge, le nombre d'appels récursifs de fonctions Sy est de l'ordre de ((1 +E)X-1)/E. Un moyen « auto-adaptatif » de répondre à la question sur l'exécution intégrale de CF* est donc de fixer l'ordre de grandeur de Uo tel que X soit important (préférentiellement au moins plusieurs dizaines) et de faire décroître c au fur et à mesure que les segments si sont exécutés.

Ainsi, le nombre d'appels de fonctions Sy restant potentiellement à effectuer est gigantesque (-2X) tant qu'aucun segment si n'a été exécuté, alors qu'il décroît fortement au fur et à mesure que les segments sont exécutés et qu'il devient inférieur à x lorsque tous les segments ont été exécutés, le nombre total d'appel étant de l'ordre de N.X. Cette méthode empirique fonctionne pour des classes de codes CF où l'on connaît a priori une bonne approximation du nombre de segments devant être exécutés. Lorsque ce n'est pas le cas, la condition d'arrêt des appels récursifs est préférentiellement complétée avec une balise contrôlant la fin de l'exécution de CF. Enfin pour parachever la mise en oeuvre du procédé P, on choisit quelle fonction Sy est initialement appelée. Le procédé P décrit précédemment permet donc d'obtenir un code CF* fonctionnellement au moins équivalent à CF, CF* étant dérivé de CF par le tirage aléatoire d'un nombre restreint de paramètres, principalement N, TF, 6inc, acond, ci, et les balises de contrôle d'exécution des segments s,, ... , sN. La combinatoire propre à ces paramètres permet de garantir lorsque cela est nécessaire dans le cadre d'une implémentation de cette invention que le code CF* est dérivé de façon quasiment unique de CF.

Les fonctions tf dont il était question dans la description du procédé P sont des fonctions dites de transformation. Leur rôle est de modifier la valeur d'une variable appelée RTK pour « Run-Time Key ». La modification apportée par une fonction tf à RTK est arbitraire et peut dépendre de paramètres d'exécution x ; il peut par exemple s'agir d'une opération algébrique portant sur la valeur courante de RTK, de x et d'autres paramètres constants, d'une opération sur les représentations binaires (rotations, transpositions, permutations), d'une opération logique (ET, OU, OU exclusif, complément), de composées de telles opérations, etc. La bibliothèque L contient un ensemble préférentiellement important de telles fonctions tf, mises en oeuvre dans CF* par le procédé P lorsqu'elles sont désignées par les coefficients de la matrice TF tirée aléatoirement. La valeur de RTK résulte de l'ensemble des modifications apportées par les fonctions tf, et donc non seulement de la valeur des paramètres d'exécution mis en oeuvre par les fonctions tf, mais surtout de quelles fonctions tf ont été exécutées. A leur tour, les fonctions tf exécutées et la séquence selon laquelle elles sont exécutées dépendent de quelles fonctions Sy ont été appelées récursivement (lié notamment à Uo, 6inc, 6cond, x), ainsi que du résultat des conditions ci.

Ainsi, une première caractéristique permise par le code CF* dérivé de CF grâce au procédé P est qu'il implémente un calcul implicite et unique d'une variable RTK. Unique grâce à la combinatoire mise en oeuvre par le procédé P ; implicite parce qu'il est impossible de décrire la formule permettant le calcul de RTK autrement que sous une forme équivalente au code CF*, et ce notamment du fait que cette formule dépend de façon non algébrique de la valeur de Uo pour une suite (Un) convenablement choisie. Une seconde caractéristique importante est que pour réaliser le calcul de RTK de façon identique au code CF* d'un utilisateur donné, il suffit de connaître les paramètres (N, TF, 6inc, 6cond, ci, balises) tirés aléatoirement lors de la mise en oeuvre du procédé P ayant généré CF*. Cela signifie que le serveur devant contrôler la validité des codes d'authentification et des signatures électroniques pour de multiples utilisateurs peut réaliser le calcul de RTK pour chacun de ces utilisateurs en exécutant un code CF* unique et identique pour tous les utilisateurs, dans lequel il insère lors de l'exécution les paramètres (N, TF, 6inc, 6cond, ci, balises) propres à chaque utilisateur. Ces paramètres ne sont en revanche pas explicitement définis dans le code CF*. On déduit de ces caractéristiques un dispositif de sécurisation de l'application d'authentification et de signature électronique : l'application est adaptée pour utiliser la valeur de RTK lors du calcul des signatures fournies au serveur d'authentification, et ce en complément des secrets (données stockées, code PIN saisi) déjà utilisés dans ce calcul. Que ce calcul mette en oeuvre un procédé symétrique ou asymétrique, le serveur ayant fait un calcul similaire de RTK sait alors vérifier la validité des signatures. Pour ce faire, on adapte l'application de la façon suivante ; On introduit dans le code CF des « points de contrôle » où certains des paramètres d'exécution x sont mis à jour ; le rôle de ces points de contrôle est de contribuer à protéger l'exécution de certaines parties du code CF, le principe étant que si cette partie du code était contournée ou modifiée, le point de contrôle le serait vraisemblablement aussi et qu'ainsi la valeur de RTK calculée par le code CF* de l'utilisateur et celle calculée par le serveur différeraient. Un exemple de partie du code CF qu'il est utile de protéger est celle s'assurant que l'information secrète saisie par l'utilisateur (code PIN) est réellement saisie - c'est-à-dire correspond à des événements liés au matériel, clavier ou souris - et non fournie par un script automatique. La sécurisation de l'application d'authentification et de signature électronique apportée par la dérivation de CF* à partir de CF par le procédé P peut être présentée de la façon suivante. Une attaque réalisée par un programme malicieux accédant aux secrets (données stockées et saisies par l'utilisateur) ne fonctionne pas. En effet, la réussite de l'authentification ou la validité de la signature électronique nécessitent de disposer d'une clé RTK calculée par l'application. Cette clé ne peut pas non plus être simplement volée puisqu'elle n'est jamais stockée et n'est valide que pour l'exécution en cours de l'application.

Une attaque réalisée par un programme malicieux accédant aux secrets (notamment les données saisies par l'utilisateur) et déclenchant l'exécution de l'application en tâche de fond ou en l'absence probable de l'utilisateur, puis saisissant à sa place les informations attendues de l'utilisateur, ne fonctionne pas. En effet, l'application vérifie que ces informations sont réellement fournies par un utilisateur. Une attaque réalisée par un programme malicieux accédant aux secrets (données stockées et saisies par l'utilisateur) et tentant d'analyser la façon dont la clé RTK est calculée pour la calculer sans exécuter l'application ne fonctionne pas. En effet, le code de CF* réalisant le calcul de RTK ne peut être extrait de façon automatique par un programme : ce code est en effet variable dans sa taille (nombre de fonctions Sy), dans sa structure (présence ou non de fonctions tf, en nombre variable), et dans sa composition (la bibliothèque L contenant beaucoup plus de fonctions tf qu'il n'y a de fonctions tf dans un code CF* et étant extensible ad libitum, il n'est pas possible pour un programme malicieux de connaître toutes les fonctions tf, même en s'appuyant sur l'analyse manuelle et préalable de nombreux codes CF*). Une analyse automatique de CF* pour en extraire les paramètres connus du serveur et suffisants pour le calcul de RTK n'est pas possible de façon automatique car elle nécessite de modéliser le code CF*, ce qui nécessite de s'appuyer sur des motifs connus et stables, en termes de structure comme de contenu. Cette implémentation de l'invention ne couvre en revanche pas les cas d'attaques où un programme malicieux s'appuie sur une modélisation de CF et non de CF*, ni les cas d'attaques où un programme malicieux exporte les secrets et le code CF* à des fins d'analyse manuelle. Ces cas seront traités dans les variantes de réalisation présentées dans la suite de ce document car les adaptations nécessaires diffèrent selon que l'application fonctionne ou non de façon connectée.

L'invention a été illustrée et décrite en détail dans les dessins et la description précédente. Celle-ci doit être considérée comme illustrative et donnée à titre d'exemple. De nombreuses variantes de réalisation sont possibles. Dans une première variante de réalisation de cette invention valable pour une application d'authentification ou de signature électronique connectée, c'est-à-dire mettant en oeuvre lors de son exécution un protocole bidirectionnel avec le serveur, le procédé P est adapté pour que des fonctions tf dédiées au calcul d'une variable RTS et d'une variable RTM soient insérées dans les fonctions Sy. Le code CF* permet alors le calcul d'une variable RTS pour « Run-Time Store » et d'une variable RTM pour « Run-Time Mask » d'une façon similaire au calcul de la variable RTK. L'application est adaptée pour utiliser la valeur de RTS (respectivement RTM) lors du calcul du code d'authentification ou de la signature électronique. Cela signifie que certaines des modifications de la valeur de RTS (respectivement RTM) par les fonctions tf se font avant l'emploi de RTS (respectivement RTM) par l'application et que d'autres se font après. Si l'on désigne par RTS0 (respectivement RTM0) la valeur de RTS (respectivement RTM) au moment de son utilisation par l'application, et par RTSend (respectivement RTMend) la valeur lors du franchissement d'un point de référence du code CF (par exemple la fin de l'exécution de CF), le serveur est adapté pour fournir à l'application une information ARTS (respectivement ARTM) préalablement - et préférentiellement simultanément - au moment où RTS (respectivement RTM) est utilisée par l'application, telle que ARTS (respectivement ARTM) soit la différence entre RTS0 (respectivement RTM0) et RTSend (respectivement RTMend), la valeur obtenue lors de la précédente exécution et mémorisée par le serveur. On entend ici spécifiquement par «différence» une opération binaire injective. La fourniture de ARTS (respectivement ARTM) par le serveur permet à l'application de déterminer la valeur de RTSend (respectivement RTMend) obtenue lors de la précédente exécution, cette valeur n'étant correcte et ne correspondant à la valeur mémorisée par le serveur que parce que le code CF* a effectivement su calculer RTS0 (respectivement RTM0). Le serveur et l'application sont adaptés pour que la valeur Uo soit préférentiellement fournie par le serveur et que les mises à jour des paramètres d'exécution x dans les points de contrôle soient préférentiellement réalisées grâce à des informations fournies par le serveur. Le serveur est par ailleurs adapté pour mettre en oeuvre un « point de non retour ». Le fait de démarrer le calcul d'un code d'authentification ou d'une signature électronique permet de franchir ce « point de non retour », par exemple lorsque l'application demande au serveur la valeur de Uo. Une fois ce point franchi, le code CF* doit terminer correctement et dans un bref délai l'authentification ou la signature électronique utilisant RTK, RTS et RTM, à défaut de quoi le serveur bloque irréversiblement l'usage de l'application.

Egalement, l'application et le serveur sont adaptés pour que les secrets soient renouvelés après chaque authentification ou signature électronique réussie. On désigne ici spécifiquement par «secrets» les données stockées par l'application et non l'information saisie par l'utilisateur. La façon de renouveler les secrets sous condition de réussite doit préférentiellement ne pas nécessiter le transfert de ces secrets entre l'application et le serveur. Si les secrets sont mis en oeuvre de façon asymétrique, un procédé de partage de clé tel que Diffie-Hellmann est préférentiellement mis en oeuvre. Si les secrets sont mis en oeuvre de façon symétrique, l'application et le serveur s'échangent préférentiellement une clé de mise à jour (DK) qui est appliquée de façon identique par l'application et le serveur sur les secrets existants afin d'en produire de nouveaux selon l'opération suivante : secretsnew = H(secretsold * DK) où H est une fonction à sens unique (préférentiellement une fonction dérivée d'une fonction de hachage) et * est un opérateur binaire. La variable RTS est utilisée par le code CF* pour déterminer l'emplacement dynamique de stockage des secrets utilisés par l'application d'authentification et de signature électronique. L'emplacement de stockage des secrets sur le moyen de stockage MS est déterminé grâce à la valeur de RTSend. La valeur de RTSend obtenue lors de l'exécution précédente désigne l'emplacement actuel des secrets, la valeur obtenue lors de l'exécution courante désigne l'emplacement des secrets renouvelés. De la même façon que pour le renouvellement des secrets, la mise à jour de l'emplacement de stockage des secrets n'est faite qu'en cas de réussite de l'authentification ou de la signature électronique. Une caractéristique importante du procédé P adapté pour que le code CF* calcule RTS est que l'emplacement des secrets utilisés pour l'authentification ou la signature électronique ne peut ainsi être connu sans exécuter l'application. Il est important de remarquer d'une part que la valeur de l'information saisie par l'utilisateur (PIN) n'intervient pas dans le calcul des variables RTK, RTS ni RTM par le code CF*, n'entraînant ainsi pas de blocage de l'usage de l'application du fait d'une faute de frappe ; d'autre part qu'en cas d'abandon de l'utilisateur, l'application est en mesure de terminer le calcul de RTK, RTS et RTM et d'effectuer une communication avec le serveur s'appuyant sur ces calculs, n'entraînant ainsi pas de blocage en cas d'abandon ou de fermeture prématurée de l'application.

On conçoit aisément que le procédé permettant de déterminer l'emplacement des secrets à partir de la valeur de RTS doive être discret afin de ne pas être simplement contourné, et que l'espace des possibles doive également être suffisamment vaste pour que l'on ne puisse pas être certain que les secrets se trouvent à coup sûr dans une zone limitée du moyen de stockage MS ou dans un ou plusieurs fichiers donnés indexés par le système de gestion de fichiers du moyen MS. Un premier exemple de tel procédé est de créer un ou plusieurs fichiers dans des arborescences liées au système d'exploitation du support d'exécution de l'application supposé suffisamment vaste. Un autre exemple encore plus discret est de ne pas stocker de secrets mais d'utiliser comme secrets les valeurs stockées dans des emplacements arbitraires du moyen de stockage ; la mise à jour des secrets entre application et serveur consiste alors pour l'application à indiquer au serveur la valeur des emplacements désignés par la valeur de RTS. Le procédé d'authentification à partir de ces secrets est adapté, puisqu'il n'est pas possible de garantir par un tel procédé que les valeurs contenues dans les emplacements ne seront pas modifiées par d'autres tâches ou applications accédant au moyen de stockage MS. L'authentification se fait alors non pas sur une certitude (égalité des secrets) mais sur une vraisemblance (degré de similitude des secrets). Enfin, la variable RTM est utilisée par l'application pour crypter et décrypter le code exécutable de certains segments si dans lesquels on a inséré un point de contrôle. Les adaptations de cette variante de réalisation permettent de contrer plusieurs types d'attaques supplémentaires. Ainsi, l'attaque réalisée par un programme malicieux exportant les secrets (notamment, l'information saisie par l'utilisateur) et le code CF* de l'application à des fins d'analyse et d'expertise manuelle ne peut aboutir. En effet, ce programme malicieux n'ayant pas pu exécuter le code CF* avant de l'exporter pour les raisons rappelées dans la description de la première implémentation de l'invention ne peut pas non plus connaître la valeur de RTS, et donc ne peut exporter une partie des secrets nécessaires. L'attaquant récupérant le code CF* peut l'analyser et l'exécuter mais est pour cela obligé de franchir le « point de non retour ». S'il parvient à effectuer un calcul de RTS et donc à déterminer l'emplacement des secrets sur le moyen de stockage MS de l'utilisateur, il ne dispose pas de leur valeur et n'a qu'une faible probabilité de les obtenir dans les délais, le serveur exigeant une réponse de l'application juste après lui avoir fourni la valeur de ARTS. Cela entraîne un blocage de l'application. Le déblocage de l'application reste possible par l'utilisateur conservant d'autres preuves de son identité auprès du service en ligne mettant en oeuvre le système d'authentification, mais ne se fait qu'après distribution d'un nouveau code CF* à l'utilisateur. L'attaquant perd ainsi tout bénéfice de l'attaque qu'il avait entreprise.

Par ailleurs, une attaque réalisée par un programme malicieux s'appuyant sur la reconstitution et l'analyse manuelles du code CF (invariant) à partir d'un ou plusieurs codes CF* afin de modifier certains segments si dans CF* ne peut aboutir. En effet, les éléments sensibles sont cryptés par la valeur de RTM et contiennent un point de contrôle. La valeur de RTM n'étant pas connue à moins d'exécuter le code CF* et de franchir un « point de non retour », le programme malicieux ne peut ni désactiver sélectivement ces éléments sensibles, ni les contourner puisqu'ils contiennent des points de contrôle. Un exemple d'élément sensible est la partie du code CF contrôlant que la saisie d'une information par l'utilisateur s'accompagne bien d'événements liés au matériel (frappe clavier, clic souris, ...). Dans une variante de réalisation de la variante présentée ci-dessus, l'application est adaptée pour empêcher l'exécution automatique de l'application grâce à un test de Turing, par exemple, mise en oeuvre d'un « captcha » que l'utilisateur doit saisir, ou d'un secret connu de l'utilisateur, affiché sous forme graphique, de façon toujours différente et non aisément reconnaissable par un programme, que l'utilisateur doit reconnaître parmi d'autres chaines de caractères en lieu et place de l'emploi d'un masque RTM. Dans une seconde variante de réalisation valable pour une application d'authentification ou de signature électronique non-connectée, c'est-à-dire mettant en oeuvre avec le serveur lors de son exécution un protocole unidirectionnel et constitué d'un seul message, le procédé P est adapté pour que des fonctions tf dédiées au calcul d'une variable RTS et d'une variable RTM soient insérées dans les fonctions Sy. Le code CF* permet alors le calcul d'une variable RTS pour « Run-Time Store » et d'une variable RTM pour « Run-Time Mask » d'une façon similaire au calcul de la variable RTK. L'application est adaptée pour utiliser la valeur de RTS (respectivement RTM) lors du calcul du code d'authentification ou de la signature électronique. Cela signifie que certaines des modifications de la valeur de RTS (respectivement RTM) par les fonctions tf se font avant l'emploi de RTS (respectivement RTM) par l'application et que d'autres se font après. Le procédé P générant le code CF* est adapté de la façon suivante : grâce aux balises de contrôle, aucun segment si n'est exécuté avant un nombre paramétrable (Y) d'appels récursifs des fonctions Sy. Par ailleurs, l'appel des fonctions Sy peut se faire selon deux modes « get » (recherche) ou « set » (définition) grâce à la valeur d'un paramètre. En mode « get », l'appel récursif des fonctions Sy s'arrête après le nombre paramétrable Y d'appels ; on note RTS1 (respectivement RTM1) la valeur prise par la variable RTS (respectivement RTM) à ce moment-là et cette valeur est mémorisée par l'application. Lors d'une exécution de l'application et du code CF* ainsi adaptés, l'appel des fonctions Sy est fait une première fois en mode « get » avec la valeur de Uo de l'exécution précédente mémorisée par l'application, puis une seconde fois en mode « set » avec la valeur de Uo de l'exécution courante. La valeur de RTS1 (respectivement RTM1) obtenue lors du premier appel est utilisée déterminer l'emplacement de stockage des secrets mis en oeuvre pour l'authentification ou la signature électronique (respectivement pour décrypter une ou plusieurs zones sensibles). La valeur de RTS1 (respectivement RTM1) obtenue lors du second appel est utilisée déterminer l'emplacement ou seront stockés les secrets après leur emploi (respectivement pour recrypter une ou plusieurs zones sensibles après leur exécution). L'application étant non-connectée, elle est adaptée pour tirer aléatoirement la valeur de Uo. Le serveur est pour sa part adapté afin d'utiliser cette valeur et d'en contrôler le non-rejeu. Une façon préférentielle de réaliser ces adaptations lorsque l'application d'authentification est celle décrite dans la demande de brevet FR2937204 est de déduire, de façon simple et déterministe, la valeur de Uo de celle de la clé Rand tirée aléatoirement lors de la génération d'un mot de passe à usage unique. Or, la clé Rand est fournie au serveur car elle est suffisamment courte pour être embarqué dans le code d'authentification ou la signature électronique générée, et son nonrejeu est contrôlé ; la transmission de Uo au serveur et son non-rejeu sont donc assurés via ceux de Rand.

De même, l'application et les serveurs sont adaptés afin que les modifications des paramètres de l'exécution utilisés dans les points de contrôle soient effectuées par l'application et similairement par le serveur sans qu'application et serveur ne communiquent entre eux.

Les adaptations de cette variante de réalisation permettent de contrer plusieurs types d'attaques supplémentaires. Ainsi, l'attaque réalisée par un programme malicieux exportant les secrets (notamment, l'information saisie par l'utilisateur) et le code CF* de l'application à des fins d'analyse et d'expertise manuelles ne peut aboutir directement. Remarquons déjà d'une part qu'une telle attaque n'est pas automatique ni industrielle pour les raisons déjà présentées, d'autre part que l'export du code CF* nécessite que, bien que l'application soit non-connectée, elle soit stockée et exécutée sur un environnement qui soit connecté. Le programme malicieux n'ayant pas pu exécuter le code CF* avant de l'exporter pour les raisons rappelées dans la description ne peut pas non plus connaître la valeur de RTS, et donc ne peut exporter qu'une partie des secrets. L'attaquant récupérant le code CF* peut l'analyser et l'exécuter ; pour calculer une valeur correcte de RTS, il doit disposer de la valeur de Uo lors de l'exécution précédente et effectuer l'attaque - après analyse manuelle du code CF* - avant que le code CF* ne soit de nouveau exécuté par l'utilisateur, car cela entraînerait la modification de la valeur de RTS. Il peut alors, connaissant RTS, tenter d'obtenir les valeurs des secrets stockés aux emplacements désignés par RTS sur le moyen de stockage MS de l'utilisateur, ce qui nécessite d'une part que le moyen MS soit connecté, d'autre part que le programme malicieux prenne l'initiative d'établir une connexion sortante. Alors seulement, et dans le cas de l'application décrite dans la demande de brevet FR2937204 uniquement si l'utilisateur n'a pas mis en oeuvre le moyen d'authentification, l'attaque pourrait aboutir. Il convient enfin de remarquer que l'installation d'un programme malicieux et sa capacité à établir discrètement des connexions sortantes sont fortement limitées sur des environnements d'exécution tels que des téléphones mobiles. Par ailleurs, une attaque réalisée par un programme malicieux s'appuyant sur la reconstitution et l'analyse manuelle du code CF (invariant) à partir d'un ou plusieurs codes CF* afin de modifier certains segments si dans CF* ne peut aboutir directement. En effet, les éléments sensibles sont cryptés par la valeur de RTM et contiennent un point de contrôle. La valeur de RTM n'étant pas connue à moins d'exécuter le code CF*, le programme malicieux ne peut ni désactiver sélectivement ces éléments sensibles, ni les contourner puisqu'ils contiennent des points de contrôle. Il peut en revanche - théoriquement - modifier une partie non protégée du code CF* afin de rendre relativement discrète l'exécution du code CF* et de calculer la valeur de RTM, puis sur cette base décrypter les zones protégées, les modifier, et enfin exécuter le code CF* complet. L'application n'étant pas connectée, le programme malicieux devrait alors établir une connexion sortante pour fournir à un attaquant un code d'authentification ou une signature électronique valide calculé par cette attaque. Enfin, dans le cas de l'application décrite dans la demande de brevet FR2937204, ce code d'authentification devrait être utilisé par l'attaquant dans un délai très réduit (typiquement, moins d'une minute après son calcul) et avant que l'utilisateur n'en ait généré un autre. Il convient également de remarquer que l'installation d'un programme malicieux et sa capacité à s'exécuter et à établir une connexion sortante à l'insu de l'utilisateur - sont fortement limitées sur des environnements d'exécution tels que des téléphones mobiles. Dans les revendications, le mot « comprenant » n'exclut pas d'autres éléments et l'article indéfini « un/une » n'exclut pas une pluralité.

Claims (12)

1. REVENDICATIONS1. Procédé de sécurisation d'un logiciel originel mettant en oeuvre un secret, le procédé comprenant: - partitionner (1) le logiciel en N éléments (si, s2, ..., 5N), N étant un entier strictement supérieur à 1 ; - générer (3) M procédures sécurisées (Sy;), M étant un entier supérieur ou égal à N, par, pour chaque procédure : - tirage aléatoire (5) d'une fonction (tf) parmi une bibliothèque (L) de fonctions ; - sélection d'un des N éléments ou de l'ensemble vide ; - combinaison (7) de la fonction tirée aléatoirement et de l'élément sélectionné quand la sélection n'est pas l'ensemble vide ; de sorte que chaque élément est combiné dans une seule procédure et que tous les éléments sont combinés ; - modifier chaque procédure par introduction de balises de direction contrôlant les appels des procédures les unes par les autres et de balises contrôlant l'exécution des éléments ; - concaténer (9) les M procédures en un logiciel sécurisé apte à être installé et exécuté sur une plateforme d'exécution non sécurisée pour mettre en oeuvre le secret.
2. 2. Procédé selon la revendication 1, caractérisé en ce que les balises de direction contrôlant les appels des procédures les unes par les autres comportent : - pour chaque procédure, une sélection d'une pluralité de procédures appelables en fonction d'un paramètre d'exécution ; - des conditions non-prédictibles fonctions de paramètre d'exécutions, fixant l'exécution de certaines des procédures sélectionnées ; - une suite mathématique définie par un premier terme et une fonction de récurrence définissant un argument d'appel de chaque procédure tel que si une procédure a comme argument d'appel l'élément de la suited'indice n, alors les procédures appelées par celle-ci ont comme argument d'appel l'élément de la suite d'indice n+1.
3. 3. Procédé selon la revendication 2, caractérisé en ce que la suite mathématique est la suite de Syracuse.
4. 4. Procédé selon la revendication 2 ou 3, caractérisé en ce que la sélection des deux procédures appelables est basée sur une fonction uniforme du paramètre d'exécution assurant que la probabilité d'appel pour chaque procédure est substantiellement identique.
5. 5. Procédé selon la revendication 2, caractérisé en ce que les balises contrôlant l'exécution des éléments comportent des appels vers des éléments extérieurs à l'élément contenant l'appel et, dans les éléments extérieurs, des repères de destination de ces appels.
6. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les fonctions de la bibliothèque de fonction sont des fonctions de transformation modifiant la valeur d'au moins une variable.
7. 7. Procédé selon la revendication 6, caractérisé en ce que le logiciel originel étant un logiciel mettant en oeuvre un procédé cryptographique nécessitant au moins un secret, le secret est fourni par la variable modifiée par les fonctions de transformation associées aux procédures. 25
8. 8. Procédé selon la revendication 7, caractérisé en ce que le secret étant pour partie calculé et pour partie dépendant d'un secret non-calculé dont l'emplacement est dynamique et calculé, les fonctions de transformation modifient par leurs exécutions une seconde variable, la seconde variable 30 étant un pointeur vers l'emplacement dynamique.
9. 9. Procédé selon la revendication 8, caractérisé en ce que les fonctions de transformation modifient par leurs exécutions une troisième variable, la20troisième variable étant utilisée par le logiciel pour crypter et décrypter au moins un des éléments.
10. 10. Procédé selon la revendication 2, caractérisé en ce que le premier terme de la suite est calculé à partir d'un nombre aléatoire utilisé lors de la génération d'un mot de passe à usage unique.
11. 11. Produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution du procédé selon l'une quelconque des revendications 1 à 10 lorsque ledit programme est exécuté sur un ordinateur.
12. 12.Système de sécurisation d'un logiciel originel mettant en oeuvre un secret, le système comprenant un calculateur adapté pour exécuter le procédé selon l'une quelconque des revendications 1 à 10.