Tee service что это

TeeService

The TeeService android app is a service in charge of running a trusted and secure operating system to protect the sensitive important information in the device processor.

During the explanation of this chapter, we will try to be very concise in what we would like to show you about the functioning and details about this built-in program very helpful for the android system.

What is TeeService for?

Tee (Trusted Execution Environment) is a pretty safe environment located in the internal processor. The TeeService is basically in charge of executing its own operating system to process its own instructions in order to provide a more adequate security for the device solutions located in a high-security area.

This service is very useful because brings more protection to the apps on your device against hackers or external attacks to the android system.

Can I uninstall TeeService?

You have the possibility of uninstalling the TeeService by just going to the app internal setting and selecting the remove option. However, we do not recommend to do so because we already explained the main role and how important is this application for the proper security of your smartphone.

If by any chance you delete this app by error, you have the possibility to get it back by just factory restoring your telephone. You can do it by just selecting your device Settings and try to locate the Reset option, where you will find the Factory Reset button. Before doing this we suggest you to back up your important information.

What permissions does this application have?

The permissions required for this app are the next:

As you can see, no permissions are required for the proper working of this service.

TeeService is a safe application or is it a virus

The TeeService may seem to be a weird app is you don´t know what is it for. Some users may think this is a virus o malware, but we already explain the service that it brings to your android.

There are isolated cases from users asking about it as a virus. We do not recommend you to delete it, and if you did it already, we recommend you to restart your telephone in order to have it again.

What to do if TeeService consumes too much battery?

The TeeService is not a heavy app. This is a 50kb built-in app that won´t consume energy from your battery at all. This app is never on the background, so, it has fewer chances to consume battery. In case it does, you just have to clear the cache on the app.

We hope you understood what is TeeService for and what is it for. If you did not, please comment on us about your doubts.

Источник

8 приложений для Android, которые нужно удалить. Они опасны

Кто бы что ни говорил, но Google Play – это помойка. Не даром её признали самым популярным источником вредоносного софта для Android. Просто пользователи в большинстве своём доверяют официальном магазину приложений Google и скачивают оттуда любое ПО без разбору. А какой ещё у них есть выбор? Ведь их всегда учили, что скачивать APK из интернета куда опаснее. В общем, это действительно так. Но остерегаться опасных приложений в Google Play нужно всегда. По крайней мере, постфактум.

Есть как минимум 8 приложений, которые нужно удалить

Google добавила в Google Play функцию разгона загрузки приложений

Исследователи кибербезопасности из антивирусной компании McAfee обнаружили в Google Play 8 вредоносных приложений с многомиллионными загрузками. Попадая на устройства своих жертв, они скачивают получают доступ к сообщениям, а потом совершают от их имени покупки в интернете, подтверждая транзакции кодами верификации, которые приходят в виде SMS.

Вредоносные приложения для Android

Нашли вирус? Удалите его

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

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

Как найти вирус на Android

Но ведь, скажете вы, на смартфоны софт устанавливается с пользовательскими названиями. Да, это так. Поэтому вам понадобится небольшая утилита, которая позволит вам эффективно выявить весь шлаковый софт, который вы себе установили, определив название их пакетов.

В красном квадрате приведен пример названия пакета

Package Name Viewer удобен тем, что позволяет не просто найти нужное приложение по названию его пакета, но и при необходимости перейти в настройки для его удаления. Для этого достаточно просто нажать на иконку приложения, как вы попадёте в соответствующий раздел системы, где сможете остановить, отключить, удалить накопленные данные, отозвать привилегии или просто стереть нежелательную программу.

Как отменить подписку на Андроиде

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

Если подписка оформлена через Google Play, отменить её ничего не стоит

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

Источник

Погружение в службы Android

Перевод статьи «Deep Dive into Android Services» от Nazmul Idris. Я оставил оригинальное название автора, хотя это скорее не «погружение», а «знакомство». Думаю, текст будет полезен начинающим разработчикам. Статья отлично дополняет офф. документацию по службам на Android. В статье разбираются особенности взаимодействия с запущенными и привязанными службами. Плюс статьи в том, что учитываются изменения в работе со службами в Android O. В переводе есть незначительные, по сравнению с оригиналом, изменения, добавленные для пущей ясности.

Введение

Большинство современных android-приложений выполняют часть задач в фоне. Это означает, что задачи выполняются в фоновом потоке, а не в потоке пользовательского интерфейса (UI-поток).

В этом случае служба (service) это подходящий компонент Android, который свяжет жизненный цикл потока со своим жизненным циклом, и таким образом не потеряет его.

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

Термины фон и передний план перегружены, и могут применяться к:

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

