Jakie strumieniowe deszyfratory firmware pasują do własnego bootloadera?

Sat Mar 23, 2013 5:34 pm   

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

Sat Mar 23, 2013 5:36 pm   

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

Sat Mar 23, 2013 5:40 pm   

On 2013-03-23 17:36, Ministerstwo Propagandy wrote:

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.

Sat Mar 23, 2013 8:00 pm   

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


Uzywalem tea.

http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm

Moze bedzie OK.


--
Andrzej

Sun Mar 24, 2013 9:23 am   

On 2013-03-23 20:00, Andy wrote:

Dziekuje wygląda ok.

Sun Mar 24, 2013 11:02 am   

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.

Sun Mar 24, 2013 11:50 am   

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

No ale bootloadera zarazi GPLem.




--
pozdrawiam
MD

Sun Mar 24, 2013 12:25 pm   

On Sat, 23 Mar 2013 17:40:05 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:

Ja do bootloadera używam xtea, raptem kilkanascie linijek kodu w C.
http://en.wikipedia.org/wiki/XTEA

--
Marek

Sun Mar 24, 2013 11:10 pm   

On 24.03.2013 22:44, bajcik@kolos.math.uni.lodz.pl wrote:

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

--
Pozdrawiam
Michoo

Sun Mar 24, 2013 11:44 pm   

Sebastian Biały pisze:

Po co deszyfrowanie w bootloaderze?

bajcik

Mon Mar 25, 2013 7:52 am   

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.

Tue Mar 26, 2013 12:34 am   

Michoo pisze:

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

Tue Mar 26, 2013 12:57 am   

On Mon, 25 Mar 2013 22:34:35 +0000 (UTC),
bajcik@kolos.math.uni.lodz.pl wrote:


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.

--
Marek

Tue Mar 26, 2013 9:38 am   

Użytkownik <bajcik@kolos.math.uni.lodz.pl> napisał w wiadomości
news:kiqjdr$q6f$1@node2.news.atman.pl...

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.

Tue Mar 26, 2013 10:04 am   

Użytkownik "Sebastian Biały" <heby@poczta.onet.pl> napisał w wiadomości
news:kimd57$i13$1@node1.news.atman.pl...

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.