Sécurité des objets connectés

Cartographier les composants IoT, comprendre la surface d’attaque et mettre en place des contrôles techniques pour sécuriser capteurs, actionneurs et passerelles.

Architecture matérielle & firmware Chaîne de confiance & mises à jour Prérequis : électronique embarquée + réseau

Sommaire technique

Introduction Architecture IoT Chaîne de confiance Surfaces d'exposition Durcissement Monitoring & réponse Laboratoire Outils Ressources

Pourquoi sécuriser les objets connectés ?

Un dispositif IoT combine microcontrôleur, firmware (bootloader + application), périphériques (capteurs/actionneurs), couche de connectivité et services Edge/Cloud. Chaque strate impose des contraintes (énergie, latence, mémoire) et ouvre des points de défaillance (intégrité binaire, extraction de secrets, dérive configuration, exposition réseau).

Cartographie fonctionnelle rapide

Composant Rôle Risques Contrôles
Bootloader Init horloges/mémoire, vérif image Code non signé, rollback vulnérable Signature + anti-rollback + attestation
Application Logique métier, capteurs, comm Overflow, corruption heap, secrets clairs MPU, canary, chiffrement secrets
Périphériques Bus SPI/I²C/UART Sniffing, injection, timing glitch Isolation bus, CRC, filtrage
Connectivité Transport MQTT/CoAP MITM, downgrade, flooding TLS/mTLS, limites débit
Stockage Config, logs, double banque Lecture Flash, corruption Chiffrement at-rest, ECC
Edge / Cloud Provisionnement, orchestration, supervision Dérive d’identité, tokens sur‑privilégiés PKI, rotation certificats, moindre privilège
  • Contraintes énergie : budget mAh → cadence réveils, fenêtre radio courte, impact sur schéma de mise à jour.
  • Empreinte mémoire : Flash disponible vs taille double banque (OTA), RAM vs buffers protocoles.
  • Latence : acquisition temps réel vs coûts crypto (sélection courbes ECC légères).

Vue mémoire typique (MCU ARM Cortex-M)

  • 0x0000_0000 : vecteurs d’interruptions
  • Bootloader : 16–64 KB
  • App Slot A : image active
  • App Slot B : image OTA candidate
  • Config : KV, calibration (EEPROM émulée)
  • SE externe : clés racine ECC, certificats
  • SRAM : pile, tas, buffers radio
  • MPU regions : code RO, data RW, périphériques

Séparation stricte code / données + régions no‑exec limite escalade en cas de corruption mémoire.

Terminologie de base

  • MCU / MPU : MCU = microcontrôleur (Flash/RAM intégrées, ressources contraintes). MPU = processeur plus riche (MMU, OS complet Linux / Android).
  • Firmware : image binaire (bootloader + application + config persistante) chargée dans la Flash exécutée au reset.
  • Bootloader : code d’amorçage; initialise horloges/mémoires, vérifie la signature cryptographique du firmware principal.
  • OTA (Over-The-Air) : processus de mise à jour distant d’une image signée (souvent double banque + rollback sécurisé).
  • Secure Element (SE) : composant isolé implémentant stockage de clés + opérations crypto (ECC, AES) sans exposition des secrets.
  • TPM : Trusted Platform Module — attestation + stockage scellé (principalement plateformes MPU/SoC complexes).
  • Edge Gateway : passerelle locale effectuant agrégation, filtrage, conversion protocolaire (ex. Wi-Fi → Ethernet/MQTT).
  • RTOS : noyau temps réel assurant ordonnancement déterministe (Zephyr, FreeRTOS, ThreadX).
  • Attestation : preuve signée (hash firmware + nonce) transmise au service distant pour valider l’intégrité.

Glossaire rapide

  • ACL : liste de contrôle d’accès.
  • ASLR : randomisation espace d’adressage.
  • CBOR : format binaire compact pour la télémétrie.
  • CRC : contrôle d’intégrité simple sur trame.
  • DTLS : TLS adapté à UDP (CoAP sécurisé).
  • EOL : phase de fin de vie du dispositif.
  • JTAG / SWD : interfaces de debug hardware bas niveau.
  • MPU (Memory Protection Unit) : segmentation mémoire basique (≠ MMU).
  • MQTT : protocole publish/subscribe léger.
  • PKI : infrastructure de gestion des certificats.
  • SBOM : inventaire des composants logiciels.
  • SoC : System on Chip intégrant CPU + IP périphériques.
  • TLS : protocole de sécurisation des transports.
  • Watchdog : timer réarmé périodiquement qui réinitialise en cas de blocage.

