Sei sulla pagina 1di 77

Sistemi di Autenticazione Introduzione

Luca Grilli

Premessa
Per autenticazione si intende il processo che permette di verificare in modo affidabile lidentit di qualcuno (o di qualcosa)
esistono svariate forme di autenticazione una persona pu essere riconosciuta
dallaspetto fisico o dalla voce da una guardia che confronta il viso con la foto nel badge nel caso degli acquisti on-line, dalle informazioni associate alla carta di credito nel seguito si esamineranno le varie forme di autenticazione

Possibili scenari
Le varie forme di autenticazione possono essere classificate in base
al tipo (persona o computer) di entit coinvolte
autenticazione computer/computer autenticazione persona/computer autenticazione persona/persona (non ci interessa)

alle informazioni e al modo in cui lautenticazione avviene


autenticazione basata su password autenticazione basata sullindirizzo autenticazione crittografica

Sistemi di autenticazione Introduzione

AUTENTICAZIONE BASATA SU PASSWORD

Autenticazione basata su password


Nel caso di autenticazione basata su password
lidentit equivale alla conoscenza della password chi si deve autenticare invia la propria password, in chiaro, allentit autenticante la quale in grado di verificare se la password inviata esiste e corrisponde allutente da cui stata inviata
Alice Bob Im Alice, the password is fiddlesticks

Ovviamente, le intercettazioni costituiscono la minaccia principale

Un chiarimento
unautenticazione che richiede linserimento di un password non detto che ricada nella categoria autenticazione basata su password se infatti le informazioni inviate risultano cifrate, (magari con una chiave derivata dalla password) allora si parler di autenticazione crittografica

Osservazioni
Domanda
Visto che lautenticazione crittografica molto pi sicura, per quale ragione si usa lautenticazione basata su password?

Risposta
per consentire ad una persona di effettuare il log-in in una workstation difficile considerare protocolli di autenticazione non basati su password
una persona ha difficolt a memorizzare delle chiavi segrete; cio delle stringhe di 64 bit sebbene, siano ormai disponibili dei gadget che permetterebbero di risolvere tale problema

Osservazioni
sfortunatamente, anche nel caso di autenticazioni computer/computer si ricorre talvolta a protocolli basati su password
perch ad esempio inizialmente il protocollo era di tipo uomo/macchina, ma poi si evoluto in computer/computer altre volte i progettisti ritengono (forse a ragione) che luso di protocolli crittografici sia costoso in termini di risorse di elaborazione e di tempo di sviluppo e implementazione altre volte la crittografia evitata a causa di questioni legali

Altre criticit
si consideri il seguente scenario
un utente ha un account presso una workstation inoltre ha la necessit di accedere, previo inserimento di username e pwd, ad uno svariato numero di risorse in rete distribuite su server distinti per evitare la scomodit di inserire username e pwd ogni volta che deve accedere ad una risorse di rete sarebbe comodo che la workstation lo facesse in modo automatico al suo posto, cio le credenziali con cui lutente si autenticato presso la workstation, possano venire inviate in modo automatico da questultima ai vari server,

Altre criticit
ma ci comporta che deve essere usato lo stesso username e pwd presso ogni server

Come possibile avere la stessa password su molti sistemi diversi? Si potrebbe assegnare ad ogni sistema la stessa password in modo indipendente, ma se poi sorge la necessit di modificarne una, come possibile garantire la sincronizzazione?

Attacchi alle password Off-line vs On-line


Gli attacchi alle password possono essere di tipo on-line o off-line
in un attacco on-line si tenta di indovinare la password semplicemente inviandola al sistema autenticante per contrastarli, si pu limitare il numero di tentativi
ad esempio, gli sportelli bancomat ATM ritirano la tessera dopo tre inserimenti errati della password in alternativa il sistema potrebbe diventare sempre pi lento allaumentare dei tentativi e/o potrebbe insospettirsi e inviare una notifica ad un operatore di sicurezza

