Protocollo di Autenticazione

Il protocollo di autenticazione e' utilizzato nella comunicazione client-server tramite l'utilizzo di segreti client-side e server-side, cosi' che:

Non sia possibile effettuare attacchi replay sulla connessione
Sia mantenuta una sessione applicativa per tutta la durata della connessione

Come vanificare attacchi replay?

Credenziali temporizzate: dopo 3/6 mesi scadono (soluzione debole)
Password generata da token con funzione univoca (basata su data/ora, un hash del tempo,etc). Questo avviene sia server-side che client-side, quindi il timestamp utilizzato deve avere una precisione sufficiente per permettere a entrambe le parti di ottenere le stesse credenziali (se scadono dopo 1 ms, il server e il client potrebbero non essere sincronizzati). Inoltre, essendo che potrebbe verificarsi il caso in cui il client e il server sono sul "limite" di validita' delle credenziali, e' necessario prendere in considerazione l'intervallo di tempo precedente e successivo (server-side). La password generata ha durata media uguale a 3*precisione del timestamp.(soluzione comunque debole per la lunga durata del timestamp)

One-time password (OTP)

Protocollo unidirezionale (client->server) utilizzando un segreto condiviso (password conosciuta da entrambe le parti). Solo che invece di mandare la password, in questo caso viene mandato h^n(password), ossia una funzione di hash eseguita n volte sulla password.

Essendo che la funzione di hash e' non invertibile e resistente alle collisioni, e' impossibile ritornare alla password dall'hash. Il server controlla che h^n sia corretta, poi segna n come utilizzato e quindi non piu' utilizzabile, e la volta successiva si calcolera' h^(n-1). Arrivati a n = 0, viene mandata la h^0(password), ossia la password stessa. Questa e' l'ultima autenticazione possibile prima di una nuova inizializzazione (nuova password, ricomincia). Questo sistema e' un primo esempio di protocollo di autenticazione. E' sicuro,ma:

Non mantiene nessuna sessione operativa successiva all'autenticazione.
Soggetto a session hijacking: dopo l'autenticazione, e' possibile inserirsi e prendere controllo della sessione.

Per risolvere queste problematiche, e' necessario un protocollo bidirezionale. NOTA: differenza tra chiave simmetrica e password Non c'e' grande differenza tra password e chiave simmetrica. L'unica differenza e' lo scopo: un utente non memorizzera' mai la chiave simmetrica, mentre una password e' facilmente memorizzabile e quindi utilizzabile anche da ambienti non propri.

Protocollo di Needham / Schroeder

NOTA: il libro Criptography... su Moodle lo chiama Key Distribution Scenario

Terminologia:

Client = Initiator (A)
Server = Responder (B)
Nonce = numero casuale generato da A, lungo abbastanza da non essere indovinabile (N)

Un dialogo tra Initiator e Responder fa si che essi riescano a stabilire una sessione sicura. Questo protocollo e' fatto di 5 messaggi:

Initiator si identifica (sono A, voglio parlare con B) fornendo: nome A, nome B, Nonce (N). Manda questo messaggio in chiaro a un key distribution center (KDC), che e' una trusted third party (TTP). Il KDC utilizza una crittografia a chiave simmetrica (la cifratura asimmetrica non era stata ancora inventata). E' quindi necessario che A e KDC utilizzino una chiave condivisa in precedenza [ K(A,KDC) ]. La condivisione della chiave viene fatta in maniera "manuale", ossia esterna al protocollo. Nota: lo stesso dialogo e' effettuato anche con B, condividendo K(B,KDC).
Il KDC risponde ad A con un messaggio cifrato sulla chiave K(A,KDC) condivisa in precedenza, inserendo nel messaggio:

una nuova chiave K(A,B) appena generata
il nome di B
il Nonce
un ticket (o capability) T, il quale e' l'encryption di [K(A,B), nome di A] sulla chiave K(B,KDC). A quando riceve questo messaggio non puo' leggere il ticket, il quale e' fatto apposta per essere utilizzato senza decifrarlo.

A manda a B il ticket, come se fosse un biglietto di accesso. Solo B puo' decifrare il ticket, grazie alla chiave condivisa K(B,KDC). B ha cosi' la certezza dell'identita' di A, perche' il ticket contiene l'identita' di A. Se un avversario intercettasse il ticket T e lo mandasse lui stesso a B, non potrebbe decifrarlo, ma potrebbe utilizzarlo come chiave d'accesso a B. Questo e' il motivo per cui ci sono i messaggi 4 e 5, che includono lo scambio di un Nonce aggiuntivo.
B risponde con un messaggio cifrato con K(A,B), inviando nel messaggio un secondo Nonce (N2). A apre il messaggio, legge N2, lo trasforma con una determinata funzione e lo ricifra con la stessa chiave K(A,B).
A manda a B la nuova cifratura di N2.

