Sicurezza II Prof. Dario Catalano

Presentazione sul tema: "Sicurezza II Prof. Dario Catalano"— Transcript della presentazione:

1 Sicurezza II Prof. Dario Catalano
Public Key Infrastructure

2 Introduzione PKI consiste delle componenti necessarie per distribuire chiavi pubbliche in modo sicuro. Certificati, Repository dove trovare certif, Metodo per rimuovere certif, Metodo per valutare catene di certif (da PK note e fidate) che portano al target. Esistono sistemi che non comprendono tutte le componenti appena descritte. Noi li ignoreremo

3 Introduzione Un certif e’ un msg firmato che prova che un dato nome e’ associato ad una certa PK. Es: [La PK di Alice e’ 15436]Carol Se Bob non conosce Carol tale certif e’ inutile… Se pero’ Bob conosce un “intermediario” che certifica Carol, il sistema diventa interessante: Es: [La PK di Carol e’ 34521]Ted e [La PK di Alice e’ 15436]Carol

4 Introduzione Anche nel caso appena visto sorgono potenziali problemi
Se Bob si fida di Ted, deve per questo anche fidarsi di Carol? Come fa Bob a conoscere la chiave di Ted e a fidarsi? Oggi, essenzialmente, studieremo questioni di questo tipo

5 Terminologia Se Alice firma un certif, che lega Bob alla sua PK, Alice e’ l’issuer e Bob e’ il subject. Se Alice vuole trovare un cammino che conduca alla chiave di Bob, allora Bob e’ il target. Se Alice valuta una catena di certif, essa e’ il verifier (o relying party). Chiunque possegga una PK e’ detto principal. Un trust anchor e’ una PK fidata per verificare certif.

6 PKI Trust Models Supponiamo che Alice voglia mandare un messaggio cifrato (via mail a Bob). Deve innanzi tutto trovare la Pk di Bob e verificarne la validita’. I Trust Models definiscono dove Alice trova Trust Anchors e che cammini costituiscono una catena affidabile che dal trust anchor conduce al Target (Bob).

7 Modello di Monopolio Il mondo sceglie una organizzazione, ORG universalmente considerata fidata. ORG diviene la CA di riferimento La chiave di ORG e’ inserita in ogni software e hardware come trust anchor. Tutti devono ottenere certificati da ORG E’ modello straordinariamente semplice. Modello favorito da organizzazioni che puntano al monopolio.

8 Modello di Monopolio, Problemi.
Non esiste alcuna organizzazione (universalmente) fidata. Cambiare la chiave in caso di problemi diventa un dramma (la chiave e’ inserita ovunque) E’ costoso certificare utenti “lontani” Come fa ORG a conoscere me? Come faccio io a mandare la mia PK, in modo sicuro (integrita’), per averla certificata?

9 Modello di Monopolio, Problemi (cont.)
Cambiare organizzazione di riferimento, in caso di problemi diventa un dramma. L’intera sicurezza del sistema dipende da ORG. Non si possono tollerare incompetenza o corruzioni in ORG.

10 Monopolio + Registration Authorities (RAs)
Simile alla precedente, ma ORG sceglie altre organizzazioni (chiamate RA appunto). Le RA verificano la validita’ delle identita’ (ID) e “legano” le PK alle IDs RA comunica (in modo sicuro) con ORG tali informaz. ORG puo’ quandi rilasciare certif, sulla base della fiducia che ripone nelle RA.

11 Monopolio + Registration Authorities (RAs)
E’ piu’ facile e sicuro ottenere dei certif Tutti gli altri problemi visti per il caso precedente rimangono. Le RAs possono essere aggiunte a TUTTI i modelli che discuteremo.

12 CA Delegate Il trust anchor CA rilascia certificati per altre CAs, garantendone l’affidabilita’. Gli utenti possono ottenere certif da una CA delegata. La differenza col modello precedente, e’ che qua Alice deve verificare una catena di certificati (fino alla PK di Bob), piuttosto che un singolo certif.

13 CA Delegate Se si assume che esista un trust anchor iniziale (monopolista) ORG, tale sistema risulta, per il resto, molto simile al precedente. Catene di certificati, ottenute attraverso CA delegate, possono essere incorporate in tutti i modelli che vedremo.