Attacchi alle password Off-line vs On-line


invece, in un attacco off-line un avversario pu catturare una quantit X derivata dalla password (ad esempio lhash) con una tecnica nota e poi,
prendendosi il tempo che vuole ed usando tutta la potenza di calcolo e di memoria di cui dispone

scegliere password candidata p, convertirla nel modo noto in Xp e verificare se Xp = X ripetendo tale procedura se luguaglianza non sussiste

Attacchi alle password Off-line vs On-line


Un attacco off-line detto anche dictionary attack perch le password candidate vengono prese da un dizionario se un avversario pu sferrare un attacco off-line, allora necessario aumentare la grandezza dello spazio cui appartiene il segreto

Memorizzare info. per autenticazione


Un server pu autenticare un utente solo se ha accesso alle corrispondenti informazioni di autenticazione
hash delle password, codice identificativo, ecc..

Molteplici sono i modi per gestire e memorizzare tali informazioni


1. Sono individualmente configurate in ogni server
le info. dellutente Alice sono configurate in modo indipendente in ogni server cui Alice ha accesso

2. Sono memorizzate in un Authentication Storage Node (ASN) che offre il servizio di repository
un server che deve autenticare Alice pu richiederle allASN poi pu eseguire da se lautenticazione

Memorizzare info. per autenticazione


1. Sono gestite in un Authentication Facilitator Node (AFN) che offre il servizio di autenticazione
un server che deve autenticare Alice, rigira le informazioni ricevute da Alice allAFN il quale esegue lautenticazione rispondendo Yes o No al server richiedente

ovviamente, nei casi 2. e 3. necessario che il server autentichi a sua volta lASN o lAFN
altrimenti qualcuno potrebbe spacciarsi per lASN/AFN e fornire informazioni di autenticazione false

Memorizzare info. per autenticazione


Riguardo al dove memorizzare tali informazioni di autenticazione
evitare database con password in chiaro qualcuno, Trudy, potrebbe catturare il database
violando il nodo (server) che lo ospita, o accedendo ad un backup

nel caso 1. Trudy potrebbe impersonare tutti gli utenti di quel server
se un utente usa la stessa password su pi server allora potrebbe essere impersonato anche in questi

nei casi 2. e 3., Trudy potrebbe impersonare tutti gli utenti di tutti i server dellASN/AFN

Memorizzare info. per autenticazione


Esiste chiaramente un trade-off:
la strategia 1. pi costosa, essendo distribuita, ma il rischio pi confinato le strategie 2. e 3. sono meno costose, essendo centralizzate, ma sono pi rischiose

Anzich memorizzare le password in chiaro una possibilit memorizzare lhash


scegliendo in modo accurato la password si protetti anche da attacchi di tipo dictionary

Memorizzare info. per autenticazione


In alternativa, il database potrebbe memorizzare password cifrate (non in chiaro)
non c il rischio di dictionary attack un intruso dovrebbe ottenere una chiave segreta robusta, cio di elevata qualit
non derivata con una tecnica nota da una password dutente

sembra pertanto che memorizzare password cifrate sia sempre la soluzione pi sicura in pratica, una scelta abbastanza giusta per la memorizzazione dei backup del database in supporti di memorizzazione esterni al server

Memorizzare info. per autenticazione


ma non lo nel caso in cui si voglia proteggere il database in esercizio
se il nodo del database viene violato da Trudy, non dovrebbe essere difficile per Trudy ottenere la chiave di cifratura che in genere memorizzata nellhard disk del server in una posizione accessibile ad utenti con privilegi (ma gli intrusi quasi sempre riescono ad ottenere i privilegi) se la chiave non fosse nellhard disk sarebbe peggio! vorrebbe dire che lamministratore di sistema inserisce a mano la chiave segreta (128 it) ad ogni reboot quindi la chiave sar molto probabilmente salvata sul suo PC

