[AlexandrY 3]

2. с каждым id на сервере связана маленькая таблица чисел.

Так вроде серверы ломают даже проще чем embedded дивайсы.

Что за сервер вы предлагаете? На собственном хостинге? На виртуальном?

Если покупаете виртуальный хостинг, то вас конкуренты легко разоряют вялотекущей DDoS атакой, поскольку хостер берет за трафик к сервису.

Люди делают VPN только бы не светить свои внешние сервера.

Но тогда дивайсы должны иметь стек протоколов VPN, т.е. серьезно дорожают.

[controller_m30 1]

А каким образом? Не присылать же исполнимый код...

Уже писал выше. Ещё раз кратко.

Сервер (или любая другая проверяющая программа) запрашивает у МК подсчёт хэша своей прошивки не всей сразу, а случайно выбранными участками: например, с адреса 0х0800 до 0х4000, потом с 0х1000 до 0х7000, и ещё раз с 0х3000 до 0х9000. Трёх раз вполне достаточно.

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

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

 

На защиту всей системы (МК + ПК клиента + ПК сервера) это способ не претендует. Вопрос, как я понимаю, пока что только о защите от поддельных устройств на МК.

[AlexandrY 3]

Уже писал выше. Ещё раз кратко.

Не мучайтесь изобретением велосипедов.

Если ваш микроконтроллер не поддерживает криптографический движок как это умеет Kinetis K81, то покупаете и ставите MAXQ1061EUD.

Всего то пару баксов, и ваш старый добрый mbed TLS становится абсолютно неломаемым и получаете в добавок собственный цент сертификации.

Т.е. не надо платить за получение SSL сертификатов и не нужно держать базу данных с уникальными номерами устройств.

Все примитивно и просто.

 

[jcxz 214]

Правильно ответить на такие запросы может только оригинальная прошивка, в которой не было изменений.

Ответить на такие запросы может не только оригинальная прошивка, но и изменённая прошивка, в которую включен образ оригинальной.

[controller_m30 1]

Ответить на такие запросы может не только оригинальная прошивка, но и изменённая прошивка, в которую включен образ оригинальной.

А как это сделать, если там нет места?

Я заполню неиспользуемую область прошивки случайными данными (например кусок MP3 файла), и хакеру придётся беречь каждый байт в неприкосновенности, т.к. он нужен для подсчёта хэша, который происходит каждый раз по заранее неизвестному диапазону.

 

[jcxz 214]

А как это сделать, если там нет места?

Я заполню неиспользуемую область прошивки случайными данными (например кусок MP3 файла), и хакеру придётся беречь каждый байт в неприкосновенности, т.к. он нужен для подсчёта хэша, который происходит каждый раз по заранее неизвестному диапазону.

Ну мы же говорим о прошивке для клонированного устройства?

Никто не мешает клонерам впаять МК с бОльшим объёмом флешь, впаять МК с EEPROM (или и её тоже заполните? ;), добавить к клону небольшую внешнюю EEPROM (на I2C или куда угодно).

А модифицировать ему достаточно небольшую область...

Если злоумышленники уже считали ранее прошивку то никакие защиты тут не помогут от получения ими обновления (новой версии) от этого сервера.

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

[controller_m30 1]

Никто не мешает клонерам впаять МК с бОльшим объёмом флешь, впаять МК с EEPROM (или и её тоже заполните? ;), добавить к клону небольшую внешнюю EEPROM (на I2C или куда угодно).

А модифицировать ему достаточно небольшую область...

Внешняя EEPROM требует большего времени для чтения, чем доступ к внутренней памяти программ - и это будет видно по времени отклика, особенно после нескольких подсчётов хэша. Так что это не поможет.

Внутренней EEPROM у STM32 вроде бы нет.

 

А вот по поводу МК с бОльшим объемом флэш... вот тут у клонеров есть шанс. Согласен. Но только если я сам не выбрал версию МК с максимальным объёмом памяти изначально :rolleyes:

[jcxz 214]

Внешняя EEPROM требует большего времени для чтения, чем доступ к внутренней памяти программ - и это будет видно по времени отклика, особенно после нескольких подсчётов хэша. Так что это не поможет.

У вас сервер - в интернете, задержка распространения до него может быть приличной. Десятки мс - запросто. К тому же - непредсказуемая. По I2C - много меньше, а уж если использовать SPI-флешь на МГц - будете мкс контролировать?

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

[Plain 184]

Какие ещё есть варианты?

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

[controller_m30 1]

У вас сервер - в интернете, задержка распространения до него может быть приличной. Десятки мс - запросто. К тому же - непредсказуемая. По I2C - много меньше, а уж если использовать SPI-флешь на МГц - будете мкс контролировать?

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

Кроме того, для сравнения есть и просто обмен рабочими данными между МК и ПК. И как это будет выглядеть, что простые данные идут с одной задержкой (иногда есть задержка, иногда нету, днём задержка больше, ночью меньше, и т.д.), а идентификация всегда тормозит так, как будто для связи используется телефонный модем 30-летней давности?

 

SPI-флеш даже при потоковом чтении, медленнее доступа к памяти процессора минимум в десять раз (для самых медленных STM).

Поставить задачу снять хэш памяти с шагом 512 байт (размер буфера флешки) - и SPI-флеш "засветится" как миленькая, т.к. только на пересылку из памяти в буфер чтения, у неё уходит от 100 мкс и более.

Получится, что один байт будет читаться за 100 мкс каждый. Или со скоростью 10кб/сек, и это в лучшем случае. Тут сравнивать со временем доступа к настоящей памяти процессора (от 10мБ/сек и выше) даже как-то неудобно. Т.е. при снятии хэша памяти с пропуском 512 байт, разница между доступом к настоящей памяти, и той что в SPI-флеш - будет больше в 1000 раз.

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

Изменено 20 августа, 2017 пользователем controller_m30

[ViKo 1]

При обновлении программы МК использовать для декодирования новой прошивки старую. В простейшем случае - XOR. Лучше брать не попорядку, чтобы больше "хаоса" использовать.

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

[VCO 0]

Как вариант: в каждом устройствеустановить крошечную EEPROM с персональным кодом. Код персионализировать софтом.

[novikovfb 17]

Как вариант: в каждом устройствеустановить крошечную EEPROM с персональным кодом. Код персионализировать софтом.

что мешает скопировать эту EEPROM вместе с основной прошивкой?

[ViKo 1]

Уникальный код можно и без доп. памяти забить во флэш.

 

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

[gerber 8]

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

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