W dniu 2013-03-23 17:34, Sebastian Biały pisze:
> Co aktualnie nadaje się do deszyfracji w locie firmware? Deszyfracja
> przez bootloader, klucz symetryczny (poza bootloaderem nie istnieje,
> bootloader chroniony hardwareowo).

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

do góry

Michoo pisze:
> On 24.03.2013 22:44, b...@k...math.uni.lodz.pl wrote:
>> Sebastian Biały pisze:
>>> Co aktualnie nadaje się do deszyfracji w locie firmware? Deszyfracja
>>> przez bootloader, klucz symetryczny (poza bootloaderem nie istnieje,
>>> bootloader chroniony hardwareowo).
>>
>> Po co deszyfrowanie w bootloaderze?
>
> Żeby można było dostarczać klientowi update w którym nie będzie mógł
> grzebać.

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

do góry

On Mon, 25 Mar 2013 22:34:35 +0000 (UTC),
b...@k...math.uni.lodz.pl wrote:
> Z drugiej strony - skoro za to zapłacił to dlaczego ma sobie nie
pogrzebać?

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

do góry

Użytkownik <b...@k...math.uni.lodz.pl> napisał w wiadomości
news:kiqjdr$q6f$1@node2.news.atman.pl...
>
> Toż to binarka, więc musiałoby mu zależeć.
> Z drugiej strony - skoro za to zapłacił to dlaczego ma sobie nie
> pogrzebać?
>
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.

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:kimd57$i13$1@node1.news.atman.pl...
> On 2013-03-23 20:00, Andy wrote:
>> Uzywalem tea.
>> http://en.wikipedia.org/wiki/Tiny_Encryption_Algorit
hm
>
> Dziekuje wygląda ok.

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.

do góry

On 2013-03-26 10:04, Piotr Gałka wrote:
> Podstawowa sprawa: trzeba pamiętać, że zabezpieczasz się nie przed
> przypadkowym zaglądnięciem do kodu tylko przed kimś, kto robi to celowo.

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.

do góry

On 2013-03-25 23:34, b...@k...math.uni.lodz.pl wrote:
> Z drugiej strony - skoro za to zapłacił to dlaczego ma sobie nie pogrzebać?

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

do góry

W dniu 2013-03-23 17:34, Sebastian Biały pisze:
> Co aktualnie nadaje się do deszyfracji w locie firmware? Deszyfracja
> przez bootloader, klucz symetryczny (poza bootloaderem nie istnieje,
> bootloader chroniony hardwareowo).
>
Jaki procesor ?

Pozdr
AK

do góry

On 2013-03-26 20:05, AK wrote:
> Jaki procesor ?

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

do góry

On 2013-03-25 07:52, Zbych wrote:
> AES. Bloki są po 16 bajtów, ale przy firmwarze nie powinno to
> przeszkadzać. Dodatkowy plus sprzętowa akceleracja w nowszych ARMach.

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

do góry