Sicurezza IIProf. Dario Catalano

Public Key Infrastructure

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

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

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

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) 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 (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 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 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 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 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 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 - 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 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 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 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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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

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 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 PKIX

I campi che seguono sono ripetuti per ogni certificato revocato.

UserCertificate: Numero seriale del crtificato revocato.

RevocationDate: Data della revocaCRLEntryExtensions: Info opzionali

(ad es perche’ il certif e’ stato revocato).