Jak skutecznie zabezpieczyć firmware uC i PLD przed nieautoryzowaną produkcją?

To może być też do obejścia, ktoś weźmie analizator cyfrowy, posiedzi
i rozgryzie protokół...
I jeszcze inne pomysly z zastosowaniem programatora:

To zakodowac sygnal cyfrowy poprzez modulacje analogowa .

Tak - klient wgrywa tylko loader, podłącza do urządzenia antenę,
urządzenie zgłasza przez radio żądanie pobrania programu a my
wysyłamy. Oczywiście w obie strony używamy DSSS
mozna i tak.

Piszę oprogramowanie na uC i projektuję PLD. Generalnie wykazuje
ograniczony poziom zaufania do klientów, ...

I jeszcze inne pomysly z zastosowaniem programatora:
1. Nasze binarne Firmware mozna latwo zaszyfrowac i zahardkodowac w
Software do programatora. Dodatkowo mozna jeszcze jakies kroki
odszyfrowania zostawic programatorowi. Wowczas zmuszamy klienta do
zastosowania naszego softu z naszym programatorem.
2. Binarke szyfrujemy sobie znanym szyfrem ktory potrafi odszyfrowac
tylko nasz Software do programatora.

Witam



Piszę oprogramowanie na uC i projektuję PLD. Generalnie wykazuje

ograniczony poziom zaufania do klientów, choć tego dla którego

wykonuje zlecenie akurat znam i to w sensie pozytywnym - co nie zmienia

mojego podejścia.



Sytuacja wygląda tak, część moich zysków, będzie to prowizja za sprzedaż

i w związku z tym chcę zachować kontrolę nad Tym ile sztuk urządzenia
zostało

wyprodukowanych. Z pewnych względów sam nie będę mógł wrzucać
oprogramowania

do uC + pliku konfiguracyjnego do PLD - problemem będzie dzieląca
odległość.

Oczywiście są przesyłki itd. Ale to raczej nie wchodzi w grę, ze względu
na wynikające

opóźnienia itd. W związku z powyższym, zbiory wynikowe udostępnię
klientowi.



Szukam sposobu zabezpieczenia mojego projektu przed niekontrolowaną

produkcją. Jednym z rozwiązań jest kość "serial number", wtedy wymagany

będzie plik dedykowany pod konkretną sztukę. Oczywiście jest to jakieś
rozwiązanie,

ale do chyba stosunkowo łatwego obejścia.



Można pewnie to załatwić przez Bootloadera, programując BL kości i
pozostawienie

ich klientowi , a następnie dosyłanie w miarę potrzeb kolejne pliki
dedykowane pod

kość z BL z zaszytym kluczem. Problem tylko w tym że uC będzie w obudowie

TQFP i zaprogramowanie go po za systemem, będzie raczej trudne.



Może z własnych doświadczeń możecie podsunąć jakieś rozwiązania

pozwalające w miarę skutecznie się zabezpieczyć w takiej sytuacji?

Pozdrawiam
Darek

Obudowa to zaden problem, do tego masz podstawki testowe, programowanie
to chwilka. Problemem jest to, ze majac kod binarny mozna prosto kazde
zabezpieczenie z niego wywalic.

A może bootloader z wszytym kluczem zabezpieczającym. Przy programowaniu
procesor dekoduje w locie zawartość przesyłaną przez klienta.

no to jest najlepsze rozwiązanie o którym zresztą pisałem w głównym
poście, jednak ma ten minus, że bootloadera musiał bym wrzucić do
kości która nie jest przylutowana, a to już problem, obudowa TQFP64.

Te metody mają jedną słabość:
Do kontrolera dane muszą iść jawne, więc o ile można dostać się fizyczne
pomiędzy programator a programowany układ to użytkownik może podsłuchać
transmisję między programatorem a programowanym układem i w ten sposób
uzyska jawną zawartość pliku programującego. Potem wystarczy programować
układu innym standardowym programatorem.

Oprócz słabości ( główna wada ) metoda jest droga bo trzeba zaprojektować ten

Obudowa to zaden problem, do tego masz podstawki testowe,
programowanie to chwilka. Problemem jest to, ze majac kod binarny
mozna prosto kazde zabezpieczenie z niego wywalic.

Sprawa dotyczy szyfrowania kluczem symetrycznym _całego_ pliku z kodem.