Modèle de menace OTA/RF : de l’exposition distante à l’indisponibilité persistante des systèmes embarqués

RÉSUMÉ

Portée de la Note 02

Une liaison radio perturbée, une mise à jour rejetée et un équipement incapable de retrouver un fonctionnement fiable décrivent des situations différentes. Les réunir sous une même étiquette PDoS rendrait les mesures difficiles à interpréter et pourrait conduire à attribuer à un détecteur une capacité qu’il n’a pas démontrée. Cette note propose un modèle de menace qui relie un accès distant, des capacités adverses explicites, une frontière de confiance, un mécanisme d’altération, un état persistant et une conséquence sur le service. Elle précise également les observations nécessaires pour qualifier cette conséquence et pour vérifier la récupération.

Le périmètre initial porte sur les altérations logicielles et de configuration, étudiées dans des environnements réversibles. La destruction physique directe est exclue. Les scénarios T01 à T05 structurent la préparation des essais sur les plateformes envisagées : Jetson Orin, Pixhawk et Android. Le cadre distingue la détection d’une anomalie, la caractérisation d’un effet persistant et l’attribution de sa cause. Cette note présente le modèle de menace et les critères d’évaluation ; leur validation expérimentale constitue l’étape suivante du projet.

1. De la Note 01 à une question vérifiable

La Note 01 fixe le vocabulaire et le périmètre général du projet : systèmes embarqués connectés, mécanismes OTA, interfaces radio, états persistants et résilience [P1]. La page du programme organise ces questions autour de l’observabilité, de la fusion de données, de la classification locale, de la réponse graduée et de la portabilité [P2]. La présente note transforme ce cadrage en objets que l’on pourra décrire avant un essai, observer pendant son déroulement et confronter à des critères annoncés à l’avance.

La question de cette étape est la suivante : quelles conditions et quelles preuves permettraient de relier une interaction distante à une indisponibilité persistante, puis de démontrer un retour à un état de fonctionnement fiable dans un périmètre donné ? Cette question précède la sélection d’un algorithme. Un modèle capable de reconnaître un changement de charge ne démontre pas, par cette seule capacité, qu’il détecte une compromission du firmware.

Le modèle s’appuie sur les sources citées pour définir les mécanismes étudiés et propose des critères de qualification propres au projet. L’évaluation sur banc devra confronter ces critères au comportement d’une configuration identifiée. Les mécanismes décrits dans une documentation constructeur et les propriétés observées expérimentalement constituent ainsi deux niveaux de connaissance distincts.

2. Définir le système et le service avant de qualifier sa perte

2.1. Une disponibilité relative à une fonction

Le système étudié comprend l’équipement, ses composants logiciels essentiels et les dépendances nécessaires au service retenu. Pour une passerelle, il pourrait s’agir de transmettre des mesures authentifiées ; pour un contrôleur de vol, de maintenir une fonction de contrôle spécifiée dans un environnement simulé ; pour une plateforme mobile, d’exécuter un service de test défini. Le choix doit être suffisamment étroit pour rendre un échec observable. « Le système fonctionne » ne constitue pas un critère de mesure.

Chaque protocole définira donc un contrat de service expérimental : fonction attendue, entrées de référence, sorties acceptables, délai maximal, conditions de sécurité opérationnelle et dépendances autorisées. On pourra noter A(t) la satisfaction de ce contrat à l’instant t. Une réponse réseau ou un démarrage réussi est une observation utile, mais ne prouve pas à elle seule que le service est correctement rendu. Inversement, la perte de contact avec l’observateur ne suffit pas à prouver l’arrêt de l’équipement.

2.2. Un état persistant n’est pas nécessairement compromis

Pour organiser les observations, l’état persistant est décomposé en quatre ensembles : code de démarrage et firmware ; configuration et données critiques ; éléments de confiance et politiques de version ; ressources nécessaires à la récupération. Cette décomposition est proposée pour le projet. Elle ne présume pas que tous ces ensembles sont accessibles à l’instrumentation ou modifiables sur chaque plateforme.

