Contre un certificat stocké dans une carte à puce, une attaque par canaux auxiliaires cherche à extraire la clé privée en observant les effets physiques de son utilisation : consommation, durée, rayonnement, ou comportement du composant sous perturbation. La mécanique est réelle et bien documentée. Mais pour un RSSI, une hiérarchie s'impose : dans la très grande majorité des organisations, la clé privée ne se trouve pas dans une carte à puce — elle se trouve dans un magasin logiciel, où aucun canal auxiliaire n'est nécessaire pour la prendre.
Les deux mondes du certificat
Le certificat sur support matériel. La clé privée est générée dans l'élément sécurisé et n'en sort jamais. Les opérations cryptographiques s'exécutent sur le composant. C'est le cas des cartes à puce, des jetons cryptographiques et des modules matériels. L'extraction exige alors une attaque physique, donc la possession du support.
Le certificat logiciel. La clé privée réside dans un magasin du système d'exploitation, dans un fichier protégé par un mot de passe, ou dans un conteneur applicatif. Selon la configuration, elle peut être exportable — parfois par un simple export, parfois par un accès en lecture au profil de l'utilisateur.
Cette différence pèse infiniment plus lourd que la résistance du composant aux canaux auxiliaires. Un audit utile commence par une question unique : combien de nos certificats ont une clé privée exportable ?
Les canaux auxiliaires sur support matériel
Pour les cas où le support est matériel, voici les mécaniques concernées et leur exigence réelle.
| Attaque | Principe | Ce qu'elle exige | Contre-mesure |
|---|---|---|---|
| Analyse simple de consommation | Lire la séquence d'opérations dans le profil de courant | Possession du support, matériel de mesure | Séquences indépendantes du secret |
| Analyse différentielle | Corréler de nombreuses traces avec des hypothèses de clé | Possession prolongée, nombreuses exécutions | Masquage aléatoire des opérations |
| Analyse temporelle | Déduire des bits depuis les durées d'exécution | Mesures fines, parfois à distance | Temps d'exécution constant |
| Rayonnement électromagnétique | Capter l'activité interne sans contact direct | Proximité, équipement dédié | Blindage, bruit injecté |
| Injection de faute | Provoquer une erreur de calcul pour révéler la clé | Possession, équipement de perturbation | Redondance et vérification des calculs |
| Sonde physique | Accéder directement au silicium | Laboratoire, destruction du composant | Maillage de protection, détection d'ouverture |
Deux enseignements se dégagent. Toutes ces attaques supposent la possession du support — sauf partiellement l'analyse temporelle. Et toutes sont traitées, à des degrés variables, par les composants évalués dans le cadre des Critères Communs, dont c'est précisément l'objet.
Conséquence : sur un parc de cartes à puce de qualité, le canal auxiliaire n'est pas le risque dominant. Il le devient pour un attaquant très motivé disposant physiquement de la carte, ce qui correspond à un modèle de menace précis — perte, vol ciblé, espionnage.
Le risque réel : le cycle de vie du certificat
Ce qui compromet les déploiements de certificats en pratique tient rarement à la cryptographie.
Les clés exportables. Un certificat émis avec une clé privée exportable peut être copié par un logiciel malveillant ou par l'utilisateur lui-même, souvent pour des raisons de commodité — travailler depuis un second poste, par exemple.
Les certificats de service. Ils vivent dans des fichiers de configuration, des images de conteneurs et parfois des dépôts de code. Leur durée de vie est longue et leur rotation, exceptionnelle.
L'absence de révocation effective. Une infrastructure qui émet correctement mais ne sait pas révoquer rapidement laisse un certificat compromis valide jusqu'à son expiration naturelle.
Le code PIN de la carte. Un support matériel excellent protégé par un code court, saisi sur un poste éventuellement compromis, réduit la sécurité au niveau du poste.
L'autorité de certification elle-même. La compromission de la chaîne d'émission dispense l'attaquant de toute attaque sur les supports : il émet ses propres certificats valides.
Ce que les certificats ne protègent pas, quel que soit le support
Un certificat authentifie une ouverture de session ou une connexion. Il ne dit rien de ce qui suit. Une session établie par certificat peut être détournée comme n'importe quelle autre si le jeton applicatif est volé, et un utilisateur manipulé qui exécute lui-même une opération frauduleuse l'aura signée en bonne et due forme.
C'est le domaine de la validation par l'action. Le facteur cognitif apporte une preuve d'intention au moment de l'opération, dans un canal éphémère ouvert par QR code dynamique à usage unique. Le polymorphisme fonctionnel et l'exécution mouvante (Moving Target Defense) y font varier en continu ce qui est observable, ce qui prive une analyse par canal auxiliaire de la stabilité nécessaire à l'accumulation de mesures. Enfin, la méthode de résolution étant personnelle et acquise hors ligne, elle n'est pas exportable — un fichier de clé, lui, l'est toujours potentiellement.
FAQ
Une attaque par canaux auxiliaires est-elle un risque réaliste pour une entreprise ?
Sur des cartes à puce évaluées, elle correspond à un attaquant disposant physiquement du support et de moyens de laboratoire. Pour la plupart des organisations, les clés logicielles exportables et la gouvernance des certificats représentent un risque bien plus immédiat.
Comment savoir si nos clés privées sont exportables ?
En vérifiant les gabarits d'émission de l'autorité de certification et la configuration des magasins de certificats. C'est un contrôle simple, rarement effectué, et souvent riche en enseignements.
Une carte à puce protège-t-elle contre le phishing ?
Elle protège contre le vol de secret si la clé ne sort pas du support. La résistance au phishing proprement dite vient de la liaison à l'origine, propriété que FIDO2/WebAuthn apporte explicitement et qu'un déploiement de certificats n'apporte pas nécessairement.
Faut-il remplacer les certificats par des passkeys ?
Les deux reposent sur la cryptographie asymétrique. Les passkeys apportent la liaison à l'origine et une meilleure expérience ; les certificats restent adaptés aux usages machine, à la signature et aux environnements où une infrastructure de gestion existe déjà.
Aller plus loin : le 4ᵉ facteur cognitif · certificat et accès administrateur · biométrie par empreinte et canaux auxiliaires · Moving Target Defense contre les canaux auxiliaires