Protocollo di autenticazione KERBEROS

Presentazione sul tema: "Protocollo di autenticazione KERBEROS"— Transcript della presentazione:

1 Protocollo di autenticazione KERBEROS
Corso di Sistemi di elaborazione delle informazioni: sicurezza Anno Accademico Protocollo di autenticazione KERBEROS Daniela Demergasso

2 KERBEROS KERBEROS: un protocollo di autenticazione. Storia
Le componenti del processo di autenticazione. Protezione della rete entro un dominio (reame). Protezione della rete tra più domini. Kerberos versioni 4 e 5. Limiti.

3 Servizio di autenticazione Kerberos
Permette ad un processo (client), in nome di un utente (user), di provare la sua identità ad un verificatore (verifier) senza spedire dati attraverso la rete. E’ della categoria “authentication for real-time”. Usato per applicazioni quali: remote login, file system r/w, information retrieval su Web. Kerberos è un protocollo di autenticazione che permette ad un processo(client), in nome di un utente (user) di provare la sua identità ad un verificatore (verifier) senza spedire dati attraverso la rete. In questo modo si impedisce ad un intruso o al verificatore stesso di ottenere informazioni che possono essere usate da questi per impersonare il client e sostituirsi ad esso per ottenere accesso a servizi cui non sono autorizzati. Appartiene alla categoria “authentication for real-time” intendendo con questo termine che il client resta in attesa di risposta per poter dare i risultati all’utente e questo richiede una rapida risoluzione del problema di autenticazione per evitare lunghe attese. Kerberos è utilizzato per risolvere il problema della trasmissione di password sotto forma di testo che è comune a numerose applicazioni di rete.

4 Storia di Kerberos E’ stato sviluppato a metà degli anni ‘80 dall’ MIT (Massachusset Institute of Tecnology), come parte del Project Athena Network. La release Kerberos 4 è stata la prima ad essere usata al di fuori dell’MIT. Dai limiti di Kerberos 4 (Es. l’uso del DES) si è realizzata l’implementazione di Kerberos 5. Kerberos 5 è definito dal Request for Comment (RFC) 1510. Kerberos è stato sviluppato a metà degli anni 80 dall’MIT nell’ambito del Project Athena Network che si proponeva di progettare, implementare e gestire ambienti distribuiti. Le prime 3 realeses di Kerberos sono state solo di sviluppo e usate essenzialmente dall’MIT stesso. Kerberos 4 è stata la prima versione ad uscire dall’MIT . Successivamente alla realese 4 numerosi sistemi hanno integrato questo protocollo di autenticazione. I nuovi utenti incontrarono numerose limitazioni con Kerberos 4 cosa che accade spesso con protocolli implementati su sistemi diversi che devono gestire richieste impreviste. Non sempre questi limiti erano tecnici. Es.: Kerberos 4 usava la cifratura DES, ma il DES non può essere esportato fuori dagli USA. A partire dai limiti di Kerberos 4 si è realizzato Kerberos 5. Tra i miglioramenti apportati c’è l’utilizzo del TriploDES o di altri algoritmi di cifratura. Nonostante i prodotti con Kerberos 4 siano ancora ampiamente usati la maggior parte dei nuovi prodotti usa Kerberos 5.

5 “Componenti” di Kerberos
Kerberos ha processo di autenticazione “three-sided” a chiave segreta condivisa(DES). Il processo coinvolge tre componenti: l’applicazione client che rappresenta l’utente che accede a un servizio l’application server: è la risorsa che vuole accertarsi che i client siano autorizzati il repository centralizzato delle chiavi, Key Distribution Center (KDC), e il servizio di generazione ticket Ticket Granting Service (TGS) (Authentication Server) Kerberos ha un processo di autenticazione three-sided a chiave segreta condivisa che usa la cifratura DES (3DES). La chiave segreta condivisa identifica il fatto che 2 parti condividono la chiave con cui possono verificare le reciproche identità. Three-sided significa che il processo di autenticazione coinvolge 3 parti. - l’application client che rappresenta l’utente - l’application server che che è la risorsa che desidera avere garanzie sull’identità dei client che gli inviano delle richieste - l’Authenticator server che si compone del repository centralizzato delle chiavi Key Distribution Center (KDC) del distributore dei ticket Ticket Granting Service (TGS). I ticket sono delle convalide con cui i client provano la loro identità agli application server per accedere ai servizi che questi offrono. KDC e TGS gestiscono dei data base in cui sono memorizzate le master key (chiavi private generate a partire dalle password) rispettivamente appartenenti ai client e agli application server che sono registrati presso tali componenti. Le master Key all’interno del data base sono criptate con la chiave privata rispettivamente del KDC e del TGS. Le password di tali componenti rappresentano l’ultimo livello di difesa. Basta “indovinare” queste password per compromettere l’intera rete. Un KDC fisicamente sicuro è una componente fondamentale per avere un efficiente sistema Kerberos.

