4  Gestione delle chiavi coinvolgendo multipli domini

Questa sezione considera modelli di gestione di chiavi per sistemi che coinvolgono multipli domini o autorità, opposto ai  modelli più semplici a singolo dominio. Un dominio di sicurezza (dominio) è definito un (sotto)sistema sotto il controllo di una singola autorità, in cui gli utenti hanno fiducia. La politica di sicurezza implementata in un dominio è definita implicitamente o esplicitamente dalla sua autorità. La fiducia che ogni utente, in un dominio, ha nella sua autorità proviene da, ed è mantenuta attraverso, un'entità specifica con cui condivide la chiave segreta o la password (nel caso simmetrico), o il possesso della chiave pubblica dell'autorità (nel caso asimmetrico). Questo permette di stabilire canali di comunicazione sicuri (che garantisce autenticità e/o confidenzialità) tra l'utente e l'autorità, o tra due utenti nello stesso dominio. I domini di sicurezza potrebbero essere organizzati (gerarchicamente) per formare domini più grandi [3]. 

4.1   Fiducia tra due domini

Due parti A e B, appartenenti a distinti domini di sicurezza  D_A e D_B con le rispettive autorità T_A e T_B, potrebbero desiderare di comunicare  in modo sicuro (oppure A potrebbe desiderare di accedere alle risorse da un distinto dominio D_B).

Questo problema può essere ridotto alla richiesta che sia  A che B (condivisione di una chiave simmetrica) stabiliscano una chiave segreta, condivisa  k_AB, in cui  hanno fiducia, visto che è conosciuta solo dall’altro utente (e possibilmente dalle autorità fidate); oppure (condivisione di chiavi pubbliche fidate) acquisiscano fiducia in una o più chiavi pubbliche comuni, che potrebbe essere usate per instaurare fiducia tra i domini, per esempio permettendo la verifica dell’autenticità  dei messaggi  proposti dall’altro, o assicurare la confidenzialità dei messaggi spediti all’altro. Se T_A e T_B  hanno una relazione di fiducia esistente, una richiesta potrebbe essere fatta usando questa ed altre relazioni di fiducia direzionate dalla coppia inizialmente, che permettono canali di comunicazione sicuri tra le coppie (A, T_A ), (T_A , T_B ) e (T_B ,B), per essere successivamente usate per stabilire la relazione di fiducia oggetto (A, B) (Figura 3). Questo può essere fatto da A e B essenzialmente delegando alle rispettive autorità il compito di acquisire fiducia in un'entità che è sotto il controllo di un'altra autorità. Se T_A e T_B non condividono direttamente una relazione di fiducia esistente, una terza autorità T_C , nella quale entrambi hanno fiducia, potrebbe essere usata come un intermediario per raggiungere gli stessi risultati finali. Questo è analogo alla catena di fiducia nel caso delle chiavi pubbliche. 

                                    Figura 3.  Comunicazione tra due domini

Le due possibili soluzioni  al problema della comunicazione tra due domini sono di seguito discusse con maggiori dettagli. Nel caso della chiave simmetrica fidata, la fiducia in una chiave segreta condivisa potrebbe essere acquisita tramite una varietà di tecniche di accordo su chiavi autenticate. Descriviamo i passi attraverso i quali le parti A e B possono fare ciò che è stato descritto sopra :

1. A fa una richiesta a T_A  per ottenere una chiave da condividere con B;

2. T_A e T_B stabiliscono una chiave segreta a breve termine k_AB;

3. T_A e T_B rispettivamente, distribuiscono k_AB ad A e B garantendo   segretezza e autenticità ; 

4. A usa k_AB  per comunicazione diretta sicura con B. I messaggi possono  essere eliminati se il loro contenuto è ritrasmesso da T_B  ad A tramite T_A come parte di messaggi esistenti; 

In questo caso, dal punto di vista di A la composizione di  T_A e T_B, e le relazioni di fiducia (T_A, T_B) possono essere viste come una singola autorità, con cui  A comunica tramite T_A. Nel caso della chiave pubblica fidata, la fiducia in una chiave pubblica potrebbe essere acquisita attraverso autenticazione dell'originalità dei dati con tecniche standard, quali firme digitali, o code di messaggi di autenticazione. A può acquisire la chiave pubblica fidata dell'utente B, descritta sopra con i seguenti passi:  

