Bezpieczeństwo – Protokoły

Opracował: Zbigniew Suski

1/6

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ść 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
nagłówka IP.

Tryby pracy protokołu IPSec

Tryb transportowy: W pakiecie szyfrowane są tylko dane. Oryginalny nagłówek IP po-

zostaje 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 ze-
wną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-

Bezpieczeństwo – Protokoły

Opracował: Zbigniew Suski

2/6

macji potrzebnych do odszyfrowania treści pakietu, sprawdzenia jego integralności lub potwier-
dzenia 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 Se-
curity Associattion and Key Management Protocol). Występuje on często pod nazwą IKE (In-
ternet 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 dar-
mowe 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 zapew-
niają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 certyfi-

kató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ą szyfro-

wania. 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 usta-

nowienie poufnego połączenia. Etap drugi jest wykorzystywany do autentykacji klienta.

Bezpieczeństwo – Protokoły

Opracował: Zbigniew Suski

3/6

Negocjowanie parametrów przebiega w sześciu etapach:
1. Faza powitania (Hello phase) – służy do ustalenia zbioru algorytmów zapewniających pouf-

ność i uwierzytelnienie. Dodatkowo wykrywane są identyfikatory pozostawione z poprzed-
nich 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łó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) występuje tylko wtedy gdy do dystrybucji

kluczy wykorzystywany jest algorytm RSA. Po otrzymaniu od klienta klucza głównego i klu-
cza sesji, serwer je deszyfruje przy pomocy swojego klucza prywatnego i wysyła potwier-
dzenie.

5. Faza uwierzytelniania klienta (client authentication phase) polega wysłaniu przez serwer

komunikaty zawierającego żądanie certyfikatu klienta. Klient odpowiada komunikatem za-
wierają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 uwiarygodnie-
nie 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ą.

Bezpieczeństwo – Protokoły

Opracował: Zbigniew Suski

4/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 wyko-
rzystuje mechanizm Diffie-Hellmana do dystrybucji kluczy i algorytmu DES do szyfrowania
przesyłanych 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

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 taj-
nego 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 zaszy-

frowane 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żyt-

kownika.

•

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 za-
bezpieczać.

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.

Bezpieczeństwo – Protokoły

Opracował: Zbigniew Suski

5/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 szyfrowa-
nia. 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 pu-
bliczne 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 dowol-
nego 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ów-
nywany 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 szy-

frowania całej dalszej transmisji. Wygenerowana liczba zostaje zaszyfrowana kluczem prywat-
nym 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 inte-

gralności, wymiany kluczy, kompresji. Dla każdego kierunku wymiany informacji mogą być wy-
korzystywane inne metody.

Bezpieczeństwo – Protokoły

Opracował: Zbigniew Suski

6/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