eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaProblem z szyfrowaniem komunikacji między mcuRe: Problem z szyfrowaniem komunikacji między mcu
  • Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
    atman.pl!news.chmurka.net!.POSTED!not-for-mail
    From: Piotr Gałka <p...@c...pl>
    Newsgroups: pl.misc.elektronika
    Subject: Re: Problem z szyfrowaniem komunikacji między mcu
    Date: Thu, 25 Jul 2013 12:37:07 +0200
    Organization: news.chmurka.net
    Lines: 152
    Message-ID: <ksqv4l$r7d$1@somewhere.invalid>
    References: <a...@n...neostrada.pl>
    <ksk95q$q9c$1@mx1.internetia.pl>
    <a...@n...neostrada.pl>
    <ksleqr$lsb$1@mx1.internetia.pl> <kslhgf$6f9$1@somewhere.invalid>
    <ksmrgi$5rd$1@mx1.internetia.pl> <kso373$den$1@somewhere.invalid>
    <ksqqvl$rli$1@mx1.internetia.pl>
    NNTP-Posting-Host: 213.192.88.238
    Mime-Version: 1.0
    Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response
    Content-Transfer-Encoding: 8bit
    X-Trace: somewhere.invalid 1374748629 27885 213.192.88.238 (25 Jul 2013 10:37:09 GMT)
    X-Complaints-To: abuse-news.(at).chmurka.net
    NNTP-Posting-Date: Thu, 25 Jul 2013 10:37:09 +0000 (UTC)
    X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
    X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
    X-Priority: 3
    X-Authenticated-User: PiotrGalka
    X-MSMail-Priority: Normal
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:650314
    [ ukryj nagłówki ]


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

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

    >
    > Oczywiście wymaga to kontroli integralności i kontrola
    > integralności+szyfrowanie w efekcie dają kontrolę autentyczności.
    >
    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.

    >
    > 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.
    >
    Oczywiste, ale nie wiem po co to piszesz. Na tym etapie byliśmy na samym
    początku wątku.

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

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

    >> Natomiast użycie 32 bitowego klucza do szyfrowania tekstu (w ogóle do
    >> czegokolwiek) wydaje mi się śmieszne.
    >
    > 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?

    Użyłeś słowa tekst, co zrozumiałem jako tekst w jakimś języku, a nie
    wiadomość wyglądającą losowo.

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

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

    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.

    >
    > Pamiętaj, że zdeterminowany atakujący o odpowiednim zapasie finansowym
    > potrafi np zdelaminować czip i po prostu odczytać klucz razem z
    > algorytmem.
    >
    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.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: