FR2875657A1 - Procede de securisation de traitements cryptographiques par le biais de leurres. - Google Patents

Abstract

Dans le procédé de sécurisation d'un traitement cryptographique contre des attaques physiques selon l'invention, tout ou partie dudit traitement cryptographique est réitéré plusieurs fois : une ou plusieurs fois sur les données correctes, les autres fois sur des données incorrectes en vue de leurrer un attaquant, le choix des itérations effectuées sur des données correctes ou incorrectes étant fait de manière aléatoire, et les itérations effectuées sur les données incorrectes étant ignorées dans le résultat final du traitement.

Description

La présente invention concerne un procédé pour la sécurisation de

traitements cryptographiques destinés à assurer la protection de données et/ou de programmes d'un système informatique tels que, par exemple, mais non exclusivement, un système embarqué.

D'une manière générale, on sait que certains systèmes embarqués, comme par exemple les cartes à puce, sont conçus pour protéger les données et les programmes qu'ils contiennent. En particulier, le support matériel de ces systèmes rend très difficile l'observation et la modification non seulement des données stockées ainsi que de l'exécution des programmes.

La protection n'est toutefois pas totale. Ces systèmes peuvent être exposés à des actions malveillantes, aussi appelées attaques, qui visent à altérer le bon fonctionnement des programmes ou à dévoiler des informations confidentielles. Certaines attaques, dites physiques, opèrent au niveau du matériel, par opposition aux attaques logicielles.

Les attaques physiques d'observation effectuent un espionnage matériel passif d'un circuit. Elles incluent par exemple la mesure du temps d'exécution (ou du nombre de cycles effectués par le processeur), la mesure de la consommation électrique, l'analyse des émissions électromagnétiques, etc. 2875657 2 Les attaques physiques de perturbation modifient l'état ou les propriétés matérielles d'un circuit. Elles incluent par exemple la perturbation de l'alimentation électrique (pics de tensions, ...), le bombardement par des rayonnements (flash de lumière, ...), la destruction de portes logiques, etc. Une perturbation peut dérouter un programme de son exécution normale ou modifier les valeurs des données sur lesquelles il opère (par exemple, en imposant des valeurs où tous les bits sont à 0, ou bien à 1) afin de le tromper ou de révéler indirectement certaines informations dans les résultats produits ou dans les émissions physiques.

Les attaques physiques de perturbation sont souvent combinées à des attaques d'observation. En effet, pour que la perturbation soit pertinente du point de vue de l'attaque, il est souvent nécessaire de la pratiquer à des moments opportuns de l'exécution et donc de se synchroniser avec le programme en cours d'exécution, ce qui nécessite une observation physique.

Les données plus particulièrement visées par les attaques sont les données de clés numériques. Ces clés sont utilisées dans des traitements, notamment des calculs cryptographiques (chiffrement, déchiffrement, signature, etc.) pour s'assurer de la confidentialité et/ou de l'authenticité et/ou de l'intégrité de textes, notamment lors des échanges entre le programme (ou système) et le monde extérieur: un texte chiffré ne peut être lu que par quelqu'un qui dispose de la clé de déchiffrement, une signature apposée sur un texte peut garantir son origine et le fait que le texte n'a pas été modifié, etc. Certains traitements cryptographiques, comme les reconnaissances d'empreinte (hash) , ne reposent pas sur des clés.

Les données de clé diffèrent suivant le type de traitement: bloc de bits pour un traitement de cryptage de données standard DES ("Data Encryption Standard"), module et exposant pour un traitement RSA ("Rivest-ShamirAdleman"), etc. La taille des données de clé peut varier en fonction du niveau 2875657 3 de protection recherché. En effet, un traitement cryptographique n'offre pas une garantie totale mais une garantie statistique (ou probabiliste). Les attaques logicielles consistent à exploiter le résultat d'un grand nombre de calculs effectués par le système pour tenter d'en déduire la clé utilisée. En général, plus la taille des données de clé est grande, plus grand est aussi le nombre de calculs nécessaires pour retrouver la valeur de la clé. Pour assurer une bonne protection, on fait en sorte que ce nombre de calculs soit très difficilement réalisable par un attaquant.

Toutefois, les traitements cryptographiques sont souvent implémentés par des algorithmes bien connus dont l'exécution a une trace caractéristique décelable par une observation physique de l'exécution. Cette trace que laisse l'exécution permet à un attaquant de se synchroniser avec les traitements, non seulement pour tenter d'en déduire une partie des données manipulées mais aussi pour pratiquer des perturbations de l'exécution, perturbations qui permettent à leur tour de faciliter d'autres observations. Par des exécutions répétées sur des données d'entrée différentes, un attaquant détermine petit à petit des informations concernant les clés, jusqu'à finalement les connaître dans leur intégralité.

En pratique, la nature de la trace laissée par une exécution dépend bien sûr du type d'observation mais aussi de la manière dont le traitement est implémenté. En particulier, dans certains systèmes embarqués, comme par exemple les cartes à puce, certaines implémentations ont recours à des circuits ou processeurs spécifiques (crypto-processeurs) qui effectuent tout ou partie de certains traitements cryptographiques. Les avantages sont notamment un temps de traitement beaucoup plus faible et, en général, une protection renforcée contre les attaques physiques, tant du point de vue de l'observation que de la perturbation.