naturalmente possibile combinare entrambe le tecniche cifrando il database con gli hash delle password
ottenendo i benefici di entrambe

Sistemi di autenticazione Introduzione

AUTENTICAZIONE BASATA SULLINDIRIZZO

Autenticazione basata sullindirizzo


Si ha unautenticazione basata sullindirizzo se lidentit della sorgente pu essere inferita esaminando lindirizzo di rete dal quale arrivano i pacchetti
lidea base che ciascun computer C memorizzi delle informazioni che specificano gli account utenti, di altri computer, accreditati ad accedere a C
ad esempio, se lutente Smith del calcolatore residente al nodo N ha il permesso di accedere al computer C ed eseguire richieste quale il log-in e comandi come copy <source-file> <destination-file> se C deduce che una richiesta arriva dal nodo N e da parte di Smith, allora C onorer tale richiesta

Autenticazione basata sullindirizzo


Lautenticazione basata sullindirizzo sicura rispetto alle intercettazioni, ma sottoposta alle seguenti minacce
a) se qualcuno, diciamo Trudy, ottiene i privilegi su un nodo FOO
oltre a poter accedere alle risorse di tutti gli utenti di FOO, pu anche accedere alle risorse di rete di ogni utente con un account su FOO

b) se Trudy pu impersonare gli indirizzi di rete dei nodi, pu accedere a tutte le risorse di rete di tutti gli utenti che hanno un account su qualcuno di tali nodi

Autenticazione basata sullindirizzo


Dipendentemente dallambiente (tipo di rete, sistema operativo e configurazione), lautenticazione basata sullindirizzo pu essere pi o meno sicura rispetto ad inviare password in chiaro E chiaramente pi conveniente ed il meccanismo di autenticazione scelto in molti sistemi distribuiti

Sistemi di autenticazione Introduzione

PROTOCOLLI DI AUTENTICAZIONE CRITTOGRAFICI

Protocolli di autenticazione crittografici


I protocolli di autenticazione crittografici possono essere molto pi sicuri sia di quelli basati su password (in chiaro) sia di quelli basati sullindirizzo

In un protocollo di autenticazione crittografico Alice prova la sua identit eseguendo delle operazioni crittografiche su quantit fornite da Bob Le operazioni crittografiche eseguite da Alice dipendono da uninformazione segreta nota solo ad Alice o al pi anche a Bob
I protocolli di autenticazione crittografici saranno ampiamente esaminati nel seguito

Sistemi di autenticazione Introduzione

PASSWORD COME CHIAVI CRITTOGRAFICHE

Password come chiavi crittografiche


Le chiavi crittografiche, in particolare quelle dei sistemi a chiave pubblica, sono costituite da sequenza binarie casuali molto lunghe una persona non pertanto in grado di ricordare delle chiavi crittografiche ma in grado di ricordare una password spesso quindi conveniente disporre di tecniche per derivare delle chiavi crittografiche a partire da password
tecniche che trasformano una stringa di testo memorizzabile da una persona in una chiave crittografica

Password

Chiave DES

Sia pwd una stringa di testo Calcola il digest hpwd = h(pwd) La chiave DES si ottiene selezionando 56 bit dal risultato hpwd
chiaramente molto pi complicato e computazionalmente costoso convertire una password in una chiave privata RSA dato che una chiave RSA deve godere di particolari propriet aritmetiche

Password

PU, PR Jeff Schiller

Jeff Schiller ha proposto un possibile modo per ottenere una coppia di chiavi RSA da una password in un tempo plausibile

Convertire la password in un seme per un generatore di numeri casuali Usare tale generatore per generare i numeri primi grandi dai quali si ottengono la chiave pubblica e privata Si noti che eseguendo due volte la generazione delle chiavi RSA si ottengono le medesime chiavi Ovviamente nella pratica tale tecnica computazionalmente inefficiente

Password

PU, PR Jeff Schiller