Потоки, службы и жизненный цикл компонентов Android

Ниже приведены пояснения к основным временным моментам этой диаграммы Гантта. Детали этих моментов (и пояснения к ним) приведены в остальной части статьи.

Метод службы onCreate() вызывается в момент ее создания (путем запуска или привязки к ней).

Метод службы onDestroy() вызывается системой только когда вы сообщили службе, что пришло время завершать работу. Служба не знает, что будет происходить в коде ваших Thread или Executor — это зона вашей ответственности. Таким образом, задача программиста сообщить службе о начале и о завершении работы.

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

Изменения в Android O

Запущенные службы

Чтобы служба стала запущенной, вы должны вызвать startService() с явным намерением. Если вы не сделаете этого, тогда служба не перейдет в запущенное состояние. И, таким образом, она не сможет перейти на передний план, и stopSelf() на самом деле ничего не выполнит.

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

Intent

Передний план и механизм постоянного уведомления

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

Примеры использования службами переднего плана:

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

Ниже пример старта запущенной службы на переднем плане:

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

Кроме того, вот еще одна статья, в которой больше деталей о создании уведомлений в MediaStyle (поскольку для фонового проигрывания аудио-файлов нужны как уведомления, так и привязанные и запущенные службы)

Остановка запущенных служб

Это объясняет почему метод onStartCommand() должен уметь обрабатывать Intent ы. Используя этот механизм мы можем «сказать» службе, чтобы она остановила работу. Ниже код, который иллюстрирует эти возможности:

Чтобы остановить службу вы можете выполнить одно из следующих действий:

Вот несколько примеров остановки службы из Activity :

И вот код в вашей службе, который будет обрабатывать эти запросы (при условии, что ваша запущенная служба находится на переднем плане):

Привязанные службы

Отличия между привязанной и запущенной службами:

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

bindService() и onCreate()

Ниже приведен пример реализации ServiceConnection :

Привязка службы

Отвязка от службы и вызов onDestroy()

Вот как выглядит вызов unbindService() в клиентском компоненте:

Вот пример как может выглядеть onUnbind() в коде привязанной службы:

Привязанные и запущенные службы одновременно

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

Если служба не запущена, то клиент, который хочет привязаться к ней, вызовет onCreate() у службы. Если служба уже запущена, этот метод не вызывается. С другой стороны, если клиент отвязывается от службы и при этом служба не запущенная, то вызывается onDestroy() и служба уничтожается.

Переход в запущенное состояние

Поскольку клиент, привязываясь к службе, не переведет ее в запущенное состояние, то для привязанных и запущенных служб одновременно, требуется чтобы служба переходила в запущенное состояние самостоятельно. Вот, как можно это сделать с учетом Android O:

В коде под спойлером:

Но, перед фактическим исполнением работы, служба сначала переводит себя в запущенное состояние.

Завершение работы службы и отвязывание

Если служба не в запущенном состоянии и клиентский компонент отвязывается от службы, то служба уничтожается и вызывается onDestroy()

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

Примеры

Реализацию большинства из того, о чем говорилось в статье, можно глянуть на GitHub.

Это небольшая утилита для Android O и N, которая держит телефон в активном состоянии, если он на зарядке.

Источник

Защищенные среды мобильных устройств

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

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

Безопасная среда исполнения (Trusted Execution Environment, TEE) характеризуется защищенностью, контролем целостности и наличием собственной оперативной памяти и пространства хранения. Она изолирована от обычной «функционально богатой среды исполнения» (Rich Execution Environment, REE), в которой работают операционная система и приложения мобильного устройства. Пользуясь возможностями TEE, разработчики могли бы создавать приложения и сервисы REE, которые остаются защищенными даже при компрометации операционной системы — рискованные операции изолированы от REE, а конфиденциальные данные (например, криптографические ключи) никогда не покидают TEE.

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

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

Безопасность мобильных платформ

Развитие механизмов безопасности для мобильных устройств шло по иному пути, нежели для персональных компьютеров [1], следуя очень жестким требованиям к защищенности, часть из которых была сформулирована еще на заре персональной мобильной связи два десятка лет назад:

Чтобы обеспечить выполнение этих требований, производители мобильных устройств, поставщики микросхем и разработчики платформ изначально создавали и внедряли защитные механизмы аппаратного и платформного уровня, и важнейшими из них стали аппаратные TEE. Первые устройства с TEE появились десять лет назад — это были телефоны Nokia на процессорах Texas Instruments [3].

