Собственно задача такова:
Нужно иметь возможность обновлять прошивки процесора у клиентов самими клиентами. То-есть при исправлении ошибок или внесении новой функциональности нужно выслать прошивку клиенту и он сам должен её залить в кристал. Но, при этом, нужно сделать так, чтобы клиент не смог склонировать устройство и зашивать в него полученую прошивку.
Сталкивался ли кто-то с такими задачами?

Пока-что у меня только общие идеи, поскольку до реализации этой части я пока не добрался. Поэтому эти идеи могут быть и неправильными. Но сами идеи следующие:
1. Написать свой загрузчик с возможностью расшифровки данных. В загрузчике заложен ключ и ID устройства. Соответсвенно клиенту сбрасывается зашыфрованая прошивка. Загрузчик расшифровывает её, получает из неё ID для которого она предназначена, сравнивает и при совпаденни прошивает флеш.
2. Чуть попроще. Часть кода, которая не будет никогда изменяться, прошивается сразу. В этой части зашивается ID и код сравнения. Прошивка не шифруется. Основная программа в какой-то момент передает управление на процедуру сравнения ID, которая в зависимости от результатов сравнения переходит в нужноё место основной программы. Как в таком случае защитить ID в прошивке, чтобы его нелегко было найти?
3. Модификация второго. Во многих местах кода открытой прошивки поставить загрузку данных из закрытой области, и выполнять с ними какие-то операции вычисляя по этим данным и данным открытой области несколько констант, которые используются закрытой частью. Этот набор операций должен изменить константы таким образом, чтобы при правильном ID получить нужные значения. При неверных значениях закрытая часть программы будет неправильно работать.

Ещё такой вопрос - можно ли пошагово проанализировать работу процесора (скажем с помощью JTAG) и посмотреть какие инструкции исполняются на каждом шаге и что находиться в регистрах процесора не зная что прошито в самом процесоре?

Возможно есть варианты получше?

Спасибо

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

Мысли о защите от копирования характерны для начинающих разработчиков.

Так и сделать. Варианты с нешифрованным образом принципиально ничем не проще, только много ненадежнее. У Atmel-а был какой-то AN для AVR AES загрузчика - можете взять шифрование оттуда в качестве образчика. Сам загрузчик там писан левой ногой - лучше и не смотрите в ту сторону, ну а шифровщик/дешифратор я портировал для ARM.

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


zltigo

Спасибо, поищу

Ещё такой вопрос - можно ли пошагово проанализировать работу процесора (скажем с помощью JTAG) и посмотреть какие инструкции исполняются на каждом шаге и что находиться в регистрах процесора не зная что прошито в самом процесоре?

Вот этот пункт непонятен. Прибор то будет обновлять через COM/USB/Ethernet я так понимаю? А доступ к JTAG Вы закроете. Так что никто ничего не проанализирует...

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

Против лома нет приёма... Разве что упрятать контакы жутага под БГА корпус...
Есть ещё вариант: использовать для загрузки дешифратор на ПЛИС с "временной" прошивкой, существующей только при загрузке. Здесь есть простор, чтобы порезвиться...

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

Если программа работает с флеша, а не копируется в память, то по идее SAM-овский security bit должен помочь (вернее помешать такому просмотру).

Сейчас посмотрел, это документ AVR231.
Из выходного формата были выброшены все record type завязанные на прошивку коннкретного чипа
(с этим нормально загрузчик разбирается - ему лучше знать в какой чип попал) и выходной/загружаемый формат вместо сырого бинарника был сделан в "стиле HEX". Теперь все платформеннонезависимо. Загрузчик с дополнительными наворотами в виде аварийного входа по перемычке на JTAGе, поддержки командной строки, вызова штатного загрузчика, загрузки HEX файлов (если защита не активизирована), поддержки легкого декомпрессора и еще всяких мелочей уложился где-то в 7K.

Да, действительно, был не прав. C SAM7 работать раньше не доводилось...

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

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

Эт точно, сам видел как слызывали память чипа на FRAM и при вполне реалистичном бюджете.
А уж чипы на FLASH так вообще скопировать детская задача.

а есть ли процессоры в большими объёмами flash (скажем 1Mb) и sram (от 256 kb) на борту, и с возможностью их закрытия от считывания?

Может это не проще, но...
Можно второй процессор поставить, через который проходит часть информационного потока (шифруется)...
Ведь какие-то функции не будут меняться.
Можно и "свой-чужой" запрос-ответ с хэшированием ID и random.
Раз Вы боитесь, значит устройство недешевое. Тогда, что Вам лишний корпус?

Глупости!!! В противном случае это можно заявить всем производителям

Tanya

Как раз дополнительные корпуса ставить не хочется, в частности и из-за повышения цены.


Так что, как я понимаю, оптимальным будет вариант написать свой прошивальщик с криптозащитой. Поскольку пример имеется, им и займуся, когда руки дойдут. :-)

Сорри за возможный офф. Вопрос как к невольному (а может и нет ) участнику - "сам видел как слызывали ..." - и сколько стоит сейчас клонировать кристалл (типа AVR, ARM(LPC, AT91, STR))? Спрашиваю не как потенциальный заказчик на взлом, а как разработчик, пытающийся понять как оптимизировать схемотехнику/архитектуру устройства для защиты от копирования. Пока просматривается рассмотренный выше вариант с битом защиты от считывания памяти программ в кристалле + несколько таких кристаллов от разных производителей, соединенных в цепочку. в каждом из них криптозащита со своим ключем. от кристаллов требуется только расшифровка данных и передача ее следующему в цепочке - не такая уж и сложная задача для чипов с малой памятью в маленьком корпусе. стоимость каждого чипа - порядка 1.5$. я думаю, что за дополнительные 10$ (то бишь 5-6 чипов) можно получить довольно высокую стойкость к взлому.

