[AHTOXA 18]

Привет. Задача такая:

 

Есть устройство (для определённости - на STM32, то есть имеется уникальный идентификатор). Есть прикладная программа, работающая с этим устройством. Устройство обменивается с программой данными по последовательному порту.

Конкуренты навострились изготавливать аналогичные устройства. Надо это дело пресечь.

Придётся менять протокол.

Надо сделать так, чтобы программа работала только с устройствами из белого списка (список, например, в интернете, на сервере). Кроме того, надо как-то шифровать обмен.

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

 

Какие ещё есть варианты? Кто решал подобные задачи?

 

[iiv 29]

Какие ещё есть варианты? Кто решал подобные задачи?

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

 

Иначе - все равно будут повторять и бороться с этим будет бессмысленно или себе дороже.

 

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

[sigmaN 0]

Что-то меня очень пугали по поводу использования шифрования. Сертификации и чего-то там еще......

[iosifk 3]

Какие ещё есть варианты? Кто решал подобные задачи?

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

 

[alexvu 5]

Программа на ПК тут слабое звено, ее всегда можно взломать, вопрос только цены.

Задача в общем виде не решается, так что ищите частные методы, связанные со

спецификой применения Вашего устройства.

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

[AHTOXA 18]

Программа на ПК тут слабое звено, ее всегда можно взломать, вопрос только цены.

Там тоже своя защита, но сейчас речь не о ней.

 

В общем, пока вырисовывается такая система:

 

* Обмен с устройством шифруется закрытым ключом;

* Перед началом передачи данных ПК запрашивает уникальный номер микроконтроллера (UID) и проверяет его по списку разрешённых (с сервера).

 

При такой системе:

1. Если прошивку просто скопируют - устройство не будет работать, потому, что не совпадёт номер процессора;

2. Если прошивку дизассемблируют и сделают выдачу валидного UID, то этот UID можно забанить.

 

Пока не вижу особых минусов в этой системе.

 

 

[syoma 1]

Конкуренты навострились изготавливать аналогичные устройства.

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

Программа может залазить в интернет?

[adnega 11]

Какие ещё есть варианты? Кто решал подобные задачи?

А у вас прошивка в свободном доступе находится что ли?

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

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

[Raven 11]

2. Если прошивку дизассемблируют и сделают выдачу валидного UID, то этот UID можно забанить.

На каком, собственно, основании вы будете банить? Факт умысла и нарушения надо еще юридически обосновать (и доказать). Иначе - пользователь иск подаст.

[migrator 0]

* Перед началом передачи данных ПК запрашивает уникальный номер микроконтроллера (UID) и проверяет его по списку разрешённых (с сервера).

 

1. Если прошивку просто скопируют - устройство не будет работать, потому, что не совпадёт номер процессора;

2. Если прошивку дизассемблируют и сделают выдачу валидного UID, то этот UID можно забанить.

 

Пока не вижу особых минусов в этой системе.

 

Дизассемблируют программу на ПК... будут выдавать либо валидный UID для проверки на сервере, либо ответ сервера в корзину - т.е. все всегда ОК.

Прошивку тоже дизассемблируют и место проверки номера процессора слегка подпатчат (минутное дело).

Всё это СМИШНО!

[AlexandrY 3]

Какие ещё есть варианты? Кто решал подобные задачи?

Как-то ломал я такой хитроумный дивайс.

Смысл в том что есть фирмы предлагающие специальный SDK и продающие суперзащищенные чипы работающие с этим SDK.

В свою программу вы интегрируете их SDK , а в свой дивайс ставите их чип.

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

Чип шлет какую-то псевдослучайную ахинею. Сломать SDK за разумные деньги никто не взялся.

И что я сделал, я взял и вычитал из чипа пару мегабайт этой ахинеи. После чего зашил эти мегабайты в SPI Flash.

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

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

А прошивка из STM32 читается элементарно.

 

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

Я бы например предложил i.MX RT или Kinetis K81

 

[AHTOXA 18]

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

Программа может залазить в интернет?

Да. По всем трём пунктам.

 

 

А у вас прошивка в свободном доступе находится что ли?

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

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

Прошивка утекла, по всей видимости. Потому и пишу - надо менять протокол.

 

На каком, собственно, основании вы будете банить? Факт умысла и нарушения надо еще юридически обосновать (и доказать). Иначе - пользователь иск подаст.

Пользователь, купивший оборудование у нас, получит новую плату (с новым UID). Пользователь, купивший оборудование у конкурентов - пусть подаёт иск на них:)

 

Я бы например предложил i.MX RT или Kinetis K81

Кто бы сомневался...

[VCucumber 0]

А прошивка из STM32 читается элементарно

пруфы ?

Прошивка утекла, по всей видимости. Потому и пишу - надо менять протокол.

прошивка не имеет права утекать

а если она обновляема, то нужен свой бутлоадер с поддержкой загрузки шифрованной прошивки

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

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

отказаться от защиты от копирования

если есть какой-то экран, то выводить на экране линк на ваш сайт и пусть все желающие клонируют

[jcxz 245]

1. Если прошивку просто скопируют - устройство не будет работать, потому, что не совпадёт номер процессора

Может просто защитить прошивку от чтения чем городить проблемы на пустом месте? :laughing:

И если прошивку скопировали, то точно также скопируют и номер процессора.

 

Прошивка утекла, по всей видимости. Потому и пишу - надо менять протокол.

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

а то и с исходниками....

 

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

Например: выдаете прошивку версии X на участок сборки-прошивки некоему монтажнику-наладчику - компилите для него свой образ с уникальным маркером и датой/временем (не видимыми в hex). Если вдруг на рынке появятся клоны, то можно будет определить кто именно слил. Каждый монтажник, выходя на смену должен иметь свою копию прошивки и не должен передавать её другому.

Тому, кто имеет доступ к исходникам это не помешает конечно, но тут уж другие меры защиты нужны.

[x736C 0]

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

 

Подобная система реализована в кабелях к айфонам. Обмен между приложением (iTunes) и кабелем, а через него с телефоном, зашифрован. В кабеле чип с ключами. Эппл банит кабели с левыми китайскими чипами. Так было раньше. Сейчас вроде бы китайцы научились делать хорошо.

 

2. Если прошивку дизассемблируют и сделают выдачу валидного UID, то этот UID можно забанить.

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

 

Белый список на сервере -- тоже уязвимая вещь от разных атак.

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

 

Нужно встроить в устройство GPRS-модем с сим-картой, и сделать аутентификацию, условно, по СМС