Attaques par canaux auxiliaires et secrets

Un canal auxiliaire ne casse pas directement l’algorithme cryptographique : il exploite ce que le calcul laisse échapper autour de lui. Temps de réponse, consommation électrique, émissions électromagnétiques ou comportement mémoire peuvent suffire à reconstruire une information que le résultat officiel ne révèle jamais.

→ Lire l’explication complète de la marmotte

Canaux auxiliaires : la fuite est dans l’exécution

Le compromis central est brutal : optimiser un calcul selon les données traitées améliore parfois la performance, mais transforme le comportement de la machine en signal exploitable. Pour les opérations qui touchent un secret, la recommandation est nette : préférer un coût prévisible à une optimisation conditionnelle. Quelques nanosecondes économisées ne compensent pas une clé récupérable.

Une attaque temporelle observe une durée qui dépend d’une donnée secrète. Le cas scolaire reste la comparaison de chaînes qui renvoie false dès le premier caractère différent. Si chaque caractère correct ajoute une opération, la latence moyenne augmente avec la longueur du préfixe deviné. À distance, le réseau ajoute du bruit, mais le bruit se moyenne. Un attaquant peut répéter les requêtes, éliminer les valeurs aberrantes, comparer les distributions et progresser caractère par caractère.

Les canaux de puissance visent plutôt les équipements physiques. Pendant un chiffrement avec une clé symétrique, la consommation électrique d’une puce varie selon les opérations exécutées et les bits manipulés. L’analyse différentielle de consommation, ou DPA (Differential Power Analysis), corrèle des milliers de traces électriques avec des hypothèses sur des fragments de clé. Une primitive cryptographique correcte reste correcte, mais son implémentation parle trop fort.

Les émissions électromagnétiques suivent le même principe. Un capteur proche d’un composant peut mesurer les champs émis pendant le traitement. L’attaque dépend de la distance, du blindage, de la fréquence du signal et de la qualité de synchronisation. Elle n’exige pas forcément un contact électrique. Le folklore du pirate qui lit une clé depuis le parking mérite moins de films, mais il existe des laboratoires, des sondes et des bancs de mesure pour cela.

Le sujet appartient à la cryptographie appliquée, pas à la magie noire. Une clé de 256 bits ne protège pas contre une implémentation qui laisse filtrer chacun de ses bits. La force théorique d’une protection doit donc être évaluée avec son environnement d’exécution, comme détaillé dans l’évaluation de la force d’une protection.

Attaque temporelle contre une comparaison de secret

Une comparaison vulnérable ressemble souvent à ceci : parcourir deux valeurs, arrêter au premier octet différent, retourner immédiatement l’échec. Pour une valeur candidate Axxx comparée au secret Abcd, un octet est validé avant l’arrêt. Pour Abxx, deux octets le sont. La différence peut être faible, mais elle est systématique si le chemin d’exécution diffère.

L’attaquant distant choisit un alphabet de candidats, teste chaque caractère possible à une position donnée, répète chaque requête un nombre élevé de fois, puis conserve la valeur avec la latence médiane ou moyenne la plus haute. Il recommence à la position suivante. La médiane résiste mieux aux pics occasionnels que la moyenne, notamment quand un ordonnanceur décide de faire de la poésie avec les délais.

Cette attaque devient réaliste lorsque plusieurs conditions sont réunies :

le secret est stable sur une période suffisante ;
le point d’entrée accepte de nombreuses tentatives ;
la réponse dépend de la comparaison avant toute opération coûteuse ou aléatoire ;
les mesures peuvent être répétées depuis une position réseau relativement stable ;
l’attaquant peut distinguer les échecs sans déclencher un verrouillage.

Un jeton d’interface de programmation, un secret de webhook ou une signature de requête sont des cibles fréquentes. Un mot de passe vérifié après une fonction de dérivation lente, telle qu’Argon2, est moins favorable à cette attaque, car le coût dominant masque souvent la comparaison. Cela ne dispense pas d’une comparaison à temps constant : un correctif qui dépend du hasard de la charge système n’est pas un correctif.

La limitation de débit réduit le nombre de mesures disponibles et doit exister, mais elle ne ferme pas la fuite. Ajouter un délai aléatoire ne la ferme pas non plus : du bruit indépendant disparaît avec davantage d’échantillons. Ajouter une attente fixe après une comparaison variable échoue aussi si le délai ne couvre pas strictement tous les chemins. La sécurité par gigue aléatoire est une loterie où l’attaquant achète davantage de tickets.