6 “Componenti di Kerberos”

7 DES (Data Encryption Standard)
E’ un cifrario composto sviluppato dall’IBM. Il testo in chiaro è codificato in blocchi di 64 bit generando 64 bit di testo cifrato. Usa una chiave a 56 bit che permette codifica e decodifica eseguendo 19 passi.

8 Protezione della rete entro un dominio
Un client C1 che vuole accedere a informazioni su di un application server S1 all’interno di un reame contatta il KDC per ottenere l’autenticazione. A fronte di tale richiesta è generata una catena di eventi che porta all’autenticazione di C1. In corrispondenza di tali eventi sono generati dei messaggi della forma: KDC > C1: {12345} KC1,S1 Quando un utente vuole accedere a informazioni su un application server S1 all’interno di un reame (dominio) il client corrispondente effettua una richiesta al KDC per ottenere l’autenticazione. A fronte di questa richiesta è generata una catena di eventi che porta all’autenticazione del client. Un REAME è l’insieme di tutti i clients e servers registrati presso lo stesso authentication server. Kerberos usa dei messaggi per fare in modo che le singole componenti sappiano cosa sta avvenendo durante il processo di autenticazione. Esempio di messaggio: KDC > C1: {12345} KC1,S1 KDC>C1 specifica che KDC invia un messaggio a C1. Il messaggio segue i “:”. Quando il messaggio è tra {} è cifrato. La K è al chiave di cifratura mentre le lettere e i numeri che seguono la chiave identificano i client e i server che possono accedere (condividono) tale chiave. Traduzione: KDC invia a C! il messaggio cifrato e C1 ed S1 possiedono la chiave per decifrarlo.

9 Protezione della rete entro un dominio
Client C1 KDC TGS Server S1 C1 KDC ts1 {KC1,TGS {C1 KC1,TGS ts2}KTGS }KC1 {S1 KC1,S1}KC1,TGS {C1 KC1,S1}KS1 { ts4 + 1} KC1,S1 {C1 KC1,S1}KS1 {ts4}KC1,S1 S1 {C1 KC1,TGS ts2}KTGS {ts3 cks}KC1,TGS Qui è mostrato il flusso dei messaggi (sincroni) tra le componenti del processo di autenticazione.

10 Protezione della rete entro un dominio PASSO 1
C1 effettua la richiesta di autenticazione al KDC. Il messaggio inviato è: C1>KDC: C1 KDC ts1 Il timestamp ts1 è l’identificativo della richiesta presso il KDC. Un client che vuole accedere ad un servizio fa una richiesta di autenticazione al KDC. Le informazioni fornite sono l’identificativo del client C1 l’identificativo del KDC un timestamp st1 che identifica univocamente il messaggio presso il KDC Il messaggio è interamente in chiaro.

11 Protezione della rete entro un dominio PASSO 2
KDC risponde con Ticket Granting Ticket (TGT) criptato con una chiave KTGS conosciuta solo dal TGS. KC1,TGS chiave di sessione tra TGS e C1. TGT contiene KC1,TGS e un timestamp ts2. L’intera risposta del KDC è criptata con la chiave privata di C1. Messaggio: KDC>C1: {KC1,TGS {C1 KC1,TGS ts2}KTGS }KC1 Il KDC risponde con un messaggio contenente un Ticket Granting Ticket (TGT) che contiene l’identificatore del client C1 la chiave di sessione condivisa tra C1 e TGS KC1,TGS un timestamp st2 che sarà usato per il controllo di validità della chiave di sessione ed è criptato con la chiave privata del TGS KTGS. Il TGT ha validità di circa 8 ore. L’intero messaggio è cifrato con la chiave privata del client in modo che solo C1 possa decifrarlo. Messaggio: KDC>C1: {KC1,TGS {C1 KC1,TGS ts2}KTGS }KC1

