1 / 61

Sicurezza II Prof. Dario Catalano

Sicurezza II Prof. Dario Catalano. Public Key Infrastructure. Introduzione. PKI consiste delle componenti necessarie per distribuire chiavi pubbliche in modo sicuro.

vivek
Download Presentation

Sicurezza II Prof. Dario Catalano

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related