Аппаратная безопасность платформ на базе RISC-V

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

Многие такие изделия хранят или обрабатывают активы, требующие защиты: криптографические ключи, учётные данные, встроенное программное обеспечение, пользовательские данные. Защищённость этих активов определяется в том числе свойствами аппаратной основы. Ошибки разграничения доступа, некорректная конфигурация отладочных интерфейсов, уязвимая цепочка загрузки или недостаточно проверенный сторонний IP-блок могут нарушать предпосылки, на которых основана работа программных средств защиты.

Аппаратная безопасность охватывает вопросы проектирования микроконтроллеров, систем на кристалле, IP-ядер, загрузочных цепочек и других компонентов вычислительных платформ. В рамках одной статьи подробно раскрыть все эти направления невозможно, поэтому ниже приведён вводный обзор основных классов угроз, подходов к верификации, аппаратных механизмов защиты и возможных направлений исследований на базе RISC-V.

Материал подготовлен по итогам вебинара "Актуальные темы НИР по аппаратной безопасности с использованием RISC-V", который был проведен технологическим и академическим комитетами Альянса RISC-V. В докладе руководитель рабочей группы "Программно-аппаратные механизмы безопасности" Технологического комитета Альянса RISC-V Владимир Карантаев рассмотрел развитие аппаратной безопасности (hardware security), классы аппаратных угроз, подходы к моделированию нарушителя, применение shift-left и возможные направления исследований для вузов и дизайн-центров. Доступна полная запись вебинара.

Значение аппаратной основы

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

Эффективность программных средств защиты зависит от корректности аппаратной основы. Ошибка в правах доступа к регистру, неверная настройка отладочного порта, дефект цепочки загрузки или некорректная интеграция стороннего IP-ядра могут снизить защищённость вышестоящих уровней.

В международной практике аппаратная безопасность представлена в программах NIST, каталоге MITRE CWE и методах верификации безопасности. NIST ведёт программу Hardware Security, ориентированную на выявление угроз для полупроводниковых компонентов и разработку мер защиты, в том числе с применением автоматизированных инструментов на протяжении жизненного цикла разработки. MITRE поддерживает классификацию недостатков аппаратного проектирования, которые могут приводить к уязвимостям.

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

Как развивалась аппаратная безопасность

Современное направление аппаратной безопасности формировалось на протяжении нескольких десятилетий. К заметным вехам относятся исследования атак по времени выполнения (timing attacks) в 1996 году, атак с введением сбоев (fault injection attacks) в 1997 году и атак по энергопотреблению (power analysis attacks) в 1999 году. Эти работы показали, что секретные данные могут быть раскрыты через наблюдаемые характеристики работы устройства, а намеренно вызванные сбои могут использоваться для изменения хода вычислений или обхода проверок безопасности.

В круг задач аппаратной безопасности также вошли уникальные аппаратные идентификаторы (unique hardware identifiers), физически неклонируемые функции (PUF), генераторы истинно случайных чисел (TRNG), методы отслеживания распространения чувствительных данных (tainting), противодействие подделке интегральных схем (IC counterfeiting) и аппаратным троянам (hardware trojans).

Источник: Hardware Security A Hands-on Learning Approach Agrawal, D., Baktir, S., Karakoyunlu, D., et al.: ‘Trojan detection using IC fingerprinting’. Proc. IEEE Symp. on Security and Privacy, Oakland, USA, May 2007, pp. 296–310

К середине 2000-х годов в отдельный класс угроз выделились аппаратные трояны и недекларированные изменения в интегральных схемах. Исследования стали охватывать полный жизненный цикл микросхемы: проектирование, интеграцию IP-блоков, производство, корпусирование и поставку. Программы DARPA IRIS и SHIELD отразили интерес к проверке доверенности и подлинности электронных компонентов, обнаружению аппаратных закладок и противодействию подделке микросхем.

Параллельно развивались доверенные среды исполнения (TEE, Trusted Execution Environment) и аппаратные корни доверия. Появились Arm® TrustZone, спецификации GlobalPlatform TEE, новые версии TPM, концепция DICE и отраслевые процессы безопасной разработки аппаратуры. Защитные механизмы встраивались в архитектуру процессоров, подсистемы загрузки, память и средства управления жизненным циклом устройства.

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

