Problema: distribuzione delle chiavi pubbliche. Autenticazione delle chiavi pubbliche - PKI: Public Key Infrastructure

Transcript

1 Problema: distribuzione delle chiavi pubbliche Sicurezza nei Sistemi Informativi Autenticazione delle chiavi pubbliche - PKI: Public Key Infrastructure Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Tutti i meccanismi e i protocolli di sicurezza tra A e B, basati su algoritmi asimmetrici, richiedono che A sia in possesso di K pubb, e, generalmente, B di K puba Come vengono distribuite le chiavi pubbliche? Nella maggior parte dei casi, è praticamente impossibile che A e B possano scambiarsi le proprie chiavi pubbliche in maniera sicura (ossia con garanzia di autenticità della sorgente e di integrità della chiave) L indisponibilità di un canale sicuro per lo scambio delle chiavi è uno dei motivi per cui è stata creata la crittografia asimmetrica Chi ci assicura che una chiave pubblica è quella di un prefissato utente? O che non sia stata alterata? O.Tomarchio Sicurezza nei Sistemi Informativi 2 Problema: distribuzione delle chiavi pubbliche Possibilità per distribuzione chiavi pubbliche Problema di scalabilità in rete: ogni nodo, in una rete con n nodi, dovrebbe gestire (n-1) chiavi pubbliche Come gestire la revoca delle chiavi pubbliche? Scenario: A si accorge che le hanno rubato K priva A deve ora avvertire tutti gli (n-1) nodi della rete che non devono più considerare valida K puba Annuncio pubblico Invio point-to-point su canale fidato Directory disponibile pubblicamente Autorità per le chiavi pubbliche Certificati per le chiavi pubbliche O.Tomarchio Sicurezza nei Sistemi Informativi 3 O.Tomarchio Sicurezza nei Sistemi Informativi 4

2 Annuncio pubblico Invio point-to-point su canale fidato Invio ad altri utenti / Broadcast chiave Esempio: aggiunta della chiave pubblica PGP ai messaggi inviati a forum pubblici (USENET newsgroup, mailing list) Problema: ci dobbiamo fidare dell annuncio? Esempi: corriere fidato, posta raccomandata, Oppure invio su canale pubblico Autenticazione (per esempio: hash su canale fidato) Va bene se: - Uso non frequente - Piccoli sistemi O.Tomarchio Sicurezza nei Sistemi Informativi 5 O.Tomarchio Sicurezza nei Sistemi Informativi 6 Directory disponibile pubblicamente Autorità per le chiavi pubbliche Entità fidata: Gestisce la directory Periodicamente pubblica la directory o gli aggiornamenti Ogni partecipante: Registra la propria chiave pubblica con l autorità (registrazione di persona, o in modo autenticato) Può aggiornare la propria chiave (usata da troppo tempo, o chiave privata compromessa) Può accedere alla directory elettronicamente bisogna prevedere comunicazione sicura ed autenticata Public-key directory Gestisce directory chiavi pubbliche Ha una chiave pubblica per la cifratura ed una per la firma conosciute da tutti gli utenti Ogni utente chiede la chiave pubblica desiderata Svantaggio: server on-line Vediamo un possibile protocollo O.Tomarchio Sicurezza nei Sistemi Informativi 7 O.Tomarchio Sicurezza nei Sistemi Informativi 8

3 E PK B (ID A,nonce1) E PK B (nonce2) E PK B (ID A,nonce1) E PK B (nonce2) Autorità per le chiavi pubbliche Public-key Authority Authority Voglio la la chiave pubblica di di B O.Tomarchio Sicurezza nei Sistemi Informativi 9 Autorità per le chiavi pubbliche Public-key Authority Authority O.Tomarchio Sicurezza nei Sistemi Informativi 11 E PKB (nonce1,nonce2) Richiesta chiave pubblica, timestamp EPKA (PK B,Richiesta, timestamp), Firma EPK B (PKA,Richiesta, timestamp), Firma Richiesta chiave pubblica, timestamp Evitare attacchi di di replay Autorità per le chiavi pubbliche Public-key Authority Authority O.Tomarchio Sicurezza nei Sistemi Informativi 10 Caching chiavi pubbliche Ottenuta una chiave pubblica, si memorizza B, B, PK B C, C, PK C ma occorre aggiornarla periodicamente O.Tomarchio Sicurezza nei Sistemi Informativi 12 E PKA (nonce1,nonce2) Richiesta chiave pubblica EPKA (PK B,Richiesta chiave pubblica ), Firma EPK B (PKA,Richiesta chiave pubblica ), Firma Richiesta chiave pubblica

