Fuzzowanie w celu sprawdzenia bezpieczeństwa SoC. Innowacja w weryfikacji

Fuzzing ma się do weryfikacji oprogramowania tym, czym randomizacja jest weryfikacją sprzętu. Czy podejście fuzzing może poprawić testowanie bezpieczeństwa sprzętu? Paul Cunningham (GM, Verification w Cadence), Raúl Camposano (Silicon Catalyst, przedsiębiorca, były dyrektor ds. technologii Synopsys) i ja kontynuujemy naszą serię dotyczącą pomysłów badawczych. Jak zawsze, opinie mile widziane.

Innowacja

Wybór w tym miesiącu to HyperFuzzing do sprawdzania bezpieczeństwa SoC. Autorzy zaprezentowali ten artykuł na ICCAD 2020. Pochodzą z IIT Kanpur.

To intrygujące podejście do fuzzingu, dostosowane specjalnie do nowoczesnego projektu SoC. Opiera się na hiper-własność sprawdzanie w symulacjach dynamicznych. Te hiperwłaściwości powodują koniec zachowań zestawy śladów, podejście dobrze dopasowane do sprawdzania bezpieczeństwa. Autorzy podają jako przykłady kontrole przepływu informacji (na przykład dane uprzywilejowane nie mogą wyciekać z punktu A do punktu B) oraz kontrole braku ingerencji (działania kontradyktoryjności nie mogą zakłócać przepływu obliczeń). Następnie sprawdza się bezpieczeństwo, porównując pakiety śladów symulacji z manipulacją i bez niej.

Manipulowanie przy tym podejściu może modelować różne typy luk w zabezpieczeniach niezaufanych źródeł. Losowo losując instrukcje oprogramowania sprzętowego, zapisz instrukcje z komponentu do NoC lub przerzuć bity w pamięci. Autorzy proponują także kilka nowych wskaźników pokrycia. Mają one na celu prowadzenie iteracji manipulacji wokół przypadków, na które największy wpływ miały poprzednie serie manipulacji.

Ich testem jest mały, ale reprezentatywny SoC (szczegóły w GitHub) przeprowadzanie testów oprogramowania układowego pod kątem bloków kryptograficznych, sprawdzanie braku zakłóceń i innych luk w zabezpieczeniach. Uruchamiają również bezpieczny rozruch z kontrolą bloków danych. Znaleźli wiele naruszeń bezpieczeństwa w blokach kryptograficznych, z wyjątkiem przypadków, gdy blok obejmuje ochronę ECC.

Pogląd Pawła

Weryfikacja bezpieczeństwa to bardzo ważny temat i wiele pracy w tej dziedzinie trwa zarówno w środowisku akademickim, jak i przemysłowym. Ten artykuł ładnie łączy randomizowane pokrycie oparte na mutacjach z „hiperwłaściwościami” w zestawach śladów symulacji, aby stworzyć innowacyjne rozwiązanie, które jest zarówno skalowalne, jak i skuteczne w demonstrowaniu luk w zabezpieczeniach.

Niektóre właściwości bezpieczeństwa można formalnie zdefiniować tylko na podstawie zestawu śladów symulacji. Na przykład „brak ingerencji” oznacza, że ​​osoba atakująca nie może ingerować w pewne chronione obliczenia w projekcie. Aby wykazać interferencję, należy porównać dwa ślady, identyczne pod względem bodźca wejściowego, z wyjątkiem obecności niektórych działań atakującego w jednym śladzie. Jeśli jakiekolwiek chronione obliczenia w zaatakowanym śladzie różnią się od tych w złotym śladzie, oznacza to zakłócenie.

Autorzy tworzą swój własny, specyficzny język dla twierdzeń na wielu śladach i wykorzystują go do formułowania właściwości bezpieczeństwa zapewniających brak zakłóceń i poufność. Tworzą niestandardowy przepływ, aby losowo manipulować symulacjami i sprawdzać ich właściwości bezpieczeństwa między symulacjami zmodyfikowanymi i nienaruszonymi. Ich algorytm losowego manipulowania ma również elegancką heurystykę uczenia się opartą na zasięgu, która pomaga mu skuteczniej znajdować luki w zabezpieczeniach.

Idea asercji w wielu symulacjach jest bardzo potężna. Zastanawiam się, czy byłoby możliwe czyste rozszerzenie SystemVerilog w celu obsługi tego rodzaju twierdzeń. Może to otworzyć drzwi do atrakcyjnych natywnych rozszerzeń symulacji komercyjnych i narzędzi formalnych. Inną możliwością może być rozszerzenie nowego standardu Portable Stimulus Standard (PSS) o twierdzenia obejmujące wiele generowanych testów.

Ten artykuł jest łatwy i przyjemny w czytaniu, chociaż chciałbym poznać więcej szczegółów na temat wyników. Autorzy twierdzą, że ich rozwiązanie znajduje luki w zabezpieczeniach w testamencie SoC typu open source, ale nie ma żadnych szczegółów na temat tego, czym są te luki ani jak ich podejście wypada w porównaniu z innymi podejściami w literaturze, które można zastosować do znalezienia tych samych luk.

Pogląd Raula

Najpierw przyjrzę się temu z punktu widzenia dojrzałości technologicznej. Ogólnie podoba mi się ten pomysł, bardzo ciekawe podejście do oceniania bezpieczeństwa w projekcie. To powiedziawszy, każdy projekt wymaga od projektantów zapewnienia testów początkowych, elementów manipulujących i specyfikacji bezpieczeństwa w nowatorskim języku asercji. Dla mnie na razie mocno ogranicza to podejście do domeny akademickiej. Świetnie nadaje się do prac dyplomowych i artykułów, ale nie jest jeszcze blisko czegoś, co mogłoby przejść do zastosowań komercyjnych.

Włożę kapelusz inwestora na drugie wyzwanie. Bezpieczeństwo to ważny temat, to nie ulega wątpliwości. Ale poza kilkoma domenami, które już znamy – na przykład lotnictwem, obronnością, systemami płatności i procesorami/serwerami. Nadal nie jest to problem egzystencjalny dla większości producentów OEM i konstruktorów komponentów. Są gotowi zaznaczyć pole, jeśli jest to ogólnie oczekiwane. Ale tylko wtedy, gdy wpływ na koszt lub czas wprowadzenia produktu na rynek jest niewielki. Ponieważ ich klienci generalnie nie zapłacą więcej za bezpieczeństwo. Co sprawia, że ​​bezpieczeństwo większości rynków nadal zależy od własności intelektualnej pod klucz, takich jak sprzętowe korzenie zaufania i łatwe w użyciu aplikacje. Rozwiązania spakowane w jeden z tych sposobów będą opłacalne, w przeciwnym razie nie tak bardzo.

Mój widok

Paul i Raúl omówili większość tego, co mogłem zasugerować. Podoba mi się pomysł Paula na rozszerzenie SVA, przynajmniej w celu zachęcenia do eksperymentowania z hiperwłaściwościami. To musi otworzyć nową klasę interesujących testów, prowadząc ostatecznie do nowych metod weryfikacji pakietowej.

Udostępnij ten post przez: Źródło: https://semiwiki.com/eda/299391-fuzzing-to-validate-soc-security-innovation-in-verification/