Следующий этап связан с открытыми аппаратными корнями доверия и воспроизводимыми процессами разработки. Проекты OpenTitan и Caliptra предоставляют открытые аппаратные и программные компоненты, документацию и материалы для проверки свойств безопасности. О начале изготовления микросхем OpenTitan, подготовленных для серийного применения, Google сообщил 6 февраля 2025 года. По данным OpenTitan, микросхемы на его основе поставляются в составе Chromebook. Это пример применения открытого аппаратного проекта в серийных устройствах.

За это время аппаратная безопасность прошла путь от защиты отдельных криптографических операций до системного анализа всей платформы. В область проверки входят процессорные ядра, память, прямой доступ к памяти (DMA), загрузочная цепочка, отладочные интерфейсы, сторонние IP-блоки, производство, обновление прошивки и физическая среда эксплуатации. Для RISC-V этот опыт задаёт основу для разработки методик, инструментов верификации и аппаратных механизмов защиты.

Преимущества открытой архитектуры RISC-V

Открытая архитектура набора команд RISC-V, наличие открытых ядер Ibex, Rocket, CVA6 и BOOM, а также проектов OpenTitan и Caliptra позволяют исследовать механизмы защиты на воспроизводимых примерах. Свойства безопасности (security properties) можно проверять на конкретных описаниях аппаратуры на уровне регистровых передач (RTL). Доступность RTL и состав механизмов защиты определяются выбранной реализацией.

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

Для исследований RISC-V удобен тем, что многие механизмы безопасности можно проверять на нескольких уровнях: в спецификации, RTL, компиляторе, прошивке, ОС и на тестовом стенде. Это позволяет связать модель угроз с конкретным свойством реализации, а затем проверить его с помощью тестов, формальной верификации, фаззинга или прототипирования на ПЛИС. Для вузов и дизайн-центров такой подход позволяет получать результаты, подтверждённые на конкретных реализациях и стендах.

Объекты аппаратной безопасности

К объектам аппаратной безопасности относятся микроконтроллеры общего и промышленного назначения, процессоры прикладного класса и системы на кристалле. В последних несколько процессорных ядер, DMA-контроллеров, аппаратных ускорителей и других блоков могут независимо обращаться к общей памяти и периферии.

Проверке также подлежат поставляемые IP-ядра и IP-блоки, ПЛИС-прототипы, криптографические ускорители, аппаратные корни доверия, подсистемы памяти, загрузки, отладки, трассировки и обновления.

Слабым звеном может оказаться вспомогательный компонент: отладочная цепочка или сторонний блок, интегрированный без достаточной проверки. Поэтому аппаратная безопасность не ограничивается специализированными защищёнными микросхемами.

Жизненный цикл и источники уязвимостей

Уязвимость может быть заложена или проявиться на разных этапах жизненного цикла изделия: при формировании архитектуры, RTL-разработке, интеграции IP-блоков, синтезе, верификации, производстве, корпусировании, поставке, эксплуатации и обновлении.

Источник: Ten years of hardware Trojans: a survey from the attacker's perspective

Типовые классы угроз включают аппаратные трояны и недекларированные возможности; ошибки разграничения доступа к регистрам, конфигурационным элементам fuse, однократно программируемой памяти (OTP) и другим областям памяти; некорректную интеграцию дочерних IP-блоков; поставку контрафактных, повторно использованных или не соответствующих требованиям компонентов.

Отдельную группу составляют утечки через побочные каналы: время выполнения, энергопотребление, электромагнитное излучение, состояние кэш-памяти и буферов трансляции адресов (TLB). Другие угрозы связаны с введением сбоев через кратковременные нарушения тактирования и питания (clock glitching, power glitching), электромагнитное воздействие (EMFI) или лазерное воздействие. Проверке также подлежат отладочные и трассировочные интерфейсы, механизмы загрузки, обновления и защиты от отката, а также микроархитектурные эффекты, влияющие на изоляцию данных и контекстов.

В вебинаре Альянса RISC-V аппаратные угрозы рассматривались как по типу атаки, так и по этапу жизненного цикла, на котором они могут появиться. Для микросхем это особенно существенно: производство, корпусирование и поставка могут находиться вне полного контроля разработчика.

Источник:  Марк Тегеранипур (Mark Tehranipoor) Hardware Security A Hands-on Learning Approach

Модель угроз и нарушителя