Rappel réglementaire

Les objets déployés dans l’Union européenne doivent respecter la directive RED, les exigences ETSI EN 303 645 et, à terme, l’acte européen sur la cyber-résilience (CRA) pour la gestion des vulnérabilités et mises à jour sécurisées.

Architecture d'un objet connecté

Comprendre les dépendances matérielles et logicielles permet de cibler les contrôles de sécurité au bon niveau.

Capteurs / Actionneurs
Entrées physiques : température, inertie, relais…
MCU / MPU
Architecture ARM Cortex, RISC-V, SoC Linux.
Firmware
RTOS, pilotes, pile crypto, stack réseau.
Connectivité
Radio (BLE, Wi-Fi, LoRa), cellulaire, filaire.
Edge / Cloud
Broker MQTT, API REST, data lake, supervision.

Strates matérielles clés

  • Alimentation : convertisseurs DC-DC, batterie, circuit de charge.
  • Interface de debug : SWD/JTAG, UART, USB DFU.
  • Périphériques : GPIO, bus SPI/I²C, mémoire Flash et RAM externes.
  • Protection physique : boîtier scellé, tamper switches, revêtement résine.

Pile logicielle

  • Boot flow : ROM → bootloader → partition firmware.
  • RTOS : FreeRTOS, Zephyr, ThreadX, Linux embarqué.
  • Protocoles applicatifs : MQTT, CoAP, OPC-UA, Modbus/TCP.
  • Services cloud : jumeau numérique, provisioning, pipeline CI/CD.

Carte mentale des dépendances

  • Dépendances matérielles : fournisseurs de MCU, modules radio, capteurs critiques.
  • Dépendances logicielles : SDK constructeur, bibliothèques cryptographiques, conteneurs.
  • Chaîne de production : usine de flash, processus d’injection clé, test in-circuit.
  • Ops : pipeline DevSecOps, gestion des certificats, portail cloud.

Chaîne de confiance et cycle de vie

La sécurité d’un objet connecté dépend de l’intégrité du firmware, de l’identité du dispositif et de la capacité à le maintenir jour après jour.

Phase Contrôles indispensables Points de vigilance Métriques
Provisionnement Injection de certificats uniques, verrouillage debug, attestation usine. Protection des secrets en usine, traçabilité série, désactivation des ports test. Taux de dispositifs provisionnés avec clé unique, temps de cycle.
Démarrage Secure boot, mesure cryptographique du firmware, anti-rollback. Gestion des clés racine, revocation list, double banque firmware. Taux de démarrages validés, nombre d’échecs de vérification.
Exploitation Segmentation mémoire (MPU), sandbox tâches, chiffrement données au repos. Contre-mesures side-channel, isolation réseau, quotas ressources. Crashes par million d’événements, dérives de consommation.
Mises à jour OTA signée, chiffrement en transit, rollback contrôlé. Scénarios d’échec (batterie faible, réseau instable), orchestrateur d’update. Couverture patch (% devices), latence de déploiement.
Fin de vie Wipe sécurisé, révocation certificats, offboarding cloud. Gestion des pièces retournées, effacement mémoire, mise à jour du stock. Nombre de dispositifs désactivés proprement, incidents post EOL.

Checklist chaîne de confiance

  • Catalogue des identités (certificats X.509, clés symétriques, PSA Root).
  • Inventaire des algorithmes cryptographiques (SHA-256/384, ECC P-256, Ed25519, AES-GCM).
  • Plan de rotation clé & certificat (expiration, révocation, distribution).
  • Test de résilience OTA : alimentation fluctuante, perte réseau, reprise automatique.
  • Journalisation des événements de boot et d’update (hash, version, timestamp signé).

Surfaces d'exposition et scénarios techniques

Les vulnérabilités IoT se répartissent sur quatre axes : physique, firmware, réseau et cloud. Cartographier ces axes aide à prioriser les contre-mesures.

Accès physique

  • Extraction mémoire via buses SPI/I²C, dump Flash externe.
  • Glitching alimentation, fault injection sur bootloader.
  • Analyse invasive (décapsulation, micro-probing).
  • Ports debug non verrouillés (UART, SWD, USB DFU).

Firmware & logiciel

  • Dépassement de tampon, format string, erreurs de parsing protocole.
  • Utilisation d’OS obsolètes, bibliothèques tierces vulnérables.
  • Clés codées en dur, stockage secrets en clair.
  • Absence de mécanismes anti-rollback ou de partition secondaire.

