Public Key Infrastructure

Transkrypt

1 Public Key Infrastructure E L E M E N T Y Z A C Z E R P N I Ę T E Z : E N C R Y P T I O N & S E C U R I T Y T U TO R I A L ( P E T E R G U T M A N N ) H T T P : / / W W W.C S. AU C K L A N D. A C. N Z / ~ P G U T / T U TO R I A L /

2 Składowe bezpieczeństwa Poufność uniemożliwia odczytanie przesyłanych informacji bez odpowiedniego klucza, Integralność umożliwia stwierdzenie, czy odebrane dane nie uległy modyfikacji, Uwierzytelnianie pozwala na weryfikację tożsamości, Niezaprzeczalność pozwala na udowodnienie, że określona wiadomość (nie)została wysłana przez określonego nadawcę, Dostępność gwarantuje nieprzerwany dostęp do zasobu, Kontrola dostępu pozwala na kontrolę dostępu do zasobu.

3

4

5

6

7

8

9

10

11

12 One Time Pad (OTP) Wiadomość P R Z Y K L A D Polega na zsumowaniu, modulo długość alfabetu, kolejnych znaków wiadomości z LOSOWYM ciągiem znaków pełniącym rolę klucza. Odszyfrowanie wymaga znajomości użytego ciągu znaków. Nie do złamania, pod warunkiem: użycia rzeczywiście losowego ciągu znaków, wykorzystania powyższego ciągu tylko raz OTP E Z C P P E F E

13 Algorytmy strumieniowe Wiadomość Ciąg szyfrujący W. zaszyfrowana Wiadomość odszyfrowana XOR Klucz Algorytm Ciąg szyfrujący Wiadomość zaszyfrowana Algorytm wymaga podania klucza szyfrującego i generuje w wyniku ciąg szyfrujący. Dla określonego klucza zawsze otrzymujemy ten sam ciąg szyfrujący. Szyfrowanie odbywa się poprzez użycie funkcji XOR na kolejnych bitach wiadomości i ciągu szyfrującego. Odszyfrowanie odbywa się poprzez użycie funkcji XOR na kolejnych bitach zaszyfrowanej wiadomości i ciągu szyfrującego który został użyty do jej zaszyfrowania.

14 Algorytmy blokowe Algorytmy blokowe przetwarzają bloki danych o określonej długości. Zróżnicowane tryby użycia koderów blokowych, np. : Electronic Codebook ECB Cipher Block Chaining CBC Ciphertext Feedback CFB ECB Klucz Wiadomość Algorytm Klucz Wiadomość Algorytm CBC Wektor inicjalizacyjny Wiadomość Wiadomość Wiadomość zaszyfrowana CFB Wektor inicjalizacyjny Wiadomość zaszyfrowana XOR XOR Klucz Algorytm Klucz Algorytm Klucz Algorytm Wiadomość zaszyfrowana Wiadomość zaszyfrowana Dane XOR Dane zaszyfrowane

15 Algorytmy symetryczne Data Encryption Standard (DES) algorytm blokowy używający klucza 56 bitowego, Data Encryption Standard XORed (DESX) przed zaszyfrowaniem z użyciem DES, dane są XORowane z dodatkowym ciągiem 64bitów, co nieco poprawia poziom bezpieczeństwa, Rivest s Cipher version 2 (RC2 40bit) algorytm blokowy, pracujący na blokach długości 64 bitów; wykorzystuje dodatkowo ciąg 40 bitów (tzw. salt) dodawany do klucza szyfrującego przed jego wykorzystaniem, RC4 algorytm strumieniowy, wykorzystujący klucze różnej długości, często używany np. w protokole SSL, Triple DES (3DES) Odmiana DES, gdzie szyfrowanie odbywa się 3 razy z różnymi kluczami 56 bitowymi: najpierw dane są szyfrowane kluczem A, potem rozszyfrowywane kluczem B, a na koniec szyfrowane kluczem C. Razem daje to odpowiednik klucza 168 bitowego. Advanced Encryption Standard (AES) opracowany jako następca DES algorytm blokowy, wykorzystuje klucze 128, 196 i 256 bitowe.

16 Algorytmy asymetryczne Diffie Hellman key agreement (DH) nie służy do szyfrowania, lecz pozwala 2 stronom na bezpieczne uzgodnienie tajnego materiału kryptograficznego (np. klucza). Rivest Shamir Adleman (RSA) algorytm służący do szyfrowania i podpisywania danych. Najczęściej wykorzystywany z kluczami 1024 bitowymi i dłuższymi. Długość klucza silnie wpływa na czas obliczeń. Gdy używany jest RSA, podpisywanie jest wolniejsze niż sprawdzanie podpisu. Digital Signature Algorithm (DSA) algorytm służący tylko do podpisywania (nie szyfrowania). Obsługuje maksymalną długość klucza 1024 bity. Gdy używany jest DSA, podpisywanie jest szybsze niż sprawdzanie podpisu.

