Deszyfrator strumienionwy do bootloadera

Mar 23, 2013 28 Replies

Co aktualnie nadaje się do deszyfracji w locie firmware? Deszyfracja przez bootloader, klucz symetryczny (poza bootloaderem nie istnieje, bootloader chroniony hardwareowo).



Niektórzy polecają Pukall Cipher 1 ale jakoś nie wierzę na slowo że kryptokgraficznie bez wad, ponadto kod jak by ktoś nasr... więc tym bardziej, żeo używaniu w środku mnożenia nie wspomnę.



Powinno być małe, strumieniowe, najlepiej łatwo "kompresowalne" do assemblera. AES i te okolice wydają się być przesadą, ale może się mylę?



Bootloader siłą rzeczy musi być mój własny (ze względu na nieco nietypowe działanie) i niestety licencje GPL odpadają.


ja się nie znam, ale taki fachowiec i sam sobie nie może napisać?

Nie jestem jednym z tych którzy codziennie pisza nowy silnie kryptograficzny cipher. Może marny ze mnie programista, ale jakoś nie czuje się na siłach.

W dniu 2013-03-23 17:34, Sebastian Biały pisze:

...

Uzywalem tea.

formatting link
Moze bedzie OK.

Dziekuje wygląda ok.

Dnia Sat, 23 Mar 2013 17:34:53 +0100, Sebastian Biały napisał(a):

Tak ogolnie to do komputerow sluza szyfry serii RC - dobrze programowalne w typowym zestawie instrukcji.

Dobry szyfr, zmiennej z kluczem nie musisz przeciez ujawniac. I moze jeszcze szyfr jednokierunkowy i nie ma sie czego bac :-)

J.

W dniu 2013-03-24 11:02, J.F. pisze:

No ale bootloadera zarazi GPLem.

Ja do bootloadera używam xtea, raptem kilkanascie linijek kodu w C.

formatting link

Sebastian Biały pisze:

Po co deszyfrowanie w bootloaderze?

bajcik

Żeby można było dostarczać klientowi update w którym nie będzie mógł grzebać.

W dniu 2013-03-23 17:34, Sebastian Biały pisze:

AES. Bloki są po 16 bajtów, ale przy firmwarze nie powinno to przeszkadzać. Dodatkowy plus sprzętowa akceleracja w nowszych ARMach.

Toż to binarka, więc musiałoby mu zależeć. Z drugiej strony - skoro za to zapłacił to dlaczego ma sobie nie pogrzebać?

bajcik

Raczej chodzi o ochronę przed skopiowaniem rozwiązania jako całości. Płytkę może sobie skopiować (patrz wątek o rewersie) ale softu zabezpieczonego w ten sposób juz nie "wgra" do "czystego" mcu z kopii układu.

Użytkownik snipped-for-privacy@kolos.math.uni.lodz.pl> napisał w wiadomości news:kiqjdr$q6f$ snipped-for-privacy@node2.news.atman.pl...

Skąd Ty się urwałeś ? Zapłacił za jedno urządzenie, a nie za licencję na jego produkcję. Gdy zakładaliśmy firmę w 1988 roku kwestia zabezpieczenia się przed kradzieżą pracy włożonej w oprogramowanie produktu był już jak najbardziej aktualnym problemem. P.G.

Po przeczytaniu książki: N.Ferguson, B.Schneier "Kryptografia w praktyce" (oryginał napisany w 2003 roku) uznałem, że już wtedy stosowanie szyfrów o bloku lub kluczu zaledwie 64 bitowym należało uznać za niewystarczające.

Nie znam się na tyle aby ocenić Tiny Encryption Algorithm. Podstawowa sprawa: trzeba pamiętać, że zabezpieczasz się nie przed przypadkowym zaglądnięciem do kodu tylko przed kimś, kto robi to celowo. Stąd zasada z tej książki: Jeśli masz stosować za słabe zabezpieczenie to równie dobrze możesz nie stosować żadnego. Kiedyś był jakiś konkurs na łamanie DESa i zwycięzcy siłowy atak zajął o ile się nie mylę kilka dni (był to jakiś hacker, który zatrudnił do tego coś koło 10000 PC-tów, na całym świecie, które miał zhackowane). Siłowy atak na kod jest łatwy, bo dość łatwo jest określić wymogi sprawdzające czy plain text jest prawdziwy. AES jest dobrze opisany i w oryginalnym opisie są wektory testowe do sprawdzenia, czy nie zrobiłeś błędu w swoim programie. No i kody źródłowe da się znaleźć. Przy którymś z algorytmów w opisie NIST były oczywiste błędy w wektorach testowych (różne dane dawały według nich ten sam wynik). Jakiś inny algorytm (CMAC, czy HMAC) udało :-) mi się przypadkowo zapisać z takim błędem, że wszystkie wektory testowe przechodziły bez błędu. Ze 4 lata temu napisałem o obu tych sprawach do NIST i poprawili jedno i dodali dodatkowe wektory w drugim. P.G.

To mało prawdopodobne aby ktoś to robił celowo jesli będzie mial do pokonania kryptografię. Rzecz nie w tym aby mieć ekstremalnie niełamalny algorytm tylko żeby *troszeńke* zabezpieczyć sie przed klonowaniem przez chińczyka. A musze robić upgrade firmware zdalnie. I tyle. Nie przypuszczam zeby ktokolwiek wydał choć $10 na złamanie tego bo się nie opłaca. Więc pewnie każdy algorytm będzie ok.

Skoro juz sobie pogrzebał to kto będzie winien jak komuś maszyna łeb urwie? I jak to udowodnić?

W dniu 2013-03-23 17:34, Sebastian Biały pisze:

Jaki procesor ?

Pozdr AK

Głównie AVR oraz celuje w ARM7 ale z powodu absurdalnych cen SAM7 właśnie rozglądam się za czymś innym z tej okolicy (LPC?) więc żadnych konkretów. Choć w SAM7 support sprzetowy do bootloadera był zerowy ...

O ile dobrze pamiętam AES jest dość cieżki. Nie wiem czy się z nim zmieszcze w kilkuset bajtach.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required