FR3020888A1 - Chiffrement d'une cle de protection de secrets protegeant au moins un element sensible d'une application - Google Patents

Abstract

L'invention concerne un procédé de chiffrement d'une clé de protection de secrets (K) protégeant au moins un élément sensible d'une application comprenant les étapes suivantes : -génération (E1) d'une clé de chiffrement relative à la pile (Kstack_i) à partir d'éléments de la pile d'exécution de ladite application, -chiffrement (E2) de la clé de protection de secrets (K) avec ladite clé de chiffrement relative à la pile générée (Kstack_i) de sorte à générer un cryptogramme ((K)Kstack_i).

Description

Chiffrement d'une clé de protection de secrets protégeant au moins un élément sensible d'une application DOMAINE DE L'INVENTION La présente invention concerne de façon générale la protection d'éléments sensibles (ou secrets) d'une application numérique. L'invention concerne plus précisément un procédé de chiffrement d'une clé cryptographique protégeant de tels éléments sensibles d'une application.

ETAT DE LA TECHNIQUE Lors de l'utilisation d'une application numérique, il peut être nécessaire de protéger certains éléments de l'application jugés sensibles, tels que des mots de passe, des clés cryptographiques ou des paramètres de configuration, afin de garantir leur intégrité ou leur confidentialité.

Pour cela, ces éléments sont en général chiffrés avec un algorithme cryptographique dont la clé doit elle-même être protégée. Une première solution de protection d'une telle clé consiste à la protéger par un mot de passe à fournir lors de l'utilisation de l'application pour accéder à la clé et déchiffrer les éléments sensibles protégés. Une telle solution est efficace mais requiert une intervention humaine d'une personne connaissant le mot de passe afin que le mot de passe soit saisi au moins à chaque démarrage de l'application. Ainsi une telle solution est inadaptée pour une utilisation sur des systèmes tels que des serveurs informatiques automatiques ou utilisés à distance pouvant être amenés à redémarrer sans intervention humaine sur la machine ou uniquement en présence d'individus n'ayant pas un niveau d'accréditation suffisant pour connaitre le mot de passe. Une deuxième solution de protection d'une telle clé consiste à cacher la clé à protéger dans le code logiciel de l'application par une technique d'offuscation. Une telle solution pour être efficace nécessite d'employer un algorithme d'offuscation assez complexe présentant un coût en ressources de calcul élevé, ce qui peut nuire aux performances de l'application protégée. De plus, elle nécessite de modifier le code du logiciel avant ou après sa compilation et l'offuscation peut avoir un impact sur le cycle de développement logiciel pouvant ainsi être un frein à l'adoption de mesures de sécurisation du code. Par ailleurs, dans le cas où les fonctions d'accès au secret sont mises à disposition de plusieurs applications sous forme d'une librairie partagée, l'emploi d'une technique d'offuscation ne permet pas de choisir quelle application peut accéder à un élément secret chiffré par la clé protégée par offuscation. Ainsi, l'ensemble des secrets protégés est accessible à toutes les applications. Enfin, une telle solution résiste mal à une analyse statique du code qui peut être mise en place de façon automatisée et permettrait à un pirate de récupérer la clé à protéger. Enfin, une troisième solution de protection d'une telle clé consiste à utiliser un dispositif cryptographique matériel pour protéger la clé. Une telle solution est efficace mais nécessite un code PIN utilisateur pour qu'une application puisse utiliser le dispositif pour accéder à la clé protégée. Une telle solution nécessite donc soit une intervention humaine, soit que le code PIN soit lui-même protégé par une autre méthode existante, telle qu'une méthode d'offuscation. De plus, l'utilisation d'un dispositif matériel supplémentaire n'est pas toujours possible ou souhaitable, pour des raisons de coûts, de performances ou d'intégration, notamment sur des systèmes mobiles. Il existe donc un besoin d'un procédé de protection d'une clé cryptographique, dénommée par la suite clé de protection de secrets, pouvant être mis en oeuvre de façon simple et efficace sans nécessiter une intervention humaine ni l'utilisation d'un dispositif matériel additionnel lors du fonctionnement et du redémarrage des applications désirant accéder aux secrets protégés par ladite clé, et permettant de rendre les éléments sensibles d'une application accessibles à cette application uniquement.

RESUME DE L'INVENTION A cet effet, la présente invention se rapporte ainsi selon un premier aspect à un procédé de chiffrement d'une clé de protection de secrets protégeant au moins un élément sensible d'une application caractérisé en ce qu'il comprend les étapes suivantes : -génération d'une clé de chiffrement à partir d'éléments de la pile d'exécution de ladite application, dite clé de chiffrement relative à la pile, -chiffrement de la clé de protection de secrets avec ladite clé de chiffrement relative à la pile générée de sorte à générer un cryptogramme.

Un tel procédé permet de protéger la clé de protection de secrets de façon simple, sans nécessiter de matériel cryptographique additionnel, tout en garantissant que la clé de protection de secrets pourra être recouvrée lors de l'exécution de l'application sans intervention humaine et que les éléments sensibles d'une application ne seront pas accessibles aux autres applications, même si elles utilisent par ailleurs le même procédé de protection. La clé de chiffrement relative à la pile peut être une clé de chiffrement symétrique.

Ceci permet d'employer les mêmes opérations pour déduire à partir de la pile d'exécution la clé de chiffrement et la clé de déchiffrement de la clé de protection de secrets.

L'étape de génération de la clé de chiffrement relative à la pile du procédé de chiffrement selon le premier aspect peut comprendre une étape de calcul d'un hash cryptographique sur des éléments de la pile d'exécution de l'application. L'utilisation d'une fonction de hachage permet de générer simplement une clé de chiffrement à partir de la pile d'exécution. Les éléments de la pile d'exécution à partir desquels est générée la clé de chiffrement relative à la pile peuvent être des éléments non variables de la pile d'exécution.

L'utilisation d'éléments non variables de la pile d'exécution permet de s'assurer que la même clé sera obtenue lors d'exécutions successives de l'application, notamment lors d'une exécution pour générer le cryptogramme et d'une exécution pour accéder au secret protégé en utilisant un tel cryptogramme. Os 3020888 4 Un tel élément non variable de la pile d'e-xécution peut être parmi un nom de fonction constituant la pile d'exécution et, pour chaque fonction, le nom du package, le nom de la classe et le numéro de ligne de ladite fonction. 5 Ceci permet de sélectionner des éléments non variables de la pile d'exécution dans le cas d'un code destiné à des plateformes d'exécution comme des machines virtuelles java. 10 Un tel élément non variable de la pile d'exécution peut être un écart entre les adresses mémoires de deux éléments de la pile d'exécution. Ceci permet de sélectionner des éléments non variables de la pile d'exécution dans le cas d'un code natif. 15 En variante, un tel élément non variable de la pile d'exécution peut être un écart entre les adresses mémoires de deux éléments de la pile d'exécution ne variant pas entre deux exécutions de l'application. 20 L'étape de génération d'une clé de chiffrement relative à la pile à partir d'éléments de la pile d'exécution du procédé de chiffrement selon le premier aspect peut comprendre : - pour une première exécution de l'application, le calcul d'un premier hash cryptographique pour chaque écart entre des adresses mémoires de deux éléments 25 de la pile d'exécution, - pour une deuxième exécution de l'application, le calcul d'un deuxième hash cryptographique pour chaque écart entre des adresses mémoires de deux éléments de la pile d'exécution, - la comparaison des premiers et deuxièmes hash cryptographiques calculés, 30 un élément non variable de la pile d'exécution étant un écart entre des adresses mémoires de deux éléments de la pile d'exécution pour lequel le premier hash cryptographique calculé est égal au deuxième hash cryptographique calculé. Ceci permet de sélectionner des éléments non variables de la pile d'exécution dans le cas d'un code natif lorsque des éléments de la pile d'exécution appartiennent à au moins deux sous-sections différentes de la pile d'exécution, appartenant elles-mêmes à deux espaces d'adresses différents. Le procédé de chiffrement selon le premier aspect peut comprendre en outre préalablement une phase d'initialisation comprenant une étape de chiffrement de la clé de protection de secrets à partir d'un mot de passe administrateur. Une telle étape de chiffrement de la clé de protection de secrets à partir d'un mot de passe administrateur lors de ladite phase d'initialisation peut comprendre : - une étape de génération d'une clé de chiffrement administrateur à partir du mot de passe administrateur de l'application et, - une étape de chiffrement de la clé de protection de secrets avec ladite clé de chiffrement administrateur générée de sorte à générer un cryptogramme administrateur.

