Sécuriser un Linux embarqué : de la carte au système

Un produit sous Linux embarqué cumule les risques d’un serveur et ceux d’un objet que l’attaquant peut tenir dans ses mains. Il peut ouvrir le boîtier, brancher une sonde sur un port série, lire la mémoire flash ou interrompre le démarrage. Les recommandations classiques de durcissement restent utiles, mais elles arrivent trop tard si la carte laisse un accès root par la console.

Les normes l’ont intégré. L’ETSI EN 303 645 et l’EN 18031 demandent de protéger les secrets stockés, de limiter la surface d’attaque et de garantir l’intégrité du logiciel. Le Cyber Resilience Act en fera des exigences de mise sur le marché à partir du 11 décembre 2027.

1. Le matériel : ce que la carte laisse faire

Les choix de conception électronique décident de ce qu’un attaquant pourra atteindre sans aucune faille logicielle.

• Les ports de debug : une console série (UART) ouverte sur un shell root, ou un JTAG actif, donnent la main sur le produit en quelques minutes. En production, la console doit être désactivée ou protégée, et le JTAG verrouillé par les fusibles du processeur.
• La mémoire : une flash eMMC ou NAND se dessoude et se lit. Tout ce qui y est stocké en clair, mots de passe, clés, certificats, configuration, doit être considéré comme lisible.
• Le stockage des secrets : un élément de confiance (élément sécurisé, TPM, ou l’environnement de confiance du processeur comme OP-TEE sur ARM) garde les clés hors de portée du système principal.
• Le routage : des pistes de bus exposées ou des points de test étiquetés facilitent l’écoute des échanges entre composants.

Un attaquant qui obtient un shell root par la console série n’a besoin d’aucune vulnérabilité logicielle.

2. La chaîne de démarrage : n’exécuter que du code signé

Le démarrage sécurisé (secure boot) garantit que chaque étape vérifie la signature de la suivante avant de lui passer la main :

1. la ROM du processeur vérifie le premier chargeur grâce à une clé dont l’empreinte est gravée dans des fusibles ;
2. le chargeur (souvent U-Boot) vérifie le noyau, le device tree et l’initramfs, regroupés dans une image FIT signée ;
3. le noyau monte un système de fichiers dont l’intégrité est contrôlée, par exemple avec dm-verity.

Deux points sont souvent oubliés. L’environnement d’U-Boot doit être verrouillé, sinon une simple modification de la ligne de commande du noyau (init=/bin/sh) contourne tout le reste. Et les clés de signature doivent vivre dans un HSM ou un coffre, jamais sur le poste d’un développeur.

3. L’image système : partir de rien plutôt que tout retirer

Deux approches existent pour construire le système :

• partir d’une distribution existante (Debian, image du fabricant de la carte) : rapide, mais l’image embarque des paquets, des services et des comptes qui ne servent pas au produit
• construire l’image avec Yocto ou Buildroot : plus exigeant au départ, mais chaque composant est choisi, versionné et reproductible.

Pour un produit, la seconde voie s’impose presque toujours. Elle produit aussi la nomenclature logicielle (SBOM) que le CRA exige : Yocto génère un SBOM au format SPDX et sait croiser les versions avec les bases de vulnérabilités connues.

La règle est simple : chaque paquet, service et port ouvert doit avoir une raison d’être. Un serveur SSH, un shell BusyBox complet ou un serveur web de configuration laissés « au cas où » sont autant de portes.

4. Le durcissement du système

Une fois l’image réduite à l’essentiel, le durcissement suit les recommandations de l’ANSSI pour les systèmes GNU/Linux, qui s’appliquent largement à l’embarqué :

• le noyau : désactiver les modules et pilotes inutiles, activer les options de protection mémoire, restreindre /dev/mem, kptr_restrict et dmesg
• les comptes : aucun mot de passe par défaut commun à tous les produits, pas de connexion root à distance, des comptes de service sans shell
• les services : chaque service tourne avec un utilisateur dédié, et systemd sait le cloisonner (ProtectSystem, NoNewPrivileges, filtrage des appels système)
• le contrôle d’accès : SELinux ou AppArmor confinent les applications exposées, même si une faille les compromet
• le système de fichiers : racine en lecture seule, données sur une partition séparée montée sans droit d’exécution.

5. Les données et les communications

Les données du produit (configuration, identifiants, données des utilisateurs) se chiffrent avec dm-crypt, la clé étant protégée par l’élément de confiance plutôt que posée à côté sur la flash. Chaque produit reçoit son identité propre, un certificat unique, ce qui évite qu’un appareil compromis compromette tout le parc.

Les échanges avec le cloud ou l’application mobile passent en TLS avec vérification du certificat du serveur, et idéalement authentification mutuelle.

6. La mise à jour : la mesure qui rattrape toutes les autres

Aucune image n’est parfaite le jour de la livraison. Une mise à jour signée, atomique et capable de revenir en arrière permet de corriger une faille sur tout le parc. C’est le sujet de notre article Mise à jour sécurisée d’un système embarqué.

Récapitulatif

Vos questions sur la sécurité d’un Linux embarqué

Ce que nous faisons avec vous

Nous intervenons à chaque étape : conception électronique et firmware sécurisés, test d’intrusion matériel et embarqué pour vérifier ce qu’un attaquant obtient réellement, et audit de sécurité produit avant la mise sur le marché.

Pour former vos équipes, la formation Sécuriser un Linux embarqué (3 jours, en intra) fait pratiquer le durcissement d’une image et les attaques sur cible, sur notre propre carte d’entraînement.

Un produit sous Linux embarqué à sécuriser ? Parlons de votre projet.

Partager : LinkedIn Facebook E-mail

Un projet à sécuriser ?

Échangeons sur votre périmètre, vos usages et vos priorités de sécurité.

Échanger avec un expert ↗

LOOTUS SECURITY

Expertise cybersécurité IoT, IT, OT et Web.

Découvrir notre équipe ↗