Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: механизмы защиты кода в процессорах, надежность? софт (API)?
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы
yes
вопрос такой :
хотелось бы (как и многим) иметь следующие фичи :

пишем софт (загружаемое и пересылаемое по открытому каналу (www/email) приложение), которое исполняется конкретной железкой и ничем другим

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

--------------------

при этом желательно предоставить возможность исполнения на этой железке (совместно с секретным) приложения "третих лиц" - всяких ОЕМ-щиков и т.п.

================

для этого могут быть использованы фичи реализованые в новых процах

-----------------------------

вопрос : встречал ли кто-нибудь описания этих технологий, порты для Линукса/eCos/WinCE или др операционок? описания API для взаимодействия и т.п.?
вообще интересен весь процесс запуска секъюрного кода

также интересен анализ криптоустойчивости - то есть какие методы хака могут дать успех при различных вариантах использования этих фич?

-----------------------------

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

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


================

вроде бы это кардинальное решение проблемы клонирования безфлашевых процев, о которой столько говорили большевики smile.gif
vshemm
Цитата(yes @ Mar 13 2008, 18:56) *
пишем софт (загружаемое и пересылаемое по открытому каналу (www/email) приложение), которое исполняется конкретной железкой и ничем другим

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

Это как? Очень даже доступно будет. Есть, конечно, универсальный вариант... но он очень затратным будет...

Цитата
при этом желательно предоставить возможность исполнения на этой железке (совместно с секретным) приложения "третих лиц" - всяких ОЕМ-щиков и т.п.

И почему эти приложения "третьих" лиц не смогут сдампить секретное ПО? А они захотят это сделать smile.gif
Цитата
вообще интересен весь процесс запуска секъюрного кода

также интересен анализ криптоустойчивости - то есть какие методы хака могут дать успех при различных вариантах использования этих фич?

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

Вообще, основной постулат защиты звучит примерно так: выгоднее купить оригинальное ПО, чем ломать или писАть свое. И тут вступают в игру множество факторов, например, жизненный цикл ПО, его стоимость, распространенность девайса, частота обновлений софта и пр. Задачу нужно решать в комплексе, поэтому в каждом конкретном случае иструменты защиты будут свои.
AlexandrY
Нет у iMX31 подробного описания железа.
Есть только отрывки введений в каждый IP блок, но подробностей ни для одного не раскрываются.

Еще хуже то, что они толком не описывают собственно и угрозы от которых эти фичи были созданы.

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

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

Ну и все!

А дальше идут концепции придумываемые самими OEM-щиками: что подписывать, а что нет, сколько сертификатов иметь и на сколько глубокой иерархии. Какие памяти контролировать на предмет модификации в real-time и т.д. Все защитные фишки меют ограничения по объему контролируемой памяти и по времени выполнения. Поэтому и от модификации и на аутентичность могут проверяться только небольшие области памяти. На этом хакеры и играют и довольно успешно.

Тут надо помнить что большие кристаллы не могут применть ухищрения применяемые в смарткартах для физической защиты чипа. Приходится играть на скрытии важных блоков в топологии. Это не надежная игра поскольку регулярные структуры типа ROM, RAM угадываются легко.
Производители и сами понимают, поэтому их решения это решения препятствующие только технологически дешевому программному взлому.
Именно так и ставят задачу испытательным хакерским конторам когда просят проверить взламываемость решений, если найдено только хардварное решение то бонус не платят.
Но как видно на примере iPhone программные решения всегда находятся. ;-)



Цитата(yes @ Mar 13 2008, 20:26) *
вопрос такой :
хотелось бы (как и многим) иметь следующие фичи :

пишем софт (загружаемое и пересылаемое по открытому каналу (www/email) приложение), которое исполняется конкретной железкой и ничем другим

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

--------------------

при этом желательно предоставить возможность исполнения на этой железке (совместно с секретным) приложения "третих лиц" - всяких ОЕМ-щиков и т.п.

================

для этого могут быть использованы фичи реализованые в новых процах

-----------------------------

вопрос : встречал ли кто-нибудь описания этих технологий, порты для Линукса/eCos/WinCE или др операционок? описания API для взаимодействия и т.п.?
вообще интересен весь процесс запуска секъюрного кода

также интересен анализ криптоустойчивости - то есть какие методы хака могут дать успех при различных вариантах использования этих фич?

-----------------------------

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

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

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

одно из применений этой секъюрности это DRM или как оно там называется - "интелектуальные права"

то есть чтобы конкретную пестню или книжку мог использовать только конкретный прибор

собственно я полагаю, что разницы нет - код защищаем или данные

да, информации мало, но то что дает фрискейл на порядки больше, чем можно найти у ТИ или АРМа

если будет защищен дебаг (например iMX31 подразумевает 4 режима, в самом сильном пережигается безвозвратно фузами), и пользовательская программма будет работать в пользовательском режиме, а секъюрная программа в superuser (при этом включен ММУ и секъюрная аппаратура доступна только суперьюзеру) : то метода для несекъюрного приложения отдебажить секъюрное нет

