D09 Sistemi Di Autenticazione Introduzione

7/29/2019 D09 Sistemi Di Autenticazione Introduzione

1/77

Sistemi di Autenticazione

Introduzione

Luca Grilli


2/77

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


3/77

Possibili scenari

Le varie forme di autenticazione possonoessere 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


4/77

AUTENTICAZIONE BASATA SUPASSWORD

Sistemi di autenticazione Introduzione


5/77

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

Im Alice, the password isfiddlesticks

Alice

Bob

Ovviamente, le intercettazioni

costituiscono la minaccia principale


6/77

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


7/77

Osservazioni

Domanda

Visto che lautenticazione crittografica molto pisicura, per quale ragione si usa lautenticazione basatasu password?

Risposta

per consentire ad una persona di effettuare il log-in inuna 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 chepermetterebbero di risolvere tale problema


8/77

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 tipouomo/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 dirisorse di elaborazione e di tempo di sviluppo e

implementazione

altre volte la crittografia evitata a causa di questioni

legali


9/77

Altre criticit

si consideri il seguente scenario

un utente ha un account presso una workstation

inoltre ha la necessit di accedere, previo inserimentodi username e pwd, ad uno svariato numero di risorse

in rete distribuite su server distinti

per evitare la scomodit di inserire username e pwdogni 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 modoautomatico da questultima ai vari server,


10/77

Altre criticit

ma ci comporta che deve essere usato lo stesso

username e pwd presso ogni server

Come possibile avere la stessa password su moltisistemi 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?


11/77

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 sistemaautenticante

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


12/77


invece, in un attacco off-line un avversario pu

catturare una quantitXderivata 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 candidatap,

convertirla nel modo noto inXp

e verificare seXp =X

ripetendo tale procedura se luguaglianza non sussiste


13/77


Un attacco off-line detto anche dictionary attack

perch le passwordcandidate 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


14/77

Memorizzare info. per autenticazione

Un server pu autenticare un utente solo se haaccesso alle corrispondenti informazioni diautenticazione

hash delle password, codice identificativo, ecc..

Molteplici sono i modi per gestire e memorizzaretali informazioni

1. Sono individualmente configurate in ogni server

le info. dellutente Alice sono configurate in modoindipendente in ogni server cui Alice ha accesso

2. Sono memorizzate in un Authentication StorageNode (ASN) che offre il servizio di repository

un server che deve autenticare Alice pu richiederle

allASN poi pu eseguire da se lautenticazione


15/77


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 eseguelautenticazione rispondendo Yes o No al server

richiedente

ovviamente, nei casi 2. e 3. necessario che ilserver autentichi a sua volta lASN o lAFN

altrimenti qualcuno potrebbe spacciarsi per

lASN/AFN e fornire informazioni di autenticazione

false


16/77


Riguardo al dove memorizzare tali informazioni diautenticazione

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 gliutenti di quel server

se un utente usa la stessa password su pi server allorapotrebbe essere impersonato anche in questi

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


17/77


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, essendocentralizzate, ma sono pi rischiose

Anzich memorizzare le password in chiarouna possibilit memorizzare lhash

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


18/77


In alternativa, il database potrebbe memorizzare

password cifrate (non in chiaro)

non c il rischio di dictionary attack

un intruso dovrebbe ottenere una chiave segretarobusta, 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


19/77


ma non lo nel caso in cui si voglia proteggere il databasein esercizio

se il nodo del database viene violato da Trudy,

non dovrebbe essere difficile per Trudy ottenere la chiave dicifratura che in genere memorizzata nellhard disk del server

in una posizione accessibile ad utenti con privilegi (ma gli intrusiquasi sempre riescono ad ottenere i privilegi)

se la chiave non fosse nellhard disk sarebbe peggio!

vorrebbe dire che lamministratore di sistema inserisce a mano lachiave segreta (128 it) ad ogni reboot quindi la chiave sar molto

probabilmente salvata sul suo PC

naturalmente possibile combinare entrambe le tecnichecifrando il database con gli hash delle password

ottenendo i benefici di entrambe


20/77

AUTENTICAZIONE BASATASULLINDIRIZZO



21/77

