Bezpieczenstwo systemow informatycznych

Bezpieczeństwo – Protokoły
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
Bezpieczeństwo – Protokoły
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
Bezpieczeństwo – Protokoły
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
Bezpieczeństwo – Protokoły
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
Bezpieczeństwo – Protokoły
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
Bezpieczeństwo – Protokoły
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.
2.
3.
4.
5.
6.
7.
www.openbsd.org/faq/faq13.html
www.cis.ohio-stae.edu/htbin/rfc/rfc2401.html
www.cis.ohio-stae.edu/htbin/rfc/rfc2409.html
www.cis.ohio-stae.edu/htbin/rfc/rfc2522.html
www.cis.ohio-stae.edu/htbin/rfc/rfc2709.html
www.cis.ohio-stae.edu/htbin/rfc/rfc2402.html
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