17 RSA Wartości dane: p, q liczby pierwsze, n = p*q, 1 < e < (p-1)*(q-1), (d*e) mod ((p-1)(q-1)) = 1 Klucze: (n, e) = klucz publiczny, (n, d) klucz prywatny, Przykład: p, q = 5, 7, n = p*q = 35, 1<e<4*6=24, e = 5; Klucz publiczny (35, 5). Klucz prywatny: np. (35, 5) bo dla d = 5: (5*5) mod ((5-1)(7-1)) = 1 M wiadomość.

18 RSA Szyfrowanie: C = M e mod n Rozszyfrowanie: M = C d mod n Przykład: Wiadomość: M = 4 Szyfrowanie: C = 4 5 mod 35 C = 1024 mod 35 = 9 Rozszyfrowanie: M = 9 M = 9 5 mod 35 = mod 35 = 4

19 Diffie-Hellman Exchange U1 Wybiera: Liczbę pierwszą: p = 23 Podstawę: g = 5 Klucz prywatny: X a = 6 Oblicza: Klucz publiczny Y a = g Xa mod p Y a = 5 6 mod 23 = mod 23 Y a = 8 Wysyła: p = 23, g = 5, Y a = 8 Otrzymuje: p = 23, g = 5, Y a = 8 Wybiera: Klucz prywatny: X b = 15 Znane Oblicza: publicznie: Klucz publiczny: p, g, Y a, Y b Y b = g Xb mod p Y b = 5 8 mod 23 Y b = 19 Otrzymuje: Y b = 19 Wysyła: Y b = 19 Oblicza: Wspólny klucz: K AB = g XaXb mod p = Y b Xa mod p K AB = 19 6 mod 23 = 2 K AB = 8 Xb mod 23 = 19 Xa mod 23 U2 Oblicza: Wspólny klucz: K AB = g XaXb mod p = Y a Xb mod p K AB = 8 15 mod 23 = 2

20 Długości klucza (oszacowanie) Algorytm symetryczny Algorytm asymetryczny Algorytm ECC Dodatkowo: klucz symetryczny używany jest raz na wiadomość/sesję, a klucz asymetryczny wielokrotnie.

21 Podpisane przez CA Certyfikaty X.509 v1 Zawiera: pola techniczne, nazwę właściciela, nazwę wystawcy, okres ważności, klucz publiczny właściciela. Podpisane przez wystawiające CA.

22 Certyfikaty X.509 v2 Wprowadzono pola: Issuer Unique ID Subject Unique ID w celu: zmniejszenia prawdopodobieństwa kolizji nazw, poprawy działania mechanizmów tworzenia łańcuchów certyfikatów, poprawy wsparcia dla odnawiania certyfikatów CA. Obecnie (RFC3280) użycie tych pól jest niezalecane.

23 Certyfikaty X.509 v3 Wersja 3 stanowi rozbudowę wersji 2 o tzw. rozszerzenia (extensions). Rozszerzenia identyfikowane są z użyciem OID. Rozszerzenia oznaczone jako krytyczne (critical) muszą zostać rozpoznane przez aplikację, albo certyfikat nie zostanie użyty.

24 Ważniejsze rozszerzenia Key usage określa ogólne zadania ( niskopoziomowe ) w których certyfikat może być wykorzystany: Digital signature może być użyty od weryfikacji podpisu właściciela certyfikatu, Non repudiation może być użyty do jednoznacznego określenia tożsamości podpisującego, Key encipherment może służyć do bezpiecznego przesyłania kluczy szyfrujących (np. symetrycznych), używanych następnie np. do (za/od)szyfrowania danych. Używane gdy wykorzystujemy mechanizmy RSA do zarządzania kluczami. Data encipherment może służyć do bezpośredniego szyfrowania danych z użyciem kryptografii asymetrycznej. Key agreement może służyć do uzgadniania klucza (np. symetrycznego), używanego następnie np. do (za/od)szyfrowania danych. Używane gdy wykorzystujemy mechanizmy DH (Diffie Hellman) do zarządzania kluczami. Key cert sign może zostać użyty do sprawdzania poprawności podpisanego certyfikatu, CRL Sign może zostać użyty do weryfikacji podpisanej listy odwołań certyfikatów (CRL). Encipher only użyty w połączeniu z Key agreement oznacza, że uzyskany klucz symetryczny, może być wykorzystywany tylko do zaszyfrowywania danych. Decipher only użyty w połączeniu z Key agreement oznacza, że uzyskany klucz symetryczny, może być wykorzystywany tylko do odszyfrowywania danych.

