Infrastruktura PKI na podstawie SSH

Infrastruktura kluczy publicznych (ang. Public Key Infrastructure, w skrócie PKI) jest podstawą współczesnej kryptografii. Miałem już styczność z wieloma osobami z branży IT, które kompletnie nie czuły o co właściwie w tym chodzi.Myślę, że poniższy tekst napewno się komuś przyda oraz, że warto mu poświęcić 5 minut. Spróbuję się maksymalnie streścić

Klucze symetryczne i niesymetryczne

Większość szyfrowanych kanałów transmisji wykorzystuje jednocześnie klucze niesymetryczne jak i symetryczne.

Zaletą kluczy symetrycznych (takich jak AES, Blowfish czy DES) jest szybkość szyfrowania/deszyfrowania przy stosunkowo niskim obciążeniu procesora.

Wadą kluczy symetrycznych jest etap nawiązania transmisji. Jeśli oba komputery nie posiadają tego samego klucza do szyfrowania/deszyfrowania wiadomości – klucz taki musiałby być wysłany z jednego z nich do drugiego drogą nieszyfrowaną. Taką wymianę klucza można byłoby łatwo podsłuchać. Następnie, korzystając z tak zdobytego klucza – można podsłuchać resztę transmisji (taki atak nosi nazwę Man In The Middle).

Dlatego właśnie pojawiły się klucze niesymetryczne (np. stosowany standardowo w protokole ssh – algorytm RSA). Klucz niesymetryczny składa się z dwóch części – publicznej i prywatnej. Posiadacz części publicznej klucza jest w stanie zaszyfrować wiadomość. Posiadacz klucza prywatnego – może taką wiadomość odszyfrować. Proste. Dodatkowo – na podstawie klucza publicznego jesteśmy w stanie zweryfikować odcisk klucza (fingerprint) – jeśli się zgadza, wiemy, że rozmawiamy z właściwym serwerem.

Klucze w praktyce

Serwery Linuxowe na których pracuje usługa ssh mają również wygenerowane swoje klucze. Autentykacja może być różnoraka, jednak do najpopularniejszych należą – para użytkownik-hasło oraz łączenie się z wykorzystaniem kluczy.

Wykorzystanie haseł jest proszeniem się o kłopoty. Warto przesiąść się na klucze. Jak to zrobić?

Wygenerujmy sobie klucz. W obecnych czasach warto zaznaczyć, że chcemy mieć klucz 4096-bitowy, będzie się generował dłużej, ale będzie bezpieczniejszy. Warto też ustawić hasło dla klucza.

nme@notebook ~ $ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/nme/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/nme/.ssh/id_rsa.
Your public key has been saved in /home/nme/.ssh/id_rsa.pub.
The key fingerprint is:
12:30:87:ca:06:81:d8:5a:32:41:81:4c:3a:74:33:a9 nme@notebook
The key's randomart image is:
+--[ RSA 4096]----+
|XO.++..          |
|X.+.++           |
|oB..  .          |
|.E+    .         |
| .    . S        |
|       .         |
|                 |
|                 |
|                 |
+-----------------+
nme@notebook ~ $

W katalogu .ssh pojawiły się dwa pliki id_rsa – będący naszym kluczem prywatnym oraz id_rsa.pub – czyli klucz publiczny.
Klucza publicznego nie trzeba specjalnie strzec. Ważne, aby nasz klucz prywatny nie dostał się w cudze ręce.

Po co ten obrazek w ASCII? Abyśmy nie musieli weryfikować znak po znaku naszych kluczy. Jeśli chcemy odczytać fingerprint klucza, wydajemy komendę:

ssh-keygen -l

Jeśli chcemy zobaczyć odcisk wraz z obrazkiem ASCII – wydajemy:

ssh-keygen -lv

Okej. Powiedzmy, że mamy klucze i serwer na który chcielibyśmy się łączyć za ich pomocą. Musimy umieścić zawartość naszego klucza publicznego w pliku .ssh/authorized_keys na serwerze docelowym. Możemy to zrobić komendą:

nme@notebook ~ $ ssh-copy-id serwer:
The authenticity of host 'serwer (x.x.x.x)' can't be established.
RSA key fingerprint is fe:2b:6b:71:6f:81:ef:07:74:89:72:e7:ef:ab:f8:62.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'serwer,x.x.x.x' (RSA) to the list of known hosts.
Password:
nme@notebook ~ $

teraz możemy już normalnie się zalogować:

nme@notebook ~ $ ssh serwer
nme@serwer ~ $

W pliku .ssh/authorized_keys możemy trzymać dowolną ilość kluczy.

Dobrą praktyką jest generowanie kluczy prywatnych na każdej stacji roboczej z której łączymy się na inne maszyny. W wypadku gdy np. ktoś ukradnie nam jedną z tych maszyn – wystarczy usunąć dane klucze z plików authorized_keys serwerów, do których mamy dostęp.

Skoro już opanowaliśmy klucze – warto wyłączyć autoryzację do naszych serwerów za pośrednictwem par użytkownik-hasło. Robimy to edytując plik /etc/ssh/sshd_config – weryfikujemy ustawienia:

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Restart sshd we współczesnych Ubuntu czy RedHatach wykonujemy komendą:

sudo service ssh restart

Kiedy wyłączymy już logowanie na pary użytkownik-hasło i pozostawimy jedynie logowanie na klucze:

nme@notebook ~ $ ssh serwer
Permission denied (publickey).
nme@notebook ~ $

Gdzie poza SSH stosowane są jeszcze klucze?

Infrastruktura kluczy publicznych (PKI) stosowana jest również przykładowo w HTTPS czy w sieciach bezprzewodowych – WPA2 (AES). Klucze niesymetryczne stosowane są do nawiązania transmisji między klientem i serwerem – celem wymiany klucza symetrycznego, a następnie transmisja jest już oparta o klucz symetryczny.

Znajomość ogólnych zasad działania PKI jest bardzo praktyczna również w przypadku, jeśli przymierzamy się do wykorzystania OpenPGP czy certyfikatów SSL, które możemy traktować jak wyższe stopnie zaawansowania