2875657 4 En l'absence de crypto-processeur, ou si le crypto-processeur n'effectue qu'une partie des traitements (qu'il peut falloir alors itérer) , des opérations liées au traitement cryptographique doivent être effectuées par le processeur principal du système. De ce fait, elles sont davantage exposées à une attaque.

Parmi les attaques physiques les plus connues basées sur l'observation, on peut citer les attaques de type SPA ("Simple Power Analysis") et DPA ("Differential Power Analysis"), qui sont basées sur un enregistrement de la consommation électrique et qui ont été utilisées avec succès notamment pour découvrir des clés de type DES.

Dans le cas d'attaques de type SPA, des observations plus fines, éventuellement corrélées avec des mesures de temps, permettent ensuite de déterminer des bits de la clé car les opérations effectuées (et leur trace en terme de consommation électrique ou de temps d'exécution) diffèrent légèrement suivant que ces bits valent 0 ou 1.

Dans le cas d'attaques de type DPA, employées notamment quand des mesures anti-SPA ont été prises (voir ci-dessous), on effectue non pas un mais plusieurs traitements cryptographiques, que l'on traite avec des outils statistiques. Pour cela, on fait une hypothèse sur la présence d'un bit positionné à 0 dans des données d'une opération particulière du traitement cryptographique et on effectue deux suites de traitements cryptographiques sur des données particulières choisies pour opérer sur ce bit, valant soit 0, soit 1.

On fait ensuite la moyenne de ces deux suites de mesures, puis la différence de ces deux moyennes. S'il y a un pic dans la courbe résultante, l'hypothèse de départ était bonne (le bit était à 0), sinon l'hypothèse était fausse. On peut ainsi de proche en proche déterminer tous les bits de la clé.

Les attaques de type SPA et DPA ont leur pendant en terme non pas de consommation électrique mais d'émissions électromagnétiques: ce sont la 2875657 5 SEMA ("Simple Electromagnetic Emanation Analysis") et la DEMA ("Differential Electromagnetic Emanation Analysis"). Bien que de mise en oeuvre moins aisée, ces techniques sont théoriquement plus fines que celles des attaques SPA et DPA car elles peuvent cibler leur attaque sur une partie précise du circuit (par exemple, le crypto-processeur) alors que l'analyse de courant est globale à tout le circuit.

Parmi les attaques exploitant des perturbations de l'exécution, on trouve par exemple les attaques de type DFA ("Differential Fault Attacks"), initialement développé contre des systèmes à clé publique de type RSA, puis étendu à la plupart des types de systèmes à clé privée.

Pour renforcer la sécurité d'un système, il faut masquer autant que possible la nature des traitements effectués et surveiller les possibles perturbations d'exécution. Les contre-mesures les plus courantes sont les suivantes: É Un délai aléatoire est introduit dans le traitement cryptographique. Ce délai peut être produit par l'exécution d'opérations inutiles.

É Des opérations superflues sont introduites de manière à rendre constant le temps d'exécution du traitement cryptographique, quelle que soit la valeur des données manipulées. En particulier, le temps ne dépend alors pas des branchements effectués dans l'implémentation du traitement. Les valeurs des données sur lesquelles portent les opérations superflues peuvent aussi être choisies pour rendre constante la consommation électrique.

É Plusieurs implémentations d'une même opération impliquée dans les traitements cryptographiques coexistent, ces implémentations pouvant différer par leur temps d'exécution et/ou leur consommation électrique. À l'exécution de l'opération, un choix aléatoire détermine l'implémentation particulière à utiliser.

2875657 6 É L'ordre d'exécution des opérations impliquées dans un traitement cryptographique est modifié avec une permutation aléatoire. (Pour cela, il peut falloir reformuler le traitement pour faire apparaître des fragments dont l'ordre d'exécution est indifférent.) É Des opérations redondantes sont ajoutées au traitement cryptographique pour calculer une empreinte ("hash"), par exemple une somme de contrôle ("checksum"), qui est représentative des opérations effectuées par le système. Si l'empreinte en fin de calcul diffère de la valeur attendue, cela signifie que l'exécution a été perturbée. Des mesures sécuritaires peuvent alors être prises, comme par exemple le blocage du système ou du programme, mesure courante dans le cas d'une carte à puce.

