Trust zone что это

Общие условия и положения, оплата и возврат платежей

Правила и Условия Trust.Zone

Наш головной офис находится по адресу: Suite 509, Capital City Building, Victoria, Mahe, Seychelles

Trust.Zone несет полную ответственность за разработку программного обеспечения, обновление, изменение или усовершенствование программного обеспечения Trust.Zone VPN, веб-сайта Trust.Zone и обслуживания клиентов.

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

Условия предоставления услуг

При использовании Trust.Zone, вы соглашаетесь с настоящими Условиями использования. Во-первых, мы просто хотели дружески напоминить, что вы несете ответственность за соблюдение всех законов и правил принятых в вашей стране. Кроме того, сайт и програмное обеспечение Trust.Zone защищены авторским правом.

Обязанности заказчика

— Вы соглашаетесь защищать свои VPN и Trust.Zone логин/пароль от несанкционированного использования и не публиковать или передавать вашу учетную запись третьим лицам. Вы несете ответственность за все действия, которые происходят на наших серверах, сделанные под Вашим логином и паролем.

— Не передавать данные Trust.Zone аккаунта, сам клиент Trust.Zone VPN с данными для авторизациии или любое другое программное обеспечение Trust.Zone другому лицу. Вы обязуетесь использовать Trust.Zone VPN только на ваших собственных устройствах. Запрещено давать в аренду или делить свой Trust.Zone аккаунт, Trust.Zone программное обеспечение с данными для авторизации или любое другое программное обеспечение Trust.Zone VPN с другими пользователями.

— Использовать не более трёх одновременных соединений к сети Trust.Zone.

— Не продавать, перепродавать, торговать или передавать ваши данные учётной записи любому другому лицу без наличия специального разрешения от Trust.Zone.

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

— Не осуществлять кибератаки в любой форме на другие компьютеры или сети с использованием сервиса Trust.Zone.

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

Если наша система определит, что вы делите свой аккаунт Trust.Zone с другими интернет-пользователями, то мы сохраняем за собой право закрыть ваш аккаунт без права аппеляции или возврата средств.

Гарантийные обязательства

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

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

Возмещение ущерба

Пользователь обязуется не причинять и возмещать ущерб Trust.Zone от любых издержек, расходов, потерь или ответственности, вытекающей из каких-либо претензий, требований, или судебного разбирательства любым лицом против Trust.Zone, которые могут возникнуть на основании: использования или попытки использования Сервиса Клиентом или любым лицом, уполномоченным Заказчиком или от использования любого объекта или оборудования, подключенного к сервису Заказчиком или любым лицом, уполномоченным Заказчиком; или любой нагрузки на оборудование или программное обеспечение возникшей в результате использования Заказчиком или любым лицом, уполномоченным Заказчиком;

Прекращение действия соглашения

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

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

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

Платная подписка

После подтверждения Клиентом своего адреса электронной почты, бесплатная тестовая подписка добавляется в профиль Клиента. Бесплатная тестовая подписка сделана для того, чтобы предоставить возможность Заказчику протестировать услуги бесплатно и принять окончательне решения о покупке платной подписки или отказаться от нее.

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

После того, как мы получаем подтверждение платежа за платную подписку, мы незамедлительно активируем вашу платную подписку. Обратите внимание, что ваша подписка БЕСПЛАТНЫЙ ТЕСТОВЫЙ ПЕРИОД незамедлительно отключается, даже если вы ещё не закончили ей пользоваться или еще не использовали 1ГБ допустимого на ней трафика.

Политика возврата денег

Если Вы будете абсолютно не удовлетворены нашими услугами, и Вы уведомите нас в письменной форме по электронной почте в течение первых 10 дней после Вашего платежа, что хотите отменить подписку, то Вам возместят 100% суммы в случае, если использование трафика было не более чем 1 ГБ.

Запросы, сделанные позже 10 дней с момента даты покупки, будут отклонены.

Перед тем, как требовать рефанд (возврат), мы просим вас ознакомиться с часто задаваемыми вопросами (FAQ) от наших пользователей. В большинстве случаев вы сможете найти ответ на любой вопрос и решить любую проблему. Тем не менее, вы также можете обратиться в службу поддержки Trust.Zone, заполнив контактную форму.

