Обеспечение безопасности микросхемы больше не сводится к финальной проверке или сертификату, прилагаемому к продукту перед его выпуском, а стало процессом, охватывающим проектирование, развертывание и мониторинг. Таков главный вывод закрытого обсуждения, организованного Semiconductor Engineering во время конференции Design Automation Conference. В нем приняли участие эксперты Arteris, Cadence, Keysight EDA, Rambus, Siemens EDA, Synaptics и Synopsys. Этот материал основан на фрагментах того обсуждения, которое модерировала Ann Mutschler.
Поверхность атаки расширяется с распространением искусственного интеллекта, chiplet, программно-определяемых систем, FPGA и подключенных систем. Поэтому опасность не ограничивается физическим дефектом схемы или атакой непосредственно на микросхему: она может исходить из сети, встроенного ПО или программируемого уровня, а затем использовать уязвимость для получения доступа к системе или ее вывода из строя.
От сертификации к фактическому использованию
Yathiendra Vunnam из Cadence отметил, что многие клиенты внедряют многоуровневую защиту, используя такие механизмы, как IPsec и MACsec, на разных уровнях модели OSI для удовлетворения требований к производительности и вычислениям. Однако он также пояснил, что некоторые компании сосредотачиваются на сертификации, поскольку она помогает им продавать продукт, а затем сокращают набор необходимых средств защиты, чтобы получить меньшую, более дешевую и пригодную для повторного использования конструкцию.
Проблема, по словам Scott Best из Rambus, заключается в том, что наличие технологии защиты не доказывает корректность ее применения. Клиент может потребовать защиту от атак по побочным каналам, атак с инъекцией сбоев или технологию PUF, а затем рассматривать эти элементы как заполненные пункты в списке требований, не уточняя, как именно они будут интегрированы и использоваться в конечной системе. То же относится к соблюдению таких рамок, как CRA и ISO 26262, или получению CSIP Level 3 от Keysight либо конкурирующей организации.
Это не означает, что сертификаты или стандарты не имеют ценности, но означает, что сами по себе они не дают достаточных доказательств безопасности продукта в реальных условиях эксплуатации. Участники сосредоточились на разрыве между наличием механизма безопасности на бумаге и его способностью работать после интеграции с остальными аппаратными средствами, программным обеспечением и сетями.
Обзор начинается со списка компонентов
Alexander Petr из Keysight EDA сказал, что современные системы строятся на последовательно накладывающихся уровнях: микросхема, затем корпус, плата и система, а затем подключенная экосистема, включающая центры обработки данных и глобальные сети. По мере переноса все большего числа функций во встроенное ПО знание о том, что именно входит в состав продукта, становится условием отслеживания рисков.
Это включает создание списка программного обеспечения для аппаратных компонентов, или, как выразился Petr, важность Software Bill of Materials for hardware, наряду с отслеживанием уязвимостей и мониторингом после развертывания. Ситуация усложняется открытым исходным кодом: он отметил попытки злоумышленников проникнуть в сообщества разработчиков открытого ПО и внедрить бэкдоры. Кроме того, обнаружения уязвимости zero-day недостаточно: сначала компания должна определить, использует ли ее система затронутый компонент, а затем понять, способна ли она исправить проблему или создать подходящую защиту.
Архитектура chiplet создает еще одну проблему. Возможность собирать модули из разных источников может снизить стоимость, поскольку для каждого блока не обязательно использовать самые передовые техпроцессы, но она ставит практический вопрос: как проектировщик проверит безопасность каждого chiplet и как гарантирует, что менее защищенный модуль не поставит под угрозу всю систему?
Регулирование повышает осведомленность, но не гарантирует поведения
Участники согласились, что нормативные акты, включая европейский Закон о киберустойчивости CRA, повысили уровень осведомленности и побудили некоторые компании инвестировать в корни доверия и встроенную защиту. Chris Giles из Siemens EDA сказал, что одного закона недостаточно, поскольку для превращения требований в постоянные инвестиции необходимо правоприменение. Участники отметили, что связанная с полупроводниками дата — 11 сентября 2026 года; при этом сохраняются вопросы о том, какие сведения потребуется раскрывать и как это будет применяться на практике.
Mohit Arora из Synaptics также отметил, что штрафы могут достигать 4% годовой выручки, а Reed Hinkel из Synopsys считает, что такое давление уже начало побуждать ранее колебавшиеся компании размещать на микросхеме полноценный корень доверия или внедрять подходы Open Compute Project, такие как Caliptra. Однако обсуждение показало, что влияние регулирования на поведение пока не определено: Giles сказал, что CRA широко присутствует в разговорах, но он не уверен, что закон изменил практики, а Petr отметил, что на момент обсуждения штрафы не налагались.
Что меняется на практике?
Требуемый переход заключается не только в покупке дополнительных инструментов или объектов интеллектуальной собственности в сфере безопасности, но и в распределении ответственности между командами проектирования, разработки ПО, управления продуктом и эксплуатации. Чем выше ценность услуги, которую предоставляет продукт, тем выше стоимость сбоя безопасности и связанной с ним ответственности. Поэтому Hinkel считает, что обещания высокоценные услуги должны сопровождаться фактической способностью выполнять соглашения об уровне обслуживания и реагировать на уязвимости.
В обсуждении также проявились коммерческие и военные стимулы. Продукты, пользующиеся доверием пользователей, могут оправдывать более крупные инвестиции в безопасность, а потребности Министерства обороны США и его поставщиков, среди которых в ходе обсуждения упоминались Boeing и Airbus, обеспечивают часть инвестиций в эту область. Однако это не отменяет ограничений: безопасность всегда конкурирует со стоимостью и сроками выпуска, а сертификацию по-прежнему легче измерить, чем качество развертывания и мониторинга.
Что касается постквантовой криптографии, Hinkel пояснил, что проблема не ограничивается аппаратными средствами или firmware, а распространяется на ускорители открытых ключей PKA, которые исторически создавались на основе накопленных уровней, сложных для обновления и расширения. Согласно обсуждению, продуктам потребуется поддержка новых алгоритмов в течение трех лет, тогда как отказ от старых алгоритмов рассчитан на пятилетний горизонт. Это указывает на то, что подготовка к постквантовой криптографии требует перестройки архитектуры, а не простого добавления алгоритма в существующую конструкцию.
Главный вывод для технического читателя заключается в том, что доказуемая безопасность должна охватывать то, что находится внутри продукта, способ его интеграции и то, как продукт будет контролироваться после продажи. Сертификация остается контрольной точкой в этом процессе, но не заменяет его. Детали правоприменения регулирования, пределы раскрытия уязвимостей и способность компаний исправлять продукты, уже широко представленные на рынке, остаются открытыми вопросами, которые источник не разрешил.