Как защитить от клонирования оставив возможность обновить прошивки, AT91SAM7X256 Опции

[OlegHmt]

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

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

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

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

Спасибо

[etoja]

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

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

[zltigo]

1. Написать свой загрузчик с возможностью расшифровки данных.

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

[OlegHmt]

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

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

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


zltigo

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

[АДИКМ]

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

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

[Stanislav]

1. Написать свой загрузчик с возможностью расшифровки данных. В загрузчике заложен ключ и ID устройства...

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

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

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

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

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

[Edmundo]

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

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

[zltigo]

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

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

[Stanislav]

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

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

[Сергей Борщ]

2. Чуть попроще.
3. Модификация второго.
Возможно есть варианты получше?

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

[dch]

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

[AlexandrY]

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

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

[Andrei....]

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

[Tanya]

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

Спасибо

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

Сообщение отредактировал Tanya - Dec 21 2006, 11:03

[SergeyDDD]

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

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