Fondements scientifiques : systèmes embarqués critiques connectés, surfaces OTA/RF et résilience face aux attaques PDoS

01 — FONDEMENTS

De l’équipement embarqué isolé au système connecté et évolutif

Un système embarqué peut être défini, dans son acception générale, comme un système informatique intégré dans un équipement plus vaste et conçu pour assurer une ou plusieurs fonctions déterminées.

Sa finalité n’est donc pas d’offrir une plateforme informatique généraliste mais de participer directement au fonctionnement d’un dispositif : réguler un moteur, commander un actionneur, exécuter une loi de contrôle, surveiller un patient, gérer une communication radio, traiter les données d’un capteur ou assurer une fonction de sécurité.

Cette définition recouvre néanmoins une très grande diversité.

Un microcontrôleur utilisant quelques dizaines ou centaines de kilo-octets de mémoire, un contrôleur de vol, une passerelle Linux embarquée et un calculateur edge équipé d’un SoC multicœur appartiennent tous à l’univers de l’embarqué, mais leurs contraintes et leurs capacités de défense sont radicalement différentes.

Trois transformations ont particulièrement modifié leur modèle de sécurité.

La première est la connectivité.

De nombreux systèmes autrefois isolés disposent désormais de Wi-Fi, Bluetooth Low Energy, liaisons cellulaires, interfaces radio propriétaires, réseaux industriels ou autres moyens de communication permettant des interactions externes.

La deuxième est la software-defined evolution.

Une part croissante des capacités fonctionnelles de l’équipement dépend de logiciels pouvant être modifiés après son déploiement : firmware, applications, modèles d’intelligence artificielle, configurations ou paramètres opérationnels.

La troisième est la maintenance distante.

Lorsque des millions d’équipements sont distribués géographiquement, leur maintenance manuelle devient économiquement ou opérationnellement impossible. Les mécanismes de mise à jour distante deviennent alors une composante normale du cycle de vie.

Ces trois évolutions produisent un changement fondamental : l’équipement peut continuer à évoluer après avoir quitté son environnement de conception et cette évolution peut être déclenchée à distance.

C’est un avantage opérationnel majeur.

C’est également une nouvelle frontière de confiance.

Système embarqué critique connecté : définition opérationnelle

Le terme « critique » doit être utilisé avec prudence.

Tous les systèmes connectés ne sont pas des systèmes critiques, et tous les systèmes embarqués ne présentent pas les mêmes conséquences lorsqu’ils deviennent indisponibles.

Dans cette recherche, la criticité est envisagée selon plusieurs dimensions complémentaires :

conséquences potentielles sur la sécurité physique ; interruption d’un service essentiel ; perte d’une capacité opérationnelle ; coût ou difficulté de récupération ; perte d’un équipement difficilement accessible ; atteinte à l’intégrité d’un processus cyberphysique ; dépendance d’autres systèmes vis-à-vis de l’équipement compromis. Définition opérationnelle proposée

Pour les besoins du programme de recherche, on désignera comme système embarqué critique connecté un système :

1. dont le fonctionnement logiciel ou firmware contribue directement à une fonction dont la perte peut entraîner une conséquence opérationnelle significative ;

2. disposant d’au moins une interface permettant une interaction distante, directement ou indirectement ;

3. possédant un état logiciel ou de configuration persistant susceptible d’être modifié ;

4. et pour lequel la corruption de cet état peut produire une indisponibilité durable ou rendre la récupération sensiblement plus difficile qu’un simple redémarrage.

Cette définition est volontairement orientée vers la problématique étudiée.

Elle ne cherche pas à remplacer les définitions normatives propres à l’automobile, au médical, au spatial ou à l’industrie.

Elle sert à identifier les propriétés communes nécessaires à l’étude des scénarios PDoS.

Hétérogénéité des plateformes et conséquences pour la sécurité

La première difficulté scientifique de cette recherche tient à l’hétérogénéité.

Deux équipements exposés à une même catégorie d’attaque peuvent présenter des chaînes de démarrage, des mécanismes de mise à jour et des capacités de récupération complètement différents.

On peut distinguer plusieurs familles architecturales.

Famille Architecture typique Contraintes dominantes Exemples MCU contraints Cortex-M, RISC-V MCU mémoire, énergie, temps réel contrôleurs, capteurs, objets connectés Contrôleurs cyberphysiques MCU + RTOS déterminisme, sûreté, actionnement Pixhawk, robotique, drones Linux embarqué Cortex-A / SBC surface logicielle plus large gateways, edge devices Edge AI SoC multicœur + accélérateur puissance, complexité logicielle Jetson Orin Plateformes mobiles SoC + OS complexe boot chain, OTA, isolation Android Systèmes spécialisés architectures spécifiques accessibilité, sûreté, endurance spatial, industriel, médical