1. A richiede a T_A la chiave pubblica fidata di B; 

2. T_A acquisisce la chiave da T_B, con autenticità garantita;

3. T_A  trasferisce questa chiave pubblica ad A con autenticità garantita; 

4. A usa questa chiave pubblica per comunicazioni dirette e sicure con B.

Definizione: un certificato ibrido (o certificato-CA) è un certificato creato da una CA che certifica la chiave pubblica di un'altra CA [3]. 

E’ possibile trasferire fiducia tra domini diversi nel seguente modo: assumiamo che T_B ha creato un certificato C_B, contenente l’identità e la chiave pubblica di B, allora T_A crea un certificato ibrido contenente l’identità e la chiave pubblica di T_B. L'utente A, possedendo la chiave fidata di verifica della firma di T_A, può verificare la firma su quest’ultimo certificato, acquisendo fiducia nella chiave di verifica della firma di T_B, e permettendo ad A di verificare e quindi avere fiducia nella chiave pubblica di B(o la chiave pubblica in ogni altro certificato firmato da T_B). Quindi l’utente A dal dominio D_A (con autorità T_A) acquista fiducia nelle chiavi pubbliche certificate in D_B da T_B .  

4.2 Catene di certificati coinvolte in  multiple CA

Esistono diverse alternative per organizzare relazioni fidate tra CA, in sistemi a chiave pubblica che coinvolgono multiple CA [3]. Queste sono chiamate modelli fidati o certificazioni topologiche, e sono logicamente distinte dai modelli di comunicazione (a volte coincidono). Relazioni fidate tra CA determinano come i certificati emessi da una CA possono essere usati o verificati da utenti certificati da distinte CA in altri domini.  

I  certificati di chiavi pubbliche forniscono un mezzo per ottenere chiavi pubbliche autenticate, fornendo al verificatore una prova di verifica fidata attraverso la chiave pubblica della CA che ha firmato il certificato. Nel caso di multiple CA, il verificatore vorrebbe ottenere la chiave pubblica autentica, verificando un certificato firmato da CA oltre che quello per il quale possiede una chiave pubblica fidata. In questo caso il verificatore può ancora fare ciò data una catena di certificati che può essere costruita e che corrisponde ad una catena di fiducia dalla chiave pubblica della CA nella quale il verificatore ha fiducia, alla chiave pubblica in cui esso desidera aver fiducia. Le catene di certificati corrispondono a path dirette  nella rappresentazione grafica di un modello fidato CA (Figura 4). Lo scopo è di trovare una sequenza di certificati corrispondente ad una path diretta (path di certificazione) che parte dal nodo corrispondente alla CA nella cui chiave pubblica il verificatore ha fiducia a priori, e termina nella CA che ha firmato il certificato della chiave pubblica da verificare.

                                                      (a) Alberi con radici multiple

                                         (b) Grafo diretto per il modello di fiducia

                                  Figura 4.  Modelli di fiducia per la certificazione

Un’illustrazione di una catena di certificati  è la seguente (Figura 4(b)): supponiamo che un’entità A in possesso della chiave pubblica P₅ della CA₅ desidera verificare il certificato di un utente B firmato da CA₃, e ottenere fiducia in P_B. Una path diretta (CA₅, CA₄, CA₃) esiste. Supponiamo che CA₅(CA₄) denota un certificato firmato da CA₅ che lega il nome CA₄  alla chiave pubblica P₄ . La catena di certificati (CA₅(CA₄), CA₄(CA₃)), con fiducia iniziale in P₅, permette ad A di verificare la firma su CA₅(CA₄) per estrarre una copia fidata di P₄, usa  P₄, per verificare la firma su CA₄(CA₃) per estrarre una copia fidata di P₃, e usa P₃ per verificare l’autenticità del certificato contenente  P_B.

Un altro esempio di costruzione di catene di certificati usando coppie di certificati ibrido è il seguente : una tecnica di ricerca per trovare la path di certificazione, citata nell’esempio precedente, necessita di coppie di certificati ibridi. In una directory pubblica, per ogni entrata CA X e per ogni CA Y, sia che X sia certificato (da certificato ibrido) e sia che X certifica, si memorizza la coppia di certificati (forward, reverse) = (CA_y(CA_x), CA_x(CA_y)), chiamata una coppia di certificati ibrido. La coppia consiste dei certificati di CA_x forward e reverse, ed almeno uno dei due certificati è presente.