Построение защиты начинается с определения модели угроз и модели нарушителя. Одним из направлений исследований для аппаратных средств на базе RISC-V может стать разработка типовой методики моделирования угроз, применимой к устройствам и подсистемам разных классов. К ним относятся микроконтроллеры, в том числе без блока управления виртуальной памятью (MMU), системы на кристалле с поддержкой Linux, доверенные среды исполнения, аппаратные корни доверия, криптографические IP-блоки и отладочные подсистемы. Наличие PMP и защищённой загрузки учитывается отдельно для каждой реализации.

Методика должна определять защищаемый объект, его активы и цели защиты. К активам относятся код, ключи, пользовательские данные, конфигурация безопасности и данные о допустимых версиях прошивки. Цели защиты включают сохранение целостности кода, конфиденциальности ключей, изоляции памяти, корректности загрузки, защиту от отката и устойчивость к введению сбоев.

Также определяются этап жизненного цикла, на котором возможна атака; категория нарушителя; его возможности и ресурсы. В зависимости от сценария нарушителем может быть внешний атакующий, пользователь устройства, сотрудник сервисной организации, поставщика IP-блока, производственной площадки или внутренней команды разработки. Его возможности могут включать физический доступ, использование лабораторного оборудования, доступ к RTL и тестовым режимам, влияние на цепочку поставок. В модели фиксируются границы доверия, допущения и исключённые сценарии.

Для открытых реализаций RISC-V модель угроз связывается с требованиями, проверяемыми свойствами безопасности, тестами и отчётами верификации. Это позволяет сформулировать исследовательскую задачу: проанализировать существующие подходы и разработать отечественную методику моделирования угроз и нарушителя для аппаратных средств на базе RISC-V разных классов.

Реестр классов аппаратных уязвимостей

Для систематизации недостатков аппаратного проектирования применяется каталог MITRE CWE. Его представление CWE-1194 Hardware Design объединяет категории, связанные, в частности, с разграничением доступа, интеграцией блоков и отладочными интерфейсами. CWE описывает типовые недостатки, способные привести к уязвимостям; сведения о конкретных публично зарегистрированных уязвимостях могут быть связаны с идентификаторами CVE. MITRE также публикует отдельный перечень наиболее значимых аппаратных недостатков, обновлённый в 2025 году.

Одним из возможных направлений исследований является формирование отечественного реестра классов аппаратных уязвимостей, адаптированного к российской элементной базе, доступным САПР, практикам проектирования и требованиям регулируемых отраслей. Для каждого класса в таком реестре можно указать применимость к реализациям RISC-V, типовые RTL-шаблоны, сценарии эксплуатации, этап возникновения, методы обнаружения и меры предотвращения, а при наличии соответствующих данных - связи с публично известными уязвимостями.

Для каждого класса следует определить применимые проверки: lint, анализ переходов между доменами тактирования и сброса (CDC/RDC), специализированный статический анализ RTL, формальные свойства, функциональные тесты, совместное моделирование, фаззинг и анализ информационных потоков. Выбор методов зависит от характера недостатка и уровня представления проекта. Такой реестр поможет разработчику IP-блока, верификатору системы на кристалле и специалисту по информационной безопасности использовать согласованную классификацию рисков и проверок. Отдельным результатом может стать отечественный список приоритетных Hardware CWE для микроконтроллеров, систем на кристалле и IP-блоков на базе RISC-V.

Атаки по побочным каналам и атаки с введением сбоев

Атаки по побочным каналам используют зависимость времени выполнения, энергопотребления, электромагнитного излучения и состояния микроархитектурных ресурсов от обрабатываемых данных. При определённых условиях это позволяет восстанавливать секретные данные, в том числе криптографические ключи. Для части таких атак достаточно программного доступа к общей вычислительной платформе; другие требуют физических измерений.

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

Устойчивость к этим воздействиям следует учитывать на этапе проектирования. Для её оценки требуются отдельные контрмеры, методы анализа и экспериментальные проверки. ПЛИС-прототипы пригодны для исследования логики защиты и ряда сценариев введения сбоев. Оценка физических утечек и устойчивости готовой микросхемы требует испытаний самой микросхемы: результаты, полученные на ПЛИС, нельзя автоматически переносить на ASIC.

Shift-left: перенос проверок на ранние стадии

Подход shift-left предполагает перенос проверок безопасности на ранние стадии разработки. Стоимость устранения дефекта обычно возрастает по мере продвижения проекта. Ошибка, выявленная при проектировании, может быть устранена корректировкой архитектуры или RTL. После изготовления кристалла исправление может потребовать новой ревизии, повторной верификации, изменения фотошаблонов и переноса сроков выпуска.

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