Если возврат платежа будет удовлетворен, Вам прийдёт уведомление по электронной почте; для получения платежа может понадобится до 20 дней с момента Вашей заявки. Если Вы не получили возврат платежа после 20 дней, пожалуйста, сообщите нам, используя форму обратной связи. Наша бесплатная тестовая подписка не может быть отменена, и не продлевается автоматически. В исключительных случаях, если ваша квота в 1 Гб на платной подписке превышена, вы можете попросить частичный рефанд. Заполните форму для получения частичного платежа здесь.

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

Дистрибуция

Trust.Zone авторизует своих дистрибьютеров получать платежи от сторонних платежных систем и сервисов, E-commerce платформ и вебсайтов, платежных терминалов.

Trust.Zone уполномочивает Tersys Group OÜ (дистрибьютор) находящийся по адресу J.Poska, tn.11, Таллинн, Эстония для проведения платежных операций.

Прочие положения

Сервис Trust.Zone постоянно и динамично изменяется и улучшается. Данные Общие положения могут быть полностью или частично изменены.

Эти изменения будут реализованы без предварительного уведомления. Мы предлагаем Вам каждый раз при посещении сайта проверять последнюю версию Общих положений, которые находятся по адресу: https://trust.zone/terms

Контакты

Источник

TrustZone: доверенная ОС и ее приложения

В прошлых статьях мы рассматривали аппаратное устройство TrustZone и работу механизма Secure Monitor. Сегодня речь пойдет о доверенной ОС (TEE) и ее приложениях. И если прошлый раз были довольно низкоуровневые вещи, сейчас все будет на вполне высоком уровне — на уровне операционной системы.

Что такое TEE

Что же такое TEE? Это доверенная среда исполнения (Trusted Execution Environment), в первую очередь — это среда исполнения программ. Опишем ее в терминах функции и свойств, но не в смысле программирования, а в философском смысле.

Например, у поезда дальнего следования, электрички и такси одна самая главная функция – перевозить людей. А вот по свойствам они отличаются, например: поезд возит между городами, электричка — за город, а такси — преимущественно по городу. Поезд и электричка по билетам, такси — нет. И так далее.

Функция TEE — доверенно хранить для нас некоторые данные и запускать для нас приложения. Мы хотим передавать TEE команды: запустить такое-то приложение, взять такие-то данные и сделать с ними то и это. При этом код приложения видеть не можем, равно как и данные. Мы будем только получать результат. Взаимодействие с TEE очень похоже на RPC.

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

У TEE есть ряд свойств, но основные таковы: a) мы доверяем ее реализации, и б) она надежно отделена от основной ОС устройства, защищена, ее сложно нарушить или сломать. Есть и другие свойства, но мы называем ее доверенной ОС именно за это. Свойство б) самое главное — TEE отделена, и ее сложно нарушить, то есть она защищена.

Если смотреть на TEE через призму функций и свойств, то становится ясно, что TEE — это даже не совсем про TrustZone. TrustZone – это один из способов отделения TEE от основной (гостевой) ОС.

Варианты реализации TEE

Если главные свойства TEE — что она отделена и ее сложно нарушить, то мы можем придумать разные варианты реализации TEE:

TEE как ОС

В прошлых статьях мы все время называли TEE доверенной ОС и говорили, что она во многом похожа на настоящие операционные системы.

Программный интерфейс TEE

Для взаимодействия с другими программными компонентами у TEE есть API:

Для TEE есть набор спецификаций GlobalPlatform, они описывают API, требования, сценарии использования и т. п.
Основные API TEE для ее программ описываются в «TEE Internal Core API Specification». Там описаны функции хранения данных, криптографические функции, и т. п. А в «TEE Client API» описано, как вызывать приложения из Normal World.

Если ваша TEE реализует эти API, написать приложение для нее будет довольно легко. Благодаря одному API реализуется и переносимость программ.

Отличия TEE от обычной ОС

Два главных отличия TEE от Linuх и других знакомых нам ОС общего применения:

TEE же не обрабатывает внешние данные и не передает их приложениям. Вместо этого она обрабатывает команды и данные, переданные из Normal World через TEE Client API, и на этом почти все. Получается, что TEE выступает для ОС как некоторая библиотека с интерфейсом RPC, функции которой вызываются. После обработки функций TEE может ничего не делать.