Connectivité

  • Protocoles non chiffrés (MQTT sans TLS, HTTP, Modbus/TCP).
  • Faible robustesse aux attaques radio (sniffing, spoofing, jamming).
  • Mauvaise segmentation : réseau plat, absence de filtrage.
  • Absence de contrôle d’accès sur API locales (REST, gRPC).

Services back-end

  • Gestion multi-tenant insuffisante, confusion d’identifiants.
  • API cloud permissives (over-privileged tokens, ACL laxistes).
  • Pipeline CI/CD sans analyse de firmware ni signature.
  • Absence de corrélation d’événements IoT/SIEM.

Indicateurs de compromission

  • Variations anormales de consommation ou de température du MCU.
  • Incohérences de certificats (subject, dates, signature) lors de l’authentification.
  • Fréquence d’erreurs CRC ou de reboots supérieure au seuil établi.
  • Flux sortants vers des domaines inconnus ou ports non documentés.
  • Empreintes firmware divergentes par rapport à la release officielle.

Durcissement matériel, firmware et réseau

Les mesures techniques doivent s’adapter aux contraintes de coût, d’énergie et de capacité de calcul. Cette section consolide les pratiques éprouvées.

Durcissement matériel

  • Activer les security fuses (Read-Out Protection, TrustZone-M, OTP).
  • Contrôler la chaîne d’alimentation pour détecter les glitchs (moniteur PVD).
  • Isoler les interfaces debug : vernis, shield, password, effacement en cas d’accès.
  • Utiliser Secure Element (ATECC608, STSAFE) pour stocker clés et certificats.

Durcissement firmware

  • Adopter un secure coding guide (CERT C, MISRA, SEI) et activer ASLR/stack canary lorsque possible.
  • Adopter un secure coding guide (CERT C, MISRA, SEI) et activer ASLR / stack canary lorsque possible.
  • Segmenter la mémoire via MPU/TrustZone pour isoler piles, heap et périphériques.
  • Signer chaque composant (bootloader, application, modules dynamiques) avec chaînage SHA-256 + signature ECC.
  • Mettre en place un watchdog logique + hardware et journaliser les redémarrages.

Durcissement réseau

  • Utiliser TLS 1.2+ avec mutual authentication (mTLS), suite (ECDHE-ECDSA-AES128-GCM).
  • Filtrer les commandes via broker (MQTT topic ACL, CoAP DTLS + OSCORE).
  • Isoler les objets sur VLAN / VRF dédiés, firewall L3/L7 pour interdire communications latérales.
  • Recourir à des protocoles orientés sécurité (Matter, OPC-UA avec profils sécurisés).

Tableau de conformité rapide

Référence Objectif Livrables Couverture
ETSI EN 303 645 Recommandations sécurité IoT grand public Checklist exigences, évaluation auto, plan patch Firmware, mises à jour, données personnelles
NISTIR 8259A Capacités de sécurité minimales Fiche device, exigences fabricant/opérateur Identité, configuration, protection OTA
PSA Certified Certification plateforme sécurisée Evidence threat model, tests laboratoire Hardware root of trust, firmware, supply chain
ISA/IEC 62443 Cyber-sécurité systèmes industriels Politique zone/conduit, analyse risque Architecture OT, segmentation, patch mgmt

Monitoring, télémétrie et réponse

Un dispositif sécurisé doit émettre des indicateurs fiables et permettre une réaction rapide en cas d’anomalie.

Télémétrie embarquée

  • Compteurs de démarrage, reset cause, watchdog status.
  • Mesure de consommation, température, tension batterie.
  • Logs applicatifs structurés (CBOR/JSON) avec horodatage monotone.
  • Hash du firmware et version protocolaire envoyés périodiquement.

Corrélation & détection

  • Corrélation IoT + SIEM (Elastic, Splunk, Azure Sentinel).
  • Modèles de comportement normal (flux, fréquence messages, puissance radio).
  • Alertes sur dérives OTA, échecs d’authentification multiples, variation RSSI.
  • Classification d’anomalies avec modèles légers (Isolation Forest, autoencoder déployé sur edge).

Plan de réponse incident IoT

  1. Détection

    Collecte télémétrie, corrélation logs, scoring d’anomalie.

  2. Confinement

    Isolation réseau (VLAN quarantine), blocage certificats, bascule mode sûr.

  3. Éradication

    Reflash firmware propre, rotation clé, purge caches cloud.

  4. Restauration

    Validation intégrité (hash, attestation), remise en service progressive.

  5. Retour d’expérience

    Update threat model, ajustement signatures, diffusion patch.

Laboratoire de validation IoT

