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

Abstract

La présente invention concerne un procédé de traitement de données mettant en oeuvre une donnée critique (VRAI, DS) initialement dans un état bloqué de sorte qu'aucune donnée de sortie (S) n'est révélatrice d'information sur cette donnée critique, le procédé comprenant l'évaluation d'une condition (Cond) déclenchant l'exécution (120, 210, 310, 410) d'une procédure de sécurité (PS1 ) affectant la donnée critique lorsque ladite condition (Cond) n'est pas vérifiée, postérieurement à l'évaluation de ladite condition, une étape de déblocage (130, 220, 320, 420) de la donnée critique éventuellement affectée, et une deuxième évaluation (140, 230, 340, 430) de la condition (Cond) déclenchant l'exécution (150, 230, 340, 430) d'une deuxième procédure de sécurité (PS2) affectant ladite donnée critique débloquée (S) lorsque ladite condition (Cond) n'est pas vérifiée.

Description

L'invention concerne un procédé de traitement conditionnel 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 formant un schéma de détection d'attaque (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 de celles-ci 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.

Ainsi, lorsque la condition vérifiée par la comparaison n'est pas remplie, une procédure de sécurité est mise en place avec par exemple la destruction des données secrètes, l'interruption du traitement cryptographique et, en tout état de cause, l'absence de résultat retourné par le système. En cas de condition remplie, le résultat du traitement cryptographique, c'est-à-dire des données sensibles, est alors renvoyé. Néanmoins, comme illustré par la figure 8, on a vu apparaître de nouvelles attaques par fautes consistant à perturber la comparaison de vérification finale de telle sorte que la vérification finale et la procédure de sécurité associée peuvent être sautées. Ainsi les attaques lors du traitement cryptographique ne sont en définitive pas détectées et le résultat comprenant les données critiques ou secrètes est toujours retourné, ce qui pose un nouveau problème de sécurité des systèmes cryptographiques. Par ailleurs, les systèmes d'identification personnelle par saisie d'un code confidentiel sont également soumis à diverses attaques telles que les attaques par génération de fautes. Dans ces systèmes, une comparaison est menée entre le code saisi et un code confidentiel mémorisé dans un équipement avant de délivrer une information d'autorisation en l'absence d'erreur, par exemple un code d'identification personnel PIN ("Persona/ Identification Number" selon la terminologie anglo-saxonne) stockée dans une carte SIM ("subscriber identity module" selon la terminologie anglo-saxonne) d'un téléphone mobile ou dans une carte bancaire. Cette information d'autorisation constitue une donnée sensible car elle peut, par exemple, permettre l'accès à des services de transactions ou à des locaux sécurisés.

Or, des attaques par fautes sont utilisées pour perturber ou sauter cette comparaison, de sorte à poursuivre l'exécution du traitement alors même que les deux codes ne sont pas égaux. Ce risque pose ainsi un problème de sécurité des systèmes électroniques d'identification ou d'authentification. La présente invention vise donc à résoudre les inconvénients de l'art antérieur. Dans ce dessein, l'invention propose un procédé de traitement de données mettant en oeuvre une première donnée, le procédé comprenant l'évaluation d'une condition déclenchant l'exécution d'une première procédure de sécurité affectant ladite première donnée lorsque ladite condition n'est pas vérifiée, procédé dans lequel ladite première donnée est initialement dans un état bloqué de sorte qu'aucune donnée de sortie n'est révélatrice d'information sur cette première donnée, et le procédé comprend en outre les étapes suivantes : - postérieurement à l'évaluation de ladite condition, une étape de déblocage de ladite première donnée éventuellement affectée, et - une deuxième évaluation de la condition, déclenchant l'exécution 10 d'une deuxième procédure de sécurité affectant ladite première donnée débloquée lorsque ladite condition n'est pas vérifiée. Le système est initialement dans un état dit "bloqué" dans lequel une personne mal intentionnée ne peut récupérer des informations sur la première donnée, généralement une donnée secrète ou critique (par exemple, les 15 données de sortie peuvent contenir des valeurs sûres). La première donnée ainsi bloquée est strictement interne au système dans lequel est exécuté le traitement des données, et est non accessible ou exploitable depuis l'extérieur de celui-ci. Le déblocage ultérieur de cette première donnée vise ainsi à l'affecter à une donnée de sortie ou à un paramètre qui est accessible depuis 20 l'extérieur du système dans lequel est réalisé le traitement. La procédure de sécurité altère généralement la donnée critique en question, par exemple par substitution par une valeur quelconque ou par effacement. Selon l'invention, la condition donnant lieu à l'exécution d'une 25 procédure de sécurité protégeant ladite première donnée est vérifiée de part et d'autre du déblocage de cette première donnée. Ainsi, lorsqu'une attaque par fautes continues est menée, la perturbation des deux conditions vérifiées par cette attaque affecte également, du fait de la continuité des fautes appliquées, l'opération de déblocage prévue 30 entre ces deux évaluations. Le déblocage de ladite première donnée n'a ainsi pas lieu.

Pour permettre le déblocage de cette donnée, l'attaque doit cesser avant cette opération de déblocage ou être postérieure à celle-ci. Ainsi, soit la première vérification soit la deuxième vérification est effectuée de telle sorte qu'au moins une mesure de sécurité est exécutée en cas de tentative de fraude. L'invention se prémunit ainsi des attaques qui peuvent sauter une instruction ou un jeu d'instructions continues. Elle est notamment d'autant plus efficace que les exécutions des instructions correspondant aux deux vérifications et au déblocage sont rapprochées, par exemple, ces trois instructions peuvent s'enchaîner directement à la suite. En effet, de nos jours, les unités de traitement présentent des fréquences de cadencement et donc d'exécution d'instructions très élevées. L'application d'attaques par fautes sur un nombre limité d'instructions précises est par conséquent complexe.

Dans un mode de réalisation simple, ladite condition porte sur la comparaison entre deux valeurs et elle est évaluée lors d'une instruction conditionnelle pour déclencher l'exécution des procédures de sécurité. Cette réalisation s'applique notamment aux solutions de l'art antérieur où par exemple une double exécution d'un traitement cryptographique est effectuée puis comparée avant émission du résultat, qui représente la première donnée dite critique. Néanmoins, de telles instructions conditionnelles ne sont pas toujours souhaitables étant donné qu'elles entraînent l'exécution d'instructions assez éloignées de l'instruction même de saut conditionnel. Ces sauts sont notamment exploités lors d'attaques par faute pour dériver l'exécution du traitement. Ainsi, selon une variante, une des évaluations de condition et la procédure de sécurité associée comprennent conjointement l'application d'un masque binaire à une forme binaire de ladite première donnée éventuellement débloquée, ledit masque étant fonction de ladite condition, notamment il peut s'agir du résultat d'une opération portant sur les éléments de la condition de telle sorte que l'on n'estime pas directement si la condition est vérifiée ou non mais on utilise ce résultat qui reflète indirectement la vérification de la condition.

Grâce à cette disposition, on réalise en une seule phase l'évaluation de la condition et l'exécution de la procédure de sécurité, le masque pouvant en effet être choisi de façon appropriée pour altérer ou non la valeur critique en fonction de la condition, comme évoqué ci-après.

En outre, l'utilisation d'un masque binaire est avantageuse en ce que la génération de celui-ci ainsi que les opérations possibles avec celui-ci requièrent peu de capacités de traitement. En particulier, on applique ledit masque binaire lors des deux évaluations et procédures de sécurité associées conjointes. Ainsi, en évitant la présence de sauts conditionnels pour l'une ou l'autre des évaluations, on exécute linéairement les instructions du traitement, ce qui sécurise ce dernier. Généralement, la condition porte sur la comparaison entre deux valeurs, par exemple deux résultats issus d'une double exécution d'un traitement cryptographique. Egalement, ce peut être la comparaison entre une donnée issue d'un traitement principal (saisie d'un code par un utilisateur) ou secondaire (mesure de vérification) et une valeur attendue mémorisée. Ainsi, on prévoit de générer ledit masque binaire en fonction du résultat de l'opération binaire OU EXCLUSIF appliquée aux deux valeurs binaires. L'opération mise en oeuvre nécessite de faibles ressources et le résultat est aisément exploitable (valeur nulle si les deux valeurs sont identiques). Ainsi, le résultat est généralement exploité comme indice d'une table stockant divers masques. Dans ce dessein, on prévoit de générer ledit masque binaire à l'aide d'une table de correspondances, ou LUT ("look-up table" selon la terminologie anglo-saxonne).

