Infrastruktura klucza Publicznego -...

Public Key Infrastructure (PKI)

Infrastruktura klucza Infrastruktura klucza

PublicznegoPublicznego

Krzysztof Boryczko

Remigiusz Górecki

Bezpieczna komunikacjaBezpieczna 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.

Definicja i role PKIDefinicja i role PKI

Infrastruktura klucza publicznego – PKI (ang. Public Key

Infrastructure):

◦ 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.

Relacje zaufaniaRelacje 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.

Osobiste sprawdzanie kluczaOsobiste 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).

Zaufanie typu Zaufanie typu webweb of trustof 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)

Zaufanie w Zaufanie w PKIPKI

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.

Zaufana trzecia strona Zaufana trzecia strona –– TTPTTP

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.

Struktura PKIStruktura 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.

Przypomnienie pojęć Przypomnienie pojęć

związanych z szyfrowaniemzwią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.

Szyfrowanie symetryczneSzyfrowanie 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

Rodzaje szyfrowania symetrycznegoRodzaje 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.

Szyfrowanie asymetryczneSzyfrowanie 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

Podpis cyfrowyPodpis 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ą.

Funkcja skrótu (Funkcja skrótu (hashhash))

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.

Cechy szyfrowania symetrycznegoCechy 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.

Cechy szyfrowania asymetrycznegoCechy 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.

Realizacja bezpiecznej komunikacjiRealizacja 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.

Bezpieczna komunikacja c.d.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.

Certyfikat klucza publicznegoCertyfikat 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

Standard X.509Standard 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.

Standard X.509 a X.500Standard 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. Distinguished Name)

◦ C (Country Name) – nazwa kraju,

◦ ST (State or Province Name) – nazwa stanu, prowincji,

województwa, itp.

◦ L (Locality Name) – nazwa miejscowości,

◦ O (Organization Name) – nazwa organizacji,

◦ OU (Organization Unit Name) – nazwa jednostki, działu w

ogranizacji,

◦ CN (Common Name) – nazwa identyfikująca podmiot.

RSA PKCS RSA PKCS –– standardy PKIstandardy PKI

PKCS (ang. Public-Key Cryptography Standards) –

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

RSA PKCS RSA PKCS –– standardy PKI c.d.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-on w 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.

Certyfikat X.509 klucza Certyfikat X.509 klucza

publicznegopublicznego 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


publicznego c.d.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


publicznego c.d.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.

Postać DN w X.509Postać 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.

Przykład certyfikatu X.509 Przykład certyfikatu X.509 -- suszisuszi

Przykład certyfikatu X.509 Przykład certyfikatu X.509 -- teksttekstCertificate:

Consulting

cc,

CA/

Zarządzania

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

02:4a:7a:dc:f5:c3:61:7e:1a:d6:da:96:cc:69:7c:30

Signature Algorithm: sha1WithRSAEncryption

Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting

cc, OU=Certification Services Division, CN=Thawte Premium Server

CA/[email protected]

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 Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

Modulus:

00:be:e7:16:8b:8c:79:1e:db:f0:9b:65:98:4e:13: ……

Przykład certyfikatu X.509 Przykład certyfikatu X.509 –– c.d.c.d.Exponent: 65537 (0x10001)

-----

MIIEFzCCA4CgAwIBAgIQAkp63PXDYX4a1tqWzGl8MDAN ……

-----

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Basic Constraints: critical

CA:FALSE

X509v3 CRL Distribution Points:

Full Name:

URI:http://crl.thawte.com/ThawteServerPremiumCA.crl

X509v3 Extended Key Usage:

TLS Web Server Authentication, TLS Web Client Authentication

Authority Information Access:

OCSP - URI:http://ocsp.thawte.com


03:b6:a6:25:84:4b:28:36:72:27:43:20:58:19:2f:9c:a8:fa: …...

-----BEGIN CERTIFICATE-----

MIIEFzCCA4CgAwIBAgIQAkp63PXDYX4a1tqWzGl8MDAN ……

-----END CERTIFICATE-----

Certyfikat X.509 CACertyfikat X.509 CA

Certyfikat CA od certyfikatu klucza publicznego różni się

jedynie wartością odpowiedniego pola rozszerzeń:

X509v3 Basic Constraints: X509v3 Basic Constraints:

CA:TRUE

SelfSelf signedsigned certyfikat CAcertyfikat 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. self signed certificates).

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 self signed ma zarówno w polu określającym

podmiot jak i wystawcę tę samą nazwę wyróżniającą DN.

