JTAG et SWD: les interfaces de debug côté attaque

Pendant le développement, le port de debug est l’outil le plus précieux de l’équipe firmware. Il permet d’arrêter le processeur, de lire la mémoire, de poser un point d’arrêt, de reprogrammer la carte en quelques secondes.

En production, ce même port offre exactement les mêmes possibilités à la personne qui tient l’objet. La seule différence, c’est qu’elle n’a pas été invitée.

JTAG et SWD en deux minutes

JTAG (norme IEEE 1149.1) a été conçu à l’origine pour tester les soudures des cartes électroniques. Il est devenu l’interface de debug standard de la plupart des processeurs. Il utilise quatre signaux, TCK, TMS, TDI et TDO, parfois complétés par une ligne de remise à zéro.

SWD (Serial Wire Debug) est l’alternative proposée par Arm pour les microcontrôleurs Cortex. Il offre les mêmes fonctions de debug avec seulement deux signaux, SWDIO et SWCLK. C’est l’interface que l’on rencontre sur la quasi-totalité des STM32, nRF et autres microcontrôleurs Cortex-M.

Les deux donnent accès au cœur du système: registres du processeur, mémoire vive, mémoire flash, périphériques.

Ce qu’un port de debug ouvert permet

• Extraire le firmware complet. C’est l’usage le plus courant, et le point de départ de toute rétro-ingénierie. Les secrets qu’il contient suivent. Voir Secrets dans le firmware: trois failles, une même cause.
• Lire la mémoire vive pendant l’exécution. Les clés de session, les mots de passe déchiffrés et les données en cours de traitement s’y trouvent en clair.
• Contourner une vérification. Arrêter le processeur juste avant un test d’authentification, modifier un registre, reprendre l’exécution.
• Reprogrammer l’équipement. Remplacer le firmware par une version modifiée, puis remettre l’objet en circulation.
• Cloner le produit. Un firmware extrait et recopié sur une carte identique donne un équipement fonctionnel.

L’analyse que nous avons publiée sur l’attaque contre les régulateurs Danfoss le rappelle: un algorithme de mot de passe caché dans un firmware n’est pas un secret, parce que le firmware finit toujours par être extrait.

Comment un attaquant trouve le port

Le connecteur de debug n’est presque jamais étiqueté sur un produit fini. Cela ne ralentit pas beaucoup un auditeur.

1. Repérage visuel. Un connecteur à 10 ou 20 broches, une rangée de pastilles non peuplées, quelques points de test alignés près du microcontrôleur.
2. Fiche technique. La référence du microcontrôleur donne les broches affectées au debug. Il reste à suivre les pistes.
3. Mesures. Un multimètre identifie la masse et l’alimentation, ce qui réduit le nombre de candidats.
4. Recherche automatique. Des outils dédiés essaient toutes les combinaisons de broches jusqu’à obtenir une réponse valide du composant.
5. Connexion. Une sonde de debug du commerce et un logiciel libre suffisent pour dialoguer avec la cible.

Supprimer le connecteur ou masquer les pastilles ne constitue pas une protection. Les signaux restent présents sur les broches du composant.

Verrouiller, et ce que cela vaut vraiment

Les fabricants de microcontrôleurs proposent des mécanismes de protection. Ils ne sont pas actifs par défaut: c’est au fabricant du produit de les activer en fin de production.

Famille	Mécanisme	Ce qu’il fait
STM32	Protection en lecture (RDP)	Selon le niveau, bloque la lecture de la flash par le port de debug, ou désactive définitivement ce port
ESP32	eFuses	Désactivation du JTAG, associée au secure boot et au chiffrement de la flash
nRF52	APPROTECT	Bloque l’accès du port de debug à la mémoire

Trois précisions honnêtes s’imposent.

Les niveaux ne se valent pas. Sur les STM32 qui en disposent, le niveau intermédiaire laisse le port actif et autorise un retour en arrière au prix d’un effacement de la mémoire. Seul le niveau le plus élevé désactive définitivement le debug. Il est irréversible, ce qui explique que beaucoup d’équipes hésitent à l’activer. Toutes les familles ne proposent pas ce niveau.

Ces protections ont été contournées. Plusieurs travaux de recherche publics ont montré des contournements sur différentes familles de microcontrôleurs, par perturbation de l’alimentation ou par exploitation de la séquence de démarrage. Ces attaques demandent du matériel et du savoir-faire, mais elles existent et sont documentées.

Verrouiller le port ne remplace pas le reste. Si le firmware est lisible par une autre voie (mémoire externe non chiffrée, mise à jour non protégée, chargeur de démarrage bavard), le verrouillage du debug ne protège rien.

Les règles de conception

• Activer la protection du port de debug sur chaque unité produite, et le vérifier en fin de ligne par un test automatique.
• Choisir le niveau de protection en fonction du modèle de menace, et documenter ce choix.
• Partir du principe que le firmware sera lu un jour. N’y placer aucun secret partagé entre tous les équipements.
• Utiliser une clé unique par équipement, de sorte que la compromission d’une unité ne compromette pas le parc.
• Prévoir le retour atelier sans réouvrir le debug: mécanisme d’authentification dédié, ou remplacement de la carte.
• Combiner verrouillage du debug, secure boot et signature du firmware et chiffrement du stockage.

Ces points correspondent aux exigences de limitation de la surface d’attaque et de protection contre les accès non autorisés du Cyber Resilience Act, ainsi qu’aux exigences de l’IEC 62443-4-2 sur les interfaces de diagnostic et de test.

Le pratiquer sur la carte DVID

La carte DVID réunit un ESP32 et un STM32, avec une couche de programmation qui expose JTAG, SWD et UART. Deux trainings sont consacrés à ces interfaces: une introduction au JTAG et une découverte du SWD sur STM32.

Les participants y apprennent à:

• identifier les broches de debug à partir de la fiche technique
• connecter une sonde et établir la communication avec la cible
• lire la mémoire et extraire un firmware
• observer l’effet des protections quand elles sont activées
• formuler une recommandation de verrouillage adaptée au produit

Pour qui?

• développeurs firmware et responsables d’industrialisation
• pentesters et auditeurs matériels
• responsables sécurité produit
• équipes qualité chargées des tests de fin de ligne

Aller plus loin

Voir aussi Sécurité I2C: ce qu’un attaquant lit sur deux fils et UART exposé, MQTT vulnérable. Pour valider ces compétences, découvrir le parcours de certification DVID.

En savoir plus: https://dvid.eu/fr
Nous contacter: https://dvid.eu/fr#contact
Suivre notre actualité: https://www.linkedin.com/company/dvid/