12 Protezione della rete entro un dominio PASSO 3
C1decifra con la sua chiave KC1 il messaggio ricevuto e ne estrae il TGT e la chiave di sessione KC1,TGS. C1 manda la richiesta al TGS composta da: nome dell’application server S1 TGT un “authenticator” criptato con KC1,TGS contenente un timestamp ts3 per i controlli di validità un checksum cks per i controlli di integrità. Messaggio: C1>TGS: S1 {C1 KC1,TGS ts2}KTGS {ts3 cks}KC1,TGS C1 ricevuto il messaggio dal KDC lo decifra con la propria chiave privata KC1ottenuta dalla digitazione della password che viene immediatamente cancellata dalla workstation. C1 ottiene così la chiave di sessione KC1,TGS e il TGT da usare per fare un’application request al TGS. La richiesta è composta da l’identificativo dell’application server S1 ai cui servizi si vuole accedere il TGT un authenticator criptato con la chiave KC1,TGS contenente un timestamp ts3 per il controllo di validità del messaggio un checksum cks per il controllo di integrità del messaggio L’authenticator rende vano ogni attacco da parte di un intruso che tenti di copiare questo messaggio per rinviarlo successivamente. L’uso del timestamp che non può essere modificato con uno più recente, in quanto cifrato fa sì che, se il messaggio viene rinviato, il TGS facendo un controllo sulla marca di tempo lo scarti. Nel caso in cui l’intruso fosse abbastanza veloce da mandare il messaggio in tempo utile otterrebbe solo una copia del messaggio di risposta che non sarebbe in grado di decifrare non conoscendo la chiave di sessione condivisa da C1 e TGS. Le chiavi hanno una validità in torno ai 5 minuti in modo da evitare intrusioni. Il fatto di dover fare controlli di tempo comporta che le componenti coinvolte di volta in volta nel processo di autenticazione siano sincronizzate.

13 Protezione della rete entro un dominio PASSO 4
TGS decripta il TGT con la sua chiave e controlla la validità della chiave di sessione KC1,TGS ricevuta. Se è valida decripta l’authenticator e ne controlla validità e integrità. Se tutto è corretto genera la chiave di sessione per C1 ed S1 KC1,S1 costruisce un ticket per S1contente l’identità di C1 e KC1,S1, criptato con KS1(chiave privata di S1). Completa il messaggio con una parte contenente l’identità di S1 e la chiave KC1,S1, criptati con KC1,TGS. TGS>C1: {S1 KC1,S1}KC1,TGS {C1 KC1,S1}KS1 Il TGS che riceve l’application request decripta il TGT con la sua chiave privata KTGS e controlla il timestamp ts2 per vedere se la chiave di sessione KC1,TGS ricevuta è ancora valida. Se lo è la estrae dal TGT e la usa per decifrare l’authenticator. Dopo aver controllato la validità dell’authenticator in base al confrontando il ts3 con il current time del sistema controlla il checksum, se anch’esso è corretto si è sicuri che è stato proprio C1 a criptare l’authenticator poiché è l’unico che può conoscere la chiave KC1,TGS. A questo punto il TGS che ha identificato C1 e S1 genera un chiave di sessione KC1,S1 per essi. Costruisce un ticket per S1 contenente l’identificatore del client C1 che vuole accedere ai suoi servizi e la chiave condivisa KC1,S1. Il ticket è cifrato con la chiave privata di S1 KS1. Un’altra parte del messaggio contiene la chiave di sessione KC1,S1 e il nome del server S1 criptati con la chiave condivisa da C1 e TGS. TGS>C1: {S1 KC1,S1}KC1,TGS {C1 KC1,S1}KS1

14 Protezione della rete entro un dominio PASSO 5
C1 decripta parte del messaggio, con la chiave che condivide con il TGS, ottenendo la chiave di sessione per comunicare con l’application server KC1,S1. Manda a S1 un messaggio contenente il ticket ricevuto dal TGS per S1 un timestamp ts4 criptato con KC1,S1. Messaggio: C1>S1: {C1 KC1,S1}KS1 {ts4}KC1,S1 C1 ottiene così la chiave di sessione KC1,S1 e può finalmente comunicare con l’application server per stabilire una sessione con lui. Il messaggio generato da C1 per S1 contiene il ticket per S1 ricevuto dal TGS e un timestamp ts4 cifrato con la chiave di sessione KC1,S1.