la generazione delle chiavi RSA richiede infatti di eseguire molti tentativi primi di ottenere un numero primo grande un trucco per accelerare i tempi il seguente una volta trovata la prima coppia di chiavi, si contano il numero di tentativi effettuati per la generazione dei numeri primi p e di q
#tp, #tq = tentativi per p, tentativi per q

si chiede allutente di memorizzare oltre alla password anche tale coppia #tp, #tq lesecuzioni successive dellalgoritmo possono rigenerare p e q in un sol colpo

Password

PU, PR Jeff Schiller

nel caso di autenticazione su una workstation si pu anche pensare che la coppia #tp, #tq sia memorizzata nella workstation stessa non ha infatti alcun valore per chi non conosce la password dutente a cui associata

tuttavia tecniche di questo tipo non sono usate perch rimangono comunque computazionalmente inefficienti

Chiave privata cifrata con la password


La soluzione comunemente adottata per evitare la memorizzazione di una chiave privata PR cifrare PR con una chiave segreta ottenuta dalla password: E(PR, Kpwd) e memorizzare E(PR, Kpwd) in una repository accessibile dalla workstation dellutente
specificando le credenziale dellutente per la workstation stessa

in modo tale che, la workstation dellutente, diciamo Alice, possa in modo trasparente ad Alice recuperare prima Kpwd e poi decifrare la chiave privata

Sistemi di autenticazione Introduzione

INTERCETTAZIONI E VIOLAZIONI DEL SERVER AUTENTICANTE

Scenario in esame
si consideri un utente, Alice, che deve autenticarsi presso un server remoto Bob
per poter fruire dei servizi resi dal server Bob

Lautenticazione deve garantire che nessuno sia in grado di impersonare Alice


anche se riesce ad intercettare i messaggi scambiati tra Alice e Bob, e/o riesce a violare il server Bob e ad accedere in modo non autorizzato al database contenente le informazioni per lautenticazione

Requisiti di sicurezza
consideriamo pertanto i seguenti requisiti d sicurezza

R1) protezione rispetto eventuali intercettazioni delle informazioni trasmesse


se un avversario intercetta tali informazioni non deve poter impersonare Alice

R2) protezione rispetto eventuali violazioni del server e/o accessi in lettura non autorizzati al suo database
se un intruso viola il server Bob e riesce ad accedere al database non deve poter impersonare gli utenti di Bob

Osservazioni/Domande
Ovviamente, i requisiti R1) e R2) impongono ladozione di una autenticazione crittografica Domande
Come si pu procedere? Conviene usare la password? Conviene usare tecniche crittografiche a chiave pubblica o a chiave segreta?

Uso di pwdAlice + PUBob


Proviamo a combinare luso della password con tecniche crittografiche a chiave pubblica
la password di Alice cifrata con la chiave pubblica di Bob nel database del server Bob la password non memorizzata in chiaro, ma viene memorizzato il suo digest
Alice Bob PUBob Im Alice, {fiddlesticks}Bob PRBob

h(fiddlesticks)

Uso di pwdAlice + PUBob


La precedente soluzione soddisfa i requisiti R1 ed R2?
R1 non soddisfatto
un impostore potrebbe riusare il messaggio inviato da Alice ed impersonarla inoltre si potrebbe ottenere la password con un attacco dictionary se non viene applicato lo standard #PKCS1

R2 parzialmente soddisfatto
violando il server Bob si potrebbe ricavare la chiave privata PRBob se la password non robusta un attacco off-line di tipo dictionary potrebbe ricavarla

Alice

Domanda: possibile modificare questo schema di autenticazione? h(fiddlesticks)

Bob

PUBob

Im Alice, {fiddlesticks}Bob

PRBob

Uso di pwdAlice + PUBob


Si considerino le seguenti modifiche ove
random: numero random
tale numero implicito nello standard #PKCS1; se si segue tale standard pu omettersi

