Sposoby zabezpieczenia komunikacji UART między mikrokontrolerami przed podsłuchem?

Thu Jul 25, 2013 11:05 am   

Użytkownik "Marek" <fake@fakeemail.com> napisał w wiadomości
news:almarsoft.4145414839725222301@news.neostrada.pl...

Tu nie rozumiem.
Jaką liczbę poleceń liczysz, że od wszystkich kombinacji odejmujesz
kombinacje prawidłowe ?
Prawidłowe to są te które można w danym momencie wysłać, aby uzyskać Y, czy
te które do tej pory wysłano ?
Nadal nie rozumiem dlaczego w jakiś specjalny sposób wyróżniasz to, że
nrsekw jest w środku strumienia. Czy to coś zmienia jakby był na początku ?


(polecenie+nrsekw) ten sam podpis.
Nie widzę najmniejszego sensu w podpisie, który mógłby mieć wiele różnych
wartości dla tej samej treści bo:
- atakujący miałby odpowiednio większą szansę losowego trafienia w
prawidłowy podpis,
- odbiornik miałby znacznie więcej roboty, aby sprawdzić, czy podpis jest
jednym z prawidłowych.
P.G.

Thu Jul 25, 2013 2:03 pm   

On Thu, 25 Jul 2013 13:05:09 +0200, Piotr
Gałka<piotr.galka@cutthismicromade.pl> wrote:

Te, które dają Y. Nie ma znaczenia czy już wysłane czy jeszcze nie
(zakładamy na razie poczatkowa "przestrzeń zbioru").



W środku, czyli podpis jest częścią strumienia (bez znaczenia w
środku czy na początku).



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.

--
Marek

Thu Jul 25, 2013 5:56 pm   

Użytkownik "Marek" <fake@fakeemail.com> napisał w wiadomości
news:almarsoft.5927629346930432473@news.neostrada.pl...

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.

Thu Jul 25, 2013 10:40 pm   

On 25.07.2013 19:56, Piotr Gałka wrote:

To jest _kolejna_ rzecz którą trzeba rozpatrzyć przy analizie
bezpieczeństwa _systemu_. Natomiast tak - jest dość prosta i dość
skuteczna - kilkaset ms odstępu praktycznie niweluje możliwość ataku
brute-force (ale czasami generuje możliwość DoS).


Zakładasz security through obscurity? - niejawna funkcja generowania
podpisu. Nie różni się to wtedy od ataku na nieznany algorytm
szyfrujący. Jeśli nie - to masz prawie to samo.



Atakujący zazwyczaj jeżeli będzie rozważał brute-force to wykona go na
swoim klastrze a "na żywo" będzie testował tylko kolizje tam znalezione.

--
Pozdrawiam
Michoo

Thu Jul 25, 2013 10:56 pm   

On 25.07.2013 12:37, Piotr Gałka wrote:

W jakim kontekście to słyszałeś?


Skoro napisałeś o samym podpisywaniu bez wspominania o sekwencji to
uznałem że to przeoczyłeś, widzę, że niesłusznie.


Jest to kolejny element systemu który należy uwzględnić. W analizie
bezpieczeństwa nie można traktować czegoś jako "oczywiste" bo się można
przejechać. (Dla mnie oczywiste są numery sekwencyjne i oczywiste są
odpowiednio długie klucze oraz oczywiste są odpowiednie opóźnienia, ale
jak się tego nie zawrze w specyfikacji to wykonawca tego prawdopodobnie
NIE wykona.)



Tekst jawny/wiadomość jawna - odwrotność szyfrogramu.


Enigma szyfrowała teksty a nie bajty. Jeżeli masz ponad 50% szans, że
losowy bajt NIE jest elementem tekstu w języku angielskim to jest to
bardzo istotna informacja.



Tak, to nie ma sensu jak i wiele innych rozważań. Myślałem, że
rozmawiamy o teorii.


To może trzeba zacząć od pytania co siedzi w urządzeniu i co tak
właściwie atakujemy.


--
Pozdrawiam
Michoo

Fri Jul 26, 2013 8:52 am   

Użytkownik "Michoo" <michoo_news@vp.pl> napisał w wiadomości
news:kssa4v$ish$1@mx1.internetia.pl...


Zawsze zakładam, że niejawne są tylko klucze, a algorytmy jawne = zakładam
jawną funkcję generowania podpisu z niejawnym kluczem.

