Problem z szyfrowaniem komunikacji między mcu - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Polish to

Threaded View
Re: Problem z szyfrowaniem komunikacji między mcu
On Tue, 30 Jul 2013 10:43:45 +0200, Piotr  
Quoted text here. Click to load it
wypowiedź kogoś,  
Quoted text here. Click to load it
i bez  
Quoted text here. Click to load it
pytającym.

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

Re: Problem z szyfrowaniem komun ikacji między mcu

Quoted text here. Click to load it
Nie mam zielonego pojęcia o dostępnych gdzieś narzędziach. Nie wiem co to  
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.  


Re: Problem z szyfrowaniem komunikacji między mcu
On Tue, 30 Jul 2013 13:18:18 +0200, Piotr  
Quoted text here. Click to load it
co to  
Quoted text here. Click to load it
obiło się o  
Quoted text here. Click to load it

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

Re: Problem z szyfrowaniem komun ikacji między mcu


Quoted text here. Click to load it
Jakby więcej jest tu:
http://en.wikipedia.org/wiki/XTEA

AES pochodzi z konkursu z 1997 roku i jest implementowany hardwareowo w  
wielu procesorach więc nie szukałem innego algorytmu.
Wychodzi na to, ze XTEA został opisany w 1997 roku w jakimś raporcie  
wewnętrznym.
Ciekawe:
- kiedy stał się publicznie znany,
- czy jest efektywniejszy od AES (może kiedyś porównam wydajność).

Quoted text here. Click to load it
Na pierwszy rzut oka rozumiem, że gpg to bardziej aplikacja niż algorytm.

Quoted text here. Click to load it

Wcale nie żartowałem. Tak użyte pojęcie gdzieś jest dla mnie po prostu  
szersze od pojęcia internet, czy wikipedia, a nie chciało mi się sprawdzać  
co to takiego to gpg i gdzie to może być dostępne.
Nigdy wcześniej się nie spotkałem, a o pgp to słyszałem tylko tyle, że  
autora wsadzili za złamanie embarga na algorytmy 128 bitowe.
P.G.  


Re: Problem z szyfrowaniem komunikacji między mcu
W dniu 2013-07-22 23:07, Marek pisze:
Quoted text here. Click to load it


Szyfrujesz okreslonym ciagiem kluczy, w takim wypadku jesli bylo by  
powtorzenie tego samego ciagu  to mcu2 odrzuca jako nieautoryzowane i już.







"Simply the best"

Re: Problem z szyfrowaniem komunikacji między mcu
Tak mi się przypomniało z dawnych czasów walk ze stosem protokołów
powiązanych z PPP:
https://en.wikipedia.org/wiki/Challenge-Handshake_Authentication_Protocol .
Powinno się nadać po odpowiednim "przycięciu" do danego zastosowania.

Re: Problem z szyfrowaniem komunikacji między mcu

Quoted text here. Click to load it

Niech razem z poleceniem (przed zaszyfrowaniem) przesyłany będzie numer  
sekwencyjny, powiedzmy seq. Bez szyfrowania wyglądałoby to tak:

seq=1 polecenie
seq=2 polecenie
seq=3 polecenie

itd.

MCU2 ma zapisany numer sekwencyjny, którego się spodziewa (o 1 większy, niż  
ostatnio odebrany). Jeżeli dostanie numer mniejszy, to ignoruje polecenie.  
Jeżeli identyczny, to OK. Jeżeli większy... to już zależy od Ciebie, możesz  
zrobić np. okno resynchronizacji, tak żeby umożliwić zgubienie X komunikatów,  
czyli jeżeli MCU2 spodziewa się np. seq=4, a dostanie seq10%, to sprawdza czy  
10-4 mieści się w jakimś założonym zakresie i jeżeli tak, to wykonuje polecenie  
i ustawia spodziewany numer na 11.

Z tego co pamiętam podobnie jest to zrobione w KeeLoq.

--  
"zanim nastala era internetu, kazdy wiejski glupek siedzial w swojej wiosce"
http://www.chmurka.net/

Re: Problem z szyfrowaniem komunikacji między mcu

Quoted text here. Click to load it
Widzisz jakiś problem w tym, że ktoś, kto podsłucha transmisję w której jest  
seq=3 nada następną w której jest seq=4 ?
P.G.  


Re: Problem z szyfrowaniem komunikacji między mcu

Quoted text here. Click to load it

Te numery byłyby szyfrowane razem z właściwą wiadomością, dopiero po  
deszyfracji MCU2 widziałby numer.

--  
"zanim nastala era internetu, kazdy wiejski glupek siedzial w swojej wiosce"
http://www.chmurka.net/

Re: Problem z szyfrowaniem komun ikacji między mcu

Quoted text here. Click to load it
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  
poprzedniego, ale prawidłowo podpisane.
Są jakieś teoretyczne wyliczenia do ilu takich ramek podpis bazujący na  
kluczu 128 bit można uznać za bezpieczny. Są to ilości chyba rzędu 2^64.
Po wyczerpaniu tej liczby należy wymienić klucze, w żadnym wypadku nie wolno  
umożliwić liczenia od początku z tym samym kluczem.
P.G.


Re: Problem z szyfrowaniem komunikacji między mcu
On 23.07.2013 10:25, Piotr Gałka wrote:

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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


--  
Pozdrawiam
Michoo

Re: Problem z szyfrowaniem komun ikacji między mcu


Quoted text here. Click to load it
Faktycznie może być podejrzane. Nawet jakby nie w jednym zdaniu :).
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.  


Re: Problem z szyfrowaniem komunikacji między mcu
On Tue, 23 Jul 2013 10:25:36 +0200, Piotr  
Quoted text here. Click to load it
podpisz (CMAC,  
Quoted text here. Click to load it
aby  
Quoted text here. Click to load it



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

Re: Problem z szyfrowaniem komunikacji między mcu
W dniu 25.07.2013 09:57, Marek pisze:
Quoted text here. Click to load it

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/


Re: Problem z szyfrowaniem komun ikacji między mcu

Quoted text here. Click to load it
Jakie oprogramowanie miałby wydłubać chińczyk aby bez łamania podpisów  
zainstalowany na przykład wewnątrz sejfu odbiornik wykonał polecenie  
"otwórz" ?
P.G.  


Re: Problem z szyfrowaniem komunikacji między mcu
On 25.07.2013 10:26, Piotr Gałka wrote:
Quoted text here. Click to load it

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

Re: Problem z szyfrowaniem komun ikacji między mcu

Quoted text here. Click to load it

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.  


Re: Problem z szyfrowaniem komunikacji między mcu
Quoted text here. Click to load it

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

Re: Problem z szyfrowaniem komun ikacji między mcu

Quoted text here. Click to load it
A widzisz różnicę między złożonym w US PITem (nrsek to rok) z podpisem i bez  
podpisu?
P.G.  


Re: Problem z szyfrowaniem komun ikacji między mcu

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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


Site Timeline