Sécurité I2C: ce qu’un attaquant lit sur deux fils

Deux pistes sur un circuit imprimé, SDA et SCL. C’est tout ce qu’il faut à un microcontrôleur pour dialoguer avec un écran, un capteur, une mémoire ou un composant de sécurité. C’est aussi tout ce qu’il faut à un attaquant pour suivre la conversation.

L’I2C est le protocole que nos clients demandent le plus souvent en formation. La raison est simple: il est présent sur presque toutes les cartes électroniques, et presque personne ne le considère comme une surface d’attaque.

I2C en deux minutes

L’I2C (Inter-Integrated Circuit) est un bus série inventé dans les années 1980 pour relier des composants sur une même carte.

• Deux lignes: SDA pour les données, SCL pour l’horloge, maintenues à l’état haut par des résistances de tirage.
• Un contrôleur et des périphériques: le contrôleur (souvent le microcontrôleur) initie tous les échanges. Chaque périphérique répond à une adresse, le plus souvent sur 7 bits.
• Des débits modestes: 100 kHz en mode standard, 400 kHz en mode rapide, parfois davantage.

Ce que le protocole ne prévoit pas compte autant que ce qu’il prévoit. Pas de chiffrement. Pas d’authentification. Pas de contrôle d’intégrité. Tout composant branché sur le bus voit passer tous les échanges, et tout composant peut y écrire.

Ce n’est pas un défaut de conception. L’I2C a été pensé pour un monde où le circuit imprimé était une zone de confiance. Le problème commence quand un produit est vendu, donc entre les mains de n’importe qui.

Ce qu’un attaquant fait d’un bus I2C

1. Écouter

Un analyseur logique à quelques dizaines d’euros, deux pinces sur SDA et SCL, un logiciel de décodage libre. En quelques minutes, chaque trame est affichée en clair: adresse, sens de l’échange, octets transmis.

Ce que l’on trouve régulièrement dans ces captures:

• des données de configuration lues dans une mémoire au démarrage
• des identifiants ou des clés stockés dans une EEPROM
• des mesures de capteur avant tout traitement
• des échanges avec un composant de sécurité, quand la session n’est pas protégée

Le dernier cas est le plus instructif. Un composant de sécurité (TPM, secure element) protège très bien un secret tant qu’il reste à l’intérieur. Si le microcontrôleur lui demande ce secret et que la réponse transite en clair sur le bus, la protection s’arrête à la broche du composant. Des chercheurs ont montré à plusieurs reprises qu’une clé de chiffrement de disque pouvait être récupérée de cette manière, par simple écoute du bus reliant un TPM au reste de la carte.

2. Cartographier

Un balayage des adresses révèle tous les périphériques présents. Certaines plages sont caractéristiques: une réponse entre 0x50 et 0x57 désigne presque toujours une EEPROM. La référence gravée sur le boîtier et la fiche technique du fabricant font le reste.

3. Lire directement

Une fois la mémoire identifiée, l’attaquant n’a plus besoin du microcontrôleur. Il se branche sur le bus avec son propre adaptateur, se comporte comme le contrôleur et lit l’intégralité du contenu. L’opération se fait souvent sans dessouder le composant.

4. Écrire et usurper

Le bus est partagé, donc l’écriture est possible aussi. Modifier un paramètre dans une EEPROM (numéro de série, seuil, option de licence, indicateur de mode debug) est un classique. Plus élaboré: répondre à la place d’un capteur pour transmettre de fausses mesures au microcontrôleur.

5. Bloquer

Maintenir une ligne à l’état bas suffit à paralyser tout le bus. Sur un produit qui n’a pas prévu ce cas, le firmware reste bloqué en attente.

Ce que cela révèle sur la conception

L’écoute d’un bus I2C est rarement une fin en soi. C’est une étape qui alimente le reste de l’analyse: le secret lu dans l’EEPROM ouvre une API, le paramètre modifié réactive une console, la clé capturée déchiffre un firmware.

Trois erreurs reviennent dans les produits que nous voyons:

• Considérer la mémoire externe comme un espace privé. Tout ce qui est écrit dans une EEPROM est lisible par quiconque possède l’objet.
• Faire confiance aux données du bus. Une valeur lue sur I2C n’est pas authentifiée. Elle doit être validée comme une entrée externe.
• Ajouter un composant de sécurité sans protéger le lien. La plupart de ces composants proposent une session chiffrée ou authentifiée avec le microcontrôleur. Elle est souvent laissée désactivée.

Les contre-mesures qui comptent

• Ne jamais faire transiter un secret en clair sur le bus. Utiliser les mécanismes de session protégée du composant de sécurité quand ils existent.
• Chiffrer ou authentifier le contenu sensible stocké en EEPROM, avec une clé qui ne se trouve pas dans la même mémoire.
• Activer la protection en écriture des mémoires qui n’ont pas à être modifiées en exploitation.
• Valider toute donnée reçue d’un périphérique: bornes, cohérence, délai de réponse.
• Prévoir un délai maximal sur les échanges pour qu’un bus bloqué ne fige pas le produit.
• Compliquer l’accès physique sur les produits sensibles: pistes en couche interne, pas de points de test sur les lignes critiques, détection d’ouverture.

Aucune de ces mesures ne rend l’écoute impossible. Elles font en sorte que ce qui est écouté n’ait pas de valeur.

Côté réglementation, ces points relèvent directement des exigences de confidentialité, d’intégrité et de limitation de la surface d’attaque de l’Annexe I du Cyber Resilience Act, qui vise explicitement les interfaces du produit.

Le pratiquer sur la carte DVID

La carte DVID a été conçue pour rendre ces attaques visibles. Elle embarque un écran OLED piloté en I2C, un composant dédié qui simule un module tiers ou un TPM, et des connecteurs qui exposent le bus pour l’observer.

Dans nos trainings I2C, les participants:

• repèrent les lignes du bus à partir de la fiche technique et du circuit
• capturent et décodent les échanges avec un analyseur logique
• identifient les périphériques présents et leur rôle
• retrouvent une information sensible qui n’aurait pas dû transiter en clair
• en tirent les règles de conception à appliquer à leur propre produit

Le module ne demande aucun prérequis en sécurité offensive. Une première expérience des systèmes embarqués suffit.

Pour qui?

• ingénieurs firmware et concepteurs de cartes électroniques
• pentesters qui débutent sur le matériel
• responsables sécurité produit qui préparent la conformité CRA ou IEC 62443-4-2
• étudiants en cybersécurité ou en systèmes embarqués

Aller plus loin

L’I2C n’est qu’une des interfaces à examiner sur une carte. Voir aussi JTAG et SWD: les interfaces de debug côté attaque et UART exposé, MQTT vulnérable. Pour situer ces techniques dans un audit complet, lire Pentest IoT ou pentest embarqué: quelles différences?.

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