Sommaire de l’article
- Les menaces sur une mise à jour
- 1. Signer chaque mise à jour, vérifier sur l’appareil
- 2. Empêcher le retour à une version vulnérable
- 3. Ne jamais bloquer l’appareil
- 4. Protéger le transport et la confidentialité
- 5. Savoir ce qui est installé
- Ce qu’exigent les textes
- Vos questions sur la mise à jour sécurisée
- Ce que nous faisons avec vous
Un produit connecté vit des années sur le terrain. Pendant ce temps, des vulnérabilités seront découvertes dans son code, dans ses bibliothèques, dans son système d’exploitation. Sans mise à jour à distance, chaque faille reste ouverte jusqu’à la fin de vie du produit.
C’est pourquoi les textes européens en font une exigence. Le Cyber Resilience Act impose de fournir des mises à jour de sécurité pendant toute la période de support, automatiques par défaut lorsque c’est applicable. L’EN 18031, sous la directive RED, définit des exigences pour le mécanisme de mise à jour sécurisée. L’ETSI EN 303 645 en fait une de ses treize recommandations.
Mais le mécanisme de mise à jour est aussi le chemin le plus direct vers le cœur du produit. Il doit donc être conçu comme une fonction de sécurité à part entière.
Les menaces sur une mise à jour
| Attaque | Ce qu’elle vise | Exemple |
|---|---|---|
| Logiciel malveillant | Faire installer son propre firmware | Serveur de mise à jour compromis, paquet modifié en transit |
| Retour en arrière | Réinstaller une ancienne version | Rouvrir une faille déjà corrigée, signée par le fabricant |
| Interception | Lire le firmware | Extraire la propriété intellectuelle ou chercher des failles |
| Déni de service | Bloquer l’appareil | Mise à jour corrompue ou interrompue, appareil hors service |
| Usurpation | Se faire passer pour un appareil | Obtenir les firmwares ou des données d’un autre client |
1. Signer chaque mise à jour, vérifier sur l’appareil
La mesure fondamentale : l’appareil n’installe que ce que le fabricant a signé, et c’est l’appareil qui vérifie la signature, pas le serveur.
- La clé privée de signature reste dans un HSM ou un coffre, utilisé par la chaîne de production des versions, jamais sur un poste de développeur.
- La clé publique est inscrite dans l’appareil de façon non modifiable, idéalement dans la chaîne de démarrage sécurisé : le chargeur vérifie le firmware à chaque démarrage, pas seulement à l’installation.
- La vérification porte sur l’ensemble de ce qui est installé : image, métadonnées, numéro de version, compatibilité matérielle.
Un simple contrôle d’intégrité (somme de contrôle, CRC) ne protège de rien : un attaquant recalcule la somme de son propre fichier.
2. Empêcher le retour à une version vulnérable
Une ancienne version porte une signature valide. Sans protection, un attaquant peut la réinstaller pour exploiter une faille corrigée depuis. La parade est un compteur anti-retour : l’appareil mémorise le niveau de sécurité minimal accepté, dans des fusibles ou une mémoire protégée, et refuse toute version inférieure.
3. Ne jamais bloquer l’appareil
Une coupure de courant ou de réseau pendant l’écriture ne doit pas transformer le produit en brique.
- Partitions A/B : la nouvelle version s’écrit sur la partition inactive ; on bascule seulement quand elle est complète et vérifiée.
- Validation au démarrage : si la nouvelle version ne démarre pas correctement après quelques essais, le chargeur revient automatiquement à la précédente.
- Déploiement progressif : un premier lot d’appareils, une surveillance, puis le reste du parc.
Des outils éprouvés implémentent ces mécanismes : SWUpdate, RAUC ou Mender pour Linux embarqué, MCUboot pour les microcontrôleurs. Les réutiliser vaut presque toujours mieux qu’un développement maison.
4. Protéger le transport et la confidentialité
- TLS avec authentification mutuelle entre l’appareil et le serveur : l’appareil vérifie qu’il parle au bon serveur, le serveur sait quel appareil demande quoi.
- Chiffrement du firmware si la propriété intellectuelle le justifie. La signature garantit l’origine ; le chiffrement empêche la lecture. Ce sont deux mesures distinctes.
- Une identité par appareil : un certificat unique, pour qu’une clé extraite d’un produit ne donne pas accès à tout le parc.
5. Savoir ce qui est installé
Le jour où une vulnérabilité est publiée, il faut savoir quels appareils sont concernés et lesquels ont reçu le correctif. Le CRA impose un signalement sous 24 heures pour une vulnérabilité activement exploitée. Notre article CRA et inventaire logiciel du parc détaille ce point.
Ce qu’exigent les textes
| Texte | Ce qu’il demande |
|---|---|
| Cyber Resilience Act | Mises à jour de sécurité pendant la période de support, automatiques par défaut lorsque c’est applicable, avec possibilité de refus, distinctes des évolutions fonctionnelles quand c’est possible |
| EN 18031 (directive RED) | Un mécanisme de mise à jour sécurisé lorsque le produit peut être mis à jour |
| ETSI EN 303 645 | Logiciel maintenu à jour, mises à jour sécurisées, politique de support publiée |
Vos questions sur la mise à jour sécurisée
Quelle différence entre OTA et FOTA ?
OTA (Over-The-Air) désigne toute mise à jour à distance, souvent du système complet ou d’une application. FOTA (Firmware Over-The-Air) désigne plus précisément la mise à jour du micrologiciel, typiquement sur un microcontrôleur. Les principes de sécurité sont les mêmes.
Faut-il chiffrer le firmware ?
La signature est indispensable, le chiffrement dépend de vos enjeux. Si le firmware contient un savoir-faire à protéger ou des informations utiles à un attaquant, chiffrez-le ; la clé de déchiffrement doit alors être protégée dans l’appareil, par exemple dans un élément sécurisé.
Un microcontrôleur peut-il faire une mise à jour sécurisée ?
Oui. Des chargeurs comme MCUboot vérifient la signature, gèrent deux emplacements et le retour arrière sur des microcontrôleurs courants. Les contraintes de mémoire imposent parfois des choix (mise à jour par échange, image compressée), mais pas de renoncer à la signature.
La mise à jour automatique est-elle obligatoire ?
Le CRA demande, lorsque c’est applicable, que les mises à jour de sécurité s’installent automatiquement par défaut, avec un moyen simple pour l’utilisateur de désactiver ce comportement. Le texte écarte notamment les produits destinés à être intégrés comme composants dans d’autres produits.
Ce que nous faisons avec vous
Nous concevons ou auditons votre chaîne de mise à jour : conception électronique et firmware sécurisés, test d’intrusion embarqué sur le mécanisme existant, et mise en conformité CRA.
La formation Sécuriser la mise à jour des logiciels embarqués (2 jours, en intra) fait concevoir à vos développeurs une chaîne complète : PKI, TLS, bootloader et outils de mise en production.
Vous concevez ou revoyez une mise à jour à distance ? Parlons-en.
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
Expertise cybersécurité IoT, IT, OT et Web.
Découvrir notre équipe
