Fuzzing for å validere SoC-sikkerhet. Innovasjon i Verifisering

Fuzzing er for programvareverifisering hva randomisering er maskinvareverifisering. Kan en uklar tilnærming forbedre testing av maskinvaresikkerhet? Paul Cunningham (GM, Verification at Cadence), Raúl Camposano (Silicon Catalyst, gründer, tidligere Synopsys CTO) og jeg fortsetter serien vår om forskningsideer. Som alltid, tilbakemeldinger velkommen.

Innovasjonen

Denne månedens valg er HyperFuzzing for SoC-sikkerhetsvalidering. Forfatterne presenterte denne artikkelen på ICCAD 2020. De er fra IIT Kanpur.

Dette er en spennende tilnærming til fuzzing, spesielt tilpasset moderne SoC-design. Det bygger på hyper-eiendom sjekker inn dynamiske simuleringer. Disse hyper-egenskapene resonnere om atferd over sett med spor, en tilnærming som er godt egnet for sikkerhetskontroll. Forfatterne tilbyr som eksempler informasjonsflytsjekker (privilegerte data kan ikke lekke fra A til B si) og ikke-interferenssjekker (motstridende handlinger må ikke forstyrre beregningsflyten). Sikkerheten blir deretter kontrollert ved å sammenligne bunter av simuleringsspor med og uten tukling.

Tubling i denne tilnærmingen kan modellere ulike typer sårbarheter til upålitelige kilder. Ved å randomisere fastvareinstruksjoner, skriv instruksjoner fra en komponent til NoC, eller bitflips i et minne. Forfatterne foreslår også flere nye dekningsmålinger. Disse er utformet for å veilede iterasjoner til tukling rundt saker som er mest påvirket av tidligere tuklingkjøringer.

Testcasen deres er en liten, men representativ SoC (detaljer i GitHub) kjører fastvaretester mot kryptografiske blokker, sjekker for ikke-interferens og andre sårbarheter. De kjører også sikker oppstart med datablokkkontroller. De fant flere sikkerhetsbrudd i kryptoblokkene, bortsett fra hvor blokkeringen inkluderer ECC-beskyttelse.

Paulus syn

Sikkerhetsverifisering er et så viktig tema, og det pågår mye arbeid her både i akademia og i industrien. Denne artikkelen samler på en fin måte randomisert mutasjonsbasert dekning med "hyperegenskaper" over sett med simuleringsspor for å skape en innovativ løsning som er både skalerbar og effektiv til å demonstrere sikkerhetsfeil.

Noen sikkerhetsegenskaper kan formelt bare defineres over et sett med simuleringsspor. For eksempel betyr "ikke-interferens" at en angriper ikke kan forstyrre visse beskyttede beregninger i et design. For å demonstrere interferens, må du sammenligne to spor, identiske i inputstimulus bortsett fra tilstedeværelsen av noen angriperhandlinger i ett spor. Hvis noen beskyttede beregninger i det angrepne sporet avviker fra de i det gylne sporet, har det vært interferens.

Forfatterne skaper sin egen spesielle smak av språk for påstander over flere spor og bruker den til å formulere sikkerhetsegenskaper for ikke-interferens og konfidensialitet. De bygger en tilpasset flyt for å tilfeldig tukle med simuleringer og sjekke sikkerhetsegenskapene deres mellom tuklet og ikke-tuklet simulering. Deres tilfeldige manipuleringsalgoritme har også en elegant dekningsbasert læringsheuristikk for å veilede den til mer effektivt å finne sikkerhetsfeil.

Ideen om påstander over flere simuleringer er veldig kraftig. Jeg lurer på om det ville være mulig å utvide SystemVerilog til å støtte denne typen påstander. Dette kan åpne døren for noen overbevisende innfødte utvidelser til kommersiell simulering og formelle verktøy. En annen mulighet kan være å utvide den nye Portable Stimulus Standard (PSS) til å inkludere påstander som spenner over flere genererte tester.

Denne artikkelen er lett og hyggelig å lese, selv om jeg ønsker litt mer detaljer om resultatene. Forfatterne hevder at deres løsning finner sikkerhetshull i deres SoC-testcase med åpen kildekode, men det er ingen detaljer om hva disse hullene er eller hvordan deres tilnærming er sammenlignet med andre tilnærminger i litteraturen som kan brukes for å finne de samme hullene.

Raúl syn

Jeg skal først se på dette fra en teknologisk modenhetsvinkel. Jeg liker ideen generelt, en veldig interessant tilnærming til å gradere for sikkerhet i et design. Når det er sagt, krever hvert design at designere gir frøtester, manipulere og sikkerhetsspesifikasjoner i et nytt påstandsspråk. For meg binder dette tilnærmingen fast til det akademiske domenet for nå. Flott for avhandlinger og artikler, ennå ikke i nærheten av noe som kan gjøre hoppet til kommersiell bruk.

Jeg tar på meg investorhatten for den andre utfordringen. Sikkerhet er et viktig tema, ingen tvil. Men utenfor noen få domener kjenner vi allerede – for eksempel romfart, forsvar, betalingssystemer og prosessorer/servere. Det er fortsatt ikke et eksistensielt problem for de fleste OEM-er og komponentbyggere. De er villige til å merke av i en boks hvis det generelt er forventet. Men bare hvis innvirkningen på kostnader eller tid til markedet er liten. Fordi kundene deres vanligvis ikke betaler mer for sikkerhet. Noe som gjør at sikkerheten for de fleste markeder fortsatt er avhengig av nøkkelferdig IP, slik som maskinvarerøtter og brukervennlige apper. Løsninger pakket på en av disse måtene vil være investerbare, ellers ikke så mye.

Mitt syn

Paul og Raúl dekket det meste av det jeg kunne ha foreslått. Jeg liker Pauls idé om å utvide SVA, i det minste for å oppmuntre til eksperimentering med hyperegenskaper. Dette må åpne en ny klasse med interessante tester, som til slutt fører til nye sammensatte verifiseringsmetoder.

Del dette innlegget via: Kilde: https://semiwiki.com/eda/299391-fuzzing-to-validate-soc-security-innovation-in-verification/