Sicurezza IIProf. Dario Catalano

Sistemi di Autentica

Introduzione Authentication e’ il processo in

base al quale si puo’ verificare (in modo affidabile) l’identita’ di qualcuno (o qualcosa).

Oggi faremo una carrellata di schemi di autentica.

Nelle prossime lezioni entreremo piu’ nel dettaglio.

Introduzione (cont.)

Due casi interessanti Un computer autentica un altro

computer Un umano usa una workstation

pubblica. L’umano deve ricordare il proprio

“segreto”.

In generale gli umani riescono a memorizzare meglio i propri segreti quando Non sono troppo lunghi Possono sceglierli

Questo rende spesso tali segreti abbastanza prevedibili

Password Based Authentication Il problema fondamentale sono gli

avversari che possono spiare la comunicazione. Quando la password e’ inviata

Per adesso escluderemo quei sistemi in cui la password si puo’ direttamente convertire in una chiave crittografica.

Una password e’ qualcosa di “piccolo” e facilmente memorizzabile.

Perche’ password?

Perche’ usare password quando potremmo utilizzare chiavi crittografiche (molto piu’ sicure)?

Semplice: Nessuno e’ in grado di ricordare a memoria una stringa casuale di 128 bit!

La soluzione crittografica talvolta puo’ essere di difficile attuazione.

Online Password Attack Un modo per “indovinare” la pwd e’ di

provarle tutte per entrare nel sistema. Se l’insieme da provare e’ piccolo tale

operaz. Puo’ essere fatta in tempo ragionevole.

Esistono molti modi per prevenire tali attacchi Es. I bancomat non permettono piu’ di 3

tentativi infruttuosi.

Offline Password Attack Un avversario A potrebbe intercettare la

comunicazione prodotta una connessione valida.

Quindi, supponendo che A conosca il protocollo utilizzato, potrebbe provare con quali password tale comunicazione e’ consistente.

Tale operazione puo’ essere fatta off-line in tutta comodita’.

Offline Password Attack (cont)

Dato che una buona sorgente di password e’ un dizionario, tale attacco e’ noto come dictionary attack.

Cio’ che rende complicati gli schemi basati su password (umanamente memorizzabili) e’ renderli resistenti a questo tipo di attacco.

Gestione delle Pwd/Chiavi

Tre metodologie generali. La chiave di Alice e’ gestita

individualmente da ogni server utilizzato. Un Authentication Storage Node conserva

la chiave I server che vogliono autenticare Alice cercano

la chiave di quest’ultima nel ASN. Un Authentication Facilitator Node

conserva la chiave I server che vogliono autenticare Alice,

mandano l’informazione (ricevuta da Alice) al AFN che fa l’autentica e risponde al server si o no.

Gestione delle Pwd/Chiavi Nei casi 2,3 bisogna essere certi di

comunicare con i veri ASN e AFN. Un utente disonesto potrebbe entrare nel

server facendosi autenticare da falsi ASN/AFN.

In ogni caso, e’ importante che il file delle password sia protetto. E’ inutile precisare quali potrebbero essere

le conseguenze di un avversario che entra a conoscenza di un file di password non protetto.

Memorizzare le pwd in modo protetto Memorizzare l’hash di ogni password

Unix, VMS Rischio Dictionary attack

Il nodo che memorizza le pwd, le cifra. L’attaccante non puo’ ricavare le pwd

senza conoscere la chiave di cifratura. Tale chiave puo’ essere una chiave

crittografica (deve essere memorizzata da un computer)

Ulteriori considerazioni

Cifrare il file di password e’, in generale, una buona idea.

Bisogna stare pero’ attenti a proteggere bene la chiave.

Memorizzarla nello stesso posto che contiene i dati da proteggere, ad esempio e’ una pessima idea.

Address-based Authentication Non si basa sull’invio di pwd. L’identita’ del mittente e’ derivata

dal suo indirizzo (i.e. dall’indirizzo dal quale arrivano i dati spediti).

Ogni computer mantiene informazioni che specificano account in altre macchine che possono aver accesso a determinate risorse.

Address-based Authentication Approccio sicuro contro avversari

che si limitano a spiare. Non vengono inviate password.

Se A ha accesso ad una macchina M, avra’ accesso anche a tutto cio’ che e’ raggiungibile da M

Si tratta comunque di un approccio molto conveniente (e usato) in pratica.

Address-based Authentication L’idea generale può essere implementata

in 2 modi M ha una lista di macchine considerate

