Deszyfrator strumienionwy do bootloadera

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ą.

Reply to
Sebastian Biały
Loading thread data ...

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

Reply to
Ministerstwo Propagandy

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.

Reply to
Sebastian Biały

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

...

Uzywalem tea.

formatting link
Moze bedzie OK.

Reply to
Andy

Dziekuje wygląda ok.

Reply to
Sebastian Biały

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.

Reply to
J.F.

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

No ale bootloadera zarazi GPLem.

Reply to
Mario

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

formatting link

Reply to
Marek

Sebastian Biały pisze:

Po co deszyfrowanie w bootloaderze?

bajcik

Reply to
bajcik

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

Reply to
Michoo

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.

Reply to
Zbych

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

Reply to
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.

Reply to
Marek

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.

Reply to
Piotr Gałka

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.

Reply to
Piotr Gałka

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.

Reply to
Sebastian Biały

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

Reply to
Sebastian Biały

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

Jaki procesor ?

Pozdr AK

Reply to
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 ...

Reply to
Sebastian Biały

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

Reply to
Sebastian Biały

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.