Avec ces contre-mesures, le temps d'exécution, la consommation électrique et les émissions électromagnétiques deviennent moins prévisibles (introduction d'un aléa) et/ou moins discernables (temps constant, indépendant des données d'entrée), et il est plus difficile de se synchroniser avec le programme pour observer les traitements cryptographiques et éventuellement les perturber.

Cependant, comme c'est fréquemment le cas en matière de sécurité, la protection résultante n'est généralement que partielle ou relative. Au lieu de viser une inaccessible immunité totale, l'objectif d'une sécurisation n'a en fait souvent comme ambition que de rendre la tâche d'un attaquant plus difficile, et notamment plus longue ou plus onéreuse.

Par exemple, certaines mesures physiques ont besoin d'une finesse qui nécessite des appareils permettant un échantillonnage élevé (de l'ordre d'une centaine de fois la fréquence du processeur, donc en pratique souvent plus de un gigahertz) et par conséquent également de très grandes capacités de stockage pour mémoriser ces mesures. La difficulté est d'autant plus élevée 2875657 7 quand ces mesures doivent être répétées de nombreuses fois, comme c'est le cas pour une attaque de type DPA, qui peut nécessiter de l'ordre de mille à dix mille mesures.

De même, le blocage sécuritaire du système ou du programme en cas de perturbation avérée de l'exécution impose à l'attaquant de disposer de plusieurs exemplaires similaires du système, pour qu'il parvienne à réaliser l'ensemble des mesures dont il a besoin pour conclure. Plus les perturbations sont détectées tôt, et le système subséquemment bloqué, plus l'attaquant nécessite d'exemplaires similaires du système.

L'invention propose un nouveau procédé pour rendre plus difficile l'observation des traitements cryptographiques. Le procédé s'applique à tout traitement cryptographique que l'on souhaite masquer. Il consiste à dissimuler au moins une partie du traitement, par exemple un calcul effectif avec de la similitude , c'est-à-dire à l'insérer parmi des leurres constitués par des traitements similaires superflus.

Plus précisément, l'invention propose un procédé de sécurisation d'un traitement cryptographique contre des attaques physiques, dans lequel tout ou partie dudit traitement cryptographique est réitéré plusieurs fois: une ou plusieurs fois sur les données correctes, les autres fois sur des données incorrectes en vue de leurrer un attaquant, le choix des itérations effectuées sur des données correctes ou incorrectes étant fait de manière aléatoire, et les itérations effectuées sur les données incorrectes étant ignorées dans le résultat final du traitement.

Dans le cas où le nombre d'itérations effectuées sur les données correctes est supérieur ou égal à deux et où les itérations effectuées sur les données correctes ont des empreintes et/ou des résultats différents, alors le programme pourra effectuer un traitement particulier.

2875657 8 Le traitement particulier du programme dans le cas où des empreintes et/ou des résultats d'itérations diffèrent pourra consister (1) à sécuriser certaines données et/ou (2) à interrompre, définitivement ou non, son exécution et/ou, quand c'est matériellement possible, (3) à éventuellement avertir l'utilisateur du dysfonctionnement par un signal sonore ou visuel.

Des raffinements pourront être apportés concernant le nombre de calculs itérés: É Si le traitement cryptographique comporte un motif algorithmique interne répété, le nombre total d'itérations NT pourra être égal au nombre de répétitions N dudit motif, ou bien à un multiple M dudit nombre de répétitions N, les itérations étant alors regroupées en N paquets de M/N répétitions du motif.

É Le nombre total d'itérations pourra aussi être déterminé en fonction: des données publiques et/ou invariantes spécifiques au traitement cryptographique, notamment les tailles des données de clé, et/ou des ressources nécessaires pour effectuer ledit traitement (lesdites ressources dépendant notamment du texte sur lequel opère ledit traitement, et/ou de la taille de ce texte), et/ou - des ressources disponibles pour effectuer ledit traitement, notamment le temps d'exécution et/ou l'espace mémoire, - d'un facteur aléatoire.

Des raffinements pourront également être apportés à la construction des données incorrectes: 2875657 9 É Les données incorrectes pourront ne concerner que les données de clé (et non les textes).

É Les données incorrectes pourront être déduites des données correctes par une transformation portant sur les premiers et/ou les derniers bits de clé manipulés dans l'implémentation du traitement cryptographique.

É Lorsque ledit traitement cryptographique impose des propriétés spécifiques pour les données de clé qu'il exploite, les données de clé incorrectes pourront être produites à partir de données particulières stockées dans le système, de manière à garantir lesdites propriétés spécifiques.

É Les données incorrectes pourront être déduites des données correctes par une transformation aléatoire conservant les mesures observables des donnés de clé (notamment le poids de Hamming).

Des raffinements particuliers pourront aussi être apportés à l'enchaînement des traitements itérés: É Si l'on effectue NC itérations sur des données correctes sur un total de NT itérations, les itérations sur des données incorrectes pourront être composées à partir de NT/NC ensembles de valeurs différentes, chacun de ces ensembles étant utilisé NC fois parmi les NT itérations, le choix des itérations portant sur tel ou tel ensemble de valeurs (correctes ou incorrectes) restant aléatoire.

Des raffinements pourront également être apportés dans la dissimulation de la construction des données incorrectes: 2875657 -10- É Les choix des itérations effectuées sur des données incorrectes et/ou les valeurs des données pour les itérations sur des données incorrectes pourront être calculés avant la toute première itération.

É Ces choix et ces valeurs pourront être stockés, avec ou sans répétitions, dans une ou plusieurs tables, et l'implémentation dudit traitement cryptographique pourra accéder à ces tables via une fonction de l'index de l'itération courante.

Le procédé selon l'invention pourra aussi être combiné avec d'autres formes de sécurisation: É Ce procédé pourra être combiné avec d'autres procédés de sécurisation de traitement cryptographique, au niveau de l'implémentation d'un traitement élémentaire (une itération) et/ou au niveau de l'implémentation de la répétition des traitements élémentaires. En particulier, des délais aléatoires pourront être insérés à l'intérieur de chaque itération et/ou entre chaque itération.

Ce procédé pourra en particulier être appliqué avec un nombre d'itérations sur des données correctes NC égal à 2 et un nombre total d'itérations NT défini de la manière suivante: É si le traitement cryptographique comprend un calcul cryptographique de type DES ou SEED (standard d'encryption de données de la Corée du Sud), alors NT = 16, É si le traitement cryptographique comprend un calcul cryptographique de type COMP128 (algorithme d'authentification GSM "Global System for Mobile Communications"), FEAL ("Fast Data Encipherment Algorithm") ou IDEA ("International Data Encryption Algorithm"), alors NT = 8, É si le traitement cryptographique comprend un calcul cryptographique de type AES-128, AES-192 ou AES-256 (AES = "Advanced Encryption Standard"), alors NT est respectivement égal à 10, 12 ou 14, É si le traitement cryptographique comprend un calcul cryptographique de type SAFER ("Secure And Fast Encryption Routine"), alors 6 NT 10, É si le traitement cryptographique comprend un calcul cryptographique de 10 type RC5 ("Rivest Cipher 5"), alors l 2 NT 16.

Ce procédé pourra être mis en oeuvre par des moyens divers: Un traitement cryptographique élémentaire pourra être mis en oeuvre par des instructions pour le processeur du système et/ou via un ou plusieurs cryptoprocesseurs et/ou via une ou plusieurs librairies cryptographiques fournies par un tiers.

L'enchaînement des itérations pourra être implémenté au niveau logiciel ou 20 mis en oeuvre au niveau matériel à l'aide d'un circuit qui effectue les itérations en séquence et/ou en parallèle, et de manière désynchronisée.

L'intérêt de l'invention tient dans la combinatoire créée à l'encontre de l'attaquant. En effet, le nombre de traitements similaires effectués (c'est-à-dire le nombre d'itérations) est tel que la combinatoire consistant à supposer comme corrects alternativement chacun des traitements élémentaires (une des itérations) est très grande. Après mise en oeuvre du procédé, ce n'est pas tant déterminer où est le traitement ? qui est difficile (à moins que d'autres mesures de sécurisation soient prises pour ça), mais quel est le traitement correct ? . Il devient alors très difficile pour l'attaquant de pratiquer des 2875657 - 12. observations utiles et de réaliser des synchronisations fines avec un traitement en cours d'exécution.