На стадии RTL выполняются статический анализ, анализ информационных потоков, формальная верификация и функциональные проверки. При интеграции системы на кристалле проверяются сквозные политики доступа между ядрами, DMA-устройствами, памятью, периферией и отладочной подсистемой. На ПЛИС-прототипе проводятся совместная верификация аппаратуры и программного обеспечения, фаззинг и эксперименты с введением сбоев в пределах возможностей стенда. На готовом кристалле выполняется практическая оценка защищённости.

Методы верификации

Проверка аппаратной безопасности требует взаимодополняющих методов, встроенных в маршрут разработки.

Статический анализ RTL при наличии соответствующих правил и сведений о политике доступа помогает выявлять типовые дефекты: открытые тестовые режимы, небезопасные состояния сброса, незащищённые регистры, несогласованные проверки привилегий, отсутствие необходимых битов блокировки (lock bits), некорректные права по умолчанию, неполные ветви и потенциальные сценарии обхода защиты.

Формальная верификация применяется для проверки формализованных свойств, в том числе инвариантов. Примеры: невозможность записи в защищённый регистр из пользовательского режима; недоступность области ключей для DMA; невозможность отладочного доступа в заданном состоянии жизненного цикла; недопустимость загрузки прошивки с версией безопасности ниже разрешённой. Результат доказательства действует в рамках выбранной модели, допущений и ограничений.

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

Аппаратный фаззинг помогает выявлять непредусмотренные состояния при взаимодействии RTL, прошивки и периферии. Анализ информационных потоков применяется для проверки отсутствия запрещённых передач секретных данных через регистры, шины, очереди, трассировку и отладочные интерфейсы. Выводы ограничены исследованными путями передачи и принятой моделью.

Отдельная прикладная задача - сформировать процесс верификации безопасности (security verification flow) для систем на кристалле на базе RISC-V. В нём функциональная верификация связывается с проверками безопасности через прослеживаемость требований, угроз, применимых CWE, свойств, тестов и отчётов. В такой процесс могут входить UVM-тесты для проверок привилегий, верификация на основе утверждений (assertion-based verification), формальные доказательства критичных инвариантов, негативное тестирование (negative testing), оценка покрытия требований и сценариев безопасности (security coverage), аппаратный фаззинг, анализ информационных потоков и совместное моделирование RTL с прошивкой.

Механизмы защиты в архитектуре RISC-V

В спецификациях RISC-V и реализованных на их основе платформах предусмотрены различные механизмы защиты. Их наличие, версии и ограничения необходимо уточнять для конкретного ядра и системы на кристалле.

Поддержку контроля целостности потока управления (CFI) предоставляют расширения Zicfiss и Zicfilp. Zicfiss вводит теневой стек для защиты адресов возврата и противодействия атакам класса ROP; Zicfilp задаёт допустимые точки назначения для контролируемых косвенных переходов. Применение этих механизмов требует соответствующей поддержки со стороны программного обеспечения.

Для разграничения доступа со стороны процессорных ядер применяются механизм защиты физической памяти PMP и расширение Smepmp. Для запросов от DMA-устройств и других инициаторов могут применяться IOPMP и IOMMU; их функции и место в системе различаются. Изоляция программных доменов и разделение ресурсов кэш-памяти зависят от архитектуры конкретной платформы и не следуют автоматически из наличия PMP или IOMMU.

Криптографические операции поддерживаются скалярными криптографическими расширениями RISC-V (Scalar Crypto). В платформах также могут использоваться аппаратные источники энтропии для генерации криптографических ключей. Их наличие и свойства требуют отдельной проверки.

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

Доверенная загрузка и удалённая аттестация

Защищённая загрузка (secure boot) строится как цепочка проверок подлинности компонентов перед передачей им управления. Цепочка может начинаться с неизменяемого загрузочного кода в Boot ROM, затем охватывать прошивку первого этапа, монитор безопасности и операционную систему. Состав этапов и участие доверенной среды исполнения зависят от архитектуры платформы. Проверка приложений определяется отдельной политикой.

При измеряемой загрузке (measured boot) вычисляются и сохраняются измерения загружаемых компонентов, которые могут использоваться при последующей аттестации. Защита от отката предотвращает запуск недопустимо старых версий. Проверка подлинности, измерение кода и защита от отката решают разные задачи; их состав и распределение по этапам следует задавать для конкретной платформы.

