Фаззинг для проверки безопасности SoC. Инновации в проверке

Нечеткость для проверки программного обеспечения - это то же самое, что рандомизация для проверки оборудования. Может ли фаззинг улучшить тестирование аппаратной безопасности? Пол Каннингем (GM, Verification at Cadence), Рауль Кампосано (Silicon Catalyst, предприниматель, бывший технический директор Synopsys) и я продолжаем нашу серию статей об исследовательских идеях. Как всегда, отзывы приветствуются.

Инновация

Выбор в этом месяце HyperFuzzing для проверки безопасности SoC. Авторы представили этот документ на ICCAD 2020. Они из IIT Kanpur.

Это интригующий подход к фаззингу, специально адаптированный к современному дизайну SoC. Он основан на гипер-свойство проверка в динамическом моделировании. Эти гипер-свойства приводят к тому, что поведение наборы следов, подход, хорошо подходящий для проверки безопасности. Авторы предлагают в качестве примеров проверки информационного потока (например, привилегированные данные не могут просочиться от A к B) и проверки невмешательства (противоборствующие действия не должны мешать потоку вычислений). Затем безопасность проверяется путем сравнения пакетов имитационных трассировок с вмешательством и без него.

Подделка этого подхода может моделировать различные типы уязвимостей для ненадежных источников. Путем рандомизации инструкций прошивки записывайте инструкции из компонента в NoC или меняйте бит в памяти. Авторы также предлагают несколько новых показателей охвата. Они предназначены для проведения итераций по вмешательству в дела, на которые больше всего повлияли предыдущие прогоны вмешательства.

Их тестовый образец представляет собой небольшую, но репрезентативную SoC (подробности см. GitHub) запускать тесты прошивки на криптографические блоки, проверять невмешательство и другие уязвимости. Они также запускают безопасную загрузку с проверкой блоков данных. Они обнаружили множественные нарушения безопасности в криптоблоках, за исключением случаев, когда блок включает защиту ECC.

Взгляд Павла

Проверка безопасности - такая важная тема, и здесь ведется большая работа как в академических кругах, так и в промышленности. В этой статье хорошо сочетаются рандомизированное покрытие на основе мутаций с «гипер-свойствами» над наборами трассировок моделирования для создания инновационного решения, которое является масштабируемым и эффективным для демонстрации недостатков безопасности.

Некоторые свойства безопасности могут быть формально определены только для набора трассировок моделирования. Например, «невмешательство» означает, что злоумышленник не может вмешиваться в определенные защищенные вычисления в проекте. Чтобы продемонстрировать интерференцию, необходимо сравнить две трассы, идентичные по входному стимулу, за исключением наличия некоторых действий злоумышленника в одной трассе. Если какие-либо защищенные вычисления в атакованной трассе отличаются от таковых в золотой трассе, значит, произошла интерференция.

Авторы создают свой собственный особый язык для утверждений по множественным трассировкам и используют его для формулирования свойств безопасности для невмешательства и конфиденциальности. Они создают настраиваемый поток, чтобы случайным образом вмешиваться в моделирование и проверять свои свойства безопасности между моделированием с вмешательством и без вмешательства. Их алгоритм случайного взлома также имеет элегантную эвристику обучения на основе покрытия, которая помогает более эффективно находить недостатки безопасности.

Идея утверждений на основе нескольких симуляций очень сильна. Интересно, можно ли чисто расширить SystemVerilog для поддержки такого рода утверждений. Это может открыть дверь для некоторых привлекательных нативных расширений для коммерческого моделирования и формальных инструментов. Другой возможностью может быть расширение нового стандарта Portable Stimulus Standard (PSS) для включения утверждений, охватывающих несколько сгенерированных тестов.

Эту статью легко и приятно читать, хотя мне хотелось бы получить более подробную информацию о результатах. Авторы утверждают, что их решение обнаруживает дыры в безопасности в их тестовом примере SoC с открытым исходным кодом, но нет никаких подробностей о том, что это за дыры или как их подход сравнивается с другими подходами в литературе, которые можно было бы применить для поиска тех же дыр.

Взгляд Рауля

Сначала я собираюсь взглянуть на это с точки зрения технологической зрелости. Мне в целом нравится идея, очень интересный подход к оценке безопасности в дизайне. Тем не менее, каждый дизайн требует, чтобы дизайнеры предоставляли начальные тесты, средства взлома и спецификации безопасности на новом языке утверждений. Для меня это на данный момент жестко ограничивает подход к академической сфере. Отлично подходит для диссертаций и статей, но еще не близко к тому, что могло бы перейти к коммерческому применению.

Я готов принять участие во втором испытании как инвестор. Безопасность - важная тема, без вопросов. Но за пределами нескольких уже известных нам областей - например, аэрокосмической, оборонной, платежных систем и процессоров / серверов. Это по-прежнему не проблема для большинства OEM-производителей и производителей компонентов. Они готовы поставить галочку, если обычно ожидают. Но только если влияние на стоимость или время выхода на рынок невелико. Потому что их клиенты обычно не будут платить больше за безопасность. Таким образом, безопасность большинства рынков по-прежнему зависит от IP «под ключ», таких как аппаратные основы доверия и простые в использовании приложения. Решения, упакованные одним из этих способов, будут инвестированы, в противном случае - не так много.

Мой взгляд

Поль и Рауль осветили большую часть того, что я мог предложить. Мне нравится идея Пола о расширении SVA, по крайней мере, для поощрения экспериментов с гипер-свойствами. Это должно открыть новый класс интересных тестов, что в конечном итоге приведет к появлению новых связанных методов проверки.

Поделитесь этим постом через: Источник: https://semiwiki.com/eda/299391-fuzzing-to-validate-soc-security-innovation-in-verification/