La conséquence est immédiate : une méthode conçue pour Linux ne peut pas être supposée applicable telle quelle à un microcontrôleur.

Inversement, une méthode suffisamment légère pour un MCU peut ne pas disposer de la richesse d’observation disponible sur un système Linux.

La portabilité recherchée dans ce programme ne doit donc pas être comprise comme la reproduction à l’identique du même code ou du même modèle sur chaque système.

Elle correspond plutôt à la recherche d’un socle méthodologique portable :

catégories de signaux observables ; principes de détection ; architecture de décision ; métriques d’évaluation ; logique de récupération ; méthode d’expérimentation.

Les implémentations pourront rester spécifiques à chaque plateforme.

02 — ARCHITECTURE

Architecture fonctionnelle générique

Malgré cette hétérogénéité, une représentation conceptuelle commune peut être construite.

Pour cette recherche, un système connecté susceptible d’être exposé à un PDoS peut être représenté par six couches.

Couche 1 — Matériel

Elle comprend le processeur ou microcontrôleur, les mémoires volatiles et non volatiles, les périphériques, les bus internes, les composants de sécurité matériels et les interfaces radio.

Elle constitue la racine physique du système.

Couche 2 — Racine de confiance et démarrage

Cette couche peut comprendre, selon les architectures :

ROM de démarrage ; bootloader ; mécanismes Secure Boot ; clés enracinées matériellement ; TPM ou composants similaires ; Trusted Execution Environment ; mécanismes de vérification de l’intégrité.

Son rôle est déterminant, car une compromission suffisamment profonde de la chaîne de démarrage peut empêcher les couches supérieures de rétablir un état fiable.

Couche 3 — Firmware / système d’exploitation

Elle comprend le firmware principal, le RTOS ou l’OS embarqué ainsi que certains composants critiques exécutés avec des privilèges élevés.

Couche 4 — Applications et logique métier

Cette couche réalise la fonction opérationnelle du système.

Dans un environnement cyberphysique, elle peut être directement liée à des actionneurs ou à des décisions physiques.

Couche 5 — Gestion et mise à jour

Cette couche regroupe les mécanismes d’administration, configuration, provisioning, FOTA/SOTA, récupération et gestion du cycle de vie logiciel.

Couche 6 — Interfaces de communication

Elle représente les moyens par lesquels des données et commandes atteignent le système :

Wi-Fi, BLE, Ethernet, cellulaire, radio dédiée, USB, bus locaux, protocoles applicatifs, interfaces de télémaintenance, etc.

Cette distinction est importante car le canal de communication et le mécanisme effectivement exploité ne doivent pas être confondus.

Une attaque peut utiliser une liaison radio comme moyen d’accès tout en exploitant une vulnérabilité située dans une application ou dans le processus OTA.

03 — SURFACE OTA

OTA : mettre à jour un système revient à lui accorder le droit de se transformer

La mise à jour distante est devenue une composante normale de la sécurité.

Un équipement non maintenable est difficile à protéger dans la durée : les vulnérabilités découvertes après son déploiement doivent pouvoir être corrigées.

L’OTA permet notamment :

de corriger des vulnérabilités ; d’améliorer le fonctionnement du système ; de renouveler des clés ou certificats ; de modifier une configuration ; d’ajouter des fonctionnalités ; de traiter des problèmes découverts après commercialisation.

L’OTA n’est donc pas un problème de sécurité en soi.

Un mécanisme OTA correctement conçu est au contraire un mécanisme de sécurité essentiel.

Le paradoxe est qu’il possède, par définition, la capacité que rechercherait également un attaquant : modifier l’état logiciel persistant de l’équipement.

La chaîne de confiance d’une mise à jour

Une mise à jour ne doit pas être considérée comme un simple téléchargement de fichier.

Il s’agit d’une chaîne de confiance.

Elle peut comprendre :

production de l’image → signature → publication → distribution → réception → vérification → installation → démarrage → validation → récupération éventuelle

Une compromission peut se produire à différents niveaux.

Elle peut concerner :

le système de construction ; les clés de signature ; le serveur de publication ; l’infrastructure de distribution ; le protocole de communication ; le parseur ou le gestionnaire de mise à jour ; la vérification cryptographique ; le mécanisme de version ; l’écriture en mémoire ; le choix de la partition de démarrage ; la procédure de rollback ; le système de récupération.

Cette approche est particulièrement importante parce que TLS seul n’est pas une garantie suffisante de sécurité du firmware.

La protection du transport ne remplace pas la vérification de l’objet distribué.

