« Nous n'avions tout simplement pas cela sur le système embarqué » : Perspectives et défis pour la sécurisation des systèmes microcontrôleurs à partir des compétitions CTF embarquées

Informations de base

• ID de l'article : 2503.08053
• Titre : "We just did not have that on the embedded system": Insights and Challenges for Securing Microcontroller Systems from the Embedded CTF Competitions
• Auteurs : Zheyuan Ma, Gaoxiang Liu, Alex Eastman, Kai Kaufman, Md Armanuzzaman, Xi Tan, Katherine Jesse, Robert J. Walls, Ziming Zhao
• Classification : cs.CR (Cryptographie et sécurité)
• Date de publication/Conférence : ACM SIGSAC Conference on Computer and Communications Security (CCS '25)
• Lien de l'article : https://arxiv.org/abs/2503.08053

Résumé

Les systèmes microcontrôleurs sont indispensables dans la vie quotidienne, alimentant les applications critiques telles que les véhicules, les dispositifs médicaux et les systèmes de contrôle industriel. Cette étude analyse le cycle de vie complet du développement sécurisé de systèmes microcontrôleurs sous une double perspective technique et cognitive, en examinant les soumissions des équipes et les entretiens post-compétition du CTF embarqué MITRE (eCTF) de 2023 et 2024. La recherche identifie deux grandes catégories de défis : conceptuels et pratiques. Sur le plan conceptuel, la migration des systèmes microprocesseurs vers les systèmes microcontrôleurs présente des difficultés, et les participants manquent de sensibilisation aux attaques spécifiques aux microcontrôleurs. Sur le plan pratique, les langages à sécurité mémoire comme Rust bénéficient d'un support insuffisant sur les microcontrôleurs, et les sources d'entropie de faible qualité affaiblissent la sécurité de la cryptographie et de la génération de clés. L'étude fournit des recommandations ciblées pour les chercheurs, développeurs, fournisseurs et éducateurs.

Contexte et motivation de la recherche

1. Questions de recherche

Les systèmes microcontrôleurs (MCU) sont largement utilisés dans les infrastructures critiques, mais leur développement sécurisé fait face à des défis uniques. Les recherches existantes se concentrent principalement sur l'analyse des vulnérabilités de microprogrammes, manquant d'une compréhension approfondie des causes profondes des vulnérabilités, en particulier aux niveaux cognitif et pratique des développeurs.

2. Importance du problème

• Applicabilité généralisée : Les microcontrôleurs alimentent les véhicules, les dispositifs médicaux, les systèmes de contrôle industriel et autres systèmes critiques
• Fragilité de sécurité : Absence de caractéristiques de sécurité standard comme les MMU, la programmation courante en C/assembleur entraîne facilement des erreurs mémoire
• Accessibilité physique : Plus susceptibles que les ordinateurs classiques de subir des attaques matérielles telles que les canaux auxiliaires et les injections de fautes

3. Limitations des approches existantes

• Obstacles du code fermé : Les microprogrammes réels sont difficiles à obtenir et analyser
• Perspective unique : Analyse technique uniquement, négligeant la cognition et les processus décisionnels des développeurs
• Absence de perspective du cycle de vie complet : Impossible de retracer l'évolution des vulnérabilités de la conception à la mise en œuvre

4. Motivation de la recherche

Grâce à la perspective unique de la compétition eCTF, l'équipe de recherche peut :

• Accéder au code source complet, à la documentation et aux outils de construction
• Combiner l'analyse technique avec les entretiens avec les développeurs
• Observer les pratiques de sécurité des premiers chercheurs, fournissant une base pour l'amélioration éducative
• Identifier les défis de sécurité systémiques et empiriques

Contributions principales

1. Innovation méthodologique : Propose une méthode d'étude des défis de sécurité des systèmes microcontrôleurs par le biais de compétitions CTF, examinant le cycle de vie complet du développement en combinant l'analyse technique et la perspective cognitive
2. Cadre de classification des défis doubles : Identifie et classe systématiquement les défis conceptuels (lacunes de connaissances) et les défis pratiques (limitations d'outils/ressources)
3. Résultats empiriques :
   • Défis conceptuels : Application insuffisante de mécanismes de sécurité fondamentaux tels que la séparation des privilèges, l'effacement mémoire et les canaris de pile ; difficultés d'adaptation de plateforme ; sensibilisation faible aux défenses contre les attaques matérielles
   • Défis pratiques : Support insuffisant des langages à sécurité mémoire comme Rust ; manque de sources d'entropie de haute qualité
4. Recommandations exploitables : Fournit 9 recommandations concrètes pour cinq catégories de parties prenantes (chercheurs, fournisseurs, éducateurs, développeurs, mainteneurs de compilateurs)
5. Ressources de données : Analyse de 47 soumissions d'équipes (20 de 2023, 27 de 2024), complétée par 22 entretiens approfondis

Détails méthodologiques

Définition des tâches

L'objectif de la recherche est d'identifier et de comprendre les défis du développement sécurisé de systèmes microcontrôleurs, incluant spécifiquement :

• Entrées : Soumissions d'équipes eCTF (code source, documentation, outils de construction) + données d'entretiens avec les participants
• Sorties : Classification des défis de sécurité, analyse des causes profondes, recommandations d'amélioration
• Contraintes : Focus sur l'environnement de compétition axé sur la sécurité, participants étant des développeurs en début de carrière

Architecture de recherche

1. Analyse des soumissions (Submission Analysis)

Sources de données :

• 2023 : 20 équipes, utilisant la carte de développement TI TM4C123GXL (ARM Cortex-M4F)
• 2024 : 27 équipes, utilisant la carte de développement Analog Devices MAX78000FTHR (ARM Cortex-M4 + RISC-V)

Dimensions d'analyse :

• Outils de construction : Langages de programmation, compilateurs, niveaux d'optimisation, drapeaux de sécurité de compilation, attributs de script de liaison
• Code source : Utilisation de git diff pour suivre les modifications, vérification de l'assemblage en ligne, opérations mémoire, génération de nombres aléatoires, code lié au timing
• Désassemblage : Vérification de l'impact des optimisations du compilateur sur les caractéristiques de sécurité
• Analyse à l'exécution : Utilisation d'outils de débogage pour vérifier les incertitudes de l'analyse statique

Points de vérification clés :

• Séparation des privilèges (configuration MPU)
• Implémentation d'effacement mémoire (problèmes d'optimisation memset)
• Activation des canaris de pile
• Configuration de pile non exécutable
• Défense contre les attaques matérielles (canaux auxiliaires, injections de fautes, tampering physique)
• Qualité de la source d'entropie

2. Entretiens avec les participants (Participant Interviews)

Caractéristiques de l'échantillon (n=22) :

• Formation éducative : 12 étudiants de premier cycle, 6 étudiants de maîtrise, 4 étudiants de doctorat
• Expérience en cours de sécurité : 8 personnes sans formation en sécurité
• Expérience en embarqué : 14 personnes avec expérience en développement embarqué

Conception des entretiens :

• Entretiens semi-structurés, durée 42-107 minutes (moyenne 69 minutes)
• Questions issues des problèmes récurrents identifiés dans l'analyse des soumissions
• Exploration de la cognition (connaissances, idées fausses) et de la prise de décision (priorités, compromis)

Analyse des données :

• Transcription par Otter AI avec vérification manuelle
• Codage ouvert indépendant par trois chercheurs
• Développement itératif du codebook : 8 thèmes principaux, 40 sous-thèmes, 278 codes
• Résolution collaborative des conflits de codage, sans vérification formelle de fiabilité requise

Points d'innovation technique

1. Approche à deux volets : Première combinaison d'une analyse de code à grande échelle avec des entretiens approfondis, révélant le « quoi » et le « pourquoi »
2. Perspective du cycle de vie complet : De la documentation de conception → code source → binaire → cognition des développeurs, retraçant l'évolution des vulnérabilités
3. Cadre d'analyse de l'écosystème : Identifie que les problèmes ne sont pas uniquement attribuables aux développeurs, mais impliquent également les compilateurs, les fournisseurs, l'éducation et d'autres parties
4. Reproductibilité : Matériaux d'entretien et codebook publiquement disponibles (https://github.com/CactiLab/eCTF-User-Study-Material)

Configuration expérimentale

Ensemble de données

Données de compétition :

• eCTF 2023 : Système d'entrée sans clé à distance (microprogrammes de véhicule + porte-clés)
• eCTF 2024 : Système de pompe à insuline (contrôleur + surveillance de la glycémie + actionneur de pompe)
• Conception de référence : Écrite en C, satisfaisant les exigences fonctionnelles mais sans caractéristiques de sécurité

Modèle de menace :

• Accès physique aux appareils et canaux de communication
• Accès au code source (sans clés/drapeaux)
• Attaques logicielles, réseau et matériel

Métriques d'évaluation

Métriques quantitatives :

• Taux de mise en œuvre des mécanismes de sécurité (séparation des privilèges, canaris de pile, effacement mémoire, pile non exécutable)
• Taux de défense contre les attaques matérielles (canaux auxiliaires, injections de fautes, tampering asynchrone)
• Distribution d'utilisation des sources d'entropie

Métriques qualitatives :

• Saturation des thèmes d'entretien
• Types d'idées fausses cognitives
• Modèles de priorités décisionnelles

Méthodes de comparaison

Comparaison avec les recherches existantes :

• Recherche en analyse de microprogrammes (FirmXRay, Nino et al., Tan et al.) : Analyse technique uniquement, cet article ajoute la dimension cognitive
• Recherche BIBIFI : Focus sur les systèmes microprocesseurs, cet article se concentre sur les défis uniques des microcontrôleurs
• Recherche sur l'adoption de Rust (Fulton et al., Sharma et al.) : Cet article combine les contraintes spécifiques à l'embarqué

Détails de mise en œuvre

• Collaboration de trois chercheurs PhD en sécurité embarquée
• L'équipe d'auteurs a participé à la compétition mais est exclue de l'étude de cas
• Exemption d'examen IRB
• Compensation de 50 dollars par participant

Résultats expérimentaux

Résultats principaux

Statistiques des défis conceptuels

1. Taux de mise en œuvre des mécanismes de sécurité (Figure 1) :

2. Taux de défense contre les attaques matérielles (Figure 2) :

• Toute défense : 17/47 (36,17%)
• Défense contre les canaux auxiliaires : 13/17 (76,47%)
• Défense contre les injections de fautes : 9/17 (52,94%)
• Défense contre le tampering asynchrone : 7/17 (41,18%)

3. Utilisation des sources d'entropie (Figure 3) :

• 2023 : 25% sans entropie, 25% codées en dur/défectueuses, 45% source d'entropie unique, 5% sources mixtes
• 2024 : 22,2% sans entropie, 14,8% codées en dur/défectueuses, 55,6% source d'entropie unique, 7,4% sources mixtes

Statistiques des défis pratiques

Taux d'adoption de Rust en baisse :

• 2023 : 5/20 (25%) équipes utilisant Rust
• 2024 : 2/27 (7,4%) équipes utilisant Rust
• Cause principale : SDK 2024 volumineux, compilation mixte Rust+C dépassant la limite de mémoire flash

Expériences d'ablation

Cas d'optimisation du compilateur pour l'effacement mémoire

Cas T12 (Listing 1) :

• Utilisation de memset 10 fois pour effacer les données sensibles
• Optimisation du compilateur supprimant 5 appels (y compris l'effacement de clé AES)
• Entretien avec développeur révélant : complètement inconscient que le compilateur optimiserait

Cas de mise en œuvre efficace :

• T20/T15 : Utilisation de la bibliothèque Monocypher crypto_wipe (mot-clé volatile)
• T14/T02 : Utilisation de la bibliothèque Rust zeroize
• T18 : Fonction inline personnalisée pour prévenir l'optimisation

Problèmes de configuration des canaris de pile

• Seulement 2/47 équipes activant le drapeau du compilateur
• Aucune équipe initialisant une valeur de canari aléatoire (valeur constante fixe par défaut)
• Cohérent avec les microprogrammes réels : <0,2% taux d'activation (recherche Xi et al.)

Études de cas

Cas 1 : Idée fausse sur la pile non exécutable (T18, T13)

Mise en œuvre erronée :

// Script de liaison T18
MEMORY {
    FLASH (rx) : ORIGIN = 0x00008000, LENGTH = 0x00038000
    SRAM (rw) : ORIGIN = 0x20000000, LENGTH = 0x00008000  // Marqué uniquement rw
}

Problème :

• Modification uniquement des attributs d'en-tête ELF, pas de configuration MPU lors de l'initialisation du microprogramme
• Entretien révélant : 21/22 participants croyant que les drapeaux du compilateur suffisent

Mise en œuvre correcte (4 équipes) :

1. Activation du MPU
2. Configuration de la région de mémoire de pile comme XN (eXecute Never)
3. Activation de cette région

Cas 2 : Abus de blocs unsafe Rust (T11)

Problème : Utilisation généralisée de blocs unsafe pour appeler les fonctions du SDK C Raison : Modèle de développement incrémental, permettant la migration progressive du code vers Rust Contraste : C18-T08 limitant unsafe à la couche d'interaction matérielle de bas niveau

Cas 3 : Combinaison de sources d'entropie (T14)

Stratégie : Mélange de quatre sources d'entropie

• Dérive RTC et horloge CPU
• Graine spécifique à l'appareil
• ADC de température interne
• SRAM non initialisée (en réalité inefficace)

Effet : Même si une source échoue, la graine combinée reste imprévisible

Résultats expérimentaux

Observation 1 : Les optimisations du compilateur peuvent compromettre l'état de sécurité au-delà de la spécification du langage (comme l'effacement mémoire)

Observation 2 : La lacune de connaissances concernant les attaques spécifiques à l'embarqué est le facteur principal entravant la mise en œuvre des défenses

Observation 3 : Facteurs de décision Rust : familiarité, support des fournisseurs, support des bibliothèques, courbe d'apprentissage

Observation 4 : Les utilisateurs de Rust font face à des défis : compilation no_std, implémentation HAL, gestion unsafe

Observation 5 : La transformation automatisée des descripteurs matériels en structures Rust peut accélérer le développement HAL, mais la fidélité et la sécurité nécessitent une recherche supplémentaire

Observation 6 : Bien que les sources d'entropie des microcontrôleurs soient limitées, la combinaison de plusieurs sources disponibles peut améliorer efficacement la robustesse du caractère aléatoire

Travaux connexes

Recherche CTF

• Orientation éducative : Vigna et al. (cadre iCTF), Vykopal et al. (CTF comme outil d'enseignement)
• Analyse des défis : Crispin et al. (expérience Defcon CTF), Chung et al. (pièges d'organisation)
• Distinction de cet article : Première combinaison d'analyse de soumissions et d'entretiens, focus sur les défis de développement sécurisé plutôt que sur l'efficacité éducative

Développement logiciel sécurisé et recherche utilisateur

• Recherche BIBIFI (Parker et al., Ruef et al., Votipka et al.) : Analyse du développement de systèmes microprocesseurs, découvrant que la plupart des vulnérabilités proviennent de malentendus plutôt que d'erreurs
• Recherche sur l'adoption de Rust :
  • Fulton et al. : Perspective des développeurs avancés, identifiant les problèmes de courbe d'apprentissage et de support de bibliothèques
  • Sharma et al. : Analyse de 6000+ projets Rust embarqués, révélant un support insuffisant de l'écosystème
• Contribution de cet article : Focus sur les contraintes spécifiques aux microcontrôleurs, combinant les perspectives technique et cognitive

Sécurité des systèmes microcontrôleurs

• Techniques de défense : Séparation des privilèges (Kage, ACES, EPOXY), CFI (μRAI, Silhouette, SHERLOC), randomisation (fASLR, HARM)
• Analyse de microprogrammes : FirmXRay, Nino et al., Tan et al. (analyse statique de microprogrammes réels)
• Unicité de cet article : Première étude des défis cognitifs des développeurs, plutôt que de solutions techniques uniquement

Conclusion et discussion

Conclusions principales

1. Responsabilité de l'écosystème : La mise en œuvre de la sécurité est une responsabilité partagée des développeurs, éducateurs, chercheurs et fournisseurs
2. Besoins uniques du développement MCU :
   • Compréhension approfondie des caractéristiques de la plateforme (matériel, compilateur, chaîne d'outils)
   • Gestion du comportement opaque et contre-intuitif du compilateur
   • Défense contre les menaces uniques de l'accès physique
3. Lacune éducative : Les programmes existants ne préparent pas suffisamment les étudiants aux défis spécifiques à l'embarqué
4. Trois défis conceptuels majeurs :
   • Application insuffisante des mécanismes de sécurité fondamentaux
   • Difficultés d'adaptation de plateforme
   • Sensibilisation faible aux défenses contre les attaques matérielles
5. Deux défis pratiques majeurs :
   • Support insuffisant des langages à sécurité mémoire
   • Manque de sources d'entropie de haute qualité

Limitations

1. Validité externe :
   • eCTF est un environnement de compétition, les éléments de gamification pouvant influencer le comportement
   • Les participants sont principalement des étudiants/développeurs en début de carrière, la généralisation à l'environnement industriel expérimenté est limitée
   • Les auteurs considèrent que les résultats représentent une limite inférieure conservatrice des vulnérabilités réelles
2. Portée de la recherche :
   • N'inclut pas la dynamique de collaboration d'équipe et la structure de compétition
   • La classification conceptuelle/pratique peut présenter des chevauchements
3. Limitations des données :
   • Les données d'auto-rapport peuvent présenter un biais d'attente sociale
   • Taille d'échantillon relativement petite (n=22)
   • Manque de données détaillées sur les antécédents éducatifs, les recommandations éducatives étant préliminaires
4. Modèle de menace :
   • Le modèle de menace de compétition peut ne pas refléter complètement tous les scénarios réels

Directions futures

1. Recherche éducative : Examen systématique des programmes de sécurité embarquée existants, identification des lacunes curriculaires
2. Comparaison empirique : Enquête auprès de professionnels expérimentés pour déterminer s'ils font face à des défis similaires
3. Développement d'outils :
   • Outils automatisés de séparation des privilèges
   • Outils de vérification de l'optimisation de sécurité du compilateur
   • Outils simplifiant le développement HAL Rust
4. Support des fournisseurs :
   • SDK Rust complet ou liaisons Rust-C
   • Transparence des sources d'entropie et normalisation des API

Évaluation approfondie

Points forts

1. Innovation méthodologique :
   • Première combinaison d'analyse de code avec entretiens approfondis, révélant le « quoi » et le « pourquoi »
   • Perspective du cycle de vie complet retraçant l'évolution des vulnérabilités
   • Forte reproductibilité (données et codebook publiquement disponibles)
2. Rigueur empirique :
   • Analyse complète de 47 soumissions d'équipes
   • 22 entretiens approfondis (moyenne 69 minutes)
   • Triangulation (code, documentation, entretiens, désassemblage)
   • Analyse qualitative suivant les méthodes établies (Saldaña, Clarke & Braun)
3. Valeur pratique :
   • 9 recommandations concrètes pour 5 catégories de parties prenantes
   • Identification des obstacles systémiques (non seulement des erreurs individuelles)
   • Cohérence avec les taux de vulnérabilités des microprogrammes réels, validant la représentativité des résultats
4. Profondeur des perspectives :
   • Révèle comment les optimisations du compilateur peuvent compromettre la sécurité (Observation 1)
   • Identifie la lacune de connaissances comme obstacle principal (Observation 2)
   • Découvre les défis multidimensionnels de l'adoption de Rust (Observations 3-5)
5. Clarté de la rédaction :
   • Classification structurée (conceptuel vs pratique)
   • Cas et exemples de code riches
   • Figures claires (Figures 1-3)

Insuffisances

1. Limitations de généralisation :
   • L'environnement de compétition diffère de la pratique industrielle
   • Les participants ont un niveau d'expérience relativement initial
   • Données couvrant seulement deux ans (2023-2024)
2. Inférence causale :
   • Impossible de séparer complètement l'impact de la pression de compétition vs lacune de connaissances
   • Pas de comparaison systématique entre participants avec/sans formation en sécurité
3. Profondeur de l'analyse quantitative :
   • Absence de tests de signification statistique
   • Pas de quantification de l'importance relative des différents facteurs
   • Taille d'échantillon d'entretien relativement petite (n=22)
4. Évaluation des outils :
   • Pas de test réel de l'efficacité des recommandations proposées
   • Absence d'expériences d'intervention validant les mesures d'amélioration
5. Couverture :
   • Focus uniquement sur les plateformes ARM Cortex-M
   • N'inclut pas les environnements RTOS (seulement bare-metal)
   • Exploration insuffisante des facteurs de collaboration d'équipe

Impact

1. Contribution académique :
   • Inaugure un nouveau paradigme de recherche utilisateur en sécurité embarquée
   • Fournit une base empirique pour la réforme éducative
   • Identifie les directions d'amélioration du compilateur et de la chaîne d'outils
2. Valeur pratique :
   • Les fournisseurs peuvent améliorer les SDK et la documentation
   • Les éducateurs peuvent ajuster les programmes d'études
   • Les développeurs peuvent éviter les pièges courants
3. Signification politique :
   • Soutient l'intégration de la sécurité dans les normes de développement embarqué
   • Fournit une analyse des causes profondes des vulnérabilités aux organismes de réglementation
4. Reproductibilité :
   • Les matériaux publiquement disponibles facilitent la vérification et l'extension
   • La méthodologie peut s'appliquer à d'autres CTF ou compétitions de développement

Scénarios d'application

1. Éducation :
   • Conception de cours de sécurité des systèmes embarqués
   • Organisation et évaluation de compétitions CTF
   • Matériel de formation des développeurs
2. Industrie :
   • Audit de sécurité des appareils IoT
   • Amélioration du cycle de vie de développement sécurisé (SDL)
   • Sélection et configuration de la chaîne d'outils
3. Recherche :
   • Optimisation de sécurité du compilateur
   • Adaptation des langages à sécurité mémoire à l'embarqué
   • Automatisation des défenses contre les attaques matérielles
4. Normalisation :
   • Guide des meilleures pratiques de sécurité embarquée
   • Exigences de sécurité des SDK des fournisseurs

Résumé des neuf recommandations principales

Références (sélection)

1. Séparation des privilèges :
   • 16 Kage (Du et al., 2022)
   • 10 ACES (Clements et al., 2018)
   • 11 EPOXY (Clements et al., 2017)
2. Sécurité mémoire :
   • 18 Recherche sur l'adoption de Rust (Fulton et al., 2021)
   • 52 Défis Rust embarqué (Sharma et al., 2024)
3. Analyse de microprogrammes :
   • 65 FirmXRay (Wen et al., 2020)
   • 42 Sécurité des microprogrammes IoT (Nino et al., 2024)
   • 56 Synthèse des systèmes Cortex-M (Tan et al., 2024)
4. Recherche utilisateur :
   • 46 BIBIFI (Ruef et al., 2016)
   • 62 Idées fausses de sécurité des développeurs (Votipka et al., 2020)

Évaluation globale : Cet article est une recherche utilisateur de haute qualité en sécurité embarquée, révélant les défis profonds du développement sécurisé de systèmes microcontrôleurs grâce à une approche innovante à deux volets. Sa plus grande valeur réside dans la combinaison de l'analyse technique avec la cognition des développeurs, fournissant un chemin exploitable pour améliorer l'éducation, les outils et la pratique. Bien que présentant des limitations de généralisation, la cohérence de ses résultats avec les taux de vulnérabilités des microprogrammes réels renforce la crédibilité des conclusions. Cette recherche établit un nouveau paradigme de recherche pour la communauté de la sécurité embarquée, méritant une vérification et une extension ultérieures.