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

Tue Jul 23, 2013 8:57 pm   

On 23.07.2013 10:25, Piotr Gałka wrote:


No właśnie pytanie jest czego potrzeba. Czy użyje się
msg=serial+msg;
msg=msg+md5(md5(msg)+key);

czy
msg=serial+msg;
msg=3des(msg,key);

jest często kwestią gustu. Dobra funkcja skrótu jest dość długa więc
użycie jej może znacznie powiększyć wiadomość, z drugiej strony hash
liczy się często szybciej niż trwa szyfrowanie większych danych...


Szczerze mówiąc nie wiem jak skomentować umieszczenie w jednym zdaniu
"2^64" i "wyczerpanie tej liczby".


--
Pozdrawiam
Michoo

Tue Jul 23, 2013 8:59 pm   

On 23.07.2013 11:13, Piotr Gałka wrote:

To nie jest wprowadzanie złożoności a jej redukcja.


Odważne słowa biorąc po uwagę popularność kryptografii asymetrycznej.


Protokoły szyfrowania zapewniają zazwyczaj też potwierdzenie
autentyczności - tylko posiadacz klucza może dokonać szyfrowania w
sposób zapewniający odszyfrowanie.


Tak i nie - pojawiają się możliwości ataków z tekstem jawnym, więc
kryptografia musi być silniejsza. 32 bitowy klucz szyfrujący nieznany
tekst może spokojnie wystarczać do typowych zastosowań, 32 bitowy klucz
podpisujący jawne polecenie nie nadaje się do niczego o ile nie ma
naprawdę wielu rund.


To działa w drugą stronę - jeżeli potrzebujesz tylko uwierzytelnienie
długiej wiadomości to używasz HMAC, który jest tańszy obliczeniowo od
dobrego szyfrowania. Jeżeli chcesz mieć dodatkowe zapewnienia (jak np
niemożliwość podrobienia wiadomości przez obie strony) to uciekasz się
do kluczy asymetrycznych - i nadal jest to tańsze od szyfrowania całości
bo podpisujesz tylko skrót wiadomości. Ale gdy wiadomość jest krótka to
szyfrowanie może być optymalnym rozwiązaniem.


Dla dobrych algorytmów nie ma to znaczenia. Natomiast odpowiednie
kombinacje pozwalają na użycie słabszych ale "tańszych" algorytmów.


Razem 32 bity - jak myślisz ile czasu zajmie kryptoanaliza wspomagana
metodą brute-force na jakimś i7?

--
Pozdrawiam
Michoo

Wed Jul 24, 2013 6:50 am   

Użytkownik "Michoo" <michoo_news@vp.pl> napisał w wiadomości
news:ksmrch$4sf$2@mx1.internetia.pl...


Możliwe, że tam było 2^48 (nie pamiętam, wyszukanie w książce zajęło by mi
za dużo czasu, bo nie wiem przy jakiej okazji to pisali). Poza tym to są
jakieś wyliczenia teoretyczne, które zakładają brak praktycznych
ograniczeń - na przykład na liczbę ramek wysyłanych na sekundę. OIDP w
przykładach rozmieszczenia danych w bloku licznikowym (preferują tryb CTR)
stosują 32 bitowy licznik ramek i 32 bitowy licznik bloków w ramce.
Autorzy sugerując wybór odpowiednich algorytmów i wielkości kluczy itp.
zakładają, że tworzony obecnie system ma zapewnić bezpieczeństwo przez 50
lat. Wyjątkiem są systemy z kluczem publicznym, które gdyby miały zapewnić
bezpieczeństwo na 50 lat wymagały by znacznie dłuższych kluczy niż stosowane
obecnie i zbytnio obniżyły by wydajność systemów. Dlatego dla systemów
klucza publicznego zakładają niełamalność przez 20 lat, ale twierdzą, że
takie systemy (w przeciwieństwie do systemów z kluczem symetrycznym) muszą
być skalowalne, aby stopniowo, wraz ze wzrostem mocy obliczeniowych
zwiększać długość kluczy.
P.G.

