-
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
- Ściąganie hasła frezem
- Koszyk okrągły, walec 3x AA, na duże paluszki R6
- Brak bolca ochronnego ładowarki oznacza pożar
- AMS spalony szybkim zasilaczem USB
- stalowe bezpieczniki
- Wyświtlacz ramki cyfrowej
- bateria na żądanie
- pradnica krokowa
- Nieustający podziw...
- Coś dusi.
- akumulator napięcie 12.0v
- Podłączenie DMA 8257 do 8085
- pozew za naprawę sprzętu na youtube
- gasik
- Zbieranie danych przez www
Najnowsze wątki
- 2025-02-01 Śmierć mózgu a narządy do pobrania
- 2025-01-31 A niektórym to naprawdę zależy na ekologi w miastach LPG POWRACA ;-)
- 2025-01-31 Lublin => Programista Delphi <=
- 2025-01-31 Łódź => Programista NodeJS <=
- 2025-01-31 Wrocław => Senior SAP Support Consultant (SD) <=
- 2025-01-31 Warszawa => Full Stack web developer (obszar .Net Core, Angular6+) <=
- 2025-01-31 Gdańsk => iOS Developer (Swift experience) <=
- 2025-01-31 Kraków => UX Designer <=
- 2025-01-31 Warszawa => Data Engineer (Tech Leader) <=
- 2025-01-31 Gliwice => Business Development Manager - Dział Sieci i Bezpieczeńst
- 2025-01-31 Gliwice => Business Development Manager - Network and Network Security
- 2025-01-31 Warszawa => Architekt rozwiązań (doświadczenie w obszarze Java, AWS
- 2025-01-31 Warszawa => Full Stack .Net Engineer <=
- 2025-01-31 Warszawa => Programista Full Stack (.Net Core) <=
- 2025-01-31 Gdańsk => Programista Full Stack .Net <=