99 lines
8.6 KiB
Markdown
99 lines
8.6 KiB
Markdown
|
# 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**:
|
||
|
|
|
||
|
|
1. **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)**.
|
||
|
|
|
||
|
|
2. **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.
|
||
|
|
|
||
|
|
3. **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.
|
||
|
|
|
||
|
|
4. **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).
|
||
|
|
|
||
|
|
5. **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**.
|
||
|
|
|