L'étape de génération d'une clé de chiffrement administrateur lors de ladite phase d'initialisation peut comprendre une étape de calcul d'un hash cryptographique sur le mot de passe administrateur de l'application.

Ceci permet de définir un mot de passe administrateur utilisable pour protéger de nouveaux éléments secrets. Dans une phase d'apprentissage mise en oeuvre au premier démarrage de ladite application, l'étape de chiffrement de la clé de protection de secrets avec ladite clé de chiffrement relative à la pile générée peut comprendre, préalablement au chiffrement de la clé de protection de secrets (K) avec ladite clé de chiffrement relative à la pile générée (Kstack_i), -une étape d'acquisition du mot de passe de l'administrateur et de génération de la clé de chiffrement administrateur à partir du mot de passe administrateur acquis; -une étape de déchiffrement du cryptogramme administrateur avec la clé de chiffrement administrateur générée de sorte à obtenir la clé de protection de secrets.

Ceci permet de récupérer la clé de protection de secrets à partir de la clé de chiffrement administrateur dans le but de générer ensuite un cryptogramme à partir de la pile d'exécution de l'application. L'accès par l'application aux éléments secrets protégés à l'aide de la clé de protection de secrets sera ainsi possible lors d'une exploitation future de façon protégée en utilisant ce cryptogramme, sans jamais avoir nécessité le stockage en clair de la clé de protection des secrets elle-même. Lors des différentes exécutions de l'application, l'ensemble des cryptogrammes peut être stocké dans des moyens de stockage. Ces cryptogrammes peuvent être stockés dans lesdits moyens de stockage en les indexant en fonction d'un hash de la clé de chiffrement relative à la pile. Ceci donne un moyen, lors de l'exécution des applications accédant aux éléments secrets protégés, de récupérer la clé de protection de secrets uniquement à partir de ces cryptogrammes et de l'état de la pile d'exécution. L'indexation des cryptogrammes permet de déterminer facilement quel cryptogramme doit être utilisé sans avoir à tenter le décodage de tous les cryptogrammes un par un. La présente invention se rapporte selon un deuxième aspect à un procédé de déchiffrement d'au moins un élément sensible d'une application chiffré avec une clé de protection de secrets lors de l'exécution de ladite application, ladite clé de protection de secrets étant chiffrée avec une clé de chiffrement relative à la pile conformément au procédé de chiffrement selon le premier aspect, comprenant des étapes de : - calcul de la clé de chiffrement relative à la pile à partir d'éléments de la pile d'exécution de ladite application; - déchiffrement d'un cryptogramme parmi l'ensemble des cryptogrammes stockés à l'aide de la clé de chiffrement relative à la pile calculée, - si le déchiffrement est un échec, déchiffrement d'un autre cryptogramme parmi l'ensemble des cryptogrammes stockés à l'aide de la clé de chiffrement relative à la pile calculée, - si le déchiffrement est un succès, obtention de la clé de protection des secrets et déchiffrement dudit au moins un élément sensible à l'aide de la clé de protection de secrets obtenue.

Un tel procédé permet d'accéder à l'élément sensible protégé sans intervention humaine ni utilisation d'un matériel supplémentaire, en produisant à la volée la clé de déchiffrement nécessaire à partir de la pile d'exécution.

La présente invention se rapporte également selon ce deuxième aspect à un procédé de déchiffrement d'au moins un élément sensible d'une application chiffré avec une clé de protection de secrets, lors de l'exécution de ladite application, ladite clé de protection de secrets étant chiffrée avec une clé de chiffrement relative à la pile conformément au procédé de chiffrement selon le premier aspect, comprenant des étapes de : - calcul de la clé de chiffrement relative à la pile à partir d'éléments de la pile d'exécution de ladite application; - calcul d'un hash de la clé de chiffrement relative à la pile et déchiffrement avec la clé de chiffrement relative à la pile calculée du cryptogramme stocké et indexé au hash calculé, - obtention de la clé de protection des secrets et déchiffrement dudit au moins un élément sensible à l'aide de la clé de protection de secrets obtenue.

Ceci permet de déchiffrer directement le bon cryptogramme grâce à leur indexation, sans avoir à essayer de décrypter des cryptogrammes au hasard jusqu'à trouver le bon. La présente invention se rapporte selon un troisième aspect à un procédé de vérification de l'intégrité d'au moins un élément sensible d'une application, un premier code d'authentification de message (MAC) ayant été généré à partir dudit au moins un élément sensible et d'une clé secrète, ladite clé secrète ayant été chiffrée conformément au procédé de chiffrement selon le premier aspect, comprenant des étapes de : - calcul d'une clé de chiffrement relative à la pile à partir d'éléments de la pile d'exécution de ladite application, lors de l'exécution de l'application; - déchiffrement avec la clé de chiffrement relative à la pile calculée d'un cryptogramme parmi l'ensemble des cryptogrammes stockés, - si le déchiffrement est un échec, déchiffrement avec la clé de chiffrement relative à la pile calculée d'un autre cryptogramme parmi l'ensemble des cryptogrammes stockés, - si le déchiffrement est un succès, calcul d'un deuxième code d'authentification de message (MAC) à partir dudit au moins un élément sensible et de la clé secrète déchiffrée et comparaison des premier et deuxième codes d'authentification de messages afin de vérifier l'intégrité dudit au moins un élément sensible. Un tel procédé permet d'attester de l'intégrité d'un élément sensible et d'empêcher quiconque de falsifier un élément pour le faire passer pour intègre. Dans une première variante de mise en oeuvre, l'élément sensible protégé peut être parmi un mot de passe, un code PIN, une clé cryptographique, des paramètres et fichiers de configuration de l'application.

Dans une deuxième variante de mise en oeuvre, l'élément sensible protégé peut comprendre du code logiciel de l'application ou du code logiciel de l'application chiffré conformément au procédé de chiffrement selon le premier aspect.

Une telle variante permet de protéger le code logiciel d'une application lui- même, rendant difficile l'analyse du code de l'application par un utilisateur malveillant. La présente invention se rapporte selon un quatrième aspect à un procédé de protection d'un code logiciel d'une application comprenant les étapes suivantes : - identification, dans le code logiciel de ladite application, de méthodes sensibles à protéger appelées dans le code logiciel de ladite application; - pour chaque méthode sensible identifiée, génération d'une clé de chiffrement de méthode ; - chiffrement de chaque clé de chiffrement de méthode conformément au procédé de chiffrement selon le premier aspect de sorte à générer des cryptogrammes; - chiffrement pour chaque méthode sensible identifiée d'une partie de code logiciel correspondante avec sa clé de chiffrement de méthode associée.