Wed Jul 24, 2013 8:28 am   

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

Redukcja złożoności obliczeniowej, ale wprowadzanie zależności pomiędzy
poszczególnymi funkcjami systemu.


Mówiłem wyłącznie o kryptografii symetrycznej. O asymetrycznej wiem za mało
aby się wypowiadać.


Oczywiste jest, że nie posiadając klucza nie zaszyfruje się tak, aby dało
się odszyfrować i nie ma to związku z autentycznością (cały czas mówię o
kryptologii symetrycznej)

Co to znaczy "zazwyczaj" ?
Są takie co zapewniają i są takie co nie zapewniają.
Z tych co zapewniają słyszałem tylko o dwu:
- OCB - ale są osoby i instytucje roszczące sobie prawa patentowe do tego
trybu.
- CCM - uważam, że przy krótkich ramkach należało by użyć jakiejś prostszej
funkcji formatującej niż przedstawiona w standardzie, ale nie umiem być na
100% pewien, czy wymyślona przeze mnie funkcja rzeczywiście spełnia
określone w standardzie wymagania, a nie spełnienie jest jak rozumiem
naruszeniem bezpieczeństwa.


Tu mnie zadziwiasz.
Według mnie 32 bitowy podpis może być wystarczający do typowych zastosowań,
ale w żadnym przypadku nie oznacza to klucza 32 bitowego.
Natomiast użycie 32 bitowego klucza do szyfrowania tekstu (w ogóle do
czegokolwiek) wydaje mi się śmieszne.
Na moim (kilkuletnim) PC AES128 (napisany przez mnie tak, aby był czytelny,
a nie optymalny) wykonuje się poniżej 1us. Zakładam, że jakiś rozsądny
algorytm z kluczem 32 bity wykona się na przykład w 200ns. Przeszukanie
całej przestrzeni kluczy zajmie w takiej sytuacji 14 minut. Zawsze trzeba
zakładać atak z tekstem jawnym.
Poza tym jeśli szyfrowany jest tekst w znanym języku to komputerowa
weryfikacja, czy uzyskany tekst ma sens w tym języku nie zajmuje dużo czasu.
Zwiększenie liczby rund ma jedynie wpływ na możliwości analitycznego
poszukiwania klucza. Dla ataku siłowego ma znikome znaczenie bo wydłuża czas
tego ataku tylko wprost proporcjonalnie do liczby rund.
Poza tym nie znam żadnych algorytmów z kluczem 32 bity, a stosowanie
wymyślonych przez siebie algorytmów (nie sprawdzonych dogłębnie przez
znających się na rzeczy) jest proszeniem się o kłopoty.


P.G.

Thu Jul 25, 2013 7:57 am   

On Tue, 23 Jul 2013 10:25:36 +0200, Piotr
Gałka<piotr.galka@cutthismicromade.pl> wrote:



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

--
Marek

Thu Jul 25, 2013 8:10 am   

W dniu 25.07.2013 09:57, Marek pisze:

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/

Thu Jul 25, 2013 8:15 am   

On Thu, 25 Jul 2013 09:57:33 +0200, Marek <fake@fakeemail.com> wrote:

Tak naprawdę nie widzę różnicy między podpisywaniem a zwykłym
cmd+nrsek, gdzie nrsek jest jednorazowy. Bo w przypadku podpisywania
i bez niego mamy taka sama liczbę możliwych komunikatów
autoryzujacych dane polecenie. A jeśli polecenie miałoby być jedno to
w ogóle szał, bo wystarczyłby sam nrsek :-)

--
Marek

Thu Jul 25, 2013 8:26 am   

Użytkownik "Zbych" <abuse@onet.pl> napisał w wiadomości
news:51f0dd5d$0$1228$65785112@news.neostrada.pl...

zainstalowany na przykład wewnątrz sejfu odbiornik wykonał polecenie
"otwórz" ?
P.G.

Thu Jul 25, 2013 8:39 am   

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

