Привет, Хабр!

Когда мы говорим о доверенной операционной системе, быстро выясняется: одного защищенного кода недостаточно. ОС нужна точка опоры еще до того, как начнет работать она сама, — компонент или механизм, с которого начинается доверие ко всей системе. Его называют Root-of-Trust, или корнем доверия.

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

Меня зовут Антон Рыбаков, я руковожу разработкой функций безопасности KasperskyOS в «Лаборатории Касперского». В этой статье разберем, какими бывают корни доверия, как мы работаем с разными реализациями в KasperskyOS и почему для индустрии все острее становится вопрос унификации: единых требований, общего языка описания и понятных правил оценки Root-of-Trust. 

Что такое Root-of-Trust?

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

Thales Group определяет корень доверия так:

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

По сути для защиты системы они могут генерировать криптографические ключи (RSA-4096, ECC-256 и другие) с закрытым доступом, хранить их в изолированной памяти. Это позволяет проводить разные операции (например, подписание TLS-сертификата) без изъятия самого ключа: значит, при взломе сервера он все равно будет в безопасности.

Важно, что Root-of-Trust можно реализовать по-разному. Это может быть отдельная микросхема, встроенный security-блок в SoC, доверенная среда исполнения, прошивочный модуль, виртуализированная реализация или комбинация нескольких механизмов. Формально все они могут выполнять роль корня доверия, но их свойства будут различаться: по уровню изоляции, модели угроз, набору функций, изменяемости секретов и способу интеграции с операционной системой.

При этом, набор различных Root-of-Trust может быть использован при проектировании одного устройства, см. схему ниже.

Разнообразие корней доверия

Корни доверия бывают очень разными. Именно это разнообразие превращает Root-of-Trust в отдельную инженерную задачу. Для доверенной ОС важно не просто обнаружить на платформе некий «корень доверия», а понять, какие гарантии он реально дает и какие сервисы безопасности можно на него опереть.

Единой классификации Root-of-Trust сегодня нет ни в России, ни в мировом ИБ-сообществе. Разные ассоциации и консорциумы, которые разрабатывают требования к RoT, предлагают собственные подходы к описанию таких компонентов. Поэтому на практике корень доверия приходится оценивать сразу по нескольким параметрам: способу реализации, изменяемости, уровню изоляции и назначению.

Один из базовых вариантов такой классификации может выглядеть так:

Поясню подробнее несколько критериев.

Например, гибридная изоляция означает, что один и тот же вычислительный модуль разделяется между разными режимами исполнения: обычным и режимом повышенной безопасности. По сути, это модель доверенной среды исполнения — Trusted Execution Environment, TEE. В такой архитектуре часть операций выполняется в изолированном контуре, но сам вычислительный модуль остается общим для основной и доверенной сред.

Возможны и более сложные варианты. Например, RoT может обеспечивать логическую изоляцию внутри SoC, но при этом сохранять физическую изоляцию для отдельных security-блоков — OTBN, OpenTitan Big Number Accelerator, OTP, One-Time Programmable Memory, — и других компонентов, отвечающих за критически важные операции и хранение неизменяемых данных.

Отдельно важно смотреть на назначение RoT. Корни доверия можно классифицировать по функциям, которые они обеспечивают:

• хранение секретов;

• измерение и оценка состояния платформы;

• обновление ПО;

• аутентификация;

• шифрование;

• доверенная загрузка;

• защита цепочки поставок.

Эта функциональная классификация особенно важна для ОС. Она показывает не только тип реализации, но и то, какие сервисы безопасности можно построить поверх конкретного корня доверия. Самый распространенный сценарий сегодня — доверенная загрузка: RoT используется как исходная точка для проверки целостности и подлинности загружаемого кода.

Еще один важный сценарий — удаленная аттестация. Она позволяет удаленной стороне получить подтверждение, что платформа находится в ожидаемом доверенном состоянии: загружены нужные компоненты, критичные параметры не изменены, а признаки компрометации или несанкционированной модификации отсутствуют. Этот сценарий используется для распределенных систем, промышленных решений, серверной инфраструктуры и устройств, к которым нельзя постоянно иметь физический доступ.

Какими бывают реализации Root-of-Trust