Les frameworks modernes de secure update cherchent précisément à maintenir une confiance sur les métadonnées, versions et artefacts même lorsque certains composants du système de distribution sont compromis. Dans le domaine automobile, Uptane est un exemple particulièrement structuré : son modèle vise notamment à limiter les conséquences de la compromission de certains composants et à faciliter la récupération lorsqu’une compromission survient. [R3]

Propriétés de sécurité attendues d’un mécanisme OTA

Pour l’analyse menée dans ce programme, plusieurs propriétés doivent être distinguées.

Authenticité

Le système doit pouvoir déterminer si la mise à jour provient d’une autorité habilitée.

Intégrité

L’artefact installé doit correspondre exactement à celui qui a été approuvé.

Fraîcheur et gestion des versions

Une image authentique mais vulnérable ne doit pas nécessairement pouvoir être réinstallée.

D’où l’importance de mécanismes anti-rollback adaptés.

Atomicité de l’installation

Une interruption pendant l’écriture ne doit pas laisser le système dans un état impossible à récupérer.

Séparation de l’état actif et de l’état de récupération

Les architectures A/B, recovery partitions ou autres mécanismes redondants permettent de réduire le risque qu’une mise à jour défectueuse détruise simultanément le système actif et son moyen de récupération.

Vérification après installation

Une image correctement écrite n’est pas nécessairement fonctionnelle.

Des health checks peuvent être nécessaires avant de considérer la nouvelle version comme valide.

Récupération

Un mécanisme de mise à jour sécurisé doit également prévoir ce qui se passe lorsque la protection échoue.

C’est précisément cette dernière dimension qui rapproche la sécurité OTA de la firmware resiliency.

Firmware resilience : protéger ne suffit pas

La cybersécurité traditionnelle insiste légitimement sur la prévention.

Mais les attaques destructrices obligent à considérer l’hypothèse suivante :

que se passe-t-il lorsque la protection est contournée ?

Le NIST SP 800-193 construit la résilience du firmware autour de trois propriétés fondamentales : [R2]

Protection : empêcher les modifications non autorisées ;

Detection : identifier une modification lorsqu’elle s’est néanmoins produite ;

Recovery : restaurer rapidement le système vers un état d’intégrité connu.

Cette logique est centrale dans la présente recherche.

Une architecture capable d’empêcher 99 % des modifications mais incapable de récupérer après le 1 % restant peut rester extrêmement vulnérable face à un scénario PDoS.

La résilience ne remplace donc pas la sécurité préventive.

Elle en constitue le prolongement lorsque la prévention échoue.

04 — SURFACE RF

Communications radio : distinguer le médium, le protocole et la fonction

Les communications radio occupent une place importante dans ce programme, mais leur rôle doit être défini précisément.

Le terme RF désigne ici la dimension radiofréquence du canal de communication.

Une attaque dite « via RF » peut pourtant exploiter des couches très différentes.

• Par exemple :
• Couche physique brouillage, interférence, modulation ou caractéristiques du signal
• Couche liaison trames de management, association, authentification locale
• Couche réseau ou transport sessions IP, routage, protocoles
• Couche applicative commandes, télémétrie, provisioning

Couche de maintenance mise à jour logicielle ou firmware transportée par le canal.

Cette séparation empêchera une confusion fréquente : le support radio n’est pas nécessairement la vulnérabilité.

Un paquet malveillant transmis par Wi-Fi peut exploiter une vulnérabilité de parsing dans l’application.

Une commande MAVLink peut être transportée sur une liaison radio, UDP ou série.

MAVLink est donc un protocole de messages, pas une technologie RF. MAVLink 2 dispose par ailleurs d’un mécanisme de signature permettant l’authentification des messages, même si son utilisation dépend de la configuration du système. [R4]

Familles de connectivité pertinentes

Plusieurs familles seront considérées dans l’état de l’art, sans supposer qu’elles présentent toutes le même risque PDoS.

Communications de proximité Bluetooth / BLE ; Wi-Fi ; NFC ; IEEE 802.15.4 et technologies associées. Communications longue portée réseaux cellulaires ; LPWAN ; liaisons radio propriétaires ; communications de drones. Communications spécialisées télémétrie industrielle ; systèmes de commande sans fil ; communications spatiales.

Le critère déterminant ne sera pas simplement la technologie.

La question sera plutôt :

Le canal fournit-il à distance un chemin permettant d’atteindre un composant dont la modification persistante peut affecter la disponibilité ?

C’est cette condition qui rend la communication pertinente pour la problématique PDoS.

05 — DE DoS À PDoS

Du DoS au PDoS : la persistance comme critère central

Le terme PDoS peut être trompeur si le mot « Permanent » est interprété uniquement comme une destruction physique définitive.