czynienia z kryptologią i pewne pojęcia jedynie obiły mi się o uszy.
To co poniżej piszę opieram na mojej matematycznej intuicji - nie mam
pewności, czy się gdzieś nie mylę.
Według mnie jeśli podpis jest na przykład 48 bitowy, a klucz podpisu 128
bitowy to przy metodzie brute firce po analizie jednej podpisanej transmisji
na swoim klastrze atakujący uzyska 2^80 domniemanych pasujących kluczy
(pracochłonność 2^128 na klastrze). Wśród wygenerowanych następnie dla
podpisania rozkazu, który chce się przesłać do systemu domniemanych 2^80
podpisów prawdopodobnie znajdą się wszystkie możliwe podpisy (jest ich tylko
2^4 więc na razie nie zbliżyliśmy się do celu.
Gdyby nawet przeanalizował podglądnięte 2^48 prawidłowo podpisanych
transmisji (analiza każdej to chyba kolejne 2^128 pracy dla klastra) to
zredukuje mu się liczba możliwych kluczy do 2^32. Teraz może już wygenerować
domniemane 2^32 podpisy. Jest ich mniej. Do ich sprawdzenia potrzebne jest
pasmo 2^32 atakowanego systemu, ale podglądnięcie 2^48 ramek wymagało pasma
2^48 atakowanego systemu - razem potrzebne pasmo atakowanego systemu 2^80
(no i robocizna klastra 2^176).

Bez korzystania ze swojego klastra do ataku brute force wymagane jest pasmo
2^48 atakowanego układu (a najprawdopodobniej 2^47) i ten jeden potrzebny
podpis jest znaleziony (klucza nadal nie mamy).

Wydaje mi się, że to oznacza, że atakowanie podpisu na swoim klastrze mija
się z celem.

Przy podpisie 64 bitowym wyjdzie mi, że można albo:
- generować losowe 2^64 podpisy i prawdopodobnie po 2^63 próbach się trafi,
- podglądać 2^64 transmisje i przy zaangażowaniu 2^192 robocizny klastra
uzyska się klucz.

Przy podpisie 96 bitowym wyjdzie mi (cały czas podkreślam, że to jest tylko
moje domniemanie):
- generowanie losowe 2^96 podpisów lub,
- podglądnięcie 2^32 ramek i 2^160 robocizny klastra i uzyska się klucz.

Widać, że podpis dłuższy od połowy długości klucza redukuje nakład pracy na
jego zaatakowanie brute-force.
Dlatego uważam, że podpis nie powinien być dłuższy od połowy długości klucza
podpisu.

Jak komuś 64 bitowy podpis za krótki to AES256 to tylko ze dwa razy więcej
roboty niż AES128 i można mieć podpis do 128 bitów.
P.G.

Fri Jul 26, 2013 10:13 am   

Użytkownik "Michoo" <michoo_news@vp.pl> napisał w wiadomości
news:kssb3h$l24$1@mx1.internetia.pl...

Wyraźnie podkreślali, że trzeba rozróżnić podpisywanie od szyfrowania bo
każde służy innemu celowi (co nie wyklucza algorytmów realizujących obie
rzeczy na raz - chodzi o zdawanie sobie sprawy co czemu służy).
Dalej, że na przykład w systemach bankowych złamanie podpisywania jest
groźniejsze niż złamanie szyfrowania. Złamanie szyfrowania pozwala podglądać
czyjeś operacje, a złamanie podpisywania pozwala je za niego wykonywać.
Dlatego oni uważają, że wiadomość należy najpierw podpisywać a dopiero potem
całość szyfrować. Atakujący musi najpierw zaatakować szyfrowanie. Gdyby mu
się to udało uzyska dostęp do śledzenia komunikacji, ale dopiero teraz może
zabrać się za drugi etap - łamanie podpisywania, aby mógł nie tylko śledzić,
ale też ingerować w wiadomości. Oni głównie zawodowo zajmują się analizą
systemów bankowych, kartowych itp. Twierdzą, że jeszcze nie trafili na
system bez czasem bardzo poważnych wad.
OIDP (czytałem 8 lat temu) jako przykład błędu podali, ze w jakimś systemie
hasła przed użyciem dalej były solone i wydłużane zgodnie ze sztuką, ale
programista wpadł na genialny pomysł przyspieszenia reakcji na błędne hasła
i zapisywał sobie gdzieś ich CRC.
Wydaje mi się, że jeśli się najpierw szyfruje a potem podpisuje to atakujący
może równolegle prowadzić atak na szyfrowanie i podpisywanie.


Zgadzam się z drugim zdaniem, ale użycie w tej samej wypowiedzi też tego
pierwszego zdania wywołuje moją reakcję.
Enigma zamieniała litery na litery a nie na bajty. Przy łamaniu brute-force
nie dostawało się bajtów tylko litery więc z klucza było 100% że każdy
uzyskany znak może być elementem tekstu w języku niemieckim.
Czytałem że jak w dwu kolejnych liniach napiszemy po 100 znaków dwóch
dowolnych tekstów w języku niemieckim (bez spacji) to spodziewana liczba
pozycji na których samogłoska będzie nad samogłoską wyniesie ileś tam (nie
pamiętam - może 12). Jeśli jednym z tych tekstów będzie losowy ciąg to
samogłoski wystąpią nad sobą znacznie rzadziej (jeśli tam było 12 to tu
mogło być 6).
Nie wiem, czy maszyny łamiące Enigmę mogły korzystać z tej właściwości czy
nie - nie wiem, czy to nie było za skomplikowane dla ówczesnego sprzętu. W
sumie z ciekawości chętnie bym się tego kiedyś dokładnie dowiedział
(dokładnie to najlepiej schemat takiej maszyny + jego zrozumienie) - tylko
ten ciągły brak czasu.


Ale nie rozmawiamy aby sobie pogadać (nie mam czasu) tylko aby rozstrzygnąć
ewentualne wątpliwości czy różnice zdań.
Jeśli coś w sposób dość oczywisty nie ma sensu to nie powinno w ogóle być
poruszane. Jeśli ktoś coś porusza to dla mnie oznacza, że uważa, ze to ma
sens i jeśli mam odmienne zdanie to jesteśmy na etapie różnicy zdań i
rozstrzygania wątpliwości.
Jeśli teraz (po tym jak się namęczyłem udowadniając, że to nie ma sensu)
twierdzisz, że to oczywiście nie ma sensu to sugeruje, że już od początku
wiedziałeś, że nie ma sensu. Sorry, ale jedyny wniosek jaki mi przychodzi do
głowy - nie szanujesz mojego czasu.

Swoją drogą jestem ciekaw czy jeszcze ktoś śledzi nasze dyskusje, czy już
sobie wszyscy odpuścili ten wątek.


jakiś rozkaz do urządzenia B. Ono go wykonuje. Podglądający zna znaczenie
rozkazu więc nie chodzi o ukrywanie sensu tego rozkazu. Pytającemu chodzi
jedynie o uniemożliwienie powtórzenia tego rozkazu. Wprowadzenie
niepowtarzalności rozkazu ale w znany sposób (dodanie numeru kolejnego)
załatwia jedną sprawę - nie można rozkazu powtórzyć. Pozostaje kwestia aby
ktoś postronny nie mógł tej jego kolejnej wersji wygenerować. Temu służy
podpis pozwalający urządzeniu B stwierdzić, ze rozkaz pochodzi od A. Czyli
dyskutujemy o podpisie.
P.G.

Fri Jul 26, 2013 6:46 pm   

W dniu 2013-07-26 12:13, Piotr Gałka pisze:


Ogólnie Panowie, skoro wybiegacie już tak teoretycznie, to warto
napomknąć jeszcze o czymś takim jak protokół AAA (authorization,
authentication, accounting). W prostych słowach określa potrzebne
mechanizmy aby wszystko było ok.


--
WS

Sat Jul 27, 2013 7:05 pm   

Śledzi, śledzi, ma nawet ambicje coś na tym skorzystać :)

