Aller au contenu
Niveau de Sécurité : Intermédiaire

MQTTS Chiffrement Logiciel

L'étape 2 implémente le TLS Mutuel (mTLS) via le port TCP 8883, passant d'une communication en texte clair à un canal cryptographiquement sécurisé. En utilisant des certificats clients X.509, nous obtenons une authentification et un chiffrement de bout en bout.

Architecture et Flux de Données

Le canal de communication est maintenant sécurisé avec le TLS Mutuel (mTLS), assurant le chiffrement et l'authentification. Cependant, la clé privée reste vulnérable dans la mémoire flash du dispositif.

ESP32

M5Go/M5Stack

Clé Privée
En Flash
Cert
client.crt
Chiffré TLS 1.2
Port 8883
Charge Utile Chiffrée

Broker Mosquitto

Serveur d'Authentification

Identité Vérifiée

Vérifie le cert client avec l'Autorité de Certification. Rejette les connexions inconnus.

Handshake mTLS & Protocole MQTT

Diagramme de séquence du processus d'authentification mutuelle pour le Publisher et le Subscriber.

Publisher
Broker
Connexion TCP :8883
Handshake mTLS
Vérif cert serveur avec CA
Certificat Serveur
Vérif cert client avec CA
Certificat Client
Clé de Session Établie
Canal Sécurisé (TLS)
MQTT CONNECT
CONNACK
Boucle (5s)
PUBLISH
m5go/env {temp,hum,press}

Vérification en Direct

L'analyse du trafic confirme que la charge utile est maintenant opaque.

Wireshark packet view demonstrating that the MQTT application data is encrypted and payload content is hidden.

Données Applicatives

L'analyse des paquets confirme que le TLSv1.2 est utilisé. La longueur du contenu est visible, mais les données elles-mêmes sont une redistribution aléatoire d'octets, rendant l'interception impossible.

Wireshark TCP stream (Follow Stream) showing only random ciphertext for the entire conversation, contrasting with the plaintext capture.

Flux Chiffré

Suivre le flux TCP (Port 8883) ne révèle que du texte chiffré illisible. Contrairement à l'ASCII clair de l'Étape 1, aucune partie du topic ou de la charge utile n'est discernable. Tous les échanges sont protégés par la couche d'enregistrement TLS.

Analyse de Menace (STRIDE)

TLS sécurise le canal, mais la Vulnérabilité du Stockage laisse des lacunes critiques dans la protection de l'identité.

Usurpation (Spoofing)

Risque
Vulnérabilité

Clé Privée stockée en Flash.

Impact

Si extraite physiquement, un attaquant peut cloner l'identité du dispositif et s'authentifier comme le capteur valide.

Falsification (Tampering)

Sécurisé
Protection

Chiffrement authentifié AES-GCM.

Impact

Les paquets modifiés en transit seront détectés par les mécanismes d'intégrité, causant l'échec de la session TLS.

Répudiation (Repudiation)

Risque
Vulnérabilité

La clé privée n'est pas confinée dans le matériel et peut être extraite.

Impact

Nous ne pouvons pas prouver qui a signé le message (l'appareil légitime ou un attaquant avec une clé dumpée).

Divulgation d'Info (Information Disclosure)

Sécurisé
Protection

Tunnel chiffré TLS 1.2.

Impact

Toute interception ne révèle que du texte chiffré aléatoire. Les données des capteurs sont confidentielles.

Déni de Service (Denial of Service)

Sécurisé
Défense

Résilience de la pile TCP/IP.

Résultat

La pile TCP/IP garantit le maintien des connexions face aux perturbations réseau.

Élévation (Elevation of Privilege)

Risque
Vulnérabilité

L'accès physique mène à une compromission totale.

Impact

Si un attaquant extrait la clé, il élève son privilège à "Propriétaire du Dispositif" de façon permanente.

Vulnérabilité Critique

Extraction de Clé Firmware

Sans Secure Element, votre clé privée vit dans la mémoire flash. Voyez avec quelle facilité un attaquant peut l'extraire.

1. La Faille de Stockage

Les certificats et la clé privée sont intégrés directement dans l'image firmware (PROGMEM) et fournis au WiFiClientSecure à l'exécution. Elle réside physiquement sur la puce flash en texte clair.

VULNERABLE_CODE.ino
// VULNÉRABILITÉ CRITIQUE : Hardcoded Secrets
// Cette clé privée réside en clair dans la mémoire Flash.

static const char client_key[] PROGMEM = R"KEY(
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQC...
... (Votre identité numérique est exposée ici) ...
-----END PRIVATE KEY-----
)KEY";

// Chargement dans la stack TLS logicielle
wifiClientSecure.setPrivateKey(client_key);

2. Accès Physique

Un attaquant connecte un adaptateur USB-vers-UART à 5€ aux broches de programmation de l'ESP32. Aucun mot de passe ou authentification n'est requis pour lire la flash brute.

3. Le Dump

Des outils comme esptool.py dumpent toute la mémoire. Une simple recherche de texte scanne le binaire pour l'en-tête PEM standard.

Impact : Une fois extraite, l'attaquant peut cloner l'identité de votre appareil et publier des données malveillantes vers votre broker.
attaquant — -zsh — 80x24
Last login: Today on ttys001
~
# Prêt à dumper le firmware...

Cliquez pour simuler l'attaque

Points Clés

Nous avons sécurisé le canal, mais l'Identité du Dispositif reste vulnérable.

Confidentialité Résolue

Le Chiffrement TLS assure que personne ne peut espionner vos données de capteurs. Le canal est opaque pour les attaquants.

Intégrité Résolue

Les mécanismes d'intégrité empêchent la falsification des paquets. Toute modification invalide le message et tue la connexion.

Lacune Critique : Stockage de Clé

La clé privée vit en texte clair dans la mémoire flash standard. Le vol physique du dispositif signifie une compromission complète de l'identité.

La Solution : Sécurité Matérielle

Nous devons déplacer la clé hors de la flash vers un coffre crypto dédié. Cela empêche l'extraction même si le firmware est compromis.

Étape Finale

Stockage de Clé Sécurisé

Nous avons le chiffrement et l'authentification, mais la clé est exposée. Il faut maintenant la déplacer dans le Secure Element.