Grzegorz PANKOWSKI Politechnika Koszali ska BEZPIECZE STWO W SIECI 1. Problem uwierzytelnienia w Internecie Dlaczego stosuje si certyfikaty autentyczno ci w Internecie? W Internecie nie widzimy kto jest po drugiej stronie, do upewnienia si e osoba z któr si komunikujemy jest t, za któr si podaje. By zapobiec oszustwom, polegaj cym na podszyciu si pod kogo innego, wykorzystuje si certyfikaty autentyczno ci potwierdzaj ce, e w a cicielem serwera jest dana instytucja. Certyfikat autentyczno ci w uproszczeniu jest kluczem publicznym (plus troch innych informacji) elektronicznie podpisanym przez klucz prywatny. W celu umo liwienia uwierzytelniania u ytkowników lub instytucji w sieci powsta a Infrastruktura Klucza Publicznego (PKI Public Key Infrastructure). Jest to sposób na zapewnienie posiadacza klucza publicznego (klucz publiczny z za o enia jest ogólno dost pny) e nale y on do konkretnej osoby i nie zosta on wygenerowany przez kogo innego. Istniej dwa modele zaufania. Pierwszy to sie zaufania, gdzie wierzymy w autentyczno tylko tych kluczy które dostajemy bezpo rednio od znajomych, ewentualnie gdy przyjaciele którym ufamy po wiadcz wiarygodno kluczy ich znajomych (model stosowany w certyfikatach PGP). Jest to model równorz dny, gdzie ka dy u ytkownik ma takie same prawa. Jest mo liwy tylko w ma ych grupach u ytkowników. Drugie podej cie to hierarchiczny podzia zaufanych urz dów certyfikacyjnych. Firmy zajmuj ce si po wiadczaniem to samo ci u ytkowników sieci, przyznaj klientom certyfikaty. PKI jest zbiorem standardów, tworzonych wspólnie przez producentów oprogramowania oraz mi dzynarodowe instytucje normalizacyjne i publikowanych obecnie przez ITU-T jako normy X.509. Innym przyk adem znormalizowanej PKI s dokumenty publikowane pod nazw PKCS#12 przez firm RSA Data Security. Weryfikacja autentyczno ci certyfikatu jest dla u ytkownika transparentna (w przypadku gdy zainstalowane jest Centrum Certyfikacji), ca procedur wykonuje za niego przegl darka internetowa. Objawia si to zamkni t k ódk na pasku statusu (IE, Mozilla Firefox) lub pasku adresowym (Opera), ponadto pasek adresowy zmienia kolor na ó ty, jest to wynik po czenia na porcie 443. Po czenie z bezpieczn witryn wi e si przez HTTPS, by ukry tre przesy anych kluczy przesy anych przy negocjacji przy po czeniu.
130 Grzegorz Pankowski 2. Historia Standardów sieciowych X.500, opis poszczególnych standardów Standard X.509 nale y do rodziny standardów X.500, która to zosta a rozwini ta przez organizacj ITU-T (International Telecommunication Union Telecommunications Sector), do 1992 znan pod nazw CCITT (International Telegraph and Telephone Consultative Committee CCITT to skrót od francuskiej nazwy Comité Consultatif International Téléphonique et Télégraphique ). Organizacja ITU-T publikuje serie rekomendacji, stosowane s oznaczenia sk adaj ce si z litery (litera X oznacza dane sieciowe i otwarty system komunikacji) i liczby (seria 500 dotyczy standardów sieci komputerowych i elektronicznych serwisów katalogowych (series of computer networking standards covering electronic directory services). 3. Specyfikacja certyfikatu X.509 (ISO/IEC 9594-8) jako standard wykorzystywany w systemie elektronicznych podpisów kwalifikowanych (prawnie niezaprzeczalnych). Struktura oraz procedury autoryzacji certyfikatów wersji 1, 2 i 3 Sygnatariusz sk adaj cy podpis jest gwarantem autentyczno ci (wedle prawa, je li jest to centrum kwalifikowane) danych posiadacza certyfikatu. Numer seryjny certyfikatu jest unikalny wewn trz jednostki wydaj cej certyfikaty (CA Certification Authority). Unikalne identyfikatory zosta y dodane, by umo liwi ponowne u ycie nazwy podmiotu i/lub wystawcy. Te pola s rzadko u ywane. Kilka powszechnych rozszerze : KeyUsage (limituje u ycie kluczy do szczególnego celu jak tylko-do-podpisu ), AlternativeNames (umo liwia innym identyfikatorom by równie zrzeszanym za pomoc klucza publicznego, np. nazwy DNS, adresy Email, adresy IP). Rozszerzenie mo e by oznaczone jako critical by wskaza, e rozszerzenie musi by sprawdzone i wymuszone/u yte. Na przyk ad, je li certyfikat posiada rozszerzenie KeyUsage z oznaczeniem krytycznym i ustawionym na keycertsign wtedy, je li ten certyfikat jest przedstawiany poprzez komunikacje SSL, powinien by odrzucony, jako e rozszerzenie certyfikatu wskazuje na to, e przypisany klucz prywatny mo e by u yty tylko do podpisywania certyfikatów, a nie do u ycia SSL.
Bezpiecze stwo w sieci 131 Wersja formatu certyfikatu Numer seryjny certyfikatu Identyfikator algorytmu podpisu Algorytm Paramerty Nazwa wystawcy Okres wa no ci Identyfikator algorytmu podpisu i jego paramentry Nazwa wystawcy (sygnotariusza) Wa ny od... do... Nazwa podmiotu Wersja 1 Wersja 2 Wersja 3 Uniewa niony certyfikat Data uaktualnienia listy Nast pna data uaktualnienia listy Numer seryjny certyfikatu Data uniewaznienia Identyfikator algorytmu klucza i jego parametry Unikalny identyfikator wystawcy Podpis certyfikatu Unikalny identyfikator podmiotu Mo liwe rozszerzenia (jedno lub wi cej) Skrót wszystkich warto ci poprzednich pól certyfikatu uzyskany za pomoc klucza prywatnego sygnatariusza Certyfikat X.509 Wszystkie wersje Uniewa niony certyfikat Podpis certyfikatu Numer seryjny certyfikatu Data uniewaznienia Algorytm Parametry Zaszyfrowane Lista certyfikatów uniewa nionych Rys. 1. Schemat struktury certyfikatów i listy certyfikatów uniewa nionych Sposoby zapisu certyfikatów do plików binarnych Dzi najcz ciej u ywany jest system Base64 s u cy do kodowania ci gu bajtów za pomoc ci gu znaków, stosowany tak e do przesy ania za czników binarnych w poczcie elektronicznej, kodowania hase przesy anych w protokole SMTP podczas uwierzytelniania metodami AUTH i LOGIN. Plik posiada rozszerzenie.pem. Wypar on wcze niejszy.ber (basic encoding rules) i.der (lub.cer disguished encoding rules). Tre certyfikatu jest otoczona przez frazy: "-----BEGIN CER- TIFICATE-----" i "-----END CERTIFICATE-----". 4. Procedury autoryzacji certyfikatów W ród wystawców certyfikatów istnieje jasno okre lona hierarchia umo liwiaj ca egzystowanie w tak olbrzymiej sieci jak jest Internet. Tak wi c istnieje g ówny wystawca certyfikatów zwany rootem, root z kolei oddelegowuje cz uprawnie certyfikacyjnych podmiotom ni szego szczebla. Takie swoiste dziedziczenie uprawnie powoduje, e gdy korporacja chce wyposa y w certyfikaty wszystkich swoich pracowników wtedy nie ma potrzeby anga owania g ównego wystawcy certyfikatów, gdy sama ma wystarczaj ce uprawnienia. Klient musi posiada klucz publiczny urz du, który podpisa dany certyfikat, albo
132 Grzegorz Pankowski urz du z wy szego szczebla. Klucz centrum certyfikacji potwierdza to samo wszystkich ogniw w hierarchii poni ej. W chwili otrzymania certyfikatu (Certificate Discovery) przegl darka sprawdza, przez jaki urz d zosta on podpisany, je eli odnajdzie go w swojej wewn trznej bazie proces jest ju zako czony, a witryna uwierzytelniona, w przeciwnym wypadku przeszukuje bazy zewn trzne, tzw. Repozytoria kluczy (powszechnie katalogi LDAP). Certyfikat znaleziony w sieci nie jest jednak wiarygodny, gdy katalog powszedni móg zosta zmodyfikowany przez osoby trzecie, które podmieni y certyfikaty (Path Validation). W takim wypadku sprawdza si nadrz dnego wystawc certyfikatu z katalogu. Je eli nadrz dny wystawca jest znany przegl darce, wtedy certyfikaty s akceptowane, w przeciwnym wypadku nast puje kolejne odwo anie do katalogów LDAP i procedura zostaje powtórzona. W tym przypadku istniej dwie mo liwo ci, jedna to znalezienie podpisu CA, który jest w bazie czego wynikiem jest akceptacja, lub znalezienie takiego certyfikatu, który nie jest podpisany przez adne centrum nadrz dne (ostatni w a cuchu certyfikacji) wtedy przegl darka informuje, e certyfikat witryny nie zosta uznany za godny zaufania i decyzj czy certyfikat zaakceptowa, pozostawia u ytkownikowi. Kolejnym krokiem przegl darki po znalezieniu akceptowalnego certyfikatu jest sprawdzenie listy certyfikatów uniewa nionych (Revocation Checking). Je eli znaleziony certyfikat znajduje si na li cie, nie mo e on by zaakceptowany. Rozró nia si trzy warianty procedury autoryzacji: Jednostronna autoryzacja anga uje pojedynczy transfer informacji od u ytkownika A do u ytkownika B. W tym przypadku sprawdzana jest tylko to samo strony inicjuj cej po czenie, to samo strony odpowiadaj ca jest nie zosta a zweryfikowana. Wiadomo musi zawiera znacznik czasowy, losow warto i to samo B, podpisana jest kluczem publicznym A. Znacznik czasowy zawiera opcjonalnie czas generacji i czas wyga ni cia wa no ci wiadomo ci. Losowa warto musi by unikalna do tego czasu, w przypadku innej wiadomo ci z t sam warto ci losowej warto ci jest ona odrzucana. Przy czystej autoryzacji, wiadomo jest u yta jedynie w celu przedstawienia si. Wiadomo mo e te zawiera dane, s wtedy przekazane razem z podpisem, co gwarantuje ich integralno i to, e pochodz od A. Wiadomo mo e zawiera takie wiadomo ci, jak klucz sesyjny zaszyfrowany kluczem publicznym B. Dwustronna autoryzacja pozwala obu stronom na komunikacj ze wzgl du na to e to samo obu stron zosta a uprzednio zweryfikowana. Odpowied zawiera tak e warto losow od A, by walidowa odpowied. Zawiera tak e znacznik czasowy i warto losow od B. Jak powy ej wiadomo mo e zawiera równie podpisane informacje dodatkowe i klucz sesyjny podpisany przez klucz publiczny A. Trójstronna autoryzacja kolejna wiadomo od A do B zostaje do czona do poprzednich, zawiera ona podpisan kopi warto ci losowej od B. W in-
Bezpiecze stwo w sieci 133 tencji autorów autoryzacji trójstronnej le a o wyeliminowanie u ycia znacznika czasowego. Ka da ze stron odes a a z powrotem odebran warto losow, wi c s w stanie wykry atak polegaj cy na próbie podmiany. Takie rozwi zanie jest stosowane w przypadku kiedy synchronizacja zegarów nie jest mo liwa. 5. Certyfikaty uwierzytelniaj ce u ytkownika a certyfikaty uwierzytelniaj ce serwer Od strony technicznej certyfikaty uwierzytelniaj ce ogromne serwery i zwyk ych u ytkowników nie ró ni si niczym, maj t sam struktur, klucze s szyfrowane tymi samymi algorytmami. Kosz wydania certyfikatu przez podmiot wydaj cy certyfikaty kwalifikowane na osob prawn oscyluje wokó 200-250 PLN, certyfikat jest taki wydawany na rok (100-150 PLN kosztuje odnowienie certyfikatu na kolejny rok.). Klient dostaje mikroprocesorow kart kryptograficzn z zainstalowanym systemem operacyjnym, która udost pnia certyfikat systemowi (jednak e klucz prywatny nigdy nie opuszcza karty). Urz dzenia te s odpowiednio zabezpieczone przed ingerencj z zewn trz. Konieczno noszenia przy sobie i ka dorazowego pod czania urz dzenia do komputera zapobiega u pieniu czujno- ci, jak przy jednorazowej instalacji w systemie. W przypadku zgubienia karty i tak przed u yciem jej przez osob trzeci chroni system kodów (PIN i PUK). 6. Instytucje certyfikuj ce wystawców certyfikatów i podmioty wydaj ce certyfikaty kwalifikowane w Polsce i na wiecie Powo ano instytucje zaufania publicznego (centra autoryzacyjne). Instytucje takie wystawiaj c zainteresowanym certyfikaty, bior w ten sposób na siebie odpowiedzialno za to, e osoba/instytucja jest t, za któr si podaje. Centra autoryzacyjne s zhierarchizowane, na samej górze jest g ówna instytucja, tzw. Root, która przyznaje certyfikaty kolejnym. W ród mi dzynarodowych urz dów certyfikacyjnych najcz ciej s wymieniane: CAcert.org, cybertrust, Globalsign, Thawte, VeriSign, GeoTrust Krajowe urz dy certyfikacyjne: Krajowa Izba Rozliczeniowa, UniZeto, Sigillum, Signet. 7. Podsumowanie W Polsce Centra Certyfikuj ce zostaj powo ane przez prezesa NBP. Mamy cztery g ówne, równowa ne instytucje. Aby uzyska certyfikat, niezb dny jest dokument potwierdzaj cy to samo w danym pa stwie. adna inna instytucja ni CA nie jest w stanie zmodyfikowa certyfikatu bez pozostawienia ladu
134 Grzegorz Pankowski (niekonsekwencji w podpisie certyfikatu, czyli skrócie wszystkich pól certyfikatu). Niestety, firmy wprowadzi y w asny format kart kryptograficznych, czytników oraz oprogramowania niekompatybilny z pozosta ymi, rozporz dzenie wykonawcze do ustawy pozwala stosowa ró ne formaty. Takie rozwi zanie jest niestety, nieoptymalne i bardzo drogie. Bibliografia: 1. Stalling W.: Cryptography and Network Security: Principles and Practice, 2nd Edition. 2. ITU-T Recommendation X.509. 3. ITU-T Recommendation X.509 (2000). Technical Corrigendum 1. 4. Horstmann C.S., Cornell G.: Core Java2: Techniki zaawansowane. 5. http://www.itu.int. 6. http://wikipedia.org. 7. http:/java.sun.com/j2se/1.5.0/docs/guide/security/cert3.html. 8. http://www.openssl.org/docs/apps/x509.html. 9. http://www.networld.pl/artykuly/9930_4.html.