Les travaux récents consacrés au sujet décrivent les PDoS comme des attaques cherchant une dégradation durable ou irréversible, notamment à travers la corruption du firmware, du processus de démarrage ou d’autres composants essentiels. La littérature dédiée reste néanmoins beaucoup moins abondante que celle consacrée aux DoS traditionnels.

Pour cette recherche, la distinction sera principalement fondée sur le mode de récupération.

DoS temporaire

Le service revient lorsque :

l’attaque cesse ; la ressource est libérée ; le système redémarre normalement ; la communication est rétablie. Dégradation persistante

Le système reste indisponible après la disparition de l’attaque et nécessite :

une intervention administrative privilégiée ; une restauration ; un reflash ; une réinitialisation hors bande ; un rollback sécurisé ; une procédure de recovery. PDoS sévère

La récupération normale n’est plus disponible et peut nécessiter :

un accès matériel ; un équipement de programmation ; une intervention constructeur ; le remplacement d’un composant ou du système.

Cette gradation est plus utile expérimentalement qu’une classification simplement binaire.

Définition opérationnelle du PDoS retenue pour le projet

La définition de travail suivante sera utilisée dans les premières expérimentations :

Une attaque PDoS est une action intentionnelle dont l’objectif ou l’effet est de provoquer une perte persistante de disponibilité en altérant un état logiciel, firmware, configurationnel ou matériel essentiel, de telle sorte que la restauration du service exige une procédure de récupération différente du fonctionnement ou du redémarrage normal du système.

Cette définition a plusieurs avantages.

Elle permet de distinguer un PDoS :

d’un simple flooding réseau ; d’un brouillage temporaire ; d’un crash logiciel suivi d’un redémarrage automatique réussi ; d’une interruption électrique sans corruption persistante.

Elle permet aussi d’étudier plusieurs niveaux de gravité sans exiger systématiquement la destruction physique de l’équipement.

Une autre distinction nécessaire : PDoS et compromission persistante

Une compromission persistante n’est pas nécessairement un PDoS.

Un attaquant peut maintenir un accès durable à un équipement tout en conservant celui-ci opérationnel.

À l’inverse, un PDoS peut viser précisément à empêcher le système de fonctionner.

Les objectifs sont différents :

Persistence attack : maintenir le contrôle.

PDoS : détruire ou neutraliser durablement la capacité opérationnelle.

Il existe néanmoins une zone de recouvrement.

Un implant persistant peut être utilisé dans une deuxième phase pour déclencher un sabotage, corrompre un firmware ou empêcher une récupération.

Cette distinction sera importante lors de la construction du modèle de menace.

Surfaces persistantes particulièrement sensibles

Plusieurs composants méritent une attention particulière.

Firmware

Une corruption du firmware peut affecter directement le fonctionnement de l’équipement.

Bootloader

Une compromission du bootloader peut intervenir avant le chargement du système principal et compromettre les mécanismes supérieurs de récupération.

Données critiques de démarrage

Partitions, métadonnées, tables, configuration de boot ou autres informations indispensables au lancement du système.

Configuration persistante

Dans certains systèmes cyberphysiques, une configuration incohérente peut empêcher le retour à un état opérationnel même si le code reste intact.

Clés et données de confiance

La perte ou la corruption de certaines clés peut empêcher l’équipement d’accepter ultérieurement des mises à jour légitimes.

Recovery environment

Un attaquant qui parvient à compromettre simultanément le système principal et le mécanisme de récupération transforme une compromission déjà grave en problème de résilience.

C’est pourquoi une architecture de recovery doit être considérée comme une frontière de confiance à part entière.

06 — ENVIRONNEMENTS EXPOSÉS

Des systèmes critiques aux plateformes expérimentales

L’ancien périmètre de recherche identifiait six domaines.

Ils restent utiles comme domaines de réflexion et de comparaison, mais ils ne doivent plus être confondus avec les trois bancs expérimentaux effectivement envisagés.

16.1 Automobile et systèmes de conduite assistée

Le véhicule moderne constitue un exemple majeur de système cyberphysique complexe.

Il combine :

dizaines de calculateurs ; réseaux internes ; interfaces télématiques ; capteurs ; actuateurs ; mécanismes OTA ; logiciels provenant de nombreux fournisseurs.

Les conséquences d’une compromission ne se limitent donc pas à la confidentialité.

Elles peuvent concerner :

disponibilité fonctionnelle ; sûreté ; capacité à démarrer ; maintenance ; intégrité de certains calculateurs.

La cybersécurité automobile fait désormais l’objet d’un cadre structuré. ISO/SAE 21434 traite de la gestion des risques cybersécurité tout au long du cycle de vie des systèmes électriques et électroniques des véhicules, tandis que le règlement ONU R155 introduit des exigences relatives aux systèmes de management de la cybersécurité automobile. [R5] [R6]