podpisu?
P.G.

Thu Jul 25, 2013 8:54 am   

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

Jeśli znasz chociaż trochę angielski to powinieneś wiedzieć, że replay
oznacza "ponowne odtworzenie".
Rozmiar b nie ma nic wspólnego z możliwością lub niemożliwością ponownego
odtworzenia podsłuchanej komunikacji.

Natomiast możliwość łatwego wypróbowania wszystkich kombinacji jest
czynnikiem sprzyjającym atakowi siłowemu właśnie na tym polegającemu.


Podpisy CMAC HMAC nie muszą być ukrywane aby były bezpieczne.


Ten nierozwiązywalny według Ciebie problem da się rozwiązać na co najmniej
kilka sposobów.


Nie rozumiem koncepcji "w środku".
P.G.

Thu Jul 25, 2013 9:12 am   

On 25.07.2013 10:26, Piotr Gałka wrote:

Skoro rozpatrujemy atak powtórzeniowy to zakładamy dostęp do urządzenia
"zewnętrznego".

Więc po co oprogramowanie? Chińczyk bierze układ i rozpuszcza mu górę
opakowania, wkłada w mikroskop i robi zdjęcie. Pobiera z bazy informację
gdzie leżą lockbity i strzela np 3 razy laserem. Podpina układ do
programatora i odczytuje cały kod i eeprom.

Teraz można zrobić dokładną kopię układu.


--
Pozdrawiam
Michoo

Thu Jul 25, 2013 9:15 am   

On 24.07.2013 10:28, Piotr Gałka wrote:

No właśnie redukujesz złożoność programu (jedna funkcja zamiast dwóch)
kosztem złożoności obliczeń (szyfrowanie jest zazwyczaj droższe od
liczenia skrótu).


To tylko taka uwaga - całe public-key cryptography, które zajmuje się
zapewnianiem poufności i/lub autentyczności, opiera się o jedną parę kluczy.

Szyfrowanie w tym wypadku sprowadza się prawie zawsze (ze względu na
wydajność) do zaszyfrowania szyfrem symetrycznym i asymetrycznego
zaszyfrowania klucza.


Jak to nie ma? Zazwyczaj protokoły mają różnego rodzaju sumy kontrolne
aby sprawdzić, czy deszyfrowanie się powiodło - dzięki temu fakt
zdeszyfrowania wiadomości W kluczem K oznacza, że wiadomość została
wygenerowana przez posiadacza klucza K.

Oczywiście wymaga to kontroli integralności i kontrola
integralności+szyfrowanie w efekcie dają kontrolę autentyczności.


Replay attack to atak w którym w ogóle nie musisz znać tekstu jawnego i
klucza a jedynie szyfrogram - możesz mieć idealnie zaszyfrowaną
wiadomość z podpisami, sumami kontrolnym, etc a jeżeli jakoś nie
kontrolujesz sekwencji to nadal jesteś podatny.

Przykład:
obserwujesz, że po wiadomości W1 sterownik wykonuje akcję A1, nie masz
zielonego pojęcia co zawiera ta wiadomość, nie umiesz w nią ingerować
(np zmienić kąta ruchu z 10 na 5 stopni) ale wiesz, że zawsze na
wysłanie tej wiadomości reakcja będzie taka a taka.

Gorzej - masz algorytm działający w trybie ECB - widzisz, że zmieniają
się tylko dwa pierwsze bajty szyfrogramu(numer seryjny) - bez kontroli
integralności można skopiować numer seryjny z bieżącej wiadomości (np
"minął termin ważności licencji") i dokleić do starej wiadomości
("wykonaj działanie"). A cały czas nie wiesz co jest w tych wiadomościach.




To nadal nie rozwiązuje problemu ataku powtórzeniowego. W tym ataku
używa się poprawnej, poprawnie podpisanej wiadomości, która została
przechwycona wcześniej.