Теперь, когда у нас есть базовый язык описания, можно перейти к конкретным реализациям Root-of-Trust и посмотреть, чем они отличаются на практике. Ниже — не исчерпывающая классификация, а скорее инженерная карта: от простых низкоуровневых механизмов до комплексных схем, где несколько корней доверия работают одновременно.

Первый и самый понятный вариант — корень доверия как уникальный секрет, обычно криптографический, связанный с системой на кристалле и записанный в однократно программируемую память.

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

Менее распространенный способ — связка PUF + DICE. В такой схеме PUF, Physically Unclonable Function, позволяет сформировать или восстановить неклонируемый корневой ключ чипа, а DICE, Device Identifier Composition Engine, строит на его основе цепочку доверия, например для защиты загрузки и аттестации платформы.

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

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

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

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

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

Примеры таких микросхем: NXP iMX 8M, RK 3588, TI TDA4VH и другие.

Второй вариант — Root-of-Trust как отдельный вычислительный компонент внутри SoC, физически или логически изолированный от ядер общего назначения.

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

Преимущество такого подхода в том, что изолированная вычислительная среда не зависит напрямую от основных процессорных ядер. Это снижает риски, связанные с уязвимостями и атаками на основную вычислительную среду, включая классы атак, направленных на нарушение изоляции между уровнями привилегий основного процессора: Spectre (CWE-1037), Meltdown (CWE-1342), Foreshadow (CWE-1209) и подобных им классах атак.

У этого подхода есть как отечественные, так и зарубежные реализации. В России можно привести в пример решения компании «Элвис». Среди зарубежных игроков — Rambus, которая разрабатывает специализированные коммерческие IP-ядра и поставляет их вместе со встроенным программным обеспечением.

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

Примеры: «Доверенное ядро» компании «Элвис» в СнК MCom-03 «СКИФ», решения Rambus.

Третий вариант — корни доверия, реализованные на отдельных микросхемах или внешних аппаратных устройствах. К этому классу можно отнести Secure Element, TPM и HSM.

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

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

По смыслу этот подход похож на отдельное security-ядро внутри SoC: корень доверия изолирован от основного вычислителя. Но степень физической изоляции здесь выше, потому что Secure Element является самостоятельной микросхемой вне корпуса основного процессора. Это дополнительно снижает поверхность атаки и усложняет часть аппаратных атак, в том числе атаки по сторонним каналам.

Отдельно стоит упомянуть TPM — Trusted Platform Module. По моему мнению, TPM является разновидностью SE, которая имеет стандартизованный набор интерфейсов — от физических до прикладных и для некоторых применений де-факто является стандартом.

HSM — Hardware Security Module. Может рассматриваться как разновидность Secure Element, выполненный в виде отдельного устройства, физически расположенного вне состава программно-аппаратного комплекса использующего механизмы безопасности.

Примеры Secure Element: решения «Аладдин», «Актив», ИнфоТеКС ViPNet SIES Core Nano, Infineon OPTIGA Trust M, Microchip ATECC608A, ST STSAFE-A110.

Примеры HSM: ИнфоТеКС ViPNet SIES Core, Thales nShield HSM.

Четвертый вариант — открытые проекты, которые можно классифицировать как аппаратный корень доверия, security-блок или основу для построения Secure Element.

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

К этому направлению относятся проекты, построенные вокруг открытых аппаратных архитектур и открытых спецификаций Root-of-Trust. Они важны для индустрии как источник требований, практик и архитектурных паттернов.

Примеры: OpenTitan Earl Grey, OpenTitan Darjeeling, Caliptra.

Пятый вариант можно назвать кооперативным. В этом случае сценарии Root-of-Trust реализуются не в отдельной микросхеме, а в доверенной среде исполнения — Trusted Execution Environment, или TEE. Такая среда опирается на механизмы изоляции, которые предоставляет основной вычислительный модуль устройства.

К таким технологиям относятся ARM TrustZone (подробнее о нем можно почитать здесь), Intel SGX, Intel TDX, AMD SEV, AMD SEV-SNP и другие. Все они решают схожую задачу: позволяют выполнять критически важный код и обрабатывать чувствительные данные в изолированной среде, даже если основная операционная система или часть программного стека скомпрометированы.