Le framework Uptane fournit par ailleurs un cas de référence particulièrement intéressant pour la sécurisation des mises à jour logicielles des véhicules.

Dans ce programme, Jetson Orin ne sera pas présenté comme un calculateur ADAS opérationnel.

Il servira comme plateforme expérimentale représentative d’un environnement Linux embarqué/edge AI relativement puissant.

Drones et contrôleurs de vol

Le drone constitue probablement le banc le plus directement cyberphysique du projet.

Son logiciel est relié à :

des capteurs inertiels ; des moteurs ; des contrôleurs ; une navigation ; des communications ; des décisions physiques immédiates.

Une réaction de sécurité inappropriée peut donc avoir elle-même des conséquences négatives.

Le problème ne consiste pas uniquement à détecter une commande suspecte.

Il faut déterminer :

quelle réponse préservera le mieux l’état sûr du système ?

Pour un contrôleur de vol, couper brutalement une fonction n’est pas toujours acceptable.

Une réponse peut devoir privilégier :

l’ignorance d’une commande ; un changement de mode ; la limitation des capacités ; le retour automatique ; un atterrissage contrôlé.

Ce banc permettra ainsi d’étudier la frontière entre cybersécurité, résilience et sûreté de fonctionnement.

Dispositifs médicaux

Les dispositifs médicaux illustrent particulièrement bien cette convergence entre security et safety.

La FDA considère désormais explicitement les risques cybersécurité dans le cycle de vie de certains « cyber devices » et exige notamment, pour les dispositifs concernés, des capacités de gestion des vulnérabilités et correctifs. Ses orientations de cybersécurité pour les dispositifs médicaux ont encore été actualisées en 2025 puis en 2026. [R7]

Dans ce domaine, la disponibilité ne peut pas être analysée indépendamment de la sécurité du patient.

Cette contrainte produit un problème particulièrement intéressant :

une contre-mesure de cybersécurité peut-elle être considérée comme correcte si elle neutralise une fonction vitale pour empêcher une compromission ?

La réponse est évidemment dépendante du contexte.

C’est précisément pourquoi une logique de réponse graduée et d’état sûr doit être analysée avec prudence.

Le biomédical restera néanmoins, dans la première phase de ce programme, un domaine d’étude de littérature et non un banc expérimental réel.

IoT et équipements edge

Les équipements IoT et passerelles représentent un environnement particulièrement intéressant car ils combinent souvent :

connectivité permanente ; firmware modifiable ; maintenance distante ; contraintes matérielles ; durée de vie longue ; forte hétérogénéité des fabricants.

L’histoire de BrickerBot en 2017 constitue l’un des exemples les plus connus de PDoS ciblant des appareils connectés. L’attaque recherchait explicitement la destruction ou la corruption de fonctions et du stockage des équipements compromis afin de les rendre inutilisables. Elle doit toutefois être décrite avec précision : certains chiffres largement repris en ligne sur le nombre total d’équipements détruits ne disposent pas toujours de la même solidité documentaire. [R10]

Les architectures IoT constituent également un domaine couvert par plusieurs référentiels de sécurité. La recommandation ITU-T X.1361, par exemple, analyse les menaces touchant les dispositifs, passerelles, réseaux et plateformes/services et décrit différentes capacités de sécurité associées. [R8]

Terminaux Android comme plateforme comparative

Le smartphone Android mérite un traitement particulier.

Un smartphone moderne n’est pas nécessairement un « système embarqué critique » au sens strict retenu dans les domaines safety-critical.

Il constitue néanmoins une excellente plateforme comparative pour cette recherche en raison de la sophistication de sa chaîne logicielle.

Android permet notamment d’étudier :

chaîne de démarrage ; partitions ; mécanismes de vérification ; mises à jour A/B selon les appareils ; recovery ; logs ; Wi-Fi ; Bluetooth ; connectivité cellulaire ; stockage persistant.

Le smartphone Android jouera donc un rôle méthodologique important :

tester la capacité de l’approche à passer d’un contrôleur cyberphysique ou d’un environnement Linux edge vers une plateforme mobile industrielle complexe.

Spatial et systèmes difficilement récupérables

Les environnements spatiaux représentent un cas limite particulièrement instructif.

Lorsqu’un équipement se trouve physiquement inaccessible, la récupération devient une propriété critique de son architecture.

Une erreur ou compromission logicielle qui serait réparable en quelques minutes sur un système au sol peut devenir catastrophique dans un environnement distant.

Les architectures spatiales modernes mettent donc fortement l’accent sur :

redondance ; safe mode ; watchdogs ; télécommande ; récupération ; tolérance aux fautes.

Le spatial ne fera pas partie de la première vague expérimentale.

