7.2. Automatyczna wymiana kluczy

W poprzedniej sekcji, szyfrowanie odbywało się za pomocą prostych kluczy. Innymi słowy, aby pozostać bezpiecznym, musiałbyś wymieniać konfigurację przez zestawiony uprzednio bezpieczny kanał. Jeśli musielibyśmy skonfigurować zdalnego hosta przez telnet, dowolny użytkownik mógłby podsłuchać klucze i konfiguracja nie byłaby bezpieczna.

Co więcej, ponieważ klucz jest współdzielony - nie jest już wcale tajny. Zdalny partner nie jest w stanie zrobić wiele znając go, ale mając wielu partnerów musimy zadbać by z każdym rozmawiać za pomocą różnych kluczy. Wymaga to dużej ilości kluczy - przy 10 partnerach musimy znać przynajmniej 50 różnych kluczy.

Poza problemami związanymi z kluczem symetrycznym, mamy jeszcze problem zmiany klucza. Jeśli osoba postronna podsłucha odpowiednio dużo ruchu, może być w stanie odzyskać klucz i odczytać nasze transmisje. Zapobiega się temu zmieniając regularnie klucz, ale należy to oczywiście zautomatyzować.

Inny problem związany z manualnym zarządzaniem kluczami jest dokładne ustalenie z partnerem parametrów połączenia - algorytmów szyfrowania i/lub uwierzytelniania. Wygodniej jest móc określić regułę w postaci 'Możemy używać 3DESa i Blowfish z kluczami o przynajmniej takiej a takiej długości'.

Aby rozwiązać te problemy, IPsec wprowadził standard wymiany kluczy w Internecie (ang. "Internet Key Exchange", IKE). Umożliwia on automatyczną wymianę losowo generowanych kluczy, wykorzystującą technologię szyfrowania asymetrycznego zgodnie z wynegocjowanymi z partnerem parametrami.

Implementacja IPsec Linuksa 2.5 działa z demonem 'racoon' pochodzącym z projektu KAME. Od 9 listopada wersja oparta o racoon znajduje się w dystrybucji iptools Aleksieja, aczkolwiek żeby ją skompilować będziesz musiał usunąć #include <net/route.h> w dwóch plikach. Możesz również ściągnąć wersję prekompilowaną.

IKE wymaga dostępu z Internetu do portu 500/udp, upewnij się że iptables nie blokują go.

7.2.1. Teoria

Tak jak wyjaśniałem wcześniej, automatyczna zmiana kluczy może wykonać za nas masę pracy. Dokładniej rzecz biorąc, tworzy SA "w locie". Nie powoduje jednak pojawienia się reguł bezpieczeństwa i w zasadzie tak powinno być.

Żeby skorzystać z IKE, skonfiguruj regułę ale nie wskazuj SA. Kernel w momencie odkrycia reguły IPsec bez SA powiadomi demon IKE, który z kolei postara się odpowiednie SA wynegocjować.

Powtórzmy to jeszcze raz: SP opisuje CO chcemy uzyskać, a SA JAK chcemy to zrobić. Zastosowanie demona IKE automatycznie wymieniającego klucze umożliwia nam ograniczenie się tylko do wskazania, CO chcemy uzyskać.

7.2.2. Przykład

Racoon w wersji KAME dostarczany jest z całą masą opcji, z których większość ma bardzo dobre ustawienia domyślne więc nie będziemy ich modyfikować. Tak jak opisałem powyżej, musimy zdefiniować reguły bezpieczeństwa (SP) a nie SA. Pozostawimy ich negocjację demonowi IKE.

W tym przykładzie, 10.0.0.11 i 10.0.0.216 ponownie chcą zestawić kanał komunikacyjny, ale tym razem z pomocą demona racoon. Dla zachowania przejrzystości konfiguracji użyjemy współdzielonych kluczy (ang. "pre-shared keys"). Zastosowanie do uwierzytelnienia partnerów certyfikatów X.509 opisano w osobnym rozdziale, zajrzyj do Sekcja 7.2.3.

Użyjemy prawie domyślnej konfiguracji, identycznej na obu hostach:

path pre_shared_key "/usr/local/etc/racoon/psk.txt";

remote anonymous
{
        exchange_mode aggressive,main;
        doi ipsec_doi;
        situation identity_only;

       my_identifier address;

       lifetime time 2 min;   # sec,min,hour
       initial_contact on;
       proposal_check obey;       # obey, strict or claim

       proposal {
               encryption_algorithm 3des;
               hash_algorithm sha1;
               authentication_method pre_shared_key;
               dh_group 2 ;
       }
}
 