4 Certificati Richiesta Certificati PK A è la chiave pubblica di A Firmato Autorità di Certificazione Certificato A Richiesta certificato, timestamp Autorità Autoritàdi di Certificazione Certificazione Certificato B Richiesta certificato, timestamp Alcune proprietà dei certificati: Ognuno può leggerli e determinare nome e chiave Ognuno può verificarli ed assicurarsi dell autenticità Solo l Autorità può crearli ed aggiornarli O.Tomarchio Sicurezza nei Sistemi Informativi 13 O.Tomarchio Sicurezza nei Sistemi Informativi 14 Scambio Certificati Ancora sul concetto di Certificato Autorità Autorità Certificazione Certificazione Una struttura dati per legare in modo sicuro una chiave pubblica ad alcuni attributi Certificato A Certificato B Tipicamente lega chiave a identità ma sono possibili altre associazioni (es: indirizzo IP) Il legame che il certificato esprime viene garantito da una Certification Authority (CA), che firma digitalmente il certificato stesso Con scadenza temporale Revocabile sia dall utente sia dall emettitore O.Tomarchio Sicurezza nei Sistemi Informativi 15 O.Tomarchio Sicurezza nei Sistemi Informativi 16

5 Ancora sul concetto di Certificato Ancora sul concetto di Certificato Avendo a disposizione una copia autentica della chiave pubblica della CA che ha generato (firmato) un dato certificato, è possibile verificare l autenticità della chiave pubblica in esso contenuta I certificati possono essere distribuiti pubblicamente, e non devono essere protetti da nessun meccanismo addizionale In altre parole, se B si fida di CA ed ha a disposizione K pubca, allora può verificare che K puba contenuta in CERT A è proprio la chiave pubblica di A, controllando l autenticità della firma di CA (S CA ) su CERT A La loro integrità e la loro autenticità è infatti protetta crittograficamente (firma della CA) O.Tomarchio Sicurezza nei Sistemi Informativi 17 O.Tomarchio Sicurezza nei Sistemi Informativi 18 PKI Public Key Infrastructure PKI Public Key Infrastructure È l infrastruttura tecnica ed organizzativa preposta alla creazione, distribuzione e revoca dei certificati di chiave pubblica Una PKI definisce i protocolli, le politiche e i meccanismi tecnologici necessari per supportare lo scambio autenticato di chiavi pubbliche Un architettura PKI necessita della definizione dei seguenti elementi: Formato dei certificati Relazione tra diverse CA, e tra CA e utenti Politiche e meccanismi di emissione e revoca dei certificati Servizi di directory O.Tomarchio Sicurezza nei Sistemi Informativi 19 O.Tomarchio Sicurezza nei Sistemi Informativi 20

6 Il ciclo di vita dei certificati (e delle chiavi) Le componenti di una PKI (RFC 3280) Generazione delle chiavi ed eventuale registrazione Terminazione delle chiavi (distruzione od eventuale archivio) Distribuzione delle chiavi Revoca delle chiavi Attivazione /Disattivazione delle chiavi Rimpiazzamento/ Aggiornamento delle chiavi Certificate/CRL Repository Operational and management transactions Publish certificates Publish certificates/crl End Entity RA management transactions CA management transactions PKI Users PKI Management entities Other CAs O.Tomarchio Sicurezza nei Sistemi Informativi 21 O.Tomarchio Sicurezza nei Sistemi Informativi 22 Le componenti di una PKI PKI: il modello di interazione Autorità di certificazione (CA): sono responsabili della emissione e della revoca dei certificati Autorità di registrazione (RA): sono responsabili della verifica delle informazioni che associano una chiave pubblica all entità che ne farà utilizzo (che può essere distinta da quella che richiede il certificato) Possessore del certificato (subject): può essere una persona, un dispositivo hardware, un agent software che rappresenta l entità che farà utilizzo della chiave pubblica (ovvero del certificato) per attestare, mediante firma digitale, la propria identità Utilizzatore del certificato: può essere una persona, un dispositivo hardware, un agent software che valida una firma digitale a partire da una chiave pubblica (certificato) di una CA ritenuta fidata Repository dei certificati: memorizzano e pubblicano i certificati e le liste di quelli revocati (CRL) O.Tomarchio Sicurezza nei Sistemi Informativi 23 O.Tomarchio Sicurezza nei Sistemi Informativi 24