Exemple reproductible de comparaison à temps constant

En Python, hmac.compare_digest fournit une comparaison conçue pour éviter l’arrêt précoce lorsque les deux entrées ont le même type et la même longueur. Le test local suivant rend visible la différence de structure, sans prétendre reproduire fidèlement un réseau ou une puce.

import hmac
import time

SECRET = b"tortue-tech-secret"

def comparaison_vulnerable(candidate: bytes) -> bool:
    # Arrêt dès le premier octet différent : fuite de progression.
    if len(candidate) != len(SECRET):
        return False
    for attendu, recu in zip(SECRET, candidate):
        if attendu != recu:
            return False
    return True

def comparaison_constante(candidate: bytes) -> bool:
    # Comparaison fournie par la bibliothèque standard.
    # Les entrées doivent rester de même type et même longueur attendue.
    return hmac.compare_digest(SECRET, candidate)

def mesurer(fonction, candidate: bytes, repetitions: int = 100_000) -> int:
    debut = time.perf_counter_ns()
    for _ in range(repetitions):
        fonction(candidate)
    return time.perf_counter_ns() - debut

# Les candidats partagent des préfixes de longueur différente avec SECRET.
for candidate in (b"x" * len(SECRET), b"t" + b"x" * (len(SECRET) - 1),
                  b"to" + b"x" * (len(SECRET) - 2)):
    print(candidate[:2], mesurer(comparaison_vulnerable, candidate),
          mesurer(comparaison_constante, candidate))

Cet exemple ne doit pas devenir une primitive maison. Dans un service, comparer une signature ou un jeton avec la fonction fournie par le langage, après validation stricte de son encodage et de sa longueur attendue. Pour un jeton hexadécimal, décoder d’abord en octets, puis comparer les octets. Comparer des chaînes de longueur variable peut encore exposer la longueur, ce qui est acceptable seulement si cette longueur n’est pas secrète.

La même discipline vaut pour les vérifications de code d’authentification de message et les signatures de requête. Le chiffrement de transport TLS (Transport Layer Security) protège le trajet, pas la branche conditionnelle exécutée par l’application à l’arrivée. Fermer le tuyau ne rend pas le robinet discret.

Consommation électrique et émissions électromagnétiques

Les attaques physiques changent l’architecture de défense. Le logiciel peut imposer un temps constant, mais il contrôle mal les variations électriques d’un processeur généraliste. Les instructions, caches, optimisations du compilateur et comportements microarchitecturaux produisent des signaux qui échappent au modèle abstrait du code source.

Le masquage réduit cette corrélation. Une valeur sensible est combinée avec une valeur aléatoire, appelée masque, et les calculs sont organisés pour que les observations intermédiaires ne dépendent pas directement du secret. Le masque doit être renouvelé selon le schéma utilisé, provenir d’une source aléatoire fiable et être maintenu à travers toutes les opérations concernées. Masquer une seule étape d’un algorithme revient à fermer une fenêtre en laissant le mur absent.

Pour les clés racines, les clés d’autorité de certification ou les opérations de signature exposées à des acteurs ayant un accès matériel, un HSM (Hardware Security Module) certifié contre les attaques par canaux auxiliaires constitue le choix défendable. Un HSM ne rend pas toute l’application invulnérable. Il conserve et utilise une clé dans une frontière matérielle, applique des contrôles d’accès et propose des contre-mesures physiques selon son niveau de certification.

Le choix dépend de la menace. Une application interne sans accès physique hostile peut s’appuyer sur bibliothèques maintenues, temps constant et isolation des secrets. Une clé de signature qui autorise des transactions, des mises à jour logicielles ou une infrastructure de certificats exige un matériel conçu pour résister à l’observation et à la manipulation. Les modules cryptographiques matériels et PKCS#11 décrivent l’interface courante entre applications et équipements de ce type.

Ce que les contre-mesures ne garantissent pas

Une comparaison à temps constant ne protège pas contre le vol du secret en mémoire, une journalisation accidentelle, un jeton exposé dans une variable d’environnement ou un contrôle d’accès absent. Elle ferme une classe de fuite précise. Le reste doit venir de la gestion des secrets, de l’isolation des processus et de l’authentification.