sainfo anonymous
{
        pfs_group 1;
        lifetime time 2 min;
        encryption_algorithm 3des ;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate ;
}

Wiele ustawień - myślę że można usunąć więcej by zbliżyć się do domyślnej konfiguracji. Parę rzeczy wartych zwrócenia uwagi - stworzyliśmy dwie sekcje anonimowe pasujące dla wszystkich partnerów zdalnych co ułatwia znakomicie konfigurację. Nie musimy definiować wszystkiego per-host, chyba że bardzo chcemy.

Co więcej, konfiguracja została wykonana w ten sposób, że identyfikowani jesteśmy na podstawie adresu IP ('my_identifier address') i deklarujemy, że jesteśmy w stanie używać algorytmów 3DES, SHA-1 oraz, że będziemy używać współdzielonego klucza zlokalizowanego w pliku psk.txt.

W rzeczonym pliku psk.txt wpisujemy po jednej linicje, która różnić się będzie na obu hostach. Na 10.0.0.11 będzie to:

10.0.0.216       password2

a na 10.0.0.216:

10.0.0.11       password2

Upewnij się że właścicielem tych plików jest root i uprawnienia do nich ustawiono na 0600 - w innym przypadku racoon nie będzie chciał ich użyć. Jeśli jeszcze tego nie zauważyłeś, zwróć uwagę że te dwa pliki są swoimi lustrzanymi odbiciami.

Teraz jesteśmy w stanie skonfigurować żądaną SP, która jest bardzo prosta. Na hoście 10.0.0.216:

#!/sbin/setkey -f
flush;
spdflush;

spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
       esp/transport//require;

spdadd 10.0.0.11 10.0.0.216 any -P in ipsec
       esp/transport//require;

I na 10.0.0.11:

#!/sbin/setkey -f
flush;
spdflush;

spdadd 10.0.0.11 10.0.0.216 any -P out ipsec
       esp/transport//require;

spdadd 10.0.0.216 10.0.0.11 any -P in ipsec
       esp/transport//require;

Tu również widać, że SP są swoimi lustrzanymi odbiciami.

W tym momencie jesteśmy gotowi do uruchomienia racoon! Jeśli już działa, zainicjowanie ruchu z 10.0.0.11 do 10.0.0.216 lub odwrotnie (np. za pomocą telnetu) spowoduje rozpoczęcie przez racoon negocjacji:

12:18:44: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA
  request for 10.0.0.11 queued due to no phase1 found.
12:18:44: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new
  phase 1 negotiation: 10.0.0.216[500]<=>10.0.0.11[500]
12:18:44: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Aggressive mode.
12:18:44: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: 
  KAME/racoon
12:18:44: NOTIFY: oakley.c:2037:oakley_skeyid(): couldn't find
  the proper pskey, try to get one by the peer's address.
12:18:44: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA
  established 10.0.0.216[500]-10.0.0.11[500] spi:044d25dede78a4d1:ff01e5b4804f0680
12:18:45: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new phase 2 
  negotiation: 10.0.0.216[0]<=>10.0.0.11[0]
12:18:45: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: 
  ESP/Transport 10.0.0.11->10.0.0.216 spi=44556347(0x2a7e03b)
12:18:45: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established:
  ESP/Transport 10.0.0.216->10.0.0.11 spi=15863890(0xf21052)

