[EMAIL PROTECTED] wrote: > Dnia Mon, 06 Feb 2006 15:33:50 +0100, Marek Guevara Braun > <[EMAIL PROTECTED]> napisał:
>> Klucz symetryczny jakoś tam jest wymieniany między klientem a serwerem >> (zakładam, że bezpiecznie) > > Diffie-Hellman? Uzgadnianie kluczy z założeniem, że atakujący ma dostęp do > całośći transmisji - niezły bajer BTW. Nie czytałem RFC od SSH, ale warto się upewnić, że stosowany algorytm D-H nie korzysta "na skróty" w żaden sposób z generowanego "raz" prywatnego klucza serwera jako podstawy do wymiany informacji - byłoby tak gdyby np. tajna liczba którą wybierałby serwer w ramach D-H zależała by w prosty sposób od "tajnej" wartości klucza prywatnego - wtedy znając ten klucz (co było by równoważne ze znajomością/możliwością prostego wyliczenia naszej tajnej liczby po stronie serwera oraz tajnego klucza serwera) i posiadając zapis wymiany danych ze sniffera moglibyśmy wyliczyć, tajną liczbę po stronie klienta oraz zależny od niej tajny klucz po stronie klienta. ZTCP Diffie-Hellmann jest podatny dodatkowo na atak typu man-in-the-middle - komunikaty serwer -> klient powinny być w jakiś sposób sygnowane przez serwer, czyli znając klucz publiczny serwera możemy stwierdzić że dogadujemy się z właściwym serwerem, a nie z pośrednikiem, jeśli natomiast nie znamy klucza publicznego to takiej pewności nie mamy. >> - żeby ktoś mógł odczytać transmitowane dane >> musi mieć dostęp do klucza szyfrującego/deszyfrującego - zgadnąć go lub >> przechwycić w momencie wymiany przy nawiązywaniu sesji (zakładam, że >> sama wymiana jest szyfrowana asymetrycznie, gdzie rolę odgrywają >> prywatne klucze serwera - jeśli masz dostęp do kluczy prywatnych serwera >> SSH - a tak jest np. w przypadku bootowania systemu z płytki RescueCD - >> wyciągnąć klucz symetryczny będzie pewnie łatwiej. > > Jeżeli uzgadniają klucz do późniejszego szyfrowania symetrycznego przy > pomocy Diffiego-Hellmana, to nawet przy przehwyceniu wszystkich danych tej > wymiany, klucz pozostaje dla atakującego nieznany. Bezpieczeństwo opiera > się na niemożności rozkładu dużych liczb na składniki w postaci liczb > pierwszych w czasie wielomianowym - czyli ta sama gwarancja, jaką mają > szyfry asymetryczne (RSA o którym piszesz chociażby) Gorzej jeśli byśmy mogli zgadnąć jaką liczbę wybierze serwer. Zagadnienie w sumie ciekawe może nawet mnie to zmobilizuje do przeczytania specyfikacji kex w SSH :-) >> Same algorytmy szyfrowania mogą być stosowane z różnymi funkcjami >> mieszającymi - np ECB lub CBC dla AES-a - dla tej pierwszej dane są >> szyfrowane blokami 128-bitowymi przy pomocy klucza lub wybranego/znanego >> fragmentu klucza (dla kluczy 192 i 256 bitów) - jeśli mamy w danych np. >> jednolite fragmenty, to będą one zaszyfrowane tak samo (ew. będzie można >> wychwycić odpowiedni wzorzec) [*] - bodajże dwukrotnie wolniejszy >> AES-CBC pozbawiony jest tej cechy, gdyż to czym szyfrowane są kolejne >> bloki zależy od zaszyfrowanej postaci poprzedniego bloku - jednolite >> obszary danych nie będą szyfrowane do tj samej postaci. > > E?? ECB i CBC to są tryby szyfrowania blokowego, to nie ma nic wspólnego z > funkcją mieszającą (hashującą - to masz na myśli? funkcję skrótu?). Prawdę mówiąc nie miałem na myśli funkcji haszujących, a dokładnie to co robi CBC - czyli tzw. funkcje/tryby wiązania zaszyfrowanych bloków. >> Podsumowując - przy transmisji SSH używaj wersji 2.0, sprawdzaj z kim >> rozmawiasz - jak najwcześniej rób połączenie tak byś miał publiczny >> klucz serwera u siebie, a przy nowym połączeniu sprawdź czy odcisk >> klucza serwera, który wyświetli się w okienku PuTTY lub openssh >> odpowiada kluczom serwera. Pilnuj kluczy prywatnych serwera oraz >> generalnie zabezpiecz serwer :-) > > Ee - manualna robota. Rządać potwierdzeń certyfikatów przy nawiązywaniu > połączenia SSL i automat sprawdzający certyfikaty sam zweryfikuje, czy > rozmawiasz, z kim chcesz rozmawiać. Dla SSH nie spotkałem się jeszcze z instytucją CA w rozumieniu takiego SSL/TLS czy chociażby PGP. Obawiam się że jedyne co mamy to ręczne sprawdzenie odcisku klucza serwera podczas pierwszej transmisji. > SSH w ogóle implementuje wiele innych trików, typu ukrywanie sytuacji > ułatwiającej łamanie, jak np. krótkie komunikaty, czy takie same znaki. Do > tego renegocjuje klucz do szyfrowania symetrycznego co 1GB/1h (które > wcześniej) i wiele innych tego typu tricków. A to całkiem miłe. > A to wszystko w świetle zalanego dziś egzamu z Ochrony Danych (podobnie > jak 36 innych osób i tylko 3 zdały ;/), bo profesorowi nie podobała się > sala ;/ No to powodzenia, nawiasem mówiąc dobre rozpracowanie KEX pewnie dało by Ci +n przy egzaminie 8-) Pozdrawiam, Marek _______________________________________________ pld-users-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