En particulier, une réalisation simple consiste à prévoir une table de correspondances comprenant au moins autant d'entrées que de valeurs prises par le résultat de l'opération binaire OU EXCLUSIF appliquée aux deux valeurs binaires. Par exemple, si les deux valeurs binaires sont chacune sur deux octets, on peut prendre une table de correspondances ayant 216 entrées, chacune correspondant à une valeur possible issue de l'opération OU EXCLUSIF.

On prévoit alors que ladite table de correspondances comprend un masque associé à la condition vérifiée dans son entrée d'index 0 (résultat de la fonction OU EXCLUSIF si les deux valeurs comparées sont égales) et des masques nuls dans les autres entrées.

Cependant, la dimension de cette table et donc l'espace mémoire requis peuvent croître très rapidement avec la taille des valeurs manipulées alors que, généralement, une seule entrée (celle d'index 0) contient le masque associé à la condition vérifiée, c'est-à-dire le masque qui n'altère pas la donnée critique. On cherche alors à utiliser une table de correspondance de taille réduite. On prévoit ainsi que l'on applique récursivement, à un masque binaire par défaut, des masques déterminés, chacun, dans ladite table de correspondances à l'aide d'une partie différente, généralement chaque octet, dudit résultat de l'opération binaire OU EXCLUSIF, de sorte à générer ledit masque binaire.

