Problem z szyfrowaniem komunikacji między mcu

W dniu 22.07.2013 23:07, Marek pisze:

Poczytaj o funkcjach haszujących.

google: replay attack

Rozwiązań jest wiele - możesz umieszczać timestamp o ile jest wspólny, możesz przesyłać numer sekwencyjny i zapisywać go po obu stronach. Możesz zignorować problem bo może go tak naprawdę nie ma...

O właśnie tego szukałem, dziękuję.

Czyli nie da się przeprowadzić bezpiecznej komunikacji TYLKO w jedną stronę (polecenie -> wykonanie) bez stosowania wzajemnej synchronizacji (nr sekwencyjne/jednorazowe kody/timestampy itp),

może coś w tę stronę

W dniu 2013-07-22 23:07, Marek pisze:

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

"Simply the best"

Tak mi się przypomniało z dawnych czasów walk ze stosem protokołów powiązanych z PPP:

się nadać po odpowiednim "przycięciu" do danego zastosowania.

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 seq=10, 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.

Użytkownik "Adam Wysocki" snipped-for-privacy@somewhere.invalid napisał w wiadomości news: snipped-for-privacy@news.chmurka.net...

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.

Niestety nie. (Można wprawdzie robić "sec-by-obscurity" np doklejając przed szyfrowaniem trochę losowego śmiecia tak aby zaszyfrowany ciąg był za każdym razem inny istnieje ryzyko, że atakujący spróbuje wysłać ciąg bez odkodowania i ze zdziwieniem stwierdzi, że to działa.)

Zauważ tylko, że numer sekwencyjny jest rozwiązaniem prostym a jednocześnie wymaga synchronizacji jedynie na początku(a wtedy umieszczasz choćby klucze w obu procesorach). W czasie pracy odbiornik musi tylko sprawdzać, czy aktualny serial jest większy od ostatniego i jeżeli tak to go sobie zapisywać - komunikacja w jedną stronę wystarcza. Musisz oczywiście mieć jakieś sumy kontrolne, żeby odkodowanie śmieci (np z powodu zakłóceń) nie spowodowało padu komunikacji.

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

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.

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

Moją wiedzę o kryptografii opieram wyłącznie na moim zdaniem genialnej książce Ferguson, Schneier "Kryptografia w praktyce". Treść zgodna z tytułem = "w praktyce". Według nich złożoność każdego systemu to wróg bezpieczeństwa i nie należy tej złożoności podnosić wprowadzając zależność między podpisywaniem wiadomości, a jej szyfrowaniem. Złamanie szyfrowania nie powinno oznaczać jednoczesnego złamania podpisywania i odwrotnie. W tym co proponujesz CRC ma być podpisem (rozumiem, że ciąg {numer|rozkaz|crc} jest szyfrowany, lub crc po szyfrowaniu). Złamanie szyfrowania natychmiast daje dostęp do podpisywania. Jeśli treść rozkazu nie musi być ukrywana to można zakładać, że takie działanie to tylko podpisywanie. Nie znam się na tyle aby być pewnym, ale coś podejrzewam, że kryptolodzy z jakiegoś powodu uzupełnienia wiadomości crc i zaszyfrowania tego nie uznają za dobrej jakości podpisywanie bo gdyby tak uznawali to nie kombinowali by z jakimiś CMAC czy HMAC. Też na podstawie tej książki - nie ma jednomyślności wśród kryptologów czy wiadomość najpierw podpisywać, czy najpierw kodować. Numer może być przesyłany jawnie - można zaoszczędzić kodowania. Na przykład numer 8 bajtów, rozkaz 8 bajtów, podpis 8 bajtów. Podpis obejmuje numer i rozkaz = jeden blok 16 bajtowy. Wysyłany jest numer i 16 bajtowy wynik zakodowania rozkazu i podpisu. P.G.

W dniu 23.07.2013 11:13, Piotr Gałka pisze:

A nie chodzi w tym przypadku o to, że obecność crc w zaszyfrowanej wiadomości ułatwia sprawdzenie czy dobrze odszyfrowaliśmy wiadomość podczas ataku?

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

Raczej nie. Algorytmy szyfrujące z definicji mają być odporne również w przypadku ataku z tekstem jawnym. Większość udanych ataków w historii było atakami z tekstem jawnym. Łamanie Enigmy w zasadzie odbywało się z tekstem jawnym - zakładali typowy znany początek wiadomości, albo znając format komunikatów statków meteo przyjmowali znaną skąd inąd pozycję tych statków, a najłatwiej było jak po północy ktoś nadał wiadomość z wczorajszymi kluczami, a potem ją powtórzył z dzisiejszymi. Dlatego zawsze się zakłada, że atakujący zna, lub potrafi przewidzieć przynajmniej część tekstu jawnego. Poza tym zawsze trzeba zakładać, że atakującym może być autor danego systemu. P.G.

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

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

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?

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

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.

Użytkownik "Michoo" <michoo snipped-for-privacy@vp.pl napisał w wiadomości news:ksmrgi$5rd$ snipped-for-privacy@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.

Jak Ci wyszły te 32 bity ? P.G.

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