logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

jak zabezpieczyc uC, ale dac mozliwosc aktualizacji jego zaw

monty_p 31 Paź 2008 00:14 3813 34
  • #1 5685549
    monty_p
    Poziom 18  
    Witam!

    W tytule niewiele moglem napisać, więc tu rozwinę :)

    Jak skutecznie zabezpieczyć przed odczytem zawartość mikroprocesora, ale dać możliwość aktualizacji jego zawartości osobom, przed którymi chcę chronić zawartość procka ??

    ...zakręcone :D

    Chodzi o to, że chcę dać komuś gotowe urządzenie, z zaprogramowanym procesorem, dać mu możliwość wgrywania aktualnych wersji zawartości procesora, ale NIE DAĆ MU MOŻLIWOŚCI skopiowania sobie urządzenia.

    ...bo jak dam mu soft do zaktualizowania, to ma wsad do procka. Robi sobie urządzenie i już nie bierze ode mnie :(

    Mam nadzieję że udało mi się przedstawić problem :) Czasem dziwnie piszę :P

    ...gdyby jednak temat nie był jasny, wytłumaczę lepiej.

    Bardzo proszę o pomoc w tym temacie


    Pozdrawiam

    Monty
  • #2 5685584
    dawid512
    Poziom 32  
    Czyli zabezpieczenie przed odczytem ;]
    Zobacz do PDF-a procka do działu memory programming odnośnie LPM.
  • #3 5685592
    monty_p
    Poziom 18  
    zabezpieczenie przed odczytem, TAK. ...ale ameryki nie odkryłeś.

    Dajęe komuś tak zabezpieczony procek (w uruchomionym urządzeniu) i go nie odczyta. SUPER.
    Po jakimś czasie dorzucam mu AKTUALIZACJE do programu.

    Musi to wgrać więc ma zawartość jak na dłoni. kopiuje płytkę, wgrywa sobie ten wsad i ma kopie urządzenia.

    W tej sytuacji na nic zabezpieczenia.

    Dodano po 1 [minuty]:

    ...chyba że można tak ustawić zabezpieczenie procka i tak zmodyfikować program, że nawet pełny wsad nie przyda się na nic, jeżeli procek nie jest odpowiednio ustawiony

    ??
  • #4 5685608
    dawid512
    Poziom 32  
    Najpierw chcesz żeby nie można było odczytać z procka nic, a za chwile dajesz sam wsad do niego....Chcesz żeby procek jedne wsady akceptował a drugie nie? Dobre sobie...
  • Pomocny post
    #5 5685667
    mirekk36
    Poziom 42  
    monty_p napisał:

    Mam nadzieję że udało mi się przedstawić problem :) Czasem dziwnie piszę :P
    ...gdyby jednak temat nie był jasny, wytłumaczę lepiej.
    Bardzo proszę o pomoc w tym temacie


    w odpowiedzi do kolegi dawid512
    monty_p napisał:

    zabezpieczenie przed odczytem, TAK. ...ale ameryki nie odkryłeś.

    gdybym zachowywał się tu na forum tak jak ty w stosunku do innych i to tych, którzy próbują jakoś ci pomóc, nawiązać dyskusję, wyjaśnić cokolwiek..... To żeby nie użyć jakichś wulgaryzmów, powiedziałbym tylko , że zachowujesz się mało grzecznie i kulturalnie. Najpierw jak widać powyżej sam stwierdzasz, że dziwnie piszesz a potem dowalasz komuś o ameryce... Jak dalej będziesz zachowywał się jak taka "mała mądrala" to rzadko kto tutaj ci w czymkolwiek pomoże.....

    licząc jednak, że zmienisz nieco swoje zachowanie, podpowiem ci jak można rozwiązać twój problem, jest to jeden z kilku sposobów (sam swego czasu miałem podobną potrzebę)

    .... możesz np napisać sobie własny "boot loader", który wczytuje zawszyfrowany wsad do procka. Oczywiście "boot loader" w trakcie wczytywania dokonuje od razu odszyfrowania i programuje już poprawną zawartością procesor. Do tego wszystkiego ustawiasz lockbity tak aby nie można było odczytać procka. W efekcie nawet jak ktoś dostanie taki zaszyfrowany wsad to nic z nim nie zrobi - bo na "żywca" nie wgra go sobie do nowego pocesora a jeśli nawet wgra na siłę to jak można przypuszczać procek niezbyt chętnie będzie chciał działać ;)
  • #6 5685752
    rmajda
    Poziom 20  
    Ja robiłem podobnie jak kolega mirekk36, tyle że bootloader ładuje firmware z karty SD. A na karcie SD mam zaszyfrowany firmware.
  • Pomocny post
    #7 5685809
    Samuraj
    Poziom 35  
    Jak pisali koledzy powyżej bez bootloadera się nie obejdzie. Na początek wystarczy proste odwrócenie bitów. Wszystko będzie na tyle bezpieczne na ile wymyślisz skomplikowany sposób kodowania zawartości firmware.
    Dodatkowo zyskujesz łatwy sposób aktualizacji oprogramowania np poprzez RS'a, USB czy jak napisał rmajda poprzez kartę SD. To wszystko zależy od tego jak napiszesz bootloader.
  • #8 5686302
    monty_p
    Poziom 18  
    mirekk36 napisał:
    monty_p napisał:

    Mam nadzieję że udało mi się przedstawić problem :) Czasem dziwnie piszę :P
    ...gdyby jednak temat nie był jasny, wytłumaczę lepiej.
    Bardzo proszę o pomoc w tym temacie


    w odpowiedzi do kolegi dawid512
    monty_p napisał:

    zabezpieczenie przed odczytem, TAK. ...ale ameryki nie odkryłeś.

    gdybym zachowywał się tu na forum tak jak ty w stosunku do innych i to tych, którzy próbują jakoś ci pomóc, nawiązać dyskusję, wyjaśnić cokolwiek.....


    Ja myślę, ze kolega Dawid raczej nie doczytał. Można to zauważyć po jego drugim poście:
    dawid512 napisał:

    Najpierw chcesz żeby nie można było odczytać z procka nic, a za chwile dajesz sam wsad do niego....Chcesz żeby procek jedne wsady akceptował a drugie nie? Dobre sobie...

    ...już mu się to kiedyś wcześniej zdarzało :),ale nie ważne. SORRY za tą Amerykę. Fakt,już dawno została odkryta ;)


    Co do drugiej części Twojej wypowiedzi:
    mirekk36 napisał:

    .... możesz np napisać sobie własny "boot loader", który wczytuje zawszyfrowany wsad do procka. Oczywiście "boot loader" w trakcie wczytywania dokonuje od razu odszyfrowania i programuje już poprawną zawartością procesor. Do tego wszystkiego ustawiasz lockbity tak aby nie można było odczytać procka. W efekcie nawet jak ktoś dostanie taki zaszyfrowany wsad to nic z nim nie zrobi - bo na "żywca" nie wgra go sobie do nowego pocesora a jeśli nawet wgra na siłę to jak można przypuszczać procek niezbyt chętnie będzie chciał działać ;)


    Nie pisałem jeszcze własnych bootloaderów. Nie wiem nawet jak zacząć :), czy można gdzieś znaleźć coś gotowego ?
  • #9 5686343
    mirekk36
    Poziom 42  
    Hmm z gotowym boot loaderem do takich celów to będziesz miał kiepsko, chyba, że ktoś już coś takiego zrobił i w niekomercyjny sposób będzie chciał udostępnić. Jednak nawet w takim przypadku ty sam będziesz musiał się dostosować do wielu rzeczy - np procka, dla któregoś ktoś napisał boot loader, do jego wielkości w pamięci no i do opracowania sposobu szyfrowania, chyba, że i to ktoś poda tak w otwarty sposób - w co troszkę, szczerze mówiąc, wątpię - no ale może się mylę ;)

    Proponuję, skoro już chcesz wykonać sam komercyjne i dobrze zabezpieczone rozwiązanie to samemu napisać własny bootloader i jak radził kolega Samuraj na początku z jakimś bardzo prostym szyfrowaniem.

    proponuję ci zapoznać się z poniższym wątkiem na elektrodzie - on może ci dużo pomóc. A jak już się zabierzesz sam na poważnie za napisanie boot loadera to zobaczysz, że to nie jest wcale taki wielki problem

    https://www.elektroda.pl/rtvforum/topic1121991.html
  • #10 5686362
    monty_p
    Poziom 18  
    DZIĘKI !!

    Już patrzę co tam masz :)

    Będę męczył temat.

    Pozdrawiam
  • #12 5692371
    romario4
    Poziom 16  
    Tu masz to co Ci potrzeba, źródła bootloadera (pod kompilator IAR'a), i programy, poczytaj to będziesz wiedział:
    Link
    Osobiście używam WinAVR i softu pobranego z tej strony:
    Link
    ale musisz się zalogować (założyć konto).
    Pozdrawiam.
  • #13 5692386
    Jacek Rutkowski
    Poziom 28  
    Może zrobić to o wiele prościej tzn dać Dallasa z numerem seryjny i wsad dla każdego procka z jego numerem jeśli ma być proste(ewentualnie jeśli jest miejsce to wszystkie numery uprawnione wpisać i jeśli się zgadza z któryś z nich to działa).
  • #14 5692804
    monty_p
    Poziom 18  
    Ja myślałem właśnie zrobić tak, że wrzucam zwykły bootloader, wrzucam do epromu jakiś ciąg znaków (klucz), zabezpieczam eprom i flash przed odczytem, odłączam programowanie po ISP a w programie, który chcę zabezpieczyć, robię odpowiedni skrypt, który odpytuje eprom, czy jest odpowiedni ciąg znaków. Jeżeli go niema, to program się nie wykona.

    ...Czy to ma jakiś sens??

    Dodano po 43 [minuty]:

    Xitami napisał:
    szyfrowanie AES albo DES
    http://atmel.com/dyn/products/app_notes.asp?family_id=607
    AN230 AN231


    ...jak tylko dojdę jak tego użyć, będzie to najlepsze rozwiązanie :D

    Bawiłeś się tym może?? Jesteś w stanie mi z tym pomóc?
  • #15 5692976
    Jacek Rutkowski
    Poziom 28  
    Ma sens tylko nie wiem jaki to ma być procek i czy można zabezpieczyć eeprom przed odczytem przez programator (równoległy)? Zależy jak bardzo chcesz zabezpieczyć program?
  • #16 5692995
    marekos
    Poziom 16  
    Ma to sens, ale w eepromie najlepiej trzymać tylko klucz do szyfru a sam szyfr w aplikacji bootloadera.

    Należy pamiętać przy okazji tej sprawy że w trakcie programowania pamięci flash w AVR nie wolno używać pamięci eeprom.
  • #17 5693010
    monty_p
    Poziom 18  
    w tej chwili mam na ATmega8 w wersji SMD

    ...można wyłączyć programowanie po SPI ale nie wiem, czy od razu po RSie się nie wyłączy :) ewentualnie wyłączę wejście reset (zrobię z niego zwykły port I/O ) :), to na pewno się nie obsłuży sprzętu po RS'ie :)

    Jeżeli chodzi o zabezpieczenie, to zrobił bym pełne zabezpieczenie flash+eprom z zaznaczeniem, że jak by kasowało flasha podczas flashowania, to żeby nie ruszało eproma
  • #18 5693090
    BoskiDialer
    Poziom 34  
    Pełne zabezpieczenie flash a klucz w niekasowanym eeprom? wystarczy wyczyścić układ i już ma się klucz.

    Najprostrze zabezpieczenie to posiadać w pamięci flash zaraz obok bootloadera dwa klucze - jeden, którym był by odszyfrowywany plik (podczas przesyłania), drugi służący do weryfikacji (podczas programowania oraz opcjonalnie przy uruchamianiu).
    Szyfrowanie: na początku pliku dać IV, uC pobierze IV a resztę będzie odszyfrowywać w CTR. Weryfikacja za pomocą CBC-MAC z całości (tryb CTR oraz CBC-MAC wymagają tylko funkcji szyfrującej). Należało by się też uchronić przed uruchomieniem skorumpowanego programu (załączenie BOR, weryfikacja przy każdym uruchomieniu) lub wybrać uC, w którym można całkowicie zablokować SPM oraz LPM - aby aplikacja (nawet skorumpowana) nie mogła odczytać kluczy.

    Co do programowania po RS'ie - nie ma w dokumentacji avr'ów opisanej możliwości programowania po RS'ie. Może być taka możliwość, ale tylko z poziomu bootloadera.
  • #19 5695266
    monty_p
    Poziom 18  
    odpowiedzią na moje pytanie jest DS2401...


    ...nic mi więcej do szczęścia nie potrzeba :)

    Dziękuję za podpowiedzi :)

    Pozdrawiam
  • #20 5695295
    BoskiDialer
    Poziom 34  
    Według mnie to nie jest żadne zabezpieczenie. Unikalny numer, nic więcej. Tym wcale nie zabezpieczysz układu przed możliwością aktualizacji zawartości bez możliwości skopiowania.
  • #21 5695351
    Samuraj
    Poziom 35  
    BoskiDialer napisał:
    Według mnie to nie jest żadne zabezpieczenie. Unikalny numer, nic więcej. Tym wcale nie zabezpieczysz układu przed możliwością aktualizacji zawartości bez możliwości skopiowania.


    A czym że jest unikalny numer jak nie kluczem.
    Co z tego że skopiujesz układ jak nie uruchomisz całości bez klucza.
    Jeśli przełożysz klucz (którym jest DS2401)z oryginału do kopi to tym samym tracisz możliwość uruchomienia oryginału i dalej pozostaje tylko jeden układ pracujący.
    W dodatku uzyskujemy jeszcze jedną zaletę - numeru DS nie da się skopiować. No chyba że ktoś opracuje układ 1Wire będący slavem.
  • #22 5695380
    monty_p
    Poziom 18  
    Samuraj napisał:
    Jeśli przełożysz klucz (którym jest DS2401)z oryginału do kopi to tym samym tracisz możliwość uruchomienia oryginału i dalej pozostaje tylko jeden układ pracujący.


    NO WLASNIE !! a jak sie jeszcze zrobi kopie SN w epromie atmegi i dopisze odpowiedni program, to jak wyjmie Dallasa z oryginalu i przelozy do kopii, to i oryginalu pozniej nie uruchomi :)

    Dla mnie bomba :)
  • #23 5695465
    K_o_n_r_a_d
    Poziom 23  
    1. Podrobienie układu DS2401 nie jest żadnym problemem, nawet dla początkującego, ale znającego 1wire. Tak samo trudno zrobić 1wire slave jak i 1wire master. Wystarczy do tego dowolny uK, nawet najtańszy, najmniejszy.
    2. Jeśli będziesz trzymał kopię numeru seryjnego w eepromie lub nawet samym bootloaderze to po co będzie sam układ DS2401?

    Odpowiednio skonstruowany bootloader wystarczy. Zrób tak jak zaproponował mirekk36 i będzie dobrze. Być może nie musisz stosować jakichś skompilowanych algorytmów szyfrowania. Nawet prosty odstraszy potencjalnych podrabiaczy.
  • #24 5695482
    monty_p
    Poziom 18  
    DS2401 dla tego, bo to nie jest skomplikowane (dla mnie). Modyfikowanie bootloadera, czy pisanie własnego to jeszcze za dużo na moje możliwości.
    :(
  • #25 5695566
    Dr_DEAD
    Poziom 28  
    monty_p napisał:
    DS2401 dla tego, bo to nie jest skomplikowane (dla mnie). Modyfikowanie bootloadera, czy pisanie własnego to jeszcze za dużo na moje możliwości.
    :(

    Hej, ja się właśnie biorę za ten bootloader Atmela z AES'em. Narazie przeczytałem tylko PDF'a ale wszystko wydaje się całkiem łatwe i dopracowane. No i dodatkową zaletą jest to że dają też soft pod PC. Komplet narzędzi nic tylko używać :-).
  • #26 5695571
    monty_p
    Poziom 18  
    :)

    Będę musiał się "wczytać" w temat. Na szybko muszę jednak zabezpieczyć jeden projekt za pomocą DS'a. :)
    ...następne sztuki będą już lepsze :)
  • #28 5695783
    RAPELC
    Poziom 17  
    Nie wiem czy to jest możliwe aby zabezpieczyć przed odczytem tylko część pamięci, zdaje mi się że coś takiego czytałem, ale nie jestem pewny.
    Jeżeli by to było możliwe, to można by umieścić w tej zabezpieczonej na stałe części pamięci stały fragment programu, np. jakieś własne biblioteki, bez których ten właściwy i aktualizowany program by nie pracował lub robił jakieś idiotyzmy nie do przyjęcia.
    Mogło by być to niezależne od wcześniej opisanych sposobów, a połączone z nimi było by już dość mocno zakręcone.
    Jeżeli gostek by chciał skopiować taką maszynkę to pocałuj wójta w d... nie będzie wiedział o co chodzi i niech to nawet sobie rozszyfruje jak będzie mądry. Dojdzie więc do wniosku że łatwiej mu napisać swój program niż tamten kopiować. A o to przecież chodzi.
  • #29 5696032
    romario4
    Poziom 16  
    monty_p napisał:
    DS2401 dla tego, bo to nie jest skomplikowane (dla mnie). Modyfikowanie bootloadera, czy pisanie własnego to jeszcze za dużo na moje możliwości.
    :(

    Witam. Ja też się obawiałem że sobie nie poradzę z tym bootloaderem, ale jednak nie było to takie trudne. Przynajmnie mnie się udało. Używałem zmodyfikowanego softu atmela (avr231.zip) pobranego z avrfreaks ( link podałem wyżej ). Soft ten trzeba odpowiednio przystosować do własnych potrzeb tzn. zmienić pin, port który ma być testowany przez mikrokontroler w czasie uruchomienia, aby wejść w bootloader, jeśli masz w swoim układzie jakiegoś leda, lub buzerek to można go użyć do sygnalizacji że bootloader się uruchomi i ewentualnie sygnalizował błędy. Poza tym trzeba ustawić typ procka, częstotliwość zegara, prędkość transmisji, kompilacja i gotowe. Mając te dane mogę pomóc w przystosowaniu ów softu do konkretnych potrzeb. Acha, ów bootloader zajmuje prawie 2kB pamięci(szyfrowanie 256bitów), więc w przypadku atmegi zostanie Ci tylko 6kB flasha.
    Pozdrawiam.
  • #30 5696927
    BoskiDialer
    Poziom 34  
    Samuraj napisał:
    BoskiDialer napisał:
    Według mnie to nie jest żadne zabezpieczenie. Unikalny numer, nic więcej. Tym wcale nie zabezpieczysz układu przed możliwością aktualizacji zawartości bez możliwości skopiowania.


    A czym że jest unikalny numer jak nie kluczem.
    Co z tego że skopiujesz układ jak nie uruchomisz całości bez klucza.
    Jeśli przełożysz klucz (którym jest DS2401)z oryginału do kopi to tym samym tracisz możliwość uruchomienia oryginału i dalej pozostaje tylko jeden układ pracujący.
    W dodatku uzyskujemy jeszcze jedną zaletę - numeru DS nie da się skopiować. No chyba że ktoś opracuje układ 1Wire będący slavem.

    Aby urządzenia nie dało się skopiować musi być co najmniej jedna niewiadoma dla osoby postronnej, której nie da się skopiować. Numer seryjny jest znany (zawsze idzie go odczytać), na tym szyfrowania nie oprzesz (brak niewiadomej - zawsze można by odszyfrować firmware), dodatkowo i tak firmware musiało by być osobne dla każdego egzemplarza. Układ z numerem seryjnym da się emulować, jak również da się (mając jawnie dany firmware) zamienić kod sprawdzający ów "klucz" na same nopy (w znaczeniu: da się wylączyć zabezpieczenia). Jako że poznanie samego firmware umożliwia skopiowanie urządzenia, należy ukryć firmware za pomocą szyfrowania. Na uC mamy to, że nie ma możliwości odczytania z zewnątrz zawartości programu (jeśli uC jest odpowiednio zabezpieczony). Wystarczy więc, aby do samego uC dostarczyć zaszyfrowany firmware, bootloader go odszyfruje znanymi tylko sobie kluczami (mogą być takie same dla każdego egzemplarza). Niemożliwość skopiowania kluczy ani zgrania firmware (rozszyfrowanego) z uC powoduje, że nie da się skopiować układu.

    Weryfikacja poprawności jest niezbędna z tego względu, że uruchomienie skorumpowanego programu może doprowadzić do wycieku kluczy - jest to porównywalne z tym, że można wgrać program który zrzuci cały flash na uart, też skopiujemy układ. Jeśli dany uC wspiera możliwość zablokowania odczytu bootloadera z poziomu aplikacji, to mamy większą swobodę, gdyż nawet skorumpowana aplikacja nie mogła by ich odczytać (mimo to, tutaj też jest zalecane bezpieczeństwo).
REKLAMA