De plus, vérifier que chaque itération effectuée sur des données correctes produit une empreinte ou un résultat identique permet de mettre en évidence des perturbations physiques de l'exécution et de prendre, le cas échéant, des mesures sécuritaires, comme par exemple le blocage du système et/ou du programme.

En pratique, un système qui duplique des traitements cryptographiques n'est exploitable que s'il est suffisamment rapide. C'est le cas notamment de systèmes équipés de crypto-processeurs. Par exemple, le temps d'exécution d'un traitement DES sur un crypto-processeur de carte à puce peut être de l'ordre d'une trentaine de cycles, ce qui est des centaines voire des milliers de fois inférieur à un traitement explicite effectué par le processeur principal (non dédié à la cryptographie).

D'autre part, le nombre d'itérations effectuées sur des données correctes doit être petit, sinon l'effet de dissimulation est perdu. Inversement, multiplier le nombre d'itérations sur des données correctes augmente d'autant la possibilité de détecter des perturbations de l'exécution. Dans la mesure où il est difficile de reproduire avec précision une même perturbation de l'exécution (empêchant ainsi la détection de la perturbation), un nombre de deux itérations avec des données correctes est un bon compromis.

Par ailleurs, le nombre total de traitements élémentaires effectués (c'est-à-dire le nombre d'itérations) n'a pas nécessairement à être constant.

Le nombre total NT de traitements élémentaires peut notamment dépendre du type de traitement cryptographique. En particulier, si le traitement cryptographique comprend un sous-traitement interne particulier qui est répété un nombre donné de fois N, alors NT pourra être choisi égal à N. Cela permet, outre l'indétermination créée par la multiplication des traitements, de leurrer un attaquant en faisant apparaître un signal caractéristique du traitement cryptographique (la répétition N fois d'un même motif algorithmique) alors qu'en fait chaque motif répété N fois est lui-même un traitement cryptographique complet.