Один из способов реализации TEE — использование защищенного режима работы процессора — например, ARM TrustZone, который имеется в большинстве существующих на сегодня смартфонов и планшетов. Наряду с TEE сейчас практически в каждом мобильном устройстве есть и защитные механизмы уровня программной платформы [1].

Состав TEE

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

Рис. 1. Стандартные аппаратные защитные механизмы на мобильных устройствах. В состав TEE входят механизмы защищенного хранения и изолированного выполнения. Приложения REE получают доступ к этим механизмам через интерфейс программирования

Механизмы безопасности

Мобильные устройства имеют доверенную вычислительную базу (Trusted Computing Base, TCB), состоящую из аппаратных и микропрограммных компонентов, которые должны быть абсолютно надежными. Целостность мобильной платформы проверяется в рамках процесса защищенной или аутентифицированной загрузки.

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

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

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

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

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

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

TCB устройства обычно имеет уникальный неизменяемый базовый идентификатор — например, серийный номер из контролируемого пространства имен или статистически уникальный код, сгенерированный случайным образом на этапе производства. Устройство можно опознавать по корню доверия и базовому идентификатору; с помощью сертификата, подписанного с использованием корня доверия, с базовым идентификатором можно защищенно связать присвоенный. Примеры идентификаторов устройства — IMEI и идентификаторы канального уровня, например адреса Bluetooth и Wi-Fi. С помощью сертификата устройства, подписанного производителем, можно привязать любой назначенный идентификатор к открытому ключу, пара к которому защищенно хранится в TEE. Подпись, использующая такой ключ, обеспечивает аутентификацию устройства. А с помощью подписанных сообщений с измерениями, собранными при аутентифицированной загрузке, производятся передача и верификация состояния устройства — удаленная аттестация. TCB также может содержать аппаратный генератор случайных чисел.

Аппаратные архитектуры безопасности

Описанные механизмы безопасности реализованы в аппаратных архитектурах ARM TrustZone и Texas Instruments M-Shield. Обычно в мобильных устройствах центральный процессор, небольшое количество постоянной и оперативной памяти, контроллеры периферийных устройств и прерываний, а также порты отладки и трассировки интегрированы на едином чипе, образуя на кристалле единую систему. Элементы, встроенные в процессор, соединены общей шиной. Остальные компоненты мобильного устройства: основная оперативная память, флэш-память, дисплей, антенна и т. д. — реализованы отдельно от главного чипа (рис. 2).

Рис. 2. Пример аппаратной конфигурации мобильного устройства с TrustZone. Управление доступом к аппаратным элементам реализовано с помощью флага состояния, определяющего режим работы процессора: защищенный или штатный. Флаг состояния передается по коммуникационной шине центральной системы на кристалле

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

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

Рис. 3. Архитектура ПО мобильных устройств с поддержкой TrustZone. Доверенные приложения выполняются в TEE, изолированной от REE, в которой работают мобильная ОС и приложения, получающие доступ к сервисам безопасности TEE через драйвер

На рис. 3 приведена программная архитектура TrustZone. Мобильная ОС из REE обращается к сервисам TEE с помощью библиотеки TrustZone через драйвер. В TEE доверенные приложения выполняются в среде доверенной ОС с минимальной функциональностью. Эта ОС предоставляет внутренний интерфейс программирования TEE, которым доверенные приложения могут пользоваться для связи с приложениями REE, а также для вызова функций криптографии и защищенного хранения. Доверенная ОС с помощью средств контроля доступа регламентирует обращения доверенных приложений к ключу устройства. Архитектура TrustZone не определяет, как приложения REE обращаются к сервисам доверенной зоны.

При защищенной загрузке системные программные компоненты из REE, в том числе библиотека TrustZone, могут проверяться на надежность. Даже если злоумышленник скомпрометирует эти программные компоненты в период выполнения, у них нет доступа к секретам, защищенным TEE, и максимум, что они могут сделать, это вызвать недоступность сервисов безопасности TEE.

Другие виды TEE

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

Виртуализация. Защищенно загруженный монитор виртуальных машин (VMM) позволяет одновременно выполнять на одном устройстве несколько «гостевых» ОС. Для обеспечения их изоляции VMM работает в домене с более высоким уровнем защиты, чем операционные системы, и вместо них контролирует работу модуля управления памятью. Технологии наподобие Overshadow позволяют аналогичным образом защищать индивидуальные приложения в потенциально вредоносной гостевой ОС. Решения на основе виртуализации обычно программно обеспечивают целостность и изоляцию, но в остальном архитектурно похожи на аппаратные TEE.

