Un servizio di autenticazione per sistemi di rete aperti

Presentazione sul tema: "Un servizio di autenticazione per sistemi di rete aperti"— Transcript della presentazione:

1 Un servizio di autenticazione per sistemi di rete aperti
Kerberos Un servizio di autenticazione per sistemi di rete aperti Tesina corso di sicurezza a/a 2001/02 a cura di Rossi Daniele

2 Introduzione Kerberos è un servizio di autenticazione distribuito che permette ad un processo (client) in nome di un utente (user) di provare la sua identità senza spedire dati attraverso la rete che possano permettere ad un intruso di impersonarlo successivamente. Il nome deriva dal cane a tre teste della mitologia greca che sorveglia le porte dell'Ade, il regno dei morti. Fu sviluppato a metà degli anni 80 come parte del progetto Athena al MIT e attualmente è alla versione 5.

3 Introduzione (2) Basato sul modello di distribuzioni delle chiavi sviluppato da Needham e Schroeder usa la crittografia a chiave simmetrica per cifrare e decifrare le comunicazioni tra client e server. Sono cruciali in questo protocollo le figure dell‘ "Authentication Server" (AS) e del “Ticket Granting Server” (TGS). L'AS conserva in un suo database le chiavi degli utenti; il suo compito è quello di fornire ad un client che vuole comunicare con un server un ticket (TGT). Tramite questo ticket il client potra’ provare la sua identita’ al TGS e ricevere da questo una chiave di sessione con la quale potra’ stabilire una comunicazione cifrata col server.

4 Cosa succede nel dettaglio
Supponiamo che il client voglia accedere ad un server : Inizialmente effettua una richiesta di autenticazione all’AS inviando un messaggio contenente Nome del client Nome del server a cui si vuole accedere Una data di scadenza calcolata a partire dalla data e dall’ora locale del client Nome client, Nome Server, scadenza Client AS Server TGS

5 L’AS prepara 2 copie di una chiave di sessione Ks valida per l’ algoritmo
crittografico scelto e crea 2 ticket che inviera’ al client: uno cifrato con la chiave del TGS; l’altro cifrato con la chiave del client. In ogni ticket c’e’ una copia di Ks, c’e’ la data di scadenza ricevuta dal cliente ci sono 2 identificativi: l’ID del client nel ticket cifrato con Ktgs e l’ID del server nel ticket cifrato con Kcli. Nome client, Nome Server, scadenza Client AS Kcli (scadenza,Ks,ID server) Ktgs(scadenza,Ks,ID client) Server TGS

6 timestamp chksum [other]
Quando il client riceve i due Ticket decifra quello cifrato con la sua chiave segreta, estrae la chiave di sessione Ks, prepara un ticket speciale chiamato “authenticator” cifrato con Ks ed invia al TGS l’ ”authenticator” e il Ticket cifrato con Ktgs. Questo Ticket e’ chiamato TGT (Ticket Granting Ticket) ed ha una vita relativamente breve, circa 8 ore. L’ “authenticator” contiene un timestamp calcolato a partire dall’ora locale del client e un chksum per un controllo dell‘ integrita’ del ticket. Ticket Authenticator Scadenza Ks ID server timestamp chksum [other] Nome client, Nome Server, scadenza Client AS Kcli (scadenza,Ks,ID server) Ktgs(scadenza,Ks,ID client) Ktgs(scadenza,Ks,ID client) Ks(timestamp,chksum,ID server) Server TGS

7 Il TGS quindi riceve il Ticket e l’ “authenticator”, con la propria chiave segreta decifra il Ticket ed estrae la chiave di sessione Ks. Con Ks decifra l’ “authenticator”, grazie al quale puo’ verificare la scadenza della chiave usando l'informazione contenuta nel Ticket, se questa è valida ha la certezza che essa sia stata generata dall’ AS perché solo quest'ultimo conosce la sua chiave segreta; analogamente decifrando l'Authenticator il TGS ne verifica l'integrità con il chksum e controlla che esso non sia stato già spedito usando il timestamp in esso contenuto (non si accettano msg con lo stesso timestamp). Questo da la certezza al TGS che la richiesta sia stata fatta dal client associato al Ticket perchè solo lui poteva conoscere la chiave di sessione. Nome client, Nome Server, scadenza Client AS Kcli (scadenza,Ks,ID server) Ktgs(scadenza,Ks,ID client) Ktgs(scadenza,Ks,ID client) Ks(timestamp,chksum,ID server) Server TGS