Второе отличие вытекает из первого. TEE в TrustZone делит процессорное время с Normal World и вызывается как библиотека. TEE не выделяет под себя процессорное время постоянно, она тратит столько времени, сколько ей нужно для выполнения запроса и потом передает управление в Normal World. А раз так, то она и не должна иметь своего планировщика — ей достаточно планировщика гостевой ОС.

Планировщик основной ОС передает управление в TEE косвенно:

Приложения TEE

Trustlet — это Trusted Applet. Это программа для TEE, как мы уже выяснили, общается она с TEE через системные вызовы, у нее есть жизненный цикл и т. п.

Но все равно название указывает, что это несамостоятельный компонент. Здесь несамостоятельность выражается в том, что трастлет будет выполнять вызовы из Normal World, а потом отключаться вместе с TEE. Если он закрутится в бесконечном цикле, ядро процессора перестанет выполнять функции ОС, и все в конечном счете повиснет. А вот программа для обычной ОС может крутиться в бесконечном цикле и майнить считать какие-то задачи, это совершенно нормально для программы. В этом плане она самостоятельнее трастлета.

Трастлет должен иметь какой-то идентификатор, чтобы Normal World мог его называть. Принято давать трастлетам в качестве имени UUID — уникальные идентификаторы.

Жизненный цикл трастлета

Рассмотрим, как происходит запуск трастлета и выполнение команд.

Логично было бы загрузить трастлет в память и начать работать, но в GlobalPlatform TEE Client API для запуска трастлета нужно создать контекст и установить сеанса работы с трастлетом.

Создание контекста (context) — это установление соединения между программой Normal World и TEE. При этом спецификация GlobalPlatform предполагает, что в устройстве может быть несколько TEE, и на момент создания контекста можно выбрать, к какой TEE обратиться.

В GlobalPlatform TEE Client API для этого предусмотрена функция:

Эта функция вызывается из приложения Normal World. Здесь name указывает на выбираемую TEE. Eсли мы хотим TEE по умолчанию или уверены, что у нас только одна TEE — подставляем NULL. В context сохраняется созданный контекст.

После создания контекста нужно установить сеанс работы с трастлетом. Тут нам пригодится UUID трастлета. Для этого вызывается функция:

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

При вызове TEEC_OpenSession контекст «context» и UUID трастлета «destination» передаются как входные данные. Установленный сеанс будет сохранен в «session». Некоторые параметры здесь и далее мы не будем рассматривать, они не так важны для понимания.

В момент создания сеанса трастлет может быть загружен в память. Это то же, что происходит с приложениями в операционной системе. В большой TEE за это отвечает линковщик, он загружает бинарный образ трастлета, это такой подписанный ELF-файл. Если это маленькая TEE, трастлет должен быть уже загружен в память — он может быть статически слинкован или, для flash-микроконтроллеров, записан в flash-память по заданному адресу.

Давайте предположим, что у нас большая TEE, и нужно загрузить трастлет в память. Откуда он берется? В принципе TEE на момент загрузки нужен объект с неким UUID, и механизм получения этого объекта может быть любой:

После загрузки образа трастлета у него проверяется электронная цифровая подпись. Используется система сертификатов, и TEE будет проверять, что трастлет подписан стороной, которой доверяет и TEE. Это очень важно, потому что это исключает возможность загрузки подмененного трастлета с каким-то malware.

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

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

Здесь «session» указывает на наш сеанс, то есть на экземпляр TEE и экземпляр трастлета, с которыми мы работаем.

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

Если нужно передать параметры вызываемой функции, их передают через operation — это указатель на структуру TEEC_Operation. Не будем сейчас сильно углубляться, просто заметим, что эта структура, содержащая до 4 параметров функции (тип TEEC_Parameter). Параметры могут быть простым значением TEEC_Value или указателем на память. У параметров также есть типизация по направлению: TEEC_VALUE_INPUT (входные данные), TEEC_VALUE_OUTPUT (выходные данные), или TEEC_VALUE_INOUT (двунаправленный).

