Infrastruktura klucza Publicznego

1. Infrastruktura klucza Publicznego Public KeyInfrastructure (PKI) Krzysztof Boryczko Remigiusz Górecki

2. Bezpieczna komunikacja • Poufność (ang. Confidentiality) Przesyłanie informacji w sposób tajny – tylko właściwy adresat może je odczytać. • Autentyczność (ang. Authenticity) Potwierdzenie tożsamości osoby wysyłającej dane – wiadomo kim jest osoba wysyłająca informacje. • Integralność (ang. Integrity) Dane pozostają niezmienione w czasie ich przesyłania. • Niezaprzeczalność (ang. Nonrepudiation) Mamy pewność co do tożsamości osoby wysyłającej dane – nie wyprze się ona przesłanych informacji.

3. Definicja i role PKI • Infrastruktura klucza publicznego – PKI (ang. Public KeyInfrastructure): • Jest to system kryptograficzny umożliwiający bezpieczną wymianę informacji pomiędzy jednostkami (podmiotami) biorącymi udział w transakcji elektronicznej w oparciu o certyfikaty cyfrowe, • Sprawdza tożsamość podmiotów i wydaje im (na określony czas) odpowiednie certyfikaty cyfrowe potwierdzające ich wiarygodność, • Zarządza certyfikatami cyfrowymi: wydaje, przechowuje, dystrybuuje oraz unieważnia je (przechowuje listę unieważnionych certyfikatów), • Umożliwia szyfrowanie informacji w oparciu o klucze publiczne podmiotów biorących udział w wymianie informacji.

4. Relacje zaufania • Każdy podmiot legitymuje się certyfikatem zawierającym jego klucz publiczny. • Konieczna jest pewność że dany klucz należy do danego podmiotu. • Przykładowo ktoś może się chcieć podszyć pod daną firmę dając nam certyfikat należący rzekomo do niej. • Sposoby weryfikacji przynależności certyfikatu: • Osobiście, • Sieć zaufania (ang. Web of trust) , • Infrastruktura klucza publicznego PKI.

5. Osobiste sprawdzanie klucza • Kontaktujemy się telefonicznie z przedstawicielem danego podmiotu (przykładowo firmy), który osobiście dyktuje nam np. odcisk klucza publicznego firmy • Musimy mieć pewność, że po drugiej stronie jest faktycznie osoba posiadająca odpowiednie uprawnienia, • Obdarzamy więc zaufaniem rozmówcę, co może być ryzykowne, • Rozmówca może podać nam przykładowo swój klucz, a nie firmy. • Udajemy się osobiście do siedziby firmy i sami potwierdzamy autentyczność certyfikatu podmiotu • Najbezpieczniejszy sposób – nie ma żadnych osób pośrednich, którym musielibyśmy zaufać, • Najmniej praktyczne – trudno udawać się osobiście do każdego podmiotu (czas i koszty).

6. Zaufanie typu web of trust • Podobna idea jak osobistego sprawdzania. • Nie sprawdzamy osobiście wszystkich, lecz część. • Obdarzamy zaufaniem wybrany przez siebie podmiot, wierząc że on weryfikuje innych. • Możemy wybrać dowolną ilość, dowolnych podmiotów, których obdarzamy zaufaniem. • Przyjmujemy klucze podpisane przez zaufane podmioty. • Budowana jest sieć zaufania – dany podmiot weryfikuje osobiście tych, którzy geograficznie są blisko niego. • Praktyczniejsze niż osobiste sprawdzanie wszystkich. • Nie mamy żadnych gwarancji prawnych, że wybrany podmiot jest uczciwy – sami obdarzamy go zaufaniem. • Stosowane w PGP i podobnych (OpenPGP, GnuPG)