8 Una volta autenticato il client, il TGS rilascera' un ticket e una session key per la comunicazione client/server. Al client la session key verra' comunicata criptata con la Ks. Opzionalmente può esser richiesta la "mutua autenticazione" che in genere consiste di un messaggio cifrato con Ks2 contenente il timestamp ricevuto dal client incrementato di un’ unita’. Anche in questo caso il client accetterà il Ticket solo se esso non contiene un timestamp non valido. [Naturalmente l'uso dei timestamp in un sistema distribuito necessita di una forte sincronizzazione dei vari host partecipanti allo scambio. ] Nome client, Nome Server, scadenza Client AS Kcli (scadenza,Ks,ID server) Ktgs(scadenza,Ks,ID client) Ks2(timestamp, chksum) Kser(scadenza,Ks2,ID client) Ktgs(scadenza,Ks,ID client) Ks(timestamp,chksum,ID server) Ks2(timestamp+1) Server TGS Ks(scadenza,Ks2,ID server) Kser(scadenza,Ks2,ID client)

9 Kcli (scadenza,Ks,ID server)
Ktgs(scadenza,Ks,ID client) AS Client Server Nome client, Nome Server, scadenza TGS Ks(timestamp,chksum,ID server) Ks(scadenza,Ks2,ID server) Kser(scadenza,Ks2,ID client) Ks2(timestamp, chksum) Ks2(timestamp+1) Se il client vuole richiedere servizi ad un altro server deve solo comunicare la richiesta al TGS, senza dover richiedere un nuovo TGT al AS. I progettisti di Kerberos previdero la possibilità di avere più domini. Un REAME è l’insieme di tutti i clients e servers registrati presso lo stesso AS. Ogni reame dispone di un AS e di un TGS. Invece di creare un account separato in ognuno dei reame per lo stesso client, cosa inaccettabile per grosse reti, si è introdotta la condivisione di chiavi gerarchiche in modo da limitare il numero di registrazioni da gestire.

10 Differenze con v4 Dalla versione 4 alla versione 5 sono stati introdotti molti miglioramenti sia all'implementazione che al protocollo. Essi possono essere riassunti nei seguenti punti: Maggior livello di astrazione Virtualmente è supportato qualsiasi algoritmo crittografico, inoltre si potrebbe scegliere una qualsiasi funzione HASH per la conversione "password2key" ed un qualsiasi algoritmo per la generazione dei checksum.

11 Maggior sicurezza (salt in password2key)
L'approccio che si segue è quello di applicare una funzione HASH alla stringa composta concatenando la password dell'utente con un "SALT" il cui valore varia a secondo delle versioni di Kerberos e che serve ad es a rendere la trasformazione sulla password dipendente dalla macchina sulla quale è effettuata. (replay cache) In kerberos v4 le autenticazioni hanno una durata di 5 minuti: se un intruso si impossessa dell’autenticazione, ha accesso ai servizi per 5 minuti. In kerberos v.5 e’ stata aggiunta una replay cache nel server. Questo per salvare l’ authenticator spedito negli ultimi minuti in modo da accorgersi di quando qualcuno sta cercando di ritrasmettere un messaggio gia’ usato.

12 Kcli (scadenza,Ks,ID server)
Ktgs(scadenza,Ks,ID client) AS Client Server Nome client, Nome Server, scadenza TGS Ks(timestamp,chksum,ID server) Ks(scadenza,Ks2,ID server) Kser(scadenza,Ks2,ID client) Ks2(timestamp, chksum) Ks2(timestamp+1) (cifratura nella richiesta di autenticazione all’AS) Kerberos 4 è passibile dell’attacco detto OFF-LINE GUESSING PASSWORD. Un attaccante, sfruttando il fatto che il primo msg è trasmesso interamente in chiaro, crea una copia falsa e ottiene così in risposta un msg dall’ AS cifrato con la chiave privata del client.Ora l’intruso può con un attacco a dizionario decifrare il messaggio ottenuto e ricavarne un ticket valido con cui impersonare il client presso l’ AS ed accedere a servizi per cui non sarebbe autorizzato. In Kerberos 5 il primo messaggio è mandato con la scadenza cifrata con la chiave privata del client.

13 Ticket Esiste una vasta gamma di autorizzazioni che corrispondono a diverse tipologie di Ticket, distinguiamo in particolare: Ticket iniziali Alcuni servizi possono scegliere di accettare solo quei ticket che sono stati rilasciati direttamente dall'AS, perché il loro rilascio è strettamente legato all'inserimento una password, invece di usare le informazioni in cache. Ticket Pre-Autenticati Il server AS chiede ai client di far di più che mandare solo un messaggio per dimostrare la loro identità.es timestamp corrente criptato con Kcli Ticket postdatati (ticket del TGS) Ticket rinnovabili (TGT) Ticket proxy Un client potrebbe desiderare un servizio che a sua volta richiede ticket per poter usufruire di altri servizi come se fosse il client. Questo è il caso quando il primo servizio ha privilegi d'accesso ad un altro servizio. Per permettere questo, può essere spedito un TGT al servizio, il quale lo re-indirizza al secondo servizio.

14 Analisi e comparazioni
Le principali limitazioni possono essere riassunte nei seguenti punti : non protegge contro la possibilità di scoperta della password dell'utente (può cadere vittima di attacchi con dizionari di password se l’utente sceglie una password a cui altri possano risalire facilmente. soluzione: usare policy per la gestione delle password e il blocco degli account.) richiede un cammino sicuro attraverso il quale deve transitare la password dell'utente, inoltre richiede in genere una macchina dedicata e sicura per AS e TGS per poterlo utilizzare le applicazioni devono essere in parte riscritte, devono essere delle "Kerberized Applications" Sebbene dal punto di vista dell'utente Kerberos sia totalmente trasparente, la sua installazione è tuttaltro che indolore. L'installazione di Kerberos è piuttosto "intrusiva" e necessita di un adattamento del sistema su cui gira che consiste nella modifica di diversi file di configurazione e nella sostituzione di gran parte dei "server" standard, il che a volte crea un conflitto con software già esistenti che non possono essere kerberizzati.

15 Differenze con SSL In generale il confronto tra SSL e Kerberos è il confronto tra il sistema di autenticazione a chiavi private con terza parte fidata contro quello a chiavi pubbliche basato sui certificati. Come si nota subito SSL ha due maggiori vantaggi su Kerberos: SSL non richiede una terza parte fidata; esso può essere usato per stabilire una connessione sicura anche quando tra le due parti non esistono segreti come chiavi, password ecc.. Questi due vantaggi rendono SSL ideale per la comunicazione sul Web e per applicazioni simili.

16 Ovviamente anche SSL ha i suoi inconvenienti:
Le chiavi revocate: se un certificato valido rilasciato ad un utente è compromesso e deve essere revocato, come fanno tutti i server con cui quell'utente interagisce a sapere che quel certificato non è più valido? Ogni revoca di certificati deve essere propagata a tutti i server più importanti più volte oppure i server verifica ogni volta i certificati entranti con il "revocation server". In questo caso il server delle revoche deve essere disponibile ogni momento e comunque deve assicurare una comunicazione sempre efficiente essendo una terza parte necessaria, e con ciò si va a perdere uno dei maggiori vantaggi di SSL su Kerberos. In Kerberos una chiave revocata può essere disabilitata attraverso il KDC e il ticket diventerà inutilizzabile al più presto senza nessuna operazione dei server.

17 La sicurezza delle chiavi in SSL: quando si ottiene un certificato, esso risiederà sull'hard disk del sistema. Essendo cifrato con una password memorizzata nel sistema e’ vulnerabile ad eventuali attacchi di hacker. In Kerberos invece non c'è la necessità di ricerca di certificati per l'autenticazione, tranne che per la password che è nella testa dell'utente e non sull'hard disk.

18 Costo di utilizzo: Kerberos è un pacchetto libero e può essere installato liberamente, mente SSL è licenziato e il suo utilizzo deve essere pagato. Discorso analogo per quanto riguarda la documentazione. La flessibilità: Kerberos è più flessibile di SSL. Per esempio se si vuole aggiungere una nuova tecnologia di autenticazione (ad es un nuovo tipo di Smart Card con il proprio algoritmo), l'unica cosa da fare è modificare il proprio AS in modo tale da accettare questo nuovo tipo di autenticazione Invece se si vuole implementare una nuova tecnologia di autenticazione in SSL, è fortemente consigliato attendere il rilascio di una nuova versione di SSL che supporti quella tecnologia.

19 In conclusione non si può dire quale sistema di autenticazione sia più efficiente tra Kerberos e SSL. Una cosa sicura è che esistono applicazioni con cui Kerberos è più efficiente di SSL e viceversa.

20 FINE