timestamp: intero che codifica lora attuale salt: numero random unico associato ad ogni utente f(): una qualche funzione deterministica; pu anche essere omessa
Alice Bob PUBob
Im Alice, {fiddlesticks||random||timestamp}Bob

PRBob

h(f(salt||fiddlesticks))

Uso di pwdAlice + PUBob


ora R1 abbastanza rispettato
la quantit random permette di sventare attacchi di tipo dictionary sulle password cifrate con PUBob il timestamp non consente di riciclare messaggi scaduti; per, messaggi molto recenti potrebbero ancora essere riciclati

invece R2 ancora parzialmente soddisfatto


violando il server Bob si potrebbe ricavare la chiave privata PRBob la presenza del salt rende pi difficile lattacco di tipo dictionary sugli hash memorizzati nel database anche se lintruso potrebbe individuare il salt!?

senza crittografia asimmetrica?

Domanda
Cosa succede se non fosse possibile ricorrere alla cifratura a chiave pubblica? Si assuma che Alice e Bob condividano un segreto SAB da cui sia possibile ottenere, con una procedura conosciuta, una password KAB

Uso di pwdAlice + segreto condiviso


R1 continua ad essere soddisfatto abbastanza bene R2 non soddisfatto: una violazione del server Bob permetterebbe di ottenere il segreto condiviso SAB
il segreto condiviso SAB in genere non sar protetto bene quanto la chiave privata di Bob PUBob la chiave privata PUBob unica ed associata al server Bob, pu essere protetta in luoghi e modi particolarmente sicuri ad esempio potrebbe non essere salvata nellhard disk, ma in una memoria non volatile speciale

Alice

h(f(salt||fiddlesticks))

Bob

SAB

Im Alice, KAB{fiddlesticks||random||timestamp}Bob

SAB

Uso di password in chiaro


utilizzando password in chiaro R1 non soddisfatto R2 soddisfatto abbastanza bene

Alice

h(f(salt||fiddlestikcs))

Bob

Im Alice, fiddlestikcs

Chiavi crittografiche vs Password


Nellipotesi che Alice (o il suo client) disponga di un qualche tipo di chiave crittografica
PRAlice: una chiave privata, o KAB: una chiave segreta condivisa con Bob, non derivata da password

E possibile migliorare i precedenti schemi di autenticazione? Conviene ancora usare tecniche a chiave pubblica o sono preferibili tecniche a chiave segreta?

Uso di PRAlice
La seguente soluzione,
che non fa uso di password, ma sfrutta le propriet della firma digitale soddisfa entrambi i requisiti R1 e R2
Im Alice Alice Bob R [R]Alice R firmato con la chiave privata di Alice

conosce PUAlice

Uso di KAB non derivata da pwd


Tale soluzione invece,
che non fa uso di password e sfrutta una chiave segreta condivisa KAB tra Alice e Bob soddisfa R1, ma non soddisfa R2; violando il server Bob si otterrebbe il segreto KAB
Im Alice Alice Bob conosce KAB R

X(R, KAB)
X() una qualche funzione crittografica X() = h((), KAB) oppure X() = KAB{}

Riassumendo
Se si desidera soddisfare a pieno i requisiti R1 e R2
conviene evitare luso di password ed necessario ricorrere alla crittografia a chiave pubblica senza la crittografia a chiave pubblica diventa molto complicato, se non impossibile, soddisfare contemporaneamente R1 e R2, mentre facile soddisfare o solo R1 o solo R2

Sistemi di autenticazione Introduzione

INTERMEDIARI FIDATI

Distribuzione delle chiavi segrete


si assuma che la sicurezza di una rete si basi sulla tecnologia a chiave segreta

se la rete ha n nodi, e ogni computer c deve poter autenticare ogni altro nodo c deve memorizzare n 1 chiavi
una per ogni altro sistema della rete