25 Ważniejsze rozszerzenia Enhanced key usage zawiera bardziej szczegółowe informacje o możliwości wykorzystania certyfikatu. Mają one postać listy identyfikatorów OID oznaczających różne zastosowania. Aplikacja może wymagać obecności określonych OID, aby wzięła pod uwagę dany certyfikat. Przykłady najpopularniejszych: Client Authentication (uwierzytelnianie klienta) Server Authentication (uwierzytelnianie serwera) Secure e Mail (zabezpieczenie poczty ) CRL distribution point zawiera URL miejsca, skąd można pobrać listę CRL, w której należy szukać informacji o ewentualnym odwołaniu danego certyfikatu. System Windows pozwala na wykorzystanie protokołów HTTP, FTP i LDAP. Authority Information Access (AIA) zawiera URL miejsca, skąd można pobrać certyfikat CA, które wystawiło dany certyfikat.

26 Ważniejsze rozszerzenia Basic constraits pozwala na określenie czy certyfikat przeznaczony jest dla CA, użytkownika, komputera, urządzenia sieciowego... Pozwala także na określnie maksymalnej liczby poziomów potomnych CA. Name constraits określa dozwolone nazwy podmiotów w wystawianych przez CA certyfikatach.

27 Certificate Authority Zadania CA: Weryfikuje podmiot Wystawia certyfikat Zarządza odwołaniami Wymagania: Posiada klucz prywatny i certyfikat Certyfikat informuje o prawie do wystawiania certyfikatów innym Przestrzega polityki wystawiania certyfikatów Określeni odbiorcy i sposób ich weryfikacji Określone rodzaje certyfikatów/parametry Użytkownicy muszą ufać, że wystawiając certyfikaty poświadcza prawdę tzn. przestrzega przyjętej polityki. Certyfikat CA ID właściciela Klucz prywatny właściciela Klucz publiczny właściciela Parametry dodatkowe Informacje uwierzytelniające ID właściciela Klucz publ. właściciela Inne atrybuty ID wystawcy Podpis elektroniczy Polityka CA Klucz prywatny CA ID właściciela, Inne atrybuty, ID wystawcy Podpis elektroniczy Certyfikat

28 Proces uzyskiwania certyfikatu Klient generuje klucze publiczny i prywatny. ID właściciela Klucz prywatny właściciela Klucz prywatny jest najczęściej szyfrowany przed zapisaniem na dysku, karcie itp., co powoduje każdorazową konieczność podania hasła (najczęściej pełniącego role klucza szyfrującego w algorytmie symetrycznym) przed jego użyciem. Bezpieczny magazyn Klucz publiczny właściciela Parametry dodatkowe Informacje uwierzytelniające CA CSR Klient tworzy żądanie certyfikatu (Certificate Signing Request CSR), łącząc: klucz publiczny, dodatkowe informacje identyfikacyjne, np. nazwę, kraj, miasto (najważniejszym parametrem jest common name) pożądane rozszerzenia certyfikatu, np.: okres ważności, zbiór możliwych sposobów wykorzystania certyfikatu itp.

29 Proces uzyskiwania certyfikatu Żądanie certyfikatu przesyłane jest do urzędu certyfikacji (CA), które: sprawdza techniczną poprawność (format) żądania, sprawdza czy polityka (policy) CA pozwala na podpisanie certyfikatu o podanych informacjach identyfikacyjnych (np. CA Politechniki Gdańskiej będzie najprawdopodobniej podpisywało tylko certyfikaty, w których organizacja właściciela jest określona jako Politechnika Gdańska ) żądanie zostaje zaakceptowane lub odrzucone, Certyfikat CA ID właściciela Klucz publ. właściciela Inne atrybuty ID wystawcy Podpis elektroniczy Polityka CA Klucz prywatny CA Inne atrybuty CSR ID właściciela, Inne atrybuty, ID wystawcy Podpis elektroniczy Certyfikat ID, Klucz publiczny sprawdza czy żądane przez klienta rozszerzenia certyfikatu są zgodne z dopuszczalnymi: cześć rozszerzeń z żądania może zostać umieszczona w certyfikacie bez zmian, część może zostać usunięta/zmodyfikowana, a nowe rozszerzenia dopisane do generowanego certyfikatu. klucz publiczny wraz z dodatkowymi informacjami i rozszerzeniami zostaje podpisany przez CA jego kluczem prywatnym, tworząc certyfikat. Klient otrzymuje certyfikat, który jest potem wykorzystywany w połączeniu z jego kluczem prywatnym.

30 Hierarchia CA Root CA (główne) posiada certyfikat samo który tworzy podpisując go własnym kluczem prywatnym (self-signed certificate) Jest znane odbiorcom (nie wnikamy skąd) i na tyle obdarzone zaufaniem, że nie wymaga poświadczenia od nikogo innego. Odbiorcy muszą jawnie uznać takie CA za zaufane, dodając jego certyfikat do odpowiednej listy. Stanowi korzeń każdego drzewa zaufania jest konieczne dla działania PKI. Intermediate CA (pośrednie) posiada certyfikat, który został mu wydane przez inne CA (Parent CA), które poświadcza tym samym, że jego zdaniem dane CA (Child CA) jest godne zaufania. Zatem jeśli ufamy Parent CA, to możemy też automatycznie zaufać danemu Child CA. Odbiorcy nie muszą jawnie dodawać takiego CA do listy zaufanych.