Une écriture persistante peut être parfaitement légitime. Une mise à jour autorisée change durablement le logiciel ; l’enregistrement d’un paramètre peut survivre au redémarrage sans dégrader le service. Le protocole doit rechercher une modification pertinente pour l’effet étudié, et non interpréter toute différence d’empreinte comme une compromission. Les zones volatiles, les journaux et les données naturellement variables devront être distingués des artefacts dont la stabilité ou la version est attendue.

2.3. Une durée longue ne suffit pas à définir un PDoS

La littérature sur le PDoS traite d’atteintes durables, voire irréversibles, touchant le logiciel ou le matériel [S1]. Le projet retient un périmètre initial plus limité : l’indisponibilité associée à une altération logicielle ou de configuration qui persiste après la fin de l’action initiale et ne disparaît pas par les mécanismes ordinaires de reprise définis pour le banc. Il s’agit d’une définition opérationnelle de travail, non d’une nouvelle définition universelle.

Il faut séparer la durée d’exposition de la persistance de l’effet. Un service bloqué pendant une perturbation continue n’est pas, pour cette raison, atteint d’un effet persistant. À l’inverse, une action brève peut laisser une configuration durablement incompatible avec le fonctionnement attendu. La question causale porte sur ce qui reste dans le système lorsque l’action a cessé.

3. Qualifier la persistance et la récupération

3.1. Trois dimensions à enregistrer séparément

La qualification proposée repose sur trois dimensions : l’état persistant pertinent, la satisfaction du contrat de service et le niveau de récupération nécessaire. Elles doivent être documentées séparément. Une configuration modifiée sans perte du service n’est pas un PDoS dans le périmètre retenu. Une perte de service sans preuve suffisante sur l’état reste une indisponibilité de cause non établie.

Un effet compatible avec le périmètre PDoS étudié exige de réunir : une altération pertinente documentée ; un lien causal étayé avec l’indisponibilité ; la persistance de cette indisponibilité après l’arrêt de la perturbation ; l’échec des reprises ordinaires prévues dans le protocole. En simulation, cette qualification reste celle d’un effet simulé. Pour parler d’attaque observée sur un équipement, il faut en plus établir le chemin adverse et ses préconditions, au-delà de l’effet produit.

L’identité ou l’intention hostile d’un auteur ne peut pas être inférée d’un pic de consommation ou d’une série de redémarrages. Sur un banc, le scénario introduit par l’expérimentateur fournit une information de contexte ; un détecteur n’en dispose pas nécessairement en exploitation. La vérité terrain de l’expérience et la connaissance disponible pour le détecteur doivent rester distinctes.

3.2. Catégories de récupération proposées

Les catégories RC0–RC3 et INDET décrivent les modalités de récupération dans le périmètre du protocole. Cette classification opérationnelle se distingue d’une échelle de gravité et des niveaux de réponse graduée du programme.

Les mécanismes de reprise ordinaire sont définis avant l’essai : redémarrage autorisé, bascule automatique documentée ou autre procédure intégrée au fonctionnement du banc. Une bascule A/B réussie relève de cette catégorie lorsqu’elle fait partie du fonctionnement prévu. Les mécanismes A/B documentés par Android visent notamment à conserver une voie de démarrage utilisable lors d’une mise à jour ; leur disponibilité exacte doit être vérifiée sur le terminal étudié [S5].

Les fenêtres d’observation seront justifiées par le fonctionnement normal du banc et les exigences du service. Aucun seuil universel de durée n’est fixé ici. Un essai interrompu pour une raison de sûreté sera enregistré comme tel ; il ne deviendra pas automatiquement une preuve de récupération impossible. Les temps de récupération non observés jusqu’au bout seront signalés comme observations censurées.

4. Actifs et frontières de confiance

4.1. Les actifs à considérer

La protection doit couvrir le service, les composants nécessaires à son démarrage et les ressources de restauration. Le NIST SP 800-193 organise la résilience du firmware autour de la protection, de la détection et de la récupération, en distinguant les racines et chaînes de confiance associées [S2]. Ces fonctions structurent l’analyse des actifs présentée ci-dessous.

4.2. Où une autorisation doit être vérifiée

