Problem z szyfrowaniem komunikacji między mcu

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

Użytkownik "Zbych" snipped-for-privacy@onet.pl napisał w wiadomości news:51f0dd5d$0$1228$ snipped-for-privacy@news.neostrada.pl...

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.

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

Użytkownik "Marek" snipped-for-privacy@fakeemail.com napisał w wiadomości news: snipped-for-privacy@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.

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.

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"... :-/

Użytkownik "Piotr Gałka" snipped-for-privacy@cutthismicromade.pl napisał w wiadomości news:ksqnfo$nmp$ snipped-for-privacy@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.

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)

Użytkownik "Michoo" <michoo snipped-for-privacy@vp.pl napisał w wiadomości news:ksqqvl$rli$ snipped-for-privacy@mx1.internetia.pl...

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

Spotkałem się raczej z tezą, że złamanie szyfrowania nie powinno dawać od 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.

Oczywiste, ale nie wiem po co to piszesz. Na tym etapie byliśmy na samym początku wątku.

Ciężko się z Tobą dyskutuje, bo co rusz wstawisz coś ni z gruszki ni z 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.

Pisałem o typowym zastosowaniu. 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.

Być może tak się rozumie atak z tekstem jawnym. 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.

Jest to podobno coraz tańsze. 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.

Użytkownik "Marek" snipped-for-privacy@fakeemail.com napisał w wiadomości news: snipped-for-privacy@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 ?

Proponowana przeze mnie metoda daje dla tej samej podpisywanej treści (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.

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.

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.

Użytkownik "Michoo" <michoo snipped-for-privacy@vp.pl napisał w wiadomości news:kssb3h$l24$ snipped-for-privacy@mx1.internetia.pl...

Było gdzieś w książce Fergusona i Schneiera o której wcześniej pisałem. 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.

Z pierwszej wiadomości w wątku mniej więcej wynika. Urządzenie A wysyła 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.

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

Śledzi. W miare wolnego czasu uważnie, ale nie komentuje ;)

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.

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

Miłego, "kontyngentujcie" ;) Irek.N.

Użytkownik "Irek N." snipped-for-privacy@taki.tajny.jest> napisał w wiadomości news:kt15ma$hmi$ snipped-for-privacy@news.dialog.net.pl...

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

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

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

Użytkownik "Marek" snipped-for-privacy@fakeemail.com napisał w wiadomości news: snipped-for-privacy@news.neostrada.pl...

Dopiero teraz otworzyłem sobie cały wątek (normalnie widzę tylko nowe 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.

wypowiedź kogoś,

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?