Aller au contenu

Résumé Exécutif

Un parcours de renforcement en trois étapes pour la télémétrie MQTT : MQTT en clair, TLS mutuel avec clés stockées dans le firmware, et enfin, TLS mutuel avec un Secure Element ATECC608B stockant la clé privée.

1. Flux en Clair

MQTT standard sur le port 1883. La télémétrie est envoyée en clair, exposant les données sensibles à quiconque sur le réseau.

Explorer l'Étape 1

2. Chiffrement Logiciel

Intègre un TLS mutuel. La clé privée et le certificat client sont chargés dans la pile TLS au moment de l'exécution.

Explorer l'Étape 2

3. Chiffrement Matériel

Clés privées déplacées vers le Secure Element ATECC608B. Identité non extractible et sécurité matérielle.

Explorer l'Étape 3
Architectures

Décomposition visuelle des composants du système et du flux de données.

Modèles de Menace

Analyse STRIDE expliquant les dangers et ce qui est corrigé durant le projet.

Reproductibilité

Procédure étape par étape pour refaire ce projet à partir de zéro.

Code Source Complet

Codes C++ complets et scripts Python pour chaque étape.

Vue d'ensemble de l'architecture

Le système connecte des dispositifs de télémétrie en périphérie à un cœur central via Wi-Fi standard, visualisant les données en temps réel.

Publisher

M5Go + ENV II
Capture température, humidité et pression atmosphérique

Wi-Fi

Broker Mosquitto

Serveur Central
Valide les certificats et route les données

Wi-Fi

Subscriber

M5Stack
S'abonne et affiche les données

Progression de la Sécurité

Découvrez comment la sécurité évolue d'une base vulnérable à une protection matérielle. Sélectionnez une étape pour voir son profil de risque.

Analyse comparative des étapes par rapport à la sécurité

Documentation du Projet

Naviguez à travers les trois étapes de sécurité, les étapes de reproduction et le dépôt complet du code source.

Étape 1 : MQTT En Clair

Port 1883 · Pas de Chiffrement

Configuration de base. Voyez exactement comment les identifiants et les charges utiles en clair traversent le réseau et peuvent être interceptés.

Étape 2 : Chiffrement Logiciel

TLS 1.2 · Sécurité Logicielle

Implémentation du chiffrement TLS. Comprenez pourquoi le stockage des clés privées dans la flash du firmware reste une vulnérabilité critique.

Étape 3 : Chiffrement Matériel

ATECC608B · Sécurité Matérielle

Sécurité maximale. La clé privée est générée de manière sécurisée et stockée dans le slot 8 du Secure Element, la rendant inextractible.

Procédure

Guide Étape par Étape

Étapes de reproduction complètes. De la génération de votre propre Autorité de Certification au flashage de l'ESP32.

Code Source

C++ · Python · Config

Accès direct à tous les sketches, scripts d'aide et fichiers de configuration du broker utilisés dans ce projet.

Légal & Licence

Conditions d'Utilisation

Informations sur les actifs tiers, la licence MIT et les contraintes d'utilisation académique.

Glossaire Technique

Définitions complètes des protocoles, composants matériels et concepts de sécurité utilisés tout au long de ce projet.

MQTT / MQTTS

  • MQTT Protocole applicatif léger de messagerie publish/subscribe au-dessus de TCP, optimisé pour l’IoT (faible bande passante, latence variable, clients contraints).
  • MQTTS MQTT encapsulé dans TLS afin d’assurer la confidentialité et l’intégrité du trafic, et (optionnellement) l’authentification par certificats.
  • Broker (serveur MQTT) Point central qui reçoit les publications, maintient les abonnements et redistribue les messages aux clients abonnés (ex. Mosquitto).
  • Publisher / Subscriber Un publisher publie des messages sur un topic ; un subscriber s’abonne à un filtre de topic et reçoit les publications correspondantes via le broker.
  • Topic / Topic Filter Le topic est la “clé de routage” textuelle d’un message ; le topic filter est l’expression utilisée à l’abonnement pour sélectionner quels topics seront reçus.
  • Payload Données applicatives transportées par MQTT (contenu du message). Le broker ne l’interprète pas ; il l’achemine.
  • Keep Alive Mécanisme de maintien de session : intervalle négocié (dans CONNECT) et rafraîchi par trafic applicatif ou par PINGREQ/PINGRESP.
  • Ports 1883 / 8883 Ports standards : 1883 pour MQTT en clair ; 8883 pour MQTT sur TLS (MQTTS), selon la configuration du broker.

