-
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
atman.pl!news.chmurka.net!.POSTED!not-for-mail
From: Piotr Gałka <p...@c...pl>
Newsgroups: pl.misc.elektronika
Subject: Re: Problem z szyfrowaniem komunikacji między mcu
Date: Thu, 25 Jul 2013 19:56:34 +0200
Organization: news.chmurka.net
Lines: 55
Message-ID: <ksrosk$949$1@somewhere.invalid>
References: <a...@n...neostrada.pl>
<kslem3$5al$1@somewhere.invalid>
<a...@n...neostrada.pl>
<ksqp3p$og7$1@somewhere.invalid>
<a...@n...neostrada.pl>
<ksr0p7$s11$1@somewhere.invalid>
<a...@n...neostrada.pl>
NNTP-Posting-Host: 213.192.88.238
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response
Content-Transfer-Encoding: 8bit
X-Trace: somewhere.invalid 1374774996 9353 213.192.88.238 (25 Jul 2013 17:56:36 GMT)
X-Complaints-To: abuse-news.(at).chmurka.net
NNTP-Posting-Date: Thu, 25 Jul 2013 17:56:36 +0000 (UTC)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-Priority: 3
X-Authenticated-User: PiotrGalka
X-MSMail-Priority: Normal
Xref: news-archive.icm.edu.pl pl.misc.elektronika:650323
[ ukryj nagłówki ]
Użytkownik "Marek" <f...@f...com> napisał w wiadomości
news:almarsoft.5927629346930432473@news.neostrada.pl
...
>
> Skoro podpis taki sam dla tej samej komendy, to oznacza ze trzeba
> wprowadzić jakaś unikalnosc, aby ta sama komenda była prawidłowa dla
> różnych Xb, aby nie można było wykorzystać tego samego Xb drugi raz, ta
> unikalnosc daje nam nr sekwencyjny, czyli mamy komunikat
> Xb=(cmd+nrsek+podpis)
>
> Xb de facto staje się strumieniem bajtów o dkugosci b, który powoduje
> wykonanie Y.
> Jeśli b będzie małe, można bez trudu wygenerować wszystkie możliwe
> kombinacje Xb i trafić na te, które wywołają Y (pisal o tym Michoo), bez
> żadnej "analizy kryptograficznej"... Wniosek jest taki, ze kryptografia
> daje jedynie algorytm i narzędzie do wygenerowania i weryfikacji tych
> unikalnych Xb, to samo mozna by uzyskać bez kryptografii umieszczając w
> obu mcu bazę kolejnych Xb autoryzujacych Y, ważne aby Xb było na tyle
> długie by zgadywanie kolejnego prawidlowego było czasowo nieopłacalne.
>
Masz rację, przy założeniu, że odbiornik w żaden sposób nie reaguje na
błędne podpisy.
O wymaganej długości podpisu decyduje pasmo kanału pozwalającego atakującemu
weryfikować swoje kolejne próby.
Jak pasmo jest wąskie (RS232 300 Bodów) lub szerokie, ale w przypadku błędów
celowo zawężane, to wystarczy względnie krótki podpis - 32 bity. Dla innych
systemów może być potrzeba 48 bitów lub 64.
Atak na podpis tym się różni od ataku na szyfrowanie, że nie można go
przeprowadzić u siebie na superkomputerze w oderwaniu od atakowanego sprzętu
bo tylko atakowany sprzęt pozwala ustalić, czy podpis jest prawidłowy.
Moim zdaniem podpis nie powinien być dłuższy niż połowa długości klucza
używanego do podpisu. Gdyby podpis był tak długi jak klucz to atakujący może
założyć, że tylko jeden klucz da prawidłowy podpis i przenieść poszukiwanie
klucza podpisu na swój sprzęt i ograniczenia pasma przestają działać.
Nie rozumiem przyjmowanego przez Ciebie podejścia celowo wydłużającego czas
ataku. Przyjmując takie podejście przy ocenie odporności systemu można się
nieźle pośliznąć.
Jednym z założeń kryptografii jest to, że algorytmy, formaty danych są
znane. Czyli przy rozważaniu takiego przypadku wiadomo, gdzie jest rozkaz i
jaki ma być, gdzie jest kolejny numer i jakie może w danym momencie przyjąć
wartości i gdzie jest podpis. Nie ma sensu próbować wszystkich kombinacji
dla całej wiadomości bo jeśli na przykład rozkaz jest tylko 1 bajtowy to z
góry skazujemy 255 z każdych naszych 256 prób na porażkę - wydłużamy
szacowany czas ataku 256 razy (wyjdzie nam, że atak potrwa 256 lat, gdy
faktycznie wystarczy rok - a to jest zasadnicza różnica). A jak zależy nam
na wymuszeniu konkretnego rozkazu, gdy rozkaz jest kodowany na większej
liczbie bajtów - wyjdą nam lata, a faktycznie wystarczą milisekundy.
Takie podejście prowadzi do absurdu bo jeśli rozkaz jest 16 bajtowy i tylko
jeden konkretny kod spowoduje akcję Y to dojdziemy do wniosku, że podpis
jest w ogóle niepotrzebny bo atakujący musi prawdopodobnie sprawdzić 2^127
kombinacji (połowę wszystkich) zanim trafi na właściwą.
P.G.
Następne wpisy z tego wątku
- 26.07.13 00:40 Michoo
- 26.07.13 00:56 Michoo
- 26.07.13 10:52 Piotr Gałka
- 26.07.13 12:13 Piotr Gałka
- 26.07.13 20:46 voyo
- 27.07.13 21:05 Irek N.
- 29.07.13 10:33 Piotr Gałka
- 30.07.13 09:37 Marek
- 30.07.13 10:43 Piotr Gałka
- 30.07.13 11:49 Marek
- 30.07.13 13:18 Piotr Gałka
- 30.07.13 14:08 Marek
- 30.07.13 17:51 Piotr Gałka
Najnowsze wątki z tej grupy
- Położyłem dwa telefony obok siebie
- Przekaźnik na szynę DIN (?)
- Taśma LED
- Jak odróżnić myjki wibrujące od ultradźwiękowych.
- Ledy na wyłączniku czasowym błyskają
- Re: Kompensacja mocy biernej przy 230VAC
- Re: Kompensacja mocy biernej przy 230VAC
- RCD wybija
- Re: Kompensacja mocy biernej przy 230VAC
- Łożysko ślizgowe - jaki olej
- Re: Kompensacja mocy biernej przy 230VAC
- Re: Kompensacja mocy biernej przy 230VAC
- Współczesny falomierz
- Zasilacz 7V na szynę DIN
- Waga z legalizacją
Najnowsze wątki
- 2025-04-07 Nagie zdjęcia nauczycieli
- 2025-04-07 czy też tak macie w swoich Wrocławiach?
- 2025-04-07 Czeladź => Specjalista ds. public relations <=
- 2025-04-07 Adam Bodnar przekracza kolejną granicę absurdu. Powoli się szykuje do nowej fuchy w TSUE
- 2025-04-07 Warszawa => Sales Executive / KAM <=
- 2025-04-07 Warszawa => Operations Support Systems (OSS) Team Leader <=
- 2025-04-07 Kraków => MS Dynamics 365BC/NAV Developer <=
- 2025-04-07 Warszawa => Software Solution Architect <=
- 2025-04-07 China-Kraków => Key Account Manager IT <=
- 2025-04-07 Kraków => NMS System Administrator <=
- 2025-04-07 szczepionkowo
- 2025-04-07 Warszawa => Manual tester <=
- 2025-04-07 Warszawa => Administrator Systemów OSS <=
- 2025-04-07 Warszawa => Node.js / Fullstack Developer <=
- 2025-04-07 Położyłem dwa telefony obok siebie