7 Formato dei certificati: X.509 Formato Certificati X.509 Derivano dalla serie di specifiche ITU-T X.500, originariamente destinate a specificare i servizi di directory In realtà, le directory X.500 non sono poi mai state realmente implementate Sono state sostituite da servizi di directory più specializzati (come il DNS), o comunque meno complessi (come LDAP) X.509 specifica tutti i parametri di riferimento per offrire servizi di autenticazione nell ambito di X.500 Formato: <oggetto=proprietà>, codifica in ASN.1 e 1 e 2 e 3 tutte le versioni O.Tomarchio Sicurezza nei Sistemi Informativi 25 O.Tomarchio Sicurezza nei Sistemi Informativi 26 Campi Certificati X.509 Campi Certificati X.509 e X.509 X default 2 se se presente Issuer unique uniqueidentifier oppure oppure Subject unique uniqueidentifier 3 se se ci ci sono sono estensioni Valore intero intero Unico Unico per per ogni ogni CA CA Identifica senza senza ambiguità il il Certificato emesso da da una una data data CA CA O.Tomarchio Sicurezza nei Sistemi Informativi 27 O.Tomarchio Sicurezza nei Sistemi Informativi 28

8 Campi Certificati X.509 Campi Certificati X.509 Algoritmo usato usato per per firmare il il Certificato parametri associati Informazione ripetuta, campo campo poco poco importante Nome Nome X.500 X.500 della della CA CA che che ha ha creato creato e firmato il il Certificato O.Tomarchio Sicurezza nei Sistemi Informativi 29 O.Tomarchio Sicurezza nei Sistemi Informativi 30 Nome X.500: Distinguished Names (DN) Campi Certificati X.509 Sequenza di coppie nome-valore che identificano univocamente un entità uid=doe, e=doe@netscape.com, cn=john Doe, o=netscape Communications Corp., c=us ID utente Nome comune utente organizzazione nazione 2 2 date date Prima Prima ed ed ultima ultima data data della della validità del del Certificato (Not (NotBefore, Not NotAfter) O.Tomarchio Sicurezza nei Sistemi Informativi 31 O.Tomarchio Sicurezza nei Sistemi Informativi 32

9 Campi Certificati X.509 Campi Certificati X.509 Subject: Nome Nome X.500 X.500 dell entità alla alla quale quale è stato stato rilasciato il il Certificato, e che che quindi quindi possiede la la chiave chiave pubblica certificata e che che conosce la la chiave chiave privata privata corrispondente Chiave Chiave pubblica del del soggetto Identificativo algoritmo e parametri associati Per Per RSA: RSA: il il modulo modulo n, n, e la la sua sua dim. dim. in in bit bit l esponente e O.Tomarchio Sicurezza nei Sistemi Informativi 33 O.Tomarchio Sicurezza nei Sistemi Informativi 34 Campi Certificati X.509 Campi Certificati X.509 Opzionale Stringa di di bit bit utile utile per per identificare la la CA CA che che ha ha emesso il il Certificato nel nel caso caso che che il il nome nome X.500 X.500 sia sia stato stato riutilizzato Opzionale Stringa di di bit bit utile utile per per identificare il il soggetto caso caso che che il il nome nome X.500 X.500 sia sia stato stato riutilizzato O.Tomarchio Sicurezza nei Sistemi Informativi 35 O.Tomarchio Sicurezza nei Sistemi Informativi 36

10 Campi Certificati X.509 Campi Certificati X.509 Diversi Diversi campi campi di di estensione Firma Firma dell hash di di tutti tutti gli gli altri altri campi campi Include Signature Algorithm Identifier O.Tomarchio Sicurezza nei Sistemi Informativi 37 O.Tomarchio Sicurezza nei Sistemi Informativi 38 Esempio Certificato in 64-byte-encoded form Certificate: Certificate: Data: Data: : v3 (0x2) Serial : Number: v3 (0x2) 3 (0x3) Signature Serial Number: Algorithm: 3 (0x3) PKCS #1 MD5 With RSA Encryption Issuer: Signature OU=Ace Algorithm: Certificate PKCS Authority, #1 MD5 WithO=Ace RSA Encryption Industry, C=US Validity: Issuer: OU=Ace Certificate Authority, O=Ace Industry, C=US Validity: Not Before: Fri Oct 17 18:36: Not NotAfter: Before: SunFri Oct Oct :36:25 18:36: Subject: Not CN=Jane After: Sun Doe, Oct OU=Finance, 17 18:36:25 O=Ace 1999Industry, C=US Subject Subject: Public CN=Jane KeyDoe, Info: OU=Finance, O=Ace Industry, C=US Subject Algorithm: Public PKCS Key Info: #1 RSA Encryption Public Algorithm: Key: PKCS #1 RSA Encryption Public Modulus: Key: Modulus: 00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86: ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c9:de:dc:85:19:22: 00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86: 43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00: ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c9:de:dc:85:19:22: 98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9: 43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00: 73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e: 98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9: 9d:3b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0: 73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e: 7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54: 9d:3b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0: 91:f4:15 7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54: Public 91:f4:15 Exponent: (0x10001) : Public Exponent: (0x10001) : Identifier: Certificate Type Identifier: Critical: Certificate no Type Certified Critical: Usage: no Certified SSL Client Usage: Identifier: SSL Authority Client Key Identifier Identifier: Critical: Authority no Key Identifier Key Critical: Identifier: no Keyf2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36: Identifier: 26:c9 Signature: f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36: 26:c9 Signature: Algorithm: PKCS #1 MD5 With RSA Encryption Signature: Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06: 30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb: 6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06: f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc: 30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb: 2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5: f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc: b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5: 2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5: 4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8:dd:c4 b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5: 4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8:dd:c4 O.Tomarchio Sicurezza nei Sistemi Informativi BEGIN CERTIFICATE----- MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzER MA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEw MTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQK EwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0 dhkwgz8wdqyjkozihvcnaqefbqadgy0amigjaogbamr6ezipgfjx3urjgejmkiqg 7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7L iqzbcrxpc0k4du+2q6xju2mpm/8wkumontuvzpo+sgxelmhvcheqoocwfdizywyz NMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNV HSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBt I6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3 UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84 hw3wwehbuqvk5sy4/zj4otjx7dwnmdgwbwfprqjd1a== -----END CERTIFICATE----- O.Tomarchio Sicurezza nei Sistemi Informativi 40

11 La revoca dei certificati I meccanismi di revoca Un sistema di certificazione di chiavi pubbliche deve naturalmente prevedere dei meccanismi per poter dichiarare tali chiavi non più valide Esempi: Chiavi pubbliche le cui corrispondenti chiavi private vengono compromesse Chiavi pubbliche le cui chiavi private sono andate perse Chiavi che non vengono più usate, perché il proprietario, per esempio, si èlicenziato Due sistemi principali La data di validità del certificati La revoca esplicita dei certificati Analogia classica: le carte di credito CRL: Certificate Revocation List Elenco dei certificati revocati, emesso periodicamente e mantenuto dagli emettitori dei certificati OCSP: On-line Certificate Status Protocol Protocollo per verificare on-line se un certificato è valido O.Tomarchio Sicurezza nei Sistemi Informativi 41 O.Tomarchio Sicurezza nei Sistemi Informativi 42 CRL: Certificate Revocation List CRL e validità certificati Ogni CA è tenuta a pubblicare periodicamente la lista dei certificati che essa ha revocato (CRL) La lista ha un formato del tipo: Issuer Last update date Next update date Lista di numeri di serie di certificati revocati, con la data nella quale sono stati revocati Firma digitale della CA (di tutta la CRL) A rigore, prima di considerare valido un certificato, bisognerebbe controllare che il suo numero di serie non compaia nell ultima versione disponibile della CRL emessa dalla CA che ha emesso il certificato Questo presuppone che ciascun nodo di rete, periodicamente, riceva o scarichi le CRL dalle CA di cui si fida Non solo: prima di accettare un certificato, bisognerebbe controllare che la CRL della relativa CA in proprio possesso non sia scaduta. Se fosse scaduta e non si riuscisse ad ottenere una copia recente, non si dovrebbero accettare certificati firmati da tale CA Ad oggi questo non viene fatto in molte implementazioni che utilizzano certificati O.Tomarchio Sicurezza nei Sistemi Informativi 43 O.Tomarchio Sicurezza nei Sistemi Informativi 44

12 Certificate revocation timeline Gestione efficiente delle CRL Problema: le CRL possono diventare molto grosse e quindi onerose da scaricare e da esaminare Varie soluzioni: eliminare la revoca dopo la prima CRL successiva alla scadenza del certificato pubblicare CRL complete solamente all inizio (Base CRL) e poi solo le differenze (Delta CRL) partizionare le CRL in tanti gruppi (es. per ogni mille certificati emessi) usando CRL DP O.Tomarchio Sicurezza nei Sistemi Informativi 45 O.Tomarchio Sicurezza nei Sistemi Informativi 46 OCSP: On-line Certificate Status Protocol Architettura di OCSP RFC-2560: standard IETF-PKIX per verificare in linea se un certificato è valido Risposte possibili: good revoked revocationtime revocationreason unknown Al server occorre un certificato firmato da ogni CA per cui fornisce informazioni possibili risposte pre-calcolate possibile attingere informazioni non da CRL Il server può diventare un collo di bottiglia dell architettura È necessario introdurre il concetto di OCSP server Le risposte, inviate al client, sono firmate dal server (non dalla CA!) È necessario un trusted server (certificato non verificabile!) O.Tomarchio Sicurezza nei Sistemi Informativi 47 O.Tomarchio Sicurezza nei Sistemi Informativi 48

13 Come distribuire la chiave pubblica della CA? Come distribuire la chiave pubblica della CA? Naturalmente, per verificare la validità di un certificato, dobbiamo avere a disposizione una copia autentica di K pubca della CA che ha emesso il certificato In scala più piccola, si ripropone il problema della distribuzione sicura (con garanzia di autenticità e integrità) delle chiavi pubbliche, in questo caso delle CA Le K pubca possono essere incluse: In un certificato self-signed (se la CA è root, o se comunque non è stata certificata da altre CA) In un certificato emesso da un altra CA ( struttura gerarchica delle CA) Il problema oggi viene risolto includendo i certificati di decine di CA nel software caricato su qualunque nodo di rete che ne abbia bisogno Sistemi operativi Svariati applicativi (browser web, applicativi per telefoni cellulari, client di posta elettronica, ) In realtà, anche per le K pubca (cioè per i CERT CA ) si potrebbe seguire un modello gerarchico, se si potesse contare su un sistema integrato di directory e una politica globale di gestione delle CA (che oggi non è applicata) O.Tomarchio Sicurezza nei Sistemi Informativi 49 O.Tomarchio Sicurezza nei Sistemi Informativi 50 Come distribuire i certificati? Architettura delle PKI: quante CA? Sistema ideale: directory Pensate ad un sistema analogo al (oppure integrato col) DNS In questo caso A può iniziare un protocollo di autenticazione con B senza la necessità di aver scambiato in precedenza i rispettivi certificati Problema: se non a livello locale, con i server LDAP, non sono ancora state implementate directory per i certificati Sistema comunemente usato: i certificati vengono inviati durante lo scambio iniziale del protocollo di autenticazione Diversi possibili modelli Modello monopolistico: una sola CA Varianti: una sola root CA, con struttura gerarchica di CA delegate Modello oligarchico: diverse CA, tutte allo stesso livello Modello oligarchico/gerarchico: diverse CA di root, con deleghe su un namespace (similitudine con il sistema DNS) Modello anarchico: nessuna CA In questo caso i certificati sono generati da utente a utente (modello PGP) L unica infrastruttura implementata oggi a livello globale ha una struttura oligarchica Si sta lavorando per definire (e implementare) una struttura gerarchica, basata sulla capacità di convalidare catene di certificati da una (o più) root verso il basso (o verso l alto) O.Tomarchio Sicurezza nei Sistemi Informativi 51 O.Tomarchio Sicurezza nei Sistemi Informativi 52

14 Network trust model Note pratiche sulla gestione di una CA Gerarchie indipendenti Relazioni di fiducia (univoca o biunivoca) L importanza di K privca Tutta la sicurezza di un architettura basata su CA si fonda su La capacità di distribuire in maniera sicura (garanzia di autenticità e integrità) i certificati delle CA La massima protezione possibile per K privca È buona norma mantenere la CA e K privca sconnesse dalla rete, accessibili fisicamente solo da personale autorizzato Meccanismi di identificazione sicura di chi richiede certificati Dato che la CA deve certificare, con l emissione di CERT A, che K puba appartiene ad A, la CA deve anche essere in grado di accertarsi dell identità di A Le politiche variano da CA a CA, e possono essere da banali ( di ritorno + codice fiscale), a relativamente molto complesse (registro delle camere di commercio) In generale, c è una generale mancanza di standardizzazione sulle politiche di emissione dei certificati (CA policy) O.Tomarchio Sicurezza nei Sistemi Informativi 53 O.Tomarchio Sicurezza nei Sistemi Informativi 54 Esempi d uso dei certificati Approfondimento: estensioni in X.509v3 In pratica i certificati vengono utilizzati in moltissimi protocolli di sicurezza in rete, tra cui: SSL/TLS (per web sicuro) IPSec (VPN sicure) Autenticazione e scambio di chiavi in reti che utilizzano il protocollo EAP (per esempio, reti di nuova generazione) S/MIME (posta elettronica) O.Tomarchio Sicurezza nei Sistemi Informativi 55 O.Tomarchio Sicurezza nei Sistemi Informativi 56

15 X.509 versione 3 Estensioni Estensioni opzionali nella versione 3 Soluzione flessibile Meglio dell aggiungere altri campi fissi alla versione 2 Esistono estensioni di due tipi: pubbliche, ossia definite nello standard e quindi note a tutti private, uniche per una certa comunità di utenti Ogni estensione contiene: Identificatore estensione Indicatore di criticità Valore estensione Indica Indica se se l estensione può può essere essere ignorata Se Se TRUE TRUE e l implementazione non non riconosce l estensione allora allora deve deve trattare il il certificato come come non-valido O.Tomarchio Sicurezza nei Sistemi Informativi 57 O.Tomarchio Sicurezza nei Sistemi Informativi 58 Categorie Estensioni (pubbliche) Quattro categorie principali per le estensioni: Key and Policy Information Certificate Subject and Issuer Attributes Certification Path Constraints CRL Distribution Points Key and Policy Information Authority key identifier indica quale di più chiavi pubbliche della CA usare per verificare la firma di un certificato o della CRL Subject key identifier identifica quale di più chiavi pubbliche viene certificata Key usage Identifica lo spazio delle applicazioni per il quale la chiave pubblica può essere usata: Esempio: digital signature, key encryption, data encryption, key agreement, CA signature verification on certificates, CA signature verification on CRL O.Tomarchio Sicurezza nei Sistemi Informativi 59 O.Tomarchio Sicurezza nei Sistemi Informativi 60

16 Key and Policy Information Certificate Subject and Issuer Attributes Private-key usage period periodo uso della chiave privata (per la firma, diverso periodo per chiave privata e pubblica) Certificate policy insieme di regole che indica l applicabilità di un certificato ad una comunità e/o classi di applicazioni con requisiti di sicurezza comuni Policy mappings usato solo per CA da altre CA. Permette ad una CA di indicare che una propria politica può essere considerata equivalente ad un altra politica usata dalla CA soggetto. Subject alternative name contiene uno o più nomi alternativi, in formati alternativi. Importante per le applicazioni che hanno formati propri per i nomi (ad es., mail elettronica, EDI, IPSec) Issuer alternative name contiene uno o più nomi alternativi, in formati alternativi Subject directory attributes contiene attributi della directory X.500 per il soggetto del certificato O.Tomarchio Sicurezza nei Sistemi Informativi 61 O.Tomarchio Sicurezza nei Sistemi Informativi 62 Certification Path Constraints CRL distribution points Basic constraints indica se il soggetto può agire come CA. Se si, si possono specificare vincoli sulla lunghezza della certification path Name constraints indica uno spazio dei nomi in cui tutti i seguenti certificati in un certification path devono essere Policy constraints inibisce policy mappings per la parte rimanente della certification path CRL distribution point identifica il punto di distribuzione della CRL da utilizzare nel processo di verifica della validità di un certificato che può essere: directory entry o URL O.Tomarchio Sicurezza nei Sistemi Informativi 63 O.Tomarchio Sicurezza nei Sistemi Informativi 64