Sicurezza II Prof. Dario Catalano Sistemi di Autentica

Introduzione Authentication e il processo in base al quale si puo verificare (in modo affidabile) lidentita 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. Lumano 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 linsieme 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 questultima nel ASN. Un Authentication Facilitator Node conserva la chiave I server che vogliono autenticare Alice, mandano linformazione (ricevuta da Alice) al AFN che fa lautentica 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 lhash di ogni password Unix, VMS Rischio Dictionary attack Il nodo che memorizza le pwd, le cifra. Lattaccante 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 sullinvio di pwd. Lidentita del mittente e derivata dal suo indirizzo (i.e. dallindirizzo 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 Lidea 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. Lutente 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 allaccount. 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 dellaccount 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 dellaccount mittente deve contenere il nome dellaccount che dovrà processare la richiesta. Se laccount 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 allaccount Bob.

Protocolli di autentica crittografici Lautentica 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 lhash 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. Lutilizzo 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 lautentica 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 loutput 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 lhash della pwd di Alice Alice si autentica inviando la propria pwd a Bob (Bob calcola lhash 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 R AB. Cifra R AB con la chiave che condivide con A e manda il crittotesto creato ad A. Cifra R AB con la chiave che condivide con B e manda il crittotesto creato ad B. A e B possono utilizzare R AB 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 allutente 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 nellultima ora devo avere un CRL molto aggiornata. Piu frequente e laggiornamento 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 ununica 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 lautentica 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 K GW. Alice informa il suo KDC di voler comunicare con Bob di Green peace.

Domini KDC Alice informa KDC WWF di voler comunicare con Bob di Greenpeace. KDC WWF genera una chiave K new e la manda ad Alice e KDC Greepeace Alice contatta Greenpeace (usando K new ) e chiede di parlare a Bob. KDC Greepeace genera una chiave K AliceBob e la manda ad Alice e Bob.

Domini KDC Lapproccio 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 CA Greenpeace di Bob, firmato da CA WWF. Tale certificato attesta che PK Greenpeace e proprio la chiave pubblica di CA Greenpeace. la validita della chiave di Bob (via il certificato emesso da CA Greenpeace ).

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 lavversario riuscire a ricavare tale chiave. Generare chiavi condivise e costoso. Per questo lauthentication 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 lintegrita, questo puo essere causa di attacchi. Un avversario potrebbe inserire dati inviati in precedenti sessioni spacciandoli per nuovi al destinatario Normalmente nellambito 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.