“equivalenti”. Ogni macchina equivalente è trattata come una sorta di clone di M. L’utente deve avere gli stessi nomi di account

in tutti i sistemi. M ha una lista (indirizzo,nome account

remoto, nome account locale).

Unix per user .rhosts files UNIX permette (ad ogni account utente)

di mantenere un file .rhosts che contiene una lista di coppie (computer, account) che sono autorizzate ad accedere all’account. Bob può dunque permettere accessi remoti

al proprio account creando un opportuno file .rhosts

I nomi account nella lista, non devono essere identici a quello dell’account dove il file .rhosts si trova Ciò permette a Bob di poter avere più

account.

Unix per user .rhosts files Ogni richiesta che non è per un

account che ha lo stesso nome dell’account mittente deve contenere il nome dell’account che dovrà processare la richiesta. Se l’account su M è Bob e la richiesta

proviene dalla macchina B, con nome di account Alice, tale richiesta deve specificare il fatto che essa vuole far riferimento all’account Bob.

Protocolli di autentica crittografici

L’autentica basata su primitive crittografiche puo’ essere molto piu’ sicura degli approcci precedenti.

Alice prova la sua identita’ effettuando una qualche operazione crittografica su una quantita’ fornita da Bob. Es. Alice firma un msg fornito da Bob.

Protocolli di autentica crittografici

In pratica le password possono essere utilizzate per produrre chiavi crittografiche nel seguente modo. Viene calcolata l’hash della password Si usa la pwd per decifrare una chiave

crittografica (memorizzata da qualche parte)

Password come chiavi crittografiche Le chiavi crittografiche sono, in

generale, numeri piuttosto grandi. Per esempio per costruire una chiave

DES a partire da una pwd: D=H(pwd) // Hash della pwd I primi 56 bit di D sono la chiave richiesta.

E’ molto piu’ complicato generare chiavi asimmetriche (es. RSA)

Da pwd a RSA La pwd e’ utilizzata come seme per un

generatore pseudocasuale. Il generatore viene utilizzato fino a

quando non produce due primi p e q (di lunghezza adeguata).

Se il metodo viene eseguito piu’ volte produrra’ lo stesso risultato

Tale metodo e’ comunque estremamente inefficiente

Schemi a chiave pubblica da pwds Gli schemi basati su tali idee sono in

generale molto poco usati La conversione è in generale estremamente

inefficiente. Conoscere la chiave pubblica permette, in

talune applicazioni, di fare un dictionary attack.

L’utilizzo tipico di PKC e pwd insieme è il seguente. Si cifra la chiave privata (asimmetrica)

utilizzando (un derivato della) pwd come chiave di un cifrario simmetrico.

Utilita’ della crittografia a chiave pubblica La crittografia a chiave pubblica

rende facile “autenticare” in modo sicuro (allo stesso tempo) contro attacchi passivi e di irruzione nel server.

Alice conosce la sua chiave privata Bob mantiene solo la

corrispondente chiave pubblica.

Utilita’ della crittografia a chiave pubblica

Chi entra nel server di Bob non potra’, per questo, impersonare Alice.

Per l’autentica Alice usa la sua chiave privata per fare operazioni crittografiche su valori forniti da Bob.

Spiare e’ del tutto inutile.

Utilita’ della crittografia a chiave pubblica

Senza la crittografia a chiave pubblica ottenere entrambe queste proprieta’ sembra molto difficile.

Per renderci conto di questo, guardiamo alcuni esempi concreti.

Protocollo 1 Bob (il computer) mantiene il segreto X

di Alice. Alice si autentica in base alla propria

identita’ (es.: calcola l’output di una funzione crittografica su input X e un msg scelto da Bob)

Se Adv spia non guadagna nulla. Se Adv ha accesso al DB di Bob, allora,

pero’, sono guai.

Protocollo 2 Bob (il computer) mantiene in memoria

l’hash della pwd di Alice Alice si autentica inviando la propria

pwd a Bob (Bob calcola l’hash di pwd e verifica se corrisponde a quella memorizzata)

Se Adv ha accesso al DB di Bob non guadagna nulla.

Se Adv spia, allora, pero’, potrà autenticarsi al posto di Alice.

Esiste un protocollo (proposto da L.Lamport) che realizza le proprieta’ citate senza utilizzare crittografia asimmetrica.

Tale protocollo ha il serio limite di poter autenticare un utente solo un numero limitato di volte (poi bisogna reinizializzare il sistema)

Vedremo tale protocollo nelle prossime lezioni.

