sicurezza ii prof dario catalano n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Sicurezza II Prof. Dario Catalano PowerPoint Presentation
Download Presentation
Sicurezza II Prof. Dario Catalano

Loading in 2 Seconds...

play fullscreen
1 / 61

Sicurezza II Prof. Dario Catalano - PowerPoint PPT Presentation


  • 112 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Sicurezza II Prof. Dario Catalano' - vivek


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
sicurezza ii prof dario catalano

Sicurezza IIProf. Dario Catalano

Public Key Infrastructure

introduzione
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
introduzione1
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

introduzione2
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
terminologia
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.
pki trust models
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).
modello di monopolio
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.
modello di monopolio problemi
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?
modello di monopolio problemi cont
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.
monopolio registration authorities ras
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.
monopolio registration authorities ras1
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.
ca delegate
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.
ca delegate1
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.
oligarchia
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.
oligarchia problemi
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.
esempio
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.
oligarchia problemi1
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.
modello anarchico
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.
modello anarchico1
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?
modello anarchico2
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.
restrizioni sui nomi
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.
restrizioni sui nomi1
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.
top down con restriz sui nomi
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.
bottom up con restriz sui nomi
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*
bottom up con restriz sui nomi alcuni vantaggi
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.
restriz sui nomi nei certificati
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.
policies nei certificati
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.
revoca
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.
revoca1
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
meccanismi di revoca
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.
delta crls
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.
primo certificato valido
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.
primo certificato valido1
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.
schemi olrs online revocation server
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.
variante
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)
buone vs cattive liste
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.
buone vs cattive liste1
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
directories e pki
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
esempi
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)

directories e pki1
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.
memorizzare certificati
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
memorizzare certificati1
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.
memorizzare certif nella memoria dell issuer
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.
trovare catene di certificati
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
esempio1
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
pkix e x 509
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
slide47
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
slide48
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
x 509 e certificati pkix
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.

x 509 e certificati pkix1
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.

x 509 e certificati pkix2
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.

x 509 e certificati pkix3
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.
x 509 e certificati pkix4
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
estensioni
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.
estensioni1
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.)

estensioni2
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.

estensioni3
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).

estensioni4
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)
x 509 e crls pkix
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.

x 509 e crls pkix1
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

x 509 e crls pkix2
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).