Miłego, "kontyngentujcie"
Irek.N.

Mon Jul 29, 2013 8:33 am   

Użytkownik "Irek N." <jakis@taki.tajny.jest> napisał w wiadomości
news:kt15ma$hmi$1@news.dialog.net.pl...



Większe audytorium podnosi samozadowolenie wypowiadającego się :)


Temat wydaje mi się być wyczerpany lub prawie wyczerpany.
P.G.

Tue Jul 30, 2013 7:37 am   

On Mon, 29 Jul 2013 10:33:21 +0200, Piotr
Gałka<piotr.galka@cutthismicromade.pl> wrote:

Dyskusja z tematu wynikła ciekawa i pouczająca.

--
Marek

Tue Jul 30, 2013 8:43 am   

Użytkownik "Marek" <fake@fakeemail.com> napisał w wiadomości
news:almarsoft.6975956142007841060@news.neostrada.pl...

wiadomości) i zauważyłem, że pierwsze pytanie pochodziło do Ciebie.
Jak zacząłeś wykładać swoją teorię Xb -> Y to wyglądało jak wypowiedź kogoś,
kto ma sprawę dokładnie przemyślaną i chce wyłożyć ją pytającemu no i bez
sprawdzania założyłem, że jesteś jednym z odpowiadających a nie pytającym.
Gdybym wtedy to sprawdził to pewnie bym trochę inaczej odpowiadał na twoje
teksty - dyskutowałem jak z kimś kogo tezy trzeba zrozumieć i jak błędne
obalić, a nie jak z kimś komu raczej trzeba wyjaśniać a nie dyskutować.