se un nuovo nodo viene aggiunto alla rete dovrebbero essere generate n nuove chiavi
per avere una chiave segreta condivisa con tutti gli n nodi pre-esistenti

Distribuzione delle chiavi segrete


sarebbe pertanto necessario distribuire tali n chiavi in modo sicuro a tutti gli altri nodi della rete tale strategia di gestione delle chiavi pu aver senso solo per reti molto piccole!

Centri di distribuzione delle chiavi


Un centro di distribuzione delle chiavi, Key Distribution Center (KDC), agevola la gestione/distribuzione delle chiavi segrete conosce le chiavi di tutti i nodi se un nuovo nodo si aggiunge alla rete, sola una chiave segreta, condivisa tra quel nodo e il KDC, deve essere generata

Comunicazione tra due nodi del KDC


KDC

KKDC chiave segreta condivisa tra il nodo e il KDC KKDC chiave segreta condivisa tra il nodo e il KDC

Comunicazione tra due nodi del KDC


Se un nodo deve comunicare con un nodo
comunica con il KDC in modo sicuro, e
usando la loro chiave segreta condivisa KKDC

gli chiede di inviargli una chiave per comunicare con


il KDC autentica , sceglie un numero random R da usare come chiave segreta condivisa tra e cifra R con la chiave segreta KKDC che condivide con , e

Comunicazione tra due nodi del KDC


trasmette a R cifrata insieme alle istruzioni che deve usare per comunicare con
in genere, il KDC non trasmette direttamente R cifrato a , ma lo invia ad che poi lo inoltrer a

il messaggio cifrato per che il KDC invia ad , e che dovr inoltrare a detto ticket oltre a contenere R il ticket contiene altre informazioni utili
data di scadenza, nome del nodo , ecc.

KDC Vantaggi
I KDC semplificano la distribuzione delle chiavi
quando un nuovo utente deve essere aggiunto alla rete, o quando si sospetta che una chiave dutente sia stata compromessa

c un singolo punto della rete, il KDC, la cui configurazione deve essere aggiornata
lalternativa al KDC installare le informazioni di un utente in ciascun server ove potrebbe accedere

KDC Svantaggi
Luso dei KDC comporta per i seguenti svantaggi
contiene tutte le informazioni per impersonare un utente ad un qualsiasi altro utente se compromesso tutte le risorse di rete risultano vulnerabili un KDC un single point of failure, in caso di guasto nessuno pu iniziare una comunicazione con uovi utenti
le chiavi precedentemente distribuite continuano a funzionare

KDC Svantaggi
possibile avere pi KDC (KDC multipli) con lo stesso database di chiavi, ma ci comporta
una maggior complessit di gestione, costi extra per le macchine e per la replicazione dei protocolli, e maggiori vulnerabilit, necessario proteggere pi target da eventuali attacchi

un KDC pu costituire un collo di bottiglia


in questa caso, avere pi di un KDC pu alleviare tale problema

Autorit di certificazione
La distribuzione delle chiavi pi facile con la crittografia a chiave pubblica
ogni nodo deve custodire soltanto la propria chiave privata tutte le chiavi pubbliche possono essere accessibili in un unico punto

ma anche in questo caso continuano ad esserci dei problemi


chi garantisce che le chiavi pubbliche disponibili in un dato punto siano corrette un intruso, Trudy, potrebbe sovrascrivere la chiave pubblica di Alice con la propria, riuscendo cos ad impersonare Alice

Autorit di certificazione
per evitare la falsificazione delle chiavi pubbliche si ricorre alle Autorit di Certificazione Una Autorit di Certificazione, Certification Authority CA, un intermediario fidato che genera i certificati, cio dei messaggi firmati dalla CA contenenti il nome, la chiave pubblica ed altre informazioni di uno specifico nodo tutti i nodi dovranno essere pre-configurati con la chiave pubblica della CA, in modo tale da poter verificare la sua firma sui certificati rilasciati
si tratta dellunica chiave pubblica che devono conoscere a priori