Un banc de test dédié permet de reproduire le cycle de vie complet : provisionnement, communication, mise à jour et réponse incident.

Infrastructure recommandée

  • Plateformes cibles : cartes STM32, ESP32, Raspberry Pi, microcontrôleurs RISC-V.
  • Passerelles : routeur programmable, broker MQTT local, concentrateur LoRaWAN.
  • Injecteurs défauts : glitcher (ChipWhisperer), alimentation programmée, chambre climatique.
  • Analyseurs : oscilloscope, logique (Saleae), SDR (HackRF, Lime), scanner BLE.

Scénarios de validation

  • Test secure boot : corruption firmware, rollback forcé, signature invalide.
  • Campagne OTA : mise à jour par lots, interruption réseau, reprise automatique.
  • Stress réseau : saturation messages, interférences radio, latence gateway.
  • Instrumentation : capter logs SWD/UART, enregistrements PCAP, capture courbe consommation.

Mini-projet : audit énergétique & sécurité d’un capteur Zigbee

  1. Instrumenter : brancher un shunt + INA219 pour mesurer la consommation instantanée.
  2. Stimuler : déclencher plusieurs cycles radio (association, envoi télémétrie, update).
  3. Analyser : corréler les pics de consommation avec les logs et captures radio (channel 15).
  4. Valider : vérifier la signature du firmware avant/après update (hash + certificat).
  5. Documenter : synthèse des paramètres (débit, durée cycle, budget énergie, version).

Carnet de tests recommandé

  • Metadata : firmware, build ID, commit, date.
  • Configuration : topologie, canal radio, puissance TX, certificats utilisés.
  • Résultats : hash, logs, captures PCAP, graphes consommation.
  • Anomalies : reproduction, impact, correctif appliqué.
  • Décision : go/no-go déploiement, exigences complémentaires.

Outils logiciels & matériels

Logiciels

Reverse Ghidra · Binary Ninja · IDA Free

Firmware binwalk · qemu-system-arm · FirmAE

Analyse radio GNU Radio · SDR++ · URH

Protocoles Wireshark · Zeek · MQTT Explorer

Monitoring Telegraf · Prometheus · Grafana

S-BOM syft · tern · SPDX tooling

Threat modeling Microsoft Threat Modeling Tool · IriusRisk · Threagile

Matériel & accessoires

Niveau Equipements Usage
Débutant STM32 Nucleo, ESP32 DevKit, adaptateur UART, analyseur logique USB Prototypage, sniffing bus, tests OTA basiques
Intermédiaire J-Link, ChipWhisperer Lite, oscilloscope 100 MHz, SDR large bande Fault injection, capture radio, débogage avancé
Avancé Analyseur réseau vectoriel, chambre TEM, Secure Element programmer Caractérisation RF, validation hardware security

Boîte à outils script

  • Python : pyocd, pyCMSIS-DAP, scapy, cryptography, paho-mqtt.
  • Rust : crates probe-rs, embassy, rumqttc, serde_cbor.
  • Go : SDK industriels (AWS IoT Device, Azure IoT Edge), goburrow/modbus.
  • DevOps : firmware-update-stager, pipelines GitHub Actions/GitLab CI pour signer et publier.
  • Data : Spark/BigQuery pour corréler logs et métriques, notebooks Jupyter pour analyses ad hoc.

Ressources & poursuite

Références & normes

  • ETSI EN 303 645, TS 103 645 — exigences IoT grand public.
  • NIST SP 800-213 — recommandations sécurité IoT et OT.
  • OWASP IoT Project — fiches vulns et contrôles.
  • PSA Certified documents — architecture, threat models, security model.
  • Papers Black Hat / DEF CON — retours d’expérience matériels et firmware.

Formations & laboratoires

  • SANS ICS418, SEC557 — focus IoT/OT.
  • Hardwear.io Labs, Hack In The Box CommSec — ateliers pratiques hardware.
  • PentesterLab IoT, TryHackMe Embedded, Attify Labs.
  • Zephyr Project — documentation RTOS et sécurité intégrée.
  • CSA IoT Working Group — rapports de menaces annuels.

Glossaire express

  • Secure Boot : mécanisme vérifiant la signature du firmware au démarrage.
  • MCU TrustZone-M : partitionnement sécurisé matériel sur ARMv8-M.
  • PSA Level 2+ : certification covering protection contre attaques logicielles et physiques limitées.
  • SBOM : Software Bill of Materials, inventaire composants logiciels.
  • Zero Touch Provisioning : enregistrement automatique d’un objet sur le cloud via certificats préchargés.