Le masquage n’empêche ni l’extraction physique invasive, ni le remplacement d’un composant, ni un défaut de génération aléatoire. Un HSM ne valide pas automatiquement l’identité de l’appelant et ne répare pas une politique d’autorisation trop large. La version plaquette promet que le matériel « sécurise les clés » ; la version exploitable exige des rôles, des journaux, une séparation des environnements et des procédures de reprise.

Une protection matérielle ne remplace pas non plus le contrôle du réseau. Si une opération de signature est accessible par une interface exposée sans limitation ni authentification forte, la clé reste confinée, mais son pouvoir est loué au premier appelant. Les choix d’exposition et de filtrage relèvent aussi de l’architecture cyber.

Exploitation, rotation et supervision des secrets

Les secrets comparés doivent être inventoriés : jetons d’API (Application Programming Interface), clés de signature, secrets de webhook, codes de récupération et mots de passe administratifs. Chaque catégorie nécessite un propriétaire, une durée de validité, un mécanisme de rotation et une révocation. Une comparaison parfaite d’un jeton permanent reste une dette de sécurité avec un joli emballage.

Pour les clés détenues dans un HSM, sauvegarder les objets selon le mécanisme prévu par le constructeur : domaines de sécurité, cartes d’administration, clés de wrapping ou réplication contrôlée. Exporter une clé non exportable pour « avoir une copie au chaud » annule précisément la propriété achetée. La reprise doit être testée avec des rôles séparés, sans dépendre d’une personne unique ni d’un tiroir dont la serrure a connu des jours meilleurs.

Superviser les échecs de vérification, les volumes de requêtes par identité, les changements de configuration cryptographique et les opérations d’administration du matériel. Une hausse de requêtes presque identiques vers une vérification de signature signale autant une attaque temporelle qu’un client mal conçu. Les deux méritent une réponse, mais pas le même ticket de support.

🐝 Ce qui arrive si on s’en passe

Sans comparaison à temps constant ni confinement matériel, chaque vérification de jeton ou de signature devient un oracle : la réponse mesurée renseigne l’appelant sur la valeur attendue, exactement comme dans la brèche « la question qui rend le module bavard ». La conséquence la plus coûteuse est l’absence de trace : une extraction par mesure de latence, de consommation ou d’émissions n’écrit aucune ligne de journal et ressemble à du trafic valide, si bien que rien ne distingue un secret encore confidentiel d’un secret déjà reconstruit. La révocation devient alors une décision sans preuve, prise sur une date inconnue, et la rotation ne peut plus être cadrée : impossible d’établir quelles signatures émises avant l’incident restent dignes de confiance.

🦫 Explication de la marmotte 🍫

Un programme qui vérifie un secret doit comparer une valeur reçue avec une valeur attendue. Si le programme arrête sa comparaison dès qu’il trouve une différence, le temps nécessaire dépend du nombre de caractères corrects placés au début de la valeur reçue. Une personne malveillante peut envoyer beaucoup de propositions, mesurer les temps de réponse et garder les caractères qui produisent les réponses les plus longues. En répétant les mesures, les retards aléatoires du réseau deviennent moins gênants. Le secret peut alors être trouvé morceau par morceau.

D’autres attaques regardent ce qui se produit dans le matériel pendant un calcul cryptographique. Une puce consomme une quantité d’électricité et émet des signaux électromagnétiques qui varient selon les données manipulées. Avec beaucoup de mesures et des hypothèses sur les calculs effectués, ces variations peuvent révéler des parties d’une clé.

Pour réduire le risque, toute comparaison de secret doit parcourir les données sans s’arrêter plus tôt selon leur contenu. Les calculs les plus sensibles peuvent aussi être conçus pour mélanger des valeurs aléatoires aux données secrètes. Quand une clé donne accès à des fonctions très critiques, elle doit rester dans un équipement matériel conçu pour limiter l’observation physique. Ces protections n’empêchent pas le vol d’un secret mal stocké, mal journalisé ou accordé à une personne non autorisée.

Pages voisines

La citent

Attaques par canaux auxiliaires et secrets

Elle cite

: les deux pages se citent l’une l’autre.

Attaques par canaux auxiliaires et secrets

Attaques par canaux auxiliaires et secrets

Canaux auxiliaires : la fuite est dans l’exécution

Attaque temporelle contre une comparaison de secret

Exemple reproductible de comparaison à temps constant

Consommation électrique et émissions électromagnétiques

Ce que les contre-mesures ne garantissent pas

Exploitation, rotation et supervision des secrets

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines