Как безопасная защищенная ОС ARM TrustZone?

Question

Я пытаюсь прочитать белую бумагу TrustZone, но очень сложно понять некоторые основные вещи. У меня есть некоторые вопросы. Это могут быть простые вопросы, но я новичок в этой области:

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

2. Кто может изменить безопасный os? Я имею в виду добавить «сервис»? может, например, разработчик приложения для мобильного приложения оплаты добавить службу в Защищенной ОС для работы с его приложением? если Да, то как любой разработчик может добавить в защищенную ОС, и он по-прежнему безопасен?

3. Что не позволяет вредоносному приложению сформировать нормальную ОС для повышения исключения SMC и передачи на защищенную ОС? , ^answered

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

Кто может изменить безопасность os? Я имею в виду добавить «сервис»? может, например, разработчик приложения для мобильного приложения оплаты добавить службу в Защищенной ОС для работы с его приложением? если Да, то как любой разработчик может добавить в защищенную ОС, и он по-прежнему безопасен?

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

На чип-ROM (только запрограммированный поставщиком SOC) обычно есть механизмы для загрузки из разных источников, таких как вспышка NAND, последовательная вспышка NOR, eMMC, ROM, Ethernet и т. Д.). Как правило, у него будет некоторая временная плавная память (EPROM), которую поставщик/поставщик решений (люди, которые делают вещи безопасными для приложения) могут запрограммировать для настройки системы.

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