Fuzzing per convalidare la sicurezza del SoC. Innovazione nella verifica

Fuzzing è per la verifica del software ciò che la randomizzazione è la verifica dell'hardware. Un approccio fuzzing può migliorare i test di sicurezza dell'hardware? Paul Cunningham (GM, Verification at Cadence), Raúl Camposano (Silicon Catalyst, imprenditore, ex CTO di Synopsys) e io continuiamo la nostra serie di idee di ricerca. Come sempre, feedback ben accetti.

L'innovazione

La scelta di questo mese è HyperFuzzing per la convalida della sicurezza del SoC. Gli autori hanno presentato questo documento all'ICCAD 2020. Sono di IIT Kanpur.

Questo è un approccio intrigante al fuzzing, adattato specificamente al moderno design dei SoC. Si basa su iper-proprietà verifica nelle simulazioni dinamiche. Queste iper-proprietà ragionano sui comportamenti insiemi di tracce, un approccio adatto al controllo della sicurezza. Gli autori offrono come esempi controlli del flusso di informazioni (i dati privilegiati non possono trapelare da A a B diciamo) e controlli di non interferenza (le azioni contraddittorie non devono interferire con il flusso dei calcoli). La sicurezza viene quindi verificata confrontando i pacchetti di tracce di simulazione con e senza manomissioni.

La manomissione in questo approccio può modellare diversi tipi di vulnerabilità a fonti non attendibili. Randomizzando le istruzioni del firmware, scrivi le istruzioni da un componente al NoC o esegui i bit flip in una memoria. Gli autori propongono anche diverse nuove metriche di copertura. Questi sono progettati per guidare le iterazioni alla manomissione nei casi più influenzati dalle precedenti esecuzioni di manomissione.

Il loro testcase è un piccolo ma rappresentativo SoC (dettagli in GitHub) eseguendo test del firmware rispetto ai blocchi crittografici, controllando la non interferenza e altre vulnerabilità. Eseguono anche l'avvio sicuro con controlli dei blocchi di dati. Hanno trovato più violazioni della sicurezza nei blocchi crittografici, tranne dove il blocco include la protezione ECC.

Il punto di vista di Paolo

La verifica della sicurezza è un argomento così importante e c'è molto lavoro in corso qui sia nel mondo accademico che nell'industria. Questo documento riunisce piacevolmente la copertura basata su mutazioni randomizzate con "iper-proprietà" su insiemi di tracce di simulazione per creare una soluzione innovativa che sia sia scalabile che efficace nel dimostrare i difetti di sicurezza.

Alcune proprietà di sicurezza possono essere formalmente definite solo su un insieme di tracce di simulazione. Ad esempio, "non interferenza" significa che un utente malintenzionato non può interferire con determinati calcoli protetti in un progetto. Per dimostrare l'interferenza, è necessario confrontare due tracce, identiche nello stimolo di input tranne che per la presenza di alcune azioni dell'attaccante in una traccia. Se i calcoli protetti nella traccia attaccata differiscono da quelli nella traccia dorata, allora c'è stata un'interferenza.

Gli autori creano il proprio linguaggio speciale per le asserzioni su più tracce e lo utilizzano per formulare proprietà di sicurezza per la non interferenza e la riservatezza. Creano un flusso personalizzato per manomettere in modo casuale le simulazioni e controllarne le proprietà di sicurezza tra simulazioni manomesse e non manomesse. Il loro algoritmo di manomissione casuale ha anche un'elegante euristica di apprendimento basata sulla copertura per guidarlo a trovare in modo più efficiente falle di sicurezza.

L'idea di asserzioni su più simulazioni è molto potente. Mi chiedo se sarebbe possibile estendere in modo pulito SystemVerilog per supportare questo tipo di asserzioni. Ciò potrebbe aprire la porta ad alcune interessanti estensioni native alla simulazione commerciale e agli strumenti formali. Un'altra possibilità potrebbe essere quella di estendere il nuovo Portable Stimulus Standard (PSS) per includere asserzioni che si estendono su più test generati.

Questo documento è una lettura facile e piacevole, anche se desidero qualche dettaglio in più sui risultati. Gli autori affermano che la loro soluzione trova buchi di sicurezza nel loro caso di test SoC open source, ma non ci sono dettagli su cosa siano questi buchi o su come il loro approccio si confronti con altri approcci in letteratura che potrebbero essere applicati per trovare gli stessi buchi.

Il punto di vista di Raull

Lo esaminerò prima dal punto di vista della maturità tecnologica. Mi piace l'idea in generale, un approccio molto interessante per valutare la sicurezza in un progetto. Detto questo, ogni progetto richiede ai progettisti di fornire seed test, manomissioni e specifiche di sicurezza in un nuovo linguaggio di asserzione. Per me questo limita saldamente l'approccio al dominio accademico per ora. Ottimo per dissertazioni e documenti, non ancora vicino a qualcosa che potrebbe fare il salto all'applicazione commerciale.

Metterò il mio cappello da investitore per la seconda sfida. La sicurezza è un argomento importante, senza dubbio. Ma al di fuori di alcuni domini che già conosciamo, ad esempio aerospaziale, difesa, sistemi di pagamento e processori/server. Non è ancora un problema esistenziale per la maggior parte degli OEM e dei costruttori di componenti. Sono disposti a selezionare una casella se generalmente previsto. Ma solo se l'impatto sui costi o sul time-to-market è minimo. Perché i loro clienti generalmente non pagheranno di più per la sicurezza. Il che lascia la sicurezza per la maggior parte dei mercati ancora dipendente dall'IP chiavi in ​​mano, come root of trust hardware e app facili da usare. Le soluzioni confezionate in uno di questi modi saranno investibili, altrimenti non tanto.

La mia opinione

Paul e Raúl hanno coperto la maggior parte di ciò che avrei potuto suggerire. Mi piace l'idea di Paul di estendere SVA, almeno per incoraggiare la sperimentazione con le iper-proprietà. Questo deve aprire una nuova classe di test interessanti, portando infine a nuovi metodi di verifica in bundle.

Condividi questo post tramite: Fonte: https://semiwiki.com/eda/299391-fuzzing-to-validate-soc-security-innovation-in-verification/