Насколько безопасна защищенная ОС ARM TrustZone?
Я пытаюсь прочитать официальный документ TrustZone, но действительно сложно понять некоторые основные вещи. У меня есть несколько вопросов по этому поводу. Это могут быть простые вопросы, но я новичок в этой области:
Что делает безопасный мир действительно "безопасным". Я имею в виду, почему нормальный мир может быть подделан, но не безопасный мир?
Кто может сменить безопасную ОС? Я имею в виду, как добавить "услугу"? может, например, разработчик приложения для мобильных платных приложений добавить службу в защищенной ОС для работы со своим приложением? если да, то как любой разработчик может добавить защищенную ОС, и она все еще безопасна?
- Что мешает вредоносному приложению из обычной ОС вызвать исключение SMC и перенести его в защищенную ОС? ответил
2 ответа
Идея безопасного мира состоит в том, чтобы код выполнялся там как можно меньше и как можно проще - минимальный уровень для выполнения своих обязанностей (обычно контроль доступа к какому-либо ресурсу, например, ключам шифрования или аппаратному обеспечению, или облегчение некоторых безопасных функций, таких как шифрование / дешифрование).,
Поскольку объем кода в безопасном мире невелик, его можно легко проверять, а площадь ошибок уменьшается. Однако это не означает, что безопасный мир автоматически становится "безопасным". Если в коде безопасного мира есть уязвимость, его можно использовать, как и любую другую уязвимость безопасности.
Сравните это с кодом, выполняющимся в обычном мире. Например, ядро Linux намного сложнее и намного сложнее для аудита. Существует множество примеров уязвимостей ядра и эксплойтов, которые позволяют вредоносному коду захватить ядро.
Чтобы проиллюстрировать этот момент, предположим, что у вас есть система, в которой пользователи могут платить деньги через некоторую систему транзакций "вызов-ответ". Когда они хотят совершить транзакцию, устройство должно подождать, пока пользователь нажмет физическую кнопку, прежде чем подписать транзакцию криптографическим ключом и авторизовать платеж.
Но что, если какой-нибудь вредоносный код воспользуется ошибкой ядра и сможет запустить произвольный код в режиме ядра? Обычно это означает полное поражение. Вредонос способен обходить все механизмы контроля и считывать ключи подписи. Теперь вредоносное ПО может производить платежи любому, кому захочет, даже не нажимая кнопку.
Что если бы был способ, позволяющий подписывать транзакции без знания ядром Linux фактического ключа? Войдите в систему безопасного мира.
У нас может быть небольшая защищенная операционная система с единственной целью подписания транзакций и удержания ключа подписи. Однако он откажется подписать транзакцию, если пользователь не нажмет специальную кнопку. Это очень маленькая ОС (в килобайтах), и вы наняли людей для ее аудита. В любом случае, в безопасной среде ОС нет ошибок или уязвимостей.
Когда операционная система нормального мира (например, Linux) должна подписать транзакцию, она делает SMC-вызов для передачи управления в безопасный мир (обратите внимание, что нормальному миру вообще не разрешается изменять / читать безопасный мир) с транзакцией, которую она хочет подписать. ОС защищенного мира будет ожидать нажатия кнопки от пользователя, подписывать транзакцию и затем возвращать управление в обычный мир.
Теперь представьте себе ту же ситуацию, когда вредоносное ПО захватило ядро Linux. Вредоносная программа теперь не может прочитать ключ подписи, потому что она находится в безопасном мире. Вредоносная программа не может подписывать транзакции без согласия пользователя, поскольку ОС безопасного мира откажется подписывать транзакцию, если пользователь не нажмет кнопку.
Этот вид использования предназначен для безопасного мира. Вся идея заключается в аппаратном разделении безопасного и нормального мира. Из нормального мира невозможно напрямую вмешаться в мир безопасности, потому что аппаратное обеспечение гарантирует это.
В частности, я не работал с TrustZone, но я думаю, что после загрузки ОС в защищенном мире, ее нельзя будет напрямую изменить. Я не думаю, что разработчики приложений должны иметь возможность "добавлять" сервисы в операционную систему безопасного мира, поскольку это противоречит ее цели. Я не видел ни одного поставщика, позволяющего третьим сторонам добавлять код в свою безопасную мировую ОС.
Чтобы ответить на ваш последний вопрос, я уже ответил на него в ответе здесь. Исключения SMC - это то, как вы запрашиваете сервис у ОС безопасного мира - это в основном системные вызовы, но для ОС безопасного мира. Что получит вредоносный код, перенеся контроль в безопасный мир?
- Вы не можете изменить / прочитать безопасный мир из нормального мира
- Когда вы передаете контроль в безопасный мир, вы теряете контроль в нормальном мире
Что делает безопасный мир действительно "безопасным". Я имею в виду, почему нормальный мир может быть подделан, но не безопасный мир?
Разработчик системы безопасности делает это безопасным. TrustZone - это инструмент. Это обеспечивает способ для разделения физической памяти. Это может предотвратить атаку DMA. TrustZone обычно поддерживает блокировку при загрузке. Поэтому, когда физическое сопоставление завершено (безопасные / обычные разрешения для мира), их нельзя изменить. TrustZone предоставляет инструменты для разделения прерываний, а также для безопасной загрузки.
Важно отметить, что безопасный мир - это технический термин. Это просто состояние, отличное от нормального мира. Название безопасный мир не делает его безопасным! Разработчик системы должен. Это сильно зависит от того, что защищенные активы. TrustZone предоставляет только инструменты для разделения вещей, которые могут помешать нормальному доступу к миру.
Концептуально существует два типа кода безопасного мира TrustZone.
- Библиотека - здесь обычно не будет прерываний, используемых в безопасном мире. Безопасный API - это волшебная восьмерка. Вы можете задать ему вопрос, и он даст вам ответ. Например, возможно, что некоторые системы управления цифровыми правами могут использовать этот подход. Секретные ключи будут скрыты и недоступны в обычном мире.
- Безопасная ОС - здесь безопасный мир будет иметь прерывания. Это сложнее, так как прерывания подразумевают какое-то упреждение. Защищенная ОС может использовать или не использовать MMU. Обычно MMU необходим, если будет использоваться системный кеш.
Это две большие разницы между окончательными решениями TrustZone. Зависит от конструкции системы и конечного приложения. TrustZone является ТОЛЬКО частью инструментов, чтобы попытаться достичь этого.
Кто может сменить безопасную ОС? Я имею в виду, как добавить "услугу"? может, например, разработчик приложения для мобильных платных приложений добавить службу в защищенной ОС для работы со своим приложением? если да, то как любой разработчик может добавить защищенную ОС, и она все еще безопасна?
Это не определяется TrustZone. Поставщик SOC (люди, которые лицензируют ARM и собирают ЦП) должен предоставить технологию безопасной загрузки. Защищенная ОС может быть в ПЗУ и, например, не может быть изменена. Другими способами являются то, что безопасный код имеет цифровую подпись. В этом случае, вероятно, имеется встроенное защищенное ПЗУ, которое проверяет цифровую подпись. Поставщик SOC предоставит (обычно NDA) информацию и методы для безопасной загрузки. Обычно это зависит от их целевого рынка. Например, физическая защита от несанкционированного доступа и аппаратное шифрование / дешифрование также могут быть включены в SOC.
Встроенное ПЗУ (запрограммированное только поставщиком SOC) обычно имеет механизмы для загрузки из разных источников, таких как флэш-память NAND, флэш-память NOR, eMMC, ROM, Ethernet и т. Д.). Как правило, он имеет некоторую одноразовую память (EPROM), которую поставщик устройства / решения (люди, которые обеспечивают безопасность приложения) может запрограммировать для настройки системы.
Другими функциями являются безопасная отладка, безопасный JTAG и т. Д. Очевидно, что все это возможные векторы атаки.