Например, TrustZone разделяет систему на два состояния: Secure и Non-Secure, которые часто называют «безопасным» и «обычным» мирами. Secure-мир предназначен для выполнения доверенного кода и работы с защищенными ресурсами. Non-Secure-мир используется для основной операционной системы и прикладного ПО.

Между мирами существует барьер — режим работы процессора, который определяется специальным битом (NS-бит). Таким образом на одном и том же ядре процессора могут выполняться как незащищенный программный код (системный, прикладной, обработчики прерываний), так и защищенный — в зависимости от того, в каком режиме исполнения сейчас находится процессор.

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

Еще один способ организации доверенной среды исполнения — виртуализация. В этом случае изоляция обеспечивается на уровне гипервизора: он выделяет набор аппаратных ресурсов, которые используются для доверенных вычислений параллельно с основными задачами программно-аппаратного комплекса.

Подход с организацией TEE для выполнения доверенных вычислений широко используется вендорами мобильных устройств на ARM-совместимых процессорах. В модели безопасности Android использование TEE рекомендуется для митигации рисков, связанных с компрометацией ядра основной операционной системы.

При этом в современных мобильных системах все чаще используется не один изолирующий механизм, а комплексная модель. Например, в Android есть подход StrongBox: критически важные операции и секреты выносятся в отдельный аппаратный модуль безопасности, а основная TEE взаимодействует с ним как с более защищенным хранилищем и вычислительной средой.

Такой подход появился как ответ на рост числа атак на основную вычислительную среду, включая микроархитектурные атаки вроде Spectre и Meltdown, Rowhammer и похожие классы воздействий.

Шестой вариант — комплексный. Он характерен для серверных систем, систем хранения данных, облачной инфраструктуры и других сложных программно-аппаратных комплексов. В таких системах Root-of-Trust редко сводится к одному механизму: разные корни доверия могут использоваться одновременно и в разных сценариях.

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

По сути, комплексная схема представляет собой комбинацию ранее рассмотренных подходов. В одной системе могут одновременно использоваться однократно программируемые секреты, отдельное security-ядро внутри SoC, TPM, HSM, TEE, Secure Element или другие специализированные компоненты.

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

Почему RoT нельзя оценивать без требований

После обзора реализаций возникает следующий вопрос: как выбирать подходящий Root-of-Trust и сравнивать разные варианты между собой? Простого перечисления технологий здесь недостаточно. Важно понимать, для какой модели угроз проектируется система, как устроен жизненный цикл секретов, какие сценарии безопасности поддерживает RoT и как он интегрируется с операционной системой.

Поэтому требования к Root-of-Trust становятся отдельной большой задачей. Для российской ИБ-индустрии это одно из ключевых направлений: без понятных критериев сложно сравнивать реализации, оценивать уровень доверия и выбирать архитектуру под конкретную платформу.

Здесь полезно обратиться к международному опыту. Например, NIST развивает подходы к аппаратной безопасности в рамках Hardware Security Program, а Trusted Computing Group уже много лет формирует требования к TPM — одному из наиболее стандартизованных примеров аппаратного корня доверия.

При этом единого центра разработки таких требований нет. У Trusted Computing Group, NIST, CHIPS Alliance, OCP, lowRISC, GlobalPlatform разные фокусы: TPM и доверенные платформы, аппаратная безопасность, открытые архитектуры, прозрачность реализации, роли и сервисы Root-of-Trust без привязки к конкретной микросхеме.

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

В KasperskyOS мы уже используем часть этих наработок, в частности подход GlobalPlatform, и дополняем их собственным опытом работы с разными реализациями Root-of-Trust.

Так, в направлении Future Tech «Лаборатории Касперского» работает группа, которая формирует собственное видение таких требований и занимается созданием отечественного стандарта ДКБ — доверенного компонента безопасности, или, если говорить в уже привычных терминах, корня доверия.

Требования сами по себе не существуют в вакууме. В доверенной системе они должны быть связаны с архитектурой ОС, сервисами безопасности и методологией разработки. Поэтому дальше нужно сказать несколько слов о конструктивной безопасности — подходе, в рамках которого Root-of-Trust становится частью общей архитектуры доверия.

Как KasperskyOS работает с разными Root-of-Trust

Теперь можно перейти от общих требований и методологии к практической задаче: как операционной системе работать с разными реализациями Root-of-Trust и при этом не зависеть от конкретного чипа, модуля или аппаратной платформы.

