Sicurezza II Prof. Dario Catalano

1. Sicurezza IIProf. 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]Tede [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 pippo@cs.unict.it) • E’ ragionevole credere che la CA di unict possa validare pippo@cs.unict.it • Unict non puo’ validare pippo@company.com (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 1.2.45.34532.6.7.3 mi puo’ fornire 1.2.45.34532.6.7.3.45 • Io posso generare nuovi numeri, purche’ contengano il prefisso 1.2.45.34532.6.7.3.45 • 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.