Ainsi, chaque méthode à protéger est chiffrée avec une clé distincte et la connaissance de l'état de la pile d'exécution au moment de l'exécution de cette méthode est nécessaire pour la déchiffrer et l'exécuter. Un mode de mise en oeuvre de la présente invention se rapporte également à un procédé de protection d'un code logiciel selon le quatrième aspect dans lequel l'étape d'identification de méthodes sensibles à protéger comprend : - une étape de construction d'un arbre d'appel des méthodes appelées dans ledit code logiciel, - une étape de détermination d'au moins une méthode pouvant être appelée par au moins deux desdites méthodes sensibles à protéger identifiées, dite méthode en collision, et dans lequel l'étape de génération d'une clé de chiffrement de méthode comprend la génération d'au moins une clé de chiffrement de méthode supplémentaire, l'étape de chiffrement de chaque clé de chiffrement de méthode comprend le chiffrement conformément au procédé de chiffrement selon le premier aspect de l'au moins une clé de chiffrement de méthode supplémentaire, et l'étape de chiffrement d'une partie de code logiciel comprend le chiffrement, d'au moins une partie de code logiciel correspondant à ladite méthode en collision déterminée, uniquement avec ladite clé de chiffrement de méthode supplémentaire.

Le chiffrement d'une méthode par deux clés de chiffrement de méthode protégées de façon distincte par le procédé de chiffrement, ce qui rendrait l'exécution d'une telle méthode impossible, est ainsi évité.

Une partie de code logiciel à chiffrer correspondant à une méthode à protéger peut comprendre une sous-partie de code logiciel chiffrée conformément au procédé de chiffrement selon le premier aspect. Ceci permet d'élever le niveau de protection d'une application en imbriquant les méthodes chiffrées, ce qui complique notablement la tache de recouvrement du code par un utilisateur malveillant. La présente invention se rapporte selon un cinquième aspect à un procédé d'appel d'une méthode d'un code logiciel d'une application protégé conformément au procédé de protection selon le quatrième aspect comprenant les étapes suivantes : - déchiffrement avec la clé de chiffrement de méthode associée et conformément au procédé de déchiffrement selon le deuxième aspect, de la partie de code chiffrée correspondant à ladite méthode; - appel de ladite méthode. Un tel procédé d'appel permet de déchiffrer une méthode protégée à partir de la pile d'exécution lorsque celle-ci doit être exécutée.

Un procédé d'appel selon le cinquième aspect d'une méthode d'un code logiciel protégé conformément au procédé de protection selon le quatrième aspect peut comprendre, pour chaque sous-partie de code logiciel chiffrée comprise dans ladite partie de code logiciel déchiffrée correspondant à ladite méthode, la mise en oeuvre du procédé d'appel selon le cinquième aspect. Ceci permet de déchiffrer des méthodes protégées imbriquées au fur et à mesure de leurs appels au cours de l'exécution de l'application.

La présente invention se rapporte selon un sixième aspect à un produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon les premier, deuxième, troisième, quatrième ou cinquième aspects lorsque ledit programme est exécuté sur un ordinateur.

Enfin, la présente invention se rapporte selon un septième aspect à un module de traitement comprenant des moyens de communication, des moyens de calcul, et des moyens de stockage caractérisé en ce qu'il est configuré pour : -générer une clé de chiffrement relative à la pile à partir d'éléments de la pile d'exécution d'une application, -chiffrer une clé de protection de secrets protégeant au moins un élément sensible de ladite application avec ladite clé de chiffrement relative à la pile générée de sorte à générer un cryptogramme.

De tels produits programmes d'ordinateur et module de traitement présentent les mêmes avantages que ceux évoqués pour les procédés selon les premier, deuxième, troisième, quatrième ou cinquième aspects.

DESCRIPTION DES FIGURES D'autres caractéristiques et avantages ressortiront encore de la description qui suit, laquelle est purement illustrative et non limitative et doit être lue en regard des figures annexées, parmi lesquelles : La figure 1 illustre un ordinogramme représentant les étapes d'un procédé de chiffrement d'une clé de protection de secrets selon un mode de mise en oeuvre de l'invention. La figure 2 illustre la génération d'une clé de chiffrement relative à la pile Kstack lorsque le code de ladite application est du code natif selon un mode de mise en oeuvre de l'invention. La figure 3 illustre la génération d'une clé de chiffrement relative à la pile Kstack lorsque le code de ladite application est du code natif et que la pile d'exécution contient des sections de code dans des sections d'adresses mémoires différentes selon un mode de mise en oeuvre de l'invention.

La figure 4a est un ordinogramme représentant les étapes d'une phase d'initialisation lors de laquelle la clé de protection de secrets est chiffrée à partir d'un mot de passe administrateur selon un mode de mise en oeuvre de l'invention. La figure 4b est ordinogramme représentant les étapes d'une phase d'apprentissage lors de laquelle un cryptogramme administrateur est déchiffré à partir d'un mot de passe administrateur selon un mode de mise en oeuvre de l'invention. La figure 5a est un ordinogramme représentant les étapes d'un procédé de déchiffrement d'au moins un élément sensible d'une application chiffré avec une clé de protection de secrets selon un mode de mise en oeuvre de l'invention.

La figure 5b est un ordinogramme représentant les étapes d'un procédé de vérification de l'intégrité d'au moins un élément sensible d'une application selon un mode de mise en oeuvre de l'invention.

La figure 6 est un ordinogramme représentant les étapes d'un procédé de protection d'un code logiciel d'une application selon un mode de mise en oeuvre de l'invention. La figure 7 illustre un arbre d'appel à des méthodes appelées dans le code logiciel d'une application. La figure 8 illustre un arbre d'appel à des méthodes appelées dans le code logiciel d'une application et chiffrées avec leur clé de chiffrement de méthode associée. La figure 9 illustre un arbre d'appel à des méthodes appelées dans le code logiciel d'une application et chiffrées avec leur clé de chiffrement de méthode associée de manière à éviter les problèmes de collisions. La figure 10 est un ordinogramme représentant les étapes d'un procédé d'appel d'une méthode d'un code logiciel d'une application protégé selon un mode de mise en oeuvre de l'invention.