Contenuto di un certificato
Un certificato include
il nome utente
persone fisica, organizzazione, server, applicazione,

la chiave pubblica dellutente la data di scadenza un numero seriale e la firma, della CA che lo ha emesso, dellintero contenuto del certificato
lo standard X.509 per le infrastrutture a chiave pubblica ha definito il formato standard di un certificato

Visualizzazione di un certificato

Autorit di certificazione
i certificati possono essere memorizzati nel luogo ritenuto pi conveniente in un directory service, oppure ciascun nodo pu memorizzare i certificati dinteresse e trasmetterli durante lo scambio di autenticazione in un certo senso le CA sono la controparte dei KDC nelle infrastrutture a chiave pubblica CA e KDC costituiscono lintermediario fidato la cui compromissione pu arrecare seri danni allintegrit della rete

Vantaggi della CA rispetto i KDC


La CA non necessario che sia on-line
pu risiedere in una stanza fisicamente ben protetta (magari con una guardia) si pu limitare laccesso alla CA ad una sola persona di grande fiducia
questa persona interagendo con la CA, genera il certificato di un dato utente, lo memorizza su un qualche supporto di memoria esterna che pu consegnare a mano al diretto interessato

se la CA non on-line
nessun potenziale intruso pu accedervi per ottenere informazioni utili non deve implementare protocolli di rete che richiedono elevata efficienza computazionale pu essere implementata da un dispositivo estremamente semplice e pertanto molto pi sicuro

Vantaggi della CA rispetto i KDC


Se la CA dovesse crashare, la rete continuerebbe a funzionare
non sarebbe per possibile aggiungere nuovi utenti o revocare certificati compromessi o di utenti sospetti pertanto non essenziale avere CA multiple

I certificati sono poco sensibili ad eventuali attacchi


se memorizzati in modo conveniente, ma potenzialmente insicuro (ad es. in un servizio di directory), un sabotatore pu cancellare i certificati, impedendo laccesso ai corrispondenti nodi della rete (attacco DOS) ma non pu creare dei certificati fasulli o modificarli in qualche modo se non dispone della chiave privata della CA

Vantaggi della CA rispetto i KDC


Una CA compromessa non pu decifrare le conversazioni tra due nodi (reali) da lei serviti
mentre un KDC compromesso pu decifrare tutte le conversazioni tra coppie di nodi da lui serviti una CA compromessa
pu ingannare un utente, diciamo Alice inviandogli una falsa chiave pubblica di Bob e riuscire ad impersonare Bob in una comunicazione con Alice ma non pu decifrare una comunicazione tra la vera Alice e il vero Bob

la compromissione di una CA rimane un fatto molto grave, ma non quanto la compromissione di un KDC

Revoca di certificati
Le CA presentano comunque il seguente svantaggio rispetto i KDC
supponiamo che Fred offra dei servizi di hosting per conto dellazienda X SpA la societ X SpA fornisce a Fred un certificato (rilasciato a favore della X SpA) necessario ad autenticare il server Fred conosce la chiave privata della chiave pubblica certificata supponiamo inoltre che a causa di un contrasto con Fred, la X SpA decida di interrompere il rapporto di lavoro se il certificato ancora valido Fred pu continuare a rendere dei servizi per conto della X SpA, magari anche danneggiandola

Revoca di certificati
per la X SpA sarebbe importante informare gli utenti di non accettare il certificato generato per Fred e ancora in corso di validit con i KDC tale problema di facile soluzione, basta rimuovere KFred dal KDC

ovviamente si ha un problema analogo anche quando viene smarrita, o peggio rubata, la chiave privata associata alla chiave pubblica certificata

Revoca di certificati
nel caso delle CA non facile estromettere qualcuno che detiene una chiave privata la cui chiave pubblica certificata
si noti che potrebbe essere molto rischioso attendere la scadenza naturale del certificato; in queste situazioni conviene revocare il certificato