Il demeure néanmoins un excellent domaine de comparaison pour la notion de résilience face à une perte d’accès physique.

Les trois bancs expérimentaux retenus

Le programme expérimental commence volontairement avec seulement trois environnements.

NVIDIA Jetson Orin

Objectif principal :

étudier la chaîne sur une plateforme Linux embarquée disposant de ressources de calcul significatives.

Cette plateforme servira notamment au prototypage initial de :

collecte de télémétrie ; preprocessing ; modèles de détection ; logique de décision ; mécanismes de récupération expérimentaux. Pixhawk / MAVLink

Objectif principal :

introduire la dimension cyberphysique et les contraintes de temps réel et de sûreté.

Android

Objectif principal :

étudier la portabilité vers un système mobile industriel présentant une boot chain et des mécanismes OTA plus complexes.

Ces trois plateformes ne représentent évidemment pas l’ensemble des systèmes embarqués.

Elles constituent des points d’ancrage suffisamment différents pour tester la généralisabilité de la méthode.

07 — OBSERVABILITÉ & RÉSILIENCE

Observer, détecter, décider et récupérer

Une attaque visant la persistance ne produit pas nécessairement un indicateur unique.

Selon sa nature, elle peut modifier :

le comportement logiciel ; les accès mémoire ; le temps d’exécution ; la charge CPU ; la consommation ; la température ; les séquences de démarrage ; le trafic ; les journaux ; certains signaux physiques.

L’un des axes centraux du projet sera donc de comparer plusieurs catégories d’observation.

Données logicielles événements système ; erreurs ; logs ; changements de configuration ; appels ou opérations sensibles ; état des processus. Données de performance CPU ; mémoire ; I/O ; délais ; contention ; timings. Données de communication événements réseau ; séquences de commandes ; fréquence des messages ; erreurs protocolaires. Données physiques

Lorsque cela est accessible :

courant ; tension ; température ; activité électromagnétique.

Cette dernière catégorie constitue une hypothèse particulièrement intéressante mais doit être traitée avec prudence.

Une signature électromagnétique observable n’est pas automatiquement une signature d’attaque.

L’un des objectifs sera précisément de déterminer si elle apporte une information discriminante au-delà des données déjà disponibles dans le logiciel.

Pourquoi envisager une fusion multi-source ?

La principale motivation de la fusion n’est pas de multiplier les capteurs pour augmenter artificiellement la complexité.

Elle repose sur une hypothèse simple :

plus une attaque agit profondément sur un système, plus elle peut modifier simultanément plusieurs dimensions de son comportement.

Une opération de flash peut, par exemple, avoir des conséquences :

logicielles ; temporelles ; énergétiques ; éventuellement thermiques.

Mais cela ne signifie pas que toutes ces données seront utiles.

La recherche devra donc répondre à plusieurs questions :

Quels signaux sont réellement discriminants ?

Quels signaux sont redondants ?

Quel est le coût de leur acquisition ?

La fusion améliore-t-elle réellement la détection ?

Est-elle portable ?

La suppression d’une source dégrade-t-elle significativement les performances ?

C’est ici que les futures études d’ablation auront un rôle essentiel.

Place de TinyML dans le programme

TinyML ne doit pas devenir une réponse décidée avant l’expérimentation.

Il s’agit d’une option technologique à évaluer.

Le raisonnement est le suivant.

Une détection centralisée peut nécessiter :

transmission permanente de télémétrie ; connectivité ; infrastructure externe ; latence supplémentaire.

Une détection effectuée localement peut réduire certaines de ces dépendances.

Mais elle impose d’autres contraintes :

mémoire ; CPU ; énergie ; stockage ; complexité du modèle ; maintenabilité.

Le projet comparera donc plusieurs familles de méthodes, potentiellement :

seuils déterministes ; méthodes statistiques ; machine learning classique ; réseaux légers ; modèles séquentiels lorsque cela est pertinent.

TinyML sera retenu lorsque son bénéfice pourra être mesuré, et non simplement parce qu’il constitue une technologie attractive.

Détecter n’est pas décider

• Un principe architectural important du projet consiste à séparer deux fonctions :
• la détection
• et

la décision de réponse.

Un modèle peut produire une probabilité ou un score d’anomalie.

Ce résultat ne signifie pas automatiquement :

isoler le système.

Une décision doit prendre en compte :

confiance du modèle ; persistance de l’anomalie ; criticité de l’action ; état opérationnel ; disponibilité d’un mode sûr ; conséquences d’un faux positif.

Cette séparation est particulièrement critique pour les systèmes cyberphysiques.

Une erreur de détection ne doit pas devenir elle-même une cause d’accident ou d’indisponibilité.

Principe de réponse graduée

Le projet étudiera une politique de réponse graduée.

