cyber / cybersecurite-fondamentale
Bases de la sécurité IoT
Explication
Ce que vous allez apprendre
- Comprendre pourquoi les identifiants par défaut restent la cause n°1 de compromission de masse en IoT
- Expliquer pourquoi chaque appareil doit avoir une identité cryptographique unique, jamais partagée
- Comprendre le principe du secure boot comme chaîne de confiance depuis l'allumage
- Sécuriser une communication device-vers-cloud avec MQTT et une authentification par certificat
- Identifier les interfaces de debug physiques (JTAG/UART) comme portes dérobées potentielles
Dans quel contexte ?
Des dizaines de milliers de caméras de surveillance connectées, vendues sous des marques différentes mais fabriquées par le même sous-traitant, partagent toutes le même mot de passe administrateur codé en usine. Un ver informatique scanne Internet à la recherche de ces caméras, se connecte avec ce mot de passe connu, et les recrute en quelques heures dans un réseau de machines zombies capable de lancer des attaques par déni de service massives. C'est exactement le scénario du botnet Mirai, qui a exploité ce défaut à grande échelle.
Des objets connectés, souvent conçus sans penser sécurité en premier
L'IoT (Internet of Things) désigne les objets physiques connectés au réseau : caméras, capteurs, appareils domestiques. Beaucoup de ces produits sont conçus avec la fonctionnalité et le coût comme priorités, la sécurité arrivant en dernier — ce qui explique pourquoi l'IoT reste une des surfaces d'attaque les plus fragiles aujourd'hui.
Le problème numéro un : les identifiants par défaut
Piège fréquent
Un très grand nombre d'appareils IoT compromis à grande échelle le sont simplement parce que leur mot de passe administrateur par défaut ("admin"/"admin") n'a jamais été changé. C'est le rappel le plus basique de la leçon 2 (mots de passe) appliqué à un contexte où l'utilisateur final n'a souvent même pas conscience qu'un mot de passe existe à changer.
Pourquoi une identité unique par appareil est essentielle
| Approche | Si un appareil est compromis physiquement | Impact |
|---|---|---|
| Secret partagé par toute la gamme | Le secret extrait fonctionne sur tous les exemplaires | Compromission massive |
| Identité cryptographique unique par appareil | Seul cet exemplaire est affecté | Compromission isolée |
Chaque appareil doit avoir sa propre identité cryptographique unique, générée individuellement, pour que la compromission d'un exemplaire reste isolée.
Le secure boot, une chaîne de confiance depuis l'allumage
Le secure boot vérifie, à chaque étape du démarrage, que le logiciel qui va s'exécuter n'a pas été modifié par rapport à une version signée et de confiance. C'est une chaîne : si la première étape est vérifiée mais fait confiance aveuglément à la suivante sans la vérifier à son tour, toute la chaîne de confiance s'effondre dès qu'un maillon est compromis.
Les interfaces de debug, oubliées mais bien réelles
Les ports JTAG et UART, utilisés par les développeurs pendant la fabrication pour déboguer le matériel, donnent souvent un accès bas niveau très puissant s'ils restent actifs et accessibles physiquement sur le produit final vendu — une porte dérobée involontaire qu'il faut désactiver ou protéger avant la mise en production.
Commandes & code
Bases de la sécurité IoT
Les objets connectés cumulent les pires conditions : ressources limitées, mises à jour rares, et souvent des identifiants par défaut jamais changés.
# OWASP IoT Top 10 (résumé) - les cibles les plus fréquemment exploitées
1. Mots de passe faibles, devinables ou codés en dur (identifiant/mot de passe usine identiques sur toute une gamme)
2. Services réseau non sécurisés (ports ouverts inutilement : telnet, débogage exposé)
3. Interfaces de l'écosystème non sécurisées (API cloud, mobile app, web app associées à l'objet)
4. Absence de mécanisme de mise à jour sécurisé (pas de signature de firmware, pas de rollback)
5. Utilisation de composants tiers non sécurisés ou obsolètes (bibliothèques, SDK abandonnés)
6. Protection de la vie privée insuffisante (données collectées non chiffrées, non anonymisées)
7. Transfert et stockage de données non sécurisés (pas de TLS, pas de chiffrement au repos)
8. Absence de gestion des appareils (pas d'inventaire, pas de procédure de mise hors service)
9. Réglages par défaut non sécurisés (souvent impossibles à changer par l'utilisateur final)
10. Absence de renforcement physique (ports de débogage UART/JTAG exposés physiquement)/* Firmware embarqué : identifiants codés en dur (anti-pattern classique, extractible par reverse engineering) */
#define ADMIN_USER "admin"
#define ADMIN_PASS "admin123" /* MAUVAIS : identique sur des dizaines de milliers d'appareils du même modèle */
/* Bonne pratique : identifiant unique par appareil, généré à la fabrication, forçant un changement au 1er démarrage */
void provision_device(char *device_id) {
char unique_password[32];
generate_random_secret(unique_password, sizeof(unique_password)); /* dérivé d'un secret matériel unique (HSM/TPM) */
store_credentials_encrypted(device_id, unique_password);
force_password_change_on_first_boot();
}# Sécurisation du firmware et du boot
1. Secure boot : chaque étage de démarrage vérifie la signature cryptographique de l'étage suivant (chaîne de confiance)
2. Signature du firmware : le bootloader refuse de flasher/exécuter un firmware non signé par la clé du fabricant
3. Chiffrement du firmware au repos : empêche l'extraction triviale des secrets/algorithmes via un dump flash
4. Rollback protection : empêche un attaquant de reflasher une ancienne version connue vulnérable
5. Désactivation des interfaces de debug (JTAG/UART) en production, ou protection par fusible matériel (eFuse)# Communication IoT -> cloud : MQTT mal sécurisé est une cible fréquente (broker exposé, wildcard non restreint)
# Configuration MQTT sécurisée type (paho-mqtt côté device)
import ssl
import paho.mqtt.client as mqtt
client = mqtt.Client(client_id="device-a1b2c3", protocol=mqtt.MQTTv5)
client.tls_set(ca_certs="ca.pem", certfile="device_cert.pem", keyfile="device_key.pem",
tls_version=ssl.PROTOCOL_TLSv1_2) # authentification mutuelle par certificat, pas juste user/pass
client.username_pw_set(username="device-a1b2c3") # identité par device, jamais un compte partagé par toute la flotte
# ACL côté broker : ce device ne doit publier/souscrire que sur SON topic, jamais sur "#" (wildcard global)
# topic autorisé : devices/a1b2c3/telemetry (publish) et devices/a1b2c3/commands (subscribe)Résumé
- Les identifiants par défaut codés en dur restent la cause n°1 de compromission de masse en IoT.
- Le secure boot et la signature du firmware forment la chaîne de confiance depuis l'allumage jusqu'à l'application.
- Chaque appareil doit avoir une identité cryptographique unique, jamais un secret partagé par toute une gamme de produits.
- Les interfaces de debug physiques (JTAG/UART) doivent être désactivées ou protégées avant la mise en production.
Exercices pratiques
Mission : la gamme de caméras recrutée en botnet
Objectif : Analyser un scénario proche de Mirai pour identifier la cause racine et concevoir une architecture d'identifiants qui limite la compromission de masse.
Contexte
Technologik lance une gamme de caméras de surveillance connectées. Un audit tardif révèle que les 50 000 exemplaires déjà vendus partagent tous le même compte administrateur admin/admin123, codé en dur dans le firmware, comme dans l'exemple du cours. Un chercheur en sécurité démontre qu'un simple scanner Internet peut les recruter en quelques heures dans un réseau de machines zombies.