FR2919739A1 - Procede de traitement de donnees protege contre les attaques par generation de fautes et dispositif associe - Google Patents

Procede de traitement de donnees protege contre les attaques par generation de fautes et dispositif associe Download PDF

Info

Publication number
FR2919739A1
FR2919739A1 FR0756943A FR0756943A FR2919739A1 FR 2919739 A1 FR2919739 A1 FR 2919739A1 FR 0756943 A FR0756943 A FR 0756943A FR 0756943 A FR0756943 A FR 0756943A FR 2919739 A1 FR2919739 A1 FR 2919739A1
Authority
FR
France
Prior art keywords
data
result
compressed
secret
compression algorithm
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0756943A
Other languages
English (en)
Other versions
FR2919739B1 (fr
Inventor
Christophe Giraud
De La Crouee Hugues Thiebeauld
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Idemia France SAS
Original Assignee
Oberthur Card Systems SA France
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oberthur Card Systems SA France filed Critical Oberthur Card Systems SA France
Priority to FR0756943A priority Critical patent/FR2919739B1/fr
Priority to US12/184,546 priority patent/US8311212B2/en
Publication of FR2919739A1 publication Critical patent/FR2919739A1/fr
Application granted granted Critical
Publication of FR2919739B1 publication Critical patent/FR2919739B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F7/00Methods or arrangements for processing data by operating upon the order or content of the data handled
    • G06F7/60Methods or arrangements for performing computations using a digital non-denominational number representation, i.e. number representation without radix; Computing devices using combinations of denominational and non-denominational quantity representations, e.g. using difunction pulse trains, STEELE computers, phase computers
    • G06F7/72Methods or arrangements for performing computations using a digital non-denominational number representation, i.e. number representation without radix; Computing devices using combinations of denominational and non-denominational quantity representations, e.g. using difunction pulse trains, STEELE computers, phase computers using residue arithmetic
    • G06F7/723Modular exponentiation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2207/00Indexing scheme relating to methods or arrangements for processing data by operating upon the order or content of the data handled
    • G06F2207/72Indexing scheme relating to groups G06F7/72 - G06F7/729
    • G06F2207/7219Countermeasures against side channel or fault attacks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/30Compression, e.g. Merkle-Damgard construction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/34Encoding or coding, e.g. Huffman coding or error correction

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Pure & Applied Mathematics (AREA)
  • Mathematical Optimization (AREA)
  • Theoretical Computer Science (AREA)
  • Computational Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

Un procédé de traitement de données comprend les étapes suivantes :- détermination d'une première donnée de résultat à partir d'une première donnée d'entrée et d'une première donnée secrète ;- obtention d'une première donnée compressée à partir de la première donnée de résultat ou de la première donnée d'entrée au moyen d'un algorithme de compression ;- détermination d'une seconde donnée de résultat à partir d'une seconde donnée d'entrée et d'une seconde donnée secrète ;- obtention d'une seconde donnée compressée à partir de la seconde donnée de résultat au moyen de l'algorithme de compression ;- comparaison de la première donnée compressée et de la seconde donnée compressée.

Description

L'invention concerne un procédé de traitement de données, en particulier
de traitement cryptographique de données, protégé contre les attaques par génération de fautes, ainsi qu'un dispositif associé. Dans certains procédés de traitement de données, en particulier dans le cadre du traitement cryptographique de données, on utilise, au sein des algorithmes de traitement, des données qui doivent rester secrètes (tel que par exemple des clés cryptographiques) pour assurer le fonctionnement du système avec la sécurité requise. Ce type de procédé est dès lors la cible d'attaques de la part d'utilisateurs malveillants qui cherchent à déjouer la sécurité du système.
Parmi ces attaques, on connaît les attaques du type par génération de fautes qui consistent à perturber l'exécution normale du procédé de traitement de données (généralement mis en oeuvre par l'exécution d'un programme au sein d'un microprocesseur) afin d'obtenir en sortie du procédé des données différentes de celles normalement attendues mais révélatrices d'informations sur les données secrètes utilisées dans l'algorithme (au contraire de ce qui est prévu dans le déroulement sans faute du programme). Il a ainsi été prévu pour lutter contre ce type d'attaques d'ajouter des étapes complémentaires (tel que par exemple la réitération des calculs déjà effectués) afin de vérifier l'exécution sans faute du procédé de traitement de données, comme décrit par exemple dans les demandes de brevet WO 2005/088895 et WO 2006/103341. Dans ce type de solution, une donnée au moins doit être mémorisée pendant les opérations supplémentaires dont le résultat permet la vérification par comparaison avec la donnée mémorisée ; il s'agit en général de mémoriser la donnée obtenue par la première itération du calcul cryptographique pendant la durée de la seconde itération de ce même calcul.
Cette mémorisation peut toutefois s'avérer problématique, en particulier dans le cas des cartes à microcircuit ayant un espace mémoire réinscriptible à accès rapide (par exemple de type mémoire vive ou RAM, appelée aussi mémoire volatile) limité (à typiquement quelques milliers de bits seulement, tandis que les contraintes relatives à la sécurité incitent à utiliser des données, notamment des clés secrètes, de plus en plus longues, typiquement d'une longueur de 1024 ou 2048 bits). Dans ce contexte, l'invention propose un procédé de traitement de données, comprenant les étapes suivantes : - détermination d'une première donnée de résultat à partir d'une première donnée d'entrée et d'une première donnée secrète (par exemple au moyen d'un premier algorithme û en général cryptographique û utilisant la première donnée secrète) ; - obtention d'une première donnée compressée à partir de la 15 première donnée de résultat ou de la première donnée d'entrée au moyen d'un algorithme de compression ; - détermination d'une seconde donnée de résultat à partir d'une seconde donnée d'entrée et d'une seconde donnée secrète (par exemple au moyen d'un second algorithme û en général cryptographique û utilisant la 20 seconde donnée secrète) ; - obtention d'une seconde donnée compressée à partir de la seconde donnée de résultat au moyen de l'algorithme de compression ; - comparaison de la première donnée compressée et de la seconde donnée compressée. 25 On peut ainsi vérifier grâce à la comparaison l'exécution correcte des processus de détermination (en général de calcul) des données de résultat dans le but de détecter les attaques par génération de faute, et ce avec des moyens de mémorisation limités. Selon une première possibilité de mise en oeuvre, la seconde 30 donnée d'entrée est la première donnée d'entrée, la seconde donnée secrète est la première donnée secrète et la première donnée compressée est obtenue par compression de la première donnée de résultat. On se place ici dans le cadre d'une vérification par la réitération d'un processus utilisant en entrée la première donnée d'entrée et en tant que donnée secrète (par exemple en tant que clé cryptographique) la première donnée secrète. Selon une seconde possibilité de réalisation, la seconde donnée d'entrée est la première donnée de résultat et la première donnée compressée est obtenue par compression de la première donnée d'entrée. On vérifie dans ce cas l'exécution correcte du processus de détermination de la première donnée par application à la première donnée de résultat (seconde donnée d'entrée dans ce cas) d'un processus inverse et on cherche donc dans ce cas à comparer la première donnée d'entrée et la seconde donnée de résultat, qui devraient en fonctionnement normal être égales. Selon d'autres modes de réalisation, par exemple dans le cadre du schéma RSA mis en oeuvre par exemple au moyen du théorème des restes chinois comme décrit plus loin, la première donnée de résultat est par exemple obtenue au moins sur la base d'une donnée de vérification liée à une donnée représentant un résultat d'exponentiation modulaire et la première donnée compressée est quant à elle obtenue par compression de la première donnée de résultat. On peut alors prévoir dans ce contexte qu'au cours de l'exponentiation modulaire, une opération déterminée est sélectivement appliquée à la donnée de vérification ou à la donnée représentant le résultat selon la valeur d'un bit de la première donnée secrète, ce qui permet d'obtenir une donnée de vérification liée au résultat de l'exponentiation modulaire de manière particulièrement pratique.
Toujours dans le contexte du schéma RSA, la seconde donnée de résultat peut quant à elle être obtenue au moyen d'un calcul comprenant au moins une recombinaison de résultats modulaires partiels. En pratique, la première donnée secrète et la seconde donnée secrète sont en général chacune au moins issues d'au moins une clé cryptographique. Il peut s'agir de la clé cryptographique elle-même ou par exemple d'un reste modulaire de cette clé.
L'algorithme de compression met par exemple en oeuvre une fonction non-inversible, ce qui est intéressant en termes de taux de compression et de rapidité du calcul. L'algorithme de compression peut être en pratique de type CRC. Cet algorithme comprend par exemple la sommation de mots d'un nombre prédéterminé de bits modulo le nombre deux élevé à la puissance de ce nombre déterminé. En variante, l'algorithme de compression peut comprendre l'application d'une opération de ou exclusif à des mots d'un nombre prédéterminé de bits. Pour la mise en oeuvre pratique du procédé, on prévoit en général une étape de mémorisation (par exemple en mémoire vive) de la première donnée compressée antérieure à l'étape d'obtention de la seconde donnée de résultat et/ou une étape de mémorisation (par exemple en mémoire vive) de la seconde donnée compressée antérieure à l'étape de comparaison. En variante, la première donnée compressée (ainsi qu'éventuellement la seconde donnée compressée) peut être mémorisée dans un registre interne d'un microprocesseur mettant en oeuvre le procédé. L'invention propose également un dispositif de traitement de données, caractérisé en ce qu'il comprend des moyens de détermination d'une première donnée de résultat à partir d'une première donnée d'entrée et d'une première donnée secrète, des moyens d'obtention d'une première donnée compressée à partir de la première donnée de résultat ou de la première donnée d'entrée au moyen d'un algorithme de compression, des moyens de détermination d'une seconde donnée de résultat à partir d'une seconde donnée d'entrée et d'une seconde donnée secrète, des moyens d'obtention d'une seconde donnée compressée à partir de la seconde donnée de résultat au moyen de l'algorithme de compression et des moyens de comparaison de la première donnée compressée et de la seconde donnée compressée. Le dispositif peut être une entité électronique de poche, tel qu'une carte à microcircuit, par exemple conforme à la norme ISO7816 ; en variante, il peut s'agir d'un autre type d'entité électronique, comme par exemple un ordinateur (tel un ordinateur personnel) ou une clé USB.
Un tel dispositif peut éventuellement comprendre en outre certaines des caractéristiques optionnelles présentées ci-dessus en termes de procédé. Les procédés évoqués ci-dessus sont typiquement mis en oeuvre au moyen de l'exécution des instructions d'un programme d'ordinateur par un microprocesseur. L'exécution des instructions permet ainsi le traitement par le microprocesseur des données mémorisées dans le dispositif, par exemple au sein d'une mémoire vive de celui-ci. D'autres modes de réalisation pourront toutefois être envisagés, comme par exemple l'utilisation d'un circuit à application spécifique apte à mettre en oeuvre les étapes des procédés envisagés ci-dessus. Dans ces différents contextes, les données d'entrée peuvent être des données reçues par le dispositif de traitement d'un dispositif extérieur, par exemple au moyen d'une interface de communication du dispositif de traitement. Il peut toutefois s'agir également de données mémorisées dans le dispositif (par exemple en mémoire non-volatile) ou de données intermédiaires obtenues à partir des données de type décrit précédemment. De même, au moins une des données de résultat peut être une donnée à émettre en sortie du dispositif, par exemple à destination du dispositif extérieur au moyen de l'interface de communication. Les données de résultat peuvent toutefois n'être que des données intermédiaires, éventuellement utilisées par le dispositif dans des processus (par exemple de calcul) ultérieurs. Chacun des algorithmes cryptographiques mentionnés ci-dessus permet par exemple de réaliser, au moins en partie, une opération de cryptage, de décryptage, de signature, d'échange de clé cryptographique ou de génération de clé cryptographique. Dans ce type d'application, les données d'entrée (en particulier la première donnée d'entrée) est par exemple un message (ou une partie d'un message) reçu du dispositif extérieur et qui est crypté (ou décrypté) au sein dispositif de traitement au moyen du ou des algorithmes cryptographiques précités, puis ré-émis en sortie du dispositif de traitement à travers l'interface de communication.
Selon une autre application, le ou les algorithmes permettent la signature du message et le dispositif de traitement émet donc en sortie la signature calculée à partir de la donnée d'entrée. En variante, le résultat obtenu au moyen notamment de l'un au moins des algorithmes cryptographiques n'est pas émis en sortie par le dispositif mais peut conditionner l'émission ultérieure par le dispositif d'autres données. D'autres caractéristiques et avantages de l'invention apparaîtront mieux à la lumière de la description qui suit, faite en référence aux dessins annexés, dans lesquels : - la figure 1 représente un dispositif de traitement de données mettant en oeuvre la présente invention ; - la figure 2 représente une carte à microcircuit comme exemple de dispositif de traitement selon la figure 1 ; - la figure 3 représente un premier exemple de procédé de traitement de données conforme aux enseignements de l'invention ; - la figure 4 représente un second mode de réalisation du procédé de traitement de données proposé par l'invention ; - la figure 5 représente un troisième mode de réalisation d'un tel 20 procédé ; - la figure 6 représente enfin un quatrième mode de mise en oeuvre de l'invention ; et - la figure 7 représente un exemple de réalisation d'un traitement utilisé dans le mode de réalisation de la figure 5. 25 La figure 1 représente schématiquement un dispositif de traitement de données 40 dans lequel la présente invention est mise en oeuvre. Ce dispositif 40 comprend un microprocesseur 10, auquel est associée d'une part une mémoire vive 60, par exemple au moyen d'un bus 70, et d'autre part une mémoire non volatile 20 (par exemple du type EEPROM), par exemple à 30 travers un bus 50.
Le dispositif de traitement de données 40, et précisément le microprocesseur 10 qu'il incorpore, peuvent échanger des données avec des dispositifs extérieurs au moyen d'une interface de communication 30. On a schématiquement représenté sur la figure 1 la transmission d'une donnée d'entrée, désignée MSG ou m dans la suite, reçue d'un dispositif extérieur (non représenté) et transmise de l'interface de communication 30 au microprocesseur 10. De manière similaire, on a représenté la transmission d'une donnée de sortie, désignée RI ou S dans la suite, du microprocesseur 10 vers l'interface de communication 30 à destination d'un dispositif extérieur. Bien que, pour l'illustration, les données d'entrée et les données de sortie figurent sur deux flèches différentes, les moyens physiques qui permettent la communication entre le microprocesseur 10 et l'interface 30 pourront être réalisés par des moyens uniques, par exemple un port de communication série ou un bus.
Le microprocesseur 10 est apte à exécuter un logiciel (ou programme d'ordinateur) qui permet au dispositif de traitement de données 40 d'exécuter un procédé conforme à l'invention dont des exemples sont donnés dans la suite. Le logiciel est composé d'une série d'instructions de commande du microprocesseur 10 qui sont par exemple stockées dans la mémoire 20.
En variante, l'ensemble microprocesseur 10 - mémoire non-volatile 20 -mémoire vive 60 peut être remplacé par un circuit à application spécifique qui comprend alors des moyens de mise en oeuvre des différentes étapes du procédé de traitement de données. La figure 2 représente une carte à microcircuit qui constitue un exemple de dispositif de traitement de données conforme à l'invention tel que représenté à la figure 1. L'interface de communication 30 est dans ce cas réalisée au moyen des contacts de la carte à microcircuit. La carte à microcircuit incorpore un microprocesseur 10, une mémoire vive 60 et une mémoire non volatile 20 comme cela est représenté sur la figure 1.
Cette carte à microcircuit est par exemple conforme à la norme ISO 7816 et munie d'un microcontrôleur sécurisé qui regroupe le microprocesseur (ou CPU) 20 et la mémoire vive 60.
En variante, le dispositif de traitement de données peut être une clef USB, un document ou un support d'informations papier comportant dans l'une de ses feuilles un microcircuit associé à des moyens de communication sans contact. Il s'agit de manière préférée d'une entité électronique portable ou de poche. La figure 3 représente les étapes principales d'une mise en oeuvre de l'invention dans le cadre de l'algorithme cryptographique DES. Ce procédé débute à l'étape E102 par la réception par le microprocesseur 10 (par exemple comme décrit précédemment à travers l'interface 30) du message MSG auquel on souhaite appliquer l'algorithme DES. Ce message est formé d'un certain nombre de bits (ici par exemple 64 bits) et est mémorisé à réception dans la mémoire vive 60. Le microprocesseur 10 procède alors à l'étape E104 à une première application de l'algorithme DES au message MSG au moyen d'une clé 15 cryptographique K mémorisée dans la mémoire non volatile 20. La clé cryptographique K est donc par nature une donnée secrète (ici également de longueur 64 bits) que des attaquants chercheront à connaître notamment en tentant de provoquer des défauts de fonctionnement du dispositif de traitement de données 40 afin de perturber les calculs mis en oeuvre au sein 20 de l'algorithme DES. L'étape E104 implique donc la lecture de la clé cryptographique K dans la mémoire non volatile 20 et sa mémorisation dans la mémoire vive 60 où sont mémorisées les données utiles à la réalisation par le microprocesseur 10 des calculs nécessaires à la mise en oeuvre de l'algorithme DES. 25 Le résultat RI de l'application de l'algorithme cryptographique DES au message MSG en utilisant la clé cryptographique K est également mémorisé en mémoire vive 60 en sortie de l'étape E104. On peut remarquer à ce sujet qu'afin de mettre en oeuvre une nouvelle itération de l'algorithme DES dans le but de vérifier l'exécution correcte 30 de cet algorithme (voir étape E110 ci-dessous), le message MSG reçu en entrée est toujours mémorisé en mémoire vive 60 à l'issue de l'étape El 04.
On procède alors à l'étape E106 à laquelle on applique un algorithme de compression au résultat RI de l'étape E104 afin d'obtenir une première donnée compressée CI. On utilise par exemple pour se faire un algorithme de type CRC (ainsi dénommé de l'anglais "Cyclic Redundancy Check" qui signifie contrôle de redondance cyclique), généralement utilisé pour obtenir une somme de contrôle (ou "checksum" selon l'appellation anglo-saxonne) et qui permet d'obtenir une donnée CI de taille réduite (par exemple 16 bits) par rapport à la donnée à compresser (ici le résultat RI) d'une longueur de 64 bits dans l'exemple décrit ici.
Un algorithme de compression de type CRC qui peut être utilisé dans ce cadre est par exemple une simple somme modulo 232 des différents mots de 32 bits qui composent la valeur à compresser. En variante, on peut utiliser une opération de ou exclusif (ou XOR) entre les mots de 32 bits qui composent la valeur à compresser. On remarque que ces différents algorithmes de compression sont non-inversibles, c'est-à-dire qu'il n'est pas possible de retrouver la valeur initiale à partir de la valeur compressée. Ce type d'algorithme est particulièrement efficace en termes de taux de compression et de vitesse d'exécution. D'autres algorithmes de compression peuvent naturellement être également utilisés, telle que par exemple une fonction à sens unique (c'est-à-dire dont l'inverse est difficilement calculable ou non calculable en pratique) par exemple de type SHA-1 ou MD5, ou une fonction inversible (par exemple l'algorithme de compression de Huffman) dont l'efficacité est toutefois limitée, notamment appliqué à des valeurs cryptographiques ou encryptées dont l'organisation des bits est par définition aléatoire. On procède ensuite à la mémorisation en mémoire vive 60 de la donnée compressée CI (étape E108) avec libération de l'espace mémoire précédemment utilisé pour mémoriser le résultat RI de l'étape E104. L'espace mémoire ainsi libéré peut dès lors être utilisé pour une nouvelle itération de l'application de l'algorithme DES au message MSG avec la clé cryptographique K à l'étape E110. Cette nouvelle application de l'algorithme DES a pour résultat une valeur R2 (égale au résultat RI de l'étape E104 si ces deux étapes se sont déroulées sans faute). Dans le cas où on utilise un crypto-processeur pour la mise en oeuvre de l'algorithme DES, la mémoire vive 60 n'est pas utilisée pour les calculs impliqués par cet algorithme, mais la libération d'espace mémoire mentionnée ci-dessus permet au moins en partie la mémorisation du résultat de l'algorithme sans nécessiter un emplacement mémoire supplémentaire correspondant. On procède alors à l'étape E112 à la compression du résultat R2 de l'étape E110 au moyen du même algorithme de compression que celui utilisé à l'étape E106, afin d'obtenir une seconde donnée compressée C2, qui est alors comparée à la première donnée compressée CI à l'étape E114. En fonction de l'architecture du dispositif de traitement de données, cette comparaison pourra ou non nécessiter la mémorisation de la seconde donnée compressée C2 en mémoire vive 60 : dans le premier cas, lorsqu'il est nécessaire de stocker la donnée compressée en mémoire vive 60, cette mémorisation se fera en sortie de l'étape E112 tandis que l'étape de comparaison E114 nécessitera la lecture des premières et secondes données compressées CI, C2 dans cette même mémoire vive (ou successivement de parties d'entre elles) ; dans le second cas dans lequel une mémorisation de la seconde donnée compressée dans la mémoire vive 60 n'est pas nécessaire, le microprocesseur 10 conservera par exemple la seconde donnée compressée C2 dans un registre interne à l'issue de l'étape E112 et lira la première donnée compressée CI de la mémoire vive 60 dans un autre registre interne afin d'effectuer la comparaison de ces deux données. Lorsque l'exécution des deux algorithmes DES se sont effectuées sans faute, leurs résultats respectifs RI, R2 sont identiques de sorte qu'après application du même algorithme de compression, la première donnée compressée CI est égale à la seconde donnée compressée C2. C'est pourquoi on considère, lorsque le résultat de la comparaison des deux données compressées à l'étape E114 est positif, qu'aucune faute n'a été détectée et on peut dès lors, en l'absence d'attaque, émettre en sortie le résultat R2 mémorisé en mémoire vive 60. L'émission de cette donnée de sortie R2 se fait par exemple à travers l'interface de communication 30. Si au contraire l'égalité entre la première donnée compressée CI et la seconde donnée compressée C2 n'est pas vérifiée, ceci signifie nécessairement (vu l'identité des algorithmes de compression appliquée aux étapes E106 et E112) que les deux applications de l'algorithme DES ont donné des résultats différents et on suppose dès lors qu'une faute a été détectée et que le résultat de l'algorithme DES ne doit pas être émis en sortie (d'une part parce qu'il est probablement erroné et d'autre part parce qu'il risquerait de renseigner un attaquant éventuel sur la clé secrète K) ; on procède par conséquent à l'étape E116 à laquelle un message d'erreur est par exemple renvoyé à travers l'interface 30. La figure 4 représente les étapes principales d'une mise en oeuvre de l'invention dans le cadre de l'algorithme RSA.
On se place ici dans le cas où une clé privée (donc secrète) d et la clé publique associée e selon le schéma RSA sont mémorisées dans la mémoire non volatile 20. L'application de l'algorithme RSA au message MSG avec la clé privée d permet par exemple la signature électronique de ce message.
Le procédé débute à l'étape E202 par la réception d'un message MSG auquel on souhaite faire subir l'algorithme RSA. Le message MSG reçu par le microprocesseur 10 à travers l'interface de communication 30 est mémorisé en mémoire vive 60 afin de permettre son traitement.
On applique alors à l'étape E204 un algorithme de compression (par exemple du type décrit eu égard au premier mode de réalisation présenté précédemment) et on obtient ainsi une première donnée compressée CI que l'on mémorise en mémoire vive 60. La mémorisation de cette première donnée compressée CI permet de garder trace, pour un coût de mémoire réduit, du contenu du message MSG reçu (même s'il n'est naturellement pas possible avec les algorithmes de compression proposés ci-dessus de retrouver le message MSG à partir de la donnée compressée CI). On remarquera qu'à l'issue de l'étape E204, le message MSG reçu en entrée est toujours mémorisé dans la mémoire vive 60.
On peut ainsi procéder à l'étape E206 à l'application de l'algorithme RSA au message MSG en utilisant une clé secrète d lue dans la mémoire non-volatile 20, ce qui permet d'obtenir le résultat RI de l'application de l'algorithme RSA au message reçu. Ce résultat RI est mémorisé en mémoire vive 60. On peut alors libérer l'espace mémoire utilisé préalablement pour la mémorisation du message reçu MSG. On peut ainsi procéder à l'étape E208, en utilisant notamment cet espace mémoire libéré, à l'application de l'algorithme RSA au résultat RI de l'étape E206 en utilisant la clé publique e (lue en mémoire non-volatile 20), ce qui permet d'obtenir le résultat R2. Si les deux applications successives de l'algorithme RSA aux étapes E206 et E208 se sont déroulées sans faute, le résultat R2 doit être (du fait des propriétés de l'algorithme RSA) identique au message MSG reçu initialement. On procède de ce fait à l'étape E210 à la compression du résultat R2 au moyen de l'algorithme de compression de l'étape E204 afin d'obtenir une seconde donnée compressée C2 (qui devrait donc en fonctionnement normal être égale à la première donnée compressée CI) et on procède à l'étape E212 à la comparaison de la première donnée compressée CI et de la seconde donnée compressée C2.
On remarque que dans certaines architectures, le résultat R2 de la seconde application de l'algorithme RSA à l'étape E208 pourrait être mémorisé dans des registres internes du microprocesseur 10 et la seconde donnée compressée C2 obtenue par calcul à l'intérieur de ce même registre (avec éventuellement écrasement de la valeur R2), auquel cas la comparaison de l'étape E212 pourrait ne nécessiter la mémorisation en mémoire vive 60 ni du résultat R2 ni de la seconde donnée compressée C2.
En variante, on peut mémoriser le résultat R2 et la seconde donnée compressée C2 dans la mémoire vive 60 afin d'effectuer les calculs nécessaires et la comparaison de l'étape E212. Selon une variante intéressante, on peut effectuer des calculs complémentaires (par exemple d'autres calculs cryptographiques), ou des opérations de lecture ou d'écriture en mémoire volatile ou non-volatile, entre les étapes E210 et E212 afin de limiter les risques d'attaque par faute sur l'étape E212 visant à contourner la contremesure permise par cette étape. L'intérêt de la compression est renforcé dans ce cas où les calculs complémentaires sont consommateurs de mémoire vive. Si le résultat de la comparaison de l'étape E212 est positif, on considère que le résultat R2 de l'étape E208 est identique au message MSG reçu en entrée et que les algorithmes RSA (en particulier le premier algorithme RSA de l'étape E206) se sont déroulés sans faute. Le résultat RI de l'application de l'algorithme RSA au message MSG avec la clé secrète d peut par conséquent dans ce cas être émis à l'extérieur à l'étape E216, par exemple à travers l'interface de communication 30. Si au contraire le résultat de la comparaison de l'étape E112 est négatif, une erreur s'est nécessairement déroulée au cours de l'un des algorithmes RSA et, par crainte d'une attaque par faute, on n'émet alors pas en sortie le résultat de l'algorithme RSA, mais par exemple au contraire un message d'erreur à destination du dispositif extérieur (étape E214). On peut en variante (éventuellement en combinaison avec l'émission du message d'erreur) provoquer dans ce cas une inhibition au niveau du microprocesseur 10 afin d'empêcher tout fonctionnement ultérieur du dispositif. La figure 5 représente un troisième mode de réalisation de l'invention, toujours dans le cadre de l'algorithme RSA, mais précisément cette fois dans une mise en oeuvre de cet algorithme utilisant le théorème des restes chinois (CRT de l'anglais "Chinese Remainder Theorem").
Pour la mise en oeuvre de cette solution, le dispositif de traitement mémorise en mémoire non-volatile 20 les modules p et q de la clé privée (d, p, q) du schéma de chiffrement RSA ainsi que les restes dp et dq de la clé secrète d respectivement modulo p et q. On rappelle qu'on a dans ce contexte p.q = n, où n est le module public du schéma de chiffrement, dp= d mod (p û 1) et dq = d mod (q û 1).
La mémoire non-volatile 20 mémorise également l'inverse modulaire a de p modulo q qui vérifie donc p.a = 1 mod q. (L'inverse modulaire a est parfois dénoté Apq.) Le procédé de la figure 5 vise à appliquer l'algorithme RSA au moyen de la clé secrète d à un message m reçu en entrée à l'étape E300, c'est- à-dire à calculer la valeur md mod n. Lorsqu'on utilise le théorème des restes chinois, on procède pour ce faire à des calculs d'exponentiations modulaires partielles, modulo p d'une part(étape E302) et modulo q d'autre part (étape E304). Pour le calcul des exposants modulaires partiels aux étapes E302 et E304, on utilise l'algorithme décrit en figure 7 (qui reprend les enseignements de l'algorithme décrit en référence à la figure 2 dans la demande de brevet WO 2006/103341). Cet algorithme permet non seulement de fournir le résultat de l'exponentiation modulaire (ici partielle) soit mdP mod p (a, dans l'algorithme de la figure 7) mais également une donnée permettant la vérification de la bonne exécution de l'algorithme, et qui vaut ici mdP1 mod p (dénoté ao dans l'algorithme de la figure 7). Après exécution de cet algorithme d'exponentiation modulaire partielle, on mémorise (toujours à l'étape E302 sur la figure 5) le résultat de l'exponentiation modulaire mdP mod p en mémoire vive 60 en tant que variable Sp. On procède en outre à la multiplication par m de la donnée de vérification mdP1 mod p , puis à l'application d'un algorithme de type CRC au résultat de cette multiplication afin d'obtenir une donnée compressée CRC1 que 30 l'on mémorise en mémoire vive 60.
On remarque qu'à ce stade, il n'est pas nécessaire de mémoriser plus longtemps en mémoire vive 60 la donnée de vérification mdP-1 modp utilisée précédemment. On procède alors à l'étape E304 à l'exponentiation modulaire partielle, grâce à l'algorithme déjà mentionné décrit en référence à la figure 7, en utilisant cette fois les valeurs m, dq et q, ce qui permet d'obtenir les valeurs dg modq (a,) et mdg l m modq (ao) qui sont mémorisées en mémoire vive 60 respectivement en tant que Sq et S'q . On débute ensuite la recombinaison des résultats modulaires partiels 10 Sp et Sq en mémorisant dans la mémoire vive 60 sous la dénomination TEMP le résultat du calcul suivant : {[(Sq -Sp)modq]*amodq}* p (étape E306). On procède alors à une étape E308 à laquelle on calcule tout d'abord la valeur [m * S'q -(TEMP modq) modq] , à laquelle on applique ensuite l'algorithme de type CRC précédemment utilisé à l'étape E302, puis on vérifie 15 enfin si le résultat ainsi obtenu est égal à la valeur CRC1 mémorisée en mémoire vive 60 à l'étape E302 (ce qui implique naturellement la lecture de cette valeur dans la mémoire vive). En effet, on a, d'après la définition même de a comme l'inverse modulaire de p modulo q : 20 f(Sq - Sp)modq] *amodq* pmodq = (Sq - Sp)modq . Par conséquent, en retranchant les deux termes de cette égalité à Sq, on obtient : Sq -j[(Sq -Sp)modq]*amodq}*pmodq=Sp modq . OrSp modq=Sp car, selon l'hypothèse classique utilisée dans la définition de l'algorithme CRT, q > p (et p > Sp). 25 Par conséquent, on a normalement : (Sqûf(SqûSp)modq]*amodq}*pmodq)modq=Sp. On utilise ici cette égalité pour vérifier le fonctionnement sans faute du dispositif en y remplaçant Sq par m.S'q et Sp par m.mdP-1 modp (et en comparant en outre les valeurs après compression, étant rappelé que CRC1 est en effet obtenu par compression de m.md 1 mod p ). Ainsi, lors d'une mise en oeuvre sans faute des différents algorithmes mentionnés ci-dessus, la vérification de l'égalité à l'étape E308 doit être positive et on procède donc dans ce cas à l'étape E312 à laquelle, si la valeur TEMP est différente de la valeur S, on ajoute Sp à la valeur TEMP, puis on réduit l'ensemble modulo p.q, ce qui permet d'obtenir la valeur souhaitée S (S = md mod p.q), qui peut donc être émise en sortie à destination du dispositif extérieur, par exemple à travers l'interface 30. La vérification de la condition TEMP ~ S permet de se protéger contre des attaques par faute ayant pour but d'empêcher l'opération "+ Sp mod (p*q)". Si au contraire la vérification de l'étape E308 est négative, on procède à l'étape E310 indiquant qu'une erreur a été détectée et qu'aucune valeur ne peut donc être retournée par le dispositif de traitement de données, et ce afin de parer notamment les attaques par génération de fautes. La figure 6 représente un quatrième mode de réalisation de l'invention, qui peut être vu comme une variante de la figure 5. Au début de ce procédé (étape E400), on reçoit donc comme pour le procédé de la figure 5 la valeur du message m auquel on souhaite appliquer l'algorithme RSA et on détient par ailleurs en mémoire les modules p et q de la clé privée, ainsi que les restes dp et dq de la clé secrète d respectivement modulo p et q. On procède alors à l'étape E402 à une première exponentiation modulaire partielle au moyen de l'algorithme de la figure 7 en utilisant les valeurs m, dp, p et on mémorise, comme dans le mode de réalisation précédent, le résultat de l'exponentiation modulaire mdP dans un emplacement mémoire Sp et, dans un emplacement mémoire CRC1, le résultat de l'application d'un algorithme de compression au produit du message m par la donnée de vérification ao (cette dernière donnée valant mdP 1 mod p ).
On procède de même concernant l'exponentiation modulaire partielle relativement à q à l'étape E404 : on mémorise en tant que Sq le résultat a1 de l'algorithme de la figure 7 mis en oeuvre avec les valeurs m, dq et q. On mémorise par ailleurs en tant que CRC2 le résultat de l'application de l'algorithme de compression utilisé à l'étape E402, cette fois appliqué au produit du message m par la donnée de vérification ao obtenue lors de la nouvelle exécution de l'algorithme de la figure 7 (et qui vaut normalement dans ce cas d4 1 m modq ). On effectue alors à l'étape E406 la recombinaison des résultats modulaires partiels Sp et Sq au moyen de la formule : {[(SgûSp)modq]*amodq}*p+Spmod(p*q), dont le résultat est mémorisé en tant que valeur de sortie S. Avant toutefois d'émettre cette donnée S en sortie, on vérifie les deux égalités suivantes : CRC1 = CRC(Smod p) et CRC2 = CRC(Smodq) . Si aucune erreur de fonctionnement ne s'est produite, les deux égalités ci-dessus sont vérifiées et on peut alors émettre en sortie la valeur S à l'étape E412. Si au contraire une erreur de fonctionnement (qui pourrait être causée par une attaque par génération de faute) s'est produite soit au cours de l'une des exécutions de l'algorithme de la figure 7 visant à effectuer ces exponentiations modulaires, soit au cours de la recombinaison de l'étape E406, l'une au moins des égalités de l'étape E408 n'est pas vérifiée et c'est pourquoi on procède, si l'une ou l'autre des égalités de l'étape E408 n'est pas vérifiée, à une étape E410 à laquelle une erreur est détectée et le fonctionnement du dispositif de traitement est par exemple inhibé (ce qui permet d'éviter toute émission de la donnée de sortie S vers l'extérieur du dispositif).
L'algorithme utilisé pour les exponentiations modulaires comme mentionné ci-dessus va à présent être décrit en référence à la figure 7. Celui-ci débute à l'étape E500 par la réception par le sous-programme décrit ici des valeurs m , d et n . En considération de ces valeurs, on procède à une étape d'initialisation E502, au cours de laquelle on initialise une variable ao à m, une variable al à m2 mod n et une variable i à la valeur k - 1 qui représente le nombre de bits de la clé secrète d (k est une donnée fixe du système cryptographique utilisé). On décrémente également d d'une unité du fait du mode de réalisation utilisé ici pour le calcul d'exponentiation modulaire. On entre alors dans une boucle permettant à proprement parler le calcul de l'exponentiation modulaire, à commencer par une étape E504 de test de la valeur du bit di , en écrivant d sous sa forme binaire (dk, ..., di). Chaque dl constitue donc un bit du nombre correspondant avec notamment d, le bit de poids le plus faible et dk le bit de poids le plus fort. On a donc d=E Si le bit de rang i dans la clé d vaut 1, on passe à l'étape E506 à laquelle on procède tout d'abord à la multiplication de la variable ao par la variable al (c'est-à-dire au calcul de ao * al mod n ), dont on mémorise le résultat dans la variable ao (avec écrasement). On procède également au sein de l'étape E506 au calcul de la valeur al mod n et la mise à jour de la variable al par le résultat de ce calcul. S'il est déterminé à l'étape E504 que le bit de rang i de la clé secrète d vaut zéro (c'est-à-dire si di = 0), on procède à l'étape E508 au cours de laquelle on calcule le produit de la variable al par la variable ao (c'est-à-dire que l'on calcule al * ao mod n ), on mémorise la valeur obtenue dans al avec écrasement, on calcule le carré modulaire de la variable ao (c'est-à-dire la valeur aô modn) et on stocke le résultat de cette dernière opération dans la variable ao avec écrasement. On peut remarquer que les étapes E506 et E508, mises en oeuvre respectivement lorsque le bit de la clé secrète d concerné lors de l'itération i 25 vaut 1 ou 0 sont totalement symétriques par rapport aux variables ao et al, l'une de ces variables étant dans chaque cas mise à jour par multiplication par l'autre variable.
Quel que soit le résultat du test de l'étape E504, on procède, après l'étape E506 ou l'étape E508, à l'étape E514, à laquelle on décrémente la variable i . On teste alors à l'étape E516 si la variable i a atteint O. Dans la négative, tous les bits de la clé secrète d n'ont pas été traités et on procède à l'itération suivante de la boucle en passant à l'étape E504 déjà décrite. Dans l'affirmative, l'ensemble des bits de la clé secrète ont été traités et le calcul d'exponentiation modulaire est alors terminé : la variable al correspond au résultat souhaité, soit md modn et la variable ao contient une donnée de vérification normalement telle que m X ao = a,. On retourne donc en sortie du sous-programme décrit ici les valeurs ao et al à l'étape E518. Les modes de réalisation qui précèdent ne sont que des exemples de mise en oeuvre de l'invention qui ne s'y limite pas.

Claims (21)

REVENDICATIONS
1. Procédé de traitement de données, caractérisé en ce qu'il comprend les étapes suivantes : - détermination d'une première donnée de résultat à partir d'une première donnée d'entrée et d'une première donnée secrète ; -obtention d'une première donnée compressée à partir de la 10 première donnée de résultat ou de la première donnée d'entrée au moyen d'un algorithme de compression ; - détermination d'une seconde donnée de résultat à partir d'une seconde donnée d'entrée et d'une seconde donnée secrète ; - obtention d'une seconde donnée compressée à partir de la 15 seconde donnée de résultat au moyen de l'algorithme de compression ; -comparaison de la première donnée compressée et de la seconde donnée compressée.
2. Procédé selon la revendication 1, caractérisé en ce que la 20 seconde donnée d'entrée est la première donnée d'entrée, en ce que la seconde donnée secrète est la première donnée secrète et en ce que la première donnée compressée est obtenue par compression de la première donnée de résultat. 25
3. Procédé selon la revendication 1, caractérisé en ce que la seconde donnée d'entrée est la première donnée de résultat et en ce que la première donnée compressée est obtenue par compression de la première donnée d'entrée. 30
4. Procédé selon la revendication 1, caractérisé en ce que la première donnée de résultat est obtenue au moins sur la base d'une donnée de vérification liée à une donnée représentant un résultat d'exponentiationmodulaire et en ce que la première donnée compressée est obtenue par compression de la première donnée de résultat.
5. Procédé selon la revendication 4, caractérisé en ce qu'au cours de l'exponentiation modulaire, une opération déterminée est sélectivement appliquée à la donnée de vérification ou à la donnée représentant le résultat selon la valeur d'un bit de la première donnée secrète.
6. Procédé selon l'une des revendications 1, 4 et 5, caractérisé en 10 ce que la seconde donnée de résultat est obtenue au moyen d'un calcul comprenant au moins une recombinaison de résultats modulaires partiels.
7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce que la première donnée secrète et la seconde donnée secrète sont chacune au 15 moins issues d'au moins une clé cryptographique.
8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce que l'algorithme de compression met en oeuvre une fonction non-inversible. 20
9. Procédé selon la revendication 8, caractérisé en ce que l'algorithme de compression est de type CRC.
10. Procédé selon la revendication 8, caractérisé en ce que l'algorithme de compression comprend la sommation de mots d'un nombre 25 prédéterminé de bits modulo le nombre deux élevé à la puissance de ce nombre déterminé.
11. Procédé selon la revendication 8, caractérisé en ce que l'algorithme de compression comprend l'application d'une opération de ou 30 exclusif à des mots d'un nombre prédéterminé de bits.
12. Procédé selon l'une des revendications 1 à 11, caractérisé par une étape de mémorisation de la première donnée compressée antérieure à l'étape d'obtention de la seconde donnée de résultat.
13. Procédé selon l'une des revendications 1 à 12, caractérisé par une étape de mémorisation de la seconde donnée compressée antérieure à l'étape de comparaison.
14. Procédé selon la revendication 12 ou 13, caractérisé en ce que l'étape de mémorisation est réalisée en mémoire vive.
15. Procédé selon l'une des revendications 1 à 11, caractérisé en ce que la première donnée compressée est mémorisée dans un registre interne d'un microprocesseur.
16. Dispositif de traitement de données, caractérisé en ce qu'il comprend : - des moyens de détermination d'une première donnée de résultat à partir d'une première donnée d'entrée et d'une première donnée secrète ; - des moyens d'obtention d'une première donnée compressée à partir de la première donnée de résultat ou de la première donnée d'entrée au moyen d'un algorithme de compression ; - des moyens de détermination d'une seconde donnée de résultat à partir d'une seconde donnée d'entrée et d'une seconde donnée secrète ; - des moyens d'obtention d'une seconde donnée compressée à partir de la seconde donnée de résultat au moyen de l'algorithme de compression ; - des moyens de comparaison de la première donnée compressée et de la seconde donnée compressée.30
17. Dispositif de traitement de données selon la revendication 16, caractérisé en ce qu'il comprend des moyens de mémorisation de la première donnée compressée.
18. Dispositif de traitement selon la revendication 16 ou 17, caractérisé en ce que la première donnée secrète et la seconde donnée secrète sont chacune au moins issues d'au moins une clé cryptographique.
19. Dispositif de traitement selon l'une des revendications 16 à 18, caractérisé en ce que l'algorithme de compression met en oeuvre une fonction non-inversible.
20. Dispositif de traitement selon l'une des revendications 16 à 19, caractérisé en ce le dispositif est une entité électronique de poche.
21. Dispositif de traitement selon l'une des revendications 16 à 20, caractérisé en ce que le dispositif est une carte à microcircuit.15
FR0756943A 2007-08-03 2007-08-03 Procede de traitement de donnees protege contre les attaques par generation de fautes et dispositif associe Expired - Fee Related FR2919739B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0756943A FR2919739B1 (fr) 2007-08-03 2007-08-03 Procede de traitement de donnees protege contre les attaques par generation de fautes et dispositif associe
US12/184,546 US8311212B2 (en) 2007-08-03 2008-08-01 Method of processing data protected against attacks by generating errors and associated device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0756943A FR2919739B1 (fr) 2007-08-03 2007-08-03 Procede de traitement de donnees protege contre les attaques par generation de fautes et dispositif associe

Publications (2)

Publication Number Publication Date
FR2919739A1 true FR2919739A1 (fr) 2009-02-06
FR2919739B1 FR2919739B1 (fr) 2009-12-04

Family

ID=39247329

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0756943A Expired - Fee Related FR2919739B1 (fr) 2007-08-03 2007-08-03 Procede de traitement de donnees protege contre les attaques par generation de fautes et dispositif associe

Country Status (2)

Country Link
US (1) US8311212B2 (fr)
FR (1) FR2919739B1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2280511A1 (fr) 2009-07-30 2011-02-02 Oberthur Technologies Procédé de traitement de données protégé contre les attaques par faute et dispositif associé
FR2984553A1 (fr) * 2011-12-15 2013-06-21 Proton World Int Nv Procede et dispositif de detection de fautes

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2990034B1 (fr) * 2012-04-25 2014-04-25 Inside Secure Procede de controle de redondance cyclique protege contre une attaque par canal auxiliaire
JP6262085B2 (ja) * 2014-06-25 2018-01-17 ルネサスエレクトロニクス株式会社 データ処理装置及び復号処理方法
JP6682743B2 (ja) * 2015-04-10 2020-04-15 シクパ ホルディング ソシエテ アノニムSicpa Holding Sa セキュリティ物品を認証するための携帯可搬装置および可搬認証装置の操作方法
CN109587557B (zh) * 2019-01-11 2022-03-08 京东方科技集团股份有限公司 数据传输方法及装置、显示装置
JP7173170B2 (ja) * 2019-01-24 2022-11-16 日本電気株式会社 情報処理装置、秘密計算方法及びプログラム

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998052319A1 (fr) * 1997-05-12 1998-11-19 Yeda Research And Development Co. Ltd. Procede et dispositif ameliores permettant de proteger les logiques de cles publiques contre les attaques basees sur la sequence des operations et les fautes
WO2003069841A1 (fr) * 2001-12-28 2003-08-21 Gemplus Procede de detection des attaques par mise en defaut contre les algorithmes cryptographiques
WO2004006074A2 (fr) * 2002-07-09 2004-01-15 Axalto Sa Procede permettant de securiser un ensemble electronique contre des attaques par l'introduction d'erreurs
WO2005088895A1 (fr) * 2004-03-11 2005-09-22 Oberthur Card Systems S.A. Procede de traitement de donnees securise, base notamment sur un algorithme cryptographique
US20070019805A1 (en) * 2005-06-28 2007-01-25 Trustees Of Boston University System employing systematic robust error detection coding to protect system element against errors with unknown probability distributions

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7246098B1 (en) * 1997-07-15 2007-07-17 Silverbrook Research Pty Ltd Consumable authentication protocol and system
US6289455B1 (en) * 1999-09-02 2001-09-11 Crypotography Research, Inc. Method and apparatus for preventing piracy of digital content
US6643815B1 (en) * 2000-03-30 2003-11-04 International Business Machines Corporation Data compression over communications links which are exposed to occasional errors
US7218734B2 (en) * 2001-05-02 2007-05-15 Nciper Corporation Limited Ring arithmetic method, system, and apparatus
DE10143728B4 (de) * 2001-09-06 2004-09-02 Infineon Technologies Ag Vorrichtung und Verfahren zum Berechnen eines Ergebnisses einer modularen Exponentiation
TW586086B (en) * 2002-12-27 2004-05-01 Ind Tech Res Inst Method and apparatus for protecting public key schemes from timing, power and fault attacks
JP2007520951A (ja) * 2004-01-27 2007-07-26 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 電力解析攻撃対策保護
US7394410B1 (en) * 2004-02-13 2008-07-01 Samplify Systems, Inc. Enhanced data converters using compression and decompression
KR100652377B1 (ko) * 2004-08-06 2007-02-28 삼성전자주식회사 모듈라 지수승 알고리즘, 기록매체 및 시스템
FR2884004B1 (fr) 2005-03-30 2007-06-29 Oberthur Card Syst Sa Procede de traitement de donnees impliquant une exponentiation modulaire et un dispositif associe
JP5431148B2 (ja) * 2006-05-31 2014-03-05 インターナショナル・ビジネス・マシーンズ・コーポレーション ストレージ用論理データオブジェクトの変換方法およびシステム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998052319A1 (fr) * 1997-05-12 1998-11-19 Yeda Research And Development Co. Ltd. Procede et dispositif ameliores permettant de proteger les logiques de cles publiques contre les attaques basees sur la sequence des operations et les fautes
WO2003069841A1 (fr) * 2001-12-28 2003-08-21 Gemplus Procede de detection des attaques par mise en defaut contre les algorithmes cryptographiques
WO2004006074A2 (fr) * 2002-07-09 2004-01-15 Axalto Sa Procede permettant de securiser un ensemble electronique contre des attaques par l'introduction d'erreurs
WO2005088895A1 (fr) * 2004-03-11 2005-09-22 Oberthur Card Systems S.A. Procede de traitement de donnees securise, base notamment sur un algorithme cryptographique
US20070019805A1 (en) * 2005-06-28 2007-01-25 Trustees Of Boston University System employing systematic robust error detection coding to protect system element against errors with unknown probability distributions

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KULIKOWSKI ET AL: "Robust codes and robust, fault-tolerant architectures of the Advanced Encryption Standard", JOURNAL OF SYSTEMS ARCHITECTURE, ELSEVIER SCIENCE PUBLISHERS BV., AMSTERDAM, NL, vol. 53, no. 2-3, 20 January 2007 (2007-01-20), pages 139 - 149, XP005855100, ISSN: 1383-7621 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2280511A1 (fr) 2009-07-30 2011-02-02 Oberthur Technologies Procédé de traitement de données protégé contre les attaques par faute et dispositif associé
FR2948792A1 (fr) * 2009-07-30 2011-02-04 Oberthur Technologies Procede de traitement de donnees protege contre les attaques par faute et dispositif associe
US9559838B2 (en) 2009-07-30 2017-01-31 Oberthur Technologies Method of processing data protected against fault injection attacks and associated device
FR2984553A1 (fr) * 2011-12-15 2013-06-21 Proton World Int Nv Procede et dispositif de detection de fautes
US9311477B2 (en) 2011-12-15 2016-04-12 Proton World International N.V. Method and device for fault detection
US10585738B2 (en) 2011-12-15 2020-03-10 Proton World International N.V. Method and device for fault detection

Also Published As

Publication number Publication date
US8311212B2 (en) 2012-11-13
US20090034717A1 (en) 2009-02-05
FR2919739B1 (fr) 2009-12-04

Similar Documents

Publication Publication Date Title
FR2919739A1 (fr) Procede de traitement de donnees protege contre les attaques par generation de fautes et dispositif associe
EP3457620B1 (fr) Procédé d'exécution d'un code binaire d'une fonction sécurisée par un microprocesseur
EP1864211B1 (fr) Procédé de traitement de données impliquant une exponentiation modulaire et un dispositif associé
EP2842232B1 (fr) Procédé de contrôle de redondance cyclique protégé contre une attaque par canal auxiliaire
EP2893431B1 (fr) Protection contre canaux auxiliaires
WO2005088895A1 (fr) Procede de traitement de donnees securise, base notamment sur un algorithme cryptographique
EP2296086B1 (fr) Protection d'une génération de nombres premiers contre des attaques par canaux cachés
FR3033965A1 (fr)
EP2282441A1 (fr) Procédé sécurisé de reconstruction d'une mesure de référence d'une donnée confidentielle à partir d'une mesure bruitée de cette donnée, notamment pour la génération de clés cryptographiques
WO2009112686A2 (fr) Procede et dispositifs de contre-mesure pour cryptographie asymetrique
EP2280511B1 (fr) Procédé de traitement de données protégé contre les attaques par faute et dispositif associé
EP3712794B1 (fr) Procédé d'exécution d'un code binaire d'une fonction sécurisée par un microprocesseur
EP3712795A1 (fr) Procédé d'exécution, par un microprocesseur, d'un code binaire comportant une fonction appelante et une fonction appelee
FR3071082A1 (fr) Procede d'execution d'un code binaire d'une fonction securisee par un microprocesseur
EP2336931B1 (fr) Procédé de vérification de signature
FR2979725A1 (fr) Procede de calculs cryptographique resistant aux defaillances materielles
FR2942560A1 (fr) Procede de traitement de donnees impliquant une exponentiation et un dispositif associe.
FR3015079A1 (fr) Verification d'integrite de paire de cles cryptographiques
FR3088452A1 (fr) Procede de verification d'integrite d'une paire de cles cryptographiques et dispositif cryptographique
WO2013186451A1 (fr) Procede de sauvegarde de donnees a l'exterieur d'un microcircuit securise
EP4089559B1 (fr) Microprocesseur équipé d'une unité arithmétique et logique et d'un module matériel de sécurisation
FR2899751A1 (fr) Procede de traitement cryptographique de donnees, dispositif et programme associes
EP3832947B1 (fr) Procédé d' exécution d'un programme d'ordinateur par un appareil électronique
FR2914129A1 (fr) Procede de traitement de donnees au sein d'une entite electronique
EP3614617A1 (fr) Procédé et dispositif de génération de paramètre(s) d'un protocole cryptographique asymétrique à partir d'une blockchain, procédé et appareil de cryptage ou de décryptage et programme d'ordinateur associés

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 10

PLFP Fee payment

Year of fee payment: 11

PLFP Fee payment

Year of fee payment: 12

PLFP Fee payment

Year of fee payment: 13

CA Change of address

Effective date: 20200218

CD Change of name or company name

Owner name: IDEMIA FRANCE, FR

Effective date: 20200218

CJ Change in legal form

Effective date: 20200218

CA Change of address

Effective date: 20200909

ST Notification of lapse

Effective date: 20210405