À ce stade, cette gradation constitue une architecture conceptuelle, et non un mécanisme validé.

Niveau 0 — Observation

Fonctionnement normal et collecte.

Niveau 1 — Suspicion

Augmentation de la télémétrie et création d’un événement.

Niveau 2 — Restriction

Limitation temporaire d’une fonction sensible.

Niveau 3 — Isolation

Neutralisation de la surface suspectée lorsque le contexte l’autorise.

Niveau 4 — Recovery

Retour vers une configuration ou image connue comme fiable.

Niveau 5 — Safe state

Maintien du système dans un état minimal considéré comme sûr jusqu’à intervention ou validation.

Chaque plateforme devra disposer de sa propre interprétation de ces niveaux.

Le safe state d’un drone n’est pas celui d’une passerelle Linux.

Continuité minimale et sûreté

Cette recherche ne considère pas la disponibilité uniquement comme une variable binaire.

Un système peut être :

pleinement opérationnel ; partiellement dégradé ; isolé ; en mode secours ; récupérable ; non récupérable.

Cette distinction est particulièrement importante dans les systèmes cyberphysiques.

La meilleure réaction à une compromission n’est pas nécessairement celle qui maximise la sécurité informatique au sens strict.

Elle peut être celle qui préserve suffisamment longtemps une fonction minimale pour atteindre un état physique sûr.

La cybersécurité rencontre ici directement la sûreté de fonctionnement.

Environnements à capacités contraintes et souveraineté technologique

Une dimension complémentaire de cette recherche concerne les environnements où la capacité d’évaluation et de maintenance des équipements est limitée.

Cette question est particulièrement pertinente pour de nombreux déploiements dans les pays où :

une grande partie des équipements complexes est importée ; le firmware reste sous le contrôle du constructeur ; les capacités de laboratoire sont limitées ; les cycles de remplacement sont longs ; les mécanismes de mise à jour dépendent de fournisseurs extérieurs.

Il faut néanmoins éviter une conclusion trop générale selon laquelle ces environnements seraient nécessairement « moins sécurisés ».

Le problème scientifique peut être formulé plus précisément :

Comment évaluer la résilience d’un équipement lorsque l’organisation qui l’exploite ne contrôle ni sa chaîne de développement ni son firmware ?

Cette question dépasse la seule analyse des vulnérabilités.

Elle concerne :

l’assurance ; la transparence ; l’homologation ; la certification ; les exigences d’achat ; le cycle de support ; le droit à recevoir des correctifs. 30. Une évolution réglementaire qui confirme l’importance de la cybersécurité des équipements

Les exigences relatives à la cybersécurité des produits connectés se renforcent progressivement.

Dans l’Union européenne, les exigences cybersécurité ajoutées à la Radio Equipment Directive pour certaines catégories d’équipements radio sont désormais appuyées par la série harmonisée EN 18031 ; la Commission a publié en janvier 2025 les références correspondantes. Les normes ont été élaborées dans le cadre d’un mandat adressé à CEN et CENELEC. [R9]

Dans l’automobile, ISO/SAE 21434 et le règlement ONU R155 structurent déjà une partie importante des processus de gestion du risque cybersécurité.

Dans le médical, les exigences et recommandations FDA relatives aux « cyber devices » renforcent également les attentes relatives à la gestion des vulnérabilités, au cycle de vie logiciel et aux correctifs.

Ces évolutions montrent que la sécurité des équipements connectés n’est plus seulement un problème de configuration réseau.

Elle devient une propriété du cycle de vie du produit.

Ce que les défenses actuelles savent déjà faire

Il serait incorrect de présenter les PDoS comme un problème dépourvu de mécanismes de défense.

De nombreuses briques existent déjà.

Secure Boot

Il peut empêcher le démarrage d’un code non approuvé.

Signature du firmware

Elle permet d’authentifier l’artefact distribué.

Anti-rollback

Il limite le retour vers une version devenue vulnérable.

A/B update

Il permet de préparer une nouvelle version sans écraser immédiatement l’état fonctionnel connu.

Recovery

Il fournit une voie de restauration.

Watchdog

Il permet de récupérer de certaines défaillances d’exécution.

Attestation et mesure

Elles peuvent contribuer à déterminer l’état d’intégrité.

IDS et monitoring

Ils permettent d’identifier certains comportements anormaux.

La question scientifique n’est donc pas :

« Pourquoi personne n’a-t-il pensé à protéger le firmware ? »

La vraie question est beaucoup plus intéressante.

08 — LACUNE SCIENTIFIQUE

Le problème n’est pas l’absence de défenses

Le problème étudié se situe à l’intersection de plusieurs domaines déjà matures séparément :