Если мы передаем указатель на структуру TEEC_Operation, ее сначала нужно инициализировать: задать все значения и направления. По завершении вызова мы можем проверить возвращенные значения в этой структуре (для TEEC_VALUE_OUTPUT и TEEC_VALUE_INOUT).

За время сеанса мы можем вызывать функции трастлета столько раз, сколько нам потребуется. В конце работы нужно будет завершить сеанс и освободить контекст вызовами TEEC_CloseSession и TEEC_FinalizeContext.

Все это очень напоминает RPC, не так ли? В принципе, все операции с TEE и задуманы как RPC, и благодаря этому можно работать с самыми разными реализациями TEE: в TrustZone, в отдельном ядре, в отдельном чипе.

Supplicant

Выше мы задались вопросом: как TEE загружает данные с файловой системы или по сети?
Если задуматься, TEE сама не имеет доступа к файловой системе ОС. То есть, TEE реализованная в TrustZone, могла бы иметь такой доступ, но тогда ей нужно было бы делить его с Normal World, а это не так-то просто. Например, Linux постоянно работает с файловой системой, и актуальное ее состояние есть только в памяти ядра Linux, а не на диске. Если TEE захочет вмешиваться и работать с файловой системой параллельно, это будет очень непросто. С сетевым обменом то же самое.

Кроме того, TEE — довольно маленькая ОС, и реализовывать в ней драйверы низкого уровня для работы с носителями, с сетевым контроллером, поддерживать сетевой стек или драйвер ФС было бы накладно. Кроме того, это многократно увеличивает attack surface — был бы шанс взломать TEE, подсунув необычный inode на ext2 или что-то такое. Мы так не хотим.
Поэтому при запуске ОС загружается так называемый Supplicant — программа-помощник. Она все время находится в соединении с TEE, и TEE использует ее для обращения к ресурсам Normal World.

Поэтому, если TEE хочет загрузить образ трастлета с файловой системы, она обращается к Supplicant:

TEE: А подайте-с объект с таким-то UUID?
Supplicant: (Загружает объект с файловой системы) Извольте-с!

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

Библиотека userspace

Программный интерфейс (вызовы TEEC_OpenSession и т. д.) реализуется с помощью библиотеки, которая транслирует вызов с уровня приложения в TEE.

При реализации TEE в TrustZone для этого библиотека должна сначала передать вызов на уровень ядра ОС, так как только ядро ОС может вызывать SMC (Secure Monitor Call).
В связке Linux + OP-TEE библиотекой userspace является libteec. Она транслирует вызовы GlobalPlatform TEE Client API в драйвер ядра через операции ioctl над файлом устройства: при запуске ОС загружается модуль ядра (драйвер), драйвер создает файл устройства. Открывая файл устройства с помощью libteec, пользовательская программа может работать с TEE Client API.

То есть, работает такая конструкция:

Приложение > libteec > файл устройства > драйвер ядра > SMC > TEE > трастлет.

Пример работы трастлета

Вот как это работает в реальном применении:

Здесь трастлет используется для электронной подписи документов. Программа из Linux вызывает трастлет, для чего последовательно создается контекст TEE, сеанс с трастлетом, передаются данные для подписи, и возвращается электронная подпись.

Заключение

В этой статье мы разбирались, что такое TEE и трастлеты. Мы познакомились с API TEE и узнали, как вызываются трастлеты.

Мы сознательно оставили в стороне многие вещи, такие как использование Shared Memory и написание трастлетов, ведь статья не претендует стать исчерпывающим руководством.

Если вы заинтересовались темой TEE, то продолжайте изучать самостоятельно: начать можно с изучения спецификаций GlobalPlatform или с разбора работы OP-TEE. Вы также можете прислать нам резюме с пометкой «TrustZone».

Источник

Технология TrustZone в STM32L5. Теория и практика

Вячеслав Семенов (г. Ростов-на-Дону), Святослав Зубарев (г. Смоленск)

Технологии защиты и безопасности встраиваемых систем постоянно совершенствуются, и компания STMicroelectronics воплощает в своих микроконтроллерах самые передовые технологии. Функция TrustZone ядра ARM Cortex-M33 открывает новые возможности для создания приложений, где требуется высокий уровень защиты программ, соответствующий стандартам PSA. Давайте подробно рассмотрим данную функцию на примере микроконтроллеров нового семейства STM32L5.

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