Mosquitto (Broker)

  • Mosquitto Broker MQTT open source. Gère connexions, abonnements, distribution des messages et, si activé, TLS/mTLS.
  • listener Directive Mosquitto définissant un point d’écoute (port + optionnellement IP/interface) pour accepter des connexions MQTT/MQTTS.
  • cafile / certfile / keyfile Chemins vers le certificat CA de confiance (cafile), le certificat serveur (certfile) et la clé privée serveur (keyfile) pour TLS.
  • require_certificate true Force le client à présenter un certificat. Active l’authentification client côté broker (mTLS) en plus de la validation du certificat serveur côté client.
  • use_identity_as_username true Utilise l’identité du certificat client (typiquement le CN) comme “username” pour les contrôles d’accès, en évitant une authentification basée uniquement sur un champ MQTT usurpable.
  • Outils CLI Mosquitto mosquitto_sub (abonnement) et mosquitto_pub (publication). Options fréquentes : -h (hôte), -p (port), -t (topic), -u (utilisateur).

PKI / Certificats

  • PKI (Public Key Infrastructure) Ensemble de règles, rôles et artefacts (CA, certificats, révocation) permettant d’émettre, distribuer et valider des identités cryptographiques.
  • X.509 Standard de certificat liant une clé publique à une identité (sujet) via une signature d’Autorité de Certification.
  • CA (Certificate Authority) Autorité qui signe des certificats. La confiance repose sur un certificat racine (ou intermédiaire) préinstallé et vérifié.
  • CSR (Certificate Signing Request) Requête de signature contenant identité + clé publique, transmise à une CA pour obtenir un certificat signé.
  • CN / SAN Champs d’identité : CN (Common Name) et SAN (Subject Alternative Name) servent à exprimer noms/DNS/identifiants attendus lors de la vérification.
  • PEM / DER / Base64 PEM = encodage texte (Base64 + en-têtes) ; DER = encodage binaire ASN.1 ; Base64 = encodage de données binaires en texte ASCII.
  • PKCS#8 Format standard de stockage d’une clé privée (structure ASN.1), souvent requis pour conversions entre outils et environnements (PEM/DER).
  • OpenSSL Suite d’outils et bibliothèque crypto pour générer clés/CSR/certificats, convertir des formats (PEM/DER/PKCS#8) et diagnostiquer des problèmes TLS.
  • Commandes OpenSSL (génération/validation) Exemples : openssl genpkey (clé), openssl req (CSR/auto-signé), openssl x509 (certificat), openssl verify (chaîne), openssl pkcs8 (conversion).

TLS / mTLS

  • TLS (Transport Layer Security) Protocole de sécurisation au-dessus de TCP fournissant confidentialité, intégrité et authentification du pair via cryptographie moderne et certificats X.509.
  • TLS 1.2 Version TLS utilisée ici : négociation de paramètres, dérivation de clés de session, puis chiffrement et authentification des enregistrements applicatifs.
  • mTLS (Mutual TLS) Variante TLS où le serveur et le client présentent chacun un certificat et prouvent la possession de leur clé privée (authentification mutuelle).
  • Handshake TLS Phase de négociation (paramètres, certificats, échanges de clés) qui établit des clés de session avant l’échange de données chiffrées.
  • Application Data Type d’enregistrement TLS transportant les données applicatives (ici MQTT) sous forme chiffrée et authentifiée.
  • Clé de session Clés symétriques dérivées pendant le handshake pour chiffrer et authentifier le flux (données applicatives) pendant la durée de la session.
  • AES-GCM / AES-128 Chiffrement symétrique : AES-128 (taille de clé) et GCM (mode AEAD) fournissent confidentialité + intégrité des messages.
  • MITM (Man-in-the-Middle) Attaque active où un adversaire s’interpose entre client et serveur. TLS correctement vérifié (CA/nom attendu) réduit fortement ce risque.
  • Erreurs “bad signature” / “signature failure” Indiquent une vérification de signature échouée (certificat, handshake, ou données signées), typiquement causée par clé/certificat incohérents, chaîne de confiance invalide ou altération.

Secure Element / Matériel

  • Secure Element (SE) Composant matériel durci pour stocker des secrets (clés) et exécuter des opérations crypto. Les clés privées peuvent y être non exportables (utilisées sans jamais sortir du silicium).
  • ATECC608B Secure Element (Microchip CryptoAuthentication) supportant ECC (P-256), signatures ECDSA, ECDH et stockage de données/attestations avec zones verrouillables.
  • Trust&GO (TNGTLS / TNGTLSU) Variantes pré-provisionnées de l’ATECC608B (ex. TNGTLS, TNGTLSU) fournissant une identité/certificats prêts pour TLS.
  • Zone Config / Zone Data / OTP Organisation mémoire : Config (permissions, verrouillage), Data (certificats/données), OTP (One-Time Programmable : écrit une fois).
  • GenKey Commande/primitive du Secure Element générant une paire de clés ECC interne. La clé privée reste interne, la clé publique peut être extraite pour produire CSR/certificat.
  • I2C (bus) / Adresse 0x35 Bus série synchrone (SDA/SCL) utilisé pour piloter l’ATECC608B ; 0x35 est l'adresse I2C typique de l'ATECC608B.
  • UART / USB-vers-UART UART = liaison série asynchrone ; l’adaptateur USB-vers-UART sert au flash/console (ex. moniteur série à 115200 bauds).
  • ESP32 / M5Stack / M5Go / Grove Plateforme microcontrôleur Wi-Fi (ESP32) intégrée à des kits (M5Stack/M5Go). Grove sert d’écosystème de connectique pour capteurs.
  • Capteurs SHT31 / BMP280 SHT31 : capteur température/humidité ; BMP280 : capteur pression, reliés via I2C.
  • PKCS#11 / HAL / callbacks ECDSA PKCS#11 est une API standard de “token” cryptographique ; une HAL (Hardware Abstraction Layer) et des callbacks (ex. ECDSA) permettent d’exécuter la crypto dans le SE tout en exposant une interface logicielle.
  • Durcissement matériel : Active Shields / obfuscation / attaques invasives Active Shields : détection de sondage/altération ; obfuscation du layout : complexification du reverse ; attaques invasives : ouverture, micro-probing, FIB, etc.
  • Firmware / Flash / RAM / PROGMEM Firmware : binaire embarqué ; flash : mémoire non volatile ; RAM : mémoire volatile ; PROGMEM : stockage de constantes en flash (Arduino) pour éviter d’occuper la RAM.
  • Dumping de firmware / clonage d’identité Extraction du contenu flash (ex. clés/certificats si stockés en clair), permettant potentiellement de cloner l’identité TLS/MQTT d’un objet si les secrets ne sont pas protégés matériellement.
  • Buffer Overflow Dépassement de tampon (écriture hors limites) pouvant corrompre mémoire et contrôle d’exécution ; risque classique sur systèmes embarqués si entrées non bornées.

Modèle STRIDE

  • Spoofing Usurpation d’identité (client, serveur, broker) via identifiants falsifiés.
  • Tampering Altération/falsification de données (payload, certificats, firmware, configurations).
  • Repudiation Contestation d’actions : absence de preuve fiable de qui a fait quoi (logs/identités faibles).
  • Information Disclosure Divulgation d’informations sensibles (sniffing MQTT en clair, fuite de clés/certificats).
  • Denial of Service (DoS) Interruption de service (saturation du broker, épuisement de ressources, resets).
  • Elevation of Privilege Obtention de droits supérieurs (exploitation logicielle, clés compromises).