Les frontières sont des séparations de confiance, pas nécessairement des équipements distincts. Un système peut transporter une image sur une liaison chiffrée tout en devant encore décider si cette image est autorisée à être installée. Les modèles de distribution sécurisée tels qu’Uptane séparent les rôles et les métadonnées de confiance pour traiter différents cas de compromission [S3].

Un scénario peut ne concerner qu’une partie de ces frontières. Une configuration incohérente peut affecter le service sans modifier le bootloader. La cohérence du modèle exige cependant que chaque transition soit compatible avec les capacités adverses retenues : un privilège d’écriture nécessaire au mécanisme doit figurer explicitement parmi ses préconditions.

5. Capacités adverses et rôle des communications radio

5.1. Des profils distincts, sans cumul implicite

Quatre profils sont proposés. A1, distant non authentifié, peut atteindre une interface exposée sans disposer d’un compte. A2, titulaire d’un accès de maintenance compromis, possède uniquement les droits réellement attachés à cet accès. A3, acteur contrôlant un composant de distribution, agit sur ce composant et sur les seules clés dont la compromission est explicitement supposée. A4, acteur disposant déjà de privilèges locaux sur l’équipement, représente un état post-compromission ; il ne démontre pas l’existence d’un accès distant initial.

Le droit d’installer une image, la capacité d’en produire une signature valide, la possibilité d’écrire directement un stockage et le contrôle d’un serveur ne sont pas des capacités équivalentes. Uptane explicite notamment des compromis partiels et des menaces de retour de version ou d’incompatibilité entre composants. Son périmètre ne couvre pas à lui seul la création malveillante d’un logiciel pourtant considéré comme fiable par la chaîne de production [S3]. Dans le projet, chaque capacité supplémentaire devra donc apparaître dans les préconditions du scénario.

5.2. OTA, RF et mécanisme vulnérable

L’OTA désigne ici une fonction de mise à jour distante ; RF désigne le support radio d’une interaction. Un scénario complet doit distinguer le canal, le protocole ou la fonction sollicitée, le mécanisme de contrôle concerné et l’état atteint. Une disponibilité radio insuffisante peut interrompre une communication. Elle ne prouve pas, sans mécanisme supplémentaire, une modification durable du firmware.

Pour chaque scénario radio, trois relations doivent être étayées : l’interaction atteint le composant considéré ; ce composant autorise ou subit une transition pertinente ; cette transition affecte durablement le service. Une simple perte de paquets n’établit pas les deux dernières relations. Les perturbations de liaison seront donc d’abord utilisées comme témoins de comportement transitoire, dans un simulateur ou un environnement de communication maîtrisé.

La documentation MAVLink 2 décrit un mécanisme d’authentification des messages et des contrôles temporels, mais laisse certaines règles d’acceptation à l’implémentation [S4]. La présence du protocole ne suffit donc pas à affirmer qu’un contrôleur accepte une commande non autorisée, ni qu’une commande atteint le stockage persistant. Il faudra identifier la pile logicielle, sa version et sa configuration effective. Le modèle initial exclut toute émission perturbatrice vers des systèmes tiers et toute destruction matérielle directe.

6. Scénarios T01 à T05 et témoins associés

6.1. Lire les scénarios comme des propositions

Les cinq scénarios T01–T05 couvrent la mise à jour, la politique de version, les commandes et la configuration persistante. Ils sont au stade de la conception expérimentale. La matrice associée précise leurs préconditions, les signaux à observer, les témoins, les critères d’interprétation et leurs liens avec les questions RQ1–RQ5 et les hypothèses H1–H4.

T01 sert d’abord à caractériser une barrière de protection. Un rejet correct est un résultat de protection, pas un exemple d’attaque PDoS réussie. L’absence d’écriture doit porter sur les zones pertinentes ; un journal de rejet peut légitimement être enregistré.

T02 distingue l’incident de mise à jour d’une action adverse capable de le provoquer. Une interruption accidentelle constitue un témoin pour comparer les états atteints et les mécanismes de reprise. L’étude d’un chemin adverse exige de caractériser séparément la capacité d’interruption et ses conséquences. L’évaluation initiale repose sur une simulation réversible.