KasperskyOS — микроядерная операционная система. Это не дистрибутив Linux, не версия Android и не надстройка над существующей ОС, а полностью собственная разработка.

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

Наша ОС должна работать на разных аппаратных платформах, а корень доверия на этих платформах может быть реализован по-разному. Одна операционная система должна уметь работать с разными вариантами Root-of-Trust, не привязывая сервисы безопасности к особенностям конкретного чипа, интерфейса или протокола обмена.

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

Для решения этой задачи нужен уровень абстракции — HAL-интерфейс над различными реализациями Root-of-Trust. В KasperskyOS таким уровнем становится KasperskyOS Root-of-Trust HAL, или KRoT HAL.

KRoT HAL используется сервисами KasperskyOS и позволяет стабилизировать представление Root-of-Trust со стороны операционной системы. Но единый интерфейс сам по себе не отвечает на вопрос, какие именно возможности Root-of-Trust должны быть доступны сервисам ОС. Для этого нужно связать требования, меры защиты и практические сценарии использования RoT.

Как RoT встраивается в сервисы безопасности KasperskyOS

При разработке KasperskyOS Root-of-Trust в качестве одного из референсов мы взяли стандарт GlobalPlatform Root of Trust Definitions and Requirements. Для нас он важен по двум причинам: достаточно подробно описывает требования к Root-of-Trust и при этом не фиксируется на одной конкретной аппаратной реализации.

Сам стандарт объемный и заслуживает отдельной статьи, поэтому здесь отмечу два важных для нас момента.

Первый связан с самой идеей HAL-уровня. Нам важно было понять, можно ли вообще корректно реализовать программный слой абстракции над Root-of-Trust. Иначе говоря, не возникает ли ситуации, в которой для правильной работы корня доверия доступ к нему должен оставаться прямым и не может быть «покрыт» программной абстракцией.

Стандарт не отвечает на этот вопрос напрямую, но в нем есть понятие Bootstrapped Root-of-Trust — процесса, при котором корень доверия создается или активируется непосредственно в момент включения питания. В такой модели цепочка доверия начинается с Initial Root-of-Trust, который определяется аппаратурой платформы. Дальше в ходе построения цепочки могут появляться дополнительные программные корни доверия: программный блок предварительно верифицируется, загружается, получает управление и становится частью доверенной цепочки.

В этой логике KasperskyOS соответствует подходу стандарта. Мы организуем сервис, который предоставляет HAL-интерфейс и, по сути, выступает как Extended Root-of-Trust над нижележащими уровнями. То есть аппаратный или аппаратно-программный корень доверия остается основанием цепочки, а KRoT HAL позволяет безопасно и единообразно предоставлять его возможности сервисам операционной системы.

Второй важный момент: GlobalPlatform рассматривает Root-of-Trust как компонент, который предоставляет верхним уровням один или несколько сервисов. Это могут быть криптографические операции, хранение секретов, авторизация, аттестация, идентификация или другие функции. То есть ОС может работать с конкретным набором возможностей, на которые можно опереть меры защиты.

В нашей разработке мы сопоставляем подход GlobalPlatform с требованиями российских регуляторов. KasperskyOS сертифицирована по требованиям ФСТЭК, и в операционной системе уже реализуется набор мер защиты. Поэтому задача KRoT HAL — связать эти реализации с практическими сценариями безопасности ОС.

Упрощенно эта логика выглядит так:

Требования регуляторов

       ↓

Меры защиты в операционной системе

       ↓

Сервисы безопасности KasperskyOS

       ↓

Сценарии использования Root-of-Trust

       ↓

Сервисы Root-of-Trust по GlobalPlatform

       ↓

Конкретная реализация RoT через KRoT HAL

Например, если ОС нужно обеспечить контроль целостности, на уровне сценария это может выражаться в доверенной загрузке или проверке состояния платформы. На уровне Root-of-Trust — в использовании доверенного хранилища, криптографических операций, измерений или аттестации. А на уровне конкретной платформы эти функции могут быть реализованы через TPM, Secure Element, security-блок в SoC или другой механизм.

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