Рис. 1. Диаграмма типового процесса работы приложения с изоляцией: зеленая зона – доверенная область, красная – недоверенная

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

Виды изоляции в STM32

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

Одним из наиболее распространенных решений является модуль защиты памяти (Memory Protection Init, MPU) в совокупности с уровнями привилегированности процессов ядра Cortex. MPU – это специализированный модуль, позволяющий определить области памяти, к которым будет ограничен доступ ядра при работе из непривилегированного режима (рисунок 2).

Рис. 2. Модуль защиты памяти MPU

Другим способом является применение Firewall, доступного в сериях L0 и L4. Firewall контролирует все транзакции на шине между областями памяти Flash и SRAM. Если Firewall закрыт, и недоверенное приложение делает попытку доступа к защищенной области памяти, то он фиксирует это событие и генерирует сигнал сброса микроконтроллера. Когда недоверенное приложение использует доверенный API для доступа к некоторым ресурсам доверенного проекта, происходит открытие Firewall, то есть переход к узко ограниченной зоне в защищенной области. Эта четко определенная точка входа позволяет реализовать весь механизм и обеспечить безопасность. Если Firewall обнаружит попытку доступа через какую-либо другую зону, также будет сгенерирован сигнал сброса (рисунок 3).

Рис. 3. Схема работы Firewall

Еще одним способ изоляции является Secure Flash, работающий только на уровне Flash-памяти. После подачи питания или сброса микроконтроллер загружается из доверенной части памяти, где выполняется доверенная загрузка (Secure Boot). После проверки целостности кода и аутентификации приложения пользователя выполнение программы переходит к недоверенной области, а зона Secure Boot становится абсолютно невидимой для системы до следующего сброса. Полностью пропадает возможность доступа к этой зоне из какой-либо другой области. Главный недостаток данной технологии в том, что если требуется получить доступ к данным, хранящимся в зоне Secure Boot, необходимо инициировать сброс питания, что усложняет алгоритм и требует дополнительных ресурсов.

Рис. 4. Работа Secure Flash

Шагом вперед является новая технология ARM – TrustZone. Она основана на фильтрации транзакций шины и отслеживании уровня доступа ядра.

Концепция TrustZone

TrustZone – это дополнительная функция ядра Cortex-M33, основанного на архитектуре ARM-V8M. Ядро Cortex®-M33 является частью группы 32-битных RISC-ядер Arm Cortex®-M. Оно реализует магистральную архитектуру Armv8-M и имеет 3-ступенчатый конвейер. В дополнение к скалярным целочисленным инструкциям, оно также поддерживает операции с плавающей запятой одинарной точности и целочисленные инструкции SIMD для улучшения производительности алгоритмов DSP. В процессоре реализована технология ARM TrustZone® с использованием расширения безопасности ARMv8-M, поддерживающего доверенные и недоверенные состояния.

TrustZone контролирует шину данных с учетом режима безопасности ядра. Данная функция сочетает качества рассмотренных выше способов изоляции, позволяет гибко настраивать области памяти и периферию, вплоть до отдельных выводов GPIO, разделяя их на доверенные и недоверенные (рисунок 5). Благодаря аппаратной поддержке TrustZone работает в реальном времени и обеспечивает малое время задержек на прерываниях, а переключение контекста делает быстрым и предсказуемым.

Рис. 5. Разделение на доверенное (а) и недоверенное (б) пространство

Система всегда запускается в доверенном режиме, если функция TrustZone активна, иначе микроконтроллер работает как при архитектуре ARM V7-M, без каких-либо разделений. Код, исполняемый в доверенном состоянии, имеет доступ как к доверенной, так и к недоверенной информации. Разметка памяти определяет границы доверенной и недоверенной областей, переходы между которыми осуществляются автоматически, что снижает нагрузку на процессор.

Переходы между доверенным и недоверенным пространствами в TrustZone V8-M

Когда статус доверенности исключения/прерывания совпадает со статусом процессора, все происходит практически также, как и в процессорах на основе V7-M.

Рассмотрим отличную ситуацию. Например, когда возникает недоверенное прерывание, а процессор выполняет доверенный код, то процессор:

