Bezpieczne protokoły Główne zagadnienia wykładu Protokół Secure IP IPSec jest standardem stworzonym przez IETF (Internet Engineering Task Force). Jest protokołem warstwy trzeciej (poziom protokołu IP) według modelu OSI zapewniającym: poufność przesyłanych informacji (poprzez szyfrowanie), integralność (poprzez generowanie i sprawdzanie sum kontrolnych), uwierzytelnienie (poprzez podpisywanie) użytkownika lub komputera, przezroczystość dla aplikacji. Zabezpieczenie polega na wprowadzeniu dwóch formatów nagłówków, dodawanych do standardowych nagłówków IP: Authentication Header (AH) i Encapsulation Security Payload (ESP). Nagłówki te są umieszczane po nagłówkach IP, a przed nagłówkami protokołów warstwy czwartej. IP Authentication Header zapewnia integralność i uwierzytelnienie datagramu IP. Jego działaniem jest objęty cały pakiet, zarówno dane jak i nagłówek IP. Dane uwierzytelniające są obliczone za pomocą funkcji skrótu zastosowanej do niezmiennej części datagramu (m.in. adres źródła i adres docelowy). Podpisu cyfrowego używa się rzadko ze względu na powolność tej technologii. Nie jest zapewniona poufność.. IP Encapsulation Security Payload zapewnia przede wszystkim poufność datagramów. Może być również wykorzystywany do zapewnienia integralności i uwierzytelnienia poprzez zastosowanie podpisu. Szyfrowanie i podpisywanie dotyczy tylko danych. Nie dotyczy nagłówka IP. Tryby pracy protokołu IPSec Tryb transportowy: W pakiecie szyfrowane są tylko dane. Oryginalny nagłówek IP pozostaje niezmieniony, ale może być podpisany. Pozostawienie nieszyfrowanego nagłówka umożliwia obcym prowadzenie analizy ruchu pomiędzy węzłami. Przesyłane dane są jednak szyfrowane. Tryb tunelowy: Oryginalny datagram IP jest w całości szyfrowany stając się zawartością w nowym pakiecie IP. Funkcje szyfrowania, deszyfrowania, sprawdzania integralności i uwierzytelnienia realizują bramy (gateway) rozpoznające protokół IPSec. Systemy docelowe nie muszą być modyfikowane aby korzystać z IPSec. Ten tryb uniemożliwia analizę ruchu. Z zewnątrz możliwe jest więc określenie jedynie końców tunelu. Security Association Określenie mechanizmów IPSec użytych w konkretnym połączenie realizuje się poprzez zdefiniowanie tzw. Security Association (SA). Określa ono sposób przekazywania danych w jednym kierunku. SA zawiera: informacje definiujące algorytm szyfrowania, informacje definiujące algorytmu uwierzytelniania i sprawdzania integralności, klucze szyfrujące i kodujące wykorzystywane w AH i ESP, okres ważności kluczy, czas ważności asocjacji. SA są jednoznacznie identyfikowane poprzez docelowy adres IP oraz SPI (Security Parameter Index). Każdy pakiet IPSec zawiera w nagłówku numer SPI, pozwalający na określenie infor- Opracował: Zbigniew Suski 1/6
macji potrzebnych do odszyfrowania treści pakietu, sprawdzenia jego integralności lub potwierdzenia tożsamości nadawcy. Zarządzanie kluczami Proces budowania bezpiecznego połączenia, dostarczania odpowiednich kluczy i wzajemnego uwierzytelnienia stron jest realizowany przy pomocy odrębnego protokołu ISAKMP (Internet Security Associattion and Key Management Protocol). Występuje on często pod nazwą IKE (Internet Key Exchange). Implementacje Implementacje IPSec pojawiają się w coraz większej ilości systemów operacyjnych. Dodawane są do wielu rozwiązań typu firewall (Checkpoint, PIX, Bordeware). Są również dostępne darmowe rozwiązania dla Linuxa (FreeS/WAN), FreeBSD (KAME). Budowanie takich połączeń jest również możliwe w Windows 2000. Protokół SSL SSL (Secure Socket Layer) realizuje uwierzytelnienie, szyfrowanie oraz zapewnia integralność wiadomości. Posiada wbudowany mechanizm uwierzytelniania serwera i opcjonalnie klienta. Współpracuje z zaporami sieciowymi i połączeniami tunelowanymi. Bazuje na protokole zapewniającym niezawodną komunikację (np. TCP). Jest niezależny od aplikacji warstw wyższych. Dzięki temu może być wykorzystywany do zabezpieczania takich protokołów jak TELNET, FTP, HTTP. Mechanizm potwierdzania tożsamości serwerów korzysta z algorytmu RSA oraz certyfikatów nadawanych przez organizacje niezależne. Składa się z dwóch protokołów: SSL Record Protocol - używany do bezpiecznego przesyłania wiadomości. SSL Handshake Protocol - używany do negocjowania parametrów bezpiecznego połączenia. SSL Record Protocol - określa strukturę ramki zawierającej przesyłane dane. Znajdują się w niej trzy pola: skrót wiadomości (MAC-DATA), nazywany kodem uwierzytelnienia MAC (message authentication code). dane do przesłania (ACTUAL-DATA), dane wypełniające (PADDING-DATA). Przy przesyłaniu rekordu tekstem jawnym, pola MAC-DATA i PADDING-DATA nie występują. MAC-DATA= HASH(SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER) Zawartość pola SECRET jest określana przez nadawcę i jest związana z metodą szyfrowania. SEQUENCE-NUMBER jest zawartością licznika aktualizowanego przez nadawcę. Każdy nadawca ma swój licznik. SSL Handshake Protocol Protokół ten realizowany jest w dwóch głównych etapach. Etap pierwszy umożliwia ustanowienie poufnego połączenia. Etap drugi jest wykorzystywany do autentykacji klienta. Opracował: Zbigniew Suski 2/6
Negocjowanie parametrów przebiega w sześciu etapach: 1. Faza powitania (Hello phase) służy do ustalenia zbioru algorytmów zapewniających poufność i uwierzytelnienie. Dodatkowo wykrywane są identyfikatory pozostawione z poprzednich sesji. Wysyłany jest również klucz publiczny klienta. 2. Faza wymiany klucza (key exchange phase) służy do wymiany kluczy pomiędzy klientem i serwerem. W wyniku obie strony wchodzą w posiadanie współdzielonego klucza głównego (master key). 3. Faza tworzenia klucza sesji (session key production) jest wykorzystywana do wymiany aktualnego klucza sesyjnego. 4. Faza weryfikacji serwera (server veryfication key) występuje tylko wtedy gdy do dystrybucji kluczy wykorzystywany jest algorytm RSA. Po otrzymaniu od klienta klucza głównego i klucza sesji, serwer je deszyfruje przy pomocy swojego klucza prywatnego i wysyła potwierdzenie. 5. Faza uwierzytelniania klienta (client authentication phase) polega wysłaniu przez serwer komunikaty zawierającego żądanie certyfikatu klienta. Klient odpowiada komunikatem zawierającym certyfikat. 6. Faza zakończenia (finished phase) polega na wymianie komunikatów końcowych. Firma Netscape udostępnia postać źródłową biblioteki SSLRef zawierającej procedury napisane w języku C. Można je stosować w programach wykorzystujących protokół SSL. Protokół S-HTTP Zapewnia usługi zabezpieczające dla transakcji HTTP. Dla zapewnienia bezpieczeństwa komunikatów S-HTTP wykorzystuje podpis cyfrowy, szyfrowanie, sprawdzanie i uwiarygodnienie komunikatów. Usługi bezpieczeństwa są negocjowane za pomocą nagłówków i atrybutów związanych ze stroną WWW. Usługi S-HTTP są dostępne tylko dla połączeń HTTP i aplikacja HTTP musi być świadoma tych usług nie są dla niej przezroczyste. W zwykłej transakcji HTTP serwer kończy połączenie po wysłaniu danych do klienta. W przypadku S-HTTP serwer nie zakończy połączenia dopóki nie nakaże tego klient. Ma to na celu zachowanie ważności ustalonego klucza szyfrowania i pominięcie fazy negocjacji przed przesłaniem następnej porcji danych. Zapobiega to uzgadnianiu przed przesłaniem każdego komunikatu. S-HTTP wprowadza nową metodę (security) i nagłówki komunikatów SHTTP przesyłanych w czasie negocjacji: SHTTP-Privacy-Domain określa standard zapisu zabezpieczanej wiadomości. SHTTP-Certificate-Type określa akceptowane formaty certyfikatów. SHTTP-Key-Exchange-Algorithm określa algorytm używamy do wymiany kluczy. SHTTP-Signature-Algorithms określa algorytm podpisu cyfrowego. SHTTP-Message-Digest-Algorithms określa algorytm zapewnienia integralności danych funkcja skrótu. SHTTP-Symmetric-Content-Algorithms określa algorytm symetrycznego szyfru blokowego, który zostanie wykorzystany do szyfrowania danych. SHTTP-Symmetric-Header-Algorithms określa symetryczny algorytm szyfrowania, który zostanie wykorzystany do szyfrowania nagłówków. SHTTP-Privacy-Enhancements określa zabezpieczenia związane z wiadomością. Opracował: Zbigniew Suski 3/6
System Secure RPC Jest to system bezpiecznego zdalnego wywoływnia procedur. Jest wbudowany w NIS+. Jest to system oparty na szyfrowaniu z kluczem publicznym i tajnym. Implementacja firmy Sun wykorzystuje mechanizm Diffie-Hellmana do dystrybucji kluczy i algorytmu DES do szyfrowania przesyłanych danych. DES jest wykorzystywany również do szyfrowania tajnego klucza użytkownika. Klucz ten jest przechowywany w centralnym serwerze sieciowym. Popularność Secure RPC jest dużo mniejsza niż pierwotnego RPC. Wynika to z faktu, że obowiązują w tej chwili ograniczenia patentowe (na szyfrowanie z kluczem publicznym) i nie ma w tej chwili dostępnej wersji bezpłatnej. Weryfikacja autentyczności Każda jednostka (principal) systemu ma klucz tajny i klucz publiczny. Klucz publiczny jest przechowywany w postaci niezaszyfrowanej, klucz tajny w postaci zaszyfrowanej z użyciem hasła jednostki. Jednostka udowadnia swoją tożsamość możliwością odszyfrowania klucza tajnego i przez to uczestniczenia w wymianie kluczy według procedury Diffie-Hellmana. Każda jednostka łączy swój klucz tajny z kluczem publicznym innych jednostek w celu otrzymania wspólnego klucza. Dystrybucja bazy danych zawierającej nazwy użytkowników, klucze publiczne i zaszyfrowane tajne jest organizowana przy pomocy NIS lub NIS+. Klucz tajny jest szyfrowany przy pomocy hasła użytkownika i algorytmu DES. Oprogramowanie stacji jest wobec tego w stanie odszyfrować klucz tajny. Serwer jest przekonany o autentyczności użytkownika gdyż: Pakiet przesyłany przez użytkownika jest zakodowany kluczem konwersacyjnym. Klucz ten może być znany tylko komuś, kto zna klucz publiczny serwera i klucz tajny użytkownika. Poznanie klucza tajnego jest możliwe po jego odszukaniu za pomocą NIS i odszyfrowaniu przy pomocy hasła użytkownika. Całe bezpieczeństwo zależy od trudności złamania klucza konwersacyjnego. Odszyfrowane hasło nie jest przesyłane. Na serwerze plików nie ma tajnych informacji, które należałoby zabezpieczać. Ponieważ szyfrowanie kluczem publicznym jest długotrwałe, więc jest wykorzystywane tylko do pierwszego logowania i wymiany kluczy sesyjnych. Wady Secure RPC: Każdy klient musi być indywidualnie modyfikowany do współpracy z Secure RPC. Lepszym rozwiązaniem byłoby wykorzystanie np. zmiennych środowiskowych. Pogorszenie szybkości działania. Kilka procent. Brak zapewnienia spójności i poufności danych. Weryfikowana jest tylko autentyczność użytkownika a nie przesyłane dane. Możliwe jest złamanie klucza publicznego. Możliwe jest złamanie klucza tajnego. Obecnie 56 bitów. Wymaga stosowania NIS lub NIS+. Trudne byłoby jego wykorzystywanie w środowiskach heterogenicznych. Opracował: Zbigniew Suski 4/6
Protokół SSH Protokół SSH umożliwia bezpieczne zdalne logowanie oraz bezpieczny dostęp do innych usług sieciowych poprzez sieć niezabezpieczoną. Obejmuje trzy główne składniki: Transport layer protocol [SSH-TRANS] udostępniający uwierzytelnienie serwera, poufność i integralność. Opcjonalnie możliwa jest również kompresja. User authentication protocol [SSH-USERAUTH] służy do uwierzytelniania klienta wobec serwera. Connection protocol [SSH-CONN] multipleksuje szyfrowany tunel w wiele kanałów logicznych. Każdy serwer posiada swój klucz. Może ich posiadać więcej dla różnych algorytmów szyfrowania. Kilka hostów może dzielić ten sam klucz. Klucz serwera jest wykorzystywany podczas wymiany kluczy do weryfikacji, czy klient nawiązał połączenie z właściwym serwerem. Klient musi wobec tego znać wcześniej klucze publiczne serwerów. Wykorzystywane są dwa modele bezpieczeństwa: Klient posiada lokalną bazę danych, w której zapisane są nazwy hostów i ich klucze publiczne. Taka baza jest dość uciążliwa w administrowaniu. Związek nazwa hosta-klucz jest certyfikowany przez urząd certyfikacyjny. Klient zna jedynie klucz CA (certification authority).i może w ten sposób uzyskać klucz dowolnego hosta znajdującego się w obszarze odpowiedzialności CA. Dostępna jest również opcja nie wymagająca kluczy podczas pierwszego połączenia. Powinna ona być wykorzystywana tylko raz. Podczas pierwszego połączenia klient powinien otrzymać klucz serwera i zapamiętać go w swojej bazie. Jeżeli połączenie nie jest realizowane po raz pierwszy, to otrzymany klucz serwera jest porównywany z kluczem zapamiętanym wcześniej. Jeżeli klucz jest inny, to prawdopodobnie nastąpiło połączenie z innym serwerem. Zgodność kluczy niczego nie dowodzi, gdyż publiczny klucz serwera może być powszechnie dostępny. W drugim etapie autoryzacji klient generuje liczbę losową, która będzie używana do szyfrowania całej dalszej transmisji. Wygenerowana liczba zostaje zaszyfrowana kluczem prywatnym klienta i kluczem publicznym serwera i wysłana do serwera. Aby odszyfrować przesyłkę serwer musi dysponować swoim kluczem prywatnym i kluczem publicznym klienta. Poprawne odszyfrowanie przesłanej liczby pozwala stwierdzić, że oba systemy biorące udział wymianie informacji są rzeczywiście tymi, za które się podają. Przesłane dane stają się kluczem sesyjnym gdyż cała dalsza wymiana informacji opiera się na metodach szyfrowania symetrycznego. W następnej kolejności odbywa się autoryzacja użytkownika. Protokół umożliwia negocjację metod szyfrowania, uwierzytelnienia, zapewnienia integralności, wymiany kluczy, kompresji. Dla każdego kierunku wymiany informacji mogą być wykorzystywane inne metody. Opracował: Zbigniew Suski 5/6
Literatura: 1) V. Ahuja. Network & Internet Security. Academic Press, Inc, 1996. (tłum.) 2) D. Atkins. Internet Security. Professional Reference. New Riders Publishing, 1997. (tłum. LT&P). 3) R. Atkinson. Security Architecture for Internet Protocol, RFC 1825, Aug 1995. 4) R. Atkinson. IP Authentication Header. RFC 1826, Aug 1995. 5) R. Atkinson. IP Encapsulation Security Payload (ESP), RFC 1827, Aug 1995. 6) S. Garfinkel, G. Spafford. Practical Unix and Internet Security, O Reilly&Associates Inc. 1996. (tłum.) 7) K.E.B. Hickman, T.Elgamal. The SSL Protocol. Internet Draft, 1995. 8) P.Karn, P.Metzger, W.Simpson. The ESP DES-CBC Transform, RFC 1829, Aug. 1995. 9) L. Klander. Hacker Proof. Jamsa Press, 1997. (tłum.) 10) P. Metzger, W. Simpson. IP Authentication using Keyed MD5, RFC 1828, Aug. 1995. 11) E.Rescola, A.Schiffman. The Secure HyperText Transfer Protocol, Internet Draft, Jul 1995. 12) P. Wayner. Digital Cash: Commerce on the Net. AP Professional, 1996 13) T. Ylonen, i inni. SSH Protocol Architecture. Network Working Group, Internet Draft, Feb. 1999. 14) T. Ylonen, i inni SSH Transport Layer Protocol, Internet Draft, Feb. 1999. 15) T. Ylonen, i inni. SSH Authentication Protocol, Internet Draft, Feb. 1999. 16) T. Ylonen, i inni. SSH Connection Protocol, Internet Draft, Feb. 1999. Dodatkowe źródła: 1. Z. Kozak, Wirtualne sieci prywatne, Software 2.0, nr 11/2000. 2. M. Szymański, IPSec i Linux, Linux Plus, nr 9/2000. 3. P. Wojakowski, R. Kuliga, Rozwiązania IPSec i VPN. Software 2.0, nr 09/2000. Adresy WWW: 1. www.openbsd.org/faq/faq13.html 2. www.cis.ohio-stae.edu/htbin/rfc/rfc2401.html 3. www.cis.ohio-stae.edu/htbin/rfc/rfc2409.html 4. www.cis.ohio-stae.edu/htbin/rfc/rfc2522.html 5. www.cis.ohio-stae.edu/htbin/rfc/rfc2709.html 6. www.cis.ohio-stae.edu/htbin/rfc/rfc2402.html 7. www.codetalker.com/greenbox/docs/vpn-24-minifaq.html - FAQ: OpenBSD 2.4 IPSEC VPN Configuration 8. www.secureops.com/vpn 9. hem.passagen.se/hojg/isakmpd/index.html Opracował: Zbigniew Suski 6/6