Autenticazione basata sullindirizzo

Si ha unautenticazione basata sullindirizzo selidentit della sorgente pu essere inferitaesaminando lindirizzo di rete dal quale arrivano i

pacchetti lidea base che ciascun computer Cmemorizzi delle

informazioni che specificano gli account utenti, di altricomputer, 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

se Cdeduce che una richiesta arriva dal nodo N e da parte di

Smith, allora Conorer tale richiesta


22/77


Lautenticazione basata sullindirizzo sicura

rispetto alle intercettazioni, ma sottoposta alle

seguenti minacce

a) se qualcuno, diciamo Trudy, ottiene i privilegi su unnodo 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


23/77


Dipendentemente dallambiente (tipo di rete,

sistema operativo e configurazione),

lautenticazione basata sullindirizzo pu essere

pi o meno sicura rispetto ad inviare password inchiaro

E chiaramente pi conveniente ed il

meccanismo di autenticazione scelto in molti

sistemi distribuiti


24/77


25/77

Protocolli di autenticazione crittografici

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

In un protocollo di autenticazione crittografico Aliceprova la sua identit eseguendo delle operazionicrittografiche su quantit fornite da Bob

Le operazioni crittografiche eseguite da Alice

dipendono da uninformazione segreta nota solo adAlice o al pi anche a Bob

I protocolli di autenticazione crittografici sarannoampiamente esaminati nel seguito


26/77

PASSWORD COME CHIAVICRITTOGRAFICHE



27/77

Password come chiavi crittografiche

Le chiavi crittografiche, in particolare quelle deisistemi a chiave pubblica, sono costituite da sequenzabinarie 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 perderivare delle chiavi crittografiche a partire da

password tecniche che trasformano una stringa di testo memorizzabile

da una persona in una chiave crittografica


28/77

Password Chiave DES

Siapwduna stringa di testo

Calcola il digest hpwd= h(pwd)

La chiave DES si ottiene selezionando 56 bit dal

risultato hpwd

chiaramente molto pi complicato ecomputazionalmente costoso convertire una

password in una chiave privata RSA dato che una chiave RSA deve godere di particolari

propriet aritmetiche


29/77


30/77

Password PU, PR Jeff Schiller

la generazione delle chiavi RSA richiede infatti dieseguire molti tentativi primi di ottenere un numeroprimo grande

un trucco per accelerare i tempi il seguente

una volta trovata la prima coppia di chiavi, si contanoil numero di tentativi effettuati per la generazione deinumeri primip e di q

#tp, #tq = tentativi perp, tentativi per q

si chiede allutente di memorizzare oltre alla passwordanche tale coppia #tp, #tq

lesecuzioni successive dellalgoritmo possonorigenerarep e q in un sol colpo


31/77

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


32/77

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 Kpwde poi decifrare la chiave privata


33/77

INTERCETTAZIONI E VIOLAZIONIDEL SERVER AUTENTICANTE



34/77

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


35/77

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


36/77


37/77

Uso dipwdAlice + PUBob

Proviamo a combinare luso della password contecniche crittografiche a chiave pubblica

la password di Alice cifrata con la chiave pubblica diBob

nel database del server Bob la password non memorizzata in chiaro, ma viene memorizzato il suodigest

Im Alice, {fiddlesticks}Bob

Alice

Bob

h(fiddlesticks)

PUBob PRBob


38/77


La precedente soluzione soddisfa i requisiti R1 ed R2?

R1 non soddisfatto

un impostore potrebbe riusare il messaggio inviato da Alice edimpersonarla

inoltre si potrebbe ottenere la password con un attacco dictionaryse 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

Im Alice, {fiddlesticks}Bob

Alice

Bob

h(fiddlesticks)

Domanda: possibile modificare

questo schema di autenticazione?

PUBob PRBob


39/77


Si considerino le seguenti modifiche ove random: numero random

tale numero implicito nello standard #PKCS1; se si seguetale standard pu omettersi

timestamp: intero che codifica lora attuale

salt: numero random unico associato ad ogni utente

f(): una qualche funzione deterministica; pu ancheessere omessa

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

Alice

Bob

h(f(salt||fiddlesticks))