Удалённая аттестация позволяет проверяющей стороне оценивать состояние платформы на основе предоставленных свидетельств, измерений и формализованных утверждений о её свойствах (claims). Архитектура таких процедур описана в RFC 9334. Решение о доверии принимается с учётом политики проверки и доверенности источников свидетельств.

Открытые реализации RISC-V позволяют исследовать защищённую и измеряемую загрузку, взаимодействие с доверенной средой исполнения или конфиденциальной виртуальной машиной, процедуры аттестации и устойчивость загрузочной цепочки к введению сбоев.

Отладочные интерфейсы

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

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

Требования к САПР и инструментам

Включение аппаратной безопасности в процесс разработки требует поддержки со стороны средств автоматизированного проектирования и верификации. К целевым возможностям набора инструментов относятся импорт модели угроз и требований безопасности; разметка критичных активов и связанных с ними ресурсов, включая ключи, конфигурационные элементы fuse, отладочные интерфейсы, загрузочный код и защищённые области памяти; прослеживаемость требований до RTL, формальных свойств, тестов и отчётов; проверки по классам аппаратных недостатков.

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

Одним из направлений исследований является оценка того, какие методы проверки аппаратной безопасности могут быть встроены в существующие маршруты автоматизированного проектирования (EDA), какие требуют специализированного инструментария и какие требования следует предъявлять к поставляемым IP-блокам.

Применение больших языковых моделей

Большие языковые модели (LLM) могут использоваться для предварительной обработки инженерных материалов: спецификаций IP-блоков, технических описаний (datasheets), карт регистров, RTL-кода, тестов, описаний CWE, требований безопасности, отчётов статического анализа и сообщений об ошибках (bug reports). Возможные сценарии включают сопоставление карты регистров с классами недостатков, поиск признаков отсутствующих битов блокировки и проверок привилегий, подготовку черновиков утверждений и негативных тестов, извлечение требований из спецификаций, классификацию дефектов и поиск пробелов в модели угроз.

Результаты работы LLM подлежат проверке верификатором, архитектором или специалистом по информационной безопасности. Сгенерированные свойства и тесты должны проходить соответствующие инструментальные проверки до использования при окончательном утверждении проекта (sign-off).

Практический маршрут исследований для вузов и дизайн-центров

Для исследовательских групп вузов и дизайн-центров можно предложить следующую последовательность:

1. Выбрать открытую реализацию RISC-V, например Ibex, CVA6, Rocket или BOOM, и зафиксировать её версию и конфигурацию.

2. Определить класс устройства и сценарии применения.

3. Построить модель угроз и модель нарушителя.

4. Составить перечень применимых аппаратных CWE.

5. Выбрать один механизм защиты, который реализован или будет добавлен в исследуемую систему: PMP, IOPMP, CFI, защищённую загрузку, блокировку отладки, память только для исполнения (XOM) или криптографический ускоритель.

6. Описать проверяемые свойства безопасности.

7. Реализовать необходимые проверки: формальные, функциональные, статические, фаззинг или совместное моделирование.

8. При необходимости подготовить ПЛИС-прототип.

9. Зафиксировать покрытие, ограничения проверки, выявленные дефекты и накладные расходы механизма защиты.

10. Оформить результаты: описание стенда, модель угроз, шаблоны свойств, тестовый набор, отчёт и рекомендации по воспроизведению.

Такой маршрут может использоваться в магистерских и аспирантских работах, а также в прикладных исследованиях дизайн-центров. Проведённый Альянсом вебинар был ориентирован в том числе на университетские исследовательские группы, магистрантов и аспирантов.

Заключение

Аппаратная безопасность платформ на базе RISC-V охватывает моделирование угроз, проектирование архитектуры и RTL, формальную и функциональную верификацию, выбор и интеграцию IP-блоков, защиту отладки и загрузки, аппаратную реализацию криптографии, подсистемы памяти, прошивку и оценку готового кристалла.

К возможным направлениям исследований относятся формирование методики моделирования угроз, адаптация аппаратных CWE к отечественной практике, развитие подхода shift-left для RTL и систем на кристалле, формирование требований к инструментам и проверка результатов на открытых и отечественных реализациях RISC-V.

Открытые реализации RISC-V предоставляют основу для построения и проверки доверенных программно-аппаратных платформ. Выводы об их защищённости должны опираться на модель угроз, проверяемые свойства, метрики покрытия, воспроизводимые тесты, формальные доказательства и практическую оценку в пределах явно указанных допущений и ограничений.