💻 computer science

SPARC: Automated Root-Cause Analysis of Pre-Silicon Power Side-Channel Leakage in the Processor Design Flow

Questo articolo presenta SPARC, un framework automatizzato pre-silicio che sfrutta l'Information Flow Tracking a livello di macro-cella per rilevare, valutare e individuare con efficienza le specifiche cause radici hardware e software della fuga di canali laterali di potenza nei design di processori, ottenendo incrementi significativi della velocità di simulazione rispetto ai metodi esistenti.

Autori originali: Andrija Nešković, Christian Ewert, Mladen Berekovic, Saleh Mulhem

Pubblicato 2026-07-28

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Andrija Nešković, Christian Ewert, Mladen Berekovic, Saleh Mulhem

Articolo originale sotto licenza CC BY 4.0 (http://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

Immagina di avere una ricetta segretissima per una torta deliziosa. La scrivi, la chiudi in una cassaforte e dai istruzioni a un robot per cucinarla. Pensi di essere al sicuro perché il robot non può leggere i tuoi appunti. Ma cosa succederebbe se il forno del robot emettesse un "ronzio" diverso quando mescola lo zucchero rispetto a quando mescola la farina? O se il contatore di energia del robot lampeggiasse leggermente più intensamente quando manipola l'ingrediente segreto? Un ladro astuto che si trova nelle vicinanze potrebbe ascoltare quei ronzii o osservare il contatore dell'energia per scoprire la tua ricetta, anche senza mai vedere gli appunti. Questo è l'inquietante scenario degli "attacchi side-channel di potenza" nel mondo dei chip informatici. I computer moderni sono come questi robot; elaborano dati segreti (come le tue password o le chiavi di cifratura) utilizzando l'elettricità. Ogni volta che un minuscolo interruttore all'interno del chip si accende o si spegne, consuma una minuscola quantità di energia. Se il pattern di questi sbalzi di potenza dipende dai dati segreti, un attaccante esperto può ascoltare l'uso dell'energia e rubare i segreti.

Per fermare questo, gli ingegneri devono controllare il design dei loro chip prima che vengano fisicamente costruiti (una fase chiamata "pre-silicio"). Devono trovare esattamente dove e quando il chip sta accidentalmente sussurrando segreti attraverso il suo consumo di energia. Il problema è che i chip moderni sono incredibilmente complessi. Cercare di controllare ogni singolo componente è come cercare di trovare un ago specifico in un pagliaio guardando ogni singolo pezzo di paglia uno alla volta: richiede un tempo infinito ed è spesso impossibile. Gli strumenti esistenti sono o troppo lenti per gestire progetti di grandi dimensioni o non sono in grado di dirti quale specifica istruzione del software o quale filo dell'hardware stia causando la fuga. Ti dicono solo: "Ehi, c'è una perdita da qualche parte", ma non ti forniscono la mappa per ripararla.

Entra in scena SPARC, un nuovo strumento di rilevamento automatizzato introdotto dai ricercatori Andrija Nešković e dal suo team. Pensa a SPARC come a una guardia di sicurezza super intelligente e veloce che non si limita a guardare l'intero edificio; indossa "occhiali oscurati" speciali che le permettono di vedere solo le parti del chip che toccano i dati segreti. Invece di controllare ogni singolo filo del processore, SPARC utilizza una tecnica chiamata "Information Flow Tracking" (tracciamento del flusso di informazioni) per etichettare i dati segreti mentre si muovono attraverso il chip. Successivamente, crea una versione speciale a "ombra" del chip che presta attenzione solo ai fili che trasportano questi dati etichettati.

Ecco come SPARC risolve il mistero:

L'Etichettatura: Quando il chip esegue un programma segreto (come un algoritmo di cifratura), SPARC etichetta i dati. È come mettere un adesivo luminoso su ogni pezzo di informazione segreta.
L'Ombra: SPARC crea una versione semplificata e veloce del chip che traccia solo gli adesivi luminosi. Ignora tutto il resto. Questo rende la simulazione incredibilmente veloce — circa 8 volte più veloce dei metodi precedenti per progetti simili.
L'Ascolto: Mentre il chip è in funzione, SPARC misura la "potenza" degli adesivi luminosi. Utilizza un test statistico (un modo matematico elegante per dire: "questo pattern è diverso per caso o per progettazione?") per individuare esattamente quali momenti temporali il chip sta perdendo segreti.
La Causa Radice: Questa è la parte magica. Una volta che SPARC trova una perdita, non si ferma lì. Traccia l'adesivo luminoso fino all'esatto filo dell'hardware che sta sfarfallando e all'esatta riga di codice nel software che l'ha causata. Dice agli ingegneri: "Ehi, il segreto sta perdendo perché questa specifica istruzione del programma interagisce con questo specifico registro nel chip".

I ricercatori hanno testato SPARC su tre diversi tipi di processori (piccoli per compiti semplici e grandi, veloci, per lavori complessi) e due diversi tipi di matematica segreta (un codice classico chiamato AES e un nuovo codice resistente ai computer quantistici chiamato ML-KEM). Hanno scoperto che SPARC poteva individuare con successo perdite note e persino scoprire nuove e subdole perdite nei processori "out-of-order" (chip che eseguono le cose in un ordine diverso per essere più veloci) che si nascondevano anche quando il software cercava di occultare i segreti.

Per esempio, su uno dei processori, SPARC ha scoperto che, anche se il software utilizzava una tecnica di "masking" (un modo per rimescolare il segreto in modo che sembri casuale), il "reorder buffer" interno del chip (una sala d'attesa per le istruzioni) stava accidentalmente perdendo la forma del segreto attraverso il proprio consumo di energia. SPARC ha individuato i segnali hardware esatti e le specifiche istruzioni software responsabili.

I risultati sono promettenti: SPARC può analizzare un processore complesso che esegue un compito di cifratura massiccio in sole poche ore (o addirittura minuti per compiti più semplici), mentre i metodi più vecchi potrebbero richiedere giorni o fallire completamente. Fornendo agli ingegneri una mappa chiara di cosa sta perdendo e del perché, SPARC li aiuta a correggere il design prima che il chip venga mai costruito, rendendo i futuri computer molto più difficili da hackerare. È come dare allo chef una lista esatta di quali ingredienti stanno facendo ronzare il forno, così che possa cambiare la ricetta o il design del forno prima che qualcuno rubi il segreto.

Riepilogo Tecnico: SPARC – Analisi Automatica della Root-Cause della Leakage di Potenza Side-Channel Pre-Silicon

1. Definizione del Problema

La Leakage Side-Channel di Potenza (PSCL) rappresenta una grave minaccia alla riservatezza del software crittografico, originando da artefatti architettonici e micro-architetturali nei design dei processori. Sebbene esistano contromisure hardware e software (ad esempio, il masking), le vulnerabilità a livello di CPU possono compromettere queste protezioni. Esiste una lacuna critica nella valutazione pre-silicon: gli attuali framework mancano della capacità di fornire simultaneamente scalabilità, sensibilità ai segreti e attribuzione della root-cause congiunta hardware-e-software.

Gli approcci esistenti soffrono di limitazioni fondamentali:

Analisi a livello di gate: La dipendenza da netlist complete a livello di gate risulta in tempi di esecuzione impraticabili (ad esempio, superiori a 60 ore per design con circa 100k celle).
Analisi a livello di Software/ISA: Spesso ignora ampie porzioni di attività di commutazione o non riesce ad attribuire la leakage ai sottostanti segnali hardware.
Scalabilità vs. Precisione: Nessun framework esistente offre un metodo scalabile per identificare quando avviene la leakage, quali segnali hardware contribuiscono e quali istruzioni software le innescano all'interno di un contesto pre-silicon.

2. Metodologia: Framework SPARC

SPARC è un framework automatizzato progettato per valutare la PSCL e svolgere l'analisi della root-cause direttamente dalla simulazione. Opera al livello di macro-cella, fungendo da astrazione intermedia tra l'RTL di alto livello e le netlist a basso livello di gate. Questo livello rappresenta il design come grafi di primitive funzionali parametrizzate (adder, multiplexer, comparatori), preservando la struttura semantica pur evitando la complessità dell'HDL e i problemi di scalabilità del livello di gate.

Il framework opera in quattro fasi distinte:

2.1 Strumentazione (Macro-Cell IFT)

SPARC utilizza una passata di trasformazione dedicata (implementata come una passata Yosys) per strumentare i design RTL con Information Flow Tracking (IFT) e logica di stima della leakage.

Propagazione del Taint: Traccia la raggiungibilità dei dati segreti (ad esempio, chiavi crittografiche) attraverso l'hardware.
Leakage Shadows: Per ogni segnale $s$ $s$ , viene generata una leakage shadow $s_{leak}$ $s_{l e ak}$ . Un segnale è considerato in leakage se è sia tainted (influenzato dal segreto) sia in transizione (cambia stato).
- Per elementi sequenziali: $s_{leak}[i][t] = (s[i][t] \oplus s[i][t-1]) \land s_{t0}[i][t]$ , dove l'XOR rileva le transizioni e l'AND impone la dipendenza dalla chiave.
- Per nodi combinatori: Viene applicato un modello conservativo ( $s_{leak} = s_{t0}$ ), assumendo che qualsiasi cambiamento in uscita sia propagazione di leakage.

2.2 Quantificazione

La strumentazione aggrega gli indicatori di leakage per segnale in contatori scalari per ciclo di simulazione per modellare il consumo di potenza dinamica:

Contatore Hamming Weight (HW): Conta il numero di bit tainted che mantengono un valore logico 1 (modellando la potenza dipendente dalla carica).
Contatore Hamming Distance (HD): Conta il numero di bit tainted che sono transitati dal ciclo precedente (modellando la potenza basata sulla transizione).
Questi contatori forniscono una proxy accurata per ciclo della potenza dinamica dipendente dalla chiave, configurabile per target specifici o l'intero design.

2.3 Valutazione della Leakage (TVLA)

Per rilevare la leakage, SPARC impiega la Test Vector Leakage Assessment (TVLA) utilizzando il t-test di Welch.

Generazione delle Tracce: Vengono generate coppie di tracce di simulazione dove il plaintext e la casualità del masking sono identici, ma la chiave segreta differisce ( $K_0$ vs $K_1$ ).
Test di Ipotesi: Per ogni ciclo di simulazione, i valori dei contatori HW/HD tra i gruppi di tracce vengono confrontati.
Criterio di Decisione: Un ciclo è classificato come in leakage se $|t| > 4.5$ . Ciò identifica intervalli temporali specifici in cui l'attività di commutazione aggregata filtrata dal taint è statisticamente dipendente dalla chiave.

2.4 Attribuzione della Root-Cause

Una volta identificati gli intervalli di leakage, SPARC esegue un'attribuzione in due fasi:

Attribuzione a livello di Segnale: All'interno di una finestra di leakage, i singoli fili di leakage shadow vengono confrontati tra i gruppi di chiavi. I segnali sono classificati in base alla differenza cumulativa di Hamming weight dipendente dalla chiave ( $\Delta_s$ ) per identificare i dominanti carrier hardware della leakage.
Attribuzione a livello di Istruzione: I valori del Program Counter (PC) registrati durante la simulazione vengono mappati su funzioni e righe di codice sorgente. Ciò collega i segnali hardware specifici alle istruzioni software in esecuzione (ad esempio, specifiche operazioni di load/store o branching).

3. Contributi Chiave

IFT a livello di Macro-Cell: L'impiego dell'IFT a livello di macro-cella consente l'identificazione scalabile delle fonti di leakage sia attraverso i segnali hardware che le istruzioni software, colmando il divario tra analisi RTL e analisi a livello di gate.
Analisi Automatica della Dual Root-Cause: Il framework fornisce unicamente una pipeline che rileva i cicli di leakage, individua i segnali hardware specifici e li mappa nuovamente alle istruzioni software in esecuzione.
Ambiente di Simulazione Scalabile: Una passata di trasformazione dedicata integrata in Verilator permette l'esecuzione di software crittografici e la raccolta di tracce di leakage dipendenti dal segreto con un overhead di runtime significativamente ridotto rispetto agli approcci a livello di gate.
Modellazione Quantitativa della Leakage: L'estensione dell'IFT per modellare la leakage basata sia sul valore (HW) che sulla transizione (HD) fornisce un flusso di valutazione pre-silicon veloce e scalabile.

4. Risultati Sperimentali

Il framework è stato validato su tre processori RISC-V open-source con diverse complessità micro-architetturali:

Ibex: 2-stage in-order, 32-bit (RV32IMC).
Proteus: Out-of-order superscalar configurabile, 32-bit (RV32IM).
Rocket: 5-stage in-order, 64-bit (RV64G).

Carichi di lavoro:

AES-128 (Unmasked e First-order Boolean Masked).
ML-KEM (CRYSTALS-Kyber-512, Unmasked).

Risultati:

Rilevamento della Leakage: SPARC ha rilevato con successo la leakage dipendente dalla chiave in tutte le combinazioni processore-algoritmo, localizzando la leakage in specifici cicli di simulazione.
Leakage Micro-architetturale: Nell'implementazione AES-128 mascherata sul processore Proteus, SPARC ha identificato artefatti di leakage micro-architetturali (specificamente nel reorder buffer, nel branch target predictor e nel bus AXI) che violavano le assunzioni di masking, esponendo informazioni dipendenti dalla chiave nonostante la protezione software di primo ordine.
Precisione della Root-Cause: Il framework ha mappato con successo i picchi di leakage a segnali hardware specifici (ad esempio, Scheduler_rob_ssbPredictorEntries) e istruzioni software (ad esempio, add_round_key, memcpy).
Performance: SPARC ha ottenuto un velocizzazione di 8x per traccia rispetto ai precedenti approcci (ad esempio, Telescope) su design comparabili.
- Tempo totale di valutazione per AES (mascherato e unmasked) sul complesso core Proteus era < 25 minuti.
- Tempo totale di valutazione per Kyber-512 su Proteus era di ~10 ore.
- L'overhead di strumentazione è stato ragionevole (< 9 minuti per processori complessi) e la dimensione del design è aumentata solo di circa l'11-12%.

5. Significato e Claim

L'articolo sostiene che SPARC fornisca un framework pratico per mitigare la PSCL precocemente nel flusso di design. Consentendo un'analisi della root-cause precisa e scalabile nella fase pre-silicon, permette ai progettisti hardware di rivedere l'RTL (ad esempio, implementando percorsi dedicati per il caricamento delle chiavi o la pulizia degli stati che contengono segreti) e agli sviluppatori software di ristrutturare le operazioni crittografiche immediatamente.

Gli autori sottolineano che SPARC affronta le "tre domande fondamentali" dell'analisi della root-cause:

RQ1: In quali cicli di simulazione il design perde informazioni?
RQ2: Quali segnali contribuiscono alla leakage?
RQ3: Quali istruzioni software causano la leakage?

Il lavoro posiziona lo strumento per iterazioni rapide di assess–modify–reassess durante la fase di design, distinto dagli strumenti di verifica formale che offrono garanzie per design finalizzati ma con costi computazionali elevati. Il framework è destinato a rafforzare la sicurezza dei futuri processori identificando e remediando le fonti di leakage prima della fabbricazione del silicio.