T03 examine une politique annoncée avant l’essai. Un retour de version autorisé dans une procédure de maintenance ne peut pas être classé comme attaque uniquement parce que la version décroît. De même, une version correctement signée n’est pas nécessairement fonctionnellement compatible avec tous les composants du système.

T04 conserve séparément commande non authentifiée, commande authentifiée mais non autorisée et commande autorisée dont le contexte rend l’exécution inappropriée. Les confondre empêcherait d’identifier le contrôle évalué. La sûreté impose aussi de distinguer l’état du système : une réaction acceptable sur un simulateur immobilisé ne devient pas automatiquement acceptable en exploitation physique.

T05 permet de préparer l’observation de la persistance et de la restauration dans une application de test isolée. Une configuration incohérente y fournit un cas contrôlé de dégradation du service. La portée de ce modèle est limitée aux mécanismes représentés : il ne reproduit pas la chaîne de démarrage ni les protections matérielles d’un équipement commercial, et n’établit pas un chemin d’exploitation OTA/RF.

6.2. Trois témoins indispensables

C00, fonctionnement normal, caractérisera les variations attendues et les reprises ordinaires. C01, anomalie bénigne de charge, mesurera le risque de confondre une variation de ressources avec un événement hostile. C02, interruption puis rétablissement d’une liaison simulée, vérifiera la distinction entre perte d’observation, interruption de service et altération persistante. Leur innocuité supposée doit être vérifiée dans le périmètre du banc ; leur étiquette ne dispense pas de contrôler l’état final.

T05 sera également comparé, lorsque le banc le permet, à une erreur de configuration bénigne produisant des symptômes voisins. Cette comparaison permettra de distinguer la capacité à détecter une dégradation de la capacité à en attribuer la cause. Des symptômes identiques peuvent justifier une alerte d’indisponibilité ou d’intégrité sans permettre de conclure à une intention malveillante.

7. Construire une observation qui puisse être contredite

7.1. Une vérité terrain indépendante

La chronologie de référence comprendra, lorsque ces instants sont observables, le début de l’action contrôlée, la transition persistante pertinente, la première violation du contrat de service, la fin de la perturbation, l’alerte, le début de récupération et le retour vérifié au service. Les événements non observables seront déclarés inconnus. Ils ne seront pas reconstruits à partir du score du détecteur que l’on cherche précisément à évaluer.

Un observateur distinct pourra enregistrer le contrat de service et les actions du banc. Cette séparation ne suffit pas à le rendre infaillible : il faudra documenter ses dépendances, son horloge et ses pertes éventuelles. Un journal produit par le composant supposé compromis ne doit pas être traité comme une preuve indépendante de son intégrité.

Le caractère précoce d’une alerte s’évalue par rapport à un événement défini à l’avance, par exemple la première violation du contrat de service. Son avance correspond à la différence entre l’instant de cet événement et celui de l’alerte. Cette mesure n’est interprétable que si elle dépasse l’incertitude de synchronisation. Une alerte postérieure à l’altération mais antérieure à la perte de service sera distinguée d’une alerte antérieure à l’altération. La qualification temporelle repose sur des transitions effectivement observables.

7.2. Les sources et leurs angles morts

Les événements logiciels pourront renseigner les validations, erreurs, versions et transitions. Les métriques de performance décriront l’usage des ressources. Les observations réseau caractériseront les échanges et leur disponibilité. Des mesures physiques pourront être ajoutées si une instrumentation adéquate existe. Cette organisation est une proposition expérimentale ; l’utilité supplémentaire d’une source reste à démontrer.

Chaque source sera caractérisée par son unité, sa fréquence, son origine temporelle, sa résolution, ses pertes, son coût et ses dépendances de confiance. Les mesures directes seront distinguées des estimations ; l’utilisation du processeur et la consommation énergétique seront traitées comme des grandeurs différentes. L’acquisition pouvant modifier la charge ou les écritures du système, son effet sera évalué au moyen de sessions avec et sans instrumentation lorsque cela est possible.

8. Relier les hypothèses à des conditions de mise à l’épreuve

Les questions RQ1–RQ5 et les hypothèses H1–H4 organisent les comparaisons proposées. RQ5 examine leur transférabilité entre plateformes. Pour chaque comparaison, les seuils de décision et la taille de la campagne seront définis dans le protocole expérimental.

