💻 computer science

State Authenticity under Multiple Bus Masters: A Non-Secure DMA Gap and Mitigation for TrustZone-M Proofs of Executio

Questo articolo rivela che le prove di esecuzione di TrustZone-M sono vulnerabili alla manipolazione dello stato tramite controller DMA non sicuri poiché le loro garanzie di sicurezza si affidano esclusivamente all'isolamento della CPU, e propone una mitigazione leggera basata sulla sicurezza DMA per canale per garantire l'autenticità dello stato contro tutti i bus master.

Autori originali: Arash Razban

Pubblicato 2026-07-30

📖 7 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Arash Razban

Articolo originale sotto licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immaginate un mondo in cui piccoli e poco costosi computer sono sparsi ovunque: all'interno del vostro termostato intelligente, del vostro fitness tracker e persino nei sensori di un impianto industriale. Questi piccoli dispositivi dovrebbero essere reporter onesti, inviando dati come letture della temperatura o conteggi di movimenti. Ma cosa succederebbe se un hacker prendesse il controllo di uno di questi dispositivi e iniziasse a mentire, immettendo dati falsi in un enorme database nel cloud? Per impedirlo, utilizziamo una "prova di esecuzione" digitale. Pensatela come un notaio per i computer: il dispositivo firma una ricevuta dicendo: "Prometto di aver eseguito questo specifico problema matematico esattamente come richiesto, senza che nessuno abbia manomesso i numeri".

Affinché ciò funzioni, il dispositivo ha bisogno di due cose: un modo sicuro per dimostrare di aver eseguito il codice corretto e un modo per dimostrare che i dati utilizzati (lo "stato") non siano stati manomessi. Il documento di cui stiamo discutendo esamina una versione specifica e tecnologicamente avanzata di questo sistema di prova chiamato TrustZone-M, che è integrato in molti microchip moderni. È come una cassaforte super sicura all'interno del chip che separa i compiti "fidati" da quelli "non fidati". La grande domanda è: se un hacker riesce a penetrare nel lato "non fidato", può infilare furtivamente la modifica dei dati mentre il computer sta facendo i suoi calcoli, ingannando il sistema affinché firmi una falsa ricevuta? Questo articolo indaga se le attuali regole della cassaforte siano abbastanza forti da fermare un aiutante subdolo e invisibile capace di scrivere dati senza che il computer principale se ne accorga.

La Penna Invisibile: Come un Hacker "Fantasma" ha Ingannato un Chip Sicuro

Nel gioco ad alta posta della sicurezza embedded, i ricercatori hanno recentemente proposto uno schema ingegnoso chiamato SLAPP (Stateful Proofs of Execution). Immaginate SLAPP come un bibliotecario molto severo che vuole verificare che uno studente (il dispositivo) abbia risolto correttamente un problema di matematica. Il bibliotecario controlla due cose: prima, che lo studente abbia usato il libro di testo giusto (il codice) e, secondo, che non abbia imbrogliato cambiando i numeri nel suo quaderno (lo stato) mentre risolveva il problema.

La logica del bibliotecario era semplice e sembrava blindata: "Se lo studente prova a cambiare i numeri nel suo quaderno, deve prima aprire il libro di testo per trovare le istruzioni su come farlo. Ma poiché abbiamo uno scanner magico che controlla il libro di testo, qualsiasi modifica alle istruzioni verrebbe rilevata immediatamente. Pertanto, se il libro di testo appare perfetto, anche i numeri nel quaderno devono essere onesti".

Questo articolo, tuttavia, solleva il velo per rivelare un difetto in quella logica. I ricercatori hanno scoperto che lo "studente" non è l'unico che può scrivere nel quaderno. Esiste un secondo scrittore, invisibile: un controller DMA (Direct Memory Access).

Lo Scrittore "Fantasma"

Per capire il DMA, immaginate il processore principale del computer (la CPU) come uno chef impegnato a tagliare verdure. Lo chef è l'unico autorizzato a toccare il tagliere (la memoria) in cucina. Lo chef è osservato da una telecamera di sicurezza (l'isolamento TrustZone-M) che assicura che nessun altro possa toccare il tagliere.