Так, RoT встраивается в архитектуру KasperskyOS как основание для сервисов безопасности, которые реализуют конкретные меры защиты и должны работать предсказуемо на разных аппаратных платформах.

Как масштабировать работу с разными RoT

Теперь остается практический вопрос: как сделать так, чтобы одна и та же модель работала на разных аппаратных платформах и с разными реализациями Root-of-Trust.

Вариантов может быть много, но в KasperskyOS мы используем модель, разделенную на две части: фронтенд и бэкенд.

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

Бэкенд, наоборот, обращен к конкретной реализации Root-of-Trust. Именно он реализует протокол обмена с аппаратным или программно-аппаратным компонентом и учитывает особенности конкретной платформы.

В рамках SDK KasperskyOS фронтенд поставляется в бинарном виде — как объектные файлы со скомпилированными методами интерфейса. Сами по себе они не являются готовым рабочим компонентом, но сторонний вендор может связать их со своим кодом, который реализует работу с конкретным корнем доверия.

Бэкенд поставляется в исходных кодах и содержит набор callback-функций. Интерфейс при этом остается достаточно простым: нужно реализовать несколько функций и связать их с протоколом обмена с конкретным RoT. Например, если сервис запрашивает доступ к объекту внутри корня доверия, KRoT HAL транслирует этот запрос в callback-функцию, а дальше бэкенд выполняет необходимые действия через протокол конкретного аппаратного компонента.

На этапе сборки SDK получается программный модуль HAL, который можно установить в информационную систему. После этого KasperskyOS работает уже с конкретным Root-of-Trust, но сервисы ОС продолжают видеть не особенности конкретного чипа, а единый интерфейс.

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

Следующий важный вопрос — безопасность такой модели. Если KRoT HAL дает сервисам ОС доступ к возможностям Root-of-Trust, нужно гарантировать, что этот доступ не станет новым каналом атаки.

Как безопасно работать с RoT внутри ОС

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

Root-of-Trust может предоставлять доверенным сервисам критически важную информацию и операции: ключ полнодискового шифрования, ключ доверенного хранилища, идентификаторы устройства, криптографические функции, данные для аттестации. Поэтому доступ к этим возможностям должен контролироваться не только на уровне самого RoT, но и на уровне архитектуры ОС.

Рассмотрим пример с сервисом удаленной аттестации. Теоретически такой сервис может быть скомпрометирован. Если у него есть возможность обращаться к Root-of-Trust, злоумышленник может попытаться использовать этот сервис, чтобы получить не предназначенный ему объект — например, ключ доверенного хранилища.

Такие сценарии нужно предотвращать заранее. В KasperskyOS для этого используется изоляция, заложенная в архитектуру системы.

Критичные сервисы выделяются в отдельные домены безопасности, а взаимодействие между доменами идет по IPC-каналам и контролируется политиками безопасности. Это значит, что сам факт обращения сервиса к KRoT HAL еще не дает ему доступ ко всем объектам и операциям Root-of-Trust.

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

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

Так, KRoT HAL встраивается в модель безопасности KasperskyOS: он не просто унифицирует работу с разными реализациями Root-of-Trust, а предоставляет доступ к ним через контролируемую архитектуру, где права сервисов явно описаны и проверяются политиками безопасности.

Что дальше: зачем индустрии единые требования к Root-of-Trust

Разные реализации Root-of-Trust уже стали нормой, но, чтобы эффективно использовать RoT в разных сценариях, индустрии нужны понятные требования к их жизненному циклу, модели угроз и процессам разработки аппаратного обеспечения.

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

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

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

• разработка требований к аппаратным механизмам безопасности;

• механизмы защищенной работы с памятью;

• аппаратное ускорение отечественных криптографических алгоритмов на уровне ISA;

• противодействие бинарным уязвимостям на аппаратном уровне;
  защита от атак по побочным каналам;

• согласование требований к RoT с отечественными маршрутами разработки ЭКБ.

Для ИБ-сообщества важно сформировать подход к созданию и поддержке Root-of-Trust на основе уже существующих лучших практик, ГОСТов, международного опыта и внутренней экспертизы российских ИБ-компаний.

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

Что вы думаете о таких требованиях и о подходе к работе с Root-of-Trust в целом? Пишите в комментариях — кажется, это как раз та тема, которую важно обсуждать всем ИБ-сообществом.