Intermediari Fidati Supponiamo di voler basare la

sicurezza delle reti su metodi simmetrici.

Se la rete e’ grande (n nodi) ogni computer deve memorizzare n-1 chiavi per comunicare.

Se un nuovo nodo viene aggiunto, n nuove chiavi devono essere generate.

Tutto questo non e’ molto pratico.

Key Distribution Center (KDC) Nodo fidato che conosce tutte le

chiavi. Se un nuovo nodo e’ installato,

solo KDC e il nuovo nodo hanno la nuova chiave.

Se A vuole parlare con B, A contatta KDC (in modo sicuro) e ottiene una chiave per parlare con B.

Piu’ precisamente

KDC sceglie una chiave RAB. Cifra RAB con la chiave che condivide

con A e manda il crittotesto creato ad A. Cifra RAB con la chiave che condivide

con B e manda il crittotesto creato ad B. A e B possono utilizzare RAB come

chiave per comunicare in modo sicuro.

Pro e contro

KDC rendono la distribuzione delle chiavi facile da gestire.

Se un nuovo nodo deve essere installato, solo KDC viene “disturbato”.

Se un utente e’ stato attaccato, solo il KDC deve essere riconfigurato.

Pro e contro

KDC ha abbastanza informazioni per impersonare chiunque.

KDC e’ un singolo punto di fallimento.

Un unico KDC puo’ divenire un collo di bottiglia del sistema.

Distribuzione di chiavi via PKC La distribuzione delle chiavi e’ piu’

facile se si utilizza PKC. Eppure anche in questo caso

sorgono dei problemi. Come facciamo ad essere sicuri

che una data chiave pubblica corrisponde davvero all’utente che sembra averla resa disponibile?

Certification Authority Nodo trusted che genera certificati

Messaggi firmati che associano ad un nome la sua chiave pubblica.

Tutti devono essere in grado di poter riconoscere e verificare le firme prodotte da CA.

I certificati possono essere conservati in qualunque luogo conveniente.

Vantaggi (rispetto a KDC) La CA non ha bisogno di rimanere sempre

on-line. CA puo’ essere qualcosa di molto semplice

-> e’ piu’ facile garantirne la sicurezza. In caso di crash di CA non crolla il sistema.

Solo la registrazione dei nuovi utenti verrebbe bloccata.

Non e’ necessario avere piu’ CA.

Vantaggi (rispetto a KDC) I certificati non sono security

sensitive Un avversario, che entra in possesso di

un certificato, non puo’ fare grandi danni.

Una CA compromessa non puo’ decifrare i crittotesti destinati ai suoi utenti. Puo’ far credere ad Alice che la pk di

Bob sia valida, quando non lo e’.

Revoca di Certificati

Un certificato ha una validita’ “standard” ma potrebbe venir revocato se determinate circostanze sono verificate. Simile al caso delle carte di credito.

Un problema di CA e’ la revoca dei certificati.

Certificate Revocation List (CRL)

E’ una lista di certificati che, per quanto formalmente validi, non devono essere considerati tali.

E’ pubblicata periodicamente. Dunque un certificato e’ valido se non

e’ scaduto, la firma (CA) e’ valida e non e’ nella CRL piu’ recente.

Il problema tempo Se ho bisogno di verificare che un

certificato non e’ stato revocato nell’ultima ora devo avere un CRL molto aggiornata.

Piu’ frequente e’ l’aggiornamento piu’ efficiente sara’ il sistema globale, ma piu’ complicata risulta la gestione delle CRL.

Vedremo in seguito maggiori dettagli su certificati e protocolli di revoca.

Molteplici Intermediari (fidati)

Sia KDC che CA richiedono un’unica amministrazione (fidata). Compromettere KDC o CA significa poter

autenticare chiunque presso chiunque. Il problema e’ che, spesso, nel mondo

reale nessuno e’ disposto a fidarsi di altri.

La soluzione e’ allora di suddividere il mondo in domini.

Domini

Ogni dominio ha una amministrazione fidata (KDC o CA)

Se Alice e Bob appartengono allo stesso dominio l’autentica avviene come gia’ accennato.

Se appartengono a domini diversi la situazione e’ un po’ piu’ complicata.

Domini KDC

Alice (ad es. dominio WWF) vuole comunicare con Bob (dominio Greepeace)

Supponiamo che i KDC di WWF e Greepeace abbiano una chiave in comune KGW.

Alice informa il suo KDC di voler comunicare con Bob di Green peace.