On traite ainsi, par exemple, successivement chaque octet dudit résultat OU EXCLUSIF, ce qui permet de se limiter à une table de correspondances comprenant uniquement 256 entrées. En pratique, on conviendra d'utiliser comme masque binaire par défaut le masque binaire associé à la condition vérifiée, et de prévoir dans l'entrée d'index 0 de la table un masque formé uniquement de 1 alors que les autres entrées sont nulles. Ainsi, en traitant le résultat du OU EXCLUSIF octet par octet, on récupère, pour chaque octet nul (c'est-à-dire que les deux valeurs ont le même octet correspondant), le masque formé de 1, qui appliqué au masque par défaut, par l'opération binaire ET par exemple, ne le modifie pas. En revanche si un octet du résultat du OU EXCLUSIF n'est pas nul, alors le masque récupéré via la table est nul de telle sorte qu'appliqué au masque binaire par défaut, ce dernier devient également nul à l'aide d'une opération appropriée, typiquement l'opération binaire ET. Bien sûr, un traitement autre que par octet et donc une table de 30 correspondances de dimension autre peuvent être prévus. Dans un mode de réalisation, ledit masque binaire est formé uniquement de "1" lorsque la condition est vérifiée, et est nul autrement. Cette disposition permet de mettre en oeuvre des procédures de sécurité simples puisque l'application du masque formé uniquement de "1" à l'aide de fonctions booléennes permet généralement de garder inchangée une valeur critique alors que l'application d'un masque nul peut aisément altérer de façon irréversible une valeur critique. Ainsi, l'on prévoit que les évaluation et procédure de sécurité conjointes comprennent le calcul suivant: (masque A DC) v (masque A DNC) où A et v représentent respectivement les opérations binaires ET et OU (par disjonction), masque le complémentaire dudit masque binaire, DC représente ladite première donnée (donnée critique) éventuellement débloquée et DNC représente une donnée quelconque (donnée non critique). Ainsi, on récupère la donnée critique DC si le masque est formé uniquement de "1" (condition vérifiée) ou une donnée quelconque DNC si le masque est nul (condition non vérifiée). Dans ce dernier cas, le traitement génère en sortie une donnée sans intérêt empêchant la divulgation de la donnée critique. Dans une variante, les évaluation et procédure de sécurité conjointes combinent ladite première donnée éventuellement débloquée avec ledit masque binaire à l'aide d'une opération booléenne bit à bit, de sorte que ladite combinaison efface la première donnée lorsque ladite condition n'est pas vérifiée. En particulier, ladite opération booléenne est l'opération binaire ET, et ledit masque binaire est formé uniquement de "1" lorsque la condition est vérifiée, et est nul autrement. En effet, l'utilisation d'un masque nul permet, à l'aide de la simple opération booléenne ET, d'effacer une donnée.

Dans un mode de réalisation, ladite étape de déblocage comprend la copie de la première donnée éventuellement affectée depuis une donnée temporaire vers une donnée de sortie. Dans ces différents contextes, différentes applications de l'invention sont envisagées.

En particulier, ladite condition porte sur la comparaison entre un code fourni et un code secret mémorisé, et ladite première donnée est une indication représentative de l'identité entre lesdites codes fourni et secret.

Ladite première donnée (critique) résultante permet par exemple l'activation de services. Cette réalisation s'applique notamment à la saisie d'un code personnel PIN, d'un code confidentiel de carte bleue et de façon générale à tout code d'accès à un système. Elle s'applique également à un message transmis dont la signature calculée (code fourni) est comparée à une signature stockée. Dans ce cadre, les mesures de sécurité consistent à indiquer dans la donnée dite critique que l'égalité des codes n'est pas vérifiée, en lieu et place de l'autorisation permettant d'activer les services. Dans un mode de réalisation, lesdites procédures de sécurité comprennent l'effacement de ladite première donnée éventuellement débloquée dans une mémoire. Cette réalisation s'applique pour le stockage de données secrètes ou sensibles, tels une clé de cryptage, un code secret. Comme prévu par des solutions connues, on peut effectuer des calculs complémentaires de détection d'attaque dont résultera, lors de l'évaluation d'une condition, l'effacement ou non des données jugées secrètes. L'invention permet ainsi d'améliorer des algorithmes cryptographiques réalisant, 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.

Corrélativement, l'invention vise également un dispositif de traitement de données mettant en oeuvre une première donnée, comprenant un moyen d'évaluation d'une condition agencé pour déclencher l'exécution d'une première procédure de sécurité affectant ladite première donnée lorsque ladite condition n'est pas vérifiée, le dispositif comprenant en outre: - un moyen de déblocage, postérieur à l'évaluation de ladite condition, de ladite première donnée éventuellement affectée, depuis un état bloqué initial dans lequel aucune donnée de sortie n'est révélatrice d'information sur cette première donnée vers un état débloqué, et - un moyen pour évaluer une deuxième fois ladite condition, ledit moyen étant agencé pour déclencher l'exécution d'une deuxième procédure de sécurité affectant ladite première donnée débloquée lorsque ladite condition n'est pas vérifié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 un mode de réalisation, le dispositif comprend un moyen de génération d'un masque binaire représentatif de ladite condition, et est apte à appliquer ledit masque binaire sur ladite première donnée de sorte à conjointement évaluer ladite condition et exécuter une desdites procédures de sécurité en cas de condition non vérifiée.