31 Certificate Chain Jeśli mamy sprawdzić czy ufamy danemu certyfikatowi (np. użytkownika), to musimy sprawdzić, czy ufamy temu kto ten certyfikat wystawił (CA) trzeba sprawdzić jego certyfikat. Jeśli CA, które wystawiło dany certyfikat to Intermediate CA, to trzeba sprawdzić, czy ufamy CA które z kolei jemu wystawiło certyfikat. W ten sposób w końcu dotrzemy do certyfikatu Root CA, które samo sobie poświadczyło swój certyfikat. Wtedy sprawdzamy czy jest na naszej liście zaufanych. DOWOLNY błąd w całym tym procesie skutkuje brakiem zaufania do sprawdzanego certyfikatu. Certyfikat Certyfikat CA ID właściciela Certyfikat CA ID właściciela ID właściciela Klucz publiczny właściciela Inne atrybuty Klucz publ. właściciela Inne atrybuty ID wystawcy Podpis elektroniczy Certyfikat CA Klucz publ. właściciela Inne atrybuty ID wystawcy Podpis elektroniczy Certyfikat Root CA Lista zaufanych certyfikatów - - Certyfikat ID wystawcy ID właściciela Klucz publ. właściciela Inne atrybuty ID właściciela Klucz publ. właściciela Inne atrybuty Podpis elektroniczy ID wystawcy ID wystawcy Podpis elektroniczy Podpis elektroniczy

32 Przykłady hierarchii CA Root CA stanowi korzeń hierarchii zaufania Policy CA wystawia certyfikaty dla Issuring CA, pozwalające na wystawiania certyfikatów: określonego typu dla określonych odbiorców Issuing CA wystawia certyfikaty dla odbiorców końcowych w ramach ograniczeń narzuconych przez własny certyfikat Najbezpieczniejszy system to taki, który nie oferuje żadnej funkcjonalności tzn. WYŁĄCZONY: Offline CA uruchamiane okresowo, pod ścisłą kontrolą administratora. Online CA realizujące usługę w sposób ciągły, wg skonfigurowanej polityki. Np żądań / rok Np żądań / miesiąc Np. 1 żądanie / s

33 Odwołanie certyfikatu Bez dodatkowych mechanizmów certyfikat pozostawałby ważny, aż upłynie jego okres ważności. Aby unieważnić go przed tym terminem stosujemy: Listy odwołań certyfikatów (Certificate Revocation Lists CRLs) Protokół Online Certificate Status Protocol OCSP HTTP CRL Download Okresowe wygenerowanie listy CRL Klient Serwer HTTP CLR CA Dostęp do bazy danych OCSP Response Klient Serwer OCSP Baza informacji o certyfikatach

34 Listy CRL Jest to, podpisana przez CA, lista numerów seryjnych wszystkich certyfikatów, które z różnych powodów zostały odwołane (revoked), a których okres ważności jeszcze nie minął. Lista CRL: jest generowana przez CA wyłącznie dla certyfikatów wydanych przez dane CA, ma swój okres ważności, przed/równo z upłynięciem którego musi zostać wygenerowana nowa jej wersja, jest podpisana przez wystawiające CA. Występują 2 rodzaje list CRL: bazowe (base CRL) lista obejmuje wszystkie certyfikaty odwołane przez dane CA, których okres ważności jeszcze trwa. różnicowe (delta CRL) lista obejmuje wyłącznie certyfikaty odwołane od czasu wygenerowania ostatniej listy bazowej. Base CRL (stan w chwili t 0 ) Delta CRL 1 (stan w chwili t 0 ) Delta CRL 2 (stan w chwili t 1 ) Delta CRL 3 (stan w chwili t 2 ) t 0 t 1 t 2 Czas

35 Listy CRL Listy CRL są pobierane przez klientów w razie potrzeby i przechowywane do momentu utraty ważności. Pobieranie list CRL odbywa się najczęściej z wykorzystaniem popularnych protokołów, takich jak np.: HTTP, FTP, LDAP. Klient Pobranie listy Serwer HTTP CLR Okresowe wygenerowanie listy CRL CA Lokalna baza list CRL Weryfikacja certyfikatu Baza informacji o certyfikatach Okres ważności listy CRL Okres ważności listy CRL Lista przechowywana w lokalnej bazie Lista przechowywana w lokalnej bazie Żądanie weryfikacji certyfikatu Pobranie listy CRL Czas