1) отправляет всю доверенную информацию в доверенный стек;

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

Следует отметить, данный порядок действий повышает задержку на прерывании с 12 до 21 тактов.

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

Рис. 6. Граф переходов между состояниями

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

С помощью модуля назначения атрибутов доверенности (Security Attribution Unit, SAU) можно программно настроить доверенность до 8 областей памяти и аппаратно — определенный модуль атрибуции (Implementation Defined Attribution Unit, IDAU), который позволяет назначать атрибут защиты на аппаратно фиксированных областях памяти. Это дает возможность задать области памяти как:

Рисунок 7 показывает, как могут совершаться вызовы из разных типов памяти.

Рис. 7. Вызовы из разных типов памяти

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

Первой инструкцией в данном случае будет “SG” – Security Gate (доверенный шлюз), а затем переход к доверенному пространству:

Функция в доверенном пространстве по завершении своей работы производит возврат в недоверенное пространство:

Рассмотрим, как можно задать конфигурацию доверенности для памяти. Как было сказано выше, IDAU статично определяет области с атрибутом NSC, недоверенные NS, а также свободные, с размером, кратным 64 Мбит. SAU позволяет задать до 8 областей, которые могут переопределить зоны IDAU в целях утверждения доверенных зон либо подтвердить их недоверенность. На рисунке 8 представлен пример конфигурации областей.

Рис. 8. Пример задания атрибутов доверенности и взаимодействия SAU/IDAU

Сочетание конфигураций SAU/IDAU определяет результат разметки памяти, показанный в столбце «FINAL». При несовпадении атрибутов SAU переопределяет IDAU. Стоит обратить внимание на области Alias-NS и Аlias-S под номерами 1 и 2 в левой части рисунка 8. Об их важности будет сказано далее.

Для лучшего понимания рассмотрим зонирование памяти в другом ключе. Рассмотрим конфигурацию памяти на примере. Имеется физическая память, которую необходимо полностью разметить атрибутами NS, NSC и S. Наша цель – получить разметку, как изображено на рисунке 9.

Рис. 9. Целевая картина разметки памяти

На рисунке 10 мы видим исходную разметку памяти по IDAU, в которой есть зоны Alias-NS и Alias-NSC. «Alias» означает «наложение», смысл и применение Alias-областей рассмотрим несколько позже.

Рис. 10. Разметка в IDAU

SAU по умолчанию определяет всю память как доверенную. Программисту необходимо переопределить в SAU, какие зоны будут являться NSC, NS или свободными от атрибутов. Пример такого переопределения показан на рисунке 11.

Рис. 11. Переопределение с помощью SAU

Результатом совместной конфигурации IDAU/SAU является разметка, представленная в правой части рисунка 12.

Рис. 12. Финальная разметка памяти

Виды доступа

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

Рис. 13. Комбинации условий доступа

Здесь вступает в силу значение Alias-областей. В соответствии с рисунком 9, нижний диапазон адресов 0x08000000…0x0BFFFFFF является Alias-Secure, а верхний диапазон 0x0C000000…0x0FFFFFFF является Alias-NSC. Этим обусловлено различие в результате попытки доступа в аналогичные области памяти. Таблица 1 консолидирует совокупности атрибутов и режимов процессора и соответствующих им результатов попытки доступа.

Таблица 1. Варианты доступа

Защита от чтения

RDP 0.5 – это режим безопасности, позволяющий производить отладку только недоверенного пространства. Отладчик не сможет получить доступ к доверенной области. Если представить, что RDP 0.5 нет, то из уровня 0 можно перейти на уровень 1, на котором нет возможности выбрать способ загрузки, нет связи с отладчиком. Если произвести возврат с уровня 1 на уровень 0, то произойдет полное стирание памяти. При переходе с уровня 1 на уровень 2 становятся невозможными какие-либо изменения, отсутствует связь, нет возможности изменять байты опций защиты, микросхема полностью закрывается. Когда мы вводим уровень 0.5, появляются дополнительные возможности. При переходе с уровня 0 на уровень 0.5 мы теряем полный доступ к доверенной зоне и можем лишь подключиться к недоверенной зоне и отлаживать ее. С уровня 0.5 мы можем перейти на уровень 1 с полной защитой, а возврат на один из нижних уровней выглядит иначе. Если происходит переход с уровня 0.5 на уровень 0, то выполняется полное стирание всей памяти. При переходе с уровня 1 на уровень 0.5 стирается лишь недоверенная область памяти. Таким образом, RDP Level 0.5 позволяет работать в недоверенном пространстве, не затрагивая доверенное.

