Аппаратная информационная безопасность рассматривает угрозы, возникающие не только в программном коде, но и в самой логической/физической реализации устройства. В материалах кафедры выделяются два направления: проектирование схем, затрудняющих раскрытие их функциональности и несанкционированное копирование, и методы обнаружения нежелательных аппаратных «закладок» в спроектированных
Поэтому безопасность может входить в задачу синтеза как дополнительное ограничение наряду с площадью, задержкой и энергопотреблением: требуется получить функционально корректную схему, которая одновременно удовлетворяет заданным требованиям защиты.
Что важно запомнить
- Аппаратная реализация сама является объектом защиты: риски могут возникать на уровне логической сети, физического проектирования и изготовления.
- Одно направление защиты — затруднить восстановление функции и несанкционированное копирование
- Другое направление — обнаруживать нежелательные аппаратные модификации («закладки», hardware
- Защитное преобразование должно сохранять требуемое штатное функционирование устройства.
Почему безопасность относится к синтезу
После перехода от алгоритма к логической сети и далее к топологии появляется отдельный объект атаки — аппаратная реализация. Злоумышленнику может быть интересна структура netlist, возможность копирования проекта или скрытое изменение схемы на одном из этапов проектирования и производства.
Сокрытие функциональности
В кафедральных материалах по применению теории управляющих систем к СБИС рассматривается проектирование схем, защищённых от раскрытия функциональности и несанкционированного Общая идея состоит в том, что наблюдаемая структура без дополнительной секретной информации не должна непосредственно раскрывать правильный режим работы. В качестве исследовательских примеров используются структурная обфускация, ключевое управление режимом и техники, затрудняющие восстановление полной сетевой
Аппаратные закладки
Вторая задача — обнаружение нежелательных изменений, внесённых в схему намеренно. Такая «закладка» может не проявляться при обычных тестах и активироваться только при специальных условиях. Поэтому одних функциональных тестов типового режима может быть недостаточно: используются дополнительные проверки структуры, эквивалентности и
Безопасность как критерий проектирования
Обычный синтез стремится удовлетворить функциональным требованиям и оптимизировать площадь, быстродействие, энергопотребление. В защищённом проектировании к этим требованиям добавляется доверие к структуре и процессу изготовления. Защитное преобразование нельзя оценивать отдельно от корректности: в штатном режиме защищённая схема должна реализовывать ту же спецификацию.
Пример простыми словами
Если в сеть добавлена ключевая логика, без правильного ключа устройство может переходить в неверный функциональный режим, а с правильным — реализовывать исходную спецификацию. Смысл такой конструкции не в изменении целевой функции для владельца, а в усложнении её восстановления и копирования сторонним
Частые ошибки
- Сводить аппаратную безопасность к шифрованию данных. Здесь объект защиты — также структура и функционирование самой схемы.
- Считать любую дополнительную логику защитой. Она должна иметь определённую модель угроз и не нарушать штатную функцию.
- Отождествлять обнаружение аппаратной закладки с обычным поиском случайной неисправности: модель противника и скрытое поведение могут быть другими.