Il protocollo finisce qui, e tutti i messaggi successivi saranno cifrati con K(A,B).

Note riguardo al protocollo

Il "cuore" del protocollo sono i messaggi 1,2,3, che fanno parte dell'autenticazione. Gli ultimi due inizializzano la sessione. Infatti, dopo il messaggio 3, B sa chi e' A ed entrambi condividono una chiave.

Session hijacking e' quindi impossibile, in quanto i primi 3 messaggi sono leggibili solo da A (grazie a K(A,KDC).
Il messaggio deve essere ben formato per garantire la sicurezza del protocollo.
Non c'e' initialization tra A e B, ma solo tra A e KDC e B e KDC.
I messaggi 4 e 5 hanno lo scopo di dimostrare che la sessione e' attiva e soprattutto di autenticare B verso A, effettuando una cosiddetta Mutual Authentication. Se A non rispondesse al messaggio 4 con il messaggio 5, A dimostra di essere vivo, non solo un avversario che effettua un replay (che non sarebbe in grado di decifrare il messaggio 4).
il Ticket viene anche chiamato capability, ossia un oggetto che non dimostra un'autenticazione ma garantisce l'accesso a un determinato servizio.

Rapporto chiave / utente

Senza una TTP, ogni utente che vuole parlare con altri N utenti ha bisogno di N chiavi. Su un gruppo di N utenti, le chiavi simmetriche sono N+(N-1)+(N-2)... che risulta essere N(N-1)/2, O(N^2). Questo non e' gestibile su una grande quantita' di utenti.

Con unt TTP (come KDC) ogni utente ha bisogno di solo una chiave, quindi il numero di chiavi aumenta in modo lineare per ogni utente aggiunto. Molto piu' gestibile.

Session Keys / Master Keys

In un protocollo di autenticazione come il NS, i dati cifrati si "appoggiano" (sono cifrati con) delle Session Keys, generate al momento. Queste chiavi si appoggiano a delle Master Keys, che di solito sono chiavi "fisiche" condivise in precedenza. Per questo, il collegamento essenziale (e durevole) e' quello che collega l'utente al KDC. Ogni utente deve recarsi a un KDC per ottenere la Master Key, ma questo e' poco pratico.

Spesso esiste piu' di un KDC, di modo da essere piu' accessibile agli utenti.

Esercizio: KDC gerarchico

Immaginare un KDC centrale e vari KDC periferici. Come posso estendere la struttura dei KDC gerarchicamente?

(suggerimento: replicare il protocollo tra il KDC centrale e i periferici) In questo modo gli utenti A,B,C possono autenticarsi sul loro KDC periferico. Cosa succede se due utenti sotto due KDC periferici differenti si vogliono parlare?

Lifetime of an Applicative Session (durata di una sessione applicativa)

NOTA: la pila ISO/OSI definisce il livello di presentazione come quello in cui encoding e crittografia sono gestiti, non quello applicativo.

La durata di una sessione applicativa non e' definita: di solito e' la durata tra il login e il logout dell'utente. La durata di una Session Key invece e' spesso minore della durata della sessione, infatti puo' essere rinnovata piu' volte durante la stessa sessione. La durata di una Master Key varia da alcuni mesi ad alcuni anni, essendo che e' poco pratico e time consuming ottenerne una nuova.

Schema di controllo delle chiavi trasparente

(vedi libro, figura 7.10) Due utenti A,B implementano la pila ISO/OSI.

A livello applicativo, A vuole mandare un messaggio 'm' a B. Il livello applicativo ignora la presenza di un TTP (KDC).
A livello di presentazione (o livello di sessione) sia A che B hanno una Master Key [K(A,KDC), K(B,KDC)]. Quando A vuole mandare un messaggio a B, il livello di sessione di A comincia mandando il messaggio (1) del protocollo al KDC. Il KDC risponde con il messaggio (2), facendo si' che nel livello di sessione si ottenga la chiave condivisa K(A,B). A manda quindi il messaggio (3) a B, utilizzando il ticket. A questo seguono i messaggi (4,5) tra A e B, e solo successivamente il livello applicativo e' autorizzato a mandare un messaggio a B.
Il livello di sessione e' quindi trasparente rispetto al livello applicativo.

8.6 KiB Raw Blame History