Instytut Informatyki, Automatyki i Robotyki Zastosowania informatyki w gospodarce Wykład 7 Certykikaty publiczne dr inż. Dariusz Caban dr inż. Jacek Jarnicki dr inż. Tomasz Walkowiak
Certyfikat Problem rozgłaszania klucza publicznego Czy udostępniany w sieci klucz osoby/instytucji rzeczywiście do niej należy? Rozwiązanie Autentyczność klucza musi być poświadczona przez zaufaną instytucję Instytucja CA (certificate authority) wystawia certyfikat (świadectwo autentyczności) Minimalna zawartość certyfikatu Jednoznaczna nazwa właściciela klucza publicznego DN (Distinguished Name) Klucz publiczny Informacje pozwalające ustalić ważność certyfikatu Podpis elektroniczny instytucji poświadczającej Certyfikat instytucji poświadczającej 2
Ważność certyfikatu Problem zaufania do instytucji wystawiającej certyfikat Certyfikat instytucji CA jest również podpisany i zawiera certyfikat nadrzędnej instytucji certyfikującej (cert. chaining) Główna instytucja certyfikująca (Root CA) podpisuje sama swój certyfikat Oprogramowanie wykorzystujące certyfikaty ma wbudowane listy głównych CA, można je uzupełniać przez doinstalowanie certyfikatów CA Informacje w certyfikacie wykorzystywane przy weryfikacji ważności Okres ważności (od do) Zastosowanie (do czego można wykorzystywać klucz) Numer seryjny certyfikatu, nadany przez instytucję CA 3
Utrata ważności certyfikatu Certyfikaty tracą ważność w sposób naturalny po upływie daty ważności (przeterminowanie certyfikatu) Instytucje certyfikujące publikują listy certyfikatów, którym cofnięto ważność CRL (certificate revocation list) zawierająca numery seryjne unieważnionych certyfikatów Listy są podpisywane przez instytucję certyfikującą i udostępniane przez serwery tej instytucji Oprogramowanie weryfikujące certyfikaty powinno okresowo ściągać listy CRL i je utrzymywać lokalnie Protokół OCSP (online certificate status protocol) RFC 2560 umożliwia badanie ważności certyfikatów na bieżąco przez sieć Obecnie nie implementowany w oprogramowaniu klientów 4
Tworzenie certyfikatów Trzy rodzaje certyfikatów Certyfikaty instytucji CA Certyfikaty serwerów Oprogramowanie klienta pobiera certyfikat z serwera i uwierzytelnia dostawcę usługi Certyfikaty użytkowników Użytkownik rozgłasza przy ich pomocy swoją tożsamość Mogą służyć do autoryzacji dostępu do usług Tworzenie certyfikatu Przygotowanie zapytania, tzn. podanie swojej nazwy DN, wygenerowanie kluczy Klucz publiczny wraz z DN w pliku zapytania (certificate request) Zaszyfrowany klucz prywatny w osobnym pliku (key file) CA podpisuje zapytanie, tworząc właściwy certyfikat 5
Standaryzacja postaci danych kryptograficznych Format danych podlegających standaryzacji Zapytania o certyfikat Klucze prywatne Certyfikaty Różne źródła standaryzacji Rekomendacje CCITT/OSI, obecnie ISO/IEC X509 Grupa norm RSA Laboratories PKCS#1 PKCS#12 Grupa robocza PKIX w ramach IETF Dokumenty RFC oraz Internet-Drafts Producenci oprogramowania Netscape SPKAC Microsoft 6
Taktyka zaufania (policy of trust) Wartość certyfikatu bezpośrednio zależy od zaufania, jakie mamy do instytucji go podpisującej Certification Practice Statement publiczna deklaracja CA dotycząca: metod weryfikowania certyfikowanych jednostek zabezpieczania danych poufnych o jednostkach zabezpieczeń danych umożliwiających fałszowanie certyfikatów warunków dystrybucji certyfikatów oraz list CRL warunków wydawania certyfikatów innym jednostkom CA Modele nabywania zaufania Hierarchiczny (PEM) Główna jednostka certyfikująca IPRA Jednostki określające taktykę wydawania certyfikatów (PCA) Jednostki certyfikujące zgodnie z tą taktyką (CA) 7
Taktyka zaufania Inne modele nabywania zaufania Publiczny (PKIX) Certyfikaty rozszerzone o pola określające ich zastosowanie oraz opisy CPS Każdy może utworzyć główną jednostkę certyfikującą, np. uczelnia może mieć zaufanie do swoich certyfikatów Ograniczenia zakresu wydawania certyfikatów, np. uczelnia wystawia certyfikaty tylko swoim pracownikom i studentom Bilansowanie kosztów i korzyści z określonego poziomu zaufania Rozproszony (OpenPGP) Każdy ma zaufanie do certyfikatów wystawionych osobiście Każdy może dodatkowo podpisać i rozesłać innych certyfikat, określając poziom weryfikacji jego tożsamości (1-3) Do uwiarygodnienia certyfikatu wykorzystujemy podpisy osób, którym ufamy (w określonym stopniu) i deklarowany poziom wer. Wymiana podpisów certyfikatów (key signing parties) 8
Formaty danych certyfikacyjnych Klucz prywatny Klucz publiczny Zaszyfrowany klucz prywatny Komplet kluczy SPKAC, PEM Zapytanie o certyfikat Kodowany klucz prywatny DER, PEM Kodowany klucz prywatny i cert. PEM, PKCS#12 Kod. podpisane zapytanie PKCS#10 Certyfikat z listą CRL PKCS#7 Certyfikat X509 z podpisem CA Lista CRL Łańcuch certyfikatów PEM, PKCS#12 9
Certyfikaty publiczne X509 Normy CCITT (obecnie ISO/IET/ITU) 1988 wersja 1 certyfikatu dokument X.509 Element definicji poczty X.400 oraz książek adresowych X.500 Kodowanie według normy ANS.1 oraz DER Obecnie wersja 3 opublikowana w 1996 Privacy Enhanced Mail (PEM), wykorzystanie w Internecie Dokumenty RFC 1421 RFC 1424 Hierarchiczny model budowy zaufania Kodowanie PEM DER przekształcony base64 i nawiasy Normy RSA Laboratories PKCS#1 PKCS#12 Dokładne procedury kodowania ANS.1/DER w interakcji z szyfrowaniem i wyliczaniem skrótów Metody pakowania certyfikatów, list CRL i kluczy Grupa robocza PKIX - RFC 2459 Certyfikat X509 w Internecie wraz z rozszerzeniami 10
RFC 2459 - certyfikaty Struktura opisana w ANS.1 z kodowaniem binarnym DER Pola podstawowe Certyfikat TBS (to be signed) Identyfikator algorytmu podpisywania MD2/RSA MD5/RSA SHA-1/RSA SHA-1/DSA Podpis (ciąg bitów) Certyfikat TBS Wersja v1(0), v3(2) Numer seryjny Identyfikator algorytmu podpisywania (ten sam co powyżej!) Nazwa DN wystawcy certyfikatu Okres ważności Nazwa DN właściciela certyfikatu Klucz publiczny Rozszerzenia 11
RFC 2459 - certyfikaty Nazwa Distinguished Name Jeżeli dostępne X.500 to pole DN w tym serwisie Pola Kraj C=PL Organizacja O=Wrocław University of Technology Jednostka OU=Institute Computer Engineering Control and Robotics Nazwa własna CN=Darek Caban w IE oczekiwana jest nazwa komputera int.ict.pwr.wroc.pl Inne pola, takie jak miasto, kod pocztowy (nie email!) Nazwa DN musi być unikalna Porównywana jest w całości (zawsze musi mieć te same pola) Klucz publiczny Identyfikator algorytmu RSA, Diffie-Hellman, DSA Wartość klucza 12
RFC 2459 - certyfikaty Rozszerzenia Authority/Subject Key Identifier Dodatkowe rozróżnienie kluczy należących do jednostki Key Usage, Extended Key Usage Do czego można używać klucz Certificate Policies Adres http do CPS i/lub opis tekstowy Identyfikator Subject Alternative Name Adres DNS, http lub email właściciela Name Constraints Ograniczenia drzew nazw DN, które można certyfikować CRL Distribution Points 13
Mechanizmy AAA Uwierzytelnienie (authentication) Identyfikacja Określenie kto wymaga dostępu do zasobów Identyfikacja użytkownika konto Identyfikacja stacji (punktu dostępu) adres internetowy» Odwrotny DNS» Wykorzystanie serwerów finger i ident Uwiarygodnienie identyfikacji, tzn. czy użytkownik i stacja są rzeczywiście tym za kogo się podają Hasła Certyfikaty Autoryzacja Nadanie określonych uprawnień użytkownikom lub stacjom Audyt Rejestracja wybranych czynności użytkownikom 14
Uwierzytelnianie Proste hasło System/serwer przechowuje hasło w postaci zaszyfrowanej (szyfrem nieodwracalnym) Użytkownik podaje tajne hasło, które jest szyfrowane i porównywane z zapamiętanym Znajomość hasła zaszyfrowanego jest niewystarczająca do uzyskania dostępu Zagrożenia Podsłuchanie, kradzież lub w inny sposób ujawnienie hasła Stosowanie tych samych haseł w różnych systemach Zgadnięcie hasła metoda przeglądu zupełnego metoda słownikowa (hasła łatwe, ograniczona wyobraźnia użytkowników) 15
Hasła jednorazowe Program generuje listę haseł dla użytkownika Przy uwierzytelnianiu, użytkownik dostaje numer kolejnego hasła, które ma podać Użytkownik podaje odpowiednie hasło z listy, które nie będzie już nigdy więcej wykorzystane Gdy lista się wyczerpie, generuje się następną Zagrożenia: Ryzyko kradzieży listy haseł Nieporęczność listy Karty identyfikacyjne (token y) Urządzenie zewnętrzne (karta chip owa, breloczek, notes) Użycie karty zabezpieczone hasłem Karta generuje hasło aktualnie (jednorazowo) ważne Karta zsynchronizowana w czasie z serwerem (SecurID) 16
Uwierzytelnianie challenge response Scenariusz 1: Serwer wysyła zapytanie challenge Klient szyfruje jego tekst z hasłem i odsyła jako odpowiedź Serwer rozszyfrowuje odpowiedź lub powiela proces szyfrowania Scenariusz 2: Serwer wysyła do klienta challenge zaszyfrowane hasłem użytkownika Klient rozszyfrowuje go i odsyła. Serwer weryfikuje poprawność rozszyfrowanego tekstu HTTP Digest Challenge nonce="abc" Response response=md5( MD5(A1):nonce:MD5(A2) ) A1: nazwa:realm:hasło A2: metoda:adres strony 17
Kerberos v. 5 Przykład uwierzytelniania poprzez serwer uwierzytelniający Serwer AS (authentication server) Serwer TGS (ticket-granting server) Ticket klucz sesyjny+id klienta zaszyfrowane kluczem serwera Credentials ticket+klucz sesyjny zaszyfrowane kluczem klienta Scenariusz podstawowy Klient wysyła prośbę o ticket serwera do AS AS odsyła credentials, które klient odszyfrowuje Klient przesyła ticket do serwera docelowego Klient i serwer mają wspólny klucz sesyjny do komunikacji Atak odtwarzania klient przesyła zaszyfrowany znacznik czasowy Scenariusz z wykorzystaniem TGS Scenariusz podstawowy ustala tylko ticket serwera TGS (TGT) Ticket dostarczane przez TGS bez szyfrowania kluczem klienta 18
Autoryzacja dostępu do zasobów Uwierzytelnienie może implikować autoryzację Rodzaje dostępu Dla zasobów prostych (plików, rekordów danych,...) Odczyt, modyfikacja, użycie Usuwanie Dostęp do atrybutów, prawo własności Dla zasobów kontenerowych (np. katalogów) Odczyt, dopisywanie/usuwanie, sięganie do elementów Uprawnienia dziedziczone Model w systemach podobnych do Unix a Uprawnienia właściciela, grupy użytkowników, innych Uprawnienia administratora root Listy kontroli dostępu ACL Uprawnienia bazowe Rekordy dodające i ograniczające uprawnienia dla użytkowników i grup 19
Zagrożenia Sieć Serwer Klient podsłuchiwanie podszywanie się zmiana treści Fałszywy serwer i/lub klient odtwarzanie ataki na serwery 20
Po co szyfrować połączenia? Poufność przesyłania danych Ochrona tajemnicy operatora usługi Ograniczenie udostępniania danych Ochrona danych powierzonych budowa zaufania klientów Ochrona prywatności Integralność danych Zmiana danych możliwa po rozszyfrowaniu i zaszyfrowaniu Zmiany strumienia zaszyfrowanego dane nieczytelne Samo szyfrowanie nie jest wystarczające! Autoryzacja przesyłanych danych Szyfrowanie zapewnia słabą autoryzację znajomość wspólnej tajemnicy Zabezpieczenie przed odtworzeniem replay attack Przy pomocy kluczy sesyjnych (nie wynika z szyfrowania) 21
Metody wprowadzenia szyfrowania w usługach sieciowych Warstwa łącza scrambling Warstwa łącza Warstwa IP IPsec Warstwa IP Warstwa tcp/udp SSL / TLS Warstwa tcp/udp Warstwa aplikacji SSH Warstwa aplikacji Serwer Klient 22