FR 3142818 A1 20240607 FR 2212834 A 20221206 La présente invention concerne un procédé de protection d’un terminal (1) comprenant des moyens de traitement de données (11), une batterie (15) et une jauge de batterie (16) fournissant aux moyens de traitement de données (11) des données descriptives de l’état de la batterie (15), contre une attaque par canal auxiliaire utilisant lesdites données descriptives de l’état de la batterie (15), le procédé étant caractérisé en ce qu’il comprend la mise en œuvre par les moyens de traitement de données (11) d’étapes de : Lorsque ledit terminal (1) est susceptible de subir ladite attaque, contrôle d’au moins un composant énergivore (11, 12, 13, 14) du terminal (1) de sorte à modifier les données descriptives de l’état de la batterie (15) fournies par la jauge de batterie (16). Fig 3. Procédé de protection d’un terminal contre une attaque par canal auxiliaire DOMAINE TECHNIQUE GÉNÉRAL La présente invention se rapporte au domaine de la sécurité informatique. Plus précisément, elle concerne un procédé de protection d’un terminal contre une attaque par canal auxiliaire. ETAT DE L’ART Les terminaux mobiles de type smartphone stockent aujourd’hui de nombreuses données personnelles d’utilisateurs, et sont utilisés pour des opérations sensibles telles que des transactions. Leur sécurisation est ainsi une nécessité, et les tentatives d’attaques pour compromettre leur contenu sont toujours plus nombreuses. On appelle attaque par canal auxiliaire (en anglais « Side-channel attack », SCA) une attaque informatique qui, sans remettre en cause la robustesse théorique des méthodes et procédures de sécurité, recherche et exploite des failles dans leur implémentation, logicielle ou matérielle. Plus précisément, alors qu’un algorithme peut être parfaitement sécurisé mathématiquement, des failles liées au matériel peuvent néanmoins apparaître lors de l'utilisation en « pratique », et permettre par exemple l’obtention d’une information secrète comme un code d’authentification de l’utilisateur. L’exemple typique est l’injection de fautes, c’est-à-dire l’introduction volontaire d’erreurs dans le système pour provoquer certains comportements révélateurs. Plus récemment, les attaques acoustiques ou de consommation consistent en l’étude soit du bruit généré par le processeur (il émet du bruit qui varie en intensité et en nature selon sa consommation), soit directement de sa consommation électrique pour donner des renseignements sur le code. En effet, chaque instruction réalisée par un microprocesseur met en œuvre un certain nombre de transistors. À chaque instant, la mesure du courant consommé peut refléter l'activité du microprocesseur. Certaines opérations, plus coûteuses, augmentent donc la consommation électrique, de sorte qu’on peut notamment distinguer des différences entre des codes valides et invalides. Les attaques par canal auxiliaire sont nombreuses et variées, difficiles à prévoir, et il est ainsi souhaitable de les rendre impossible. L’invention vient améliorer la situation PRÉSENTATION DE L’INVENTION La présente invention se rapporte donc selon un premier aspect à un procédé de protection d’un terminal comprenant des moyens de traitement de données, une batterie et une jauge de batterie fournissant aux moyens de traitement de données des données descriptives de l’état de la batterie, contre une attaque par canal auxiliaire utilisant lesdites données descriptives de l’état de la batterie, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre par les moyens de traitement de données d’étapes de : Lorsque ledit terminal est susceptible de subir ladite attaque, contrôle d’au moins un composant énergivore du terminal de sorte à modifier les données descriptives de l’état de la batterie fournies par la jauge de batterie. Selon des caractéristiques avantageuses et non-limitatives : Ledit composant énergivore est un vibreur. Le procédé comprend une étape (a) de requête de saisie d’un code sur une interface du terminal, l’étape (b) étant mise en œuvre pendant la saisie dudit code par un utilisateur sur ladite interface. Les moyens de traitement de données sont configurés pour activer ledit vibreur à chaque saisie d’un caractère dudit code sur l’interface. A l’étape (b), ledit composant énergivore du terminal est contrôlé soit pour être activé au moins une fois de manière factice, soit pour être temporairement désactivé. A l’étape (b), soit ledit vibreur ou un autre composant énergivore du terminal est contrôlé pour être activé de manière factice hors d’une saisie d’un caractère dudit code sur l’interface, soit ledit vibreur est contrôlé pour ne pas être activé lors de la saisie d’au moins un caractère dudit code sur l’interface. Le procédé comprend une étape (c) de détection de si ladite attaque est tentée sur la base des données descriptives de l’état de la batterie modifiées suite à l’étape (b). L’étape (b) simule la mise en œuvre d’un processus cible sur le terminal en contrôlant le composant énergivore de sorte à obtenir les mêmes données descriptives de l’état de la batterie que celles qu’on aurait pour ledit processus cible. Le processus cible est la saisie d’un code sur une interface du terminal. Le procédé comprend une étape (d) de mise en œuvre d’une mesure de riposte en fonction du résultat de l’étape (c). Ladite mesure de riposte comprend un blocage logiciel des données descriptives de l’état de la batterie fournies par la jauge de batterie. Selon un deuxième aspect, l’invention concerne un terminal comprenant des moyens de traitement de données, au moins un composant énergivore, une batterie et une jauge de batterie fournissant aux moyens de traitement de données des données descriptives de l’état de la batterie, les moyens de traitement de données étant configurés pour : Lorsque ledit terminal est susceptible de subir une attaque par canal auxiliaire utilisant lesdites données descriptives de l’état de la batterie, contrôler ledit composant énergivore de sorte à modifier les données descriptives de l’état de la batterie fournies par la jauge de batterie. Selon un troisième et un quatrième aspect, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect de protection d’un terminal comprenant des moyens de traitement de données, une batterie et une jauge de batterie fournissant aux moyens de traitement de données des données descriptives de l’état de la batterie, contre une attaque par canal auxiliaire utilisant lesdites données descriptives de l’état de la batterie ; et un moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect de protection d’un terminal comprenant des moyens de traitement de données, une batterie et une jauge de batterie fournissant aux moyens de traitement de données des données descriptives de l’état de la batterie, contre une attaque par canal auxiliaire utilisant lesdites données descriptives de l’état de la batterie. PRÉSENTATION DES FIGURES D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : la représente un exemple de terminal mobile à jauge de batterie ; la illustre une attaque par canal auxiliaire utilisant les données descriptives de l’état de la batterie ; la est un schéma d’un système pour la mise en œuvre du procédé selon l’invention ; la est un logigramme illustrant les étapes d’un mode de réalisation du procédé selon l’invention. DESCRIPTION DÉTAILLÉE Nouvelle attaque Les inventeurs ont découvert que les progrès des terminaux mobiles sur batterie tels que les smartphones rendent possible un nouveau type d’attaque par canal auxiliaire par analyse de la consommation électrique (qui n’a cependant pas grand-chose à voir avec les attaques connues de ce type). Cela est paradoxal car la recherche continue d’amélioration de l’autonomie de ces terminaux a conduit à augmenter l’efficacité énergétique des composants électroniques (pour baisser la consommation) à un point tel que les variations de consommation devenaient presque imperceptibles, et donc les attaques par analyse de la consommation bien plus complexes. Cependant, pour optimiser les cycles de charge et décharge des batteries (et éviter la baisse de leur capacité), on a rendu ces batteries intelligentes en ajoutant aux terminaux des composants clé en main (i.e. avec leurs propres moyens de traitement de données, de type microcontrôleur) dédiés au contrôle du niveau de charge restante (dit SoC, « state of charge »), appelés « fuel gauge », par analogie avec les jauges de carburant des véhicules. En français, on emploiera le terme de « jauge de batterie », même si le terme « fuel gauge » est celui communément utilisé par l’homme du métier même en français. En référence à la , de manière classique on a représenté dans un terminal 1 des moyens de traitement de données 11 (par exemple un processeur), la batterie 15 et la jauge de batterie 16. On voit que la jauge de batterie 16 est montée de sorte que : La jauge 16 est connectée aux bornes de la batterie 15 ; Les moyens 11 (et de façon générale les composants du terminal 1) sont alimentés via la jauge 16 ; Des données sont échangées entre la jauge 15 et les moyens de traitement de données via un bus informatique (tel que I2C). La jauge 16 est configurée pour acquérir en continu les données descriptives de l’état de la batterie 15 (en général courant, tension à ses bornes, niveau de charge restant et souvent température) et communiquer ces informations aux moyen de traitement de données 11 via ledit bus. Toutes ces données peuvent être mesurées et/ou calculées, à ce titre la jauge 15 pourra utiliser toute technique de déduction de la capacité de la batterie connue telle que basée sur la mesure de la tension (en estimant la résistance interne et en appliquant la courbe de décharge), ou bien sur la mesure de la charge entrante et sortante en modélisant l’auto-décharge en fonction de la température (technique dite du « compteur de Coulomb »). De manière particulièrement performante la jauge de batterie 16 peut d’ailleurs combiner les deux techniques : la mesure de la tension est effectuée quand la batterie 15 n’est pas soumise à une charge ; et la mesure du courant est effectuée quand la batterie 15 reçoit ou délivre de l’énergie. Ainsi, la tension de la batterie est utilisée pour mettre à jour son état de charge actuel d’après la courbe d’évolution de sa tension fonction de sa capacité restante. Ensuite, lorsqu’une charge lui est appliquée, la méthode du compteur de Coulomb est utilisée pour mesurer l’énergie entrante et sortante du système. En utilisant les deux mesures de tension et celle des charges, la capacité maximale de la batterie peut être estimé. La résistance interne de la batterie peut, elle aussi, être calculé en utilisant le courant mesuré, et les deux tensions de batterie avec et sans charge. Ainsi, avec la capacité maximale de la batterie et sa résistance interne, une valeur précise de la capacité restante peut être obtenue. Sur les terminaux 1 dotés d’un système d’exploitation (OS), ce dernier peut choisir ou non de laisser les informations remontées par la jauge de batterie 16 (données descriptives de l’état de la batterie 15) accessibles aux applications. À titre d’exemple, sur un environnement Android, ces données peuvent être activement relayées sous demande d’une application, sans permission nécessaire. Les inventeurs ont constaté que cette fonctionnalité représente un risque de sécurité, susceptible d’ouvrir le champ à une nouvelle attaque par canal auxiliaire. En effet, chaque application se voit en fait octroyer des droits en lecture (puisque les requêtes sont relayées par l’OS) mais également en écriture (puisqu’en déclenchant une utilisation plus ou moins intensives de divers composants, l’application influence de facto la métrique mesurée par ces capteurs) ! Des tests ont montré qu’en utilisant une application malicieuse développée à dessein, l’attaquant était en mesure de retrouver un code PIN entré par un utilisateur, malgré l’isolation logicielle entre applications proposée par le système d’exploitation. Sur la , les pics du haut représentent l’interception de touchers sur le clavier numérique sur la base des données de la jauge de batterie 16. Il est à noter que la plupart des téléphones, dans leur configuration en sortie d’usine, activent le vibreur à chaque toucher, rendant la détection malicieuse encore plus aisée. Une fois que l’on a récolté ces données, on peut mener une analyse temporelle. En effet, connaissant la disposition du clavier, on peut exploiter les contraintes qu’il implique, et la distance entre toutes les touches. Un simple script donne, pour une suite de durées entre les touchers, l’ensemble des codes PIN possibles, qu’on peut même réduire en utilisant des données gyroscopiques avec des postulats simples (exemple : on sait qu’une personne droitière va faire un mouvement caractéristique pour toucher le 1 du clavier avec son pouce, car c’est la touche la plus éloignée de ce dernier). On comprendra que la présente nouvelle attaque par canal auxiliaire utilisant les données descriptives de l’état de la batterie 15 fournies par la jauge 16 n’a pas grand-chose à voir avec les attaques connues par analyse de la consommation des moyens de traitement de données 11 : La nouvelle attaque ne cherche pas à distinguer des opérations du processeur, mais directement à détecter des actions particulières de l’utilisateur par leur impact sur la batterie ; La nouvelle attaque permet en théorie d’obtenir directement une ou plusieurs codes probables, et non juste de savoir si un code saisi est correct ou pas. Procédé La présente invention concerne un procédé de protection d’un terminal 1 contre la nouvelle attaque par canal auxiliaire qu’on vient de décrire, qui exploiterait les données de la jauge de batterie 16. En référence à la , le terminal 1 comprend à ce titre : les moyens de traitement de données 11, généralement des moyens de stockage de données 12 (une batterie), une interface 13 tel qu’un écran tactile apte à afficher un clavier virtuel et/ou un clavier physique une batterie 15, alimentant au moins les moyens de traitement de données 11 (et en pratique tout le terminal 1 – on note que le terminal 1 peut en général être branché au secteur pour recharger la batterie 15, mais en pratique le terminal est toujours alimenté par la batterie 15, et ainsi le terminal 1 est dit « à batterie ») ; une jauge de batterie 16 fournissant aux moyens de traitement de données 11 des données descriptives de l’état de la batterie 15, on rappelle que ces données peuvent être une tension aux bornes de la batterie 15 (en V), un courant (en A) et/ou une charge restante de la batterie 15 (en Ah). Le terminal 1 est typiquement un terminal mobile tel qu’un smartphone, une tablette tactile, mais également un TPE, ou tout périphérique sur batterie En outre, le terminal 1 comprend au moins un « composant énergivore » 11, 12, 13, 14, également alimenté par la batterie. Par composant énergivore, on entend un composant ayant, lorsqu’il est activé, une consommation significative, c’est-à-dire ayant sur la batterie 15 un impact détectable par la jauge de batterie 16. Pour reformuler encore, la consommation (en mAh, ou plutôt µAh) d’une activation dudit composant énergivore est supérieure à un seuil de détection prédéfini. Ledit composant énergivore 11, 12, 13, 14 peut être les moyens de traitement 11, les moyens de stockage de données 12, l’interface 13, mais également un vibreur 14 du terminal 1. On est typiquement dans un contexte à clavier virtuel dans lequel les moyens de traitement de données 11 sont configurés pour activer ledit vibreur 14 à chaque saisie d’un caractère sur l’interface 13 (i.e. à chaque qu’on touche le clavier virtuel). En effet, cela permet un « retour haptique » dans lequel l’utilisateur à la sensation d’utiliser un vrai clavier. Alternativement, le composant énergivore pourrait être un haut-parleur, une antenne, une caméra, un flash, une puce GPS, etc. A noter que le terminal 1 peut être connecté par exemple via un réseau 10 tel que internet à un serveur 2 centralisant la lutte contre l’attaque par canal auxiliaire. En référence à la , le présent procédé, mis en œuvre par les moyens de traitement de données 11 du terminal 1, comprend principalement une étape (b), mise en œuvre lorsque ledit terminal 1 est susceptible de subir ladite attaque par canal auxiliaire, de contrôle d’au moins un composant énergivore 11, 12, 13, 14 du terminal 1 de sorte à modifier les données descriptives de l’état de la batterie 15 fournies par la jauge de batterie 16. Le critère « lorsque ledit terminal 1 est susceptible de subir ladite attaque par canal auxiliaire » correspond typiquement : soit à un contexte d’attaque identifié, par exemple le serveur 2 peut avertir le terminal 1 qu’il a détecté une activité suspecte ; soit une utilisation du terminal 1 sensible, en particulier la saisie d’un code sur l’interface 13 par exemple pour mettre en œuvre une transaction, accéder à des données personnelles, etc. On prendre l’exemple de ce dernier cas, et alors le procédé commence par une étape (a) de requête de saisie du code sur l’interface 13, et ledit contrôle du composant énergivore 11, 12, 13, 14 du terminal 1 de sorte à modifier les données descriptives de l’état de la batterie 15 fournies par la jauge de batterie 16 est mis en œuvre pendant la saisie dudit code par un utilisateur sur ladite interface 13 (i.e. dans ce cas « Lorsque ledit terminal 1 est susceptible de subir ladite attaque » = « pendant la saisie du code »). On note que si les moyens de traitement de données 11 sont configurés pour activer ledit vibreur 14 à chaque saisie d’un caractère sur l’interface 13, on est sensé avoir une activation du vibreur 14 à chaque saisie d’un caractère du code, ce qui rend aisée l’attaque par canal auxiliaire puisque c’est un composant énergivore. Par contrôle du composant énergivore 11, 12, 13, 14, on entend une utilisation « imprévisible » de ce composant qui va modifier sa consommation et donc perturber les données descriptives de l’état de la batterie 15. Pour reformuler, la jauge de batterie 16 va continuer de remonter les données descriptives de l’état de la batterie 15, mais celles-ci auront été « brouillées » par le composant énergivore et rendues inexploitables pour l’attaque par canal auxiliaire, qui va donc échouer. En particulier, le composant énergétique est contrôlé : soit pour être activé au moins une fois de manière factice (i.e. il est activé pour rien, à un instant où il n’aurait pas dû être activé, pour créer une consommation parasite), soit pour être temporairement désactivé (i.e. il n’est pas activé, à un instant où il aurait dû l’être, pour créer une sous-consommation parasite). A noter que de manière préférée, le contrôle de ce composant est tel que le fonctionnement général du terminal 1, et donc l’expérience utilisateur, ne sont pas perturbés. De plus il est préférentiellement aléatoire pour éviter qu’un attaquant ne puisse prévoir la perturbation et en tenir compte. Dans l’exemple préféré de la saisie d’un code, le vibreur 14 est ainsi contrôlé : soit pour être activé de manière factice hors d’une saisie d’un caractère dudit code sur l’interface 13 (i.e. il crée une consommation parasite et simule une saisie de touche inexistante), à noter qu’un autre composant énergivore 11, 12, 13 peut être utilisé à la place du vibreur 14 pour créer ladite consommation parasite, soit pour ne pas être activé lors de la saisie d’au moins un caractère dudit code sur l’interface 13 (i.e. il occulte une saisie de touche réelle). De manière préférée, on a au moins, sur la saisie du code : une activation légitime du vibreur 14 (lors de la saisie d’un caractère du code) ; une activation factice du vibreur 14 (hors de toute saisie d’un caractère du code) une absence d’activation légitime du vibreur 14 (lors de la saisie d’un caractère du code). Alternativement au vibreur 14, on peut avoir les contrôles suivants de composants énergivores : la mise en œuvre d’un opération factice sur les moyens de traitement de données 11 ; une écriture mémoire factice (en particulier si les moyens 12 sont un disque dur) ; un affichage factice (ou une absence d’affichage) sur l’interface 13 ; une émission de son par le haut-parleur à fort volume mais à une fréquence inaudible ou presque telle que 5Hz. Modes diagnostic ou provocation Dans un autre mode de réalisation, on cherche à prévenir l’attaque par canal auxiliaire, soit en vérifiant à quel point le terminal 1 est vulnérable, soit en incitant carrément l’attaquant à agir pour le débusquer (technique de défense active dite honeypot). Pour ce faire, l’étape (b) simule la mise en œuvre d’un processus cible sur le terminal 1 en contrôlant le composant énergivore 11, 12, 13, 14 de sorte à obtenir le même profil de consommation (les mêmes données descriptives de l’état de la batterie 15) que celui qu’on aurait sur ledit processus cible. Typiquement, le processus cible est la saisie d’un code sur une interface 13 du terminal 1, de sorte qu’on simule ladite saisie du code, par exemple en activant le vibreur 14 de manière à reproduire la séquence qu’on obtiendrait lors de la saisie d’un code leurre. On peut alors voir s’il est facile de retrouver le code leurre à partir des données descriptives de l’état de la batterie 15 modifiées (par l’activation du vibreur 14) fournies par la jauge de batterie 16 (ce qui trahirait une vulnérabilité – on peut simplement alerter l’utilisateur, ou mettre en place diverses vérifications (réponses aux requêtes, à quelle fréquence, avec quelle précision…) afin d’obtenir un bilan des risques encourus, et ces résultats peuvent être présentés à l’utilisateur ou utilisés par une solution logicielle sensible pour mieux évaluer son environnement), voire mettre en œuvre une étape (c) de détection de si ladite attaque est tentée sur la base des données descriptives de l’état de la batterie 15 modifiées suite à l’étape (b). Cette manière de procéder ouvre la possibilité de piéger un attaquant, en regardant s’il y a une tentative d’utilisation du code leurre plus tard, on peut déterminer que le système est sous attaque, ou sous surveillance active, et agir en conséquence. A ce titre, le procédé peut comprendre une étape (d) de mise en œuvre d’une mesure de riposte en fonction du résultat de l’étape (c), qui peut aller de la simple alerte à l’utilisateur, à la tentative d’identification et de neutralisation de l’attaquant, en passant par le blocage logiciel complet (au moins temporairement) des données descriptives de l’état de la batterie 15 fournies par la jauge de batterie 16 (i.e. les moyens de traitement de données 11 empêchent les autre applications d’y avoir accès). Cela risque temporairement de nuire à l’autonomie de la batterie (car les applications ne pourront plus optimiser finement la consommation énergétique), mais le risque d’attaque réelle sera écarté. Terminal Selon un deuxième aspect, l’invention concerne le terminal 1 pour la mise en œuvre du procédé selon le premier aspect. Ainsi, ce terminal 1 comprend comme expliqué des moyens de traitement de données 11, au moins un composant énergivore 11, 12, 13, 14 (typiquement un vibreur 14), une batterie 15 et une jauge de batterie 16 fournissant aux moyens de traitement de données 11 des données descriptives de l’état de la batterie 15. Il peut en outre comprendre des moyens de stockage de données 12, une interface 13, etc. Les moyens de traitement de données 11 sont configurés pour mettre en œuvre des étapes visant à protéger le terminal 1 contre une attaque une attaque par canal auxiliaire utilisant lesdites données descriptives de l’état de la batterie 15, ces étapes consistant à : Lorsque ledit terminal 1 est susceptible de subir une telle attaque par canal auxiliaire utilisant lesdites données descriptives de l’état de la batterie 15 (par exemple lors de la saisie d’un code sur l’interface 13), contrôler ledit composant énergivore 11, 12, 13, 14 de sorte à modifier les données descriptives de l’état de la batterie 15 fournies par la jauge de batterie 16 ; Le cas échéant détecter si ladite attaque est tentée sur la base des données descriptives de l’état de la batterie 15 modifiées ; voire mettre en œuvre d’une mesure de riposte en fonction du résultat de la détection. Produit programme d’ordinateur Selon un quatrième et un cinquième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution (sur les moyens de traitement de donnés 11 du terminal 1) d’un procédé selon le premier aspect de protection du terminal 1 contre une attaque par canal auxiliaire utilisant lesdites données descriptives de l’état de la batterie 15 fournies par la jauge de batterie 16, ainsi que des moyens de stockage lisibles par un équipement informatique (par exemple les moyens de stockage de données 12 du terminal) sur lequel on trouve ce produit programme d’ordinateur. Procédé de protection d’un terminal (1) comprenant des moyens de traitement de données (11), une batterie (15) et une jauge de batterie (16) fournissant aux moyens de traitement de données (11) des données descriptives de l’état de la batterie (15), contre une attaque par canal auxiliaire utilisant lesdites données descriptives de l’état de la batterie (15), le procédé étant caractérisé en ce qu’il comprend la mise en œuvre par les moyens de traitement de données (11) d’étapes de : Lorsque ledit terminal (1) est susceptible de subir ladite attaque, contrôle d’au moins un composant énergivore (11, 12, 13, 14) du terminal (1) de sorte à modifier les données descriptives de l’état de la batterie (15) fournies par la jauge de batterie (16). Procédé selon la revendication 1, dans lequel ledit composant énergivore est un vibreur (14). Procédé selon l’une des revendications 1 et 3, comprenant une étape (a) de requête de saisie d’un code sur une interface (13) du terminal (1), l’étape (b) étant mise en œuvre pendant la saisie dudit code par un utilisateur sur ladite interface (13). Procédé selon les revendications 2 et 3 en combinaison, dans lequel les moyens de traitement de données (11) sont configurés pour activer ledit vibreur (14) à chaque saisie d’un caractère dudit code sur l’interface (13). Procédé selon l’une des revendications 1 à 4, dans lequel à l’étape (b), ledit composant énergivore (11, 12, 13, 14) du terminal (1) est contrôlé soit pour être activé au moins une fois de manière factice, soit pour être temporairement désactivé. Procédé selon les revendications 4 et 5 en combinaison, dans lequel à l’étape (b), soit ledit vibreur (14) ou un autre composant énergivore (11, 12, 13) du terminal (1) est contrôlé pour être activé de manière factice hors d’une saisie d’un caractère dudit code sur l’interface (13), soit ledit vibreur (14) est contrôlé pour ne pas être activé lors de la saisie d’au moins un caractère dudit code sur l’interface (13). Procédé selon l’une des revendications 1 à 6, comprenant une étape (c) de détection de si ladite attaque est tentée sur la base des données descriptives de l’état de la batterie (15) modifiées suite à l’étape (b). Procédé selon la revendication 7, l’étape (b) simulant la mise en œuvre d’un processus cible sur le terminal (1) en contrôlant le composant énergivore (11, 12, 13, 14) de sorte à obtenir les mêmes données descriptives de l’état de la batterie (15) que celles qu’on aurait pour ledit processus cible. Procédé selon la revendication 8, dans lequel le processus cible est la saisie d’un code sur une interface (13) du terminal (1). Procédé selon l’une des revendications 7 à 9, comprenant une étape (d) de mise en œuvre d’une mesure de riposte en fonction du résultat de l’étape (c). Procédé selon la revendication 10, dans lequel ladite mesure de riposte comprend un blocage logiciel des données descriptives de l’état de la batterie (15) fournies par la jauge de batterie (16). Terminal (1) comprenant des moyens de traitement de données (11), au moins un composant énergivore (11, 12, 13, 14), une batterie (15) et une jauge de batterie (16) fournissant aux moyens de traitement de données (11) des données descriptives de l’état de la batterie (15), les moyens de traitement de données (11) étant configurés pour : Lorsque ledit terminal (1) est susceptible de subir une attaque par canal auxiliaire utilisant lesdites données descriptives de l’état de la batterie (15), contrôler ledit composant énergivore (11, 12, 13, 14) de sorte à modifier les données descriptives de l’état de la batterie (15) fournies par la jauge de batterie (16). Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 11 de protection d’un terminal (1) comprenant des moyens de traitement de données (11), une batterie (15) et une jauge de batterie (16) fournissant aux moyens de traitement de données (11) des données descriptives de l’état de la batterie (15), contre une attaque par canal auxiliaire utilisant lesdites données descriptives de l’état de la batterie (15), lorsque ledit programme est exécuté sur un ordinateur. Moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 11 de protection d’un terminal (1) comprenant des moyens de traitement de données (11), une batterie (15) et une jauge de batterie (16) fournissant aux moyens de traitement de données (11) des données descriptives de l’état de la batterie (15), contre une attaque par canal auxiliaire utilisant lesdites données descriptives de l’état de la batterie (15).