уязвимым местом кажется BOOT - но при использовании несимметричной криптографии и внутренней ПЗУ (ОТР + CHIP ID) можно сделать защищенным этот процесс (даже если предположить, что пользователь(хакер) может запустить суперпользовательский режим со своим кодом - знание открытой половинки ключа не даст ему возможность сгенерить "правильный" образ загрузки в секъюрном режиме)

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

по поводу возможности найти ключ в чипе - есть имплементации ОТР в виде пробиваемых затворов (kilopass emem еще какие-то производители). сканирование электронным микроскопом ничего не даст - там нет зарядов. пробой тоже увидить нельзя. шины от такой памяти выводятся во второй металл - то есть подцепить к ним щупы без разрушения чипа невозможно. (да и с подключением к первому металлу в 90-45нм сомнительно)
даже разрушив чип и считав публичный ключ 1) это ничего не даст - несиметричная криптография, 2) в другом чипе - другой ключ

RAM для хранения криптоинформации аппаратно стирается при попытке взлома (срабатывании индикатора защиты - видимо там участвуют таймеры и контроллер прерывания)

=================

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

TrustZone выглядет более привлекательно, но так как по нему совсем мало инфы - то чисто домыслы
проблемы сделать параллельный режим (в доке они называют world, чтобы не путать с суперюзером) нет концептуальной проблемы - просто суперъюзер получается ограниченым - несекъюрный суперюзер не имеет доступа к секретной аппаратуре и ММУшно засекъюреной памяти

------------------------------

как это можно успешно атаковать - пока непонятно.

=================

а есть ли какие-то хакерские конторы, которые имеют официальное представительство (и способны проанализировать криптозащиту, включая и аппаратную (чип))?
blackfin
Цитата(yes @ Mar 13 2008, 18:56) *
вопрос : встречал ли кто-нибудь описания этих технологий, ..
...
вообще интересен весь процесс запуска секъюрного кода..

Lockbox Secure Technology.
yes
Цитата(blackfin @ Mar 14 2008, 15:14) *


спасибо! видел, но забыл

только тут совсем просто : один процессор - одно приложение
возможно с CPLB и юзер/суперюзер что-то замутить

но в любом случае, это самый простой подход (который как элемент есть в более "продвинутых")

------------------

если интересно - подключил АРМовское описание, вроде понятно что и зачем они засекретили в таймерах и IC
AlexandrY
...Мда, закрутили.

Правильно ли я понял, что они обмен на внешней шине собираются шифровать?.
Тут главное до фузов добраться. Инсайдеры подкинут описание API на защищенный режим.
Дальше анализом профиля энергопотребления и повторным программированием фузов можно и их содержимое попробывать вычислить. Либо повышением напряжения выжечь определенные блоки на чипе чтоб не мешали. И т.д... Придется подумать biggrin.gif


Цитата(yes @ Mar 13 2008, 20:26) *
вопрос такой :
хотелось бы (как и многим) иметь следующие фичи :

пишем софт (загружаемое и пересылаемое по открытому каналу (www/email) приложение), которое исполняется конкретной железкой и ничем другим

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

--------------------

при этом желательно предоставить возможность исполнения на этой железке (совместно с секретным) приложения "третих лиц" - всяких ОЕМ-щиков и т.п.

================

для этого могут быть использованы фичи реализованые в новых процах

-----------------------------

вопрос : встречал ли кто-нибудь описания этих технологий, порты для Линукса/eCos/WinCE или др операционок? описания API для взаимодействия и т.п.?
вообще интересен весь процесс запуска секъюрного кода

также интересен анализ криптоустойчивости - то есть какие методы хака могут дать успех при различных вариантах использования этих фич?

-----------------------------

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

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

вроде бы это кардинальное решение проблемы клонирования безфлашевых процев, о которой столько говорили большевики smile.gif
yes
Цитата(AlexandrY @ Mar 15 2008, 16:53) *
...Мда, закрутили.

Правильно ли я понял, что они обмен на внешней шине собираются шифровать?.
Тут главное до фузов добраться. Инсайдеры подкинут описание API на защищенный режим.
Дальше анализом профиля энергопотребления и повторным программированием фузов можно и их содержимое попробывать вычислить. Либо повышением напряжения выжечь определенные блоки на чипе чтоб не мешали. И т.д... Придется подумать biggrin.gif


не только по шине, но и можно выложить на сайт или перслать можно

единственно, что во всех коммерческих аппаратно встроен только DES/AES - симметричные, менее устойчивые - но несиметричным можно только сессонный ключ шифровать - так вроде ssh и всякие банкоматы работают...

фузы - это не бязательно спец ячейки - а возможно битовые поля в ОТР памяти (так вроде Аналоги и сделали, хотя тоже темнят - но у меня и сразу подозрение, что отдебажив их ROM можно наверно много интересного smile.gif узнать)
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.