Mamy system komputerowy w którym administrator wysyła polecenia z 32
bitowym podpisem. Ile czasu potrwa wstrzelenie się sekwencyjnym podpisem
jeżeli łącze ma 10GB/s?


Możesz w stosunkowo krótkim czasie wygenerować wszystkie 2^32
potencjalne teksty jawne. Jeżeli tekst jawny wygląda jak losowe słowo to
który jest prawidłowy?

Natomiast, oczywiście, security by obscurity nie jest dobrym pomysłem.
Choćby dlatego, że łatwo je zepsuć - powiedzmy, że zabezpieczamy się
przed replay attack doklejając do słowa kodowego numer sekwencyjny - nie
można użyć klasycznej sekwencji bo wyjdzie to w kryptoanalizie, zamiast
tego musimy zastosować np tajny prng. Itd, etc.



Zdziwiłbyś się jak często się go w praktyce nie zakłada. Faktem jest, że
jest to nierozsądne.


"Atak z tekstem jawnym" nie znaczy tylko że znasz dokładnie wiadomość
ale, że znasz jej pewne własności. I np "tekst w języku naturalnym" jest
bardzo istotną własnością.


Jeżeli oryginalnie było 200ns to 14 minut nie jest problemem. Jeżeli
zrobisz z tego 500ms to nagle koszt wynajęcia chmury do łamania może być
niewart zysku z łamania.

Pamiętaj, że zdeterminowany atakujący o odpowiednim zapasie finansowym
potrafi np zdelaminować czip i po prostu odczytać klucz razem z algorytmem.


Zgadza się.


Widzę "bajty" czytam "bity"... :-/

--
Pozdrawiam
Michoo

Thu Jul 25, 2013 9:18 am   

Użytkownik "Piotr Gałka" <piotr.galka@cutthismicromade.pl> napisał w
wiadomości news:ksqnfo$nmp$1@somewhere.invalid...

Przy pierwszym czytaniu "wydłubanie" mylnie zrozumiałem jako napisanie od
nowa, a nie reverse engineering.
Kwestia zarządzania kluczami to oddzielne, bardzo złożone zagadnienie, o
którym mam zaledwie blade pojęcie.
Przede wszystkim w każdej instalacji klucze powinny być inne, ustalone
(wylosowane) przez użytkownika i nie znane producentowi urządzenia.
Zatem nie da się ich wydłubać z pierwszego lepszego urządzenia tego typu -
musi to być urządzenie z tego systemu.
Kradzież urządzenia z tego systemu powinna być zauważona i klucze zmienione
zanim chińczyk zdąży wydłubać te klucze i je dostarczyć.
Poza tym stosowane do podpisywania klucze są zazwyczaj wylosowanymi kluczami
sesji. Istnieją algorytmy (np. DH) pozwalające ustalić wspólny klucz sesji
tak, że ktoś podglądający całą transmisję i nawet znający całe zawartości
pamięci flash obu uzgadniających ze sobą klucz urządzeń nie jest w stanie
ustalić jaki klucz uzgodniono.
P.G.

Thu Jul 25, 2013 9:59 am   

On Thu, 25 Jul 2013 10:54:14 +0200, Piotr
Gałka<piotr.galka@cutthismicromade.pl> wrote:

Kryptografie analizuje jako strumien bajtów dający reakcje Y, nie
wnikam w sens strumienia (czy jest to szyfrowany komunikaty, czy
komunikaty z podpisem itp).
Wiec jeszcze raz:
Xb -> Y
Xb to ciąg bajtów o ograniczonej długości b wysłany z nadajnika,
który odpowiada za reakcje Y u odbiornika (wykonanie polecenia).
Transmisja jest zawsze jednokierunkowa i każda jedna transmisja
(prawidłowa) daje prawidłową reakcje Y.

W Twojej propozycji Xb było komunikatem zawierającym polecenie,
nrsekw i podpis. Ten nrsekw jest wlaśnie "w środku" strumienia
komunikatu i ma zapewnić unikalnosc.
Analizujac strumień Xb jest to nic innego jak jeden wielki nr
sekwencyjny, ktory może się pojawić tylko raz, ergo liczbę poleceń
mamy ograniczona liczba kombinacji Xb - liczba prawidłowych Xb.