DESCRIPTION DETAILLEE D'AU MOINS UN MODE DE REALISATION Chiffrement d'une clé de protection de secrets protégeant au moins un élément sensible d'une application Un mode de mise en oeuvre concerne un procédé de chiffrement d'une clé de protection de secrets K, telle qu'une clé symétrique de type AES, protégeant au moins un élément sensible d'une application à partir d'éléments de la pile d'exécution (ou pile d'appel) lors de l'exécution de ladite application par un système informatique.

Un tel élément sensible peut être un mot de passe administrateur du système, un mot de passe d'un utilisateur, un mot de passe d'un conteneur de clés cryptographiques ou de certificats (« keystore ») tels qu'un conteneur au format PKCS12, JKS ou PEM, une clé cryptographique ou encore un code PIN d'un dispositif cryptographique matériel (« token cryptographique ») tel qu'une carte à puce ou un module HSM. Un tel élément sensible peut également être un paramètre ou un fichier de configuration du système ou d'une de ses applications.

Ledit système informatique peut comprendre un module de traitement doté de moyens de calcul utilisés pour exécuter l'application et réaliser les différents calculs cryptographiques mis en oeuvre dans les procédés selon l'invention. Ledit module de traitement peut également comprendre des moyens de stockage permettant le stockage du code logiciel de l'application, sous forme de code natif spécifique de l'architecture du système informatique ou sous forme de code destinée à des plates-formes d'exécution, telle que le « bytecode » destiné à une machine virtuelle Java. Lesdits moyens de stockage peuvent également stocker les cryptogrammes utilisés ou les hash générés tels que décrits par la suite.

Enfin, ledit module peut comprendre des moyens de communications, tel qu'une interface réseau avec ou sans fil utilisable pour dialoguer avec des systèmes distants ou une interface de saisie permettant à un être humain tel qu'un administrateur d'interagir physiquement avec le système informatique.

Plus précisément, la clé de protection de secrets K protégeant au moins un élément sensible d'une application est chiffrée à l'aide d'une clé de chiffrement Kstack_i générée à partir d'éléments de la pile d'exécution de l'application, Kstack_i étant ensuite dénommée clé de chiffrement relative à la pile. Ceci permet ainsi d'utiliser la nature structurelle d'une application lors de son exécution pour lui permettre d'accéder aux éléments sensibles protégés par cette clé de protection de secrets. De plus, un élément sensible de l'application à protéger est scellé à une application donnée puisque l'état de la pile d'exécution lors de l'exécution de l'application est inconnu des autres applications qui ne peuvent ainsi pas accéder à la clé de protection de secrets protégée. Ainsi une première application voulant recouvrer les secrets d'une deuxième application ne pourra pas y parvenir. Enfin la clé de protection de secrets à protéger est scellée à un mot de passe administrateur afin de permettre de chiffrer un nouvel élément sensible avec cette clé sans remettre en cause la protection de cette clé. Une telle protection ne nécessite ni dispositif matériel supplémentaire, ni intervention humaine pour permettre à une application d'accéder aux éléments sensibles protégés par ladite clé de protection de secrets. Pour ce faire et comme illustré sur la figure 1, le procédé de chiffrement d'une clé de protection de secrets K comprend une étape de génération El d'une clé de chiffrement au cours de laquelle une clé de chiffrement relative à la pile Kstack_i est générée à partir d'éléments de la pile d'exécution de ladite application. Une telle clé est une clé de chiffrement symétrique permettant à la fois de chiffrer lors d'une étape E2 la clé de protection de secrets à protéger K pour obtenir un cryptogramme (K)Kstack et de déchiffrer ce cryptogramme pour retrouver la clé de protection de secrets K et accéder aux éléments sensibles protégés par celle-ci Cette étape de génération peut comprendre une étape de calcul El 1 d'un hash cryptographique, ou condensat, sur une concaténation d'éléments de la pile d'exécution de l'application. La clé de chiffrement relative à la pile générée peut alors consister en un sous-ensemble de bits du hash calculé. La fonction de hachage utilisée peut être du type SHA (Secure Flash Algorithm). La fonction de hachage choisie permet d'extraire des clés de taille plus ou moins importante (de 128 bits à 256 bits par exemple). Le sens du calcul du hash peut commencer par le haut de la pile pour atteindre le bas de la pile. Le procédé peut être configurable pour n'utiliser qu'une sous partie de la pile d'exécution pour le calcul de la clé de chiffrement relative à la pile. Par exemple le bas de la pile peut être ignoré afin d'éviter de calculer le hash sur un élément variable suivant l'environnement d'exécution, comme le nom du classloader JAVA. Une liste de mots clés peut être renseignée lors de la phase d'initialisation du procédé afin d'exclure la partie de la pile allant du bas de la pile à l'élément de la pile contenant ce mot clé. Si une sous partie de la pile d'exécution est utilisée alors le nombre d'éléments de la pile et l'indice du premier élément à prendre en compte pour le calcul du hash peuvent être stockés pour permettre de calculer la clé de chiffrement relative à la pile ultérieurement lors d'un accès à un élément sensible protégé. Les éléments de la pile d'exécution à partir desquels est générée la clé de chiffrement relative à la pile Kstack_i peuvent être des éléments non variables de la pile d'exécution de sorte à ce que la clé de chiffrement relative à la pile générée ait toujours la même valeur à chaque exécution de l'application. Les éléments de la pile d'exécution à partir desquels peut être générée la clé de chiffrement relative à la pile Kstack_i peuvent être différents en fonction du type de code de l'application sur lequel est réalisé le procédé : code natif ou code destiné à des plateformes d'exécution comme des machines virtuelles java (JVM). Lorsque le code de ladite application est destiné à une plateforme d'exécution, les éléments non variables de la pile d'exécution peuvent être le nom de fonctions présentes dans la pile d'exécution, ainsi que pour chaque fonction, certaines informations remontées telles que le nom du package, le nom de la classe ou le numéro de ligne.

Lorsque le code de ladite application est du code natif, les éléments non variables de la pile d'exécution peuvent être de différents types en fonction des options de compilation et de l'environnement d'exécution. Si les symboles des fonctions sont présents dans le code binaire de l'application, les éléments non variables utilisés peuvent être des noms de fonction présents dans la pile d'exécution. Si ce n'est pas le cas, il est possible d'utiliser les adresses mémoires de ces fonctions. Néanmoins, l'application et ses fonctions peuvent être localisées à des adresses mémoires différentes lors de deux exécutions successives de celle-ci. Les éléments non variables de la pile d'exécution peuvent alors être des écarts (deltas) entre les adresses mémoires de deux éléments de la pile d'exécution comme illustré en figure 2. En effet ces écarts ne varient pas entre deux exécutions de l'application même en cas de relocalisation de l'ensemble de l'application à des adresses différentes, par exemple par une technique ASLR (« Address space layout randomization »). L'ensemble des adresses mémoires des fonctions de la pile d'exécution peuvent être pris en compte. Néanmoins, il existe des cas où les éléments de la pile d'exécution dont les adresses sont comparées appartiennent à dessections de code différentes dans des espaces d'adresses différents. Les écarts entre les adresses de tels éléments peuvent varier d'une exécution à une autre, par exemple si l'accès aux éléments sensibles se fait dans des fonctions de rappel (« call back ») fournies à une librairie tierce, si le code où est implémenté le procédé est une librairie dynamique appelée par une application ou si le code où est implémenté le procédé est du code déchiffré et donc localisé dans une section autre que le code d'origine.

Dans une variante de mise en oeuvre, les éléments non variables de la pile d'exécution peuvent alors être des écarts entre les adresses mémoires de deux éléments de la pile d'exécution ne variant pas entre deux exécutions de l'application. Pour déterminer de tels écarts, il est alors possible d'exécuter l'application deux fois lors d'une phase d'initialisation, de localiser les écarts des adresses entre deux éléments de la pile d'exécution qui évoluent entre les deux exécutions et de les exclure de la génération de la clé de chiffrement relative à la pile Kstack_i. Une telle variante est particulièrement efficace dans le cas d'un système utilisant une technique d'ASLR. Plus précisément, comme illustré par le schéma de la figure 3 l'étape de génération El d'une clé de chiffrement relative à la pile (Kstack_i) à partir d'éléments de la pile d'exécution comprend : - pour une première exécution de l'application, le calcul d'un premier hash cryptographique Elll pour chaque écart entre des adresses mémoires de deux éléments de la pile d'exécution et le stockage des premiers hash cryptographiques calculés, - pour une deuxième exécution de l'application, le calcul d'un deuxième hash cryptographique E112 pour chaque écart entre des adresses mémoires de deux 20 éléments de la pile d'exécution et le stockage des deuxièmes hash cryptographiques calculés, - la comparaison E113 des premiers et deuxièmes hash cryptographiques calculés. Un élément non variable de la pile d'exécution est alors un écart entre des adresses mémoires de deux éléments de la pile d'exécution pour lequel le premier hash 25 cryptographique calculé est égal au deuxième hash cryptographique calculé. Les hash cryptographiques d'écart peuvent être stockés dans un fichier temporaire (list1 et list2). L'utilisation de tels hash et non des écarts en eux-mêmes permet de ne pas révéler ces écarts qui pourraient renseigner un pirate sur le contenu de la 30 pile d'exécution. La liste des index des écarts entre deux éléments de la pile d'exécution ne devant pas être utilisés pour la génération de la clé de chiffrement relative à la pile Kstack_i peut être enregistrée dans un fichier stocké sur les moyens de stockage du module de traitement. Un tel fichier peut également mémoriser la taille de la pile d'exécution correspondante afin de permettre à un procédé de déchiffrement utilisant ces informations de déterminer quelle liste utiliser lorsque plusieurs clés de chiffrement Kstack_i générées d'une telle manière ont été employées pour chiffrer une clé de chiffrement.

Lors d'une phase d'initialisation représentée en figure 4a, la clé de protection de secrets K est chiffrée à partir d'un mot de passe administrateur 11. Plus précisément, l'étape de chiffrement 11 de la clé de protection de secrets à partir d'un mot de passe administrateur comprend : - une étape de génération 111 d'une clé de chiffrement administrateur Kadmin à partir du mot de passe administrateur de l'application et, - une étape de chiffrement 112 de la clé de protection de secrets K avec ladite clé de chiffrement administrateur générée Kadmin de sorte à générer un cryptogramme administrateur (K)Kadmin.

La clé de chiffrement administrateur peut être générée en calculant un hash cryptographique 1111 sur le mot de passe administrateur de l'application et en sélectionnant ce hash ou une sous-partie de celui-ci, tels que les 128 ou 256 premiers bits de celui-ci, comme clé de chiffrement administrateur. Ainsi cette étape d'initialisation permet de définir un mot de passe administrateur protégeant cette clé de protection de secrets K protégeant les éléments sensibles de l'application. Ce mot de passe est ensuite demandé pour chiffrer de nouveaux éléments sensibles d'une application ou pour les modifier. Lors d'une phase d'apprentissage, illustrée à titre d'exemple en figure 4b, mise en oeuvre au premier démarrage de ladite application, le mot de passe de l'administrateur est acquis lors d'une étape d'acquisition Al et la clé de chiffrement administrateur Kadmin est générée lors d'une étape A2 à partir du mot de passe administrateur acquis. Le cryptogramme administrateur (K)Kadmin est ensuite déchiffré lors d'une étape A3 avec la clé de chiffrement administrateur Kadmin générée de sorte à obtenir la clé de protection de secrets K. Puis, comme illustré en figure 1 dans le cas d'un code destiné à une plateforme d'exécution, à chaque accès à un élément sensible protégé, la clé Kstack_i est calculée à partir du contenu de la pile d'exécution et la clé de protection des secrets K est chiffrée avec ladite clé de chiffrement relative à la pile générée Kstack_i de sorte à générer un cryptogramme (K)Kstacki. Un chiffrement utilisant une technique de bourrage (« padding ») peut être utilisé afin de pouvoir déterminer lors du déchiffrement si celui-ci a réussi ou non. L'algorithme de chiffrement utilisé pour chiffrer la clé de protection de secrets peut être l'algorithme AES.

Ainsi cette phase d'apprentissage, mise en oeuvre une fois pour chaque premier accès par une application à un élément sensible protégé, permet de calculer l'ensemble des cryptogrammes (K)Kstack_i correspondants et de les stocker dans les moyens de stockage pour une utilisation ultérieure lorsque cette application cherchera à accéder à un élément sensible chiffré par la clé de protection de secrets K. Dans une variante de mise en oeuvre, l'ensemble de ces cryptogrammes (K)Kstack_i peut être stocké en les indexant en fonction d'un hash de la clé de chiffrement relative à la pile d'exécution Kstack_i.

Déchiffrement d'au moins un élément sensible d'une application chiffré avec une clé de protection de secrets Dans un premier mode de mise en oeuvre, le procédé peut être appliqué au déchiffrement, lors de l'exécution d'une application, d'au moins un élément sensible de ladite application chiffré avec une clé de protection de secrets K, la clé de protection de secrets K ayant été chiffrée avec une clé de chiffrement relative à la pile Kstack_i générée à partir d'éléments de la pile d'exécution de ladite application comme représenté en figure 5a.

Dans ce premier mode de mise en oeuvre, la clé de chiffrement relative à la pile Kstack_i est une clé de chiffrement symétrique pouvant être générée par un algorithme cryptographique symétrique de type AES par exemple. Le déchiffrement peut être réalisé lors de l'exécution de l'application lorsque celle-ci cherche à accéder à des éléments sensibles de l'application. Les fonctions de chiffrement précédemment décrites et de déchiffrement peuvent appartenir à une même librairie. Plus précisément, dans une première variante de mise en oeuvre, ce déchiffrement est réalisé en mettant en oeuvre les étapes suivantes : - calcul, lors d'une étape D1, de la clé de chiffrement relative à la pile Kstack_i à partir d'éléments de la pile d'exécution de ladite application; - déchiffrement, lors d'une étape D2, avec la clé de chiffrement relative à la pile calculée Kstack_i, d'un cryptogramme (K)Kstack_i parmi l'ensemble des 5 cryptogrammes stockés, - si le déchiffrement est un échec, déchiffrement avec la clé de chiffrement relative à la pile calculée Kstack_i d'un autre cryptogramme (K)Kstackj parmi l'ensemble des cryptogrammes stockés, - si le déchiffrement est un succès, obtention de la clé de protection des secrets et 10 déchiffrement à l'aide de la clé de protection de secrets obtenue K dudit au moins un élément sensible chiffré, lors d'une étape D3. Dans une deuxième variante de mise en oeuvre, si l'ensemble des cryptogrammes (K)Kstack_i a été stocké en les indexant en fonction d'un hash de la 15 clé de chiffrement relative à la pile d'exécution, ce déchiffrement est réalisé en mettant en oeuvre les étapes suivantes: - calcul, lors d'une étape D1, de la clé de chiffrement relative à la pile Kstack_i à partir d'éléments de la pile d'exécution de ladite application; - déchiffrement, lors d'une étape D2, avec la clé de chiffrement relative à la pile 20 calculée Kstack_i et après calcul d'un hash de la clé de chiffrement relative à la pile d'exécution, du cryptogramme (K)Kstack_i stocké et indexé au hash calculé, - obtention de la clé de protection des secrets K et déchiffrement à l'aide de la clé de protection de secrets obtenue K dudit au moins un élément sensible chiffré, lors d'une étape D3. 25 Par ailleurs, dans le cas d'un code natif, si un fichier enregistrant une liste des index des écarts entre deux éléments de la pile d'exécution ne devant pas être utilisés pour la génération de la clé de chiffrement relative à la pile Kstack_i est stocké dans les moyens de stockage, et si un tel fichier contient plusieurs listes de 30 ce type, le déchiffrement de l'élément sensible comprend la détermination de la taille de la pile d'exécution au moment de la génération de la clé et prend en compte la liste correspondant à cette taille de pile pour générer la clé de chiffrement relative à la pile. Si le fichier comprend au moins deux listes d'index associées à cette taille de pile, une clé de chiffrement relative à la pile est calculée en prenant en compte une de ces listes d'index et cette clé est utilisée pour tenter de déchiffrer les cryptogrammes (K)Kstacki - Si un de ces déchiffrements est un succès, l'élément sensible chiffré est déchiffré à l'aide de la clé de protection de secrets K. Sinon, tant qu'aucun cryptogramme n'est déchiffré avec succès, une nouvelle clé de chiffrement relative à la pile est calculée en prenant en compte la liste suivante parmi ces listes d'index correspondant à la taille de la pile et cette clé de chiffrement relative à la pile est utilisée pour tenter de déchiffrer les cryptogrammes (K)Kstack i - Vérification de l'intégrité d'au moins un élément sensible d'une application Dans un deuxième mode de mise en oeuvre, le procédé peut être appliqué à la vérification de l'intégrité d'au moins un élément sensible d'une application, un premier code d'authentification de message MAC1 ayant été généré à partir dudit au moins un élément sensible et d'une clé secrète K, ladite clé secrète K ayant été chiffrée avec ladite clé de chiffrement relative à la pile Kstack_i générée à partir d'éléments de la pile d'exécution de ladite application. Ce deuxième mode de réalisation est illustré en figure 5b. Plus précisément, cette vérification d'intégrité est réalisée en mettant en oeuvre les étapes suivantes : - calcul, lors d'une étape V1, d'une clé de chiffrement relative à la pile Kstack_i à partir d'éléments de la pile d'exécution de ladite application, lors de l'exécution de l'application; - déchiffrement, lors d'une étape V2, avec la clé de chiffrement relative à la pile 25 calculée Kstack_i d'un cryptogramme (K)Kstack_i parmi l'ensemble des cryptogrammes stockés, - si le déchiffrement est un échec, déchiffrement avec la clé de chiffrement relative à la pile calculée Kstack_i d'un autre cryptogramme (K)Kstackj parmi l'ensemble des cryptogrammes stockés, 30 - si le déchiffrement est un succès, calcul d'un deuxième code d'authentification de message MAC2, lors d'une étape V3, à partir dudit au moins un élément sensible et de la clé secrète déchiffrée K et comparaison, lors d'une étape V4, des premier et deuxième code d'authentification de messages afin de vérifier l'intégrité dudit au moins un élément sensible.

Protection d'un code logiciel d'une application L'élément sensible protégé peut également comprendre du code logiciel de l'application ou du code logiciel de l'application déjà chiffré par le procédé de chiffrement décrit ci-dessus. Le procédé peut ainsi être appliqué à la protection d'une partie du code logiciel d'une application. L'application devra alors, lors de son exécution, calculer une clé de chiffrement relative à la pile à partir d'éléments de la pile d'exécution pour récupérer la clé de protection de secrets utilisée pour le chiffrement d'une partie du code de l'application protégée puis déchiffrer cette partie de code chiffrée pour pouvoir l'exécuter.

Plus précisément pour que cette partie de code logiciel soit protégée, comme représenté en figure 6, lors d'une phase d'initialisation une étape d'identification P1, dans le code logiciel de ladite application, de méthodes sensibles à protéger appelées dans le code logiciel de ladite application peut être mise en oeuvre. Pour ce faire un ensemble de sections de code sensibles sont identifiées dans l'application. Un arbre d'appel aux méthodes appelées dans le code peut ensuite être généré permettant d'identifier et de lister les méthodes à protéger comme illustré en figure 7 dans laquelle les méthodes à protéger sont les méthodes E3, Gl, G3 et Z8 et leur arborescence.

Ensuite, pour chaque méthode sensible identifiée method_i, une clé de chiffrement de méthode Kenc_i est générée lors d'une étape P2. Ces clés de chiffrement générées pour chaque méthode sont stockées dans un répertoire accessible par l'application lors de sa première exécution ainsi que la liste des correspondances clés et méthodes.

Puis chaque clé de chiffrement de méthode Kenc_i est chiffrée, lors d'une étape P3, conformément aux étapes de chiffrement E2 et 11 du procédé de chiffrement décrit ci-dessus de sorte à ce que des cryptogrammes (Kenc_i) vKadmin et (Kenc_i) Kstacki soient générés.

Pour ce faire, une clé de chiffrement administrateur est générée et conservée par l'administrateur. Toutes les clés de chiffrement de méthode Kenci sont chiffrées à partir de la clé de chiffrement administrateur de sorte à générer des cryptogrammes administrateur (Kenc_i) Kadmin. Selon un mode de mise en oeuvre, la clé de chiffrement administrateur est générée avant la génération des clés de chiffrement de méthode Kenc_i. Lorsqu'une telle clé de chiffrement de méthode Kenc_i est générée, elle peut alors être chiffrée directement à partir de la clé de chiffrement administrateur de sorte à générer le cryptogramme administrateur (Kenc_i)kadmin correspondant. Ainsi, les clés de chiffrement de méthode Kenc_i ne sont jamais stockées sous forme non chiffrée.

Les cryptogrammes générés sont stockés de façon à être disponibles pour les opérations décrites ci-dessous. Les cryptogrammes administrateur associés à une ou plusieurs méthodes sensibles sont ensuite déchiffrés avec la clé de chiffrement administrateur Kadmin.

Chaque méthode sensible identifiée method_i est ensuite chiffrée, lors d'une étape P4, avec sa clé de chiffrement de méthode Kenc_i associée, comme illustré en figure 8. Ce chiffrement peut être réalisé en partant des feuilles de l'arbre d'appel et en remontant vers la fonction main() de l'application. Ce chiffrement peut être mis en oeuvre lors de la phase de compilation de l'application ou peut être réalisé après celle-ci en insérant des fonctions proxy pointant vers le code chiffré et en supprimant le reste du code des méthodes protégées. Le chiffrement peut se faire sur l'ensemble de la sous arborescence d'une méthode. La méthode est chiffrée mais aussi les méthodes appelées par cette 30 dernière. Il est possible d'encapsuler du code chiffré dans du code chiffré et de renforcer ainsi la sécurité de l'application. Dans l'exemple de la figure 8, la méthode G1 chiffrée avec la clé Kenc_2 fait ainsi partie de l'arborescence de la méthode E3 chiffrée avec la clé Kenc_1. Le code d'une application pour laquelle le procédé selon l'invention a été utilisé de manière récursive en encapsulant du code chiffré dans du code chiffré sera recouvré à l'exécution de l'application de façon progressive grâce aux différentes piles d'exécution des procédures appelant des méthodes du code chiffrées. Une telle encapsulation rend plus difficile la tâche de recouvrement du code par un utilisateur malveillant par reverse engineering ou par débugage. Les procédures de déchiffrement successives peuvent être différentes pour chaque section de code chiffrée afin d'éviter de mettre un point d'arrêt ou de tracer les appels à une procédure de déchiffrement centralisée. Il est possible qu'une méthode, telle que la méthode G3 dans l'exemple de la figure 8, soit appelée par deux méthodes à protéger par des clés différentes. Il y a alors une collision dans le procédé de chiffrement/recouvrement pour la méthode G3. Plusieurs possibilités sont envisageables pour contourner un tel problème. Le code de l'application peut être modifié pour éviter d'appeler une méthode commune dans deux sous arborescences protégées mais ceci nécessite de modifier le code. Une liste de méthodes à exclure du procédé, c'est-à-dire qui ne seront pas chiffrées dans l'arborescence, peut être établie. Une telle méthode peut enfin être chiffrée uniquement avec une clé Kenc_i dédiée au chiffrement de cette méthode. Une telle méthode est alors exclue des chiffrements des sous arborescences auxquelles elle appartient. Ainsi cette procédure protégée restera accessible aux deux sous arborescences. Une telle solution est illustrée en figure 9 dans laquelle la méthode G3 est finalement chiffrée par une clé de chiffrement dédiée Kenc_3. Selon un mode de mise en oeuvre d'une telle solution, l'étape d'identification de méthodes sensibles à protéger P1 comprend alors une étape de construction d'un arbre d'appel des méthodes appelées dans ledit code logiciel et une étape de détermination d'au moins une méthode pouvant être appelée par au moins deux desdites méthodes sensibles à protéger identifiées, dite méthode en collision ; l'étape de génération P2 d'une clé de chiffrement de méthode Kenc_i comprend la génération d'au moins une clé de chiffrement de méthode supplémentaire ; l'étape de chiffrement P3 de chaque clé de chiffrement de méthode comprend le chiffrement conformément aux étapes de chiffrement E2 et 11 du procédé de chiffrement décrit ci-dessus de chaque clé de chiffrement de méthode supplémentaire ; et l'étape de chiffrement P4 d'une partie de code logiciel comprend le chiffrement, d'au moins une partie de code logiciel correspondant à ladite méthode en collision déterminée, uniquement avec ladite clé de chiffrement de méthode supplémentaire.

Enfin, dans une phase d'apprentissage mise en oeuvre lors du premier démarrage de l'application, les cryptogrammes nécessaires à l'exécution de l'application sont générés. Pour cela, lors du premier appel à une méthode chiffrée, la clé de chiffrement administrateur est acquise et utilisée pour déchiffrer le cryptogramme (Kenc_i)K_admin- Puis une clé de chiffrement relative à la pile Kstack_i est déterminée à partir de la pile d'exécution. Enfin la clé de protection de secrets Kenc_i est chiffrée avec la clé de chifffrement Kstack_i de sorte à produire le cryptogramme (Kenc_i) -,Kstack Î et ce cryptogramme est stocké dans un fichier. Un hash de la clé Kstack_i peut être utilisé comme nom de fichier afin d'indexer les cryptogrammes. L'application doit ensuite continuer à s'exécuter pour générer les cryptogrammes correspondant aux éventuelles autres méthodes protégées non encore traitées en phase d'apprentissage. Pour cela l'application appelle la méthode chiffrée selon le procédé d'appel décrit ci-dessous.

Lors de son exécution, que ce soit en phase d'apprentissage ou en fonctionnement normal, une application souhaitant exécuter une méthode protégée peut réaliser les opérations suivantes illustrées en figure 10. L'application commence par récupérer la clé de protection de secrets Kenc_i lors d'une étape CO. Pour cela elle calcule la clé de chiffrement relative à la pile Kstack_i à partir de la pile d'exécution. Elle détermine ensuite le cryptogramme (Kenc_i) -,Kstack à déchiffrer. Si les cryptogrammes sont indexés par un hash de la clé de chiffrement relative à la pile Kstack_i, l'application calcule un hash de la clé de chiffrement relative à la pile Kstack_i et cherche le cryptogramme dont le nom correspond à ce hash. Le cryptogramme est ensuite déchiffré de sorte à obtenir Kenc_i. La méthode protégée et son arborescence sont ensuite déchiffrées, lors d'une étape Cl, à raide de la clé de protection de secrets Kenc_i obtenue. Puis la méthode déchiffrée est appelée lors d'une étape C2.

L'arborescence de la méthode déchiffrée peut encore contenir du code chiffré si une des méthodes appelées dans cette arborescence a été elle-même chiffrée avec une autre clé de protection de secrets Kenc j selon le principe d'encapsulation de code chiffré dans du code chiffré décrit ci-dessus. Dans ce cas, cette méthode chiffrée sera à son tour déchiffrée par les opérations d'appel à une méthode protégée qui viennent d'être décrites, lorsque la méthode parent dans l'arbre d'appel des méthodes de l'application aura besoin d'exécuter cette méthode protégée.

Par ailleurs, les procédés décrits ci-dessus peuvent être implémentés dans ledit système informatique sous forme d'une ou plusieurs librairies partagées ou statiques stockées sur les moyens de stockages et utilisables par différentes applications pour protéger leurs éléments sensibles et les recouvrer.

Ainsi, un élément sensible d'une application peut être protégé sans nécessiter lors de l'exécution de celle-ci une intervention humaine. Aucun dispositif cryptographique matériel additionnel n'est requis. Les secrets d'une application ne sont accessibles qu'à cette application puisqu'elle est la seule à pouvoir reconstituer à partir de la pile d'exécution la clé de chiffrement relative à la pile Kstack_i nécessaire pour recouvrer la clé de protection de secrets employée pour protéger les éléments secrets de l'application.

Claims (2)

1. REVENDICATIONS1. Procédé de chiffrement d'une clé de protection de secrets (K) protégeant au moins un élément sensible d'une application caractérisé en ce qu'il comprend les étapes suivantes : -génération (El) d'une clé de chiffrement (Kstack_i) à partir d'éléments de la pile d'exécution de ladite application, dite clé de chiffrement relative à la pile, -chiffrement (E2) de la clé de protection de secrets (K) avec ladite clé de chiffrement relative à la pile générée (Kstack_i) de sorte à générer un cryptogramme (K)Kstack_i.
2. 2. Procédé de chiffrement selon la revendication 1, dans lequel la clé de chiffrement relative à la pile (Kstack_i) est une clé de chiffrement symétrique.3. 4. 5. 6. Procédé de chiffrement selon l'une des revendications précédentes, dans lequel l'étape de génération de la clé de chiffrement relative à la pile (Kstack_i) comprend une étape de calcul (E11) d'un hash cryptographique sur des éléments de la pile d'exécution de l'application. Procédé de chiffrement selon l'une des revendications précédentes, dans lequel les éléments de la pile d'exécution à partir desquels est générée la clé de chiffrement relative à la pile (Kstack_i) sont des éléments non variables de la pile d'exécution. Procédé de chiffrement selon la revendication 4, dans lequel un élément non variable de la pile d'exécution est parmi un nom de fonction constituant la pile d'exécution et, pour chaque fonction, le nom du package, le nom de la classe et le numéro de ligne de ladite fonction. Procédé de chiffrement selon la revendication 4, dans lequel un élément non variable de la pile d'exécution est un écart entre les adresses mémoires de deux éléments de la pile d'exécution.7. Procédé de chiffrement selon la revendication 6, dans lequel un élément non variable de la pile d'exécution est un écart entre les adresses mémoires de deux éléments de la pile d'exécution ne variant pas entre deux exécutions de l'application. 8. Procédé de chiffrement selon la revendication 7, dans lequel l'étape de génération (El) d'une clé de chiffrement relative à la pile (Kstack_i) à partir d'éléments de la pile d'exécution comprend : - pour une première exécution de l'application, le calcul d'un premier hash cryptographique (E111) pour chaque écart entre des adresses mémoires de deux éléments de la pile d'exécution, - pour une deuxième exécution de l'application, le calcul d'un deuxième hash cryptographique (E112) pour chaque écart entre des adresses mémoires de deux éléments de la pile d'exécution, - la comparaison (E113) des premiers et deuxièmes hash cryptographiques calculés, un élément non variable de la pile d'exécution étant un écart entre des adresses mémoires de deux éléments de la pile d'exécution pour lequel le premier hash cryptographique calculé est égal au deuxième hash cryptographique calculé. 9. Procédé de chiffrement selon l'une des revendications précédentes, comprenant préalablement une phase d'initialisation comprenant une étape de chiffrement (11) de la clé de protection de secrets (K) à partir d'un mot de passe administrateur. 10. Procédé de chiffrement selon la revendication 9, dans lequel l'étape de chiffrement (11) de la clé de protection de secrets à partir d'un mot de passe administrateur lors de ladite phase d'initialisation comprend : - une étape de génération (111) d'une clé de chiffrement administrateur (Kadmin) à partir du mot de passe administrateur de l'application et, - une étape de chiffrement (112) de la clé de protection de secrets (K) avec ladite clé de chiffrement administrateur générée (Kadmin) de sorte à générer un cryptogramme administrateur ((K)Kadmin).11. Procédé de chiffrement selon la revendication 10, dans lequel l'étape de génération d'une clé de chiffrement administrateur (111) lors de ladite phase d'initialisation comprend une étape de calcul (1111) d'un hash cryptographique sur le mot de passe administrateur de l'application. 12. Procédé de chiffrement selon l'une des revendications 10 ou 11, dans lequel dans une phase d'apprentissage mise en oeuvre au premier démarrage de ladite application, l'étape de chiffrement de la clé de protection de secrets (K) avec ladite clé de chiffrement relative à la pile générée (Kstack_i) (E2) comprend, préalablement au chiffrement de la clé de protection de secrets (K) avec ladite clé de chiffrement relative à la pile générée (Kstack_i),: -une étape d'acquisition (A1) du mot de passe de l'administrateur et de génération (A2) de la clé de chiffrement administrateur (Kadmin) à partir du mot de passe administrateur acquis; -une étape de déchiffrement (A3) du cryptogramme administrateur ((K)Kadmin) avec la clé de chiffrement administrateur (Kadmin) générée de sorte à obtenir la clé de protection de secrets (K). 13. Procédé de chiffrement selon l'une des revendications précédentes, dans lequel lors des différentes exécutions de l'application, l'ensemble des cryptogrammes (K)Kstack_i est stocké dans des moyens de stockage. 14. Procédé de chiffrement selon la revendication précédente, dans lequel lors des différentes exécutions de l'application, l'ensemble des cryptogrammes ((K)Kstack_i) est stocké dans lesdits moyens de stockage en les indexant en fonction d'un hash de la clé de chiffrement relative à la pile (Kstack_i). 15. Procédé de déchiffrement d'au moins un élément sensible d'une application chiffré avec une clé de protection de secrets (K), lors de l'exécution de ladite application, ladite clé de protection de secrets (K) étant chiffrée avec une clé de chiffrement relative à la pile (Kstack_i) selon le procédé de chiffrement de la revendication 13, comprenant des étapes de :- calcul (D1) de la clé de chiffrement relative à la pile (Kstack_i) à partir d'éléments de la pile d'exécution de ladite application; - déchiffrement (D2) d'un cryptogramme ((K)Kstack_i) parmi l'ensemble des cryptogrammes stockés à l'aide de la clé de chiffrement relative à la pile calculée (Kstack_i), - si le déchiffrement est un échec, déchiffrement d'un autre cryptogramme ((K)Kstackj) parmi l'ensemble des cryptogrammes stockés à l'aide de la clé de chiffrement relative à la pile calculée (Kstack_i), - si le déchiffrement est un succès, obtention de la clé de protection des secrets (K) et déchiffrement (D3) dudit au moins un élément sensible à l'aide de la clé de protection de secrets obtenue (K). 16. Procédé de déchiffrement d'au moins un élément sensible d'une application chiffré avec une clé de protection de secrets (K), lors de l'exécution de ladite application, ladite clé de protection de secrets (K) étant chiffrée avec une clé de chiffrement relative à la pile (Kstack_i) selon le procédé de chiffrement de la revendication 14, comprenant des étapes de : - calcul (D1) de la clé de chiffrement relative à la pile (Kstack_i) à partir d'éléments de la pile d'exécution de ladite application; - calcul d'un hash de la clé de chiffrement relative à la pile (Kstack_i) et déchiffrement (D2) avec la clé de chiffrement relative à la pile calculée (Kstack_i) du cryptogramme ((K)Kstack_i) stocké et indexé au hash calculé, - obtention de la clé de protection des secrets (K) et déchiffrement (D3) dudit au moins un élément sensible à l'aide de la clé de protection de secrets obtenue (K). 17. Procédé de vérification de l'intégrité d'au moins un élément sensible d'une application, un premier code d'authentification de message (MAC1) ayant été généré à partir dudit au moins un élément sensible et d'une clé secrète (K), ladite clé secrète (K) ayant été chiffrée selon le procédé de chiffrement de la revendication 13, comprenant des étapes de : - calcul (V1) d'une clé de chiffrement relative à la pile (Kstack_i) à partir d'éléments de la pile d'exécution de ladite application, lors de l'exécution de l'application;- déchiffrement (V2) avec la clé de chiffrement relative à la pile calculée (Kstack_i) d'un cryptogramme ((K)Kstack_i) parmi l'ensemble des cryptogrammes stockés, - si le déchiffrement est un échec, déchiffrement avec la clé de chiffrement relative à la pile calculée (Kstack_i) d'un autre cryptogramme ((K)Kstack j) parmi l'ensemble des cryptogrammes stockés, - si le déchiffrement est un succès, calcul (V3) d'un deuxième code d'authentification de message (MAC2) à partir dudit au moins un élément sensible et de la clé secrète déchiffrée (K) et comparaison (V4) des premier et deuxième codes d'authentification de messages afin de vérifier l'intégrité dudit au moins un élément sensible. 18. Procédé selon l'une des revendications précédentes, dans lequel l'élément sensible protégé est parmi un mot de passe, un code PIN, une clé cryptographique, des paramètres et fichiers de configuration de l'application. 19. Procédé selon l'une des revendications précédentes, dans lequel l'élément sensible protégé comprend du code logiciel de l'application ou du code logiciel de l'application chiffré selon le procédé de chiffrement de l'une quelconque des revendications 1 à 14. 20. Procédé de protection d'un code logiciel d'une application comprenant les étapes suivantes : - identification (P1), dans le code logiciel de ladite application, de méthodes sensibles à protéger appelées dans le code logiciel de ladite application; - pour chaque méthode sensible identifiée (method_i), génération (P2) d'une clé de chiffrement de méthode (Kenc_i) ; - chiffrement (P3) de chaque clé de chiffrement de méthode (Kenc_i) conformément au procédé de chiffrement de l'une des revendications 1 à 14 de sorte à générer des cryptogrammes ((Kenc_n .,Kadmin et (Kenc_i) Kstack_i); - chiffrement (P4) pour chaque méthode sensible identifiée (method_i) d'une partie de code logiciel correspondante avec sa clé de chiffrement de méthode (Kenc_i) associée ; -21. Procédé de protection d'un code logiciel selon la revendication précédente dans lequel l'étape d'identification de méthodes sensibles à protéger (P1) comprend : - une étape de construction d'un arbre d'appel des méthodes appelées dans ledit code logiciel, - une étape de détermination d'au moins une méthode pouvant être appelée par au moins deux desdites méthodes sensibles à protéger identifiées, dite méthode en collision, et dans lequel l'étape de génération d'une clé de chiffrement de méthode (Kenc_i) (P2) comprend la génération d'au moins une clé de chiffrement de méthode supplémentaire, l'étape de chiffrement de chaque clé de chiffrement de méthode (P3) comprend le chiffrement conformément au procédé de chiffrement de l'une des revendications 1 à 14 de l'au moins une clé de chiffrement de méthode supplémentaire, et l'étape de chiffrement d'une partie de code logiciel (P4) comprend le chiffrement, d'au moins une partie de code logiciel correspondant à ladite méthode en collision déterminée, uniquement avec ladite clé de chiffrement de méthode supplémentaire. 22. Procédé de protection selon la revendication précédente dans lequel une partie de code logiciel à chiffrer correspondant à une méthode à protéger comprend une sous-partie de code logiciel chiffrée selon le procédé de chiffrement de l'une quelconque des revendications 1 à 14. 23. Procédé d'appel d'une méthode d'un code logiciel d'une application protégé selon le procédé de protection de l'une des revendications 20 à 22 comprenant les étapes suivantes : - déchiffrement (C1) avec la clé de chiffrement de méthode (Kenc_i) associée et conformément au procédé de déchiffrement selon l'une des revendications 15 ou 16, de la partie de code chiffrée correspondant à ladite méthode (method_i); -appel (C2) de ladite méthode.24. Procédé d'appel selon la revendication 23 d'une méthode d'un code logiciel protégé selon le procédé de protection de la revendication 22 comprenant, pour chaque sous-partie de code logiciel chiffrée comprise dans ladite partie de code logiciel déchiffrée correspondant à ladite méthode, la mise en oeuvre du procédé d'appel de la revendication 23. 25. Produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur. 26. Module de traitement comprenant des moyens de communication, des moyens de calcul, et des moyens de stockage caractérisé en ce qu'il est configuré pour : -générer une clé de chiffrement relative à la pile (Kstack_i) à partir d'éléments de la pile d'exécution d'une application, -chiffrer une clé de protection de secrets (K) protégeant au moins un élément sensible de ladite application avec ladite clé de chiffrement relative à la pile générée (Kstack_i) de sorte à générer un cryptogramme ((K)Kstacki).