Domini KDC

Alice informa KDCWWF di voler comunicare con Bob di Greenpeace.

KDCWWF genera una chiave Knew e la manda ad Alice e KDCGreepeace

Alice contatta Greenpeace (usando Knew) e chiede di parlare a Bob.

KDCGreepeace genera una chiave KAliceBob e la manda ad Alice e Bob.

Domini KDC

L’approccio descritto continua a non essere troppo pratico in presenza di molti domini.

In generale e’ preferibile avere strutture un po’ piu’ complicate (alberi, catene, ecc.)

Vedremo in seguito (forse) alcuni di tali aspetti.

Domini CA Il ruolo delle chiavi e’ svolto dai certificati. Ogni CA certifica la validita’ delle altre CA. Alice (WWF) per essere sicura della chiave di

Bob (Greenpeace) controlla il certificato della CAGreenpeace di Bob, firmato da

CAWWF. Tale certificato attesta che PKGreenpeace e’ proprio la chiave pubblica di CAGreenpeace.

la validita’ della chiave di Bob (via il certificato emesso da CAGreenpeace).

Session Key Establishment

Se al posto di pwd scambiate in chiaro si facessero sempre autentiche con chiavi crittografiche, le reti sarebbero molto piu’ sicure di quanto non siano oggi.

Domanda: come utilizzare e gestire le chiavi crittografiche?

Crittografia a chiave pubblica Una soluzione potrebbe essere di usare

sempre crittografia a chiave pubblica. Alice firma tutti i messaggi che manda

in modo da poter essere autenticata senza che il destinatario debba mantenere chiavi segrete.

Problema: PKC e’ (molto) piu’ inefficiente di SKC

Crittografia a chiave segreta

Se Alice e Bob condividono una chiave segreta per autenticarsi vicendevolmente, potrebbero pensare di utilizzare la stessa chiave per cifrare i propri messaggi.

Questa non e’ una buona idea.

Crittografia a chiave segreta Le chiavi tendono a “rovinarsi” se

utilizzate troppo Piu’ dati vengono cifrati con una stessa

chiave piu’ e’ facile per l’avversario riuscire a ricavare tale chiave.

Generare chiavi condivise e’ costoso. Per questo l’authentication key dovrebbe

essere utilizzata solo per il messaggio iniziale.

Una chiave di sessione puo’ essere generata (in fase di autentica) ed utilizzata per cifrare e garantire integrita’ durante la sessione.

Crittografia a chiave segreta Se Alice e Bob vogliono utilizzare la stessa

chiave per auth e proteggere l’integrita’, questo puo’ essere causa di attacchi. Un avversario potrebbe inserire dati inviati in

precedenti sessioni spacciandoli per nuovi al destinatario

Normalmente nell’ambito della stessa sessione si utilizzano codici sequenziali per prevenire tala problema

In generale potrebbe non esserci alcun codice per distinguere sessioni differenti.

Crittografia a chiave segreta

Se una chiave master e’ compromessa, tutto e’ a rischio. Sarebbe utile poter evitare che dati

inviati o ricevuti prima della sessione corrotta rimanessero riservati.

Proteggere un segreto per breve tempo e’ piu’ facile che proteggerlo a lungo.

Delega Talvolta e’ utile che qualcuno (o

qualcosa) agisca al nostro posto. Es. Permettere ad un server di stampare un

documento che sono autorizzato a leggere. Un modo per realizzare questo potrebbe

essere dare la propria pwd a chi deve svolgere il compito per noi. Problema: chi riceve la password potrebbe

far danni.

Delega Approccio migliore: si genera un

msg (firmato) che specifica a chi, per cosa e per quanto tempo viene fatta la delega.

Una volta scaduto il tempo, la delega perde di validita’

Utilizzando PKC questo puo’ essere realizzato tramite firme digitali.

Delega via KDC Alice chiede a KDC di dare a Bob

determinati permessi. KDC crea il msg contenente gli adeguati

permessi, lo cifra con una chiave (nota solo a KDC) e manda il crittotesto ottenuto (C) a Bob.

Bob non puo’ decifrare C, ma in caso di necessita’ puo’ dare C a KDC per ottenere gli accessi ai quali ha diritto.

Perche’ la scadenza? Se posso delegare dei diritti per un

dato lasso di tempo, in un certo senso devo fidarmi.

Fidarsi per poco tempo e’ meglio che doversi fidare sempre.

Oltra a poter limitare la durata, potremmo limitare anche le risorse accessibili.