Ma aspettate! C'è un braccio robotico (il controller DMA) seduto in cucina. Questo robot è programmato per spostare ingredienti dal frigorifero al tagliere automaticamente. La telecamera di sicurezza sta guardando solo le mani dello chef. Non sa che il robot esiste. Il robot può protendersi, afferrare un sacco di farina e rovesciarlo sul tagliere mentre lo chef è occupato a tagliare. Lo chef non vede il robot e la telecamera di sicurezza non sbatte le palpebre perché le mani dello chef non si sono mosse.

Nel mondo dello schema di sicurezza SLAPP, il "robot" è il controller DMA. I ricercatori hanno scoperto che il sistema di sicurezza stava controllando solo lo chef (la CPU). Presupponeva che se il libro di ricette (memoria del programma) non veniva modificato, nessuno avrebbe potuto cambiare gli ingredienti (lo stato). Ma il robot poteva cambiare gli ingredienti senza toccare il libro di ricette.

L'Attacco: Un Avvelenamento Silenzioso

I ricercatori hanno allestito un test su un chip reale (un microcontrollore STM32L5) per vedere se questo scrittore "fantasma" potesse effettivamente rompere il sistema. Hanno creato uno scenario in cui un hacker, che aveva già preso il controllo della parte "non fidata" del chip, ha usato il robot DMA per sostituire un numero legittimo con uno falso proprio nel mezzo del calcolo.

Ecco come si è svolta la truffa:

Il Controllo: La parte sicura del chip ha controllato il quaderno e ha visto che i numeri erano puliti. Ha dato il via libera.
La Sostituzione: Immediatamente dopo il controllo, ma prima che il risultato finale venisse firmato, il robot DMA è intervenuto e ha sostituito il numero con un valore "avvelenato".
La Firma: Il chip ha terminato il calcolo usando il numero avvelenato e ha firmato la ricevuta.
Il Risultato: La telecamera di sicurezza ha guardato il libro di ricette, ha visto che era intatto e ha accettato la ricevuta come valida.

Il risultato è stato una "prova di esecuzione" matematicamente valida ma fattualmente falsa. Il sistema ha certificato un risultato basato su dati che erano stati manomessi, mentre il computer principale pensava che tutto fosse in ordine.

Perché le Difese Solite sono Fallite

I ricercatori si sono poi chiesti: "Perché la sicurezza integrata del chip non ha fermato questo?". Hanno provato tre difese standard, e ognuna è fallita per un motivo diverso e curioso:

Il Tentativo di "Bloccare il Robot": Hanno cercato di dire al sistema di sicurezza di bloccare il braccio del robot. Ma il sistema ha risposto: "Io non controllo i robot; io controllo lo chef". Il cancello di sicurezza semplicemente non si applicava al robot.
Il Tentativo di "Bloccare il Tavolo": Hanno cercato di bloccare il tagliere in modo che nessuno potesse toccarlo. Ma questo era troppo restrittivo! Anche lo chef doveva scrivere sul tagliere. Se avessero bloccato il tagliere, lo chef non avrebbe potuto fare il suo lavoro e l'intero sistema si sarebbe fermato.
Il Tentativo dell' "Allarme": Hanno cercato di impostare un allarme che suonasse se il robot toccava il tagliere. Ma l'allarme suona solo se qualcuno infrange una regola. Poiché il robot era autorizzato a toccare il tagliere (era solo il tipo di tocco sbagliato per questa specifica regola di sicurezza), l'allarme è rimasto silenzioso.

La Soluzione: Addomesticare il Robot

La soluzione non è stata costruire un muro più grande o un allarme più rumoroso. È stata quella di dare al robot un piccolo tesserino di riconoscimento. I ricercatori hanno scoperto che il robot (il controller DMA) possedeva in realtà un interruttore nascosto al suo interno che poteva essere azionato dallo chef sicuro.

Azionando questo interruttore, il mondo sicuro poteva dire: "Questo specifico braccio robotico è ora sotto il mio controllo. Se l'hacker prova a dirgli di muoversi, lo ignorerà e segnalerà un'anomalia".

Questa correzione è stata sorprendentemente economica e facile. Non ha rallentato lo chef e non ha richiesto nuovo hardware. I ricercatori l'hanno testata mettendo in sicurezza tutti i bracci robotici sul chip. Quando hanno tentato nuovamente l'attacco, il robot si è rifiutato di muoversi, l'allarme è scattato e la falsa ricevuta è stata rifiutata.

La Grande Lezione

La lezione più importante di questo articolo non riguarda solo un chip specifico o un singolo trucco da hacker. È una lezione su come concepiamo la sicurezza.

