Perché FPGAs richiedono un diverso modello di fiducia

Gli array di gate programmabili sul campo alimentano tutto, dai sistemi avanzati di assistenza al conducente e dai carichi satellitari alle infrastrutture 5G e ai circuiti di controllo industriali. In questi ambienti, un'immagine del firmware rogue può corrompere le funzioni di sicurezza, i segreti di esfiltrato, o trasformare un nodo affidabile in un vettore per il movimento laterale. Le due discipline di boot sicuro e gli aggiornamenti firmware crittografici convalidati non sono più extra opzionali - sono la base di una vita fidata.

A differenza di un microcontrollore indurito, un FPGA non esegue istruzioni da una maschera ROM fissa. Carica i dati di configurazione – spesso chiamati bitstream – che definisce il tessuto hardware stesso. Un bitstream manomesso può istantanare la logica segreta, bypassare le protezioni di memoria, o subvertire le letture dei sensori senza alterare una singola linea di codice di applicazione.

In primo luogo, le densità FPGA superano un milione di elementi logici, eseguendo sottosistemi complessi di processori, acceleratori di crittografia e condotte di inferenza AI sulla stessa die. In secondo luogo, la globalizzazione della catena di fornitura significa che i dispositivi possono essere forniti a produttori di contratto dove l'accesso fisico è incontrollato.

Threat Paesaggio per FPGA Dispositivi