Активация TrustZone

Активация данной функции осуществляется посредством установки бита TZEN в его байте опций. SAU конфигурируется на этапе загрузки системы. Кроме того, на данном этапе можно сконфигурировать функции защиты Flash-памяти:

Деактивация TrustZone

Деактивация производится путем сброса бита TZEN, что возможно только при понижении защиты RDP с уровня 1 до уровня 0, что влечет за собой полное стирание памяти. Когда TrustZone деактивируется после загрузки байтов опций, также отключаются следующие функции защиты:

Также все доверенные регистры становятся RAZ/WI (Read-as-zero, Writes Ignored) – при чтении возвращают нули, запись игнорируется.

TrustZone в МК STM32L5

В практической части мы рассмотрим работу с защищенной и незащищенной областями памяти микроконтроллера STM32L5 на примере отладочной платы NUCLEO-L552ZE-Q:

Активация TrustZone на плате NUCLEO-L552ZE-Q

Для активации TrustZone первым делом подключим плату к ПК и запустим утилиту STM32CubeProgrammer (рисунки 14, 15).

Рис. 14. Запуск STM32CubeProgrammer

Рис. 15. Подключение NUCLEO-L552ZE-Q в STM32CubeProgrammer

Следующим шагом будет переход в раздел Optional bytes, далее в раздел User Configuration, и проверка установки бита DBANK. Его установка свидетельствует о том, что наша Flash-память разбита на два банка (рисунок 16).

Рис. 16. Проверка состояния бита DBANK

В данном разделе также проведем активацию TrustZone, установив соответствующий бит данных и нажмем «Apply» для сохранения конфигурации (рисунок 17).

Рис. 17. Проверка бита TZEN для активации TrustZone

После активации TrustZone мы видим, что появились разделы Secure Area 1 и Secure Area 2, определяющие области памяти, доступные для работы. По умолчанию их диапазоны установлены как SECWM*_PSTRT Value = 0x0 и SECWM*_PEND Value = 0x7f в обоих случаях, что свидетельствует о том, что обе области являются защищенными. Для того чтобы область стала незащищенной, необходимо, чтобы значение байта SECWM*_PSTRT было больше SECWM*_PEND. Установим для второй области SECWM2_PSTRT Value = 0x7f и SECWM2_PEND Value = 0x0 и нажмем «Применить» (рисунок 18).

Рис. 18. Редактирование областей памяти Secure Area 1 и Secure Area 2

На этом настройки TrustZone окончены, перейдем к созданию тестового проекта в среде в STM32CubeIDE.

Создание тестового проекта в STM32CubeIDE

Запустим STM32CubeIDE и создадим новый проект для платы NUCLEO-L552ZE-Q (рисунок 19).

Рис. 19. Выбор платы проекта в STM32CubeIDE

Нажмем «Next» и зададим имя проекта, а также активируем функции TrustZone, остальные настройки оставим по умолчанию (рисунок 20).

Рис. 20. Установка имени проекта и активация функций TrustZone

Согласно документации на NUCLEO-L552ZE-Q, пользователю для работы доступна одна кнопка (GPIO PC13) и 3 светодиода: LD1 – GPIO PA5, LD2 – GPIO PB7 и LD3 – GPIO PA9. Для работы с ними необходимо активировать соответствующие GPIO.

Назначим PC13 функцию входа (рисунок 21).

Рис. 21. Установка GPIO PC13 в состояние Input

Далее установим PB7 как выход (будем использовать светодиод LD2), как показано на рисунке 22.

Рис. 22. Установка GPIO PB7 в состояние Output

Перейдем в настройки GPIO и назначим Pin Context Assignment для GPIO PC13 и GPIO PB7 как «Cortex-M33 non secure» и «Cortex-M33 secure», соответственно (рисунки 23, 24).

