Fuzzing az SoC biztonság érvényesítéséhez. Innováció a hitelesítésben

A fuzzing a szoftverellenőrzésben azt jelenti, hogy mi a véletlenszerűség a hardveres ellenőrzés. Javíthatja-e a hardverbiztonsági tesztelést egy zavaros megközelítés? Paul Cunningham (GM, Verification at Cadence), Raúl Camposano (Silicon Catalyst, vállalkozó, volt Synopsys CTO) és én folytatjuk kutatási ötletekkel foglalkozó sorozatunkat. Mint mindig, szívesen fogadjuk a visszajelzéseket.

Az innováció

E havi választás az HyperFuzzing a SoC biztonsági ellenőrzéséhez. A szerzők ezt a tanulmányt az ICCAD 2020 kiállításon mutatták be. Az IIT Kanpurtól származnak.

Ez a fuzzing érdekes megközelítése, amelyet kifejezetten a modern SoC dizájnhoz igazítottak. Arra épít hipertulajdon dinamikus szimulációk ellenőrzése. Ezek a hipertulajdonságok a viselkedés megszűnését indokolják nyomok halmazai, amely jól illeszkedik a biztonsági ellenőrzéshez. A szerzők példaként kínálják az információáramlás-ellenőrzést (a privilegizált adatok nem szivároghatnak ki A-ból B-be) és az interferencia-ellenőrzést (a kontradiktórius cselekvések nem zavarhatják a számítások áramlását). A biztonságot ezután a szimulációs nyomok kötegeinek összehasonlításával ellenőrizzük manipulációval és anélkül.

Ennek a megközelítésnek a manipulálása különféle típusú sebezhetőségeket modellezhet nem megbízható forrásokból. A firmware-utasítások véletlenszerű besorolásával utasításokat írhat egy összetevőből a NoC-be, vagy bitátfordítja a memóriában. A szerzők számos újszerű lefedettségi mérőszámot is javasolnak. Ezeket úgy tervezték, hogy irányítsák az iterációkat a korábbi manipulációs futtatások által leginkább befolyásolt esetek manipulálásához.

A teszttok egy kicsi, de reprezentatív SoC (részletek itt GitHub) firmware-tesztek futtatása kriptográfiai blokkokkal szemben, az interferenciamentesség és egyéb sebezhetőségek ellenőrzése. Biztonságos rendszerindítást is futtatnak adatblokk-ellenőrzéssel. Több biztonsági megsértést találtak a kriptoblokkokban, kivéve ahol a blokkok ECC védelmet tartalmaznak.

Pál nézete

A biztonsági ellenőrzés nagyon fontos téma, és sok munka folyik itt mind a tudományos élet, mind az ipar területén. Ez a cikk remekül egyesíti a véletlenszerű mutáció alapú lefedettséget a szimulációs nyomok „hipertulajdonságaival”, hogy egy innovatív megoldást hozzon létre, amely egyszerre méretezhető és hatékony a biztonsági hibák kimutatására.

Egyes biztonsági tulajdonságok formálisan csak szimulációs nyomkövetéseken definiálhatók. Például a „nem interferencia” azt jelenti, hogy a támadó nem zavarhatja meg a terv bizonyos védett számításait. Az interferencia kimutatásához össze kell hasonlítania két nyomkövetést, amelyek a bemeneti inger tekintetében azonosak, kivéve néhány támadói művelet jelenlétét egy nyomon. Ha a megtámadott nyom bármely védett számítása eltér a golden trace-től, akkor interferencia történt.

A szerzők megalkotják saját, sajátos nyelvezetüket a több nyomon keresztüli állításokhoz, és ezt használják a beavatkozásmentesség és a bizalmasság biztonsági tulajdonságainak megfogalmazására. Egyéni folyamatot építenek fel a szimulációk véletlenszerű manipulálására, és ellenőrzik azok biztonsági tulajdonságait a manipulált és a nem manipulált szimulációk között. Véletlenszerű manipulációs algoritmusuk elegáns lefedettség-alapú tanulási heurisztikával is rendelkezik, amely segít a biztonsági hibák hatékonyabb megtalálásában.

A több szimuláción keresztüli állítások ötlete nagyon erős. Kíváncsi vagyok, hogy lehetséges lenne-e a SystemVerilog tiszta kiterjesztése az ilyen jellegű állítások támogatására. Ez megnyithatja az ajtót a kereskedelmi szimuláció és a formális eszközök néhány lenyűgöző natív kiterjesztése előtt. Egy másik lehetőség az új Portable Stimulus Standard (PSS) kiterjesztése több generált tesztre kiterjedő állításokkal.

Ez az írás könnyű és élvezetes olvasmány, bár szeretnék néhány további részletet az eredményekről. A szerzők azt állítják, hogy megoldásuk biztonsági lyukakat talál a nyílt forráskódú SoC tesztesetben, de nincsenek részletek arról, hogy mik ezek a lyukak, vagy hogy megközelítésük hogyan hasonlítható össze a szakirodalom más megközelítéseivel, amelyek alkalmazhatók ugyanazon lyukak megtalálására.

Raúl nézete

Ezt először a technológiai érettség szemszögéből nézem meg. Általában tetszik az ötlet, egy nagyon érdekes megközelítés a tervezés biztonsága érdekében. Ennek ellenére minden terv megköveteli a tervezőktől, hogy új állítási nyelven adjanak meg magteszteket, szabotázsokat és biztonsági specifikációkat. Számomra ez egyelőre határozottan az akadémiai területhez köti a megközelítést. Kiválóan alkalmas disszertációkhoz és dolgozatokhoz, még közel sincs valamihez, ami ugrást tehetne a kereskedelmi alkalmazáshoz.

Felteszem a befektetői kalapomat a második kihívásra. A biztonság fontos téma, nem kérdés. De az általunk már ismert néhány tartományon kívül – például repülés, védelem, fizetési rendszerek és processzorok/szerverek. Ez továbbra sem jelent egzisztenciális problémát a legtöbb OEM és alkatrészgyártó számára. Hajlandóak bejelölni egy négyzetet, ha általában elvárják. De csak akkor, ha a költségekre vagy a piacra jutás idejére gyakorolt ​​hatás csekély. Mert ügyfeleik általában nem fizetnek többet a biztonságért. Ez a legtöbb piac biztonságát továbbra is a kulcsrakész IP-től függ, például a bizalom hardveres gyökerei és a könnyen használható alkalmazások. Az ilyen módon csomagolt megoldások befektethetőek lesznek, különben nem annyira.

Az én nézetem

Paul és Raúl foglalkoztak azzal, amit javasoltam volna. Tetszik Paul ötlete az SVA kiterjesztésére, legalábbis a hipertulajdonságokkal való kísérletezés ösztönzésére. Ennek meg kell nyitnia az érdekes tesztek új osztályát, amely végül új, összevont ellenőrzési módszerekhez vezet.

Oszd meg ezt a bejegyzést ezen keresztül: Forrás: https://semiwiki.com/eda/299391-fuzzing-to-validate-soc-security-innovation-in-verification/