Jeśli w tym momencie wykonamy polecenie `setkey -D', które pokazuje nam nasze SA, powinny wyglądać mniej więcej tak:

10.0.0.216 10.0.0.11 
       esp mode=transport spi=224162611(0x0d5c7333) reqid=0(0x00000000)
       E: 3des-cbc  5d421c1b d33b2a9f 4e9055e3 857db9fc 211d9c95 ebaead04
       A: hmac-sha1  c5537d66 f3c5d869 bd736ae2 08d22133 27f7aa99
       seq=0x00000000 replay=4 flags=0x00000000 state=mature 
       created: Nov 11 12:28:45 2002       current: Nov 11 12:29:16 2002
       diff: 31(s)       hard: 600(s)       soft: 480(s)
       last: Nov 11 12:29:12 2002       hard: 0(s)       soft: 0(s)
       current: 304(bytes)       hard: 0(bytes)       soft: 0(bytes)
       allocated: 3       hard: 0       soft: 0
       sadb_seq=1 pid=17112 refcnt=0
10.0.0.11 10.0.0.216 
       esp mode=transport spi=165123736(0x09d79698) reqid=0(0x00000000)
       E: 3des-cbc  d7af8466 acd4f14c 872c5443 ec45a719 d4b3fde1 8d239d6a
       A: hmac-sha1  41ccc388 4568ac49 19e4e024 628e240c 141ffe2f
       seq=0x00000000 replay=4 flags=0x00000000 state=mature 
       created: Nov 11 12:28:45 2002       current: Nov 11 12:29:16 2002
       diff: 31(s)       hard: 600(s)       soft: 480(s)
       last:                            hard: 0(s)       soft: 0(s)
       current: 231(bytes)       hard: 0(bytes)       soft: 0(bytes)
       allocated: 2       hard: 0       soft: 0
       sadb_seq=0 pid=17112 refcnt=0

Powinny być również widoczne reguły bezpieczeństwa, które skonfigurowaliśmy sami:

10.0.0.11[any] 10.0.0.216[any] tcp
       in ipsec
       esp/transport//require
       created:Nov 11 12:28:28 2002 lastused:Nov 11 12:29:12 2002
       lifetime:0(s) validtime:0(s)
       spid=3616 seq=5 pid=17134
       refcnt=3
10.0.0.216[any] 10.0.0.11[any] tcp
       out ipsec
       esp/transport//require
       created:Nov 11 12:28:28 2002 lastused:Nov 11 12:28:44 2002
       lifetime:0(s) validtime:0(s)
       spid=3609 seq=4 pid=17134
       refcnt=3

7.2.2.1. Problemy i znane usterki

Jeśli coś poszło nie tak, sprawdź czy wszystkie pliki konfiguracyjne należą do roota i tylko przez niego mogą zostać przeczytane. Aby uruchomić demon racoon na pierwszym planie użyj opcji `-F'. By zmusić go do przeczytania innego pliku konfiguracyjnego niż domyślnego, użyj opcji `-f'. Aby obejrzeć dokładne informacje o wszystkim co demon robi, dodaj do pliku racoon.conf linijkę zawierającą `log debug;'.

7.2.3. Automatyczna wymiana kluczy przy użyciu certyfikatów X.509

Wspominałem wcześniej, że zastosowanie współdzielonych kluczy nie jest najwygodniejsze, ponieważ nie są zbyt łatwe do bezpiecznego współdzielenia - a gdy już są współdzielone, przestają być sekretem. Na szczęście w tym momencie technologie wykorzystujące kryptografię asymetryczną wchodzą do gry i rozwiązują problem.

Jeśli każdy z partnerów IPsec stworzy klucz prywatny i publiczny, możemy zestawić bezpieczny kanał komunikacyjny pozwalając obu stronom opublikować swoje klucze publiczne i odpowiednio skonfigurować reguły bezpieczeństwa.

Stworzenie klucza jest relatywnie łatwe, aczkolwiek wymaga trochę pracy. Poniższy opis opiera się o zastosowanie do tego celu narzędzia openssl.

7.2.3.1. Tworzenie certyfikatu X.509 dla twojego hosta

OpenSSL dysponuje bogatą infrastrukturą związaną z operacjami na kluczach, podpisanych lub niepodpisanych przez autorytety/instytucje certyfikujące (ang. "certificate authorities"). Na razie zajmiemy się domyślnie generowanymi kluczami bez użycia instytucji certyfikującej.

Najpierw stworzymy `prośbę o certyfikat' dla naszego hosta, nazwanego `laptop':

$ openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout \
  laptop.private -outform PEM -out request.pem

Polecenie spowoduje konieczność odpowiedzi na parę pytań:

Country Name (2 letter code) [AU]:NL
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:Delft
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Linux Advanced
Routing & Traffic Control
Organizational Unit Name (eg, section) []:laptop
Common Name (eg, YOUR name) []:bert hubert
Email Address []:ahu@ds9a.nl

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Od ciebie zależy ile z informacji podasz i w jaki sposób je podasz. Może to zależeć od twoich oczekiwań związanych z bezpieczeństwem. W powyższym przykładzie podaliśmy większość informacji.

