plik


ÿþBezpieczeDstwo  ProtokoBy Bezpieczne protokoBy GBówne zagadnienia wykBadu ProtokóB Secure IP IPSec jest standardem stworzonym przez IETF (Internet Engineering Task Force). Jest protokoBem warstwy trzeciej (poziom protokoBu IP) wedBug modelu OSI zapewniajcym: " poufno[ przesyBanych 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 nagBówków, dodawanych do standardowych nagBówków IP: Authentication Header (AH) i Encapsulation Security Payload (ESP). NagBówki te s umieszczane po nagBówkach IP, a przed nagBówkami protokoBów warstwy czwartej. IP Authentication Header zapewnia integralno[ i uwierzytelnienie datagramu IP. Jego dziaBaniem jest objty caBy pakiet, zarówno dane jak i nagBówek IP. Dane uwierzytelniajce s obliczone za pomoc funkcji skrótu zastosowanej do niezmiennej cz[ci datagramu (m.in. adres zródBa i adres docelowy). Podpisu cyfrowego u|ywa si rzadko ze wzgldu na powolno[ tej technologii. Nie jest zapewniona poufno[.. IP Encapsulation Security Payload zapewnia przede wszystkim poufno[ data- gramów. Mo|e by równie| wykorzystywany do zapewnienia integralno[ci i uwierzytelnienia poprzez zastosowanie podpisu. Szyfrowanie i podpisywanie dotyczy tylko danych. Nie dotyczy nagBówka IP. Tryby pracy protokoBu IPSec Tryb transportowy: W pakiecie szyfrowane s tylko dane. Oryginalny nagBówek IP po- zostaje niezmieniony, ale mo|e by podpisany. Pozostawienie nieszyfrowanego nagBówka umo|liwia obcym prowadzenie analizy ruchu pomidzy wzBami. PrzesyBane dane s jednak szyfrowane. Tryb tunelowy: Oryginalny datagram IP jest w caBo[ci szyfrowany stajc si zawarto- [ci w nowym pakiecie IP. Funkcje szyfrowania, deszyfrowania, sprawdzania integralno[ci i uwierzytelnienia realizuj bramy (gateway) rozpoznajce protokóB IPSec. Systemy docelowe nie musz by modyfikowane aby korzysta z IPSec. Ten tryb uniemo|liwia analiz ruchu. Z ze- wntrz mo|liwe jest wic okre[lenie jedynie koDców tunelu. Security Association Okre[lenie mechanizmów IPSec u|ytych w konkretnym poBczenie realizuje si poprzez zdefiniowanie tzw. Security Association (SA). Okre[la ono sposób przekazywania danych w jednym kierunku. SA zawiera: " informacje definiujce algorytm szyfrowania, " informacje definiujce algorytmu uwierzytelniania i sprawdzania integralno[ci, " klucze szyfrujce i kodujce 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 nagBówku numer SPI, pozwalajcy na okre[lenie infor- OpracowaB: Zbigniew Suski 1/6 BezpieczeDstwo  ProtokoBy macji potrzebnych do odszyfrowania tre[ci pakietu, sprawdzenia jego integralno[ci lub potwier- dzenia to|samo[ci nadawcy. Zarzdzanie kluczami Proces budowania bezpiecznego poBczenia, dostarczania odpowiednich kluczy i wzajemnego uwierzytelnienia stron jest realizowany przy pomocy odrbnego protokoBu ISAKMP (Internet Se- curity Associattion and Key Management Protocol). Wystpuje on czsto pod nazw IKE (In- ternet Key Exchange). Implementacje Implementacje IPSec pojawiaj si w coraz wikszej ilo[ci systemów operacyjnych. Dodawane s do wielu rozwizaD typu firewall (Checkpoint, PIX, Bordeware). S równie| dostpne dar- mowe rozwizania dla Linuxa (FreeS/WAN), FreeBSD (KAME). Budowanie takich poBczeD jest równie| mo|liwe w Windows 2000. ProtokóB SSL SSL (Secure Socket Layer) realizuje uwierzytelnienie, szyfrowanie oraz zapewnia integralno[ wiadomo[ci. Posiada wbudowany mechanizm uwierzytelniania serwera i opcjonalnie klienta. WspóBpracuje z zaporami sieciowymi i poBczeniami tunelowanymi. Bazuje na protokole zapew- niajcym niezawodn komunikacj (np. TCP). Jest niezale|ny od aplikacji warstw wy|szych. Dziki temu mo|e by wykorzystywany do zabezpieczania takich protokoBów jak TELNET, FTP, HTTP. Mechanizm potwierdzania to|samo[ci serwerów korzysta z algorytmu RSA oraz certyfi- katów nadawanych przez organizacje niezale|ne. SkBada si z dwóch protokoBów: " SSL Record Protocol - u|ywany do bezpiecznego przesyBania wiadomo[ci. " SSL Handshake Protocol - u|ywany do negocjowania parametrów bezpiecznego poBczenia. SSL Record Protocol - okre[la struktur ramki zawierajcej przesyBane dane. Znajduj si w niej trzy pola: £' skrót wiadomo[ci (MAC-DATA), nazywany kodem uwierzytelnienia MAC (message authentication code). £' dane do przesBania (ACTUAL-DATA), £' dane wypeBniajce (PADDING-DATA). Przy przesyBaniu rekordu tekstem jawnym, pola MAC-DATA i PADDING-DATA nie wystpuj. MAC-DATA= HASH(SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER) Zawarto[ pola SECRET jest okre[lana przez nadawc i jest zwizana z metod szyfro- wania. SEQUENCE-NUMBER jest zawarto[ci licznika aktualizowanego przez nadawc. Ka|dy nadawca ma swój licznik. SSL Handshake Protocol ProtokóB ten realizowany jest w dwóch gBównych etapach. Etap pierwszy umo|liwia usta- nowienie poufnego poBczenia. Etap drugi jest wykorzystywany do autentykacji klienta. OpracowaB: Zbigniew Suski 2/6 BezpieczeDstwo  ProtokoBy Negocjowanie parametrów przebiega w sze[ciu etapach: 1. Faza powitania (Hello phase)  sBu|y do ustalenia zbioru algorytmów zapewniajcych pouf- no[ i uwierzytelnienie. Dodatkowo wykrywane s identyfikatory pozostawione z poprzed- nich sesji. WysyBany jest równie| klucz publiczny klienta. 2. Faza wymiany klucza (key exchange phase)  sBu|y do wymiany kluczy pomidzy klientem i serwerem. W wyniku obie strony wchodz w posiadanie wspóBdzielonego klucza gBów- nego (master key). 3. Faza tworzenia klucza sesji (session key production) jest wykorzystywana do wymiany aktualnego klucza sesyjnego. 4. Faza weryfikacji serwera (server veryfication key) wystpuje tylko wtedy gdy do dystrybucji kluczy wykorzystywany jest algorytm RSA. Po otrzymaniu od klienta klucza gBównego i klu- cza sesji, serwer je deszyfruje przy pomocy swojego klucza prywatnego i wysyBa potwier- dzenie. 5. Faza uwierzytelniania klienta (client authentication phase) polega wysBaniu przez serwer komunikaty zawierajcego |danie certyfikatu klienta. Klient odpowiada komunikatem za- wierajcym certyfikat. 6. Faza zakoDczenia (finished phase) polega na wymianie komunikatów koDcowych. Firma Netscape udostpnia posta zródBow biblioteki SSLRef zawierajcej procedury napisane w jzyku C. Mo|na je stosowa w programach wykorzystujcych protokóB SSL. ProtokóB S-HTTP Zapewnia usBugi zabezpieczajce dla transakcji HTTP. Dla zapewnienia bezpieczeDstwa komunikatów S-HTTP wykorzystuje podpis cyfrowy, szyfrowanie, sprawdzanie i uwiarygodnie- nie komunikatów. UsBugi bezpieczeDstwa s negocjowane za pomoc nagBówków i atrybutów zwizanych ze stron WWW. UsBugi S-HTTP s dostpne tylko dla poBczeD HTTP i aplikacja HTTP musi by [wiadoma tych usBug  nie s dla niej przezroczyste. W zwykBej transakcji HTTP serwer koDczy poBczenie po wysBaniu danych do klienta. W przypadku S-HTTP serwer nie zakoDczy poBczenia dopóki nie naka|e tego klient. Ma to na celu zachowanie wa|no[ci ustalonego klucza szyfrowania i pominicie fazy negocjacji przed przesBaniem nastpnej porcji danych. Zapobiega to uzgadnianiu przed przesBaniem ka|dego komunikatu. S-HTTP wprowadza now metod (security) i nagBówki komunikatów SHTTP przesyBanych 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 nagBówków. SHTTP-Privacy-Enhancements  okre[la zabezpieczenia zwizane z wiadomo[ci. OpracowaB: Zbigniew Suski 3/6 BezpieczeDstwo  ProtokoBy System Secure RPC Jest to system bezpiecznego zdalnego wywoBywnia procedur. Jest wbudowany w NIS+. Jest to system oparty na szyfrowaniu z kluczem publicznym i tajnym. Implementacja firmy Sun wyko- rzystuje mechanizm Diffie-Hellmana do dystrybucji kluczy i algorytmu DES do szyfrowania przesyBanych danych. DES jest wykorzystywany równie| do szyfrowania tajnego klucza u|yt- kownika. Klucz ten jest przechowywany w centralnym serwerze sieciowym. Popularno[ Secure RPC jest du|o mniejsza ni| pierwotnego RPC. Wynika to z faktu, |e obowizuj w tej chwili ograniczenia patentowe (na szyfrowanie z kluczem publicznym) i nie ma w tej chwili dostpnej wersji bezpBatnej. 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 hasBa jednostki. Jednostka udowadnia swoj to|samo[ mo|liwo[ci odszyfrowania klucza taj- nego i przez to uczestniczenia w wymianie kluczy wedBug procedury Diffie-Hellmana. Ka|da jednostka Bczy swój klucz tajny z kluczem publicznym innych jednostek w celu otrzymania wspólnego klucza. Dystrybucja bazy danych zawierajcej nazwy u|ytkowników, klucze publiczne i zaszy- frowane tajne jest organizowana przy pomocy NIS lub NIS+. Klucz tajny jest szyfrowany przy pomocy hasBa 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 przesyBany przez u|ytkownika jest zakodowany kluczem konwersacyjnym. " Klucz ten mo|e by znany tylko komu[, kto zna klucz publiczny serwera i klucz tajny u|yt- kownika. " Poznanie klucza tajnego jest mo|liwe po jego odszukaniu za pomoc NIS i odszyfrowaniu przy pomocy hasBa u|ytkownika. CaBe bezpieczeDstwo zale|y od trudno[ci zBamania klucza konwersacyjnego. Odszyfrowane hasBo nie jest przesyBane. Na serwerze plików nie ma tajnych informacji, które nale|aBoby za- bezpiecza. Poniewa| szyfrowanie kluczem publicznym jest dBugotrwaBe, wic jest wykorzystywane tylko do pierwszego logowania i wymiany kluczy sesyjnych. Wady Secure RPC: " Ka|dy klient musi by indywidualnie modyfikowany do wspóBpracy z Secure RPC. Lepszym rozwizaniem byBoby wykorzystanie np. zmiennych [rodowiskowych. " Pogorszenie szybko[ci dziaBania. Kilka procent. " Brak zapewnienia spójno[ci i poufno[ci danych. Weryfikowana jest tylko autentyczno[ u|ytkownika a nie przesyBane dane. " Mo|liwe jest zBamanie klucza publicznego. " Mo|liwe jest zBamanie klucza tajnego. Obecnie 56 bitów. " Wymaga stosowania NIS lub NIS+. Trudne byBoby jego wykorzystywanie w [rodowiskach heterogenicznych. OpracowaB: Zbigniew Suski 4/6 BezpieczeDstwo  ProtokoBy ProtokóB SSH ProtokóB SSH umo|liwia bezpieczne zdalne logowanie oraz bezpieczny dostp do innych usBug sieciowych poprzez sie niezabezpieczon. Obejmuje trzy gBówne skBadniki: " Transport layer protocol [SSH-TRANS] udostpniajcy uwierzytelnienie serwera, poufno[ i integralno[. Opcjonalnie mo|liwa jest równie| kompresja. " User authentication protocol [SSH-USERAUTH] sBu|y do uwierzytelniania klienta wobec serwera. " Connection protocol [SSH-CONN] multipleksuje szyfrowany tunel w wiele kanaBów logicznych. Ka|dy serwer posiada swój klucz. Mo|e ich posiada wicej dla ró|nych algorytmów szyfrowa- nia. Kilka hostów mo|e dzieli ten sam klucz. Klucz serwera jest wykorzystywany podczas wymiany kluczy do weryfikacji, czy klient nawizaB poBczenie z wBa[ciwym serwerem. Klient musi wobec tego zna wcze[niej klucze pu- bliczne serwerów. Wykorzystywane s dwa modele bezpieczeDstwa: " 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. " Zwizek nazwa hosta-klucz jest certyfikowany przez urzd certyfikacyjny. Klient zna jedynie klucz CA (certification authority).i mo|e w ten sposób uzyska klucz dowol- nego hosta znajdujcego si w obszarze odpowiedzialno[ci CA. Dostpna jest równie| opcja nie wymagajca kluczy podczas pierwszego poBczenia. Powinna ona by wykorzystywana tylko raz. Podczas pierwszego poBczenia klient powinien otrzyma klucz serwera i zapamita go w swojej bazie. Je|eli poBczenie nie jest realizowane po raz pierwszy, to otrzymany klucz serwera jest porów- nywany z kluczem zapamitanym wcze[niej. Je|eli klucz jest inny, to prawdopodobnie nastpiBo poBczenie z innym serwerem. Zgodno[ kluczy niczego nie dowodzi, gdy| publiczny klucz serwera mo|e by powszechnie dostpny. W drugim etapie autoryzacji klient generuje liczb losow, która bdzie u|ywana do szy- frowania caBej dalszej transmisji. Wygenerowana liczba zostaje zaszyfrowana kluczem prywat- nym klienta i kluczem publicznym serwera i wysBana do serwera. Aby odszyfrowa przesyBk serwer musi dysponowa swoim kluczem prywatnym i kluczem publicznym klienta. Poprawne odszyfrowanie przesBanej liczby pozwala stwierdzi, |e oba systemy biorce udziaB wymianie informacji s rzeczywi[cie tymi, za które si podaj. PrzesBane dane staj si kluczem sesyjnym gdy| caBa dalsza wymiana informacji opiera si na metodach szyfrowania symetrycznego. W nastpnej kolejno[ci odbywa si autoryzacja u|ytkownika. ProtokóB umo|liwia negocjacj metod szyfrowania, uwierzytelnienia, zapewnienia inte- gralno[ci, wymiany kluczy, kompresji. Dla ka|dego kierunku wymiany informacji mog by wy- korzystywane inne metody. OpracowaB: Zbigniew Suski 5/6 BezpieczeDstwo  ProtokoBy Literatura: 1) V. Ahuja. Network & Internet Security. Academic Press, Inc, 1996. (tBum.) 2) D. Atkins. Internet Security. Professional Reference. New Riders Publishing, 1997. (tBum. 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. (tBum.) 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. (tBum.) 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 zródBa: 1. Z. Kozak, Wirtualne sieci prywatne, Software 2.0, nr 11/2000. 2. M. SzymaDski, IPSec i Linux, Linux Plus, nr 9/2000. 3. P. Wojakowski, R. Kuliga, Rozwizania 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 OpracowaB: Zbigniew Suski 6/6

Wyszukiwarka

Podobne podstrony:
Bezpieczeństwo protokołów TCP IP oraz IPSec (2)
Bezpieczeństwo protokołów TCP IP oraz IPSec
IPSEC i SSL Bezpieczne Protokoly Sieciowe
BSI wsti 07 bezpieczne protokoły
Bezpieceństwo militarne Polski
Administracja bezpieczenstwa st
Dobór bezpieczników topikowych
Zagrożenia bezpieczeństa informacji
Bezpieczeństwo państwa instytucje bezpieczeństwa
02 Żydzi którzy napisali Protokoły Syjonu

więcej podobnych podstron