In assenza di più avanzate tecniche o tabelle di routing, ogni path di certificazione esistente potrebbe essere trovata attraverso una ricerca in profondità o in ampiezza dei certificati reverse nella coppia di certificato ibrido che inizia dal CA relativa alla chiave pubblica che il verificatore possiede inizialmente [3].

4.3  Possibili attacchi alle CA

Si potrebbe pensare che le CA siano difese da tutti i possibili attacchi, per esempio un attaccante potrebbe tentare di scoprire la chiave privata di una CA "rompendo" l’ingegneria del dispositivo in cui è memorizzata. Per questa ragione una CA deve adottare precauzioni estreme per prevenire accessi illegittimi alla sua chiave privata.

La chiave di un CA potrebbe essere l’obiettivo di un attacco esaustivo di crittoanalisi. Per questa ragione le CA dovrebbero usare lunghe chiavi e cambiarle regolarmente. Le CA di top-level necessitano esplicitamente lunghe chiavi rendendone difficile una sostituzione frequente  visto che la chiave potrebbe essere scritta in un software usato da un grande numero di verificatori.

Se un attaccante rompe la chiave del CA ed  essa non è più valida, l’attaccante, detto Alice, può falsificare un certificato datato quindici anni prima che attesta una chiave pubblica falsa per qualche altra persona, detta Bob. Alice può allora falsificare un documento con una firma di Bob datata quindici anni fa, per esempio Bob lascia tutto ad Alice. Ciò che si evince da questo attacco è come firmare un documento datato diversi anni fa. Il timestamp è una soluzione a questo caso. Ci sono altri attacchi da considerare che però non coinvolgono la compromissione della chiave privata della CA.

Per esempio, supponiamo che Bob desidera impersonare Alice. Se Bob può firmare convincentemente messaggi come Alice esso può spedire un messaggio alla banca di Alice per ottenere dei soldi. Per eseguire questo attacco Bob genera una coppia di chiavi e spedisce la chiave pubblica ad una CA dicendo di essere Alice e di certificarlo con quella chiave pubblica . Se la CA è ingannata e spedisce  a Bob un certificato esso può imbrogliare la banca e quindi eseguire con successo tale attacco. Per evitare tale attacco la CA deve verificare che una richiesta di certificato provenga dal legittimo proprietario cioè la CA deve richiedere sufficienti informazioni che attestino che è proprio Alice a richiedere il certificato. Un altro attacco consiste nel fatto che Bob corrompe qualche persona che lavora per la CA per farsi emettere un certificato a nome di  Alice. Così Bob può spedire messaggi firmati col nome di Alice ed ogni ricevente crederà che sia autentico visto che una catena di certificati piena e verificabile accompagna il messaggio [1].

4.4   Perdita o compromissione della chiave della CA

Se la chiave di una CA è persa o distrutta ma non compromessa, i certificati firmati con la vecchia chiave sono ancora validi fino a quando il verificatore conosce l’uso della vecchia chiave pubblica per verificare il certificato. Si potrebbe mantenere una copia di backup cifrata della chiave privata della CA in un dispositivo in modo da poterla ripristinare quando essa è persa. Se il dispositivo è distrutto la fabbrica può fornirne un altro con le stesse informazioni interne  permettendo il recupero della chiave. La compromissione della chiave della CA è la situazione più disastrosa. Un attaccante che scopre la chiave privata di una CA può emettere certificati falsi a nome della CA, che potrebbe causare falsificazioni  non individuabili.

Se una compromissione della chiave occorre, la CA deve immediatamente cessare di emettere certificati con la vecchia chiave e deve adottarne una nuova. Se la CA sospetta che qualche certificato falso è stato emesso, tutti i certificati dovrebbero essere ritirati e riemessi con la nuova chiave della CA. Queste misure potrebbero essere rilassate se i certificati furono registrati con un servizio digitale di timestamping. La compromissione di una chiave CA non invalida le chiavi degli utenti, ma solo i certificati che le autenticano. La compromissione della chiave privata della CA di top-level potrebbe essere catastrofica, visto che la chiave pubblica potrebbe essere coinvolta in applicazioni che verificano i certificati [1].