Użytkownik "Marek" <f...@f...com> napisał w wiadomości
news:almarsoft.4886869967084930227@news.neostrada.pl
...
> 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...
>
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.

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:ksleqr$lsb$1@mx1.internetia.pl...
>>
>> 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.
>
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.

do góry

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

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

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?

do góry

Użytkownik "Zbych" <a...@o...pl> napisał w wiadomości
news:51ee50e4$0$1223$65785112@news.neostrada.pl...
>W dniu 23.07.2013 11:13, Piotr Gałka pisze:
>
>> 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.
>
> 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?
>
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.

do góry

Piotr Gałka <p...@c...pl> wrote:

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

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/

do góry

On 23.07.2013 10:25, Piotr Gałka wrote:

> Potrzebujesz podpisywania, a nie szyfrowania.
> Przed poleceniem (nawet jawnym) umieść kolejny numer i całość podpisz
> (CMAC, HMAC).

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

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

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


--
Pozdrawiam
Michoo

do góry

On 23.07.2013 11:13, Piotr Gałka wrote:
> 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.

To nie jest wprowadzanie złożoności a jej redukcja.

> Złamanie szyfrowania nie powinno oznaczać jednoczesnego złamania
> podpisywania i odwrotnie.

Odważne słowa biorąc po uwagę popularność kryptografii asymetrycznej.

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

Protokoły szyfrowania zapewniają zazwyczaj też potwierdzenie
autentyczności - tylko posiadacz klucza może dokonać szyfrowania w
sposób zapewniający odszyfrowanie.

> Jeśli treść rozkazu
> nie musi być ukrywana to można zakładać, że takie działanie to tylko
> podpisywanie.

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.

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

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.

> Też na podstawie tej książki - nie ma jednomyślności wśród kryptologów
> czy wiadomość najpierw podpisywać, czy najpierw kodować.

Dla dobrych algorytmów nie ma to znaczenia. Natomiast odpowiednie
kombinacje pozwalają na użycie słabszych ale "tańszych" algorytmów.

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

Razem 32 bity - jak myślisz ile czasu zajmie kryptoanaliza wspomagana
metodą brute-force na jakimś i7?

--
Pozdrawiam
Michoo

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:ksmrch$4sf$2@mx1.internetia.pl...

>> 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.
>
> Szczerze mówiąc nie wiem jak skomentować umieszczenie w jednym zdaniu
> "2^64" i "wyczerpanie tej liczby".
>
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.

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:ksmrgi$5rd$1@mx1.internetia.pl...
>> 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.
>
> To nie jest wprowadzanie złożoności a jej redukcja.

Redukcja złożoności obliczeniowej, ale wprowadzanie zależności pomiędzy
poszczególnymi funkcjami systemu.

>> Złamanie szyfrowania nie powinno oznaczać jednoczesnego złamania
>> podpisywania i odwrotnie.
>
> Odważne słowa biorąc po uwagę popularność kryptografii asymetrycznej.

Mówiłem wyłącznie o kryptografii symetrycznej. O asymetrycznej wiem za mało
aby się wypowiadać.

>
>> 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.
>
> Protokoły szyfrowania zapewniają zazwyczaj też potwierdzenie
> autentyczności - tylko posiadacz klucza może dokonać szyfrowania w sposób
> zapewniający odszyfrowanie.

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.

>
>> Jeśli treść rozkazu
>> nie musi być ukrywana to można zakładać, że takie działanie to tylko
>> podpisywanie.
>
> 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.

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.

>> 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.
>
> Razem 32 bity - jak myślisz ile czasu zajmie kryptoanaliza wspomagana
> metodą brute-force na jakimś i7?
>
Jak Ci wyszły te 32 bity ?
P.G.

do góry

On Tue, 23 Jul 2013 10:25:36 +0200, Piotr
Gałka<p...@c...pl> wrote:
> 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
aby
> poprzedniego, ale prawidłowo podpisane.



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

do góry