15 Protezione della rete entro un dominio PASSO 6
S1 decifra con la sua chiave privata il ticket ottenendo la chiave di sessione condivisa con C1 KC1,S1. Controlla la validità del messaggio. Poiché è sicuro di parlare con C1 gli manda un messaggio contenente il timestamp ts4 incrementato di uno e criptato con la chiave di sessione. Messaggio: S1>C1: { ts4 + 1} KC1,S1 Questo messaggio è per C1 la prova che sta comunicando con S1. S1 che riceve il messaggio decifra il ticket, con la sua chiave privata KS1, e vedere che il processo è stato autorizzato ad accedere ai suoi servizi è C1. Con la chiave di sessione KC1,S1, recuperata dal ticket decifra il timestamp ts4 rilevando la validità del messaggio. S1 è sicuro di parlare con C1 e gli invia un messaggio contenente ts4 incrementato di 1 cifrato con KC1,S1. S1>C1: { ts4 + 1} KC1,S1 Questo messaggio è per C1 la prova che sta parlando con S1 e non con un intruso perché solo S1 poteva decifrare il ticket e quindi il timestamp. A questo punto C1 e S1 possono comunicare (condividendo la chiave di sessione) in modo sicuro della reciproca identità.

16 Protezione della rete entro un dominio
Ora C1 e S1 sono sicuri delle reciproche identità. Se C1 vuole comunicare con un altro application server S2 deve solo ripetere la richiesta (a partire dal passo 3) specificando S2 al posto di S1. Non deve autenticarsi di nuovo presso il KDC. Il TGS gli fornirà subito un ticket cifrato per il server S2 che C1 potrà inviargli per autenticarsi e iniziare una nuova sessione. Il ticket presentato è solo un’autenticazione, quello che C1 può fare dipende solo dal server contattato. Se il client vuole richiedere servizi ad un altro application server S2 deve solo comunicare la richiesta al TGS (passo 3) specificando S2 al posto di S1, senza dover richiedere un nuovo TGT al KDC. Il TGS risponderà subito con un nuovo ticket di convalida cifrato con la chiave di S2 che C1 potrà inviare a S2 per identificarsi e iniziare una nuova sessione. C1 può quindi accedere a tutti gli application server in rete in maniera sicura senza che la sua password sia transitata in rete. Quando il client presenta un ticket (convalida) questo prova al server solo l’identità di chi lo ha inviato. Quello che il client può fare dipende solo dal server.

17 Protezione della rete tra più domini
Kerberos può “coprire” più domini. Ogni reame dispone di un KDC e di un TGS. C1 per autenticarsi presso un server in altro reame fa una richiesta ai propri KDC e TGS locali. TGS riconosce la richiesta per un altro reame e fornisce a C1 un TGT per la richiesta al TGS remoto. Il TGT è cifrato con la chiave condivisa dai due TGS. I progettisti di Kerberos previdero la possibilità di avere più domini. Ogni reame dispone di un KDC e di un TGS. Il client C1 per avere una chiave di sessione per autenticarsi presso il server S in un altro reame contatta i propri KDC e TGS locali. Il TGS che riconosce una richiesta riferita ad un altro reame fornisce a C1 un TGT per la richiesta al TGS remoto. Questo TGT è cifrato con la chiave condivisa dai due TGS. Ora il TGT remoto può autenticare il client e gli fornisce il ticket per il server voluto.

18 Protezione della rete tra più domini
Il TGS remoto autentica il client fornendogli il ticket per il server voluto. I client dovrebbero registrarsi nei diversi domini: proposta inaccettabile. Kerberos 5 prevede la condivisione di chiavi gerarchica. C1 contatta un reame che conosce l’altro reame e così via fino a che non si trova il TGS remoto che emette i ticket per il server voluto. Invece di creare un account separato in ognuno dei reami per lo stesso client, cosa inaccettabile per grosse reti come Internet si è introdotta la condivisione di chiavi gerarchiche in modo da limitare il numero di registrazioni da gestire. Questa è la soluzione adottata da Kerberos 5. Il client contatta un reame che conosce l’altro reame e così via fino a che non si trova il TGS remoto che emette il ticket per il server del reame voluto.