Le traitement d'un chiffrement ou déchiffrement DES, très caractéristique, en fournit un bon exemple: outre une permutation de données initiale et finale, le coeur de ce traitement est en effet constitué par 16 itérations d'une séquence quasiment identique d'opérations. L'observation d'un même signal physique se répétant 16 fois de suite est un indice qui trahit la présence du calcul DES. Si l'on sécurise le traitement DES en le répétant 16 fois comme décrit dans la présente invention, un attaquant qui observe les traitements peut se prendre au leurre de ces 16 itérations en pensant y voir la répétition du motif interne du traitement DES, alors qu'en fait il s'agit d'un traitement DES complet répété 16 fois.

Selon cette logique, le nombre d'itérations NT pourra par exemple être défini 20 ainsi pour les traitements cryptographiques suivants: É COMP128: 8 itérations, É DES: 16 itérations, É FEAL: 8 itérations, É IDEA: 8 itérations, É SEED: 16 itérations.

Toutefois, ce leurre supplémentaire n'est efficace que si l'attaquant peut confondre une itération du traitement avec d'autres opérations, c'est-à-dire à la condition qu'elles produisent un signal du même ordre: temps d'exécution, consommation électrique, etc. 2875657 - 14 - En pratique, un processeur cryptographique dédié peut être nécessaire à cela, notamment pour que chaque traitement cryptographique élémentaire soit suffisamment rapide. Le temps de traitement, suffisamment faible pour être comparable aux autres opérations élémentaires du processeur principal, justifie non seulement la viabilité d'un traitement répété (même une centaine de fois, si nécessaire) mais aussi la pertinence du leurre consistant à faire croire en un traitement programmé intégralement sur le processeur principal, mettant en oeuvre NT répétitions d'un soustraitement caractéristique, alors qu'il est en fait effectué NT fois sur le processeur cryptographique dédié.

Si le traitement cryptographique comporte un motif répété N fois, on peut plus généralement adopter pour NT un multiple M de N. En effet, un traitement réitéré M fois peut être organisé en N itérations d'un groupe de M/Ntraitements, laissant ainsi apparaître le leurre d'un motif répété N fois. Dans le cas d'un traitement DES, on pourra par exemple fixer le nombre d'itérations à 32 ou 48, que l'on organisera en 16 itérations d'un paquet de 2 ou 3 traitements.

Le nombre total d'itérations n'a pas à être constant pour un traitement cryptographique donné, il peut dépendre des données publiques et/ou des données invariantes spécifiques au traitement. Par exemple, dans le cas d'un traitement DES, on peut le faire dépendre de la taille de la clé ; dans le cas d'un chiffrement ou d'un déchiffrement RSA, il peut dépendre de la taille et/ou de la valeur du module et de l'exposant.

En particulier, si la spécification d'un traitement cryptographique comporte un motif répété un nombre de fois variable, par exemple relié à la taille de la clé, on pourra adopter un nombre d'itérations du traitement complet égal au nombre effectif de répétition du motif, ou bien le fixer à un des nombres de 2875657 -15- répétitions recommandés par les cryptanalystes. Le nombre d'itérations pourra par exemple être défini ainsi pour les traitements cryptographiques suivants: É AES-128: 10 itérations; AES-192: 12 itérations; ASE-256: 14 itérations.

É SAFER: de 6 à 10 itérations.

É RC5: de 12 à 16 itérations.