Capire gli obiettivi dell’avversario affiora la progettazione delle contromisure. Le minacce cadono in larga misura in tre categorie: interferenza di fabbricazione-tempo, manipolazione del pre-boot e sostituzione di run-time.

  • Iniezione a catena di fornitura:[[] Gli avversari sostituiscono o modificano la memoria flash che tiene il bitstream di avvio, sia durante l'assemblaggio del bordo che durante il transito del dispositivo.
  • Estrazione del canale-side:[[] Un attaccante misura la potenza o le emanazioni elettromagnetiche per recuperare le chiavi di decrittografia.
  • Riconfigurazione indotta da un firmware:[] Una volta che un processore in esecuzione sul FPGA è stato compromesso, un aggressore può tentare di spingere un nuovo bitstream attraverso la porta di configurazione interna. I controlli di accesso e l'autenticazione a bitstream run-time possono bloccare il motore di configurazione anche quando il processore stesso è stato violato.
  • Attacchi di downgrade:[] Viene riattivata un'immagine firmware valida ma obsoleta con vulnerabilità note. I protocolli di aggiornamento sicuri devono tracciare i metadati della versione e far rispettare i contatori anti-rollback.
  • JTAG e abuso di interfaccia di debug:[ Le porte Debug lasciate attive nella produzione forniscono un percorso diretto per leggere o sovrascrivere la memoria di configurazione.

Una catena di avvio sicura adeguatamente progettata si rivolge a ciascuno di questi vettori controllando l'autenticità in ogni fase: prima immagine di avvio, successivi volumi del firmware, e qualsiasi sovrapposizione di carico o parziale regione di riconfigurazione.

Fondamenti di Secure Boot su FPGAs

Il boot sicuro su un FPGA verifica che il bitstream di configurazione caricato a power-on provenga da una fonte attendibile e non è stato modificato. La catena di verifica poggia su tre pilastri: firme crittografiche, una radice hardware di fiducia e un flusso di avvio a manomissione-evidente.

1. Firme crittografiche e Gerarchia chiave

Il produttore o l'integratore di sistema possiede una chiave privata che firma il bitstream dorato. La chiave pubblica corrispondente, incorporata in eFusibili programmabili di una volta o registri a batteria, agisce come la radice della fiducia. Durante il boot, un nucleo IP rigido legge la firma aggiunta al bitstream, ricomputa l'hash, e verifica la firma contro la chiave pubblica memorizzata.

Per limitare i danni da un compromesso chiave, molti progetti adottano una gerarchia chiave a due livelli: una chiave principale che firma chiavi secondarie, che a sua volta firmano i bitstreams applicativi reali. Questo consente di ruotare le chiavi di applicazione senza eFuses di ricombustionamento, un'operazione che è spesso una volta in natura.

2. Radice hardware della fiducia

Un blocco di sicurezza indurito all'interno del FPGA fornisce un punto di partenza immutabile. Ad esempio, i dispositivi Xilinx incorporano un'area di eFuse e DNA del dispositivo che può memorizzare un hash digerente o un hash chiave pubblica. Le famiglie Intel Agilex e Stratix 10 integrano un Gestione dispositivi Secure (SDM) che funge da coprocessore per l'autenticazione del boot.

Quando il FPGA manca di un blocco di sicurezza completo, gli ingegneri possono abbinarlo con un elemento esterno sicuro - come un [Microchip ATECC608[ o un TPM - che memorizza le chiavi e e effettua la verifica della firma.

3. Portata di avvio ammortizzante

Il flusso di avvio deve essere progettato in modo che ogni fase autentichi il successivo prima di passare il controllo.

  1. Hardware self-test:[] Il circuito di reset di potenza della FPGA stabilizza orologi e controlla l'integrità della logica interna. Molti dispositivi includono un controllo CRC della memoria di configurazione stessa.
  2. Carico chiave di gioco:[ Il blocco di sicurezza carica la chiave pubblica da eFuses o un elemento sicuro. In alcuni disegni, questo passaggio deriva anche una chiave di decrittazione della sessione dalla chiave di root.
  3. autenticazione a monte:[[] Il blocco boot loader legge il bitstream candidato, calcola un hash SHA-384 o SHA-256 e verifica la firma ECDSA o RSA. Se il bitstream è crittografato, il motore di decrittografia utilizza una chiave simmetrica non impostata dalla chiave root.
  4. Fallback e lockdown:[] In caso di guasto, la FPGA può riprovare da un'immagine d'oro designata memorizzata in una partizione flash separata. Se l'immagine d'oro fallisce, il dispositivo deve entrare in uno stato chiuso con funzionalità minime, emettendo un indicatore di guasto di avvio sicuro a un piano di gestione.

La crittografia da sola fornisce riservatezza ma non integrità se non abbinata a una modalità di crittografia autenticata come AES-GCM. Senza l'autenticazione, un aggressore può capovolgere bit nel testo cifrato senza conoscere la chiave, potenzialmente causando comportamenti sfruttabili. Pertanto, la migliore pratica è quella di utilizzare la crittografia accanto alla verifica della firma o di affidarsi a primitivi di crittografia autenticati in cui esiste il supporto al silicio.

Implementazione Stivale sicuro: una pratica

Gli ingegneri che si avvicinano al boot sicuro per la prima volta spesso si aggrappano all'integrazione della catena degli strumenti. I seguenti passaggi delineano un flusso di implementazione tipico per un dispositivo Xilinx UltraScale+ o Intel Agilex, anche se i concetti generalizzano alle famiglie Lattice, Microchip e Gowin con variazioni minori.

Passo 1: Provisione chiavi in sicurezza

Genera una coppia di tasti ECDSA P-384 o RSA-3072 in un modulo di sicurezza hardware (HSM) tenuto in una struttura fisicamente sicura. Sfrutta la chiave pubblica e programma la digerisci nelle eFuses di FPGA. Mai esporre la chiave privata al server di costruzione. Invece, la firma viene eseguita dal HSM, che riceve l'hash bitstream e restituisce un blob firma.

Passo 2: Configurare l'immagine di avvio

Gli strumenti del fornitore FPGA consentono di specificare i parametri di autenticazione durante la generazione a bitstream. Istruire lo strumento per riservare spazio alla firma, impostare la chiave pubblica digerire e abilitare la crittografia con una chiave AES avvolta dalla chiave di root. L'immagine risultante viene memorizzata in un quad-SPI esterno o NAND flash accessibile al controller di configurazione di FPGA.

Passo 3: Impostare le politiche di sicurezza nell'hardware

Una volta impostato, la FPGA respingerà qualsiasi bitstream che non abbia una firma valida, incluse le immagini predefinite fornite dal fornitore. Questo passo irreversibile deve essere eseguito solo dopo una valida valida valida convalida del laboratorio. In produzione, gli script ATE (automatated test) applicano le impostazioni del fuso come parte del test finale della linea. Alcune famiglie offrono anche una modalità di avvio chiave che consente di portare alla produzione una chiave di avvio di sviluppo.

Passo 4: Testare la catena

Convalida tutti gli scenari del mondo reale: avvio a freddo, reset caldo, recupero a brunire e bitstream deliberatamente danneggiato. Misurare la latenza di avvio— verifica della firma con acceleratori hardware in genere aggiunge sotto 100 millisecondi, ma questo può variare. Confermare che gli stivali di immagine dorati di caduta correttamente e che gli indicatori di guasto si propagano al controller di gestione del sistema.

Un riferimento noto per tale flusso è NIST []]Platform Firmware Resiliency Guidelines[]], che descrivono i requisiti di protezione, rilevamento e recupero applicabili a qualsiasi dispositivo programmabile.

Architettura di aggiornamento firmware sicuro

Anche l'immagine di avvio più rigorosamente verificata avrà bisogno di un aggiornamento, sia per patchare una vulnerabilità, aggiungere funzionalità, o allineare con una politica di sicurezza riveduta. Il meccanismo di aggiornamento deve fornire integrità end-to-end, autenticità e protezione rollback, riducendo al minimo i tempi di inattività.

Costruire una linea di aggiornamento attendibile

Un processo di aggiornamento sicuro inizia nell’infrastruttura ingegneristica e termina all’interno della logica di configurazione della FPGA.

  1. Image creazione e firma:[] Il sistema di costruzione produce un nuovo bitstream. Un HSM lo firma con una chiave privata attualmente attiva. La firma può essere avvolta in un manifesto che include le tracce di file, i metadati di versione e un timestamp.
  2. Sicurezza del trasporto:[[] L'immagine firmata viaggia oltre TLS 1.3 a un server di aggiornamento e poi al dispositivo. L'autenticazione reciproca tra il server e l'endpoint TLS del dispositivo impedisce attacchi man-in-the-middle. Il certificato TLS del dispositivo dovrebbe essere legato alla sua identità unica, come il DNA del dispositivo di FPGA.
  3. Riservazione di stato:[] Il dispositivo scrive l'immagine in arrivo a una partizione flash dedicata, mantenendo intatta l'immagine avviabile corrente. Questo sistema di partizione "A/B" garantisce che un aggiornamento fallito non in mattoni l'unità. Alcuni disegni utilizzano tre partizioni: A (attivo), B (backup), e G (immagine di fabbrica d'oro) per la massima affidabilità.
  4. Verifica di preinstallazione:[] L'agente di aggiornamento, se una routine software in esecuzione su un processore integrato o il proprio gestore di configurazione di FPGA, convalida la firma e controlla il numero di versione contro un contatore anti-rollback memorizzato.
  5. Attivazione atomica:[ Il puntatore di configurazione del boot viene aggiornato in un singolo, sicuro di potenza. Sul successivo reset, gli stivali FPGA dalla nuova immagine. Se l'immagine si rivela inutilizzabile, un timer del watchdog innesca un failback alla partizione precedente. Il timeout del watchdog dovrebbe essere abbastanza lungo per consentire un tentativo di avvio completo, ma abbastanza breve da rilevare un sistema bloccato.

Tecniche anti-Rollback

Per chiudere questo gap, progettare un contatore anti-rollback memorizzato in una memoria monotonica, non volatile, come eFuses o un modulo di piattaforma affidabile. Ogni manifesto del firmware include un numero di versione di sicurezza minimo. L'agente di aggiornamento confronta questo numero con il contatore memorizzato e rifiuta qualsiasi immagine la cui versione è inferiore.

Gestione della riconfigurazione parziale

Molti progetti ad alte prestazioni utilizzano la riconfigurazione parziale per scambiare moduli hardware al momento dell’esecuzione. Questi bitstream parziali devono essere autenticati rigorosamente come bitstream completi. Il flusso Xilinx Dynamic Function eXchange (DFX) supporta, ad esempio, l’autenticazione parziale bitstream autenticata in cui ogni modulo di riconfigurazione analizzabile ruota la propria firma.

Primitivi crittografici e considerazioni di performance

La scelta degli algoritmi influisce sia sulla sicurezza che sul tempo di avvio. Le curve ECDSA con P-256 o P-384 offrono firme compatte e una verifica rapida sugli acceleratori hardware, rendendolo una scelta popolare. RSA-2048 è ancora comune nei dispositivi più vecchi, ma richiede una maggiore archiviazione delle chiavi e tempi di verifica più lunghi.

Per la crittografia a bitstream in massa, AES-256 in modalità GCM fornisce sia la riservatezza che l'integrità. Molte famiglie FPGA più recenti includono motori AES-GCM rigidi che possono decifrare e autenticare bitstream multi-megabyte a velocità di filo. Gli ingegneri devono garantire che i vettori di inizializzazione (IV) non vengano mai riutilizzati; un generatore di numeri casuali basato su hardware o un contatore monotonico avvolto nella sessione di avvio

Un'analisi pratica della latenza da Xilinx guida utente di configurazione[] mostra che abilitare la decrittazione AES-256 e l'autenticazione basata su HMAC aggiunge circa 50-80 millisecondi al tempo di configurazione totale per un bitstream tipico di 25 MB, ben entro limiti accettabili per la maggior parte delle applicazioni incorporate.

Gestione chiave nel corso del ciclo di vita

La gestione delle chiavi è la parte più difficile di qualsiasi sistema di avvio sicuro. Un approccio lifecycle-aware segmenti l'uso chiave in fasi distinte:

  • ]Fornitura di fabbrica:[ L'hash della chiave pubblica radice è programmato in eFuses. La chiave privata è bloccata in un HSM offline e non lascia mai la struttura. Durante questa fase, l'identità unica del dispositivo (ad esempio, DNA del dispositivo) può essere fusa per consentire il binding di chiavi a singole unità.
  • Aggiornamenti file:[[] I tasti di firma secondari sono utilizzati per gli aggiornamenti firmware di routine. Queste chiavi sono firmate dalla chiave di root e possono avere una vita più breve o essere memorizzate in un HSM basato su cloud. La rotazione della chiave secondaria può essere automatizzata in modo che un dispositivo non funzioni mai con una chiave precedente, ad esempio, un anno.
  • End-of-life:[ Quando un prodotto viene decommesso, i certificati di revoca o un bit “uccidere” possono essere impostati per disabilitare in modo permanente la capacità di FPGA di accettare il nuovo firmware, rendendo il dispositivo inutilizzabile per un avversario che ottiene l’accesso fisico.

La rotazione automatica delle chiavi può essere implementata con la spedizione di un manifesto che contiene la nuova chiave pubblica, firmata dalla vecchia chiave. L'agente di aggiornamento verifica la catena, installa la nuova chiave in un registro protetto da scrittura, e poi avanza il contatore anti-rollback. La vecchia chiave può essere ritirata non appena il contatore si manifesta a tutti i dispositivi. Questo approccio è documentato nel [FLT: SU3]IAB Internet of Things Software Update Workshop[FFFFFFFFFFFFF][

Regolazione e allineamento degli standard di settore

Gli ingegneri nei settori automobilistico, medico e industriale devono allineare la sicurezza FPGA con le normative del settore. ISO 21434 per i veicoli stradali richiede un meccanismo di aggiornamento software sicuro e una radice hardware di fiducia per qualsiasi logica programmabile che influisce sulla sicurezza. IEC 62443 per i mandati dei sistemi di controllo industriale che i dispositivi verificano l'integrità del firmware prima dell'esecuzione e supportano gli aggiornamenti di campo autenticati.

Per applicazioni aerospaziale e di difesa, standard come DO-254 e FIPS 140-3 impongono requisiti aggiuntivi sul modulo crittografico e lo schema di gestione chiave. Utilizzando una libreria crittografica convalidata FIPS per la verifica della firma, anche se implementata nel tessuto FPGA, è possibile semplificare la certificazione. Inoltre, la scheda TPM 2.0 del Gruppo Trusted Computing fornisce un'interfaccia standardizzata per lo storage e l'attestazione chiave che possono essere sfruttati da FPMAs.

Migliori pratiche operative per la sicurezza delle pulci FPGA

La tecnologia non può garantire una flotta sicura. I team devono avvolgere la loro implementazione in pratiche operative robuste:

  • Seguire l'infrastruttura di costruzione:[[]] Isolare il server di firma dalla LAN aziendale. Utilizzare un HSM fisico per tenere le chiavi private e registrare ogni operazione di firma.
  • Controlli di accesso basati sul ruolo:[] Separare i doveri dello sviluppo, del test e della distribuzione a bitstream. Solo un gestore di rilascio designato dovrebbe essere in grado di avviare la firma di un'immagine di produzione.
  • Monitor e audit:[] I database di gestione patrimoniale devono monitorare la versione firmware, il controvalore anti-rollback e l'ultimo tempo di avvio di successo per ogni sistema di rilevamento FPGA distribuito. I sistemi di rilevamento di Anomaly dovrebbero contrassegnare i dispositivi che ripetutamente ricadono in un'immagine d'oro o in una versione mostra controsostituta che si spostano all'indietà .
  • Plan per la risposta agli incidenti:[] Avere una procedura pre-testata per la distribuzione di un aggiornamento firmware di emergenza in risposta a una vulnerabilità zero-day. Ciò include il mantenimento di una lista di revoca per le chiavi compromesse e garantire che il canale di aggiornamento rimanga raggiungibile anche su dispositivi parzialmente compromessi.
  • Condurre test di penetrazione regolari:[] Le valutazioni di sicurezza esterne dovrebbero mirare specificamente alla catena di configurazione FPGA. I vettori di attacco comuni includono l'abbattimento dell'alimentazione durante lo boot, l'estrazione di bitstream tramite JTAG, o lo sfruttamento della generazione IV debole nel motore di decrittografia.
  • Mantenere un inventario crittografico:[] Tenere un record di tutti i materiali chiave, tra cui la chiave pubblica digerire, l'autorità di certificazione chiave pubblica e le date delle rotazioni chiave.Questo inventario è essenziale quando si richiamano o aggiornano le chiavi attraverso la flotta.

Queste pratiche creano una postura di difesa-in-profondità che si estende dal silicio al backend cloud.

Il futuro della sicurezza FPGA: Post-Quantum e Oltre

I sistemi di firma basati su retice come CRYSTALS-Dilithium offrono dimensioni più piccole rispetto a RSA per la sicurezza equivalente, ma la velocità di verifica e la complessità di implementazione rimangono aree di ricerca attive. Alcuni fornitori di FPGA hanno iniziato a dimostrare acceleratori hardware per questi algoritmi, anticipando che le apparecchiature di infrastruttura a lungo ciclo avranno bisogno di un percorso di migrazione prima di un processo di elaborazione di grandi dimensioni

Inoltre, gli avanzamenti nella tecnologia PUF consentono di generare chiavi specifiche che non memorizzano mai le chiavi a riposo, riducendo ulteriormente la superficie di attacco. Combinare un PUF con una catena di avvio sicura che misura l'uscita PUF contro un dato di helper memorizzato, questo consente a ogni FPGA di derivare la propria chiave di root unica senza alcuna iniezione chiave durante la produzione.

Mentre i primitivi crittografici si evolvono, i principi sottostanti di avvio sicuro e aggiornamento firmware misurato rimangono costanti: ancorare la fiducia in hardware immutabile, misurare ogni link della catena di avvio, e non permettere mai codice non firmato per eseguire.