En particulier, ce moyen de génération comprend une table de correspondances comme évoquée plus haut. Selon une caractéristique de l'invention, le moyen de génération comprend : - un masque binaire par défaut, - une table de correspondances comprenant une pluralité de masques, - un moyen de récupération, partie par partie, d'une donnée représentative de ladite condition, - un moyen de détermination, pour chaque partie récupérée, d'un masque de ladite table correspondant à ladite partie récupérée, ledit moyen de génération étant apte à appliquer successivement lesdits masques déterminés audit masque binaire par défaut de sorte à générer ledit masque binaire. Ainsi, l'invention garantit l'exécution d'une procédure de sécurité pour protéger une donnée critique lorsqu'une condition donnée n'est pas satisfaite, et notamment de sécuriser la comparaison entre deux valeurs et l'exécution des actions qui résultent de cette comparaison. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les dessins ci-joints, 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, sous forme de logigramme, un premier exemple général de procédé de traitement de données conforme aux enseignements de l'invention ; - la figure 4 représente un premier exemple d'application du procédé conforme à l'invention; - la figure 5 représente une amélioration du procédé de la figure 4 par l'utilisation d'un masque binaire ; - la figure 6 illustre un exemple de génération du masque binaire utilisé dans le procédé de la figure 5 ; - la figure 7 représente un deuxième exemple d'application du procédé conforme à l'invention; - la figure 8 illustre un scénario d'attaques sur un système de l'art antérieur; et - la figure 9 représente différents scénarios d'attaques d'un système incorporant la présente invention.

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 à 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 E 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 S dans la suite, du microprocesseur 10 vers l'interface de communication 30 à destination d'un dispositif extérieur. Cette donnée de sortie S issue d'un traitement de données par le microprocesseur 10 est généralement une donnée critique en ce qu'elle peut donner autorisation à poursuivre ou accéder à des services via un autre système, ou peut révéler des informations sur une donnée secrète 80 interne au système. On souhaite ainsi protéger cette donnée critique. 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 générales d'une mise en oeuvre de l'invention. Dans un état initial 100, le système du dispositif 40 est dans un état bloqué par défaut, dans lequel les données secrètes 80 et critiques ou sensibles DS que le système manipule, sont isolées et inaccessibles depuis l'extérieur du dispositif. On peut, par exemple, s'assurer que la valeur de sortie S ou autres paramètres du dispositif 40, accessibles depuis l'extérieur, comprend une valeur sûre qui n'est pas révélatrice, à cet instant, d'une donnée critique DS que l'on souhaite protéger et dérivant de la donnée secrète 80. Cet état peut par exemple faire suite à des opérations classiques de traitements, notamment de traitements cryptographiques ayant générés la donnée critique ou sensible DS à partir de celle secrète 80. Ainsi, comme illustré par la figure 9a, toute attaque par fautes à ce stade, court-circuitant l'ensemble des traitements subséquents selon l'invention, ne conduit qu'à la transmission de cette donnée de sortie S dépourvue de criticité. Comme on le verra par la suite, il y a donc lieu qu'une action de déblocage de la donnée critique DS pour l'affecter dans la donnée de sortie S se produise, afin qu'une exploitation normale de cette donnée puisse être effectuée.

Comme l'illustreront les exemples ci-après et notamment la figure 9, la présente invention repose sur au moins une double vérification d'une condition, généralement également liée à la détection d'attaques, dont chaque vérification prend place de part et d'autre de l'action de déblocage. Ainsi, l'invention permet qu'en cas d'attaque visant au saut d'une instruction ou d'un jeu d'instructions continues liées à ces vérifications, soit l'action de déblocage n'est pas exécutée, soit une des vérifications est normalement effectuée de telle sorte que des mesures de sécurité peuvent être prises, le cas échéant, pour éviter la mise à disposition de la donnée critique DS à des personnes malveillantes. Ainsi, dans une première étape 110, on évalue une condition Cond à satisfaire, levée par exemple au travers d'un schéma de détection d'attaques ou d'une simple comparaison de codes saisis. Il peut s'agir à titre d'exemple de la comparaison entre les résultats de deux exécutions d'un traitement cryptographique ayant précédé l'état 100. Si la condition Cond n'est pas vérifiée (sortie NON de l'étape 110), on procède, à l'étape 120, à l'exécution d'une procédure de sécurité PSI visant à empêcher tout accès à la donnée critique DS. Cette procédure de sécurité PSI peut consister, comme on le verra par la suite, en un effacement pur et simple de la donnée en question de telle sorte que la carte à microcircuit 40 hébergeant le procédé de traitement n'est plus exploitable. Elle peut également consister en la substitution de la valeur critique par une valeur quelconque. Ainsi, dans ce dernier cas, les éventuelles actions ultérieures seront réalisées sur cette valeur quelconque.