H1 porte sur une classe de scénarios explicitement délimitée : un cas sans signal précoce contredit une affirmation universelle, mais sa portée dépend du domaine de validité annoncé. H2 exige un gain minimal pertinent, H3 un budget de ressources propre au banc et H4 une évaluation conjointe des restaurations et des effets indésirables. Ces critères seront arrêtés avant l’évaluation afin de préserver l’indépendance entre les objectifs de l’étude et l’interprétation des résultats.

9. Protocole minimal et critères d’analyse

9.1. Séquence proposée

La préparation commence par identifier un banc, son propriétaire, les versions utilisées, la fonction testée et les dépendances. Avant toute perturbation, une restauration doit être essayée et son résultat vérifié. Le protocole fixe ensuite la question, le scénario, les témoins, la mesure principale, les fenêtres d’observation, les répétitions et les conditions d’arrêt. Une préparation incomplète maintient le scénario au statut documentaire.

La première collecte couvre le fonctionnement normal et les témoins bénins. Le scénario contrôlé vient ensuite, initialement en observation seule. L’ordre des conditions sera randomisé ou contrebalancé lorsque cela est possible, pour éviter de confondre scénario et dérive du banc. Chaque exécution sera séparée de la suivante par un retour à l’état de référence contrôlé. Une campagne de réponse autonome sera distincte et ne commencera qu’après examen de la récupération et des contraintes de sûreté.

9.2. Unité d’évaluation et données

Le protocole annoncera si l’unité de décision est une fenêtre, un événement ou une session. Un grand nombre de fenêtres issues du même essai ne remplace pas un grand nombre d’essais indépendants. Les partitions d’entraînement, de validation et de test seront séparées par sessions et, pour certaines questions de transfert, par appareils. La normalisation et la sélection des caractéristiques utiliseront seulement l’entraînement. Le jeu de test restera réservé à l’évaluation finale de la configuration retenue.

La classe positive dépendra de la question : anomalie, transition persistante ou violation du service. Elle ne sera pas renommée « attaque PDoS » sans disposer des preuves correspondantes. Les fichiers conserveront également un statut de provenance : simulation, essai matériel ou capture externe autorisée. Les données brutes, transformations et exclusions seront tracées séparément.

9.3. Mesures proposées

L’évaluation de la détection rapportera la matrice de confusion, le rappel et la précision de la classe définie, le taux de faux positifs, les événements manqués et la chronologie des alertes. Les métriques dont le dénominateur est nul seront notées non définies. L’analyse des témoins permettra notamment de mesurer les alertes liées au démarrage d’une session plutôt qu’à l’événement étudié.

Pour la récupération, le temps entre le début de la restauration et le retour vérifié au service sera distingué de la durée totale d’indisponibilité. Le taux de succès précisera son dénominateur ; les essais arrêtés et les durées censurées seront rapportés séparément. Pour les ressources, on mesurera au minimum les coûts accessibles et pertinents : mémoire, charge, latence et taille des artefacts. L’énergie restera non mesurée tant qu’aucun dispositif adapté n’est disponible.

Le plan d’analyse justifiera le nombre de répétitions à partir d’une étude pilote, de la variabilité observée et de la précision recherchée. Les intervalles d’incertitude seront calculés au niveau d’indépendance pertinent, notamment la session.

10. Décliner le modèle sur les plateformes envisagées

10.1. Jetson Orin

Jetson Orin est envisagé comme environnement Linux embarqué pour l’observation des services et la préparation de la collecte. La documentation Jetson Linux r36.5.2 décrit une redondance A/B du bootloader [S6]. Son évaluation nécessitera d’identifier le modèle exact, la version logicielle, le stockage, les protections activées et les voies de récupération. Les premiers essais porteront sur des services de test restaurables avant d’étudier les composants de démarrage.

10.2. Pixhawk et pile de contrôle de vol

