Brevet FR3154832A1 — publié le 20250502

L’invention concerne une carte à puce (100), pour transaction avec un lecteur (200) ou un serveur (300), comprenant : • une première puce (110), pour pouvoir établir une transaction, • une deuxième puce (120), muette par défaut, configurée pour pouvoir effectuer un calcul à partir des données de la transaction, et émettre un signal dont la valeur est représentative du résultat, Elle est essentiellement caractérisée en ce que : La deuxième puce (120) est configurée pour pouvoir sortir de son mode muet et émettre une requête de sabotage, qui est : • soit reconnue comme telle par le lecteur (200) ou le serveur (300), • soit inattendue par le lecteur (200) ou le serveur (300), la réception de l’ensemble d’au moins une requête de sabotage par le lecteur (200) ou le serveur (300) sabotant la transaction entre la première puce (110) et le lecteur (200) ou le serveur (300). Carte à puce. Une carte à puce comprend une antenne de communication, qui permet les échanges de données et d’énergie entre la puce de la carte et un serveur, via un lecteur. Typiquement, les échanges de données et d’énergie ont lieu soit hors ligne entre la carte à puce et un lecteur, soit en ligne entre la carte à puce et un serveur, via un lecteur. Une carte à puce est utilisée par exemple pour des applications bancaires, des applications identitaires, ou des applications sécuritaires, notamment les mots de passe à usage unique, dits « OTP » pour « One Time Password ». La présente invention concerne tous les types de carte à puce, c’est-à-dire quelle que soit l’application de celle-ci. Toutefois, par souci de concision, seul le cas d'une carte à puce pour application bancaire sera décrit ici, et dénommée ci-après « la carte », et chaque utilisation de la carte est appelée « transaction » quelle que soit l’application. Par « transaction », on entend un échange de données et d’énergie correspondant à une opération interactive préprogrammée, de forme « question-réponse » et qui inclue la recherche, l'introduction ou la modification d'informations dans un fichier ou dans une base de données. Également, la présente invention est limitée aux types de carte à puce qui comprennent une première puce, dite de transaction, qui permet d’établir une transaction avec le lecteur ou avec le serveur selon une norme de communication préétablie, et une deuxième puce, dite de calcul, montée en parallèle avec la puce de transaction. La puce de transaction est configurée pour pouvoir établir une communication avec un lecteur selon une norme de transaction avec le serveur. Par exemple dans le domaine bancaire, cette première puce est dite de paiement et permet d’effectuer des transactions bancaires selon une norme, typiquement la nome EMV (Europay Mastercard Visa, marques déposées). La puce de calcul est muette par défaut. Elle est configurée pour pouvoir accéder aux données analogiques ou numériques de la transaction émises par le lecteur à destination de la carte à puce, typiquement à destination de la puce de transaction. La puce de calcul est également configurée pour pouvoir effectuer un calcul à partir d’au moins une des données de la transaction émise par le lecteur, et émettre un signal dont la valeur est représentative du résultat dudit calcul. Par exemple dans le domaine bancaire, la puce de calcul permet de calculer et d’afficher un code dynamique, ou cryptogramme dynamique, dit DCVV pour Dynamic Card Validation Code sur un écran d’affichage de la carte à puce. Pour l’affichage du DCVV, ces cartes à puces comprennent un écran d’affichage, ou papier électronique, qui est relié électriquement à la puce de calcul. La deuxième puce est muette par défaut, c’est-à-dire que : elle ne communique pas avec la première puce ; elle « comprend » les commandes du serveur émises par le lecteur, c’est-à-dire qu’elle peut être activée en fonction d’une ou plusieurs commandes émises par le serveur, via le lecteur. Le serveur, lui, est configuré pour n’échanger qu’avec la première puce, les échanges comprenant typiquement un ensemble de questions/réponses. Comme le lecteur transfère les informations du serveur vers la carte et de la carte vers le serveur, par simplification, on entend indistinctement ici « lecteur » et « serveur ». A l’heure actuelle, pour que les échanges entre le serveur et la carte à puce soient sécurisé, le serveur est configuré pour ne communiquer qu’avec la première puce, et la deuxième puce est configurée par exemple pour calculer et afficher un code dynamique DCVV sur réception d’une instruction du serveur, et elle est limitée à cet usage. Pour sécuriser les échanges entre la carte et le serveur, le serveur comprend, pour une carte à puce donnée, une liste de codes dynamiques DCVV préétablis. Normalement, ce code dynamique change à chaque transaction. Pour qu’une transaction soit validée par le serveur, en particulier pour une transaction dite « carte absente » ou « sans présence de carte », plus connue sous l’acronyme anglais CNP pour « card not present », par exemple pour une transaction bancaire sur Internet, l’utilisateur de la carte doit saisir notamment le DCVV affiché sur la carte dont il est le porteur. Normalement, le DCVV affiché sur la carte doit être égal au DCVV du serveur. Toutefois, il peut arriver que la valeur du DCVV affiché sur la carte à puce ne change pas d’une transaction à l’autre. Or la valeur du DCVV sur le serveur change à chaque transaction. Dans ce cas, la valeur du DCVV du serveur est en avance par rapport à la valeur du DCVV affiché sur la carte à puce. Il arrive également que la valeur du DCVV affiché sur la carte à puce est incrémentée mais que la transaction n’aboutisse pas. Dans ce cas, la valeur du DCVV du serveur est en retard par rapport à la valeur du DCVV affiché sur la carte à puce. Par exemple, la FIG. 2 illustre un ensemble de positions tridimensionnelles de mesures pour lesquelles on mesure l’efficacité de la première puce et de la deuxième puce d’une carte à puce selon l’art antérieur. Le résultat de certaines au moins de ces mesures est illustré sur la FIG. 3 . Sur la FIG. 3 , la première colonne correspond à la position de la carte à puce sur la FIG. 2 , la deuxième colonne comprend la réponse OK/NOK de la première puce, et troisième colonne comprend la réponse OK/NOK de la deuxième puce. Si la réponse de la première puce est OK (transaction OK) et que la réponse de la deuxième puce est OK (transaction OK), alors le code de la base de données et le code DCVV de la carte à puce sont les mêmes. Si la réponse de la première puce est NOK (transaction non OK) et que la réponse de la deuxième puce est OK (transaction OK), alors le code de la base de données est en retard par rapport au code DCVV de la carte à puce. Si la réponse de la première puce est OK (transaction OK) mais que la réponse de la deuxième puce est NOK (transaction non OK), alors le code de la base de données est en avance par rapport au code DCVV de la carte à puce. Il existe donc parfois un problème de désynchronisation entre la valeur du DCVV affiché sur la carte et la valeur du DCVV correspondant du serveur. Pour pallier ce problème il est connu de mettre en œuvre une fenêtre de codes, comprenant un nombre prédéterminé de codes DCVV possibles attendus par le serveur. Typiquement, dans la liste préétablie de codes, si le code attendu est le code de rang N, alors le serveur peut néanmoins accepter, c’est à dire considérer comme valable, le code de rang N-1, N-2 ou N-3 ou le code de rang N+1, N+2 ou N+3, dans la liste préétablie de codes, et ainsi autoriser la transaction. La taille de la fenêtre [N-M ; N+M] avec M un entier naturel paramétrable. Dans le domaine bancaire, la banque détermine elle-même la valeur de M sur son serveur. Cependant, plus la valeur de M est grande, plus la transaction est vulnérable aux attaques. La présente invention permet de remédier à ce problème. A cet effet, la présente invention concerne une carte à puce (100), pour transaction hors ligne avec un lecteur (200), ou transaction en ligne avec un serveur (300) via un lecteur (200), la carte à puce (100) comprenant : • un corps de carte, • une première puce (110), dite de transaction, configurée pour pouvoir établir une transaction avec le lecteur (200) ou avec le serveur (300) selon une norme de communication préétablie, • une deuxième puce (120), dite de calcul, et qui est muette par défaut, qui est configurée pour pouvoir accéder aux données analogiques ou numériques de la transaction émises par le lecteur (200) ou le serveur (300), et configurée pour pouvoir effectuer un calcul à partir d’au moins une des données de la transaction émise par le lecteur (200) ou le serveur (300), et émettre un signal dont la valeur est représentative du résultat ; • un dispositif de communication configuré pour pouvoir transmettre ledit signal émis par la deuxième puce (120). Elle est essentiellement caractérisée en ce que : La deuxième puce (120) est configurée pour pouvoir sortir de son mode muet et émettre un ensemble d’au moins une requête de sabotage vers le serveur (300) ou vers le lecteur (200), une requête de sabotage étant une requête prédéterminée émise par la deuxième puce (120) et qui est : • soit reconnue comme telle par le lecteur (200) ou le serveur (300), • soit inattendue par le lecteur (200) ou le serveur (300), la réception de l’ensemble d’au moins une requête de sabotage par le lecteur (200) ou le serveur (300) sabotant la transaction entre la première puce (110) et le lecteur (200) ou le serveur (300). Grâce à l’invention, une requête de sabotage peut être émise éventuellement indistinctement du dispositif de communication. On peut prévoir un unique module (140), ledit module (140) comprenant la première puce (110) et la deuxième puce (120). On peut prévoir que la deuxième puce (120) est configurée pour : • Mesurer la valeur du courant ou de la tension à ses bornes, • Comparer la valeur du courant ou de la tension mesurée à une valeur seuil préenregistrée dans une mémoire, et • Si la valeur du courant ou de la tension mesurée est inférieure à la valeur seuil, • Alors émettre un ensemble d’au moins une requête de sabotage vers le serveur (300). Grâce à cette caractéristique, il est possible de saboter une transaction si le dispositif de communication n’est pas suffisamment alimenté en énergie électrique. On peut prévoir que la deuxième puce (120) est configurée pour inhiber l’émission du signal dont la valeur est représentative du résultat calculé par la deuxième puce (120). On peut prévoir que la deuxième puce (120) est configurée pour : • Détecter une réponse prédéterminée du serveur (300), • Compter le nombre de réponses prédéterminées successives, et • A chaque réponse prédéterminée ou si le nombre de réponses prédéterminées est supérieur à une valeur seuil préenregistrée dans une mémoire, • Alors émettre un ensemble d’au moins une requête de sabotage vers le serveur (300). Par exemple dans une transaction bancaire, la réponse prédéterminée est une requête R(NAK) ou S(WTX). On peut prévoir que la deuxième puce (120) est configurée pour : • Mesurer la valeur du courant ou de la tension à ses bornes, • Comparer la valeur du courant ou de la tension mesurée à une valeur seuil préenregistrée dans une mémoire, et • Si la valeur du courant ou de la tension mesurée est supérieure à la valeur seuil, Alors : • Déclencher un chronomètre ou un compteur si une réponse prédéterminée du serveur (300) est détectée, et • Si la transaction entre la première puce (110) et le serveur (300) ou le lecteur (200) est toujours en cours quand le chronomètre ou le compteur atteint une valeur seuil préenregistrée dans une mémoire, • Alors émettre un ensemble d’au moins une requête de sabotage vers le serveur (300). Par exemple pour une transaction dans le domaine bancaire, la réponse prédéterminée du serveur 300 est une requête GENERATE AC ou GPO. On peut prévoir que la deuxième puce (120) est configurée pour conserver en mémoire la valeur du signal calculé, et afficher cette valeur lors de la transaction suivante. On peut prévoir que le nombre de réponses prédéterminées successives est supérieur ou égal à 2. On peut prévoir que la première puce (110) et la deuxième puce (120) sont configurées pour des transactions dites « carte absente » (CNP). On peut prévoir que l’ensemble d’au moins une requête de sabotage de la transaction comprend une suite prédéterminée d’octets. La suite prédéterminée d’octets peut éventuellement être non conforme à une norme prédéterminée. D’autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante donnée à titre d’exemple illustratif et non limitatif et faite en référence aux figures annexées. FIG. 1 illustre un schéma électrique de principe pour une transaction entre un lecteur et une carte à puce selon l’art antérieur ou selon l’invention, FIG. 2 illustre un ensemble de positions dans l’espace, pour lesquelles on mesure l’efficacité de la première puce et de la deuxième puce d’une carte à puce selon l’art antérieur, FIG. 3 illustre le résultat de mesures d’efficacité de transactions pour des positions de la FIG. 2 , FIG. 4 illustre un chronogramme simplifié d’une transaction réussie dans le domaine bancaire, FIG. 5 illustre un chronogramme simplifié d’une transaction sabotée dans le domaine bancaire. Description détaillée La FIG. 1 illustre un schéma électrique de principe pour une transaction entre une carte à puce 100 selon l’invention et un serveur 300, via un lecteur 200. La carte à puce 100 comprend un corps de carte, une première puce 110 et une deuxième puce 120, indépendantes l’une de l’autre. De préférence, la première puce 110 et la deuxième puce 120 sont configurées pour des transactions dites « carte absente ». La première puce 110 est dite de transaction. Elle est configurée pour pouvoir établir une transaction selon une norme de communication préétablie. Par exemple dans le domaine bancaire, la norme est la norme dite EMV. La transaction peut être hors ligne avec un lecteur 200, ou en ligne avec un serveur 300 via un lecteur. La deuxième puce 120 est montée en parallèle avec la première puce 110. De manière connue, la deuxième puce 120 est muette par défaut. Elle est configurée pour pouvoir accéder aux données analogiques ou numériques de la transaction émises par le lecteur 200 ou le serveur 300, et configurée pour pouvoir effectuer un calcul à partir d’au moins une des données de transaction, et émettre un signal dont la valeur est représentative du résultat du calcul. La deuxième puce 120 « écoute » les requêtes du lecteur 200 et les réponses de la première puce 110 pour voir où en est la transaction. De préférence, la première puce 110 et la deuxième puce 120 sont comprises dans un module 140. La carte à puce 100 comprend également un dispositif de communication configuré pour pouvoir transmettre ledit signal calculé et émis par la deuxième puce 120. Par exemple le dispositif de communication peut être, comme exposé en début de description, un écran d’affichage, ou papier électronique, qui permet d’afficher un code dynamique (DCVV) calculé par la deuxième puce 120, ou encore un mot de passe à usage unique (OTP), le code dynamique DCVV ou le mot de passe à usage unique OTP étant le résultat du calcul. La carte à puce 100 peut également comprendre comme dispositif de communication un ensemble d’au moins une LED, ou un dispositif sonore, par exemple de type buzzer, et la deuxième puce 120 peut émettre un signal correspondant à l’activation sélective du dispositif de communication correspondant. Par exemple, si la carte à puce 100 est une carte d’abonnement, alors la deuxième puce 120 peut émettre un signal d’activation d’un dispositif de communication, le signal correspondant par exemple au nombre de voyages / d’entrées restant au crédit du porteur de la carte à puce 100 ou à une tranche de paiement, etc. De préférence, la carte à puce 100 comprend également un concentrateur 130, qui permet de concentrer l’énergie du lecteur 200 vers le module 140 de la carte à puce 100. On peut prévoir que la carte à puce 100 comprend un unique module 140, qui comprend la puce de transaction 110 et la puce de calcul 120. La deuxième puce 120 est configurée pour pouvoir sortir de son mode muet, c’est-à-dire qu’elle comprend un algorithme qui, en fonction de certains paramètres de sabotage exposés ultérieurement, commande à la puce de calcul 120 d’émettre un ensemble d’au moins une requête prédéterminée, dite de sabotage, exposée ultérieurement. L’ensemble d’au moins une requête de sabotage est émise vers le serveur 300 ou vers le lecteur 200. Une requête de sabotage est une requête prédéterminée, émise par la deuxième puce 120, et qui est reconnue comme telle par le lecteur 200 ou le serveur 300. Par exemple une requête de sabotage est une suite d’octets dont la valeur est prédéterminée, et par exemple toujours la même, reconnue dans le protocole de communication entre la carte à puce 100 et le lecteur 200 ou le serveur 300 comme une requête de sabotage. Une requête de sabotage peut également être une requête inattendue par le lecteur 200 ou le serveur 300. Par exemple une requête reconnue comme valable dans le protocole de communication mais qui n’est pas émise au moment opportun. A réception de l’ensemble d’au moins une requête de sabotage par le lecteur 200 ou le serveur 300, celui-ci sabote la transaction avec la première puce 110, par exemple en stoppant la transaction. Paramètres de sabotage Dans un mode de réalisation, on peut prévoir que la deuxième puce 120 est configurée pour mesurer la valeur du courant ou de la tension à ses bornes. Elle compare alors la valeur du courant ou de la tension mesurée à une valeur seuil préenregistrée dans une mémoire, et en fonction du résultat de la comparaison, elle reste silencieuse ou émet un ensemble d’au moins une requête de sabotage. Par exemple, si la valeur du courant ou de la tension mesurée est inférieure à la valeur seuil, alors on peut prévoir que la puce de calcul 120 sort de son mode muet et émet un ensemble d’au moins une requête de sabotage vers le serveur 300 ou vers le lecteur 200, avantageusement indépendamment des échanges aboutis ou non entre la première puce 110 et le lecteur 200 ou le serveur 300. Typiquement, cela signifie que la puce de calcul 120 n’a pas assez d’énergie pour aliment le dispositif de communication. Si la puce de calcul 120 n’a pas assez d’énergie pour alimenter le dispositif de communication, on peut aussi prévoir que celle-ci est configurée pour inhiber l’émission du signal dont la valeur est représentative du résultat calculé par la deuxième puce 120. En l’espèce la deuxième puce 120, qui est par défaut en mode muet, se réveille et émet une réponse vers le lecteur 200. L’émission de données par la deuxième puce 120 saborde la transaction car le lecteur 200 ou le serveur 300 reçoit ainsi des instructions non attendues. Dans ce cas, la deuxième puce 120 empêche l’incrément de la valeur du DCVV, et la valeur du DCVV affichée est conservée. Dans un exemple non limitatif, le dispositif de communication est un écran d’affichage de DCVV. Si l’énergie électrique n’est pas suffisante pour que le code DCVV soit affiché, alors l’affichage du code DCVV sur l’écran d’affichage de la carte à puce 100 peut être inhibé, ou la transaction peut être sabotée, ce qui évite de désynchroniser le code DCVV de la carte à puce 100 et le code DCVV du serveur 300. Dans un autre mode de réalisation, on peut prévoir que la deuxième puce 120 est configurée pour détecter une réponse prédéterminée du serveur 300, et compter le nombre de réponses prédéterminées successives. On peut ensuite prévoir qu’à chaque réponse prédéterminée ou si le nombre de réponses prédéterminées est supérieur à une valeur seuil préenregistrée dans une mémoire, alors la puce de calcul 120 émet un ensemble d’au moins une requête de sabotage vers le serveur 300 ou le lecteur 200. Par exemple dans le domaine des transactions bancaires, la réponse prédéterminée du serveur 300 peut être une réponse R(NAK) ou S(WTX). Par exemple au-delà de 2 réponses R(NAK) successives, émises par le serveur 300 ou le lecteur 200, la puce de calcul 120 émet un ensemble d’au moins une requête de sabotage. Dans un autre mode de réalisation, lorsque la deuxième puce 120 est configurée pour mesurer la valeur du courant ou de la tension à ses bornes et que la valeur du courant ou de la tension mesurée est supérieure à la valeur seuil, alors la deuxième puce 120 est configurée pour déclencher un chronomètre ou un compteur si une réponse prédéterminée du serveur 300 ou du lecteur 200 est détectée par celle-ci. Ensuite, si la transaction entre la première puce 110 et le serveur 300 est toujours en cours quand le chronomètre ou le compteur atteint une valeur seuil préenregistrée dans une mémoire, alors la deuxième puce 120 émet un ensemble d’au moins une requête de sabotage vers le serveur 300 ou le lecteur 200. Par exemple, dans le domaine bancaire, une réponse prédéterminée du serveur 300 ou du lecteur 200 peut être une requête GENERATE AC, ou GPO. Typiquement, en référence à la FIG. 4 , si la transaction entre la première puce 110 et le serveur 300 est toujours en cours, c’est-à-dire que la requête S(DESELECT) n’a pas encore été émise quand le chronomètre ou le compteur atteint une valeur seuil préenregistrée dans une mémoire, alors la deuxième puce 120 émet un ensemble d’au moins une requête de sabotage vers le serveur 300 ou le lecteur 200. L’exemple non limitatif suivant est donné à titre illustratif pour une transaction dans le domaine bancaire. Dans ce cas, le dispositif de communication de la carte à puce 100 est un écran d’affichage configuré pour pouvoir afficher un code dynamique DCVV. La valeur du DCVV calculée et affichée par la deuxième puce 120 n’est pas émise vers le lecteur 200 ni vers la première puce 110, mais uniquement vers l’écran d’affichage. De manière classique, une transaction EMV entre un lecteur 200 et une telle carte à puce 100 fonctionne de la manière suivante. Par concision, par « lecteur 200 » on entend dans toute la présente description « lecteur 200 ou serveur 300 ». A partir du début d’une transaction, il existe un échange de données entre le lecteur 200 et la carte à puce 100. Cet échange est normalisé. Comme illustré sur la FIG. 4 , les échanges de données entre le lecteur 200 et la carte à puce 100 sont représentés par les requêtes INIT et les réponses INIT_R. A ce stade (étape A), la tension ou la valeur du courant est mesurée aux bornes de la deuxième puce 120. Si cette valeur est inférieure à la valeur seuil, alors on peut prévoir que la deuxième puce 120 sort de son mode muet et émet un ensemble d’au moins une requête de sabotage vers le lecteur 200 (non illustré). Si cette valeur est supérieure à la valeur seuil, alors la transaction suit son cours. Lors de cet échange normalisé, le lecteur 200 envoie à la carte à puce 100 une commande prédéterminée, dite GPO pour Gate Processing Option , qui est une commande cryptographique normée, et qui est émise même pour les cartes à puce qui ne comprennent pas d’écran d’affichage d’un DCVV, et qui permet de chiffrer la suite des échanges entre la carte à puce 100 et le lecteur 200. En général la commande GPO est émise à environ 28 ms depuis le début de la transaction EMV. La réponse GPO_R est émise par la première puce 110. La commande GPO est un déclencheur pour la deuxième puce 120. A réception de cette commande GPO par la deuxième puce 120, illustrée par l’étape B sur la FIG. 4 , la deuxième puce 120 débute son calcul de la valeur DCVV à afficher sur l’écran d’affichage grâce à une valeur contenue dans cette commande GPO, par diversification cryptographique. De préférence, le compteur ou chronomètre est également déclenché. Au bout d’un certain temps, en l’espèce environ 200 ms après la réception de la commande GPO par la deuxième puce 120, la deuxième puce 120 a terminé son calcul de la valeur et affiche cette nouvelle valeur de DCVV sur l’écran d’affichage. Pendant que la deuxième puce 120 calcule la valeur du DCVV à afficher sur l’écran d’affichage, les échanges continuent entre le lecteur 200 et la première puce 110. La dernière étape de la transaction EMV consiste à émettre une commande prédéterminée « Generate AC » par le lecteur 200, à laquelle doit répondre la première puce 110. Il peut exister un certain nombre de requêtes et de réponses entre la réponse GPO_R et la requête Generate AC, elles ont volontairement été non référencées sur la FIG. 4 pour en simplifier la lecture. La réponse à cette requête Generate AC par la carte à puce 100 implique un calcul cryptographique lourd, qui consomme du courant et prend du temps. Si la transaction se passe normalement, alors la valeur du DCVV est affichée sur l’écran d’affichage, illustrée par l’étape C sur la FIG. 4 . Si la réponse de la carte à puce 100 est correcte, alors la transaction est approuvée, et terminée par le lecteur 200. La fin de la transaction EMV se termine par une sonorité, en général un bip, émis par le lecteur 200, suite à un échange entre une requête S(DESELECT) et la réponse correspondante S(DESELECT)_R par la première puce 110. La durée est en général au moins de 300 ms depuis le début de la transaction EMV. Si le calcul de la première puce 110 à la commande « Generate AC » est trop long, c’est-à-dire au-delà d’une durée prédéterminée, alors la première puce 110 peut émettre un ensemble d’au moins une commande prédéterminée « S(WTX) », qui déclare au lecteur 200 qu’elle a besoin d’un laps de temps supplémentaire, dont la durée est prédéterminée. La première puce 110 peut émettre une succession de commandes « S(WTX)_R ». Et le lecteur 200 répond S(WTX)_A à chaque commande « S(WTX) », comme illustré sur la FIG. 5 . En fonction du nombre de réponses prédéterminées successives, en l’espèce S(WTX) ou R(NAK), et comparaison de ce nombre de réponses successives à une valeur seuil, on peut prévoir d’émettre un ensemble d’au moins une requête de sabotage vers le lecteur 200, comme illustré par l’étape D sur la FIG. 5 . Il est possible que la valeur du DCVV à affichée sur l’écran d’affichage soit différente de celle attendue par le serveur 300 bancaire. La présente invention permet de limiter, voire de supprimer une telle désynchronisation. La première puce 110 consomme un courant différent en début de transaction et en fin de transaction. En fin de transaction, la consommation de courant de la première puce 110 est maximale à cause du calcul cryptographique lourd, suite à la commande « Generate AC ». On peut prévoir que si la première puce 110 est en limite, elle n’autorise pas la transaction. Or à ce stade, la deuxième puce 120 a modifié la valeur du DCVV affiché sur l’écran d’affichage de la carte à puce 100. Dans ce cas, la valeur du DCVV du serveur 300 bancaire est en retard par rapport à la valeur du DCVV affiché sur la carte à puce 100. Pour resynchroniser, la deuxième puce 120 détecte que la transaction précédente n’a pas abouti et dans ce cas lors de la transaction suivante, la deuxième puce 120 bloque l’incrémentation de la valeur du DCVV à afficher. Avantageusement, lors du sabotage d’une transaction, la valeur du DCVV calculée n’est pas enregistrée. Elle est donc recalculée lors de la transaction suivante. Avantageusement selon l’invention, la carte à puce 100 peut être exempte de batterie. Nomenclature 100 carte à puce 110 première puce 120 deuxième puce 130 concentrateur 140 module 200 lecteur 300 Serveur / base de données Carte à puce (100), pour transaction hors ligne avec un lecteur (200), ou transaction en ligne avec un serveur (300) via un lecteur (200), la carte à puce (100) comprenant : un corps de carte, une première puce (110), dite de transaction, configurée pour pouvoir établir une transaction avec le lecteur (200) ou avec le serveur (300) selon une norme de communication préétablie, une deuxième puce (120), dite de calcul, et qui est muette par défaut, qui est configurée pour pouvoir accéder aux données analogiques ou numériques de la transaction émises par le lecteur (200) ou le serveur (300), et configurée pour pouvoir effectuer un calcul à partir d’au moins une des données de la transaction émise par le lecteur (200) ou le serveur (300), et émettre un signal dont la valeur est représentative du résultat ; un dispositif de communication configuré pour pouvoir transmettre ledit signal émis par la deuxième puce (120), Caractérisée en ce que : La deuxième puce (120) est configurée pour pouvoir sortir de son mode muet et émettre un ensemble d’au moins une requête de sabotage vers le serveur (300) ou vers le lecteur (200), une requête de sabotage étant une requête prédéterminée émise par la deuxième puce (120) et qui est : soit reconnue comme telle par le lecteur (200) ou le serveur (300), soit inattendue par le lecteur (200) ou le serveur (300), la réception de l’ensemble d’au moins une requête de sabotage par le lecteur (200) ou le serveur (300) sabotant la transaction entre la première puce (110) et le lecteur (200) ou le serveur (300). Carte à puce (100) selon la revendication 1, comprenant un unique module (140), ledit module (140) comprenant la première puce (110) et la deuxième puce (120). Carte à puce (100) selon l'une quelconque des revendications précédentes, dans laquelle la deuxième puce (120) est configurée pour : Mesurer la valeur du courant ou de la tension à ses bornes, Comparer la valeur du courant ou de la tension mesurée à une valeur seuil préenregistrée dans une mémoire, et Si la valeur du courant ou de la tension mesurée est inférieure à la valeur seuil, Alors émettre un ensemble d’au moins une requête de sabotage vers le serveur (300). Carte à puce (100) selon la revendication 3, dans laquelle la deuxième puce (120) est configurée pour inhiber l’émission du signal dont la valeur est représentative du résultat calculé par la deuxième puce (120). Carte à puce (100) selon l'une quelconque des revendications précédentes, dans laquelle la deuxième puce (120) est configurée pour : Détecter une réponse prédéterminée du serveur (300), Compter le nombre de réponses prédéterminées successives, et A chaque réponse prédéterminée ou si le nombre de réponses prédéterminées est supérieur à une valeur seuil préenregistrée dans une mémoire, Alors émettre un ensemble d’au moins une requête de sabotage vers le serveur (300). Carte à puce (100) selon l'une quelconque des revendications précédentes, dans laquelle la deuxième puce (120) est configurée pour : Mesurer la valeur du courant ou de la tension à ses bornes, Comparer la valeur du courant ou de la tension mesurée à une valeur seuil préenregistrée dans une mémoire, et Si la valeur du courant ou de la tension mesurée est supérieure à la valeur seuil, Alors : Déclencher un chronomètre ou un compteur si une réponse prédéterminée du serveur (300) est détectée, et Si la transaction entre la première puce (110) et le serveur (300) ou le lecteur (200) est toujours en cours quand le chronomètre ou le compteur atteint une valeur seuil préenregistrée dans une mémoire, Alors émettre un ensemble d’au moins une requête de sabotage vers le serveur (300). Carte à puce (100) selon la revendication 5 ou 6, dans laquelle la deuxième puce (120) est configurée pour conserver en mémoire la valeur du signal calculé, et afficher cette valeur lors de la transaction suivante. Carte à puce (100) selon l'une quelconque des revendications 5 à 7, dans laquelle le nombre de réponses prédéterminées successives est supérieur ou égal à 2. Carte à puce (100) selon l'une quelconque des revendications précédentes, dans laquelle la première puce (110) et la deuxième puce (120) sont configurées pour des transactions dites « carte absente » (CNP). Carte à puce (100) selon l'une quelconque des revendications précédentes, dans laquelle l’ensemble d’au moins une requête de sabotage de la transaction comprend une suite prédéterminée d’octets.