Suite à l'exécution de la procédure de sécurité ou lorsque la condition est vérifiée (sortie OUI de l'étape 110), on procède, lors de l'étape 130, au déblocage du système ou de la donnée critique DS, c'est-à-dire par exemple avec l'affectation, à la donnée de sortie S, de la donnée critique DS issue de traitements cryptographiques par exemple.

On remarquera ici que la donnée affectée à la donnée de sortie S n'est pas nécessairement la donnée critique DS de l'état 100, puisque l'exécution de la procédure de sécurité PSI peut l'avoir altérée.

On poursuit à l'étape 140 en vérifiant à nouveau la condition Cond. Si la condition Cond n'est pas vérifiée (sortie NON de l'étape 140), on procède, à l'étape 150, à l'exécution d'une nouvelle procédure de sécurité PS2 visant à empêcher tout accès à la donnée de sortie S contenant éventuellement la donnée critique DS. Cette étape 150 peut être en tout point similaire à l'étape 120, à l'exception qu'elle affecte la donnée critique DS débloquée, c'est-à-dire généralement la donnée de sortie S. Le traitement se termine, à l'étape 160, si la condition Cond est vérifiée ou à la suite de l'étape 150. Cette étape 160 peut notamment consister en la fourniture de la donnée de sortie S à des dispositifs extérieurs via l'interface de communication 30. Selon la mise en oeuvre logicielle choisie (par exemple l'utilisation d'une instruction conditionnelle ou d'un masque), ces différentes étapes peuvent couvrir plus ou moins d'instructions logicielles exécutées par le microprocesseur 10 du système 40. Pour plus d'efficacité de l'invention, on veille à prévoir ces instructions groupées (sans autre opération entre elles) et linéaire dans la mesure du possible. En effet, il convient de garantir que l'instruction de déblocage soit positionnée entre les deux groupes d'instructions relatifs aux deux évaluations et procédures de sécurité associées.

On illustre maintenant l'efficacité de l'invention en référence à différents scénarios proposés sur la figure 9. L'exemple de la figure 9a est un cas où l'action de déblocage n'est pas exécutée puisque l'attaque menée court-circuite l'ensemble des instructions, notamment celle du déblocage 130. Ainsi, la donnée critique reste bloquée dans l'état sécurisé initial. De façon générale, toute attaque sautant l'opération de déblocage 130 ne permet pas de récupérer la donnée critique en sortie, car cette donnée reste bloquée. Voyons maintenant différents scénarios d'attaques dans lesquels le déblocage a lieu mais où l'invention est efficace. Sur la figure 9b, on a représenté une attaque au début du traitement visant à sauter la première vérification (110) et la procédure de sécurité PSI (120) associée. Dans ce cas, le déblocage 130 a bien lieu. L'attaque par fautes continues étant finie, la deuxième vérification 140 a alors lieu, En cas de vérification positive, la valeur attendue critique est retournée 160 comme sortie du système puisque aucune erreur n'est détectée.

En cas de vérification négative, la procédure de sécurité PS2 altère (150) alors la donnée critique. La sortie obtenue (160) n'est donc pas la donnée critique. Sur la figure 9c, on a représente une autre attaque visant la fin du traitement pour sauter la deuxième vérification (140) et la procédure de sécurité PS2 (150) associée.

Dans ce cas, lors du déblocage 130, soit la condition n'a pas été vérifiée et la donnée critique a été altérée par la procédure PSI, soit la condition est vérifiée auquel cas on conserve la donnée critique puisque aucun problème n'a été détecté. Dès ce stade, on a garanti la sécurité de la donnée critique, encore bloquée. Les étapes ultérieures de déblocage 130 et de sortie 160 ne sont alors utiles que pour la fourniture en sortie de la donnée soit critique, soit altérée. Par conséquent, quelque soit le scénario envisagé, on obtient en sortie la donnée critique uniquement si on a pu vérifier au moins une fois l'exactitude de la condition Cond.