Динамические корни доверия. В ноутбуках и других мобильных устройствах архитектуры x86 среды TEE могут быть реализованы на основе стандарта Dynamic Roots of Trust Measurement организации Trusted Computing Group (TCG). Работая в соответствии со спецификацией связки TPM ( Trusted Platform Module ), процессор с поддержкой DRTM может запускать небольшие доверенные программы изолированно от ОС. Такие TEE изолируются аппаратно, но активны лишь короткие периоды времени.

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

Доступ к TEE

Несмотря на то что TrustZone и M-Shield существуют уже почти десять лет, в сторонних приложениях они используются редко — в основном функции TEE применяются производителями мобильных устройств для своих внутренних нужд, например для привязки к оператору и защищенной загрузки.

Некоторые мобильные платформы предоставляют API для доступа к аппаратным средствам безопасности. Платформа Java ME, широко применявшаяся в мобильных телефонах, реализует JSR 177 — интерфейс для связи с защищенными элементами и вызова функций шифрования. JSR 177 может поддерживаться защищенным элементом мобильного телефона, например SIM-картой. С недавнего времени в Android появился API для работы с аппаратно реализованными функциями шифрования, отвечающий стандарту PKCS #11, а в iOS аналогичные функции предоставляет проприетарный API. Все эти API высокого уровня разрабатывались с расчетом на использование с аппаратными модулями безопасности, защитными токенами и смарткартами. Они позволяют генерировать аппаратно защищенные ключи и выполнять стандартные криптографические операции вроде шифрования и подписывания. Однако, чтобы пользоваться всеми возможностями программирования TEE, нужен API иного типа, предоставляющий средства инсталляции доверенных приложений и загрузки секретов на устройство, авторизации доверенных приложений для доступа к секретам и ключам устройства, а также проверки прав приложений REE на запуск доверенного кода. Ни один из стандартизованных и проприетарных аппаратных API безопасности сегодня не предоставляет таких функций, в связи с чем была создана система On-board Credentials (ObC).

On-board Credentials

Безопасная среда выполнения ObC (рис. 4) была разработана в исследовательском центре Nokia и сегодня реализована на отличающихся своей надежностью смартфонах этого производителя, построенных на базе Windows Phone 8 и Symbian.

Рис. 4. Архитектура On-board Credentials. Интерпретатор ObC выполняет доверенные приложения в TEE, планировщик готовит к запуску доверенные приложения и хранит их данные. Приложения REE обращаются к сервисам ObC через соответствующий API

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

Создавать доверенные приложения для ObC можно на диалекте языка Бейсик или с использованием ассемблера. Виртуальная машина ObC реализована в качестве набора взаимодействующих в TrustZone программных компонентов. В зависимости от аппаратного обеспечения и программной архитектуры TEE эти компоненты могут постоянно находиться в TEE или загружаться в нее по требованию. В некоторых средах они составляют единственную «доверенную ОС» устройства, а в других — компоненты интерпретатора ObC сами по себе являются доверенными приложениями. В последнем случае интерпретатор ObC используется как дополнение к средствам изоляции и управления установкой, имеющимся в доверенной ОС (далее термином «доверенное приложение» обозначается байт-код, работающий на виртуальной машине ObC).

Планировщик ObC, работающий в REE, обеспечивает подготовку к запуску компонентов ObC в TrustZone и хранит в зашифрованном виде состояние активного интерпретируемого приложения. Приложения REE обращаются к системе ObC через соответствующий API (рис. 4).

Планирование

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

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

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

Инсталляция

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

Разработка приложений

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

Для приложений REE в API ObC есть функции инсталляции и запуска доверенных приложений и передачи используемых ими секретов, а также локальной пломбировки данных приложений REE без использования отдельного доверенного приложения.

Примеры приложений

Рассмотрим два приложения, реализованных с использованием системы ObC.

Билеты на общественный транспорт. Приложение для покупки билетов на общественный транспорт предназначено для мобильных телефонов с поддержкой технологии NFC (Near-Field Communication). Для транспорта с турникетами и без них были разработаны отдельные варианты доверенных приложений и соответствующих приложений REE. В первом случае для контроля подлинности билета используется простой протокол запрос-ответ. На транспорте без турникетов пассажирам самим надо указывать начальный и конечный пункты поездки, дотрагиваясь смартфоном до специальных устройств на остановках, но при этом билеты могут время от времени проверять контролеры. При такой схеме возможно мошенничество: например, пассажир может не отчитываться о поездках, во время которых не было проверок. Для борьбы с зайцами было разработано доверенное приложение ObC, реализующее счетчик, привязанный к проверкам подлинности. При проверке билетов и передаче отчетов о поездках процедуры контроля подлинности учитываются в журнале операций сервиса, и тот сопоставляет использование счетчика с типичным на соответствующей транспортной системе временем поездок и проверок. Традиционные криптографические API, основанные на PKCS #11 или TPM, не дают достаточно функций для бестурникетного сценария, а программируемая среда TEE позволила бы без особых усилий реализовать необходимый криптографический механизм. Билетное приложение для транспортных систем без турникетов уже тестировалось в Нью-Йорке.

