Połaczenia SSH i bezpieczenstwo transmisji

[Cz@rny]

Dnia Mon, 06 Feb 2006 15:33:50 +0100, Marek Guevara Braun  
<marek.guevara w atm.com.pl> napisał:

> Są to blokowe algorytmy symetryczne (trzy pierwsze na pewno, RC4 pewnie
> też)

Arcfour (implementacja otwarta ukrywanego algorytmu RC4). RC4 jet szyfrem  
strumieniowym - miesza bity z pomieszanym kluczem.

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

  - ż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)

>
> 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?).  
OpenSSH na pewno implementuje MD5, które to ostatnio podobno jest łamane  
na PC-cie w ~15 minut, bodajrze SHA1, ale czy coś > 160 bitowego, to nie  
wiem. Na prawdę trzeba by się postarać, żeby złamanie tego coś dało -  
skrót zapewnia tylko integralność, czyli że nikt Ci nie wstrzyknie innych  
pakietów, a z czsem - niech i nawt będzie 5minutowym, to i tak gówno da,  
bo nie będzie w stanie proxować połączenia na bierząco.

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

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.

Zdroofka
Cz w rny
P.S.
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 ;/