Si revoca un certificato quando,


a partire da un certo momento, non devono essere pi considerate valide le firme generate con la chiave privata abbinata alla chiave pubblica contenuta nel certificato

Liste di certificati revocati


La revoca di un certificato si attua inserendo un riferimento al certificato allinterno di una lista di revoca (Certificate Revocation List CRL)
una CRL elenca una lista di numeri seriali di certificati da non onorare ogni CA pubblica periodicamente una nuova CRL che contiene tutti i certificati revocati e non scaduti

Liste di certificati revocati


Un certificato valido se
la firma della CA valida, non scaduto non inserito nella CRL pi recente della CA che lo ha emesso
la CRL ha una data e ora di emissione
se unapplicazione vuole assicurarsi che nessuno dei certificati che onora sia stato revocato entro unora prima della verifica allora deve essere trascorsa al pi un ora dal momento in cui la CRL, consultata da tale applicazione, stata emessa quindi, in questo caso, una nuova CRL deve essere pubblicata con una cadenza di unora

Liste di certificati revocati


un intruso potrebbe cancellare lultima CRL, in tal caso le applicazioni configurate per consultare esclusivamente CRL pubblicate nellultima ora si rifiuteranno di onorare tutti i certificati ma lintruso non pu impersonare un utente valido distruggendo la CRL o sovrascrivendola con una CRL pi vecchia

lo standard X.509 ha definito anche il formato delle CRL, in base a tale standard una CRL deve includere
una lista di numeri seriali di certificati revocati e non scaduti e una data e ora di emissione della CRL la firma dellintera lista con la chiave privata della CA

Problema
Supponiamo che Bob sia unapplicazione che deve autenticare lutente Alice

Illustrare un possibile protocollo di autenticazione a chiave pubblica, che includa una verifica della correttezza della chiave pubblica di Alice

Soluzione

chiaramente Bob ha bisogno del certificato di Alice, CertAlice, e di una CRL recente
Bob pu ottenerli da un servizio di directory, oppure Alice li trasmette a Bob

Soluzione
0) Bob recupera il certificato di Alice CertAlice e una CRL recente 1) Consultando il certificato CertAlice individua la chiave pubblica di Alice PUAlice 2) Verifica la correttezza di PUAlice come segue
2.1) se il certificato CertAlice correttamente firmato dalla CA che lo ha emesso e non scaduto, e 2.2) la CRL correttamente firmata dalla CA ed sufficientemente recente e non contiene il certificato CertAlice allora Bob conclude che PUAlice corretta (quindi quella nel certificato)

Soluzione
3) Bob ed Alice iniziano uno scambio di messaggi seguendo uno schema di autenticazione a chiave pubblica, ad esempio
3.1) Bob invia una sfida R ad Alice 3.2) Alice firma R con la propria chiave privata ed invia [R]Alice a Bob 3.3) Bob verifica la firma di Alice ed in caso affermativo autentica Alice

Soluzione schema
Im Alice, CertAlice, CRL

1) ottiene PUAlice 2) verifica correttezza PUAlice 3.1) genera R

R
Alice
3.2) calcola la firma [R]Alice

[R]Alice
3.3) verifica la firma [R]Alice

Bob

Bibliografia
[DES81] DES Modes of Operation, FIPS PUB 81, National Bureau of Standards, U.S. Department of Commerce, 1981. [KPS02] C. Kaufman, R. Perlman, M. Speciner. Network Security Private Communication in a Public World. Prentice Hall. [PFL08] C. P. Pfleeger, S. L. Pfleeger. Sicurezza in Informatica. Pearson, Prentice Hall. [STA07] W. Stallings. Sicurezza delle reti. Pearson, Prentice Hall. [Wiki-it] http://it.wikipedia.org/wiki/ [Wiki-en] http://en.wikipedia.org/wiki/ [ISECOM] Institute for Security and Open Methodologies