Рис. 23. Установка Pin Context Assignment для GPIO PС13

Рис. 24. Установка Pin Context Assignment для GPIO PB7

Сохраним проект (Ctrl + F5), откроем файл main.с в разделе TrustZone_test_Secure и добавим следующий код сразу после инициализации портов GPIO (рисунок 25):

Теперь при включении платы светодиод LD2 выполнит приветственное мигание, что подтвердит его работоспособность.

Рис. 25. Редактирование файла main.с в разделе TrustZone_test_Secure

Для работы с портом GPIO PB7 из незащищенной области создадим функцию типа CMSE_NS_ENTRY в файле secure_nsc.c (рисунок 26):

Рис. 26. Редактирование файла secure_nsc.c в разделе TrustZone_test_Secure

Чтобы получить к ней доступ из других областей проекта, добавим ее инициализацию в файл secure_nsc.h (рисунок 27):

Рис. 27. Редактирование файла secure_nsc.h

Далее перейдем в раздел TrustZone_test_NonSecure и в файле main.c добавим проверку состояния нашей кнопки (GPIO PС13). Если кнопка нажата, вызовем функцию Secure_Toggle_Pin(), после чего должен загореться светодиод LD2 (рисунок 28):

Рис. 28. Редактирование файла main.с в разделе TrustZone_test_NonSecure

Выполним сохранение и компиляцию проекта (рисунок 29).

Рис. 29. Компиляция проекта TrustZone_test

Далее зайдем в настройки откладки для TrustZone_test_Secure и добавим туда раздел TrustZone_test_NonSecure, как это показано на рисунках 30…32.

Рис. 30. Переход в настройки откладки для TrustZone_test_Secure

Рис. 31. Добавление в откладку раздела TrustZone_test_NonSecure

Рис. 32. Конечный результат настроек

Запустим отладку и проверим работоспособность нашей программы: при запуске платы светодиод LD2 должен мигнуть, после чего он вновь загорится только после нажатия пользовательской кнопки (рисунки 33, 34).

Рис. 33. Состояние платы NUCLEO-L552ZE-Q до нажатия пользовательской кнопки

Рис. 34. Состояние платы NUCLEO-L552ZE-Q после нажатия пользовательской кнопки

Проверка программы при активации RDP и отключение TrustZone

Для проверки работы включим защиту RDP уровня 0.5. Данный уровень защиты позволяет проводить отладку только в незащищенной области и доступен только при активации TrustZone. Для активации защиты снова запустим STM32CubeProgrammer и перейдем в раздел Option bytes, где зададим RDP значение, равное 55 (рисунок 35).

Рис. 35. Активация RDP уровня 0.5

Произведем сброс питания платы и проверим работоспособность нашего приложения (рисунки 36, 37).

Рис. 36. Состояние платы NUCLEO-L552ZE-Q до нажатия пользовательской кнопки, RDP Level 0.5

Рис. 37. Состояние платы NUCLEO-L552ZE-Q после нажатия пользовательской кнопки, RDP Level 0.5

Деактивация TrustZone происходит снятием соответствующего бита конфигурации, как это было ранее показано на рисунке 4.

Заключение

Мы подробно рассмотрели функцию TrustZone ядра Cortex-M33 с архитектурой ARMV8-M на примере микроконтроллеров серии STM32L5 – разобрали способы активации и деактивации, разделение памяти, атрибуты безопасности и их влияние на исполнение программного кода в различных режимах работы процессора. В ходе практической работы закрепили знания о работе с TrustZone на примере управления светодиодом по нажатию кнопки – создали проект в среде STM32CubeIDE, прошили микроконтроллер, получили наглядное представление о различии режимов работы TrustZone, особенностях применения защиты от чтения RDP level 0.5 и корректной деактивации TrustZone.

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

Функция TrustZone в микроконтроллерах STMicroelectronics доступна не только в серии STM32L5. Недавно было анонсировано новое семейство малопотребляющий микроконтроллеров STM32U5 на базе ядра ARM Cortex-M33. Благодаря улучшенному техпроцессу и специальной архитектуре модели STM32U5 будут иметь рекордно малое потребление и так же, как STM32L5, соответствовать высоким требованиям стандартов безопасности PSA.

Источник