La figure 4 représente, de façon schématique, un premier exemple d'application de l'invention reposant sur une fonction de comparaison. Il peut s'agir de la comparaison de deux valeurs qu'un schéma de détection d'attaques peut fournir à l'issue d'un traitement cryptographique. Ce schéma fournit ainsi une valeur c* calculée et une valeur correspondante c attendue (éventuellement calculée lors d'une itération précédente du traitement cryptographique). En variante, il peut s'agir de la comparaison entre un code personnel E type code PIN ou code bancaire, saisi par un utilisateur sur un clavier et transmis au dispositif de traitement 40, ici une carte à microcircuit, avec un code secret CS déjà mémorisé dans ladite carte à microcircuit. Dans une autre variante, la donnée E reçue par le dispositif de traitement 40 est un message numérique reçu, à partir duquel il calcule, dans un traitement préliminaire, une valeur de signature. Ainsi, cette valeur de signature est comparée à une signature enregistrée CS et attendue pour valider l'authenticité. Dans ce premier exemple d'application de l'invention, le résultat de la comparaison (un booléen indiquant VRAI ou FAUX) est transmis comme donnée de sortie S à un autre ensemble logiciel de codes ou à un dispositif extérieur, par exemple pour permettre l'accès à des services ou continuer un programme informatique en cours d'exécution. On remarque donc que le booléen "VRAI" constitue une donnée critique car il est l'image de l'identité entre les deux valeurs à comparer et donne accès auxdits services ou à la suite du programme informatique. L'utilisation d'un type de donnée autre qu'un booléen peut toutefois être envisagée. Les traitements sur celui-ci restant alors similaires en tout point. Le traitement selon l'invention est alors le suivant : - à l'étape 200, on affecte le booléen VRAI à une donnée temporaire. Le système est dans un état bloqué car cette donnée temporaire n'est pas accessible : temp - VRAI - à l'étape 210, on utilise une instruction conditionnelle pour exécuter la mesure de sécurité PSI si les deux valeurs c et c* à comparer sont différentes. La mesure de sécurité écrase la donnée temporaire, qui contient la valeur critique VRAI, avec le booléen FAUX. De la sorte, la donnée critique DS "VRAI" n'est plus présente dans le système : si eval(c≠c*) alors temp - FAUX - à l'étape 220, on débloque le système en affectant la donnée temporaire dans la donnée de sortie S : S - temp - enfin, à l'étape 230, on utilise de nouveau une instruction conditionnelle pour exécuter la mesure de sécurité PS2 si la condition Cond n'est pas vérifiée (les deux valeurs c et c* à comparer sont différentes). La mesure de sécurité écrase la donnée de sortie avec le booléen FAUX. De la sorte, la donnée critique DS "VRAI" n'est plus présente dans le système : si eval(c≠c*) alors S - FAUX Ainsi, la valeur VRAI n'est obtenue en sortie S qu'avec l'exécution des étapes 200 et 220, sans qu'aucune des procédures de sécurité PS n'ait été jouée. L'utilisation d'une attaque permettant le saut d'une instruction ou d'un jeu d'instructions continues ne permet de débrancher les deux procédures de sécurité PSI et PS2 tout en permettant l'exécution de l'étape de déblocage 220. Ainsi, on garantit la communication de la valeur critique uniquement lorsque la condition est vérifiée. La figure 5 illustre cette même application, améliorée par l'utilisation 10 d'un masque à la place de l'instruction conditionnelle si...alors. Dans une première étape 300, on détermine un masque binaire reflétant l'opérande de la condition Cond à vérifier : masque f(c=c*) On utilise, pour ce faire, une fonction f associant la condition Cond à 15 deux masques de taille w, où w est la taille de la donnée critique, ici un booléen d'un bit : (1,1,...,1) si Cond est vraie f:Cond - (0,0,...,0) si Cond est fausse En variante, on peut utiliser des masques de taille w inférieure à celle de la donnée critique ou sensible DS, par exemple w=8 bits, et appliquer ce 20 masque à chaque octet de la donnée critique. A l'étape 310, on calcule : temp - (masque A "VRAI") v ( masque A "FAUX") où A et v sont les opérations binaires ET et OU (par disjonction), et masque est le complémentaire de masque. Cette opération réalise à la fois 25 l'èvaluaUon de la condition Cond et l'exécution de la mesure de sécurité PSI. Elle permet d'affecter la valeur VRAI à la donnée temporaire uniquement si la condition est vérifiée, et la valeur FAUX en cas de condition non vérifiée. En cas de saut d'instruction, la donnée temporaire temp n'est pas affectée et reste ainsi à une valeur par défaut supposée différente de VRAI. Le reste du traitement ci-dessous ne pourra donc en aucun cas aboutir à fournir la valeur VRAI en sortie S. A l'étape 320, on débloque le système en affectant la donnée temporaire dans la donnée de sortie S, de façon similaire aux étapes 130 et 220: S - temp A l'étape 330, on génère à nouveau le masque, au cas où l'étape 300 ait été perturbée par une éventuelle attaque : masque f(c=c*) Cette nouvelle génération du masque permet de parer toute attaque sur le masque généré à l'étape 300, et qui aurait pu être réutilisé. Puis, à l'étape 340, on calcule de façon similaire à l'étape 310 : S - (masque A S) v (masque A "FAUX") La figure 6 propose un mode de mise en oeuvre de la fonction f.