• secure update
• firmware resilience
• anomaly detection
• cyber-physical security
• embedded machine learning
• communications radio

recovery et safe state.

La recherche cherche à déterminer si ces dimensions peuvent être combinées dans une architecture suffisamment cohérente pour permettre :

• 1. d’observer un comportement précurseur ou associé à une compromission persistante
• 2. d’estimer localement le niveau d’anomalie
• 3. de distinguer autant que possible une attaque d’une défaillance bénigne
• 4. de décider d’une réaction proportionnée
• 5. de préserver ou restaurer un état opérationnel fiable

6. et d’appliquer le même raisonnement méthodologique à plusieurs architectures.

Ce dernier point est probablement le plus difficile.

Ce que cette recherche ne doit pas supposer

Plusieurs hypothèses séduisantes devront rester ouvertes.

Il ne faut pas supposer que :

toutes les attaques PDoS produisent une signature précoce ; les signaux physiques améliorent systématiquement la détection ; TinyML sera toujours préférable à une approche déterministe ; un modèle entraîné sur une plateforme fonctionnera sur une autre ; une réponse automatique sera toujours plus sûre qu’une intervention externe ; une architecture universelle existe ; toute corruption de firmware peut être récupérée.

Au contraire, démontrer que l’une de ces hypothèses est fausse pourrait constituer un résultat scientifique utile.

Première formulation de l’espace de recherche

À ce stade, le programme peut être résumé par six objets.

Objet 1 — Threat model

Identifier les chemins pouvant conduire d’une exposition OTA ou distante à une dégradation persistante.

Objet 2 — Observability

Identifier les signaux disponibles avant et pendant la compromission.

Objet 3 — Detection

Déterminer si ces signaux permettent une classification suffisamment fiable.

Objet 4 — Embedded feasibility

Mesurer le coût réel de cette détection.

Objet 5 — Decision

Transformer une détection probabiliste en une décision opérationnelle maîtrisée.

Objet 6 — Recovery

Mesurer la capacité du système à revenir vers un état d’intégrité connu.

Ces six objets constitueront le fil directeur des travaux suivants.

09 — SUITE DES TRAVAUX

Questions ouvertes et prochaine étape

Cette note conduit naturellement à plusieurs questions.

À partir de quel niveau de persistance une indisponibilité doit-elle être considérée comme PDoS ?

Comment distinguer une attaque destructrice d’une panne produisant les mêmes symptômes ?

Quels événements sont observables avant la corruption irréversible ?

Une fusion de télémétrie logicielle et physique améliore-t-elle effectivement cette détection ?

Quel compromis existe entre temps de détection et taux de faux positifs ?

Peut-on déployer cette détection localement sans perturber la fonction principale du système ?

Comment décider automatiquement d’un rollback ou d’un safe mode lorsqu’une classification reste probabiliste ?

Quelle partie du pipeline peut réellement être portée de Jetson à Pixhawk puis Android ?

Ce sont ces questions qui transformeront progressivement le projet d’un cadre conceptuel en programme expérimental.

Positionnement des prochaines étapes

À l’issue de cette première note, la suite logique du travail ne consiste pas encore à entraîner immédiatement un modèle TinyML.

La prochaine étape doit être la construction d’un modèle de menace formel.

Celui-ci devra définir :

actifs ; frontières de confiance ; capacités des adversaires ; préconditions ; surfaces OTA ; surfaces de communication ; mécanismes de persistance ; scénarios d’altération ; états de récupération ; conditions de succès et d’échec.

Ce travail devra également permettre de construire une taxonomie précise distinguant :

accès initial → compromission → modification persistante → perte de disponibilité → récupération ou non-récupération.

Ce n’est qu’après cette étape qu’un plan expérimental pourra être correctement dérivé.

Synthèse

Cette première note établit plusieurs principes.

Les systèmes étudiés sont devenus profondément dépendants de logiciels modifiables et de communications distantes.

Cette évolution rend indispensable la mise à jour logicielle, mais transforme également la chaîne de maintenance en surface de confiance critique.

Le canal radio doit être considéré comme un vecteur de communication dont l’exploitation réelle peut se situer à différentes couches.

Le PDoS se distingue principalement du déni de service temporaire par la persistance de l’état indisponible et la complexité de récupération, plutôt que par l’obligation d’une destruction physique.

Les défenses pertinentes ne se limitent pas à empêcher l’attaque.

Elles doivent être pensées dans une chaîne plus large :

protéger → observer → détecter → décider → contenir → récupérer → vérifier

La difficulté scientifique réside enfin moins dans l’existence individuelle de chacun de ces mécanismes que dans leur intégration cohérente sous contraintes embarquées et dans leur portabilité entre systèmes hétérogènes.

C’est sur ce problème que se concentre la suite du programme.