Ścieżka certyfikatów w X.509Ś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 self signed nie będzie nic

ponad nim samym w hierarchii:

Dla certyfikatu klucza publicznego podpisanego przez CA

uwierzytelnione przez inne CA ścieżka certyfikacji:

Praktyczna realizacja PKIPraktyczna 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.

Ostrzeżenie Ostrzeżenie –– nieznane CAnieznane 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ć.

Niezgodność DN z FQDNNiezgodność DN z FQDN

Różnicy w adresie z polem DN certyfikatu – niewłaściwa

witryna:

Import certyfikatu CAImport 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:

Listy odwołań certyfikatówListy odwołań certyfikatów

Lista odwołanych certyfikatów – CRL (ang. Certificate

Revocation 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.

Certyfikaty atrybutu uprawnieńCertyfikaty atrybutu uprawnień

Certyfikaty atrybutu uprawnień AC (ang. Attribute

Certificate) 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.

Sposób uzyskania certyfikatuSposób uzyskania certyfikatu

1. Użytkownik za pomocą odpowiedniego oprogramowania

generuje, dla siebie lub usługi, żądanie certyfikatu.

2. Tworzony jest plik ze zgłoszeniem oraz klucz prywatny.

3. Plik zgłoszenia, zawierający klucz publiczny, wysyłany

jest do urzędu certyfikacji – CA.

4. Urząd rejestracji – RA weryfikuje tożsamość

zgłaszającego się podmiotu i po jej potwierdzeniu

zezwala CA na wydanie certyfikatu klucza publicznego.

5. CA przyjmuje zgłoszenie i podpisuje je swoim kluczem

prywatnym tworząc certyfikat.

6. Użytkownik otrzymuje podpisany przez CA certyfikat.

7. Może już udostępniać otrzymany certyfikat.

Utworzenie Utworzenie selfself signedsigned CACA

Utworzenie CA za pomocą openSSL:

◦ Przygotowanie pustego pliku na bazę,

◦ Przygotowanie pliku na numery seryjne – na początek wartość 01

◦ Wygenerowanie certyfikatu – plik ca.crt oraz klucza prywatnego

– plik ca.key przykładowym poleceniem:

[franio@dns1 ~]$ openssl req -new -x509 -days 3650 -out ca.crt \[franio@dns1 ~]$ openssl req -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 – self signed CA. Wartości pól Issuer oraz Subject

są takie same.

Postać wygenerowanego CAPostać wygenerowanego CA

[franio@dns1 ~]$ openssl x509 -in ca.crt -text[franio@dns1 ~]$ openssl x509 -in ca.crt -text

Wypisanie zawartości utworzonego certyfikatu CA

Certificate:

OU=IT

CN=krakow.wszib.edu.pl

OU=IT

CN=krakow.wszib.edu.pl

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

ee:14:78:2c:90:85:9e:d2


Issuer: C=PL, ST=Malopolska, L=Krakow, O=Firma Frania z.o.o.,

OU=IT,

CN=krakow.wszib.edu.pl/[email protected]

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/[email protected]

Subject Public Key Info: …..

Wygenerowanie zgłoszeniaWygenerowanie zgłoszenia

Utworzenie za pomocą openSSL zgłoszenia – plik serv.req

i klucza prywatnego – serv.key

[franio@dns1 ~]$ openssl req -new -out serv.req -keyout serv.key[franio@dns1 ~]$ openssl req -new -out serv.req -keyout serv.key

Certificate Request:

z.o.o

[email protected]

Certificate Request:

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=

[email protected]




Modulus:

00:c9:ec:0c:fc:3d:9d:01:51:27:52:29:6a:05:55: ……

[franio@dns1 ~]$ openssl req -in serv.req -text[franio@dns1 ~]$ openssl req -in serv.req -text

Wypisanie zawartości zgłoszenia

Podpisanie zgłoszeniaPodpisanie zgłoszenia

Podpisanie zgłoszenia (utworzenie certyfikatu):

[franio@dns1 ~]$ openssl ca -cert ca.crt -keyfile ca.key -in serv.req \

>

[franio@dns1 ~]$ openssl ca -cert ca.crt -keyfile ca.key -in serv.req \

> -out serv.crt -days 1825

Signature ok

Certificate

…..

Signature ok

Certificate Details:

Serial Number: 1 (0x1)

Validity



Subject:

countryName = PL

stateOrProvinceName = Malopolska

organizationName = Firma Frania z.o.o.

organizationalUnitName = IT-www

commonName = secure.krakow.wszib.edu.pl

emailAddress = [email protected]

…..

Podpisanie zgłoszenia c.d.Podpisanie zgłoszenia c.d.

……

X509v3 extensions:

CA:58:4D:C7:DD:DF:6A:AC:68:DC:12:99:03:07:F9:3A:1F:13:A8:2F

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

……

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

Utworzony certyfikatUtworzony certyfikat

Certificate:

OU=IT

[email protected]

CN=secure.krakow.wszib.edu.pl

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 1 (0x1)


Issuer: C=PL, ST=Malopolska, L=Krakow, O=Firma Frania z.o.o.,

OU=IT, CN=krakow.wszib.edu.pl/emailAddress=

[email protected]

Validity



Subject: C=PL, ST=Malopolska, O=Firma Frania z.o.o., OU=IT-www,

CN=secure.krakow.wszib.edu.pl/[email protected]




Modulus:

00:a6:5f:6f:8d:fa:52:7d:19:e6:e1:28:d5:d8:a2: ……

[franio@dns1 ~]$ openssl x509 -in serv.crt -text[franio@dns1 ~]$ openssl x509 -in serv.crt -text

Cechy certyfikatuCechy certyfikatu

V 150409140230Z 01 unknown

www [email protected].

edu.pl

V 150409140230Z 01 unknown

/C=PL/ST=Malopolska/O=Firma Frania z.o.o./OU=IT-

www/CN=secure.krakow.wszib.edu.pl/[email protected].

edu.pl

Ważność certyfikatu została ustalona przez CA podczas

podpisywania zgłoszenia i wpisana do certyfikatu.

W polu Subject znalazł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:

Protokół SSL/TLS

Bezpieczne przesyłanie danych Bezpieczne przesyłanie danych

protokołów warstwy aplikacjiprotokołów warstwy aplikacji

Krzysztof Boryczko

Remigiusz Górecki

Protokół TLS (ang. Transport Layer Security) jest

rozwinięciem protokołu SSL (ang. Secure Socket Layer).

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 OpenVPN i SSL VPN

Protokół SSL/TLSProtokół SSL/TLS

1994 r. – Netscape opracowuje SSL v1 – wersja

wewnętrzna, niedostępna publicznie.

1995 r. – SSL v2 pierwsza dostępna wersja protokołu.

1996 r. – SSL v3 poprawiona wersja 2, gdyż zawierała ona

błędy związane z bezpieczeństwem.

1999 r. – TLS v1.0 uaktualnienie SSL i uczynienie go

bardziej bezpiecznym. Zmiany na tyle duże, iż jest to nowa

wersja.

2006 r. – TLS v1.1 dodane zabezpieczenie przed pewnymi

atakami na szyfry blokowe CBC.

2008 r. – TLS v1.2 kilka istotnych zmian dotyczących

algorytmów szyfrowania.

Historia protokołu SSL/TLSHistoria protokołu SSL/TLS

Protokół klient / serwer.

Jest to protokół połączeniowy.

Protokół TLS składa się z dwóch warstw:

◦ TLS Record Protocol – umiejscowiony w warstwie transportowej –

ma za zadanie przesyłanie danych w sposób zapewniający

poufność i integralność.

Wykorzystane jest tu szyfrowanie symetryczne – np. 3DES.

◦ TLS Handshake Protocol – umiejscowiony ponad warstwą

transportową (w warstwie prezentacji) – jego zadaniem jest

wynegocjowanie parametrów połączenia, potwierdzenie tożsamości

serwera i klienta (jeśli wymagane) oraz ustalenie klucza sesji.

Wykorzystane jest tu szyfrowanie asymetryczne – głównie RSA.

TLS TLS –– zasada działaniazasada działania

TLS Record Protocol zapewnia bezpieczne połączenie

posiadające następujące cechy:

◦ Prywatność – przesyłane dane są szyfrowane w sposób

symetryczny (RC4, DES, 3DES, itp) z wykorzystaniem unikalnego

klucza. Klucz jest generowany dla danej sesji w czasie fazy

negocjacji – prookół TLS Handshake Protocol,

◦ Autentyczność – dane zawierają MAC (ang. Message

Authentication Code) co potwierdza ich autentyczności. Jest to

swego rodzaju podpis pod danymi wykorzystujący odpowiedni

klucz. Integralność jest zapewniona przez wykorzystanie funkcji

skrótu takich jak MD5 czy SHA.

TLS TLS RecordRecord ProtocolProtocol

TLS Handshake Protocol zapewnia przede wszystkim

nawiązanie sesji i wynegocjowanie jej parametrów.

Wpierw następuje przedstawienie się podmiotów i

ustalenie wstępnych parametrów:

1. Klient wysyła wiadomość „Client hello” a w niej listę

obsługiwanych algorytmów szyfrowania, ID sesji oraz pewną

liczbę losową służącą później do ustalenia klucza sesji.

2. Serwer odpowiada wiadomością „Server hello”, w której wysyła

analogiczne informacje jak klient w swym powitaniu.

3. Serwer przedstawia swą tożsamość wysyłając swój certyfikat

klucza publicznego w formacie X.509. Może też zażądać

potwierdzenia tożsamości klienta. Na koniec wysyła wiadomość

„Server hello done”.

4. Punkt opcjonalny – klient wysyła swój certyfikat klucza

publicznego jeśli tego zażądał serwer.

TLS TLS HandshakeHandshake ProtocolProtocol

Następnie jest ustalenie klucza sesji do szyfrowania

transmisji:

1. Klient wysyła wiadomość „Key exchange” , a w niej

wygenerowany losowo 48-bitowy (w przypadku RSA) premaster

key zaszyfrowany kluczem publicznym serwera.

2. Serwer otrzymawszy wiadomość odszyfrowuje ją swoim kluczem

prywatnym i generuje klucz sesji – do otrzymanego klucza dodaje

jako sól otrzymaną uprzednio losową liczbę od klienta oraz

wygenerowaną wcześniej przez siebie losową liczbę.

3. Klient posiadając wygenerowaną przez serwer liczbę generuje w

analogiczny sposób jak serwer klucz sesji.

TLS TLS HandshakeHandshake ProtocolProtocol c.d.c.d.

Końcowa faza negocjacji to przełączenie się do warstwy

protokołu TLS Record Protocol umożliwiającej bezpieczne

wysyłanie danych:

1. Klient wysyła wiadomość „Change cipher spec” , która informuje

serwer, że klient jest gotów do szyfrowania danych za pomocą

klucza sesji i wynegocjowanego wcześniej algorytmu. Klient

przełącza się do warstwy protokołu TLS Record Protocol.

2. Klient wysyła wiadomość „Client finished”, która jest pierwszą

zaszyfrowaną wiadomością. Zawarte są w niej: klucz sesji,

wynegocjowane algorytmy itp.

3. Serwer otrzymawszy pierwszą wiadomość od klienta przełącza

się do warstwy protokołu TLS Record Protocol.

4. Otrzymawszy wiadomość nr 2 weryfikuje ją i odsyła analogiczną

„Server finished” do klienta.

5. Obie strony gotowe są do szyfrowanej transmisji danych.

TLS TLS HandshakeHandshake ProtocolProtocol c.d.c.d.

Konfiguracja serwera www z SSL/TLS

Użycie protokołu SSL/TLS do Użycie protokołu SSL/TLS do

zabezpieczenia HTTPzabezpieczenia HTTP

Krzysztof Boryczko

Remigiusz Górecki

Instalacja serwera www Apache w dystrybucjach z rodziny

Red Hat – pakiet httpd.

Wykorzystanie protokołu SSL/TLS przez serwer Apache

– instalacja pakietu mod_ssl.

Główny katalog konfiguracyjny serwera www to /etc/httpd.

Znajdują się w nim katalogi:

◦ conf – katalog z plikami konfiguracyjnymi serwera Apache –

znajduje się w nim główny plik konfiguryjny serwera httpd.conf,

◦ conf.d – katalog z plikami konfiguracyjnymi rozszerzeń serwera

– znajduje się w nim między innymi plik ssl.conf, dotyczący

konfiguracji protokłu SSL/TLS.

◦ logs – katalog z dziennikami (logami) serwera,

◦ modules – katalog z modułami roszerzeń serwrera httpd,

◦ run – katalog z plikiem httpd.pid zawierającym PID procesu httpd.

Instalacja Apache z SSL Instalacja Apache z SSL –– RHRH

Plik konfiguracyjny serwera – /etc/httpd/conf/httpd.conf.

W pliku znajdują się definicje atrybutów w postaci

nazwa_atrybutu wartość_atrybutu.

Plik zawiera bardzo dużą liczbę atrybutów; najważniejsze:

◦ User – nazwa użytkownika w kontekście którego będzie

uruchomiony serwer httpd (domyślnie – apache),

◦ ServerName – adres FQDN serwera (ewentualnie adres IP),

◦ ServerAdmin – adres e-mail administratora serwera,

◦ DocumentRoot – główny katalog strony www serwra,

◦ Listen – adres i numer portu na jakim nasłuchuje serwer,

◦ AccessFileName – nazwa pliku z dalszymi ustawieniami

konfiguracyjnymi serwera – domyślnie .htaccess

◦ LogLevel – poziom szczegółowości zapisywania informacji (logów)

– domyślnie warn.

Konfiguracja serwera ApacheKonfiguracja serwera Apache

Plik zawiera również definicje sekcji takich jak IfModule,

Directory, Files, Proxy czy VirtualHost.

Sekcja IfModule zawiera ustawienia dotyczące danego

modułu; przykładowo umożliwienie użytkownikom

wystawiania ich własnych stron w katalogu public_html:

Konfiguracja Apache c.d.Konfiguracja Apache c.d.

<IfModule mod_userdir.c>

</

<IfModule mod_userdir.c>

UserDir public_html

</IfModule>

Strona taka będzie widoczna pod adresem

http://adres.serwera/~nazwa_uzytkownika

Wyłączenie takiej możliwości – ustawienie disabled jako

wartości atrybutu UserDir

Sekcja Directory umożliwia zdefiniowanie własności i

parametrów dostępu związanych z danym katalogiem.

Standardowe ustawienie głównego katalogu ze stroną:

Apache Apache –– Sekcja Sekcja DirectoryDirectory

<Directory ”/var/www/html”>

</

<Directory ”/var/www/html”>

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from all

</Directory>

Ustawienie to oznacza:

◦ Zwrócenie indeksu (listy) plików z katalogu, gdy nie ma w nim pliku

strony, podążanie za dowiązaniami symbolicznymi,

◦ Zabronienie nadpisywania atrybutów wartościami z .htaccess

◦ Pozwolenie wszystkim na dostęp do zawartości tego katalogu.

W przypadku gdy serwer www ma obsługiwać więcej niż

jeden adres FQDN stosuje się hosty wirtualne.

Konfiguracja hosta wirtualnego może zawierać prawie

wszystkie ustawienia jakie definiowane są dla serwera.

Stosuje się aktualnie definicje hostów oparte o ich nazwy

FQDN, a nie jak dawniej o adresy IP.

Przykład włączenia obsługi hostów wirtualnych i definicja

przykładowego hosta www.krakow.wszib.edu.pl

Apache Apache –– hosty wirtualnehosty wirtualne

NameVirtualHost *:80

<

</

NameVirtualHost *:80

<VirtualHost *:80>

ServerName www.krakow.wszib.edu.pl

ServerAdmin [email protected]

ErrorLog logs/krakow.log

DocumentRoot /var/www/krakow

</Directory>

W celu udostępnienia serwera www za pośrednictwem

protokołu HTTPS konieczna jest instalacja i konfiguracja

modułu mod_ssl.

Należy przygotować również następujące certyfikaty w

formacie X.509:

◦ Certyfikat klucza publicznego serwera podpisany przez

odpowiednie CA,

◦ Certyfikat klucza publicznego CA, które podpisało certyfikat serwera

– powinien zostać udostępniony przez CA,

◦ Plik z kluczem prywatnym serwera http – musi zostać umieszczony

w takim miejscu i z takimi prawami, aby dostęp do niego miał tylko

serwer Apache.

Konfiguracja SSL wKonfiguracja SSL w ApacheApache

Konfiguracja modułu mod_ssl znajduje się standardowo w

pliku /etc/httpd/conf.d/ssl.conf

Składnia jest analogiczna jak konfiguracyjnego serwera.

Najważniejsze atrybuty:

◦ Listen – numer portu na którym nasłuchuje serwer na szyfrowane

połączenia za pomocą protokołu HTTPS (standardowo 443)

◦ SSLCertificateFile – ścieżka do certyfikatu serwera,

◦ SSLCertificateKeyFile – ścieżka do pliku z kluczem prywatnym

serwera – odpowiadającemu kluczowi publicznemu z certyfikatu,

◦ SSLCAAertificateFile – ścieżka do certyfikatu CA – dzięki temu we

własnościach certyfikatu widzianych w przeglądarce będzie

widoczny certyfikat CA, które go podpisało,

◦ SSLVerifyClient – umożliwia wymuszenie weryfikacji klienta

– będzie musiał wylegitymować się odpowiednim certyfikatem.

Konfiguracja SSL wKonfiguracja SSL w Apache c.d.Apache c.d.

Infrastruktura klucza Publicznego -...

Documents

Transcript of Infrastruktura klucza Publicznego -...