Teraz sami `podpiszemy' swoją prośbę:

$ openssl x509 -req -in request.pem -signkey laptop.private -out \
  laptop.public
Signature ok
subject=/C=NL/L=Delft/O=Linux Advanced Routing & Traffic \
  Control/OU=laptop/CN=bert hubert/Email=ahu@ds9a.nl
Getting Private key

Plik request.pem można teraz usunąć.

Powtórz tą operację dla wszystkich hostów które potrzebować będą klucza. Możesz oczywiście dystrybuować plik .public, ale plik .private trzymaj z daleka od wszystkich w tajemnicy.

7.2.3.2. Konfiguracja i uruchomienie

Po wygenerowaniu kluczy należy poinformować racoon by ich użył.

Wracamy w tym momencie do naszej poprzedniej konfiguracji pomiędzy dwoma hostami - 10.0.0.11 ('upstairs') i 10.0.0.216 ('laptop').

Do pliku racoon.conf na 10.0.0.11 dodaj:

path certificate "/usr/local/etc/racoon/certs";

remote 10.0.0.216
{
       exchange_mode aggressive,main;
       my_identifier asn1dn;
       peers_identifier asn1dn;

       certificate_type x509 "upstairs.public" "upstairs.private";

       peers_certfile "laptop.public";
       proposal {
              encryption_algorithm 3des;
              hash_algorithm sha1;
              authentication_method rsasig;
              dh_group 2 ;
       }
}

Taka konfiguracja spowoduje, że racoon poszuka kluczy w katalogu /usr/local/etc/racoon/certs/. Konfiguracja zawiera również elementy specyficzne dla zdalnego hosta 10.0.0.216.

Linijka asn1dn informuje racoon, że identyfikator obu stron należy pobrać z kluczy publicznych. Będzie to ciąg znaków `subject=/C=NL/L=Delft/O=Linux Advanced Routing & Traffic Control/OU=laptop/CN=bert hubert/Email=ahu@ds9a.nl'.

Linijka certificate_type wskazuje lokalny klucz prywatny i publiczny. Natomiast linijka peers_certfile wskazuje demonowi racoon plik z kluczem publicznym zdalnego partnera - i jest to plik laptop.public.

Sekcja proposal pozostaje w niezmienionej formie w stosunku do tego co widzieliśmy wcześniej za wyjątkiem opcji authentication_method którą jest obecnie rsasig - wskazując, że używamy pary prywatnej/publicznej RSA do wykonania uwierzytelnienia.

Zmiany w konfiguracji 10.0.0.216 są analogiczne do tych, wykonanych na 10.0.0.11:

path certificate "/usr/local/etc/racoon/certs";

remote 10.0.0.11
{
       exchange_mode aggressive,main;
       my_identifier asn1dn;
       peers_identifier asn1dn;

       certificate_type x509 "laptop.public" "laptop.private";
 
       peers_certfile "upstairs.public";

       proposal {
              encryption_algorithm 3des;
              hash_algorithm sha1;
              authentication_method rsasig;
              dh_group 2 ;
       }
}

Teraz, gdy już dodaliśmy odpowiednie opcje na obu hostach, musimy tylko umieścić klucze we właściwych miejscach. Maszyna `upstairs' powinna mieć pliki upstairs.private, upstairs.public, i laptop.public w katalogu /usr/local/etc/racoon/certs. Upewnij się że właścicielem tego katalogu jest root a sam katalog ma prawa dostępu ustawione na 0700 - w przeciwnym wypadku racoon odmówi ich odczytania.

Maszyna `laptop' powinna mieć pliki laptop.private, laptop.public i upstairs.public w katalogu /usr/local/etc/racoon/certs. Innymi słowy, każdy host potrzebuje dostęp do swojego klucza prywatnego, publicznego oraz do klucza publicznego hosta z którym chce nawiązać łączność.

Sprawdź, czy reguły bezpieczeństwa zostały prawidłowo zdefiniowane (wykonaj polecenia spdadd z Sekcja 7.2.2). Teraz uruchom racoon i wszystko powinno działać.

7.2.3.3. Jak bezpiecznie budować tunele

Aby ustanowić bezpieczną trasę komunikacji ze zdalnym partnerem, musimy wymienić klucze publiczne. O ile same klucze publiczne nie muszą być sekretem, ważne jest by zachować je w niezmienionej formie. Innymi słowy, trzeba mieć pewność że nie dojdzie do ataku typu `człowiek-pośrodku' (ang. "man in the middle").

Aby to ułatwić, w OpenSSL zaimplementowano polecenie digest:

$ openssl dgst upstairs.public 
MD5(upstairs.public)= 78a3bddafb4d681c1ca8ed4d23da4ff1

Teraz wystarczy zweryfikować że nasz zdalny partner ma taką samą sumę kontrolną dla tego pliku. Można to zrobić po prostu spotykając się, lub przez telefon - generalnie chodzi o to, by potwierdzić to inną drogą komunikacji. Niedopuszczalne jest, by zdalna strona wysłała swoją sumę kontrolną również np. mailem!

Innym sposobem osiągnięcia tego samego, jest zaufana trzecia osoba/instytucja (ang. "Trusted Third Party") która utrzymuje instytucję certyfikującą (ang. "Certificate Authority", CA). CA podpisze klucz, który w naszym przypadku sami podpisaliśmy i partner będzie mógł w CA zweryfikować że otrzymany od nas klucz jest faktycznie tym, który my pierwotnie zgłosiliśmy do podpisania w CA.