14 Oligarchia I prodotti sono configurati in modo da poter far riferimento a diversi trust anchors. Un certif rilasciato da un qualunque TA e’ accettato. Spesso e’ possibile (da parte dell’utente) esaminare la lista dei TA (e aggiungere o eliminare TA). Molto usato nei browser Il vantaggio (rispetto al modello di monopolio) e’ che mette in competizione i TA.

15 Oligarchia - Problemi Puo’ essere anche meno sicuro del modello basato sul monopolio. Basta che una sola TA venga corrotta perche’ la sicurezza dell’intero sistema sia a rischio. Potrebbe essere facile indurre un utente inesperto ad aggiungere TA non fidate.

16 Esempio Se l’utente sceglie un TA poco opportuno un buon browser potrebbe far partire un pop-up di allarme del tipo Warning! Questo e’ stato firmato da una CA non fidata? Procedere comunque? La risposta dell’utente (che spesso non legge il Warning) e’ molto spesso si. Una CA che si chiama “Madre Teresa”, ha buone probabilita’ di essere accettata dall’utente a scatola chiusa.

17 Oligarchia - Problemi Gli utenti spesso non sanno cosa una TA sia.
Sentire parlare di schemi di cifratura, spesso rassicura gli utenti e li spinge a fidarsi ciecamente. Non e’ praticamente possibile, anche per un esperto, esaminare correttamente la lista di TA e rendersi conto se tale lista e’ stata modificata (in modo disonesto) oppure no. Esaminare il nome, non garantisce la validita’ della chiave.

18 Modello Anarchico Modello usato da PGP.
Ogni utente e’ responsabile della configurazione di alcuni TA. Es. PK di utenti dai quali ha ricevuto il loro PGP fingerprint (hash della PK). Tutti possono firmare certificati per chiunque altro. Alcune organizzazioni (es. MIT) offrono un database dove tutti possono depositare certificati. Per ottenere la chiave di qualcuno si puo’ cercare nel database.

19 Modello Anarchico Modello duale rispetto a quello monopolista.
Pone un’enorme quantita’ di problemi. Il database puo’ facilmente assumere dimensioni terrificanti se usato su larga scala (internet) Anche trovando una catena che certifichi il proprio target, chi garantisce l’affidabilita’ di tale catena?

20 Modello Anarchico Tale modello e’ utile (ed applicabile) in contesti molto limitati. Essenzialmente comunita’ di ridotte dimensioni, dove tutti gli utenti sono fidati. Su internet, dove molte persone non hanno nulla di meglio da fare che creare problemi, e’ del tutto impraticabile.

21 Restrizioni sui Nomi Idea: l’affidabilita’ di una CA non e’ qualcosa di tipo si/no Esistono CA parzialmente affidabili. Es. Una CA gestita da utenti di un dato videogioco, puo’ essere affidabile per cio’ che riguarda il gioco in esame, ma non per tutto il resto.