7. Zaufanie w PKI • Istnieją urzędy certyfikacji CA, które obdarzone są zaufaniem przez wszystkie podmioty. • CA są tak zwaną zaufaną trzecią stroną – TTP(ang. Trusted Third Party). • Poświadczają one autentyczność podmiotów w PKI. • Użytkownicy nie wybierają podmiotu, któremu ufają spośród użytkowników lecz obdarzają zaufaniem odpowiednią instytucje. • Najwyżej w hierarchii są główne CA mające odpowiednie poświadczenia prawne. • Kolejne CA są przez nie uwierzytelnione – sieć zaufania. • Istnieją niepotwierdzone CA, których użytkownik sam obdarza zaufaniem.

8. Zaufana trzecia strona – TTP • Instytucja rządowa – w Polsce Narodowe Centrum Certyfikacji prowadzone przez Departament Obrony Narodowego Banku Polskiego, • Firma posiadająca stosowną akredytację – w Polsce: • Krajowa Izba Rozliczeniowa S.A. – „Szafir”, • Polska Wytwórnia Papierów Wartościowych S.A. – „Sygillum” • Unizeto Technologies S.A – „Certum”. • Wydzielona komórka organizacyjna w przedsiębiorstwie administrująca wewnętrzną hierarchią urzędów certyfikacji, które wysyłają certyfikaty odbiorcom końcowym (komputerom, usługom sieciowym lub osobom); nie koniecznie poświadczona przez inne CA.

9. Struktura PKI • W skład infrastruktury PKI wchodzą takie elementy jak CA, RA oraz użytkownicy • Urząd rejestracji – RA (Registration Authority)Potwierdza tożsamość podmiotu ubiegającego się o certyfikat i zezwala (bądź nie) na wydanie certyfikatu dla niego, • Urząd certyfikacji – CA (Certificate Authority)Jest to organizacja wydająca certyfikat cyfrowy w oparciu o klucz publiczny, potwierdzający tożsamość jego właściciela. Jest przykładem „zaufanej trzeciej strony” – TTP (Trusted Third Party) • UżytkownicySą to zarówno instytucje, jak i osoby czy systemy świadczące odpowiednie usługi (www, poczta, itp.) posiadające certyfikaty cyfrowe oraz ich klienci.

10. Przypomnienie pojęć związanych z szyfrowaniem • Szyfrowanie – procedura przekształcania informacji nieszyfrowanej (jawnej) w informację zaszyfrowaną (tajną) za pomocą odpowiedniego klucza. • Deszyfrowanie – procedura przekształcania informacji zaszyfrowanej w jawną z wykorzystaniem odpowiedniego klucza. • Klucz – ciąg znaków o określonej długości, który umożliwia wykonywanie czynności kryptograficznych takich jak szyfrowanie lub deszyfrowanie. • Szyfrogram – zaszyfrowana informacja, która nie jest możliwa do odczytania bez odpowiedniego klucza deszyfrującego.

11. Szyfrowanie symetryczne • Ten sam klucz jest wykorzystywany do szyfrowania i deszyfrowania informacji. • Klucz jest zazwyczaj przypisywany do danego kanału informacyjnego, a nie do posiadacza. • Przykłady: DES, 3DES, AES, RC4, IDEA, Blowfish