36 Listy CRL Lista CRL powinna być sprawdzana przez aplikację (lub okresowo przez system operacyjny i wyniki udostępniane aplikacjom) zanim certyfikat zostanie uznany za ważny jednak w rzeczywistości często krok ten nie jest realizowany. W przypadku niektórych funkcji, nowe (2008+, Win7) systemy operacyjne MS sprawdzają CRL przy każdym użyciu danego certyfikatu. Brak dostępu do listy CRL traktowany jest jako stan krytyczny, uniemożliwiający użycie certyfikatu. Dotyczy to również braku informacji o sposobie dostępu do danego CRL. Każdy z odwołanych numerów seryjnych opatrzony jest powodem odwołania, np.: Key compromise klucz prywatny powiązany z danym certyfikatem został ujawniony, CA compromise klucz prywatny podpisującego CA został ujawniony, Affiliation changed właściciel certyfikatu przestał być częścią wystawiającej organizacji, Superseded certyfikat został zastąpiony uaktualnionym, Cessation of operation właściciel certyfikatu (np. serwer WWW) zaprzestał działalności, Certificate hold powoduje tymczasowe ZAWIESZENIE ważności certyfikatu. Jedyny przypadek, gdy certyfikat może odzyskać ważność.

37 OCSP Protokół pozwalający na uzyskanie informacji na temat aktualnego stanu określonego certyfikatu. protokół bazujący na protokole HTTP, w zapytaniu wskazujemy konkretny identyfikator certyfikatu, zwracany stan: valid lub revoked. W przeciwieństwie do list CRL generuje wiele pojedynczych, niewielkich zapytań rozłożonych w czasie. Listy CRL generują znaczący ruch w postaci dłuższych transferów w okresie następującym po wygenerowaniu nowej listy. OCSP Response Status: successful (0 0) Response Type: Basic OCSP Response Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 922CD93C975EDC121DB25B1A55BA9B544E06F9B3 Issuer Key Hash: 322A8DBF79BE1A934543DC4F24FC69220A2803BA Serial Number: 06 Cert Status: revoked Revocation Time: Feb 27 01:07: GMT This Update: Feb 27 01:12: GMT Response verify OK dummy.isrlabs.net.crt: revoked This Update: Feb 27 01:12: GMT Revocation Time: Feb 27 01:07: GMT

38 Weryfikacja certyfikatu Otrzymany certyfikat sprawdzany jest pod względem podstawowej poprawności formatu. Tworzony jest łańcuch certyfikatów (certificate chain), zawierający sprawdzany certyfikat, certyfikat CA które wystawiło dany certyfikat, oraz (jeśli jest to CA pośrednie) to również certyfikaty wszystkich CA nadrzędnych, aż do root CA (typu self signed). Dla całego łańcucha: Sprawdzane są krytyczne rozszerzenia certyfikatu (własności które muszą być rozumiane przez aplikację) jeśli występuje jakaś niezrozumiała, certyfikat jest odrzucany. Sprawdzane są rozszerzenia certyfikatu, aby sprawdzić, czy jest on możliwy do życia w roli w której próbuje go wykorzystać aplikacja (np. do podpisywania), Sprawdzane są listy CRL, w celu weryfikacji, czy żaden z certyfikatów nie został odwołany. Sprawdzana jest poprawność podpisów CA, w celu wykrycia ewentualnych, nieuprawnionych modyfikacji certyfikatów. Sprawdzany jest okres ważności certyfikatu. Następuje sprawdzenie czy łańcuch certyfikatów kończy się znanym, zaufanym certyfikatem root CA (typu self signed). Oznacza to, że jeśli ufamy root CA, a łańcuch jest poprawny i nieprzerwany aż do badanego certyfikatu, to jemu też możemy zaufać.

39 Public Key Cryptography Standards PKCS #1 RSA Cryptography Standard Name Comments See RFC Defines the mathematical properties and format of RSA public and private keys (ASN.1-encoded in clear-text), and the basic algorithms and encoding/padding schemes for performing RSA encryption, decryption, and producing and verifying signatures. PKCS #3 Diffie-Hellman Key Agreement Standard PKCS #5 Password-based Encryption Standard See RFC 2898 and PBKDF2. PKCS #7 Cryptographic Message Syntax Standard A cryptographic protocol that allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. See RFC Used to sign and/or encrypt messages under a PKI. Used also for certificate dissemination (for instance as a response to a PKCS#10 message). Formed the basis for S/MIME, which is as of 2010 based on RFC 5652, an updated Cryptographic Message Syntax Standard (CMS). Often used for single sign-on. PKCS #8 Private-Key Information Syntax Standard See RFC Used to carry private certificate keypairs (encrypted or unencrypted). PKCS #9 Selected Attribute Types PKCS #10 Certification Request Standard PKCS #11 Cryptographic Token Interface (Cryptoki) PKCS #12 Personal Information Exchange Syntax Standard Defines selected attribute types for use in PKCS #6 extended certificates, PKCS #7 digitally signed messages, PKCS #8 private-key information, and PKCS #10 certificate-signing requests. See RFC Format of messages sent to a certification authority to request certification of a public key. See certificate signing request. An API defining a generic interface to cryptographic tokens (see also Hardware Security Module). Often used in single sign-on, Public-key cryptography and disk encryption systems. Defines a file format commonly used to store private keys with accompanying public key certificates, protected with a password-based symmetric key. PFX is a predecessor to PKCS#12. This container format can contain multiple embedded objects, such as multiple certificates. Usually protected/encrypted with a password. Usable as a format for the Java key store. Usable by Tomcat, but not by Apache. PKCS #13 Elliptic Curve Cryptography Standard PKCS #14 Pseudo-random Number Generation PKCS #15 Cryptographic Token Information Format Standard Defines a standard allowing users of cryptographic tokens to identify themselves to applications, independent of the application's Cryptoki implementation (PKCS #11) or other API.