Per molto tempo, i progettisti di sicurezza hanno assunto che se proteggi il cervello principale (la CPU), proteggi tutto. Questo articolo dimostra che sui chip moderni esistono altre "mani" che entrano nella memoria senza che il cervello se ne accorga. Se vuoi fidarti dei dati di un computer, non puoi limitarti a osservare il cervello; devi osservare ogni mano che può toccare i dati.

I ricercatori hanno dimostato che lo schema SLAPP, così come era stato pubblicato, aveva un buco nella sua logica perché aveva dimenticato le "mani robotiche". Non si sono limitati a trovare il buco; hanno mostrato esattamente come ripararlo con una correzione semplice e leggera. È un promemoria del fatto che, nel mondo dei piccoli computer, i hacker più pericolosi potrebbero non essere quelli che digitano su una tastiera, ma i robot invisibili che lavorano in sottofondo, in attesa che qualcuno si dimentichi di controllare il loro tesserino.

Sintesi Tecnica: Autenticità dello Stato sotto Molteplici Bus Master

Definizione del Problema
Il documento identifica una lacuna critica di correttezza nei sistemi di prova di esecuzione con stato (stateful proofs of execution) su piattaforme commodity Arm TrustZone-M, prendendo di mira specificamente lo schema SLAPP (pubblicato in IEEE TIFS 2025). SLAPP mira a fornire garanzie di attestazione remota che un dispositivo embedded a basso costo abbia eseguito correttamente una funzione su uno stato autentico e non modificato, anche se il mondo non sicuro (non-secure world) è completamente compromesso.

La vulnerabilità principale risiede nella Proprietà P4 (Autenticità dello Stato). L'argomento di sicurezza di SLAPP si basa su una riduzione: assume che qualsiasi avversario che manipoli lo stato attestato ( $S$ ) durante l'esecuzione debba modificare la memoria del programma ($PMEM$) per farlo. Poiché SLAPP misura l'integrità di $PMEM$, conclude che la manipolazione dello stato verrebbe rilevata.

Tuttavia, questa riduzione è infondata su hardware TrustZone-M. L'isolamento basato sull'indirizzo della piattaforma (SAU/IDAU) vincola solo la CPU. Altri bus master, come i controllori DMA, non sono soggetti a tali attributi di sicurezza centrati sulla CPU. Sulla piattaforma target STM32L5, i controllori DMA sono non-sicuri e programmabili per impostazione predefinita. Un avversario può programmare un canale DMA per scrivere direttamente nello stato attestato nella memoria dati senza che la CPU esegua alcuna istruzione, modificando così $S$ senza toccare $PMerm$. Di conseguenza, la misurazione $h = H(PMEM, \dots)$ rimane valida e la prova viene accettata nonostante lo stato sia stato avvelenato.

Metodologia
Gli autori validano questa lacuna utilizzando l'esatto hardware di riferimento e il modello di avversario definiti da SLAPP:

Modello di Minaccia: Un mondo non sicuro completamente compromesso con accesso a tutto il codice e i dati non sicuri, ma senza accesso alla memoria sicura o a guasti hardware.
Costruzione dell'Attacco: Gli autori hanno implementato un attacco puramente software su una scheda NUCLEO-L552ZE-Q:
- Un avversario non sicuro pre-arma un canale DMA (configurato per il trasferimento memoria-memoria) per sovrascrivere lo stato protetto (una cache a risposta randomizzata) con un valore avvelenato.
- L'attacco viene attivato all'interno della finestra "check-then-commit": dopo che il mondo sicuro verifica lo stato (CheckState) ma prima che lo stato venga confermato (SetState).
- Il trasferimento DMA viene eseguito autonomamente, corrompendo lo stato senza l'intervento della CPU.
Valutazione dell'Atomicità: Gli autori hanno testato l'attacco sia contro la configurazione rigorosa di SLAPP (interrupt disabilitati) sia contro la sua configurazione rilassata. Hanno dimostrato che la disabilitazione degli interrupt della CPU non vincola il bus master DMA, il che significa che l'attacco ha successo anche nella configurazione strettamente atomica, così come pubblicata.
Analisi delle Difese Native: Il documento valuta sistematicamente perché le strutture di isolamento native di TrustZone-M falliscono nel mitigare il problema:
- Peripheral Security Controller (TZSC): Non governa i controllori DMA; tentare di mettere in sicurezza i DMA tramite TZSC causa un errore di avvio (boot fault).
- Block-Based Memory Protection (MPCBB): Filtra in base agli attributi di sicurezza delle transazioni (sicuro vs non-sicuro) piuttosto che al master emittente. Non può distinguere tra una legittima scrittura della CPU non-sicura e una maliziosa scrittura DMA non-sicura; mettere in sicurezza i blocchi di memoria bloccherebbe la CPU, interrompendo lo schema.
- Illegal Access Controller (TZIC): Solo segnala le violazioni; non può impedire il trasferimento se l'accesso è tecnicamente "legale" (un master non-sicuro che scrive in memoria non-sicura).

