Połaczenia SSH i bezpieczenstwo transmisji

[Marek Guevara Braun]

Cz w rny wrote:
> Dnia Mon, 06 Feb 2006 15:33:50 +0100, Marek Guevara Braun  
> <marek.guevara w atm.com.pl> 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