"We just did not have that on the embedded system": Insights and Challenges for Securing Microcontroller Systems from the Embedded CTF Competitions

Informazioni Fondamentali

• ID Articolo: 2503.08053
• Titolo: "We just did not have that on the embedded system": Insights and Challenges for Securing Microcontroller Systems from the Embedded CTF Competitions
• Autori: Zheyuan Ma, Gaoxiang Liu, Alex Eastman, Kai Kaufman, Md Armanuzzaman, Xi Tan, Katherine Jesse, Robert J. Walls, Ziming Zhao
• Classificazione: cs.CR (Crittografia e Sicurezza)
• Data di Pubblicazione/Conferenza: ACM SIGSAC Conference on Computer and Communications Security (CCS '25)
• Link Articolo: https://arxiv.org/abs/2503.08053

Riassunto

I sistemi a microcontrollore sono indispensabili nella vita quotidiana, alimentando applicazioni critiche come veicoli, dispositivi medici e sistemi di controllo industriale. Questo studio analizza il ciclo di vita completo dello sviluppo sicuro di sistemi a microcontrollore da una prospettiva tecnica e cognitiva, attraverso l'analisi dei contributi dei team e delle interviste post-competizione dei Campionati eCTF (embedded CTF) MITRE del 2023 e 2024. La ricerca identifica due categorie principali di sfide: concettuali e pratiche. Sul piano concettuale, i partecipanti incontrano difficoltà nella migrazione dai sistemi a microprocessore ai sistemi a microcontrollore e mostrano consapevolezza insufficiente degli attacchi specifici ai microcontrollori. Sul piano pratico, i linguaggi memory-safe come Rust hanno supporto limitato sui microcontrollori, e le fonti di entropia di bassa qualità indeboliscono la sicurezza della crittografia e della generazione di chiavi. Lo studio fornisce raccomandazioni mirate per ricercatori, sviluppatori, fornitori e educatori.

Contesto di Ricerca e Motivazione

1. Domande di Ricerca

I sistemi a microcontrollore (MCU) sono ampiamente utilizzati nelle infrastrutture critiche, ma il loro sviluppo sicuro affronta sfide uniche. La ricerca esistente si concentra principalmente sull'analisi delle vulnerabilità del firmware, mancando di una comprensione approfondita delle radici delle vulnerabilità, in particolare a livello cognitivo e pratico degli sviluppatori.

2. Importanza del Problema

• Ampiezza Applicativa: I microcontrollori alimentano veicoli, dispositivi medici, sistemi di controllo industriale e altre applicazioni critiche
• Fragilità di Sicurezza: Mancanza di caratteristiche di sicurezza standard come MMU, programmazione frequente in C/assembly che favorisce errori di memoria
• Accessibilità Fisica: Più vulnerabili rispetto ai computer generici agli attacchi hardware come side-channel e fault injection

3. Limitazioni degli Approcci Esistenti

• Ostacoli Open-Source: Il firmware reale è difficile da ottenere e analizzare
• Prospettiva Singola: Solo analisi tecnica, trascurando la cognizione e i processi decisionali degli sviluppatori
• Mancanza di Prospettiva del Ciclo di Vita Completo: Impossibile tracciare l'evoluzione delle vulnerabilità dalla progettazione all'implementazione

4. Motivazione della Ricerca

Attraverso la prospettiva unica della competizione eCTF, il team di ricerca può:

• Accedere al codice sorgente completo, alla documentazione e agli strumenti di compilazione
• Combinare analisi tecnica con interviste agli sviluppatori
• Osservare le pratiche di sicurezza dei ricercatori in fase iniziale, fornendo basi per il miglioramento educativo
• Identificare sfide sistematiche ed empiriche di sicurezza

Contributi Principali

1. Innovazione Metodologica: Propone un metodo per studiare le sfide di sicurezza dei sistemi a microcontrollore attraverso competizioni CTF, combinando analisi tecnica e prospettiva cognitiva per esaminare il ciclo di vita dello sviluppo
2. Framework di Classificazione Doppia: Identifica e classifica sistematicamente le sfide concettuali (lacune di conoscenza) e le sfide pratiche (limitazioni di strumenti/risorse)
3. Risultati Empirici:
   • Sfide Concettuali: Applicazione insufficiente di meccanismi di sicurezza fondamentali come separazione dei privilegi, cancellazione della memoria, canari dello stack; difficoltà di adattamento della piattaforma; consapevolezza debole della difesa dagli attacchi hardware
   • Sfide Pratiche: Supporto limitato per linguaggi memory-safe come Rust; mancanza di fonti di entropia di alta qualità
4. Raccomandazioni Attuabili: Fornisce 9 raccomandazioni specifiche per cinque categorie di stakeholder (ricercatori, fornitori, educatori, sviluppatori, manutentori di compilatori)
5. Risorse Dati: Analizza 47 contributi di team (20 del 2023, 27 del 2024), completando 22 interviste approfondite

Dettagli Metodologici

Definizione del Compito

L'obiettivo della ricerca è identificare e comprendere le sfide nello sviluppo sicuro di sistemi a microcontrollore, includendo specificamente:

• Input: Contributi del team eCTF (codice sorgente, documentazione, strumenti di compilazione) + dati di interviste ai partecipanti
• Output: Classificazione delle sfide di sicurezza, analisi delle cause radice, raccomandazioni di miglioramento
• Vincoli: Focalizzazione su ambiente di competizione orientato alla sicurezza, partecipanti sono sviluppatori in fase iniziale di carriera

Architettura della Ricerca

1. Analisi dei Contributi (Submission Analysis)

Fonti Dati:

• 2023: 20 team, utilizzando scheda di sviluppo TI TM4C123GXL (ARM Cortex-M4F)
• 2024: 27 team, utilizzando scheda di sviluppo Analog Devices MAX78000FTHR (ARM Cortex-M4 + RISC-V)

Dimensioni di Analisi:

• Strumenti di Compilazione: Linguaggi di programmazione, compilatori, livelli di ottimizzazione, flag di sicurezza della compilazione, proprietà degli script di collegamento
• Codice Sorgente: Utilizzo di git diff per tracciare modifiche, verifica di assembly inline, operazioni di memoria, generazione di numeri casuali, codice correlato al timing
• Disassemblaggio: Verifica dell'impatto delle ottimizzazioni del compilatore sulle caratteristiche di sicurezza
• Analisi Runtime: Utilizzo di strumenti di debug per verificare l'incertezza dell'analisi statica

Punti di Controllo Chiave:

• Separazione dei privilegi (configurazione MPU)
• Implementazione della cancellazione della memoria (problema di ottimizzazione memset)
• Abilitazione dei canari dello stack
• Configurazione dello stack non eseguibile
• Difesa dagli attacchi hardware (side-channel, fault injection, manomissione fisica)
• Qualità della fonte di entropia

2. Interviste ai Partecipanti (Participant Interviews)

Caratteristiche del Campione (n=22):

• Formazione Educativa: 12 studenti universitari, 6 studenti di master, 4 dottorandi
• Esperienza di Corsi di Sicurezza: 8 persone senza background in corsi di sicurezza
• Esperienza Embedded: 14 persone con esperienza di sviluppo embedded

Progettazione dell'Intervista:

• Interviste semi-strutturate, durata 42-107 minuti (media 69 minuti)
• Domande derivate da problemi ricorrenti nell'analisi dei contributi
• Esplorazione della cognizione (conoscenza, fraintendimenti) e delle decisioni (priorità, compromessi)

Analisi dei Dati:

• Trascrizione con Otter AI e verifica manuale
• Codifica aperta indipendente da tre ricercatori
• Sviluppo iterativo del codebook: 8 temi, 40 sottotemi, 278 codici
• Risoluzione collaborativa dei conflitti di codifica, nessun test di affidabilità formale richiesto

Punti di Innovazione Tecnica

1. Metodologia Doppia: Per la prima volta combina analisi del codice su larga scala con interviste approfondite, rivelando sia "cosa" che "perché"
2. Prospettiva del Ciclo di Vita Completo: Dalla documentazione di progettazione → codice sorgente → binario → cognizione dello sviluppatore, tracciando l'evoluzione delle vulnerabilità
3. Framework di Analisi dell'Ecosistema: Identifica i problemi non solo attribuibili agli sviluppatori, ma anche coinvolgenti compilatori, fornitori, educazione e altri attori
4. Riproducibilità: Materiali di intervista e codebook pubblicamente disponibili (https://github.com/CactiLab/eCTF-User-Study-Material)

Configurazione Sperimentale

Dataset

Dati della Competizione:

• 2023 eCTF: Sistema di accesso senza chiave remoto (firmware veicolo + portachiavi)
• 2024 eCTF: Sistema di pompa per insulina (controllore + monitoraggio della glicemia + attuatore pompa)
• Progettazione di Riferimento: Scritta in linguaggio C, soddisfa i requisiti funzionali ma senza caratteristiche di sicurezza

Modello di Minaccia:

• Accesso fisico al dispositivo e ai canali di comunicazione
• Accesso al codice sorgente (esclusi chiavi/flag)
• Attacchi software, di rete e hardware

Metriche di Valutazione

Metriche Quantitative:

• Tasso di implementazione dei meccanismi di sicurezza (separazione dei privilegi, canari dello stack, cancellazione della memoria, stack non eseguibile)
• Tasso di difesa dagli attacchi hardware (side-channel, fault injection, manomissione asincrona)
• Distribuzione dell'utilizzo della fonte di entropia

Metriche Qualitative:

• Saturazione dei temi dell'intervista
• Tipi di fraintendimenti cognitivi
• Modelli di priorità decisionale

Metodi di Confronto

Confronto con la ricerca esistente:

• Ricerca di Analisi del Firmware (FirmXRay, Nino et al., Tan et al.): Solo analisi tecnica, questo articolo aggiunge dimensione cognitiva
• Ricerca BIBIFI: Focalizzata su sistemi a microprocessore, questo articolo si concentra su sfide uniche dei microcontrollori
• Ricerca di Adozione di Rust (Fulton et al., Sharma et al.): Questo articolo combina vincoli specifici embedded

Dettagli di Implementazione

• Collaborazione di tre ricercatori di livello PhD in sicurezza embedded
• Il team di autori ha partecipato alla competizione ma escluso dall'analisi del caso di studio
• Esenzione di revisione IRB
• Compenso di $50 per partecipante

Risultati Sperimentali

Risultati Principali

Statistiche delle Sfide Concettuali

1. Tasso di Implementazione dei Meccanismi di Sicurezza (Figura 1):

2. Tasso di Difesa dagli Attacchi Hardware (Figura 2):

• Qualsiasi Difesa: 17/47 (36.17%)
• Difesa Side-Channel: 13/17 (76.47%)
• Difesa Fault Injection: 9/17 (52.94%)
• Difesa Manomissione Asincrona: 7/17 (41.18%)

3. Utilizzo della Fonte di Entropia (Figura 3):

• 2023: 25% senza entropia, 25% hardcoded/difettoso, 45% fonte di entropia singola, 5% fonte di entropia mista
• 2024: 22.2% senza entropia, 14.8% hardcoded/difettoso, 55.6% fonte di entropia singola, 7.4% fonte di entropia mista

Statistiche delle Sfide Pratiche

Tasso di Adozione di Rust in Declino:

• 2023: 5/20 (25%) team utilizzano Rust
• 2024: 2/27 (7.4%) team utilizzano Rust
• Causa Principale: Nel 2024 l'SDK è voluminoso, la compilazione mista Rust+C supera i limiti di memoria flash

Esperimenti di Ablazione

Caso di Ottimizzazione del Compilatore per Cancellazione della Memoria

Caso T12 (Listing 1):

• Utilizzo di memset 10 volte per cancellare dati sensibili
• Il compilatore ottimizza 5 chiamate (inclusa la cancellazione della chiave AES)
• L'intervista allo sviluppatore rivela: completamente ignaro che il compilatore avrebbe ottimizzato

Casi di Implementazione Efficace:

• T20/T15: Utilizzo della libreria Monocypher crypto_wipe (parola chiave volatile)
• T14/T02: Utilizzo della libreria Rust zeroize
• T18: Funzione inline personalizzata per prevenire l'ottimizzazione

Problema di Configurazione dei Canari dello Stack

• Solo 2/47 team abilitano il flag del compilatore
• Nessun team inizializza il valore del canaro casuale (costante fissa predefinita)
• Coerente con il firmware reale: <0.2% tasso di abilitazione (ricerca Xi et al.)

Analisi dei Casi

Caso 1: Fraintendimento dello Stack Non Eseguibile (T18, T13)

Implementazione Errata:

// Script di collegamento di T18
MEMORY {
    FLASH (rx) : ORIGIN = 0x00008000, LENGTH = 0x00038000
    SRAM (rw) : ORIGIN = 0x20000000, LENGTH = 0x00008000  // Solo marcato rw
}

Problema:

• Modifica solo gli attributi dell'intestazione ELF, non configura l'MPU durante l'inizializzazione del firmware
• L'intervista rivela: 21/22 partecipanti ritengono che i flag del compilatore siano sufficienti

Implementazione Corretta (4 team):

1. Abilitazione dell'MPU
2. Configurazione della regione di memoria dello stack come XN (eXecute Never)
3. Abilitazione di quella regione

Caso 2: Abuso di Blocchi Unsafe di Rust (T11)

Problema: Utilizzo diffuso di blocchi unsafe per chiamare funzioni SDK C Motivo: Modello di sviluppo incrementale, consente la migrazione graduale del codice a Rust Confronto: C18-T08 limita unsafe all'interazione hardware di basso livello

Caso 3: Combinazione di Fonti di Entropia (T14)

Strategia: Combinazione di quattro fonti di entropia

• Deriva RTC e clock della CPU
• Seed specifico del dispositivo
• ADC della temperatura interna
• SRAM non inizializzata (effettivamente inefficace)

Effetto: Anche se una fonte fallisce, il seed combinato rimane imprevedibile

Risultati Sperimentali

Osservazione 1: L'ottimizzazione del compilatore può compromettere lo stato di sicurezza al di là della specifica del linguaggio (come la cancellazione della memoria)

Osservazione 2: La lacuna di conoscenza negli attacchi specifici embedded è il fattore principale che ostacola l'implementazione della difesa

Osservazione 3: Fattori decisionali di Rust: familiarità, supporto del fornitore, supporto della libreria, curva di apprendimento

Osservazione 4: Gli utenti di Rust affrontano sfide: compilazione no_std, implementazione HAL, gestione unsafe

Osservazione 5: La conversione automatica dei descrittori hardware in strutture Rust può accelerare lo sviluppo di HAL, ma la fedeltà e la sicurezza richiedono ulteriori ricerche

Osservazione 6: Nonostante le fonti di entropia limitate dei microcontrollori, la combinazione di più fonti disponibili può migliorare efficacemente la robustezza della casualità

Lavori Correlati

Ricerca su CTF

• Orientamento Educativo: Vigna et al. (framework iCTF), Vykopal et al. (CTF come strumento didattico)
• Analisi delle Sfide: Crispin et al. (esperienza Defcon CTF), Chung et al. (organizzazione delle trappole)
• Distinzione di questo Articolo: Per la prima volta combina analisi dei contributi con interviste, focalizzandosi sulle sfide di sviluppo sicuro piuttosto che sull'effetto educativo

Sviluppo Software Sicuro e Ricerca Utente

• Ricerca BIBIFI (Parker et al., Ruef et al., Votipka et al.): Analizza lo sviluppo di sistemi a microprocessore, scopre che la maggior parte delle vulnerabilità derivano da fraintendimenti piuttosto che da errori
• Ricerca di Adozione di Rust:
  • Fulton et al.: Prospettiva di sviluppatori di alto livello, identifica problemi di curva di apprendimento e supporto della libreria
  • Sharma et al.: Analizza 6000+ progetti Rust embedded, rivela supporto insufficiente dell'ecosistema
• Contributo di questo Articolo: Focalizzato su vincoli specifici dei microcontrollori, combina prospettiva tecnica e cognitiva doppia

Sicurezza dei Sistemi a Microcontrollore

• Tecnologie di Difesa: Separazione dei privilegi (Kage, ACES, EPOXY), CFI (μRAI, Silhouette, SHERLOC), randomizzazione (fASLR, HARM)
• Analisi del Firmware: FirmXRay, Nino et al., Tan et al. (analisi statica del firmware reale)
• Unicità di questo Articolo: Per la prima volta studia le sfide cognitive degli sviluppatori, non solo soluzioni tecniche

Conclusioni e Discussione

Conclusioni Principali

1. Responsabilità dell'Ecosistema: L'implementazione della sicurezza è una responsabilità condivisa di sviluppatori, educatori, ricercatori e fornitori
2. Esigenze Uniche dello Sviluppo MCU:
   • Comprensione approfondita delle caratteristiche della piattaforma (hardware, compilatore, toolchain)
   • Affrontare il comportamento opaco e controintuitivo del compilatore
   • Difesa dalle minacce uniche derivanti dall'accesso fisico
3. Lacuna Educativa: I corsi esistenti non preparano sufficientemente gli studenti ad affrontare le sfide specifiche embedded
4. Tre Sfide Concettuali Principali:
   • Applicazione insufficiente dei meccanismi di sicurezza fondamentali
   • Difficoltà di adattamento della piattaforma
   • Consapevolezza debole della difesa dagli attacchi hardware
5. Due Sfide Pratiche Principali:
   • Supporto limitato per linguaggi memory-safe
   • Mancanza di fonti di entropia di alta qualità

Limitazioni

1. Validità Esterna:
   • eCTF è un ambiente di competizione, gli elementi di gamification possono influenzare il comportamento
   • I partecipanti sono principalmente studenti/sviluppatori in fase iniziale, la generalizzazione all'ambiente industriale esperto è limitata
   • Gli autori ritengono che i risultati rappresentino un limite inferiore conservatore delle vulnerabilità reali
2. Ambito della Ricerca:
   • Non copre la dinamica della collaborazione di team e la struttura della competizione
   • La classificazione concettuale/pratica potrebbe avere sovrapposizioni
3. Limitazioni dei Dati:
   • I dati auto-riferiti potrebbero avere bias di aspettativa sociale
   • Dimensione del campione (n=22) relativamente piccola
   • Mancanza di dati dettagliati sul background educativo, le raccomandazioni educative sono preliminari
4. Modello di Minaccia:
   • Il modello di minaccia della competizione potrebbe non riflettere completamente tutti gli scenari reali

Direzioni Future

1. Ricerca Educativa: Revisione sistematica dei corsi di sicurezza embedded esistenti, identificazione delle lacune curriculari
2. Confronto Empirico: Indagine su professionisti esperti per determinare se affrontano sfide simili
3. Sviluppo di Strumenti:
   • Strumenti automatizzati per la separazione dei privilegi
   • Strumenti di verifica dell'ottimizzazione di sicurezza del compilatore
   • Strumenti per semplificare lo sviluppo di HAL Rust
4. Supporto del Fornitore:
   • SDK Rust completi o binding Rust-C
   • Trasparenza della fonte di entropia e standardizzazione dell'API

Valutazione Approfondita

Punti di Forza

1. Innovazione Metodologica:
   • Per la prima volta combina analisi del codice con interviste approfondite, rivelando sia "cosa" che "perché"
   • Prospettiva del ciclo di vita completo traccia l'evoluzione delle vulnerabilità
   • Forte riproducibilità (dati e codebook pubblici)
2. Rigore Empirico:
   • Analisi completa di 47 contributi di team
   • 22 interviste approfondite (media 69 minuti)
   • Triangolazione (codice, documentazione, interviste, disassemblaggio)
   • L'analisi qualitativa segue metodi maturi (Saldaña, Clarke & Braun)
3. Valore Pratico:
   • 9 raccomandazioni specifiche per 5 categorie di stakeholder
   • Identifica ostacoli sistematici (non solo errori personali)
   • Coerente con i tassi di vulnerabilità del firmware reale, verifica la rappresentatività dei risultati
4. Profondità di Intuizione:
   • Rivela come l'ottimizzazione del compilatore compromette la sicurezza (Osservazione 1)
   • Identifica la lacuna di conoscenza come ostacolo principale (Osservazione 2)
   • Scopre le sfide multidimensionali dell'adozione di Rust (Osservazioni 3-5)
5. Chiarezza della Scrittura:
   • Classificazione strutturata (concettuale vs pratica)
   • Ricchi casi di studio e esempi di codice
   • Grafici chiari (Figure 1-3)

Insufficienze

1. Limitazioni di Generalizzazione:
   • L'ambiente di competizione differisce dalla pratica industriale
   • I partecipanti hanno livello di esperienza iniziale
   • Copre solo due anni di dati (2023-2024)
2. Inferenza Causale:
   • Impossibile separare completamente l'effetto della pressione della competizione dalla lacuna di conoscenza
   • Nessun confronto sistematico tra background con/senza corso di sicurezza
3. Profondità dell'Analisi Quantitativa:
   • Mancanza di test di significatività statistica
   • Non quantifica l'importanza relativa di diversi fattori
   • Dimensione del campione di intervista relativamente piccola (n=22)
4. Valutazione degli Strumenti:
   • Non testa effettivamente l'effetto delle raccomandazioni proposte
   • Mancanza di esperimenti di intervento per verificare le misure di miglioramento
5. Copertura:
   • Focalizzato solo su piattaforme ARM Cortex-M
   • Non copre ambienti RTOS (solo bare-metal)
   • Non esplora profondamente i fattori di collaborazione di team

Impatto

1. Contributo Accademico:
   • Inaugura un nuovo paradigma di ricerca utente sulla sicurezza embedded
   • Fornisce base empirica per la riforma educativa
   • Identifica direzioni di miglioramento per compilatori e toolchain
2. Valore Pratico:
   • I fornitori possono migliorare SDK e documentazione
   • Gli educatori possono adattare i curricula
   • Gli sviluppatori possono evitare trappole comuni
3. Significato Normativo:
   • Supporta l'inclusione della sicurezza negli standard di sviluppo embedded
   • Fornisce analisi della causa radice delle vulnerabilità per gli organi di regolamentazione
4. Riproducibilità:
   • I materiali pubblici facilitano la verifica e l'estensione
   • Il metodo è applicabile ad altri CTF o competizioni di sviluppo

Scenari Applicabili

1. Educazione:
   • Progettazione di corsi di sicurezza dei sistemi embedded
   • Organizzazione e valutazione di competizioni CTF
   • Materiali di formazione per sviluppatori
2. Industria:
   • Audit di sicurezza dei dispositivi IoT
   • Miglioramento del ciclo di vita di sviluppo sicuro (SDL)
   • Selezione e configurazione della toolchain
3. Ricerca:
   • Ottimizzazione di sicurezza del compilatore
   • Adattamento embedded di linguaggi memory-safe
   • Automazione della difesa dagli attacchi hardware
4. Definizione di Standard:
   • Linee guida sulle migliori pratiche di sicurezza embedded
   • Requisiti di sicurezza dell'SDK del fornitore

Sintesi delle Nove Raccomandazioni Principali

Bibliografia (Selezionata)

1. Separazione dei Privilegi:
   • 16 Kage (Du et al., 2022)
   • 10 ACES (Clements et al., 2018)
   • 11 EPOXY (Clements et al., 2017)
2. Memory Safety:
   • 18 Ricerca di Adozione di Rust (Fulton et al., 2021)
   • 52 Sfide di Rust Embedded (Sharma et al., 2024)
3. Analisi del Firmware:
   • 65 FirmXRay (Wen et al., 2020)
   • 42 Sicurezza del Firmware IoT (Nino et al., 2024)
   • 56 Rassegna dei Sistemi Cortex-M (Tan et al., 2024)
4. Ricerca Utente:
   • 46 BIBIFI (Ruef et al., 2016)
   • 62 Fraintendimenti di Sicurezza degli Sviluppatori (Votipka et al., 2020)

Valutazione Complessiva: Questo è un articolo di ricerca utente di alta qualità sulla sicurezza embedded che rivela le sfide profonde dello sviluppo sicuro di sistemi a microcontrollore attraverso un metodo innovativo doppio. Il suo valore massimo risiede nella combinazione di analisi tecnica con cognizione dello sviluppatore, fornendo un percorso attuabile per migliorare educazione, strumenti e pratica. Sebbene presenti limitazioni di generalizzazione, la coerenza dei risultati con i tassi di vulnerabilità del firmware reale rafforza la credibilità delle conclusioni. Questo studio stabilisce un nuovo paradigma di ricerca per la comunità di sicurezza embedded, meritevole di ulteriore verifica e estensione da parte di lavori successivi.