Contributi Chiave

Prima Dimostrazione su Silicio: Il documento fornisce la prima prova empirica che uno schema di prova di esecuzione con stato pubblicato su TrustZone-M (SLAPP) fallisce nell'imporre la sua proprietà di autenticità dello stato contro un avversario DMA non-sicuro sul proprio hardware di riferimento.
Indipendenza dall'Atomicità: Gli autori dimostrano che la vulnerabilità non è il risultato di rilassamenti opzionali dell'atomicità, ma colpisce la configurazione strettamente atomica, poiché il mascheramento degli interrupt della CPU non vincola i bus master.
Analisi Sistematica delle Difese: Un'analisi dettagliata spiega perché le tre primitive di isolamento naturali di TrustZone-M (TZSC, MPCBB, TZIC) sono insufficienti, stabilendo vincoli di progettazione specifici per qualsiasi mitigazione corretta.
Mitigazione Leggera: Gli autori propongono e validano una correzione minima utilizzando la sicurezza nativa per canale del controller DMA (DMA_CCRx.SECM). Rendendo sicuri i canali DMA dal mondo sicuro durante il boot, il software non sicuro è impedito di riprogrammare il canale. Ciò blocca l'avversario a livello di master senza influenzare la capacità della CPU di leggere/scrivere lo stato.
Principio Generale: Il documento stabilisce che per qualsiasi schema di attestazione su una piattaforma con più master che opera su uno stato mutabile, l'autenticità deve essere mediata contro ogni bus master capace di scrivere lo stato, non solo la CPU.

Risultati

Successo dell'Attacco: Sulla scheda di riferimento, l'avversario è riuscito a corrompere lo stato attestato entro la finestra del protocollo. Lo schema non ha segnalato errori e il verificatore del prototipo ha accettato la prova relativa all'output avvelenato.
Successo della Mitigazione: Quando tutti i 16 canali DMA del dispositivo sono stati messi in sicurezza al boot:
- Il tentativo dell'avversario di riprogrammare il canale DMA è stato intercettato (è scattato l'interrupt di accesso illegale).
- Lo stato è rimasto non corrotto.
- Il protocollo benigno è stato eseguito correttamente con un overhead trascurabile (la correzione consiste in una singola scrittura di registro all'avvio).
- La correzione si è dimostrata "chirurgica", bloccando il percorso DMA pur preservando l'accesso legittimo della CPU allo stato.
Analisi dell'Overhead: La configurazione di atomicità rigorosa (disabilitazione degli interrupt) comporta un costo in tempo reale significativo (~654ms di finestra mascherata) ma fornisce zero beneficio di sicurezza contro la minaccia DMA; la configurazione rilassata rimuove questo costo senza sacrificare la sicurezza contro questo specifico vettore di attacco.

Significatività e Rivendicazioni
Il documento afferma che lo specifico schema SLAPP pubblicato non ha alcuna enforcement della sua garanzia di autenticità dello stato contro un avversario DMA non-sicuro sul suo hardware di riferimento. Il fallimento è radicato in una riduzione infondata nel suo argomento formale, che equipara erroneamente l'integrità dello stato all'integrità del codice sotto l'assunto di un singolo scrittore (CPU).

Gli autori sottolineano che si tratta di un fallimento dell'argomento e dell'implementazione specifica, non di una prova che nessuna attestazione di stato sicura sia possibile su TrustZone-M. La mitigazione proposta (sicurezza DMA per canale) è sufficiente per il carico di lavoro SLAPP pubblicato (che non utilizza DMA) e ripristina la proprietà di sicurezza prevista. Il documento conclude che qualsiasi schema di attestazione futuro che ragioni sullo stato mutabile su piattaforme con più master deve esplicitamente mediare tutti i bus master, non solo la CPU.