Pixhawk désigne une famille matérielle ; la pile exécutée doit être nommée séparément. PX4 fournit des environnements de simulation, dont le software-in-the-loop, permettant de préparer certaines observations sans contrôleur physique [S7]. Une simulation peut servir à examiner une politique de validation ou une transition de service. Elle ne démontre pas la résistance d’une mémoire réelle, les délais d’un bus matériel ou le comportement radio effectif. Le passage à un banc physique demande des vérifications propres au matériel, aux périphériques et à l’état sûr.

10.3. Android

Android Verified Boot décrit une chaîne de vérification ainsi qu’une protection contre certains retours de version [S8]. La référence A/B décrit, pour les architectures concernées, des mécanismes de continuité de démarrage pendant les mises à jour [S5]. L’évaluation devra identifier le fabricant, le modèle, la version, l’état du bootloader et le schéma de mise à jour réellement employé. Un terminal déverrouillé ou une image modifiée pour le laboratoire représente un autre modèle de confiance qu’un terminal de production verrouillé. Cette différence sera consignée, sans assimiler automatiquement l’un à l’autre.

11. Récupération, réponse et sûreté de fonctionnement

Une alerte propose une information ; une réponse modifie le système. Le protocole doit pouvoir mesurer séparément la qualité de cette information et les conséquences de l’action. Le score d’un classifieur ne sera pas traité comme une probabilité fiable sans évaluation de sa calibration. Les seuils et conditions de décision seront déterminés sur les données prévues à cet effet, puis figés avant le test.

La récupération vise un état dont les propriétés attendues sont vérifiées. Un redémarrage réussi peut laisser une configuration incohérente ; un service rendu peut masquer un retour vers une version qui ne satisfait plus la politique de confiance. La vérification finale portera donc sur les propriétés retenues dans le contrat : fonction, version ou intégrité accessible, cohérence de configuration et maintien de la voie de récupération.

Les actions autorisées dépendront du contexte. Isoler une interface, suspendre une mise à jour et restaurer une configuration n’ont pas les mêmes conséquences. Pour un système cyberphysique, l’état sûr sera défini avec les fonctions physiques concernées ; il ne se réduit pas systématiquement à l’arrêt de l’équipement. Les critères d’arrêt de l’essai et l’autorité de reprise manuelle seront fixés avant exécution. Un état non vérifiable maintiendra la conclusion ouverte.

12. Validité, limites et diffusion

La première menace de validité est de démontrer seulement le comportement que l’on a programmé dans un simulateur. Un modèle simplifié peut valider une procédure de collecte ou un schéma d’analyse, mais sa structure peut rendre la discrimination artificiellement facile. Les conclusions indiqueront donc précisément quelles transitions ont été imposées et lesquelles ont réellement été observées sur un équipement.

Une deuxième limite concerne l’instrumentation : privilèges supplémentaires, journaux activés et supervision externe peuvent changer le fonctionnement du banc. Une troisième concerne la généralisation : mêmes familles de processeurs ou mêmes protocoles ne garantissent ni les mêmes signaux ni les mêmes possibilités de récupération. Une quatrième concerne la causalité : les symptômes d’une panne et d’une action malveillante peuvent être identiques. Le projet peut produire une détection utile de dégradation sans résoudre cette attribution.

La diffusion publique porte sur le modèle de menace, les critères d’évaluation et les limites d’interprétation. Les données et les détails opérationnels des bancs relèvent d’un accès contrôlé, adapté à leur sensibilité.

13. Prochain jalon et conditions de passage

La prochaine étape associe la revue du modèle de menace à la qualification d’un premier environnement réversible. Elle comprend la définition d’une fonction observable, la vérification des préconditions du scénario, l’essai d’une procédure de restauration et la fixation des témoins et des règles d’analyse. Les versions du banc et la chronologie des opérations seront documentées pour permettre l’interprétation et la reproduction des essais.

Une première séquence en simulation pourra associer C00, C01 et C02, puis une variante limitée de T05. Elle servira à éprouver l’observation du service, la qualification de la persistance et la vérification de la restauration. Le passage à un équipement physique dépendra ensuite des capacités d’instrumentation et de récupération propres à la plateforme retenue.