Аттестация для систем MirrorLink. Другое приложение реализует спецификацию MirrorLink, обеспечивающую интеграцию смартфонов с автомобильными информационно-развлекательными системами. По нормативным требованиям бортовая система автомобиля должна проверять надежность данных, которые она получает от мобильного устройства. В приложении на основе ObC для этого используется протокол аттестации, реализующий функции и структуры данных, определенные стандартом Mobile Trusted Module организации Trusted Computing Group. Подпись, защищенная ключом, назначенным производителем смартфона, служит для бортовой системы гарантией надежности ПО мобильного устройства. Аттестация контента реализована на базе механизмов аттестации устройства и его ПО.

Последний пример иллюстрирует особый вариант использования программируемых TEE. Многие старые стандарты безопасности, от алгоритмов выдачи одноразовых кодов до интерфейсов вроде MTM, первоначально были рассчитаны на использование со специализированными аппаратными токенами или ресурсами. Потребительские устройства с программируемой TEE и достаточным уровнем защищенности позволяют легко задействовать такие интерфейсы. Основанная на ObC реализация MirrorLink прошла сертификацию на защищенность в Car Connectivity Consortium.

Начало стандартизации

Сегодня нет готовых стандартов на интерфейсы доступа приложений REE к сервисам безопасности TEE для установки и использования доверенных приложений. Фактической отправной точкой для разработки подобных стандартов можно считать архитектуру ARM TrustZone. Недавно Национальный институт стандартов и технологий опубликовал черновик требований к аппаратно реализованным средствам безопасности мобильных устройств. В качестве рекомендуемых элементов в NIST перечисляют защищенное хранение, контроль целостности кода, а также механизмы отчетности, инсталляции, политик и измерения компонентов ОС.

В Global Platform Consortium идет подготовка полного комплекта стандартов на интерфейсы TEE, в том числе касающиеся инсталляции и использования доверенных приложений, доступа к функциям безопасности и связи с внешними системами. Клиентский API безопасной среды, доступный в ОС через драйвер, позволяет приложениям REE активировать и запускать доверенные приложения, а внутренний API безопасной среды, в свою очередь, предоcтавляет доверенным приложениям функции TEE: средства резервирования памяти, криптографические алгоритмы и т. д. В GPC пока не подготовили стандарт на процедуры установки приложений и передачи данных в TEE.

Стандарт TPM от TCG описывает интерфейсы сохранения данных в энергонезависимой памяти, создания и использования ключей, а также пломбировки. В опубликованной недавно спецификации TPM 2.0 появилась гибкая модель авторизации доступа к объектам. TPM обычно реализуется в виде отдельного чипа, но в мобильных устройствах вероятнее его реализация в виде доверенного приложения. В TPM нет интерфейсов инсталляции доверенного приложения в TEE, но TPM Mobile — рабочая группа TCG по мобильным устройствам — готовит стандарты на клиентский API, процедуры использования доверенных приложений и, возможно, их инсталляции. Эти спецификации станут дополнением к стандартам Global Platform Consortium.

Перспективы

Проекты стандартов, разрабатываемые Global Platform Consortium и TCG, осуществляются в связи с высокой заинтересованностью индустрии в возможности широкого использования функциональности TEE. Но на сегодня еще нет стандартных API для инсталляции доверенных приложений и выполнения приложений REE. Недавно появился доклад Global Platform Consortium, в котором рекомендуется отходить от модели инсталляции, зависящей от поставщика приложения, к более открытой, ориентированной на потребителя. Но конкретных спецификаций еще нет, и неясно, насколько они будут открытыми. Кроме того, есть вероятность, что не будет учтен ряд важных вопросов. На многих новых мобильных платформах приложения разрабатываются с использованием веб-технологий, и непонятно, как веб-приложениям осуществлять доступ к сервисам TEE. Мобильные устройства имеют несколько интерфейсов, требующих высокой степени защиты, в том числе интерфейсы SIM-карт и NFC-платежей, — смогут ли будущие доверенные приложения пользоваться ими? Если из традиционных супермаркетов приложений REE будут распространяться доверенные приложения, то как давать им разрешение на выполнение в защищенной области пользовательского устройства и как передавать ему соответствующие секретные ключи?

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

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

Источник