40 MIME Rozwiązanie Multipurpose Internet Mail Extension (MIME) stworzono w związku z ograniczeniami protokołu SMTP: Maksymalnie 998 znakowe linie 7-bitowych (1-127) znaków, gdzie wartości 10 i 13 mogą występować wyłącznie razem, jako znacznik końca linii. Pozwala na przesyłanie dowolnych danych (w tym binarnych) wraz z informacją o sposobie ich przetwarzania oraz definiuje strukturę wiadomości złożoną z wielu elementów. W chwili obecnej jest ogólnie przyjętym standardem kodowania różnorodnych wiadomości przesyłanych w sieci Internet. MIME definiuje nowe pola nagłówka wiadomości: MIME-Version: 1.0 identyfikuje wiadomość jako wykorzystującą format MIME, Content-Type określa rodzaj zawartości danej wiadomości, Content-Disposition informuje o zalecanym sposobie prezentacji treści, Content-Transfer-Encoding określa, w jaki sposób przesyłane są dane binarne.

41 Przykładowe wartości Content Type Typ Podtyp Text plain Tekst ASCII enriched Tekst z formatowaniem Multipart mixed Wiadomość złożona z wielu niezależnych elementów, lecz powinny być one przetwarzane w kolejności w jakiej występują. parallel alternative signed Jak wyżej, lecz kolejność nie jest istotna. Image jpeg Obraz w formacie jpeg gif Elementy wiadomości zawierają tę samą treść w różnych formach, w kolejności wzrastającej preferencji. Wiadomość podpisana cyfrowo. Zawiera 2 części: pierwsza to treść wiadomości (typ dowolny), druga (typu application/pkcs7-signature) to podpis. Obraz w formacie gif Video mpeg Zapis filmowy w formacie MPEG Audio basic Zapis dźwiękowy w formacie ISDN u-law Application octet-stream Dane binarne pkcs7-mime pkcs7-signature pkcs10-mime Dane zabezpieczone (enveloped data) Podpis cyfrowy (patrz multipart/signed) Żądanie certyfikatu

42 Content-Transfer-Encoding Sposób przetwarzania danych binarnych 7bit standardowe dane w formacie zgodnym z SMTP 8bit jak wyżej, lecz znaki mogą przybierać wartości binary dane binarne w postaci 8 bitowych znaków base64 dane binarne przekształcone w zapis wykorzystujący 7 bitowe znaki. ghyhhhuujhjhjh77n8hhgtrfvbnj756tbb9hg4vqpfyf467ghigfhfyt6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8hhgtrfvhjhjh776tbb9hg4vqbnj7567ghigfhfyt6ghyhhhuujpfyf4 quoted-printable dane binarne, gdzie standardowe znaki 7bit przesyłane są w sposób niezmodyfikowane, a inne znaki zapisywane są z użyciem specjalnych kodów spełniających wymogi 7bit. W efekcie Przyk=C5=82adowy tekst

43 S/MIME multipart/signed Content-Type: multipart/signed; protocol= application/pkcs7-signature ; micalg=sha1; boundary=boundary --boundary Content-Type: text/plain This is a clear-signed message. --boundary Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyhhhuujhjhjh77n8hhgtrfvbnj756tbb9hg4vqpfyf467ghigfhfyt6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8hhgtrfvhjhjh776tbb9hg4vqbnj7567ghigfhfyt6ghyhhhuujpfyf4 --boundary--