Dyskusja na grupie nie jest w stanie przekazać tyle informacji ile można
znaleźć w książce. Ja polecam tę, co tu wspominałem. Wybrałem ją nie
przypadkowo, ale to było dawno. Teraz może bym wybrał inną.
P.G.

Tue Jul 30, 2013 9:49 am   

On Tue, 30 Jul 2013 10:43:45 +0200, Piotr
Gałka<piotr.galka@cutthismicromade.pl> wrote:


Historia była prosta, chciałem użyć XTEA bo jest w sam raz na
ograniczone zasoby i używałem go wcześniej z bootloaderem. Załozenie
było takie, aby komunikacja była tylko w jedną stronę (polecenie->
wykonanie) i była jak najkrótsza. Ustaliłem sobie klucz, liczbę rund
ustaliłem na 64. Zaszyfrowalem polecenie "włącz P1" aby przesłać je
do drugiego mcu. XTEA "zmieniła" polecenie na ciąg bajtów
"0x5693290689607436". Mcu2 odebrał ten strumień i prawidłowo
rozszyfrował na "włącz P1". Tylko, że jak ponownie wysłać ten sam
"tekst" to xtea wygeneruje ten sam ciąg "0x5693290689607436". Taki
sposób szyfrowania komunikacji nic nie da bo wystarczy powtórzyć sam
zaszyfrowany ciąg aby uzyskać ten sam efekt. Zdziwiło mnie, że zawsze
dostaję ten sam zaszyfrowany ciąg... i tak powstał ten wątek.

W gpg przy szyfrowaniu tego samego tekstu tym samym kluczem/hasłem
zawsze na wyjściu jest inny ciąg bajtów, od czego to zależy?

--
Marek

Tue Jul 30, 2013 11:18 am   

Użytkownik "Marek" <fake@fakeemail.com> napisał w wiadomości
news:almarsoft.3432653674957594115@news.neostrada.pl...

XTEA, gpg.
Obiło mi się o uszy pgp (może to miałeś na myśli) ale nic poza obiło się o
uszy.

Jak coś wydaje mi się ciekawe (a kryptologia jest ciekawa) to jest to dla
mnie wystarczający powód aby zrozumieć to dokładnie.
Nie znam tych narzędzi, gdyż na swoje potrzeby piszę wszystko od zera (w
oparciu o dokumenty NIST) - w ten sposób uważam, że lepiej można zrozumieć.

Algorytmy to jedno, a ich praktyczne zastosowanie to drugie. W tym drugim
łatwiej popełnić błąd.
Jak rozkaz jest szyfrowany zawsze tak samo to jest właśnie błąd w
praktycznym stosowaniu algorytmu.

Przykład błędu w stosowaniu algorytmu.
Masz super dobry algorytm. Szyfrujesz bitmapę, na której na białym tle jest
parę kresek rysunku (bajt = poziom szarości). Jeśli po prostu każde kolejne
16 bajtów przepuścisz przez ten algorytm to w szyfrogramie w zasadzie będzie
widać ten rysunek.

W większości zastosowań kryptologii atakujący nie powinien móc nic zrobić.
Jeśli szyfrogram jest zawsze taki sam, to atakujący może powtarzać stare
szyfrogramy (nawet ich nie rozumiejąc) a odbiorca przyjmie je jako
prawidłowe pochodzące od nadawcy. A to już jest coś a nie nic więc coś jest
nie tak.
P.G.

Tue Jul 30, 2013 12:08 pm   

On Tue, 30 Jul 2013 13:18:18 +0200, Piotr
Gałka<piotr.galka@cutthismicromade.pl> wrote:

xtea:
http://en.m.wikipedia.org/wiki/XTEA

gpg:
http://pl.m.wikipedia.org/wiki/GNU_Privacy_Guard

"dostępne gdzieś" gpg brzmi humorystycznie, mam nadzieję, że
żartujesz...

--
Marek