W dniu 25.07.2013 09:57, Marek pisze:
> On Tue, 23 Jul 2013 10:25:36 +0200, Piotr
> Gałka<p...@c...pl> wrote:
>> Potrzebujesz podpisywania, a nie szyfrowania.
>> Przed poleceniem (nawet jawnym) umieść kolejny numer i całość
> podpisz (CMAC,
>> HMAC).
>> Odbiornik akceptuje tylko polecenia z dowolnym wyższym numerem od
> aby
>> poprzedniego, ale prawidłowo podpisane.
>
>
>
> Ale to jest sposób komunikacji, w którym:
>
> Xb -> Y
>
> gdzie Xb polecenie o ilosci bajtow b wysłane z nadajnika
> Y akcja odbiornika (wykonanie polecania Xb)
>
>
> nie analizujac zupełnie zawartości Xb daje nam
> ograniczona liczbę możliwych Xb tj. ograniczoną wielkością możliwych
> kombinacji zbioru b. Jeśli b będzie małe, a założenie jest takie aby
> komunikacja była jak najkrótsza, to wystarczy wypróbować wszystkie
> możliwe kombinacje. Model wręcz stworzony do replay attack.
> Odbiornik musiałby pamiętać ostatni nr sekwencyjny aby nie przyjąć już
> użytego. Takie rozwiązanie ma kolejne dwa zastrzeżenia:
> 1. jawna komunikacja, skrót dostępny jak na dłoni, można go użyć jako
> wsad do analizy krypto w celu wykrycia jego słabości.
> 2. nr sekwencyjny musiałby być zapisywany w jakieś pamieci nieulotnej,
> przy kilku tysiącu poleceń na godzinę flash mcu może szybko przekroczyć
> gwarantowana liczbe zapisów. Trzeba by mieć jakiś zewnętrzny,
> odpowiednio duży flash. A mając zewnętrzna pamięć ja trzeba by też
> chronić, by nie można było zewnętrznie zmodyfikować jej zawartość
> (zmniejszyć numer sekwencyjny).
> PozostajeStosowanie nr sekwencyjnego "w środku" działa dodatkowo na
> niekorzyść, bo powoduje, ze dla różnych b istnieje takie samo Y
> (dokładnie tyle ile jest możliwych nr sekwencyjnych).

A na końcu okaże się, że taniej jest zlecić chińczykowi wydłubanie
programu z uC i nie trzeba się bawić w żadne łamanie podpisów/szyfrów.
(no chyba, że klucze trzymamy w RAMie podtrzymywanym bateryjnie i przy
próbie otwarcia urządzenia jest on czyszczony)

Ostatnio taki fajny spam dostałem: http://hack-mcu.com/