19 Kerberos 4 e Kerberos 5 Kerberos 4 è passibile del off-line password guessing. In Kerberos 5 si è risolto il problema: il timestamp ts1 del primo messaggio viene criptato con la chiave privata del client, ottenuta dall’immediata digitazione della password e solo dopo è inviato al KDC. C1>KDC: C1 KDC {ts1} KC1 KDC determina la KC1 dal suo data base locale, decifra ts1e solo se il tempo è corretto manda il TGT. Un “baco” della versione 4 corretto in Kerberos 5. Kerberos 4 è passibile dell’attacco detto OFF-LINE GUESSING PASSWORD. Un attaccante, sfruttando il fatto che è trasmesso interamente in chiaro, fa una copia del primo messaggio, modifica il timestamp con uno più recente e ottiene così in risposta un messaggio dal KDC cifrato con la chiave privata di C1 KC1. Ora l’intruso può con un attacco a dizionario decifrare il messaggio ottenuto e ricavarne un ticket valido con cui impersonare C1 presso il TGS ed accedere a servizi per cui non sarebbe autorizzato. In Kerberos 5 il primo messaggio è mandato con il ts1 cifrato con la chiave privata di C1. L’utente deve digitare la password immediatamente in modo da generare la chiave con cui cifrare il timestamp. Solo dopo la digitazione della password il messaggio è inviato al KDC. C1>KDC: C1 KDC {ts1} Il KDC usa l’identificatore di C1 contenuto nel messaggio per recuperare dal data base la chiave privata KC1 con cui decifrare la marca di tempo. Se il timestamp è corretto il messaggio è originale e C1 riceverà la risposta contenente il TGT altrimenti il messaggio viene scartato.

20 Kerberos 4 e Kerberos 5 Client C1 KDC C1 KDC ts1 Kerberos 4: Il primo messaggio inviato non e` criptato. Client C1 KDC C1 KDC {ts1}KC1 Kerberos 5: Il primo messaggio inviato e` criptato.

21 Limiti di Kerberos E’ soggetto ad attacchi con dizionari di password.
Ogni programma che lo usa deve essere kerberizzato e questo non è sempre possibile. Il server di autenticazione KDC deve essere fisicamente protetto. Tutte le password sono crittografate con una singola master key. Un server compromesso implica il cambiamento di tutte le password. Può cadere vittima di attacchi con dizionari di password se l’utente sceglie una password a cui altri possano risalire facilmente. Chi indovina la password e decifra il ticket può sostituirsi al client e ingannare altri server. Soluzione: usare policy per la gestione delle password e il blocco degli account. Ogni programma per usare Kerberos deve essere modificato. Il processo di modifica è detto “kerberising” ed è tanto più complesso a secondo del tipo di programma che deve esserre “kerberizzato”. Questo processo non è sempre possibile poiché si deve avere accesso ai sorgenti delle applicazioni da trasformare. Il server di autenticazione (KDC e TGS) deve essere fisicamente protetto dentro ad una struttura protetta. Tutte le password memorizzate sono cifrato con una singola master key. Se il server è compromesso si deve cambiare la password a tutti gli utenti (client e application server) registrati.

22 Limiti di Kerberos Il server di Kerberos deve essere sempre disponibile. Non c’è protezione contro le modifiche del sistema Sw: un utente non può sapere se il server è compromesso. Kerberos non lavora bene in ambiente time-sharing. (Esempio: memorizzazione dei ticket in /tmp di Unix) Il tempo limitato per la validità dei ticket è un problema per applicazioni con run time elevato. Il server deve essere sempre disponibile. Se il server cade tutta la rete che usa Kerberos è inutilizzabile. Non c’è protezione contro le modifiche del sistema Sw: un utente seduto alla workstation non può sapere in alcun modo se il server è stato compromesso. Non lavora bene in ambiente time-sharing. Ad esempio in Unix a causa delle difficoltà nella condivisione di dati tra più processi differenti che girano sulla stessa macchina, kerberos mantiene i ticket in /tmp che è una directory pubblica cui chiunque può accedere per rubare i ticket. Avere tempo limitato per la validità dei ticket (8 ore) crea problemi per le applicazioni che necessitano di tempi di esecuzione elevati. Per questo si deve ricorrere a politiche di gestione e rinnovo delle convalide (ticket).

23 Riferimenti Reti di computer UTET (Prentice Hall International)
Tanenbaum -Terza Edizione - Edizione Italiana (1997) UTET (Prentice Hall International) Kerberos Authentication System G.Gramegna - Università degli studi di Padova Un cerbero per proteggere i dati Michael E. Chacon