22 Restrizioni sui Nomi Si assuma che i nomi siano di tipo gerarchico (es E’ ragionevole credere che la CA di unict possa validare Unict non puo’ validare (anche se si tratta dello stesso utente) Gli utenti potrebbero avere piu’ nomi Ogni nome viene gestito come un’entita’ separata dalla PKI.

23 Top Down con restriz. sui nomi
Ognuno deve essere configurato con una chiave root (non modificabile). La CA root puo’ delegare altre CAs Le CAs delegate possono generare certificati solo per le loro “porzioni” di spazio dei nomi Simile al modello di monopolio E’ facile trovare il cammino fino al nome cercato Tale metodo ha tutti gli altri problemi del modello di monopolio.

24 Bottom Up con restriz. sui nomi
Ogni organizzazione crea la propria PKI e poi si collega alle altre. Si assumono spazi dei nomi gerarchici, (ad ogni nodo corrisponde una CA) Il padre certifica il figlio e viceversa. Sono permessi anche cross-link (due nodi non parenti si certificano) Il sistema di ricerca usa una regola up*-cross once-down*

25 Bottom Up con restriz. sui nomi – Alcuni vantaggi
Il fatto di usare PKI locali e’ utile (la responsabilita’ dei certif di ogni organiz. e’ nelle mani dell’organizz. stessa) Competizione tra organizzazioni e’ sempre possibile La configurazione e’ molto semplice Il requisito minimo e’ conoscere la propria chiave. Le altre CA possono essere raggiunte a partire dal proprio nodo.

26 Restriz. sui nomi nei Certificati.
Alice (issuer) specifica quali nomi Bob (subject) e’ autorizzato a certificare. I certificati hanno un formato che puo’ contenere un campo di nomi autorizzati e non.

27 Policies nei Certificati
E’ possibile aggiungere policies ai certificati. Per essere certificata in una data gerarchia Alice deve possedere i requisiti richiesti (e sara’ certificata solo nella corrispondente gerarchia) Ad es quanto attentamente Alice ispeziona le identita’ che certifica. Le policies non hanno numeri ad esse associati Es security level. Questo contribuisce a renderle non sempre attraenti in pratica.

28 Revoca I certif. hanno tipicamente una data di scadenza
In genere dell’ordine dei mesi (e’ complicato fare nuovi certif. troppo spesso) In caso di problemi e’ importante poter revocare i certif rapidamente. Situazione molto simile a quella delle carte di credito. Il commerciante ogni volta che esegue una transazione (dovrebbe) collegarsi ad un database di carte di credito considerate non piu’ valide.

29 Revoca Perche’ i certif hanno una data di scadenza?
Assumendo un sistema di revoca affidabile, effettivamente la scadenza sembra inutile. La scadenza rende il sistema di revoca piu’ efficiente La taglia del DB rimane di dimensioni gestibili. Inoltre Per alcuni sistemi esiste solo la scadenza (e non la revoca) Le aziende che forniscono certificati, vogliono guadagnare da tale operazione. Molti browser non controllano la data di scadenza

30 Meccanismi di Revoca CRL: CA periodicamente pubblica una lista firmata (CRL appunto) di tutti i certificati revocati (e non scaduti). Tale lista e’ pubblicata periodicamente (anche se nessun certificato e’ stato revocato dall’ultimo aggiornamento) Un verificatore puo’ rifiutarsi di onorare un certificato se non trova una CRL sufficientemente recenti che ne attesti la non avvenuta revoca.

31 Delta CRLs Se si volessero rendere le revoche effettive nel giro di un’ora dovremmo pubblicare una nuova CRL ogni ora. Una Delta CRL contiene solo i cambiamenti prodotti relativamente alla lista pubblicata precedentemente. Tale lista e’ potenzialmente molto piu’ piccola. Quando la Delta CRL diviene troppo grande la CRL completa (ed aggiornata) viene pubblicata nuovamente.

32 Primo Certificato Valido
Rendere la CRL di nuovo piccola, quando e’ diventata troppo lunga. Ogni certif contiene un numero seriale che viene incrementato ogni volta che esso viene rinnovato. Contiene anche un campo First Valid Certif. Se il num seriale di un certif e’ inferiore al FVC il certif e’ da considerarsi non valido.

33 Primo Certificato Valido
Se la CRL cresce troppo tutti coloro che hanno un certif con num seriale < n dovranno ottenere un nuovo certificato n e’ scelto in modo che non troppi certif abbiano un num seriale < n I certif revocati e con num seriale < n sono rimossi dalla CRL. Il campo FVC e’ aggiornato a n.

34 Schemi OLRS (online revocation server)
Server che puo’ essere interrogato (magari con comunicaz autenticata) circa lo stato di un dato certif ORLS non sono security sensitive quanto CA (o KDC) Nel caso peggiore possono dichiarare valido un certif revicato Non contengono chiavi private.

35 Variante Alice richiede a OLDS un nuovo certif che dichiari la validita’ del suo certif per un tempo limitato. Se Alice visita vari server, presentando i due certif. Questo evita a OLRS di dover essere interrogato tante volte (dai diversi server)

36 Buone vs Cattive liste Lo standard prevede liste che contengono i certif cattivi (bad lists) Uno schema che tenga traccia dei buoni certif sarebbe piu’ sicuro. Con Bad lists, se una CA (corrotta) produce un certif apparentemente valido tale certif potra’ essere utilizzato impunemente Chi e’ preposto a stilare la CRL non ne conosce l’esistenza.

37 Buone vs Cattive liste Le buone liste tendono pero’ ad espandersi maggiormente (e a dover essere cambiate piu’ di frequente) Una organizzazione potrebbe non voler pubblicare l’elenco dei propri certif validi. Soluzione semplice: pubblicare l’hash dei certif

38 Directories e PKI Directory: DB gerarchico distribuito indicizzato con un nome gerarchico Ad ogni nome e’ associato un record di info (es IP address, certif che ha firmato, etc) Ogni nome e’ un nodo in un albero. La directory dovrebbe conservare info che permettono di trovare il record padre (o figlio) di un dato nodo

39 Esempi DNS: Utilizza nomi come dario.cs.unict.it, ed e’ universalmente utlizzato su internet. Specificando un nome si ottengono gli attributi di tale nome. Servizio di tipo look-up (estremamente utile per applicazioni automatizzate) Non sono presenti funzionalita’ piu’ sviluppate. X.500: Ha bisogno di un linguaggio per essere interrogato (es LDAP)

40 Directories e PKI La maggior parte dei PKI utilizzati non usa directories. Si possono costruire PKI senza directories, ma e’ piu’ conveniente avere directories a disposizione.

41 Memorizzare Certificati
Assumendo di avere un servizio di look up (es DNS) con che nome devono essere memorizzati i certificati? Se Carol firma un cerif ad Alice, tale certif potrebbe essere memorizzato nel record di Carol, di Alice o di entrambe. PKIX propone di memorizzare tale info nel record del subject (Alice) Ricorda il modello Top Down: i padri certificano i figli ed i figli memorizzano i certif

42 Memorizzare Certificati
Per una CA che offre servizi di root (e ha tanti figli) e’ piu’ conveniente che siano i figli a memorizzare i certif. Se un principal Alice sa che la propria chiave e’ stata compromessa, dovrebbe comunicarlo a chiunque l’avesse certificata Se i certif sono memorizzati nella memoria di Alice e’ facile fare tale operazione. Non e’ chiaro come fare lo stesso se i certif fossero lasciati nella memoria dell’issuer.

43 Memorizzare Certif (nella memoria dell’issuer)
Il problema puo’ essere risolto in vari modi (non molto eleganti, a mio modesto avviso) Spesso, pero’, ha senso creare un cammino da un trust anchor a un target. Cio’ e’ difficile da realizzare se il certificato e’ memorizzato nella memoria del subject.

44 Trovare catene di certificati
Per trovare la chiave pubblica di Alice (in modo sicuro) Bob deve trovare un cammino dal suo TA ad Alice. Cio’ puo’ essere realizzato muovendosi da Alice (o Bob) verso un adeguato TA o viceversa. building “forward” o “in reverse” Il primo approccio diventa complicato se sono permesse policies o restriz. sui nomi

45 Esempio Supponiamo vi sia un gran numero di cross certificates (con restriz. sui nomi) Partendo dal TA, le restriz. suggeriscono quale link seguire. Partendo al contrario tuttavia, le restriz. sui nomi non aiutano a risalire al TA

46 PKIX e X.509 X.509 e’ un formato di certif molto diffuso
L’efficienza di un PKI dipende anche dal formato scelto per i certif PKIX specifica che opzioni di X.509 sono supportate. Adesso descriveremo i dettagli di X.509

47 Nomi Utilizza il formato (particolarmente strano) di X.500
Componenti del tipo C:country, O: organization, OU: organizational unit, CN: common name La codifica consiste in identificatori (OID) per ognuno dei tipi citati. Pochissime applicazioni utilizzano nomi X.500

48 OIDs Nomi assegnati gerarchicamente.
Consistono in numeri separati da punti. Possono essere gestiti senza dover riferimento ad un’amministrazione centrale Basta rivolgersi a qualcuno che ha gia’ un OID. Chi possiede mi puo’ fornire Io posso generare nuovi numeri, purche’ contengano il prefisso Organizzazioni differenti possono attribuire numeri diversi alla stessa cosa

49 X.509 e Certificati PKIX Un certif X.509 contiene le seguenti info
Version: 3 versioni (con codici 0,1,2) Serial Number: Intero che, insieme al nome della issuing CA, identifica univocamente il certificato. Si assume che due certif diversi abbiano numeri seriali differenti.

50 X.509 e Certificati PKIX Firma: Specifica l’algoritmo utilizzato per firmare (ed eventuali parametri aggiuntivi dell’algoritmo) Issuer: Il nome, in formato X.500, dell’issuer del certif Validita’: Specifica l’inizio e la fine di validita’ del certif.

51 X.509 e Certificati PKIX Subject: Il nome, in formato X.500, del subject. Tale campo e’ obbligatorio in X.509 (ma opzionale per PKIX) PKIX permette di utilizzare una stringa nulla in tale campo, e di utilizzare il campo subjectAltName per utilizzare nomi DNS. SubjectPublicKeyInfoIssuer: Due sottocampi contenenti il nome dell’algoritmo e la chiave pubblica del subject.

52 X.509 e Certificati PKIX IssuerUniqueId: Opzionale. Specifica l’issuer del certif. SubjectUniqueId: Opzionale. Specifica il subject del certif. L’obiettivo di tale campo e’ eliminare la possibilita’ di confusione in casi di omonimie.

53 X.509 e Certificati PKIX AlgorithmId: E’ identico al campo Firma.
Ridondante ed inutile. Encrypted: Contiene la firma su tutti i campi (escluso quello appena descritto) Il nome non ha senso PKIX lo ha rinominato Signature Value

54 Estensioni Permesse solo in X.509 versione 3.
Possono essere di tipo arbitrario. PKIX suggerisce quelle che andremo ad elencare WARNING: Come spesso accade per gli standard alcune di esse sono praticamente inutili.

55 Estensioni AuthorityKeyId: Specifica la chiave della CA che ha firmato il certif. SubjectKeyId: Tipicamente e’ un hash della PK del subject (ma puo’ essere qualsiasi altra cosa che identifichi univocamente la chiave). KeyUsage: Stringa in cui ogni bit stabilisce per cosa il subject e’ autorizzato ad utilizzare la chiave. Esistono 9 “tipi” (encryption, firme, firma di certif, etc.)

56 Estensioni PrivateKeyUsagePeriod: Contiene due timestamps
Simile (se non identico) al campo validity. Dovrebbe indicare al subject fino a quando utilizzare la chiave per evitare di produrre certif che diverrebero presto non validi CertificatePolicies: Sequenza di OIDs che rappresentano policies. Policy mapping: Sequenza di coppie di OID che mappano da policies per gli issuer a policies per i subject.

57 Estensioni SubjectAltName: Stringa che specifica una sequenza di nomi alternativi al nome in uso IssuerAltName: Analogo per l’issuer. SubjectDirectoryAttributes: Permette di specificare ulteriori attributi (es. data di nascita, etc).

58 Estensioni BasicConstraints: Concede al subject il permesso di creare nuovi certif. Due tipi di restrizioni: se il subject e’ autorizzato ad agire da CA, e la lunghezza massima consentita della catena di certificati che partono dal subject Esistono tante altre estensioni, (che non discuteremo)

59 X.509 e CRLs PKIX Una CRL X.509/PKIX contiene i seguenti campi.
Firma: Specifica l’algoritmo utilizzato per firmare (come prima) Issuer: Il nome, in formato X.500, dell’issuer del certif (come prima) ThisUpdate: Specifica quando e’ stata creata la CRL.

60 X.509 e CRLs PKIX NextUpdate: Opzionale. Specifica quando verra’ pubblicata la prossima CRL. CRLExtensions: Varie info opzionali (es l’ID della chiave dell’autorita’ che rilascia la CRL, etc) AlgorithmId: Come prima identico al campo Firma. Encrypted: Come prima, contiene la firma su tutti i campi (tranne AlgorithmId) della CRL

61 X.509 e CRLs PKIX I campi che seguono sono ripetuti per ogni certificato revocato. UserCertificate: Numero seriale del crtificato revocato. RevocationDate: Data della revoca CRLEntryExtensions: Info opzionali (ad es perche’ il certif e’ stato revocato).