44 S/MIME application/pkcs7-mime MIME-Version: 1.0 Content-Disposition: attachment; filename="smime.p7m" Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data; name="smime.p7m" Content-Transfer-Encoding: base64 MIICQQYJKoZIhvcNAQcDoIICMjCCAi4CAQAxggEKMIIBBgIBADBvMGoxCzAJBgNV BAYTAlBMMRIwEAYDVQQIEwlQb21vcnNraWUxDzANBgNVBAcTBkdkYW5zazEQMA4G A1UEChMHV0VUSSBQRzEMMAoGA1UECxMDS1RJMRYwFAYDVQQDEw1MYWIxNDIgUm9v denbagebma0gcsqgsib3dqebaquabigaexaxkj5akyra6tdpmwp8fudnlvog/9my g87ia6i5hyanyhy/9fyagqj+jurpegmsvgltlfsbqu9fhcioufl8u3zcq9s1y7qm SheonXVosGMQLl4jzEps+dO6YFLVc5cGMOA4ATB+Uv/p+OFEHZHU1/T6Ok7EiUiu V3TCVDFC6aIwggEZBgkqhkiG9w0BBwEwEQYFKw4DAgcECPj5p/1NZ+ZegIH4SxqU Bu89JdJXIUspDh4RvcuZSoPRvxBlwDb+Zz6BhIuF0LLbOZ7Lx9W2TY0S7f6ZCo4B HHCOJR4iiB8h/d9iubUOkErqjZ4olchzW1iMgcMWmakXsde/DIRQoO+s2+2hKH93 wga8c0qulext0rjvokmypibrtjhiphymv52ntdnmhzyc+bcnbmsjsyys+ehlxnhj PjyQcHOif72EFGz+eclVorW6k0iSb7s2/L37pVff6qZGnGyF3/2QtkA8Kz4/l1c3 ZqNBSV/7HHqeiRqNAjAdlRe6coUTYfCzMrHPeerr/22grNQ7CZpTVxO48svC0xzY l8s5k3o=

45 OpenSSL

46 OpenSSL Standard commands asn1parse ca ciphers cms crl crl2pkcs7 dgst dh dhparam dsa dsaparam enc engine errstr gendh gendsa genpkey genrsa nseq ocsp passwd pkcs12 pkcs7 pkcs8 pkey pkeyparam pkeyutl prime rand req rsa rsautl s_client s_server s_time sess_id smime speed spkac ts verify version x509 Message Digest commands md2 md4 md5 rmd160 sha sha1 Cipher commands aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb aes-256-cbc aes-256-ecb base64 bf bf-cbc bf-cfb bf-ecb bf-ofb camellia-128-cbc camellia-128-ecb camellia-192-cbc camellia-192-ecb camellia-256-cbc camellia-256-ecb cast cast-cbc cast5-cbc cast5-cfb cast5-ecb cast5-ofb des des-cbc des-cfb des-ecb des-ede des-ede-cbc des-ede-cfb des-ede-ofb des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb des-ofb des3 desx rc2 rc2-40-cbc rc2-64-cbc rc2-cbc rc2-cfb rc2-ecb rc2-ofb rc4 rc4-40 seed seed-cbc seed-cfb seed-ecb seed-ofb zlib

47 Wybrane polecenia req służy do generowania kluczy prywatnych i żądań certyfikatów (Certificate Signing Request - CSR) w formacie X.509, ca służy do obsługi urzędu certyfikacji, wymaga poprawnie skonfigurowanego pliku openssl.cnf pkcs12 pozwala na obsługę formatu PKCS#12, używanego do importu i eksportu certyfikatów wraz z kluczami prywatnymi, x509 umożliwia zarządzanie certyfikatami X.509, enc pozwala na szyfrowanie i rozszyfrowywanie, rsautl pozwala na bezpośrednie wykorzystanie kryptografii asymetrycznej do szyfrowania i podpisywania niewielkich ilości danych, smime funkcje pozwalające na obsługę wiadomości w formacie S/MIME, crl umożliwia zarządzanie listami CRL, ocsp pozwala na uruchomienie i odpytanie serwera OCSP.

48 Plik konfiguracyjny: openssl.cnf

49 Openssl.cnf Używany przez polecenia: ca działania związane z lokalnym CA, req generowanie żądań certyfikatów, x509 działania związane z wystawionymi już certyfikatami, crl / ocsp zarządzanie odwołaniami certyfikatów. Odczytywany jest z folderu ustalonego podczas kompilacji pakietu OpenSSL (np. /etc/pki/tls/openssl.cnf) Możliwe podanie innej ścieżki z linii polecenia. Podzielony na sekcje o tytułach umieszczonych w [ ].

50 Openssl.cnf [ca] default_ca = CA_default Wybór domyślnego CA Domyślne parametry żądań certyfikatów [req] distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_selfsigned req_extensions = v3_request... [CA_default] policy = policy_match crl_extensions = crl_ext x509_extensions = usr_cert... [inne_ca] policy =... crl_extensions =... x509_extensions = Parametry CA: CA_default [policy_match]... [usr_cert]... [req_distinguished_name]... [req_attributes]... [v3_selfsigned]... [v3_request]... [crl_ext]... Parametry CA: inne_ca Polityka wystawiania certyfiaktów Parametry generowanych list CRL Parametry wystawianych certyfikatów Definicja pól identyfikujących właściciela certyfikatu Definicja pól dodatkowych Rozszerzenia dodawane do certyfikatu self-signed Rozszerzenia dodawane do żądania certyfikatu

51 Sekcja [ca] OpenSSL pozwala na obsługę kilku niezależnych CA, każdej opisanej własną sekcją w pliku konfiguracyjnym. Do konkretnej CA można odwoływać się z użyciem parametru linii polecenia: -name <nazwa_sekcji_ca>. Jeśli nie podamy tego parametry z linii polecenia, użyta zostanie domyślna definicja CA, określona w sekcji [ca]: [ca] default_ca = <nazwa_domyślnej_sekcji_ca> Standardowo sekcja opisująca domyślne CA nazwana jest CA_default [ca] default_ca = CA_default