La fonction f reçoit ici en entrée une valeur binaire X représentative de la condition c=c*. On choisit X = cOc* (opération binaire OU EXCLUSIF qui renvoie donc 0 si les deux valeurs sont égales). La donnée X a donc la même longueur k (ici on choisit k multiple de w pour simplifier les explications) que chacune des deux données c et c*. 1) si X = 0 Une fonction f satisfaisant f : X (1,1 peut donc être (0,0,...,0) si X 0 choisie pour la présente invention. Néanmoins, on propose ci-après une mise en oeuvre rapide de cette fonction à l'aide d'une table de correspondances (look-up table LUT). Cette dernière comprend 28=256 entrées, ce qui permettra, comme on le verra par la suite de travailler sur des octets de X. En variante, on peut utiliser toute autre longueur de travail, par exemple quatre bits, auquel cas la table LUT comprendra 24=16 entrées. La table LUT est remplie comme suit :

LUT[0] = 2w-1 = (1,1,1,...,1) LUT[i] = 0, pour i e {1, ..., 255}.

On définit initialement un masque par défaut Res = 2w-1. Puis on procède aux calculs suivants : Pour i = 0 à k/8-1 Res - Res A LUT [X[i] A 255] où X[i] est le i-ième octet de X. On utilise ensuite Res comme masque pour les opérations de la figure 5.

La figure 7 représente, de façon schématique, un deuxième exemple d'application de l'invention, notamment dans le cas de traitements classiques en cryptographie où, avant de retourner une valeur considérée comme sensible, on vérifie deux valeurs issues de l'exécution du calcul cryptographique. Cette application s'appuie sur une fonction de destruction qui garantie l'effacement de la donnée sensible DS stockée lorsqu'une attaque durant le traitement cryptographique a été détectée. Initialement la donnée sensible n'est pas accessible aux individus ou équipements externes au dispositif de traitement 40: c'est l'état bloqué dudit dispositif.

A l'étape 410, on utilise une instruction conditionnelle pour exécuter la mesure de sécurité PSI si les deux valeurs c et c* à comparer sont différentes. La mesure de sécurité efface la donnée sensible DS de la mémoire: si eval(c≠c*) alors effacer(DS) A l'étape 420, on débloque le système en affectant la donnée 20 temporaire dans la donnée de sortie S : S-DS Puis, à l'étape 430, on utilise de nouveau une instruction conditionnelle pour exécuter la mesure de sécurité PS2 si la condition Cond n'est pas vérifiée (les deux valeurs c et c* à comparer sont différentes). La 25 mesure de sécurité efface la donnée de sortie : si eval(c≠c*) alors effacer(S). L'utilisation d'un masque et d'une table de correspondances LUT peut également s'appliquer à ce deuxième exemple d'application de l'invention comme décrit ci-après. Les différentes étapes du traitement selon l'invention se 30 résume alors comme suit : masque f(c=c*) pour i = 0 à m-1 (où m vaut le ratio entre la longueur de la donnée sensible DS et la longueur du masque, on peut ainsi travailler, partie par partie DS[i], sur la donnée sensible DS et utiliser un masque de faible taille, par exemple d'un octet) DS[i] - DS[i] A masque S-DS masque f(c=c*) pour i=0àm-1 S[i] - S[i] A masque.

Bien entendu, on utilise ici aussi un masque (1,1,...,1) lorsque la condition Cond est vérifiée et un masque nul autrement. L'application du masque nul sur la donnée sensible DS ou sur la donnée de sortie S permet l'effacement de celles-ci lors des procédures de sécurité PS. Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas. En particulier, une table de correspondances LUT comprenant autant d'entrées que de valeurs possibles de X = cOc* peut être envisagée. Dans ce cas, l'entrée LUT[0] comprend le masque (1,1...1) souhaité en cas de condition remplie et les autres entrées, un masque nul. On obtient ainsi le masque binaire lors des étapes 300 et 330 par lecture directe dans la table de correspondantes, sans procéder aux différentes étapes de la figure 6.

Claims (15)

