FR 3140960 A1 20240419 FR 2210698 A 20221017 L’invention concerne un procédé de génération d’encodage pour algorithme cryptographique, mis en œuvre par ordinateur. On y met en œuvre les étapes suivantes : - obtention d’au moins une caractéristique propre à un périphérique informatique (1) configuré pour exécuter un algorithme cryptographique (43) ; - à partir de la caractéristique propre, génération d’une opération d’encodage (433, 434) dépendante du périphérique (1); - association de l’opération d’encodage dépendante (433, 434) générée à l’algorithme cryptographique (43). Figure pour l’abrégé : figure 2 Encodage en boite blanche L’invention concerne la cryptographie en boite blanche, et plus particulièrement les opérations d’encodage associées à un algorithme de chiffrement dans le cadre d’un modèle d’attaque en boite blanche. La cryptographie en boite blanche est un sujet d’étude reposant sur le postulat qu’un attaquant, qui cherche à identifier des données secrètes, chiffrées, pouvant être déchiffrées au moyen d’un algorithme de chiffrement, a un accès complet à plateforme d’exécution de l’algorithme et à l’implémentation logicielle de cet algorithme dans la plateforme : le code binaire est ainsi entièrement visible, il est modifiable, et l’attaquant peut également agir à souhait sur l’exécution logicielle à travers les divers systèmes de la plateforme tels que la mémoire, les appels aux processeurs, etc. L’exemple le plus classique est celui d’un attaquant ayant accès à un smartphone d’un tiers, dans lequel une application logicielle du smartphone chiffre ou déchiffre des données secrètes au moyen d’une clé de chiffrement et d’un algorithme cryptographique, par exemple du type « AES » (pour « Advanced Encryption Standard »). L’attaquant a les pleins pouvoirs sur le smartphone et sur l’algorithme, et peut ainsi chercher à lire le code binaire correspondant, le modifier, l’exécuter d’une manière spécifique, avec pour objectif à terme, connaissant le type d’algorithme utilisé, d’identifier la clé de chiffrement, de déchiffrer les données secrètes, et/ou de modifier ces données. Pour empêcher cet attaquant d’accéder aux données secrètes et protéger l’intégrité du chiffrement dans ce contexte de boite blanche, on connaît dans l’état de la technique une méthode consistant à encoder des opérations élémentaires de l’algorithme de chiffrement (ou de déchiffrement). En effet, une opération élémentaire, issu de la combinaison entre un type d’algorithme connu et une clé de chiffrement spécifique, est généralement implémentée sous la forme d’une table de vérité indiquant les résultats possibles de l’opération en fonction des données d’entrée. Une opération d’encodage consiste donc à appliquer une transformation aléatoire à une opération élémentaire de manière à rendre illisible cette opération. Pour encoder une opération, on peut réaliser une substitution des éléments de la table de vérité, en combinant la table initiale avec une table de substitution aléatoire, de manière à obtenir une table « obfusquée » ou « fusionnée ». Alternativement, on peut appliquer à l’opération une transformation linéaire en combinant un vecteur représentant les données de sortie, ou une matrice correspondant à l’opération, à une autre matrice, dite matrice d’encodage, aléatoire elle-aussi. Un encodage peut aussi être une combinaison d’une ou plusieurs substitutions et d’une ou plusieurs matrices d’encodages. D’autres types d’encodage sont possibles. En outre, chaque opération élémentaire succédant à une opération élémentaire encodée est elle-même combinée avec un encodage dit « inverse », ou décodage, correspondant de façon inverse à l’encodage précédent. Il s’agit par exemple de la table de substitution inverse ou de la matrice inverse correspondantes à l’encodage précédent, de manière à ce que l’algorithme prévu initialement ne soit pas modifié par les encodages successifs. Dans tous les cas, on ne stocke dans la mémoire logicielle implémentant l’algorithme que les tables de vérité résultant de ces opérations d’encodage fusionnées avec les opérations élémentaires, c’est-à-dire les tables dites « obfusquées » ou « fusionnées ». De cette manière, l’attaquant, n’ayant accès qu’aux tables obfusquées, ne peut identifier quelle est l’opération élémentaire associée à chaque table et ne peut donc pas déterminer la clé de chiffrement utilisée et déchiffrer les données secrètes. Ces encodages, permettant d’encoder un algorithme de chiffrement (et/ou de déchiffrement) au sein d’une plateforme d’exécution non sécurisée, par exemple au sein d’un smartphone, sont dit « internes », puisqu’ils permettent de rendre illisible la clé de chiffrement utilisée au sein de la boite blanche formée par l’algorithme implémenté. Cependant, cette boite blanche communique généralement d’une part avec un serveur situé à distance, et d’autre part avec une application tierce située sur la même plateforme. Par exemple, il est courant qu’un serveur chiffre des données et communique les données chiffrées au smartphone, puis que la boite blanche, c’est-à-dire l’algorithme de déchiffrement exécuté par le smartphone, soit utilisé pour déchiffrer les données avant que ces données déchiffrées ne soient communiquées au sein du même smartphone à une application tierce, dite « finale », qui a vocation à utiliser les données déchiffrées. Or, les applications finales sont développées par des sociétés tierces, indépendamment des boites blanches. Ces sociétés font donc l’acquisition de boites blanches commercialisées sous la forme de bibliothèques logicielles contenant l’algorithme de chiffrement et de déchiffrement, et une API (pour « Application Programming Interface ») permettant de contrôler l’algorithme et d’utiliser les données sortant de cet algorithme dans l’application finale développée. Dans ce cadre, les encodages « internes » au sein de la boite blanche n’empêchent pas les données déchiffrées de circuler, en clair, entre la boite blanche et l’application finale. De même, même si la clé de chiffrement utilisée est désormais très difficile à identifier au sein de la boite blanche grâce aux encodages internes installés dans cette boite blanche, l’attaquant peut tenter de réaliser un portage du code, c’est-à-dire exporter l’intégralité du code de la boite blanche sur un autre périphérique pour l’y exploiter sans avoir à identifier la clé. C’est pourquoi il est connu dans l’état de la technique d’implémenter, en plus de ces encodages internes, des encodages dits « externes », placés aux extrémités du canal de communication complet entre l’envoi des données et leur usage. Par exemple, tout d’abord au sein du serveur situé à distance, un premier encodage « externe » est appliqué à la dernière table de vérité de l’algorithme de chiffrement du serveur, que ce soit sous la forme d’une table de substitution, d’une matrice d’encodage ou d’une autre forme d’encodage aléatoire, de sorte que les données à communiquer au smartphone sont non seulement chiffrées comme prévu, mais également encodées avant d’être communiquées au smartphone. Puis, à l’entrée de la boite blanche, l’encodage inverse de l’encodage externe est appliqué à la première table de vérité de l’algorithme de déchiffrement, avant que les données ne soient traitées à travers l’algorithme de déchiffrement de la boite blanche et ses encodages internes. L’encodage inverse correspondant au premier encodage externe fait donc partie de la boite blanche. Ensuite, un nouvel encodage aléatoire se fait à la sortie de la boite blanche, en appliquant ce nouvel encodage à la dernière table de vérité de la boite blanche. Là aussi, ce deuxième encodage fait dès lors partie de la boite blanche. En sortie, les données sont donc déchiffrées, mais encore encodées cette fois au moyen de ce nouvel encodage aléatoire, avant d’être communiquées à l’application tierce finale ayant vocation à les utiliser. Enfin, au sein de cette application tierce, l’encodage externe correspondant à l’inverse de l’encodage appliqué en fin de boite blanche permet de décoder au sein de l’application les données avant qu’elles ne soient utilisées par l’application. Grace à ces encodages externes placés à l’extérieur de la boite blanche, même une fois déchiffrées, les données ne circulent pas « en clair » à l’extérieur de la boite blanche, elles restent encodées, donc protégées des manipulations d’un attaquant qui souhaiterait les intercepter. En outre, l’attaque consistant à porter l’intégralité du code de la boite blanche sur un autre périphérique ne fonctionne pas, puisque dans ce cadre le code de la boite blanche comprend en son sein un encodage à son entrée et un encodage à sa sortie. Sans les encodages inverses correspondant, qui sont situés à distance (au sein du serveur et au sein de l’application finale), il n’est pas possible de de retrouver les données en clair. De plus, ajoutés aux encodages internes, ces encodages externes associés à des encodages en sortie et entrée de boite blanche rendent encore plus difficiles d’identifier la clé de chiffrement de la boite blanche. Il est à noter que l’ensemble de ces encodages, internes comme externes, sont aléatoires, c’est-à-dire qu’ils font appels à des transformations, substitutions ou autres manipulations inconnues de tous, de manière à ce qu’aucun attaquant ne puisse les retrouver. Cependant, ce procédé comprenant encodages internes et encodages externes comprend encore au moins deux inconvénients. Premièrement, comme indiqué plus haut, les applications finales sont développées par des sociétés tierces qui font l’acquisition de boites blanches et utilisent une API pour les contrôler. Ces sociétés doivent donc intégrer elles-mêmes à leur application l’encodage externe correspondant, de manière inverse, à l’encodage de sortie de la boite blanche. Elles doivent ensuite elles-mêmes s’assurer de la protection de cet encodage externe (qu’on peut appeler décodage externe) au sein de l’application finale. Elles ont donc une responsabilité s’agissant de la sécurité qui est inconfortable et les force souvent à faire appel à une solution extérieure, potentiellement couteuse, peu fiable et ajoutant de la complexité à l’ensemble du canal de communication des données. En outre, cette contrainte contrevient au principe de sécurité simplifiée vendu à ces sociétés lors de l’acquisition de la boite blanche. Deuxièmement, en cas de fuite de la boite blanche, il reste difficile d’identifier la source de la fuite. En particulier, il est peu pertinent d’embarquer des signatures ou jetons d’identification dans la boite blanche, puisque l’attaquant aura la possibilité de les modifier ou de les supprimer. L'invention a notamment pour but d’améliorer la sécurité d’un algorithme cryptographique en boite blanche déjà encodé. Un autre but est de permettre d’identifier la source d’une éventuelle fuite de l’algorithme. A cet effet l’invention a pour objet un procédé de génération d’encodage pour algorithme cryptographique, mis en œuvre par ordinateur, caractérisé en ce qu’on met en œuvre les étapes suivantes : - obtention d’au moins une caractéristique propre à un périphérique informatique configuré pour exécuter un algorithme cryptographique ; - à partir de la caractéristique propre, génération d’une opération d’encodage dépendante du périphérique ; - association de l’opération d’encodage dépendante générée à l’algorithme cryptographique. Ainsi, la transformation associée à l’opération d’encodage dépendante dépend d’au moins une caractéristique du périphérique sur lequel a vocation à être exécuté l’algorithme. Cette opération d’encodage dépendante, qu’on peut appeler encodage dépendant, permet donc d’ancrer l’algorithme sur un périphérique particulier. La sécurité des données et du chiffrement est donc améliorée. En particulier, si cet encodage dépendant est un décodage d’un encodage précédent, il est nécessaire pour décoder les données de générer cet encodage dépendant au moyen du périphérique, puisque seul ce périphérique fournit la caractéristique propre permettant de générer le bon décodage. Alternativement, si cet encodage dépendant vise à encoder des données, ces dernières ne pourront également qu’être décodées au moyen du périphérique. En outre, étant donné que l’encodage dépendant dépend du périphérique, il est plus facile d’identifier la source de la fuite de l’algorithme, puisque seul le périphérique prévu permet de décoder correctement les données encodées au moyen de cet encodage dépendant et donc d’exécuter l’algorithme. Par ailleurs, si l’attaquant modifie l’encodage dépendant pour rendre la source de la fuite introuvable, l’algorithme ne fonctionne plus, ce qui rend toute attaque inutile. Avantageusement, pour associer l’opération d’encodage dépendante à l’algorithme, on combine l’opération d’encodage avec une opération élémentaire cryptographique de l’algorithme de manière à former une seule opération fusionnée, de sorte qu’une donnée traitée par l’opération fusionnée est opérée conformément à l’opération élémentaire cryptographique et simultanément encodée conformément à l’opération d’encodage dépendante. Ainsi, l’encodage dépendant ne peut être distingué d’une opération élémentaire, en particulier de chiffrement ou déchiffrement, de l’algorithme. L’opération comme l’encodage dépendant sont donc impossibles à identifier pour un attaquant ayant accès au code exécutable. L’opération et l’encodage sont ainsi « masqués ». De préférence, on associe l’opération d’encodage dépendante à l’algorithme avant toute exécution cryptographique de l’algorithme sur le périphérique, en particulier lors d’une installation de l’algorithme sur le périphérique, l’exécution cryptographique correspondant en particulier à une opération de chiffrement ou de déchiffrement de données. Ainsi, l’algorithme inclut cet encodage dépendant avant-même qu’il ne soit utilisé sur le périphérique. L’encodage dépendant reste donc ici identique même si l’algorithme est implémenté sur un autre périphérique que celui dont l’encodage est dépendant. Il est notamment possible que l’algorithme se voit associer cet encodage avant d’être implémenté sur le périphérique, si le périphérique et sa caractéristique propre sont connus à l’avance. Alternativement, l’algorithme ayant été installé sur le périphérique, on réalise les étapes d’obtention de la caractéristique propre, de génération de l’opération d’encodage dépendante et de l’association de l’opération d’encodage dépendante à l’algorithme, lors d’une exécution cryptographique de l’algorithme sur le périphérique, l’exécution cryptographique correspondant en particulier à une opération de chiffrement ou de déchiffrement de données. Ainsi, ici l’encodage dépendant est au contraire généré au moment de l’exécution de l’algorithme. Il doit être en particulier généré de nouveau à chaque exécution. L’encodage dépendant généré peut donc dans ce cas varier en fonction du périphérique sur lequel il est généré. Avantageusement, l’opération d’encodage dépendante associée avant toute exécution cryptographique étant une première opération d’encodage dépendante, l’opération d’encodage dépendante générée et associée lors de l’exécution cryptographique sur le périphérique étant une deuxième opération d’encodage dépendante, on génère cette deuxième opération d’encodage de sorte qu’une donnée encodée via la première opération d’encodage dépendante est décodée via la deuxième opération d’encodage dépendante. En d’autres termes, on réalise parallèlement les deux opérations précédentes pour générer deux encodages dépendants distincts mais correspondants : l’un - généré à l’avance et restant identique quel que soit le périphérique sur lequel est implémenté l’algorithme - encode des données, tandis que l’autre, dans ce cas le décodage dépendant - généré à chaque exécution à partir du périphérique sur lequel est implémenté l’algorithme - décode ces mêmes données. Ainsi, les données ne peuvent être décodées que si l’algorithme est implémenté sur le périphérique dont sont dépendants l’encodage et le décodage. Si l’algorithme est implémenté sur un autre périphérique, l’encodage dépendant va encoder les données conformément au périphérique dont il est dépendant, puis le décodage dépendant va les décoder conformément à l’autre périphérique, de sorte que les données ne seront pas correctement décodées. L’association entre un encodage dépendant généré à l’avance et un décodage dépendant généré à chaque exécution cryptographique permet donc un ancrage de la boite blanche sur un périphérique particulier. On peut inverser les opérations de sorte que l’opération générée à l’avance est le décodage, l’opération générée à chaque exécution étant l’encodage. De préférence, l’opération élémentaire cryptographique étant une première opération élémentaire cryptographique et l’opération fusionnée étant une première opération fusionnée, l’algorithme comprenant également une deuxième opération élémentaire cryptographique succédant directement à la première opération élémentaire cryptographique, on met en œuvre les étapes suivantes : - combinaison, avant toute exécution cryptographique de l’algorithme sur le périphérique, de la première opération d’encodage dépendante avec la première opération élémentaire cryptographique de manière à former la première opération fusionnée ; - combinaison, lors de l’exécution cryptographique de l’algorithme sur le périphérique, de la deuxième opération d’encodage dépendante avec la deuxième opération élémentaire, de manière à former une deuxième opération fusionnée, de sorte que, lorsque la donnée encodée et opérée par la première opération fusionnée est traitée par la deuxième opération fusionnée, elle est décodée conformément à la deuxième opération d’encodage dépendante et simultanément opérée conformément à la deuxième opération élémentaire cryptographique. Ainsi, les opérations d’encodage et de décodage dépendants ne peuvent pas être distinguées, par un attaquant ayant accès au code exécutable, des opérations élémentaires auxquelles elles sont respectivement combinées. Ces opérations élémentaires et d’encodage sont « masqué e s » dans la boite blanche. Avantageusement, on met en outre en œuvre les étapes suivantes : - au préalable des premières étapes énoncées, génération d’une troisième opération d’encodage, non dépendante du périphérique, et d’une quatrième opération d’encodage, non dépendante du périphérique et générée de sorte qu’une donnée encodée via la troisième opération d’encodage est décodée via la quatrième opération d’encodage, - avant toute exécution cryptographique de l’algorithme, combinaison de la troisième opération d’encodage avec la première opération fusionnée, de manière à former une nouvelle première opération fusionnée permettant simultanément d’encoder la donnée conformément à la première opération d’encodage et à la troisième opération d’encodage et d’opérer la donnée conformément à la première opération élémentaire ; - lors de l’exécution cryptographique, combinaison de la quatrième opération d’encodage avec la deuxième opération fusionnée, de façon à former une nouvelle deuxième opération fusionnée permettant simultanément de décoder la donnée conformément à la deuxième opération d’encodage et à la quatrième opération d’encodage et d’opérer la donnée conformément à la deuxième opération élémentaire. Ainsi, on ajoute aux opérations d’encodage (et décodage) dépendantes du périphérique des opérations d’encodage (et de décodage) non dépendantes, c’est-à-dire aléatoires, conventionnelles, et on les fusionne également respectivement avec les première et deuxième opérations élémentaires de l’algorithme. On obtient donc deux opérations fusionnées, l’une correspondant à une première opération élémentaire, à l’encodage dépendant et à un encodage non dépendant (qu’on appelle troisième opération d’encodage), l’autre correspondant à la deuxième opération élémentaire, au décodage dépendant et au décodage non dépendant (qu’on appelle quatrième opération d’encodage), ces opérations ne pouvant pas être distinguées l’une de l’autre au sein des opérations fusionnées. L’ajout des encodages et décodage non dépendants permet de masquer la deuxième opération élémentaire. En effet, étant donné que le décodage dépendant (la deuxième opération d’encodage dépendante) n’est généré qu’à l’exécution de l’algorithme, en l’absence de l’encodage non dépendant, la deuxième opération élémentaire serait accessible et compréhensible pour un attaquant disposant du code exécutable. La fusion entre le décodage non dépendant et la deuxième opération élémentaire permet donc de masquer cette dernière avant la génération du décodage dépendant. Là encore, comme dans toute la description, sauf évidence contraire, les termes d’encodage et de décodage pourraient être inversés. De préférence, la première et la deuxième opération élémentaire cryptographique formant une paire d’opérations encodées, on répète les étapes de génération et de combinaison d’encodages pour au moins une autre paire d’opérations encodées de l’algorithme, de préférence pour plusieurs paires. Ainsi, le procédé concerne plus de deux opérations élémentaires cryptographiques de l’algorithme. Potentiellement, chaque opération élémentaire de l’algorithme peut être concernée par une association avec un encodage dépendant, mais la génération d’un encodage ou décodage dépendant au moment de l’exécution de l’algorithme nécessite des ressources et du temps qui peuvent rendre l’exécution trop longue. Il est donc avantageux d’adapter le nombre d’opérations élémentaires combinées aux encodages dépendants en fonction du degré de sécurité voulu et des ressources disponibles au sein du périphérique. Avantageusement, l’algorithme cryptographique est de type « AES », pour « Advanced Encryption Standard » ou « DES » pour « Data Encryption Standard ». Ces algorithmes, associés à des clés privées, incluent en effet des opérations aisément séparables les unes des autres et qui vont former les opérations élémentaires cryptographiques. Or, plus un algorithme est facilement séparable en opérations élémentaires simples, plus il est aisé de l’encoder en associant à ces opérations des encodages, en particulier ici des encodages dépendants. De préférence, la caractéristique propre au périphérique obtenue est l’une des caractéristiques suivantes ou une combinaison d’au moins certaines des caractéristiques suivantes : - le numéro MAC (pour « Media Access Control ») du périphérique ; - le numéro IMEI (pour « International Mobile Equipment Identity ») du périphérique ; - le numéro de série du téléphone ; - un compteur d’un nombre d’installations d’un algorithme cryptographique au sein du périphérique. Ainsi, la génération de l’encodage dépendant au moyen d’un autre périphérique aboutit à un encodage différent, ou à un décodage non correspondant, puisque la caractéristique propre est différente. Avantageusement, la génération de l’opération d’encodage dépendante du périphérique comprend une étape de hachage de la ou des caractéristiques propres au périphérique, de manière à générer une table d’encodage dépendante du périphérique ou une matrice d’encodage dépendante du périphérique, au moins un des éléments de la table ou respectivement de la matrice étant issu du hachage. Ainsi, les fonctions de hachage de type SHA, par exemple de la famille SHA-2, sont utilisables pour générer l’encodage dépendant à partir de la ou des caractéristiques propres. De préférence, pour combiner l’opération d’encodage dépendante avec l’opération cryptographique élémentaire, on substitue les termes d’une table de vérité correspondante à l’opération élémentaire au moyen de la table de substitution générée, de manière à former une table fusionnée correspondant à l’opération fusionnée, ou on réalise une opération mathématique entre une matrice correspondant à l’opération élémentaire et la matrice d’encodage dépendante générée, de manière à former une matrice fusionnée correspondant à l’opération fusionnée. On prévoit également selon l’invention un procédé de cryptographie, dans lequel on chiffre ou on déchiffre au moins une donnée sur un périphérique informatique par un algorithme cryptographique et on encode la donnée par au moins une opération d’encodage associée à l’algorithme, dans lequel l’opération d’encodage est dépendante d’au moins une caractéristique propre au périphérique. De préférence, l’opération d’encodage de ce procédé de cryptographie a été préalablement associée à l’algorithme cryptographique conformément au procédé de génération d’encodage décrit plus haut. On prévoit également selon l’invention un programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé de génération d’encodage ou du procédé cryptographie décrits plus haut. On prévoit également selon l’invention un support d'enregistrement lisible par ordinateur comprenant des instructions qui, lorsqu'elles sont exécutées par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé de génération d’encodage ou du procédé de cryptographie décrits plus haut. On prévoit également selon l’invention un périphérique informatique comprenant des moyens de calcul informatique aptes à exécuter un algorithme cryptographique associé à une opération d’encodage générée conformément au procédé décrit plus haut. Brève description des figures L'invention sera mieux comprise à la lecture de la description qui va suivre donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés dans lesquels : la est un schéma d’un système selon un mode de réalisation de l’invention ; la est un schéma détaillé d’une boite blanche selon le mode de réalisation de la ; la est un logigramme selon un premier mode de mise en œuvre de l’invention ; la est un logigramme selon un deuxième mode de mise en œuvre de l’invention ; la est un logigramme selon un troisième mode de mise en œuvre de l’invention incluant les premier et deuxième mode de mise en œuvre. Description détaillée Définitions On désigne par « opération élémentaire » toute transformation, par exemple mathématique, appliquée à une ou des données d’entrée résultant en une ou des données de sortie de l’opération. Au sein d’un code exécutable, une opération élémentaire peut ainsi être représentée par une table de vérité, accessible et compréhensible pour un attaquant informé, indiquant, pour chaque entrée possible de l’opération, chaque sortie correspondante. Il s’agit en particulier d’indiquer pour toute série de bits d’entrée dans une opération quelle est la série de bits de sortie correspondante. Par « encodage », on désignera dans la suite toute opération visant à rendre incompréhensible, au sein d’un code exécutable, soit une ou des données, soit la transformation associée à une opération élémentaire. L’encodage est donc lui-même une opération de transformation de données d’entrées en données de sortie. L’encodage d’une opération élémentaire vise donc à empêcher un attaquant de comprendre la table de vérité de l’opération élémentaire. Un tel encodage peut donc consister à remplacer les données de sortie de la table de vérité par d’autres données via une table de substitution, non enregistrée et aléatoire, indiquant les substitutions à effectuer. Il peut également s’agir d’une opération mathématique entre un vecteur correspondant aux données de sortie de la table de vérité initiale et une matrice aléatoire, dite matrice d’encodage, là encore non enregistrée. Dans tous les cas, la table de vérité initiale n’est alors plus accessible puisqu’elle est remplacée par la table de vérité « encodée », « fusionnée » ou encore dite « obfusquée », correspondant à la table résultant à la fois de l’opération élémentaire et de l’opération d’encodage associée. L’opération élémentaire encodée et l’encodage sont donc combinés l’un à l’autre de manière à ne plus pouvoir être distingués l’un de l’autre à la lecture du code exécutable. Par simplicité, bien que l’opération d’encodage ne soit elle-même pas distinguable des données ou de l’opération auquel elle est associée, et bien qu’elle puisse avoir été fusionnée à d’autres opérations successives, on pourra désigner dans la suite par « encodage » la position théorique de l’opération d’encodage dans une succession d’étapes. On pourra également désigner par « encodage » le résultat d’une opération d’encodage. Il est à noter qu’à tout encodage correspond nécessairement un encodage inverse, ou décodage. Il s’agit de l’opération associée à la transformation inverse de l’encodage, permettant de retrouver les données ou l’opération encodées lorsqu’elle est appliquée à la suite. On pourra dans la suite désigner un décodage indifféremment par le terme d’encodage ou d’encodage inverse. Lors d’une succession d’opérations élémentaires, en particulier dans un algorithme de chiffrement ou de déchiffrement, à une opération encodée succède une autre opération fusionnée avec l’encodage inverse. De cette façon, les opérations élémentaires se succèdent comme prévu dans l’algorithme sans que les encodages ne les perturbent. Dans le code exécutable, un attaquant peut parvenir à identifier une table obfusquée correspondant à une opération élémentaire et à un premier encodage, les deux opérations étant fusionnées. Puis, il peut identifier la table obfusquée suivante, correspondant à l’encodage inverse, à une nouvelle opération élémentaire et à un deuxième encodage, les trois opérations étant également fusionnées. Cependant, et c’est là l’intérêt des encodages, l’attaquant ne peut pas identifier les opérations élémentaires effectuées puisqu’elles sont fusionnées avec les encodages. Il ne peut donc pas retrouver la clé de chiffrement et les données chiffrées. On fera la distinction entre chiffrement/déchiffrement d’un côté, et encodage de l’autre. Le chiffrement ou le déchiffrement correspond à une succession d’opérations réalisées au moyen d’un algorithme cryptographique et d’une clé. Un encodage consiste à encoder l’une de ces opérations ou des données de sortie de ces opérations. Ainsi, par « algorithme cryptographique », on désignera un algorithme de chiffrement ou de déchiffrement basé sur un type d’algorithme connu, par exemple « DES » ou « AES », utilisant une clé spécifique, et on le distinguera des opérations d’encodages qui y sont fusionnées. Enfin, par « périphérique », on désigne tout terminal comprenant des moyens pour mettre en œuvre le procédé décrit. Dans la suite, il s’agira en particulier de tout terminal de communication doté de moyens de calcul informatique, tel qu’un smarpthone. Mode de réalisation Dans le mode de réalisation illustré, l’invention est mise en œuvre au sein d’un smartphone 1. Ce dernier inclut, sous forme logicielle, une application finale dont le code exécutable 2 est schématiquement illustré. Cette application reçoit en entrée des données chiffrées, tel que des données émises par un serveur bancaire 9 situé à distance, et permet en sortie de générer un paiement par smartphone. Il pourrait s’agir d’un tout autre type d’application et d’un tout autre type de données. Dans tous les cas, elle se présente sous la forme d’un code 2 exécutable via le smartphone 1, code 2 que l’on peut schématiquement diviser en deux parties. Ainsi, la partie 3 est directement issue du code source développé par le développeur, ou société de développement, en charge de l’application 2. Elle n’est pas propre à l’invention mais c’est le cœur de l’application 2 dans le sens où elle reçoit en entrée les données déchiffrées et met en œuvre le rôle attribué à l’application, ici un paiement conformément à des procédés qui ne sont pas spécifique de l’invention et ne seront pas décrits. La partie 4 du code 2 comprend un algorithme cryptographique de type « AES » (pour « Advanced Encryption Standard ») opérant avec une clé privée et des encodages internes à l’algorithme qui seront décrits en détails plus bas. Cet ensemble d’opérations forme un procédé de déchiffrement 43, qui permet de déchiffrer les données reçues du serveur 9 avant de les communiquer à la partie 3 qui va les utiliser. Cette portion 4 permettrait également de chiffrer des données à envoyer au serveur, on parlerait alors de chiffrement. La partie 4 forme une « boite blanche ». En effet, un attaquant disposant du smartphone 1 peut lire l’ensemble du code de l’application 2, le manipuler, l’exécuter d’une manière fine, pour essayer d’identifier dans cette partie 4 les données chiffrées, et/ou les opérations élémentaires formant l’algorithme de chiffrement ou de déchiffrement 42 pour en déduire en particulier la clé utilisée. Il peut également tenter d’exporter cette boite blanche 4 sur un autre dispositif. Cette boite blanche 4 comprend également en son sein deux encodages 41 et 42, distincts des encodages internes à l’algorithme 43 qui seront décrits plus bas. A ces encodages 41 et 42 correspondent des encodages dits « externes » 92 et 31. L’encodage 42 permet d’encoder les données en sortie des opérations de déchiffrement de l’algorithme 43. Ainsi, bien que les données soient déchiffrées par l’algorithme 43, elles ne circulent pas « en clair » entre la boite blanche 4 et le cœur 3. Le cœur 3 de l’application comprend au niveau de son entrée un encodage 31 qui est l’encodage inverse de l’encodage 42, permettant de décoder les données reçues de la boite blanche 4. Cet encodage inverse 31 est fusionné avec la première opération programmée par le cœur 3 de manière à ce que cet encodage 31 ne soit pas compréhensible. On considère que l’encodage 31 est « externe » car il est extérieur à la boite blanche. Il ne peut toutefois décoder que les données encodées via l’encodage 42 de la boite blanche, et vice versa. Similairement, l’encodage 41 à l’entrée de la boite blanche 4 est l’encodage inverse de l’encodage 92 placé en sortie de l’algorithme 91 au sein du serveur 9. Ainsi, les données en sorties du serveur 9 sont à la fois chiffrées et encodées, avant d’être décodées par l’encodage 41 puis déchiffrées par l’algorithme 43. Il est à noter que l’encodage 92 est le seul encodage associé à l’algorithme 91. En particulier, cet algorithme 91 n’inclut pas d’encodages internes, associés à des opérations élémentaires. La partie 4, englobant l’algorithme 43 et les encodages internes 41 et 42, n’est pas directement issue du développeur de l’application 2. En effet, elle a été développée par une autre société de façon indépendante à la partie 3, et a été acquise par le développeur de l’application 2 pour être implémentée sous la forme de bibliothèques logicielles. Ainsi, pour contrôler cette boite blanche 4 indépendante, il est prévu dans le code de la partie 3 des appels à une API (pour « Application Programming Interface ») fournie par le vendeur de la boite blanche 4, l’API permettant par exemple d’initialiser l’algorithme, de chiffrer ou déchiffrer des données au moyen de cet algorithme 43. Le développeur a donc utilisé l’API pour programmer les appels à la boite blanche 4 permettant d’obtenir les données déchiffrées ou au contraire de fournir à la boite blanche 4 des données à chiffrer. Enfin, à distance du smartphone, le serveur bancaire 9 inclut lui aussi sous forme logicielle un algorithme « AES » et une clé privée associée. L’algorithme permet de chiffrer des données au moyen de la clé avant de les communiquer au smartphone 1. L’ensemble de ces opérations de chiffrement forment l’algorithme de chiffrement 91. Il peut également permettre de déchiffrer des données reçues. En revanche et contrairement à l’algorithme 43, cet algorithme 91 ne comprend pas d’encodages internes. On va maintenant détailler les opérations de l’algorithme cryptographique 43 placé dans la boite blanche 4 et exécuté au sein du smartphone 1, en référence à la . On ne décrira pas dans quelle mesure et à quels moment la clé privée est changée, ni comment elle est communiquée au serveur 9, ces éléments n’étant pas propres à l’invention. En combinant un algorithme de type AES et une clé privée, on obtient l’algorithme cryptographique 43 qui sert dans le mode de réalisation illustré à déchiffrer des données chiffrées par l’algorithme 91. Il est donc formé d’une succession d’opérations élémentaires résultant de la combinaison entre l’algorithme AES tel qu’il est connu et la clé privée choisie ou déterminée. Ces opérations sont encodées, c’est-à-dire qu’à chaque opération est associée un encodage. Les encodages 432 et 435 ne dépendent pas des caractéristiques du smartphone 1, ils sont générés à l’installation de l’application 2 sur le smartphone indépendamment de ce dernier, ou avant même son installation. Les encodages 41 et 42 ne dépendent également pas du smartphone 1. En revanche, ils sont choisis de manière à correspondre aux inverses des encodages respectifs externes 92 et 31, ou inversement. Ces encodages 432, 435, 41, 42, 92 et 31 sont donc générés de façon conventionnelle. En revanche, l’encodage 433, généré à l’installation de l’application 2 sur le smartphone 1, dépend directement du smartphone 1, tandis que l’encodage 434 n’est généré qu’à chaque exécution de l’algorithme 43 et dépend également du smartphone 1, comme décrit ci-après. Sur la , l’opération élémentaire 431 est encodée par l’encodage 432. Cet encodage 342 est conventionnel : il s’agit de l’application d’une table de substitution choisie aléatoirement. Ainsi, les substitutions opérées ne dépendent de rien sinon du hasard. Ensuite est appliqué un nouvel encodage, l’encodage 433. Cet encodage est d’un type différent : il n’a pas été choisi au hasard. Au contraire, la table de substitution de cet encodage 433 a été décidée au moment de l’installation de l’application 2 sur le smartphone 1 et a été réalisée au moyen de caractéristiques du smartphone 1, selon un procédé qui sera décrit plus bas. En d’autres termes, cet encodage 433 dépend directement du smartphone 1 sur lequel l’application 2 a vocation à être utilisée. L’opération 431, l’encodage 432 et l’encodage 433 sont fusionnés de façon à ne plus pouvoir être distingués les uns des autres, et la table de vérité correspondante est implémentée définitivement dans l’algorithme 43 dès l’application 2 installée sur le smartphone 1. Dès lors, l’opération élémentaire 431 initiale ne peut plus être identifiée tel quel par un attaquant. L’opération élémentaire suivante de l’algorithme 43 est l’opération 436. Elle est fusionnée avec l’encodage 435 qui est l’encodage inverse de l’encodage 432. Ces deux opérations doivent également être fusionnées avec l’encodage 434 inverse de l’encodage 433. Par construction, cet encodage inverse 434 est nécessairement dépendant lui aussi du smartphone 1. Cependant, à la différence de l’ensemble des encodages précédents, l’encodage 434 n’est pas implémenté dans l’application 2, ni avant ni après son installation. En effet, il est généré uniquement à l’exécution de ces opérations. Procédés de génération d’encodage Nous allons maintenant décrire en référence à la un procédé de génération d’encodage 10 pour générer l’encodage dépendant 433. Il est mis en œuvre dans le cadre de l’installation de l’application 2 au sein du smartphone 1. Il est à noter que les opérations élémentaires auxquelles sont combinés les encodages portent sur des données formant des vecteurs de huit bits, c’est-à-dire 256 entrées possibles. Bien entendu, ce nombre peut varier et être ajusté afin d’équilibrer les ressources disponibles au niveau de sécurité souhaité. A l’étape 100, le programme 2 demande à obtenir des caractéristiques propres au smartphone 1 que sont le numéro MAC (pour « Media Access Control »), le numéro IMEI (pour « International Mobile Equipment Identity »), et le numéro de série du téléphone. Il génère également un quatrième numéro qui est un compteur incrémenté à chaque installation de la boite blanche 4 sur le smartphone 1. On désigne ces caractéristiques propres au smartphone 1 par le terme d’ « empreintes ». Ces appels sont effectués par le code 2 au moyen d’ « API » conventionnelles associées au smartphone. Ces appels peuvent avoir été préalablement autorisés par l’utilisateur au moment de confirmer l’installation de l’application 2. Les caractéristiques propres peuvent avoir été choisies différemment. A l’étape 200, les empreintes obtenues sont passées à une fonction de hachage de type SHA256, la fonction de hachage ayant été choisie pour que la sortie corresponde à une table de substitution de même type que la table de vérité des encodages conventionnels. La fonction de hachage est également choisie de manière à ce qu’une variation d’un des numéros fournis engendre en sortie une table de substitution différente. Elle est enfin choisie de manière à ce que cette table ne puisse être obtenue que par le hachage des numéros entrés et non par d’autres numéros. Ainsi, cette table, qui correspond donc à un encodage dépendant du smartphone 1, ne peut avoir été générée que via le smartphone 1. Cet encodage interne permet donc d’ancrer la boite blanche sur le smartphone 1. Dans le cas où la fonction de hachage servirait à établir une matrice d’encodage dépendante, il est nécessaire que cette matrice soit inversible, de manière à pouvoir déterminer l’encodage inverse. A l’étape 300, la table de substitution dépendante, où table d’encodage dépendant, est appliquée à la table de vérité résultant de l’encodage 432 (elle-même appliquée à la table initiale 431). A l’étape 400, seule la table de vérité finale, résultant de la combinaison entre la table associée à l’opération initiale 431, l’encodage 432 et l’encodage dépendant 433, est stockée dans le code exécutable 2. Il est à noter que, au lieu d’obtenir directement depuis le périphérique 1 les caractéristiques à l’étape 100, celles-ci peuvent être connues à l’avance. Dans ce cas, les étapes 200 à 400 pourraient être réalisées en dehors du périphérique 1. On peut ainsi envisager de mettre en place l’encodage 433 dans l’algorithme avant l’installation de cet algorithme dans le périphérique 1. On va maintenant décrire en référence à la un procédé de génération d’encodage 20 pour générer l’encodage dépendant 434. Celui-ci est mis en œuvre uniquement à chaque exécution de l’algorithme 43 sur le périphérique 1, c’est–à-dire lors du déchiffrement de données. A l’étape 500, qui est la première étape de la génération de cet encodage 434, le programme 2 demande à obtenir les caractéristiques propres au smartphone 1 que sont le numéro MAC (pour « Media Access Control »), le numéro IMEI (pour « International Mobile Equipment Identity »), et le numéro de série du téléphone. Il génère également le compteur démarrant à 0. Étant donné que ces appels sont effectués sur le même smartphone 1 que celui sur lequel les appels de l’étape 100 ont été effectués, et que le compteur est choisi pour démarrer au même stade, les mêmes empreintes sont obtenues. A l’étape 600, la même fonction de hachage que celle de l’étape 200 est appliquée sur ces numéros. Il en résulte la même table de substitution que celle déterminée à l’étape 200 du procédé 10. A l’étape 700, cette table est inversée, entrée et sorties se remplaçant les unes les autres. Cette table est donc l’inverse de la table résultant de l’étape 200. Des données encodées au moyen de l’une des tables pourraient donc directement être décodées au moyen de l’autre. A l’étape 800, cette table inverse est fusionnée avec l’encodage 435 et la table associée à la nouvelle opération élémentaire 436, de sorte qu’une seule table correspondant à ces trois opérations est stockée dans l’implémentation logicielle. Désormais, les données résultant de l’opération 431 et encodées par les encodages internes 432 et 433 peuvent être décodées par les décodages internes 434 et 435 en même temps que l’opération élémentaire 436 se déroule. Bien entendu, il est possible d’inverser les rôles des encodages 433 et 434 en générant l’encodage inverse 434 à l’installation et l’encodage 433 uniquement à chaque opération de déchiffrement. Il est à noter que, dans ce mode de mise en œuvre, seules les opérations 431 et 436 sont associées à des encodage 433 et 434 dépendants. Les autres opérations élémentaires de l’algorithme 43 ne sont associées qu’à des encodages conventionnels, tels que les encodages 432 et 435, ne dépendant pas du smartphone 1 et n’étant pas générés à l’exécution du déchiffrement, mais implémentés dès l’installation (voire avant). Cependant, il peut être avantageux de procéder à des encodages dépendants pour plusieurs des opérations de l’algorithme 43, afin d’améliorer encore plus la sécurité du procédé. En revanche, il peut ne pas être nécessaire de procéder à des encodages dépendants pour toutes les opérations élémentaires. En effet, un trop grand nombre de génération d’encodages dépendants risque d’engendrer une consommation de ressources excessive lors de l’opération du déchiffrement puisque chaque encodage à générer dans ce cadre devra faire l’objet des étapes 500 à 800. Le temps passé par l’exécution de l’algorithme 43 risque également d’être allongé. Au final, dans une variante à plusieurs encodages dépendants, chaque opération de l’algorithme 43 est associée à un encodage conventionnel, puis certaines de ces opérations sont, en outre, associées à des encodages dépendants tels que les encodages 433 et 434. Il est du ressort du développeur de la boite blanche d’identifier le nombre et la place des encodages dépendants en fonction du degré de sécurité voulu et des ressources du périphérique prévu. Chiffrage, déchiffrage, encodage et décodage de données On va maintenant décrire un procédé 30 résumant la chaine de communication de données entre le serveur 9 et le cœur 3 de l’application 2 au moyen notamment des procédés 10 et 20. L’étape 40 est l’initialisation du canal de communication. Les boites blanches 4 et 91, respectivement au sein du smartphone 1 et du serveur 9, sont installées lorsque l’application 2 est installée. Les opérations élémentaires initiales de l’algorithme 43, ainsi que l’algorithme 91, sont générés de manière à ce que l’algorithme 43 puisse déchiffrer des données chiffrées par l’algorithme 91, et vice versa. En particulier, dans le cadre d’algorithme de type « AES », la clé privée est la même pour les algorithmes 43 et 91. Les algorithmes diffèrent toutefois en ce que l’algorithme 91, placé sur le serveur, ne comprend pas d’encodages interne, car le serveur est considéré comme un environnement sécurisé. Les étapes 100 à 400 du procédé 10 sont alors mises en œuvre. En particulier, l’encodage dépendant 433 est généré à ce moment-là dans l’application 2 au moyen des caractéristiques du smartphone 1. C’est également le cas des encodages non dépendants 432 et 435. A l’étape 50, le cœur 3 de l’application 2 requiert l’envoi de données secrètes de la part du serveur 9 situé à distance. Il s’agit en particulier de validations de données bancaires pour valider un paiement. A l’étape 60, le serveur 9 chiffre les données demandées au moyen de l’algorithme 91. A l’étape 70, les données chiffrées sont encodées par l’encodage externe 92 situé sur le serveur 9. A l’étape 80, elles sont envoyées au smartphone 1, en particulier à l’application 2, et en particulier à la boite blanche 4. A l’étape 90, l’encodage 41 à l’entrée de la boite blanche, qui correspond à l’inverse de l’encodage 92, décode les données. Pour rappel, étant donné qu’il est fusionné à l’opération et à l’encodage suivants, ce décodage n’est pas compréhensible pour un attaquant. Les étapes 500 à 800 décrites plus haut, du procédé 20, sont ensuite réalisées au cœur de l’algorithme 43 de déchiffrement des données. En particulier, l’encodage dépendant 434, inverse de l’encodage 433, est généré uniquement au moment de ce déchiffrement. A l’étape 810, une fois l’encodage 433 généré, les données sont déchiffrées et décodées. A l’étape 820, les données toujours déchiffrées sont à nouveau encodées, cette fois au moyen de l’encodage 42. A l’étape 830, les données déchiffrées et encodées sont communiquées au cœur 3 de l’application. A l’étape 840, l’encodage externe 31, inverse de l’encodage 42, décode les données. Là encore, sa fusion avec les opérations ultérieures du cœur 3 ne permettent pas de l’identifier. Il est à noter que bien que le procédé illustré soit un procédé de déchiffrement, les encodages fonctionnent de la même manière pour un procédé de chiffrement. Les encodages sont alors associés à des opérations élémentaires de chiffrement plutôt que de déchiffrement. Les encodages internes dépendants 433 et 434 permettent donc d’ancrer la boite blanche sur le smartphone 1. Ainsi, même si un encodage externe, typiquement l’encodage 31, venait à fuiter, c’est-à-dire à être identifié par un attaquant, les encodages dépendants internes à la boite blanche assureraient une sécurité supplémentaire. En effet, grâce à ces encodages dépendants 433 et 434, il est nécessaire de disposer du smartphone 1 pour exécuter l’algorithme. En effet, en l’exécutant sur un dispositif différent, l’encodage 434 généré au moment de l’exécution sur ce nouveau périphérique ne correspondrait pas à l’encodage 433 dépendant du smartphone 1, et l’algorithme 43 dans son ensemble échouerait. Un attaquant ne peut donc pas faire fonctionner la boite blanche sur un autre dispositif. En outre, à la différence d’une signature ou de jeton d’identification, ces encodages dépendants ne peuvent pas être supprimés par l’attaquant, car, étant donné qu’ils sont fusionnés aux étapes élémentaires de l’algorithme, ils font pleinement partie de l’algorithme et toute modification engendrerait l’échec de l’exécution de l’algorithme. Une attaque ne devient donc réalisable qu’au moyen d’une machine virtuelle visant à fausser les empreintes du périphérique. Cependant, pour ce faire, il est nécessaire de très bien connaître le périphérique, au point qu’il est préférable de le posséder, rendant la création d’une machine virtuelle appropriée obsolète. Ce procédé d’encodages dépendants internes à la boite blanche dépend du développeur de la boite blanche et pas du développeur de l’application finale. Ceci est conforme à l’esprit de sécurité simplifiée associé à la vente de boites blanches « clef en main » aux sociétés développant des applications finales. En particulier, la responsabilité de ces dernières concernant la protection des encodages externes est atténuée étant donné que les encodages dépendants internes à la boite blanche offrent une sécurité supplémentaire. En outre, la génération d’un encodage dépendant permet de faciliter l’identification d’une fuite. En effet, étant donné que seule la plateforme d’exécution appropriée à l’encodage dépendant peut permettre de faire fonctionner l’algorithme, il est plus facile d’identifier la plateforme d’où provient la fuite. Ainsi, dans le cas du mode de réalisation illustré, si la boite blanche 4 venait à fuir, elle ne fonctionnerait sur aucun dispositif excepté sur le smartphone 1, ce qui permettrait de déterminer qu’elle est issue du smartphone 1. L'invention n'est pas limitée aux modes de réalisation présentés et d'autres modes de réalisation apparaîtront clairement à l'homme du métier. Par exemple, d’autres fonctions de hachage sont possibles. De plus, la caractéristique propre ne se limite pas aux exemples fournis mais concerne toute caractéristique qui peut être extraite d’un périphérique et qui est propre à ce périphérique. Il s’agit également de toute combinaison pertinente de caractéristiques propres permettant d’isoler encore plus un périphérique vis-à-vis des autres. En outre, l’invention rend en particulier pertinent le fait de se passer des encodages externes, qui sont dans le mode de réalisation illustré les encodages 92 et 31. Dans ce cas, les encodages 41 et 42 sont également retirés. Ceci est particulièrement pertinent en ce qui concerne l’encodage externe 31 dont l’implémentation et la protection doivent être assurés par le développeur de l’application finale 2, ce qui contrevient au principe de sécurité simplifié vendu avec la boite blanche 4. Or, étant donné que les encodages dépendants permettent d’ancrer la boite blanche sur le périphérique comme le vise les encodages externes, ces derniers deviennent surabondants et peuvent être supprimés. Dans ce cas, toute attaque de type portage de code de la boite blanche reste délicate compte tenu des encodages dépendants, et le développeur de l’application finale n’a plus à assurer la sécurité d’un encodage. En revanche, dans ce cas, les données circulent en clair, c’est-à-dire de manière déchiffrée, entre l’algorithme de déchiffrement et l’application finale. Il est possible d’intégrer des encodages internes à l’algorithme 91 de manière à améliorer sa sécurité. En outre, il est possible d’intégrer comme à la boite blanche 43 des encodages dépendants à l’algorithme 91 du serveur, pour améliorer encore sa sécurité et faciliter l’identification d’une éventuelle fuite de cette boite blanche 91. Cela est toutefois généralement moins indispensable que pour un algorithme opérant sur un périphérique mobile, où la sécurité est plus sujette à caution. Il est possible d’intégrer des encodages dépendants dans des algorithmes cryptographiques autres que l’algorithme de type « AES ». C’est par exemple le cas pour l’algorithme « DES » (pour « Data Encryption Standard »). De manière plus générale, chaque algorithme pouvant être encodé peut faire l’objet des encodages dépendants de l’invention. C’est particulièrement le cas des procédés de chiffrement ou déchiffrements divisés en opérations élémentaires pouvant être encodées. Procédé (10, 20) de génération d’encodage pour algorithme cryptographique, mis en œuvre par ordinateur, caractérisé en ce qu’on met en œuvre les étapes suivantes : obtention (100, 500) d’au moins une caractéristique propre à un périphérique informatique (1) configuré pour exécuter un algorithme cryptographique (43) ; à partir de la caractéristique propre, génération (200, 600) d’une opération d’encodage (433, 434) dépendante du périphérique (1); association (300, 400, 700, 800) de l’opération d’encodage dépendante générée à l’algorithme cryptographique. Procédé (10, 20) selon la revendication précédente, dans lequel, pour associer l’opération d’encodage dépendante (433, 434) à l’algorithme, on combine l’opération d’encodage (433, 434) avec une opération élémentaire cryptographique (431, 436) de l’algorithme de manière à former une seule opération fusionnée, de sorte qu’une donnée traitée par l’opération fusionnée est opérée conformément à l’opération élémentaire cryptographique (431, 436) et simultanément encodée conformément à l’opération d’encodage dépendante (433, 434). Procédé (10) selon l’une quelconque des revendications précédentes, dans lequel on associe (300, 400, 700, 800) l’opération d’encodage dépendante (433) à l’algorithme (43) avant toute exécution cryptographique de l’algorithme sur le périphérique (1), en particulier lors d’une installation (40) de l’algorithme sur le périphérique, l’exécution cryptographique correspondant en particulier à une opération de chiffrement ou de déchiffrement de données. Procédé (20) selon l’une quelconque des revendications 1 à 2, dans lequel, l’algorithme (43) ayant été installé sur le périphérique (1), on réalise les étapes d’obtention (100) de la caractéristique propre, de génération (200) de l’opération d’encodage dépendante (434) et de l’association (300, 400) de l’opération d’encodage dépendante (434) à l’algorithme (43), lors d’une exécution (810) cryptographique de l’algorithme sur le périphérique, l’exécution cryptographique correspondant en particulier à une opération de chiffrement ou de déchiffrement de données. Procédé (10, 20) selon les revendications 3 et 4, dans lequel l’opération d’encodage dépendante (433) associée (10) avant toute exécution cryptographique selon la revendication 3 étant une première opération d’encodage dépendante, l’opération d’encodage dépendante (434) générée et associée (20) lors de l’exécution (810) cryptographique sur le périphérique (1) selon la revendication 4 étant une deuxième opération d’encodage dépendante, on génère cette deuxième opération d’encodage (434) de sorte qu’une donnée encodée via la première opération d’encodage dépendante (433) est décodée via la deuxième opération d’encodage dépendante (434). Procédé (10, 20) selon la revendication précédente et la revendication 2, dans lequel l’opération élémentaire cryptographique (431) étant une première opération élémentaire cryptographique et l’opération fusionnée étant une première opération fusionnée, l’algorithme (43) comprenant également une deuxième opération élémentaire cryptographique (436) succédant directement à la première opération élémentaire cryptographique, on met en œuvre les étapes suivantes : Combinaison (10), avant toute exécution cryptographique de l’algorithme sur le périphérique, de la première opération d’encodage dépendante (433) avec la première opération élémentaire cryptographique (431) de manière à former la première opération fusionnée ; Combinaison (20), lors de l’exécution cryptographique de l’algorithme sur le périphérique, de la deuxième opération d’encodage dépendante (434) avec la deuxième opération élémentaire (436), de manière à former une deuxième opération fusionnée, de sorte que, lorsque la donnée encodée et opérée par la première opération fusionnée est traitée par la deuxième opération fusionnée, elle est décodée conformément à la deuxième opération d’encodage dépendante (434) et simultanément opérée conformément à la deuxième opération élémentaire cryptographique (436). Procédé (10, 20) selon la revendication précédente, dans lequel on met en outre en œuvre les étapes suivantes : au préalable des étapes de la revendication 1, génération (40) d’une troisième opération d’encodage (432), non dépendante du périphérique (1), et d’une quatrième opération d’encodage (435), non dépendante du périphérique et générée de sorte qu’une donnée encodée via la troisième opération d’encodage (432) est décodée via la quatrième opération d’encodage (435), avant toute exécution cryptographique de l’algorithme (43), combinaison de la troisième opération d’encodage (432) avec la première opération fusionnée, de manière à former une nouvelle première opération fusionnée permettant simultanément d’encoder la donnée conformément à la première opération d’encodage (433) et à la troisième opération d’encodage (432) et d’opérer la donnée conformément à la première opération élémentaire (431) ; lors de l’exécution cryptographique (810), combinaison de la quatrième opération d’encodage (435) avec la deuxième opération fusionnée, de façon à former une nouvelle deuxième opération fusionnée permettant simultanément de décoder la donnée conformément à la deuxième opération d’encodage (434) et à la quatrième opération d’encodage (435) et d’opérer la donnée conformément à la deuxième opération élémentaire (436). Procédé (10, 20) de génération d’encodage selon l’une des revendications 6 à 7, dans lequel la première (431) et la deuxième (436) opération élémentaire cryptographique formant une paire d’opérations encodées, on répète les étapes de génération et de combinaison d’encodages pour au moins une autre paire d’opérations encodées de l’algorithme (43), de préférence pour plusieurs paires. Procédé (10, 20) selon l’une quelconque des revendications précédentes, dans lequel l’algorithme cryptographique est de type « AES », pour « Advanced Encryption Standard » ou « DES » pour « Data Encryption Standard ». Procédé (10, 20) selon l’une quelconque des revendications précédentes, dans lequel la caractéristique propre au périphérique (1) obtenue est l’une des caractéristiques suivantes ou une combinaison d’au moins certaines des caractéristiques suivantes : - le numéro MAC (pour « Media Access Control ») du périphérique ; - le numéro IMEI (pour « International Mobile Equipment Identity ») du périphérique ; - le numéro de série du téléphone ; - un compteur d’un nombre d’installations d’un algorithme cryptographique au sein du périphérique. Procédé (10, 20) selon l’une quelconque des revendications précédentes, dans lequel la génération de l’opération d’encodage dépendante (433, 434) du périphérique (1) comprend une étape de hachage (200, 600) de la ou des caractéristiques propres au périphérique (1), de manière à générer une table d’encodage dépendante du périphérique ou une matrice d’encodage dépendante du périphérique, au moins un des éléments de la table ou respectivement de la matrice étant issu du hachage. Procédé (10, 20) selon au moins la revendication précédente et la revendication 2, dans lequel, pour combiner l’opération d’encodage dépendante (433, 434) avec l’opération cryptographique élémentaire (431, 436), on substitue les termes d’une table de vérité correspondante à l’opération élémentaire au moyen de la table de substitution générée, de manière à former une table fusionnée correspondant à l’opération fusionnée, ou on réalise une opération mathématique entre une matrice correspondant à l’opération élémentaire et la matrice d’encodage dépendante générée, de manière à former une matrice fusionnée correspondant à l’opération fusionnée. Procédé de cryptographie (30), dans lequel on chiffre ou on déchiffre au moins une donnée sur un périphérique informatique (1) par un algorithme cryptographique (43) et on encode la donnée par au moins une opération d’encodage (433, 434) associée à l’algorithme, caractérisé en ce que l’opération d’encodage (433, 434) est dépendante d’au moins une caractéristique propre au périphérique (1). Procédé (30) selon la revendication précédente, dans lequel l’opération d’encodage (433, 434) a été préalablement associée à l’algorithme cryptographique (43) conformément à l’une quelconque des revendications 1 à 12. Programme d'ordinateur (2) comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé selon l’une quelconque des revendications 1 à 14. Support d'enregistrement lisible par ordinateur comprenant des instructions qui, lorsqu'elles sont exécutées par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé selon l’une quelconque des revendications 1 à 14. Périphérique informatique (1) comprenant des moyens de calcul informatique aptes à exécuter un algorithme cryptographique associé à une opération d’encodage générée conformément à l’une quelconque des revendications 1 à 12.