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

Mon Jul 22, 2013 9:07 pm   

Mam jakieś zaćmienie, problem może nie do końca z tematki grupy ale
w końcu dotyczy obszaru mikrokontrolerów więc zaryzukuję. Dwa mcu
komunikują się ze soba (UART), jeden wysyła polecenie (komunikat)
drugiemu, ten drugi wykonuje robotę w zależności od polecenia,
komunikacja jest w jedną stronę (mcu1->mcu2) i wg schematu: polecenie
-> wykonanie. Chciałbym zaszyfrować komunikację między tymi dwoma
mcu, aby nie można było podsłuchać komunikatu i go później
"podrzucić" do mcu2 wpinając się w uart. Założenie jest takie, że oba
mcu maja "w sobie" klucz, wybieram jakis dowolny cipher. I tu pojawia
się problem, bo generalnie szyfrownaie nic nie daje, bo: mcu 1
szyfruje polecenie X, dajac zaszyfrowany strumień, powiedzmy
"Gk16w123clh3RZdYbGZc8g", 2 mcu mając ten sam klucz deszyfruje
"Gk16w123clh3RZdYbGZc8g" dostając polecenie X i je wykonuje. Teraz
wystarczy "udawać" mcu1 i wysłać do mcu2 po prostu
"Gk16w123clh3RZdYbGZc8g", które zostanie odszyfrowane i spowoduje
wykonanie polecenia X. Jak w miarę prosty sposób uniemożliwić taki
atak? Wyobrażam sobie, że mcu2 może pierwszy nawiązywać komunikację i
stowrzyć "dialog", który (jeśli będzie prawidłowy) oznaczać będzie,
że druga strona ma prawidłowy klucz, czyli jest zaufana. Ale można
wyobrazić sobie, że będzie można całą sekwencje odpowiedzi mcu1
podrzucic na podstawie analizy statytycznej (np. wcześniej snifująć
komunkację), liczba możliwych kombinacji jesty wielka ale skończona,
więc nadal problem istnieje...

--
Marek

Mon Jul 22, 2013 9:10 pm   

W dniu 22.07.2013 23:07, Marek pisze:

Poczytaj o funkcjach haszujących.

--
Pozdrawiam
Jakub Rakus

Mon Jul 22, 2013 9:34 pm   

On 22.07.2013 23:07, Marek wrote:

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

--
Pozdrawiam
Michoo

Mon Jul 22, 2013 10:43 pm   

On Mon, 22 Jul 2013 23:34:47 +0200, Michoo <michoo_news@vp.pl> wrote:

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

--
Marek

Mon Jul 22, 2013 11:39 pm   

może coś w tę stronę
http://en.wikipedia.org/wiki/KeeLoq

Tue Jul 23, 2013 12:00 am   

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"

Tue Jul 23, 2013 2:37 am   

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.

Tue Jul 23, 2013 8:06 am   

Użytkownik "Adam Wysocki" <gof@somewhere.invalid> napisał w wiadomości
news:gof.pme.1374561196@news.chmurka.net...

seq=3 nada następną w której jest seq=4 ?
P.G.

Tue Jul 23, 2013 8:17 am   

On 23.07.2013 00:43, Marek wrote:

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.

--
Pozdrawiam
Michoo

Tue Jul 23, 2013 8:25 am   

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

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.

Tue Jul 23, 2013 8:33 am   

Marek <fake@fakeemail.com> wrote:


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.

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

Tue Jul 23, 2013 9:13 am   

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

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.

Tue Jul 23, 2013 9:46 am   

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?

Tue Jul 23, 2013 10:54 am   

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

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.

Tue Jul 23, 2013 3:29 pm   

Piotr Gałka <piotr.galka@cutthismicromade.pl> wrote:


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/