PUBob PRBob


40/77


41/77

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


42/77


43/77

Uso di password in chiaro

utilizzando password in chiaro

R1 non soddisfatto

R2 soddisfatto abbastanza bene

Im Alice,fiddlestikcs

A

lice

B

ob

h(f(salt||fiddlestikcs))


44/77


45/77

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

conosce PUAlice

Im Alice

[R]AliceR firmato con la chiave privata di Alice

R

A

lice

Bob


46/77

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 serverBob si otterrebbe il segreto KAB

conosce KAB

Im Alice

X(R, KAB)

X() una qualche funzione crittografica

X() = h((), KAB) oppure X() = KAB{}

RAlice

Bob


47/77

Riassumendo

Se si desidera soddisfare a pieno i requisiti R1e R2

conviene evitare luso di password

ed necessario ricorrere alla crittografia a chiavepubblica

senza la crittografia a chiave pubblica diventa

molto complicato, se non impossibile, soddisfarecontemporaneamente R1 e R2,

mentre facile soddisfare o solo R1 o solo R2


48/77

INTERMEDIARI FIDATI



49/77


50/77

Distribuzione delle chiavi segrete

sarebbe pertanto necessario distribuire tali n chiavi inmodo sicuro a tutti gli altri nodi della rete

tale strategia di gestione delle chiavi pu aver sensosolo per reti molto piccole!


51/77


52/77

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


53/77


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


54/77


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

data di scadenza, nome del nodo , ecc.


55/77

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 statacompromessa

c un singolo punto della rete, il KDC, la cuiconfigurazione deve essere aggiornata

lalternativa al KDC installare le informazioni di unutente in ciascun server ove potrebbe accedere


56/77

KDC Svantaggi

Luso dei KDC comporta per i seguenti svantaggi

contiene tutte le informazioni per impersonare unutente ad un qualsiasi altro utente se

compromesso tutte le risorse di rete risultanovulnerabili

un KDC un single point of failure, in caso di guasto

nessuno pu iniziare una comunicazione con uoviutenti

le chiavi precedentemente distribuite continuano afunzionare


57/77


58/77


59/77

Autorit di certificazione

per evitare la falsificazione delle chiavi pubbliche si ricorrealleAutorit di Certificazione

UnaAutorit di Certificazione, CertificationAuthorityCA,

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 suafirma sui certificati rilasciati

si tratta dellunica chiave pubblica che devono conoscere a priori


60/77


61/77

Visualizzazione di un certificato


62/77

Autorit di certificazione

i certificati possono essere memorizzati nel luogoritenuto 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 KDCnelle infrastrutture a chiave pubblica

CA e KDC costituiscono lintermediario fidato la cuicompromissione pu arrecare seri danni allintegritdella rete


63/77


64/77


65/77


66/77

Revoca di certificati

Le CA presentano comunque il seguente svantaggiorispetto i KDC

supponiamo che Fred offra dei servizi di hosting per contodellaziendaX SpA

la societX SpA fornisce a Fred un certificato (rilasciato afavore dellaX SpA) necessario ad autenticare il serverFred conosce la chiave privata della chiave pubblicacertificata

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 dellaX SpA, magari anchedanneggiandola


67/77


68/77

Revoca di certificati

nel caso delle CA non facile estromettere qualcunoche detiene una chiave privata la cui chiave pubblica certificata

si noti che potrebbe essere molto rischioso attendere la

scadenza naturale del certificato; in queste situazioniconviene 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


69/77

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 dicertificati da non onorare

ogni CA pubblica periodicamente una nuova CRL

che contiene tutti i certificati revocati e nonscaduti


70/77


71/77


72/77

Problema

Supponiamo che Bob sia unapplicazione che deve

autenticare lutente Alice

Illustrare un possibile protocollo diautenticazione a chiave pubblica, che includa

una verifica della correttezza della chiave

pubblica di Alice


73/77


74/77

Soluzione

0) Bob recupera il certificato di Alice CertAlice e una CRLrecente

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)


75/77


76/77


77/77

D09 Sistemi Di Autenticazione Introduzione

Documents

Transcript of D09 Sistemi Di Autenticazione Introduzione