52 Domyślna sekcja [CA_default] Stanowi definicję CA używanego domyślnie. Dane podstawowe: dir = /etc/pki/przykladca - główny folder CA. Używany dalej jako $dir certificate = $dir/ca.cer - certyfikat CA, private_key = $dir/private/ca.key klucz prywatny CA, RANDFILE = $dir/private/.rand - plik służący generacji danych losowych, policy = policy_match zawiera odwołanie do sekcji określającej politykę przyznawania certyfikatów. Baza wystawionych certyfikatów: database = $dir/index.txt - Plik zawierający informacje o wystawionych certyfikatach, new_certs_dir = $dir/newcerts - Folder w którym zapisywane są kopie wystawionych certyfikatów, serial = $dir/serial - Plik zawiera numer seryjny następnego certyfikatu.

53 Domyślna sekcja [CA_default] Lista CRL: crlnumber = $dir/crlnumber zawiera numer seryjny aktualnej listy CRL, crl = $dir/crl.pem - plik zawierający aktualną listę CRL. default_days = jak długo ważna jest lista CRL default_crl_days= 30 - kiedy będzie dostępna nowa lista CRL default_md = sha1 - funkcja skrótu używana przy podpisywaniu listy CRL crl_extensions = crl_ext zawiera odwołanie do sekcji pozwalającej zdefiniować rozszerzenia listy CRL. Parametry wystawianych certyfikatów: x509_extensions = usr_cert sekcja zawierająca właściwości dodawane do wystawianego certyfikatu przez CA. unique_subject = no - Ustawienie na 'no' pozwala tworzyć kilka certyfikatów z takimi samymi tematami. copy_extensions = copy - Ustawienie na copy nakazuje kopiować do certyfikatu właściwości z żądania. Jeśli nie jest ustawione - właściwości ustawia tylko CA

54 Domyślna sekcja [policy_match] Określa jakie warunki musi spełniać żądanie certyfikatu, aby zostało podpisane. Zawiera pola informacyjne certyfikatu oraz określenia: match pole musi mieć taką samą wartość, jak analogiczne pole certyfikatu CA, supplied pole musi być obecne i zawierać dane, optional pole nie jest wymagane. Np.: countryname stateorprovincename organizationname organizationalunitname commonname address = match = match = match = optional = supplied = optional

55 Domyślna sekcja [req] Zawiera domyślne parametry generowanych żądań certyfikatów. default_bits = domyślna długość klucza prywatnego, default_md = sha1 - funkcja skrótu stosowana przy podpisywaniu certyfikatu, default_keyfile = privkey.key - domyślny plik do którego trafi klucz prywatny, distinguished_name = req_distinguished_name - nazwa sekcji definiującej informacje o właścicielu zawarte w żądaniu, attributes = req_attributes - nazwa definicji dodatkowych informacji do umieszczenia w żądaniu certyfikatu, x509_extensions = v3_selfsigned - właściwości dodawane do certyfikatu typu self-signed. req_extensions = v3_request - Propozycje rozszerzeń dodawane do żądania certyfikatu.

56 Domyślna sekcje [req_distinguished_name] i [req_attributes] Zawiera definicje pól do umieszczenia w żądaniu certyfikatu, wraz z dodatkowymi parametrami. Format: przykladowyparametr = Treść zapytania o wartość parametru przykladowyparametr_min = 4 - minimalna długość pola przykladowyparametr_max = 50 - maksymalna długość pola przykladowyparametr_default = Domyślna wartość parametru Np.: countryname = Country Name (2 letter code) countryname_default = PL countryname_min = 2 countryname_max = 2

57 Domyślne sekcje [v3_request] i [v3_selfsigned] Zawiera domyślne właściwości zawarte w generowanym: żądaniu certyfikatu [ v3_request ] certyfikacie samo-podpisanym [ v3_selfsigned ] Np: basicconstraints = CA:FALSE keyusage = nonrepudiation, digitalsignature, keyencipherment

58 Domyślna sekcja [usr_cert] Określa właściwości certyfikatu wystawionego przez CA. Np: basicconstraints=ca:false - cert nie może być użyty do stworzenia CA. subjectkeyidentifier=hash - informacje identyfikujące certyfikat authoritykeyidentifier=keyid,issuer informacje identyfikujące CA keyusage = nonrepudiation, digitalsignature, keyencipherment dopuszczalne użycie certyfikatu extendedkeyusage = szczegółowe przeznaczenie certyfikatu (serverauth) subjectaltname = DNS:<dns_name>,DNS:<IP_addr> - alternatywne nazwy właściciela certyfikatu. crldistributionpoints=uri: lokalizacja listy CRL