Viene utilizzato il protocollo di autenticazione a chiave pubblica di Needahm-Schroeder che prevede le seguenti operazioni:
Header |
Message |
||
1. |
A->S |
A,B |
A richiede a S la chiave pubblica di B. |
2. |
S->A |
{PKB,B}SKS |
S manda ad A la chiave pubblica di B criptata con la sua chiave segreta. Il messaggio viene cifrato per assicurare che non sia possibile modificarlo. A (e chiunque altro) può decifrare il messaggio usando la chiave pubblica del Server, PKs. |
3. |
A->B |
{NA,A}PK B |
A manda un messaggio contenente un nonce a B cifrato con la chiave pubblica di B. Solo B Solo B può decifrarlo per ottenere il nome di A. |
4. |
B->S |
B,A |
B richiede ad S la chiave pubblica di A. |
5. |
S->B |
{PKA,A}SK S |
S manda ad B la chiave pubblica di A cifrata con la sua chiave segreta. |
6. |
B->A |
{ NA,NB}PK A |
B manda ad A una coppia di nonce cifrati con la chiave pubblica di A |
7. |
A->B |
{NB}PK B |
A manda a B il nonce che ha appena ricevuto cifrato con la chiave pubblica di B. Questo prova la freschezza della comunicazione, e assicura che è proprio A lutente che sta comunicando (solo A poteva decifrare il messaggio 6). |
PKA chiave
pubblica di A PKB chiave pubblica di B PKS chiave pubblica di S SKA chiave segreta di S |
E interessante notare come il protocollo assicuri lautenticità del mittente (il nonce deve essere unico e deve essere generato su domanda). Infatti se il protocollo completa con successo, sia A che B sono sicuri, mediante lo scambio di nonce, che i messaggi che hanno ricevuto vengono proprio dallaltro perché solo lui aveva la possibilità di decifrare il messaggio e rispondere. Naturalmente al termine di questo protocollo avviene la comunicazione vera e propria tra A e B.
Il punto debole del protocollo è lassenza di protezioni contro la replicazione di vecchi messaggi.
I messaggi che possono dare problemi sono i numeri 2 e 5. Un intruso potrebbe intercettare uno di questi messaggi e ripeterlo successivamente ,ad esempio quando la chiave pubblica in questione non è più valida.
La soluzione più ovvia è quella di inserire nel messaggio un timestamp. Utilizzando il clock fisico delle macchine si crea un problema di sincronizzazione di tutti i server. Ammettendo di effettuare tale sincronizzazione, anche il protocollo con cui essa è realizzata dovrebbe essere sicuro. Il problema diventa quindi difficilmente risolvibile e viene inutilmente complicato.
Per risolvere il problema utilizzeremo un clock logico (contatore) unico per ogni client. A invia, oltre la propria identità e quella del destinatario, anche un timestamp incrementale (t1). LAS risponde con lo stesso valore; in questo modo siamo sicuri della freschezza del messaggio, poiché se questo venisse riutilizzato A vedrebbe recapitarsi un messaggio con un numero inferiore a quello che lui ha attualmente in memoria. Il messaggio di richiesta non ha bisogno di essere crittografato poiché è importante solo la corrispondenza del valore nei messaggi tra A e S. Nel caso eventuali intrusioni modificassero tale messaggio A non riconoscerebbe più il Server come mittente del messaggio e inizierebbe nuovamente la procedura di richiesta. Analogamente lavorerà B.
1. |
A->S |
A,B,t1 |
A richiede a S la chiave pubblica di B |
2. |
S->A |
{PKB,B, t1}SKS |
S manda ad A la chiave pubblica di B cifrata con la sua chiave segreta. Il messaggio viene cifrato per assicurare che non sia possibile modificarlo. A (e chiunque altro) può decifrare il messaggio usando la chiave pubblica del Server, PKs. |
|
|
|
|
4. |
B->S |
B,A, t2 |
B richiede ad S la chiave pubblica di A. |
5. |
S->B |
{PKA,A, t2}SKS |
S manda ad B la chiave pubblica di A cifrata con la sua chiave segreta. |
|
|
|
... |
Il DNS è suddiviso in domini gerarchici. Organizzeremo il DNS secondo un principio di delegazione. Ciascun dominio cioè, può delegare la gestione dello spazio dei nomi di ogni suo sottodominio al sottodominio stesso.
Distinguiamo quindi la definizione di dominio da quella di zona che indica quella frazione del dominio di cui si mantiene il controllo (che non è stata delegata ai sottodomini).
Il DNS sarà quindi organizzato come un insieme di Name Server (NS), ciascuno competente per una determinata zona.
Un NS mantiene quindi i seguenti tipi di associazioni:
<nome logico utente - indirizzo fisico utente>
<nome logico dominio - NS competente>
<indirizzo AS per il dominio>
In ciascun client sarà presente un resolver che ad ogni richiesta accederà al NS locale, questo deve interagire con gli altri NS per restituire al resolver la risposta.
Si è molto discusso, infatti, su quali strategie adottare per il coordinamento tra i Server.
Una possibile soluzione è quella iterativa: il resolver interroga il NS locale, che a sua volta interroga una serie di NS alla ricerca di una risposta . Ogni NS a cui è stata inoltrata la domanda, se non è in grado di fornire i dati richiesti, risponde con lindirizzo del NS per lui migliore (vedremo in seguito cosa significa). Alla fine il NS in grado di rispondere restituirà la risposta.
Ad esempio se ogni NS conosce lindirizzo del nodo in cui si trova il NS root, e lindirizzo degli NS dei sottodomini, si può ottenere una soluzione di questo tipo:
Tale soluzione presenta dei vantaggi per il fatto che ogni NS deve conoscere solo lindirizzo della root, unico server che deve rimanere fisso.Questa realizzazione può introdurre un collo di bottiglia perché tutte le richieste sono inviate alla root che potrebbe trovarsi troppo carico di richieste. Comunque lintero procedimento non viene effettuato tutte le volte poiché ogni NS ha la possibilità di fare del caching.
Un altro approccio iterativo può essere quello di partire dal basso. Cioè ogni NS conosce lindirizzo non più della root ma del NS del domino superiore. Ovviamente in caso di spostamenti spetta al NS andare a registrarsi sotto un nuovo gestore. Supponiamo di trovarci nel dominio di spirit.
Questo è naturalmente un esempio in cui si avvantaggiano le richieste locali rispetto a quelle non locali . Se, infatti, fossimo stati in un altro ramo ad inoltrare la richiesta, ad esempio chem avremmo dovuto risalire fino alla root per poi ridiscendere esattamente come abbiamo fatto nellesempio precedente. Anche in questo caso si ipotizza di effettuare del caching che velocizzi la procedura.
Si può pensare anche ad una soluzione transitiva. Ovvero il NS interrogato non restituisce al NS richiedente un indirizzo ma inoltra lui stesso la richiesta al server sottostante. Il server locale, che conosce direttamente il destinatario, provvederà a comunicarlo al NS richiedente.
Questa soluzione impegna meno il server locale distribuendo il carico di lavoro tra tutti i Name Server.
Esiste infine la soluzione ricorsiva che in molti aspetti è simile a quella transitiva. Quando la richiesta giunge al NS competente, non è inviata al NS richiedente ma percorre il cammino inverso a quello della query.
Tale soluzione ha il vantaggio di avere dei messaggi di dimensioni ridotte rispetto a quella transitiva a scapito di un maggior numero di messaggi.
Ovviamente non cè una soluzione migliore in assoluto ma dipende dal tipo di richieste che sono effettuate maggiormente.
Tra tutte si è scelta la soluzione iterativa poiché anche se a prima vista può sembrare onerosa, in realtà mediante il meccanismo di caching permette un successivo riutilizzo degli indirizzi reperiti nella ricerca. Ricordiamo che nella soluzione transitiva e quella ricorsiva tale meccanismo è meno vantaggioso poiché la ricerca è esterna al NS locale che inoltra la domanda e aspetta la risposta.
Nella gestione del DNS assume un ruolo fondamentale il caching. In seguito ad una richiesta iterativa il NS locale memorizza gli indirizzi dei NS con cui comunica, in modo che ad ogni richiesta successiva non si debba ripartire ogni volta dalla root.
Effettuando caching però si può andar incontro a problemi di consistenza. Un NS, infatti, potrebbe mantenere in memoria un indirizzo che non è più valido perché nel frattempo il NS corrispondente è stato spostato. In questi casi il NS non ottenendo risposta dal NS di cui ha lindirizzo dovrà ripetere il protocollo di richiesta e invalidare la cache.
Ogni NS assocerà alle informazioni che comunica un Time To Live (TTL), cioè un tempo di vita delle informazioni.
Il tempo di vita delle informazioni della cache è un compromesso tra performance e consistenza dei dati.
Ovviamente anche la gestione dei nomi deve essere tollerante ai guasti. E necessario formulare delle ipotesi di guasto per quanto riguarda i NS. Considereremo solo guasti singoli, per quanto riguarda la caduta di un nodo in cui è presente un NS. I NS saranno dunque replicati in due (o più) copie, tra cui distingueremo un Primary Server su cui sono mantenuti i dati aggiornati e Secondary Server che periodicamente si aggiorneranno collegandosi al Primary Server. Primary e Secondary Server devono essere ovviamente failure-independent e quindi collocati su nodi differenti. La replicazione, oltre che per la tolleranza ai guasti, è utile anche per alleggerire il carico del server primario e distribuirlo su nodi diversi.
Nella realtà, lindirizzo reperito dal Client non sarà direttamente quello dellAS che detiene le informazioni sugli utenti locali, ma quello di un gestore. Tale gestore ha la funzione di bilanciare le richieste fra le varie copie che svolgono il servizio. Il gestore (costituito da una coppia Master Slave per motivi di robustezza ai guasti) inoltra la richiesta ad una copia, attende la risposta e provvede ad inviarla al Client.
Il numero di copie è variabile e dipende anche dalla quantità di richieste che mediamente bisogna soddisfare.
Trattando solo il problema della distribuzione delle chiavi, e non quello della registrazione di nuovi utenti, (compito svolto da unautorità di certificazione esterna), non è previsto il coordinamento tra le varie copie.
Il Gestore deve distribuire le richieste alle varie copie. Poiché il tempo delaborazione delle richieste è uniforme tra tutte le copie (a prescindere dalla velocità della macchina su cui esegue la copia) un semplice approccio è di assegnare sequenzialmente le richieste a tutte le copie. Se una copia non risponde entro un determinato intervallo di tempo, il messaggio viene ripetuto. Se neanche questo messaggio ottiene risposta, la copia viene considerata inattiva e la richiesta viene inoltrata alla successiva copia. Una copia inattiva per tornare a ricevere richieste deve registrarsi nuovamente.
Una copia quando si registra ha bisogno del database delle chiavi. Il gestore mantiene una copia in memoria permanente utilizzata solo per inizializzazione delle copie. Ovviamente linvio del database alle copie deve essere cifrato con la chiave privata dellAS
A seconda del tipo di comunicazione si è pensato di utilizzare un diverso protocollo. Le comunicazioni nellambito del DNS vengono implementate mediante un protocollo senza connessione (UDP) in quanto trattasi di messaggi di dimensione contenuta. Si preferisce, infatti, in questa fase della comunicazione, puntare più alla velocità che allaffidabilità. Si introducono pertanto controlli aggiuntivi per rimediare alle situazioni di perdita di pacchetti.
Quando invece è la sicurezza il fattore fondamentale si utilizza un protocollo a stream (TCP) affidabile e sicuro. In questo caso si predilige laffidabilità allefficienza. Tali comunicazioni coinvolgono i due Client, lAS e il Client: in particolare, il gestore dellAS e il Client. Un'altra comunicazione a stream riguarda linvio del database delle chiavi pubbliche a seguito della registrazione di una nuova copia. Infine i messaggi di richiesta e risposta tra gestore e copie utilizzano datagrammi.