Pytanie dodatkowe: czy proponowana przez Ciebie metoda podpisu daje
ten sam podpis dla tego samego komunikatu, czy ten sam komunikat
może generowac różne (prawidlowe) podpisy (podobnie jak hash
ograniczony kombinacja możliwych saltow)

--
Marek

Thu Jul 25, 2013 10:37 am   

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

OK.
Poprzednią Twoją wypowiedź interpretowałem trochę w oderwaniu od kontekstu i
stąd nieporozumienie.


razu dostępu do podpisywania.
Dlatego algorytmy, pozwalające podpisywać i szyfrować jednym kluczem są
bardziej złożone niż CRC (nawet 64b) i szyfrowanie.


początku wątku.


pietruszki. To się chyba nazywa trollowaniem.

Jeśli dalej będziemy dyskutować będę bez komentowania wycinał takie wstawki.
Temat algorytmów zapewniających jednocześnie szyfrowanie i podpisywanie jest
niezależnym tematem powstałym dlatego, że ktoś (może Ty) zasugerował CRC +
szyfrowanie.
Przecież konieczność rozróżnienia kolejnych poleceń i nie akceptowania
powtórzonych poleceń została ustalona już ileś tam wypowiedzi temu wstecz.


System nie reagujący na błędne podpisy (na przykład obniżeniem pasma) nie
jest według mnie typowy.
Obniżenie pasma to na przykład przyjęcie kolejnej ramki dopiero po 1ms jeśli
wystąpiły 3 kolejne błędne podpisy, po 2 ms gdy 4 błędne, po 4ms gdy 5
błędnych itd.
Nie obniża to pasma w przypadku przypadkowego przekłamania jednej ramki, ale
uniemożliwia atak siłowy na podpis.
Jak system przyjmuje wszystko jak leci i z pasmem 10GB/s to oczywiście
podpis powinien być dłuższy. Dla tak głupiego systemu pewnie 128bitów
minimum.


Użyłeś słowa tekst, co zrozumiałem jako tekst w jakimś języku, a nie
wiadomość wyglądającą losowo.


Ja pisząc o ataku z tekstem jawnym rozumiałem, że znam dokładnie kawałek
tego tekstu bo wyobrażam sobie zawsze te elektroniczno/mechaniczne maszyny
co amerykanie skonstruowali do łamania Enigmy, które sprawdzając wszystkie
kolejne możliwości porównywały (chyba) z konkretnym założonym kawałkiem
tekstu, a nie sprawdzały czy to co wyszło jest tekstem w języku niemieckim
(ale może się mylę - nie wiem jak dokładnie one działały).


Wydłużyłeś czas ataku siłowego _zaledwie_ 2 500 000 razy uzyskując przy
okazji kompletnie nieefektywny algorytm bo _aż_ 2 500 000 razy wolniejszy.
Odpowiada to wydłużeniu klucza o 21 bitów. Czyli jakby klucz zamiast 32
bitów (o których była mowa) miał 53 bity.
To nie ma sensu, gdy dostępne są algorytmy z kluczem 128 bitów (czy 256
bitów) działające na tym samym sprzęcie 500 000 razy szybciej od Twojego
rozwiązania z dodaniem całej masy rund.

Kilka lat temu był jakiś konkurs na łamanie DESa (klucz 56 bitów). Wygrał
jakiś hacker - już nie pamiętam, ale chyba kilka dni mu wystarczyło.


Klucza sesji nie ma w chipie. Oczywiście jeśli jest on wymieniany między
urządzeniami za pomocą kluczy symetrycznych to podglądając taką wymianę
atakujący pozna klucz sesji.
Ale jeśli urządzenia mają odpowiednio dobre generatory losowe a do ustalenia
kluczy stosują na przykład algorytm DH to analiza chipa nic nie da.
P.G.