Le nombre d'itérations peut aussi être dynamique et dépendre des ressources nécessaires pour effectuer le traitement (qui peuvent dépendre du texte, et en particulier de sa longueur) et/ou des ressources disponibles pour effectuer le traitement (telles que le temps d'exécution et/ou l'espace mémoire) et/ou d'un facteur aléatoire. Cela permet de trouver des compromis entre niveau de sécurisation (difficulté d'observer et de perturber), qualité de service (temps de traitement) et coût de service (mémoire devant être disponible dans le système).

Pour que ce procédé soit efficace même lorsque l'attaquant peut faire des observations fines de l'exécution, il faut rendre difficile la possibilité de reconnaître si une itération est effectuée sur des données correctes ou sur des données incorrectes.

Les itérations sur les données correctes peuvent être reconnues notamment parce qu'elles sont répétées, soit dans un même groupe d'itérations pour un traitement sécurisé (cas de plusieurs itérations effectuées sur les données correctes), soit au travers de plusieurs traitements sécurisés effectués sur des données identiques. L'usage de procédés de sécurisation additionnels, comme par exemple l'introduction de délais aléatoires, permet de rendre plus difficile l'observation de cette répétition. Mais on peut aussi se protéger en raffinant le procédé de sécurisation qui fait l'objet de la présente invention. Pour cela, on peut faire en sorte de rendre semblables les données correctes et incorrectes, à 2875657 - 16 la fois par leurs valeurs (par exemple, quelques bits de différence) et dans les usages faits de ces valeurs.

Pour rendre semblables les valeurs, on peut construire des données incorrectes en ne modifiant que légèrement certaines des données correctes du traitement. Il faut toutefois que les données incorrectes ne soient pas trop proches des données correctes, sinon des conclusions concernant l'observation des données incorrectes seraient alors également pertinentes à propos des données correctes, et l'effet de dissimulation serait perdu car les leurres n'en seraient pas. Il y a donc un compromis à trouver pour rendre les données incorrectes suffisamment différentes, mais pas trop. Pour cela, on peut considérer quels types de données et quelles fractions de ces données sont les plus intéressants à modifier.

L'objet principal de la sécurisation est de dissimuler les données de clé lors d'un traitement cryptographique. Or, un traitement cryptographique peut dépendre non seulement de la valeur de clés mais aussi du texte sur lequel il opère. Cependant, dans la mesure où la trace d'exécution laissée par un traitement cryptographique dépend généralement plus de la valeur des données de clé que du texte, on aura avantage, pour construire des données incorrectes, à modifier les données de clé et non le texte.

Le choix des données de clé à modifier (en partie ou en totalité) pour fabriquer des données incorrectes peut dépendre du type de traitement cryptographique et de son implémentation. En pratique, les attaquesphysiques exploitent souvent les toutes premières ou les toutes dernières opérations effectuées par le traitement, qui portent sur des bits à des positions connues de la clé. Déterminer ces bits permet ensuite, de proche en proche, de déterminer la totalité de la clé. Pour masquer les données correctes, il importe donc de masquer en priorité les bits qui interviennent en premier ou en dernier dans l'implémentation du traitement.

2875657 -17- Par exemple, dans le cas du DES, on aura intérêt à modifier les derniers bits de la clé. En effet, les attaques du DES par DPA permettent de déterminer les bits d'une clé en commençant par le dernier puis, connaissant le dernier, en déterminant le précédent, et ainsi de suite jusqu'au premier. En plaçant des bits incorrects (au moins) en fin de clé, on rend difficile l'observation de la totalité des données de clé.

Dans le cas de clés constituées de valeurs ayant des propriétés particulières, comme par exemple dans le cas de RSA (qui repose sur des nombres premiers), il faut s'assurer que les modifications de données de clé préservent ces propriétés. Des données particulières, comme par exemple des données de clé totalement ou partiellement calculées, peuvent éventuellement être stockées dans le système pour permettre la génération facile de données de clé modifiées qui satisfont ces propriétés.

Dans la mesure où des fractions de données de clé peuvent être ignorées dans certains traitements cryptographiques, par exemple parce qu'elles sont redondantes, il faut aussi s'assurer que les valeurs incorrectes diffèrent suffisamment des valeurs correctes pour garantir que le traitement diffère opérationnellement. C'est le cas en particulier des clés DES, qui n'exploitent en fait que 56 bits sur 64.

Certaines observations physiques peuvent aussi fournir des renseignements sur la valeur des données manipulées lors d'un traitement, renseignements éventuellement relatifs, permettant juste de classer ou de comparer des mesures. C'est le cas par exemple du poids de Hamming (nombre de bits positionnés à 1), dont dépend la consommation électrique du circuit. Lors de la modification des données pour fabriquer des données incorrectes, on aura donc avantage à préserver les invariants qui sont observables. Par exemple, - 18 - contre la SPA, on pourra faire en sorte que le poids de Hamming des données de clé incorrectes soit identique à celui des données de clé correctes.

Le fait de rendre les valeurs semblables peut aussi avoir un impact sur le nombre d'exemplaires différents des données incorrectes utilisées dans l'ensemble des itérations. En effet, sous peine de rendre inefficace le procédé, il ne faut pas que l'on puisse identifier les itérations effectuées sur les données correctes par le seul fait que, comparées à celles qui portent sur des données incorrectes, elles sont en petit nombre et/ou identiques.

Ainsi, dans le cas où une seule des itérations porte sur les données correctes, il est bon que toutes les itérations sur des données incorrectes soient effectuées avec des ensembles de valeurs différentes. Il est alors difficile d'identifier l'itération correcte parmi les autres. Plus généralement, si l'on effectue NC itérations correctes sur un total de NT itérations, il est bon que les itérations sur des données incorrectes soient composées, autant que possible, à partir de NT/NC ensembles de valeurs différentes, chacun de ces ensembles étant utilisé NC fois parmi les NT itérations, le choix des itérations portant sur tel ou tel ensemble de valeurs (correctes ou incorrectes) restant totalement aléatoire.

Dans le cas où NT et NC sont imposés par d'autres considérations, la division entière NT/NC peut avoir un reste différent de zéro. On peut alors choisir NT /NC ou NT /NC + 1 ensembles de valeurs, chacun étant utilisé NC ou NC + 1 fois.

Par exemple, un traitement DES pourra avantageusement être sécurisé par 16 itérations composées à partir de 8 ensembles différents de valeurs (1 avec des valeurs correctes, 7 avec des valeurs incorrectes), chacun utilisé 2 fois au hasard des 16 itérations. Une observation fine pourrait éventuellement déceler que les 16 itérations peuvent se regrouper en 8 paires d'itérations sur des données identiques, mais sans pouvoir toutefois déterminer laquelle de ces paires correspond aux données correctes.

En pratique, il est bon de combiner ce procédé à d'autres contre-mesures afin de rendre différentes entre elles chacune des itérations, même lorsqu'elles portent sur des valeurs égales, par exemple en insérant des délais aléatoires dans chaque itération.

Pour rendre semblables les usages qui sont faits des données correctes et incorrectes, on peut précalculer certaines informations et valeurs dans une phase initiale (avant d'effectuer la première itération) et rendre uniforme ultérieurement (lors des itérations) la manière d'accéder à ces informations et valeurs précalculées, évitant ainsi qu'une observation puisse facilement les distinguer. On peut notamment effectuer les prétraitements suivants: É On peut préparer les choix d'itérations: lesquelles sont à faire sur des données correctes, lesquelles sont à faire sur des données incorrectes.

É On peut préparer les valeurs effectives des données à utiliser pour les différentes itérations: l'ensemble des valeurs correspondant aux données correctes, et les différents ensembles de valeurs correspondant à des données incorrectes.

É On peut faire en sorte que chaque itération accède de la même manière aux données précalculées. Pour cela, on peut par exemple préparer dans une ou plusieurs tables des choix et/ou valeurs à utiliser pour chacune des itérations (avec des répétitions éventuelles), et accéder à ces tables lors des itérations via le simple index de l'itération courante, ou une fonction de cet index.

Il devient ainsi très difficile de savoir si une itération opère sur des données correctes ou incorrectes.

2875657 - 20 - Il faut noter que le procédé de sécurisation au coeur de la présente invention peut facilement être combiné à d'autres procédés de sécurisation pour augmenter d'autant la tâche d'un attaquant.

Cette combinaison peut s'effectuer à deux niveaux: un autre procédé peut en effet être employé, d'une part, pour sécuriser un traitement élémentaire (c'est-à-dire une itération) et, d'autre part, pour sécuriser l'enchaînement des traitements répétés. Par exemple, un délai aléatoire peut être introduit, d'une part, parmi les opérations du traitement élémentaire, ce qui a un impact à chaque itération et, d'autre part, entre chaque itération du traitement.

Le procédé qui fait l'objet de la présente invention peut évidemment être mis en oeuvre quand on a toute liberté sur l'implémentation du traitement élémentaire. Mais il peut aussi être mis en oeuvre lorsque l'on n'a pas la maîtrise du traitement élémentaire sous-jacent, ce qui peut être le cas quand on utilise un crypto-processeur ou une librairie cryptographique fourni par un tiers. Le moyen de traitement est alors utilisé comme une boîte noire à chaque itération.

Ce procédé de sécurisation peut être mis en oeuvre au niveau logiciel, en programmant l'enchaînement des différentes itérations d'un traitement élémentaire. Il peut aussi être mis en oeuvre au niveau matériel, à l'aide d'un circuit qui enchaîne les différentes itérations.

Puisque les itérations sont indépendantes les unes des autres, elles peuvent aussi avoir lieu en parallèle. Ce parallélisme permet de rendre le procédé utilisable dans les cas où un traitement élémentaire ne peut pas être répété un trop grand nombre de fois sous peine de rendre le traitement sécurisé inexploitable car trop long en temps d'exécution.

2875657 -21- Dans le cas d'une mise en oeuvre parallèle, on pourra veiller à désynchroniser les différents processus ou processeurs effectuant les itérations, afin de brouiller les observations et rendre plus difficile la distinction des différents traitements.

Bien entendu, l'invention concerne le système d'exécution mettant en oeuvre un ou plusieurs traitements cryptographiques, dans lequel certains des traitements cryptographiques sont sécurisés contre des attaques physiques conformément au procédé précédemment décrit. Dans ce système d'exécution, les calculs cryptographiques élémentaires des traitements cryptographiques sécurisés pourront être mis en oeuvre par des instructions pour le processeur du système et/ou via un crypto-processeur et/ou via une librairie cryptographique fournie par un tiers. L'enchaînement des différentes itérations d'un traitement cryptographique élémentaire pourra être implémenté au niveau logiciel ou mis en oeuvre au niveau matériel, à l'aide d'un circuit qui effectue les itérations en séquence et/ou en parallèle, de manière désynchronisée.

Claims (18)

- 22 - Revendications

1. Procédé de sécurisation d'un traitement cryptographique contre des attaques physiques, caractérisé en ce que tout ou partie dudit traitement cryptographique est réitéré plusieurs fois: une ou plusieurs fois sur les données correctes, les autres fois sur des données incorrectes en vue de leurrer un attaquant, le choix des itérations effectuées sur des données correctes ou incorrectes étant fait de manière aléatoire, et les itérations effectuées sur les données incorrectes étant ignorées dans le résultat final du traitement.

2. Procédé selon la revendication 1, caractérisé en ce que, dans le cas où le nombre d'itérations effectuées sur les données correctes est supérieur ou égal à deux, si les itérations effectuées sur les données correctes ont des empreintes et/ou des résultats différents, alors le programme effectue un traitement particulier.

3. Procédé selon la revendication 2, caractérisé en ce que le traitement particulier du programme dans le cas où des empreintes et/ou des résultats d'itérations diffèrent consiste (1) à sécuriser certaines données et/ou (2) à interrompre, définitivement ou non, son exécution et/ou, quand c'est matériellement possible, (3) à avertir l'utilisateur du dysfonctionnement par un signal sonore ou visuel.

4. Procédé selon la revendication 1, caractérisé en ce que, si le traitement cryptographique comporte un motif algorithmique interne répété, le nombre total d'itérations NT est égal au nombre de répétitions N dudit motif, ou bien à un multiple M dudit nombre de répétitions N, les itérations étant alors regroupées en N paquets de M/ N répétitions du motif.

- 23 -

5. Procédé selon la revendication 1, caractérisé en ce que le nombre total d'itérations NT est déterminé en fonction: des données publiques et/ou invariantes spécifiques au traitement cryptographique, notamment les tailles des données de clé, et/ou des ressources nécessaires pour effectuer ledit traitement (lesdites ressources dépendant notamment du texte sur lequel opère ledit traitement, et/ou de la taille de ce texte), et/ou des ressources disponibles pour effectuer ledit traitement, notamment le temps d'exécution et/ou l'espace mémoire, d'un facteur aléatoire.

6. Procédé selon la revendication 1, caractérisé en ce que les données incorrectes ne concernent que les données de clé (et non les textes).

7. Procédé selon la revendication 1, caractérisé en ce que les données incorrectes sont déduites des données correctes par une transformation portant sur les premiers et/ou les derniers bits 20 de clé manipulés dans l'implémentation du traitement cryptographique.

8. Procédé selon la revendication 1, caractérisé en ce que les données incorrectes sont déduites des données correctes par une transformation aléatoire conservant les mesures observables 25 des donnés de clé (notamment le poids de Hamming).

9. Procédé selon la revendication 1, caractérisé en ce que, lorsque ledit traitement cryptographique impose des propriétés spécifiques pour les données de clé qu'il exploite, les données de clé incorrectes sont produites à partir de données particulières stockées dans le système, de manière à garantir lesdites propriétés spécifiques.

2875657 - 24 -

10. Procédé selon la revendication 1, caractérisé en ce que, si l'on effectue NC itérations sur des données correctes sur un total de NT itérations, les itérations sur des données incorrectes sont composées à partir de NT /NC ensembles de valeurs différentes, chacun de ces ensembles étant utilisé NC fois parmi les NT itérations, le choix des itérations portant sur tel ou tel ensemble de valeurs (correctes ou incorrectes) restant aléatoire.

11. Procédé selon la revendication 1, caractérisé en ce que les choix des itérations effectuées sur des données incorrectes et/ou les valeurs des données pour les itérations sur des données incorrectes sont calculés avant la toute première itération.

12. Procédé selon la revendication 11, caractérisé en ce que lesdits choix et/ou lesdites valeurs sont stockés, avec ou sans répétition, dans une ou plusieurs tables, et l'implémentation dudit traitement cryptographique accède à ces tables via une fonction de l'index de l'itération courante.

13. Procédé selon la revendication 1, caractérisé en ce qu'une combinaison avec d'autres procédés de sécurisation de traitement cryptographique s'effectue au niveau de l'implémentation d'un traitement élémentaire et/ou au niveau de l'implémentation de la répétition des traitements élémentaires.

14. Procédé selon la revendication 13, caractérisé en ce que des délais aléatoires sont insérés à l'intérieur de chaque itération et/ou entre chaque itération.

- 25 -

15. Procédé selon l'une des revendications 1 à 14,

caractérisé en ce que le nombre d'itérations sur des données correctes NC est égal à 2 et le nombre total d'itérations NT est défini de la manière suivante: - si le traitement cryptographique comprend un calcul cryptographique de type DES ou SEED, alors NT= 16, - si le traitement cryptographique comprend un calcul cryptographique de type COMP 128, FEAL ou IDEA, alors NT= 8, - si le traitement cryptographique comprend un calcul cryptographique de type AES-128, AES-192 ou AES-256, alors NT est respectivement égal à 10, 12 ou 14, - si le traitement cryptographique comprend un calcul cryptographique de type SAFER, alors 6 NT 5 10, si le traitement cryptographique comprend un calcul cryptographique de type RC5, alors 12 NT 5 16.

16. Système d'exécution mettant en oeuvre un ou plusieurs traitements cryptographiques, caractérisé en ce que certains desdits traitements cryptographiques sont sécurisés contre des attaques physiques conformément au procédé selon l'une 25 des revendications 1 à 15.

17. Système d'exécution selon la revendication 16, caractérisé en ce que les traitements cryptographiques élémentaires des traitements cryptographiques sécurisés sont mis en oeuvre par des instructions pour le processeur du système et/ou via un ou plusieurs crypto-processeurs et/ou via une ou plusieurs librairies cryptographiques fournies par un tiers.

- 26 -

18. Système d'exécution selon la revendication 16, caractérisé en ce que l'enchaînement des différentes itérations d'un traitement cryptographique élémentaire est implémenté au niveau logiciel ou mis en oeuvre au niveau matériel à l'aide d'un circuit qui effectue les itérations en séquence et/ou en parallèle, et de manière désynchronisée.