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

do góry

W dniu 22.07.2013 23:07, Marek pisze:
> 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.

Poczytaj o funkcjach haszujących.

--
Pozdrawiam
Jakub Rakus

do góry

On 22.07.2013 23:07, Marek wrote:
> 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",

google: replay attack

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

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

do góry

On Mon, 22 Jul 2013 23:34:47 +0200, Michoo <m...@v...pl> wrote:
> google: replay attack

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


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

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

--
Marek

do góry

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

do góry

W dniu 2013-07-22 23:07, Marek pisze:
> 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...
>


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







"Simply the best"

do góry

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_Au
thentication_Protocol.
Powinno się nadać po odpowiednim "przycięciu" do danego zastosowania.

do góry

Marek <f...@f...com> wrote:

> Jak w miarę prosty sposób uniemożliwić taki atak?

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/

do góry

Użytkownik "Adam Wysocki" <g...@s...invalid> napisał w wiadomości
news:gof.pme.1374561196@news.chmurka.net...
>
> 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.
>
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.

do góry

On 23.07.2013 00:43, Marek wrote:
> On Mon, 22 Jul 2013 23:34:47 +0200, Michoo <m...@v...pl> wrote:
>
>> 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.
>
> Czyli nie da się przeprowadzić bezpiecznej komunikacji TYLKO w jedną
> stronę (polecenie -> wykonanie) bez stosowania wzajemnej synchronizacji
> (nr sekwencyjne/jednorazowe kody/timestampy itp),
>

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

do góry