La preuve attendue de cette étape est un ensemble cohérent : protocole arrêté, fiche du banc, traces horodatées, description des transformations, conclusion limitée et vérification de l’état final. Tant que ces éléments ne sont pas réunis, les scénarios restent proposés et les hypothèses restent ouvertes. Une conclusion négative ou indéterminée correctement documentée sera conservée comme résultat utile de la démarche.

Références bibliographiques

• [P1] Mamani Malam Goga, Abdoul Karim. Fondements scientifiques : systèmes embarqués critiques connectés, surfaces OTA/RF et résilience face aux attaques PDoS. Note 01, version 0.1, septembre 2026. Lire la Note 01.
• [P2] Mamani Malam Goga, Abdoul Karim. Résilience des systèmes embarqués face aux attaques PDoS. Présentation du programme.
• [S1] Abaimov, Stanislav. Understanding and Classifying Permanent Denial-of-Service Attacks. Prépublication, version 1, 9 février 2024. Texte de la prépublication. Version publiée : Journal of Cybersecurity and Privacy, 4(2), 324–339, 2024. doi:10.3390/jcp4020016.
• [S2] Regenscheid, Andrew. Platform Firmware Resiliency Guidelines. NIST SP 800-193, mai 2018. doi:10.6028/NIST.SP.800-193. Document PDF.
• [S3] Uptane Community. Uptane Standard for Design and Implementation, version 2.1.0, 2023, sections 3.4, 4 et 5. Consulter le standard.
• [S4] MAVLink. Message Signing (Authentication). Documentation MAVLink 2. Consulter la documentation.
• [S5] Android Open Source Project. A/B (seamless) system updates. Consulter la documentation.
• [S6] NVIDIA. Jetson Linux Developer Guide: Update and Redundancy, archive r36.5.2. Consulter la documentation.
• [S7] PX4. Simulation, guide de la branche main. Consulter la documentation.
• [S8] Android Open Source Project. Verified Boot. Consulter la documentation.

Annexes associées

Synthèse des huit scénarios et témoins

La matrice détaillée des scénarios (Excel) rassemble les préconditions, les observations et les critères associés aux cinq scénarios T01–T05 et aux trois témoins C00–C02. Une version CSV brute reste disponible pour l’analyse de données. Les principes de lecture précisent l’articulation entre les scénarios, les hypothèses et leur évaluation.

Présentation du projet · Note 01 · Demander un accès à l’espace de travail

Lecture de la matrice de scénarios

La matrice relie chaque scénario à ses capacités adverses, à ses préconditions et aux frontières de confiance concernées. Elle associe ensuite l’effet étudié aux observations nécessaires, aux témoins de comparaison et aux critères de récupération. Les cinq scénarios et les trois témoins sont au stade de la conception expérimentale.

Des scénarios aux hypothèses

Les questions RQ1–RQ5 et les hypothèses H1–H4 indiquent l’objectif scientifique de chaque comparaison. Leur évaluation repose sur un protocole précisant le service attendu, les versions du banc, l’unité d’analyse, les fenêtres d’observation, les répétitions et les critères d’interprétation. L’étude du transfert, portée par RQ5, nécessite une comparaison explicite avec une seconde plateforme.

Exemple : configuration persistante et restauration

Dans T05, une configuration incohérente est étudiée au moyen d’un service de test restaurable. L’analyse porte sur le maintien de cet état après la fin de la perturbation, la réponse des mécanismes de reprise ordinaire et le retour vérifié au service. Si une restauration de référence est nécessaire puis réussit, le résultat pourra relever de RC2. Cette qualification restera limitée au système représenté : elle n’établira ni une vulnérabilité d’un équipement commercial ni un accès initial OTA/RF.

Interprétation des observations

Les catégories RC0–RC3 décrivent les modalités de récupération et INDET signale l’insuffisance des éléments disponibles. La solidité d’une conclusion dépendra des conditions d’observation, de la répétition des essais et de leur reproduction indépendante. La comparaison avec les témoins permettra d’examiner les explications concurrentes, notamment les incidents bénins produisant des symptômes proches.

PROGRAMME PDoS

Continuer la lecture et accéder aux travaux.

Cette note prolonge les fondements présentés dans la Note 01. L’espace de travail du projet est accessible sur demande.

Lire la Note 01 →Accès aux travaux sur demande →