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

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

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

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

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

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

• идентификатор устройства (International Mobile Equipment Identifier, IMEI) должен быть защищен от «манипуляций и изменений любыми средствами, включая механические, электрические и программные» [2];
• согласно нормативным требованиям, необходимо защищенно хранить радиочастотные настройки, откалиброванные на этапе производства;
• существуют бизнес-требования наподобие привязки к оператору (когда мобильные телефоны со скидкой продаются абоненту только вместе с контрактом и не могут использоваться в других сетях) и наличия защищенных реализаций систем управления цифровыми правами;
• имеются строгие требования к надежности — никаких «синих экранов смерти».

Чтобы обеспечить выполнение этих требований, производители мобильных устройств, поставщики микросхем и разработчики платформ изначально создавали и внедряли защитные механизмы аппаратного и платформного уровня, и важнейшими из них стали аппаратные 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, первые опыты такого рода уже были.

Литература

1. K. Kostiainen et al. Old, New, Borrowed, Blue — A Perspective on the Evolution of Mobile Platform Security Architectures, Proc. 1st ACM Conf. Data and Application Security and Privacy(CODASPY), 2011, P. 13–24.
2. 3GPP TS 42.009 Security Aspects, 3GPP, Mar. 2001. URL: http//www.3gpp.org/ftp/Specs/html-info/42009.htm.
3. J. Srage and J. Azema. M-Shield Mobile Security Technology, white paper, Texas Instruments, 2005. URL: http://focus.ti.com/pdfs/wtbu/ti_mshield_whitepaper.pdf.

Ян-Эрик Экберг (jan-erik.ekberg@trustonic.com) — директор передовых разработок, компания Trustonic; Кари Костяйнен (kari.kostiainen@inf.ethz.ch) — научный сотрудник отдела системной безопасности, Швейцарская высшая техническая школа Цюриха; Н. Асокан (asokan@acm.org) — профессор, Университет Аалто (Финляндия).