1. REVENDICATIONS1. Procédé de traitement de données mettant en oeuvre une première donnée (VRAI, DS), le procédé comprenant l'évaluation (110, 210, 310, 410) d'une condition (Gond) déclenchant l'exécution (120, 210, 310, 410) d'une première procédure de sécurité (PSI) affectant ladite première donnée lorsque ladite condition (Gond) n'est pas vérifiée, le procédé étant caractérisé en ce que ladite première donnée (VRAI, DS) est initialement dans un état bloqué de sorte qu'aucune donnée de sortie (S) n'est révélatrice d'information sur cette première donnée, et en ce qu'il comprend les étapes suivantes : - postérieurement à l'évaluation de ladite condition, une étape de déblocage (130, 220, 320, 420) de ladite première donnée éventuellement 15 affectée, et - une deuxième évaluation (140, 230, 340, 430) de la condition (Gond), déclenchant l'exécution (150, 230, 340, 430) d'une deuxième procédure de sécurité (PS2) affectant ladite première donnée débloquée (S) lorsque ladite condition (Gond) n'est pas vérifiée. 20
2. 2. Procédé selon la revendication précédente, dans lequel une des évaluations de la condition (Gond) et la procédure de sécurité associée comprennent conjointement l'application (310, 340) d'un masque binaire à une forme binaire de ladite première donnée éventuellement débloquée (VRAI, DS, S), ledit masque étant fonction de ladite condition (Gond). 25
3. 3. Procédé selon la revendication précédente, dans lequel on applique ledit masque binaire lors des deux évaluations (310, 340) et procédures de sécurité (PSI , PS2) associées conjointes.
4. 4. Procédé selon l'une des revendications 2 et 3, dans lequel la condition (Gond) porte sur la comparaison entre deux valeurs (c, c*, E, CS), et 30 on génère ledit masque binaire en fonction du résultat (X) de l'opération binaire OU EXCLUSIF appliquée aux deux valeurs binaires.
5. 5. Procédé selon l'une des revendications 2 à 4, dans lequel on applique récursivement, à un masque binaire par défaut (Res), des masques déterminés, chacun, dans une table de correspondances (LUT) à l'aide de chaque octet dudit résultat (X) de l'opération binaire OU EXCLUSIF, de sorte à générer ledit masque binaire.
6. 6. Procédé selon l'une des revendications 2 à 4, dans lequel on génère ledit masque binaire à l'aide d'une table de correspondances (LUT), ladite table de correspondances (LUT) comprenant un masque associé à la condition vérifiée dans son entrée d'index 0 et des masques nuls dans les autres entrées.
7. 7. Procédé selon l'une des revendications 2 à 6, dans lequel ledit masque binaire est formé uniquement de "1" lorsque la condition est vérifiée, et est nul autrement.
8. 8. Procédé selon la revendication 7, dans lequel les évaluation et procédure de sécurité (310, 340) conjointes comprennent le calcul suivant: (masque A DC) v (masque A DNC) où A et v représentent respectivement les opérations binaires ET et OU (par disjonction), masque le complémentaire dudit masque binaire, DC représente ladite première donnée éventuellement débloquée (VRAI, DS, S) et 20 DNC représente une donnée quelconque.
9. 9. Procédé selon la revendication 7, dans lequel les évaluation et procédure de sécurité conjointes (310, 340) combinent ladite première donnée éventuellement débloquée (VRAI, DS, S) avec ledit masque binaire à l'aide d'une opération booléenne ET, de sorte que ladite combinaison efface la 25 première donnée lorsque ladite condition (Gond) n'est pas vérifiée.
10. 10. Procédé selon la revendication 1, dans lequel ladite condition (Gond) porte sur la comparaison entre deux valeurs (c, c*, E, CS) et elle est évaluée lors d'une instruction conditionnelle (210, 230, 410, 430) pour déclencher l'exécution des procédures de sécurité (PSI , PS2). 30
11. 11. Procédé selon l'une quelconque des revendications précédentes, dans lequel ladite condition (Gond) porte sur la comparaison entre un code fourni (c*, E) et un code secret mémorisé (c, CS), et ladite premièredonnée est une indication (VRAI) représentative de l'identité entre lesdites codes fourni et secret.
12. 12. Procédé selon l'une quelconque des revendications précédentes, dans lequel lesdites procédures de sécurité (PSI, PS2) comprennent l'effacement de ladite première donnée éventuellement débloquée dans une mémoire.
13. 13. Dispositif (40) de traitement de données mettant en oeuvre une première donnée (VRAI, DS), comprenant un moyen d'évaluation d'une condition (Gond) agencé pour déclencher l'exécution d'une première procédure de sécurité (PSI) affectant ladite première donnée lorsque ladite condition (Gond) n'est pas vérifiée, le dispositif étant caractérisé en ce qu'il comprend : - un moyen de déblocage, postérieur à l'évaluation de ladite condition, de la première donnée éventuellement affectée, depuis un état bloqué initial dans lequel aucune donnée de sortie n'est révélatrice d'information sur cette première donnée vers un état débloqué, et - un moyen pour évaluer une deuxième fois ladite condition (Gond), ledit moyen étant agencé pour déclencher l'exécution d'une deuxième procédure de sécurité (PS2) affectant ladite première donnée débloquée (S) lorsque ladite condition n'est pas vérifiée.
14. 14. Dispositif selon la revendication précédente, comprenant un moyen de génération d'un masque binaire représentatif de ladite condition, et est apte à appliquer ledit masque binaire sur ladite première donnée de sorte à conjointement évaluer ladite condition et exécuter une desdites procédures de sécurité en cas de condition non vérifiée.
15. 15. Dispositif selon la revendication précédente, dans lequel le moyen de génération comprend : - un masque binaire par défaut (Res), - une table de correspondances (LUT) comprenant une pluralité de masques, - un moyen de récupération, partie par partie, d'une donnée (X) représentative de ladite condition (Gond),- un moyen de détermination, pour chaque partie récupérée, d'un masque de ladite table correspondant à ladite partie récupérée, ledit moyen de génération étant apte à appliquer successivement lesdits masques déterminés audit masque binaire par défaut de sorte à générer 5 ledit masque binaire.