12. Rodzaje szyfrowania symetrycznego • Szyfrowanie strumieniowe • Odbywa się na poziomie poszczególnych bitów strumienia danych • Dane są na bieżąco szyfrowane przy użyciu tajnego klucza (np. operacja XOR, który może ulegać zmianie w czasie szyfrowania • Najbardziej znany algorytm to RC4. • Szyfrowanie blokowe • Dane są dzielone na bloki o określonej długości i bloki te są szyfrowane. • Tryb ECB (ang. Electronic CodeBook) – bloki szyfrowane są niezależnie tym samym kluczem. Te same bloki danych dadzą ten sam szyfrogram, a więc łatwiejszy atak na duże dane. • Tryb CBC (ang. Cipher Block Chaining) – blok jawny jest przed szyfrowaniem sumowany (operacja XOR) z szyfrogramem bloku poprzedniego. Pierwszy blok z wektorem inicjalizacyjnym.

13. Szyfrowanie asymetryczne • Klucz publiczny (jawny) adresata wiadomości – dostępny dla wszystkich, upubliczniony, użyty do szyfrowania. • Klucz prywatny (tajny) unikatowy, znany jedynie właścicielowi, chroniony – tylko on może odkodować. • Przykłady: RSA, DSA, ElGamal

14. Podpis cyfrowy • Analogiczny mechanizm jak w przypadku szyfrowania asymetrycznego, lecz odwrotne zastosowanie kluczy. • Stosowane te same algorytmy, jak np. RSA czy DSA. • Klucz prywatny (podmiotu, który podpisuje) wykorzystywany jest przy składaniu podpisu cyfrowego. • Odbiorca zna klucz publiczny nadawcy i weryfikuje nim podpis pod wiadomością.

15. Funkcja skrótu (hash) • Podstawowe cechy funkcji skrótu: • Skrót daje się utworzyć łatwo, natomiast odwrócenie operacji ma być niemożliwe (funkcja jednokierunkowa), • Wynik generowany jest na podstawie całego wejścia, • Zmiana jednego bajtu (znaku) – całkiem inny wynik, • Niezależnie od długości wejścia wynik ma tę samą długość dla danego algorytmu. • Przykłady algorytmów:DES, MD2, MD4, MD5, SHA1, SHA256, SHA512, itp.

16. Cechy szyfrowania symetrycznego • Zalety: • Bardzo szybkie (stosowane do dużych ilości danych), • Zapewnia poufność informacji, • Może (ale nie musi) zapewniać integralności, np. w trybie CBC odszyfrowanie całości gwarantuje, że dane nie zostały zmienione. • Wady: • Jest jeden wspólny klucz, który ma być znany tylko stronom wymieniającym informacje. Problem z przekazaniem klucza w sposób bezpieczny. • Nie zapewnia autentyczności i niezaprzeczalności.

17. Cechy szyfrowania asymetrycznego • Zalety: • Zapewnia poufność informacji, • Nie ma problemu z przekazywaniem kluczy, gdyż prywatny posiada jedynie jego właściciel, • Wykorzystanie podpisu cyfrowego zapewnia integralność, autentyczność i niezaprzeczalność. • Wady: • Stosunkowo wolne (RSA wolniejsze około 1000 razy od DES) – nie nadaje się do szyfrowania większej ilości danych czy strumieni informacji jak w np. w VPN.

18. Realizacja bezpiecznej komunikacji • Poufność – dane są szyfrowane i tylko podmiot znający odpowiedni klucz może je odszyfrować – dla osób trzecich są niemożliwe do odczytania • Kryptografia symetryczna – obie strony posiadają ten sam klucz i tylko one mogą odczytywać przesyłane informacje, • Kryptografia asymetryczna – informacje szyfrowane są kluczem publicznym adresata i tylko on może je odczytać, ponieważ posiada odpowiedni klucz prywatny. • Autentyczność – podpis cyfrowy pod wiadomością potwierdza tożsamość jej autora. • Podpis może złożyć tylko ten kto ma klucz prywatny, • Autor udostępnia klucz publiczny, więc wszyscy którzy go otrzymają mogą weryfikować podpis.

19. Bezpieczna komunikacja c.d. • Integralność – podpis cyfrowy zapewnia o niezmienności danych • Podpis cyfrowy wykonywany jest pod całą wiadomością, • Zmiana danych zmienia podpis cyfrowy, • Najczęściej podpisuje się skrót wiadomości. • Niezaprzeczalność – podpis cyfrowy określa jednoznacznie autora wiadomości – nie wyprze się on jej • Nie ma dwóch takich samych kluczy prywatnych, • Klucz prywatny potrzebny do podpisu znany jest tylko jego właścicielowi, Jak sprawdzić czy klucz prywatny należy do właściwej osoby? Klucz prywatny jest niczym dokument tożsamości – przyznawany jest jedynie właściwej osobie (po potwierdzeniu jej tożsamości). Wydaje go uprawniony organ – TTP.

20. Certyfikat klucza publicznego • Dokument elektroniczny potwierdzający tożsamość podmiotu legitymującego się kluczem publicznym. • Jest podpisany przez podmiot, któremu ufamy – TTP. • Potwierdza autentyczność klucza publicznego. • Zawiera takie informacje jak: • Informacje o podmiocie – jego nazwa, umiejscowienie geograf. Itp. • Informacje o wystawcy, który go podpisał, • Czas ważności certyfikatu, • Klucz publiczny podmiotu, • Podpis elektroniczny wystawcy. • Przykłady certyfikatów: X.509, PGP, SPKI/SDSI

21. Standard X.509 • X.509 – standard ITU-T (International Telecommunication Union w Genewie) wywodzący się ze standardu X.500 • Opisuje certyfikaty i sposób zarządzania nimi w PKI • Umożliwiający stworzenie hierarchicznej struktury powiązanych z sobą CA - w odróżnieniu od Web of Trust. • Określa schemat i normy dla: • Certyfikatów kluczy publicznych, • Odwołań certyfikatów – listy CRL, • Certyfikatów atrybutu uprawnień. • X.509v3 opisany w RFC 5280 i PN-ISO/IEC 9594-8 (2006) • Protokoły i standardy wykorzystujące X.509: smartcard, SSH, IPsec, TLS/SSL – HTTPS, IMAPS, LDAPS, itp.

22. Standard X.509 a X.500 • Standard X.509 wchodzi w skład grupy dotyczącej usług katalogowych i wywodzących się z protokołu X.500. • W certyfikatach X.509 pojawia się nazwa podmiotu i wystawcy – obie jako nazwa wyróżniona w formacie X.500 • Struktura nazwy wyróżnionej (ang. DistinguishedName) • C (Country Name) – nazwa kraju, • ST (State orProvinceName) – nazwa stanu, prowincji, województwa, itp. • L (LocalityName) – nazwa miejscowości, • O (OrganizationName) – nazwa organizacji, • OU (Organization Unit Name) – nazwa jednostki, działu w ogranizacji, • CN (CommonName) – nazwa identyfikująca podmiot.

23. RSA PKCS – standardy PKI • PKCS (ang. Public-KeyCryptographyStandards) – to standardy kryptograficzne publikowane przez RSA The Security Division of EMC. • PKCS to normy przemysłowe dotyczące kryptografii z kluczem publicznym, czyli szyfrowania asymetrycznego. Najczęściej wykorzystywane to: • PKCS #1 – definiuje matematyczne własności oraz format kluczy publicznych i prywatnych dla algorytmu RSA. Opisuje również podstawowe algorytmy wykorzystywane do szyfrowania i tworzenia podpisów z wykorzystaniem RSA. • PKCS #7 – standard kryptograficznego kodowania wiadomości. Opisuje dane, które podlegają operacjom kryptograficznym. Wykorzystywany w przypadku przesyłania żądania odnowienia certyfikatu lub podczas jego eksportowania – RFC 2315

24. RSA PKCS – standardy PKI c.d. • PKCS #8 – standard opisujący format zapisu klucza prywatnego – RFC 5208. • PKCS #10 – standard kodowania wniosku o certyfikat wysyłanego do CA – RFC 2986. • PKCS #11 – standard kodowania interfejsu tzw. żetonu kryptograficznego. Używany w celu realizacji modelu Single sign-onw Infrastrukturze klucza publicznego. Taki format mają certyfikaty cyfrowe umieszczane na kartach inteligentnych. • PKCS #12 – standard kodowania informacji osobistych. Opisuje formaty zapisu danych kryptograficznych. Wykorzystywany przy przesyłaniu pary kluczy (prywatny, publiczny), które są dodatkowo chronione hasłem. Stosowany jest do przechowywania certyfikatów osób.

25. Certyfikat X.509 klucza publicznego • Certyfikat X.509 v3 klucza publicznego składa się z następujących części: • Certyfikat – zawiera standardowe pola opisujące certyfikat oraz opcjonalną część związaną z rozszerzeniami – od wersji 3 X.509 • Algorytm sygnatury certyfikatu – najczęściej SHA1 z RSA • Wartość sygnatury certyfikatu – podpis certyfikatu złożony przez CA w formacie DER w kodowaniu ASN.1

26. Certyfikat X.509 klucza publicznego c.d. • Standardowe i obowiązkowe pola certyfikatu X.509 klucza publicznego zawiera pola – od wersji 2: • Wersja – numer standardu X.509; aktualnie 3 – w polu wartość 2 • Numer seryjny – unikalny w obrębie CA numer certyfikatu • Algorytm sygnatury certyfikatu – najczęściej SHA1 z RSA • Wystawca – nazwa wyróżniona CA, które podpisało certyfikat • Ważność • Nieważny przed – data od kiedy certyfikat jest ważny • Nieważny po – data po której certyfikat traci ważność • Podmiot – nazwa wyróżniona podmiotu, którego jest to certyfikat • Informacje o kluczu publicznym • Algorytm klucza publicznego – najczęściej RSA • Klucz publiczny – zawartość klucza publicznego; z reguły już 2048 bitów

27. Certyfikat X.509 klucza publicznego c.d. • Od wersji 3 X.509 certyfikat może zawierać rozszerzenia. • Umożliwiają definiowanie dodatkowych atrybutów związanych z użytkownikami i zarządzaniem certyfikatami. • Rozszerzenie posiada swe ID, wartość i pole logiczne określające czy jest ono krytyczne. • Gdy jest ono krytyczne musi mieć wartość i być znane. • Przykłady rozszerzeń: • Podstawowe ograniczenia certyfikatu – wartością może być przykładowo „Nie jest organem certyfikacji” – krytyczne, • Punkty dystrybucji CRL – zawiera URI miejsca z listą odwołań certyfikatów – niekrytyczne.

28. Postać DN w X.509 • Nazwa wyróżniona – DN musi jednoznacznie (w obrębie CA) identyfikować podmiot. • DN składa się z części opisującej położenie podmiotu (geograficzne i logistyczne w obrębie organizacji) oraz z nawy potocznej – CN. • W praktyce nazwa potoczna – CN podmiotu powinna spełniać następujące reguły: • W przypadku certyfikatu dla serwera usługi (poczta, www, itp.) jest jego adresem w postaci FQDN – np. poczta.wszib.edu.pl, • W przypadku certyfikatu dla CA jest adresem domenowym organizacji – np. wszib.edu.pl, • W przypadku certyfikatu wystawianego osobie jej imię i nazwisko.

29. Przykład certyfikatu X.509 - suszi

30. Przykład certyfikatu X.509 - tekst Certificate: Data: Version: 3 (0x2) Serial Number: 02:4a:7a:dc:f5:c3:61:7e:1a:d6:da:96:cc:69:7c:30 SignatureAlgorithm: sha1WithRSAEncryption Issuer: C=ZA, ST=WesternCape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com Validity Not Before: Mar 24 00:00:00 2010 GMT Not After : Mar 24 23:59:59 2011 GMT Subject: C=PL, ST=Małopolska, L=Kraków, O=Wyższa Szkoła Zarządzania i Bankowości, OU=suszi, CN=suszi.wszib.edu.pl Subject Public KeyInfo: Public KeyAlgorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:be:e7:16:8b:8c:79:1e:db:f0:9b:65:98:4e:13: ……

31. Przykład certyfikatu X.509 – c.d. Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 CRL DistributionPoints: FullName: URI:http://crl.thawte.com/ThawteServerPremiumCA.crl X509v3 ExtendedKeyUsage: TLS Web Server Authentication, TLS Web ClientAuthentication Authority Information Access: OCSP - URI:http://ocsp.thawte.com SignatureAlgorithm: sha1WithRSAEncryption 03:b6:a6:25:84:4b:28:36:72:27:43:20:58:19:2f:9c:a8:fa: …... -----BEGIN CERTIFICATE----- MIIEFzCCA4CgAwIBAgIQAkp63PXDYX4a1tqWzGl8MDAN …… -----END CERTIFICATE-----

32. Certyfikat X.509 CA • Certyfikat CA od certyfikatu klucza publicznego różni się jedynie wartością odpowiedniego pola rozszerzeń: X509v3 Basic Constraints: CA:TRUE

33. Selfsigned certyfikat CA • Z reguły certyfikaty CA są podpisywane przez inne CA będące wyżej w hierarchii poświadczające autentyczność. • Najwyższe w hierarchii (root certificates) nie mają przez kogo być potwierdzone i podpisane są przez ich twórców(ang. selfsignedcertificates). • Jeśli certyfikat CA nie jest poświadczony przez zaufane CA, to musi być obdarzony zaufaniem przez podmiot korzystający z certyfikatów przez niego podpisanych. • Każdy może utworzyć własne CA i podpisać go samemu – przykładowo CA w firmie – ufają mu wszyscy pracownicy. • Certyfikat selfsigned ma zarówno w polu określającym podmiot jak i wystawcę tę samą nazwę wyróżniającą DN.

34. Ścieżka certyfikatów w X.509 • Gdy certyfikat klucza publicznego podpisany jest przez CA, to przy prawidłowej konfiguracji powinna być widoczna hierarchia – dane uwierzytelniającego CA • W przypadku certyfikatu CA selfsignednie będzie nic ponad nim samym w hierarchii: • Dla certyfikatu klucza publicznego podpisanego przez CA uwierzytelnione przez inne CA ścieżka certyfikacji:

35. Praktyczna realizacja PKI • Najczęściej spotykane wykorzystanie PKI – bezpieczne www (protokół HTTPS) i poczta (POP3S, IMAPS). • Proces potwierdzania tożsamości podczas bezpiecznego połączenia np. www czy poczta: • Łączymy się z witryną, która przedstawia się certyfikatem klucza publicznego, • Oprogramowanie klienckie (przeglądarka, program pocztowy) sprawdza podpis certyfikatu serwera: • Jeśli podpisany jest przez jedno z głównych CA, których listę klient ma wbudowaną, to potwierdza to jego tożsamość, • Jeśli podpisany jest przez nieznane CA, to użytkownik otrzyma stosowne ostrzeżenie i będzie musiał sam potwierdzić zaufanie do niego. • Po uznaniu autentyczności serwera zostaje nawiązana sesja.

36. Ostrzeżenie – nieznane CA • Nawiązanie połączenia z serwerem przedstawiającym się certyfikatem podpisanym przez nieznane CA • Użytkownik musi sam podjąć decyzję czy zaakceptować certyfikat tymczasowo lub na stałe czy go odrzucić.

37. Niezgodność DN z FQDN • Różnicy w adresie z polem DN certyfikatu – niewłaściwa witryna:

38. Import certyfikatu CA • Możliwe jest zaimportowanie do systemu Windows czy Linux certyfikatu danego CA i obdarzenie go zaufaniem. • Certyfikaty kluczy publicznych podpisane przez obdarzone zaufaniem CA będą miały potwierdzaną autentyczność. • Zaimportowanie certyfikatu CA na potrzeby programu firefox:

39. Listy odwołań certyfikatów • Lista odwołanych certyfikatów – CRL (ang. CertificateRevocation List) przechowywana jest w CA. • Znajdują się w niej numery seryjne certyfikatów. • Podmioty korzystające z PKI pobierają cyklicznie CRL i sprawdzają nie tylko ważność czasową certyfikatów, lecz także ich obecność na liście. • Przykładowe przyczyny odwołania certyfikatu w czasie jego ważności: • Zmiana nazwy podmiotu – konieczność zmiany pola DN, • Ujawnienie klucza prywatnego podmiotu, • Odejście pracownika z firmy legitymującego się certyfikatem, • Niemożność wykorzystania klucza prywatnego użytkownika – zgubienie tokenu, zapomnienie hasła do klucza, itp.

40. Certyfikaty atrybutu uprawnień • Certyfikaty atrybutu uprawnień AC (ang. AttributeCertificate) opisane są w RFC 3281. • Wydawane są przez AA (ang. Attribute Authority). • Zawierają atrybuty danego podmiotu określające jego uprawnienia – spełniają funkcję autoryzacji. • Wydawane najczęściej na podstawie uprzedniego uwierzytelnienia podmiotu – sprawdzenia jego certyfikatu klucza publicznego. • Podmiot może posiadać wiele certyfikatów AC nadających mu różne uprawnienia.

41. Sposób uzyskania certyfikatu • Użytkownik za pomocą odpowiedniego oprogramowania generuje, dla siebie lub usługi, żądanie certyfikatu. • Tworzony jest plik ze zgłoszeniem oraz klucz prywatny. • Plik zgłoszenia, zawierający klucz publiczny, wysyłany jest do urzędu certyfikacji – CA. • Urząd rejestracji – RA weryfikuje tożsamość zgłaszającego się podmiotu i po jej potwierdzeniu zezwala CA na wydanie certyfikatu klucza publicznego. • CA przyjmuje zgłoszenie i podpisuje je swoim kluczem prywatnym tworząc certyfikat. • Użytkownik otrzymuje podpisany przez CA certyfikat. • Może już udostępniać otrzymany certyfikat.

42. Utworzenie selfsigned CA • Utworzenie CA za pomocą openSSL: • Przygotowanie pustego pliku na bazę, • Przygotowanie pliku na numery seryjne – na początek wartość 01 • Wygenerowanie certyfikatu – plik ca.crtoraz klucza prywatnego– plik ca.key przykładowym poleceniem: [franio@dns1 ~]$ opensslreq -new -x509 -days 3650 -out ca.crt \ > -keyout ca.key • Po podaniu hasła zabezpieczającego klucz prywatny wygenerowany zostanie klucz prywatny i certyfikat CA. • Stworzony został certyfikat podpisany przez samego siebie – selfsigned CA. Wartości pól Issueroraz Subjectsą takie same.

43. Postać wygenerowanego CA • Wypisanie zawartości utworzonego certyfikatu CA [franio@dns1 ~]$ openssl x509 -in ca.crt -text Certificate: Data: Version: 3 (0x2) Serial Number: ee:14:78:2c:90:85:9e:d2 SignatureAlgorithm: sha1WithRSAEncryption Issuer: C=PL, ST=Malopolska, L=Krakow, O=Firma Frania z.o.o., OU=IT, CN=krakow.wszib.edu.pl/emailAddress=master@krakow.wszib.edu.pl Validity Not Before: Apr 10 12:59:27 2010 GMT Not After : Apr 7 12:59:27 2020 GMT Subject: C=PL, ST=Malopolska, L=Krakow, O=Firma Frania z.o.o., OU=IT, CN=krakow.wszib.edu.pl/emailAddress=master@krakow.wszib.edu.pl Subject Public KeyInfo: …..

44. Wygenerowanie zgłoszenia • Utworzenie za pomocą openSSL zgłoszenia – plik serv.req i klucza prywatnego – serv.key [franio@dns1 ~]$ opensslreq -new -out serv.req -keyoutserv.key • Wypisanie zawartości zgłoszenia [franio@dns1 ~]$ opensslreq -in serv.req -text CertificateRequest: Data: Version: 0 (0x0) Subject: C=PL, ST=Malopolska, L=Krakow, O=Fimrma Frania sp. z.o.o., OU=IT-www, CN=secure.krakow.wszib.edu.pl/emailAddress= frank@krakow.wszib.edu.pl Subject Public KeyInfo: Public KeyAlgorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c9:ec:0c:fc:3d:9d:01:51:27:52:29:6a:05:55: ……

45. Podpisanie zgłoszenia • Podpisanie zgłoszenia (utworzenie certyfikatu): [franio@dns1 ~]$ opensslca -cert ca.crt -keyfileca.key -in serv.req \ > -out serv.crt -days 1825 Signature ok CertificateDetails: Serial Number: 1 (0x1) Validity Not Before: Apr 10 13:57:59 2010 GMT Not After : Apr 9 13:57:59 2015 GMT Subject: countryName = PL stateOrProvinceName = Malopolska organizationName = Firma Frania z.o.o. organizationalUnitName = IT-www commonName = secure.krakow.wszib.edu.pl emailAddress = frank@krakow.wszib.edu.pl …..

46. Podpisanie zgłoszenia c.d. …… X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: CA:58:4D:C7:DD:DF:6A:AC:68:DC:12:99:03:07:F9:3A:1F:13:A8:2F X509v3 Authority Key Identifier: keyid:CA:7F:2A:99:71:D5:E8:BF:AE:34:37:04:A5:C5:B6:51:04:53:7D:93 Certificate is to be certified until Apr 9 13:57:59 2015 GMT (1825 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated

47. Utworzony certyfikat [franio@dns1 ~]$ opensslx509 -in serv.crt-text Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) SignatureAlgorithm: sha1WithRSAEncryption Issuer: C=PL, ST=Malopolska, L=Krakow, O=Firma Frania z.o.o., OU=IT, CN=krakow.wszib.edu.pl/emailAddress= master@krakow.wszib.edu.pl Validity Not Before: Apr 10 14:02:30 2010 GMT Not After : Apr 9 14:02:30 2015 GMT Subject: C=PL, ST=Malopolska, O=Firma Frania z.o.o., OU=IT-www, CN=secure.krakow.wszib.edu.pl/emailAddress=frank@krakow.wszib.edu.pl Subject Public KeyInfo: Public KeyAlgorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:a6:5f:6f:8d:fa:52:7d:19:e6:e1:28:d5:d8:a2: ……

48. Cechy certyfikatu • Ważność certyfikatu została ustalona przez CA podczas podpisywania zgłoszenia i wpisana do certyfikatu. • W polu Subjectznalazła się nazwa wyróżniona podmiotu pobrana ze zgłoszenia. • W polu Issuer jest nazwa wyróżniająca podpisującego CA. • Certyfikat otrzymuje kolejny numer seryjny. • Numery seryjne i przyporządkowane im certyfikaty przechowywane są w bazie CA – jeden certyfikat, to jedna linia: V 150409140230Z 01 unknown /C=PL/ST=Malopolska/O=Firma Frania z.o.o./OU=IT-www/CN=secure.krakow.wszib.edu.pl/emailAddress=master@krakow.wszib.edu.pl

49. Bezpieczne przesyłanie danych protokołów warstwy aplikacji Protokół SSL/TLS Krzysztof Boryczko Remigiusz Górecki

50. Protokół SSL/TLS • Protokół TLS (ang. Transport Layer Security) jest rozwinięciem protokołu SSL (ang. SecureSocketLayer). • Ma za zadanie zapewnić poufność i integralność przesyłanych danych. • Wykorzystuje certyfikaty X.509 i PKI co umożliwia potwierdzenie autentyczności serwera jak i klienta. • Jest protokołem warstwy transportowej i prezentacji – umożliwia enkapsulację i szyfrowanie protokołów warstwy aplikacji; takich jak: HTTP, POP3, IMAP, SMTP, NNTP, itp. • Protokoły wykorzystujące TLS z reguły posiadają przydzielony oddzielny port i otrzymują nazwę z literą „s” na końcu – HTTPS, POP3S, itp. • Wykorzystywany jest również przez OpenVPNi SSL VPN