Насколько безопасна ОС ARM TrustZone?

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

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

Сравните это с выполнением кода в обычном мире. Например, ядро ​​Linux намного сложнее, и его гораздо труднее проверить. Существует множество примеров уязвимостей ядра и эксплойтов, которые позволяют вредоносному коду завладеть ядром.

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

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

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

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

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

Теперь представьте себе ту же ситуацию, когда вредоносное ПО захватило ядро ​​Linux. Теперь вредоносная программа не может прочитать ключ подписи, потому что находится в безопасном мире. Вредоносное ПО не может подписывать транзакции без согласия пользователя, поскольку ОС безопасного мира откажется подписывать транзакцию, пока пользователь не нажмет кнопку.

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

В частности, я не работал с TrustZone, но я полагаю, что после загрузки ОС безопасного мира невозможно напрямую изменить ее. Я не думаю, что разработчики приложений должны иметь возможность «добавлять» службы в ОС безопасного мира, поскольку это противоречит ее цели. Я не видел ни одного поставщика, позволяющего третьим сторонам добавлять код в свою ОС безопасного мира.

Чтобы ответить на ваш последний вопрос, я уже ответил на него в здесь. Исключения SMC — это то, как вы запрашиваете услугу из ОС безопасного мира — это в основном системные вызовы, но для ОС безопасного мира. Что получит вредоносный код, передав управление защищенному миру?

• Вы не можете изменить/прочитать безопасный мир из обычного мира
• Когда вы передаете управление безопасному миру, вы теряете контроль в обычном мире.

Что делает безопасный мир действительно «безопасным». Я имею в виду, почему нормальный мир может быть подделан, но не безопасный мир?

Разработчик системы безопасности делает ее надежной. TrustZone — это инструмент. Он предоставляет способ разбиения ФИЗИЧЕСКОЙ памяти. Это может предотвратить атаку DMA. TrustZone обычно поддерживает функции блокировки при загрузке. Поэтому, как только физическое сопоставление завершено (разрешения для безопасного/нормального мира), их нельзя изменить. TrustZone предоставляет инструменты для разделения прерываний, а также для безопасной загрузки.

Важно отметить, что безопасный мир — это технический термин. Это просто состояние, отличное от обычного мира. Название безопасный мир не делает его безопасным! Разработчик системы должен. Это сильно зависит от того, какие безопасные активы. TrustZone предоставляет только инструменты для разделения вещей, которые могут помешать нормальному доступу к миру.

Концептуально существует два типа кода безопасного мира TrustZone.

1. Библиотека - здесь обычно не используются прерывания, используемые в безопасном мире. Безопасный API — это волшебная восьмерка. Вы можете задать ему вопрос, и он даст вам ответ. Например, возможно, что некоторые системы управления цифровыми правами могут использовать этот подход. Секретные ключи будут скрыты и недоступны в обычном мире.
2. Безопасная ОС - здесь в безопасном мире будут прерывания. Это более сложно, поскольку прерывания подразумевают своего рода упреждение. Защищенная ОС может использовать или не использовать MMU. Обычно MMU необходим, если будет использоваться системный кеш.

Это две большие разницы между окончательными решениями TrustZone. Это зависит от конструкции системы и конечного приложения. TrustZone — это ТОЛЬКО часть инструментов, позволяющих добиться этого.

Кто может изменить безопасную ОС? Я имею в виду, как добавить "сервис"? Может ли, например, разработчик приложения для мобильного платежного приложения добавить сервис в ОС Secure для работы со своим приложением? если да, то как любой разработчик может добавить в безопасную ОС и она по-прежнему безопасна?

Это не определяется TrustZone. Поставщик SOC (люди, которые лицензируют ARM и создают ЦП) должен предоставить технологию безопасной загрузки. Например, защищенная ОС может находиться в ПЗУ и не может быть изменена. Другие методы заключаются в том, что безопасный код имеет цифровую подпись. В этом случае, вероятно, имеется защищенное ПЗУ на кристалле, которое проверяет цифровую подпись. Поставщик SOC предоставит (обычно NDA) информацию и методы для безопасной загрузки. Обычно это зависит от их целевого рынка. Например, в SOC также могут быть включены защита от физического вмешательства и аппаратное обеспечение для шифрования/дешифрования.

Встроенное ПЗУ (запрограммированное только поставщиком SOC) обычно имеет механизмы для загрузки из разных источников, таких как флэш-память NAND, последовательная флэш-память NOR, eMMC, ПЗУ, Ethernet и т. д.). Как правило, у него будет некоторая однократная плавкая память (СППЗУ), которую поставщик устройства/решения (люди, обеспечивающие безопасность приложения) может запрограммировать для настройки системы.

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