Что-то паронаидальное просматривается. И в бездумной чепочке достаточно банально снять протокол программирования последнего и только его "ломать".

Дык можно последний на первый закольцевать и дешифровать в 1000000 кругов!

Никакие цепочки чипов не помогут если чипы общего применения.
Как-то видел проект где вскрывали игровую консоль сделаную в СНГ.
Основной процессор был ARM выполняющий программу из SDRAM
На защите стоял мелкий AVR.
AVR участвовал в раскриптовке содержимого FLASH при загрузке в SDRAM.
Ну что, AVR вскрыли, пропатчили лоадер который он передает в ARM. Этим патченым лоадером слили уже расшифрованную прогу из RAM-а (заметьте, с алгоритмом шифрования даже не разбирались!), а потом ее уже не шифрованную записали обратно во FLASH, а в лоадере убрали шифрацию.
Кстати алгоритм шифрования идентифицировали сразу же, это был RC4. Есть проги в сети которые по дампу программы независимо для какого проца она написана находят и идентифицируют большинство общеизвестных алгоритмов шифрования и сжатия по характерным таблицам. В RC4 правда нет таблиц но зато примитивный легко идентифицируемый алгоритм.
Инвазивное вскрытие AVR обходится менее 5 тыс. $.
Временные затраты на всю работу были менее месяца.
Это еще не применяя микропробинг и анализ трафика на шинах!
Грубый патч как метод не срабатывает только когда дивайс имеет уникальный серийный номер к которому привязывается защита и дивайс должен проходить online проверку как оригинальный.
Тогда приходится серьезно исследовать алгоритмы. Но тут надо помнить, что как не велик был бы общий объем кода программы сами алгоритмы защиты обнаруживаются и локализуются в программе очень быстро даже когда не до конца известна архитектура аппаратной платформы.
Если алгоритмы самопальные то они будут примитивны (иначе у их разработчика крыша съедет при отладке), если алгоритмы стандартны, то хакеры быстро найдут их исходники чтобы воспроизвести их работу в патче.
Отсюда вывод - нельзя делать ставку на сложность и хитроумность софтварной защиты.
Инвазивное вскрытие самый узкий момент во всей технологии.
Тут совет один, чем меньше технологическая норма кристалла тем меньше лабораторий в мире смогут снять защиту в кристалле. Прикидочно на сегодня чтобы цена взлома подскочила до 50 тыс.$ и выше надо чтобы норма кристалла была не больше 0.18 мкм
Либо ставить как часть приложения смарткарты или заказные SoC-и со спецзащитой.

Интересный вопрос - по какому интерфейсу вы запишите прошивку в SAM7S с установленым битом Security ?

Учитывая что апдейтер прошивки внутри девайса будет использовать любой алгоритм однонаправленого шифрования ?

По тому же самому по которому заливается "штатная" прошивка.
Теперь я не понял вопроса. В раскритикованных втором и третьем вариантах прошивка не шифруется. Именно это и позволяет подсунуть любую прошивку. Шифруется она в одобренном первом варианте.

А не проще посмотреть, как это сделали в коммерческом проекте до Вас? Если у вас нет примеров, могу выслать прошивку такого проекта (его уже хакнули)

Если интерфейс для прошивки стандартный, подкручиваем к шнуру прошивальщика провода и в raw пишем прочитанное на комп.. Там будет и расшифрованная прошивка.
Короче, на любую хитрую Ж найдется свой болт. Смысл имеет только аппаратная защита..

Полуофф, но кому-то может и будет интересно. Есть такое семейство, зовется TMS320LF240xA. Там есть Code Security. Пароль 64 бита. Записывается при программировании (под него отведено кусок флеши, 4 слова). После этого при подаче питания процессор стартует разлоченным, но лочится сразу при подключении жтага. В залоченном состоянии доступа к флеши нет. Чтобы перешить проц другой прошивкой, или даже просто стереть флешу - нужно вписать в спец. регистры правильный пароль!!!
Вроде в 28хх серии то же самое, но пароль 128 бит.

Конечно если нужна прошивка клиентом - это не помогает, а вот просто от перепрошивки левыми прошивками - помогает...

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

Вдруг пригодится.
Видел на компьтерах Compaq вроде бы биос прошивался через прошивальщик в виде exe файла, где внутри был имидж запакованный(может и пришитый к конкретному железу).
Видел также промышленный контроллер, в нем прошивку можно было залить через сом порт, стоял там Lattice ispsi 1016, ватчдог 21DY4YB и проц интеловский(плюс флэха на 4мб и памяти пару метров) При вкл девайса проходила иницилизация и запускался лодарь , а потом уже и весь девайс(вкл всю переферию).


Из идей:
Прошивку шифровать, лить через УСБ или ком , в процессе заливки сам заливальщик должен проверить содержимое основного и вторичного контроллера на чек сумму по такому то адресу.
Если к концу заливки прошивальщик узнает что чек разный, последняя часть прошивки меняется и вливается ловушка.
Которая либо тупо вообще портит работу устройства или по случайному алгоритму начитает вводит девайс в ступор.

До кучи влепить на доп.проце (контроллере) проверку чеков в памяти основного по таймеру, если что не так в ступор.

Вот интересный материал по пикам, хотя и не очень то в тему.
http://www.pology.zp.ua/har/usb_module.html

По поводу защиты прошивки AT91SAM7X256 посмотрите атмелевский родной аппнот "Safe and Secure Bootloader Implementation" для SAM'ов.

Существует две причины, благодаря которым можно получить чужую прошивку -
1. Ошибки разработчика программы загрузчика/обновлятеля.
2. Ошибки допущенные при разработке MCU (всем известные)

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

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

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