Fuzzing om SoC-beveiliging te valideren. Innovatie in verificatie

Fuzzing is voor softwareverificatie wat randomisatie hardwareverificatie is. Kan een vage aanpak het testen van hardwarebeveiliging verbeteren? Paul Cunningham (GM, Verification bij Cadence), Raúl Camposano (Silicon Catalyst, ondernemer, voormalig CTO van Synopsys) en ik vervolgen onze serie over onderzoeksideeën. Zoals altijd: feedback welkom.

De innovatie

De keuze van deze maand is HyperFuzzing voor SoC-beveiligingsvalidatie. De auteurs presenteerden dit artikel op ICCAD 2020. Ze zijn van IIT Kanpur.

Dit is een intrigerende benadering van fuzzing, specifiek aangepast aan modern SoC-ontwerp. Het bouwt voort hyper-eigendom het inchecken van dynamische simulaties. Deze hypereigenschappen redeneren over gedrag reeksen sporen, een aanpak die zeer geschikt is voor veiligheidscontroles. De auteurs geven als voorbeeld informatiestroomcontroles (bevoorrechte gegevens kunnen bijvoorbeeld niet van A naar B lekken) en niet-interferentiecontroles (tegengestelde acties mogen de rekenstroom niet verstoren). Vervolgens wordt de veiligheid gecontroleerd door bundels simulatiesporen met en zonder manipulatie te vergelijken.

Door knoeien met deze aanpak kunnen verschillende soorten kwetsbaarheden voor niet-vertrouwde bronnen worden gemodelleerd. Door firmware-instructies willekeurig te maken, instructies van een component naar de NoC te schrijven of bit-flips in een geheugen te maken. De auteurs stellen ook verschillende nieuwe dekkingsstatistieken voor. Deze zijn ontworpen om iteraties te begeleiden bij het knoeien met gevallen die het meest zijn beïnvloed door eerdere manipulaties.

Hun testcase is een kleine maar representatieve SoC (details in GitHub) het uitvoeren van firmwaretests tegen cryptografische blokken, waarbij wordt gecontroleerd op niet-interferentie en andere kwetsbaarheden. Ze voeren ook veilig opstarten uit met datablokcontroles. Ze vonden meerdere beveiligingsschendingen in de cryptoblokken, behalve waar de blokken ECC-bescherming bevatten.

De mening van Paul

Beveiligingsverificatie is een zeer belangrijk onderwerp en er wordt op dit gebied veel werk verricht, zowel in de academische wereld als in de industrie. Dit artikel brengt op mooie wijze gerandomiseerde, op mutaties gebaseerde dekking samen met ‘hypereigenschappen’ over sets simulatiesporen om een ​​innovatieve oplossing te creëren die zowel schaalbaar is als effectief in het aantonen van beveiligingsfouten.

Sommige beveiligingseigenschappen kunnen alleen formeel worden gedefinieerd via een reeks simulatiesporen. ‘Niet-interferentie’ betekent bijvoorbeeld dat een aanvaller zich niet kan bemoeien met bepaalde beveiligde berekeningen in een ontwerp. Om interferentie aan te tonen, moet u twee sporen vergelijken die identiek zijn qua invoerstimulus, behalve de aanwezigheid van enkele aanvalleracties in één spoor. Als beveiligde berekeningen in het aangevallen spoor verschillen van die in het gouden spoor, is er sprake van interferentie.

De auteurs creëren hun eigen speciale taal voor beweringen over meerdere sporen en gebruiken deze om beveiligingseigenschappen te formuleren voor niet-inmenging en vertrouwelijkheid. Ze bouwen een aangepaste stroom om willekeurig met simulaties te knoeien en hun beveiligingseigenschappen te controleren tussen gemanipuleerde en niet-gemanipuleerde simulaties. Hun algoritme voor willekeurige manipulatie heeft ook een elegante, op dekking gebaseerde leerheuristiek om het efficiënter te helpen beveiligingsfouten te vinden.

Het idee van beweringen over meerdere simulaties is zeer krachtig. Ik vraag me af of het mogelijk zou zijn om SystemVerilog netjes uit te breiden om dit soort beweringen te ondersteunen. Dit zou de deur kunnen openen voor enkele overtuigende native uitbreidingen van commerciële simulatie en formele tools. Een andere mogelijkheid zou kunnen zijn om de nieuwe Portable Stimulus Standard (PSS) uit te breiden met beweringen die zich over meerdere gegenereerde tests uitstrekken.

Dit artikel is gemakkelijk en plezierig te lezen, hoewel ik wel wat meer details over de resultaten zou willen hebben. De auteurs beweren dat hun oplossing veiligheidslekken in hun open-source SoC-testcase vindt, maar er zijn geen details over wat deze gaten zijn of hoe hun aanpak zich verhoudt tot andere benaderingen in de literatuur die zouden kunnen worden toegepast om dezelfde gaten te vinden.

De mening van Raúl

Ik ga hier eerst naar kijken vanuit een technologische volwassenheidshoek. Ik vind het idee in het algemeen leuk, een zeer interessante benadering om de veiligheid in een ontwerp te beoordelen. Dat gezegd hebbende, vereist elk ontwerp dat ontwerpers zaadtests, manipulaties en beveiligingsspecificaties leveren in een nieuwe beweringstaal. Voor mij beperkt dit de aanpak voorlopig stevig tot het academische domein. Geweldig voor proefschriften en papers, maar nog niet in de buurt van iets dat de sprong naar commerciële toepassing zou kunnen maken.

Ik zet mijn beleggershoed op voor de tweede uitdaging. Beveiliging is een belangrijk onderwerp, daar bestaat geen twijfel over. Maar buiten een paar domeinen kennen we het al – lucht- en ruimtevaart, defensie, betalingssystemen en processors/servers bijvoorbeeld. Voor de meeste OEM's en componentenbouwers is het nog steeds geen existentieel probleem. Ze zijn bereid een vakje aan te vinken als dat algemeen wordt verwacht. Maar alleen als de impact op de kosten of de time-to-market klein is. Omdat hun klanten over het algemeen niet meer willen betalen voor beveiliging. Waardoor de beveiliging voor de meeste markten nog steeds afhankelijk is van kant-en-klare IP, zoals hardwarewortels van vertrouwen en eenvoudig te gebruiken apps. Oplossingen die op een van deze manieren zijn verpakt, zullen investeerbaar zijn, anders niet zo veel.

Mijn mening

Paul en Raúl hebben het meeste besproken van wat ik had kunnen voorstellen. Ik hou van Pauls idee om de SVA uit te breiden, in ieder geval om experimenten met hypereigenschappen aan te moedigen. Dit moet een nieuwe klasse van interessante tests openen, die uiteindelijk tot nieuwe gebundelde verificatiemethoden moeten leiden.

Deel dit bericht via: Bron: https://semiwiki.com/eda/299391-fuzzing-to-validate-soc-security-innovation-in-verification/